1. 移植前必须想清楚的事先别急着改代码在Ardupilot里做硬件移植很多人一上来就冲进hwdef.dat文件里改引脚或者直接把BootLoader源码拉下来编译结果往往是在烧录环节卡住反复变砖几次才回头补基础概念。这个坑我自己踩过所以文章开头先给所有打算动手的人泼一盆冷水硬件移植不是改配置而是整条链路的重构固件、引导程序、硬件电路、编译环境四者必须同时对齐任何一个环节想当然都会在后续排查中付出成倍的时间。先解释一下Ardupilot固件的整体构成。以常见的ChibiOS版本为例固件源码里跟硬件直接相关的部分主要是libraries/AP_HAL_ChibiOS/hwdef目录下的各板级定义文件其中核心就是hwdef.dat。它不是一个“配置文件”这么简单而是一份被构建系统解析的源文件定义了MCU型号、时钟树、外设映射、存储布局、PWM输出、传感器总线、电源管理、甚至BootLoader本身的行为。换句话说你在hwdef.dat里写的每一行最终都会被加工成C语言头文件参与固件和引导程序的编译。BootLoader在Ardupilot体系里承担的角色也不只是“把固件拷进Flash”这么简单。对于STM32平台Ardupilot使用自己的ChibiOS引导程序它在上电后负责检查是否有固件更新请求通常通过USB或UART进入、校验固件合法性、管理App分区的写入然后把控制权交给飞控固件。这套BootLoader和固件是成对出现的BootLoader放在Flash起始地址固件App放在BootLoader之后的分区地址两者的链接地址、分区大小、CRC校验方式都必须匹配。所以在移植过程中必须把BootLoader当作整个系统的一部分来对待否则很容易出现“固件编译成功但刷进去飞控没反应”的诡异问题。这篇文章面向的读者是那些已经用过Pixhawk等现成飞控、对Ardupilot编译有一定了解、正准备把自己设计的飞控硬件跑起来的人。内容会围绕一条主线展开从评估硬件选型到动手修改hwdef.dat再到编译出固件、处理BootLoader最后到常见故障的排查。每一部分都会给出可以直接参考的配置片段和命令同时把我实际操作中遇到过的“坑”标注出来希望能帮你少走几段弯路。2. 硬件选型和评估哪些板子适合移植哪些要绕道2.1 评估一个目标板能不能跑Ardupilot的几个硬指标不是所有MCU都能跑Ardupilot。进入ChibiOS时代之后Ardupilot官方维护的硬件平台集中在STM32F3/F4/F7/H7系列以及部分NuttX时代的旧平台如Pixhawk 1用的是STM32F427。如果你打算移植一个完全自研的板子首先要确认MCU的资源是否满足最低要求。以最常见的STM32F405/F427为例实际项目里必须满足的基本条件有几个Flash容量至少1MB512KB会非常紧张固件编译出来动辄七八百KBSRAM至少192KB以上这样才能跑得动Ardupilot三四个主要任务和日志缓存至少要有2个以上的硬件UART一个用于MAVLink数传一个用于GPS或者调试至少1个硬件I2C或SPI总线用于传感器连接如果要做多旋翼或固定翼的PWM输出至少要有8路以上的定时器通道并且这些通道要能映射到板子的物理引脚上。这里有一个很容易被忽略的点Ardupilot对MCU的“外设资源”要求其实是刚性的特别是DMA通道和定时器。因为Ardupilot的PWM输出在ChibiOS架构下大量依赖硬件定时器和DMA如果目标MCU的DMA资源不够或者定时器通道被其他功能占用最终会出现某些电机无法解锁、PWM输出波形错误这类问题。所以选型阶段就要把MCU的datasheet打开把每个定时器的通道数和DMA映射表理一遍不要等到焊好板子再发现引脚冲突。2.2 选择官方评估板作为参考设计的好处如果你不是从零设计飞控而是想在一个现成的开发板上把Ardupilot跑起来比如某些STM32F407核心板最省力的路径是找一个硬件结构最接近的官方板子作为“模板”。Ardupilot在hwdef目录下维护了上百个板级配置从Pixhawk 1到Pixhawk 4、Cube系列、mini系列覆盖了绝大多数外设排布方式。具体做法是先把目标板子的原理图吃透看看MCU型号、晶振频率、LED接在哪个引脚、USB使用哪对D/D-、传感器走哪条总线然后去hwdef目录下找最接近的官方配置作为起点。比如你用STM32F405的板子可以参考Pixhawk1的hwdef如果是F427可以参考Pixhawk1的F427版本或者CubeBlack。用官方配置做起点好处是编译链路和链接脚本大概率可以直接复用你只需要改引脚映射、外设启停、存储分区这三块能大幅减少初期的工作量。我见过不少人非要自己从零写hwdef结果把启动文件和链接脚本也一起重写最后卡在编译报错上。Ardupilot的构建系统设计得已经很“傻瓜”了它希望你只关心板级差异而不是把整个系统重造一遍。所以这里给个建议第一次移植先找一个参考板在它的基础上改成功了再考虑精简和优化。3. hwdef.dat深度拆解一行配置背后的完整逻辑3.1 文件结构概览hwdef.dat虽然叫“dat”但它本质上是一份由Python脚本解析的配置描述文件。构建时Tools/autotest和libraries/AP_HAL_ChibiOS/hwdef/scripts下的脚本会读取这份文件最终生成一个名为hwdef.h的头文件里面包含了所有宏定义、引脚映射关系和编译选项。所以你在hwdef.dat里写的内容其实是在“声明”飞控硬件长什么样。一份典型的hwdef.dat内容大致可以分为四个区域MCU与时钟树配置、Flash与RAM布局、外设使能与引脚映射、PWM输出与传感器总线。我建议严格按照这个顺序往下读、往下改而不是跳着看因为后面的配置有时依赖前面的宏定义。以下是一段带注释的hwdef.dat片段基于某个STM32F405板子摘取了核心部分# MCU型号与Flash大小 MCU STM32F405RE # 外部晶振频率 OSCILLATOR_HZ 8000000 # Flash布局BootLoader占用前32KB固件App从0x08008000开始 FLASH_BOOTLOADER_LOAD_ADDR 0x08000000 FLASH_BOOTLOADER_RESERVE_START 0x08000000 FLASH_BOOTLOADER_RESERVE_END 0x08008000 # 外设使能 STM32_UART 1 USART1 STM32_UART 4 UART4 # SPI总线IMU放在SPI1上 STM32_SPI 1 SPIDEV_1 SPIDEV_IMU1 SPI1 DEVID1 0 0 # PWM输出定时器TIM1的四个通道 STM32_PWM TIM1 CH1 PA8 STM32_PWM TIM1 CH2 PA9 STM32_PWM TIM1 CH3 PA10 STM32_PWM TIM1 CH4 PA11这段配置虽然简短但它体现了hwdef.dat的几个核心机制MCU声明、晶振频率、Flash分区、串口和SPI外设开启、PWM引脚映射。每一类配置的作用下面逐步展开讲。3.2 时钟树移植后“串口乱码”的根源移植中最常遇到的第一个坑就是串口输出乱码。很多人把锅甩给“线路干扰”但十有八九是时钟树配置错了。Ardupilot的ChibiOS版本会根据OSCILLATOR_HZ和MCU型号自动计算PLL分频倍频参数如果晶振频率写错比如实际是8MHz晶振却写成25MHz系统主频会跑偏波特率自然就不对。我之前移植一块板子时原理图上画的是8MHz晶振但抄网上模板时抄了个25MHz配置结果USB能识别但串口全是乱码折腾了一整天才定位到这一行配置。所以拿到新板子第一件事用示波器或频率计测一下晶振实际频率然后严格核对OSCILLATOR_HZ的值。还有个细节STM32F405/F427的USB需要48MHz时钟ChibiOS版本会自动根据PLL配置生成但如果你改过倍频系数一定要确认USB枚举是否正常。USB能识别不一定代表时钟正确但USB识别不了基本上可以先怀疑时钟。3.3 引脚映射GPIO、外设复用和冲突避免hwdef.dat里最经典的配置是STM32_PWM和STM32_GPIO这样的行。每一行的格式基本是“功能 参数 引脚”。例如STM32_GPIO PA0 GPIO_PA0_LED_BOOTLOADER # 把PA0用作BootLoader指示灯 STM32_PWM TIM1 CH1 PA8 # 把PA8用作PWM输出这里需要特别注意的是“同一个物理引脚不能同时被两个功能占用”。Ardupilot在编译时不会帮你检查引脚冲突你把PA0既配置成LED又配置成SPI的片选最后刷进板子通常只是某个功能失效不会报编译错误排查要靠肉眼一条条看配置非常痛苦。所以每次改完hwdef.dat都建议用脚本或者手动搜索一遍每个引脚出现几次把这个动作变成肌肉记忆。引脚映射的另一个问题是“外设复用”的支持情况。ChibiOS的STM32驱动库对每个外设的引脚映射有固定表比如USART1可以复用PA8/PB6/PC4等但不是所有RM0433上列出的复用组合ChibiOS都实现了。你写STM32_UART 1 USART1之后默认的引脚映射可能会选PA9/PA10如果你想用PB6/PB7需要额外指定UART1_TX PB6和UART1_RX PB7。建议在选引脚时就去查ChibiOS的stm32f405xx.h和Ardupilot的pinmap配置确认你想要的映射组合是受支持的。3.4 传感器配置SPI与I2C总线的选择逻辑现代飞控的IMU多数走SPI总线而气压计、罗盘常常走I2C。hwdef.dat里通过SPIDEV和I2C配置来声明传感器设备。以IMU为例SPIDEV_IMU1 SPI1 DEVID1 0 0这行的含义是把“SPI1总线、片选序号0”注册为IMU1传感器设备其中DEVID1是设备编号后面的0 0分别是片选GPIO Bank和Pin。实际使用时你需要在libraries/AP_InertialSensor/AP_InertialSensor_BMI270.cpp或类似源文件里配置传感器驱动与设备ID的对应关系或者通过BoardConfig和hwdef.dat里的宏让驱动识别设备。这个环节最常遇到的问题是SPI设备的CS引脚选错或者片选极性配置反了。Ardupilot的SPI驱动默认是低有效片选如果你的硬件设计是高有效就要在驱动层面调整否则传感器读取会一直失败。还有一点多个SPI设备共用一个SPI总线时每个设备的CS引脚必须不同且DMA通道尽量分开否则会出现在高负载时传感器数据偶尔丢失的问题。I2C外设的配置逻辑类似Ardupilot会自动扫描I2C总线上的设备所以你只要确保I2C总线被正确使能并且总线上拉电阻阻值合适一般4.7k欧姆设备就能被识别到。如果I2C设备扫描不到优先检查上拉电阻和地址冲突很多新人会忽视地址冲突结果多个设备挂同一地址导致总线上的数据错乱。4. 编译与烧录从hwdef.dat到固件出包的完整链路4.1 编译环境的搭建与版本选择Ardupilot的编译系统经历了从Make到Waf的迁移目前ChibiOS版本推荐使用Waf。在Ubuntu 20.04或22.04上先安装基础依赖sudo apt-get update sudo apt-get install git python3-pip python3-setuptools python3-dev sudo apt-get install build-essential gcc-arm-none-eabi pkg-config libtool然后拉取源码并初始化子模块git clone https://github.com/ArduPilot/ardupilot.git cd ardupilot git submodule update --init --recursiveArdupilot的Python依赖里可能包含原生扩展官方建议用Tools/environment_install/install-prereqs-ubuntu.sh脚本一键装完省心很多。这里给一个重点提醒不要用系统自带的老版本gcc-arm-none-eabi有些旧版编译器不支持某些新的编译选项可能会导致链接失败。推荐从ARM官网下载10.3版本解压后把bin目录加入PATH。4.2 一条waf命令背后的编译流程Waf的用法先记住两个命令./waf configure --board 你的板子名称 ./waf build --target bin/arducopter--board参数对应的是libraries/AP_HAL_ChibiOS/hwdef/板子名称目录如果这个目录不存在Waf会直接报错。所以写好了hwdef.dat之后先手动创建一个以板子命名的目录比如hwdef/MyF405然后把hwdef.dat放进去。构建过程大体分三步第一步Python脚本解析hwdef.dat生成hwdef.h和外围设备配置头文件第二步ChibiOS的Makefile和链接脚本根据这些头文件编译内核和外设驱动第三步编译Ardupilot各传感器库和飞行控制主程序链接成最终固件。整个过程是自动的但你如果在hwdef.dat里写入了不支持的配置选项报错信息可能很隐晦比如“undefined reference to xxx”这时候第一反应应该是回hwdef.dat里找问题而不是去改C代码。编译完成后固件输出在build/板子名称/bin/arducopter四旋翼或者arduplane等名称取决于你指定的target。这里面有一个很容易踩的坑如果你在配置hwdef.dat时没有指定ENABLE_BOOTLOADER之类的选项编译出来的bin文件可能不包含BootLoader区域它只能通过已有的BootLoader加载不能直接从零烧录。后面会专门讲BootLoader怎么处理。4.3 烧录的几种路径和方法固件编译出来之后烧录方式取决于你的硬件当前处于什么状态。第一种情况板上已经有官方的Ardupilot BootLoader那么最简单的方式是按住板子的Boot按钮插上USB用QGroundControl或Mission Planner上传固件电脑上会看到一个串口设备地面站会自动进入BootLoader升级模式选择你刚编译出来的固件即可。这种方式不需要额外的烧录工具适合已经跑过官方固件的板子。第二种情况板载还没有BootLoader或者BootLoader已经被你刷坏了那就要借助ST-Link或J-Link这类调试器把BootLoader的elf或hex文件直接下载到Flash的起始地址。在Linux下可以用openocd配合ST-Link完成烧录。烧录前务必确认调试器和目标板的SWD接线正确一般只需要SWDIO、SWCLK、GND三根线。第三种情况如果你在移植初期想快速验证固件能否运行也可以先用调试器直接烧录整个固件固件本身自带App链接地址但这样有个风险一旦重启如果没有BootLoader接管下次升级固件只能再拿起调试器。所以我的建议是第一次烧录就先把BootLoader和固件一起处理好后面调试会轻松很多。5. BootLoader全流程解析从烧写到启动一个都不能错5.1 BootLoader来源选择Ardupilot的BootLoader有两种来源。第一种是使用官方预编译好的BootLoader文件这些文件通常在Tools/bootloaders目录下命名格式类似于板子名称_bl.bin。如果新板子的硬件设计和某个官方板子几乎一致直接拿对应的预编译BootLoader烧录就行。第二种是自行编译BootLoader。在hwdef.dat目录下用Waf构建时指定--bootloader选项即可生成对应的BootLoader固件./waf configure --board MyF405 --bootloader ./waf build --target bootloader编译产物是个bin文件里面包含了ChibiOS引导程序。这个BootLoader的编译过程与固件编译共用hwdef.dat所以它会自动匹配Flash分区大小和串口/USB外设的定义。自行编译的好处是灵活性高但也意味着你需要保证hwdef.dat里关于BootLoader的配置是正确的——比如BootLoader指示灯引脚、进入刷写模式的按键引脚、串口重定向等。5.2 BootLoader启动流程上电后到底发生了什么Ardupilot的BootLoader启动流程可以概括为下面几步第一步MCU上电BootLoader从Flash起始地址开始执行。它会初始化时钟树和最小外设至少包括LED、USB或某个UART方便你进入刷写模式。第二步BootLoader检查“是否需要进入刷写模式”。这里的触发条件通常是检测到特定按键按下或者USB设备的DTR信号被地面站拉高。实际使用中Mission Planner上传固件前会自动发送请求进入BootLoader的命令BootLoader收到后就会停在等待固件的状态。第三步进入刷写模式后BootLoader与地面站建立通信接收新的固件数据写入到App分区。写入过程中会做CRC校验写入完成后还会尝试跳转到App地址执行。第四步如果没有检测到进入刷写模式的请求BootLoader会直接跳转到App分区的起始地址执行飞控固件。这里有个需要注意的点跳转时BootLoader和App之间的“交接”必须干净包括正确设置栈指针、关闭不必要的中断、重新配置时钟树等否则App在启动早期就会崩溃或死循环。我遇到过一种情况自己编译的BootLoader能正常进入刷写模式但刷完固件重启后飞控没有任何反应串口也没有数据。最后排查发现是BootLoader在跳转到App前没有正确关闭一个外设中断导致App的启动代码在配置外设时被意外打断。这类问题很难靠看代码直接发现通常要配合调试器和逻辑分析仪把BootLoader和App两端的行为都抓出来对比。5.3 BootLoader编译和配置的关键参数hwdef.dat里跟BootLoader直接相关的配置需要着重检查几项时钟和外设初始化部分确保BootLoader阶段只初始化必要的外设尤其是USB。有些板子的USB D/D-引脚没有接上拉电阻导致BootLoader模式下USB枚举不稳定地面站经常识别不到设备。这种问题通常在硬件设计时就要规避但如果板子已经做出来了可以试试在BootLoader里把USB D引脚强制作为普通GPIO拉高模拟设备连接。Flash分区的配置务必和你的链接脚本一致。BootLoader编译时会读取FLASH_BOOTLOADER_RESERVE_START和FLASH_BOOTLOADER_RESERVE_END这个区间必须足够容纳BootLoader代码同时又不能太小不然固件App的起始地址会跟BootLoader重叠刷完固件大概率起不来。还有一个容易被忽略的参数是HAL_BOOTLOADER_BUILD。这个宏在编译BootLoader时会被定义用来告诉代码“现在正在编译BootLoader环境”。如果某个板级配置在这个宏下做了不完整的外设初始化比如跳过某些传感器驱动要确保该宏的处理分支是健壮的否则后续改hwdef时可能把BootLoader环境也带偏。5.4 通过日志和串口输出定位BootLoader问题BootLoader阶段的报错不像运行固件时那么好观察因为地面站此时可能还没建立通信。我的经验是在hwdef.dat里给BootLoader配置一个专用的调试LED把程序执行到关键步骤时用LED闪烁次数来表示状态。比如上电后LED快闪3次代表进入刷写模式慢闪2次代表固件校验失败长亮代表正常跳转。这套方法虽然原始但在BootLoader这种早期环境下往往是最可靠的手段。同时如果你在BootLoader阶段预留了UART调试口输出建议把SERIAL_DEBUG或类似选项打开把BootLoader的启动日志和跳转日志打印出来。这比盲猜要高效得多。在硬件上至少留一组UART的SCK/TX/RX/GND测试点方便调试时飞线连接USB转串口模块。6. 常见问题与排查技巧实录从编译报错到上电无反应6.1 编译阶段的典型报错编译报错虽然烦人但往往是最容易定位的。常见的有这么几类第一类Undefined reference to xxx。这类报错大半是因为hwdef.dat里声明的外设在ChibiOS驱动库中没有对应的实现比如你写了一个STM32_CAN但目标MCU的HAL里没有CAN驱动。解决办法是检查该外设在modules/ChibiOS/os/hal/ports/STM32/STM32F4xx下是否有对应的hal.mcu配置如果没有就先把hwdef.dat里的外设行注释掉。第二类Multiple definition of xxx通常是把同一个引脚或同一个外设声明了两遍比如同时写了STM32_UART 1 USART1和STM32_USART 1 USART1。这类问题用文本编辑器搜索关键字就能查出来。第三类Error: Flash overflow说明固件体积超过了MCU的Flash容量。这时候首先要检查是不是把固件刷错了分区比如FLASH_BOOTLOADER_RESERVE_END设置得过大其次可以考虑裁剪不需要的传感器驱动、减少日志缓冲、关闭不该启用的功能。6.2 上电后的常见现象与排查顺序硬件通电后如果一切正常应该能在设备管理器里看到USB虚拟串口设备或者至少一个串口设备。如果看不到设备我的排查顺序是固定的第一步量供电。用万用表检查主控芯片的3.3V电压是否稳定。不少自研板子的问题由LDO选型不当导致MCU在启动瞬间电流很大电压拉低后导致复位循环。第二步量晶振。用示波器看晶振引脚是否有振荡波形。没有波形MCU根本没有正常运行。第三步用调试器看PC指针。接上ST-Link读MCU的PC寄存器如果停在0x08000000附近说明BootLoader在运行如果是个飞掉的地址说明跳转流程出了问题。第四步检查BootLoader的进入方式。如果接上USB后地面站还是识别不到设备但按着Boot键能进刷写模式问题可能出在固件App的USB驱动配置上而不是BootLoader本身。实际排查中我发现很多“上电没反应”的板子问题出在Reset电路上。Reset引脚如果悬空或者电容接错MCU会一直处于复位状态怎么刷都不会有反应。这个在原理图阶段就要画对。6.3 烧录成功但飞控不识别传感器进入固件运行阶段后另一个高频问题是传感器全部或者部分识别不到。在Mission Planner的MAVLink控制台查看日志时会出现诸如IMU0: no data或者Barometer: not found的报错。这种问题的排查顺序是 先看总线是否使能。打开地面站的参数树看COMPASS_ENABLE、AHRS_EKF_TYPE等参数是否正常如果参数存在说明固件至少没用错板子配置。 再用I2C扫描工具或SPI设备检测工具Ardupilot编译时可以启用DEBUG_BUS之类的选项或者通过SYSID_ENFORCE参数来辅助诊断传感器总线。我习惯先在硬件上给传感器芯片的供电和中断脚测一遍波形确认传感器芯片本身在工作。 最后再回hwdef.dat检查片选引脚和中断引脚是否正确。有时候原理图上默认的上拉/下拉状态没画导致传感器在复位期间被错误使能也会出现死活识别不到的情况。6.4 常见问题速查表下面这个表格是这几轮移植里比较典型的问题与对策建议保存下来对照排查。现象可能原因排查方向解决参考串口乱码晶振频率配置错误用示波器测晶振频率核对hwdef.dat的OSCILLATOR_HZ修改OSCILLATOR_HZUSB识别不到USB D/D-上拉缺失MCU时钟异常测量USB DP/DM波形检查时钟树配置修正USB上拉硬件检查PLL配置刷完固件无反应BootLoader跳转条件未满足或分区重叠用调试器读PC指针查看Flash分区修正跳转代码核对Flash地址固件编译报Flash溢出固件体积过大或保留区设置过大查看编译日志估算分区大小裁剪功能缩小保留区IMU无数据SPI/I2C总线配置错误CS引脚错误检查CS引脚和总线地址用示波器抓波形修正hwdef配置检查传感器驱动电机无法解锁PWM定时器映射错误或DMA冲突检查PWM引脚是否被其他功能占用重新分配PWM定时器通道7. 从“能编译”到“能飞”移植完成后的验证闭环很多人觉得固件编译通过、BootLoader刷好、传感器全部识别移植就算大功告成了。但实际上这距离“能飞”还有一段路。Ardupilot在启动时会做大量的自检包括传感器方向、加速度计偏差、罗盘干扰、PWM输出校准等每一项都需要认真的地面验证。我的建议是移植完成后先不着急装桨把飞控固定好用USB供电连接Mission Planner进入初始设置界面把加速度计校准、水平校准、罗盘校准、遥控器校准全部做一遍。然后打开扩展调试页面查看翻滚、俯仰、偏航三个轴的IMU数据是否平稳查看罗盘数据是否有异常跳动查看输出的PWM波形是否干净。在这个阶段最容易发现的问题是传感器方向反了或者轴序错了。比如IMU的物理安装方向跟hwdef.dat里定义的轴序不一致会导致飞控在自稳模式下乱摆。解决办法是在hwdef.dat里通过IMU_ACCEL_TOP、IMU_ACCEL_Z_UP等功能换向或者直接改飞行控制器的安装方向参数AHRS_ORIENTATION。千万别觉得“方向不对”是硬件问题就推翻重做很多情况下只是软件层面的轴映射没配好。如果一切正常最后一步是上电缓慢推油门测试观察电机旋转方向是否正确四个电机是否按预期依次解锁。因为PWM定时器通道和电机顺序的软件映射即使引脚配置正确也可能因为HAL层初始化顺序的问题导致通道错位。这一步只能在地面试而且要万分小心我建议一开始把桨叶全部拆掉再推油门。8. 从移植到维护我的几点个人体会Ardupilot硬件移植这件事做到后面你会发现真正消耗时间的不是“写配置”和“改代码”而是排查那些看起来毫无逻辑的硬件和软件交互问题。比如一次偶发的传感器数据丢失可能跟SPI总线的DMA通道冲突有关也可能跟电压跌落有关要定位到真正原因往往需要把硬件、固件、地面站三个维度同时拉通。我自己实际操作中的体会是移植前花三天把硬件原理图、MCU手册、官方参考板配置、ChibiOS的外设支持列表全部读完比移植后再花三周修bug要划算得多。特别是hwdef.dat这个文件它没有严格的语法教程最好的学习方式就是对照官方配置慢慢啃然后把你自己的板子逐行映射进去。最后再分享一个小技巧每次修改hwdef.dat之前用Git建一个分支或者打好tag保持每次修改的粒度足够小这样出了问题可以二分定位。Ardupilot的构建系统是增量编译的但如果你大改引脚映射很多依赖头文件的源文件会全部重编一次编译可能要好几分钟保持修改记录能帮你减少很多无谓的等待和返工。
