移动机器人激光SLAM建图实战：基于Cartographer的配置与调优

这段时间一直在折腾 lingbot-map 这个项目，起因其实很简单：想给一台差速底盘室内移动机器人配一套靠谱的建图方案，让它在没GPS的楼道、厂房里能自己画出地图，并且地图后续能直接给导航用。项目名称里的 map 不只是“地图”这张图片，而是把激光雷达、里程计、扫描匹配、位姿图优化串起来的一整套配置和交付物。lingbot-map 跑通后，一台普通差速底盘加一个单线激光雷达，室内环境能稳定输出 5cm 分辨率的二维栅格地图，保存成 PGM 后可以直接丢给导航栈做路径规划。

这篇文章适合两类人：一是刚入手移动机器人、想搞清楚建图链路到底怎么配的初学者；二是已经能用现成 Demo 跑出图、但一换到自己的底盘就出现重影、漂移、回环不触发等问题的开发者。我会把 lingbot-map 的项目结构、参数调优过程、完整实操步骤和踩坑记录全部写出来，里面很多细节都是常规教程里不会展开的。

1. lingbot-map 是什么：先把它放在地图构建的坐标里

1.1 这个项目解决的最核心问题

很多刚接触机器人建图的人会觉得“建图”就是打开一个 SLAM 算法节点，然后拿着手柄推着车走一圈。实际上一个真正能落地的建图工程，要同时处理三件事：

• 数据链路：激光雷达的 /scan、底盘的 /odom、IMU 的 /imu，能不能以正确的频率和坐标变换汇合到 SLAM 节点；
• 参数匹配：扫描范围、最小距离、体素分辨率、回环检测频率，这些参数要和你的雷达、底盘、场景匹配，而不是抄官方的默认 Demo 配置；
• 交付格式：生成的 PGM/YAML 地图是否能被 navigation stack 识别，占据阈值、初始位姿、分辨率设置是否一致。

lingbot-map 做的就是这三个层面的打包。它不是一个从零写的 SLAM 算法，而是基于 Cartographer 这套比较成熟的二维 SLAM 方案，结合自己的底盘、雷达和场景需求做定制化配置。项目目录里包括 launch 启动文件、Cartographer 的 Lua 参数文件、Rviz 显示配置，还有把 pbstream 转成导航地图的脚本。这样换一台机器人，或者换一套雷达，不需要重新研究算法，只要改配置文件就能快速出一张可用地图。

1.2 技术选型：为什么从 gmapping 换到 Cartographer

最开始我图省事，直接用 gmapping 跑了一版。小房间、短走廊没问题，但一旦到了大约 30 米长的走廊，或者需要绕过一个中庭形成闭环时，gmapping 的地图就开始出现错位。

这里要说一下几个常见开源二维 SLAM 方案的差异：

lingbot-map 最终选 Cartographer，核心原因是它把局部扫描匹配和全局回环优化分成两个层级。局部扫描匹配负责当前激光帧和最近子图的配准，保证短时间内的轨迹平滑；全局位姿图优化则定期把所有子图、约束、里程计信息放到一张图里做整体调整，一旦回环检测触发，累计漂移会被拉回来。gmapping 的问题在于粒子滤波虽然能把当前位姿的分布估计出来，但在长走廊这种退化场景里，激光在沿走廊方向上的约束很弱，里程计误差又无法被后续闭环修正，地图就很容易逐渐歪掉。

换个生活化的类比：gmapping 像边走边画草稿，只盯着刚走过的几步，后面的画错了也不回头改；Cartographer 则像画完一个局部就拍一张照片，最后把整卷照片放到一起拼全景，发现首尾对不上时会重新调整中间所有照片的位置。

1.3 项目目录和模块划分

lingbot-map 的目录结构我在重构过程中几经调整，最终稳定成下面这样：

