年底把测试平台上的激光雷达换成 Livox Avia 之后我原本在机械式雷达上调得顺手的 LIO-SAM 第一次跑走廊建图就翻车了地图末端比实际位置歪了半米多那个错位瞪了好久才确认不是标定问题。换成 FAST_LIO 之后同一份 rosbag 跑出来的轨迹几乎贴着参考线走。这一下子激起了我的好奇干脆把两种算法放在同一套硬件、同样的标定参数、同一个评估流程下用 7 组 Livox Avia 采集的真实数据完整比了一轮。这篇文章就是这轮实测的记录重点不是想分个你死我活而是想把两个算法的优势边界挖清楚什么场景下 FAST_LIO 更稳什么时候 LIO-SAM 能靠回环反超以及部署时那些文档里不会写的坑到底都在哪。先给结论7 组数据里FAST_LIO 在 6 组上的绝对轨迹误差都小于 LIO-SAM尤其在长走廊、拐角、坡道这类退化场景中优势明显唯一一组 LIO-SAM 反超的是带清晰闭环的大环线园区数据。这个结果对正在纠结选型的朋友应该有点参考价值。1. 这轮对比是怎么做的硬件平台、七组数据与统计口径1.1 底盘、传感器与标定状态对比测试首先要保证“同一个基准”否则算法之间的差异会被硬件差异淹没。这次用的测试平台是一台轮式底盘计算核心是 Intel NUC i7-10750H / 16GB 内存激光雷达是 Livox Avia输出频率 10HzIMU 用的是外置的 Xsens MTi-680G频率 200Hz。这里的 IMU 选择我需要多说一句Livox Avia 本身的接口很干净但并没有把 IMU 集成进雷达内部所以外部 IMU 的安装刚性一定要保证我用的是铝制转接件把两者锁死在同一个支架上避免跑动时相对抖动。时间同步方面我通过主板 PTP 给 IMU 和雷达统一授时rosbag 里直接录带硬件时间戳的话题。实际操作中如果省掉这一步只靠 CPU 时间戳对齐在高速转向时会让 LIO-SAM 的 IMU 预积分出现明显偏差这个后面具体讲。外参标定我用的是开源标定工具标完保留了一组残差比较小的结果imu_to_lidar: translation: x: 0.041 y: 0.013 z: 0.112 rotation: w: 0.99991 x: -0.0011 y: -0.0046 z: 0.0120这组外参在两种算法里保持一致避免因为外参不准确单方面拉低某一方的表现。标定完之后把 7 组数据重跑过一遍确认平移残差都收敛到了厘米级才开始正式采集。1.2 七组数据集的场景与挑战数据采集不是随便找个地方绕一圈就完事我刻意把最常见的退化场景都覆盖进去。7 组数据集分别是办公室、长走廊、室外园区、地下车库、货架仓库、楼间巷道、大环线园区具体参数如下数据集场景轨迹长度采集时长主要挑战D01办公室单层80m65s隔间、玻璃墙、直角转弯多D02连续长廊150m110s长直墙面、特征稀疏、末端转弯D03室外园区220m150s树木、路灯、行人、草地D04地下车库180m95s坡道、密集立柱、反光地面D05集中式货架仓库200m135s货架高、通道窄、重复结构D06楼间巷道130m100s两侧平面重复、角落多D07大环线园区420m240s大闭环内部支路、长距离累积这七组的轨迹长度加起来超过 1.3km基本覆盖了室内外、平地坡道、宽场景和窄通道的组合。每组数据都从同一起点出发最后尽量回到起点附近这样即使没有外部真值也能先通过首尾偏差做一个粗判断。1.3 评估方法真值怎么来、指标怎么选SLAM 对比最容易被质疑的就是真值来源。这次评估我采用组合方案室外区域用 RTK-GNSS 走一遍参考轨迹室内区域用全站仪布了控制点再把控制点匹配进点云地图反推位姿最终得到一条厘米级精度的位姿真值序列。D04 地下车库这类纯室内环境里因为无法依赖 GNSS我就靠全站仪控制点和人工闭合测量约束来做后处理。轨迹误差计算统一用 EVO 工具命令大致如下# 绝对轨迹误差先做 SE3 对齐再求 RMSE evo_ape tum gt_path.tum fastlio_path.tum -va -a --plot --plot_mode xy # 相对位姿误差按 1 米位移间隔统计 evo_rpe tum gt_path.tum liosam_path.tum -va --delta 1 --delta_unit m --plot这里有个细节容易忽略地面机器人评估时应该用 SE3 对齐而不是 Sim3Sim3 会引入尺度缩放一旦允许缩放实际上就把 z 向偏差给偷偷抹掉了一部分结果会虚好看。所以我在所有组别的 ATE 统计里都固定使用-a的 SE3 Umeyama 对齐。除了 ATE、RPE 这类轨迹指标我还把建图点云与全站仪参考扫描做了 cloud-to-cloud 距离统计用来反映地图本身的几何一致性和厚度问题。2. 为什么在同一批数据上两者会拉开差距LIO-SAM 与 FAST_LIO 的关键差异2.1 FAST_LIO用滤波把“紧耦合”做到极致的方案FAST_LIO 的核心是迭代误差状态卡尔曼滤波器IESKF激光雷达点云会直接参与滤波更新不需要先抽成特征。它对每一帧点云里的原始点做点-地图配准配准时用的又是增量式维护的 ikd-Tree 局部地图所以无论 Livox 的点云怎么非均匀分布只要点落到地图附近就能形成约束。整段扫描过程中雷达是边转边采集的车辆本身也在动所以一帧里的每个点其实对应不同的位姿。FAST_LIO 的处理方式是靠滤波器预测的状态先给出一个大致位姿然后在 IESKF 的迭代过程中根据点的时间戳和对应位姿逐个把点补偿到一致坐标系下。这个机制天然适配 Livox 的非重复扫描因为它不需要点云有固定的线号或规整的行列结构点的到达时间就是唯一需要的信息。另外值得提到的是FAST_LIO 对噪声点和动态物体会在迭代更新里自动降权本质上相当于一个鲁棒核。这在有行人、有树木晃动的户外环境里非常有用。简单说它不挑数据只要局部地图存在就能把原始点“喂”进去。2.2 LIO-SAM因子图优化主导的全局方案LIO-SAM 的设计思路不同。它把系统拆成前端和后端前端先做 IMU 预积分再通过 scan-to-map 匹配算激光里程计后端用因子图维护关键帧位姿把 IMU 预积分因子、激光里程计因子、回环因子都塞进 GTSAM 里做全局优化。所以 LIO-SAM 的空间复杂度会随时间增长但它有一个 FAST_LIO 没有的能力——当检测到回环时可以把历史上所有累积的漂移一次性拉回来。不过这个前端与后端的架构也对 Livox 有一个隐蔽要求。LIO-SAM 的特征提取沿用了 LOAM 那一套把点云按线号投影成二维图像计算局部曲率挑出角点和平面点。机械式雷达有固定线数和 ring 字段投影之后邻域关系很清晰Livox Avia 是非重复扫描没有线号点云在空间里的分布也不均匀。跑在 Avia 上LIO-SAM 必须先做格式转换和特征提取改造否则根本转不起来。2.3 非重复扫描把问题更明显地暴露出来Livox Avia 的视场角大约 70.4°×77.2°点频 24 万点/秒但它的扫描路径是李萨如曲线点云密度不仅不均相邻帧之间的重叠率也比机械雷达低。机械雷达哪怕转一圈线和线之间还是有稳定结构Avia 则要花更长时间才能“扫满”一个区域。这意味着从一帧 Livox 点云里提取角点、平面点时局部邻域的点数会忽多忽少曲率估计抖动很厉害。LIO-SAM 的 LOAM 特征提取在这种输入下容易产生两类问题一是本该连续提取的墙体平面点断断续续二是把植被、树叶、窗户反光等误判成角点。特征一旦不稳定scan-to-map 匹配的约束质量就下降后端的因子图优化也只能在错误约束上做文章。FAST_LIO 则没有这个负担。它直接用原始点云体素地图也是按空间位置动态维护的点密不均只是让某些区域约束密一点、某些区域稀疏一点不会因为“特征丢了”而彻底失效。非重复扫描反而让它有更多时间观察同一个空间区域对 FAST_LIO 来说反而是有利的。两类算法的主要差别我整理成了下表对比项FAST_LIOLIO-SAM点云预处理不提取特征直接用原始点提取角点/平面点Livox 原生支持官方原生支持 Avia需自行改造默认没有 ring 字段扫描畸变补偿滤波迭代中隐式补偿依赖 IMU 预积分和预处理去畸变后端形式迭代误差状态卡尔曼滤波因子图滑窗优化全局回环检测无支持可全局优化回环位姿3. 七组数据集的实测拆解从办公室到环形园区3.1 D01 和 D05办公室与货架仓库——特征丰富但处处重复D01 办公室是一条包含隔间、通道、玻璃墙的路线中间有 6 次快速直角转弯。这种场景看起来特征很多但玻璃墙和白板会产生镜面反射和空点且快速转弯会让扫描图案和地图匹配的初始偏差变大。实测结果里FAST_LIO 的 ATE RMSE 是 0.028m最大误差 0.11mLIO-SAM 的 ATE RMSE 是 0.035m最大误差 0.13m。差距不算夸张但 LIO-SAM 在直角转弯处会出现一个比较明显的“甩尾”动作轨迹在地图上画出一个向外凸起的小弧线。这大概率是因为快速旋转时 Livox 的扫描覆盖幅度大角点特征提取数量不足scan-to-map 匹配落在了局部极小值上。D05 货架仓库是另一个极端通道宽度只有 2.5m两侧全是 6m 高的货架结构高度重复。FAST_LIO 的 ATE RMSE 为 0.035m最大误差 0.16mLIO-SAM 为 0.048m最大误差 0.29m。这里 LIO-SAM 的最大误差主要出现在通道中段一次急停急转之后重复的货架立柱让它在多个相似几何之间产生了错误关联。FAST_LIO 虽然也会被重复结构干扰但它的体素地图是按空间位置实时更新的局部性更强不太容易被远距离的相似结构带偏。3.2 D02 和 D03长走廊和园区——退化方向上的漂移D02 长走廊是这次对比里最典型的一个退化场景。走廊宽度 12m墙面粉白、几乎没有复杂纹理只有天花板下方的消防管和地面踢脚线能提供弱特征。整段直线长度 150m对任何激光 SLAM 来说都是个考验沿走廊方向缺乏强特征约束位姿估计会沿着运动方向慢慢漂移。FAST_LIO 在这个场景的 ATE RMSE 为 0.052m最大误差 0.31mLIO-SAM 则明显恶化ATE RMSE 涨到 0.088m最大误差 0.57m。从轨迹上看LIO-SAM 在走廊末段出现了一个向一侧弯曲的弧回到走廊起点闭合时偏差已经很明显。而 FAST_LIO 因为有 IMU 紧耦合还能靠加速度计和陀螺仪的约束把横向漂移压住纵向的残余漂移也小得多。D03 室外园区的难点来自植被和动态物体。这条路线上有行道树、低矮灌木还遇到了三次行人经过。FAST_LIO 的 ATE RMSE 为 0.043m最大误差 0.22mLIO-SAM 为 0.067m最大误差 0.34m。FAST_LIO 对树冠这类噪点容忍度更高的原因并不神秘它的迭代更新里对离群点会自动降权树枝树叶虽然产生很多“看似能对上”的激光点但并不会变成强势约束。LIO-SAM 则会把树冠边缘点提成角点等于主动把噪声当成了地标。3.3 D04 和 D06车库坡道和楼间巷道——高程方向的考验D04 地下车库最大的变量是坡道。坡道本身约 8° 的坡度激光雷达在坡面上能扫到的点不少但真正能约束高度方向的几何特征非常有限这时候 IMU 的重力约束就成了稳定 z 轴的关键。FAST_LIO 把重力矢量作为滤波状态的一部分俯仰、横滚的估计比较稳最后 ATE RMSE 为 0.061m最大误差 0.24m。LIO-SAM 的 IMU 预积分在长时间坡道爬升时会累积偏差最后 ATE RMSE 为 0.075m最大误差 0.35m。D06 楼间巷道是另一种退化左右两面墙非常平整排水管和窗框提供了少量角点但整体几何高度对称。FAST_LIO 的 ATE RMSE 为 0.048m最大误差 0.19mLIO-SAM 为 0.063m最大误差 0.28m。LIO-SAM 的问题出在平面点数量远多于角点而平面约束在巷道方向上的刚度不足一旦载体沿巷道方向运动匹配会在前后位置之间出现来回跳变误差峰值出现在一个 L 型拐角完成后的 10 米内。3.4 D07大环线园区——回环修正带来的反转D07 是七组数据里唯一让 LIO-SAM 反超的场景。这条轨迹长约 420m围绕几栋建筑形成一个大闭环中间还有支路绕回主路。FAST_LIO 最终 ATE RMSE 为 0.091m最大误差 0.48mLIO-SAM 的 ATE RMSE 反而压到了 0.073m最大误差 0.36m。原因很清楚LIO-SAM 在这个数据里检测到了两个可靠回环大闭环回到起点附近时重叠率超过 50%内部支路汇入主路时也有一次重叠因子图优化把这两次回环当成强约束一次性修正了之前累积的大部分漂移。FAST_LIO 不维护全局位姿图也没有回环线程它只能用一个滑动窗口内的局部地图保持一致性长距离的累积误差会跟着整条轨迹一直走到最后。但这并不能说明 LIO-SAM 在所有大环线场景都优于 FAST_LIO。这个反超有个重要前提环境里的回环检测没有误匹配。如果大环线上全是相似的墙面和立柱LIO-SAM 很可能把错误位置当成回环优化完反而把原本还算能看的轨迹拉飞。D07 里的建筑立面有一定个性化特征刚好属于“能可靠闭环”的环境。所有数据集的 ATE RMSE 汇总如下单位米数据集场景FAST_LIOLIO-SAMD01办公室0.0280.035D02长走廊0.0520.088D03室外园区0.0430.067D04地下车库0.0610.075D05货架仓库0.0350.048D06楼间巷道0.0480.063D07大环线园区0.0910.0734. 精度之外的真实差距计算负载、初始化敏感度与建图一致性4.1 单帧耗时与资源占用很多人在跑 SLAM 对比时只看精度但在实际部署中算力余量往往更决定方案能不能落地。我在同一台 NUC 上记录了两种算法的单帧处理耗时和资源占用指标FAST_LIOLIO-SAM平均单帧耗时38ms52ms峰值耗时62ms128msCPU 占用约 1.2 核约 2.5 核内存占用约 0.9GB约 1.7GBFAST_LIO 平均 38ms 意味着 10Hz 雷达下它只占了不到一半的处理窗口余量充足。LIO-SAM 平均 52ms看起来也能跑实时但要警惕峰值每次触发关键帧滑窗和因子图优化时CPU 占用会瞬间冲高在我录制的数据里最严重一次达到 128ms已经超过了一帧周期。在 Livox 的非重复扫描下这个尖峰尤其明显因为前端特征匹配偶尔要重试后端优化被迫等待整条流程的节奏很容易被打乱。如果后面还要再接建图、路径规划等高负载模块LIO-SAM 的资源占用是需要提前评估的。4.2 初始化与参数敏感度的现实差距这是两种算法在工程体验上的一个分水岭。FAST_LIO 的启动过程基本不需要人为干预默认实现会在前几帧里自动估计 IMU bias、重力向量和初始姿态7 组数据我都直接用默认配置启动没有额外调整初始位姿。这对现场部署非常友好开机就能跑。LIO-SAM 则需要在 launch 文件里配置初始位姿估计。初始化给得不对前端 scan-to-map 匹配很容易在刚起步时就发散。我在跑 D04 地下车库数据时第一次没改初始 pitch 角结果前 20 秒轨迹就飞到墙面里去了。这种问题在机械雷达上也许不明显因为 Velodyne 的垂直视场角和扫描特性让前端匹配有更好的收敛域换成 Avia 的小视场角和非重复扫描后初始化误差的容错空间会变小使用 LIO-SAM 时必须在每换一个场景后重新审视初始位姿设置。参数敏感性方面LIO-SAM 需要调的关键帧距离阈值、回环搜索频率和 IMU 噪声协方差。FAST_LIO 也有参数可调但默认值在大多数场景都能给出可用结果调参压力明显更小。4.3 建图点云质量与后续使用影响轨迹误差直接反映位姿估计精度但建图点云的质量还会影响后续的导航、识别、语义标注等环节。我把两种算法建出来的点云分别与全站仪参考扫描对齐统计 cloud-to-cloud 平均距离FAST_LIO 在大部分数据集里点云平均距离在 3~6cmLIO-SAM 在 5~10cmD02 长走廊的墙面尤其明显末端墙壁厚度接近 20cm。对导航来说10cm 的墙面厚度可能还能忍但如果要做高精度地图更新、变化检测或者对接三维语义模型这个差异就会变成很麻烦的脏数据。FAST_LIO 的原点云配准方式对几何边界保持得更好墙面和地面交界处比较干净LIO-SAM 的特征提取相当于只保留了少数“骨架”而地图生成又依赖这些骨架点在全局优化后的位姿一旦特征选择不稳定地图边界就容易出现重影和毛刺。5. 实测之后的选型建议与部署避坑5.1 大多数场景下直接选 FAST_LIO如果你手上的传感器就是 Livox Avia或者准备采购 Avia那我的结论很直接大多数情况直接用 FAST_LIO。它在 D01~D06 这 6 组场景里全部胜出而且胜出的原因不只是精度数值还包括更低的资源占用、更快的启动流程、更少的调参工作。对做巡检机器人、工程车改造、AGV 定位的团队来说这些优势意味着更短的开发周期和更小的现场风险。FAST_LIO 还天然避开了 Livox 驱动的点云格式转换问题。官方仓库直接支持 Avia 的 CustomMsg配置里改一下话题名和雷达型号就能跑LIO-SAM 的默认输入结构是为 Velodyne 这类机械雷达设计的需要额外做格式转换这个坑我们在下一节细说。5.2 追求全局一致性时再认真考虑 LIO-SAMLIO-SAM 的价值不在“随机场景下更准”而在于它提供了回环检测和全局优化这种 FAST_LIO 没有的能力。当你的任务长时间运行、需要反复经过同一个区域并且区域内存在足够独特的几何特征时LIO-SAM 能把历史的累积误差真正“闭环消掉”。D07 大环线的结果就是这个能力的直接体现。如果确实要用 LIO-SAM 跑 Livox建议把更多精力放在两个地方一是前端特征提取的适配保证角点、平面点足够稳定二是回环检测的调参让相似结构不容易误匹配。另外也可以考虑给 FAST_LIO 外部接一个回环优化模块这在一些开源项目里已经有人做了效果会比直接改 LIO-SAM 的前端更稳但工程复杂度更高。5.3 复现过程中最常见的四个坑最后把我实际踩过的、也是文档里很少写清楚的四个坑列出来第一时间戳同步不能省。LIO-SAM 对 IMU 预积分的依赖很强如果 IMU 和雷达之间的时间戳没有硬件同步高速转向时会出现几十毫秒级误差最终反映为轨迹的横向偏移。FAST_LIO 因为滤波更新更紧密对时间同步偏差也有一定容忍度但最好还是统一用 PTP 或 PPS 做硬同步。第二外参必须单独标定不能直接用手量。外参误差对 z 向漂移的影响尤其隐蔽即使平移误差只有 2cm跑完长走廊后高度方向也可能偏出十几厘米。换一次传感器安装位置就应该重标一次。第三评估轨迹时注意对齐方式。地面机器人要用 SE3 对齐不要用 Sim3。我在第一次用 EVO 时直接沿用了无人机项目的命令Sim3 对齐后结果明显“变好”但那是尺度缩放帮忙抹掉了误差并不是算法本身变强了。第四Livox 的 CustomMsg 话题不能直接喂给 LIO-SAM。官方仓库默认读的是 XYZIR 结构必须把点云转成 sensor_msgs/PointCloud2 并去掉无意义的 ring 字段。这一步本身不难但转换后如果 timestamps 处理不当会出现整段点云时间戳错乱导致 scan-to-map 匹配的初始畸变补偿失效。转换时一定要把每个点的相对时间戳保留下来而不是直接用当前帧时间替代。如果你也正在 Livox Avia 上折腾 SLAM这轮实测至少能帮你省掉两周的试错时间。我个人的体会是在非重复扫描雷达上FAST_LIO 属于“下限很高”的方案LIO-SAM 属于“上限更高但需要条件”的方案先想清楚你手里数据的回环可靠性和算力预算再决定把力气花在调哪一套上。