Thrust-vector-controlled model rocket

Flight 1 — Motor Failure

The first flight ended almost immediately when the motor failed shortly after ignition. I had pressure-fit the commercial F15 motor into the rocket, and my best explanation afterward was that the force used to install it had damaged or cracked part of the motor's paper casing. Once the motor came up to pressure, combustion gases were able to escape through the damaged casing instead of remaining contained through the nozzle, resulting in a catastrophic failure.

It was obviously not how I wanted the first attempt to go, but it forced me to think much more carefully about how seemingly small mechanical decisions could affect the entire system. For the next version I changed the motor retention design so that the motor no longer relied on a tight friction fit and instead used a proper mechanical retainer.

Post-flight inspection of the motor end after Flight 1.

F15 motor hardware after the first flight.

Flight 2 — Launch Detection Failure

About a month later I returned with a rebuilt and improved rocket. The motor worked correctly this time, but the vehicle immediately began doing backflips instead of stabilizing itself.

After looking through the flight data, I found that the thrust-vector-control system had never actually entered powered-flight mode. My launch-detection threshold was set too high, and the software was only looking at acceleration along the rocket's Z-axis. Because the rocket left the launch rod at a slight angle, not all of the acceleration appeared along that single axis. The total acceleration was high enough to indicate launch, but the value the software was monitoring never crossed the threshold.

The flight computer therefore never enabled active stabilization. The hardware was working, but the software did not realize that the rocket had launched.

Rather than simply lowering the threshold and hoping it worked, I wanted a way to test the new logic before flying again. I went through frames from the launch video and used them to estimate the rocket's acceleration as it left the rod. I then performed a series of backyard tests where I physically threw the rocket while logging sensor data, trying to reproduce roughly the acceleration and duration it would experience during launch.

The goal was to find a launch threshold that existed in a useful middle ground: low enough that the rocket would reliably detect a real launch, but high enough that normal handling or movement on the launch pad would not accidentally trigger powered-flight mode.

I also rewrote the launch detection to use the magnitude of the three-dimensional acceleration vector rather than relying only on one axis. This meant that launch detection no longer depended as heavily on the exact orientation of the rocket.

Flight 2 — vehicle tumbling after an incorrect launch-detection response.

Post-flight gimbal and servo inspection.

Second view of the gimbal and actuator hardware after Flight 2.

Post-flight hardware inspection after the early test flights.

Recovered vehicle hardware during failure analysis.

Flight 3 — Successful Stabilization

The third launch was the first time the complete thrust-vector-control system operated correctly in flight.

The rocket left the rod and flew almost perfectly straight. The IMUs, Kalman-filtered attitude estimate, PID controller, and servo-driven gimbal all worked together as intended, and the rocket actively corrected its orientation during powered flight.

This was a major milestone for the project because it proved that the core control system actually worked outside of simulation and ground testing.

However, the flight exposed another problem.

The recovery system was designed to deploy the parachute near apogee, but the rocket did not reach the altitude I had expected. Because the altitude target was set too high, the normal deployment condition was never reached. I had also included an emergency backup timer in the flight software, but during testing I had intentionally set that timer much longer than it should have been and forgot to change it back before launch.

The result was that the rocket returned to the ground before the backup timer expired. The parachute charge eventually fired, but only after the rocket had already impacted.

Once again, the failure was not caused by a single piece of broken hardware. It came from an assumption I had made about the expected flight and a test setting that had accidentally made its way into the flight configuration.

For the next attempt I created an approximate OpenRocket model of the vehicle and used it to get a much better estimate of the expected altitude. I lowered the altitude threshold used by the recovery logic and changed the backup timer to a value that would actually provide meaningful protection if the primary deployment condition failed.

Flight 3 vehicle — “To Boldly Go…”

Intermediate TVC vehicle iteration.

Flight 3 at liftoff.

Flight 3 climbing under active control.

Flight 3 during powered ascent.

Flight 3 attitude data used to evaluate closed-loop stabilization.

Flight 3 servo commands during thrust-vector control.

Flight 4 — Final Iteration

By the fourth flight, almost every major system in the rocket had been changed or validated through one of the previous attempts.

The motor mounting had been redesigned after the first failure. Launch detection had been rewritten around three-dimensional acceleration after the second. The thrust-vector-control system had been proven in flight during the third, and the recovery logic had been updated using more realistic altitude estimates and a properly configured backup timer.

What made the final version work was not one major breakthrough. It was the accumulation of dozens of small lessons from the previous rockets, test-stand runs, simulations, software changes, and failed launches.

The finished vehicle used an onboard RP2040-based flight computer, an MPU6050 and LSM6DSOX for inertial sensing, a BMP280 for altitude measurements, Kalman filtering for sensor fusion, and closed-loop PID control. The controller commanded two micro servos driving a custom PETG gimbal capable of approximately 12° of movement in each axis. The flight computer also controlled its own electronic pyrotechnic recovery system and contained multiple software failsafes intended to protect the vehicle if the normal flight sequence did not occur as expected.

Flight 4 attitude data from the final vehicle.

Flight 4 gimbal servo commands.

Flight 4 barometric altitude used to verify the recovery sequence.