做激光雷达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和你自己源码编译的PCL，CMake经常找到错误的那份，导致链接时符号冲突。建议用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领域是有示范意义的。以后新出的系统如果能在退化场景下保持更低的误差衰减速率，对比起来也更有说服力。
从工业角度看，退化场景处理能力直接决定了一款定位产品能不能从停车场扩展到地下矿、从室内仓扩展到大平层。开源的实现和基线数据让技术团队可以更早评估方案的可行性，不必拖到现场才知道行不行。
我个人判断，这个方向后续值得期待的扩展有三块：一是和固态激光雷达的适配，固态雷达视场角有限，退化发生的频率和形态都会变化，检测策略需要重新设计；二是和语义信息的结合，如果系统能识别出门、柱子、反光条等人造特征，退化判断就不必完全依赖几何分布；三是动态场景下的退化处理，现有方法大多假设环境静止，有行人和车辆穿梭的环境里，退化检测的难度会明显上升。
写在最后的个人体会
从我在实际项目里折腾的经验来看，面向退化场景的激光雷达配准最考验人的地方，不是算法推导，而是对"未知状态"的容忍和取舍。一个没有退化处理模块的系统，在正常环境里跑得很好，一旦进入隧道就会瞬间崩溃。一个加了退化处理的系统，在隧道里能保持低速漂移，回到开阔区域还能重新对齐。从"瞬间崩溃"到"缓慢漂移"已经是质的飞跃，这也正是这类开源工作最值得借鉴的地方。
如果你想在自己的系统里引入退化感知能力，建议先别急着改核心模块，而是把开源代码跑通、把自带的数据集玩透，重复几次论文里的实验曲线。等你确认自己对"约束方向""退化强度"这些概念有了直观感受，再动手集成到自己的系统里。调参的时候记住一条经验：退化检测宁可敏感一点，也不要迟钝；但在融合时要保持克制，过度信任退化标志反而会破坏原本正常区域的精度。最好的状态，是让退化处理成为一个低调的守护者，平时不打扰，关键时刻能把系统从悬崖边拉回来。
