如果你正打算在 Ubuntu 18.04 上搭建 ROS Melodic Gazebo PX4 的无人机仿真开发环境我先说句实话官网文档写得很工整但真实安装过程不是照着敲就能一路跑通的。我前后折腾了两天中间重装过一次系统最后才把这套环境彻底捋顺。这篇文章就是把我踩过的坑、验证过能用的步骤全部写下来帮你把这个过程压缩到半天以内。无论你是刚开始接触 PX4 二次开发还是实验室里想快速跑一个 Gazebo 仿真都可以按这份流程走一遍。需要说明的是这里不讨论新版本 Ubuntu 22.04 ROS 2 或者 Gazebo Classic 的迁移方案只讲一套目前仍然在大量无人机项目里服役的组合Ubuntu 18.04、ROS Melodic、Gazebo 9、PX4 1.12.3。这套组合虽然不新但胜在资料多、踩坑记录全、和很多老版本开源项目兼容特别适合入门和复现论文。1. 为什么 Ubuntu 18.04 Melodic 是 PX4 开发绕不开的组合1.1 版本对应关系先理清楚很多人装环境失败不是操作问题而是版本搭配本身就错了。PX4 的仿真体系对 ROS 版本和 Gazebo 版本有对应关系不是随便拿个 Ubuntu 20.04 ROS Noetic 就能无脑跑出同样的效果。Ubuntu 18.04 对应的官方 ROS 版本就是 Melodic而 Melodic 默认自带的 Gazebo 是 9。PX4 的 SITL 仿真插件从很早就在 Gazebo 9 上做过大量验证尤其是我下面推荐的 PX4 1.12.3 版本对 Gazebo 9 的支持非常稳定。三者之间的匹配关系可以简单看作组件推荐版本说明操作系统Ubuntu 18.04.5长期支持版生态最成熟ROSMelodicUbuntu 18.04 官方对应版本Gazebo9.xROS Melodic 自带PX4 1.12 验证充分PX4 固件1.12.3国内很多教程和开源项目的基础版本如果你去查 PX4 官网会发现最新固件版本对 Gazebo 版本的要求已经变了比如 1.14 以后更偏向 Gazebo Classic 甚至新的 Gazebo 版本。但 Ubuntu 18.04 上单独升级 Gazebo 11 会带来一整套依赖冲突不值得为了追新而无谓消耗时间。新版本可以等环境跑通了以后再在 Docker 或者新系统下去尝试。1.2 什么场景下必须用这套环境我自己遇到最多的是两类需求一类是跑开源算法比如目标跟踪、路径规划、视觉 SLAM很多老项目基于 Melodic 写成直接给你 launch 文件和环境配置文件换到 Noetic 就得改一堆依赖和接口另一类是实验室的 PX4 二次开发底层仿真链路由学长学姐传下来用的就是 Gazebo 9 加 PX4 旧版本。还有一类是课程作业和毕业论文复现。国内不少无人机方向的研究生论文附录里写的都是 Ubuntu 18.04 Melodic PX4你照着搭环境至少能减少一个“版本环境不一致”带来的变量。如果你纯粹想尝鲜用 ROS 2 跑新功能那 Ubuntu 18.04 这套组合并不适合可以直接去看 Ubuntu 22.04 ROS 2 Humble 的方案。但如果你想踏踏实实学 PX4 仿真、把无人机二次开发的基础链路搞明白这套环境仍然是当前最稳的起点。1.3 不要被“旧系统”三个字劝退我在实际使用中最大的感受是Ubuntu 18.04 看起来老但好在所有坑都已经被前人踩干净了。你搜任何一个报错信息几乎都能找到对应的讨论帖。这种“经验的确定性”在开发环境搭建阶段非常宝贵比追新版本然后自己去踩未知的坑要省心得多。2. 正式安装前必须搞定的系统配置与依赖清单2.1 硬件准备和安装方式选择先说结论如果条件允许优先用物理机安装双系统。虚拟机也能跑但性能和 3D 加速方面会多一些奇怪的问题比如 Gazebo 界面闪、地面渲染不出来。内存建议至少 8 GB编译 PX4 固件的过程中内存不够很容易 OOM直接编译报错排查起来很糟心。磁盘预留至少 30 GBROS 本体加 PX4 源码加编译产物实际占用远比你想象的大。安装 Ubuntu 18.04.5 时要注意几点不要选最小安装就选正常安装因为后续很多开发库在最小安装下缺得厉害。分区时给根目录单独分一个区不用太在意 /home 单独分个人开发用根目录一个分区就够。如果安装过程中遇到“执行 grub 安装失败”通常是引导分区的问题重装时手动指定 /boot 分区可以解决。装完系统以后先执行一遍系统更新sudo apt update sudo apt upgrade这里跑一遍很有必要不少官方软件源里的依赖缓存可能停留在旧版本后续安装 ROS 时容易碰到依赖版本不满足的怪问题。2.2 显卡驱动和 OpenGL 检查是重灾区我折腾了两天其中至少半天耗在 Gazebo 界面一直闪这个问题上。后来定位到根因是 OpenGL 渲染环境没有准备好Gazebo 加载图形界面时反复刷新导致闪烁。先安装 Mesa 工具检查渲染环境sudo apt install mesa-utils glxinfo | grep OpenGL renderer如果输出的是类似llvmpipe这样的软件渲染设备说明 OpenGL 没走硬件加速。这种情况在虚拟机里非常常见在 N 卡闭源驱动没装好的物理机上也偶尔出现。对应的解决办法分两种情况虚拟机环境打开虚拟机的 3D 加速开关。VMware 里在虚拟机设置的显示器选项中勾选“加速 3D 图形”VirtualBox 则需要在设置里把显存调到 128 MB并启用 3D 加速。改完以后要重启虚拟机生效。物理机 N 卡办法是安装合适的闭源驱动sudo ubuntu-drivers autoinstall之后重启或者用“软件和更新”里的额外驱动选项卡手动选一个 recommended 版本。如果显卡驱动已经装好但渲染还是不稳定可以临时用软件渲染兜底export LIBGL_ALWAYS_SOFTWARE1 gazebo这个变量只对当前终端生效测试没问题后再考虑要不要固化到.bashrc。2.3 提前安装的通用依赖在装 ROS 之前先把这些基础工具装好避免中间被打断sudo apt install -y build-essential cmake git python-pip python3-pip \ g gdb vim htop net-tools curl wget这里要特别提一下python-pipUbuntu 18.04 默认自带的是 Python 2.7 和 Python 3.6很多 PX4 构建脚本还会依赖 Python 2 生态。虽然官方已经逐步放弃 Python 2但为了兼容 PX4 1.12.3 的构建流程把 Python 2 相关工具链保持可用会让你少很多麻烦。3. ROS Melodic 安装从软件源到 rosdep 的完整链路3.1 添加软件源和安装 ROS 本体ROS Melodic 的软件源在国外的服务器上直接访问速度不稳定建议先换成国内镜像。我用的是清华源实测速度比默认源快了非常多。sudo sh -c echo deb http://packages.ros.org/ros/ubuntu bionic main /etc/apt/sources.list.d/ros-latest.list上面这行仍然是官方源。如果你想要清华的 ROS 镜像源可以改成sudo sh -c echo deb https://mirrors.tuna.tsinghua.edu.cn/ros/ubuntu bionic main /etc/apt/sources.list.d/ros-latest.list添加 keysudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-key C1CF6E31E6BADE8868B172B4F42ED6FBAB17C654如果加 key 时网络不稳定多试几次即可。接着sudo apt update sudo apt install ros-melodic-desktop-full为什么直接装desktop-full而不是ros-melodic-ros-base因为 desktop-full 不仅包含 ROS 核心功能还包含 Gazebo 9、RViz、TF 等一堆后续写代码绕不开的工具库。单独装 base 虽然能省一点空间但之后你大概率还是要补装反而多花时间。安装完成后先验证一下source /opt/ros/melodic/setup.bash roscore如果看到started core service的输出ROS 本体就没问题了。网上也有很多一键安装 ROS 的脚本比如鱼香ROS的一键安装工具确实能省不少时间。但我的看法是第一次搭建环境还是手动跑一遍比较好至少你能知道每一步做了什么之后遇到环境变量问题、软件源问题时你知道去哪里排查。3.2 初始化 rosdep 与环境变量ROS 安装完以后还有一步是很多人会漏掉甚至直接跳过的初始化 rosdep。这步不做好后面编译工作空间时会频繁报依赖缺失而且有些依赖不是 apt 能直接解决的。sudo rosdep init rosdep updaterosdep init常见报错是ERROR: cannot download default sources list from github。这不是你操作的问题而是访问 GitHub 的服务不稳定。解决思路不是一遍遍死磕而是换一种方式多试几次有些时候网络波动是暂时的。如果多次失败可以搜索国内常用的 rosdep 镜像更新源修改/usr/lib/python2.7/dist-packages/rosdep2/sources_list.py或者/etc/ros/rosdep/sources.list.d/20-default.list中的地址替换成国内可达的镜像。这一步需要一点动手能力但值得花时间。rosdep update成功以后把环境变量写入~/.bashrc避免每次开终端都要手动 sourceecho source /opt/ros/melodic/setup.bash ~/.bashrc source ~/.bashrc然后初始化 catkin 工作空间mkdir -p ~/catkin_ws/src cd ~/catkin_ws catkin_make这里要提醒一下catkin_make第一次运行时会出现devel和build两个目录这是正常的。如果这一步出现rosdep相关的报错说明前面的 rosdep 初始化没做好回头检查。3.3 验证 ROS 环境是否完整打开一个新终端执行echo $ROS_DISTRO如果输出melodic说明环境变量正常。再执行printenv | grep ROS你会看到ROS_MASTER_URI、ROS_PACKAGE_PATH等变量这是正常的。到这里ROS 层面的环境就绪了。接下来才是真正耗时间的部分Gazebo 和 PX4 的联动。4. Gazebo 与 PX4 固件编译最容易翻车的几个环节4.1 先单独验证 Gazebo 是否能正常启动ROS Melodic 装完以后Gazebo 9 已经装好了。不要急着去编译 PX4先把 Gazebo 单独跑起来确认环境没问题gazebo如果一切正常你会看到一个包含地面、天空和光照的空场景窗口。如果窗口打不开、闪烁、崩溃那大概率是显卡加速问题回到第 2.2 节去处理。这里还有一个高频问题Gazebo 启动后下面的状态栏一直显示Downloading model...。这是因为 Gazebo 首次启动会从模型库下载一些默认模型下载速度很慢甚至卡住。解决办法是先手动把模型库下载到本地cd ~/.gazebo git clone https://github.com/osrf/gazebo_models.git models然后把模型路径写进环境变量echo export GAZEBO_MODEL_PATH$GAZEBO_MODEL_PATH:$HOME/.gazebo/models ~/.bashrc source ~/.bashrc这样 Gazebo 启动时加载的就是本地模型不会再卡在下载环节。4.2 获取 PX4 固件并安装依赖PX4 的源码在 GitHub 上选对版本是关键。建议使用 1.12.3而不是直接拉最新主干cd ~ git clone -b v1.12.3 https://github.com/PX4/PX4-Autopilot.git --recursive这里必须带--recursive否则子模块缺失严重编译到一半会报各种各样的找不到头文件的错误。如果你当时没带--recursive事后补救命令是cd ~/PX4-Autopilot git submodule update --init --recursivePX4 官方提供了一键安装依赖的脚本位于Tools/setup/ubuntu.sh。在 Ubuntu 18.04 上可以直接执行cd ~/PX4-Autopilot bash ./Tools/setup/ubuntu.sh --sim这个脚本会安装大量仿真需要的依赖包括 Gazebo 相关插件、MAVLink 库、Python 库等等。脚本执行时间取决于网络状况有时候会卡在某个 apt 包上。遇到脚本卡住时我的做法是先 CtrlC 停掉然后手动执行它刚才正在安装的命令确认是不是网络问题。如果是某个包下载慢可以多试几次或者改用国内的 apt 源。4.3 编译 PX4 SITL 固件依赖装好以后开始编译。这一步风险最高因为耗时可能很长而且报错信息五花八门。cd ~/PX4-Autopilot make px4_sitl gazebo第一次编译需要几分钟到十几分钟取决于你的 CPU 性能。如果内存不足 8 GB很容易在某个 C 文件编译时进程被杀掉。这时候不要慌先确认是不是 OOMdmesg | grep -i oom如果是内存不足可以通过临时增加 swap 来解决。比如创建一个 8 GB 的 swap 文件sudo fallocate -l 8G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile编译成功的标志是终端最后出现类似[100%] Built target gazebo_plane的输出然后自动弹出 Gazebo 窗口里面停着一架多旋翼无人机。如果没有自动弹出窗口说明环境变量没有正确加载。PX4 的仿真环境需要设置几个关键变量我把它们统一写进.bashrc里会比较省事source ~/PX4-Autopilot/Tools/setup_gazebo.bash ~/PX4-Autopilot ~/PX4-Autopilot/build/px4_sitl_default export ROS_PACKAGE_PATH$ROS_PACKAGE_PATH:~/PX4-Autopilot export GAZEBO_PLUGIN_PATH$GAZEBO_PLUGIN_PATH:~/PX4-Autopilot/build/px4_sitl_default/build_gazebo export GAZEBO_MODEL_PATH$GAZEBO_MODEL_PATH:~/PX4-Autopilot/Tools/sitl_gazebo/models这里的环境变量顺序有讲究。如果先 source 了 ROS 的 setup.bash再 source PX4 的 setup_gazebo.bashPX4 自己的 Gazebo 工具会追加到已有路径的后面。如果你反过来了ROS 的路径会覆盖掉 PX4 的路径导致 Gazebo 加载不到 PX4 的模型和插件。4.4 编译过程中的典型报错处理我遇到过最多的是下面这几类报错特征真实原因处理办法找不到mavlink头文件子模块没有下载完整重新执行git submodule update --init --recursiveGLIBC_2.XX not foundPython 环境或系统动态库混乱尽量别手动卸载系统自带 Python使用虚拟环境隔离CMake Error: The source directory does not appear to contain CMakeLists.txt目录切换错误或源码路径有中文检查当前目录是否为~/PX4-Autopilot编译器被 kill内存不足增加 swap 或关闭占用内存的浏览器Qt platform plugin xcb相关报错Gazebo 图形库依赖残缺安装libqt5gui5和libxcb-xinerama05. 打通 Ubuntu 18.04 Melodic Gazebo PX4 仿真链路5.1 从命令行启动一套完整仿真环境变量配置好以后启动仿真就变得很简单了cd ~/PX4-Autopilot make px4_sitl gazebo这条命令会启动 PX4 SITL 进程同时拉起 Gazebo。等待十几秒后你能看到 PX4 终端输出类似[px4] Startup script的日志紧接着 Gazebo 窗口中出现无人机模型。如果 Gazebo 窗口有了但是无人机没有出现最常见的原因是模型路径没设对。验证方法echo $GAZEBO_MODEL_PATH输出里应该包含~/PX4-Autopilot/Tools/sitl_gazebo/models这个路径。仿真起来以后PX4 默认会等待地面站连接。你可以用 QGroundControl 连接协议选择 UDP端口默认14550。连接成功以后在 QGC 上能看到无人机的姿态和位置信息也可以规划任务。5.2 使用 ROS 话题和 MAVROS 进行交互如果你需要在自己的 ROS 节点里订阅无人机的位姿、传感器数据或者给 PX4 发送指令只靠 QGC 不够至少还要装 MAVROSsudo apt install ros-melodic-mavros ros-melodic-mavros-extras装完以后在新终端里启动 MAVROS 节点把 PX4 的 SITL 数据转成 ROS 话题source ~/catkin_ws/devel/setup.bash roslaunch mavros px4.launch fcu_url:udp://:14540127.0.0.1:14557这里的fcu_url是 PX4 SITL 默认暴露的 UDP 端口具体值以你当前 PX4 版本的sitl脚本为准。连接成功后可以通过rostopic echo /mavros/state看到connected: true就说明 ROS 和 PX4 已经通了。之后你再跑自己的控制节点、SLAM 节点都可以通过 MAVROS 提供的/mavros/setpoint_position/local或/mavros/rc/override等话题来控制仿真无人机。这里有个经验启动顺序很重要。先启动 PX4 SITL 和 Gazebo等终端稳定输出后再启动 MAVROS最后启动 QGC。反过来先启动 QGC 再启动仿真有时候会导致 MAVROS 抢不到数据流端口。5.3 仿真环境里常见的使用误区我发现很多初学者会把 Gazebo 当成一个独立工具来调实际上在 PX4 仿真链路里Gazebo 只是“传感器仿真器”PX4 SITL 负责飞控逻辑QGC 负责地面站MAVROS 负责 ROS 桥接。三者各司其职任何一个环节断掉无人机在 Gazebo 里都会表现异常但 Gazebo 本身看起来又是正常的。所以排查问题时先确认 PX4 终端有没有正常输出EKF syncing之类的日志再确认 QGC 有没有出现无人机连接最后才去看 Gazebo 画面。6. 实测排错我踩过的坑与快速定位方法6.1 高频问题排查表以下这些问题是搜索记录里热度最高、也是我自己实际遇到过的。我整理成一张表方便你遇到症状时直接对照。症状可能原因快速解决办法Gazebo 界面一直闪OpenGL 没有硬件加速检查glxinfo虚拟机开 3D 加速或export LIBGL_ALWAYS_SOFTWARE1Gazebo 启动慢且一直下载模型模型库没有本地化手动 clonegazebo_models到~/.gazebo/models并设置GAZEBO_MODEL_PATH编译make px4_sitl gazebo卡住网络下载依赖失败或内存不足换代理不现实时就重试内存不足加 swaprosdep update失败访问 GitHub 不稳定多试几次或把 sources_list 换成国内镜像ROS 找不到px4相关包ROS_PACKAGE_PATH没设置确认export ROS_PACKAGE_PATH$ROS_PACKAGE_PATH:~/PX4-Autopilot已写入 bashrcQGC 连不上无人机端口被占用或启动顺序不对关掉所有 QGC/MAVROS先启动 SITL再启动地面站报错Exception ignored in: module mavlink...Python 2/3 模块冲突确认编译和运行时都用同一个 Python 环境6.2 一个更省事的排错思路日志分期看不要等 Gazebo 窗口弹出来才去排查问题。启动make px4_sitl gazebo之后整个启动过程可以分成三个时间段前 5 秒PX4 SITL 初始化和 Gazebo 加载。这个阶段报错大多是环境变量、模型路径、子模块缺失。中间 5 到 20 秒Gazebo 加载世界文件和无人机模型。这个阶段报错一般是模型库缺失、插件路径错误。20 秒以后PX4 与 Gazebo 握手。如果卡在这里通常是端口冲突或 QGC 抢占数据流。按时间段去日志里找关键词能大幅缩小排查范围。6.3 我的实际操作体会这套环境我前前后后配过三台机器一台物理机加两台虚拟机。物理机用 N 卡闭源驱动Gazebo 渲染很稳虚拟机只要把 3D 加速打开跑 PX4 的简单仿真场景也没问题但复杂场景下帧率会比较低。另一个体会是环境变量这个问题看起来简单其实最容易阴沟翻船。每次打开新终端先用echo $GAZEBO_MODEL_PATH看一眼不要直接去跑 launch。如果路径是空的后续所有问题都会表现成“Gazebo 里没有无人机”但你看 ROS 节点一切正常容易误判成 PX4 编译失败。最后再提醒一句不要用sudo去跑 Gazebo、roscore 或者 roslaunch。一旦用 root 权限跑过~/.gazebo里的文件所有者和权限会乱掉后面普通用户启动 Gazebo 时会莫名其妙读不到模型库。遇到这种情况sudo chown -R $USER:$USER ~/.gazebo可以救回来。我这些年踩过最大的坑就是贪图方便用 root 跑完整个仿真然后花了一个下午处理权限问题。把这套环境手动走一遍之后你的收获不只是“能跑起来”而是知道每一条命令背后在干什么。之后换到 Ubuntu 20.04、ROS Noetic甚至 ROS 2你都有足够底气去应对新的报错。