1. 项目概述两个开源飞控巨头到底该怎么选做无人机开发这几年我被问得最多的一个问题就是Ardupilot和PX4到底选哪个说实话这个问题没有标准答案但你要是搞不清楚两者的来龙去脉就贸然入坑后面大概率会走很多弯路。这篇是我计划中的“入门系列”第一部分先把两个项目的基本盘讲透——它们是什么、为什么存在、架构上有什么本质差异、开发环境怎么搭、固件怎么编译、仿真怎么跑起来。后续Part 2我会深入写飞控算法层面的细节比如姿态解算、EKF、导航滤波这些。这篇文章适合谁看零基础但打算认真入门飞控开发的学生、准备用无人机做毕设或科研项目的工程师以及那些已经在用某一家固件、却始终对另一家抱有好奇心的同行。我会尽量把话说明白但假设你至少会基本的Linux操作知道什么是终端和文件权限。如果你连Ubuntu都没装过建议先花一天把系统装好再回来读这篇。直接说结论Ardupilot资历更老社区积累深厚固件代码整体更“皮实”特别适合改装传统航模、无人车、无人船这些载具PX4更工程化代码结构更像现代软件项目在学术圈和科研领域渗透率极高而且对多机编队、视觉避障这类前沿功能支持更友好。注意这里说的是“更”不是“绝对”。两个项目都在飞速进化你完全可能用Ardupilot跑完整个科研项目也可以用PX4做出一台非常可靠的商用无人机。为什么要写“Part 1”因为我在各种群里看到太多人一上来就问“怎么装PX4环境”然后照着某篇博客折腾两天最后编译失败人直接劝退。真正的问题不在于操作步骤难而在于你根本不知道每一步在干什么。所以这篇Part 1把项目背景、环境搭建原理、固件编译流程、仿真工具链全串起来先把地基打牢。提示本文所有操作基于Ubuntu 22.04 LTS这也是目前两个项目官方文档支持最积极的版本。Windows用户建议先装虚拟机或用WSL2但如果你要做真机调试我强烈建议直接上双系统虚拟机在USB设备直通上还是会有不少麻烦。2. 两个飞控项目的来龙去脉与核心差异2.1 Ardupilot从航模社区走出来的常青树Ardupilot的起源可以追溯到2007年它最初是DIY Drones社区的一个开源自动驾驶项目核心开发者是Jan Hirschenberger和Chris Anderson这帮人。如果你对这段历史感兴趣可以去翻翻当年的ArduPilotMegaAPM硬件那是基于Arduino Mega 2560做的飞控板在今天看来性能弱得感人但在当时几乎是草根飞手们唯一能接触到的自动驾驶系统。Ardupilot走到今天已经从一个单固件演变成了一个庞大的“载具家族”ArduPlane固定翼、ArduCopter多旋翼、ArduRover无人车、ArduSub潜水器、ArduBoat无人船以及最近几年重新整理的ArduPilot固件体系。这种多载具支持是它最大的差异化优势之一——你想做一个水空两栖的运载器原型一套Ardupilot代码库就能全部搞定不需要切换整个软件栈。从技术栈来看Ardupilot主要用C编写但它的代码风格整体上偏“经典”大量使用全局变量和宏定义不像现代C项目那样强调封装。对新人来说这既是坏事也是好事——坏处是代码读起来费劲好处是逻辑链路相对直接你沿着一个变量往下追基本能把整条数据流穿起来。Ardupilot的调度器是简单的实时线程加忙等待模式没有用复杂的实时操作系统RTOS这反而让它移植到各种单片机平台时非常容易。从Pixhawk系列到各种F4、F7飞控再到Linux单板计算机Ardupilot的适配性极强。2.2 PX4苏黎世联邦理工学院的工程化产物PX4的出身和Ardupilot完全不一样。它起源于2009年苏黎世联邦理工学院ETH Zurich的一个计算机视觉项目从第一天起就是按照“严谨的软件工程标准”来打造的。PX4在2012年前后和Pixhawk硬件项目合流之后成立了PX4 Autopilot项目至今由Dronecode基金会管理NXP、英特尔这些公司都在背后提供支持。PX4最核心的技术特征是用了一个完整的实时操作系统——NuttX。这带来了两个直接好处第一所有的任务姿态控制、位置估计、导航、通信都是独立线程有明确的优先级调度系统复杂了之后依然能保持稳定第二因为有了操作系统的抽象层PX4的代码结构非常模块化你可以在不干扰其他模块的情况下单独替换掉某个算法模块这种可插拔架构对科研工作极其友好。PX4的代码同样以C为主但它在代码规范、命名空间、接口抽象上要比Ardupilot严格得多。整个系统有清晰的层级驱动层、模块层、应用层。每个核心模块都有独立的uORB消息接口模块之间通过消息总线通信而不是直接互相调用函数。这意味着你在PX4里加一个新的传感器驱动只需要往uORB上发布对应的消息上层模块自动就能感知到不需要修改一堆现成代码。2.3 架构差异决定了什么搞明白了两者的历史和技术栈你才能真正理解为什么它们在实际使用中的表现风格完全不同。Ardupilot的架构核心是一个巨型的“主循环”通过调度器周期性调用各个任务模块任务何时执行、执行多久主要由开发者预先设定。这种模式的好处是简单可控非常适合资源有限的单片机坏处是当系统复杂度上来以后任务之间的耦合会越来越难管理。在Ardupilot上做二次开发很多时间都花在搞清“这个模块在这个阶段有没有被调用”“这个变量在这个线程里会被谁修改”这类问题上。PX4则是典型的分层架构所有外围设备、传感器数据都通过uORB消息总线进行传递。比如惯性测量单元IMU驱动模块把原始数据发布到/vehicle_imu这个主题上姿态估计模块订阅这个主题解算出姿态后再发布到/vehicle_attitude。这里很像ROS的通信模型但没有ROS那么重。这种架构让PX4非常适合做增量开发——你要换一套视觉里程计方案写一个发布姿态消息的新模块就行不用动原来的代码。我建议你在选型时用这个思路来思考如果你的项目偏“整机集成”比如要做一台传统航拍机或者要改装一辆无人车Ardupilot的成熟度会让你省不少心如果你的项目偏“算法创新”比如要做视觉自主飞行、强化学习控制、多机协同PX4的模块化和学术生态会是更好的选择。当然这个分界线并不是绝对的后面Part 2我详细写硬件在环仿真和真机移植时还会再展开讲。3. 从零搭建PX4开发环境Ubuntu 22.04实操全记录3.1 为什么强调用22.04而不是20.04每次有人问PX4环境配置我都要反复强调一件事Ubuntu版本一定要对齐官方支持矩阵。PX4最新主线代码对Ubuntu 22.04的支持做得最到位工具链的预编译二进制、依赖库的版本、Gazebo的兼容性都经过完整测试。你用20.04不是说完全不行但会遇到很多“别人行你不行”的玄学问题比如编译器版本导致编译报错或者Gazebo 9和PX4固件的接口对不上。另一个原因是新版PX4已经逐步转向Python 3.10配套工具链22.04自带的Python和系统包版本与之更匹配不会出现装个包还要去折腾虚拟环境版本的尴尬。Ubuntu 22.04的安装我这里不展开直接说装完之后的关键操作。先换好国内软件源——这一点不做的话后面下载依赖会慢到怀疑人生。这里顺便提醒一句尽量不要在配置环境的中途去切换软件源容易导致缓存不一致部分包装到一半报错最稳的做法是装完系统后第一时间换源然后sudo apt update再继续。注意PX4官方工具链安装脚本会调用GitHub和Python包的海外源国内网络环境下经常卡住。如果你下载速度太慢或连接超时可以考虑给Git配置代理或者在环境变量里临时指定镜像地址。这里不细说网络工具本身每个人情况不同思路是优先保证能够稳定访问官方脚本所需资源。3.2 基础依赖与工具链安装PX4的工具链安装官方提供的最省心方式是一键脚本。你只需要在终端执行git clone https://github.com/PX4/PX4-Autopilot.git --recursive cd PX4-Autopilot bash ./Tools/setup/ubuntu.sh这个脚本会帮你搞定所有依赖包括编译工具链、Python包、Gazebo模拟器、ROS 2相关的工具如果你勾选的话。我实测下来脚本能解决90%的依赖问题但剩下那10%的坑基本都出现在网络上。一个很常见的坑是脚本在安装过程中会从GitHub拉取部分子模块和第三方库国内网络一旦中断脚本不会自动重试而是直接报错退出。解决方案其实很简单看脚本的日志定位到失败的具体步骤手动把那个包装好然后重新运行脚本。注意脚本是有幂等性的已经装好的部分会自动跳过所以重复执行不会造成什么副作用。如果脚本跑完最后一行提示All dependencies are installed恭喜你环境这块已经通关。接下来验证一下编译工具链arm-none-eabi-gcc --version正常的话会输出一个含arm-none-eabi的版本信息这就是交叉编译固件用的编译器。不要慌虽然它会打印不少警告和版权信息只要版本号能出来就行。3.3 首次编译PX4固件从源码到固件文件依赖装好之后先不要急着跑仿真因为仿真和真机固件编译还有区别。我们先把固件编译跑通。PX4支持的板卡非常多默认的编译目标对应的是标准Pixhawk系列。以目前主流的Pixhawk 4为例对应的编译命令是cd PX4-Autopilot make px4_fmu-v5_default这里稍微解释一下px4_fmu-v5是目标板卡的代号Pixhawk 4的主控芯片是STM32F765FMU指的是飞行管理单元后缀default表示默认配置不出意外我们平时做的大部分开发都能用默认配置。如果你手头的是Holybro的Pixhawk 6C那对应的目标就是px4_fmu-v6c_default以此类推。首次编译的时间取决于你的机器性能我多年前第一次在四核老笔记本上编译足足花了将近一小时现在用16核的台式机大概也就三四分钟。编译过程中你会看到终端里刷出大量的编译输出不用被吓到这很正常。中途如果卡住不动先别急可能是CMake在做配置检查给点耐心。如果长时间没有任何输出按CtrlC终止后重试即可。编译完成后固件文件会生成在build/px4_fmu-v5_default/目录下主要产物是.px4后缀的固件文件和.bin后缀的烧录文件。PX4的固件烧录工具支持通过USB连接飞控后一键烧录make px4_fmu-v5_default upload这个命令在连接好飞控后直接执行PX4工具链会自动识别设备并进入烧录模式过程大概几十秒比你用QGroundControl地面站烧还要快而且能看到详细的日志排查问题方便得多。3.4 Ardupilot环境搭建的简化路径如果你对Ardupilot的兴趣更大它的环境搭建相对PX4要轻量一些。最核心的依赖是ardupilot代码仓库和waf构建系统。我推荐的步骤是git clone https://github.com/ArduPilot/ardupilot.git cd ardupilot git submodule update --init --recursive然后安装工具链官方提供了一个安装脚本cd Tools/environment_install ./install-prereqs-ubuntu.sh -y这个过程会帮你把gcc-arm-none-eabi编译器等工具链装好。Ardupilot的编译命令很统一以四旋翼为例cd ardupilot ./waf configure --board Pixhawk4 ./waf copter编译好的固件在build/Pixhawk4/bin/目录下同样可以直接用Mission Planner地面站或MAVProxy烧写进板卡。Ardupilot在编译上大量依赖waf这个Python构建工具它比make配置更简洁但也需要你稍微适应一下它的命令行风格。实际体验下来Ardupilot工具链的出错率确实比PX4低一些但这也和Ardupilot的代码组织方式更单体化有关——它不需要构建那么多独立的模块和驱动。4. 仿真环境搭建不炸机就能练手的核心手段4.1 Gazebo与SITL仿真先理解它在整个链路中的位置说实话真正让我觉得PX4“香”的地方就是它的仿真工具链。虽然Ardupilot也有SITLSoftware In The Loop但PX4和Gazebo的集成深度确实做得更好。仿真的意义不在于“能飞个模拟器”而在于你在不接触真实硬件的情况下把整个飞控逻辑、控制算法、传感器融合模型全部跑起来。PX4的SITL仿真原理是直接在电脑上运行PX4固件的本机编译版本然后通过MAVLink协议与Gazebo模拟器通信。Gazebo负责构建一个虚拟世界里面有相机、激光雷达、IMU、气压计等仿真传感器PX4固件从虚拟传感器获取数据经过姿态估计和控制算法处理再输出电机指令给Gazebo里的虚拟旋翼。这套链路和真机运行几乎没有区别。启动流程分成两步。第一步是启动Gazebo仿真环境cd PX4-Autopilot make px4_sitl gazebo-classic这条命令会编译SITL版本的固件不需要交叉编译直接用本机编译器然后自动打开一个Gazebo窗口里面会有一架默认的Iris四旋翼模型静静躺在地面上。与此同时终端里启动了一个MAVLink实例监听在UDP端口14540上。第二步用QGroundControl地面站连接这个UDP端口你就能像操作真机一样看到姿态、电量、GPS状态并且通过地面站发送起飞指令。注意PX4从较新版本开始已经把gazebo替换成了gazebo-classic作为老版Gazebo的入口同时也在推进新版的Gazebo现名Ignition Gazebo。如果你的PX4源码较新make px4_sitl gazebo可能直接对应新版这点要看官方文档别被网上老教程误导。4.2 QGroundControl与MAVProxy两个地面站的取舍地面站是飞控的外围标配。PX4官方推荐QGroundControl因为它在PX4功能覆盖上做得最完整参数调优、日志回放、任务规划都是全的。Ardupilot那边的默认地面站是Mission Planner功能强劲但界面老气横秋而且Mission Planner只能在Windows上原生运行Linux要用Mono模拟体验一言难尽。我的建议是做PX4开发就用QGroundControl下载对应Linux版本的AppImage文件加上执行权限就能运行chmod x QGroundControl.AppImage ./QGroundControl.AppImage第一次启动后QGroundControl会自动扫描本机的MAVLink连接如果你启动SITL之后它通常会在几秒内自动发现仿真连接。如果没发现手动添加UDP连接、端口填14540即可。这里有个容易踩的坑QGroundControl默认会占用串口设备如果你同时插着USB连接的飞控再启动仿真时可能会冲突。最简单的处理方式是仿真调试时拔掉飞控USB线或者给QGroundControl配置不同的通信端口。这是新手最容易烦的问题之一。如果你不喜欢图形界面或者之后要写自动化测试脚本可以试试MAVProxy。这是Ardupilot社区开发的命令行地面站轻量、脚本化、支持Python扩展。虽然它在PX4上也能用但功能覆盖远不如QGroundControl完整所以我的建议是日常开发用QGroundControl自动化场景再上MAVProxy。4.3 让仿真动起来起飞、悬停、降落全流程演练环境跑通之后我们实际操作一遍。假设你已经启动好了make px4_sitl gazebo-classic并且QGroundControl显示连接正常、GPS模式正常。接下来我习惯用MAVProxy来发指令因为它比在QGroundControl里点按钮更容易理解每个动作的实质。打开新终端连接MAVProxy到SITL的UDP端mavproxy.py --masterudp:127.0.0.1:14550这条命令把MAVProxy作为地面站连上PX4的SITL实例。然后在MAVProxy命令行里输入arm throttle takeoff 10第一行是解锁arm第二行是让无人机起飞到10米高度。你会看到Gazebo里的Iris模型缓缓升空并在接近10米高度后悬停。这期间QGroundControl的姿态仪表也会实时摆动和真机操作完全一致。起飞之后你可以用mode guided指令切换到自动导航模式然后在QGroundControl地图上点击一个目标点飞机就会飞过去。整个链路验证下来你等于已经把飞控的核心工作流程摸了一遍。4.4 Ardupilot的SITL仿真体验Ardupilot的SITL同样非常成熟。它的Simulator进程和飞控代码是集成的运行起来更简单cd ardupilot sim_vehicle.py -v ArduCopter -f gazebo-iris --console --map这个命令会同时打开MAVProxy控制台和地图窗口然后把Ardupilot的SITL对着Gazebo模型跑起来。输入arm throttle和takeoff 10同样能让虚拟四旋翼飞起来。两家SITL对比下来PX4Gazebo在传感器模型和物理引擎上感觉更精细ArdupilotSITL则更方便快速验证固件逻辑、飞行模式和调参效果。没有好坏看你的具体需求。5. 避坑指南与排查技巧我从翻车现场总结的教训5.1 编译过程最常遇到的3个错误先说PX4编译时报错最密集的三个场景。第一个是CMake配置阶段卡住报错信息往往和FetchContent或git submodule有关。这种现象绝大多数是网络问题PX4的CMake会从GitHub上拉取一堆外部依赖比如uavcan、libphonenumber这些库。遇到这个先重试几次看能不能过要是重试一直失败就把子模块手动更新一遍建议单独执行git submodule sync --recursive git submodule update --init --recursive第二个错误是arm-none-eabi-gcc版本不匹配。PX4对交叉编译器版本其实很挑剔太新的编译器可能会因为优化选项变化导致链接失败太老的编译器又不支持某些C11特性。建议严格使用官方脚本安装的编译器版本不要自己去ARM官网下一个最新的。你可以在PX4-Autopilot目录里查看CMakeLists.txt中的编译器版本约束确保环境一致。第三个错误是内存不足导致编译中断。SITL和固件编译都比较吃内存我见过有人2G内存的虚拟机直接编译到一半系统卡死。建议至少8G内存编译时关闭浏览器等大内存应用。要是遇到internal compiler error: Killed基本都是OOM给虚拟机加内存或增大swap即可。5.2 仿真连不上GPS一个让人血压飙升的经典问题很多新手第一次跑QGroundControl连接SITL会发现QGroundControl一直提示“No GPS”飞机的状态是黄色的或灰色的。这是仿真环境下的正常现象不代表系统没跑起来。原因是Gazebo中的GPS传感器默认可能没有正常发布数据或者QGroundControl展示的GPS状态有延迟。最简单的解决方法是在MAVProxy里输入gps status如果显示卫星数为0说明SITL和Gazebo的GPS消息没接上如果卫星数正常就耐心等一会儿QGroundControl的GPS图标通常会变绿。还有一个土办法就是把飞机的初始位置拉到离默认坐标有一定距离的地方模拟GPS定位成功——在SITL启动时指定-L参数即可例如make px4_sitl gazebo-classic PX4_HOME_LAT31.23 PX4_HOME_LON121.47这个参数之后GPS状态大概率立刻恢复正常。5.3 地面站看不到飞机先查端口再查防火墙QGroundControl连不上SITL九成是UDP端口的问题。SITL默认的MAVLink端口是14540用于QGC连接和14550用于MAVProxy连接。如果你启动SITL时有其他程序占用了这些端口连接就会失败。排查方法很简单netstat -tulpn | grep 1454看端口是否处于监听状态。如果端口没问题再看防火墙Ubuntu默认防火墙一般不会拦截本机的UDP通信如果你自己装过ufw并配置过策略记得放行这些端口。另外有一个特别隐蔽的问题如果你同时在真机和仿真之间反复切换QGroundControl会把先前的连接当作“手动连接”导致新的SITL连接显示不了。这种情况在QGroundControl的应用设置里删除旧的“手动连接”项重新扫描即可。5.4 编译速度优化别让每次改代码都等半天随着你对飞控代码的改动越来越多增量编译的效率会直接影响开发体验。我这里给出一个经验参数在PX4-Autopilot目录下有一个.ci文件夹里面放着CI的编译配置我们自己本地编译时可以设定-j参数来指定并行编译的核心数。例如make px4_sitl gazebo-classic -j8-j8表示用8个线程并行编译。如果你不知道自己的CPU有多少核心先跑nproc查看然后给-j设成核心数减2留一些资源给系统本身。另外如果你频繁修改px4模块代码又不涉及底层驱动改动可以单独编译你所修改的模块而不是每次全量编译。比如只编译flight_mode_manager模块可以在PX4-Autopilot/build/px4_fmu-v5_default/目录下执行make flight_mode_manager这能极大缩短编译周期是我日常开发中性价比最高的一招。5.5 硬件选型与下载源避坑建议如果你还没入手真实飞控硬件先别急着买我把Pixhawk系列现状梳理一下。PX4官方参考硬件目前主要有Holybro的Pixhawk 4、Pixhawk 6C和6X以及CUAV、ARK这些第三方兼容板。入门的话我建议买Pixhawk 6C性价比最高双冗余IMU接口齐全跑主流PX4和Ardupilot都毫无压力。至于那些几十块钱的F450套装搭配的杂牌飞控虽然能用但驱动适配和稳定性可能让你哭天喊地。软件下载方面PX4的Gihub仓库大文件很多国内直接clone经常慢你可以考虑用国内镜像加速。Ardupilot的仓库也一样遇到下载慢不要硬扛多试试各种优化的网络方案。6. 下一步学习路线与我的个人体会写到这里Part 1的内容差不多该收尾了。如果你已经顺着文章把PX4和Ardupilot的环境都搭了起来并且亲手完成了一次仿真起飞那你已经跑赢了大部分“收藏从未停止行动从未开始”的人。接下来几天我建议你重点做几件事一是把PX4的主要模块文件夹挨个浏览一遍至少搞清楚src/modules下的mc_att_control、mc_pos_control、ekf2分别是干什么的二是尝试改一两个参数比如把最大起飞高度限制改低然后去仿真里验证改参数对飞行表现的影响三是习惯用listen命令去查看uORB消息这是理解PX4内部通信最关键的手段比如在SITL命令行里输入uorb top就能实时看到各模块之间的消息频率和延迟。对我个人来说玩飞控这些年的最大体会是真正难的不是跑通工具链而是建立对整个系统“数据从哪来、算法在哪里处理、指令往哪里去”的整体认知。飞控不是一个软件而是一整套包含硬件驱动、实时控制、通信协议、人机交互的系统工程。Part 1先把系统框架和环境给你搭好Part 2我们就可以一头扎进代码深处去动那些真正有意思的算法了。最后再分享一个小技巧在PX4-Autopilot/msg目录下你可以看到所有uORB消息的定义文件每一条消息包含哪些字段、用什么单位都写得清清楚楚。很多所谓的大神其实就是靠这些基础文档加上日复一日的实机测试堆出来的经验你也能做到。