CanSat & Model Rocketry Avionics

Two competitions, one avionics architecture

We entered two student competitions, both organized by IN-SPACe with the Astronautical Society of India: the CANSAT India Student Competition and the Model Rocketry India Student Competition. For the first, we built a CanSat. For the second, we built a model rocket that carried a second CanSat as its deployable payload.

As Software Lead, my bet was that the two builds shouldn’t need two codebases. We designed a shared onboard-computer stack — 3 of the 4 PCBs are common across both — with competition-specific peripherals and state machines layered on top.

The firmware

Each stack pairs an STM32H7 (Cortex-M7) onboard computer with an STM32F4 (Cortex-M4) RF board. The firmware is multi-threaded FreeRTOS: deterministic task scheduling, mutex and queue synchronization between sensing, state-machine, and telemetry tasks, and DMA-driven I/O so the CPU isn’t babysitting transfers during flight events.

I wrote the bare-metal HAL/LL drivers underneath — GPIO, timers, PWM, RTC, flash, ADC, SPI, I2C — with register-level access and careful ISR design. Sensor fusion combines IMU, barometer, and GPS to drive the flight state machine. Telemetry goes out over XBee, LoRa, and GSM/4G with CRC-16 packet framing and ACK/NACK, falling back to safe states when a link drops.

Bring-up and validation

I owned board bring-up from schematics through validation: pinmux and clock-tree verification, logic-analyzer traces on every serial bus, UART log analysis, and Python test scripts that exercised the telemetry protocol and sensors automatically. The avionics that went to the launch rail were the avionics we had already validated end to end on the bench.

Result

The team earned an Excellent grade in the IN-SPACe CANSAT India Student Competition, and the shared-stack architecture paid off beyond the competitions — the drivers and the telemetry protocol libraries built here were reused across our later projects.