说实话，第一次搭PX4仿真环境的时候，我差点被劝退。虚拟机里编译到一半磁盘满了，Gazebo启动后黑屏，QGroundControl怎么都连不上，最崩溃的是每次报错我都得从头搜一遍教程，改了这儿那儿又炸。后来我重新梳理了版本关系、资源分配和编译流程，第二次只用了一天多就把PX4仿真环境完整跑起来了。这篇全记录就是把我第二次搭建的过程、选型思路、踩过的坑和完整排查链路都写下来。如果你正准备入门PX4飞控，或者第一次搭建失败想重来，这篇文章能让你少走很多弯路，直接跟着一套流程走就能跑通。

1. 第一次失败的现场复盘：我到底在哪个环节翻车的

1.1 第一次搭建的真实过程回顾

第一次搭建时，我用的方案是Windows 11加VMware虚拟机，系统装的是Ubuntu 22.04。当时想得很简单：装好系统，跑官方脚本，编译完就万事大吉。结果刚进入依赖安装阶段还算顺利，等到底层编译器开始构建PX4固件，磁盘空间就迅速告急。我创建虚拟机时只给了40G虚拟磁盘，编译产物加上系统占用很快就塞满了。内存也只有4G，并行编译时系统直接OOM，编译进程被杀掉，终端里一堆Killed字样。

后来我尝试扩容磁盘、删软件包、降低编译并行度，勉强把编译跑完，但Gazebo启动后又遇到模型加载不出来、地面站连接超时等一系列问题。那时候我完全不懂版本匹配的概念，随便拉了一个分支编译，结果仿真器和固件版本对不上，运行行为也非常奇怪。整个环境折腾了三四天，最后以重装系统告终。现在回头看，那次失败几乎是必然的，因为我在环境层面埋了太多雷。

1.2 复盘结论一：资源分配是环境搭建的地基

第一次的核心问题，是低估了PX4编译环境的资源需求。PX4固件从源码编译时，不仅要构建固件本体，还要编译Gazebo插件和配套工具，整个构建产物加起来体积不小。如果你还要安装ROS、下载Gazebo模型库、存放QGroundControl，磁盘占用很快会超过40G。所以我建议磁盘至少预留80G，内存8G起步，如果条件受限，swap分区也要给足，否则编译时很容易被系统杀进程。

虚拟机不是不能用，我自己身边也有朋友在虚拟机里成功跑通了PX4仿真，但关键是在创建虚拟机时就把资源给够。第一次我用默认配置创建，后期扩容非常痛苦，还容易遇到磁盘格式、启动引导之类的问题。第二次搭建时，我改成物理机安装Ubuntu双系统，磁盘和内存压力一下就小了。如果你不方便动系统，那就把虚拟磁盘初始设定到100G，内存给到8G以上，CPU核心给到4个以上，能省掉后面一大堆麻烦。

1.3 复盘结论二：版本匹配比什么都重要

新手很容易觉得PX4项目就应该用最新分支，直接把main拉下来编译。但实际上，最新开发分支的固件、Gazebo插件和仿真器之间的接口经常变化，系统版本一不对，就会出现各种诡异问题。第二次搭建时，我特意把版本组合固定下来，不追新，只求能复现、能查资料。

下面是我实测下来比较稳妥的几个组合，供参考：

不是说不能用Ubuntu 22.04，而是版本组合要配套看，不能只看PX4版本。这是第一次搭建时我完全没意识到的问题，也是第二次顺利跑通的重要原因之一。

1.4 复盘结论三：报错信息一定要沉淀下来

第一次搭建还有一个很蠢的毛病：不看报错，也不记录信息，报错内容一划而过，然后去搜索引擎里凭感觉找答案。结果就是同样一个问题，第二天又要踩一遍，又要重新查一遍，效率极低。

第二次搭建时，我专门建了一个笔记文档，记录完整操作流程、每一步输入的命令、所有报错和解决方案。第二次之所以能一天多跑通，除了资源给足了之外，很大程度上靠的就是这份日志。建议你也准备一个搭建记录文档，不用多规范，但至少把命令、报错和解决方式记下来。后面遇到同样问题时直接翻笔记，效率能提升不少。

2. 第二次搭建前的版本选型与依赖处理

2.1 为什么选Ubuntu 20.04加PX4 v1.14

