小议2019机器人顶会上的3D 激光紧耦合里程计——Lio

里程计——Lio"/>

小议2019机器人顶会上的3D 激光紧耦合里程计——Lio

笔者想结合自己移动机器人的实际工作简单谈谈2019年的激光imu紧耦合slam。

谈讨论的这三篇都是基于Loam的二次开发的。

lio-mapping[1]七月份最先出来。完全基于vins mono框架改编。loam的特征基于nearest neighbor完全是很弱的匹配。图结构里面为了把所有滑窗的pose vertices串起来，只能每滑窗帧都去相对fixed frame（pivot）提nearest neighbors，这个非常耗时的。在滑窗帧中，每帧的激光观测都是与第一帧关联。除毗邻帧间用imu观测串起来外， 为了建立激光帧相互间的联系，必须边缘化掉第一帧，这个其实也挺耗时的，而且违背FEJ。其实loam中边优化，边重新计算nearest neighbors，相当于观测重新采样了剔除了outlier。 但是 lio-mapping中放到滑窗中统一优化，没有重新计算nearest neighbors环节。实际上，每帧都提nearest neighbors算力已经吃不消了，在优化中更新nearest neighbors激光观测是不现实的。这样导致没有剔除的outlier会随着边缘化后产生的prior传递给后面的信息矩阵。总结：算法资源挺耗的， 计算的信息也没有充分利用，但是很好的展现了vins-mono框架可以在其它传感器上迁移应用。该作者还回避了一个业界痛点： 数据同步！

lio-mapping后该课题组改良了实时性的问题，回归并尊重了loam算法的本质，并用上了lego-loam的前端数据预处理策略。在R_LINS[2] 中，用iterated Kalman filtering来改写loam的帧间匹配。图结构上可以理解为window size为2的一个滑窗。总结：删繁就简，返普归真，但是为什么还是回避了数据同步&