12/24/2025 2:28 AM - the technicalities of the project

So basically the crux of the project is to make a real size rocket control system that can support a rocket with a controllable thrust vector. The flight computer reads data from the IMU, altimeters, magnetometer, temperature sensor, and GPS. It processes this data using complementary and Kalman filters to estimate the rocket’s orientation, altitude, and velocity. During ascent, PID controllers use this state information to adjust the ST3215 servos on the fins, keeping the rocket stable. After reaching apogee, the system deploys the parachute or parafoil automatically and uses N20 gearmotors to adjust line lengths, steering the rocket toward a target landing using GPS data. All critical actions are autonomous, powered by a 7.4 V Li‑ion battery with regulated voltage rails, and logged to SPI flash. Telemetry is transmitted via LoRa for monitoring only. Safety features like watchdog timers, sensor redundancy, and time‑based backups ensure the system functions even if parts fail.

the heart of the rocket

STMsmthh NUCLEO‑H753ZI (STM32H7 MCU)

• Runs PID controllers, Kalman filters, sensor fusion, state machine, safety logic
• Programmed in C/C++ (ofc)

sensors

• BMI088 – 3‑axis accelerometer & gyro for angular rates & linear acceleration
• LIS3MDL – Magnetometer for orientation reference during non‑powered flight
• BMP388 – Pressure sensor for altitude reference
• MS5611‑01BA03 – High‑precision altimeter for apogee detection
• TMP102 – Thermal sensor for temperature monitoring
• NEO‑M8N – GPS module for descent navigation and target landing

actuation (hence rocket science)

ascent fins (the do or die factor):

• ST3215 servos with encoder
• Controlled via MAX485 serial interface
• PID control loops adjust fins to reduce rotation

aescent parachute / parafoil (you know what this is for):

• N20 coreless DC gearmotors with encoders
• DRV8833 motor driver
• Adjust line lengths to steer during descent based on GPS

data & Telemetry (to talk with the rock)

• SPI flash – Logs sensor readings, control outputs, and flight events
• LoRa SX1276 + 433 MHz antenna – Telemetry to ground (monitoring only, not control)

power system (the energy sourcee)

• 2S Li‑ion 18650 protected battery (7.4 V)
• LM2596 buck converter and REES52 RC BEC 5V 5A for regulated logic and actuator voltage
• Sufficient capacity for entire flight duration

safety (cause thats important kids)

• Autonomous flight logic; critical actions do not rely on radio
• Watchdog timers, time‑based backups, and sensor consistency checks
• Servos and motors fail to safe positions if sensors fail
• Battery and regulators sized for stable operation under load

controll (the everything everywhere part)

• Complementary filter for orientation estimation
• 1D Kalman filter for altitude and vertical velocity
• PID loops for fin stabilization
• GPS‑based control for descent steering
• Flight state machine: launch > boost > coast > apogee > descent > landing

12/24/2025 2:38 AM - Modelling the rocket first to get a hold of data

As yea you can see there was a lot of testing and predicting done until the components get delivered to get a hold of the data you are dealing with.
Any further work requires the components to be present.

12/24/2025 8:04 PM - explaining the overall controlling

so talking about how everything is going to work, heres my monologue and the upcoming ones.

1 . the (glorious) purpose of the control system

the purpose of this control system is to autonomously sense, estimate, decide, and actuate throughout the entire flight of a small experimental rocket with an apogee of approximately 1 km. the system must operate without external commands, must tolerate sensor noise, vibration, acceleration, and power disturbances, and must guarantee recovery even in the presence of partial failures.

the system is divided into functional layers, not just hardware blocks. these layers are:

1. physical sensing layer
2. state estimation layer
3. decision and control layer
4. actuation layer
5. power and survivability layer
6. data logging and telemetry layer

each layer depends on the one below it and provides inputs to the one above it. no layer directly bypasses another. this separation is critical for correctness, stability, and fault containment.

2 . central controller and its role

at the center of the entire system is the stm32h753 microcontroller, implemented using the nucleo-h753zi board during development. this microcontroller is not just a “processor”; it is the timing authority, synchronization point, and safety supervisor for the entire system.

the stm32h753 performs the following roles simultaneously:

• schedules all tasks using hardware timers
• reads all sensors at deterministic rates
• executes all estimation mathematics
• computes all control outputs
• drives all actuators
• monitors power health
• logs and transmits data
• enforces safety and fallback logic

there is no secondary flight computer. reliability is achieved through simplicity, determinism, and redundancy in logic, not duplication of processors.

3 . time-based architecture

the system is time-driven, not event-driven.

every important operation runs at a fixed frequency:

task	typical rate
imu sampling	1000 hz
attitude estimation	500–1000 hz
rate pid control	400–800 hz
barometric sampling	50–100 hz
vertical kalman filter	50–100 hz
gps updates	5–10 hz
descent guidance	5–10 hz
telemetry	2–10 hz
logging	50–200 hz

