Daedalus is an SSI program to teach design principles of high power rocketry with hands-on experience. Teams will design and launch novel rocket concepts iteratively, starting with L1, L2 and finally ending with an L3 rocket that successfully flies the thoroughly tested design. The technology coming out of this project will benefit the Rockets Team’s flagship rocketry project.

Documentation of the process is a crucial aspect of Daedalus. Explaining pitfalls, triumphs, and the minutiae of designing a fully functional rocket will aid and speed up the process for future teams. Each team will go through a five stage development cycle: 1. research, 2. preliminary design, 3. critical design, 4. testing and documentation review, 5. build and launch. The milestones will focus on providing hardware - not presentations.

1. The rocket will be certified through Tripoli Rocketry Association or the National Association of Rocketry
2. Most of the rocket must be able to be machined or modified on Stanford’s campus.
3. Level 3 Certification allows fliers to fly High Power Rockets with a total installed impulse greater than 5120 N-s.
4. See appendix for all the rest of the details.
   

After many hours of thought, the team decided on the name Daedalus. The justification can be understood from reading this highly relevant wikipedia quote: “Daedalus was a skilled craftsman and artist... Daedalus set to work to fabricate wings for himself and his young son Icarus. He tied feathers together, from smallest to largest so as to form an increasing surface. He secured the feathers at their midpoints with string and at their bases with wax, and gave the whole a gentle curvature like the wings of a bird. When the work was done, the artist, waving his wings, found himself buoyed upward and hung suspended, poising himself on the beaten air. He next equipped his son in the same manner, and taught him how to fly." [1]

Phases

The project will be broken up into three phases.

Phase 1. Research and Preliminary Design Review of Concept

• This entails understanding the concept you’re flying, basic implementation details, soft numbers on final rocket size and characteristics, and most importantly how you will test out the concept.
• Most of the calculations should be able to bluntly characterize the system so we can refine the method with empirical methods. This will require teams to begin by choosing the parameters that they have the least control over (maximum diameter of an airframe made of a certain type of polycarb for instance).
• There will be many interdependent parameters that will make the project seem insurmountable, but it is essential that you find a way to find the most important ones and characterize them. For example, say you have a function F, and you know that a whole bunch of things affect this function: F(g(x1), h(x2), i(x3)). You need to find what parameters are actually constrained and matter to the system. It would be good then to find what x1, x2, and x3 represent in order to truly understand the system. Then using your constraints and current understanding, take an educated guess as to what they are. Plug that into your function and repeat until you have a reasonable answer. Guess and check is essential at this stage.
• Get to know your team.
  • Understand your strengths and weaknesses and use them to your advantage. Specialization is encouraged. There are four categories in a conventional model rocket that will need work: Avionics, Propulsion, Recovery, and Structures. Each is flight critical and will need to be integrated with the concept that you will be testing.
  • One person needs to serve as the team lead in order to act as a systems engineer. The team lead will ensure that every system is in communication with the other and that nothing will interfere with itself.
  • Having the same level of engagement is critical to succeeding. One person can theoretically do this herself, but you are also Stanford students who are over-committed and extremely busy. Don’t be a black hole, ask for help if you can’t do it alone.
  • Set up at least two meetings/work sessions a week with your team.

This process of figuring out a PDR will speed up as more and more people graduate from Daedalus.

Phase 2. Hardware Testing and Critical Design Reviews

• This phase is more rigorous than the previous. It will require testing and reiteration of designs over a quarter in order to launch a safe L3 by the end of Winter/beginning of Spring quarter.

• Testing outside of the official hardware tests is highly encouraged.

• The concept will be tested on an L1, L2 and finally on the L3 rocket over a time period of three to four months. Each test (L1, L2, and L3) will require a PDR, CDR and Hardware Review. The L1 and L2 tests will be used to gradually increase the capabilities of each rocket as well as provide useful data for future testing and integration. Each official test should be used as a major milestone to review and add more complex and critical flight systems to the final version of the rocket. This has to be done in order to document the process and have enough time to back out of any potentially dangerous launching situations. An example has been provided to clarify the process.
  

  • Using ARES-4 (Prometheus) as an example. The eventual goal of Prometheus is to bring a payload down with PID controlled fins in order to stabilize descent. The L1 test will test out the ability to deploy servo-controlled fins at apogee. This is a challenge because it will need to be perfect on the L3 in order to be considered successful. The next test which is a month away, will take the rocket higher (due to the L2 motor). By this time, the team should have created the control system for the fins. This test will then integrate fin deployment and PID control on an L2 rocket. That same day, the team will get their L3 certification. That rocket will be a testbed for their fins later on, but will not use the PID fins during flight certification - in order to just test out the basic design of the L3 rocket. The next launch will integrate the fin deployment and controller system onto the L3 rocket.

  The goal is to test out each part of each critical subsystem separately and on useful scales in order to ensure a successful end flight.
  Certification launches will be done at the Tripoli Central California launch days (every third Saturday of the month). LUNAR holds launches at Snow Ranch every first Saturday of the month; these will serve as backup launch dates (or extra testing dates if failure occurs). See schedule for more specifics.

Phase 3. Build, Flight Readiness Review, and L3 Launch

• Finish final CDR and freeze design work completely.
• Refurbish the L3 that your team has launched once or twice at this point with the complete system.
• Have your reports completely generated and thoroughly vetted by Rockets leadership.
• Compile all documents into a useful (and slightly informal) report.
• Launch.

All the work in Phase 2 will have built up to this point. At this stage your team should be confident in its data and ability to have a safe L3 flight.

Design Reviews

