也说 ego-planner 仿真从第一次跑通到把坑填平做机器人路径规划的人大概率绕不开 ego-planner 这个名字。它最吸引人的地方不是论文里的公式多漂亮而是开源代码拿来就能用——仓库里一拉编译完就能在 RViz 里看到那标志性的绿色轨迹刷出来那种感觉确实会上瘾。但如果你真打算从头开始搭这套仿真从 RViz 可视化一路验证到 Gazebo 里的完整闭环中间会遇到一堆文档里不会写、Issue 里也翻不到的问题。这篇文章就按我自己的实操顺序来写先讲明白这套系统到底是怎么组织的再带你过一遍 RViz 里能看到的每个关键元素接着转战 Gazebo 做完整仿真最后把高频踩坑点集中梳理一遍。全程只讲 I 实操过、验证过的东西不说废话。1. ego-planner 项目全景它解决什么问题仿真环境怎么搭1.1 ego-planner 的核心思路和代码结构ego-planner 全称是EGO-Planner: An ESDF-free Gradient-based Local Planner核心卖点就是不用建 ESDF欧氏符号距离场地图直接用梯度优化来生成局部轨迹。传统方法比如 Fast-Planner要先花大量计算资源去维护一个距离场才能得到碰撞代价的梯度ego-planner 换了个思路把碰撞检测从体素栅格采样变成对轨迹上的点做射线投影算出一个“向量的推力”来代替梯度。这么做最直接的好处就是计算量下来了在嵌入式平台和真实无人机上都能跑得很稳。代码层面整个项目可以拆成两部分ego_planner 主包包括traj_opt轨迹优化器、planner_manager规划器管理、bspline_optB样条优化、grid_map相关的代价计算等模块。trajectory_prediction 包用来预测周围动态障碍物的轨迹仿真里主要给室内动态场景用。编译流程不用多说ROS 的标准三步走catkin_make或者catkin build都行。我习惯用catkin build因为编译报错时能看到更细的模块信息。提示如果你用的是 Ubuntu 20.04 ROS Noetic建议先确认 Eigen 和 osqp 的版本。ego-planner 对 Eigen 3.3.x 支持最好osqp 用默认安装就行但千万不要用系统自带的旧版不然编译到traj_opt时会报一堆模板错误。仿真环境这块官方仓库直接给了一套simulator包里面封装好了四旋翼动力学模型和传感器模型也就是说你不一定非得用 Gazebo。只做算法验证的话RViz 的仿真器就完全够用但如果要验证“规划指令真的能控制飞机飞起来”那就必须上 Gazebo。1.2 仿真环境选型Ubuntu 版本、ROS 版本、Gazebo 版本仿真环境选型是最容易被低估的一步。很多教程默认你已经有了一套能跑的 ROS/Gazebo但实际中“RViz 打不开”“Gazebo 界面一直在闪”“VNC 桌面无法启动 rviz”这类问题九成以上都是环境匹配的问题。我自己的推荐组合是软件推荐版本备注操作系统Ubuntu 20.04 LTS别用 22.04除非你愿意踩 ROS1 兼容坑ROSROS Noetic对 ego-planner 支持最好Gazebo9.x / 11.xNoetic 自带的是 11.x显卡驱动NVIDIA 470开源驱动跑 RViz 会很痛苦Eigen3.3.7过高或过低都有编译坑这里特别想吐槽一句不要在虚拟机和远程 VNC 里跑 RViz。RViz 是 OpenGL 渲染程序在虚拟机里要么白屏要么启动直接闪退VNC 里更是连窗口都出不来。你如果搜过“vnc desktop cant start rviz”就会发现一堆人在问但结论几乎都是同一个换物理机、换本地桌面别跟虚拟化死磕。2. RViz 可视化先让规划结果“看得见”2.1 RViz 里到底要看什么ego-planner 的 RViz 界面其实很有代表性它能直接反应规划器的内部状态。第一次跑起来的时候你会看到绿色的 B 样条轨迹这个是优化后的最终轨迹也是飞控实际要跟踪的参考线。你给个目标点绿色轨迹会嗖地一下生成非常直观。红色的八叉树地图OctoMap这是环境感知模块构建的地图。注意一个点ego-planner 规划时虽然不依赖 ESDF但它仍然需要占用地图来判断碰撞只是碰撞代价的计算方式变了。蓝色的航线点表示当前全局路径的航点序列。当前速度/加速度箭头在轨迹上能看到拉出来的向量如果你做过轨迹优化相关的论文复现看到这个会特别亲切。所以 RViz 不只是个“可视化窗口”它其实是调试规划器的一层“透视镜”。比如你观察绿色轨迹穿墙那就是碰撞代价计算有问题看到蓝色航点乱跳那是前端路径搜索出了问题。从 RViz 里能直接判断优化器收敛没有——轨迹在终点附近来回抖动多半是代价权重没调好。2.2 坐标系与话题关系可视化背后是关键数据流这一步很多人会忽略但它直接决定了你是否能理解这个系统。ego-planner 仿真环境里涉及几个坐标系map全局坐标系地图和轨迹都在这个坐标系下表示。odom里程计坐标系用作控制反馈。body或者base_link机体坐标系IMU 的数据在这里。RViz 里的 Fixed Frame 默认是map如果你手贱改成odom大概率看不见完整轨迹或地图因为 TF 树里少了一层变换许多 topic 的信息会被过滤掉。数据流的关系大概是仿真器 / 真机发布odom和imu话题ego-planner 接收传感器数据和目标点做规划规划结果发布到/planning/pos_cmd位置控制指令仿真器接收位置指令更新无人机状态新的状态又发布出去形成一个闭环。记住这条链路后你排查问题就有思路了RViz 没轨迹先看/planning/pos_cmd有没有输出有输出但飞机不动看仿真器是否订阅了这个话题。很多人一上来就重装 Gazebo结果最后发现自己忘记在 launch 文件里加true参数这种错误很浪费时间。2.3 rviz 打不开、白屏、显示异常的集中排查“rviz 打不开”是我在热词里看到出现最多的问题我这里集中把原因和排查步骤列出来窗口一闪而过大概率是.config里的 RViz 配置损坏了。删掉~/.config/ros.org-rviz文件夹再重开基本能解决。启动后全白 / 无法加载地图先查Fixed Frame是否设为map再查 TF 树是否完整。终端里跑rqt_tf_tree能看到有没有断链。界面能开但过一会儿卡死地图体素开太大或者分辨率设太小八叉树更新会把 CPU 打满。仿真阶段resolution设 0.1 就够不要为了“看得清楚”设到 0.02。VNC 里打不开 RViz上面说过因为是 OpenGL 渲染问题。最省事的方案是在本机跑 RVizGazebo 可以放在服务器上跑。如果你非要用 VNC要么装virtualgl要么换x11vnc配合xfce4实测会比默认 VNC 配置好一些但依然不如物理机流畅。独家心得排查 RViz 别盯着程序改。先用rosrun rqt_console看日志级别很多显示异常的直接原因是某个 topic 的 QoS 策略不兼容在终端里会有明确的 warning 提示只是被默认日志级别藏起来了。3. Gazebo 实战在物理仿真里跑通 ego-planner3.1 Gazebo 环境搭建模型加载与界面闪避坑如果只是 RViz 跑跑仿真你还没碰到 ego-planner 的“精髓”——物理仿真。要验证轨迹跟踪效果让飞机在 Gazebo 里真的飞起来才算完整。这个阶段的环境搭建比较繁琐特别是“Gazebo 界面一直在闪”这个问题太典型了。界面闪烁的原因通常有三个显卡渲染问题、模型材质解析问题、Gazebo 版本兼容问题。前两个更常见。显卡渲染问题多数时候是因为没有启用硬件加速。Gazebo 用的是 OGRE 渲染引擎在虚拟机或者没有 proper 驱动的机器上会退化成软渲染帧率低到个位数界面看起来就是一直在闪。解决方式检查glxinfo输出确认OpenGL renderer是不是你的独立显卡。如果是 VMware/VirtualBox 这类虚拟机建议直接放弃挣扎用物理机。模型材质解析的问题比较隐蔽。你用solidworks或blender导出的模型进 Gazebo如果.dae里的材质路径写的是相对路径Gazebo 解析时常会因为找不到纹理而不断重试表现出来像是界面闪烁。解决办法在.world文件里把模型路径和纹理路径全部改成file://或绝对路径不要用相对路径。Gazebo 版本的问题主要体现在老模型加载上。比如网上流传的一些四旋翼模型是用 Gazebo 7/8 版本做的放到 Noetic 自带的 Gazebo 11 里就会因为传感器插件 API 变化而加载失败一次失败之后 Gazebo 界面会陷入反复加载的循环看起来也是“一直闪”。处理方式找适配 Gazebo 11 的模型或者手动改一下 plugin 的 XML 标签。注意模型加载慢不是 bug。Gazebo 首次启动会从网络下载模型库的索引文件如果网络不好启动界面会停在“Loading model...”很久。你可以提前手动拉取gazebo_models仓库放到~/.gazebo/models下这样能省掉不少等待时间。这种方法不涉及任何敏感操作只是把开放模型库提前准备好。3.2 从 RViz 到 Gazebo话题打通与被忽略的 TF在 RViz 里跑 ego-planner 的时候你用的是官方附带的simulator它内部直接发/odom、/imu也能直接接收位置指令更新状态。但到了 Gazebo我们要坐的是另一条船Gazebo 里跑着四旋翼的物理模型模型上挂着 IMU 插件、GPS 插件、电机插件这些插件发出来的话题格式和 ego-planner 默认订阅的对不上就需要自己写转换节点或者调 launch 文件的 remap。我最常遇到的问题是 TF 对不上。ego-planner 的规划和控制节点默认要求 TF 树里存在map - odom - base_link这条链路。Gazebo 模型如果没有加载机器人状态发布器robot_state_publisher那base_link到imu_link的 TF 往往只有模型里的固定关节而odom到base_link的变换完全缺失。结果就是 RViz 里看得到飞机模型但规划器直接罢工。排查方法在一开始就说过跑rqt_tf_tree看树形结构。正常链路至少要有map - odom - base_link - imu_link如果中间断了在 launch 文件里补一个tf2_ros的static_transform_publisher就能解决。要特别注意的是这个 static TF 的坐标要跟你的 Gazebo 模型初始位姿匹配不然飞机会在天上跑、规划器却以为它在原地不动。顺带说一个 Gazebo 里跑 ego-planner 时容易忽略的点时钟源。ego-planner 的仿真环境默认用 ROS 的/clock话题同步时间但 Gazebo 默认发布的时钟话题在/clock而仿真器节点订阅的是use_sim_time为 true 的时钟。如果你在 launch 里没把use_sim_time设成 true会出现“RViz 里有轨迹、Gazebo 里飞机不动”或者“速度慢十倍”之类的现象。我第一次跑的时候就觉得奇怪明明规划正常飞机却像在放慢动作后来才发现就是少了这一行参数。3.3 四旋翼动力学与参数为什么仿真能飞、真机未必能飞很多人跑通 Gazebo 仿真后会顺手把自己调的 PID 参数直接搬到真机结果摔机这是最惨烈的教训。这里要明确一个概念Gazebo 里的四旋翼模型就算物理引擎再真实它和真机之间也有差距。Gazebo 的四旋翼电机模块通常被建模为“期望转速到推力/扭矩”的一阶惯性环节。也就是说你给的电机转速指令会平滑地映射成力和力矩但真实的电机响应还受到电压、桨叶气动干扰、风场、机体振动的影响这些是 Gazebo 里极难模拟的。因此你在仿真里能跑通的 PID 参数至少要做三处修正减少微分项D项仿真里的 IMU 数据是理想的高斯噪声真机的 IMU 有一个明显的高频振动分量D 项增益过大会把振动放大成高频抖动严重时飞控会直接饱和。检查推力模型Gazebo 里的推力系数一般是恒定的但真机的电机效率会随着电量下降而下降。如果你在仿真里用的是悬停油门 50% 的参数真机在低电量时可能得 60% 以上才能悬停。验证时间常数仿真电机响应时间可以调到 0.05 秒以内但真机的电调加电机整体响应往往在 0.1~0.2 秒控制周期和带宽完全不同。这也就是说ego-planner 的 Gazebo 仿真真正适合验证的是规划轨迹的合理性和震动程度而不是直接验证控制参数。你飞真机时轨迹跟踪控制要重新整定参数这是很基本但很多人忽略的常识。4. 常见问题与排查技巧实录4.1 高频问题速查表直接给一张表都是我平时踩坑总结出来的。按照“现象—原因—解决”三列来列现象最常见原因解决方式rviz 打不开 / 窗口一闪而过RViz 配置损坏 / OpenGL 渲染问题删配置、换物理机、更新显卡驱动Gazebo 界面一直在闪显卡渲染 / 模型材质 / 版本不兼容按 3.1 节的三个方向逐个查Gazebo 加载模型卡住不动模型库下载失败或网络不通手动放模型到~/.gazebo/models有轨迹但飞机不动use_sim_time没设置或 TF 断链检查 launch 参数补 TFRViz 地图黑屏Fixed Frame 错误 / Topic QoS 不匹配设为 map检查 QoS 策略优化轨迹抖动代价权重过大/时间惩罚过小调w_obs和时间分配权重键盘控制没反应目标点话题名对不上确认/goal话题和 Rviz 的 2D Nav Goal 发布一致4.2 三个印象最深的坑第一个坑是RViz 里看不到地面Grid。我一开始以为是自己配置问题折腾了半天最后发现是 RViz 的默认视角在 map 坐标系下离地面太远是个纯视角问题把相机拉到近处就正常了。但这个现象配合“Fixed Frame 错误”一起出现的时候很容易让人误以为环境没启动好。第二个坑是roslaunch 启动顺序导致的偶发失败。ego-planner 的仿真需要先启动地图、再启动规划器、最后启动控制循环如果地图节点还没完全 load 完、规划器就开始收点云可能什么事都没有也可能规划器直接崩溃。解决方式是加延时启动实测sleep 5基本能避免九成以上的偶发问题。如果你用 systemd 服务或开机自启动脚本跑仿真一定要把等待逻辑写好。第三个坑比较冷门trajectory_prediction包的动态障碍物话题和 Gazebo 里的模型对不上。室内动态场景仿真的障碍物是用虚拟多边形表示的它不从 Gazebo 感知而是独立发布。如果你把这个包去掉仿真也能跑但你就看不到“动态障碍物避开”的效果。排查方法是在 RViz 里加一个PolygonArray显示看有没有对应的 topic 在发数据。4.3 让仿真更接近实物的三个小技巧跑通只是第一步要让验证结果有参考价值建议再做三件事注入噪声默认的 imu 话题噪声太小增益到真实水平后再测路径跟踪会提前暴露很多问题。加风扰Gazebo 有wind_plugin可以直接叠加定常风和阵风用来测规划器的鲁棒性。用真机地图如果有过实际场地扫描的 pcd 地图文件转成 octomap 喂给仿真器比用程序生成的地图更接近真实使用场景。这三个技巧能让你的仿真结论更可信同时也是从“能跑”走向“会调”的必经之路。5. 写在最后踩过这些坑之后的一点体会坦白说ego-planner 的仿真代码质量在学术开源项目里算不错的结构清晰、注释也够用但它的官方文档非常简略几乎没有讲环境适配。你照着 README 跑一遍可能没问题但一旦自己加传感器、换地形、改模型就会进到“没人能帮你”的灰色地带。这时候最靠谱的排查方式不是去论坛发帖而是把数据链路捋一遍——从话题、TF、QoS、时间戳这四个维度去对百分之八十的问题都能自己找出来。我个人实际操作中的体会是调仿真环境和调规划器本身一样都需要“最小化复现”的思路。先跑官方 demo再逐步加自己的改动每加一步验证一次。千万别一上来就改一堆参数不然出了问题你根本不知道是哪个变量导致的。最后再分享一个小技巧在命令行里跑仿真的时候开一个htop窗口盯 CPU 占用。ego-planner 的轨迹优化非常快但地图更新在低端配置的电脑上特别吃 CPU如果 CPU 占用持续接近 100%说明地图分辨率或传感器频率设置太高先降一档再继续调算法。这能帮你把“环境问题”和“算法问题”快速区分开省下大量排查时间。