ROS2与Gazebo仓库动态仿真：差速轮双RGBD建图导航实战

简介：本资源是一套面向机器人算法开发者与ROS/Gazebo初学者的动态物流仓库仿真项目，聚焦于在Gazebo中构建具备实时交互能力的仓储环境，并通过CMake实现可复现、易扩展的工程化构建。项目完整覆盖三维模型（24个DAE）、物理世界定义（13个SDF、1个WORLD）、插件逻辑（PLUGINS目录）、传感器配置（13个CONFIG）、地图与可视化（3个PGM、2个YAML、1个RVIZ）等核心模块，共104个文件，总大小9.52MB。已有350人学习下载，说明其在教学实践与算法验证场景中具备较强实用性。用户解压后可直接基于CMakeLists.txt完成编译，配合LAUNCH脚本一键启动含移动机器人、货架、输送带及动态货物的完整仿真环境；目录结构规范，src/model/worlds/plugins/launch分层清晰，附带LICENSE与README.md，便于二次开发与课程实验复用。 上个月接了一个仓库场景仿真方案验证的任务，需求听起来挺清晰：在Gazebo里搭一个带动态障碍物的仓库环境，放一台差速轮底盘小车，车上挂两颗RGBD传感器，用ROS2写几个话题节点把数据收上来、再发出去，后面还要接slam_toolbox和nav2跑建图导航。听起来就是一套很标准的仿真流程，结果实际动手才发现，坑全藏在细节里——CMake版本不匹配、URDF传感器坐标系没对齐、Gazebo插件找不到函数符号、虚拟机里跑得跟放幻灯片一样。这篇文章就把我从0到1搭建这套环境的过程完整记录下来，包括CMake构建环境的版本处理、仓库动态场景设计、差速轮模型和双RGBD传感器挂载、ROS2话题通信代码，以及最后slam_toolbox和nav2联调验证的实测结论。无论你是刚入门Gazebo仿真，还是已经在用ROS2但被传感器建模和依赖版本折磨过，这篇都应该能帮你省下不少排查时间。

1. 仓库动态环境仿真的需求拆解：为什么是差速轮加双RGBD

1.1 选型逻辑：Gazebo对比Mujoco，场景复杂度决定方案

先说选型。任务要求的是“仓库中的动态环境”，这个需求里有两个关键词，一个是“仓库”，一个是“动态”。仓库环境本质上是结构化室内场景，有货架、墙体、通道、托盘，这些东西对传感器仿真、碰撞检测、导航规划都有要求；而“动态”意味着环境里还会有移动的障碍物，比如自动导引车、搬运机器人、叉车，这些物体在场景里穿梭，会直接影响建图和导航的稳定性。

Mujoco这些年确实很火，尤其在强化学习和控制算法验证上，物理求解快、渲染性能好，社区资源和模型也越来越多。但真到了“仓库环境+传感器仿真+ROS2话题通信+导航算法验证”这个组合，Mujoco的短板也很明显：它和ROS2的集成没有Gazebo那么顺滑，传感器仿真的完整度、插件生态、URDF/SDF的兼容性都不如Gazebo直接。Gazebo最值钱的地方是它天生就是为机器人仿真设计的，gazebo_ros插件族把传感器、模型、物理仿真和ROS2话题无缝打通，你几乎不需要做额外适配就能把仿真里的传感器数据以标准消息推给导航栈。

所以选型结论很直接：如果只做控制算法验证、跑强化学习，Mujoco足够；但如果要验证完整机器人系统，包括传感器感知、建图、导航、避障，Gazebo仍然是更稳妥的选择。仓库环境需要足够复杂的传感器交互和物理反馈，Gazebo在这方面积累成熟，踩坑资料也多，更适合作为这套方案的主战场。

1.2 需求拆解：动态障碍物、双传感器覆盖与建图导航的关系

把需求拆开看，这个任务其实有四个层次：环境搭建、机器人建模、通信实现、算法验证。环境搭建是基础，机器人建模是载体，通信是桥梁，算法验证是最终目标。

