ChipSat Flight Software

Overview

I joined the chipsat team in Cornell’s Space Systems Design Studio as a flight software engineer while the board was moving from Arduino to STM32. Rather than patch the existing code, I rebuilt the entire flight software stack.

• 80% → 20% space usage. The rebuilt stack uses a quarter of what the old one did, freeing most of the budget on a size-, weight-, and power-constrained target. It is also more efficient and more reliable.
• Library bugs found and fixed. Several third-party libraries the stack depended on had bugs. I tracked them down and replaced those libraries with my own implementations built for flight.
• Ground software rewritten. I also rewrote the ground software that commands the spacecraft and receives its telemetry.

Two rocket launches are planned this semester, so the software is exercised in real flight rather than only on the bench.

Design decisions 03

• Use the existing Arduino build as the behavioral reference before rebuilding — without a known-good reference there is no way to tell a new bug from a bug the firmware always had.
• Move to STM32 because the chipsat’s size, weight, and power envelope rules the Arduino hardware out; the platform choice follows the SWaP budget, not developer convenience, and the MCU in turn bounds what the flight software can afford to do.
• Plan flight testing on two rocket launches instead of bench testing alone, so the software meets the vibration, power, and timing conditions it actually has to survive.

C/C++ · STM32 (ARM Cortex-M) · Arduino · embedded firmware · ground software

listed under research & publications →