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

前言:

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

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

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

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

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

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

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

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

相关推荐

  1. LIO-SAM阅读笔记》-为何引入增量里程

    2024-01-13 12:20:06       61 阅读
  2. LIO-SAM阅读笔记》3.后端优化

    2024-01-13 12:20:06       52 阅读

最近更新

  1. docker php8.1+nginx base 镜像 dockerfile 配置

    2024-01-13 12:20:06       94 阅读
  2. Could not load dynamic library ‘cudart64_100.dll‘

    2024-01-13 12:20:06       100 阅读
  3. 在Django里面运行非项目文件

    2024-01-13 12:20:06       82 阅读
  4. Python语言-面向对象

    2024-01-13 12:20:06       91 阅读

热门阅读

  1. Rust语言的Hello, World! 程序解析

    2024-01-13 12:20:06       43 阅读
  2. Prior information

    2024-01-13 12:20:06       50 阅读
  3. JWT相关问题及答案(2024)

    2024-01-13 12:20:06       41 阅读
  4. C#执行数据加密的DES.Create 方法

    2024-01-13 12:20:06       58 阅读