Flight Software Made Simple(r) with NASA's "core Flight System"

When I’m not working on ground systems or web applications projects for NASA Goddard or doing schoolwork, I’m working on the flight software for my university’s upcoming satellite mission, CACTUS-1. We’re launching two experiments in a single chassis with a common power bus and communication rig.

One of the two experiments going up on CACTUS-1 is TRAPSat, an experiment designed to catch orbital/high-altitude debris and photograph it so we can see what we’ve caught. Then, once the orbit decays, the satellite burns up, removing that debris from orbit.

Smaller-scope TRAPSat missions have been flown before - an experimental TRAPSat payload flew on the August 2016 launch of RockSat-X, and a variant designed to be flown with weather balloons instead of propulsive launch systems has flown many times. As a result, re-engineering TRAPSat to ride in the CACTUS-1 chassis is just that - re-engineering. The code already exists in a few different forms, we just have to clean it up and tweak it for the different hardware we’re using.

Something that has made this incredibly easy is NASA’s core Flight System (cFS), which was the framework used for TRAPSat’s flight on RockSat-X. cFS sits on top of NASA’s Operating System Abstraction Layer (OSAL) and provides OS-agnostic task scheduling, cross-application messaging, and many other features in one well-documented package. Regardless of the fact that we, unlike most satellite missions, are using a Raspberry Pi running Linux as our main flight computer, cFS gives us all the same tools as someone designing flight software for NASA using a more specialized controller would have.

cFS provides a build chain as well, which includes Platform Support Packages (PSPs) for a number of targets, including Linux, RTEMS, and VxWorks on a few specialty micro-PCs. It’s all contained in documented Make and CMake files, so tweaking to your specific build needs is very easy. For instance, I implemented cross-compilation to ARM as a build target in our fork so we could use x86 continuous integration infrastructure to automatically build for our Pi.

cFS is a fantastic tool, and while (in my opinion) it’s way overkill for a small CubeSat mission, it provides us with a framework to grow into. If the mission becomes more advanced in future iterations of CACTUS, we can re-use our same code even if we completely switch CPU architectures and operating systems.

If you’re interested in flight software, you can take a look at cFE (the main component of cFS) and OSAL at the NASA open source portal.