CubeSat Flight Software

Context

STeRG is building MIT-WPU’s first CubeSat, entirely student-built. The program is in the design and qualification-model phase, targeting launch in 2027. I lead the software subsystem — a team of 7–10 engineers across STeRG’s missions — and on this CubeSat that means owning everything that executes on the satellite: onboard computer software, attitude determination and control, payload, and communications.

Architecture

The onboard computer is an STM32MP257 (dual Cortex-A35 + Cortex-M33) running embedded Linux, with NASA cFS as the user-space flight-software framework. Subsystem boards — attitude control, payload, communications — are our own custom PCBs, running STM32U5 and STM32H7 in a mix of FreeRTOS and bare-metal configurations.

That split is deliberate: cFS gives us a proven application framework, software bus, and command/telemetry plumbing on the Linux side, while the hard real-time loops stay on microcontrollers where timing is provable.

The unglamorous part: BSP bring-up

The OBC is custom hardware, which means nobody hands you a working Linux image. I’m bringing up the board support package myself: Yocto image builds, U-Boot configuration, device-tree edits to describe our actual hardware, GCC ARM cross-compilation, and user-space drivers over sysfs for GPIO, I2C, SPI, and UART. Most of this work happens over a serial console in minicom, watching boot logs to find out which device-tree node is wrong this time.

In parallel I’m writing the inter-board interface control documents — the CAN, UART, and Ethernet contracts that let the subsystem teams build against stable interfaces instead of against each other.

Where it stands

The flatsat photos show the current phase: OBC, EPS, ADCS, S-band, and UHF subsystems wired together on the bench and under test as a satellite-in-pieces. The qualification model comes next, then the flight model, with launch targeted for 2027.