不少刚开始接触SLAM的朋友都有过这样的经历代码仓库clone好了依赖库装好了满心欢喜准备跑一个Demo结果卡在第一步——没有激光雷达数据。买一台雷达少说几百上千还没法随时随地带着跑这时候2D激光SLAM数据集就成了性价比最高的选择。但数据集这事说起来简单做起来全是坑。下回来的数据要么格式不对要么话题名对不上要么时间戳乱跳导致建图直接飘飞。我最早接触2D激光SLAM数据集时光是把一个bag包在ROS里正常回放就折腾了整整一个下午。后来数据集玩多了才发现这里面其实有一套非常清晰的筛选、下载、校验、测试逻辑。这篇就把我实际用过的流程和踩过的坑完整梳理一遍从选数据集到跑通建图再到量化评估结果一次说明白。1. 先想清楚你要的数据集解决什么问题下载数据集之前先别急着找链接。不同阶段、不同目的适合的数据集完全不一样。这一步想不清楚后面会浪费大量时间。1.1 2D激光数据集的核心维度传感器、环境、真值衡量一个2D激光SLAM数据集能不能用主要看三个维度。第一个是激光雷达的型号与参数。2D激光雷达不是只有一种常见的包括SICK LMS系列如LMS100、LMS151、Hokuyo URG系列如UTM-30LX、UST-10LX、以及后来在服务机器人里大量使用的RPLIDAR系列。不同雷达的扫描范围、角分辨率、扫描频率都不相同。比如SICK LMS100的扫描范围是270度Hokuyo URG-04LX则是240度。这些参数直接影响SLAM算法对环境的感知能力也决定了你调参时的一些基准值。第二个是环境特征。走廊、办公室、仓库、室外园区这些环境的几何特征差异极大。走廊场景直线特征多对激光SLAM来说相对友好仓库场景货架林立存在大量重复结构对闭环检测和局部匹配的挑战就大得多。第一次跑数据集建议选结构化良好的室内办公室场景技术熟练后再挑战复杂环境。第三个是真值Ground Truth的获取方式。有些数据集提供高精度轨迹真值可以用于量化评估算法精度有些则只有激光和里程计数据只能用于定性的建图测试。对精度评估有要求的场景必须优先选带真值的。1.2 不同学习阶段的选型差异我把接触数据集的人粗略分为三类选型逻辑完全不同。刚入门想跑通第一个Demo的。这类朋友需要的是“一次就能成功”的数据集。优先级最高的是数据完整、格式标准、文档详细的经典数据集。最典型的就是Intel Research Lab数据集这个2006年采集的老数据集至今仍是2D激光SLAM入门测试的首选原因无他——数据干净、话题标准、文件不大跑Gmapping基本零门槛。在做算法对比或调参研究的需要的是覆盖多种场景、有真值的数据集。建议选择包含多个子数据集的集合包比如Cartographer官方提供的2D数据集合集里面既有室内办公室也有户外园区可以充分压测算法在不同环境下的表现。在搞工程化落地的则应该找与目标场景高度相似的数据。比如做仓储机器人就找仓库环境的数据集做楼宇清扫机器人就找办公楼的数据集。这个阶段最忌讳拿一个不相关场景的数据集硬调参数调出来的参数换个场景大概率废掉。2. 主流2D激光SLAM数据集横向对比与适用场景这一节把我在实际测试中用过的、且社区里公认度较高的数据集整理成一张对照表方便你按需取用。数据集传感器配置环境类型是否含真值文件大小适合用途Intel Research LabSICK LMS200室内办公室无约80MB入门Demo、Gmapping测试MIT CSAIL BuildingSICK LMS200室内办公/走廊无约1.5GB大规模室内建图测试Freiburg CampusSICK LMS系列室内室外部分子集有数百MB混合环境测试Cartographer 2D官方集多种雷达室内/仓库/园区部分有综合较大算法对比与压测Radish数据集多种配置多样部分有大学术研究综合测试KITTI OdometryVelodyne HDL-64E3D室外道路有大可抽2D scan做室外测试2.1 几个经典数据集的真实体验Intel Research Lab我愿称之为2D激光SLAM的“Hello World”。数据采集于Intel实验室的办公环境整个轨迹是一个闭环非常适合验证建图能否正确回环。用Gmapping跑这个数据集默认参数基本就能出图唯一要注意的是雷达话题名是/scan激光frame是laser这些信息在后续配置launch文件时会用到。MIT CSAIL Building规模比Intel大不少覆盖了MIT计算机系大楼的完整走廊网络。这个数据集对内存和CPU有一定要求如果跑Cartographer时机器配置一般建议先把点云分辨率调低一点否则很可能会出现实时性跟不上导致建图断裂的情况。Cartographer官方2D数据我强烈建议所有做算法对比的人都收藏。它里面的数据包覆盖了不同年代的传感器、不同风格的场景最关键的是部分数据带了高精度真值轨迹可以直接配合evo工具做定量评估。比如其中的b2-2016-04-05-14-44-52.bag就是典型的仓库货架场景具有大量自相似结构对算法辨识能力是很好的考验。2.2 怎么看一个数据集的“坑”在哪里光看介绍还不够很多数据集的坑要用起来才知道。几个高频问题bag包损坏或不完整老数据流传太久部分文件下载后无法正常解析。下载后先跑rosbag info检查。时间戳不一致有的数据激光帧频率标称20Hz实际包里不均匀跑起来会看到轨迹抖动。坐标系定义混乱有的数据base_link和laser的tf树不完整需要自己手工补静态变换才能跑通。话题命名不规范比如某些数据集用的是/laser_scan而大多数SLAM算法默认订阅/scan必须在launch文件里remap。这些坑单看介绍很难发现所以下载后先用工具核一遍再进算法流程能帮你省掉大量排查时间。3. 下载实操从哪里拿、怎么校验、如何避坑数据集下载听起来就是“点个链接”但实际操作中存在不少细节问题尤其对于一些老数据集来说服务器在海外、带宽受限、文件不完整都是常态。3.1 几个可靠的获取途径官方来源优先。Cartographer的数据集可以从其官方GitHub仓库找到下载链接MIT和Intel的数据集通常托管在高校实验室网站上。这些渠道的文件完整性比较有保障。学术资源共享平台。有一些专门整理机器人数据集的门户站比如Radish数据集的主页就汇集了大量激光雷达数据并提供统一的下载入口。这类平台的好处是数据集描述比较统一方便横向比较。ROS官方教程配套数据。ROS Wiki的SLAM相关教程页面会附带一些测试用的bag文件这些通常比较小适合快速验证环境是否配好。需要提醒的是很多老数据集托管在大学服务器上访问速度不稳定。遇到下载中断建议用支持断点续传的命令行工具重试而不是反复用浏览器下载后者一旦中断就要重来。3.2 下载后先做三件事校验、目录整理、格式转换下载完成后别急着解压先完成下面三个动作。第一校验文件完整性。如果下载页面提供了MD5或SHA256校验值务必先算一遍再解压。我遇到过不止一次bag文件下载到一半断了但文件大小看起来差不多直到回放时才报错。用md5sum命令核对一下几秒钟的事能省掉后面一小时的排错。md5sum intel_lab.bag拿到结果后和官网提供的校验值比对一致就说明文件完好。第二建立一个规范的数据集目录。这个习惯我自己受益很大。每份数据集单独建目录目录下至少包含三个子目录data存放原始bag或数据文件config存放你写好的launch和参数文件result存放建图输出或评估报告。这样当你同时处理多个数据集时不会互相干扰也方便后续复盘。第三检查压缩格式。有些数据集提供的是tar.gz或zip压缩包解压前先看包内文件结构避免解压出一堆散乱文件污染目录。推荐统一用如下方式解压mkdir intel cd intel tar -xzf intel_lab.tar.gz ls -la3.3 关于bag版本和时间戳的连环坑这一部分内容是实操中踩出来的值得单独拎出来说。bag版本兼容问题。ROS1的bag和ROS2的bag格式不通用这是最基础的问题。如果你用的是ROS1下载时就要确认数据集是ROS1格式绝大多数经典2D激光数据集Intel、MIT、Radish等都是ROS1 bag可以直接用。但有的新数据集会提供ROS2格式就需要用rosbags这种工具做格式转换而不能直接回放。时间戳异常。这是最隐蔽的坑。我在跑一个老数据集时发现Gmapping建图过程中机器人位置突然跳变排除了里程计噪声后用rqt_bag查看发现激光数据存在长达数百毫秒的间隔空洞。查了数据集文档才知道原始采集时传感器驱动偶发丢帧采集者做了数据压缩但没做插值补帧。这种问题在跑算法时是无法通过调参解决的只能先对bag做时间戳预处理或者换数据集。雷达坐标系命名不统一。很多数据集的激光坐标系叫laser但部分算法默认会去lookupTransform一个叫laser_link或base_laser的坐标。这会造成TF坐标变换找不到数据而直接报错或者建图时点云位置错乱。碰到这种情况你的launch里需要手写静态坐标变换node pkgtf2_ros typestatic_transform_publisher namelaser_broadcaster args0 0 0 0 0 0 base_link laser /参数含义简述前三个数表示x、y、z平移后三个数表示roll、pitch、yaw旋转这里假设激光与机器人中心完全重合。实际配置时需参考数据集自带的测量说明不能盲目照抄。4. 把数据集跑起来ROS环境下的一次完整测试下载和校验完成后真正的测试环节才刚开始。我以最经典的Intel数据集为例在ROS1 Noetic环境下完整跑一遍Gmapping再对比跑一下Cartographer把整个过程和涉及到的排查思路都交代清楚。4.1 环境准备与话题检查假设你已经有了一台装好ROS1的机器并且已经安装了gmapping功能包。如果没装先装好基础功能包sudo apt install ros-noetic-gmapping ros-noetic-cartographer ros-noetic-cartographer-ros然后打开数据集的bag先看内部结构rosbag info intel_lab.bag这一步极其重要。你会看到类似下面的输出topics: /odom - 998 msgs / freq: 25.0 Hz /scan - 333 msgs / freq: 8.3 Hz /tf - 1996 msgs / freq: 50.0 Hz重点关注三点话题名是什么、频率够不够、tf是否完整。激光频率只有8.3Hz对于Gmapping来说完全够了但如果跑Cartographer低于10Hz的数据就需要在配置里做体素滤波和扫描匹配频率的调整。启动roscore后先看tf树正不正常rostopic echo /tf或者用rviz加载TF面板直接观察。常见的错误是base_link到odom的变换丢失或跳变。基础确认完成后再进算法层。4.2 从回放bag到跑通Gmapping的完整链路Gmapping的启动文件写法网上有很多但很多人照抄后跑不通原因往往在于remap没对齐。下面是我实际验证过的启动方式。先写一个gmapping_intel.launchlaunch node pkggmapping typeslam_gmapping nameslam_gmapping outputscreen remap fromscan toscan / param namebase_frame valuebase_link/ param nameodom_frame valueodom/ param namemap_frame valuemap/ param namemap_update_interval value2.0/ param namemaxUrange value15.0/ param namelinearUpdate value0.5/ param nameangularUpdate value0.2/ /node /launch关键点在于base_frame和odom_frame必须和bag里的tf树一致。有的数据集用的底盘frame叫base_footprint你就要改成那个名字否则Gmapping会直接等待tf数据超时。启动算法节点roslaunch gmapping_intel.launch在另一个终端回放bag注意加--clock参数rosbag play intel_lab.bag --clock--clock的作用是让ROS使用bag内的时间戳作为系统时钟来源这对SLAM至关重要因为建图算法极度依赖时间一致性。如果不加这个参数bag里的数据会按系统当前时间发布TF和时间戳会错乱。回放的同时开发rviz加载Map、Scan、RobotModel等显示项。正常情况下你会看到地图随着bag播放逐渐生长出来走完一个闭环后地图首尾能对齐就说明整个链路通了。4.3 换算法时的差异化调整跑通Gmapping后再跑Cartographer不能直接复用前面的启动方式。两者的输入输出端虽然都是/scan和tf但从参数配置到建图逻辑差异很大。Cartographer需要两个配置文件一个lua参数文件一个launch文件。lua文件里几个核心参数-- 2D laser slam config map_builder.use_trajectory_build_2d true map_builder.num_background_threads 4 -- SLAM 核心参数 TRAJECTORY_BUILDER_2D.use_imu_data false TRAJECTORY_BUILDER_2D.min_range 0.3 TRAJECTORY_BUILDER_2D.max_range 20.0 TRAJECTORY_BUILDER_2D.missing_data_ray_length 5.0 -- 前端扫描匹配 TRAJECTORY_BUILDER_2D.ceres_scan_matcher.translation_weight 1.0 TRAJECTORY_BUILDER_2D.ceres_scan_matcher.rotation_weight 1.0 -- 后端优化回环 POSE_GRAPH.optimize_every_n_nodes 90 POSE_GRAPH.global_sampling_ratio 0.003 POSE_GRAPH.constraint_builder.min_score 0.55注意这里use_imu_data false因为大部分纯2D激光数据集不提供IMU数据。Intel数据集尤其如此。很多人跑Cartographer失败就是因为照着官方demo开了IMU结果程序一直在等IMU数据。启动方式roslaunch cartographer_ros demo_2d.launch bag_filename:intel_lab.bag如果你的bag路径没有放在~/Downloads之类默认的位置最好在launch里显式指定绝对路径避免浪费时间。5. 测试结果怎么读不只是跑通更是对比把数据跑通只是第一步。实际工作中怎么从建图结果中提取有效信息、判断算法好坏才算真正把数据集用到位。5.1 可视化与人工判读建图完成后先人工看一眼地图。重点看三处环境结构是否清晰。墙线是否笔直拐角是否方正有没有出现重影或者叠影。出现叠影通常说明前端匹配在某个时刻漂移了而后端回环没有完全修正回来。回环是否闭合。观察bag播放到结束位置时地图上的起点和终点是否对齐。如果不齐说明累计漂移超过后端优化能力范围。对于Intel这种小规模闭环场景跑得好应该是严丝合缝的。雷达扫描点是否有明显穿透。有些地图里墙会“变薄”或出现穿墙点这大概率是雷达数据中的多路径反射或镜面反射没有被滤除。观察这些现象时配合rviz中的实时点云显示一起看能更准确定位问题发生在哪个路段。保存成地图rosrun map_server map_saver map:/map -f ~/slam_test/intel_gmapping会生成intel_gmapping.pgm和intel_gmapping.yaml两个文件。pgm文件就是你可以直接看到的地图图像。5.2 在数据集没有真值时的替代评估方法很多经典数据集不带真值那怎么量化评估建图结果我常用的一种间接评估方式是扫描匹配回代误差。简单来说就是把建图得到的栅格地图作为参考重新把原始激光帧与地图做一次配准统计所有帧在最优位姿下的平均匹配得分。匹配得分越高说明地图与原始数据越自洽。这个指标不能完全代表绝对精度但作为横向对比两个算法在同一个数据集上的表现足够稳定。网上也有一些工具可以做类似事情比如lidar_align系列虽然主要用于雷达到其他传感器的外参标定但其中的交叉配准思路可以借鉴。如果你用的是Cartographer它自带的rosmap工具还支持把子图submap导出成PGM文件你可以把多个子图叠加比对或直接用图像处理方式计算子图间配准残差。5.3 多数据集组合测试策略只跑一个数据集是不足以说明算法性能的至少要在三个不同特征的数据集上测试才能得出较可靠的结论。我个人的组合策略是测项数据集考察目的基本闭环Intel Research Lab算法基本盘是否正常大规模环境MIT CSAIL Building大场景下内存与计算压力结构重复环境Cartographer b2仓库序列回环检测与全局优化能力如果算法能在这三个数据集上都能建出清晰的闭环地图基本可以说明它具备了一定的泛化能力。只在一个数据集上表现好说服力远远不够。6. 实测避坑记录那些文档里不写的事情最后这部分把我测试过程中的“翻车”经验集中记下来几乎每一件都是花时间换来的教训。6.1 数据集的“隐藏依赖”比想象中多有些数据集虽然在文档中说“只需要激光和tf”但实际跑起来会发现缺少必要的时间基准。比如有的bag包里激光帧的时间戳是采集电脑的本地时间而odom的时间戳是工控机时间两边没有做同步。在rosbag回放时这种偏差会以topic时间戳不连续的形式体现出来算法实时性越高的数据集影响越明显。排查方式并不复杂回放时打开rqt_tf_tree观察每个时刻odom到base_link的变换是否平滑再打开rqt_plot把/scan的时间戳差值画出来看有没有周期性尖峰。如果有说明数据集自身时间同步不好不是你的算法问题不必死磕。6.2 数据集测试的“算法配置迁移陷阱”同一个算法在不同数据集之间切换时很多人喜欢直接复用上一份配置这是很大的陷阱。雷达量程、扫描帧率、环境尺寸不同最优配置参数差异巨大。举个例子maxUrange这个参数在Gmapping里代表有效匹配的最大激光量程。在Intel实验室这种小空间里设成15米没问题但放到走廊型数据集里激光经常打到30米远的尽头如果上限设太小会丢掉大量有效特征建图精度明显下降。反过来在狭窄环境中设太大会把玻璃门、金属面这些低质量点也纳入匹配反而拉低精度。我现在习惯的做法是每切换一个数据集先花10分钟用rosbag info和第一视角快速浏览确认环境尺度再针对性地修改量程、更新频率等几个最敏感的参数。盲目沿用配置是低效调试的根源。6.3 性能监控应成为测试的必要环节建图跑通了不代表测试结束了性能数据同样关键。我在每次建图时都会同步开三个监控CPU占用、内存占用、实时性算法线程处理一帧雷达数据耗时。方式很简单开一个终端跑top -b -p $(pgrep -d, -f slam_gmapping|cartographer)和rosparam set /use_sim_time true rostopic hz /maprostopic hz /map可以统计地图发布的实时频率频率过低说明算法后端优化压力大可能在建图过程中出现地图卡顿。对实时性敏感的场景这一步必须做。如果发现某段路线上建图耗时有明显毛刺建议回去对比bag里对应时间段是否有密集闭环触发。闭环优化本身是计算密集型操作偶尔的毫秒级卡顿可以接受但持续卡顿就需要考虑调低optimize_every_n_nodes或增加num_background_threads这类参数了。这些坑我几乎都踩过一遍写出来也是希望大家少走点弯路。数据集的下载与测试看似只是SLAM开发链路上的一小环但这一环顺不顺直接影响后面所有算法验证的效率。把基础工作做扎实了后面调参、对比、优化才有真正的参考价值。