说实话第一次搭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插件和仿真器之间的接口经常变化系统版本一不对就会出现各种诡异问题。第二次搭建时我特意把版本组合固定下来不追新只求能复现、能查资料。下面是我实测下来比较稳妥的几个组合供参考操作系统PX4固件版本仿真器适用场景Ubuntu 20.04v1.14.xGazebo 11入门学习、课程作业、二次开发Ubuntu 20.04v1.13.xGazebo 11老教程配套资料多Ubuntu 22.04v1.15.xGazebo Classic / Garden新特性较多适合尝鲜不是说不能用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 11PX4 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 是否需要提前安装ROSPX4 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提示符说明启动流程有问题需要回头看编译日志。实际编译时可能会在某个环节卡住很久。先别急着按CtrlC观察是不是在下载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渲染窗口直接跑SITLCPU占用会明显下降。这个技巧在批量跑测试时特别有用。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 px4simcd ~/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的示例。这个顺序能让你在每个阶段都只面对一个新问题。仿真环境的意义就是让你在低成本、零炸机风险的前提下反复试错。环境搭好只是第一步能在里面真正理解飞控原理和控制方法才不白费这次搭建的功夫。