3. 开发环境搭建
ArduPilot外设驱动的开发与调试，第一步不是写代码，而是把“能编译、能仿真、能连硬件”的环境搭稳。ArduPilot支持Linux、Windows、macOS三类主机，但外设驱动开发最推荐Ubuntu，因为其工具链完整、脚本兼容性最好；Windows则适合以Mission Planner为主、配合WSL2或原生工具链进行开发。本章围绕工具链、源码获取、SITL仿真与HIL准备四条主线展开。
一、核心原理：ArduPilot构建系统的三层结构
ArduPilot的构建体系可以理解为三层：最上层是waf构建系统，负责配置、编译、链接与上传；中间层是板级目标（board）与硬件抽象层（AP_HAL），决定代码面向哪类飞控或仿真平台；最下层是外设驱动与库，如AP_Periph、AP_GPS、AP_Compass等。理解这三层，才能明白为什么同一份源码既能编译出Pixhawk固件，也能编译出SITL可执行文件。
外设驱动开发通常涉及两种目标：一是SITL（Software In The Loop），在PC上模拟飞控运行，便于快速验证驱动逻辑；二是HIL（Hardware In The Loop），真实飞控运行固件，PC模拟传感器或外部设备，用于验证真实时序与总线行为。两者共用同一套源码，但编译目标与运行方式不同。
二、方法流程：从零到可运行的四步法
- 安装基础依赖：Ubuntu下执行官方脚本，Windows下建议启用WSL2并安装Ubuntu发行版，避免路径与权限问题。
- 获取源码：使用
git clone --recursive拉取主仓库与子模块，确保mavlink、gtest等依赖完整。 - 配置与编译：先
./waf configure，再按目标选择./waf copter或--target=AP_Periph。 - 运行与验证：SITL用
sim_vehicle.py启动，HIL则烧录固件后通过串口连接地面站。
# Ubuntu 依赖安装（官方脚本）
cd ardupilot
Tools/environment_install/install-prereqs-ubuntu.sh -y
. ~/.profile
# 源码获取
git clone --recursive https://github.com/ArduPilot/ardupilot.git
cd ardupilot
git submodule update --init --recursive
# 配置与编译 SITL
./waf configure --board sitl
./waf copter
# 启动 SITL 仿真
cd Tools/autotest
./sim_vehicle.py -v ArduCopter --console --map三、案例场景：为AP_Periph外设编译固件
假设我们要开发一个基于STM32的CAN外设节点，使用AP_Periph框架。此时编译目标不是飞控固件，而是--target=AP_Periph，板级选择对应硬件，例如--board=Hitec-Airspeed或自定义板。编译成功后生成.apj文件，通过Mission Planner或uploader.py烧录。验证时，将外设接入飞控CAN总线，在Mission Planner的MAVLink Inspector中观察CAN_FRAME与AP_Periph相关消息，确认节点被识别。
SIM_参数模拟，例如SIM_GPS_TYPE、SIM_COMPASS，无需真实硬件即可验证驱动初始化与数据解析逻辑。四、常见误区与复盘
| 误区 | 现象 | 正确做法 |
|---|---|---|
未加--recursive克隆 |
编译报mavlink头文件缺失 | 补执行git submodule update --init --recursive |
| Windows下直接用原生工具链 | 路径空格、权限、脚本不兼容 | 优先使用WSL2或Ubuntu虚拟机 |
| SITL与HIL混用同一套参数 | HIL下传感器数据异常 | HIL需设置HIL_MODE并关闭仿真传感器 |
| 忽略板级目标 | 编译出的固件无法启动 | 确认--board与硬件一致 |
HIL_MODE已生效，再接入动力系统。环境搭建完成后，建议做一次“最小闭环”验证：SITL能起飞、能解锁、能收到GPS与姿态数据；HIL能通过串口收到SIMSTATE并回传HIL_SENSOR。只有这两条链路都通了，后续外设驱动的调试才有可靠基线。