lingbot_map/ ├── config/ │ ├── lingbot_2d.lua # Cartographer 核心参数 │ └── lingbot_lidar.yaml # 雷达驱动和坐标系校准参数 ├── launch/ │ ├── lingbot_mapping.launch # 建图主启动文件 │ ├── lingbot_base.launch # 底盘驱动与里程计发布 │ ├── lingbot_lidar.launch # 雷达驱动 │ └── lingbot_localization.launch ├── rviz/ │ └── lingbot_map.rviz # 调试显示配置 ├── scripts/ │ └── map_to_nav.sh # pbstream -> PGM/YAML 转换脚本 └── maps/ └── README.md

这个结构的思路是把“硬件相关”和“算法相关”分开。底盘和雷达的驱动放在独立 launch 文件里，因为它们的设备接口、串口名称、话题名称最容易变；Cartographer 的 Lua 参数单独放到 config 里，方便针对不同场景切换。Rviz 配置也值得单独维护，建图时你需要同时看到 /map、子图、激光帧、机器人模型和轨迹，缺一样都很难判断问题出在数据链路还是算法参数。

2. 建图链路配置：从激光数据到栅格地图的关键路径

2.1 硬件与坐标变换准备

lingbot-map 这套配置原始设计面向的是差速底盘 + 单线激光雷达的组合。差速底盘提供了 /odom 里程计话题和 odom -> base_link 的 TF 变换，单线激光雷达提供 /scan 话题。需要注意，激光雷达通常安装在底盘上方某个固定位置，所以必须有 laser 到 base_link 的静态 TF。

在动手调 Cartographer 之前，我先把所有 TF 关系列了出来：

map -> odom (由 Cartographer 发布，位姿图优化的结果) odom -> base_link (底盘驱动发布，来自编码器里程计) base_link -> laser (静态变换，由雷达安装位置决定)

这里最容易踩的坑是很多人只配置了 laser 到 base_link，却忽略了 odom 到底是谁发布的。Cartographer 默认允许自己去“补充” odom 与 base_link 之间的变换，如果底盘驱动已经发布了 odom，而 Cartographer 又去抢着发布，就会产生 TF 丢帧和地图抖动的现象。我的处理方式是让底盘驱动只发布 odom->base_link，Cartographer 发布 map->odom，职责单一，排查问题也更方便。

雷达安装位置的静态变换可以通过一个简单的量测流程来标定：把机器人推到一堵墙边，用激光在 Rviz 里看墙面的点云是否和模型侧面平行。如果不平行，就在 static_transform_publisher 里逐步调整 yaw 角度，直到点云形成的直线和机器人侧面一致。这一步看起来简单，但如果不校准，后面所有 map 角度都会是歪的。

2.2 Cartographer 的 Lua 参数到底怎么调

Cartographer 的参数都在一个 Lua 文件里，很多人看到一堆层级结构就头大。其实 lingbot-map 里只需要重点关注几个关键项。

我的 lingbot_2d.lua 核心配置如下：

include "map_builder.lua" include "trajectory_builder.lua" options = { map_builder = MAP_BUILDER, trajectory_builder = TRAJECTORY_BUILDER_2D, map_frame = "map", tracking_frame = "base_link", published_frame = "odom", odom_frame = "odom", provide_odom_frame = true, use_odometry = true, num_laser_scans = 1, num_multi_echo_laser_scans = 0, } TRAJECTORY_BUILDER_2D.use_imu_data = false 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.use_online_correlative_scan_matching = true TRAJECTORY_BUILDER_2D.real_time_correlative_scan_matcher.linear_search_window = 0.1 TRAJECTORY_BUILDER_2D.real_time_correlative_scan_matcher.angular_search_window = math.rad(10.) TRAJECTORY_BUILDER_2D.ceres_scan_matcher.translation_weight = 1.0 TRAJECTORY_BUILDER_2D.ceres_scan_matcher.rotation_weight = 1.0 TRAJECTORY_BUILDER_2D.ceres_scan_matcher.occupied_space_weight = 1.0 MAP_BUILDER.use_trajectory_builder_2d = true MAP_BUILDER.num_background_threads = 4 MAP_BUILDER.pose_graph.optimize_every_n_nodes = 20

逐个说下关键项：