动态环境这一点重点说。很多人做Gazebo仿真习惯搞一个静态地图，放几面墙几个货架就完事，但“动态”才是这个项目验证的核心价值。动态障碍物对slam_toolbox的影响是直接的：建图时障碍物在移动，激光扫描会把移动物体纳入地图轮廓，导致地图出现“鬼影”；导航时更明显，局部代价地图如果更新频率不够，规划路径可能直接穿过移动障碍物，机器人和障碍物就会在仿真里硬碰硬。

双RGBD传感器也是围绕这个需求设计的。一颗RGBD放前向，负责前进方向的障碍物感知和避障；一颗放后向，负责倒车和侧向盲区的补盲。两颗传感器的数据可以为depthimage_to_laserscan提供双路2D激光扫描源，也可以分别订阅、融合处理，为后续的感知算法预留接口。在动态环境里，双传感器最大的价值是“就算转个身，也不会瞬间丢失环境感知”，这对导航可靠性非常重要。

1.3 环境版本搭配：一张表理清Ubuntu、ROS2与Gazebo的关系

这个项目对版本非常敏感，我在本地踩过坑，也看过群里不少人迷茫。ROS2不同发行版对应的Gazebo方案差异很大，直接影响后续所有操作。这里给出一份实测可行的搭配组合。

系统	ROS2发行版	Gazebo方案	适配建议
Ubuntu 22.04	Humble	Gazebo Classic 11（默认apt源）	最稳，slam_toolbox和nav2集成资料最多
Ubuntu 24.04	Jazzy	Gazebo Harmonic（新架构，默认）	新项目可用，但gazebo_ros插件API有变化
Ubuntu 24.04虚拟机	Jazzy	Gazebo Classic（需额外配置）	兼容性一般，性能损耗明显
WSL2	Humble/Jazzy	视WSLg和GUI支持情况	适合轻量测试，复杂场景建议虚拟机

如果你照搬的是网上基于Ubuntu 22.04 + Humble + Gazebo Classic 11的教程，在24.04上翻车的概率很高，因为Gazebo Harmonic和Classic在插件接口、launch文件写法上都有差异。仓库环境仿真本身就有一定复杂度，我的建议是不要在上环境时给自己增加不确定性，Ubuntu 22.04 + Humble + Gazebo Classic是最省心的基线。如果一定要用24.04，那CMake版本管理就更要谨慎，这正好是下一章要展开的内容。

2. CMake构建环境：从版本回退到生成器报错的清理过程

2.1 CMake为什么成了项目启动的第一道坎

很多人会忽略CMake这种“底层工具”，觉得装好ROS2和Gazebo就能跑。但实际做下来，CMake版本问题几乎卡住了项目启动的第一周，这也是为什么这个项目被压缩成“_CMake_下载.zip”这种附带CMake处理内容的压缩包——构建环境问题确实值得单独打包记录。

CMake版本问题具体表现是什么？第一，Ubuntu 24.04自带CMake 3.28，而很多ROS2包和依赖库（尤其是Gazebo Classic 11相关的构建链、旧版OGRE、Qt5组件）在更高版本CMake下的配置行为有变化，轻则警告，重则直接构建失败。第二，如果你从网上直接下载别人打包的源码工程，里面大概率带着对方机器的CMakeCache.txt，缓存里的生成器和路径信息跟你本地完全不匹配。

“如何将ubuntu中cmake降到3.16.3”这个需求在搜索里很热门，还真不是个例。3.16.3这个版本是很多成熟ROS2工程和Gazebo相关依赖的舒适区，最低版本要求普遍能被它满足，又不会因为太新而触发一些兼容性bug。这里说的“降到3.16.3”，未必是你要精确回到这个老版本，而是代表一个思路：把CMake版本纳入工程管理，而不是任由系统版本摆布。

2.2 源码编译回退CMake到3.16.3的完整步骤

如果你决定把CMake固定到3.16.3，最可靠的方式是源码编译安装到独立目录，再用update-alternatives管理版本切换，尽量不要直接覆盖系统自带CMake，免得影响其他依赖。