第二次选型的时候，我确实纠结过要不要上Ubuntu 22.04，毕竟新系统对硬件和驱动的支持更好。但查了一圈资料后发现，PX4 v1.14和Ubuntu 20.04的配套文档最齐全，Gazebo 11也是最成熟的仿真器。论教程数量、社区问答的完整程度，这个组合明显更省心。

实际跑下来也验证了这个判断。Ubuntu 20.04的软件源里直接就能装到Gazebo 11，PX4 v1.14对Gazebo 11的适配很完整，不需要额外处理版本冲突。对于想快速跑通、专注学飞控算法的人来说，可靠性优先比追新版更有意义。仿真环境说到底只是工具，版本太新反而容易把时间浪费在环境折腾上，而不是飞控学习上。

2.2 基础依赖安装与常见报错

确定版本之后，第一步是更新系统并安装基础工具。这里不建议手动去翻依赖列表，PX4官方在源码仓库里提供了一个自动安装脚本Tools/setup/ubuntu.sh，它会安装编译PX4所需的绝大多数依赖。你只需要先装好git和curl，把源码拉下来，给脚本加执行权限运行。

sudo apt update && sudo apt upgrade -y sudo apt install -y git curl git clone --recursive https://github.com/PX4/PX4-Autopilot.git cd PX4-Autopilot bash ./Tools/setup/ubuntu.sh

脚本运行时间取决于网速，通常在10到30分钟之间。运行过程中可能会因为网络原因下载失败。我第二次搭建时，脚本中途有几次提示某些包下载超时，处理方法很简单：等脚本退出后重新执行一次bash ./Tools/setup/ubuntu.sh，它会继续未完成的部分，而不是从头开始。

如果你的网络环境拉取GitHub源码确实很慢，可以把仓库同步到自己的Gitee仓库，再执行git clone --recursive。这样至少能避免在clone环节就卡住不动。注意子模块一定要一并拉取，如果发现某个子模块是空目录，执行：

git submodule update --init --recursive

另外，Ubuntu 20.04自带的Python是3.8版本，脚本会安装一些Python工具包。如果你之前手动装过不同版本的Python或pip，可能会出现包冲突。建议脚本跑完后，检查一下PX4相关的工具能否正常执行，缺什么用pip3 install补上就行。

2.3 是否需要提前安装ROS

PX4 SITL仿真本身并不强制依赖ROS。官方默认的make px4_sitl gazebo启动方式是标准流程，完全可以直接跑起来，地面站用QGroundControl就够了。

那ROS什么时候装？当你准备做机载计算、编写offboard模式控制程序，或者想用mavros生态里已有的功能包时，再装。第一次搭建时我犯过一步到位的错误，在系统里同时装ROS和PX4编译环境，结果变量太多，报错根本分不清是ROS的问题还是PX4的问题。第二次我明确决定：先只用原生Gazebo把PX4仿真跑通，ROS留到后面单独处理。

把变量隔离在一个小范围内，是多依赖环境搭建里最重要的一条原则。环境越复杂，互相干扰的概率越高。先跑通最小可用系统，再逐步叠加功能，看起来慢，实际比一口气装完再排错快得多。

3. 从源码下载到仿真窗口弹出：第二次完整操作记录

3.1 拉取PX4源码与子模块处理

我选择的版本是v1.14分支，在clone完成后单独切换了标签。如果你不需要最新的开发特性，建议直接切到正式发布版本。

git checkout v1.14.4

切换标签之后，要继续检查子模块状态，因为不同标签对应的子模块版本也会变化。执行git submodule update --init --recursive，确保所有依赖模块都正确拉取。

这个步骤第一次搭建时被我完全忽略了。当时我clone了main分支，以为代码最新就没事，结果后续编译时出现各种奇怪的报错。锁定版本等于给整个工程建立了一个可复现的基线，后面再出问题，按照社区里对应版本教程找方案，基本都能直接对上。

3.2 编译PX4 SITL固件

编译命令非常简单，在PX4-Autopilot目录下执行：

make px4_sitl gazebo

这个命令会做两件事：先编译PX4飞控固件的SITL版本，再编译Gazebo仿真插件并启动仿真环境。首次编译耗时取决于CPU性能，一般在10到30分钟之间。编译过程中终端会滚动输出大量日志，看到类似Firmware build finished的提示，说明固件编译成功。