• min_range 和 max_range：必须根据雷达参数设置。普通单线激光雷达最小量程大多是 0.1 到 0.2 米，如果 min_range 设置太大，靠近雷达的障碍物会被丢弃，机器人贴着墙走时点云会突然少一截。max_range 设置要保守一点，别把雷达标称最远量程当作建图量程，因为远距离点云噪点大、角度误差会被距离放大。

• missing_data_ray_length：这个参数很多人不理解。它表示当激光束没有打中障碍物时，这条方向上的“虚拟射线”算多远。默认如果设成 0，Cartographer 会把没打中的区域完全当作未知，地图上会出现大量黑色区域。设成一个合理值如 5 米，可以让激光穿过的空旷区域在栅格地图里被标记为 free，地图看起来更干净，导航时代价地图也不会把明明空的地方当成未知禁区。

• use_online_correlative_scan_matching：这个开关建议打开。它是在 Ceres 精确匹配之前先做一个粗略搜索，相当于先在大范围里找一个不错的初值，再精配准。代价是多一点 CPU 占用，但能显著减少局部匹配掉进局部最小值的问题。尤其当你用手柄推着机器人快速旋转时，这行配置救过我很多次。

• ceres_scan_matcher 里的 translation_weight 和 rotation_weight：如果不小心把 rotation_weight 调太小，算法会觉得旋转误差“无所谓”，地图就会在转弯处积累角度误差；反过来调太大，又会导致算法为了迎合旋转约束而忽略点云的实际形状。一般先用默认的 1.0 稳定跑一遍再微调。

2.3 分辨率怎么选：不是越细越好

很多人拿到建图工程第一件事就是把分辨率改成 2cm 甚至 1cm，总觉得越细越准。实际上分辨率必须和雷达的角分辨率匹配，否则只是增加计算量和地图文件体积。

用一个简单计算来说明：假设单线激光雷达的角分辨率是 0.5 度。在距离 4 米处，相邻两个激光点的间距大约是：

间距 = 4 * tan(0.5°) ≈ 4 * 0.008727 ≈ 0.035 米

在距离 8 米处，间距扩大到约 0.07 米。如果你把栅格地图分辨率设置为 1cm，那么激光在 4 米外的每个“点”之间隔着三四个像素，像素其实是被插值或者空出来的，并没有真实测量数据支撑。所以实际操作中，5cm 分辨率对室内单线雷达建图是一个很合理的起点。雷达在 4 米左右的数据能填满多数栅格，而 8 米外的偶尔空一点也可以接受。

还有一层是文件体积和导航性能。一张 50 米乘 50 米的地图，如果分辨率是 0.05 米，边长像素数是 1000，总像素 100 万个，PGM 文件大约 1MB。如果改成 0.02 米，边长像素数变成 2500，总像素 625 万，文件体积和后续代价地图维护量都明显上升。导航栈的 costmap 还要在内存里维护膨胀层和障碍层，并不是地图越细越好。

2.4 TF 常见坑

建图过程中如果 Rviz 里出现机器人模型和激光点云分离，或者地图和点云隔着一段距离，绝大多数是 TF 问题。

我见过最典型的一个问题是：底盘驱动把 odom 坐标系发布成了odom_combined，而 Cartographer 配置里写的还是odom。这导致地图参考系和里程计参考系不是同一个 TF 树，Cartographer 虽然也能启动，但 map 到 odom 的变换会额外耦合一个未知的偏移，地图转着转着就飘走。检查方法很简单，启动后运行：

rosrun tf tf_monitor odom base_link rosrun tf tf_echo odom base_link

如果 TF 树里有两个 odom 开头的坐标系，或者 base_link 的父坐标系不是 odom，就要先改驱动配置，而不是急着调算法参数。

另一个坑是 static_transform_publisher 的坐标定义。雷达通常装在机器人前方偏上位置，如果只给了 x、y、z 的平移，没给 yaw 的旋转，Rviz 里点云会整体偏转一个角度。建议在标定的时候把雷达安装的 yaw、pitch、roll 全部写清楚，哪怕 pitch 看起来接近 0 也要写 0。

3. 完整实操：把 lingbot-map 跑起来的七个步骤