# 先安装编译依赖 sudo apt update sudo apt install build-essential libssl-dev # 下载CMake 3.16.3源码 wget https://cmake.org/files/v3.16/cmake-3.16.3.tar.gz tar -xzf cmake-3.16.3.tar.gz cd cmake-3.16.3 # 配置并编译，prefix指定到独立目录 ./bootstrap --prefix=/opt/cmake-3.16.3 make -j$(nproc) sudo make install # 配置版本切换 sudo update-alternatives --install /usr/bin/cmake cmake /opt/cmake-3.16.3/bin/cmake 100 sudo update-alternatives --config cmake # 验证 cmake --version

这里有几个细节值得注意。bootstrap阶段如果没有安装libssl-dev，会在处理OpenSSL相关组件时报错；make -j后面的核数不要盲目拉满，虚拟机里跑的读者尤其注意，内存不够的时候并行编译很容易OOM，我一般用-j4到-j8之间。另外这个源码编译过程在虚拟机里会等一会儿，属于正常现象，不要中途Ctrl+C。

如果你不想编译源码，也可以试试pip安装特定版本CMake：pip install cmake==3.16.3，但这个方案依赖Python环境和系统库，成功率看运气，源码编译是更可控的路径。

2.3 CMakeCache与Generator残留引发的构建失败及处理

“cmake error: error: generator : visual studio 16 2019 does not match the gen”这个报错，很多在Windows和Linux之间来回切换的工程都会遇到。原因其实很简单：CMakeCache.txt里残留了Windows上Visual Studio 16 2019生成器的记录，把工程文件拷到Linux下继续cmake时，CMake发现当前系统的生成器和缓存记录不一致，直接拒绝执行。

这个坑的排查思路比解决手段更重要。第一反应不是重装CMake，而是看工程目录下有没有CMakeCache.txt和CMakeFiles目录，尤其是从网上下载的zip工程，几乎必带这两个东西。处理办法就是清理缓存重新配置：

rm -rf CMakeCache.txt CMakeFiles cmake ..

如果你用的是CMake GUI，还要注意在工具菜单里切换生成器，不要沿用上次选择的生成器。跨平台工程里，养成“复制工程后先清缓存再构建”的习惯，能避免大量莫名其妙的问题。

另外，“cmake如何指定编码方式”也是常见问题，这主要是Windows下MSVC的默认代码页问题。Linux一般不用管，但如果你的工程在Windows上编译时中文路径或注释乱码，可以在CMakeLists里加一行：

add_compile_options(/utf-8)

GCC/Clang对应的写法是-finput-charset=UTF-8 -fexec-charset=UTF-8。这些细节不影响仿真主体，但在分发工程给不同平台伙伴时很实用。

2.4 ROS2包构建中CMakeLists的规范写法与常见误区

ROS2功能包本身的构建也是CMake，而且比普通工程更讲究。用colcon build时，底层会把编译工作交给CMake，所以CMakeLists.txt的写法直接影响编译结果。高频踩坑点有三个：

• find_package顺序：ROS2包的CMakeLists里，依赖包必须在ament_cmake之前或按约定顺序找到，漏掉某个find_package会在链接期报找不到头文件的错误。
• 自定义消息和服务：如果写了.msg或.srv文件，必须在CMakeLists里显式调用rosidl_generate_interfaces，并且把这个包的依赖也在package.xml里声明，不少人在CMakeLists里加了消息接口但忘了在package.xml加 ，编译时就报找不到rosidl生成的头文件。
• install规则：任何自定义的可执行文件、launch文件、配置文件，都要有对应的install指令，否则colcon build成功但ros2 run找不到目标。

CMake版本回退之后，ROS2包编译时如果还报版本相关错误，建议检查是否某些依赖包强制要求更高CMake版本，比如ROS2 Jazzy的默认依赖可能要求CMake 3.22以上。这时候就不要硬降了，直接用系统自带的3.28就行。版本管理的核心是“匹配依赖链”，不是“越低越好”。

3. 仓库场景搭建：把静态地图变成动态干扰场

3.1 仓库场景的模型组织：地面、货架、托盘与障碍物布局

