核心架构对比：PX4的微对象模型 vs ArduPilot的调度器模型

聊到飞控架构，很多人第一反应是「不就是跑个实时任务嘛」。其实不然。我这些年折腾过不少飞控板，从最早的APM 2.5到现在的Pixhawk系列，最深的感触是：架构决定了你能飞多稳，也决定了你改代码时有多痛苦。

这一章，咱们就掰开揉碎看看PX4和ArduPilot在核心架构上的差异。说白了，就是两个团队对「飞控软件该怎么组织」这件事，给出了完全不同的答案。

2.1 两种哲学：模块化 vs 大循环

先看一张整体对比图，你心里就有谱了。

2.2 PX4 的微对象模型：模块化到极致

PX4 的架构，我习惯叫它「乐高积木」。每个功能都是一个独立模块，模块之间通过 uORB 消息总线通信。你想想看，传感器模块只管发数据，导航模块只管收数据做计算，控制模块只管收指令输出控制量——谁也不依赖谁的具体实现。

核心思想：每个模块是一个独立的进程/线程，通过 uORB 发布和订阅消息。模块之间没有直接函数调用，只有消息传递。

举个例子，传感器数据怎么走？

// 传感器模块发布数据
struct sensor_accel_s accel_data;
orb_publish(ORB_ID(sensor_accel), accel_pub, &accel_data);

// 导航模块订阅数据
int accel_sub = orb_subscribe(ORB_ID(sensor_accel));
orb_copy(ORB_ID(sensor_accel), accel_sub, &accel_data);

我在一个物流无人机项目里吃过这个架构的甜头。当时需要换一个更高级的IMU，传统做法得改一堆代码。但在PX4上，我只需要写一个新的传感器驱动模块，发布同样的uORB消息就行。其他模块完全不用动，直接订阅新消息。嗯，这就是模块化的威力。

2.2.1 模块生命周期管理

每个模块都可以独立启动、停止、重启。这在调试时太爽了。

启动：模块名 start
停止：模块名 stop
状态查看：模块名 status

比如你怀疑姿态估计有问题，直接 ekf2 stop 停掉，换个算法模块上去测试。这在ArduPilot里可做不到——你得重新编译整个固件。

2.2.2 uORB 消息总线的设计哲学

uORB 本质上是一个发布-订阅的消息中间件。我刚开始接触时觉得多此一举，直接函数调用多快啊。后来发现，正是这层「间接」带来了巨大的灵活性。

特性	说明	实际价值
松耦合	发布者不知道谁在订阅	可以随时增减模块
多对多	一个消息可被多个模块订阅	日志、地面站、控制同时使用
实时性	基于共享内存，零拷贝	延迟低至微秒级
可扩展	新增消息类型不影响现有代码	快速原型验证

我的建议：如果你做多旋翼之外的载具（比如VTOL、无人船），PX4的模块化架构会让你少掉很多头发。每个载具类型只需要换对应的控制模块和混控器，其他部分复用。

2.3 ArduPilot 的调度器模型：简单就是力量

ArduPilot 走的是另一条路。它用一个主循环，按调度表顺序执行各个任务。说白了，就是一个大 while 循环里，按时间片轮转。

我最早接触APM时，觉得这方式太「土」了。但后来在资源受限的硬件上跑飞控时，才明白这种设计的精妙——它不需要操作系统，不需要复杂的进程管理，一个STM32F103就能跑得飞起。

核心思想：所有任务在同一个线程中按优先级和时间片执行。调度表决定了每个任务的执行频率和顺序。

看一段调度器的核心代码，你就懂了：

// AP_Scheduler 核心逻辑（简化）
void Scheduler::run()
{
    uint32_t now = micros();
    for (uint8_t i = 0; i < _num_tasks; i++) {
        if (now - _last_run[i] >= _tasks[i].interval_us) {
            _tasks[i].function();  // 执行任务
            _last_run[i] = now;
        }
    }
}

每个任务有一个固定的执行间隔。比如姿态控制在 400Hz，导航在 100Hz，地面站通信在 50Hz。调度器会保证每个任务按自己的节奏运行。

2.3.1 调度表的配置方式

ArduPilot 的调度表是静态定义的，写在代码里。想改执行频率？得改代码重新编译。

// 调度表定义示例
const AP_Scheduler::Task Scheduler::scheduler_tasks[] = {
    { &failsafe_check,      1,    1000 },  // 1ms
    { &ahrs_update,        10,    2000 },  // 10ms
    { &attitude_control,   20,    3000 },  // 20ms
    { &gps_update,        200,    5000 },  // 200ms
};

每个任务有三个参数：函数指针、执行间隔（单位是调度器的基本时间片）、预估执行时间。调度器会根据这些参数决定是否在本次循环中执行该任务。

我曾经踩过的坑：有一次在ArduPilot里加了一个新的传感器处理任务，没注意预估执行时间设得太短。结果主循环超时，导致姿态控制任务被延迟，飞机在高空开始剧烈抖动。后来排查了两天才发现是调度表配置问题。所以，预估执行时间一定要留余量。

2.4 两种架构的实战对比

说了这么多理论，咱们看看在实际项目中怎么选。

对比维度	PX4 微对象模型	ArduPilot 调度器模型
代码复杂度	较高，需要理解uORB和模块机制	较低，一个main函数就能看懂
调试难度	可单独调试模块，但需要理解消息流	整体调试，但代码路径清晰
硬件适配	需要RTOS支持，对MCU要求高	裸机也能跑，适合低端MCU
扩展性	极强，新增功能不影响现有模块	一般，新增任务需修改调度表
实时性保障	依赖RTOS调度，模块间有消息延迟	确定性高，执行顺序可预测
社区生态	偏向学术和工业应用	偏向创客和商业应用

2.5 我的选型建议

做了这么多年飞控，我总结了一个简单的判断标准：

选 PX4 的场景：
- 你在做研究，需要频繁换算法模块
- 你的载具比较特殊（VTOL、无人车、无人船）
- 你用的是高性能硬件（STM32F7/H7 或以上）
- 团队有多人并行开发不同模块
选 ArduPilot 的场景：
- 你刚开始学飞控，想快速上手
- 你的硬件资源有限（STM32F1/F4）
- 你需要确定性高的实时行为
- 你主要做标准多旋翼或固定翼

个人经验：如果你不确定选哪个，先学ArduPilot。它的调度器模型更容易理解飞控的整体流程。等你能把ArduPilot的调度表背下来，再去看PX4的uORB，你会发现很多设计思路是相通的。

架构没有绝对的好坏，只有适不适合。PX4的微对象模型像瑞士军刀，功能强大但需要时间掌握；ArduPilot的调度器模型像一把菜刀，简单直接但能解决90%的问题。你想想看，你现在的项目更需要哪种？

📚 课程目录

核心架构对比：PX4的微对象模型 vs ArduPilot的调度器模型

2.1 两种哲学：模块化 vs 大循环

2.2 PX4 的微对象模型：模块化到极致

2.2.1 模块生命周期管理

2.2.2 uORB 消息总线的设计哲学

2.3 ArduPilot 的调度器模型：简单就是力量

2.3.1 调度表的配置方式

2.4 两种架构的实战对比

2.5 我的选型建议