3.1 安装与编译环境

lingbot-map 基于 ROS 1 Noetic 开发和验证。选择 ROS 1 不是因为它最新，而是 Cartographer 在 ROS 1 下的接口最成熟，安装和调试路径最短。对于只想尽快出图的人来说，稳定和可复现比版本新旧更重要。

安装 Cartographer 相关依赖：

sudo apt install ros-noetic-cartographer ros-noetic-cartographer-ros

然后把项目放进自己的工作空间：

mkdir -p ~/lingbot_ws/src cd ~/lingbot_ws/src # 将 lingbot_map 目录放到这里 cd ~/lingbot_ws catkin_make source devel/setup.bash

如果只有 lingbot_map 这一个包，编译很快。需要注意，Cartographer 的 launch 文件里写了很多参数路径，用绝对路径会很容易因为换电脑而失效，我的习惯是全部写成$(find lingbot_map)/...这样相对包路径的写法。

3.2 启动底盘、雷达和 TF

上面的目录结构里，把底盘和雷达分别放在独立 launch 文件，就是为了能单独验证每一段链路。

先启动底盘驱动：

roslaunch lingbot_map lingbot_base.launch

这个文件里重点检查两件事：一是要正确发布 odom->base_link 的 TF，二是里程计的协方差初始值不要太离谱。很多底盘驱动默认把 position covariance 设成 0，这样会导致后续 EKF 或 Cartographer 里的位姿估计过度信任里程计。合理做法是把线速度位置协方差设置成一个很小的非零值，比如1e-6，表示“这里有一点点不确定性”，而不是“绝对精确”。

再启动雷达驱动：

roslaunch lingbot_map lingbot_lidar.launch

雷达启动后先不要急着进建图，先检查话题和频率：

rostopic hz /scan rostopic echo /scan | head

单线雷达的 /scan 频率如果是 10Hz，Cartographer 默认可以正常工作；如果雷达能调成 20Hz，需要同时注意 CPU 占用，不一定非要拉满频率。点云频率高并不能直接带来更高精度的地图，因为 Cartographer 内部会做子图积累和位姿图优化。

3.3 启动建图主程序

确认雷达、底盘、TF 都正常后，启动 lingbot-map 的建图主文件：

roslaunch lingbot_map lingbot_mapping.launch

mapping launch 的核心内容大致是这样：

<launch> <arg name="use_sim_time" default="false"/> <node name="cartographer_node" pkg="cartographer_ros" type="cartographer_node" args="-configuration_directory $(find lingbot_map)/config/ -configuration_basename lingbot_2d.lua" output="screen"> </node> <node name="cartographer_occupancy_grid_node" pkg="cartographer_ros" type="cartographer_occupancy_grid_node" output="screen"> </node> </launch>

cartographer_node 负责处理激光、里程计、IMU 并维护位姿图；cartographer_occupancy_grid_node 负责把子图实时拼接成 /map 话题供 Rviz 显示。如果你在 Rviz 里添加 /map 话题后一直没数据，优先检查 occupancy grid 节点有没有启动成功，以及它的输出话题是否被重映射过。

3.4 扫描路径和回环策略

建图时扫描路径的重要性不亚于参数。我的经验是：先慢速沿墙走一圈，把周边环境轮廓扫清楚；再走中间区域，把结构连接起来；最后一定要做一次回环。

回环是 Cartographer 发挥最强能力的关键。所谓回环，就是让机器人回到之前经过的地方，并且让当前激光扫描到的位置和之前子图里的位置重叠。当系统检测到这种“闭合”，位姿图优化就会调整之前所有子图的位姿，把累积漂移压下去。

如果没有回环，或者回环太少，Cartographer 的地图在长距离上依然可能缓慢扭曲。实际操作中，如果现场有一条较长的走廊，单纯沿走廊去再回来还不够，最好在走廊两端各做一个小半径转向，让雷达能看到走廊两侧的墙面特征，给回环检测提供更充足的约束。