编译成功后，会弹出Gazebo窗口，里面出现一架多旋翼无人机模型，同时运行仿真的终端会进入pxh>提示符。这个提示符就是PX4的Shell，你可以直接输入命令控制无人机。如果只看到Gazebo窗口但没有pxh>提示符，说明启动流程有问题，需要回头看编译日志。

实际编译时，可能会在某个环节卡住很久。先别急着按Ctrl+C，观察是不是在下载Gazebo模型或子模块，网络慢时等待时间会比较长。如果真的卡死，可以重新执行make，因为有增量编译机制，第二次会比第一次快很多。

3.3 启动仿真并连接QGroundControl

有了PX4 SITL和Gazebo之后，还需要一个地面站来和仿真无人机通信。QGroundControl是官方推荐的地面站软件，下载AppImage版本后执行：

chmod +x ./QGroundControl.AppImage ./QGroundControl.AppImage

首次启动QGroundControl时，它会自动扫描本机UDP端口，发现PX4 SITL生成的MAVLink连接。正常情况下，左上角连接状态会变成绿色，地图页面能看到无人机模型和传感器数据。如果地面站没有自动发现，可以在应用设置里增加一个UDP连接，监听端口填14550，地址填127.0.0.1，然后手动连接。

QGroundControl连上后，你可以看到IMU加速度计、陀螺仪、气压计和GPS数据都在跳动，说明仿真环境已经真正跑通了。到了这一步，整个搭建任务算完成了八成，剩下两成就是各种实测和优化，也就是我接下来要重点说的部分。

4. 第二次实测中冒出的新坑与完整排查过程

第二次搭建虽然整体顺利，但实测过程中还是冒出了几个问题，而且每一个都很有代表性。把排查链路完整写出来，你遇到类似问题可以直接照着查。

4.1 编译阶段：CMake版本过旧导致的配置失败

现象是执行make px4_sitl gazebo后，cmake检查阶段直接报错，提示CMake版本过低。我系统里装的是3.16.3，按理说够用，但报错信息显示实际检测到的是另一个旧版本。排查后发现，系统里同时存在多个cmake，/usr/local/bin/cmake的优先级高于/usr/bin/cmake，编译脚本调用了错误的旧版本。

排查方法很直接：

which cmake cmake --version

如果发现路径不对，可以用绝对路径指定cmake，或者把新版本路径放到PATH最前面。我最终在~/.bashrc里把/usr/local/bin加到PATH前面，然后重新加载配置，问题就解决了。这个问题在第一次搭建时也经常遇到，只是那时候我不知道往这个方向查。

4.2 Gazebo模型加载不出来

这个问题第一次搭建时遇到过，第二次仍然碰到了。现象是仿真窗口已经打开，地面也在，但无人机模型不显示，环境里一片空白。排查过程如下：

• 先看终端有没有报错，通常是找不到某个模型文件，或者下载模型超时。
• Gazebo首次运行某个模型时，需要从模型库下载对应模型文件，网络慢时就会加载失败。

解决方式是手动准备模型库。把Gazebo需要的模型资源放到~/.gazebo/models目录下，避免每次启动都去网络下载。具体做法是提前下载好官方模型库，放到对应用户目录下，然后设置环境变量GAZEBO_MODEL_PATH指过去。另外，每次打开新终端前，建议先执行：

source /usr/share/gazebo/setup.sh

这一步是为了让Gazebo相关的环境变量在当前终端生效。很多模型加载问题，本质上都是环境变量没设置好导致的，不是仿真器本身坏了。

4.3 仿真画面卡顿、CPU占用过高

Gazebo仿真本身是实时物理引擎加渲染，CPU和内存占用高是正常的。但第二次搭建时，仿真画面卡得没法操作，CPU占用接近100%。排查后发现两个原因叠加：笔记本GPU驱动没有正确启用，Gazebo用的OpenGL渲染变成了软件渲染；同时后台还挂了大量Electron进程，占了不少内存。

解决办法分几步：

• 先关闭不相关的后台程序，尤其是一次性开了一堆浏览器页面和聊天工具的情况。
• 在Gazebo侧降低渲染负载，比如把窗口分辨率调低、关闭反锯齿选项。
• 内存压力大时增加swap空间，避免编译或仿真过程中内存不足。