hardware timers trigger interrupts or rtos tasks. no task blocks another. no task waits for i/o. this guarantees that control loops remain stable even if non-critical subsystems (like telemetry) slow down or fail.

4 . flight state machine

the entire system is governed by a finite state machine. every control law and actuator output is conditional on the current state.

core states

1.idle
system powered, sensors initializing, no actuation allowed.

2.armed
sensors calibrated, recovery system armed, waiting for launch detection.

3.boost
rocket under thrust. fin stabilization active. highest vibration and acceleration.

4.coast
motor burnout detected. no thrust. stabilization continues with reduced authority.

5.apogee
vertical velocity near zero. recovery initiation.

6.descent_controlled
parachute deployed. line actuation and gps guidance active.

7.landed
motion near zero. actuators disabled. logging continues.

each state strictly defines:

• which sensors are trusted
• which control loops are active
• which actuators are allowed to move
• which failures trigger immediate transitions

this prevents inappropriate actions such as fin movement during descent or parachute steering during boost.

5 . sensor layer: raw physical measurements

the sensor layer converts physical phenomena into electrical signals.

imu (bmi088)

• measures angular velocity ω = [ωx, ωy, ωz]
• measures linear acceleration a = [ax, ay, az]

during boost, accelerometer readings are dominated by thrust and vibration, while gyroscope readings remain reliable. this asymmetry is explicitly accounted for later in estimation.

pressure sensors (ms5611 + bmp388)

• measure static pressure p
• pressure is converted to altitude using a standard atmospheric model:

the ms5611 is used as the primary altitude source due to lower noise. the bmp388 provides redundancy and cross-checking.

magnetometer (lis3mdl)

• measures earth magnetic field vector b
• used only when acceleration is low
• never trusted during boost

gps (neo-m8n)

• provides position (lat, lon, alt)
• used only during descent guidance
• never part of stabilization loops

6 . state estimation layer

the rocket never directly “knows” its orientation or velocity. these must be estimated.

6.1 attitude estimation

orientation is estimated using a complementary filter.

gyroscope integration:

accelerometer-based gravity reference:

combined estimate:

where:

• α ≈ 0.98 during low acceleration
• α ≈ 1.0 during boost (accelerometer ignored)

this produces stable roll and pitch estimates without requiring a full nonlinear ekf.

6.2 vertical motion estimation (kalman filter)

the vertical state vector is:

state propagation:

measurement update:

this allows accurate estimation of vertical velocity even when pressure noise is high. apogee detection becomes a mathematically robust zero-crossing of estimated velocity, not a noisy altitude peak.

7 . control layer

7.1 ascent stabilization control

the goal during ascent is rate damping, not angle targeting.

desired angular rate:

error:

pid law:

the output u maps directly to fin deflection angles. this minimizes rotational energy and prevents divergence.

the controller is intentionally conservative to avoid excitation of structural modes.

7.2 descent guidance control

during descent, control switches from rotational dynamics to horizontal trajectory correction.

gps provides position error:

heading correction is computed, and line lengths are adjusted asymmetrically. this is effectively a low-bandwidth guidance loop, not a fast control loop.

motor commands are rate-limited and position-bounded to avoid fabric overload.

8 . actuation layer integration

• st3215 servos actuate fins during ascent only
• n20 motors + drv8833 actuate parachute lines during descent only
• mutual exclusion is enforced in software

encoders close the loop locally, allowing precise mechanical control independent of motor nonlinearity.

9 . power and fault containment

power is regulated into separate rails:

• logic
• actuation
• communication

voltage is continuously monitored. brown-out conditions immediately disable actuators and trigger recovery logic.

watchdog timers reset the system if timing guarantees are violated.

12/24/2025 8:09 PM - how to not hurt the feelings of the system

1 . role of the sensor subsystem in this project

the sensor subsystem exists to convert real physical quantities, motion, pressure, temperature, magnetic field, and position, into digital data that can be processed by the flight computer. the sensors themselves do not provide usable flight information. they provide noisy, biased, delayed, and sometimes misleading measurements. the role of the sensor subsystem in this project is not accuracy in isolation, but observability of the rocket’s state under extreme conditions.

this project intentionally uses multiple sensors that measure related but different physical quantities. this allows the system to remain functional even when one sensor becomes unreliable due to vibration, acceleration, thermal drift, or saturation. every sensor is used with a clear understanding of its limitations, bandwidth, noise characteristics, and failure modes.

2 . inertial measurement unit: bmi088

2.1 what the bmi088 measures

the bmi088 consists of two separate sensing elements:

1. a gyroscope, which measures angular velocity
2. an accelerometer, which measures specific force

the gyroscope outputs angular rate values:

in units of degrees per second or radians per second.

the accelerometer outputs specific force:

