FreeRTOS Based Firmware For Australis Series Flight Computers

Want to submit an issue?

Operating avionics hardware for winning rocket of Technical Excellence Award and runner's up overall in AURC 2024 - Aurora V

Powering IREC & AURC 2025 entries for avionics subsystem - Legacy III

Warning: The firmware system and this repository are still under active development. Documentation and source code are not yet considered stable.

Pre-release builds are being made available as progress is made, however the user should be aware that there may be undocumented or unfinished features in some parts of the code.

Overview

This repository contains the firmware for the Australis series flight computers, developed using FreeRTOS. The project includes source code, build tooling, and documentation to facilitate development and deployment.

Australis version 2 (AV2) flight-computer hardware platform

Note: The firmware is designed to run on various hardware platforms, with explicit support for STM32F439 microcontrollers, however the AV2 system (pictured above) is the basis for implementation. While other platforms are supported unofficially as extended targets, correct operation is not guaranteed.

Getting Started

For a detailed guide to get started with the project, follow the instructions in the Firmware README. This includes information on setting up the build environment, building the firmware, and running it on supported hardware platforms.

Docker Environment

This repository provides a containerised development environment to simplify the process of setting the project up on different systems and platforms. To make use of this environment, first ensure Docker is installed and running on your system and then follow these steps to get started:

If you haven't already, clone this repository to your local system:

git clone https://github.com/RMIT-Competition-Rocketry/Australis-Avionics-firmware.git
Navigate to the repository root directory:

cd /path/to/Australis-Avionics-firmware
Inside the root directory, run the following command. This may take a couple of minutes to finish when running for the first time:

docker compose run --rm australis-dev

This will build the image, if not already available, and enter a running container in the project root: /firmware (/src/firmware on the container's filesystem).

The --rm flag deletes the container on exit, this is desirable as the container mounts the repository in the host filesystem into the running container, enabling editing on the host while using the container to manage building and deployment.
Follow the steps outlined in the Firmware README to build and deploy the project.

Common Issues

The /src directory inside the container is empty/unavailable

Consider investigating the file sharing configuration of your Docker installation.

I followed the steps but the container is taking a long time to start

Configuring the Docker environment can take a bit of time on the first run as it needs to build the image before creating the container. Once the image is built, the container should be much faster to start.

Documentation

For detailed information about the project, including build instructions, code guidelines, and hardware targets, refer to the following resources:

Project Wiki: Comprehensive documentation about the project.
API Reference: Detailed API documentation for the project.
Firmware README: Detailed information about the firmware source structure, build process, and target platforms.

FAQ

Q: What is Australis?

Australis is a combined firmware and hardware platform designed for high degrees of flexibility and redundancy in its implementation. The system supports a core architecture that provides all the tools necessary for creating and operating a complete flight computer for any rocket configuration.

Q: What makes the system flexible?

Australis sports various hardware interconnects and a range of highly modular firmware systems provided to enable your designs. AV2 boards each provide two directly connected microcontrollers, and may be interconnected with other boards, primarily via CAN.

Q: What makes the system redundant?

Redundant apogee detection and recovery deployment is currently under development for official firmware targetting AV2. The approach follows a triple-mode-redundant (TMR) architecture designed for a dual-board setup with two stages of redundancy:

In hardware, one microcontroller on the bus is dedicated the role of arbiter. The arbiter is in charge of collating "votes" from the other three microcontrollers, and when it determines a majority vote it activates the recovery output interlocks and detonates the energetics
Each remaining microcontroller provides the role of voter, maintaining an active estimate of their flight-state dynamics. The physical system state is considered a global input to each voter, where the processed state variables determine the input redundancy stage through a "vote" on the output when at least two of the following three conditions are met:
- Vertical velocity (ground axis referenced) is negative
- Barometric pressure is increasing
- Tilt angle (ground axis referenced) is greater than 90°

While designed for dual-board systems for a TMR configuration, the level of N-Modular Redundancy is highly flexible and can easily be extended for greater values of N. Additional redundancy is also being considered for support as flexible redundancy, where a TMR configuration could fall-back to other forms of redundancy such as hot-standby in the event of a number of failures that cannot be masked in the implemented redundancy configuration by N modules.

Contributions

Contributions to the project are welcome. Please refer to the contributing guidelines in the firmware README for more information on how to contribute.

Acknowledgements

Key Contributors

Name	Role
Matthew Ricci	Principal firmware developer
William Houlahan	Initial driver implementations
Benjamin Wilsmore	Initial driver implementations

Special Thanks

Other members of the Aurora V Avionics team:

Hugo Begg - avionics hardware
Jonathan Chandler - ground control station
Jeremy Timotius - data analysis
Lucas Webb - ground control station

Thank you to Aurora & Legacy project team leads Patrick Underwood and Brodie Alexander for providing the opportunity and environment to work on these rockets as part of the team, and thank you to everyone who helped make them a reality!