如果只是做算法验证，其实不需要可视化界面，可以让仿真不启动Gazebo渲染窗口，直接跑SITL，CPU占用会明显下降。这个技巧在批量跑测试时特别有用。

4.4 QGroundControl显示连接超时

第三个问题是QGroundControl界面一直显示连接超时。排查链路是这样的：

• 确认PX4 SITL终端还停在pxh>，说明仿真端存活。
• 检查QGroundControl左下角连接状态，如果显示未连接，看它探测到的端口。
• 默认情况下PX4 SITL会把MAVLink数据发送到本机14550端口，QGroundControl也监听这个端口。如果端口被占用，启动时会报错，需要先杀掉占用进程。
• 检查防火墙是否拦截了UDP 14550。

我最后发现是防火墙规则没放行UDP端口。在Ubuntu上执行：

sudo ufw allow 14550/udp

然后重新启动QGroundControl，连接就正常了。还有一点，如果你开了多个终端同时启动PX4实例，会出现端口冲突，记得只保留一个仿真实例。

5. 验收飞行与后续提效：第二次搭建后我做了什么

5.1 一套快速验收环境的飞行流程

环境跑通之后，我建议按下面这套流程做一次完整验证，确保每个环节都正常。

• 打开终端，进入PX4-Autopilot目录，启动make px4_sitl gazebo。
• 等待Gazebo窗口和pxh>提示符出现。
• 启动QGroundControl，确认连接状态变绿。
• 在QGroundControl里把飞行模式切换到Position或Offboard。
• 回到pxh>终端，执行commander takeoff，设置一个起飞高度。
• 观察Gazebo窗口里无人机是否起飞，QGroundControl里的高度和GPS数据是否同步变化。

如果无人机能正常起飞并悬停，说明PX4 SITL、Gazebo、QGroundControl三个环节都正常。这套验证流程看起来简单，但能把大部分隐藏问题暴露出来。

5.2 用别名和脚本把启动命令沉淀下来

跑通之后，每次启动仿真都重复敲长命令，比较烦。我写了一个小脚本放到~/.bash_aliases里：

alias px4sim='cd ~/PX4-Autopilot && make px4_sitl gazebo' alias qgc='~/下载/QGroundControl.AppImage &'

在~/.bashrc里加上别名定义后，每次打开终端直接输入px4sim就能启动仿真，输入qgc就打开地面站。如果你经常同时开多个终端，建议用tmux管理，把仿真、地面站和日志窗口分在不同面板，切换起来比来回开终端方便很多。

5.3 给后来人的几条实在建议

磁盘空间一定要多留。我第二次预留了100G，最后编译产物、Gazebo模型库、QGroundControl加一起差不多30G，后面如果再装ROS，空间需求还会涨。别卡在磁盘满了这种低级问题上。

版本锁定之后不要再频繁切换。有时为了试试新功能切到main分支，切回来的时候子模块版本对不上，又得重新编译，很浪费时间。可以另外建一个目录放main分支，和长期维护的正式环境分开，互不干扰。

学会看日志。PX4在编译和运行阶段都会输出大量日志，大多数问题都能在日志里找到关键报错。别只看终端最后几行，往上翻一翻，或者把输出重定向到文件里慢慢看。

一次只引入一个新变量。新学PX4时，不要把PX4、ROS、Gazebo、新模型、外设驱动全部叠在一起。先用默认配置跑通，再逐步叠加，这样出问题时很容易定位。

5.4 仿真跑通后值得继续深挖的方向

跑通SITL之后，下面几个方向都可以继续深入。一是用MAVSDK写程序，远程控制仿真无人机起飞、飞行和降落，这是学习控制逻辑很好的入口。二是研究offboard模式，通过机载代码发送期望位置和速度，这是很多飞控算法的必经之路。三是把同一套代码稍作调整，部署到Pixhawk等真实飞控上，配合QGC做真机飞行验证。

我自己在跑通后的做法是：先把takeoff和land练熟，再用MAVSDK写一个简单的航线任务，最后才去看offboard的示例。这个顺序能让你在每个阶段都只面对一个新问题。仿真环境的意义，就是让你在低成本、零炸机风险的前提下反复试错。环境搭好只是第一步，能在里面真正理解飞控原理和控制方法，才不白费这次搭建的功夫。