一次飞行任务拆解 ArduPilot 开源飞控系统：从自检到返航全解析
【免费下载链接】ardupilotArduPlane, ArduCopter, ArduRover, ArduSub source项目地址: https://gitcode.com/GitHub_Trending/ar/ardupilot
ArduPilot 是一套开源飞控系统，同一份代码能驱动多旋翼、固定翼、地面车、水下机器人和天线跟踪器。想读懂它的内核，与其平铺直叙地翻目录，不如跟着一次真实飞行任务走一遍：从上电自检、解锁起飞，到自主巡航、异常自救，最后降落复盘。每个阶段背后都压着一块明确的代码，本文就把架构知识挂到这些阶段上。
上电自检：系统凭什么敢确认"能飞"
按下电源那一刻，固件先做一轮"体检"：IMU 是否在正常出数、气压计是否锁定高度、GPS 是否拿到三维解、罗盘航向是否稳定、电池电压是否在阈值内。任何一项不达标，解锁请求都会被拒绝。这套预检逻辑分散在各平台的启动与解锁代码里，多旋翼的入口就是 ArduCopter/ 下的解锁实现，配合 libraries/AP_Arming/ 的通用解锁框架。
设计动机很直接：电机一旦上电就可能伤人，所以"敢不敢转"必须先于"会不会转"。自检通过只是拿到解锁资格，真正解锁后还有持续监控接手。
姿态是怎么"算"出来的：EKF 融合多路传感器
控制器需要的是一个稳定可信的姿态与位置估计，而原始传感器要么噪声大、要么互相矛盾。扩展卡尔曼滤波（EKF）在这里做仲裁：以 IMU 的陀螺和加速度计提供高频角运动，GPS 给水平位置与速度，气压计给垂向高度，罗盘给航向基准，再按各自噪声水平加权融合。ArduPilot 当前主力实现放在 libraries/AP_NavEKF3/。
关键不在于"用了哪些传感器"，而在于滤波器会动态判断谁可信：IMU 漂移偏大时压低它的权重，GPS 在城市峡谷里跳变时自动降低其贡献。这种自适应正是系统能扛住现实噪声的原因——姿态环因此始终拿到的是一组平滑、低延迟、被交叉验证过的估计值。
解锁起飞：控制环如何把目标变成动作
估计值到位后，控制链分两段。内环是姿态环：把期望姿态和当前姿态的偏差，经 PID 修正成每个执行器的输出。多旋翼的四个（或更多）电机差速产生俯仰、横滚、偏航力矩，由 libraries/AP_Motors/ 把指令翻译成 PWM；固定翼则不同，它不能靠电机差速，而是靠舵面，并且高度与空速是耦合的——这正是 TECS 总能量控制要解决的问题：把"想飞多高"和"想飞多快"拆成能量分配，再协调升降舵与油门，libraries/AP_TECS/ 负责这部分。
同一个控制框架能同时伺候两类飞行器，靠的是把"机体响应模型"和"控制律"分开。姿态控制器 libraries/AC_AttitudeControl/ 只关心"怎么稳"，机体差异下沉到底层执行器。
换新飞控板：为什么不用重写控制算法
这是 ArduPilot 最核心的解耦。上层算法只面向"硬件抽象层"（HAL）的通用接口读写，比如"读一路 UART""发一路 PWM""挂一个 I2C 设备"，从不关心背后是哪块芯片。HAL 本身又分通用定义与各平台实现，libraries/AP_HAL/ 提供统一契约，libraries/AP_HAL_ChibiOS/ 则用 waf 构建系统把契约落到具体 MCU 上。
真正适配一块新板子，主要工作在硬件定义（hwdef）里：声明哪些引脚接 GPS、哪些走 CAN、哪个串口给数传、电源与 BEC 怎么配。仓库里已经沉淀了数百套 hwdef，新板照葫芦画瓢即可。像 CM4Pilot 这种双板设计，更把实时控制（FMU）和算力密集任务（计算模块）物理拆开，用 CAN、USB、UART 互联，控制与数据处理各占一颗芯片，互不抢占。
出问题时系统如何自救
安全不是某个单一功能，而是一组分层防线。第一层是"主循环心跳"：控制主循环若卡住，failsafe 检测到看门狗时间戳超时就直接停桨，多旋翼的实现就在 ArduCopter/failsafe.cpp。第二层是地理围栏，libraries/AP_Fence/ 在飞出预设范围时触发返航或降落。第三层是任务级高级故障安全，libraries/AP_AdvancedFailsafe/ 针对信号丢失、电池低电量、高度/速度异常等场景给出预设动作，比如丢数传就自动 RTL。
支撑这一切的是调度器 libraries/AP_Scheduler/：它按固定节拍给各任务发"该干活了"的令牌，姿态控制这类高频任务优先，日志、遥测等低频任务在空隙里跑。正因为任务都受控调度、节拍可预测，心跳检测才敢在"主循环真卡死"和"只是正常让出 CPU"之间做出可靠判断。
没有真机时怎么验证：SITL 软件在环
改算法最怕"逻辑对但飞起来不对"。SITL（软件在环）把传感器、执行器、机体动力学都仿真出来，让固件跑在 PC 上却像在真机上飞行：libraries/SITL/ 提供了大量仿真设备，GPS、IMU、电池、数传乃至碰撞模型都有。配套自动化测试在 Tools/autotest/ 下，sim_vehicle.py 拉起一个仿真飞行器并按脚本跑场景，CI 对每次提交做回归。
流程是：本地改代码 → SITL 跑通目标行为 → 自动化测试确认无回归 → 再谈实飞。这套闭环让"传感器融合与 EKF 姿态估计""硬件抽象层适配""SITL 软件在环仿真"这三件事能在不碰硬件的前提下被反复验证。
从哪切入：按你的场景选入口
| 你的场景 | 先做的动作 | 入口目录 |
|---|---|---|
| 想搞懂姿态/位置怎么估出来 | 读 EKF 核心与融合逻辑 | libraries/AP_NavEKF3/ |
| 要适配一块新飞控板 | 照现成 hwdef 改引脚与总线 | libraries/AP_HAL_ChibiOS/hwdef/ |
| 要改多旋翼/固定翼控制律 | 看姿态控制器与 TECS | libraries/AC_AttitudeControl/、libraries/AP_TECS/ |
| 想在无硬件下验证改动 | 用脚本拉起仿真跑场景 | Tools/autotest/、libraries/SITL/ |
【免费下载链接】ardupilotArduPlane, ArduCopter, ArduRover, ArduSub source项目地址: https://gitcode.com/GitHub_Trending/ar/ardupilot
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
