标定一下背景这篇文章不是从零教学“怎么编译EGO-Planner”而是记录我在完整搭建 ego-planner 仿真环境、跑通 RViz 可视化、再进到 Gazebo 做闭环实验时踩过的所有坑。如果你现在正处于“代码能编译但 RViz 打不开”“Gazebo 窗口一直闪”“明明给了目标点但无人机不动”的状态那这篇文章大概率能帮你省下几天时间。我假设你已经知道 EGO-Planner 的大致定位——一种不需要预计算 ESDF 距离场的梯度优化局部规划器常用于四旋翼无人机在未知环境中的自主避障飞行。EGO-Planner 擅长在感知的地图点上直接做梯度优化生成光滑、安全且动态可行的 B 样条轨迹。听起来不难但把它放到 Gazebo RViz 的仿真闭环里真正冒出来的问题往往不在规划算法本身而在环境、渲染、话题通信这些“看不见的下层”。1. 仿真路线选型开始动手前先看懂这套系统的四个角色1.1 EGO-Planner 官方仓库到底包含哪些模块分别负责什么初次接触 EGO-Planner 时最容易被绕晕的一点是它明明是一个“局部规划器”但代码仓库里塞了地图、可视化、仿真生成器、轨迹服务器一堆东西。这不是作者闲得慌而是因为仿真闭环缺了任何一个模块都跑不起来。我把仓库里的主要模块按“分工”拆了一下plan_manage规划器主体。负责接收目标点、读取地图信息、执行 B 样条轨迹优化然后把轨迹发布出去。sdf_map在线的局部地图管理。虽然 EGO-Planner 叫“无 ESDF”但在仿真里仍然需要有一个“当前障碍物分布”的表示用来生成梯度优化所需的障碍物表面信息。map_generator仿真辅助模块。没有真实传感器时用它生成随机障碍物、走廊或城市环境方便你在 RViz 里直接观察规划效果。odom_visualization可视化里程计、无人机模型、相机视野等。RViz 里那个能跟随无人机移动的 3D 视图就是它的功劳。traj_server/ 控制器接口把规划出来的轨迹喂给底层控制器仿真中通常由 PX4 或一个简化的位置控制器接收。如果你直接在终端里跑roslaunch一次性拉起所有节点会看到多个窗口同时蹦出来。很多新人以为“只要 RViz 能打开就算成功”其实 RViz 只是最终结果的展示层真正决定无人机飞不飞得起来的是上面这一串节点之间的协作。1.2 仿真数据流从传感器点云到轨迹输出中间经历了什么为了后面排查问题方便我建议你先在脑子里画一条数据流水线Gazebo 中的无人机模型带深度相机 → 发布点云和里程计 →sdf_map更新局部地图 → 用户/脚本在 RViz 中发布一个目标点 →plan_manage基于当前地图生成候选轨迹并用梯度优化迭代 → 输出 B 样条轨迹 → 控制器跟踪 → 无人机运动 → 里程计再次更新 → 循环。这条链路里任何一个环节断掉表现出的现象都可能是“无人机没反应”。这话听起来像废话但实际操作中我见过太多人一头扎进规划参数里调max_vel、max_acc最后发现目标点根本没有被订阅到。所以我反复提醒自己做仿真排查的第一步永远是用rostopic echo看话题而不是打开代码一行行找逻辑。1.3 为什么官方 Demo 可以在纯 RViz 环境跑还要再上 Gazebo很多教程会给你展示“效果惊艳”的 RViz 演示障碍物在灰色点云地图中生成无人机轨迹像蛇一样绕来绕去。那个环境下没有真实物理没有相机噪声没有控制延迟一切都过于完美。Gazebo 的意义在于把这三个变量补回来。EGO-Planner 在真实机器人上部署时你不可能拿到完美的障碍物点云也不可能指望里程计毫无漂移。Gazebo 至少能模拟出“传感器数据不完全可靠”“底层控制器有响应延迟”这两个现实约束。所以如果你的最终目标是真机部署别只在 RViz 里自嗨务必把 Gazebo 闭环跑通。实操经验我从一开始就直接在 Gazebo 里验证而不是先在纯 RViz 环境里“爽”一把。虽然前期调试慢一些但后面切换到真机时省了大量时间因为大部分传感器噪声、话题延迟问题已经被仿真暴露过了。2. Ubuntu 22.04 下的环境搭建ROS 和 Gazebo 的版本兼容问题最劝退新手2.1 “gazebo安装ros环境ubuntu22”到底坑在哪每次看到有人搜“gazebo安装ros环境ubuntu22”我就知道对方大概率是照着旧的 ROS1 教程装环境。EGO-Planner 官方仓库依赖 ROS1通常是 Noetic而 ROS Noetic 官方只支持 Ubuntu 20.04。到了 Ubuntu 22.04你当然可以用源码强行编译很多 Noetic 包但你很快会发现Gazebo 的版本、Qt 的版本、OpenGL 的驱动支持全都在跟你作对。我并不是说 22.04 上一定跑不了 EGO-Planner而是说这条路对新手极不友好。你不是在搭环境你是在 simultaneously 和底层的 Python 版本、Boost 库、PCL 版本做斗争。我个人的建议非常明确如果你是第一次跑 EGO-Planner老老实实用 Ubuntu 20.04 ROS Noetic。如果因为特殊原因必须留在 22.04可以考虑两条路装一个 Ubuntu 20.04 虚拟机专门用来跑 ROS1 仿真使用 Docker 镜像比如osrf/ros:noetic-desktop-full把整个环境隔离在容器里。虚拟机方案在性能上确实有损耗尤其是 Gazebo 这种需要 GPU 渲染的程序在虚拟机里画面闪烁和卡顿的概率会明显增加。Docker 方案更接近原生性能但你需要额外解决“容器内打开图形界面”的问题这就引出了 VNC 和 RViz 的经典纠缠。2.2 Gazebo Classic 和 Gazebo SimIgnition千万别混为一谈很多人刚接触时分不清“Gazebo”和“gz sim”再加上日志里出现 “Gazebo Sim, version 8.15.0” 之类的字样就就更晕了。简单区分一下名称常见别名主要集成对象启动命令Gazebo Classicgazebo 9/11ROS1gazebo_ros_pkgs、部分ROS2gazeboGazebo SimIgnitiongz sim、ign gazeboROS2、PX4 SITL、QGroundControlign gazebo或gz sim如果你想跑 EGO-Planner 这种基于 ROS1 的规划器绝大多数教程里出现的是 Gazebo Classic。而 PX4 无人机仿真、QGroundControl 配合 ISITL 时现在主流方案已经切换到 Gazebo SimIgnition Fortress 对应版本号 7 或 8.x。当你看到日志里明确写着Gazebo Sim, version 8.15.0时说明你现在跑的是 Ignition 系列的 Gazebo Sim而不是经典版 Gazebo。这两者的模型格式、插件机制、话题接口差别都不小。如果在搜资料时把二者混着看最常见的后果是你把一个给 Gazebo Classic 写的插件配置文件放到 Gazebo Sim 里然后 Gazebo 界面打不开或者一直闪。2.3 容器里跑图形界面的通用解决办法VNC 和 RViz 纠缠的起点如果你选择 Docker 或远程服务器方案迟早会撞上“vnc桌面无法启动rviz”这类问题。这里先把结论放在前面RViz 能不能启动和你能不能看到桌面是两回事。VNC 环境里 RViz 打不开绝大多数是因为 VNC 默认的虚拟显示器不提供硬件 OpenGL 加速RViz 需要 OpenGL 3.3 及以上版本系统给不了就会直接崩溃或闪退。我常用的临时救急办法是在容器或 VNC 会话里设置软件渲染export LIBGL_ALWAYS_SOFTWARE1 export LIBGL_ALWAYS_INDIRECT0 rosrun rviz rviz设了以后 RViz 大概率能起来但画面可能比较卡。这个方案只适合“确认代码逻辑没毛病”不适合长时间做密集点云可视化。想要流畅体验还是得依赖硬件 GPU 透传比如在 Docker 里挂载/dev/dri设备或在宿主机装好 NVIDIA 驱动后用--gpus all参数启动容器。3. RViz 打不开的完整排查链路从命令行报错到软渲染兜底3.1 先弄清“打不开”发生在哪一步“rviz打不开”这个搜索词背后其实掩盖了至少五种完全不同的故障表现输入rviz后终端报错窗口根本没出现窗口一闪而过然后消失窗口能打开但白屏或黑屏窗口能打开但拖拽视角时崩溃远程连接时提示cannot connect to X server。第一步永远是打开终端手动运行rosrun rviz rviz观察输出。最典型的报错是这类The QGLWidget had a problem with the GL context Could not initialize OpenGL 3.3看到它基本可以锁定到显卡驱动或 OpenGL 支持问题而不是 RViz 本身的问题。3.2 用 glxinfo 快速确认 OpenGL 到底行不行建议先装一下 mesa 工具sudo apt install mesa-utils glxinfo | grep OpenGL version如果输出的版本低于 3.3或者输出GLX: Could not acquire connection那就明确是图形环境的问题。在虚拟机和 VNC 场景里最常见的解法是把渲染方式切到软件渲染export LIBGL_ALWAYS_SOFTWARE1 roslaunch ego_planner rviz.launch另外还要检查DISPLAY变量是否设置正确echo $DISPLAY如果是在 VNC 里显示号通常类似:1如果是普通本地桌面通常为:0。很多时候rviz打不开就是因为在 SSH 远程会话里直接执行rviz却没有设置DISPLAY也没用xhost授权。3.3 VNC 场景下的渲染策略不要和显卡驱动死磕我之前在一台只有核显的服务器上用 VNC 跑整个仿真RViz 经常出现“能启动但动两下就闪退”的情况。后来总结出一套相对稳定的组合在 VNC 服务端的 xstartup 里不要强制启动 GNOME 或 Unity 这种重桌面用轻量级的xfce4或openbox启动 RViz 前设置export LIBGL_ALWAYS_SOFTWARE1在 RViz 的 “Panels → Display” 里把点云显示的分辨率调低例如Decay Time调小、不要加载过大的全局地图如果还崩溃直接删掉~/.rviz下可能已损坏的配置文件再重试rm -rf ~/.rviz这个操作听起来不优雅但确实解决了不少“RViz 上次崩溃后一直打不开”的情况。3.4 硬件加速到底该不该折腾有些人在 VNC 里想了各种办法开硬件加速我觉得要分场景。如果你只是跑 EGO-Planner 的仿真调试软渲染完全够用毕竟 RViz 里主要看轨迹和点云不需要 60FPS 的游戏级流畅度。但如果你想在 RViz 里同时看三四个大点云、渲染复杂网格模型软渲染会觉得“卡成 PPT”这时才值得去研究显卡直通、NVIDIA Container Toolkit 之类的高级操作。个人心得不要在 VNC 的图形性能上花超过半天时间。如果你发现 VNC 里怎么调都卡果断换回本机显示器或使用支持 GPU 的远程桌面方案比如专业远程桌面软件或局域网串流时间成本会更低。4. Gazebo 界面一直闪先从渲染和传感器两个方向夹击4.1 闪烁的本质GUI 刷新和传感器渲染抢同一份资源和 RViz 打不开不同“为什么gazebo界面一直在闪”更像一个“性能及资源竞争”问题。Gazebo 的界面不只是显示静态模型它内部有大量传感器插件在更新数据包括相机图像、激光雷达、深度点云等。如果你的 GPU 或 CPU 比较紧张GUI 刷新线程和传感器渲染线程就会互相抢资源表现出来就是界面闪、模型闪、或者场景闪烁不定。还有一种典型情况是双显卡机器NVIDIA Optimus 之类没有设置好默认显卡。系统一会儿用独显渲染一会儿用核显渲染切换过程中 Gazebo 的画面就会出现周期性闪烁或黑块。4.2 我的三步排查顺序照着做基本能定位第一步先把无关节点停掉包括 RViz单独启动 Gazebogazebo --verbose如果单独启动时还闪说明问题出在 Gazebo 本身或系统渲染环境。如果单独启动不闪但一上规划器就闪那通常是传感器负载或话题通信压力太大。第二步检查显卡驱动状态sudo apt install mesa-utils glxinfo | grep OpenGL renderer看输出里是NVIDIA、AMD还是llvmpipe。如果是llvmpipe说明当前用的还是软件渲染Gazebo 界面闪烁完全正常因为软件渲染扛不住多视角 3D 刷新。第三步尝试调整 Gazebo 的图形渲染偏好。在 Gazebo 窗口菜单栏的 “Edit → Preferences → Rendering” 里把阴影质量调低关闭不必要的后处理效果看闪烁是否缓解。4.3 虚拟机和高分辨率屏幕下的特殊处理如果你是在 VMware、VirtualBox 或云服务器虚拟机上跑 Gazebo闪烁概率非常高。这类虚拟机的 3D 加速能力有限建议在启动虚拟前打开虚拟机的“3D 加速”选项如果还是不行干脆接受现实用 Gazebo 的 headless 模式跑服务端再用 RViz 或者别的前端去看状态。在主机屏幕分辨率很高的场景下如 4K 屏幕Gazebo 界面闪烁也可能是因为 GPU 的同步信号和屏幕刷新率不匹配。可以试试设置export __GL_SYNC_TO_VBLANK0 gazebo这个环境变量对 NVIDIA 显卡比较有用核心思想是取消垂直同步导致的强制等待。4.4 顺带说一说 “gazebo sim, version 8.15.0 qgroundcontrol” 的组合如果你不是跑 EGO-Planner而是用 PX4 无人机 SITL经常会看到gz sim和一个版本号同时旁边还开着 QGroundControl 地面站。这个组合下如果 Gazebo 界面一直闪我的建议是把 Gazebo 的 GUI 当作辅助不用一直盯着它直接看 QGroundControl 里的飞行数据和地图。你可以用服务端模式只跑物理和传感器不加载图形界面避免闪屏干扰注意力。ign gazebo -s -r --world-name my_world-s表示 server-only-r表示开始运行。这样 Gazebo 仍然在实时仿真但不弹出 3D 窗口所有状态通过话题发送出去。对于只关心规划和控制的人来说这比在闪屏里硬扛要舒服得多。5. EGO-Planner 仿真实战在 RViz 里给目标让无人机在 Gazebo 中真正动起来5.1 启动前先确认三个话题避免“虚假的沉默”很多人在跑 EGO-Planner 仿真时无人机一动不动第一反应是“规划器没工作”。但实际原因是话题名称根本没对上。建议启动完整仿真后立刻打开一个新终端确认以下三类话题在线rostopic list | grep -E odom|depth|goal|traj至少应该看到类似这些名字具体前缀以你用的无人机模型为准里程计/odom或/uav/odom之类深度相机点云/camera/depth/points或/d435/depth/points目标点/goal或/planning/target规划输出轨迹/planning/trajectory或/traj_server/trajectory。如果目标点的话题和规划器实际订阅的话题不同你在 RViz 里点目标点点到手抽筋无人机也只会纹丝不动。5.2 RViz 里“给目标”的正确姿势EGO-Planner 的仿真界面里一般会在 RViz 工具栏提供类似Goal或2D Nav Goal的工具。选择以后在场景中点击并拖拽出一个方向箭头即可设定目标位置和期望朝向。注意几个容易忽略的细节目标点不要放在当前障碍物内部否则规划器会一直报 “invalid goal”目标点离无人机太近时规划器可能认为“已经到达”不会重新规划如果你启用了多个规划器要确认发目标点时对应的topic是当前正在运行的规划器订阅的那个。通常点击目标后RViz 里会很快出现一条彩色的 B 样条轨迹同时 Gazebo 里的无人机会开始缓慢加速。如果轨迹出现了说明规划器在工作剩下的问题多半出在控制器如果轨迹没出现优先检查目标点话题和地图是否更新。5.3 轨迹卡住、规划失败、无人机乱抖这是我在 Gazebo 里最常见的三个问题轨迹卡住不更新多半是局部地图太久没有变化。在 Gazebo 中深度相机点云可能因为视野范围太小长时间没有扫描到新的障碍物EGO-Planner 会认为当前环境已经“够安全”于是不再频繁重规划。这不是 bug而是局部规划器的预期行为。你可以主动给一个绕远一点的目标点或者把深度相机的视角范围调大。规划失败但 RViz 没反应打开运行规划器的终端窗口看有没有类似failed、invalid、trajectory optimization timeout的日志。如果是优化超时可以适度增加规划器允许的迭代次数或者降低地图分辨率减少单次优化需要处理的障碍物点数量。无人机乱抖这通常是控制增益和规划器速度上限不匹配导致的。比如规划器允许最大速度 5m/s但底层控制器在 1m/s 时就开始过冲整个闭环就会震荡。在仿真里我习惯先把max_vel降到 1~2m/s把max_acc也调小先验证闭环通了再逐步拉大。# 以动态调参为例很多参数可以用 rqt_reconfigure 在线改 rosrun rqt_reconfigure rqt_reconfigure如果仓库里没配置dynamic_reconfigure那就只能改参数文件重启节点改完后再跑一次对比差异。5.4 善用地图生成器先在简单场景里验证再上复杂场景EGO-Planner 的公关仓库里一般会带map_generator可以随机生成障碍物。我的建议是第一次跑仿真时不要直接选随机复杂地图先用一个走廊地图或稀疏障碍物地图让规划器在一个相对干净的环境里跑通闭环。等确定 RViz 和 Gazebo 的话题链路都正常了再切到密集障碍物场景测试规划器的真实避障能力。这样做的好处是如果系统失败你能快速判断是“环境太复杂导致规划算法失效”还是“底层话题没通导致整个仿真压根没跑起来”。这两种问题的排查方向完全不同。6. 跳出四旋翼Panda 机械臂、Blender 模型和二维码标签的仿真痛点6.1 Panda 机械臂 Gazebo 仿真和无人机仿真有什么本质差异“panda机械臂gazebo仿真” 是另一个热度很高的搜索词。Panda 机械臂Franka Emika Panda在 Gazebo 里仿真的核心路径通常是 MoveIt ros_control Gazebo而不是 EGO-Planner 那一套规划器。如果你之前只玩过无人机仿真转过来做机械臂仿真时最容易犯的错是沿用“话题直接发目标点”的思路。机械臂仿真的主流方式是用 MoveIt 的PlanningScene和move_groupaction 接口而不是往某话题塞一个PoseStamped就完事。在 Gazebo 里跑 Panda 时几个高频坑包括机器人模型文件URDF/SDF里缺少真实传动装置transmission配置导致关节完全不受控ros_control的硬件接口名称没有和 Gazebo 插件对齐MoveIt 的规划组planning group名称写错导致运动规划器找不到臂的关节。我个人的调试策略是先忽略运动规划器直接用effort_controllers或position_controllers给每个关节发目标位置确认 Gazebo 里的机械臂能产生正常运动再去接 MoveIt。顺序反过来的话你很可能会被“错误到底在 Gazebo 还是 MoveIt”这个问题卡到崩溃。6.2 Blender 导出 Gazebo 模型的三个致命细节单位、轴和纹理“blender导出gazebo模型”也是一个高频搜索词这背后是真切的痛。很多人在 Blender 里建了一个漂亮的模型导出成.stl或.dae放进 Gazebo 后发现模型“躺在地上”或者“大得没边”。常见的三个原因如下单位问题Blender 的默认单位是米但有些人会切换到厘米或英寸。Gazebo 和 URDF 默认使用米。导出前务必在 Blender 的“场景属性”里把单位改回米制。轴向问题Blender 默认的 Z 轴向上部分建模软件习惯 Y 轴向上。如果导出的模型在 Gazebo 里横躺优先检查.dae或.stl中模型的朝向并在visual和collision里加上origin rpy.../修正。纹理问题.dae文件引用的纹理路径必须是相对路径且纹理图片要放在模型包可访问的目录里。很多人导出后直接把.dae丢进Gazebo忘记带材质贴图结果模型变成一片惨白。更稳妥的做法是不要从零写 SDF而是用 Blender 插件导出成 URDF或者在 ROS 里用assimp工具检查导出文件。6.3 “ign gazebo加载二维码”这类需求本质上是传感器仿真当你搜“ign gazebo加载二维码”时你可能是在做视觉目标检测仿真。Gazebo SimIgnition和 Gazebo Classic 加载二维码方式完全不同。在 Gazebo Classic 里你可以用visual插件把一个带有二维码纹理的平面贴到模型上再用ar_track_alvar或apriltag_ros识别。关键是二维码模型必须位于相机视野范围内且周围光线要足够Gazebo Classic 默认的光照有时会让贴图反射造成识别失败。在 Gazebo SimIgnition里建议使用官方提供的视觉标签传感器功能或自己创建一个带有二维码纹理的实体模型。如果你只是想在 ROS2 里测试视觉检测更轻量的做法是直接发布一个模拟的识别结果而不是真的在仿真场景里渲染二维码图片。先保证下游检测逻辑能跑通再回头折腾“如何让仿真环境里的二维码更逼真”。6.4 ROS2 用户接触 Gazebo 仿真的最佳路径现在越来越多新项目直接基于 ROS2 Humble 开发而 EGO-Planner 官方毕竟还偏 ROS1。如果你想在 ROS2 生态里跑类似规划器仿真需要先搞清楚 ROS2 版本的 Gazebo 集成方式和 ROS1 完全不同ROS2 使用gazebo_ros_pkgs的 ROS2 分支launch 文件是 Python 格式节点生命周期管理机制也和 ROS1 不同话题名经常带~重映射调试时要用ros2 topic list而不是 ROS1 的rostopic listTF 树的维护方式没变但tf2的 API 和消息类型跟 ROS1 存在细节差异。其实还有一个选项用 ROS1 容器跑 EGO-Planner再用ros1_bridge把目标点和轨迹消息桥接到 ROS2 侧的上层应用。这样既保住了 EGO-Planner 成熟稳定的规划算法又让整个系统能接入 ROS2 的下游组件。桥接会带来一定延迟但仿真阶段完全够用。经验总结不要把 ROS1 和 ROS2 想象成“同一个系统的两版本”它们在很多底层机制上已经分道扬镳。做仿真之前先想清楚整个项目最终的部署环境再用最小的成本把规划算法和仿真器跑通而不是先跳进“全链路 ROS2 化”的兔子洞。最后再分享一个我自己养成的习惯无论遇到 RViz 打不开、Gazebo 闪屏还是无人机不动作我都会先看终端日志里有没有明确报错再决定动环境还是动代码。很多时候我们急着改参数反而把问题带偏了方向。找一台配置普通的电脑装好 Ubuntu 20.04 ROS Noetic按先官方 Demo、后自定义场景的顺序来你会发现自己很快就能把 ego-planner 仿真的每个模块都摸透。
