📚 课程目录第2章开发环境搭建

2. 开发环境搭建

好，咱们正式开始啃系统架构这块硬骨头。说实话，很多新手一上来就急着调参、试飞，结果遇到诡异问题根本不知道从哪下手——说白了就是没搞懂这玩意儿到底是怎么搭起来的。这一章我带你从上帝视角看一遍ArduPilot的全貌，再聊聊它和PX4那点“恩怨”，最后把代码仓库扒开看看。

2.1 整体架构概览

ArduPilot的架构，我习惯用“三层两线”来记。哪三层？硬件抽象层、飞行核心层、应用层。哪两线？MAVLink通信线和传感器数据线。

核心观点：ArduPilot不是一个大泥球，而是分层解耦的。每一层只关心自己的事，层与层之间通过定义好的接口通信。这带来的好处是——换飞控板？换传感器？换外设？你只需要动最下面那一层，上面的代码基本不用改。

先看一张整体架构图，我亲手画的，你感受一下这个分层逻辑。

你看，最下面是硬件抽象层（HAL）。这一层负责把所有硬件差异给“抹平”了。我在项目里换过Pixhawk 1、Pixhawk 4、Cube Orange，甚至自己画过一块STM32F7的板子——只要把HAL层的驱动写好，上面的代码几乎不用动。这就是分层架构的魅力。

中间是飞行核心层。导航、控制、EKF状态估计、任务调度全在这。这一层是ArduPilot的“大脑”，也是最难啃的部分。我建议你先别急着钻进去，先把外围摸清楚，回头再啃核心。

最上面是应用层。Copter、Plane、Rover、Sub、AntennaTracker，这些“车型”都在这一层。它们共享下面的核心代码，只是把不同的控制逻辑和参数组合起来。

我的习惯：看代码时，先从应用层入口文件（比如 ArduCopter.cpp）开始，一路往下追。这样你能快速理解“一个飞行模式是怎么跑起来的”，而不是一头扎进底层驱动里出不来。

2.2 APM与PX4的区别

这个问题几乎每场技术交流都会被问到。我直接给你一张对比表，看完就清楚了。

对比维度	ArduPilot (APM)	PX4
起源	2009年，DIY Drones社区	2012年，苏黎世联邦理工
架构风格	整体式（Monolithic），但分层清晰	微内核 + 模块化（uORB消息总线）
调度方式	主循环 + 定时器（Scheduler）	多任务 + 实时线程
RTOS	ChibiOS（主流）/ Linux / NuttX	NuttX（主流）/ QURT
代码语言	C++（面向对象风格明显）	C / C++（模块间用C接口）
参数系统	全局参数表（PARAM）	参数 + uORB主题
地面站	Mission Planner / QGC	QGC（官方推荐）
学习曲线	中等，文档丰富	较陡，需要理解微内核概念
典型用户	航模爱好者、工业应用、农业	学术研究、无人机公司、竞速

嗯，这里我要多说两句。很多人问我“到底学哪个好？”我的回答是：看你干什么。

做产品、做项目、做集成——我推荐ArduPilot。它的代码风格更“工程化”，参数系统直观，文档和社区资源极其丰富。我在农业植保项目里，从原型到量产，ArduPilot的成熟度帮了大忙。
做研究、做算法验证、做定制化飞控——PX4的微内核架构更适合你。模块之间通过uORB消息总线通信，你想换掉某个模块（比如EKF），只需要写一个新的模块，注册一下就行，不用动其他代码。

我曾经踩过的坑：有一次我想把PX4的EKF模块移植到ArduPilot里用，结果发现两者的传感器数据流、时间同步机制、坐标系定义完全不一样。折腾了两周，最后还是老老实实重写了接口层。所以，别想着“混用”，选一条路走到黑。

2.3 ArduPilot的代码仓库结构

好，现在咱们打开ArduPilot的GitHub仓库。你第一次看到那个目录结构，可能会有点懵——怎么这么多文件夹？别急，我带你捋一遍。

先看顶层目录，我列了最重要的几个：

目录/文件	作用
`ArduCopter/`	四旋翼/多旋翼应用层代码
`ArduPlane/`	固定翼应用层代码
`ArduRover/`	地面车辆/船应用层代码
`ArduSub/`	水下机器人应用层代码
`AntennaTracker/`	天线跟踪器应用层代码
`libraries/`	核心库，所有共享代码都在这里
`modules/`	第三方模块（如MAVLink协议栈）
`Tools/`	编译工具、调试脚本、自动测试
`mk/`	Makefile构建系统
`wscript`	Waf构建脚本（新版本用）

重点来了——libraries/ 目录。这是ArduPilot的“心脏”。我带你看看里面几个关键子目录：

libraries/
├── AP_NavEKF/          # EKF状态估计（核心中的核心）
├── AP_InertialSensor/  # IMU驱动（加速度计、陀螺仪）
├── AP_GPS/             # GPS驱动
├── AP_Baro/            # 气压计驱动
├── AP_Compass/         # 磁力计驱动
├── AP_AHRS/            # 姿态航向参考系统
├── AC_AttitudeControl/ # 姿态控制
├── AC_PosControl/      # 位置控制
├── AP_Math/            # 数学工具（四元数、矩阵、向量）
├── AP_Common/          # 通用工具类
├── GCS_MAVLink/        # 地面站通信（MAVLink）
├── AP_Scheduler/       # 任务调度器
├── AP_Param/           # 参数系统
└── AP_HAL/             # 硬件抽象层（HAL）

我个人习惯，看代码时先看 AP_HAL/，理解硬件抽象是怎么做的。然后看 AP_Scheduler/，理解主循环怎么跑。接着看 AP_Param/，理解参数怎么存、怎么读。这三块搞懂了，后面的都是“业务逻辑”。

一个小技巧：你想快速找到某个功能对应的代码？直接在仓库里搜参数名。比如你想看“悬停精度”相关的代码，搜 HOVER 或者 HOVER_，参数定义和引用代码全出来了。这比漫无目的地翻目录快得多。

最后，我画了一张代码仓库的“依赖关系图”，帮你理清这些目录之间的调用关系。

你看，这个依赖关系是单向的。应用层调用核心库，核心库调用HAL，HAL调用硬件驱动。反过来不行。这种设计保证了代码的可移植性和可维护性。