Gazebo的world文件用SDF格式描述，一个仓库场景的基本构成包括地面、墙体、货架、托盘、障碍物，以及这些物体的碰撞属性、物理属性、视觉材质。我习惯用“模型引用+独立SDF文件”的方式组织场景，而不是把所有模型堆在一个巨大SDF里，这样维护起来清晰得多。

地面用一个大平面即可。货架直接用box模型堆叠：四个立柱加几层隔板，用一个SDF文件定义，内部包含一个visual标签和一个collision标签。别小看collision，很多人偷懒只写visual，结果小车直接穿货架而过，物理仿真形同虚设。

托盘和箱子是动态环境里最常用的道具。托盘可以是带碰撞的box模型，箱子可以做成可抓取的动态模型。障碍物布局不要均匀撒，要模拟真实仓库的动线和盲区：通道两侧有货架，通道中段有不定期停放的托盘，角落里有一台“来回搬运”的AGV，这样才能检验导航算法在真实复杂工况下的表现。

3.2 动态障碍物的实现方案：插件驱动与ROS2节点控制

动态障碍物有两种实现路线，我建议优先级不同时选不同路线。

第一种是用Gazebo原生插件驱动模型运动。写一个简单的ModelPlugin，在OnUpdate里按指定轨迹更新模型位置，就能做出往返运动的AGV。这种方案的好处是跟ROS2解耦，纯仿真层面就能跑起来，不需要额外启动节点；缺点是轨迹写死在插件里，改起来要重新编译。

第二种是用ROS2节点控制一个差速轮模型，发布/cmd_vel让它按预设路径行驶。这个方案的好处是灵活，动态障碍物的行为可以被外部脚本控制，甚至可以跟后续的感知算法做对抗测试；缺点是需要多维护一套机器人模型。

实际项目我推荐两种结合：静态周期性运动的障碍物用插件，需要动态响应的用ROS2节点。仓库里那种“按固定路线来回巡航的AGV”用插件就够了，而“临时移动的搬运车”用ROS2控制更真实。

3.3 光照、材质与虚拟机性能的平衡技巧

场景逼真度和仿真性能是天平两头。仓库动态环境如果要跟真实传感器数据对标，光照和材质就不能太敷衍；但如果跑在虚拟机上，又要时刻防止卡顿。

光照方面，Gazebo默认的太阳光在室内场景里不够真实，室内仓库应该用多个点光源或聚光灯模拟顶灯，同时关闭不必要的阴影计算。材质方面，地面和货架的反光率会影响RGBD深度图像的噪点水平，太光滑的材质反射会干扰深度传感器，墙面和地面建议使用中等灰度材质。

虚拟机性能优化我单独说，因为很多读者就是在这类环境下做的。最有效的三板斧：一是把传感器update_rate从30降到10，图像分辨率从1280x720降到640x480，RGBD点云密度降低；二是关闭Gazebo GUI，只用RViz做可视化，Gazebo里headless模式跑仿真可以省下大量渲染资源；三是把物理更新频率从1000Hz降到500Hz，仓库场景不需要那么高的物理步长。实测这三步做完，虚拟机的仿真流畅度能提升一倍以上。

4. 差速轮机器人建模与双RGBD挂载：URDF/Xacro实操

4.1 差速轮底盘关键参数与运动学换算

差速轮机器人模型的核心是URDF/Xacro。不用Xacro的话，每个车轮和传感器都手写重复的link/joint定义，既容易出错也难维护。我用Xacro把轮子和传感器定义成宏，参数化处理，一套模板生成前后两套传感器。

底盘关键参数就是轮距（wheel_separation）和轮径（wheel_radius）。这两个参数直接决定运动学换算：

• 线速度 v = (wl + wr) × r / 2
• 角速度 ω = (wr - wl) × r / L，其中L是轮距

URDF关节的物理属性也很重要。轮子joint类型通常是continuous，绕Y轴或Z轴旋转取决于你的底盘布局，但要注意Gazebo里如果摩擦参数没设置，小车会原地打滑。我习惯在每个轮子的gazebo标签里显式设置mu1=1.0、mu2=1.0，再给一点摩擦力方向系数，这样小车在仓库地面上就不至于“脚底抹油”。

