这两年我做机器人感知评估几乎把所有叫得上名的开源SLAM都测过一遍。ORB-SLAM3、VINS-Mono、Cartographer、A-LOAM、LeGO-LOAM、LIO-SAM、FAST-LIO2……每一套都踩过坑。被同事问得最多的问题是开源SLAM方案这么多到底选哪个我的回答从来不是“某某方案最好”而是先反问三个问题你的场景长什么样、传感器怎么搭的、算力预算是多少这三个问题不回答清楚任何评估都是空中楼阁。这篇就把我这套评估流程完整摊开给正在做技术选型的机器人和AR开发者一个可以直接照做的参考。1. 评估前先回答三个问题场景、传感器、算力1.1 场景决定算法家族室内与室外完全是两回事SLAM算法没有万金油。ORB-SLAM3在纹理丰富的室内办公室表现不错但换到低纹理的仓库走廊它可能比不过一个老老实实的2D激光方案。反过来Cartographer在结构化环境里回环效果好拉到森林或半开放矿区激光退化问题就会让定位精度掉得很难看。我一般会把场景先分成几个维度来打分是否有重复纹理走廊、货架、是否有大量动态物体行人、车辆、是否有多层结构、光照是否稳定、GPS是否可用。这些维度直接决定你该看视觉SLAM、激光SLAM还是融合方案。这个步骤看起来基础但很多人跳过它直接去GitHub看Star数最后往往白忙一场。比如同样一套视觉SLAM白天在靠窗的办公楼里跑得好好的晚上换成灯光昏暗的仓库前端提不出足够特征整个定位就直接崩了。不是算法不行是场景不匹配。1.2 传感器配置决定方案上限先盘家底再选算法评估开源SLAM方案本质上是评估“传感器配置 算法”的组合。同一套算法配上不同传感器效果能差出数量级。传感器清单至少要明确几项在视觉侧是单目、双目还是RGB-D在激光侧是2D单线还是3D多线有没有IMUIMU的型号和量程有没有轮式里程计可提供。单目方案ORB-SLAM3的单目模式、VINS-Mono恢复不了真实尺度除非引入IMU或已知运动约束。双目方案精度上限更高但必须做严格的基线校准和立体匹配调参。RGB-D在室内近距效果优秀一到强光环境和空旷场景就容易被深度噪声带偏。激光方案相对稳定但3D激光的成本和功耗也要计入评估。IMU几乎已经成为现代方案的标配它能兜住快速运动、短暂遮挡和视觉退化代价是引入IMU标定、外参标定和时间同步的复杂性。我见过不止一个团队拿着一套带IMU的视觉SLAM跑数据IMU外参随便填了一个单位矩阵结果精度还不如纯视觉方案最后还反过来怪算法不好其实是传感器配置没盘清楚。1.3 算力与平台约束评估结论必须绑定硬件很多团队的评估错误出在硬件不统一。算法在台式机上跑60帧一上Jetson Orin就掉到10帧就这么点差距足以影响你对“方案可用性”的判断。所以在评估表里第一列就应该写清楚目标平台工控机、Jetson、树莓派还是手机CPU型号、内存大小、可用GPU、有没有NPU。我常用的预判方法是先看算法论文和源码里的资源消耗量级特征点法每帧要提多少特征、帧和关键帧怎么维护、后端优化频率多少、建图分辨率多少。比如ORB-SLAM3的词袋回环检测在资源受限的设备上会明显增加CPU占用而FAST-LIO2的ikd-Tree建图在高线束雷达下内存增长很快。这类问题在demo阶段就要量化否则原型转产品时会非常痛苦。下面这张表是我评估前会填写的“方案筛选卡”按照它圈定候选方案再去跑编译和数据集能省掉大量无用功维度需要填写/回答的内容对评估结果的影响运行场景室内/室外、纹理、动态、退化决定视觉还是激光传感器配置相机型号、雷达线数、IMU型号决定方案上下限标定状态内参、外参、时延是否已标定决定能否公平对比算力平台CPU、内存、GPU/NPU决定实时性结论成本约束传感器、计算单元、许可证决定是否可落地ROS版本与系统Ubuntu版本、ROS1/ROS2决定依赖是否好装这张表看起来简单但值得反复提醒的是评估阶段跑出来的分数只代表当前这一套传感器加标定加平台的分数换掉任何一项结论都可能翻盘。我在实际评估中曾经因为把雷达换了个型号Cartographer的精度结论直接从“可用”变成“不可用”原因只是新雷达的测距噪声分布不一样而默认参数完全没适配。所以拿着别人总结的“最优方案”直接套用大概率会翻车一定要自己跑一遍。2. 主流开源SLAM方案全景视觉、激光与融合2.1 视觉系主力ORB-SLAM3与VINS-Mono怎么选先聊视觉。ORB-SLAM3是目前最全面的视觉SLAM开源工程之一支持单目、双目、RGB-D还支持单目/双目与IMU紧耦合回环检测和地图复用做得很成熟。它采用ORB特征点作为前端中后端挂在g2o图优化上整个工程结构清晰。如果你要学习一个工程化的视觉SLAMORB-SLAM3几乎是必修课。它的代价也很明显为了通用性代码里集成了大量模式分支编译和依赖管理比较繁琐且特征的提取和词袋检索在低端ARM上的实时性会打折扣。VINS-Mono是港科大团队早期开源的视觉惯性里程计单目IMU紧耦合用滑动窗口和Marginalization做状态估计优点是长期在无人机和手持设备上被验证过对标定误差和快速运动的鲁棒性都不错。VINS-Fusion进一步扩展到双目和GPS融合适合做多源定位。和ORB-SLAM3相比VINS系列更偏里程计而非完整的地图系统没有全局回环维护这种“地图级”功能但胜在轻量、稳以及大量工程移植案例可以直接抄。真要在两者之间选我的经验是如果重点是建图和长时间大范围回环ORB-SLAM3更合适如果重点是轨迹稳定性和快速开发原型VINS系更好上手。2.2 激光系主力Cartographer与LOAM/LIO系各有阵地激光SLAM这边Cartographer是Google开源的2D/3D SLAM框架在室内轮式机器人上几乎是默认选项。它的核心思路是Local SLAM用子图Submap做局部匹配Global SLAM用稀疏位姿优化在后台做回环约束输出的栅格地图直接用来做路径规划。Cartographer工程成熟、ROS集成度高室内结构化环境的精度和稳定性非常能打但要跑好它别指望默认参数一梭子到底分辨率、回环频率、IMU权重都需要按场景调。LOAM系则是3D激光的代名词。A-LOAM是把LOAM用Ceres重新实现的轻量版本适合学习和快速验证LeGO-LOAM在地面分割和轻量化上做了优化适合搭载于地面机器人的单线/低线束雷达场景LIO-SAM把IMU紧耦合进来结合因子图优化定位稳定性和建图精度都比纯LOAM系前进了一大步。如果你的传感器是16线以上雷达加IMULIO-SAM基本可以成为评估基线之一。需要提醒的是激光方案在长直走廊、玻璃墙、镜面反射这类几何退化场景下同样会出问题并不是用了激光就高枕无忧。2.3 融合方案与新秀FAST-LIO2、LIO-SAM与R3LIVE等近几年激光惯性融合方案热度很高。FAST-LIO2最大的卖点是直接对原始点云进行计算配合增量式ikd-Tree管理地图省掉了传统前端特征提取环节计算效率高动态场景下表现也不错。LIO-SAM则强调因子图框架把点云匹配、IMU预积分、GPS约束统一管理代码结构清晰特别适合需要加额外约束的产品化场景。R3LIVE/R3LIVE则把视觉、激光、IMU三者融合建出来的是带颜色纹理的稠密地图AR和数字孪生项目可以重点关注。既然是评估我给一个简化版本对比表方案主要传感器输出优势明显短板上手难度ORB-SLAM3单目/双目/RGB-D/IMU稀疏点云轨迹模式全、回环成熟依赖多、嵌入式开销高中高VINS-Mono/Fusion单目/双目IMU稀疏点云轨迹轻量、无人机验证多回环/地图能力弱中Cartographer2D/3D雷达、IMU、里程计栅格/子图地图室内2D标杆室外退化场景一般中A-LOAM/LeGO-LOAM3D雷达点云地图轨迹上手快、算力友好精度依赖地表和调参低中LIO-SAM3D雷达IMU可选GPS点云地图轨迹融合稳、可扩展依赖好IMU中FAST-LIO23D雷达IMU点云地图轨迹计算快、退化鲁棒地图内存增长快中这张表是我基于常用环境、常用型号得出的经验基线不是绝对真理。同一套方案在不同硬件、不同标定质量下排名完全可能变化。所以表格的作用是帮你圈定两到三个候选而不是直接告诉你要选哪个。我自己评估时会把候选方案控制在三个以内因为每一套从编译到数据测试都挺耗时候选太多容易分散精力最后哪个都没摸透。3. 搭一套可复现的评估环境依赖、数据集与标定3.1 系统与版本选择Ubuntu 20.04 ROS Noetic仍是性价比之王评估开源SLAM方案第一个大坑是系统与ROS版本。我的习惯是主力评估机使用Ubuntu 20.04 ROS Noetic因为ORB-SLAM3、VINS-Mono、LIO-SAM这些项目的新版本和社区issue基本都是在这个组合下验证过的。Ubuntu 22.04 ROS2 Humble近年来生态也越来越好但不少老项目还没完全迁到ROS2临时编译会遇到更多第三方库问题。如果你不想污染主系统推荐用Docker。但要注意SLAM调试经常要可视化、要看ROS topic、要连传感器容器里跑GUI需要配置X11转发或虚拟显示器容器里访问USB摄像头需要映射设备节点。这些坑都会消耗时间所以我现在的做法是评估机直接装双系统跑纯数据集评估用Docker需要接真机传感器时再切换到物理环境两边并行不冲突。很多人一上来就折腾Docker里的图形界面搞到天都黑了还没跑起一个demo不如直接物理机装系统痛快。3.2 数据集准备TUM、EuRoC、KITTI怎么选评估SLAM需要统一的输入数据集就是那个“统一输入”。最常用的三套是TUM RGB-D系列室内视觉提供RGB、深度和Groundtruth轨迹适合单目/双目/RGB-D方案、EuRoC MAV无人机视觉惯性数据集IMU频率高、视觉纹理丰富适合视觉惯性方案、KITTI车载双目和激光场景是城市道路适合双目和激光方案。选数据集时我建议至少准备两个风格不一样的一个是标准室内比如TUM的fr1_desk一个是带挑战性的比如EuRoC的MH_05或者自采的低纹理走廊。原因很简单光在理想数据上跑出高精度不能证明什么SLAM方案在退化、高速、遮挡下的表现才是评估真正要考察的部分。数据集下载完先检查Groundtruth文件的格式和时间戳范围做好时间对齐准备这一步省不了。数据没对齐后面EVO算出来的误差数值就是乱弹琴。3.3 标定是评估前的硬门槛Kalibr与自采数据很多开源SLAM方案跑出来的结果差不是算法差而是传感器没标准。尤其带IMU的视觉惯性系统相机内参、相机与IMU的外参、时间偏移任何一个偏差都会让融合结果产生系统性漂移。评估前花上半天做标定比后面排查诡异错误划算得多。我见过有人用厂家出厂的内参直接跑VINS-Mono跑出来轨迹歪得离谱查了半天才发现是标定参数不准。我用的标定工具是Kalibr配合Aprilgrid棋盘格。标定流程大致是先录一段包含旋转、各方向平移的rosbag保证Aprilgrid在画面中位置和角度尽量丰富然后用kalibr_calibrate_cameras标定相机内参接着用kalibr_calibrate_imu_camera联合标定外参和时间偏移。标定结果的参数会作为SLAM算法的输入后续所有对比实验都建立在同一套标定基础上这样的评估结论才是可复现的。另外录制标定包时别贪快动作要慢而充分让IMU和视觉都能充分激励否则外参可观测性差标定结果看着收敛实际用起来还是飘。3.4 从README到Demo跑通版本锁定是复现的关键开源SLAM项目普遍存在“依赖地狱”Eigen、OpenCV、Ceres、g2o、Pangolin、DBoW2、Sophus、yaml-cpp版本稍微错位就编译失败。我发现网上搜“ubuntu20.04 orb_slam2安装配置运行”的人很多说明大家确实卡在这一步。我的经验是严格锁定三个东西系统版本、ROS发行版、第三方依赖的commit/tag。项目官方README如果写得含糊就去GitHub的issue区搜“build”关键词基本能把坑找全。比如ORB-SLAM3对OpenCV版本敏感Pangolin的版本也会影响编译。如果你只是评估功能而不改算法可以优先尝试官方提供的Docker镜像或预编译二进制但如果要修改参数、加打印、做故障注入就必须从源码编译。源码编译再痛苦也是评估工作的一部分因为产品化阶段你会遇到同样问题提前解决比上线后再解决轻松。还要记得用git submodule update --init --recursive把所有子模块拉全这条命令漏掉的概率很高漏了就会编译出各种莫名其妙缺头文件的报错。4. 用EVO量化精度ATE、RPE与轨迹对比的全流程4.1 精度指标ATE看全局RPE看局部评估SLAM定位效果业界提得最多的是两个指标绝对轨迹误差ATEAbsolute Pose Error和相对位姿误差RPERelative Pose Error。简单理解ATE是把估计轨迹和真值轨迹做刚体对齐后逐点位姿差的RMSE它衡量的是整条轨迹的全局一致性RPE则是计算每间隔一定位移或时间后两帧之间的相对位姿偏差它更侧重局部里程计的漂移速度。实际评估时两者都要看不能只看RMSE。一个方案可能ATE均值很低但某一段长廊轨迹偏差特别大也可能RPE整体平稳但累计到全局后位置偏出好几米。我通常会把EVO输出的RMSE、mean、median、max这几个统计量全部记录下来也把误差曲线保存成图方便后续做故障定位和方案横向对比。只看平均值最容易误判尤其是当一个方案在大多数时间段都很好、只在少数瞬间出现大跳变时平均值会把这些致命问题掩盖掉。4.2 EVO实操从安装到轨迹对比的完整流程很多人搜“evo slam评估工具下载”以为EVO是某个SLAM算法其实它是一个评估工具箱GitHub上的MichaelGrupp/evo专门用来比较里程计和SLAM轨迹。安装非常简单Python 3环境里执行pip install evo --upgrade --no-binary evo如果有多个Python环境或不想污染系统建议用虚拟环境。EVO支持的轨迹格式很多TUM格式每行时间戳 tx ty tz qx qy qz qw、EuRoC格式csv、KITTI格式和ROS bag。拿到SLAM输出的轨迹文件后先转成EVO能识别的格式再和Groundtruth对齐。跑APE的命令evo_ape tum groundtruth.tum estimated.tum -va-v是verbose-a表示做SE(3) Umeyama对齐。单目方案因为没有尺度要加-s做尺度对齐或者用-as同时对齐位姿和尺度。跑RPE时用evo_rpe tum groundtruth.tum estimated.tum -r trans_part --delta 1 --delta_unit m-r trans_part表示只看平移分量--delta 1 --delta_unit m表示每隔1米计算一次相对误差。最后可以用evo_traj一次性对比多条轨迹输出误差统计和误差曲线evo_traj tum estimated1.tum estimated2.tum --ref groundtruth.tum -p这条命令会把不同方案的轨迹画在同一个坐标系里一眼就能看出哪条漂移了大哪条在中段出现了回环修正。我习惯在评估报告里放三张图完整轨迹对比、ATE误差随时间的曲线、RPE误差随距离的曲线。这三张图基本能支撑90%的结论。如果你的SLAM算法输出的是ROS bag格式的里程计topicEVO也能直接读取省去手写格式转换脚本的麻烦前提是bag里的时间戳和tf树结构要完整。4.3 精度之外实时性、资源占用和稳定性测试EVO只能说“定位精度”这一个维度而评估开源SLAM方案还要测实时性、资源占用和长期稳定性。实时性用ROS提供的rostopic hz或直接记录算法输出的频率就能测CPU和内存用htop或pidstat记录一段时间内的曲线长期稳定性则要跑至少30分钟以上连续运行观察轨迹是否有发散、地图是否有内存泄漏。我踩过的一个典型坑是某个视觉SLAM在TUM数据集上测出很高精度但用真机连续运行后每帧处理时间偶尔会从20ms飙到300ms原因是一个动态物体突然出现在画面中触发了大量特征匹配和回环候选。这种偶发卡顿在EVO指标里完全看不出来但对机器人的实时控制是致命的。所以我的评估流程里加了一条“最差单帧处理时间”而不是只看平均频率这个指标能暴露很多隐藏问题。资源占用也很重要曾经有个方案精度不错但内存随运行时间线性增长跑了两个小时直接OOM这在产品上是绝对不能接受的。5. 避坑清单与真实选型建议5.1 许可证是评估的一部分不能等上线再看评估开源SLAM不能只看技术还要看法律边界。ORB-SLAM3、VINS-Mono等不少项目使用GPLv3这意味着如果你基于它做闭源商用产品代码里有GPL部分可能就必须开源或购买商业授权而Cartographer采用Apache 2.0相对友好可以更灵活地集成进闭源产品。现在国内很多团队在Gitee上托管项目选许可证时也有类似困扰到底选MIT、Apache 2.0还是GPLv3核心原则是先想清楚自己是否需要保护核心代码不被商用拿走。我的建议是评估表里专门加一列“License”连同STAR数、最后commit时间、活跃度一起记录下来。如果要做商用产品尽量选择宽松许可证方案或者确认授权路径。这条虽然不直接体现性能但能在项目后期省下巨大的法律成本。很多人做选型时根本不看LICENSE文件等项目跑通了、准备上线了才发现底层依赖用了GPL的库后面要么换方案要么走授权成本远高于一开始多做一步评估。5.2 依赖地狱与版本锁定别和第三方库斗智斗勇所有开源SLAM项目的README都写得“光鲜亮丽”真正编译起来才体会到什么叫依赖地狱。Eigen版本影响Ceres编译OpenCV版本影响特征提取和图像可视化Pangolin的API在不同版本之间兼容性很差g2o直接从fork源编译有时比系统包管理还省心。如果你用的是apt或vcpkg统一管理的版本反而容易踩“装太新”的坑。我的实操经验是每次评估一个项目先花10分钟浏览它的.gitmodules、CMakeLists.txt和thirdparty目录把这些依赖版本记录下来。再找一个已知能编译通过的issue或教程锁定这个组合。如果项目提供了Dockerfile直接基于它构建镜像最省事。不要在评估阶段试图“升级所有依赖到最新版”那只会让错误从算法层转移到编译层最后你会发现调了两天库算法一行没跑。另外依赖下载慢的话把pip和git的镜像源配好能省下大把时间这不影响评估结论。5.3 退化场景与鲁棒性测试标准数据集之外必测三件事一个有说服力的开源SLAM评估必须包含自采的退化场景测试。我的固定三件套是长直走廊测试视觉是否退化、激光是否因几何重复而匹配错乱、动态人流区域测试前端是否被干扰、后端是否因为误匹配而崩、光照突变场景测试视觉特征是否大面积丢失。这些测试序列不需要精密的Groundtruth只要人工记录大致路径和关键节点就能判断方案在真实部署时的鲁棒性。为什么一定要测退化场景因为开源SLAM论文里报的精度基本都是在“友好数据”上测出来的而产品化环境到处都是“不友好”条件。方案在退化场景下是直接报错、输出坏轨迹还是靠IMU硬撑一段后恢复这是TUM/EuRoC数据集不会告诉你的信息。我遇到过有的视觉SLAM在光照突变后花好几秒才重新收敛这期间机器人已经撞墙了。评估时不把这类场景跑一遍选型报告就是不完整的。5.4 给三类开发者的选型建议最后给一个尽量可落地的结论。如果你是学生或刚入门先不要纠结选型老老实实把《视觉SLAM十四讲》的课后实践做完再把ORB-SLAM3跑通并用EVO测一遍这套流程会帮你建立SLAM评估的基本盘。如果你在做一个室内轮式机器人原型Cartographer是最不容易翻车的高性价比起点配合2D激光、IMU和轮式里程计能把80%的调度导航任务跑得很稳。如果你做无人机、AR或者传感器本身受限的移动设备VINS-Fusion和FAST-LIO2这类轻量紧耦合方案更值得投入时间。选型不是选“最好的算法”而是选“最匹配你约束条件的算法”。把场景、传感器、算力、许可证、维护成本这五个维度想清楚你的评估表就已经赢过大半团队了。我个人现在评估一个开源SLAM方案的流程已经固定成四步列约束、跑标准数据集、量化精度和资源、做退化场景压力测试。每次换新方案都沿用这套流程效率比早期瞎跑高得多。如果你正卡在某个开源SLAM的编译或标定问题上放平心态那基本是评估之路的必修课走完这一步后面会顺很多。
 做请求级去重)
