写这一篇的时候我刚在Gazebo里连续跑了几个小时仿真把TurtleBot3从模拟仓库开到模拟走廊又换到真实小车上试了一遍。整个过程里gmapping既给我带来了按几个键就能出地图的爽快感也让我踩了不少关于参数调优和坐标变换的坑。这篇文章就把我的实操记录、踩坑经过和调整思路一次性整理清楚给同样在做ROS机器人SLAM建图的朋友当参考。1. 准备工作从环境搭建到启动第一个gmapping建图1.1 环境选择与安装思路先说环境。我这边用的是Ubuntu 20.04 ROS Noetic原因是gmapping在Noetic上支持得最干净基本不需要额外折腾依赖。如果你用的是Ubuntu 22.04 ROS 2 Humble情况会稍微不同——ROS 2原生没有官方维护的gmapping功能包社区维护版本虽然能编译但不如直接用slam_toolbox方便slam_toolbox本身就是Gmapping的升级版保留了很多Gmapping的设计思路雷达数据处理接口也类似。很多新手在第一步就被安装劝退了。这里我不重复写一遍完整的ROS安装步骤只给一个非常明确的建议Ubuntu版本和ROS版本必须严格对应。Ubuntu 20.04对应ROS NoeticUbuntu 22.04对应ROS 2 Humble跨版本安装大概率会出现无法定位软件包一类的问题。如果你还在为安装ROS发愁可以搜索鱼香ROS一键安装这个社区工具对新手特别友好一条命令就能把环境搭好省去手动配源的很多麻烦。1.2 在Gazebo仿真中准备好机器人和环境我这次建图实验分两步走先在Gazebo仿真里跑通流程再上真实小车验证。仿真最大的好处是可以随时重置环境、修改参数不用担心里程计漂移把车撞了。第一步安装必要的功能包sudo apt install ros-noetic-gmapping ros-noetic-map-server ros-noetic-navigation sudo apt install ros-noetic-turtlebot3 ros-noetic-turtlebot3-simulations第二步设置TurtleBot3模型并启动仿真环境echo export TURTLEBOT3_MODELwaffle ~/.bashrc source ~/.bashrc roslaunch turtlebot3_gazebo turtlebot3_world.launch这个turtlebot3_world是一个带有墙壁、柱子和障碍物的室内小场景非常适合做gmapping的入门测试。它会启动一个完整的Gazebo仿真环境包含机器人模型、激光雷达传感器和物理引擎。然后在另一个终端启动键盘控制节点roslaunch turtlebot3_teleop turtlebot3_teleop_key.launch这样你就获得了对机器人的手动控制权可以开着车在场景里转悠为建图提供位姿轨迹。1.3 手动启动gmapping节点的完整流程很多教程喜欢直接给大家一个现成的launch文件但我觉得第一次做最好手动拆解启动这样能直观看到gmapping依赖了哪些节点、发布了哪些topic对后续排错非常有帮助。启动gmapping节点rosrun gmapping slam_gmapping scan:/scan _base_frame:base_footprint _odom_frame:odom这里的参数映射很关键scan:/scan把gmapping默认订阅的/scan话题映射到TurtleBot3实际发布的激光话题。如果你的雷达话题名不同比如/laser、/lidar就在这里改。_base_frame:base_footprint指定机器人的基座坐标系。TurtleBot3是base_footprint但有些机器人用的是base_link根据自己的URDF模型设定。_odom_frame:odom指定里程计坐标系。启动后可以用rqt_graph查看节点关系或者用rostopic echo /map确认地图话题是否有数据输出。如果你看不到地图数据90%的情况是tf树不完整这个后面详细说。1.4 launch文件整合一劳永逸的启动方式手动启动能帮助理解但每次开三个终端确实麻烦。所以我后来还是写了一个整合的launch文件把机器人状态发布、gmapping、地图话题输出都打包在一起launch !-- 机器人模型与状态发布 -- param namerobot_description command$(find xacro)/xacro $(find turtlebot3_description)/urdf/turtlebot3_waffle.urdf.xacro / node pkgrobot_state_publisher typerobot_state_publisher namerobot_state_publisher outputscreen / !-- Gmapping 核心节点 -- node pkggmapping typeslam_gmapping nameslam_gmapping outputscreen param namebase_frame valuebase_footprint/ param nameodom_frame valueodom/ param namemap_frame valuemap/ param namemaxUrange value5.0/ param namemaxRange value6.0/ param nameparticles value30/ param nameminimumScore value50/ param namelinearUpdate value0.1/ param nameangularUpdate value0.2/ param nametemporalUpdate value0.5/ param namemap_update_interval value2.0/ /node /launch关于launch文件里每个参数的含义和调优逻辑下一节我会拆开讲——这是gmapping实验里最有价值的部分也是我花了最多时间试错才搞明白的。2. gmapping的底牌粒子滤波与核心参数调优2.1 粒子滤波、Rao-Blackwellized到底在干嘛很多教程把gmapping当作一个黑盒来用按几个键把地图建出来就算完事。但如果只是这样一旦地图飘了、歪了、有重影了你根本不知道从哪儿下手修。所以我想先花点篇幅把gmapping的原理讲明白。Gmapping的核心是Rao-Blackwellized粒子滤波RBPF。这个名字看起来很吓人但拆开看并不复杂。Slam建图要解决的本质上是这样一个鸡生蛋的问题要构建地图你得知道机器人的位置要知道机器人的位置你又得有一张地图来对照激光扫描数据。传统解法是先定位后建图RBPF的思路则是同时维护很多个猜测版本的机器人轨迹每个轨迹版本对应一张地图。这些轨迹版本就是粒子。每来一帧激光数据就用当前时刻的机器人位姿和激光观测去修正地图然后对比每个粒子的观测置信度保留置信度高的粒子淘汰置信度低的粒子用这种方式逼着整个系统朝正确的轨迹和地图收敛。打个比方就像一群人站在一个陌生的房间里每个人都闭着眼睛走了一段路每走一步摸一次墙壁。某些人走的路线让每次摸到的墙壁位置都自洽这些人留下的墙壁地图就越来越清晰另外一些人走的路线前后矛盾摸到的墙壁位置不断打架这些人就被淘汰掉了。Gmapping对RBPF的具体改进在于在预测粒子下一步位置的时候不仅用里程计信息还提前用当前帧激光扫描数据做了一次修正让粒子的分布更加集中在真实位姿附近。这也是为什么Gmapping在计算资源有限的小机器人上效果比早期粒子滤波SLAM算法好得多——它不需要那么多粒子就能维持差不多的建图质量。但是粒子滤波的天花板也很明显它是一个维持多样化猜测的过程主要依靠不断地猜测、淘汰、重新采样来逼近真实轨迹。一旦里程计漂移严重、激光匹配得分整体偏低比如环境特征太少激光扫描基本处于看谁都像的状态整个粒子群就会集体跑偏而且跑偏后很难再拉回来。这也是大场景建图容易失败的原因。2.2 核心参数逐项拆解每个参数到底在控制什么了解了原理参数就比较好理解了。Gmapping在launch文件里有一堆参数我按功能分组来解运动/观测噪声参数描述雷达与里程计的信任程度参数含义我常用的值调整思路srr机器人平移时里程计位移带来的角度误差弧度/米0.01值越小越信任里程计的角度估计如果机器人轮子打滑严重适当调大srt机器人平移时里程计位移带来的平移误差米/米0.02同上str机器人旋转时里程计旋转带来的位移误差米/弧度0.02值越小越信任旋转时的位移估计stt机器人旋转时里程计旋转带来的角度误差弧度/弧度0.01值越小越信任旋转时的角度估计srr与srt的区别前者是走直线时方向会不会漂后者是走直线时位置会不会漂—在铺设光滑地砖的真实环境中我会把srr调大到0.05以上因为轮胎确实容易在加速瞬间打滑这四个参数描述的是运动模型的不确定性。你可以把它们理解为卡尔曼滤波里的过程噪声协方差。数值越大gmapping就越不相信里程计给出的位移和角度转而更加依赖激光匹配结果来确定位姿。这里有个常见的误区不少人以为把srr、srt这些参数调小就能让地图更精确。实际恰恰相反——如果你把噪声参数调得小于机器人真实的打滑水平系统会过度相信里程计一旦轮子真的打滑了地图立刻出现重影或偏斜。正确的做法是给里程计留出合理的怀疑空间让激光匹配有机会纠正里程计的错误。激光匹配相关参数决定建图的质量上限参数含义我常用的值调整思路maxUrange激光最大有效测量距离米5.0超过这个距离的激光点会被用于匹配但不会更新空闲区域的地图maxRange激光最大扫描范围米6.0雷达硬件最大量程一般比maxUrange大20%左右minimumScore激光匹配的最低得分阈值50如果匹配得分低于这个值就认为当前帧扫描和地图对不上不更新地图delta地图栅格大小米/像素0.05默认是0.05米即每像素代表5厘米。越小地图越精细但计算量越大kernelSize搜索窗口大小用于寻找最优匹配10值越大搜索空间越大匹配越鲁棒但CPU占用越高提一下maxUrange这个参数它和雷达最大量程不是一回事。maxUrange决定了你在建图时能利用多远的激光点。在实际建图时我不会把maxUrange设得太大原因有二第一远处的激光点噪声大会干扰匹配精度第二激光超过一定距离后入射角很大打在障碍物边缘容易产生拖尾噪声。TurtleBot3的雷达量程大概是3.5米我把maxUrange设为3.0左右能有效把靠谱的近距离点和不靠谱的远距离点分开。地图更新策略参数决定建图的实时性与平滑度参数含义我常用的值调整思路linearUpdate机器人平移多少米触发一次扫描匹配与地图更新0.1值越小建图越密集但计算负载越高angularUpdate机器人旋转多少弧度触发一次扫描匹配与地图更新0.2旋转时尤其要触发扫描匹配否则转向过程中地图容易糊temporalUpdate距离上次更新超过多少秒强制触发一次更新0.5防止机器人静止不动时地图长时间不更新map_update_interval地图发布的时间间隔秒2.0值越小地图刷新越流畅但CPU占用越高这三个Update参数组合起来实际上控制的是多久做一次扫描匹配和多久发布一次地图。注意区分扫描匹配决定机器人的位姿估算是否修正地图发布决定你看到的/map话题是否更新。即使机器人静止不动只要temporalUpdate到了也会做一次匹配这能防止机器人在原地小幅晃动时位姿飘移。在这组参数里最值得新手注意的坑是angularUpdate不宜过大。我第一次用默认值0.3跑仿真机器人转个90度的弯时地图上转角处经常出现一道模糊的拖影。原因就是转向过程中帧与帧之间的角度差太大激光扫描的匹配窗口跟不上。把angularUpdate降到0.1到0.2之后转弯处的地图明显干净了。粒子数参数最直接影响CPU占用的开关参数含义我的建议值说明particles粒子滤波中维持的粒子数量30~80值越大建图越鲁棒但CPU负载直线上升粒子数量是gmapping里最贵的一个参数。每个粒子都维护着一张完整的栅格地图粒子数从30调到80内存和CPU占用几乎翻倍。性能一般的笔记本跑仿真时我会控制在30左右在真实小车上用性能较好的主控板时可以放到50到80环境越复杂、里程计越差需要的粒子数越多。2.3 一组直接能用的调参参考结合上面的分析我整理了三组不同场景下的参数配置你可以直接参考参数仿真环境TurtleBot3真实小车室内平整地面真实小车粗糙/地毯地面srr0.010.030.08srt0.020.050.10str0.020.050.10stt0.010.030.08particles305080linearUpdate0.10.050.05angularUpdate0.20.10.1minimumScore50100200maxUrange3.05.05.0map_update_interval2.01.01.0为什么粗糙地面需要更大的srr、srt和更多粒子因为地毯和凹凸不平的地面会让轮子产生不可预测的打滑里程计误差急剧增大。这时候必须让gmapping更加依赖激光匹配而不是里程计预测同时用更多粒子来维持足够的位姿猜测多样性。minimumScore在真实环境中也要调高一点。原因是在光线变化、人群走动等干扰下激光匹配很容易得到虚假的高分。把阈值调高能强迫系统只接受真正高质量的匹配避免被异常数据带偏。但注意阈值不能过高否则在环境特征稀疏的长走廊里激光扫描几乎没有有效特征匹配得分会持续低于阈值导致地图长时间不更新。3. 建图实测与典型问题排查地图为什么会飘、扭、糊3.1 第一次建图遇到的地图偏斜问题我先说一个最典型的故障现象地图建到一半墙壁开始歪了。明明走的是笔直的走廊地图上却呈现出逐渐偏移的弧形转角的墙角也不再是直角。我遇到这个问题时第一反应是调粒子数结果没用。后来用rqt_tf_tree查看tf树才发现问题不在gmapping而在里程计数据本身——仿真的里程计虽然理想但在高速急转时仍然会产生明显漂移。我又检查了/odom话题的频率和协方差发现机器人转弯时odom消息的角速度数据有明显跳变。排障链路是这样的先确认tf树是否完整map - odom - base_footprint - base_link - laser缺任何一环gmapping都无法工作。再用rostopic echo /odom检查里程计数据的连续性和振幅如果出现跳变说明里程计源头有问题。最后用rviz同时显示激光点云和robot model观察激光点云是否贴合在小车模型周围——如果不贴合说明激光的安装位置标定有误差或外参laser相对base_link的变换没设对。在我这个案例里问题其实是激光的外参。TurtleBot3的激光雷达装在机器人顶部和base_link之间有一个高度偏移但由于URDF里没有正确声明laser坐标系导致gmapping认为雷达装在机器人的中心点。转向时激光的旋转中心和小车的旋转中心不一致累积起来就出现了地图走廊越来越歪的现象。这个坑在真实机器人上更容易踩。很多diy小车把激光雷达装在车体前方或后方而不是旋转中心上方这时必须在URDF中精确声明laser关节相对于base_link的xyz偏移否则建图效果会非常差——你可能会以为是gmapping算法不行其实只是外参标定没做。3.2 地图出现重影粒子发散和激光匹配失败的博弈第二个常见问题是重影。具体表现是墙壁变成了两条线或者同一个柱子周围出现一圈光晕。重影的本质是粒子滤波器在某个时刻产生了两个完全不同的可信轨迹一个认为机器人在走廊左侧另一个认为在走廊右侧两个轨迹分别生成了两张地图叠加在一起就成了重影。什么情况会导致粒子发散主要是三个因素叠加环境特征不足。比如在一条非常长的笔直走廊里激光在走廊方向上的观测几乎没有区别所有粒子都有相似的匹配得分系统无法从中挑出唯一正确的轨迹。里程计误差过大。粒子预测的分布本来就铺得很开再加上环境特征不足无法收敛。linearUpdate和angularUpdate过大导致触发匹配的频率太低系统长时间没有修正机会发散已经形成后才做一次匹配为时已晚。针对重影我从实践中总结了一套排查顺序第一步先判断是局部重影还是全局重影。如果只是转弯处重影优先调小angularUpdate和linearUpdate让转向过程的帧间匹配更密集。我之前就是通过这个办法解决了大部分局部重影。第二步如果整个地图都发虚、糊成一片优先检查里程计稳定性。把srr、srt整体调大给里程计更多不确定性同时把particles加倍试试。这样做的逻辑是既然里程计靠不住就让滤波器更依赖激光匹配同时用更多粒子去广撒网。第三步如果长走廊场景始终重影那是gmapping这类粒子滤波方法的先天短板。解决思路有两个一是调整控制策略不要匀速直线长距离行走走几米就转个弯、换个角度扫描环境人为给激光匹配增加特征二是换用cartographer这类基于图优化的SLAM算法它通过子图submap间的回环检测能更有效地处理长走廊场景。补充一点很多人在室内场景建图时喜欢关掉所有灯光觉得激光雷达不需要光。这是个误区。虽然激光雷达不依赖可见光但某些家具、玻璃、镜面、黑色哑光表面在暗光环境和亮光环境下的反射特性是有差异的。我实测下来保持环境光线稳定一致比频繁变换光线条件的地图效果好很多。3.3 地图上出现幽灵障碍物动态物体与雷达噪声的干扰有一次在真实小车上建图时我发现地图上出现了一个不该存在的幽灵障碍物——一堵厚约10厘米的短墙但我清清楚楚记得那个位置什么都没有。排查过程花了我半小时最后发现是一只垃圾桶它在我建图经过时恰好被风吹动了一下。看起来很简单但这件事给我提了个醒gmapping本质上是静态环境的假设——它默认地图里的一切都是固定的。任何动态物体行人、移动的推车、开关的门都会在地图上留下痕迹。动态物体干扰的处理策略我总结为三层第一层控制操作习惯。建图时清场请同事暂时离开房间关门并固定住。这是成本最低、效果最直接的做法。第二层利用srr等参数间接抑制。把噪声参数适当调大让gmapping对观测中的异常点不那么敏感——但这只能减轻不能根除。第三层换用自带动态物体过滤的SLAM算法。比如cartographer的hold_out参数、某些开源算法中的动态点云滤除模块如ground removal、moving object detection。如果你必须在有行人的开放环境建图建议直接用cartographer或slam_toolbox的后续版本别再和gmapping死磕了。3.4 里程计话题频率不足导致的锯齿状地图第四个冷门问题也值得一提。有一次我帮朋友调他的DIY小车地图总是出现不规则的锯齿状边缘就像蒙了一层马赛克。检查了所有参数、tf树、激光外参都没问题最后用rostopic hz /odom一看——里程计发布频率只有8赫兹明显偏低。Gmapping对里程计频率是有隐性要求的。如果里程计update速率低于激光的采集速率机器人每走一步粒子预测阶段就缺乏足够的运动信息导致扫描匹配的初值不准。这就好比你闭着眼睛走路别人每隔两秒才告诉你一次你现在大概在哪个位置你能走出直线才怪。这类问题的解决方式是直接调整里程计发布节点。如果是基于轮式编码器的里程计节点检查是否有人在循环里添加了不必要的高延迟处理逻辑比如把编码器数据通过网络远程传输再进行解算——延迟会直接体现在里程计话题的时间戳上。我遇到的那个案例就是朋友把编码器数据先通过Wi-Fi发到上位机再解算网络抖动导致里程计帧间隔不均。改成在单片机本地解算后再发布问题就消失了。4. 建图只是开始地图保存、质量检查与后续规划4.1 使用map_server保存地图建好一张满意地图后下一步就是保存。ROS中保存地图用的是map_server功能包里自带的map_saver命令rosrun map_server map_saver -f ~/maps/room1运行这条命令后会在~/maps/目录下生成两个文件room1.pgm地图图像和room1.yaml地图元数据。如果你想保存当前rviz中看到的彩色地图的可导航版本只包含栅格可通行区域可以在保存前先把地图话题转换一下不过这超出了gmapping本身的范畴暂时按下不表。room1.yaml的内容一般长这样image: room1.pgm resolution: 0.050000 origin: [-10.000000, -10.000000, 0.000000] negate: 0 occupied_thresh: 0.65 free_thresh: 0.196我来逐项解读resolution每个像素代表的实际长度单位是米/像素。0.05表示每像素5厘米。gmapping的delta参数决定了这个值保存时会自动写入。origin地图左下角像素在真实世界坐标系中的坐标[x, y, yaw]。这是gmapping内部基于激光匹配结果和轨迹推算出来的一般不用管。occupied_thresh栅格被占用的概率阈值。值越大越难把某个栅格判定为有障碍物。如果你发现建出来的地图在rviz里墙壁特别虚边缘处很多色块闪烁可以适当调低这个值比如0.5。free_thresh栅格为空闲的概率阈值。配合occupied_thresh使用两者之间的区域被判定为未知。4.2 地图质量检查清单保存完地图后别急着进导航阶段。先用肉眼和工具检查一遍地图质量很多导航中的撞墙迷路问题根源都在建图阶段。我的检查清单是这样的看整体轮廓房间应该是封闭的墙线连续没有缺口。如果走廊尽头是开着的检查是否因为雷达量程不够或者建图时没走到那个位置。看直角墙角理论上室内墙角应该是90度如果你导出的地图上墙角变成了圆弧或斜面说明激光匹配有轻微偏差或者里程计在转弯时有漂移。看厚度一致性同一面墙在不同的位置扫描墙线的厚度应该基本一致。如果同一面墙一段厚一段薄说明某些区域的激光数据质量差。检查黑色区域和白色区域的边界用图像查看器打开pgm文件黑色是障碍物白色是空闲区域灰色是未知区域。如果大片区域都是灰色说明你的建图轨迹没有覆盖到那个区域地图发布时没扫过的地方会标记为未知。用cartographer或第三方工具比对同一场景建两次图的一致性——虽然麻烦但这是验证算法稳定性的最硬核方式。我用这个清单检查过好几次发现最常见的问题是墙角圆弧化。这通常不是gmapping参数问题而是机器人转向时运动控制不够平滑导致的。如果你用键盘控制转弯时可以尝试小幅、多次按压转向键而不是按住不动。4.3 从建图到导航把地图交给amcl之前必须知道的事地图保存好之后你自然想往自主导航的方向走。这里有一个很重要的概念需要提前说清楚gmapping建的图是给谁用的Gmapping建图的同时已经完成了定位——它一直在用粒子滤波跟踪机器人的位姿。但当你重启机器人、把地图文件加载进来时gmapping就不再工作了此时需要另一个专门负责定位的模块——amcl自适应蒙特卡洛定位。AMCL和gmapping虽然都属于粒子滤波家族但任务不同gmapping是在建图的同时估计位姿并构建地图amcl是在已知地图的基础上单独估计机器人在地图中的位置。所以从建图切换导航时要注意以下几个问题坐标系必须一致。amcl默认在map坐标系下工作gmapping输出的地图环境也是以map坐标系为参考。如果你在建图时自定义了坐标系名称例如把map改成了mymap那么在导航时也要做相应的映射否则amcl会一直无法正确定位。分辨率要匹配。amcl在低分辨率地图上定位精度会下降但高分辨率地图对CPU要求也高。如果地图是0.05米/像素用0.02米/像素的图做导航会导致成本地图无法有效生成——两个分辨率grid单位必须和costmap配置保持一致。地图里不能有大量假障碍物。前面提到动态物体会在地图上留下痕迹到了导航阶段这些痕迹会变成不可通行区域导致路径规划绕远路或者完全找不到路径。如果你发现导航时机器人总是绕着某个实际不存在的障碍物转圈多半是建图阶段留下了幽灵障碍物得回到建图阶段去清理或者在costmap配置里把这些区域标记为inscribed或static layer忽略层。4.4 从gmapping到slam_toolbox/cartographer迁移时机与思路最后说一说什么时候应该放弃gmapping换用更先进的算法。我个人的迁移决策线是这样的当建图场景超过约1000平方米或者环境中存在大量长走廊、重复纹理区域或者需要在线更新地图比如地图动态变化场景我会直接放弃gmapping改用cartographer。原因前面也提到了gmapping的粒子滤波缺少回环检测机制。所谓回环检测是指算法识别出机器人回到了曾经到过的地方并据此修正整个历史轨迹的能力。Gmapping也可以通过调大粒子数来隐式实现一定程度的回环修正但代价极高——你要用几十倍的计算资源去换取本来应该由后端优化直接解决的事情。Cartographer使用子图submap加图优化的框架局部扫描匹配负责实时定位全局优化定期修正子图间的累积误差。它明显更适合大场景和需要回环修正的场景。代价是安装配置更复杂调参维度更多。Slam_toolbox则是一个更平滑的过渡选择。它在ROS 2里得到了良好维护算法思路保留了Gmapping的粒子滤波和扫描匹配框架同时引入了位姿图优化和回环检测能力对从gmapping迁移过来的用户特别友好——很多坐标系、话题名、参数命名习惯都很相似。所以我的建议是如果你的目标是快速跑通一个demo、验证机器人底盘和雷达的配合gmapping完全够用别折腾如果你的目标是构建可靠的多场景复用地图、准备长期运行导航系统那就不要试图把gmapping发挥到极限直接在slam_toolbox或cartographer上深入。4.5 调试时最值得拥有的三个工具写这篇文章的结尾部分我想分享三个在建图调试中帮了我大忙的工具它们不是技术难点但能极大提高排错效率。第一个是rviz这不是什么冷门工具但很多人用错了重点。在SLAM调试中我只关心三个显示项Map地图是否清晰、LaserScan激光点云是否贴合环境、Tf机器人各坐标系是否完整。其他花哨的显示项我会全部关掉避免画面过载干扰判断。第二个是rqt_tf_tree。当你怀疑坐标变换有问题时这个工具能画出一棵完整的tf坐标树让你一眼看出哪个坐标系没有正确连接。我在调试外参问题时就是靠它定位到laser坐标系没有挂在正确的parent下。第三个是rostopic hz和rostopic delay。这两个命令行工具能检查话题发布频率和延迟是否正常。前面提到的里程计频率不足问题就是靠rostopic hz /odom抓出来的。很多奇怪的建图问题根源其实是某个话题掉帧了而不是算法参数不对。最后说说我个人的操作体会。Gmapping最大的特点就是宽容——它对硬件要求不高、配置灵活、调参空间大非常适合作为理解SLAM算法原理的入门工具。但宽容不等于万能。在建图时养成随时观察地图质量、分阶段保存地图、每走一段路就检查一次激光匹配得分的习惯比事后想办法修图要高效得多。我每次建图前都会先让机器人原地旋转一圈通过rviz确认激光扫描的覆盖范围无异常后再开始正式建图这个习惯帮我避免了很多无谓的返工。