先说一个结论如果你正在学开源飞控Ardupilot和PX4这两套生态迟早都要碰到。Part 1里我们已经聊过各自的出身、硬件适配范围、MAVLink协议的基础概念也聊了怎么给飞控刷固件、接地面站。这篇Part 2我准备换个方向不重复基础概念而是集中聊聊真正让你头疼的部分选型纠结、环境搭建、编译报错、仿真调试、以及那些网上翻半天也找不到答案的坑。有朋友问我网上教程这么多为什么还是搭不起来PX4的环境我自己也是从“打开虚拟机、装Ubuntu 22.04、然后卡在编译一天”这个阶段过来的。说句实话大部分教程只告诉你“运行这个命令”但没人告诉你“为什么运行这个命令、运行完如果报错怎么办”。所以这篇文章我把那些年踩过的坑、改过的配置、查过的issue全部整理出来当作一个可以反复翻的实操笔记。目标读者是已经了解飞控基本概念、准备自己动手搭建开发环境或者正在两个平台之间纠结的朋友。1. 从“能飞”到“会选”Ardupilot和PX4到底差在哪这部分本来应该在Part 1就细讲但当时只给了轮廓。这里补充一下我自己的理解。很多人纠结选Ardupilot还是PX4其实是在纠结“我接下来要做什么、我的基础是什么、我愿不愿意处理复杂的编译环境”。选型不是看哪边吹得响而是看你的开发场景。1.1 软件架构的核心差异Ardupilot的架构核心是AP_Scheduler调度器和AP_InertialNav这类库化模块。它把所有功能拆成一个个应用模块模块之间通过共享内存、指针和辅助函数直接通信。用惯了单片机开发的人会觉得很亲切因为Ardupilot本质上就是一个大而全的实时嵌入式工程主循环跑调度器调度器按照固定频率调用每个模块的update函数。好处是逻辑简单、调试直观坏处是模块之间耦合比较重想要彻底理解某一套逻辑需要读不少代码。PX4的架构则更偏向学术派。它使用**uORB微对象请求代理**作为核心通信总线所有传感器数据、姿态估计结果、控制指令都以“主题”形式在系统中发布和订阅。比如SensorAccel这个主题发布加速度计数据姿态控制器订阅它进行解算同时日志模块也订阅它往SD卡写数据。这种消息通信机制的好处是模块完全解耦换一个传感器驱动不影响控制逻辑非常适合做模块级测试和多传感器融合研究。代价就是概念门槛高一点刚接触uORB的人很容易绕晕。如果你问我选哪个答案取决于你的长期目标。想快速做出一台能稳定飞行的航拍机或FPV穿越机Ardupilot的Mission Planner地面站更加成熟参数体系也更容易理解。想做科研验证、算法快速原型、或者以后要往自主无人机、视觉导航方向发展PX4配合Gazebo和ROS生态是更顺畅的路径。当然这不是绝对的两者都能做很多事情只是“顺手程度”不同。1.2 脚本、API和开发语言生态Ardupilot除了用C开发核心功能外还支持Lua脚本可以说是一大亮点。你可以不重新编译固件直接在SD卡上写Lua脚本挂载到某个事件上去执行自定义逻辑。比如我想做一个“当飞行器离地高度超过10米且电池电压低于3.7V时自动触发返航”的规则用Lua脚本就可以实现不用改C代码不用重新烧录。PX4这边也同样提供了辅助脚本机制但更吸引人的是它的对外API体系非常完善。官方主推的MAVSDK和配套的PX4-Avoidance库让开发者可以用Python或C在机载计算机上方便地读取状态、发送指令、跑避障算法。很多做物流无人机、巡检无人机的项目都是PX4飞控加NVIDIA Jetson机载电脑上位机跑MAVSDK和深度学习模型下位机跑PX4核心控制。Ardupilot其实也有配套的MAVProxy和DroneKit但对比下来MAVSDK的文档质量和跨语言支持还是好一些。另一个很实际的区别是调参方式。Ardupilot的PID调参主要是通过Mission Planner的“扩展调参”页面改参数后写入飞控、重启生效或者热调整。PX4则支持在QGroundControl里进行“自动调参”起飞后在微调模式下自动测量响应、计算姿态增益。实测下来PX4的自动调参在穿越机这类机动性强的机型上效果还不错但Ardupilot的调参逻辑更透明手动可以控制得更细。对喜欢“知其所以然”的人我建议先手动把Ardupilot的PID搞懂再去看PX4的自动调参会更容易理解它在干什么。1.3 社区支持和文档成熟度选平台的重要因素是“遇见问题时你能找到答案”。Ardupilot社区讨论区discuss.ardupilot.org的历史帖子非常多很多十年前的问题至今仍然有效搜索时加上“site:discuss.ardupilot.org”能翻到很多硬核讨论。PX4这边虽然也有官方论坛和Discord群但它的迭代速度太快了很多老教程对应的是旧版本固件照着做不一定能成功这点需要特别留意。我的建议是不管最后选了哪个先把官方文档从头到尾翻一遍。Ardupilot有完整的《Copter 4.x》和《Plane 4.x》手册PX4有User Guide和开发指南这些文档虽然有些地方写得不够细但至少是唯一权威的起点。不要一上来就跟着YouTube视频点半天视频经常过时。2. 开发环境搭建拿Ubuntu 22.04装机交学费的完整记录这部分是血泪史。我相信很多人在“PX4 编译环境 ubuntu 22.04”这个搜索词上消耗了整整一天。这里我把自己的实践步骤完整写下来只要照着做大概率能顺利通过。我用的系统是Ubuntu 22.04 LTS环境为VMware 16虚拟机虚拟机分配了4核CPU、8GB内存、60GB硬盘。2.1 开始之前先搞清楚版本匹配关系先说一个最容易踩的坑PX4官方现在对Ubuntu系统版本有明确的推荐和支持矩阵。目前对Ubuntu 22.04支持版本是PX4 v1.13以后的主线代码。如果你还在照着早期PX4 1.11/1.12的教程去搭那大概率会撞上Python依赖冲突、Qt版本不兼容等问题。决定版本匹配前先确认三样东西的版本缺一不可PX4固件版本通过git branch -a和git tag看当前分支和标签Gazebo版本PX4 v1.13 的仿真实例默认是Gazebo Classic 11Ubuntu 22.04仓库默认就有地面站版本QGroundControl 4.2 对PX4 v1.13的支持比较好。这里有个很关键的原则别用Ubuntu 24.04别用Ubuntu 20.04的老教程生搬硬套到22.04。我记得自己第一次就是在Ubuntu 24.04上折腾结果编译器GCC版本太新PX4固件编译到一半报错而且报错信息还很绕查了半天才发现是GCC 13的问题。2.2 完整搭建步骤从零到编译固件下面就是我实测可用的完整步骤全程需要用到的命令尽量白盒化让你知道每一步在干什么。第一步更新系统和安装基础依赖sudo apt update sudo apt upgrade -y sudo apt install -y \ git zip cmake build-essential genromfs ninja-build \ exiftool astyle python3-pip python3-setuptools \ python3-venv python3-dev python3-jinja2 \ python3-tk python3-lxml wget curl \ libxml2-dev libxslt1-dev libssl-dev \ libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev \ libqt5gui5 libqt5core5a libqt5dbus5 \ qml-module-qtquick2 qml-module-qtquick-controls \ qml-module-qtquick-controls2 qml-module-qtquick-layouts \ qt5-qmake qtbase5-dev qtbase5-dev-tools \ qttools5-dev-tools qtdeclarative5-dev \ libeigen3-dev libopencv-dev libgazebo11-dev \ protobuf-compiler gstreamer1.0-plugins-base \ gstreamer1.0-plugins-good gstreamer1.0-plugins-bad \ gstreamer1.0-plugins-ugly gstreamer1.0-libav \ gstreamer1.0-tools这些包是PX4官方脚本安装的一部分我手动拆开列出是为了让你知道我们在装什么。特别是libgazebo11-dev和protobuf-compiler少了它们后面跑仿真会莫名其妙报错。第二步克隆源代码并初始化子模块cd ~ git clone --recursive https://github.com/PX4/PX4-Autopilot.git cd PX4-Autopilot如果你的网络访问速度比较慢建议用代理或者镜像。没有代理的话可以多试几次git submodule update --init --recursivePX4的依赖很多一次拉全概率极低。网络不顺畅时我习惯的做法是git config --global submodule.recurse true git submodule sync --recursive git submodule update --init --recursive在下载子模块的时候你可能会看到很多Receiving objects进度条卡住不动不要慌张先等几分钟如果彻底卡死再重新执行。这是网络问题不是代码问题。第三步使用官方安装脚本安装剩余依赖PX4官方提供一个工具脚本PX4-Autopilot/Tools/setup/ubuntu.sh它会自动安装各种工具链。我建议先让脚本跑一遍然后手动检查它漏了什么。注意脚本运行到某个位置可能因为权限问题中断我们不用root权限而是用普通用户加sudo执行bash ./PX4-Autopilot/Tools/setup/ubuntu.sh跑完后重新打开一个终端让环境变量生效然后执行cd ~/PX4-Autopilot make px4_sitl gazebo-classic如果编译顺利你会看到类似[100%] Built target px4的输出然后自动弹出Gazebo仿真界面里面有一台3DR Iris无人机。第四步把地面站和仿真环境连通新开一个终端启动QGroundControl然后在Vulcan或任意PX4 SITL终端里输入commander takeoff应该能看到地面站里飞机起飞。这一步能成功说明环境搭建基本完成。这里我强烈建议第一次跑仿真时先编译一个空白目标比如make px4_sitl_default gazebo-classic不要带自定义编译选项避免额外的变量干扰。2.3 VMware虚拟机用户的特殊注意事项很多朋友是在VMware里跑Ubuntu我也是其中之一。虚拟机跑PX4仿真不是不行但需要注意内存至少要分8GB最好12GB。PX4编译时GCC会把所有核心都吃满内存不够直接OOM killer把编译进程杀掉报错信息是killed或者internal compiler error容易误判为代码问题硬盘分配60GB以上PX4源码加上编译产物至少10GB起步如果还要装ROS2和XTDrone20GB打底开启3D加速否则Gazebo界面卡到怀疑人生虚拟机的网络模式建议用NAT走桥接模式时偶尔会出现MAVLink连接刷屏但地面站搜不到设备的情况。我用VMware 16实测下来CPU最好从4核起步。以前用双核编译一次make要跑20分钟后来加了核心数时间缩短到6分钟。编译过程中CPU风扇狂转是正常的不用担心。2.4 一个容易忽略的坑Python环境版本Ubuntu 22.04默认自带Python 3.10如果你为了跑其他项目装过Anaconda或Miniconda很可能会把PYTHONPATH搞乱。PX4的构建系统对Python版本敏感建议不要用conda的基环境做PX4编译创建一个独立的虚拟环境如果非要用conda就单独建一个环境并明确激活安装jinja2、numpy、tqdm、cerberus等包时用pip3 install --user --upgrade来避免污染系统环境。我见过最悲惨的情况是因为conda的libstdc版本冲突PX4固件编译到一半报undefined reference to这种报错和代码一点关系都没有纯粹是编译器链接到了错误的标准库。3. 仿真平台才是效率杀手锏SITL、Gazebo与XTDrone的搭配环境搭好只是开始真正干活是在仿真平台里。这一节会聊SITL软件在环、Gazebo仿真、以及XTDrone这种集成开发平台。个人觉得认真玩好仿真至少能省掉70%的炸机成本。3.1 什么是SITL为什么必须学会SITLSoftware In The Loop是指把飞控固件当成一个普通程序跑在电脑上不需要任何真实硬件。PX4固件通过MAVLink与Gazebo仿真器通信仿真器里的虚拟无人机反馈传感器数据飞控算法处理后输出控制命令形成一个完整的闭环。好处显而易见代码和算法可以在没有硬件风险的情况下验证。做路径规划不用真的飞做视觉识别可以在仿真场景里放各种虚拟目标做编队算法甚至可以同时启动多架虚拟无人机。启动SITL的基本命令是cd ~/PX4-Autopilot make px4_sitl gazebo-classic启动后这个终端实际上变成了一个类似PX4控制台的界面你可以输入help查看可用的MAVLink命令比如commander takeoff、commander land、param set等。3.2 Gazebo环境定制和模型加载Gazebo是PX4最常用也是默认的仿真器。它有两种风格老款的Gazebo Classic 11和新版的Ignition Gazebo后来的Gazebo Garden。目前PX4主线还在大量使用Gazebo Classic也因为文档和示例多。如果你不想每次都用默认的Iris无人机PX4也支持加载自定义模型。最简单的方法是使用现有的模型框架比如make px4_sitl gazebo-classic_plane加载固定翼模型或者加载带云台的摄像头模型。自己做一个3D模型放入仿真环境需要你同时会点CAD建模和SDF格式。SDFSimulation Description Format是Gazebo的模型描述格式可以用XML编写也可以从SolidWorks等工具导出。这里我不展开讲建模但给一个思路先把官方模型文件打开看一遍理解link、joint、sensor这些标签然后基于它修改比自己从零开始写SDF快得多。3.3 重点聊聊XTDrone集成平台热词里出现“ubuntu22.04搭建px4仿真环境及xtdrone开发平台”说明有不少人在跑XTDrone。XTDrone是国内高校无人机爱好者开发的一套基于PX4和Gazebo的仿真平台最大优点是把“飞机模型、传感器模型、摄像头模型”全部整合好了还提供了很多脚本直接跑SLAM、目标跟踪、自主探索等算法演示。XTDrone官方推荐使用Windows双系统或Vmware虚拟机。安装过程大致分四步安装Ubuntu 22.04和ROS2如果是ROS1版本则是Ubuntu 20.04安装GazeboXTDrone要求Gazebo 9及以上建议直接装在22.04自带的11下载XTDrone源码并把sitl_config等文件夹放到PX4-Autopilot对应位置运行./run.sh启动仿真场景。这里要注意XTDrone对PX4版本的兼容性有严格要求。不是每个PX4版本都能直接配合XTDrone跑起来需要看它README里指定的版本号有时候需要git checkout到特定commit。这也是为什么很多人在XTDrone和PX4版本之间来回折腾。我自己的经验是如果是纯做视觉算法验证XTDrone非常香因为它的相机模型、图像话题发布都配置好了运行YOLO检测可以省去很多调试时间。但如果是想深入理解PX4内部工作原理还是老老实实直接用原生PX4 SITL吧XTDrone把很多细节封装掉了不利于学习底层。3.4 仿真和真机调试的差距很多刚接触仿真的人容易产生一种错觉仿真里能飞真机肯定也能飞。这个想法十分危险。仿真环境和真机的差距主要在于传感器噪声模型不够真实真实的加速度计和陀螺仪有噪声、温漂、安装误差仿真里的电机响应是理想模型真实的电机有延迟、有推力衰减真机环境有风、有地效、有GPS信号遮挡、有磁干扰。所以仿真能过的算法真机不一定能直接落地。但在“炸机成本为零”这一点上仿真绝对是投资回报率最高的工具。我建议的流程是先在SITL里验证功能逻辑再上HITL硬件在环测试。HITL就是把真实的飞控硬件和电脑连接让飞控以为自己在带一个虚拟飞机跑这样能验证真实硬件和真实固件但传感器和电机还是虚拟的。启用HITL也很简单在QGroundControl里把飞控连接电脑然后在PX4参数里设置SYS_AUTOSTART为对应的机型把飞控模式切到HITL。之后启动一个带HITL的Gazebo场景即可。4. 常见问题排查实录编译失败到自动调参的避坑指南这一节我把遇到过的、以及论坛里高频出现的问题整理了速查表。虽然是个人经验但覆盖了大部分常见场景。4.1 编译问题速查表报错现象根本原因解决办法fatal error: xxx.h: No such file or directory缺少依赖头文件检查make之前的submodule update --recursive是否完整重新执行git submodule update --init --recursiveinternal compiler error: Killed内存不足被系统杀掉增加虚拟机内存或者降低并行编译参数make -j2cmake error: Could not find a package configuration file缺少特定开发包根据报错中的包名执行sudo apt install libxxx-devninja: build stopped: subcommand failed子模块编译报错信息在上面重新运行make时加VERBOSE1查看具体错误ImportError: No module named numpyPython路径不对检查是否在conda环境改用系统Python重新编译error: __s32 does not name a typeGCC版本过新使用官方推荐的GCC版本或者用Docker编译环境Firmware version X is not supported地面站固件版本过旧升级QGroundControl到最新版MAVLink not received on heartbeat防火墙或串口权限问题检查sudo usermod -a -G dialout $USER重新登录后再次连接表格里的解决办法都可以作为第一排查手段。如果出现internal compiler error: Killed很多人第一反应是改代码其实根本就不是代码问题。我当时就是傻乎乎地优化了好几轮C代码后来发现虚拟机内存只有4GB一次性编译太吃内存老老实实把内存调到12GB就好了。4.2 编译源码时最容易忽略的GCC版本坑PX4源码编译对GCC版本有严格限制。在Ubuntu 22.04默认GCC 11是没问题的但如果你之前装过其他工具链把默认gcc改成了13或者12编译时就会遇到一堆莫名其妙的模板报错。查看当前GCC版本gcc --version如果需要切换到GCC 11可以sudo update-alternatives --config gcc如果提示没有可选版本就手动安装sudo apt install gcc-11 g-11 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-11 110 sudo update-alternatives --install /usr/bin/g g /usr/bin/g-11 110同样的道理适用在ARM交叉编译环境。如果是编译飞控板子的固件比如Pixhawk 4、Pixhawk 6CPX4会从Arm官网自动下载工具链。如果你遇到热词里提到的“px4 fetching xtensa compilers”卡住多半是网络问题。解决办法是手动下载官方工具链然后放到~/PX4-Autopilot/Tools/arm-none-eabi目录下再修改环境变量让它跳过自动下载。具体路径和版本号PX4官方文档里有照着做就行。4.3 从PX4到Ardupilot的调参对比说完编译再聊聊调参。很多人自动飞行或手动飞行时发现飞机不稳第一反应就是改PID。这里把Ardupilot和PX4的调参方式做个对比Ardupilot以ArduCopter为例调参入口Mission Planner的“配置→全参数列表”或者“扩展调参”界面关键参数RATE_RLL_KP、RATE_RLL_KI、RATE_PIT_KP、RATE_PIT_KI、RATE_YAW_KP好处参数全开放随便改改了马上能看到效果坏处参数太多新手容易改乱。PX4使用QGroundControl自动调参调参入口QGC左侧栏“齿轮图标→参数→自动调参”流程先飞起来悬停切换到调参模式飞机会自动做小幅扰动然后估算出最优PID好处流程自动化适合对新飞控不熟悉的人坏处对机型结构有要求机体太轻或太重都会影响结果。我自己的体会是先把默认参数飞顺再考虑调参。如果飞机起飞后严重偏航、抖动优先检查的是螺旋桨动平衡、电机安装方向、GPS罗盘校准而不是PID。很多“飞机乱晃”其实是硬件或校准问题不是控制问题。这条经验同样适用于Ardupilot和PX4。4.4 毫米波雷达避障、编队等扩展玩法的坑如果你已经能飞稳了下一步大概率想扩展功能。热词里提到“px4毫米波雷达避障”和“px4编队esp32”这里简单说一下都有什么坑。毫米波雷达避障的场景一般是基于PX4ROS2Gazebo。PX4通过距离传感器比如北醒TF系列或者毫米波雷达发布距离信息机载电脑里的避障节点订阅这些信息后产生新的期望航向并写入PX4的Offboard控制模式。坑在于雷达数据的坐标系和PX4的机体坐标系定义经常对不上需要做一次坐标变换另外雷达在近距比如小于0.5米时数据不稳定需要在算法里做数据有效性判断。编队的场景更偏向软件和通信。ESP32作为一个小型飞控或MAVLink转发器通过UART或WiFi接收PX4的MAVLink消息然后执行编队逻辑。常见坑是UART串口波特率不匹配、MAVLink消息频率太高导致ESP32死机。解决方案是降低MAVLink流率或者只转发必要消息比如只转发LOCAL_POSITION_NED和ATTITUDE不要全量转发。4.5 自动调参为什么有时会失败最后聊聊自动调参失败的问题。PX4自动调参有个前提飞行器必须处于稳定悬停状态而且用户必须临时把遥控器模式打到“位置控制”或“定高模式”。如果在调参过程中乱动油门、风太大、或者遥控器信号不稳调参过程会失败甚至导致飞机坠落。我实操中遇过一次调参失败一架续航很长的固定翼机身很轻但机翼长度长自动调参时由于风的影响飞机一直处于小幅震荡结果估算出来的增益偏大落地后手感很差。这个问题的本质是自动调参对“激励信号”有要求如果飞机本身响应太慢激励信号无法充分激发动态特性结果自然不准。如果你是纯新手我的建议是先用官方默认参数飞5-10个起降记录飞行日志看QGC里的日志分析结果再考虑要不要调参。如果必须调尽量在无风、空旷的场地进行最好给飞机系上安全绳体验几次“炸机和救机”比任何理论都管用。5. 一些值得收藏的进阶资源和工作流建议这一部分不讲具体配置了但我觉得跟前面同等重要。5.1 日志分析是飞控调试的第三只眼Ardupilot和PX4都内置了强大的日志系统。Ardupilot的日志扩展名是.binPX4的日志扩展名是.ulog。分析日志是定位飞行问题最有效的方法但这部分很多人都不重视。Ardupilot日志用Mission Planner的“数据闪存日志”页面查看PX4日志用Flight Review在线工具拖入.ulog文件即可或plotjuggler离线分析。我建议新机第一次试飞后不管飞得顺不顺利都导出一份日志放进Flight Review看看。重点关注振动水平振动级别应该在3以下、电机输出饱和度、GPS精度、姿态角跟踪误差。这些指标正常了再飞复杂动作。5.2 版本管理永远别用master分支干活如果你用PX4做实际项目强烈建议不要直接基于主分支开发。PX4的更新节奏快昨天能编译的代码今天拉取更新后可能就编译不过了。正确做法是用git checkout到一个稳定的release版本比如v1.14.0基于这个版本建自己的分支例如dev/mydrone_controller新功能合并到自己的分支之前先在小范围测试。Ardupilot同时有Copter-4.5等稳定分支也同样建议基于稳定分支开发而不是master。5.3 尝试在项目中同时使用两套系统说了这么多最后聊一个有意思的体会很多项目实际上会同时用到Ardupilot和PX4的思路。举个例子现在比较火的中大型无人机物流项目底层的制导导航控制算法通常在Ardupilot跑因为它的固定翼和垂直起降模式支持非常成熟而且调参体系透明但机载视觉、碰撞检测、多机协同这些算法模块又在PX4或ROS2环境里做原型验证。因为PX4的模块化架构更方便在机载电脑上做外部开发。所以别把自己绑死在一个平台。先通过Ardupilot理解“飞控是怎么调参、怎么规划航点、怎么和地面站协同的”再通过PX4理解“模块化软件架构、uORB通信、Offboard控制接口是怎么回事”。两个平台都上手一遍你对开源飞控的认知会有一个质的提升。6. 最后再分享一个小技巧在你准备搭建环境前我强烈建议先给当前Ubuntu做一次快照虚拟机用户。搭建PX4环境涉及几十个依赖包中途万一装坏了某个库恢复系统比重装所有东西快太多了。我自己的习惯是干净系统装完基础软件后立刻打一个快照每成功完成一个阶段再打一个快照。这样就算后面玩坏了回到干净环境也就是几分钟的事。另外如果你同时用Windows和Linux双系统不要在Windows下直接把PX4源码放到NTFS分区里去编译Linux下访问NTFS的权限和符号链接问题会让你纠结到怀疑人生。把源码放到Linux原生分区Ext4里老老实实放在~/目录下就少了一半的问题。最后关于“从放弃到精通”我的感受是飞控开发没有捷径但也没有想象中那么难。唯一确定能缩短学习周期的办法就是多编译、多飞仿真、多查日志别怕踩坑。这篇Part 2写出来的所有经验都是靠一次次失败换来的希望你能少走一些弯路把时间花在真正有意思的算法和飞行上。