Intro to PROVE Flight Software

For our second post on the technical side of the project we are talking about software. The Flight Software (FSW) and Onboard Computer (OBC) is the central brain of any spacecraft. For PROVE Pathfinder, it controls when the system performs any action, like taking a picture, collecting telemetry or sending data to storage. The way this has been implemented for PROVE Pathfinder is summarized in Figure 1. Essentially, the core of the flight software is the scheduler service that continually runs while PROVE is switched on. It never directly interacts with hardware (like cameras), but has all the logic coded into it to know when tasks need to be performed during the mission. For example, when it is time to take images during an observation pass, the scheduler starts new task processes that communicate with the cameras using their own software libraries to take pictures.

 

Figure 1: Overview of PROVE Pathfinder Flight Software

The logic that the scheduler runs is controlled by two .json files; tasks.json and config.json. tasks.json describes details about the operational tasks themselves, like what mode they are executed in (see Figure 2) and where their code files are located. The config.json file contains information on the configuration of the system, like camera settings, imaging pass start and stop times and fault detection thresholds. Finally a python package is included in the flight software to provide functions and classes used across the software in flight.

Figure 2: System Mode Diagram of PROVE Pathfinder Flight Software

Development Approach

A git repository was the core tool of the software development. It allowed version control of the code, meaning different branches for specific development activities could be easily created and remerged into the master branch, ensuring stability of the flight software throughout the process. The online git webservice GitHub was chosen to host the git repository, which supports a bunch of other great capabilities. GitHub “Actions” were particularly useful to us, as it allowed the software to be tested automatically each time an update was made. This meant that any issues with the software could be rapidly identified and with a bit of tinkering with “Self-Hosted Runners” tests could be run on the FlatSat (see Figure 3) hardware model, see this link for more info. With this “Hardware In the Loop” (HIL) approach to development testing, the team were able to support the Continuous Delivery/ Continuous Integration (CI/CD) mantra of constantly integrating and testing code to deliver a stable system.

Figure 3: PROVE FlatSat Model

If you are interested in reading more about our flight software feel free to head over to the UoBSat GitHub or public repository of our flight_software where you can find the documentation and the code itself