which includes gravity, thrust acceleration, aerodynamic forces, and vibration.

importantly, the accelerometer does not measure velocity or position, and the gyroscope does not measure orientation directly. both sensors only provide derivatives of the quantities we actually want.

2.2 why the bmi088 is chosen for this project

the bmi088 is chosen because:

• it has low gyro noise density, which is critical for rate-based control
• the gyro and accelerometer are on separate dies, reducing mechanical and thermal coupling
• it tolerates high vibration better than hobby-grade imus
• it supports spi, allowing deterministic high-speed reads

in a rocket environment, vibration and acoustic noise are severe during boost. the bmi088 maintains usable gyro data under these conditions, which is essential because angular rate control depends entirely on gyro reliability.

2.3 gyroscope behavior during flight

the gyroscope is the most trusted sensor during powered ascent.

the angular rate measurement follows:

where:

• b is bias (slowly varying)
• n is noise (high frequency)

bias drift is slow relative to the duration of ascent. this means that over a few seconds, gyro integration remains accurate enough for stabilization. noise is handled by filtering and by the fact that pid control reacts to average behavior, not instantaneous spikes.

during boost, gyroscope data is sampled at high rate (≈1 khz) to ensure control loops remain stable.

2.4 accelerometer behavior and its limitations

the accelerometer measures specific force, not gravity alone. during powered ascent, this means:

as a result:

• accelerometer data is not reliable for orientation during boost
• accelerometer magnitude can exceed ±10 g or more
• high-frequency vibration introduces additional noise

in this project, accelerometer data is used for vertical acceleration estimation and used cautiously for attitude correction only when acceleration magnitude is near 1 g.

3 . pressure-based altitude sensors

3.1 ms5611-01ba03 (primary altimeter)

the ms5611 measures static atmospheric pressure with very high resolution. pressure is converted into altitude using a standard atmospheric model. the ms5611 is chosen because it has very low short-term noise and allows accurate detection of altitude trends.

in this project, the ms5611 is used as the primary source for altitude estimation.

3.2 bmp388 (secondary pressure sensor)

the bmp388 serves as a secondary pressure sensor. its role is not precision, but cross-checking. if the ms5611 produces readings that are inconsistent with expected trends, the bmp388 can be used to validate or reject the data.

3.3 pressure measurement errors in rockets

pressure sensors are affected by:

• dynamic pressure due to airflow
• temperature changes
• sensor port orientation
• venting delays

to mitigate these effects, pressure sensors are sampled at moderate rates and apogee detection relies on velocity trends, not absolute altitude.

4 . magnetometer: lis3mdl

the lis3mdl measures the earth’s magnetic field vector:

in this project, the magnetometer is:

• not used during boost
• not trusted near motors or power electronics
• used mainly during coast and descent

its role is to provide a long-term heading reference to correct slow drift in orientation estimates.

5 . temperature sensor: tmp102

the tmp102 measures temperature near the avionics board. temperature affects:

• gyroscope bias
• accelerometer scale factor
• battery voltage behavior
• pressure sensor readings

by logging temperature, the system can apply compensation curves or diagnose post-flight anomalies.

6 . gps: neo-m8n

the gps provides latitude, longitude, altitude, and ground speed.

gps updates are slow compared to inertial sensors and have latency. because of this, gps is never used for stabilization or ascent control.

in this project, gps is used exclusively during descent to:

• estimate horizontal position
• compute distance and bearing to a target landing point
• guide parachute steering corrections

7 . sensor synchronization and timing

all sensor readings are time-stamped using the stm32’s internal timers. this ensures that sensor fusion algorithms operate on data that corresponds to the same time window. unsynchronized data can cause estimation instability.

the system explicitly accounts for:

• sensor sampling delays
• communication latency
• measurement update timing

8 . sensor failure modes and detection

each sensor is monitored for stuck values, out-of-range readings, sudden discontinuities, and communication failures.

when a fault is detected:

• the sensor is flagged as unreliable
• its data is excluded from estimation
• backup logic is enabled if available

9 . how sensors feed the rest of the system

sensor outputs are the raw inputs to the estimation layer. they are never fed directly into control loops. all sensor data must pass through filtering, validation, and estimation before being used for any control decision.

this separation ensures that noise, spikes, or transient failures do not propagate directly into actuator commands.

10. summary of sensor roles in this project

• bmi088 gyro: primary source for rotational control
• bmi088 accelerometer: vertical acceleration and gravity reference when valid
• ms5611: primary altitude and apogee detection
• bmp388: redundancy and validation
• lis3mdl: long-term heading reference
• tmp102: thermal monitoring and compensation
• neo-m8n gps: descent navigation only

12/24/2025 9 PM - how to avoid a million catastrophes AKA rocket science

1. the curx of the control system

