基于ROS2的SLAM算法对比仿真：环境搭建与轨迹误差分析

简介面向机器人自主导航与SLAM技术研究可运行的仿真工程资源适用于ROS2学习者、毕业设计、课程设计及期末大作业等场景。压缩包基于ROS2搭建了turtlebot3_rtab和turtlebot3_burger等仿真环境支持rtab-map等视觉与激光融合SLAM算法的对比测试与性能评估能够帮助研究者掌握不同算法的建图质量、定位精度与运行效率。资源共476个文件以dae三维模型、sdf仿真场景、config与yaml参数配置为主辅以Python控制脚本、urdf机器人描述、Dockerfile容器配置以及PDF评估报告整体约85.1MB便于完整构建可复现的仿真实验环境。目前已有45人学习使用。通过阅读说明文档与运行仿真读者可掌握ROS2下SLAM算法的部署流程学会利用定位精度、建图质量等指标横向比较多种算法并结合Docker一键复现实验尤其适合课程报告、论文或实际项目中的算法选型参考。1. 基于ROS2的SLAM算法对比仿真毕设课设最稳的落地路径做机器人的毕业设计或课程设计只要沾上SLAM十有八九最后都卡在同一个地方算法选好了、环境装好了跑起来却对不上图建得歪歪扭扭对比实验结果根本没法写进论文。这套《基于ROS2的SLAM算法对比仿真》就是把slam_toolbox、cartographer和ORB-SLAM3在ROS2环境下的完整对比流程打包好从Gazebo仿真场景到bag回放、从参数配置文件到地图保存、从轨迹对比到论文图表一条线走通。适合正在做ROS2方向毕设、课设或者期末大作业的从业者和学生尤其适合那些不想把整个学期耗在编译和调参上的人。拿到之后按步骤跑能直接产出三套算法的仿真对比数据和图表剩下的就是整理进论文。2. 先搞懂SLAM对比的底层逻辑算法选型与评价指标2.1 三套主流算法的定位差异与选型理由做对比仿真之前先把三套算法各自的脾气摸清楚。slam_toolbox是2D激光SLAM里性价比最高的选择它脱胎于Karto核心是scan-to-map匹配加回环检测对结构化环境比如走廊、办公室特别友好CPU占用低8G内存的笔记本也能跑得动。cartographer是Google开源的图优化方案支持2D激光、IMU、里程计多传感器融合全局优化做得扎实建出来的图更好看但代价是吃算力跑起来CPU经常飙到300%以上。ORB-SLAM3是视觉SLAM的标杆靠ORB特征点做前端带视觉惯导紧耦合适合没有激光雷达的场景。选哪几套做对比要看题目方向。如果题目是室内移动机器人2D SLAM对比那slam_toolbox加cartographer就够了再加一个视觉方案属于加分项如果题目挂了视觉SLAM或者多传感器融合那ORB-SLAM3必须上哪怕只跑通单目模式也比空谈强。常见做法是三套全跑因为对比仿真最怕的就是样本太少只有两个算法对比答辩时老师一句为什么不用cartographer就能把你问住。三套算法对比时还要注意一个客观差异它们建图输出的数据格式不一样。slam_toolbox和cartographer都输出2D栅格地图直接能喂给navigation2做导航ORB-SLAM3输出的是稀疏点云和关键帧轨迹严格来说它不产出可直接用于导航的栅格地图。这个差异本身就可以写成对比分析的一节——不同SLAM方案对下游导航任务的适配性这是很多毕设里没写透的部分。2.2 评价指标怎么定轨迹误差、建图完整度、CPU占用评价指标定得准对比实验才有说服力。最核心的是轨迹误差分绝对轨迹误差ATE和相对位姿误差RPE。ATE衡量的是估计轨迹和真值轨迹之间的整体偏移RPE衡量的是每一小段运动的误差累积。做2D激光SLAM对比时一般用evo工具计算ATE的RMSE均方根误差这个数据能直接用作论文里的定量对比表。数据来源方面Gazebo仿真里可以直接拿到ground truth常见做法是订阅gazebo的odom话题或者用gazebo_ros的ground_truth插件把真值发出来。rosbag回放场景的话如果bag包里本身带odom或者gps真值也可以直接用如果只有激光和里程计那只能靠建图结果定性对比。除了轨迹误差建图完整度也是要量化的指标。怎么量化把算法输出的栅格地图导入matplotlib或OpenCV数一数地图上被占用的栅格数量和墙面边长度的偏差算一个地图覆盖率——覆盖率 已建出的有效栅格数 / 仿真场景总栅格数。这个口径不需要额外工具Python脚本几十行就能出结果对毕设来说足够了。。CPU占用和内存峰值也要记录zcat /proc/cpuinfo查CPU型号用psutil每两秒采样一次进程的CPU和内存把slam_toolbox、cartographer、ORB-SLAM3的峰值落在同一张表里。很多课设只比建图效果不比资源开销但实际答辩时老师特别喜欢问这一类问题备好数据有备无患。3. 环境搭建与数据集准备3.1 ROS2版本选择与Gazebo仿真环境配置ROS2的版本选择直接影响后面所有步骤能不能走得通。目前毕业设计用得最多、资料最好找的是Ubuntu 22.04加ROS2 Humble这套组合从2022年开始就是主流官方文档、博客、Gitee上的项目模板基本都是按这个版本来的。如果你的机器是Ubuntu 24.04那对应的是ROS2 Jazzy也能用但很多第三方的仿真包和算法包的兼容性验证还不充分不建议在毕设这种有限时间里折腾版本兼容问题。装在装ROS2 Humble之后先把Gazebo相关的东西装齐。TurtleBot3的仿真包是做2D激光SLAM最省事的选择它自带一个带墙壁和障碍物的world激光雷达、IMU、里程计的TF树都配好了跑slam_toolbox和cartographer直接开箱即用。# 安装TurtleBot3仿真相关包 sudo apt install ros-humble-turtlebot3 ros-humble-turtlebot3-simulations # 安装SLAM算法包 sudo apt install ros-humble-slam-toolbox ros-humble-cartographer ros-humble-cartographer-ros # 安装环境变量指定默认机器人模型 echo export TURTLEBOT3_MODELwaffle_pi ~/.bashrc source ~/.bashrc模块说明第一行装的是TurtleBot3本体和仿真包后面SLAM相关包是后面跑对比的核心。TURTLEBOT3_MODEL指明使用waffle_pi型号这个型号带的是360度激光雷达比burger的多一层雷达覆盖范围建图效果更好。如果课程设计用的虚拟机内存建议不低于8G否则后面gazebo、rviz2、算法节点三个进程同时跑会非常卡。下一步是验证Gazebo能不能正常启动。输入ros2 launch turtlebot3_gazebo turtlebot3_world.launch.py如果看到一个小车出现在带墙体的仿真环境里说明环境没问题。这里有个细节TurtleBot3仿真包默认用的是gazebo_ros的use_sim_time机制也就是所有节点的时间基准都要统一用仿真时间后面跑SLAM时这个开关必须在launch文件里显式设置。3.2 数据集方案仿真场景与rosbag回放哪个更合适SLAM对比的数据来源有两个一个是仿真场景实时跑一个是rosbag回放。仿真场景适合跑全流程验证好处是完全可控可以在同一个世界里反复跑确保不同算法走同样的路径这个控制变量在对比实验里非常重要。rosbag回放则适合跑真实数据集比如学校实验室里TurtleBot3实车录的一段激光包回放时算法消费的是完全相同的传感器数据对比公平性更强。一个高质量流程是仿真场景先跑通再bag回放做复现。仿真里跑通说明代码和参数没问题bag回放就是换个数据源验证算法的鲁棒性。回放时用ros2 bag play注意要先启动SLAM再启动播放否则前面几帧激光丢失影响初始位姿估计。# 先启动SLAM节点以slam_toolbox为例 ros2 launch slam_toolbox online_async_launch.py # 再播放bag包 ros2 bag play /path/to/your/bag --loop数据源说明bag包里的话题名需要和SLAM算法订阅的话题名对上TurtleBot3的激光话题是/scan里程计是/odomTF树是/tf和/tf_static。如果你的bag包话题名不一样常见做法是写一个launch文件里加remap参数比如remap/scan:/your_scan_topic_name。这一步不加remap的话算法收不到激光数据建图直接空白。另外--loop参数是让bag循环播放方便反复调试参数不用每次播放完再倒回去。还有一个常见的做法是先用键盘控制机器人在仿真世界里走一个8字或者沿墙一圈同时录制bag。这样后面对比所有算法时播放的是同一份数据机器人的运动轨迹完全一致对比结果的说服力比手动跑两次强得多。录制命令是ros2 bag record /scan /odom /tf /tf_static录完就是一条完整的数据集。4. 跑通三套算法参数调整与启动文件实战4.1 slam_toolbox参数配置与launch文件实战slam_toolbox在ROS2里用起来是这三套里最简单的它提供一个online_async的启动方式适合建图时实时出图。参数都集中在params.yaml里我一般会先改几个关键项max_laser_range、map_update_interval和minimum_travel_distance。# slam_toolbox参数文件节选 slam_toolbox: ros__parameters: odom_frame: odom map_frame: map base_frame: base_footprint scan_topic: /scan max_laser_range: 12.0 # 激光最大量程waffle_pi雷达量程到12米 minimum_time_interval: 0.5 # 两次扫描之间的最小时间间隔秒 minimum_travel_distance: 0.2 # 两次扫描之间的最小移动距离米 map_update_interval: 5.0 # 地图更新间隔秒 resolution: 0.05 # 栅格分辨率0.05米5cm一格参数说明max_laser_range设10到12米就行设太大远处的噪声点会污染匹配minimum_travel_distance是触发scan-to-map匹配的最小移动距离设0.2米意味着静止时不做匹配省CPU但设太大又会导致小幅度转弯时地图像素模糊resolution0.05是常用值既保证地图精度又不至于让地图文件过大。改完参数后在launch文件里加载它。# slam_toolbox的launch文件节选 from launch import LaunchDescription from launch_ros.actions import Node def generate_launch_description(): return LaunchDescription([ Node( packageslam_toolbox, executableasync_slam_toolbox_node, nameslam_toolbox, outputscreen, parameters[params.yaml], # 加载上面的yaml remappings[(/scan, /scan)] ) ])逻辑说明这个launch文件直接启动async_slam_toolbox_node节点并把参数文件路径传进去。实际跑之前在launch文件里还要加上use_sim_time参数——在Gazebo仿真里一定要设成true否则时间戳会穿越回当前系统时间TF那里直接报unable to transform。4.2 cartographer从lua配置到建图启动cartographer的参数和slam_toolbox不是一个路子它用lua配置文件而且配置项非常多新手最容易在这里翻车。核心配置就几个tracking_frame、published_frame、odom_frame、provide_odom_frame和use_online_correlative_scan_matching。-- cartographer的lua配置文件节选 include map_builder.lua include trajectory_builder.lua options { map_builder MAP_BUILDER, trajectory_builder TRAJECTORY_BUILDER, map_frame map, tracking_frame base_footprint, -- 传感器挂载的坐标系 published_frame base_footprint, -- 发布位姿的坐标系 odom_frame odom, provide_odom_frame true, -- 是否提供odom帧 publish_frame_projected_to_2d true, use_pose_extrapolator true, use_online_correlative_scan_matching true, -- 在线相关性匹配提升精度 num_laser_scans 1, num_subdivisions_per_laser_scan 1, trajectory_builder_2d TRAJECTORY_BUILDER_2D } TRAJECTORY_BUILDER_2D.use_online_correlative_scan_matching true TRAJECTORY_BUILDER_2D.min_range 0.2 TRAJECTORY_BUILDER_2D.max_range 12.0 TRAJECTORY_BUILDER_2D.missing_data_ray_length 5.0 TRAJECTORY_BUILDER_2D.submaps.num_range_data 90参数说明cartographer的核心机制是submapnum_range_data90指每个submap积累90帧激光数据后输出一次数值越大submap覆盖范围越大回环检测的频率降低但更稳定。use_online_correlative_scan_matchingtrue是开启实时相关性扫描匹配能显著提高激光匹配精度但会多占用CPU低配电脑上容易出现线程饥饿。provide_odom_frametrue表示由cartographer自己发布odom到map的变换关系如果你的机器人平台上已经有里程计TF这个可以设false但TurtleBot3仿真里通常让它自己来更省事。启动cartographer的launch文件比slam_toolbox复杂因为cartographer_ros的节点需要同时加载lua配置和URDF。一般做法是# 先启动cartographer节点注意--ros-args后面的参数路径 ros2 launch cartographer_ros cartographer.launch.py \ configuration_basenameturtlebot3_2d.lua如果用的配置没有现成URDF就要在launch文件里显式加载机器人模型描述参数不然robot_state_publisher缺URDFTF树缺链算法启动后一秒就报错。这里给个建议跑cartographer前先ros2 run tf2_tools view_frames看一下TF树是否完整缺哪个frame就补哪个别等建了半天地图发现map和odom关系错乱再回头找原因。4.3 ORB-SLAM3视觉方案的配置与启动要点ORB-SLAM3是视觉SLAM跑它之前要先确认仿真环境里有相机。TurtleBot3的waffle_pi模型带一个RGB相机话题是/camera/rgb/image_raw可以直接喂给ORB-SLAM3的单目模式。# 下载ORB-SLAM3的ROS2分支放到src目录 cd ~/ros2_ws/src git clone https://github.com/zhenxiangli/ORB_SLAM3.git cd ORB_SLAM3 # 编译前先装依赖 sudo apt install libeigen3-dev libboost-all-dev libssl-dev cd ~/ros2_ws colcon build --packages-select orbslam3编译说明ORB-SLAM3的依赖比较多Eigen、Boost、OpenCV是硬性要求。编译过程中最常见的是OpenCV版本不匹配导致的C编译错误Ubuntu 22.04自带的OpenCV 4.2一般够用。如果报错指向cv::Mat类型不匹配多半是OpenCV头文件路径没找到检查/usr/include/opencv4是否存在于CMakeLists的include路径里。启动单目模式的命令长这样# 启动ORB-SLAM3单目节点需要词袋文件路径 ros2 run orbslam3 mono \ /path/to/Vocabulary/ORBvoc.txt \ /path/to/config/Turtlebot3_mono.yaml参数说明第一个参数是词袋模型文件ORBvoc.txt的路径这个文件是特征点匹配的字典缺了它节点直接崩溃第二个参数是相机内外参配置文件里面包括图像话题名、相机内参矩阵、畸变系数。仿真里的相机内参可以在Gazebo的世界文件里查到也可以直接用TurtleBot3官方给的配置模板注意把Camera.frame设置成/camera/rgb/image_raw话题对不上时ORB-SLAM3会一直等待图像、不发任何输出。ORB-SLAM3跑通之后有个特点它会定期把当前帧的位姿发到/orb_slam3/odometry话题同时也维护一个局部地图线程。对比轨迹时订阅这个位姿话题就可以记录估计轨迹很方便。但它不输出栅格地图所以建图质量这个维度ORB-SLAM3要单独说明——它的产出是稀疏点云地图评价指标侧重轨迹精度和2D栅格建图不在一个赛道。4.4 三套算法同路径跑的工程化方法这里有一个很关键的实践问题三套算法用同一个键盘控制去建图人不可能每次走得一模一样对比就不公平。一个靠谱的方案是用ros2 run teleop_twist_keyboard teleop_twist_keyboard配合一个固定时长的脚本或者直接写一个Python节点匀速发布/cmd_velTopic让机器人走一条固定的L形或圆形轨迹。# 发布匀速圆周运动指令的脚本节选 import rclpy from rclpy.node import Node from geometry_msgs.msg import Twist class CircleDriver(Node): def __init__(self): super().__init__(circle_driver) self.pub self.create_publisher(Twist, /cmd_vel, 10) self.timer self.create_timer(0.1, self.drive) def drive(self): twist Twist() twist.linear.x 0.2 # 线速度 0.2 m/s twist.angular.z 0.3 # 角速度 0.3 rad/s self.pub.publish(twist) rclpy.init() node CircleDriver() rclpy.spin(node)逻辑说明这个脚本每0.1秒发布一次速度指令让机器人以0.2m/s线速度和0.3rad/s角速度走出一个固定半径的圆。同一段轨迹给三套算法各跑一遍跑出来的图才有可比性。跑完一次后把机器人stop掉清除地图重新跑下一个算法。注意每次换算法时要重启整个SLAM节点清空旧的map话题最好直接把相关进程CtrlC杀掉再重新launch不然旧节点残留的位姿会影响新算法初始估计。5. 避坑专题SLAM仿真对比中最容易翻车的五个场景5.1 TF树报错unable to transform from map to base_footprint现象启动SLAM算法后rviz2里一片空白控制台持续刷unable to transform from map to base_footprint地图窗口里看不到机器人和激光点云。原因TF树缺了map到odom或odom到base_footprint的变换。slam_toolbox和cartographer发布map到odom的变换机器人模型发布odom到base_footprint的变换。如果机器人URDF没加载robot_state_publisher没有运行后面那一段TF断层算法自然拿不到位姿关系。仿真环境下还有一个常见原因use_sim_time没开节点时间基准和仿真时钟错位导致TF的timeout。解决先把URDF加载到参数服务器再启动SLAM节点。加上use_sim_timetrue后重启全部节点。可以用ros2 run tf2_tools view_frames生成当前TF树视图来验证。5.2 激光话题对不上算法订阅不到数据现象启动slam_toolbox或cartographer后控制台显示等待scan数据但雷达话题明明在发。原因slam_toolbox的launch参数里scan_topic写的是/scan你的机器人激光话题如果叫/laser_scan或者/lidar收不到数据是必然的。cartographer的lua配置里设置num_laser_scans 1但扫描线实际在/scan之外的话题也一样。解决用ros2 topic list确认激光话题名然后在launch的remap里把/scan映射到实际话题。cartographer则建议把雷达数据重映射到/scan在launch文件给节点加remap参数或者直接用topic_tools的relay节点转发。5.3 cartographer跑起来CPU占用100%比别的算法慢一半现象cartographer建图时CPU占用冲到400%车载仿真里的机器人在rviz里明显掉帧激光点云显示滞后。原因cartographer的submap优化和全局回环检测线程是资源大户。如果num_range_data设得太小比如30submap快速产出后端优化线程频繁被唤醒CPU直接打满。还有use_online_correlative_scan_matchingtrue本身就是高强度匹配低配电脑扛不住。解决把num_range_data调到90以上max_range缩到10米内减少无效匹配范围。低配机器上把cartographer的launch里加execution_policyasync让它别阻塞控制线程。要记录CPU数据做对比时给cartographer单独留出5到10秒预热时间再采样。5.4 建图跑完地图有重影走廊变成两条线现象机器人沿墙跑完一圈地图上同一面墙出现双线重影拐角处墙壁错位。原因重影本质是位姿漂移。跑多圈时submap匹配只收敛到局部最优没有触发有效的回环闭合。slam_toolbox的minimum_travel_distance设得太大导致每帧激光都没参与闭环检测。cartographer那边往往是因为global_sampling_ratio设太低回环检测抽样的帧数太少。解决把slam_toolbox的minimum_travel_distance降到0.1让每一小段移动都触发匹配。cartographer把global_sampling_ratio调整到0.3以上提高回环检测参与率同时确保跑图时经过同一区域——如果不闭环算法没有重访区域的约束漂移只能越来越严重。跑图时宁可多走一段回头路也别只走单程。5.5 三套算法跑出的轨迹对比数据对不齐现象把三套算法的轨迹时间序列导出来做evo对比显示长度不一致轨迹终点明显错位阈值差得离奇。原因三套算法起始建图的时间基准不同。slam_toolbox在节点启动瞬间开始建图cartographer要等收到第一帧激光并完成初始位姿估计才输出数据ORB-SLAM3可能等待图像特征初始化几秒钟。三者的epoch起点错开几秒到几十秒轨迹自然对不齐。解决在所有算法启动前订阅一个统一的计时起点。常见做法是把ros2 bag record的起点作为基准用启动脚本先让各算法预热到收到数据后再统一发出开始信号。做法是写一个launch脚本先启动全部SLAM节点sleep 3秒然后发布一个std_msgs的起跑指令Topic三套算法各自记录收到起跑指令后的轨迹。起跑前把bag数据的头部丢弃掉保证每一帧对比数据的起点时间戳一致。6. 对比结果的可视化落地用evo把轨迹误差变成论文图表6.1 生成TUM格式轨迹文件三套算法跑完后把各自的估计轨迹保存成TUM格式这是evo工具最方便读入的格式。TUM格式每行四个字段时间戳、x、y、z注意ROS2里时间戳以纳秒为单位要换算成秒存进文本。# 录制三套算法的位姿输出 ros2 topic echo /slam_toolbox/pose --fieldpose.pose slam_toolbox_pose.txt ros2 topic echo /orb_slam3/odometry --fieldpose.pose orbslam3_pose.txt # cartographer的位姿可以通过 /cartographer_ros/tracked_pose 获取 ros2 topic echo /cartographer_ros/tracked_pose --fieldpose.pose carto_pose.txt这三个文件需要经过一次格式清洗把时间戳和位置坐标按TUM格式拼接起来。清洗可以用一个简单的awk命令完成或者我在实际项目中是直接写一个几十行的Python脚本处理——从原始topic输出中按行解析出时间戳和x、y值输出为timestamp x y z qx qy qz qw的格式。6.2 用evo计算并绘制误差曲线# 安装evo pip install evo --upgrade --no-binary evo # 计算绝对轨迹误差ATE evo_ape tum ground_truth.tum slam_toolbox_pose.tum -va --plot --plot_modexy --save_results slam_toolbox.zip evo_ape tum ground_truth.tum carto_pose.tum -va --plot --plot_modexy --save_results carto.zip参数说明-va表示同时输出verbose和all信息把每个时间点的绝对误差明细列出来--plot_modexy指定轨迹投影平面2D平面导航用xy比较合适--save_results把计算结果保存成压缩包后面可以用evo_res批量对比多组结果。输出的RMSE、Mean、Median精度数据直接贴进论文的实验表格里。计算完精度指标后建图质量的对比可以用map_server把地图保存成图片再把三张地图放成一排对比。# 保存slam_toolbox建出的地图 ros2 run nav2_map_server map_saver_cli -f map_slam_toolbox --ros-args -p save_map_timeout:30.0 # 保存cartographer建出的地图 ros2 run nav2_map_server map_saver_cli -f map_cartographer --ros-args -p save_map_timeout:30.0保存出来的pgm图片放进论文答辩PPT里标注每张地图的建图时间、栅格分辨率、轨迹RMSE三套算法的高下就一目了然。最后再把evo生成的三张误差曲线图合并成一张对比图——我会把RMSE数值直接标在图上答辩时老师扫一眼就能看懂核心结论。从那次做这个ROS2对比仿真开始我跑任何SLAM算法之前都会先强制走一遍这套流程检查TF树完整性、确认use_sim_time状态、统一话题名、固定运动轨迹、统一轨迹对齐原点。流程不乱翻车的概率至少降低一半。这套资源里已经把这些步骤和配置都拆好了照着执行就能省掉之前那些反复编译和调试的弯路希望帮到你。本文还有配套的精品资源点击获取