还有一个容易忽略的问题：建图时不要突然快速原地旋转，尤其是没有 IMU 的情况下。快速旋转会造成相邻两帧激光重叠区域太小，局部扫描匹配容易掉到错误的局部最优解。控制机器人转弯角速度不要超过 0.5 弧度每秒是比较稳妥的。

3.5 保存地图并转成导航地图

扫描满意后，先结束轨迹并保存 pbstream：

rosservice call /finish_trajectory 0 rosservice call /write_state "{filename: '/tmp/lingbot_map.pbstream'}"

pbstream 是 Cartographer 的完整建图状态文件，里面包含所有子图、位姿节点和约束关系，之后还能继续加载增量建图或做纯定位。但导航栈不认识 pbstream，所以需要转成 PGM + YAML：

rosrun cartographer_ros cartographer_pbstream_to_ros_map \ -pbstream_filename /tmp/lingbot_map.pbstream \ -map_filestem /tmp/lingbot_map

执行后会生成/tmp/lingbot_map.pgm和/tmp/lingbot_map.yaml。YAML 文件内容类似：

image: /tmp/lingbot_map.pgm resolution: 0.05 origin: [-25.0, -25.0, 0.0] negate: 0 occupied_thresh: 0.65 free_thresh: 0.196

这里 occupied_thresh 和 free_thresh 是 Cartographer 转换工具建议使用的默认阈值，一般不要乱改。origin表示地图左下角在 map 坐标系下的位置，如果地图保存后右下角或左上角有大量空白，可以适当调整 origin 让地图内容居中，但这不影响导航质量。

4. 实测中的经典问题与排查技巧

4.1 建图跳变和重影

跳变最常见的场景是机器人停下时，激光点云在 Rviz 里还在缓慢漂移；或者地图出现“重影”，同一面墙在画面里同时存在两层轮廓。

这种问题大概率不是 Cartographer 参数引起的，而是里程计质量太差。差速底盘的里程计如果长时间运行，轮子打滑、左右轮直径不一致、编码器分辨率不足都会导致 odom 漂移。处理办法分几步：

• 先做里程计标定，不要让底盘在粗制滥造的参数下影响整个系统；
• 把底盘速度调低，尤其是直线速度不要超过 0.5 米每秒；
• 检查雷达点云与机器人模型的相对位置是否稳定，如果雷达安装支架松动，任何算法都救不回来。

如果加了 IMU，还要检查 IMU 数据的坐标系朝向是否正确。常见错误是 IMU 的 pitch 轴和实际 pitch 轴相反，导致 Cartographer 认为机器人倾斜，严重时地图会被直接“扭歪”。

4.2 累计漂移和回环不触发

有一次我在厂房建图，机器人走了一个很大的“几”字路线，视觉上走廊都是直的，但左右两段地图明显错开了一个角度。回环检测一直不触发，因为机器人最后停下来的位置虽然离起点很近，但由于中间错位，当前激光帧和起点子图的重叠率一直低于触发阈值。

这个问题的核心是：错位发生后，回环算法自己很难把“错得太远”的约束找回来。解决办法不是死调回环参数，而是保证建图过程中多次制造小型回环，比如绕一个岛形区域转一圈。小的回环会持续约束位姿图，让大回环始终有机会触发。

另外不要忽略pose_graph.optimize_every_n_nodes这个参数。它表示每积累多少个节点做一次全局优化。太大会让优化不频繁，地图在视觉上一直处于“微调中”；太小则 CPU 占用高，而且可能导致优化结果因果断地调整子图位姿让地图不断“跳边”。我用 20 作为起点，如果地图在转弯处总出现抖动，会尝试调整到 10 到 15。

4.3 CPU 和内存占用过高

Cartographer 比 gmapping 更吃性能是正常的。它需要同时维护局部匹配、子图概率网格和全局位姿图。但如果 CPU 长期占用接近 100%，而且地图越来越卡，就要检查几个方面。

首先，MAP_BUILDER.num_background_threads不要随意调大。4 个线程对一般室内机器人足够，超过这个值并不会线性提升速度，反而会增加线程切换开销。