the purpose of the control system in this project is very specific: keep the rocket stable and pointed along its desired direction during powered ascent, despite disturbances like wind, motor misalignment, thrust oscillations, and manufacturing imperfections. this is not guidance (choosing where to go). this is attitude stabilization (not tumbling like a thrown screwdriver).

in this rocket, stabilization is achieved using movable fins, controlled by servos, driven by commands generated from PID control loops, which operate on state estimates produced by the sensor fusion system discussed earlier.

everything here runs on the stm32h753, in real time, deterministically.

2. what exactly are we controlling

let’s define the problem clearly. the rocket has three rotational axes:

• roll ($\phi$) – rotation around the long axis
• pitch ($\theta$) – rotation up/down
• yaw ($\psi$) – rotation left/right

for a typical fin-stabilized rocket:

• pitch and yaw must be actively controlled
• roll is usually left uncontrolled or damped passively, unless roll coupling becomes severe

so in this project:

• we actively control angular rates and angles in pitch and yaw
• control happens only during powered ascent
• once motor burnout occurs, control authority raPIDly drops and the system transitions to recovery logic

3 . why angular rate control comes first

a common beginner mistake is trying to directly control angle ($\theta, \psi$). that fails fast. rockets respond much better when you control:

• angular velocity ($\omega$), not angle
• because fins generate torque proportional to airflow, not position

the imu (BMI088) gives us gyroscope measurements:

these are fast, clean, and perfect for feedback control. so the inner control loop is: “make angular rate = 0”. that means:

• no rotation
• rocket flies straight along its velocity vector

4 . the control architecture (nested loops)

this system uses a two-layer control structure:

inner loop: angular rate PID

• input: measured angular rate from gyroscope
• target: zero angular rate
• output: fin deflection angle

outer loop (optional, light)

• input: estimated attitude angle
• target: desired attitude (usually zero deviation)
• output: angular rate command to inner loop

in practice for amateur systems, the inner loop is mandatory, while the outer loop is optional. many rockets fly perfectly fine with rate-only control. this project prioritizes robustness over complexity, so the core loop is angular-rate control.

5 . the PID controller

The PID equation in continuous time is:

Where:

• e(t) =
• u(t) = fin deflection command

In discrete time (what the STM actually runs):

5.1 what each PID term does in this rocket

• proportional term (p): reacts immediately to rotation. if the rocket starts rotating right, fins push left. too low sluggish response; too high oscillations, fin chatter, instability. this term does most of the work.
• integral term (i): corrects long-term bias, such as motor misalignment or asymmetric fin mounting. however, integral windup can destroy stability, so in this project, the integral gain is very small, clamped, or disabled during early ascent.
• derivative term (d): predicts future error and acts like rotational damping. because gyroscopes already measure rate, the d-term is effectively rate damping. it reduces overshoot and is extremely important for high-thrust vehicles.

6 . mapping control output to fin motion

the PID controller outputs a number that represents desired aerodynamic torque, but servos don’t understand torque. so we do this mapping:

1. PID output desired fin angle
2. fin angle servo pwm command
3. servo moves fin airflow over fin generates force torque is generated

mathematically, torque is , where lift force depends on:

this means control authority increases with velocity squared. early ascent = weak control; near burnout = peak authority. the software limits fin deflection based on estimated velocity to avoid overcontrol.

7 . real-time constraints on the stm32h753

this control loop runs at:

• 500–1000 hz for gyros
• PID update at 250–500 hz

the stm32h753 has more than enough compute; the fpu handles all math with deterministic timing via hardware timers. all steps (read imu, update estimate, compute PID, saturate, send pwm) happen within <1 ms, repeatedly, for the entire burn.

8 . actuator limits and saturation (critical detail)

servos have physical limits (max angle, speed, torque). after PID calculation, the output is clamped, the rate of change is limited, and sudden jumps are prevented. without this, you risk PID instability, servo damage, or structural failure.

9 . what happens if something goes wrong?

control logic includes hard safety rules:

• if angular rate exceeds safe limit fins neutral
• if imu data invalid fins neutral
• if power dips fins neutral
• if watchdog trips fins neutral

a neutral fin configuration is passively stable. fail-safe behavior is designed into control, not added later.

. how this fits with the rest of the system

this control system consumes state estimates from sensor fusion, outputs commands to fin actuators, and is active only during ascent. it hands over to recovery logic after burnout. it is independent, testable, and simulatable, which is exactly how real flight systems are built.

12/24/2025 11:16 PM - power management so we dont explode mid air

In this project, power is not “a battery plus a regulator.” it is a distributed, noisy, high-impulse electrical environment where motors, servos, radios, and sensors all fight for current at different times. your job is to make sure the flight computer experiences none of that drama.

let’s define the power consumers first, because power design always starts from loads, not sources.

The system has three distinct electrical load classes:

1. high-current, noisy loads

