Loading files…
Custom STM32H743 flight computer and GNC software for a roll-rate-stabilised high-power rocket.
This is an engineering project, not a product. The safety case, regulatory compliance, and airworthiness of any vehicle built from this material are the builder's sole responsibility.
The project is designed to:
Control scope. The flight controller closes a loop on roll rate, not roll angle. It damps rate transients and cancels the standing roll moment produced by build asymmetry. It holds no commanded heading and has no outer attitude loop. Roll-angle hold and full three-axis attitude control are planned work and are not implemented.
This repository contains the hardware design, embedded software, simulation models, and analysis tools used during development.
| Parameter | Specification |
|---|---|
| Purpose | Active roll stabilisation for mid- and high-power rockets |
| Flight Computer | STM32H743 ARM Cortex-M7 |
| Control Surfaces | Four independently actuated canards |
| Control System | Proportional roll-rate damper, dynamic-pressure gain scheduled, with a slow bounded trim path for bias rejection |
| Control Scope | Roll rate damping and bias rejection. No attitude loop |
| Interfaces | I²C, UART and 6× PWM outputs |
| Data | On-board logging with optional telemetry |
| Simulation | MATLAB, Simulink, 6DOF modelling and Monte Carlo analysis |
| Architecture | Modular flight computer, sensor board and power distribution board |
| Design Goals | Low mass, modular, reliable and adaptable |
| License | Apache 2.0 |
| Feature | Status |
|---|---|
| Flight Computer Design | Complete |
| Flight Computer Testing | In Progress |
| Flight Software | In Progress |
| Flight Hardware Design | In Progress |
| Flight Hardware Testing | In Progress |
| Simulink Roll Model | Complete |
| Simulink 6DOF Model | Complete |
| MATLAB Monte Carlo Analysis | Complete |
| System Integration | Not Started |
| HITL Testing | Not Started |
| Flight Testing | Not Started |
Hyades-Flight-Computer
│
├── Documentation/
│ └── Images/
├── Firmware/
│ └── STM32IDE/
├── Hardware/
│ ├── 29mm Rocket/
│ ├── Avionics Bay/
│ ├── Canards/
│ ├── Fin Can/
│ └── PCB Designs/
└── Simulation/
├── Buck Regulator SPICE Simulation/
├── Canard Sizing/
├── HSE Clock SPICE Simulation/
└── Matlab Roll Tuning/
The main PCB, containing all the computation and data gathering.
Rev 0.2 render; rev 0.3 layout in progress.
The PDB board, provides power and distributes PWM signals to the servos, as well as providing a clean 3V3 to the sensor board.
0 Ohm Series Termination vs 47 Ohm Series Termination for the 24 MHz HSE Oscillator, unnecessary? Yes, but a good opportunity to learn SPICE Simulations, plus it looks cool. Below the schematic that the simulations were derived from.
The second hardware iteration of the flight computer. The first failed due to many oversights and lack of basic knowledge. On this version, the MCU boots and runs, USB and PDB works completely. An incorrectly wired CS pin has caused a bus fault where the I2C bus thinks its SPI and so fails to communicate. Future redesign to address this and a number of other design/architecture level issues is in progress, enabled by kind sponsorship from JLCPCB. Also seen is the Sheppard PCB design for my research project, which served a dual purpose in allowing me to validate the layout and connections for all the critical components for the next iteration, such as the ICM-42688P IMU and STM32H743 MCU and controlled impedance USB-HS routing for high data rate logging.
After some more testing, I have realised that the supposed ICM-42688-P's are actually QMI8658A IMU, substituted as a fake version of the target gyros (cross referenced WHO_AM_I 0x05, rev 0x7C, address 0x6B), after rewriting some of the code I got them working, allowing for a breakout board/bodge to be avoided. After collecting 2+ hours of data running at 16 g, 2048 dps, 224.2~ Hz ODR over I2C at 400kHz, I computed allan variance and then fitted a white-noise + Gauss-Markov + random-walk model to it (GMWM) with the rate-quantisation component computed separately under PQN model assumptions.
This is beneficial as the state estimator (IEKF) requires a model of the sensors noise to optimally estimate the current pose and to make its covariance trustworthy, which fault detection partly relies on. See Quantisation Research Project for my related work on this topic.
The built airframe, assembled and with the front avionics section separated from the booster.
CAD full assembly, an earlier render with the front section and nose cone missing.
Spinning Rear Fin Can designed to avoid the roll reversal phenomenon where upstream control surfaces tip vortices interact with the downstream fixed fins, causing a difficult to predict moment in the opposite direction.
Front avionics assembly, WIP.
%words
%words
The loop closes on roll rate, along two paths.
Damping is proportional and gain scheduled on dynamic pressure, Kp = c / q_e. The 1/q schedule holds the open-loop crossover constant across the envelope.
Trim is a slow bounded integrator that cancels the standing roll moment Cl_0 from fin cant and build asymmetry. It is kept out of the damper because the deflection that cancels a standing bias, -Cl_0 / Cl_delta, is independent of q and V - one fixed deflection works everywhere, so it can be learned slowly and stay clear of the loop dynamics. Four gates bound it: bandwidth, a dead zone subtracted from the integrator input, a saturation freeze, and a clamp with a rate limit. It accepts an external Cl_0 estimate, so a future MEKF can supply the value directly.
Putting integral action in the damper instead produces a limit cycle against the servo dead zone. That dead zone sits inside the servo's own position loop, so command-side compensation does not reach it; dither on the command does. Flown at 1.5x the modelled dead zone, 125 Hz.
Open items. The trim saturation gate tests the pre-dither command while the travel clamp acts post-dither, so it can miss a saturation event within one dither amplitude of the stop. The dither frequency also needs checking against the servo's maximum frame rate.
%words
%words
400 dispersed runs per design point. Aerodynamic coefficients, vehicle properties, actuator parameters and the disturbance bias are sampled per run. The controller's dynamic-pressure estimate is drawn about the sampled truth rather than the nominal, so scheduling error compounds with aerodynamic dispersion instead of cancelling against it.
| Metric | Definition |
|---|---|
rms_err | RMS of (p - ref) over the steady tail |
bias | mean(p) - ref over the tail |
ripple_pp | max(p) - min(p) over the tail; limit-cycle amplitude |
activity | RMS surface rate; catches stick-slip |
growth | RMS of the last half of the tail over the first half; the stability test |
travel_peak / travel_steady | Travel used over the whole run / over the tail |
Dither amplitude was swept over four campaigns at matched dispersion. Limit-cycle amplitude falls sharply at the flown setting with no rise in surface activity; the cost shows up as a small steady rate bias.
c is set analytically from a 4 Hz crossover target; the numerical work confirms the margins near it survive parameter uncertainty rather than searching for an optimum. Margins come from the open-loop frequency response with the transport delay treated exactly, evaluated over paired (q, V) flight conditions spanning q = 2-40 kPa, with independent +/-30% on Cl_delta and Cl_p, accepted at phase margin >= 35 deg, gain margin >= 6 dB and peak sensitivity <= 2.0 at the worst corner. Constants are read from the parameter file rather than restated here.
A separate grid search over c and the trim parameters scores candidates on settling time, hang-off, limit-cycle amplitude and actuator demand, using the Monte Carlo campaign at each point.
Ti applies only to the legacy PI mode kept for A/B comparison.
%words
%words
%words
No comments yet. Be the first to ask about this board.