Preliminary Design Review

“A PDR demonstrates that the overall preliminary design meets all requirements with acceptable risk, and within the cost and schedule constraints, and establishes the basis for proceeding with detailed design. It shows that the correct design options have been selected, interfaces have been identified, and verification methods have been described. Full baseline cost and schedules, as well as all risk assessment, management systems, and metrics, are presented.” After the research and initial design processes are completed, each team will present their design considerations to Rockets leadership to receive constructive criticism. Lightning’s PDR has been shared with you as an example as well as several others from MIT, Vanderbilt, etc. A visual presentation of the information is required, since teams will give an in-person presentation about their plans. Google Slides/PowerPoint highly encouraged, as well as useful diagrams (CAD, drawings, block diagrams of avionics, etc.). A text version of the PDR is also required, with the following sections included:

1. Team Summary
2. Launch Vehicle Summary
3. Payload Summary
4. Vehicle Criteria
   1. Mission Statement
   2. Mission Success Criteria
   3. Constraints
   4. Systems Overview
   5. Propulsion
      1. Motor performance
      2. Flight Characteristics
   6. Structural
      1. Bill of Materials
      2. Nosecone
      3. Fins
      4. Airframe
   7. Avionics
      1. In-Flight Tracking
      2. Other avionics things...
   8. Parafoil/fins/whatever concept
      1. Details
   9. Backup Systems
   10. Mission Performance Predictions
5. Manufacturing and Assembly
6. Systems Integration and Testing
   1. Major Vehicle Milestones…
7. Risk Management
   1. Safety Hazards
   2. Budget
   3. System Functionality
8. Activity Plan
   1. Timeline
   2. Budget
      

Calculations and graphs are required to be included in your PDR. LaTeX is also strongly encouraged! Many examples of Latex documents have been generated (including this document) by the Rockets team. It should also be noted that for every plot, the required code/mathematics behind the plot should be included at the end of the presentation version of the PDR.
Whenever a test of the concept is conducted on a smaller rocket, those rockets will also require a PDR. For example, if a team is planning to test a part of their system on an L1 rocket, they must write a text PDR for that specific L1 with the same sections. These do not have to be as in-depth however since a team will most likely be using a kit and modifying it slightly. The Systems Integration section will probably not be necessary as well, since it encompasses the entirety of the project (not a single test). Furthermore, L1 and L2 launches already have a Risk Management plan approved by Stanford, so the sections on Risk Management can be ignored.

Critical Design Review

After the design phase is completed, there will be another design review with Rockets leadership and outside observers. Once a team revises their rocket based on feedback, design will freeze and the next phase will begin. You must create a presentation as well as a text document (just like PDR). It should include all the previous categories and an additional section: Major Changes Since PDR.

Conventions

CAD and Drawing

Each team will conform to the NASA Drawing standards (a document that will be provided). Any part that is created or modified will need to pass through two checks: the project manager, Ian Gomez, and the manufacturing lead, Chris May.

Analysis of Rocketry Problems: Methodology

In solving complex problems, we recommend a systematic procedure that most engineering classes make use of at Stanford. It consists of the following steps:

1. Known: After identifying the problem, state briefly and concisely what is known about the problem.
2. Find: State briefly and concisely what must be found.
3. Schematic: Draw a schematic of the system. If application of the conservation laws is anticipated, represent the required control surface or surfaces by dashed lines on the schematic.If there are forces acting on the system, denote them with appropriately labeled arrows on the schematic.
4. Assumptions: List all pertinent simplifying assumptions.
5. Properties: Compile property values needed for subsequent calculations and identify the source from which they are obtained.
6. Analysis: Begin your analysis by applying appropriate laws, and introduce equations as needed. Develop the analysis as completely as possible before substituting numerical values. Perform the calculations needed to obtain the desired results.
7. Discussion: Discuss your results. Such a discussion may include a summary of key conclusions, a critique of the original assumptions, and an inference of trends obtained by performing additional what-if and parameter sensitivity calculations.
   

Question Checklist

What do we care about? Provided is a non-exhaustive list of things you will need to think about every time you design something new (or review an old system for mistakes).
Big questions

• What is it?
• How does it work?
• What will it do?
• How does it get there? how fast?

Design

• Is it static or dynamic?
• How much stress or load will it take?
• How will it accelerate?
• Can we make it? easily? quick prototype? cost?
• Can we model it? assumptions? cost to do more complex analysis?

Thermal

• How much heat will it generate?
• How much heat can it store without breaking?
• How much heat will move through it (flux)?
• How can we prevent it from breaking?
• Can we make it more efficient?

Fluids

• How much pressure over surface area?
• How heat transfer occurs?
• How much drag? how much lift/thrust required?
• Do we care about this?

Electronics/Coding

• Do we know the states it needs to exist in?
• How does it know where it is?
• How much power will it draw?

Teams

Every team will have a team lead and a concept design lead. Team lead responsibilities have been outlined above in the Phase 1 section. They will be in close contact with the current project managers. Concept design leads will maintain domain over the integration of the advanced concept. Work to be divided up as each team sees fit. The designation for this mission is ARES, which stands for Advanced Rocketry and Experimental Systems.

ARES-1

ARES-1, code name Talos, is the designation for the rocket which will be a testbed for the avionics suite.

ARES-2

ARES-2, code name Pegasus, is the designation for the rocket which will test a parafoil descent system.

ARES-3

ARES-3, code name Charybdis, is the designation for the rocket which will use canted fins.

ARES-4

ARES-4, code name Prometheus, is the designation for the rocket with PID controlled descent system.