• ST3215 fin servos
• N20 dc gear motors for parachute lines these draw large transient currents and inject noise back into the rails.

1. moderate-current rf and peripherals

• lora sx1276
• gps neo-m8n these are sensitive to voltage dips but also generate rf noise.

1. low-current, high-sensitivity logic and sensors

• stm32h753
• imu, baro, magnetometer, flash these must see clean, stable voltage or your math becomes fiction.

you do not power all of these from one rail and pray. you separate them intentionally.

battery choice and why 2s is the correct call

you selected a 2s li-ion (7.4 v nominal) pack using protected 18650 cells. this is the correct decision for three reasons.

first, voltage headroom.
servos and motors need power even under load. a 1s system (3–4.2 v) would force boost converters everywhere, which are noisy and inefficient. a 2s pack gives you enough voltage to step down cleanly.

second, current capability.
18650 cells can comfortably supply several amps for short bursts. servos fighting airflow and motors pulling lines both cause current spikes. you want those spikes handled by chemistry, not converters.

third, simplicity and reliability.
a 2s system with buck regulators is far more predictable than stacked boost stages.

the battery does not need large capacity. flight time is minutes at most. what matters is instantaneous current delivery, not mah bragging rights.

rail separation: one battery, multiple worlds

from the battery, power is split into three regulated domains.

1. actuator rail (5–6 v, high current)

• powered by the rc ubec (5 v, 5 a)
• feeds fin servos and dc motor drivers
• designed to absorb current spikes

1. logic rail (5 v clean)

• generated via lm2596 buck
• feeds mcu input, sensors, flash
• isolated from actuator noise

1. 3.3 v rail (ultra-clean)

• generated by onboard ldos from 5 v
• feeds imu, baro, magnetometer, spi flash

this separation is not optional. when a servo stalls briefly at mach 0.8, you want the ubec to suffer — not your stm32.

why ubecs exist (and why you should use one)

rc ubecs are designed for exactly this problem: servos doing stupid things electrically.

they handle:

• high transient currents
• back emf
• inductive load switching
• brownout recovery

a general-purpose buck converter can provide average current. a ubec survives chaos. that’s why it feeds actuators exclusively.

grounds are tied together at a single point, close to the battery return. this prevents ground loops, which can corrupt sensor readings and spi communication.

decoupling and bulk capacitance (the unsung heroes)

every regulator output is useless without capacitors.

near each servo rail:

• large electrolytic capacitors (hundreds of µf)
• these absorb instantaneous current spikes

near logic rails:

• ceramic capacitors (0.1 µf, 1 µf)
• these suppress high-frequency noise

near the stm32:

• multiple decoupling capacitors close to vdd pins
• because the mcu itself draws sharp current edges when executing code

this is not “good practice.” this is survival engineering.

brownouts: how rockets quietly die

a brownout is when voltage dips just low enough to reset logic but not low enough to look dramatic.

typical causes:

• servo stalls
• motor startup
• radio transmit burst
• poor wiring resistance

effects:

• mcu resets
• state is lost
• parachute logic fails
• rocket becomes ballistic

to counter this, the system uses:

• hardware brown-out detection in the stm32
• software state persistence
• watchdog timers
• conservative power margins

the goal is not to avoid all brownouts. the goal is to recover deterministically if one occurs.

power budget reality check

let’s be blunt: your battery is massively sufficient.

peak currents:

• servos: a few amps total, brief
• motors: hundreds of ma each
• mcu + sensors: tens of ma
• radio bursts: ~100 ma

even worst-case simultaneous load is well within what a 2s 18650 pack can deliver for seconds. the flight duration is short. thermal limits are irrelevant.

what matters is voltage stability, not energy capacity.

power sequencing and startup behavior

when power is applied:

1. battery voltage rises
2. buck converters stabilize
3. mcu boots
4. sensors initialize
5. actuators remain disabled until software enables them

servos are not allowed to move on boot. motors are not allowed to spin on boot. the system starts in a safe inert state.

only after:

• sensors are validated
• state estimation is stable
• flight mode is confirmed

…does actuation get enabled.

this prevents “tabletop launches” and accidental line pulls.

emi, noise, and why spi was the right choice

motors and radios inject noise. spi is more robust than i²c at high speeds and in noisy environments. short traces, proper termination, and clean grounds keep data intact.

gps and lora are physically separated from imu and baro. rf noise and vibration-sensitive sensors do not mix.

power design and layout decisions are inseparable. you cannot “fix noise in software.”

12/24/2025 11:37 PM - descent control and recovery

this part of the system looks calm. it is not. powered ascent lasts seconds. descent lasts minutes. that gives errors time to grow, wind time to dominate, and small mistakes time to compound. the recovery system must therefore be slow, stable, redundant, and conservative.

this project does not use a passive parachute. it uses a controlled canopy whose line lengths are actively adjusted to influence horizontal motion during descent. the goal is not aggressive steering. the goal is biasing drift so the rocket lands near a predefined coordinate.

