开源飞控平台与技术路线¶
选择飞控项目首先是选择任务模型、软件架构、硬件生态和验证工具，不是比较哪个项目“功能最多”。同一块飞控板也不一定被所有项目支持，更不能把不同项目的固件文件、参数或板级目标互换。
图中会出现以下平台专名：
- ArduPilot硬件抽象层（AP_HAL，ArduPilot Hardware Abstraction Layer）用于隔离上层库与具体板卡接口；
- uORB是PX4内部的异步发布订阅消息总线；
- NuttX是常用于飞控板的实时操作系统；
- 可移植操作系统接口（POSIX，Portable Operating System Interface）定义一组操作系统接口约定；
- 软件在环（SITL，Software In The Loop）在主机上运行飞控代码；
- 硬件在环（HITL，Hardware In The Loop）在真实飞控硬件上运行固件，并由仿真环境提供反馈。
四种常见技术路线¶
下表用于建立方向感，不替代各项目当前版本的正式支持列表。
| 项目 | 主要取向 | 代表性架构特征 | 适合先验证的场景 |
|---|---|---|---|
| Betaflight | 小型多旋翼的人工操控、响应和飞行性能 | 紧凑的嵌入式控制链、任务调度器、板级目标和配置器 | 控制链、滤波、数字油门、日志与资源约束 |
| INAV | 多种遥控模型与导航功能 | 与小型飞控硬件生态结合的导航、任务和配置体系 | 导航传感器、返航、固定翼或多旋翼任务 |
| ArduPilot | 多载具、自主任务和丰富外设 | 车辆代码、公共库、硬件抽象层、调度器和软件在环 | 自动驾驶逻辑、任务、故障处理与硬件抽象 |
| PX4 | 模块化自动驾驶与机器人系统集成 | 模块、发布订阅消息总线、驱动、中间件和飞行栈 | 模块通信、状态估计、控制分配和机器人集成 |
“主要取向”不是功能排他声明。例如某项目可能同时支持人工飞行、导航和多种载具，但其默认工作流、主要硬件和贡献路径仍可能不同。
先用任务筛选¶
至少回答：
- 目标载具是多旋翼、固定翼、垂直起降、车辆还是其他平台；
- 主要是人工操控、辅助飞行还是自主任务；
- 是否需要任务规划、避障、冗余或伴随计算机；
- 目标飞控板是否有当前维护的正式目标；
- 需要哪些传感器、执行器和通信协议；
- 是否需要软件在环、硬件在环或自动化回归；
- 团队更熟悉C、C++、实时操作系统还是消息化模块；
- 修改是否计划向上游提交；
- 开源许可证是否与发布方式和商业计划兼容；
- 谁负责后续版本升级、安全修复和硬件维护。
三个示例任务¶
| 示例任务 | 强制需求 | 优先候选 | 仍需继续确认 |
|---|---|---|---|
| 5英寸人工操控练习机 | 小型多旋翼、低延迟人工操控、黑匣子日志、目标板正式支持 | Betaflight | 接收机、电调协议、目标版本和配置器版本 |
| 自主垂直起降验证机 | 固定翼与多旋翼状态转换、任务规划、位置控制、仿真 | ArduPilot或PX4 | 载具支持、转换策略、外设、团队经验和仿真场景 |
| 飞控源码教学平台 | 主机仿真、清晰模块边界、消息接口、板级移植资料 | 本专题选择PX4作为贯穿示例 | 主机系统、稳定版本和后续真实目标板 |
“优先候选”不是直接采购结论。真实项目仍须使用下方矩阵逐项验证，任一强制项失败就淘汰候选。
本专题为什么用PX4演示¶
本专题需要一条从源码到软件在环再到只读模块改动的公开路径。PX4官方同时提供：
- 明确的稳定发布标签；
- 开发环境和构建说明；
- 软件在环仿真；
- 模块示例；
- 发布订阅消息接口；
- 板级移植指南。
因此后续实操固定使用PX4 v1.17.0作为教学样例。选择它只为保证示范步骤连续，不表示它适合所有飞行器，也不要求后续硬件购买PX4生态产品。
平台名称不能替代版本¶
必须同时记录：
- 仓库地址；
- 发布标签或提交哈希；
- 子模块提交；
- 板级目标名称；
- 地面配置工具版本；
- 参数和消息协议版本；
- 本地补丁；
- 构建环境。
“使用PX4”“使用Betaflight”无法复现实验。主分支每天变化，同名板卡也可能存在不同硬件版本。
许可证也是架构约束¶
不同项目采用的开源许可证不同。许可证会影响修改、分发、链接、源代码提供和声明义务。
| 项目 | 仓库标示的主要许可证 | 开发时需要确认 |
|---|---|---|
| Betaflight | GNU通用公共许可证第3版 | 分发修改版固件时的对应义务 |
| INAV | GNU通用公共许可证第3版 | 修改和分发边界 |
| ArduPilot | GNU通用公共许可证第3版 | 派生代码和发布方式 |
| PX4 | BSD三条款许可证 | 版权声明、许可文本和免责条款 |
这里只提示许可证差异，不构成法律意见。实际产品还可能包含第三方库、硬件设计、商标和无线电合规要求。
架构比较要落到源码证据¶
不要只根据宣传页判断。至少找到：
- 主入口或启动脚本；
- 调度器或任务模型；
- 硬件抽象和驱动目录；
- 传感器与状态估计模块；
- 控制器和控制分配模块；
- 参数定义；
- 消息或协议定义；
- 日志实现；
- 板级目标；
- 自动化测试入口。
同一个概念在不同项目中可能使用不同名称。例如“混控器”“控制分配”“输出混合”都可能承担从控制需求到执行器命令的映射，但数据结构、限幅和故障处理并不相同。
选择矩阵¶
为候选项目填写：
| 维度 | 必须满足 | 候选A | 候选B | 证据 |
|---|---|---|---|---|
| 载具与任务 | 待填 | 待填 | 待填 | 官方功能和限制 |
| 飞控板 | 正式目标和硬件版本 | 待填 | 待填 | 支持列表与源码 |
| 传感器 | 型号、总线和冗余 | 待填 | 待填 | 驱动目录与板级定义 |
| 执行器 | 数量、协议和更新率 | 待填 | 待填 | 输出驱动 |
| 仿真 | 所需载具和故障场景 | 待填 | 待填 | 官方仿真文档 |
| 地面工具 | 系统、版本和协议 | 待填 | 待填 | 发布说明 |
| 许可证 | 满足发布计划 | 待填 | 待填 | 仓库许可证 |
| 维护 | 活跃分支和升级责任 | 待填 | 待填 | 提交、发布和维护规则 |
任何关键维度处于未知状态时，都不应进入板级移植或真实飞行测试。
填写后的教学样例¶
假设目标是“在普通计算机上学习模块、消息和仿真，不接真实电机；后续可能研究自主多旋翼并做板级移植”。下表依据均核验于2026-09-21：
| 维度 | 强制条件 | Betaflight | INAV | ArduPilot | PX4 | 证据 |
|---|---|---|---|---|---|---|
| 主机仿真 | 必须有官方路径 | 有 | 有 | 有 | 有 | 各项目开发文档与仿真入口 |
| 独立应用示例 | 必须有固定版本、源码和运行命令 | 没有采用本专题所需的同类教学路径 | 没有采用本专题所需的同类教学路径 | 有库示例，但流程不同 | 有hello示例 |
PX4 v1.17 hello源码 |
| 发布订阅教学 | 必须有官方消息接口说明 | 不满足本次特定教学要求 | 不满足本次特定教学要求 | 架构不同 | uORB明确 | PX4 uORB |
| 自主多旋翼 | 后续需要 | 非主要教学路径 | 支持 | 支持 | 支持 | 各项目官方功能与载具文档 |
| 板级移植资料 | 后续需要 | 有目标配置 | 有目标配置 | 有AP_HAL与板级支持 | 有独立移植指南 | PX4移植指南 |
| 本次结论 | 所有强制条件通过 | 淘汰 | 淘汰 | 淘汰 | 选择 | 固定到PX4 v1.17.0 |
这里不使用简单总分，因为“目标板不受支持”“许可证不满足发布计划”等强制条件不能被其他高分抵消。
前三个项目被“淘汰”只针对这份需要官方PX4式模块和发布订阅教程的教学任务，不表示它们不适合其他飞行任务。若任务改为5英寸人工操控练习机，强制条件也会改变，Betaflight就可能成为优先候选。
常见错误¶
因为界面熟悉就选择固件¶
配置器只显示固件已经实现的能力。开发者最终需要理解源码、板级目标、消息和测试体系。
因为处理器相同就交叉刷写¶
处理器相同不代表时钟、闪存布局、引脚、电源控制、传感器和引导加载程序相同。
先写功能，再考虑上游¶
若计划长期维护，应在设计前阅读贡献规则、代码风格、测试要求和版本兼容策略。大面积偏离上游会持续增加合并和升级成本。
把仿真支持理解为所有硬件行为都已验证¶
软件在环可以验证大量逻辑，但不能证明真实总线时序、电源、传感器噪声、执行器和射频链路正确。
检查理解¶
- 为什么不能只按“功能最多”选择飞控项目？
- 同一飞控板为什么可能只支持部分开源固件？
- 平台比较为什么必须包含许可证和维护责任？
- 软件在环通过后还缺少哪些硬件证据？
- 哪些信息共同定义了“实际使用的固件版本”？