FMT-Firmware: an autopilot whose control laws start in Simulink

The autopilot is split between a firmware repo and a model repo

Firmament is presented as an advanced autopilot system designed with Model-based design, and the README is careful about what this particular repository is. The system is composed of two parts. FMT-Firmware, the repository you are reading, is the embedded side, a stable embedded system written in C/C++. FMT-Model is a separate repository holding a simulation framework with algorithm libraries designed with MATLAB/Simulink.

That division explains the awkward, otherwise unremarkable, sentence in the README about high development efficiency achieved with model-based design and easier debugging. The claim is about the pair, not about the firmware alone.

For the audience this matters: people who want an autopilot to fly a vehicle. The README says it can be used to build control systems for autonomous vehicles such as uav, car, ship and robot, and the topic list covers autopilot, drone, uav, evtol, multicopter, flight-controller, robotics and mavlink. The product pages and the S1 Flight Controller page suggest a commercial ecosystem around it, with the company site linked from the README banner.

So this is not a general purpose robotics framework. It is one autopilot with a model based development flow attached to it.

The target directory is where hardware support is declared

The repository layout puts the hardware abstraction in plain sight. The top level holds rtos/ for the real-time layer, src/ for the core, target/ for board support, unit_test/ for tests, utils/ for helpers, docs/, figures/, plus .clang-format, .gitmodules and a .github directory whose build workflow the README badges point at.

Inside target/ the README links to one directory per supported board, and the paths describe the naming convention: target/sieon/s1 for the SIEON S1, target/amov/icf5 for the AMOV ICF5, target/cuav/v5_nano, target/cuav/v5_plus and target/cuav/7_nano for the CUAV boards, target/pixhawk/fmu-v5 and target/pixhawk/fmu-v2 for the two Pixhawk revisions, and target/qemu/qemu-vexpress-a9.

That last entry is the one to notice. A QEMU vexpress-a9 target sits alongside the real boards, so the firmware has a target that runs under emulation rather than on hardware. For a control system with a simulation half, being able to execute the firmware under QEMU is a practical necessity rather than a curiosity, because it lets you exercise the embedded side without a vehicle or a bench full of hardware.

The hardware list is short and specific. Eight entries, including one emulated target, is a matrix you can hold in your head, and it is also a boundary: a new board means a new target directory, not a configuration change.

RT-Thread underneath, Simulink above

The real-time foundation is RT-Thread, and the README credits it for the real-time performance, describing the firmware as built on the RT-Thread RTOS with an active community and a large number of third-party components. The rtos/ directory at the repository root corresponds to that, and .gitmodules in the root indicates dependencies arrive as submodules.

Above the RTOS sits the model based layer. The README lists auto code generation from a Simulink model adapted to different hardware platforms, naming ARM, AMD and Intel among them. The generated code is what the firmware runs, and the model itself lives in the FMT-Model repository alongside the simulation framework.

This is the central design decision, and it is also the central trade-off. The benefit is that the control algorithm can be validated in simulation against algorithm libraries before it is ever compiled for a target, and that the same model can be regenerated for different hardware. The cost is that the development loop now runs through MATLAB and Simulink, which are licensed tools, and that a team without that toolchain inherits a workflow it cannot fully exercise.

The cross-platform toolchain support mentioned in the feature list covers Windows, Linux and Mac for the development environment. The build workflow lives in .github, and unit_test/ at the root suggests the C side has its own test surface.

Getting the source means taking the submodules too

There is one download command in the README, and it comes with an explicit warning about the submodules.

git clone https://github.com/Firmament-Autopilot/FMT-Firmware.git --recursive --shallow-submodules

The --recursive flag is what the note insists on, because FMT-Firmware contains submodules and the note says to use --recursive to download the submodule as well. The --shallow-submodules flag keeps that fetch shallow. The .gitmodules file at the repository root is the evidence for this, and it also means that the RT-Thread components and any other vendored dependencies arrive through the same mechanism.

The practical consequence for a new user is that a clone without --recursive produces a tree that will not build, and the failure will look like a missing directory rather than a clone error. If you already have a checkout, the fix is to initialise the submodules in it.

