Thrust Vector Controlled Rocket

A finless model rocket designed to hold its attitude with active thrust vector control: the solid motor sits in a two-axis gimbal and is steered by a control loop running on the vehicle itself.

Without fins there is no passive aerodynamic stability, so the rocket is only ever as stable as its estimator and its controller. That single constraint drove every decision — structure, actuation, sensing and software.

The project followed an earlier model rocket from 2023, whose flight path was unstable and whose logged data proved of limited use. This vehicle was the answer to both problems: a smaller airframe, a far faster flight computer, and closed-loop guidance in place of passive stability.

Christophe Mayers and I built it as a two-person project, sharing the mechanical, electronic and software work rather than splitting it into separate halves.

The airframe is a 10 cm diameter tube carrying the flight computer and thrust vector assembly in its lower half, and the reaction wheel and recovery system above. All-up mass is approximately 1 kg.

The gimbal is 3D printed and driven by two servos through linkages. Mapping servo angle to gimbal angle was solved twice over: once empirically, by strapping an IMU to the gimbal, commanding known servo angles and curve-fitting the measured response; and once analytically, from the linkage geometry. Having two independent derivations that agreed was the point.

The nose cone was modelled with a chamber whose door is held shut by a servo. At apogee the servo releases the plate and the parachute falls out — a direct fix for the previous rocket, whose parachute had stayed stuck inside the body.

Connecting this many components to a development board on flying hardware invites intermittent faults, so the electronics were consolidated onto a custom PCB designed in EAGLE, fabricated by Eurocircuits, then hand-assembled and tested.

A Teensy 4.1 acts as the main MCU, chosen for its clock speed and onboard SD card interface. It reads a BNO055 IMU for orientation and a BMP390 barometer for altitude, and drives the two TVC servos, the parachute servo, an RGB LED and a buzzer from an 11.1 V pack.

Assembly caught its own errors: a reversed RGB LED, and a voltage converter whose design did not hold up. The converter was dropped in favour of the 5 V rail already provided by the brushless motor’s speed controller.

Control commands depend directly on knowing which way the rocket is pointing. Gyroscopes are smooth in the short term but drift; accelerometers give an absolute gravity reference but are corrupted by every acceleration the vehicle experiences.

A Madgwick filter fuses the two cheaply enough to run in real time on the embedded target. Orientation is carried as a quaternion to avoid gimbal lock: the gyro propagates it, and the accelerometer corrects long-term drift by comparing measured gravity against the direction the current estimate predicts. Because powered ascent is a highly dynamic environment, the accelerometer’s influence is weighted very low.

The flight software is a finite state machine, so behaviour stays deterministic and time-critical control is only ever enabled when it is actually needed.

LAUNCH_PAD_IDLE waits on the pad with sensors live, watching vertical acceleration for liftoff. ASCENT enables thrust vector control and runs two tasks in parallel: the control loop at 100 Hz doing estimation, control law and servo output, and health monitoring plus logging at 25 Hz. DESCENT ejects the parachute and disables flight control. LANDED activates a buzzer-and-LED recovery beacon.

SD card writes introduce non-deterministic latency, which is unacceptable inside a 100 Hz control loop — so high-rate flight data is buffered in the Teensy’s flash during ascent and only flushed to the card during descent, once nothing time-critical is left to do.

During powered ascent the rocket is stabilised by a Linear Quadratic Regulator acting on its rotational dynamics, linearised about the upright flight condition. The state is attitude deviation and angular rate; the controller returns a demanded torque about the centre of mass.

The gain matrix comes from minimising a quadratic cost that trades attitude error against control effort. With a moment of inertia of 0.0857 kg·m² and weights Q = diag(10, 1) and R = 2.5, solving the algebraic Riccati equation gives K = [2.0000, 0.8619].

That demanded torque is converted into a thrust vector deflection using the known thrust magnitude and the moment arm of the gimbal, and the mapping respects real actuator limits — maximum deflection, actuator delay, and the fact that the flight computer only closes the loop 100 times a second.

Before any of this went near a rocket motor it was validated in a nonlinear Simulink environment, built to mirror the structure of the onboard software so that controller parameters and state machine logic could be evaluated under realistic conditions.

The rocket is modelled as a rigid body rotating about its centre of mass under Euler’s equation, with motor thrust as a time-varying external input. Gaussian noise is injected into the attitude and rate signals to emulate inertial sensor imperfections, and disturbance torques stand in for aerodynamic effects such as wind gusts.

Under those disturbances the closed loop drives both attitude deviation and angular rate back toward zero, well damped and without sustained oscillation, with peak deviation and rates staying within what the thrust vector control system can deliver.

The flight software was then driven with sensor data from the simulation while an IMU mounted on top of the TVC mechanism measured what the hardware actually did. The measured TVC angle tracks the simulated command closely across the whole interval, offset by roughly 0.09 s — the servo actuation delay, which the simulation already models explicitly.

Two launch attempts failed, so every result here rests on ground testing. There is no successful controlled flight behind this project: the loop has never been closed around the vehicle in the air, and nothing on this page should be read as saying otherwise.

The first failure was traced to the motor plug at the top of the gimbal: printed at 30% infill, it tore open the moment the motor fired. The fix is unglamorous — 100% infill — and it is the kind of detail that only surfaces once you fire the thing.

The gimbal is printed in PLA, which is structurally weak and sensitive to heat; ABS or nylon would be the better material. The servos are adequate up to around 60 N of motor thrust and would need replacing above that. A third attempt is planned.

A reaction wheel was built as a support system for the gimbal: a 3D printed ring on a central hub, driven by a brushless motor, counter-rotating against any roll the vehicle picks up so that it does not develop a coning motion.

It runs a PID loop on the Y-axis gyro rate, holding the setpoint of not rotating. Getting there meant discovering that the original speed controller would not drive the motor bidirectionally, and replacing it with one that would.

It works, but it was deliberately left out of the launch configuration. Its parameters — mass, motor strength, whether the PID is even necessary — were estimated rather than simulated, and flying it would have clouded the evaluation of the thrust vector control simulation. For this vehicle it stays a prototype, to be designed in from the start next time.