2. 开发环境搭建
ArduPilot Plane 的固件规模庞大，涉及 C++ 模板、ChibiOS 实时内核、MAVLink 通信协议以及大量传感器驱动。要在这套代码上做二次开发，第一步不是写飞控逻辑，而是把“能编译、能仿真、能烧录”的工具链搭起来。本节围绕 Ubuntu 与 Windows 两条主线，讲清工具链安装、源码获取、编译流程和 SITL 仿真环境配置，并给出常见坑位的排查思路。
一、核心原理：为什么 ArduPilot 需要专用工具链
ArduPilot 的构建系统基于 waf，而不是传统的 Makefile 或 CMake。waf 负责配置目标板、选择 HAL 层、调用交叉编译器，并生成 .apj、.bin、.elf 等固件产物。因此开发环境必须同时满足三个条件：
- 交叉编译工具链：为 STM32 等 ARM Cortex-M 芯片生成机器码，Ubuntu 下通常使用
gcc-arm-none-eabi。 - Python 运行环境：waf、MAVProxy、pymavlink、SITL 仿真器都依赖 Python 3，且对版本和依赖包有明确要求。
- 仿真与地面站：SITL 在主机上模拟飞行动力学与传感器，Mission Planner 或 MAVProxy 通过 UDP/TCP 与仿真器通信。
理解这条“源码 → waf 配置 → 交叉编译 → 固件/仿真可执行文件 → 地面站连接”的链路，后面的安装步骤就不会变成机械照抄。
二、Ubuntu 下的工具链安装与源码获取
Ubuntu 是 ArduPilot 官方最推荐的开发平台。以 Ubuntu 22.04 为例，先安装基础依赖，再克隆源码。注意源码仓库体积较大，建议使用 --recursive 拉取子模块，否则编译时会缺少 ChibiOS、mavlink 等目录。
sudo apt update
sudo apt install -y git python3 python3-pip python3-dev \
gcc-arm-none-eabi g++-arm-none-eabi binutils-arm-none-eabi \
libtool libxml2-dev libxslt1-dev
git clone --recursive https://github.com/ArduPilot/ardupilot.git
cd ardupilot
git submodule update --init --recursive
# 安装 Python 依赖
pip3 install --user -r requirements.txt
pip3 install --user pymavlink MAVProxy如果 git clone 速度慢，可以改用国内镜像或先 git clone 主仓库，再单独更新子模块。源码目录结构中最关键的是 ArduPlane/（固定翼主程序）、libraries/（公共库）、modules/（ChibiOS、mavlink 等子模块）和 Tools/autotest/（SITL 启动脚本）。
三、Windows 下的两种可行路径
Windows 原生编译 ArduPilot 非常麻烦，官方并不推荐。实际工程中有两条路：
- WSL2 + Ubuntu：在 Windows 中安装 WSL2，再装 Ubuntu 22.04，之后完全按 Ubuntu 流程操作。源码放在 Linux 文件系统内（如
/home/user/ardupilot），不要放在/mnt/c下，否则编译速度会明显下降。 - 纯 Windows + Mission Planner：只用于地面站和固件烧录，不做源码编译。Mission Planner 自带固件下载功能，适合只做参数调试和飞行的用户。
usbipd 做 USB 直通，才能把飞控板识别到 WSL 内进行烧录；否则烧录步骤仍需回到 Windows 下用 Mission Planner 完成。四、编译流程与 SITL 仿真配置
编译固定翼固件时，先配置目标，再执行编译。以 Pixhawk 系列（ChibiOS）为例：
cd ardupilot
./waf configure --board Pixhawk6X
./waf plane
# 编译完成后产物位于：
# build/Pixhawk6X/bin/arduplane.apj
# build/Pixhawk6X/bin/arduplane.elfSITL 仿真不需要真实飞控，直接在主机上运行。常用命令如下：
cd ardupilot/ArduPlane
sim_vehicle.py -v ArduPlane --console --map
# 指定起飞点和仿真速度
sim_vehicle.py -v ArduPlane -L CMAC --speedup 1 --console --map启动后，MAVProxy 会监听 udp:127.0.0.1:14550，Mission Planner 选择 UDP 连接即可看到仿真飞机。SITL 默认从 Tools/autotest/default_params/plane.parm 加载参数，修改该文件可以改变仿真初始状态。
| 环节 | Ubuntu 命令/工具 | Windows 对应方案 | 常见问题 |
|---|---|---|---|
| 交叉编译器 | gcc-arm-none-eabi | WSL2 内安装 | 版本过旧导致链接失败 |
| 源码获取 | git clone --recursive | WSL2 内 git | 子模块缺失，编译报 mavlink 找不到 |
| 编译 | ./waf configure + ./waf plane | WSL2 内 waf | board 名称写错，提示未知目标 |
| SITL 仿真 | sim_vehicle.py -v ArduPlane | WSL2 内运行，Windows 连 UDP | 端口被占用或防火墙拦截 |
| 地面站 | MAVProxy / QGroundControl | Mission Planner | UDP 14550 未监听 |
五、案例与误区复盘
一个典型场景是：开发者第一次编译时报 arm-none-eabi-gcc: command not found，原因是只装了 gcc-arm-none-eabi 却未把工具链加入 PATH，或者装的是 gcc-arm-linux-gnueabi（面向 Linux ARM，不是裸机 Cortex-M）。另一个高频问题是 waf configure 通过但 waf plane 报 Python 模块缺失，通常是 pip3 install --user 后没有重新登录，导致 ~/.local/bin 不在 PATH 中。
sudo 运行 waf 或 sim_vehicle.py。这会把构建产物和缓存文件的所有者改成 root，后续普通用户编译时会出现权限拒绝，清理起来非常麻烦。复盘建议：把环境搭建拆成“依赖安装 → 源码拉取 → 编译验证 → SITL 启动 → 地面站连接”五个检查点，每完成一步就做一次最小验证。例如源码拉取后执行 git submodule status，编译后确认 .apj 文件存在，SITL 启动后确认 MAVProxy 控制台能收到心跳包。这样一旦出错，能快速定位是工具链、源码还是网络配置的问题，而不是在整条链路上反复猜测。