《LIO-SAM阅读笔记》-为何要引入增量式里程计?

前言:

LIO-SAM在后端中同时维护着两个里程计,一个是增量式里程计,一个是优化后的里程计,其中优化后的里程计是经过imu、回环、gps因子图联合优化后的结果,是整个系统中最准确的位姿估计,那么为什么还需要维护增量式里程计呢?

以下是我的理解,不一定正确,如有错误,或者不一样的见解欢迎在评论区留言讨论。

我认为最主要的原因(或者是最大的用途)是需要用增量式里程计信息结合imu预积分信息进行联合的因子图优化,更新IMU偏置。

为何此处要进行联合imu的因子图优化呢?

此处因子图优化可以更新三个变量,分别是:当前帧位姿、速度、IMU偏置。其中前两个完全可以采用后端优化后的里程计信息 ,要比此处优化后的位姿更加准 确,因此这里的因子图优化操作最不可替代的是更新IMU偏置。

那么为什么不采用后端优化后的里程计信息结合imu预积分信息进行联合的因子图优化,更新IMU偏置呢?

增量式里程计是一个平滑的结果不会有大幅度的位姿跳跃,适用于因子图优化时,帧间的位姿变换对imu预积分的约束。而后端优化后的里程计经过联合因子图优化后(尤其是回环时全局的位姿的调整),其帧间的位姿变换幅度可能较大,这样对IMU预积分的约束就起不到什么效果,也就无法准确的更新IMU偏置。

因此我认为,如果不需要更新IMU偏置,在LIO-SAM中完全可以不维护增量式里程计,直接使用后端优化后的位姿联合IMU帧间的预积分结果,就可以发送最终的imu里程计信息。

相关推荐
地平线开发者11 小时前
SparseDrive 模型导出与性能优化实战
算法·自动驾驶
董董灿是个攻城狮12 小时前
大模型连载2:初步认识 tokenizer 的过程
算法
地平线开发者12 小时前
地平线 VP 接口工程实践(一):hbVPRoiResize 接口功能、使用约束与典型问题总结
算法·自动驾驶
罗西的思考12 小时前
AI Agent框架探秘:拆解 OpenHands(10)--- Runtime
人工智能·算法·机器学习
HXhlx15 小时前
CART决策树基本原理
算法·机器学习
Wect16 小时前
LeetCode 210. 课程表 II 题解:Kahn算法+DFS 双解法精讲
前端·算法·typescript
颜酱17 小时前
单调队列:滑动窗口极值问题的最优解(通用模板版)
javascript·后端·算法
Gorway1 天前
解析残差网络 (ResNet)
算法
拖拉斯旋风1 天前
LeetCode 经典算法题解析:优先队列与广度优先搜索的巧妙应用
算法
Wect1 天前
LeetCode 207. 课程表:两种解法(BFS+DFS)详细解析
前端·算法·typescript