做激光雷达SLAM的兄弟肯定都有过这种体验车子开进一条笔直的长走廊或者一片开阔的大广场原本稳定的里程计突然开始画龙地图上出现重影转角莫名其妙漂出去一截。运气好点停下来转一圈能拉回来运气不好整个定位直接发散任务宣告报废。这类让传统配准算法集体失效的场景圈里叫退化场景是激光雷达配准从能用走向好用绕不过去的坎。香港科技大学最近在IJRR上开源的这项工作主题正好就是面向退化场景的激光雷达配准。IJRR是机器人领域的老牌顶刊能在这个平台上发至少说明方法和实验都比较扎实。更关键的是代码开源针对的就是那些让FAST-LIO、LIO-SAM们在墙角怀疑人生的环境。我这篇博文会从退化问题的本质讲起拆解这类方案的设计思路再结合实际跑代码的经验说说怎么把开源的东西落到自己的项目里。1. 退化场景激光雷达配准工程里的隐形杀手1.1 我们说的退化到底是什么先不扯术语用大白话讲。激光雷达配准的原理说白了就是让当前帧的点云和上一帧或者局部地图对齐对齐的依据是找到足够的点对、线对、面对应关系然后求解一个刚体变换。这个过程在数学上是一个非线性优化问题优化的目标是让对应点之间的距离误差最小。问题在于不是所有环境都能提供足够的约束来唯一确定这个变换。想象一下你站在一条又长又直、两侧墙壁平整的走廊里沿走廊方向往前看前后景物的轮廓几乎一模一样。雷达扫过去你能清楚知道离墙多远离天花板多高但我到底往前挪了十厘米还是一米点云在数学上几乎给不出有效信息。用优化的话说这个方向上的误差函数非常平坦梯度趋近于零梯度下降根本走不动。工程上常见的退化场景就那几种长直走廊、隧道、开阔广场、地下车库的大平层、雪地、水面。它们有一个共同点某个或某几个空间方向上缺少可靠的几何特征。走廊缺的是沿轴向的约束广场缺的是水平面上的两个方向约束雪地和水面缺的更多。在这些方向上算法估算出的位姿表面上看着在更新实际上是在瞎猜噪声一大就直接飘走了。1.2 为什么常规配准算法救不了场传统ICP及其变体点到点、点到面、GICP包括NDT在退化场景中失效本质原因是它们在求解时把六个自由度的变换当作一个整体来处理。点云提供的约束分布在Hessian矩阵或者说信息矩阵的特征向量方向上当某个方向几乎没有特征点时矩阵出现病态最小特征值接近零。数值求解时这个方向上的微小扰动就会被放大成巨大的位姿误差。LOAM系的特征点方法稍微好一点因为它显式提取边缘点和平面点至少在几何直觉上更接近约束的本质。但边缘点和平面点依然存在分布不均匀的问题。一条直隧道里平面点占了绝大多数边缘点稀疏而且边缘线的朝向大多和隧道轴向平行对轴向位移的约束能力依然有限。NDT把空间划分成体素每个体素用正态分布描述体素密集的地方约束强体素稀疏或形状扁的地方约束照样弱。我自己的切身体会这类问题最坑的不是它无法被监测到而是它经常在你最松懈的时候爆发。你跑KITTI或者自己的园区数据集算法表现优秀RMSE压得很低于是你带着它去现场。结果现场有条80米长的通道跑到一半里程计就开始慢性漂移最后回到起点地图错开了好几米。这种指标很美、实际翻车的情况在退化场景处理不充分的系统里比比皆是。2. 面向退化场景的配准这项开源工作在解决什么问题2.1 核心思路把约束质量量化出来要应对退化第一步是知道什么时候退化、在哪个方向退化。HKUST这套工作给我的印象是它把约束质量的量化做得比较透。它没有把退化当成一个黑箱开关要么退化、要么没退化而是分析当前帧与地图之间的几何约束在哪些方向上是强的、哪些方向上是弱的。具体做法上常见的主流方案是构造当前帧点到局部地图的残差在解算位姿的同时统计优化问题的信息矩阵。对信息矩阵做特征值分解六个特征值分别对应六个自由度方向上的约束强度特征值大说明这个方向被点云约束得好特征值小说明约束不足。再往下走一步就是设定两个阈值把特征值分成强约束方向和弱约束方向弱约束方向上的特征值占比一旦超过设定的比例系统就标记为退化状态并记录退化发生的主方向。这套逻辑本身不是这家机构首创但他们的工程化处理要完善得多。比如如何区分真退化和局部特征稀疏如何利用多帧历史信息来平滑退化的判断结果如何把退化方向实时同步给融合前端。这些细节在论文里可能只是几张图和几段公式但放到实际系统里都是决定稳定性的关键点。2.2 退化方向上的有限更新策略检测出退化方向只是第一步更关键的是知道检测出来之后该怎么办。最粗暴的做法是发现退化就直接冻结位移更新但这会导致位姿不连续恢复过来的时候地图会跳变。更合理的做法和这套开源工作的重点比较一致在强约束方向上信任激光配准的结果在弱约束方向上限制更新的幅度用其他传感器或者运动先验去填补这部分缺失的信息。所谓有限更新通俗地说就是如果系统认为走廊轴向约束不足那就保留激光在横向和垂向上的精确估计但轴向位移改用IMU积分或轮式里程计来推算并且在优化迭代时给轴向位移加上一个较小的信任上限防止误差被一步步积大。这种方法相当于把六自由度的位姿问题拆成强约束子空间和弱约束子空间分别处理而不是强迫算法在一个病态问题上硬解出完整答案。这一点和我之前折腾FAST-LIO的体会是一致的。FAST-LIO用IESKF理论上可以在退化场景下靠IMU扛住一段时间但如果退化持续时间长IMU的bias会逐渐累积最终还是会被激光的微弱约束带偏。有了显式的退化方向分析系统可以在退化方向上有意识地下调激光的权重而不是被动地等着误差累积到不可收拾。要提醒一下的是任何有限更新策略都依赖一个前提你有一个足够可靠的先验来源要么IMU性能还行要么轮速计不打滑要么车辆运动模型基本靠谱。如果三样都没有那再好的退化检测也只能把系统的失效模式从瞬间发散变成缓慢漂移做不到完全根治。2.3 开源带来的工程价值我觉得这项工作的开源价值很大程度在于它给了一套可以对比、可以移植、可以二次开发的基线。现在的开源SLAM系统不少但很多论文代码, released满天飞真正能直接编译跑通的不多能在你自己的传感器配置下稳定工作的更少。这套代码如果按照IJRR的惯例通常会附带完整的运行说明、样例数据和评估脚本这对想复现实验、做学术对比的团队是很友好的。从工程集成的角度看最理想的使用方式是把它作为现有LO/LIO系统的一个退化检测与约束管理模块。自己做一遍的话光是推导退化分析、调阈值、处理各种极端的点云分布可能就要花掉两三个月。开源之后你拿到的是一个已经跑通、有测试数据和论文实验背书的参考实现剩下要做的就是适配自己的传感器外参、运动模型和场景特征。3. 从论文到落地开源仓库的实操与配置经验3.1 环境准备与依赖清单先说环境。这类配准项目的老朋友基本是Ubuntu系统20.04或22.04都行ROS1的Noetic或者ROS2的Humble开源仓库一般两者会支持一个或给出适配说明加上PCL、Eigen3、Ceres Solver、OpenMP这些基础库。如果项目里带了因子图优化或者预积分模块大概率还会依赖GTSAM或Sophus编译的时候需要一并装上。我自己在编译这类项目时踩过不少坑这里说几个高频注意点PCL版本和C标准要对应如果系统里同时装了系统自带的PCL和你自己源码编译的PCLCMake经常找到错误的那份导致链接时符号冲突。建议用CMake指定PCL_DIR并且保证编译的C标准一致。Eigen的版本不能太旧至少3.3以上部分函数在旧版本里性能差很多。如果项目用了Ceres注意它的LOSS_FUNCTION和SOLVER_TYPE的可选项在不同版本中略有差异报错信息不会直接告诉你版本问题需要逐一排查。ROS的catkin工作空间和纯CMake工作空间不要混在一起编译建议开一个干净的catkin_ws/src把项目clone进去后只用catkin_make或者colcon build。3.2 数据准备与评测流程跑通代码不能只靠自带数据一定要自己准备场景更恶化的测试数据。我的建议是分三个层级递进测试第一层用仓库自带的公开数据跑一遍确认编译和运行链路没问题。第二层找一段你自己采集的、有部分退化的数据比如园区里有一小段开阔广场观察退化检测模块有没有正确触发。第三层专门采集强退化数据比如一条笔直的地下停车库通道、一段隧道或者雪后的大操场这是检验方案成色的关键。采集的时候注意把IMU和激光雷达的时间戳对齐。很多开源项目会要求输入的点云话题带有精确时间戳如果IMU话题和点云话题的时间基准不一致退化分析模块的输入时序就会乱掉。跑出来的结果即使轨迹看起来没问题你也不知道到底有没有踩到检测的逻辑分支上。评测时不要只看绝对轨迹误差ATE建议同时记录退化检测模块输出的退化标志、退化方向占比和位姿置信度离线画一条时间线。你就能清楚地看到轨迹开始漂移之前退化标志是不是先触发了触发的方向是不是和实际环境几何吻合这个信息在调试时比任何总指标都管用。3.3 需要重点关注的参数开源项目通常把参数集中在YAML配置文件里每个参数改起来都很方便但关键是知道哪些值得动、哪些不要乱动。结合我自己的经验下面几个参数是调试时的重点体素分辨率体素太大几何信息被过度平滑退化检测会偏乐观体素太小点云噪声放大退化检测会偏敏感。先从和雷达线数匹配的经验值开始比如32线雷达用0.5到1.0米64线雷达可以更细一点。最近邻搜索的邻域半径这影响到每个点关联到局部地图时的约束计算。半径太小约束不足半径太大地图点分布稀疏退化也会误报。退化特征值比例阈值这是最敏感的一个参数。默认值如果在大场景数据上经常误报就调高比例阈值如果在小场景数据上漏报就调低。没有一劳永逸的值必须根据部署场景标定。IMU和激光融合的权重一些项目用固定的协方差矩阵一些项目会根据退化方向动态缩放。如果你想在目标场景里让系统偏向平滑运动可以把IMU权重调大但代价是地图精度下降反过来如果场地特征丰富可以调大激光权重轨迹会更锐利。调参的过程本质上是找平衡点没有通用的最优参数只有在你部署环境里不翻车的参数。我通常的做法是先保存一组基准参数然后每次只改一个变量跑同一段rosbag记录每个变量变化前后的ATE和退化误报率。这个表格最后会告诉你在当前场景里哪个参数是瓶颈。3.4 编译与运行的常规步骤下面是一份基于常见实践的运行流程具体细节以仓库的README为准# 1. 创建工作空间并克隆代码 mkdir -p ~/degenerate_ws/src cd ~/degenerate_ws/src git clone 项目仓库地址 # 2. 安装依赖Debian/Ubuntu sudo apt install libeigen3-dev libpcl-dev ros-noetic-pcl-ros ros-noetic-velodyne-msgs # 3. 编译 cd ~/degenerate_ws catkin_make source devel/setup.bash # 4. 修改配置文件中的传感器外参、话题名和参数阈值 # 通常位于 config/xxx.yaml # 5. 运行rosbag回放同时启动配准节点 roslaunch 包名 run.launch rosbag play --clock your_dataset.bag这段流程看起来不起眼但修改传感器外参这一步最容易出问题。外参标定不准的话退化检测的方向判断会出错系统可能在正常环境里疯狂报退化或者在真正的退化方向上看不见异常。如果你的雷达和IMU之间没有精确的外参建议先跑一遍外参标定工具再用标定结果替换配置文件里的初值。4. 常见问题与排查技巧实录4.1 退化误报怎么处理大概每个接触这类系统的人都会遇到在一个明明特征丰富、转角很多的室内环境里系统却频繁报退化轨迹抖动得厉害地图边缘看到明显的毛刺。这种情况通常是退化检测的阈值设置得太敏感了。排查思路有三个方向。第一检查你输入的点云是不是被降采样得过狠体素网格或者VoxelFilter的分辨率设得太大导致原本锐利的墙角、柱子边缘都变成了模糊的团块特征被抹掉了。第二检查局部地图的构建方式如果地图点太少约束矩阵自然就病态退化检测就会把正常环境误判成退化。第三检查传感器噪声雷达本身晃动大或者运动畸变明显的时候残差的协方差会被撑大特征值分布会发生偏移这时需要适当调低检测灵敏度。我遇到过的一个真实案例是把雷达安装在机器人顶部的支架上支架有一点弹性机器人急转弯的时候雷达会轻微晃动。正常的建图精度影响不大但退化检测模块对异常运动非常敏感连续误报。最后在算法前端加了一个基于IMU角速度的运动畸变补偿误报率一下子降下来了。4.2 传感器之间的时间同步多传感器融合系统里时间同步是能让老手都挠头的问题。激光雷达的每一帧点云实际上是在扫描周期内的不同时间点采集的不同点如果直接把这帧点云当作同一个时刻的快照再和其他传感器的数据做融合运动畸变大的时候误差就明显了。这套开源工作在退化方向分析时肯定也依赖IMU或里程计数据。如果真的采用IMU做退化方向的先验时间戳错位会直接影响约束分析的结果。排查时间同步问题时建议用以下方法在回放数据时打开rviz同时显示点云和IMU的tf变换观察点云有没有因为运动补偿不准而出现双影。查看话题的时间戳统计写个小脚本输出点云和IMU相邻消息的时间差看是否存在稳定的偏移。如果时间偏移是固定的可以在配置里设置时间偏移量如果是漂移的就需要每个传感器各自校准时钟比如用PTP或NTP。4.3 在下游定位、建图模块里集成时的坑跑通单点不太够更常见的需求是把退化处理能力集成到自己的定位或者建图系统里。集成时最容易出的问题是没有把退化检测的置信度和下游模块对接好。下游模块接收到每帧位姿时并不知道这一帧的估计有多可信。如果你只是把退化标志位从前端传到后端而后端的图优化或回环检测没有处理低置信度约束的逻辑那么退化的影响还是会传播出去。一个可行的做法是在退化方向上的约束残差协方差放大让图优化在后端自动降低这些边的权重。这样前端负责判断哪里不可信后端负责遇到不可信约束时怎么做分工清晰也不会破坏原有系统的结构。另外如果系统里有回环检测退化场景下检测到的回环候选往往更多也更杂因为长走廊两边几何相似。建议在回环验证阶段加入方向一致性检查把退化方向上的回环候选排除掉否则会误报一堆假回环。5. 这套方案能用到哪些场景价值和边界在哪5.1 地下空间与矿区GNSS拒止下的硬骨头矿区巷道、地下管廊这类场景是退化问题的重灾区。巷道空间狭窄、墙面平整、照明条件差有时候还有水和粉尘干扰雷达的反射特性也会变化。机器人和无人矿卡在这种环境里作业对定位稳定性的要求极高一旦里程计漂移有可能直接碰撞巷道壁。紧凑的空间也意味着雷达点云在横向和垂向上的约束可能勉强够用但巷道的走向方向上约束极弱这和本文开头说的走廊问题一模一样。退化检测和有限更新策略正好能派上用场。在这类场景里通常需要额外融合轮式里程计或者矿山自身的定位信标退化处理模块负责判断什么时候该信任这些辅助源。5.2 室内仓储与物流高频往返下的长期一致性室内仓储环境有意思的地方在于它既有货架林立、特征丰富的区域也有大片的装卸区和通道交叉口。AGV长时间在相同路径上往返短期配准的误差被重复路径不断累积最后会出现同一货架在多次路过时地图位置对不齐的情况。退化方向分析在这里的价值主要不是解决某个瞬间发散而是维护长期的一致性。AGV进入装卸区这种空旷区域时退化检测模块会看到水平方向约束不足于是系统自动降低这一段的激光位姿置信度同时回环检测到货架区时用强约束把累积误差拉回来。开源的实现可以作为一个标准的参考模块嵌入到现有的AMR定位系统里比自己从零开发要高效很多。5.3 隧道与桥梁检测垂直面为主的结构化环境检测无人机搭载激光雷达去扫描隧道内壁或者桥梁底面时点云的主体是一个巨大的曲面或平面。在这种面状环境里激光传感器沿面法线方向的约束很强但沿面的切向约束很弱。传统配准会把无人机定在面附近但忽略在贴面滑动方向上持续漂移。面向退化的配准方案如果能够把面内切向识别为退化方向并把这部分的位移估计交给IMU或视觉惯性模块整体定位就会稳定很多。这类场景还经常涉及小范围、高精度的纹理化建模需求退化处理做得好不好直接决定了最终模型有没有重影。5.4 影响范围与技术拓展方向从学术角度看这类工作把退化从一个被回避的边角问题转化成了可以被显式建模、可量化评估的研究对象这对整个LiDAR SLAM领域是有示范意义的。以后新出的系统如果能在退化场景下保持更低的误差衰减速率对比起来也更有说服力。从工业角度看退化场景处理能力直接决定了一款定位产品能不能从停车场扩展到地下矿、从室内仓扩展到大平层。开源的实现和基线数据让技术团队可以更早评估方案的可行性不必拖到现场才知道行不行。我个人判断这个方向后续值得期待的扩展有三块一是和固态激光雷达的适配固态雷达视场角有限退化发生的频率和形态都会变化检测策略需要重新设计二是和语义信息的结合如果系统能识别出门、柱子、反光条等人造特征退化判断就不必完全依赖几何分布三是动态场景下的退化处理现有方法大多假设环境静止有行人和车辆穿梭的环境里退化检测的难度会明显上升。写在最后的个人体会从我在实际项目里折腾的经验来看面向退化场景的激光雷达配准最考验人的地方不是算法推导而是对未知状态的容忍和取舍。一个没有退化处理模块的系统在正常环境里跑得很好一旦进入隧道就会瞬间崩溃。一个加了退化处理的系统在隧道里能保持低速漂移回到开阔区域还能重新对齐。从瞬间崩溃到缓慢漂移已经是质的飞跃这也正是这类开源工作最值得借鉴的地方。如果你想在自己的系统里引入退化感知能力建议先别急着改核心模块而是把开源代码跑通、把自带的数据集玩透重复几次论文里的实验曲线。等你确认自己对约束方向退化强度这些概念有了直观感受再动手集成到自己的系统里。调参的时候记住一条经验退化检测宁可敏感一点也不要迟钝但在融合时要保持克制过度信任退化标志反而会破坏原本正常区域的精度。最好的状态是让退化处理成为一个低调的守护者平时不打扰关键时刻能把系统从悬崖边拉回来。