As a launch vehicle engineer, I have a bit of a unique job.  My job is to get a payload into space so that it can complete its goals.  NASA sounding rockets take advantage of pre-existing motors originally designed for military applications.  This means that launch vehicle engineering is often subject to requirements that were defined decades ago.  Ensuring that decades-old motors are ready for flight while designing modern hardware that interfaces with hardware designed the better part of 50 years ago provides a unique challenge not really seen elsewhere in the sounding rocket program.

Projects

While working as a launch vehicle engineer, I have undertaken a number of projects ranging from design to major updates and improvements to analysis code

Interstage Design for a Proposed Vehicle Stack:

Every multi-stage vehicle requires an interstage in order to mate stages together and allow technicians to access required parts of the vehicle for mating and checkout operations.  The motors interfacing with the interstage will be left unstated until it becomes publicly available information.

Requirements

• Interstage will allow 2 motors to mate to one another, allowing for drag separation at first stage burnout

  • Aft end of upper motor and for end of lower motor have different diameters

• Interstage will survive all pre-flight and flight loading conditions with an appropriate factor of safety

• Interstage will be designed with weight and flow characteristics in both subsonic and supersonic regimes as considerations

• Interstage must be designed with consideration to manufacture

Challenges

• Non-standard radax joint required to mate stages

• Proper fastener hole alignment on transition door and door cutout

  • Centerpoint alignment of fastener holes will not give proper registration

• Compromise between additional structural margin and reduced interstage mass

Technical Skills Used

• Structural Design

  • SolidWorks

• Finite Element Analysis

  • SolidWorks

• Geometric Dimensioning and Tolerancing (GD&T)

  • SolidWorks

For a sample interstage, please see below

Recovery System Drawing Updates

On Black Brant series recovery flights, we use a ogive recovery system located at the forward end of the vehicle (NFORSe).  NSROC currently flies 3 different NFORSe configurations, with plans to add a 4th to accommodate heavier payloads.  The design work has already been done for this, so I served as a reviewer for engineering drawings.  My job was to ensure that drawings for each part accurately conveyed the true part and were made in such a way that the part was properly dimensioned and made use of GD&T.

Requirements

• Review NFORSe drawings, ensure tolerancing is acceptable, dimensioning is done appropriately, GD&T is used properly

Challenges

• Becoming familiar with GD&T

• Gaining confidence with reviewing complicated engineering drawings

• Discrepancy in controlling document between machine shop and inspection

  • Machine shop largely ignores callouts on drawings while inspection uses drawing as the controlling document

Technical Skills Used

• Engineering Drawing Review

  • SolidWorks

• Geometric Dimensioning and Tolerancing (GD&T)

  • SolidWorks

Automatic Launch Detection

During a launch, any instruments flown will start recording when turned on.  This means that T0 is rarely with respect to launch.  Previously, a time-acceleration plot would be generated and a user would manually pick the launch time.  This time is then used on nearly everything downstream as we work with times relative to launch.  Manually selecting the launch time slows down the data analysis process and adds the risk of downstream code breaking should the wrong time accidentally be selected or inputted.  getLaunchTimes is a MATLAB function designed to detect launch based on Z-Axis (Roll-Axis) acceleration.  It works by sampling data in order to detect the average signal noise, then detecting the first area where the reported acceleration is outside of the noise range.

Selecting the first location where there is reported acceleration greater than the expected signal and noise is not foolproof.  It is not uncommon to see a spike at a random time.  These spikes are only 1-2 datapoints long and are clearly an erroneous value.  As such, they can be filtered.  After getLaunchTimes detects a spike, it will continue searching for 1 second beyond the detected spike.  If launch truly was detected, nearly all datapoints in this set should have an acceleration greater than 1.5 g.  If more than 150 datapoints (~1/8 second) worth of datapoints do not meet this acceleration condition, it is clear that we have detected an erroneous spike.  The filter then discards this value and continues searching, until true launch acceleration is detected.

The user is prompted to confirm the detected time.  If getLaunchTimes has detected the incorrect time, the user will manually input the launch time.

Requirements

• getLaunchTimes will successfully detect the time of launch based on Z-Axis acceleration data.

  • The user will confirm the time to be correct.

  • The user has the ability to manually select the launch time.

• getLaunchTimes will increase the speed and ease of use of postflight data analysis.

• getLaunchTimes will work with all missions we fly.

Challenges

• Accelerometers record at ~1250 Hz, it is not uncommon for getLaunchTimes to handle upwards of 1.5 million datapoints.

• Erroneous spikes will case getLaunchTimes to report an incorrect launch time.

  • Spike filter developed as a response to this.

• MATLAB is a case sensitive language.

  • Developer of data analysis code getLaunchTimes interfaces with used both cases to refer to different variables.

    •  start_time and Start_time refer to different variables.

Technical Skills Used

• MATLAB

  • Large Data Handling

• Signal Processing

• Debugging and Optimization

The Block Diagram for getLaunchTimes can be found below

Magnetometer Roll Rate

We use gyro data for our primary roll rate data, but use magnetometers for backup.  Our current magnetometer roll rate analysis code is an .exe written in 2001, for which back end code is either missing or does not exist.  Because it is outside of MATLAB, where we run all of our other analysis code, running this .exe adds a significant amount of time to the data analysis process.  This code only seems to be able to record roll rate at 2 samples per revolution, likely when the magnetometers cross the 0-180 plane.  

Fortunately, raw magnetometer data follows a sinusoidal function, meaning that we can take a derivative.  Sine and cosine are offset by 90 degrees, meaning that when one of the functions is passing through zero, the other will be at a peak or trough.  We can take advantage of this by taking the derivative of the magnetometer sine function, then finding the peaks on both the raw and differential functions.  Finding the peaks on both of these functions allows us to measure the roll rate at 4 samples per revolution, meaning that we have doubled our sampling rate simply by knowing calculus.  Once we have counted peaks, all that is left is to place them in the appropriate order, and measure the delta time between peaks.  Then dividing 0.25 (we have delta time between quarter revolutions) by this delta time, we are able to find the roll rate at discrete timesteps.

The updated roll rate function has been written in MATLAB, meaning that it interfaces with the rest of our data analysis suite effortlessly.  Using an automated tool to calculate roll rate has reduced the time required from roughly 5 minutes with the .exe to 2.9 seconds with the roll rate function I wrote.

Requirements

• At a minimum, updated roll rate code must work as well as the current analysis .exe

• Updated roll rate code must provide a notable improvement, whether in quality of life or results, in order to justify the switch

Challenges

• Raw magnetometer data requires heavy smoothing in order to eliminate signal noise to the point that peak counting can be reliably used

  • Over smoothing of data runs the risk of eliminating real events, while under smoothing means that excessive noise is contained in dataset

• On vehicles with no spin motors, magnetometer data can take a few seconds to stabilize as the vehicle rolls up

Technical Skills Used

• MATLAB

• Signal processing

• Differential calculus