最新开源Faster-LIO：快速激光IMU里程计
文章：Faster-LIO: Lightweight Tightly Coupled Lidar-inertial Odometry using Parallel Sparse Incremental Voxels
作者：Chunge Bai1,2, Tao Xiao2, Yajie Chen2, Haoqian Wang1 , Fang Zhang2and Xiang Gao
代码：https://github.com/gaoxiang12/faster-lio.git
本文仅做学术分享，如有侵权，请联系删除。内容如有错误欢迎评论留言，未经作者允许请勿转载，欢迎各位同学积极分享和交流。
内容部分摘自半闲居士的知乎文章，https://zhuanlan.zhihu.com/p/468628910
本文仅做学术分享，如有侵权，请联系删除。
摘要
本文提出了一种基于增量体素的激光雷达惯导里程计（LIO）方法，用于快速跟踪旋转和固态激光雷达扫描点云，为了获得较高的跟踪速度，我们既不使用复杂的基于树的结构来划分空间点云，也不使用严格的k近邻（k-NN）查询来计算点匹配。相反，我们使用增量体素（iVox）作为我们的点云空间数据结构，它是从传统体素修改而来的，支持增量插入和并行近似k-NN查询，我们在算法中提出了线性iVox和PHC（伪希尔伯特曲线）iVox作为两种可选的底层结构，实验表明，在固态激光雷达中，iVox的每次扫描速度达到1000-2000HZ，而在32线旋转激光雷达中，iVox的速度超过200赫兹（仅使用现代CPU），同时仍保持相同的精度水平!
总体介绍
大体来讲，LIO系统的整个计算流程是比较固定的：它们从IMU中得到一个粗略的估计，然后把雷达的数据与一些历史数据做配准，最后用某种状态估计算法进行滤波或者优化。IMU部分的处理差别不大，所以LIO系统的计算效率主要与点云算法和后端算法相关，我们大致分三个方面：
点云最近邻的数据结构。点云配准的基本问题是计算给定点与历史点云的最近邻，通常需要依赖一些最近邻的数据结构。这些数据结构又大体分为树类的（tree like）和体素类（voxel like）的。广义的，高维的最近邻问题是一个比较复杂的问题，但LIO里的最近邻则是低维的、增量式的问题。于是，像R*树、B* 树等静态的数据结构并不是非常适合LIO。FastLIO2里提出使用增量式的kdtree来处理最近邻，我们则认为增量的体素更适合LIO系统。
点云残差的计算方式。自动驾驶里普遍偏向不直接使用点到点的残差，而是使用点到线或点到面的残差。点到点的残差形式虽然简单，但雷达点云和RGBD点云相比，更加稀疏，在车辆运动过程中不见得都能打到同一个点，而且点云也往往会被降采样后再进行处理，所以并不太适合在自动驾驶中使用。LOAM系列会计算点云特征，实际当中特征提取要花的时间是不可忽略的，甚至是主要计算部分。
状态估计算法的选型。LIO和VIO中普遍会使用介于单帧EKF和批量优化之间的方案，例如IEKF、MSCKF、Sliding Window Filter等等。这其中又以IEKF算是最简单有效的一类，既有迭代来保证精度，又不需要像预积分系统那样算一堆雅可比矩阵。
以上内容摘自半闲居士的知乎文章：https://zhuanlan.zhihu.com/p/468628910
实验
仿真实验是在一个随机生成的点云里进行K近邻查找以及新增地图点的实验。我们对比了Kdtree flann, ikd-tree, nanoflann R-tree, faiss-IVF, nmslib几个库。耗时与地图点数的关系图如下：
插入、K近邻查询时间与点数的关系
各算法的召回率与时间曲线如下：
数据集实验
数据集实验主要比较整个LIO系统的耗时和计算精度。由于Faster-LIO框架与FastLIO2基本相同，我们时间上对标的也主要是FastLIO2，其他系统主要是用来做个参考。32线雷达的详细步骤算法耗时如下图所示：
在精度方面，考虑到LIO默认不带回环检测，所以我们主要评价每百米的漂移误差指标（百分比形式），见下表
与LeGO-LOAM对比
总结
本文提出了一种更快速的LIO方法，使用iVox作为最近邻方案，在同等精度指标下可以明显提升LIO计算速度。
内容摘自半闲居士的知乎文章，可查看知乎原文：https://zhuanlan.zhihu.com/p/468628910