其次，雷达话题频率如果被雷达驱动设置得过高，Cartographer 会忙于处理每一帧激光。普通室内建图 10Hz 完全够用，没有必要为了视觉上更“密”的扫描点而把频率提高一倍。

还有一点经常被忽略：如果你在 /scan 话题之前又接了一个滤波节点，比如体素滤波、中值滤波、去噪滤波，请注意保持输出频率稳定。滤波节点如果跑得慢，就会造成激光数据时间戳拥堵，Cartographer 收到数据时已经是“过去”的数据，看上去就是 map 更新变慢和轨迹滞后。

4.4 地图转 PGM 后的细节丢失

pbstream 转成 PGM 后，有些人会发现地图“简化”了：细柱子没了，墙角变成圆弧，或者原本很清楚的障碍物边缘变得模糊。这通常不是转换工具的问题，而是 Cartographer 栅格地图的表示方式和导航地图的需求不一样。

Cartographer 内部的子图概率网格保存的是每个栅格被占据的概率，转换工具在输出 PGM 时会把概率映射到 0 到 255 的灰度值。导航栈关心的则是“这个格子是 free、occupied 还是 unknown”，所以会按照 occupied_thresh 和 free_thresh 做二值化。如果柱子太细，或者激光在柱子后面缺少多角度观测，栅格概率可能只到 0.4 左右，二值化后就被当成 free 了。

我的做法是：建图时不只扫一遍，遇到细柱、薄墙这类目标时，尽量绕它一圈或者在不同距离各扫一次，让概率网格充分累积。这样导出的地图就不会丢失这些细节。

4.5 问题速查表

5. 从 map 到 use：lingbot-map 的后续扩展和我的坑

5.1 给导航栈用：YAML 参数和代价地图适配

地图导出来后，导航栈的 map_server 可以直接加载：

rosrun map_server map_server /tmp/lingbot_map.yaml

但导航能不能用，还要看代价地图的配置。在 navigation stack 里，global_costmap 和 local_costmap 的static_map参数要设置为 true，并且要订阅 map 话题。如果你的机器人本身不大，膨胀半径不要用官方 Demo 里的默认 0.5 米，而应该根据车体宽度重新算。

比如车体宽度 0.4 米，那么膨胀半径至少要给 0.2 米以上，保证规划出来的路径不会贴着墙。这里有一个实际教训：我在 lingbot-map 刚做好的时候，觉得自己建图很准，就把膨胀半径调成了 0.15 米，结果导航过程中频繁出现“路径离墙太近导致转向卡住”的问题。后来把膨胀半径调回 0.25 米，路径立即顺了很多。地图精度高，不代表导航不需要余量。

5.2 加入 IMU 的注意事项

lingbot-map 最初版本没有用 IMU，跑下来也能出图，但在不平整地面或者底盘打滑时明显吃力。后来加了一个 IMU，反而先引入了一堆问题。最常见的是 IMU 坐标系的 axis 配置不对，Cartographer 把重力方向解算错了，导致 2D 建图里的机器人平面被旋转到奇怪角度。

如果你的雷达数据本身质量不错，且底盘在室内平整地面运行，先用use_imu_data = false建一版稳定的图，再去接 IMU。接 IMU 时不要一次把所有数据都喂给 Cartographer，先在 Rviz 里检查 IMU 的 orientation 是否跟随机器人姿态自然变化。这一步能省掉后来花费在 TF 和坐标轴上的大量时间。

5.3 最后一点个人体会

lingbot-map 这个项目做到后面，我最大的体会是：建图工程的瓶颈通常不在算法本身，而在你对数据的理解。激光扫描质量、里程计精度、TF 正确性，这些才是决定地图好坏的地基。遇到问题不要盲目去改 Cartographer 的一大堆“高级参数”，先把数据链路逐段验证一遍。参数调优是很自然的事，难的是知道该调谁。

如果你现在也卡在机器人建图这一步，建议就从最简配置开始：一台差速底盘、一个单线激光雷达、一份 5cm 分辨率配置，先跑出一张能闭环的粗糙地图，再逐步优化细节。很多看起来复杂的建图问题，其实就是一次数据来源排查和一个参数优先级判断的事。