PX4 的模块化架构与工程目录解析
PX4 并不是一个传统意义上的'飞控程序'，而是一个基于模块划分的实时系统框架。 其核心设计目标不是算法性能最大化，而是：
在长期演进、多人协作与多机型适配之间取得工程稳定性
因此，理解 PX4，首先必须理解它的模块化架构，其次才是控制算法。
本章从系统结构出发，说明：
- PX4 为什么采用模块化设计
- 模块之间如何协作
- GitHub 工程目录的职责划分
src目录的真实结构与功能边界
一、PX4 模块化架构的设计动机
无人机飞控同时处理：
- 多源传感器输入
- 状态估计
- 飞行模式逻辑
- 多级控制
- 通信协议
- 外设管理
这些功能具有明显特征：
- 更新频率不同（1Hz ～ 8kHz）
- 实时性要求不同
- 开发人员专业不同
- 生命周期不同
如果采用单体程序（Monolithic Architecture），结果通常是：
- 模块强耦合
- 修改风险指数级上升
- 新功能引入困难
- 调试成本持续增长
PX4 的选择是：
拆分职责，让系统通过数据协作，而不是函数调用协作
二、PX4 模块化的核心机制
PX4 模块化由两部分构成：
1、独立运行模块（Module）
每个核心功能都是独立任务，例如：
- 传感器驱动
- EKF 状态估计
- 姿态控制
- 导航模块
- Commander 状态机
模块具备：
- 独立生命周期
- 独立调度
- 可单独启动/停止
换句话说：
PX4 更像一个微型操作系统，而不是应用程序
2、uORB 消息总线（模块通信）
模块之间禁止直接依赖。
通信方式：
发布（Publish） → 订阅（Subscribe）
示例数据流：
IMU → vehicle_imu ↓ EKF2 ↓ vehicle_attitude ↓ Attitude Controller ↓ Actuator Output
模块不知道数据来自谁，只关心数据是否存在。
工程意义：
- 可替换模块
- 降低耦合
- 易于扩展
代价是：
- 消息复制开销
- 调度延迟增加
PX4 用少量性能换可维护性，这是明确的工程取舍。
三、PX4 GitHub 工程整体结构
PX4-Autopilot 根目录并不是随机组织，而是按系统层级划分。
