这两年我几乎每周都会收到类似的咨询：“手头一个机器人项目，室内外都有，雷达是16线机械式，到底该上Cartographer3D还是直接上LIO-SAM？”说实话，每次看到这种问题，我都会多问一句：你先告诉我，机器人在什么环境里跑、单次工作多久、谁负责长期维护、车上还有什么传感器。因为从Cartographer3D到LIO-SAM，表面上看是两个开源方案之间的二选一，实际上是两套完全不同的建图与定位哲学之间的取舍。3D激光SLAM算法选型这件事，选错方向不是“多调几天参”能补回来的，它会直接影响项目周期、硬件成本，甚至整个机器人团队的后续技术路线。这篇文章不打算复述论文，也不做跑分测试，我就以实际落地和踩坑的视角，聊聊主流3D激光SLAM算法怎么选，尤其是Cartographer3D和LIO-SAM这两个高频选项背后的真实差异。
1. 选型之前，先把需求盘清楚
1.1 三个高频问题：精度、场景、资源
我接过的项目里，咨询者最常问的是三个问题：
- “这个算法精度能到多少厘米？”
- “室内室外都能用吗？”
- “在Jetson上能不能跑？”
这三个问题本身没问题，但孤立拿出来问，一定会得到误导性的答案。精度不是算法单方面决定的，而是传感器、场景、标定、乃至运行时长共同作用的结果。室内室外都能用不代表同一套配置能同时处理好两种环境，更不代表换一个环境后不用调参。而“能不能跑”更是要拆开看：是勉强实时，还是长期稳定运行，CPU余量还剩多少都完全不同。
我在一个园区巡检项目里最早用Cartographer3D做原型验证，3D点云建图效果确实好，闭环一拉，地图干干净净。但等真把建图节点挂到Jetson Xavier NX上，室内外切换跑了一圈，CPU峰值直接接近满载，后面再做路径规划和避障时明显感到压力。后来换LIO-SAM做定位，才把计算资源挤出来。所以第一步不是打开GitHub找算法，而是先把需求盘成一张可执行的清单。
1.2 建图、定位、重定位：你要的到底是“SLAM”的哪一部分
很多项目方嘴上说“我要SLAM”，但真正要的东西其实不一样。有的是要离线建图，把一份高质量点云地图导出来，后续定位交给别的模块；有的是要实时建图同时本体定位，边跑边建；还有的是地图已经存在，机器人只需要在既定地图里做重定位。
这三个需求对应的算法选型完全不同。Cartographer3D的强项在于离线或准实时的全局建图，激光帧与子图的匹配能力强，回环检测做得好，适合“先把地图建准”的场景。LIO-SAM更像一个完整的多传感器融合里程计系统，IMU、激光雷达、GPS因子都可以融进去，连续定位和户外长距离运行是它的主场。如果你要的是“边跑边定位边更新地图”，两者都行，但LIO-SAM在动态环境下的鲁棒性通常更好。
我记得有个客户做地下车库清扫机器人，场地是封闭的，但地形长、柱子多，车体本身还有颠簸。他们最开始想用LIO-SAM，因为“听起来新一点”，但地下车库GPS完全失效，IMU又偏消费级，长走廊里位姿会慢慢飘。后来我们切到Cartographer3D，利用墙柱结构做精确回环，地图终于是能看的状态。项目要什么，决定算法怎么选，这比谁在排行榜上靠前重要得多。
1.3 用一张需求清单把现场约束写下来
建议你在看任何算法之前，先写一份针对项目的需求清单，至少包括下面这些维度：
- 环境类型：室内结构化、室外园区、矿区、隧道、半开放仓储，还是混合环境
- 单次运行里程/时长：几百米巡逻还是几公里长距离作业
- 运动特性：底盘匀速行驶还是频繁加减速、原地旋转、上下坡
- 传感器配置：激光雷达型号、线数、扫描频率，是否带IMU，IMU级别，有没有轮式里程计或GPS/RTK
- 计算平台：工控机CPU、Jetson系列、内存，是否还要同时跑识别和规划
- 精度指标：全局一致性更重要还是局部定位精度更重要
- 回环需求：是否需要重访已走过的区域，能否接受闭环后的位姿跳变
- 团队能力：是否有能力改C++源码、做参数调优、处理驱动和标定
不要急着回答“我大概知道”，把这些逐条写下来。选型时你会发现，真正起决定作用的往往是那些一开始你没在意的小约束，比如雷达扫描频率、IMU消息频率、底盘没有轮速计、现场只有一台老旧的i5工控机。
1.4 为什么“能跑通demo”和“能稳定交付”是两件事
很多工程师对某个算法的第一印象来自GitHub上的demo视频或者自己的rosbag回放。说实话，demo环境下跑通真的不难，尤其是官方数据集，点云干净、时间戳完整、运动平缓。但交付项目时，环境不会迁就你：
- 点云会因为雷达本身的抖动出现畸变；
- IMU消息可能因为驱动配置问题少了几十个；
- 长走廊来回走一圈，回环检测没触发，轨迹就慢慢飘了；
- 动态车辆从旁边经过，点云里多出的簇直接污染特征提取。
这些才是你能不能稳定交付的分水岭。所以，这篇文章后续所有分析，都默认你是冲着“稳定落地”去的，不是冲着“把demo视频发朋友圈”去的。带着这个前提，我们再看主流算法的血缘和差异。
2. 主流3D激光SLAM算法全景：系别、血缘与技术差异
2.1 LOAM家族的家谱：LOAM → A-LOAM → LEGO-LOAM → LIO-SAM
如果你刚接触3D激光SLAM，第一件事是理清LOAM家族的传承关系。LOAM是2014年Ji Zhang等人提出的经典方案，核心思路是把激光里程计拆成两个模块：一个用scan-to-scan做高频低精度的位姿估计，另一个用scan-to-map做低频高精度的匹配校正。算法提取两类特征：边缘点和平面点，再通过点到直线、点到平面的距离构建残差。LOAM没有回环检测，长时间运行会累积漂移。
A-LOAM是港科大对LOAM的简化重写，代码更干净，是很多工程师入门LOAM系的首选，但它依然没有回环。LEGO-LOAM是Tixiao Shan的改进版，亮点是地面分割和轻量化，适合地面机器人，运行效率高。LIO-SAM是同一作者后来的工作，把IMU预积分直接融入因子图，和激光雷达做紧耦合，同时把回环检测、GPS因子都收进同一个优化框架里，可以理解为LOAM系在工程易用性和传感器融合能力上的集大成者。
这里要提醒一句：不要以为LIO-SAM只是LEGO-LOAM加了IMU。它把IMU预积分因子放进了因子图，雷达特征又可以反过来修正IMU零偏，形成一个双向约束。这个设计让它在快速旋转、剧烈颠簸时依然能维持一个相对稳定的姿态估计，这也是LIO-SAM在很多户外场景比纯激光算法更抗造的根本原因。
2.2 Cartographer3D：谷歌系子图优化的“重炮”
Cartographer是Google开源的一套2D/3D SLAM框架，2D部分在扫地机器人领域已经很成熟，3D部分则常被低估。它的核心思想是子图（submap）加全局优化：雷达帧先和当前局部子图做匹配形成位姿约束，随着子图越来越多，后端用Ceres求解器做全局图优化，把所有子图之间的误差摊平，同时配合回环检测修正累积漂移。
Cartographer3D对点云数据的处理方式决定了它的性能特点。3D点云数据量远大于2D，Cartographer内部会做自适应体素滤波，把点云分辨率降下来再匹配。如果你们用的雷达是32线或64线，且扫描频率很高，Cartographer3D的计算压力会非常大。我在室内仓库测试过，把参数调低到拥抱实时性的水平后，建图细节又会明显变差。这是一个很现实的取舍。
但Cartographer3D的优势也很突出：它对环境中的几何特征利用得很充分，在室内有墙有柱、有稳定结构的场景里，回环一旦建立，全局一致性非常漂亮。而且它在2D和3D之间共用一套代码框架，团队如果后面还要做2D机器人，学习成本可以摊薄。
2.3 FAST-LIO/FAST-LIO2：滤波系的后起之秀
只看LIO-SAM和Cartographer还不够，现在很多项目里FAST-LIO系列也很常见，尤其是港大开源的FAST-LIO2。它和LIO-SAM的路线不同：LIO-SAM走的是因子图优化，FAST-LIO2走的是迭代误差状态卡尔曼滤波。FAST-LIO2还用了ikd-Tree数据结构直接配准原始点云，不需要额外提取角点平面点，代码更简洁，在CPU资源受限的平台上表现更友好。
对工程师来说，FAST-LIO2是LIO-SAM之外的另一个实用备选。如果你的场景不需要那么多GPS因子，希望代码尽量精简、实时性高，FAST-LIO2值得作为第二候选来测试。很多团队在Livox固态雷达上会优先考虑FAST-LIO或LIO-Livox，因为LOAM系的特征提取逻辑和Livox的非重复扫描特性并不完全适配。
2.4 其它绕不开的名字：HDL、BLAM、livox系
除了这几个主流选项，业内还活跃着一些各有侧重但不可忽视的方案：
- HDL_graph_slam：基于NDT配准和图优化，代码结构清晰，对地面机器人比较友好，在室内外小规模场景都有应用。
- BLAM：Berkeley出品，用ICP做前端匹配，GTSAM做后端优化，结构简单，适合学习和快速原型，但工程化程度偏低。
- LOAM-Livox / LIO-Livox：专门针对Livox固态雷达优化的方案，如果你项目里的雷达是Livox系列的，直接在通用LIO-SAM上硬跑可能会遇到点云畸变和视角受限的坑。
- Point-LIO：港大后来提出的方案，能处理剧烈运动和极端抖动，但工程成熟度不如FAST-LIO2。
这些算法不是不优秀，而是各有明确的适用边界。选型时不要迷信某一家，建议先把候选方案限制在两到三个，否则测试成本会失控。
2.5 这些算法表面在用不同“匹配”，本质差异在哪
我把主流算法放在一起看，真正决定选型的其实是这么几个维度：
| 算法 | 前端匹配 | 状态估计 | IMU融合 | 回环检测 | 典型适用 |
|---|---|---|---|---|---|
| LOAM/A-LOAM | 特征边面点 | 位姿优化 | 无 | 无 | 入门学习、早期原型 |
| LEGO-LOAM | 特征+地面分割 | 图优化 | 松耦合 | 有 | 地面机器人轻量建图 |
| LIO-SAM | 特征边面点 | 因子图 | 紧耦合IMU预积分 | ICP回环 | 户外长距离、多传感器融合 |
| Cartographer3D | 子图匹配 | 全局图优化Ceres | 可选 | 分支定界/实时回环 | 室内结构化建图、全局一致 |
| FAST-LIO2 | ikd-Tree直接配准 | 迭代误差状态卡尔曼滤波 | 紧耦合 | 无默认回环 | 嵌入式平台、动态运动 |
从表里能看出，LIO-SAM和Cartographer3D其实是两条技术路线的代表：一个有IMU和GPS的强融合能力，适合连续定位和户外长距离；一个靠子图和全局优化能力，适合把一张大图建准。这个差异会在具体场景里被无限放大。
3. 核心场景实测：Cartographer3D与LIO-SAM的正面PK
3.1 室内仓储与地下车库：Cartographer3D更稳
我拿一个实际测试项目说。场地是两层地下车库，总面积约一万平方米，有立柱、墙面、坡道，灯光正常，地面平坦。传感器是一个16线机械式激光雷达，加一个消费级9轴IMU。我们用同一份rosbag分别跑Cartographer3D和LIO-SAM。
Cartographer3D建出来的图，柱子和墙面轮廓清晰，绕场一圈回到起点后，全局一致性良好，重合误差肉眼几乎看不出，回环检测在库内多次触发。LIO-SAM的结果则依赖IMU状态，在空旷停车区域和长直坡道附近出现了缓慢漂移，回到起点时轨迹和地图存在轻微错位，需要重新触发回环才能拉回来。但Cartographer3D的代价是CPU占用明显更高，点云处理频率也被拉低了一截。
这个结果不是偶然。室内结构化环境对Cartographer来说是最舒服的主场，墙、柱、墙角这些几何特征给了局部子图和全局优化足够多约束。而LIO-SAM过度依赖连续的激光约束和IMU预测，在空旷区域一旦特征退化，IMU零偏又不够准，误差就会悄悄累积。
3.2 户外园区与矿区：LIO-SAM更抗造
换一个户外园区场景，情况立刻反转。场地有起伏坡道、大片空地、绿化植被，还有零星建筑，长度接近两公里。同样的16线雷达和IMU配置，LIO-SAM凭借IMU预积分和GPS因子，在长距离连续运动时保持了明显更好的姿态稳定性，轨迹漂移控制在可接受范围内。Cartographer3D在这种场景下，由于全局图优化依赖闭环来消除累积误差，而园区路径长、回环触发次数少，地图容易出现“整体漂移积累”，再想靠回环修正已经晚了。
这不是说LIO-SAM永远赢，而是在“没有密集几何结构提供闭环”的户外场景里，LIO-SAM的IMU-GPS融合补偿了激光退化。矿区那种地形起伏大、路面颠簸的环境同样如此。只要IMU标定靠谱、GPS信号不是完全丢失，LIO-SAM比纯激光子图方案稳得多。
3.3 长走廊与隧道：两种算法都会遇到的问题
这两种算法在长走廊和隧道里的表现非常有趣：它们都会漂，但漂的方式不同。
Cartographer3D在长走廊里，如果前后没有可回访的位置变化，局部子图匹配会沿着走廊方向慢慢累积误差，后端图优化因为没有闭环，也没法消除。LIO-SAM相对好一些，因为IMU预积分给位姿提供了一个短期预测基准，在没有激光约束的方向上不至于立刻发散。但如果走廊长度超过几百米且没有任何测距特征，IMU零偏误差也会逐渐把姿态带偏，只是“晚飘一会儿”。
我的实操经验是：遇到长走廊，只靠算法本身是不够的。正攻法是加入轮式里程计因子、或者在地面布置反光标识，再不行就控制机器人速度，减少快速转向。你们在测试时最好专门录一段长走廊bag，因为这是最容易暴露算法软肋的场景。
3.4 计算资源与实时性：一张压力测试表
不同平台的资源差异会直接影响算法可用性。我用同一份16线机械式雷达的bag，在同样的工控机（酷睿i7-9700）上分别跑三个方案，简单记录CPU占用和帧处理表现：
| 算法 | 平均CPU占用 | 内存占用 | 能否实时处理16线10Hz点云 | 表现备注 |
|---|---|---|---|---|
| Cartographer3D | 约3.5核满载 | 高 | 勉强可以 | 地图质量好，但点云滤波参数需要收紧 |
| LIO-SAM | 约1.5核 | 中 | 轻松 | 实时性充裕，有调参空间 |
| FAST-LIO2 | 约1核 | 中 | 轻松 | 实时性最好，无回环 |
在Jetson Xavier NX这类嵌入式平台上，差异会更明显。Cartographer3D跑16线点云时，CPU很容易逼近极限，此时如果你还需要同一个设备跑YOLO做识别，直接卡死。很多项目最终放弃Cartographer3D并不是因为它建图不够好，而是因为它运行时吞掉的资源太多，挤占了其他模块。
3.5 建图质量的评价方法：别用“肉眼看着行”来下结论
做对比测试时，不要只截两张图说“看起来A比B好”。工程交付需要可复现的量化指标。推荐用evo工具评估轨迹误差：把你记录的ground truth轨迹和算法估计轨迹对齐后，计算ATE（绝对轨迹误差）和RPE（相对位姿误差）。在室内可以用全站仪或高精度动作捕捉系统打点，在室外可以用RTK轨迹做参考。
即便没有高精度真值，你也可以用一个笨办法估算全局一致性：在起点附近设置一个明显标记物，机器人建图跑完一圈回来后，把建图结果里的标记物位置与实际位置做差，误差能控制在10厘米以内就算优秀。这个方法简单，但在项目验收时非常有用。
4. 工程落地避坑地图：这八类坑我几乎每次都见到
4.1 时间同步：雷达、IMU、主机时钟的“毫秒级战争”
这是所有激光SLAM项目里最隐蔽、最毁心态的坑。LIO-SAM这类紧耦合算法对IMU和雷达的时间戳一致性要求很高，如果IMU时间戳和激光点云时间戳不在一个时钟域，预积分结果和点云畸变校正都是错的，典型表现是机器人静止时地图正常，一跑起来轨迹就开始上下抖。
机械式激光雷达本身每个点都有精确的时间偏移，驱动会把点的时间戳标到主机时间上。IMU消息也同理。如果主机没有配置PTP或NTP同步，雷达和IMU各自用的时钟源不一致，那你后续所有标定都白费。建议在录制bag之前先做一件事：把机器人放到静止状态，录制一段时间的数据，回放时看rviz里的IMU姿态和点云是否稳定重合。如果静止状态下IMU和点云都对不上，先别急着调算法，去查驱动参数和时钟同步。
4.2 运动畸变：底盘一快就露馅
很多人第一次碰到运动畸变是在底盘高速原地旋转的时候。机械式雷达的一帧扫描是分时扫描的，点云内部的点并不属于同一时刻的机器人位姿，如果底盘在快速旋转，一帧点云会被拉成螺旋状，直接破坏帧间匹配。轮式AGV速度慢感知不到这个问题，但换成巡检机器人或者无人车，这个坑就非常明显。
LIO-SAM会在IMU预积分的基础上做运动补偿，把一帧扫描内的点都投影到统一的坐标系下，所以对运动畸变有天然抵抗力。Cartographer3D虽然也内置了一定的运动补偿机制，但在快速旋转时，如果点云分辨率高、滤波又不够，畸变依然会体现到子图匹配残差里。选型时一定要问一句：“我的机器人会不会快速转向？旋转角速度能达到多少度每秒？”如果会，必须优先考虑有IMU紧耦合和去畸变的方案。
4.3 退化场景：几何特征消失时，优化器开始“自由飞翔”
退化场景是激光SLAM的公共死穴。所谓退化，就是环境中的几何特征在某一个方向上缺失，导致位姿在该方向上不可观测。常见退化场景有：长走廊（沿走廊方向无约束）、大面积开放广场（垂直方向和平移方向约束弱）、隧道（纵向约束弱且点云特征单一）。
我见过最离谱的一次是在一条长走廊里，Cartographer3D的轨迹沿着走廊方向越拉越长，地图末端直接偏移了将近一米。LIO-SAM虽然没有立刻发散，但因为消费级IMU的零偏估计不准确，也慢慢走出了一条“弧线”。
正攻法有几个方向：一是加传感器因子，比如轮式里程计、GPS、甚至激光测距仪；二是做退化检测，检测到特征退化就降低机器人速度或切换定位模式；三是利用已知地图做重定位约束。算法层面没有银弹，工程层面才是解决退化问题的关键。
4.4 回环检测：“开了回环”不等于“有回环”
很多工程师以为在配置里把回环检测开关打开，项目就自动具备回环能力了。实际完全不是这样。Cartographer3D的回环检测依赖子图之间的匹配，大场景下的回环搜索本身有计算压力。LIO-SAM的回环检测用的是雷达帧到历史关键帧的ICP匹配，对初始位姿和匹配阈值都很敏感。
更麻烦的是，即使在相似几何结构较多的环境里，回环匹配也容易误检。地下停车场一圈柱子长得一模一样，LIO-SAM有可能把这段走廊误认为那一段，产生错误的回环约束，反而把原本不漂的轨迹拉歪。遇到这种情况，我一般会把回环搜索半径调小，或者增大关键帧之间的时间间隔，避免把太近的帧误判成回环。
还有一个容易被忽略的点：很多算法回环优化后的位姿是给建图全局优化用的，不一定实时反馈到当前定位结果里。如果你的应用是实时定位，一定要确认当前使用的算法是否会把闭环修正同步到当前位姿，否则会出现“地图突然跳一下，但车的位置显示不变”的诡异现象。
4.5 IMU选型与外参标定：好算法也救不了烂参数
LIO-SAM这类紧耦合算法的性能上限，很大程度取决于IMU质量和外参标定精度。消费级IMU零偏不稳定、随机游走严重，训练出来的预积分结果就是带噪声的，雷达就算再准，融合进来也会被带偏。我踩过的坑是，把IMU和激光雷达的外参随手写了一个大概值，机器人在平地没问题，一到坡道位姿直接失稳，查了半天才发现是外参的旋转分量写反了。
给你的建议：能用工业级IMU就尽量用工业级IMU，至少在样机阶段准备一块性能达标的IMU，不然你会把算法问题和传感器问题混在一起，排查成本极高。外参标定尽量用工具离线做，比如kalibr或li_calib，不要把外参当成一个随便填的随机数。
4.6 坐标系与TF：一个Z轴方向写反，整张地图直接歪掉
Cartographer3D和LIO-SAM都依赖正确的TF树。常见的树形结构是map -> odom -> base_link -> laser，IMU和雷达相对base_link的外参一定要严格对应。我见过太多人把laser的Z轴朝上写成了Z轴朝下，或者把IMU和base_link之间的平移忘掉，结果建出来的地图整体倾斜。
排查这类问题有一个小技巧：在rviz里把点云、IMU姿态、TF坐标系一起显示出来，让机器人原地转动，观察点云和坐标轴是否贴合。如果点云绕着一个错误的旋转中心转，外参一定有问题。坐标系问题一定要在调参之前解决，否则你后面调的所有参数都会被坐标系错误带偏。
4.7 雷达硬件的适配差异：机械式、固态、Livox的“性格”完全不同
不是所有激光雷达对算法都一视同仁。Velodyne、Ouster这类机械式雷达扫描线均匀、视场覆盖广，LIO-SAM和Cartographer3D都能适配。Livox的固态雷达采用非重复扫描模式，点云分布和扫描模式与机械式差异巨大，直接套用LOAM系特征提取往往效果很差，一般需要在特征提取环节单独适配，或者直接用LIO-Livox、FAST-LIO这类针对Livox开发的方案。
另外，现在很多项目喜欢在车体周围加补盲固态雷达来弥补盲区。多雷达融合会引入新的时间同步和坐标变换问题，且回环检测时还需要考虑不同雷达视场不一致带来的匹配困难。如果你是多雷达配置，选型前最好先确认算法是否支持多雷达输入，还是需要自己改前端匹配代码。
4.8 参数调优：从默认跑到落地，差距都藏在配置里
每个开源算法都会给一套默认参数，但默认参数几乎等于“在作者的数据集上能用”。Cartographer3D的lua配置项很多，比如体素滤波尺寸、子图大小、匹配线程数、回环搜索参数，任何一个不合适都可能造成地图糊掉或CPU爆炸。LIO-SAM的yaml配置涉及IMU频率、雷达频率、扫描周期、关键帧距离阈值、回环搜索半径等，同样需要针对你的雷达和运动特性重调。
调参时我有一个铁律：一次只改一个参数，改完跑同一份bag，记录前后差异。如果一次改五个参数，出了问题你根本不知道是哪个改错了。最好把每次验证使用的bag、参数、输出地图路径、评测评分都记录下来，形成一份自己的调参日志。
5. 我的选型决策方法：从需求到方案的一套动作
5.1 用一张评分矩阵代替直觉
我不建议凭“名气”选算法。比较靠谱的方法是先用一张评分矩阵给候选方案打分。比如你的项目更看重全局建图精度和稳定性，那你可以把精度权重调高；如果项目更依赖长距离导航和实时性，则工程成熟度和资源占用更重要。
下面是一个简化版评分示例（满分5分），你们可以按自己项目的权重改：
| 维度 | 权重 | Cartographer3D得分 | LIO-SAM得分 |
|---|---|---|---|
| 建图全局一致性 | 0.25 | 5 | 3 |
| 户外长距离鲁棒性 | 0.20 | 2 | 5 |
| 计算资源占用 | 0.15 | 2 | 4 |
| 实时定位稳定性 | 0.20 | 3 | 4 |
| 工程成熟度与社区 | 0.20 | 4 | 4 |
| 加权总分 | 1 | 3.35 | 4.00 |
这不是说LIO-SAM一定比Cartographer3D好。如果你的项目权重换成“室内结构化 + 全局精度优先”，分数会立刻反转。重点是把选型从情绪判断变成可比较的量化过程。
5.2 先录真实bag，再在办公室反复回放
无论你心里倾向哪个算法，我都建议先到现场录一段包。环境越接近最终作业场景越好，路径要覆盖长走廊、转弯、坡道、空旷区域，时长最好超过三十分钟，中途不要人为干预。然后把这包数据拿来反复跑候选算法，比较轨迹误差、地图质量、CPU占用和回环触发情况。
rosbag的价值在于可复现。一次现场测试只能代表一次试跑的结果，但同一包数据你可以在不同配置上跑无数遍。我见过很多团队拿着现场有限试跑的数据下结论，结果最后发现是那次试跑IMU时间戳没同步好，算法白背了锅。数据在手，排错才有的放矢。
5.3 三个“必须验证”的场景
拿到候选算法后，不管它评分多高，都必须在下面三个场景里做验证：
- 退化场景：长走廊、空旷广场、隧道，至少各录一段，观察算法的漂移速度和发散方式。
- 长时间运行：连续跑一个小时以上或连续走几次同一路线，检查地图是否有重叠误差及回环触发情况。
- 动态环境：有叉车、人员、车辆经过的场地，观察动态物体是否导致地图糊点或位姿跳变。
这三个场景过不了，说明算法和当前传感器配置不匹配，选型基本可以否掉，不用等到最终交付再去返工。
5.4 双方案并行的现实策略
在项目早期，我不建议只押一个算法。更现实的做法是并行维护两套候选方案，比如Cartographer3D和LIO-SAM各跑一路，在关键场景做交叉验证。等现场测试数据足够多了，再砍掉表现差的那一套，收敛到唯一方案。双方案并行会增加一些开发和维护成本，但相比选错方向后的返工，这点成本完全值得。
我见过一些团队前期为了省事，直接锁死一个算法，后来发现算法和场景不匹配，整个感知模块都要推倒重来。并行方案虽然“看起来慢”，实际上是最快见到确定性的方式。
6. 写在最后：算法选型没有银弹，但有清晰的取舍
6.1 我个人的痛苦与收获
早几年我做项目时，也有过“某算法一出，立刻全面切换”的冲动。后来被现场数据教育了几次，才彻底明白：算法选型的本质是传感器、场景、计算资源和团队能力的匹配，而不是找一个“最好的框架”。Cartographer3D和LIO-SAM之间的选择，说到底是在问你的机器人“更像室内结构化建图器，还是更像户外多传感器融合定位平台”。我能给你的建议只有一个：先盘需求，再录数据，最后跑分，用真实数据替你做决定。
6.2 一个值得长期投入的小技巧
最后分享一个我坚持了很久的小习惯：把调参记录、rosbag数据集、评估脚本固化成一个“选型测试平台”。每次接手新项目，先把这份平台拿出来，用同一套数据做算法对比，让结果说话。这套平台救过我太多次了，也让团队在项目交付时拿得出数据来向客户解释为什么选这个算法、为什么这个精度已经达标。项目可以不完美，但选型的过程必须可追溯、可复盘。这比记住某篇论文的公式有用得多。
