请教下回环结果不反馈到前端的问题~！

[lonlonago]

FAST_LIO_LC的作者yanliang-wang,在FAST_LIO_SLAM的基础上添加了：1.基于Radius Search 基于欧式距离的回环检测搜索，增加回环搜索的鲁棒性；2.回环检测的优化结果，更新到FAST-LIO2的当前帧位姿中，幷进行ikdtree的重构，进而更新submap。

我想问个问题

如果做了回环检测优化位置后，不把优化后的结果更新到 fast lio，也不重构 ikdtree ，直接就用回环后的结果作为最后的结果，前端后端不耦合，完全分离，这样做有什么影响吗？

不重构的话，当前实修正的里程计就没更新到 fastlio里，然后，fastlio的维护的submap还是原始的激光里程计

不用 fastlio 的结果作为最后的结果，只用回环后端的结果作为最后结果

Fatlio 就做为一个单纯的里程计

Fastlio 单纯的只输出，不接受回环输入

相当于没有实时修正

这样有个好处，即便原作者改了代码，因为二者不耦合，也可以继续使用，各自都是单独的模块

我的疑问就是这种方式有什么坏处 会不会修正了 fastlio 的 submap 会使得最后的结果更好，因为相当于一直在修正，对于激光里程计的结果也会更好，还是说对于最后的结果影响不大，因为后端在不停的修正漂移

谢谢您的回复~

[yanliang-wang]

你好，
是的，FAST_LIO_SLAM那种将fastlio和后端优化解耦的方式会更方便一些，可以方便地更换独立的模块；

我将后端优化的结果传给fastlio是想要使用后端优化的结果对fastlio的累积误差进行修正，修正后的fastlio理论上会有更高的定位精度。至于这种方式的坏处，我个人认为可能是实时性会差一些，因为加了实时运行的后端优化模块，有点违背了“fast”的原则

[lonlonago]

谢谢，那我想追问下，您是否尝试过，只用后端回环优化模块优化前端激光里程计的结果，我猜想这样运行的结果也是ok的？也就是前端保持原作者的不动，后端用您的这个部分

[hitzhang]

谢谢，那我想追问下，您是否尝试过，只用后端回环优化模块优化前端激光里程计的结果，我猜想这样运行的结果也是ok的？也就是前端保持原作者的不动，后端用您的这个部分

FAST_LIO_LC 有把后端结果传到里程计修正么 我没看到ikdtree重构啊？请问下是哪部分

[zhh2005757]

谢谢，那我想追问下，您是否尝试过，只用后端回环优化模块优化前端激光里程计的结果，我猜想这样运行的结果也是ok的？也就是前端保持原作者的不动，后端用您的这个部分

回环之后不调整地图的话你当前位姿对应的点云帧和之前的旧地图匹配得到的位姿不就是错误的了吗？

[Junble19768]

我说一下我个人在FastLIO使用过程中的体验。
我个人使用场景偏向于室内，使用时间不长，但是环境比较恶劣，同时对定位的要求比较高，激光雷达使用的是mid360；在使用的过程中，大部分情况下fastlio都可以良好的工作，甚至我可以考虑只用前端做定位；但是曾经有一回因为车体的冲撞等各种原因，imu检测到线性加速度有10g，并接连发生了几次后，fastlio本身的定位就发生很大的漂移（1m左右），但是由于我有一定的后端，实际上这些漂移是可以纠正回来的，但是fastlio在发生漂移后把新的地图建立在ikdtree中，然后可能是因为新老地图同时进行icp的检测，导致fastlio的漂移几乎是雪崩一样的接连发生；如果此时在后端可以把优化后的地图回传给fastlio的ikdtree的话，我觉得实际的效果可能会好很多，但是我还没有这么尝试过。