the recovery phase begins when the system determines that the rocket has reached apogee. this detection is based on redundant signals: vertical velocity crossing zero (from the altitude kalman filter), barometric altitude trend reversal, and time since launch. any one of these can trigger deployment, but at least one must. this is intentional redundancy. rockets do not get second chances.

once apogee is declared, the flight computer disables fin control permanently and arms the recovery actuators. a deployment mechanism releases the parachute or parafoil. from this moment onward, the vehicle is no longer a rigid body dominated by inertia; it is a drag-dominated system suspended under a flexible surface.

why line control works at all

a parachute or parafoil descends by converting vertical gravitational force into aerodynamic drag. if all suspension lines are equal length, the system descends mostly vertically, with drift determined by wind.

if one side’s lines are shortened slightly, that side of the canopy generates more drag. the result is a horizontal force component. the system does not “turn” like an airplane. it leans, and gravity plus drag do the rest.

the control authority is weak, delayed, and heavily damped. this is not fast feedback control. it is bias correction over time.

that distinction matters.

actuators: slow, precise, and power-efficient

each control line is attached to an n20 dc gearmotor with an encoder, driven by a drv8833 dual h-bridge. these motors:

• move slowly
• provide enough torque to pull under load
• allow precise measurement of line displacement

the encoder converts motor rotation into line length change. this lets the system know exactly how much correction has been applied, even if the canopy reacts slowly.

steppers are avoided because:

• they waste power holding position
• they lose steps under load
• they are heavier for the same usable torque

dc motors with encoders are quieter, more forgiving, and easier to recover from stalls.

control variables during descent

the system tracks three primary quantities:

• current gps position (latitude, longitude)
• target landing position
• line lengths (or relative differences)

altitude is still tracked, but now it is used to:

• scale aggressiveness of control
• disable steering near the ground

wind dominates near the surface. steering late in descent often makes things worse, not better.

guidance logic: simple on purpose

this project does not run full glide path optimization or wind estimation. that is overkill and brittle.

instead, it computes:

• horizontal position error vector
• desired horizontal correction direction

this vector is projected into the parachute’s control axes. based on that projection, the system slightly shortens or lengthens specific lines.

mathematically, this is a proportional controller in position space:

where:

• ΔL is change in line length
• k_g is a small gain
• updates happen slowly (seconds, not milliseconds)

there is no derivative term. no integral accumulation. the environment is too noisy and delayed for that to help.

timing and bandwidth: why slowness is stability

gps updates at ~5–10 hz. canopy response happens over seconds. wind gusts come and go. if you try to correct rapidly, you inject oscillations.

so the control loop:

• runs at low frequency
• applies small corrections
• waits
• observes
• adjusts again

this is closer to sailing than flying.

safety logic during descent

several safety constraints override guidance:

• maximum line tension limits
• maximum asymmetry limits
• minimum altitude cutoff for steering
• timeout-based full neutralization

if anything looks abnormal, the system returns all lines toward equal length and becomes a passive parachute again. passive descent is safe. overactive control is not.

the system does not fight wind aggressively. it nudges, then accepts reality.

power and thermal considerations

motors are duty-cycled. they do not run continuously. this conserves power and prevents heating. the battery easily supports descent operations, even in cold air.

the tmp102 thermal sensor helps validate that electronics remain within safe limits. thermal runaway is unlikely, but data is logged for analysis.

telemetry during recovery

lora telemetry remains active throughout descent. position, altitude, and system state are transmitted to the ground station. this is not for control; it is for awareness and recovery assistance.

the rocket does not depend on radio commands to land safely. communication is advisory, not critical.

12/24/2025 11:46 PM - socializing with people on the ground

1 . telemetry & communication: knowing what’s happening without touching anything

this article is about visibility, not control. telemetry exists so you can observe the rocket, not steer it. the moment your rocket depends on radio commands to survive, it has already failed as an autonomous system. in this project, telemetry is deliberately non-critical. it can fail completely and the rocket must still fly, recover, and land safely.

that design decision shapes everything that follows.

telemetry in this system is built around LoRa (SX1276) operating in the 433 mhz band, paired with a simple ground station receiver. the choice of lora is driven by physics: low data rate, long range, strong penetration, and graceful degradation are exactly what you want when the vehicle is moving fast, rotating, and surrounded by electrical noise.

2 . what telemetry is allowed to do (and what it is not)

telemetry is allowed to:

• report system health, position, and altitude
• report current flight mode
• help locate the rocket after landing

telemetry is not allowed to:

• arm actuators or deploy recovery
• modify control parameters
• override safety logic

this hard separation prevents human error, rf dropouts, or interference from becoming catastrophic.

3 . data flow through the system

