NASA Student Launch

Cedarville University's NASA student launch initiative team

For my senior capstone project at Cedarville (Fall 2024 and Spring 2025), I had the privilege of being a part of the NASA student launch team at the university. Every year, NASA hosts a competition for universities (and high schools seperately) called the NASA Student Launch Challenge Initiative. Every year, each team is required to start from scratch to design and manufacture a model rocket and its payload. Each year the payload has a different goal, which is announced at the beginning of the competition year. For 2024-2025, the goal of the payload was to collect and transmit at least three of eight given data points to a reciever after landing over radio. The payload also had four Lego figures on-board (called STEMnauts). I was responsible for software engineering on the payload team, which consisted of two other people Rebekah Porter and Keneth Lee III. Additionally, our team had to work with a mechanical engineering team, consisting of our project manager Grant Parker, our chief engineer Daniel Hogsed, Joseph Copeland, Jack Kealen, Jackson Maley, Seth Mitchell, Elisa Schmitt, and Jesse DePalmo. We were also supported by Wright Stuff Rocketeers (NAR #703). It was truly an amazing experience to work with all of these people during the project.

The payload consisted of two custom printed circuit boards (PCBs), designed by Keneth Lee III, which used Raspberry Pi Pico 2’s. We were required by NASA to have a backup board to cut off transmissions after five minutes in case the primary board is unable to so that we do not interfere with other teams during competition. Out of the eight possible options, our team decided to attempt to transmit five: the temperature of the landing site, apogee reached, orientation of the on-board STEMnauts after landing, the time of landing, and the battery status. We used two external sensors: a BMP280 for temperature and altitude as well as a MPU6050 for acceleration (to detect orientation). Both boards contained these sensors for redundant flight data. Both boards also contained a MicroSD to store flight data as well as a W25Q64FV flash memory module that was unused. Additionally, we used a DS1307 real-time clock on the primary board to keep time in case of a system restart. The payload transmitted using a Baofeng UV-5R by taking advantage of the Kenwood K1 connector on its side. I was required to get an amatuer radio license to transmit.

Part of my software design responsibility was to develop software for our secondary payload: airbrakes. Part of the goal of the rocket’s design is to hit a specific apogee; we chose 4,100 feet. To aid in this, the team decided to implement airbrakes to slow the rocket down to hit the desired apogee. This had been attempted by Cedarville teams previously, but was never successful. The mechanical system was designed by Seth Mitchell and the controls were developed by Joseph Copeland. My primary job was to port the control algorithm written in Matlab to C++ and ensure it functioned with the mechanical system. The airbrakes system used a modified version of the override PCB to control it. The following image shows the primary, override, and airbrake PCBs.

Because of the similarities between these three systems, I developed a central shared library called the State Framework. The State Framework is responsible for synchronizing state across cores, managing persistent state across restarts, logging data, keeping track of faults, playing status tones, managing flight phases, and communication with the external calibration computer. Though it does a lot, it easily allows for flight data collection without code replication. Furthermore, because it collects so much data, we are able to reconstruct everything that happened in flight, from the data collected, to what sensors were detected as faulty, log messages, and even system restarts. It does this by using a custom binary file format. This file format is designed to be self-containing, meaning all of the data required to read the file is contained in the file itself. This allows us to change the data collected per system, and read data from old versions, without having to worry about matching the reader version. The file format also reuses a lot of the packet-based information that is sent to the calibration computer, allowing reuse of the encoding and decoding software and outputs. Because of the State Framework’s advanced logging methods, we were able to verify that the airbrakes worked during our flight readiness review after on-board cameras failed, allowing us to qualify the airbrakes to be flown for the competition.

The calibration computer uses a program written in Python 3 that runs in the terminal. It is used to set ground pressure, calibrate the accelerometer, and validate the time stored on the real-time clock. Also, it allows reading live sensor readings and log outputs, and provides a command-based system to execute send data and execute code on the Pico, which is incredibly useful for debugging and testing. A picture of the interface can be seen below.

Our rocket flew a total of 10 times. The team learned a lot from each flight. Our competition launch was held on April 28, 2025. Unfortunately there were very high winds that day, and the rocket drifted 2,694 feet, which is outside of the 2,500 feet limit given by NASA. Furthermore, the rocket landed on the other side of a patch of trees, with the antenna facing directly away from the reciever. Therefore, we were unable to recieve any data from the rocket upon landing. However, logs indicated that the payload attempted to successfully transmit the landing site temperature, apogee reached, STEMnaut orientation, and battery status. The only significant error with the data that was sent is the time of landing, which was caused by the payload restarting after landing. This error was observed during the previous full-scale launch, but was never reproduced in testing, nor was it ever observed during simulations. Steps were taken to ensure that some data could be restored after a restart and earlier logs indicate that the payload tried to restore the landing time, and it incorrectly assumed that the restoration attempt had been successful; this led to the incorrect landing time being transmitted.

The apogee the team actually reached was 3,719 feet, which is about 400 feet under the target apogee. This discrepancy is due to a calibration issue that occured with the airbrakes. The team decided to implement recalibration the day before the final launch. Recalibration would occur on the launch-pad, to account for changes in air pressure between manual calibration and when the rocket actually launched (which could be several hours). This system was only tested with simulations, and worked well in theory. In practice, however, there was a faulty measurement by the BMP280 that occured. This error of about 50,000 Pascals of pressure and about 80°C of temperature occured in just one of the forty-five averaged measurements, but was enough to change the calibration so that the airbrakes thought it was higher than it really was. The BMP280 did not catch this change in pressure, as it was slightly below the threshold to be considered faulty. It was unwise to implement something so close to launch, as the performance benefit was in reality negligible. Furthermore, there should have been additional checks to ensure the recalibration was sufficiently close to the original calibration values.

I enjoyed working on this project a lot, and it is definetly one of the top highlights from my time at Cedarville. While my primary responsibility on this team was software development, I also had other responsibilities, including writing detailed technical reports to both NASA and Cedarville, giving presentations to Cedarville University, and teaching elementary through high school students about rocketry at local schools. This project taught me a lot about technical development, embedded development, and problem solving, but also the importance of communication, technical writing, and risk assesment. The code is publicly archived on GitHub here. More media and information can be found on the team’s website, Instagram, and YouTube. Our team’s final video was created by Daniel Hogsed: