很多刚开始做飞控相关开发的朋友第一次把这四个词放到一块儿看——PX4、Pixhawk、ArduPilot、APM基本都是同一个反应这几个到底谁是谁有的文章说“Pixhawk刷PX4固件”另一篇又说“APM刷ArduPilot固件”还有人干脆告诉你“PX4就是Pixhawk”听完直接原地懵圈。别急这四个词其实分属“软件、硬件、历史沿革”三条完全不同的线。只要把这三条线拆开彼此的关系就非常清楚了。这篇文章专门帮你理清这层关系顺带把我这些年做飞控开发时踩过的坑比如源码子模块没初始化、编译报错、QGC连不上地面站、电机装反之类的实操问题一起写进来。无论你是准备入手第一块飞控板还是打算做PX4二次开发、ArduPilot编译移植这篇应该都能帮你少走不少弯路。1. 关系拆解软件、硬件、历史沿革一条线一个坑1.1 先记住一句话PX4和ArduPilot是软件Pixhawk是硬件APM是古老的历史遗留我见过太多人把“软件”和“硬件”混在一起聊然后越聊越乱。最简单的心智模型是这样的PX4和ArduPilot本质都是一套“飞控软件/固件”可以理解为飞机的“操作系统”而Pixhawk是一块“飞控硬件板子”相当于“跑操作系统的手机”。拿手机类比很合适PX4和ArduPilot相当于安卓和iOSPixhawk则相当于某一款具体的手机型号。安卓可以跑在这款手机上iOS不行但Pixhawk这块硬件比较特殊它既可以刷PX4也可以刷ArduPilot等同一台手机能装两套操作系统这在行业里其实是很少见的设计。为了减少歧义我用表格把这四个名词的定位直接摊开名词本质所属层级核心特征常见使用场景PX4开源飞控软件/固件软件层模块化架构、uORB消息总线、MAVLink通信支持多旋翼/固定翼/VTOL/无人车/无人船学术研究、算法验证、定制开发ArduPilot开源飞控软件/固件软件层单进程调度、架构紧凑源于APM项目支持载具类型最全含水下机器人航模爱好者、工程产品落地、低成本项目Pixhawk开源飞控硬件板硬件层可兼容运行PX4和ArduPilot经历FMUv2/FMUv3/FMUv5等硬件版本迭代买板子、刷固件、装机实飞APM早期飞控硬件ArduPilotMega或ArduPilot固件的旧称硬件历史层最初基于Arduino Mega的硬件项目后来固件独立改名ArduPilot老玩家手里的旧板子、搜资料时容易混淆这张表建议直接截图保存以后再有人问你这几个名词啥关系直接把表甩过去。1.2 APM到底是个什么东西这个名字是“历史歧义”的重灾区APM这个词是很多人混淆的总根源。它最早指“ArduPilotMega”是一块基于Arduino Mega 2560扩展出来的飞控硬件板。当年的航模圈里APM板子价格比商业飞控便宜一大截功能还不少所以很多老玩家从APM入坑今天你搜“APM飞控”还能看到一堆二手APM 2.8板子。但后来固件项目独立出来了改名叫ArduPilot硬件APM板则慢慢退出历史舞台。于是现在你再听到“APM固件”大概率不是指那块老硬件而是指ArduPilot这套软件。同一个缩写在不同语境里指向完全不同的东西这就是它特别容易让人搞混的原因。更闹心的是APM在今天还有一个完全不相关的含义——Java生态里的Maven依赖管理工具经常带“APM”相关概念IT监控领域还有Application Performance Management应用性能管理也缩写为APM。你要是用“APM”做关键词搜索搜出来的东西那叫一个五花八门。所以不要怪自己笨是这个领域的历史命名本身就埋了雷。1.3 Pixhawk为什么和PX4绑得这么紧这得从出生讲起Pixhawk最初就是PX4项目团队设计出来的硬件平台所以两者的关系天然很近。当时PX4团队做了一套开源软件需要配套的硬件于是设计并开源了Pixhawk飞控板。这也是为什么很多人默认“PX4就是Pixhawk”因为第一款完全适配PX4的开源硬件就是Pixhawk早期资料里这两个词经常直接混用。但后来的事情很有意思ArduPilot团队看中了Pixhawk硬件的性能也把它移植成了ArduPilot的官方推荐硬件之一。从那之后Pixhawk就不再是PX4专属硬件了而是成了一个“中立平台”PX4和ArduPilot都支持它。这有点像当年安卓和第三方刷机ROM的关系硬件是公版软件各有各的玩法。你现在如果买一块Pixhawk 4或者Pixhawk 2.4.8的板子市面上常见的是兼容板完全可以自己选择刷PX4还是刷ArduPilot刷完固件之后它俩就是两套完全不同的飞控系统。这不是“改名”的关系而是“一台机器装了两套系统”的关系。2. PX4和ArduPilot到底怎么选架构、生态、场景全面对比2.1 PX4的设计哲学模块化、学术范儿、适合“拆开来研究”PX4的软件架构走的是模块化路线模块之间通过uORB消息总线通信姿态估计用EKF2控制输出走混控器模块。每一个模块都是相对独立的进程或任务你可以单独替换、单独调试某一个模块而不影响其他部分。如果你想研究卡尔曼滤波可以直接去读源码里的src/modules/ekf2想改姿态控制规律就在control模块里动手。这种架构对开发者非常友好尤其适合高校实验室和科研团队。你想验证一个新的算法只需要写一个模块往uORB上订阅传感器数据再把输出发回控制通道整个流程是清晰且标准的。PX4的文档也比较系统化官方有PX4 User Guide针对开发者的架构文档也写得比较细整体学习曲线虽然不低但路径明确。不过模块化的代价是系统复杂度偏高运行也相对“重”一些。同样的硬件PX4用的资源往往比ArduPilot要多一点调试和排查问题的时候涉及模块之间的交互新手容易看晕。2.2 ArduPilot的设计哲学单进程、工程范儿、追求“跑得稳”ArduPilot的架构是单进程加调度器驱动的模式代码的耦合度比PX4高但运行起来非常紧凑高效。它的历史包袱小设计目标很直接在有限的计算资源上跑出足够稳定可靠的飞控行为。所以你能看到很多低成本飞控板、老APM板子、甚至一些非主流的DIY硬件跑ArduPilot都挺顺畅。ArduPilot支持载具类型的广度在开源界可以说是第一ArduCopter多旋翼、ArduPlane固定翼、ArduRover无人车、ArduSub水下机器人、ArduBoat无人船全都覆盖。如果你要做水下机器人ArduSub基本是开源ROV的事实标准要做无人船ArduPilot的Boat固件也成熟得多。这个特点对项目选型影响很大尤其非航空类的无人平台项目选ArduPilot会省很多事。工程产品落地方面ArduPilot的社区更偏“实战派”很多航模玩家从十几年前就开始用它Mission Planner地面站的功能也极其丰富。如果你追求“今天刷固件明天就能飞后天就开始挂设备测试”ArduPilot的上手速度比PX4快不少。2.3 选型建议别被“哪个更强”带偏要看你的目标是什么我个人的建议是不要问“PX4和ArduPilot哪个更好”要问“你的项目更依赖哪条生态链”。如果你要做学术研究、算法验证、定制化二次开发并且打算用Gazebo、AirSim这类仿真环境做实验那PX4的生态更匹配。PX4配合QGroundControlQGC、MAVSDK、MAVLink这套工具链研究路径非常顺。很多高校的无人机课程、科研项目都是基于PX4展开的遇到问题找参考也更方便。如果你的目标是快速造一台能稳定飞的工具平台或者要做无人车、无人船、水下机器人那ArduPilot更省心。它的成熟稳定度非常高几十种载具型号的调参资料在官方Wiki上应有尽有Mission Planner里几乎把你能想到的功能都做成了图形化界面。还有一个现实考量团队能力结构。如果团队里有写代码底子好的人选PX4做长期开发更友好如果团队主要是操作手、飞手、装配工那ArduPilot的图形化调参方式门槛更低。3. PX4开发环境搭建源码、子模块、QGC连接一次说清楚3.1 搭建前的准备Ubuntu版本和基础依赖PX4的新版本对Ubuntu的适配一直在变。我实测比较稳妥的是Ubuntu 22.04装PX4 v1.14.X比较顺Ubuntu 24.04装新版本也可以但老教程里的依赖脚本可能匹配不上建议先看官方文档。Windows用户我比较推荐用WSL2跑Ubuntu这样既能用Windows下的IDE、QGC又能在Linux环境里编译PX4源码。这里多说一句如果你用WSL2做PX4仿真要注意默认网络模式是NATQGC在Windows宿主里连接WSL2里的SITL时可能会遇到端口访问问题。解决方案一般是在WSL2里监听0.0.0.0用Windows的localhost转发必要时调整Windows防火墙。我自己第一次在WSL2里跑Gazebo时花了半天才搞明白端口为什么会不通结果就是网络模式问题提前知道能省很多时间。3.2 克隆源码时最容易出的问题子模块没初始化很多人编译PX4第一步就翻车。报错信息往往很迷什么找不到头文件、编译器奇怪报错但根源就一个源码仓库的子模块没有拉全。PX4的代码仓库依赖了大量子模块包括MAVLink协议定义、uORB消息定义、各类外部驱动库等。正常操作应该是git clone --recursive https://github.com/PX4/PX4-Autopilot.git但很多人会漏掉--recursive这个参数或者clone到一半网络断了子模块就缺了。如果已经出现了类似情况先用一句话救命cd PX4-Autopilot git submodule update --init --recursive如果这条命令跑完还是报错尤其卡在某一个子模块拉不下来优先检查submodule状态git submodule status会看到路径前面有-或者符号说明对应的子模块没同步成功。这时候可以单独补拉那个子模块或者简单粗暴地换个网络环境再来一次。实操中我遇到过大概率是某个较大仓库超时多跑两遍git submodule update --init --recursive就能过。3.3 编译目标怎么选SITL仿真、真机固件别搞混了PX4的编译目标区分得很细做仿真和做真机固件的编译命令完全不同。仿真场景下最常用的是SITLSoftware In The Loop编译cd PX4-Autopilot make px4_sitl gazebo这条命令会启动Gazebo仿真环境自动加载一个多旋翼模型PX4飞控作为软件进程跑在Gazebo里。你可以用QGC连接它就相当于连接了一台虚拟飞控。这个方法特别适合练手不用买硬件就能把PX4的基本操作、日志分析、参数调整全都学会。真机固件则是编译成能在Pixhawk上运行的固件不同板子的编译目标不一样比如Pixhawk 4FMUv5是make px4_fmu-v5编译完会生成带.px4后缀的固件文件用QGC里的“固件”页面刷到飞控板即可。这里有个关键点一定要根据你的飞控板型号选择对应的编译目标。刷错固件轻则设备不识别重则bootloader出问题所以动手前先查清楚板子对应的FMU版本。Pixhawk 2.4.8对应的是FMUv2或FMUv3Pixhawk 1兼容Pixhawk 4是FMUv5不同版本不要混刷。3.4 QGC连不上飞控按照这个顺序排查十分钟解决“PX4链接不上QGC”是我收到过最多的求助问题之一。其实绝大多数情况就三类串口权限、USB线问题、版本兼容性。排查顺序我总结成一套心法按顺序来换线。很多USB线只能充电没有数据传输能力。你用手机充电线连接飞控系统根本识别不到设备。看系统是否识别设备。Linux下用lsusb或者ls /dev/ttyACM*有设备说明硬件已经被系统看到了没有设备直接检查线材、飞控供电和USB口。修串口权限。Linux下最常见的坑是当前用户没有串口权限导致QGC能看到设备但打不开。执行sudo usermod -a -G dialout $USER然后重新登录系统再打开QGC。 4.检查版本兼容性。PX4的版本和QGC版本不宜差距太大。比如PX4 v1.13、v1.14对应新版本QGC没问题但如果你拿一个很老的PX4固件配最新版QGCMAVLink握手就可能失败。遇到问题先查官方Release Notes里的兼容矩阵。 5.虚拟机/WSL特殊检查。如果你是在虚拟机里跑QGC确认USB设备被透传到了虚拟机如果宿主Windows装QGC连接WSL2里的SITL确认是网络通信问题而不是USB问题。这套流程走下来绝大多数连不上QGC的问题都能解决。你别一上来就去翻代码先把物理连接和权限搞定这是每个飞控开发者都经历过的基础课。4. ArduPilot编译、电机设置和更多应用场景4.1 ArduPilot源码编译waf构建和板卡选择ArduPilot的编译方式和PX4不一样它用的是waf构建系统。源码克隆git clone https://github.com/ArduPilot/ardupilot.git cd ardupilot git submodule update --init --recursive然后配置板卡比如Pixhawk 1./waf configure --board Pixhawk1 ./waf copter编译完的固件在build/Pixhawk1/bin目录下同样用地面站刷入。注意ArduPilot的板卡名称跟PX4不太一样Pixhawk 1、Pixhawk4、CubeBlack都有对应的board名字编译前./waf list_boards可以查看所有支持的板卡列表。仿真方面ArduPilot提供了sim_vehicle.py这个神器cd ardupilot/Tools/autotest sim_vehicle.py -v ArduCopter --map --console它会自动启动SITL并打开MAVProxy地面站再配合Mission Planner或QGC连接就能在没有硬件的情况下完成大量参数调试和航线测试。相比PX4ArduPilot的SITL更轻量资源占用小老电脑也带得动。4.2 ArduPilot电机设置调试顺序决定成败很多新手在ArduPilot里设置电机时一上来就急着解锁推油门结果电机方向反了或者转速不一致。正确的顺序应该是接线 - ESC校准 - 电机方向测试 - 螺旋桨安装方向确认。先说接线。电调信号线要插在飞控对应的电机输出通道上不同飞控板的输出顺序不一样Pixhawk系列通常遵循编号顺序但具体仍要看板子丝印和说明书。接错通道会直接导致飞控给错电调发信号起飞是不可能的严重时还可能在地面试车时翻车。ESC校准的通用方法先把遥控器油门推到最高再给飞控和电调上电听到电调提示音后三秒内把油门拉到最低电调会发出确认音完成校准。这个步骤的目的是让电调知道信号范围的上限和下限不校准的话电机响应会不稳定容易导致解锁后转速忽高忽低。电机方向测试一定要记住一个原则先拆桨再测试。这点我说过无数遍仍然有人不听。把电机一个一个接在通道上解锁后用Mission Planner的“电机测试”功能缓慢推动油门观察电机旋转方向是否与软件标定的一致。如果方向反了最简单的方式是交换电机和电调之间的任意两根相线对BLDC电机来说交换两相就能反转。最后才是装桨。注意螺旋桨有正反桨之分多旋翼对角电机装同向桨相邻电机装反向桨安装方向错误的话四旋翼根本飞不起来甚至会在解锁瞬间翻倒。4.3 水下机器人、无人船和更多“跳出四旋翼”的应用ArduPilot的应用范围远不止航拍机。除了ArduCopter还有ArduPlane固定翼、ArduRover无人车、ArduSub水下机器人、ArduBoat无人船而且子项目都很成熟。水下机器人用的就是ArduSub很多人搜“水下机器人 APM”其实指的就是ArduSub固件。ArduSub支持ROV传统布局兼容树莓派、Pixhawk硬件配合QGC或QGroundControl for ROV实现水下定深、定向、姿态保持这些功能都很成熟。国内做低成本水下机器人、水下观测ROV的团队很多直接用ArduSub打底省掉了底层飞控开发的巨大工作量。我想强调的是选型之前先确认你需要的载具类型在目标固件里的成熟度。ArduPilot的固定翼和多旋翼稳定性极高水下和水面载具也积累了大量社区案例PX4在VTOL、尾部推进等新型飞机上的支持则更活跃。这个差异非常实际别想当然“都是飞控啥都能干”。5. 从放弃到精通给新手的实战学习路线5.1 五步学习法避开“重复造轮子”的浪费我见过太多人学PX4一上来就clone源码然后盯着代码发呆三天后放弃了。这套学习路线是我自己验证过效率比较高的分享给所有刚入门的同学第一步明确路线的终点。先定下来你是做科研算法、做工程产品还是自己DIY玩。这个决定直接决定你选PX4还是ArduPilot。两边都学是自我折磨先把一条线跑通再说。第二步把官方文档当“小说”看一遍。PX4 User Guide、ArduPilot Wiki都是宝藏。不要跳着看把概念、架构、术语过一遍哪怕很多细节没记住也比你去论坛碎片化搜资料强很多。这个过程一般两三天但会让后面所有环节快十倍。第三步跑通一次仿真。PX4用make px4_sitl gazeboArduPilot用sim_vehicle.py。把地面站连上看看姿态解算、日志、参数表理解整套数据流。到了这一步你已经超越很多只“看过资料”的人了。第四步改一点小东西。给PX4加一个新的MAVLink消息或者修改ArduPilot的一个参数文件形成“改代码 - 编译 - 仿真验证 - 看结果”的闭环。完整的开发流程走一遍才算真正入门。第五步上真机但永远从保守模式开始。室内、自稳模式、装好桨保、周围清空人员这是底线。真机验证容易出各种意想不到的问题千万不要跳过仿真直接上头飞。5.2 我的个人经验始终盯着“版本”这根弦最后分享一个压箱底的经验是我踩了无数次坑之后才总结出来的飞控开发里90%的奇怪问题根源都是版本不匹配。硬件版本、固件版本、地面站版本这三个变量必须统一记录。比如说Pixhawk 2.4.8这个型号不同批次可能有不同的传感器老批次的IMU在某些PX4新固件上会报错同样是Pixhawk 4不同厂商的兼容板在硬件细节上也有差异。我自己现在每做一个项目都会在项目文件夹里建一个“版本清单.txt”记录硬件板卡型号、PX4或ArduPilot的具体版本号、QGC或Mission Planner的版本号以及USB线材、串口权限这类看似细枝末节的配置。你说这些东西值不值得记值得。有一次我做一套基于ArduPilot的无人船项目船在水里死活连不上地面站查了一下午发现是数传模块固件版本太旧和ArduPilot新版协议不兼容。如果没有版本清单这个问题排查起来就像大海捞针。另外遇到问题一定要学会“用版本号报错关键词”去搜索比如搜“PX4 v1.14.3 子模块编译报错”而不是搜“PX4编译不了”。开源项目版本迭代极快过时教程里的方法很可能已经失效。能区分“这个教程适用于哪个版本”本身就是飞控开发的核心能力之一。我把这一条记在笔记最前面也送给你。