4.2 两颗RGBD传感器的位置设计和坐标系对齐

双RGBD传感器的位置不是随便挂的，它直接决定感知覆盖范围。我的方案是前向摄像头装在前端上方0.35米高度，向后倾斜5度左右，负责主视野感知；后向摄像头装在后端上方0.35米高度，方向朝后，负责倒车和尾部盲区。

坐标对齐这句要重点讲。ROS的坐标规范是X轴向前、Y轴向左、Z轴向上，相机传感器默认的成像方向是Z轴负方向。所以你在URDF里给相机link设置origin时，必须要用rpy旋转把相机朝向掰过来。前向相机：

<joint name="front_camera_joint" type="fixed"> <parent link="base_link"/> <child link="front_camera_link"/> <origin xyz="0.3 0 0.35" rpy="0 0.05 0"/> </joint>

后向相机的yaw要转180度，让镜头朝向车尾方向：

<joint name="back_camera_joint" type="fixed"> <parent link="base_link"/> <child link="back_camera_link"/> <origin xyz="-0.3 0 0.35" rpy="0 0.05 3.14159"/> </joint>

这个细节如果忽略，你在RViz里看到的点云会是倒置或者朝错方向的，排查起来特别容易绕弯路。

4.3 Gazebo传感器插件的配置方式

URDF只定义模型结构，要把RGBD传感器变成真正产生数据的仿真传感器，需要在 标签里挂插件。ROS2的Gazebo Classic环境下，深度相机插件是libgazebo_ros_depth_camera.so，配置要点如下：

<gazebo reference="front_camera_link"> <sensor type="depth" name="front_depth_camera"> <update_rate>10</update_rate> <camera> <horizontal_fov>1.0472</horizontal_fov> <image> <width>640</width> <height>480</height> </image> <clip> <near>0.2</near> <far>10.0</far> </clip> </camera> <plugin name="front_depth_camera_controller" filename="libgazebo_ros_depth_camera.so"> <ros> <namespace>/camera/front</namespace> <remapping>image:=image_raw</remapping> </ros> <camera_name>front_camera</camera_name> <frame_name>front_camera_link</frame_name> </plugin> </sensor> </gazebo>

update_rate不建议设太高，10Hz够仓库导航使用，过高会在虚拟机里卡爆。clip的near/far远近裁剪面也要根据仓库尺度设置，太远会产生大量噪点深度点，太近又丢失近处信息。frame_name必须跟URDF里的link名严格对应，否则TF树对不上，传感器数据在RViz里会漂移。

5. ROS2话题通信实战：数据的接收、处理与再发布

5.1 话题通信的基本模型与消息类型选择

ROS2把机器人系统拆成松耦合节点，节点间通过话题进行异步通信。这个项目的数据流是：Gazebo传感器插件发布原始话题，我们写一个处理节点订阅这些话题，处理后再发布新话题，实现“接收与发送”。

消息类型上，图像用sensor_msgs/Image，深度图通常也是Image（编码为16UC1或32FC1），相机内参用sensor_msgs/CameraInfo，点云用sensor_msgs/PointCloud2。如果你只做图像级处理，订阅Image就够了；要做3D融合，就订阅PointCloud2。

一个容易踩的坑是QoS策略。传感器数据是时效性优先、丢帧无所谓的，所以Gazebo插件发布端通常用BestEffort QoS；订阅端如果用默认的Reliable QoS，两边协商不上，话题数据根本收不到。rclpy里订阅传感器话题请使用qos_profile_sensor_data这个配置。

5.2 一个节点搞定左右RGBD数据接收与融合发布

下面给出一个完整的最小节点示例，订阅前向和后向两路图像话题，接收回调里做简单处理，再发布一路融合图像。这个节点把“接收-处理-发送”完整串起来，你可以在此基础上扩展自己的算法。

