企业官网建设流程全解析

很多刚开始做飞控相关开发的朋友，第一次把这四个词放到一块儿看——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相当于安卓和iOS，Pixhawk则相当于某一款具体的手机型号。安卓可以跑在这款手机上，iOS不行；但Pixhawk这块硬件比较特殊，它既可以刷PX4，也可以刷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配合QGroundControl（QGC）、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仿真，要注意默认网络模式是NAT，QGC在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的编译目标区分得很细，做仿真和做真机固件的编译命令完全不同。

仿真场景下，最常用的是SITL（Software In The Loop）编译：

cd PX4-Autopilot make px4_sitl gazebo

这条命令会启动Gazebo仿真环境，自动加载一个多旋翼模型，PX4飞控作为软件进程跑在Gazebo里。你可以用QGC连接它，就相当于连接了一台虚拟飞控。这个方法特别适合练手，不用买硬件就能把PX4的基本操作、日志分析、参数调整全都学会。

真机固件则是编译成能在Pixhawk上运行的固件，不同板子的编译目标不一样，比如Pixhawk 4（FMUv5）是：

make px4_fmu-v5

编译完会生成带.px4后缀的固件文件，用QGC里的“固件”页面刷到飞控板即可。这里有个关键点：一定要根据你的飞控板型号选择对应的编译目标。刷错固件轻则设备不识别，重则bootloader出问题，所以动手前先查清楚板子对应的FMU版本。Pixhawk 2.4.8对应的是FMUv2或FMUv3（Pixhawk 1兼容），Pixhawk 4是FMUv5，不同版本不要混刷。

3.4 QGC连不上飞控：按照这个顺序排查，十分钟解决

“PX4链接不上QGC”是我收到过最多的求助问题之一。其实绝大多数情况就三类：串口权限、USB线问题、版本兼容性。

排查顺序我总结成一套心法，按顺序来：

1. 换线。很多USB线只能充电，没有数据传输能力。你用手机充电线连接飞控，系统根本识别不到设备。
2. 看系统是否识别设备。Linux下用lsusb或者ls /dev/ttyACM*，有设备说明硬件已经被系统看到了；没有设备，直接检查线材、飞控供电和USB口。
3. 修串口权限。Linux下最常见的坑是当前用户没有串口权限，导致QGC能看到设备但打不开。执行：

sudo usermod -a -G dialout $USER

然后重新登录系统，再打开QGC。 4.检查版本兼容性。PX4的版本和QGC版本不宜差距太大。比如PX4 v1.13、v1.14对应新版本QGC没问题，但如果你拿一个很老的PX4固件配最新版QGC，MAVLink握手就可能失败。遇到问题先查官方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连接，就能在没有硬件的情况下完成大量参数调试和航线测试。相比PX4，ArduPilot的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 gazebo，ArduPilot用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编译不了”。开源项目版本迭代极快，过时教程里的方法很可能已经失效。能区分“这个教程适用于哪个版本”，本身就是飞控开发的核心能力之一。

我把这一条记在笔记最前面，也送给你。