This repository contains code to support a flight controller. Currently, the only supported hardware is the Fjalar flight controller (as the name suggests) but one of the goals of this project is portability.
The codebase is split into three projects, the dashboard, the handheld tracker firmware and the flight firmware. Ideally these should be split into separate repositories eventually.
Both firmwares use zephyr and are located in the /application/ folder.
Building the software is most easily done with the Zephyr SDK. This is separate thing from the Zephyr RTOS/library and is just a bundle with tools for compiling, linking and so on. Please refer to the zephyr docs on how to install.
It is recommended to set up a Python virtual environment for the repository. A virtual environment is basically a sandbox isolate each project and prevent collisions between library versions. The project can be built without this but there will most likely be unexpected issues a few months down the line.
Configuring one can be as simple as running python -m venv .venv. Every time you want to build something run source .venv/bin/activate to activate and enter the virtual environment.
The project is built and managed using West. West will automatically fetch everything Zephyr related (other than the SDK).
important there is a bug in the used version of Zephyr. Before installing anything in the virtual environment you need to install a specific version of pillow pip install pillow==9.4.0.
West can be installed through pip pip install west. (enable your virtual environment first if you have one). Then run west update in the root of this repository to make West fetch Zephyr RTOS and all required dependencies.
The tracker can be built and flashed using west application/tracker -b t_echo -p auto. Then you need to manually copy the firmware to the t-echo. Connect it over USB, double tap the reset button to enter the bootloader and mount it as a drive. Copy build/zephyr/zephyr.uf2 to the new drive to flash.
Run west build application/flight_controller/ -p auto -b fjalar -t flash to build and flash.
Both the tracker and flight firmware supports compiling for native_sim allowing you to run it natively. This only works on linux, if you are on Windows try using WSL 2 (WSL 1 doesn't work).
To run natively change the board to -b native_sim and use -t run instead of -t flash
west build application/flight_controller/ -p auto -b native_sim -t run
The state machine is constrained so that each state can only progress to the next; there is no other way for the FC to be in a state without first having been in the one prior. Every state has an exit requirement that, when fulfilled, changes the state variable to the next state.
At this stage, the state is mainly used in if-statements related to the State Estimation script, since some functions are only valid in specific states. With the addition of air brakes, the state and event are also sent via CAN to Loki to determine whether the air brakes should be deployed.
| Int | State | Cause | Consequence |
|---|---|---|---|
| 0 | STATE_IDLE |
Set as initial state | Nothing |
| 1 | STATE_AWAITING_INIT |
LoRa command received | Initialization script is allowed to run |
| 2 | STATE_INITIATED |
Init sequence completed | Filter.c runs attitude_filter_accelerometer_ground function (otherwise not) |
| 3 | STATE_AWAITING_LAUNCH |
LoRa command received | Operation of motor systems is allowed (not enforced yet) |
| 4 | STATE_BOOST |
Acceleration > boost threshold and altitude > 10 m OR velocity > boost threshold |
Nothing |
| 5 | STATE_COAST |
thrust_bool is negative → force analysis shows no thrust in system |
Air brakes can be used (1 of 2 conditions) |
| 6 | STATE_DROGUE_DESCENT |
Apogee reached | Drogue pyro charge activated |
| 7 | STATE_MAIN_DESCENT |
Altitude AGL < 200 m | Main pyro charge activated |
| 8 | STATE_LANDED |
Accelerometer senses only normal force (~+9.81 m/s²) | Nothing |
The event machine is a collection of boolean flags that simplify the logging of important events.
Currently, the velocity class is only used to decide whether the barometer filter function should be executed. It is only run in the subsonic state, since in the transonic state shockwaves would interfere with readings.
The velocity class machine differs slightly from the other two in that it can move both upward and downward between classes.
Here, M refers to the Mach number.
The flight computer makes use of linear and nonlinear kalman filters that are detailed in aesir's slab posts.