NASA Student Launch Case Study
/An OpenMETA model for the conceptual design of a high-powered rocket for the Collegiate NASA Student Launch competition
Using the NASA Student Launch competition as a case study, OpenRocket was integrated into the OpenMETA framework to demonstrate the strengths of Model Based Systems Engineering (MBSE) in complex design fields. The MBSE approach allows an engineer to develop a small number of models, and continuously simulate different variations until a desirable solution is found. In this case study, 972 rocket designs were considered. After several rounds of analysis, this large design space was narrowed down to a single final design, shown below.
Final rocket design chosen using an MBSE design approach
SOURCE: METAMORPH, INC.
NASA Student Launch
NASA Student Launch (NSL) is a STEM outreach initiative hosted by Marshall Space Flight center in Huntsville, AL. Now in its 18th year, this exciting rocketry competition provides research-based, experiential learning for students while simultaneously producing relevant, cost-effective research for NASA. Over a period of 8 months, middle school, high school, and university student teams from about 23 states design and test high-powered rockets containing an experimental payload.
For this case study, a rocket was designed as if we were entering the Collegiate-level NSL competition. For this competition, the launch vehicle must:
- reach an apogee of exactly 5,280 ft (~1609 m) above ground level, and
- use a motor class no greater than L.
Additional vehicle requirements include:
- Must use an 8 ft (~2.4 m) launch rail
- Minimum static stability margin of 2.0 at rail exit
- Minimum velocity of 52 fps (~15 m/s) at rail exit
- Speed cannot exceed Mach 1 (~343 m/s)
Additionally, NSL rockets have strict recovery requirements. Each rocket must deploy two parachutes: a drogue parachute at apogee and an additional main parachute at a lower altitude. It must land within a 2500 ft radius of the launch pad, with a maximum landing kinetic energy of 75 ft-lbf per section.
We also imposed a two extra requirements to make the results more realistic:
- Maximum acceleration must not exceed 15 g’s (~147 m/s^2)
- Maximum landing velocity must not exceed 11 mph (~5 m/s)
More detailed information about the vehicle requirements of NSL can be found here.
OpenRocket
SOURCE: OPENROCKET
OpenRocket is an open-source Java application that allows users to design and simulate model rockets before building them. It features an extensive catalog of components and materials, along with the ability to create custom components and materials. Its robust simulations provide easily extractable results including both time series data (altitude, stability, etc) and summary scalar values (maximum velocity, apogee, etc). Many NSL teams use this exact software to simulate their designs before launch day.
With just a few simple source code changes and a Java-Python bridge library called JPype, this application was easily integrated into the OpenMETA workflow using OpenMETA Python Components. For specific details on these source code modifications and JPype, see the OpenRocket Modifications section at the end of this post.
Building the OpenMETA Rocket Model
Though specific vehicle requirements are provided, the design space for an NSL-qualified high-powered rocket is quite diverse, making it a perfect application for OpenMETA’s Model-Based Engineering toolset. The highest level of our analysis is the Parametric Exploration Tool (PET). The OpenMETA rocket model is comprised of the following partial models within the PET (shown below):
- OpenMETA design space
- OpenRocket file generator and generic rocket template
- OpenRocket simulation and data retrieval
- OpenMETA parameter study driver
Data flow in the OpenMETA Rocket Model
SOURCE: METAMORPH, INC.
OpenMETA Design Space
We used a design space to encapsulate the discrete decisions made by a designer. These decisions are typically high level choices made at the beginning of the design, such as the material used to make the rocket and the class of the motor used. The full list of discrete design decisions can be found below.
Tree view of discrete rocket design decisions
SOURCE: METAMORPH, INC.
Since each decision shown above is exclusive (one and only one at a time), our generic discrete model provides 972 unique design configurations. Once The OpenMETA Design space is complete, it needs to be wrapped in Testbench before it is included in the PET.
Rocket Design Space Testbench
SOURCE: METAMORPH, INC.
Knowing just the discrete decisions, however, is not enough information to design a successful rocket! After a discrete configuration is determined, other continuous design variables must be calibrated as well. For example, once the nose cone’s shape is determined to be parabolic, the length and base diameter of the nose cone must also be decided. These variables are determined by the PET’s Parameter Study Driver during execution.
OpenRocket file generator and template
The combination of discrete and the continuous variables determined by the PET are passed to GenORK.py, a OpenMETA Python Component which generates the input file for OpenRocket (.ork). This wrapper loads an .ork template called advanced_template.ork and fills in all of the discrete and continuous variables supplied to it. It saves this file to the configuration results folder and passes it on for simulation.
SOURCE: METAMORPH, INC.
OpenMETA simulation and data retrieval
Once generated, the OpenRocket file is passed to another Python Component which simulates the design. Two OpenMETA Python Components were created for this purpose.
The first wrapper (SimORK.py) was written to simulate multiple unique rocket configurations in one PET. Its only required input is an OpenRocket ork file, and its outputs include several simulation results and images of the rocket’s trajectory and thrust curve for each run. Optionally, simulation parameters such as wind speed can be added as inputs for this Python Component.
SOURCE: METAMORPH, INC.
The second wrapper (FullMissionTest.py) is meant to test a single rocket configuration over a variety of simulation conditions. It outputs the same metrics as SimORK.py, but only accepts simulation conditions as inputs.
SOURCE: METAMORPH, INC.
Additionally, two alternative versions of SimORK.py and FullMissionTest.py were created that do not plot and save images of each rocket’s trajectory and thrust curves. These versions were made to enable faster execution of a large-scale PET.
The fully assembled PET is shown below. It studies any number of discrete rocket configurations over a range of continuous design variables and wind speeds.
Fully assembled OpenRocket PET
SOURCE: METAMORPH, INC.
Analyzing the Design Space
As stated previously, there were 972 unique rocket configurations possible from the design space. Each of these discrete configurations was simulated 32 times with varying samples of all its continuous variables, resulting in 31,040 records to review. The results were examined inside of the OpenMETA Visualizer where the mission objective and design requirement constraints were applied to the dataset as filters. The target apogee mission objective was set at 1500 m to 1700 m, allowing for a generous initial range of ±100 m. Of the 972 discrete configurations tested, it was found that only 269 of them satisfied the mission objective and vehicle requirements set forth by NASA and ourselves. Additionally, this round of analysis found that all successful configurations used J class motors.
A second round of analysis was conducted on the 269 successful configurations. To better sample the performance of the remaining configurations, each of these was simulated 96 times, again with varying values for all of its continuous variables. Here the apogee range was refined to 1550 m to 1650 m allowing for only ±50 m off of the target apogee. With the stricter apogee requirement, it was found that only 63 configurations satisfied the mission objective while adhering to the vehicle requirements. Of these 63 configurations, none used carbon fiber as their material as it was too light for the given payload.
A third iteration of simulations was conducted much like the second. The 63 successful configurations were simulated 256 times each, resulting in 15,688 records. Further constraining the apogee mission criteria was avoided, since this may have excluded some designs due to industry standard manufacturer uncertainty in the motor thrust. So rather than tighten design constraints, the different configurations were ranked by performance.
OpenMETA Visualizer TOPSIS ranking function
SOURCE: METAMORPH, INC.
The ranking function shown above took into consideration a rocket’s payload mass, total mass, stability at launch rod clearance, and its overall maximum stability, so that the function favored the smallest rocket with the largest payload that was most stable at launch rod clearance but not overstable overall. The OpenMETA Visualizer displayed the top 25 simulation records as ranked by this function. Of these 25 results, 7 discrete rocket configurations remained.
These 7 configurations were then simulated 1000 times each to ensure that the entire range of all continuous variables were sampled thoroughly before the winning configuration was chosen. These 7000 simulation records were then ranked using the same ranking function described previously, revealing that the optimal discrete configuration was configuration 555.
With the optimal configuration chosen, a final round of analysis was conducted, simulating the configuration 5000 times. The continuous variables were chosen from this final thorough iteration, allowing the complete design to be finalized. To get the best outcome possible, the filters were set to match the design variables exactly, and the target apogee range was limited to 1575 m to 1625 m. The ranking function was again applied to this dataset, the results of which are shown below as a plot of Apogee vs the Rank function.
Plot of Ranking vs. Apogee (meters)
SOURCE: METAMORPH, INC.
The optimal design for our purpose is the one with both the lowest rank and apogee closest to 1609 m, as is highlighted above. The continuous variable values for this optimal design are highlighted below.
SOURCE: METAMORPH, INC.
From the data shown above, we see that the optimal rocket design falls just 6 meters shy of the target altitude, never reaches an understable or overstable stability margin, and weighs just over 6 kg (13.5 lbf).
The Final Design
Final rocket design: Configuration 555
SOURCE: METAMORPH, INC.
The final rocket design is shown above. As mentioned previously, it features discrete configuration 555. Per NSL specifications, the upper body tube includes the payload, and the middle body tube includes both a drogue parachute and a main parachute. The discrete and continuous design variables considered are shown in the table at left. The performance of this design is specified in the table at right.
Design Parameters
| Variable | Final Design |
|---|---|
| Material | Bluetube |
| Finish | Polished |
| Motor | Class J |
| Nose Cone | Conical |
| Nose Cone Length | 25.6 cm |
| Fin Type | Elliptical |
| Fin Cross Section | Rounded |
| Fin Count | 4 |
| Total Mass | 6.17 kg |
| Total Length | 135 cm |
Performance
| Parameter | Requirement | Final Design |
|---|---|---|
| Apogee | 1,609 m | 1,603 m |
| Static Stability @ Rail Exit | > 2.0 | 3.75 calibers |
| Velocity @ Rail Exit | > 15 m/s | 15.59 m/s |
| Mach | < Mach 1 | Mach 0.57 |
| Maximum Acceleration | < 147 m/s2 | 136.59 m/s2 |
| Maximum Landing Velocity | < 5 m/s | 4.89 m/s |
Future Work
Optimization
One large problem in the field of optimization is sampling. Currently, the design space is built so that every component is forced to have the same material and surface finish. This is a realistic simplification for rockets on our scale, but would quickly lead to failure for orbital rockets. If each component were allowed to have a different material and finish, the discrete space would allow for 8748 possible configurations. When scaled up to large rockets, the design space could explode into millions of possible combinations. But how can we efficiently sample millions of configurations?
We are working on a way to sample a large, discrete design space based on the level of effect each decision has on overall system performance. The level of effect each decision has will be stored as a metric inside of the design container. When the configuration generator runs, it will follow a protocol to generate the most diverse designs by first varying the components that have the largest impact. This allows for the full range to be coarsely sampled, while keeping the total number of configurations low. Once a satisfactory performance range is determined, the process can be repeated iteratively allowing for more configurations within each refined range until a desirable design is found.
Motor Impulse Sensitivity Analysis
During the 2017-2018 competition year, we met with a student design team and discussed some of the problems they had while designing their rocket. They found that they had designed their rocket around a motor that had a ±20% uncertainty in the total impulse specified by the manufacturer, which led to them not being able to accurately predict how high their rocket would launch. We plan on countering this by designing a sensitivity analysis comparing motor impulse (and impulse curve) with apogee, rail clearance velocity, and other vehicle requirements. With this addition, the model would be equipped to produce a probabilistic ranking of designs in addition to the "best design" shown above.
Software Improvements
In addition to improving the rocket model itself, changes could be implemented in OpenRocket to improve the design process in OpenMETA. The first of these would be upgrading to OpenRocket version 15.03. Currently, OpenRocket version 1.1.9 is being used, since the OpenRocket developers provided support for modifying the sources code and writing Python scripts for this version. Upgrading would involve changing the source code of version 15.03 and potentially rewriting the OpenRocket helper python library.
Additionally, to enable visualization of the rocket during the design process, sketches of the rocket design could be saved along with the trajectory and thrust curve images during PETs. Such a design sketch can be accessed currently by opening a generated ork file in OpenRocket, but integrating this feature into the OpenMETA toolset would streamline the design process.
OpenMETA Rocket Model Source Code
OpenMETA Rocket Project
This OpenMETA project, including all PET models and Python component source code, is available on OpenMETA’s rocket project GitHub. This repo also contains the modified version of OpenRocket (openmeta-OpenRocket.jar) and detailed instructions on how to install the JPype library in OpenMETA. Additional information and tutorials on the OpenMETA tool set can also be found in the documentation.
OpenRocket Modifications
A few simple changes were made to the OpenRocket source code so that it could be called from a PET using an OpenMETA Python Component. The startup functions initializeLogging(), setLogOutputLevel(), and initializeL10n() were all changed from private to public functions. This version of the OpenRocket source code is available on OpenMETA’s openrocket GitHub repo. The source code was then repackaged as openmeta-OpenRocket.jar, and is available on the rocket project GitHub repo.