FMT-Firmware

FMT-Firmware：把 Simulink 模型直接飞上天的开源飞控固件

项目背景与痛点

飞控固件这个领域，长期被两套「重工业级」方案统治：PX4 和 ArduPilot。它们成熟、稳定、生态庞大，但也带来了另一个问题——代码体量巨大，控制律与底层驱动深度耦合。一个控制工程师想在姿态环里试一种新的非线性控制方法，往往要先啃完几百个源文件，搞清楚 uORB 消息怎么流转、驱动怎么注册，才能把一个公式塞进去。

与此同时，控制算法的研发流程早已模型化：工程师在 MATLAB/Simulink 里搭框图、跑仿真、做 Monte Carlo 验证。但模型验证通过之后，落地到嵌入式仍然是一次痛苦的「手工翻译」——重写 C 代码、手动对齐参数、再在实机上反复调。仿真与实机之间的鸿沟，本质上是工具链的断裂。

FMT-Firmware（Firmament Autopilot）要解决的正是这个断裂。它的核心主张很明确：Model-Based Design（基于模型的设计）。控制律、状态估计等算法在 Simulink 中建模，通过代码生成直接产出可上机的 C 代码，再由一套轻量、分层的嵌入式框架承载。换句话说，模型即固件，仿真即验证。

核心技术揭秘

FMT 的架构可以粗暴地切成四层：硬件抽象层（HAL）、驱动层、框架层、算法模块层。RT-Thread 作为实时内核提供任务调度与同步原语，模块之间不直接互相调用，而是通过一套 Topic 发布/订阅消息总线解耦——这一点与 PX4 的 uORB 思路相近，但实现更精简。

数据在主链路中的流向非常清晰：

几个值得细看的设计点：

其一，消息总线的解耦价值。 传感器采集、状态估计、控制计算各自是独立任务，以固定频率跑在 RT-Thread 的调度器上，彼此只依赖 Topic 的数据契约。这意味着替换一个 EKF 实现、或者换一款 IMU，不需要改动调用方代码，模块边界是真正干净的。

其二，代码生成的接口层。 Simulink 生成的 C 代码天然是「函数式」的：输入结构体、输出结构体、内部状态。FMT 在模型与固件之间做了一层薄封装，把 Topic 数据映射为模型输入，把模型输出写回 Topic。这层胶水看似不起眼，却是整个工程能否工程化的关键——它决定了模型迭代后能否平滑地重新集成，而不引发大范围的连锁修改。

其三，跨平台的 HAL。 从 Pixhawk 系列到 FMU，再到 QEMU 仿真环境，底层差异被 HAL 吃掉。这让 SITL（软件在环）和 HITL（硬件在环）成为同一套代码的不同编译目标，而不是两套平行实现——这正是模型驱动开发能闭环的前提。

功能亮点与差异

对比 PX4，FMT 最鲜明的差异不是功能多，而是开发范式的不同。PX4 是「工程师写代码」，FMT 是「工程师画模型」。前者胜在可控性与极致优化，后者胜在迭代速度与算法可验证性。

对比 ArduPilot，FMT 的代码量和模块数量都小一个量级，阅读成本低，适合作为教学与科研的底座。ArduPilot 的杀手锏是几十种机型的成熟支持与庞大的参数体系，而 FMT 的杀手锏是从仿真到实机的一致性与可追溯性：模型版本、生成代码、固件版本三者可以严格对应。

另一个隐含优势是调试路径。算法出问题时，你可以回到 Simulink 里做信号级回放与频域分析，而不是在嵌入式调试器里靠打日志猜。对于做控制理论验证的团队，这个价值远超功能清单上的任何一项。

应用场景与落地建议

适合的场景：高校与研究所的飞控算法教学、新控制律的快速原型验证、定制化无人机的自研飞控、以及需要 HITL 验证的型号预研。

生产环境需要警惕的几点：

• 安全机制：相比成熟商用固件，FMT 在失效保护、传感器冗余仲裁、失控返航等安全链路上的完备度需要自行补强。上真机前务必补齐看门狗、通信丢失保护、姿态异常保护。
• 实时性验证：RT-Thread 的调度抖动、Topic 传递的延迟、模型代码的执行时间，都应在目标硬件上实测，而不是靠仿真推断。控制周期一旦抖动，再好的算法也白搭。
• 双仓库版本管理：模型仓库与固件仓库必须严格对齐版本，否则「代码和模型不一致」会成为最难排查的故障来源。
• 推荐路径：SITL → HITL → 系留/限高试飞 → 全包线，逐级放开，不要跳步。

综合评价

优点：架构分层清晰，模块边界干净；Model-Based Design 打通了「仿真—生成—上机」的链路，算法迭代效率高；代码轻量，可读性与可改造性都优于大型飞控项目；跨平台 HAL 让仿真与实机共用一套代码。

缺点：社区规模与文档厚度远不及 PX4/ArduPilot，遇到冷门硬件或边界问题时能查的资料有限；高级功能（避障、集群、复杂任务规划）基本需要自研；代码生成的黑盒特性会让底层调试变得别扭——出了问题时，你面对的是一堆自动生成的变量名；安全与冗余机制需要使用者自己兜底。

一句话结论：FMT-Firmware 不是来取代 PX4 的，它是给「以算法为核心竞争力」的团队准备的一把快刀。如果你要的是开箱即用的成熟产品，选 PX4；如果你要的是把控制理论快速变成能飞的东西，FMT 值得认真看一遍。