inside the stm32, telemetry is treated as a consumer of data, not a driver of behavior. sensors feed the state estimator, which feeds control and recovery logic. telemetry reads snapshots of that state and transmits them outward.

this one-way dependency is intentional. telemetry never blocks control loops. if the radio is busy, slow, or dead, the rest of the system does not care.

4 . what data is actually transmitted

the telemetry packet is compact and intentional. lora works best when packets are small and infrequent. typical fields include:

• timestamp
• flight mode (idle, ascent, descent, landed)
• estimated altitude and vertical velocity
• gps latitude and longitude
• battery voltage and error flags

transmission rate is dynamic: faster during ascent for visibility, slower during descent, and even slower after landing to conserve power.

5 . timing, latency, and reality

lora has high latency compared to wi-fi or ble. that’s fine. telemetry is not real-time control. if you receive altitude data 200 ms late, nothing breaks. what matters is that packets arrive intact from far away. this is why lora uses spreading factors and forward error correction; when signal quality drops, the data rate drops gracefully instead of disappearing.

6 . antenna placement and rf hygiene

the antenna is part of the system. the 433 mhz antenna is placed away from motors and regulators and has a solid ground reference. rf noise from buck converters and motors is real; poor layout can reduce range by orders of magnitude.

additionally, the magnetometer is kept away from the antenna and power traces. rf and magnetic sensing do not coexist peacefully.

7 . ground station philosophy

the ground station does not command; it listens. its job is to display live telemetry, log received packets, and assist recovery teams by estimating the landing location. if the ground station crashes, the rocket remains unaffected. rockets are autonomous machines, not remote-controlled toys.

8 . telemetry failure modes and behavior

telemetry is fire-and-forget.

• if telemetry drops out: no retries block execution and no errors propagate into control.
• if telemetry resumes: packets resume naturally with no state resynchronization required.

the rocket does not wait to be heard; it simply executes its mission.

12/25/2025 12:04 AM - stopping system from destroying itself (it really wants to)

ngl this is the most important article in the entire project.

a rocket does not fail because one thing breaks.
it fails because something breaks and the system doesn’t know how to react.

the fail-safe design is not about preventing failures. it is about containing damage, preserving recovery, and guaranteeing a safe outcome even with partial loss of function. and most overlook how critical this step is.

the core principle

every subsystem in this rocket must obey one rule:

if i disappear, the rocket must still recover safely.

that rule drives every architectural decision.

control can fail.
telemetry can fail.
sensors can lie.
power can dip.

recovery must still happen.

classes of failure

failures are not all equal. this system explicitly categorizes them.

1. recoverable transient faults

• brief sensor glitches
• rf dropouts
• momentary voltage dips

1. persistent subsystem faults

• one sensor dead
• one actuator unresponsive
• gps lost

1. catastrophic but bounded faults

• mcu reset
• control loop instability
• partial power rail failure

each class has a different response. treating them the same is how rockets die.

sensor redundancy without duplication

you do not duplicate sensors blindly. you cross-check physics.

altitude comes from:

• ms5611 precision altimeter
• bmp388 barometric sensor
• integrated vertical acceleration (short term)

if one disagrees violently with the others, it is ignored.

orientation comes from:

• gyroscopes (short-term truth)
• accelerometers (long-term reference)
• magnetometer (low-priority correction)

no single sensor is trusted absolutely. consistency matters more than precision.

apogee detection is redundant by design

apogee triggers recovery. missing it is fatal. triggering early is usually survivable.

so apogee is declared if any of the following occurs:

• vertical velocity estimate crosses zero
• barometric altitude trend reverses
• time since launch exceeds a hard limit

these are independent mechanisms. one failure does not block recovery.

actuator fail-safe states

every actuator has a defined safe position.

• fins goes to neutral
• line motors goes to equalized lengths
• deployment mechanism gets released

if control logic dies, actuators default to passive, stable configurations.

this is enforced both:

• in software (explicit commands)
• in hardware (spring bias, power-off behavior)

fail-safe means what happens when nothing is happening.

watchdogs: trust nothing, especially yourself (lol)

the stm32 hardware watchdog is always active.

if the main loop:

• locks up
• runs too slow
• enters undefined state

the mcu resets.

on reset:

• system boots into safe mode
• actuators are disabled
• recovery logic is re-armed
• previous state is reconstructed from persistent flags

a reset is not a failure. an unrecoverable reset is.

brownout survival strategy

brownouts are assumed to happen.

to survive them:

• brownout detection is enabled
• critical state is stored redundantly
• recovery logic is time-based as well as sensor-based

if the system reboots mid-flight and cannot trust sensors immediately, it will still deploy recovery after a timeout.

the rocket is allowed to forget everything except that it must deploy.

telemetry is never a dependency

loss of radio:

• does not block any action
• does not delay recovery
• does not change control behavior

this is enforced architecturally. telemetry runs at lowest priority and is allowed to fail silently.

“last-resort” recovery logic

there is always a final backstop.

if:

• sensors are invalid
• state estimation fails
• control logic is corrupted

then after a fixed time since launch, recovery is forced.

this logic does not ask questions. it does not optimize. it deploys.

the goal is not elegance. it is hardware retrieval.

logging for post-mortem, not for safety

spi flash logs everything:

• sensor data
• control outputs
• fault flags
• state transitions

this does not help during flight. it helps after.

fail-safe design is not complete unless you can explain failures later and fix them next time.

12/25/2025 12:42 AM - the final piece - software architecture

the final piece and then there shall be peace. (and fire)

this is the final structural layer. everything you’ve learned so far only works if the software is organized so that each part runs when it should, stops when it must, and never interferes with something more important. rockets don’t fail because math is wrong; they fail because software states overlap, timing assumptions break, or one task blocks another.
this is also the key component of rocketry.

in this article I monolouge how the entire system is stitched together into one coherent, deterministic program on the stm32h753. (which is a crazy beast)

the software is built around a finite state machine (fsm). this is not an implementation detail; it is the backbone of safety. at any moment, the system is in exactly one flight state, and that state strictly defines which subsystems are allowed to run.

the primary flight states are:

• idle / safe – powered, on the pad
• ascent – motor burning, fins active
• coast / apogee detect – motor out, waiting for peak
• descent – recovery deployed, line control active
• landed – system inert

there is no “partially ascent, partially descent” mode. ambiguity is eliminated by design.

why state machines beat “if statements everywhere”

without an fsm, logic slowly turns into:

• if (altitude > x) do this
• if (time > y) do that
• if (sensor_valid) maybe do something else duh

soo as you can see eventually, conditions WILL overlap. whether you like it or not. two subsystems activate simultaneously. actuators fight. recovery triggers twice. or not at all.

with an fsm:

• entry conditions are explicit
• exit conditions are explicit
• transitions are logged
• illegal transitions are impossible

every subsystem checks the current state before acting. if the state does not permit it, the subsystem does nothing.

task structure and timing

the stm32 runs multiple logical tasks, but not in an uncontrolled way. each task has a fixed responsibility and priority.

typical task breakdown:

• fast loop (hundreds of hz)
  imu read ---> state estimation ---> control output

• medium loop (tens of hz)
  baro update ---> apogee detection ---> health checks

• slow loop (few hz)
  gps update ---> telemetry ---> logging

• background / idle
  flash writes, non-critical housekeeping

critical loops never wait on slow ones. telemetry never delays control. logging never delays recovery.

this can be implemented with:

• timer interrupts
• cooperative scheduling
• or a lightweight rtos if desired

the key is determinism, not framework choice.

data ownership and flow

data flows in one direction:

sensors ---> estimation ---> decision ---> actuation

no subsystem reaches backward in the chain. control does not read raw sensors. actuators do not decide anything. telemetry reads but never writes.

shared data is stored in clearly defined structures, updated atomically. no global free-for-all. no hidden side effects.

this prevents:

• race conditions
• partial updates
• state corruption during interrupts

mode-based parameter changes

different flight phases need different behavior.

examples:

• pid gains during ascent vs coast
• steering aggressiveness during early vs late descent
• telemetry rate changes by state

these are not handled with “if altitude < x”. they are handled by state entry configuration.

when the state changes, parameters change once. not continuously. not conditionally.

this makes behavior predictable and testable.

error handling as a first-class citizen

errors are not printed and ignored. they are events.

sensor fault ---> flag set
flag triggers behavior change
behavior change may trigger state transition

for example:

• imu failure during ascent ---> fins neutral ---> continue ballistic ---> recovery still armed
• gps loss during descent ---> disable steering ---> passive parachute

the system does not panic. it degrades gracefully.

persistent state and reset survival

the system assumes resets can happen mid-flight.

so critical facts are stored redundantly:

• “has launch occurred? (idk man)”
• “has recovery been deployed??????”

on reboot, the software reconstructs reality based on:

• time since power-up
• sensor readings
• stored flags

if in doubt, it biases toward deploying recovery.

testing philosophy embedded in architecture

because subsystems are isolated:

• control can be tested with fake sensor data
• recovery logic can be tested without motors
• telemetry can be disabled entirely

this is not accidental. the architecture is designed so you can simulate or stub any part.

that’s the difference between “code that runs” and “code that flies”.

how everything finna fits together

the rocket software is not clever. it is disciplined.

• states prevent chaos
• timing prevents interference
• separation prevents cascading failure
• defaults prevent disasters

when the rocket leaves the rail, the software stops being flexible. it becomes rigid on purpose.

that rigidity is what keeps it alive.

at this point, you have the complete system:

• physics
• control
• actuation
• power
• recovery
• telemetry
• fail-safes
• software structure

there is nothing essential left.