Beyond the source itself, the README points to a User Guide at docs.sieon.net, a product page for the S1 Flight Controller, and the company website. Those hosted pages are where the hardware bring-up instructions live, since the repository's own docs/ directory is not described in the README.

Pixhawk and MAVLink are the interoperability surface

Two entries in the feature list define how this autopilot meets the wider ecosystem. The first is support for the most widely used open-source hardware Pixhawk, with both FMUv2 and FMUv5 supported, and the README backs that with the target paths for both revisions. The second is support for MAVLink and QGroundControl, which is the link between this autopilot and ground control software.

That combination is what makes FMT-Firmware usable on hardware that other people own. If you buy a Pixhawk FMUv5, you get a board with a target directory in this repository, and the MAVLink support means a ground station can talk to it.

The Pixhawk claim also sets the ceiling on the supported hardware story. The README is explicit that both FMUv2 and FMUv5 are supported, and the hardware list adds the SIEON S1, the AMOV ICF5 and three CUAV boards. Everything listed is a flight controller with a directory in target/.

The README also names one drone built with the system, the Amovlab MFP450, linked through a store listing. That is the only end product mentioned, and it is worth noticing that a project with an open source firmware also has a commercial hardware and model offering behind it, which affects who you can ask questions of and how quickly fixes land.

A release every year or so, and a permissive licence

The release history is short and legible. There is v1.0.0 from 2024-02-08, v1.1.0 from 2025-04-01 and v1.2.0 from 2026-10-20. The last push was on 2026-10-21, the day after the newest tag, and the repository is not archived, so the tip of the branch closely follows the release rather than lagging behind it.

For an embedded project, that is the ideal case for the question of whether you are building on current code. It also tells you the project is still pre one point five, so interfaces may still move between minor versions, and the gap between v1.0.0 and v1.1.0 is a long one by release count.

The licence is Apache-2.0, with the LICENSE file at the root and the badge in the README pointing at it. Apache-2.0 carries patent grants and an explicit notice requirement when you redistribute the firmware, which is manageable for most commercial flight work but worth checking against your own distribution model. This review does not offer legal advice on how the licence applies to your product.

One gap to note: the README describes the system as stable and high performance but does not publish any measurement, flight log or test report, so those adjectives have to be taken as the project's own description rather than as something a reader can check.

Model based workflow versus hand written control code

The real alternative to FMT-Firmware is to write the control code yourself in C and C++ and run it on the same flight controller, and the difference is where the algorithm lives.

With a hand written stack, the control law is a function in your repository, the simulation is either something you build or something you skip, and the loop from an idea to a flying vehicle goes through compilation and flashing. Nothing requires a commercial toolchain, and a small team can hold the whole thing in its head. What you give up is the ability to run the same model in a simulation framework with a library of algorithms and then generate code for several processors from it, which is exactly the workflow FMT is built around.

With FMT, the algorithm is a Simulink model in a separate repository, the code on the target is generated, and the simulation framework is the place where behaviour is checked first. That is a real advantage when the vehicle is a ship or a car where each test costs money, and it is a real liability when the work is a small experiment and MATLAB/Simulink is not already part of your toolchain.

The board matrix follows the same logic. A hand written stack can be aimed at whatever board you own, whereas here you are inside the list of seven real targets plus one QEMU target, and adding hardware means adding a target directory.

Editorial conclusion

Adopt FMT-Firmware if you are building an autonomous vehicle control system and your team already works in MATLAB/Simulink, since the model based workflow and the generated code are the reason to choose this firmware over a hand written one. Do not adopt it if your team has no Simulink capability, if you need a wide board matrix, or if you want a firmware you can modify entirely in C. Verify first by cloning with submodules and building the Pixhawk FMUv5 target listed under target/pixhawk/fmu-v5, then confirm on the docs.sieon.net user guide how the generated model is linked into the firmware before committing an aircraft to it.

Frequently asked questions

Official sources

1. Firmament-Autopilot/FMT-Firmware on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases