简介：本资源是一套面向机器人方向本科生与研究生的ROS2-SLAM算法对比仿真实践包，适用于毕业设计、课程设计及期末大作业等教学场景，旨在解决SLAM算法在ROS2环境下部署、测试与性能评估的学习痛点。压缩包共476个文件（85.1MB），涵盖72个SDF世界模型、71个配置文件（config/yaml）、148个DAE三维模型、94个PNG纹理贴图、26个JPG示意图，以及Docker相关文件（Dockerfile、docker-compose.yml等）和RVIZ可视化配置，支撑多算法（如RTAB-Map）在TurtleBot3 Burger/RTAB仿真环境中的可复现对比实验。已有45人学习下载，资源提供完整仿真工作流：从Docker一键构建环境、多传感器数据融合建图、定位精度与地图质量量化评估，到Software GET Assessment报告模板，帮助学习者系统掌握ROS2通信机制、SLAM原理验证与工程化评测方法。 做过几轮基于ROS2的SLAM仿真对比之后，我最大的感受是：真正费时间的不是跑通算法，而是把“对比”这件事做得公平。仿真环境里车走的路不一样、雷达频率不一样、甚至TF树的发布时序不太一样，最后算出来的指标都很难直接横向比较。所以这篇东西我打算用“仿真对比”这个角度切入，把环境搭建、算法选型、数据采集、评测方法、还有我踩过的坑一次性讲清楚。适合刚入门ROS2、或者想在仿真里评估SLAM效果的开发者参考。
1. 为什么要在ROS2里做SLAM算法对比仿真
1.1 对比SLAM，核心是控制变量
先回答一个问题：SLAM算法对比到底比什么？很多人觉得比的就是建出来的地图好不好看，但真正落到实际工程里，至少要看四个维度。
- 建图精度：地图轮廓是否清晰，直线是否笔直，墙角有没有变形，回环闭合后有没有错位。
- 轨迹一致性：机器人跑一圈回到原点，漂移了多少。这个数据直接反映里程计和SLAM算法的累积误差，比单看地图更客观。
- 资源占用：CPU占用率、内存增长曲线、单帧激光数据处理的耗时。这决定了算法能不能跑到嵌入式平台上去。
- 鲁棒性：在传感器噪声增大、快速旋转、长走廊等退化场景下，算法会不会崩溃或者地图发散。
这四个维度在实体机器人上做对比，要付出大量时间成本，而且很难复现相同的运动轨迹。仿真环境最大的价值就在这里：场景可以精确重置、传感器噪声可以调节、机器人运动轨迹可以录制回放。在我实际做对比的过程中，最常用也最推荐的方案是先录制bag包，再用不同算法做数据回放。这样所有算法吃的是完全相同的输入数据，对比结果才真正有意义。
1.2 为什么选ROS2而不是ROS1
ROS1已经停止维护，新项目再从头搭ROS1的基础设施有点逆势而行。ROS2带来的好处很直接：DDS通信替代了原来的Master节点，不再有“单点故障”；依赖的组件、节点的生命周期管理明显更规范；参数服务、日志系统、bag录制接口都比ROS1好用的多。
这里有一点需要提前说明：虽然ROS2是趋势，但SLAM算法生态在ROS1时期积累得更猛。很多经典算法，比如Gmapping、Hector SLAM，官方支持基本停留在ROS1，ROS2环境下要么靠社区移植、要么通过第三方包集成，稳定程度和文档完整度参差不齐。真正在ROS2里开箱可用、文档齐全的，主要是Google的Cartographer和Slam Toolbox。这个局面也决定了我们做对比时，算法选型必须提前确认好发行版和依赖关系。
2. 仿真环境搭建与关键配置
2.1 环境版本选型
我用的组合是Ubuntu 22.04 + ROS2 Humble + Gazebo 11。ROS2 Humble是LTS版本，技术支持到2027年，社区用户量大，有问题搜起来也有答案。Gazebo 11是Humble自带的版本，对ROS2的集成度已经比较成熟，不会出现Gazebo 9时代那种插件频繁崩溃的问题。
安装ROS2 Humble时，新手建议用鱼香ROS的一键安装脚本，省去手动配源的麻烦；老手可以自己配源逐步安装，官方文档写得很清楚。装完ROS2之后再装建模和仿真依赖：
sudo apt install ros-humble-gazebo-ros-pkgs sudo apt install ros-humble-gazebo-ros2-control sudo apt install ros-humble-turtlebot3* sudo apt install ros-humble-slam-toolbox sudo apt install ros-humble-cartographer sudo apt install ros-humble-cartographer-ros sudo apt install ros-humble-nav2*注意：ROS2 Humble里没有官方发布的Gmapping二进制包，别折腾了。要用Gmapping就只能自己按GitHub上的第三方仓库编译，而且一般还要带补丁。我实际测下来，Gmapping在ROS2下的维护状态很差，效果也不如Slam Toolbox稳定，所以后续对比我主要讲Slam Toolbox和Cartographer。
2.2 仿真世界和机器人模型
仿真场景我直接用了TurtleBot3的官方场景turtlebot3_world。这个场景是TurtleBot3作者专门为SLAM和导航仿真设计的，包含墙壁、障碍物和回环路径，尺寸适中，跑一圈大概2到3分钟，做算法对比非常合适。TurtleBot3的激光雷达配置也接近真实入门级雷达：
- 传感器类型：2D激光，scan话题
- 扫描范围：360度
- 测量距离：0.12m到3.5m
- 扫描频率：默认5Hz左右（实际版本可能有差异，可以通过参数调整）
这个3.5米的量程在小型室内场景里是够用的，但在比较大或者结构复杂的场景里会吃亏。如果你的仿真场景尺寸很大，记得在TurtleBot3的URDF里调整雷达量程，否则远处墙面完全扫不到，任何SLAM算法都建不好图。
启动仿真环境：
source /opt/ros/humble/setup.bash export TURTLEBOT3_MODEL=burger ros2 launch turtlebot3_gazebo turtlebot3_world.launch.py启动完以后，另外开一个终端启动键盘控制：
export TURTLEBOT3_MODEL=burger ros2 run turtlebot3_teleop turtlebot3_teleop_key2.3 录包：让所有算法吃同样的数据
录包是整个对比流程里我最看重的一步。很多人在仿真里跑SLAM，是开着A算法跑一遍、再开着B算法跑一遍，然后比地图。这个对比方式不严谨，因为机器人运动的轨迹并不一样，传感器噪声也有随机性，算法表现的好坏可能和算法的能力没关系，纯粹是这次跑得顺不顺。
正确的做法是：先开着键盘控制，让机器人在场景里完整走一圈，同时把激光、里程计、TF和底盘状态全部录制下来。后面跑任何算法，都只是把这个bag当作传感器数据源重放，运动轨迹和输入数据完全一致。
录制命令：
mkdir -p ~/slam_data ros2 bag record -o ~/slam_data/turtlebot3_world_bag \ /scan \ /odom \ /tf \ /tf_static \ /imu这里我建议把/imu也录上，Cartographer是支持IMU融合的，后续如果要对比带IMU和不带IMU的效果，没有这个数据就得重新跑一遍仿真。
录制时控制机器人尽量走“慢速直线 + 弯道平滑过渡”的路线，同时绕一个完整的闭环回来。实测下来，走太快的bag会导致激光帧间位移过大，很多算法在这种输入下回环检测会失效，这不是算法的真实水平。
3. SLAM算法原理分析与选型
3.1 粒子滤波派的代表逻辑
说到2D SLAM，Gmapping是很多人的启蒙算法，它的核心逻辑是粒子滤波。你可以把每个粒子理解成“机器人姿态的一个猜测”，算法维护成千上万个粒子的集合，每个粒子都携带一个局部地图。随着机器人移动，粒子不断根据激光观测和里程计输出来更新权重，权重高的粒子保留下来，权重低的被淘汰，最终加权平均得到机器人的位姿估计。
Gmapping的优点是代码相对简单、对计算资源要求低，室内小场景效果不错。缺点是它没有显式的回环检测机制，一旦粒子滤波收敛到错误的位置，后续很难拉回来。而且在长廊这种单方向结构里，激光约束不足，粒子多样性快速下降，地图发散的案例比比皆是。
在ROS2里检测Gmapping的效果，我只能说“能编译、能跑，但效果十不存一”。社区版的ROS2 Gmapping包往往用的是ROS1代码包了一层ROS2接口，参数接口和TF处理都有一点陈旧问题。如果你是做算法学习，可以试试；如果是做项目，我不建议。
3.2 Slam Toolbox：ROS2里的长跑冠军
Slam Toolbox在ROS2里是官方维护的包，直接apt install就能装，不用折腾源码。它的核心思想是基于图优化的2D SLAM，大致流程是：
- 每一帧激光扫描先与当前局部地图做匹配，得到机器人的相对位姿。
- 这个匹配结果和里程计一起构成图中的节点和约束，形成一个位姿图。
- 后台图优化器不断调整所有节点的位姿，让所有约束的总误差最小。
- 关键的是它带有闭环优化，当机器人回到之前去过的地方，回环约束会把累积的位姿漂移一把拉回来。
Slam Toolbox还有一个很实用的功能：地图持久化。建完图之后可以序列化保存，下次再启动时把地图读进来，继续建图或直接做定位导航。这个能力在实际项目中非常常用，仿真里做对比时也可以用来快速恢复历史地图。
跑Slam Toolbox之前，建议把雷达的扫描频率调高到10Hz再录bag。它内置的扫描匹配对帧间运动量比较敏感，5Hz的雷达频率在转弯稍快时容易匹配失败，这是我在实践中最先遇到的坑。
3.3 Cartographer：精度上限更高，代价也更明显
Cartographer来自Google，理论上是目前2D激光SLAM里精度天花板最高的开源方案之一。它创新性地引入了**子图（Submap）**的概念：
- 激光数据不断和当前子图做匹配，累积形成一个局部子图。
- 新扫描插入子图的同时，算法会根据置信度对子图拼接的位置做优化。
- 一旦检测到回环，后台全局优化器会把整条轨迹和所有子图的位姿一起做非线性优化。
这套机制让Cartographer在回环检测和大场景下表现明显更好，建出来的地图构图规整。但代价也很现实：
- 计算资源占用高：后台全局优化是持续进行的，我实测在普通笔记本上跑Cartographer，CPU占用率会比Slam Toolbox高出30%到50%。
- 参数极其多：Cartographer的lua配置参数有上百个，新手第一次看到配置文件往往直接崩溃。
- 对传感器质量要求高：如果雷达数据有抖动或乱码，Cartographer很容易出现局部子图对不齐，地图上有“鬼影”。
在ROS2里使用Cartographer时，官方提供了turtlebot3的示例配置，直接用是最省心的方式：
export TURTLEBOT3_MODEL=burger ros2 launch turtlebot3_cartographer cartographer.launch.py如果你要录包回放，需要先跑一个静态TF的节点，或者直接用bag自带的TF。很多人在回放时发现Cartographer建图失败，大多是TF时间戳对不上。
3.4 一张表格看懂算法差异
| 维度 | Gmapping | Slam Toolbox | Cartographer |
|---|---|---|---|
| ROS2支持程度 | 差，需第三方编译 | 官方包，开箱可用 | 官方示例支持 |
| 核心原理 | 粒子滤波 | 图优化 + 回环 | 子图 + 全局优化 |
| 回环检测 | 无 | 支持 | 支持且较强 |
| CPU开销 | 低 | 中 | 高 |
| 地图质量（室内） | 中 | 高 | 高 |
| 大场景表现 | 差 | 中 | 好 |
| 参数复杂度 | 低 | 中 | 高 |
| 适合场景 | 学习、对比 | 项目落地 | 高精度需求 |
我个人的算法选型建议是：如果做实际项目且硬件不算强，优先Slam Toolbox；如果对精度有执念，愿意调参数且CPU有余量，选Cartographer；Gmapping在ROS2里就当作理论学习素材，踩坑时间太长，不建议浪费。
4. 实操：算法对比全流程
4.1 用bag回放对比，关键在时间轴
录好的bag要用来跑不同算法，有一个细节容易被忽略：bag文件里包含的是录制时的时间戳，重放时如果直接ros2 bag play，算法节点拿到的是历史时刻的数据，TF树会因为时间戳和当前系统时钟不一致而报错。
正确做法是使用--clock参数，让bag回放作为仿真时钟的发布者：
ros2 bag play --clock ~/slam_data/turtlebot3_world_bag同时在启动SLAM算法之前，把环境变量设置成使用仿真时钟：
export ROS_DOMAIN_ID=0 export TURTLEBOT3_MODEL=burger ros2 param set /slam_toolbox use_sim_time True或者直接在launch文件里给节点加上use_sim_time参数。在启动之前先把bag的时钟问题解决掉，后面所有算法跑起来才会有公平一致的时间基准。
启动Slam Toolbox的方式：
export TURTLEBOT3_MODEL=burger ros2 launch slam_toolbox online_async_launch.py注意：我这里用的是
online_async_launch.py，不是online_sync_launch.py。Async模式是把扫描匹配和图优化解耦，图优化在后台异步执行，实时性更好，也更适合回放bag的场景。Sync模式在回放时会因为图优化占用时间而丢掉一部分激光帧，对比指标时会吃亏。
启动Cartographer的回放配置后，记得在启动命令里加上use_sim_time:=true参数，否则TF时间戳会直接报警。这也是Cartographer在ROS2里回放bag最常见的一个坑。
4.2 控制仿真机器人的运动轨迹
如果选择不录制bag，而是直接让TurtleBot3在Gazebo里跑，也有办法保持不同算法的轨迹一致：用TurtleBot3自带的自动导航程序，或者保存一份键盘控制的指令序列脚本，逐条执行相同的指令。相比录包回放，这个方法繁琐且容易受到仿真物理引擎微小差异的影响，我不太推荐。
在实际录包时，我常用键盘控制TurtleBot3沿场景中轴走，先沿墙壁外侧绕一圈，再回到起点附近完成回环。整个过程大概3分钟，会产生几百兆的bag包文件，注意磁盘空间。
录制完成以后，用下面命令确认bag数据完整：
ros2 bag info ~/slam_data/turtlebot3_world_bag查看输出中的topic列表和消息数量，重点检查/scan、/odom、/tf是否有大量消息缺失。如果/tf的消息数量少得离谱，说明机器人的TF树没有正常发布，回头去查robot_state_publisher节点。
4.3 记录性能指标
性能对比不只是建图结束后的结果对比，算法运行过程中的实时指标更关键。实测下来我会同时记录四个方面：
- CPU和内存占用：用
htop或pidstat记录SLAM节点对应的进程资源占用。 - 地图话题的分辨率和更新频率：可以用
ros2 topic hz /map查看。 - 算法输出的轨迹：Slam Toolbox和Cartographer分别发布不同的位姿话题，可以通过
ros2 bag record配合ros2 topic echo抓取。 - TF的延迟：
ros2 topic delay /tf可以查看TF消息延迟。
如果你是用bag回放模式，还可以借助工具对比算法输出的轨迹与真实位姿：Gazebo里TurtleBot3发布的是地面真值里程计/odom，这个数据本身就是带噪声的仿真结果，不完全等于真实轨迹，但作为相对基准已经够了。
ros2 topic echo /map --once ros2 topic hz /scan ros2 topic delay /tf以上命令在不同终端分别跑起来，就能实时观察SLAM节点运行时的数据流情况。通过对比不同算法在相同bag上的CPU曲线、地图更新频率和话题延迟，可以直观地判断哪种算法更适合目标硬件平台。
4.4 地图结果对比与轨迹评估
地图质量评估有一个比较直观的做法：把Slam Toolbox和Cartographer分别建出来的/map保存为图片，叠加在原始场景的栅格地图上，然后计算重叠率或者直接肉眼看对齐程度。
保存地图的方式很简单：
ros2 run nav2_map_server map_saver_cli -f ~/slam_data/map_cartographernav2_map_server会生成pgm和yaml两个文件，用图像软件打开就能看到建图结果。
如果有精力做量化评估，建议用evo工具。虽然evo主要面向视觉SLAM和里程计评估，但通过ros2 bag转成tum格式后，也可以对2D激光SLAM输出的轨迹做ATE和RPE计算。这里的流程是：
- 用
ros2 bag extract或者Python脚本将SLAM输出的位姿话题导出成轨迹文件。 - 把激光SLAM的位姿时间戳对齐到
/odom真值轨迹的时间戳。 - 用
evo_ape和evo_rpe计算绝对轨迹误差和相对位姿误差。
举例：
python3 export_traj.py --bag ~/slam_data/turtlebot3_world_bag \ --topic /slam_toolbox/pose --output traj_toolbox.tum python3 export_traj.py --bag ~/slam_data/turtlebot3_world_bag \ --topic /tracked_pose --output traj_carto.tum evo_ape tum groundtruth.tum traj_toolbox.tum -a --plot evo_ape tum groundtruth.tum traj_carto.tum -a --plot注意：/slam_toolbox/pose和/tracked_pose分别是Slam Toolbox和Cartographer的常见位姿话题名，具体名称需要根据启动的launch文件来确定，建议先跑ros2 topic list确认。
4.5 多趟建图的一致性与定位测试
完成了单次建图对比之后，还有一个容易被忽视的维度：多趟建图的一致性。方法也很简单：
- 在同样的仿真环境里，分别用两个算法建多张地图。
- 用
map_saver_cli保存地图和对应的yaml。 - 用一个简单的评估脚本，将地图转换为占用栅格，计算两张地图的像素级差异。
此外，如果时间允许，还可以把建好的地图交给Nav2去做路径规划测试，看地图中的障碍物边界是否和真实场景对齐。这样能验证建图结果最实际的可用性，而不只是停留在“地图看上去挺好看”的层面。
我测过一轮典型数据，放在同一个bag上：
- Slam Toolbox建图耗时约40秒，CPU峰值约85%，回环闭合后地图无明显错位。
- Cartographer建图耗时约70秒，CPU峰值约140%（双核笔记本），地图线条更加规整，在墙角处几乎没有噪点。
- 但在建图过程中，Slam Toolbox的地图话题更新频率更稳定，没有出现像Cartographer那样的周期性卡顿。
以上数据只是单次实验的参考，不同电脑硬件差异较大，建议自己动手测一轮拿到自己的基准数据。
5. 常见问题与排查技巧实录
5.1 高频问题速查表
| 现象 | 可能原因 | 排查思路与解法 |
|---|---|---|
| TF data timeout | 没有设置use_sim_time，或bag没有启动时钟 | 加--clock回放bag，节点加use_sim_time:=true |
| 地图出现大块空白或黑洞 | 雷达量程不足，或场景遮挡严重 | 调整TurtleBot3 URDF雷达量程，检查/scan消息内容 |
| 建图过程中地图乱跳 | 机器人运动过快，帧间位移过大 | 放慢速度，或提高雷达扫描频率后再录bag |
| Cartographer内存狂涨 | 子图数量太多，全局优化队列积压 | 调低子图插入频率、降低轨迹分辨率，或换更薄的雷达数据 |
| Slam Toolbox启动后不进图 | 当前地图模式配置错误，或缺少TF帧 | 检查scan_topic、frame_id配置，确认激光帧在TF树中存在 |
| Gazebo卡顿严重 | 渲染负担过高 | 使用headless模式，或者调低图形渲染质量 |
| ROS2的bag录制文件过大 | topic数量多、帧率高 | 只记录/scan、/odom、/tf、/imu，降低雷达频率 |
回放bag时SLAM节点不发布/map | 初始位姿估计失败，或TF树未建立 | 检查/tf和/tf_static，确认base_footprint到laser的坐标变换无误 |
5.2 最关键的一条经验：控制“手速”
无论跑哪种算法，键盘控制机器人建图时，方向盘要稳。仿真环境下很多人喜欢开“氮气加速”，结果激光数据之间的位移太大，SLAM算法无法准确匹配扫描帧。我后来学乖了，录制bag时特别控制线速度在0.2m/s以内，角速度不超过0.5rad/s，跑出来的建图成功率提升非常明显。
5.3 检查TF树是解决一切诡异问题的前提
很多SLAM异常表现，比如地图一开始乱、回环闭合错误、rviz2里机器人在地图上漂移，根源往往不是算法本身，而是TF树不对。启动SLAM前和回放bag前，一定要在rviz2里打开TF显示，或者直接在终端看TF消息：
ros2 run tf2_ros tf2_echo map odom ros2 run tf2_ros tf2_echo odom base_footprint ros2 run tf2_ros tf2_echo base_footprint base_scan如果这几个TF链中任意一个断了或者跳变，SLAM算法即使能力再强也无法正常建图。这个检查花不了两分钟，但能帮你避开至少一半的折磨。
5.4 资源不够时，如何降低Gazebo卡顿
仿真环境里最让人头疼的问题就是Gazebo吃资源导致实时性变差，进而影响SLAM结果。除了前面提到的headless模式，还有一个技巧是把Gazebo的物理更新频率调低一点。TurtleBot3这种小型机器人，把max_step_size稍微调大一点，物理精度并不会明显下降，但CPU占用下降很明显。
另外，在录制bag时可以临时关掉rviz2和Gazebo的画面渲染，把系统资源尽量留给录制进程。录完包后分析和回放时再开可视化。
写在最后的一些实操心得
做SLAM算法对比仿真，最大的收获并不是知道“谁地图看起来更好”，而是深刻理解了仿真环境的时钟、TF、传感器数据质量对算法表现的影响有多大。很多在实体机器人上难以复现的边界情况，在仿真里可以随时重置并反复测试，这对算法选型和参数调试的帮助非常大。
如果你刚开始做这件事，我建议先不要急着跑算法，第一天就把仿真环境、键盘控制、bag录制和回放这条链路完整跑通。这条链路顺畅了，后面无论换什么算法、什么场景，都只是加新包的问题。我个人实际测试时，前两周里花在TF和时钟上的时间远比花在算法本身上的时间多，但这些摸索带来的经验，最后都成了调试效率的护城河。
最后再分享一个小技巧：每次对比实验结束，把当时的bag文件、配置文件、算法版本、运行结果都放在同一个文件夹，命名带上日期和场景信息。几周后再回头看时，你会发现这套记录习惯的价值远超预期，它能让你真正沉淀出可靠的经验，而不是每次都从零开始。
本文还有配套的精品资源，点击获取
的MATLAB实现与工程实践指南)
