2D激光SLAM四算法实测对比与选型指南

做2D激光SLAM算法对比这件事我拖了小半年才真正动手。之前一直在单测Gmapping和Cartographer总觉得“四种算法放到同一台机器、同一个场景里跑一遍”很麻烦——要处理不同的参数接口、调不同的建图模式还要保证运动轨迹一致想想就头大。但后来给一个客户做仓储AGV方案对方直接问“你们用哪个算法和另外几种比到底好在哪里”我发现自己居然没法用一份自测数据回答这才下定决心把这事彻底补上。这篇文章就用我实际跑出来的结果说话把这四种2D激光SLAM算法的建图效果、适用边界、调参体验一次讲透。无论你是在做扫地机器人、服务机器人还是刚接触SLAM建图准备入门的开发者都能从中找到适合自己的选型思路。1. 算法选型第一步四种经典方案的核心原理与适应边界很多人一上来就问“哪个算法建图最准”这个问题本身就是外行问法。SLAM算法没有绝对好坏只有适合不适合关键看你的机器人底盘有没有里程计、现场环境有没有明显的回环、处理器算力够不够。在对比实测之前我先把四种算法的血统和脾气梳理清楚。1.1 Gmapping粒子滤波代表小场景建图的性价比之选Gmapping基于Rao-Blackwellized粒子滤波RBPF框架核心思路是用一组粒子表示机器人可能的轨迹每个粒子维护一张地图通过不断更新粒子的权重来逼近真实位姿。它的关键优势在于对激光雷达的噪声和底盘的里程计误差都有不错的容忍度——因为它把运动模型的预测和激光观测的修正结合在了一起。当年开源的时候Gmapping几乎成了ROS社区2D建图的默认选择直到今天仍然有大量老项目在跑它。但它的短板也很明显粒子数量直接决定计算量粒子太少容易丢真实轨迹粒子太多又让CPU吃不消。另外它只能维护小规模地图在几百平方米的范围内表现稳定一旦场景扩大到数千平方米或者出现长距离闭环粒子退化的问题就会让建图彻底翻车。1.2 Hector SLAM不用里程计也能出图的应急方案Hector SLAM走的是另一条路——它完全不依赖里程计只靠激光扫描和已有地图的匹配来估计位姿数学上用的是Gauss-Newton优化把当前帧激光点投影到栅格地图上通过最小化占用概率差异来求最优位姿。它的地图用两层栅格resolutor和superresolutor同时维护低分辨率层负责粗略匹配高分辨率层做精细对齐。因为没有里程计约束Hector非常依赖激光雷达自身的频率和精度更适合手持设备、无人机这类装不了高质量轮式里程计的场合。问题在于Hector没有回环检测能力。建图过程中一旦出现匹配错误错误就会一直累积下去地图后面部分会越来越歪。我见过不少新手在坑坑洼洼的地面上推着机器人跑Hector结果走廊尽头的地图直接扭成了S形就是这个原因。1.3 Karto SLAM图优化的早期布道者Karto SLAM是最早把图优化Graph Optimization思路做成开源实现的2D激光SLAM之一。它的做法是把机器人的每个位姿当作图中的节点把相邻位姿之间的相对约束当成边然后用稀疏位姿调整SBA/SPA对整张图做全局优化。相比Gmapping和HectorKarto的最大进步是引入了显式的回环检测——当机器人回到曾经到过的位置时算法能识别出这条约束把累积的漂移拉回来。所以在大场景测试中Karto的表现通常比前两者稳。但Karto的回环检测比较简单默认条件下比较容易产生误匹配在对称环境或者布满相似墙体的仓库里回环边可能给你胡乱加上反而把原本还算平整的地图拉坏。这也是后来Cartographer着重优化的点。1.4 Cartographer工业级闭环利器复杂场景的兜底选择Cartographer是Google开源的项目在工程化程度上比前三个高出一个身位。它的核心设计是局部子图submap加全局回环两层结构局部地用Ceres非线性优化来把当前激光帧匹配到最近的子图里同时维持一个全局位姿图定期做分支定界搜索来闭环。Cartographer还支持融合IMU和里程计的多传感器输入并且在架构上把局部建图和全局优化彻底分离可以异步运行。这意味着它在大面积、多回环的工业场景里建图精度和稳定性远超其他三种。代价是编译安装复杂、参数极多、占用资源相对高对刚入门的开发者并不友好。而且它内部有一些“隐含前置条件”比如纯2D激光雷达在无特征环境里也容易出现“环闭崩坏”这个后文细说。2. 同一场地、同一底盘、同一行程公平对比实验设计为了避免“田忌赛马”式的对比我把四种算法放在同一台机器人上、用同一份rosbag回放数据跑确保输入完全一致。下面说一下测试环境、数据采集和评价方式的细节。2.1 硬件平台与软件环境我用的是自研的两轮差速底盘前轮带编码器输出50Hz的里程计信息。激光雷达用了单线机械雷达10Hz扫描频率标称测距范围30米角分辨率0.18度在测试环境下实测有效测距大约20米。主控板是一块Jetson Xavier NX理论算力足够同时跑四种算法但我会单独记录每种的CPU占用率。软件环境是Ubuntu 20.04加ROS Noetic。这里给新手提个醒Gmapping、Hector、Karto在ROS1下的驱动包都相对成熟直接apt安装就行Cartographer则建议直接用官方提供的install脚本编译不要自己瞎改依赖版本否则光是ceres-solver就能折腾你半天。2.2 测试场地的三种典型场景我在同一个园区里选了三条典型路线闭合走廊场景约400米周长有转角、有玻璃幕墙、有少量行人走动。用来测试回环能力和弱纹理环境的表现。大厂房场景面积约1500平方米货架整齐排列存在大量相似纹理顶部有钢结构横梁。这是仓库AGV的典型工况。办公区混合场景有开放工位、隔断、走廊尽头死路动态人员较多用来模拟服务机器人。三条路线我都用遥控器以相近速度约0.5m/s跑完采集bag后分别喂给四个算法。这里要额外提醒rosbag回放时激光和里程计必须带时间戳同步否则不同算法对消息时序的敏感度差异会直接影响结果这种误差比算法本身的差距还大。2.3 评价指标不只看地图好不好看还看过程消耗我把评价拆成三组指标地图质量定性项墙体边缘是否平直、转角是否保持90度、重复纹理区域是否错位、闭环处是否重影。轨迹误差定量项利用建图过程中机器人经过已知坐标标记点时地图与实际位置的偏差来估算漂移量另外看闭环处的轨迹跳变值。工程成本项每种算法跑完一遍花的时间、峰值CPU占用、参数调优消耗的尝试次数。后两项在纯展示“建图效果”的视频里没人会提但在实际工程项目里这些往往是决定选型的隐形关键。3. 建图效果实测对比同样一圈跑下来地图差距肉眼可见这一章是这篇文章的核心我把三条路线里最有代表性的地图现象梳理出来。需要先说明以下结论来自我的测试条件和参数配置换一台雷达、换一种底盘绝对数值会有变化但在趋势上有参考意义。3.1 走廊闭合场景Gmapping和Hector的拐点错位Karto和Cartographer的闭环对比在这个长走廊场景里Gmapping跑出来的地图整体轮廓完整但转角处有明显的内收变形。原因是走廊环境特征单一粒子滤波在机器人转弯时容易出现“对称歧义”粒子分布一分散地图边缘就显得不那么锐利。不过它胜在稳定从头到尾没有崩坏只是不够好看。Hector的表现就差一些。因为没有里程计校正每次经过轻微颠簸的路面时匹配误差都会悄悄累积。跑到第二圈、回到起点附近时起点位置的墙体边界已经出现了约0.3~0.5米的错位整个走廊被拉长了一小截。这就是没有回环的代价。Karto在闭环处给出了不错的表现——当机器人回到起点附近时回环检测能把累计漂移拉回大部分地图起点处的重合误差大概在0.1米以内。但仔细观察会发现它把靠近玻璃幕墙的那一段墙体拉得略微倾斜因为激光在玻璃上的反射点本身就不稳定回环边把错误的观测也当作约束加进了全局优化。Cartographer是唯一在三个闭环位置都做到几乎无缝拼接的算法。它靠子图机制把错误控制在局部范围全局优化只在真正检测到可靠回环时才起作用。最终地图上墙体的厚度均匀、转角尖锐基本达到了商用交付水平。3.2 大厂房相似纹理场景误匹配率决定地图成败大厂房才是真正拉开差距的场地。这里货架排列高度相似算法很难区分“这个货架和那个货架”非常考验回环检测的鲁棒性。Gmapping在这种场景下基本上在用直觉硬撑。粒子滤波依赖概率分布相似场景多了以后粒子会分散到多个“看起来都很像”的位置地图里出现不少错位的“幽灵货架”整体完整性受影响较大。Hector在重复纹理区域几乎是无差别匹配经常跳变到对称位置然后把后续扫描全部带偏。我的测试里它只跑完了前半段后半段地图已经严重扭曲只能重新来过。Karto比前两者好很多但在某些回环时刻我还是能在rviz里看到它突然把整张图拧了一下——这是误回环导致的全局优化崩坏。后来我把回环检测的阈值调高、限制最大回环距离情况改善了一些。Cartographer依然是全场最稳的。它的分支定界搜索策略要求候选匹配达到足够高的评分才会被接受误回环比Karto少一个数量级在相似纹理的大空间里依然能保持地图整体结构正确。3.3 办公区动态场景动态障碍物过滤与地图“脏点”对比办公区测试里人走来走去是常态。建图时如果算法把所有动态点都塞进地图后续导航会产生大量误障碍物。我的观察是四种算法在默认配置下对动态障碍物的处理能力都不算好但程度有区别。Gmapping的地图里动态人物会留下淡淡的“影子”因为粒子滤波更新时对栅格占用概率的更新比较慢人走过去留下的痕迹要隔几秒才消退Hector几乎不动动态点因为缺少时间域滤波建出来的地图里全是短暂出现的“飞点”Karto的表现居中Cartographer在配合高更新频率时动态点的影响最小这是因为它的子图更新时间窗口较窄动态点在多数情况下不会固化进全局地图。需要说明的是如果要真正做动态环境建图这四种算法都需要外接动态目标过滤节点比如基于激光点云背景差分的过滤器不能指望算法自己解决。4. 按数据说话轨迹精度、资源消耗与调参难度横向打分上一章定性的地图现象最终还是要落到具体数值上。我整理了一张横向对比表数值是在前述三种测试场景下多次运行取的中位数具体数值因环境会有浮动但排序关系比较稳定。4.1 轨迹精度与地图贴合度指标GmappingHector SLAMKarto SLAMCartographer闭环处重影走廊场景/最大缝隙约0.15米不闭环约0.4米错位约0.08米约0.03米相似纹理误回环次数厂房场景不适用/无回环不适用/无回环2~3次可调整0~1次建图完成后地图整体倾斜度轻微内收中等漂移轻微倾斜基本无对里程计的依赖强无里程计不能用无中有更好弱有IMU更好从地图贴合度来说Cartographer在各场景中都排名第一尤其是带多层回环的大空间它属于“唯一能交付的”。Karto排名第二前提是你愿意花时间调回环阈值。Gmapping和Hector更适合作为快速原型阶段的工具而不是最终交付方案。4.2 CPU资源占用与建图速度算法峰值CPU占用Xavier NX 6核单场景建图耗时约10分钟bag内存占用峰值Gmapping30粒子约25%约6分钟约1.2GBHector约15%约8分钟约800MBKarto约35%约9分钟约1.5GBCartographer默认配置约70%约7分钟约2GB我这里测的是建图模式还没开实时定位模式。如果用同一套配置去跑在线SLAM并实时发布地图Cartographer的CPU占用会更高在算力有限的低成本主控上很可能让导航模块一起卡顿。这是选型时值得权衡的点——精度是用算力换来的。4.3 调参难度排名从快速上手到深度调优调参体验是新手最关心、也最容易忽略的一环。我的经验打分如下最容易上手Gmapping。核心参数就那么几个——粒子数、更新距离阈值、最大测距范围调几轮就能出图。默认参数在很多场景下就能跑通。次之Hector。需要调的主要是地图分辨率、多分辨率层数、更新频率参数数量不多但很敏感。尤其地图分辨率设太高会导致实时匹配跟不上设太低会让图糊成一片。中等Karto。需要理解回环检测、扫描匹配器、位姿图优化等概念参数分布在多个配置文件里新手容易漏调某处导致性能上不去。最难Cartographer。原生参数实现复杂光是lua配置里的参数就有数十个还涉及IMU权重、子图大小、全局搜索采样率等隐含概念。我建议新手先用官方默认配置跑通再逐项调优化目标权重。5. 冲出建图环节之后定位、导航和长期运行的隐性成本建图只是SLAM应用的第一步。地图建得好不好最终要体现在导航定位稳不稳、长期更新是否容易上。这一章聊聊我在把这些地图投入实际导航系统之后发现的坑。5.1 从“好看的图”到“能用的图”地图分辨率与代价不少人在rviz里看到一张漂亮的地图就直接说“建图成功”但放到move_base里做路径规划时才发现问题地图分辨率通常0.05米每像素如果和定位初值偏差不在一个量级AMCL重定位会频繁丢失导航时机器人会在地图边缘“抽风”。从我的测体验来看Hector建出来的地图因为存在累积漂移在后续做AMCL定位时最容易出问题哪怕局部地图再清晰全局坐标框架是歪的导航就会跟着歪。Gmapping的地图比较“稳”但边缘有噪点膨胀层半径稍微调小一点就容易让机器人贴墙太近。Karto和Cartographer建出的地图在导航阶段表现更好因为全局误差小amcl粒子不需要在很大范围内反复撒网。5.2 地图更新与闭环后的“二次破坏”我犯过一个典型错误先用Cartographer建好一张厂房地图后面因为货架调整需要局部更新地图。结果局部重新建图后整个全局地图的变形比之前更大。这是因为算法在全局优化时会重新调整所有子图的位姿局部更新会牵动全局。如果你也遇到类似问题我的建议是建图时尽量一次性把所有区域跑完不要分多次拼接迫不得已要更新时干脆清空局部区域重新建一张全图省下来的时间不如重新来一次。5.3 从2D激光SLAM走向视觉SLAM或多传感器融合我在实际项目里经常遇到客户从2D激光SLAM向更高精度定位方案升级的需求。如果你的建图环境存在大量坡道、悬空物体、透明玻璃墙2D激光雷达本身就存在物理上的局限这时候就得考虑视觉SLAM或者多线激光雷达融合IMU的方案。2D激光SLAM的四套算法其实都把“平面世界”假设发挥到了极致。一旦环境不满足这个假设比如机器人经过减速带时俯仰角变化过大Hector会瞬间丢失匹配Cartographer如果没有IMU辅助也很容易挂掉。所以做复杂地形机器人时别再纠结这四种算法谁更强直接上3D方案或视觉惯性方案更省事。6. 踩坑实录参数调试里最容易犯的几个错误最后把我这几年调试这些算法时踩过的坑集中写出来多数问题不在算法本身而是配置和操作顺序出了偏差。6.1 Gmapping粒子数调到100反而更差刚接触Gmapping时我迷信“粒子越多越精确”直接把粒子数调到100和200结果地图不但没有变得更清晰反而墙边出现了大量摩擦感很重的噪点。原因是粒子数增多后重采样过程更频繁高频噪声更容易被留在栅格概率里。后来我回到30个粒子地图反而干净了。粒子数不是精度指标它只是概率分布的表达精度超过环境复杂度需求之后只会增加噪声和计算量。6.2 Hector在高分辨率地图下的实时性陷阱做手持激光扫描时我把地图分辨率设成了0.025米觉得这样地图会细腻很多结果Hector的匹配更新率直线下降机器人稍微动快一点地图就开始撕裂。还是那句话Hector完全依赖激光帧间匹配分辨率设得太高匹配算法来不及收敛反而得不偿失。后来我保持在0.05米并在机器上加装了IMU做姿态补偿效果才稳定下来。6.3 Karto的误回环在装修现场特别明显有次客户办公室正在施工走廊里立了不少高度相似的分隔板Karto在跑到后半程时突然把所有分隔板的位置全部拉到了一起整张地图像被捏变形了。排查后发现是激光在板间空隙产生了相似的射程模式回环检测把它们当成了同一位置。我当时把回环检测的最小响应阈值提高了一截并限制了回环距离在15米内问题才缓解。如果你在现场看到Karto地图突然“拧”了一下优先怀疑回环误匹配而不是里程计漂移。6.4 Cartographer的“回环已优化”不代表地图一定正确Cartographer的回环能力强但它增加的约束如果和真实位姿不一致全局优化也会把原本正确的地图拉歪。我有一次在一条环形走廊里建图因为激光在某些区域只测到单侧墙体子图约束完全依赖里程计推算结果回环被认为“成功闭合”但走廊的半径被优化得比实际小了不少。排查方法是在生成地图后用卷尺实测几个关键点之间的距离不要只看闭环处是否对齐。7. 如果让我重新选一次按项目类型直接给结论写到这里我不再重复那些详细的对比数据直接给出实践中验证过的选型结论。这几种算法我都实际调过、翻过车、补救过下面的建议都是踩过坑之后的条件反射。如果项目是小型室内服务机器人比如餐厅送餐、酒店引导地图面积在几百平方米以内运行环境相对规则Gmapping是最高效的选择。它部署快、参数少、对底盘要求低项目周期能压得很短。你不需要为了追求地图好看多花两周去调Cartographer。如果项目是无人机或者无法安装轮式里程计的手持扫描设备Hector仍然值得考虑但前提是你愿意接受它没有回环这个硬伤并且会额外引入IMU来做姿态辅助。它的应用场景狭窄但在特定条件下确实没有替代品。如果项目是仓储AGV或工业巡检机器人地图面积动辄上千平方米还有大量相似货架Cartographer基本是当前2D激光SLAM方案里最稳妥的选择。算力不够的话Karto可以作为降级替换但要预留调回环参数的时间。需要提前考虑的是这台机器人是否最终做长期运行和定位如果是我会直接跳过Gmapping和Hector不要纠结。如果你只是自己在家里折腾一个ROS机器人、跑跑Gazebo仿真我的建议是四种算法都装起来用小场景的数据分别跑一遍亲自观察地图差异。很多SLAM概念——子图、回环、粒子退化、扫描匹配——光看理论记不住亲手跑几遍地图对比理解会深很多。建图所用的rosbag还可以反复利用这也是最快的学习路径。结尾写这篇文章前我一直觉得算法对比这类内容网上已经很充足真正跑完才意识到零散的经验和实测的结论之间隔着很多细节。不同算法对同一份数据的反应差异是真的很大参数、环境、硬件都会改变最终结果。如果你也在做SLAM建图的选型或者面试准备希望这份实测记录能帮你省掉一些我走过的弯路。后面如果有机会我再把手持建图、多传感器融合方向的实际案例整理出来继续聊。