import rclpy from rclpy.node import Node from rclpy.qos import qos_profile_sensor_data from sensor_msgs.msg import Image class RGBDFusionNode(Node): def __init__(self): super().__init__('rgbd_fusion_node') # 接收前向图像 self.sub_front = self.create_subscription( Image, '/camera/front/image_raw', self.front_callback, qos_profile_sensor_data ) # 接收后向图像 self.sub_back = self.create_subscription( Image, '/camera/back/image_raw', self.back_callback, qos_profile_sensor_data ) # 发布融合结果 self.pub_fused = self.create_publisher(Image, '/camera/fused/image_raw', 10) self.latest_front = None self.latest_back = None def front_callback(self, msg): self.latest_front = msg self.try_fuse() def back_callback(self, msg): self.latest_back = msg self.try_fuse() def try_fuse(self): # 两路数据都到位后，再做融合发送 if self.latest_front is not None and self.latest_back is not None: # 这里可以替换成你自己的实际处理逻辑 fused_msg = self.latest_front self.pub_fused.publish(fused_msg) self.get_logger().info('已发送一帧融合数据') def main(args=None): rclpy.init(args=args) node = RGBDFusionNode() rclpy.spin(node) node.destroy_node() rclpy.shutdown() if __name__ == '__main__': main()

这个节点是逐步演进的。先实现“收到数据就打印”，确认话题链路通了，再往上叠加融合逻辑。别一上来就写复杂处理，因为一旦数据流没通，你根本分辨不出是通信问题还是算法问题。

5.3 通信链路联调：从topic list到rqt_graph

节点写完后，验证链路通畅的步骤有很强的顺序性。

第一步，启动Gazebo场景和机器人，确认传感器插件在发布话题：

ros2 topic list | grep camera

正常会看到/camera/front/image_raw、/camera/front/camera_info、/camera/back/image_raw等话题。

第二步，检查话题发布频率：

ros2 topic hz /camera/front/image_raw

如果输出频率接近你配置的update_rate，说明传感器数据在正常产生。

第三步，启动融合节点，再查看处理后的话题和节点图：

ros2 run your_package rgbd_fusion_node ros2 topic echo /camera/fused/image_raw --once rqt_graph

rqt_graph是排查话题连接最直观的工具。如果融合节点订阅端和发布端都正确出现在图里，说明通信链路完整；如果出现灰色断线，多半是QoS不匹配或话题名打错。这个检查顺序我每次做项目都会重复，几乎能排除90%的通信类故障。

6. slam_toolbox与nav2验证：动态仓库环境下的建图与导航实测

6.1 先跑通建图：depthimage_to_laserscan把RGBD变成激光扫描

slam_toolbox内置适配的是2D激光话题/sacn，但我们的差速轮小车标配是RGBD传感器，没有物理激光雷达。在Gazebo里当然可以给机器人加一个雷达模型，但在本方案里，利用RGBD深度图转成2D激光扫描更合理，还能顺带验证双传感器的额外价值。

depthimage_to_laserscan是ROS2官方工具，配置参数主要是depth_image_topic、scan_topic、以及angle_min/angle_max/angle_increment三个角度范围参数。前向相机转出的扫描基本覆盖正前方180度，后向相机转出的扫描覆盖后方，两路scan可以各自独立用，也可以拼接成360度扫描（需要做坐标变换和点云融合）。

建图操作流程：

1. 启动Gazebo仓库场景和机器人模型。
2. 启动depthimage_to_laserscan，把前向深度图转成/scan。
3. 启动slam_toolbox：

   ros2 launch slam_toolbox online_async_launch.py use_sim_time:=true

4. 另外开一个终端用teleop_twist_keyboard控制小车在仓库里巡视：

   ros2 run teleop_twist_keyboard teleop_twist_keyboard

   控制小车把仓库各条通道都走一遍，重点是要“回头看”，因为只有前向scan的话，转弯时后方的货架轮廓建不出来。
5. 建图完成后保存地图：

   ros2 run nav2_map_server map_saver_cli -f warehouse_map

动态障碍物在建图阶段的影响，slam_toolbox处理得还行，但依然会在地图边缘留下一些“扰动痕迹”。建图时尽量让动态障碍物离小车远一些，或者等它停到某个角落再继续扫图，能显著减少地图瑕疵。

6.2 保存地图与启动nav2的完整流程

地图保存后，会生成warehouse_map.yaml和warehouse_map.pgm两个文件。启动nav2组合导航：

ros2 launch nav2_bringup bringup_launch.py map:=warehouse_map.yaml use_sim_time:=true

然后打开RViz，设置导航所需显示项：

• Map显示加载的静态地图
• RobotModel显示机器人URDF模型
• TF、LaserScan、Path、Global Costmap、Local Costmap等

在RViz里先设置InitialPose（使用2D Pose Estimate工具，在机器人实际位置点一下，方向对准车头朝向），再设置Goal（使用2D Goal Pose工具）。nav2会规划一条全局路径，然后控制小车跟着路径移动。

如果你没有给激光雷达模型，只是用depthimage_to_laserscan转出的scan，初始化nav2时要注意把Nav2的scan topic参数指向你的转换话题，同时确保use_sim_time=true，否则导航栈的时间戳会和仿真时间脱节，目标点的轨迹会出现漂移。

6.3 动态障碍物对局部代价地图的影响与调参方向

这是整个项目最有价值的部分：在导航运行中，仓库的“动态障碍物”开始移动，观察nav2怎么应对。

我实测的效果是，当一台AGV以0.5米/秒横穿小车规划路径时，局部代价地图如果更新频率偏低，小车会一头撞上障碍物才紧急制动，然后原地重新规划。这不是nav2不能用，而是默认参数适配的是静态场景。

调参方向有三个：

• local_costmap的update_frequency和publish_frequency：从默认的1-2Hz调到5Hz，代价地图能更快反映动态障碍物。
• cost_scaling_factor：控制代价地图膨胀半径对障碍物距离的衰减速度，动态场景下适当降低，让远离障碍物的区域代价梯度平缓，避免规划路径过度绕行。
• inflation_radius：如果小车因为障碍物附近的膨胀层过大而频繁规划失败，把它从默认值调小到轮距的一半左右。

这几个参数需要在仿真里反复试，没有一劳永逸的组合。我的经验是先调update_frequency，因为动态场景的核心矛盾就是“地图更新跟不上障碍物移动”，频率上去了，很多导航卡顿问题会缓解一半。

6.4 虚拟机、WSL2与真机环境的性能差异

最后说说环境对性能的影响。如果你和我一样在Ubuntu 24.04虚拟机里跑这套东西，最直观的感受就是卡。虚拟机里Gazebo虽然能用，但渲染和物理仿真都吃CPU，再叠加RViz、slam_toolbox、nav2，整机负载会很吃力。

虚拟机优化优先级：headless模式跑Gazebo是性价比最高的，在launch文件里设置headless:=true，Gazebo不渲染GUI，只跑物理和传感器计算；RViz仍然会连上传感器数据做可视化，所以你不会“看不见”场景。然后是降传感器分辨率、降更新率，这两步能把CPU占用降下来一大截。

WSL2的情况跟虚拟机类似，尽管WSLg改善了GUI支持，但Gazebo的OpenGL渲染在WSL2里依然不稳定，深度相机点云可能出现花屏或空白。我的建议是：临时验证用WSL2可以，正经搭建仓库动态环境仿真，还是在Ubuntu 22.04虚拟机或实体Ubuntu上跑更省心。

最后分享一个我从这个项目里得到的最有用的心得：在开始搭建环境之前，花半小时把CMake版本、ROS2发行版、Gazebo方案这三者之间的兼容关系理清楚，比什么都会重要。版本一致了，后面的URDF、话题通信、导航联调就是按图索骥；版本乱了，你会陷入“装的包报错、查半天发现是环境问题”的循环。如果你时间有限，只记住一件事——用Ubuntu 22.04 + ROS2 Humble + Gazebo Classic 11作为基线，CMake用自带的或固定到3.16.3都行，这套组合最不容易出幺蛾子。后面再往Ubuntu 24.04或者Gazebo Harmonic迁移，那就是另一个项目了。

本文还有配套的精品资源，点击获取