Question About Result.

[Gatsby23]

感谢作者做出了如此丰富的对比试验，完全让我没想到的是LINS能达到这么好的效果。因为看LINS的代码和论文，Lidar和IMU的紧耦合结果仅仅作为初值送入Mapping Module，Mapping Module本身还需要再做一次Scan-to-Map的ICP，所以我自己尝试过在不同初值下的Scan-to-Map的结果，发现得到结果差距不大，但没想到实际效果中LINS的结果如此的好。不过可能也有两方面的原因：一方面是在LINS的代码中有通过重力方向来校正Roll和Pitch的过程。这个可能对车体运动本身有较好的校正效果。二是在一些激烈运动中，需要较好的初值才能收敛，这是我做实验不足和没有想到的地方。 但我更推荐作者去尝试现在新出的两种算法：F-LOAM和Fast-LIO。特别是FAST-LIO是基于当前帧与地图的观测来做更新，理论上能取得更好的效果。

[chengwei0427]

紧耦合的效果会比松耦合效果要好（约束更多，同样对传感器要求也更高），这个也必将符合预期；

lego_loam表现虽然让人诧异，但也符合其工作原理（scan-to-scan效果很差，这也是不如aloam的地方）；

[Gatsby23]

紧耦合的效果会比松耦合效果要好（约束更多，同样对传感器要求也更高），这个也必将符合预期；

lego_loam表现虽然让人诧异，但也符合其工作原理（scan-to-scan效果很差，这也是不如aloam的地方）；

LEGO-LOAM应该也有scan-to-map的部分，LINS就是对LEGO-LOAM的修改。LEGO-LOAM当时的研究背景是针对野外，所以需要去除地面点（避免野草的干扰）。但是在城市道路上，这种缺乏地面约束，反而带来效果不一定好。但LINS本身的聚类这些都对算法的提升应该有实际帮助。

[chengwei0427]

紧耦合的效果会比松耦合效果要好（约束更多，同样对传感器要求也更高），这个也必将符合预期； lego_loam表现虽然让人诧异，但也符合其工作原理（scan-to-scan效果很差，这也是不如aloam的地方）；

LEGO-LOAM应该也有scan-to-map的部分，LINS就是对LEGO-LOAM的修改。LEGO-LOAM当时的研究背景是针对野外，所以需要去除地面点（避免野草的干扰）。但是在城市道路上，这种缺乏地面约束，反而带来效果不一定好。但LINS本身的聚类这些都对算法的提升应该有实际帮助。

虽然lego也有scan-to-map，但是在退化场景，如果scan-to-scan 效果不好，对scan-to-map影响很明显；

关于地面约束，loam类方法，都有这类问题；你有没有什么好的解决办法呢？可以讨论一下。

[Gatsby23]

紧耦合的效果会比松耦合效果要好（约束更多，同样对传感器要求也更高），这个也必将符合预期； lego_loam表现虽然让人诧异，但也符合其工作原理（scan-to-scan效果很差，这也是不如aloam的地方）；

LEGO-LOAM应该也有scan-to-map的部分，LINS就是对LEGO-LOAM的修改。LEGO-LOAM当时的研究背景是针对野外，所以需要去除地面点（避免野草的干扰）。但是在城市道路上，这种缺乏地面约束，反而带来效果不一定好。但LINS本身的聚类这些都对算法的提升应该有实际帮助。

虽然lego也有scan-to-map，但是在退化场景，如果scan-to-scan 效果不好，对scan-to-map影响很明显；

关于地面约束，loam类方法，都有这类问题；你有没有什么好的解决办法呢？可以讨论一下。

对scan-to-map这里还是持有疑问的。LEGO-LOAM的优化算法好像是自己写的，你可以用ceres重构下，会发现scan-to-map这类算法几乎不受初值影响就可以得到很好的效果（优化的时候要在SE3上）。换句话说就是scan-to-scan可以直接去掉来降低计算开销了。关于地面约束这块：LEGO-LOAM本身是直接去掉地面的，所以肯定不好（至于为什么还能看到部分地面，应该是历史原因，受当时的地面算法约束）。对于地面约束的话，更多感觉应该是和采集设备相关，像你们做实验的小车，就可以直接采用类似零速修正，或者地面限高这样的方法来做。这类算法在LINS当中是有的，可以看看

[chengwei0427]

紧耦合的效果会比松耦合效果要好（约束更多，同样对传感器要求也更高），这个也必将符合预期； lego_loam表现虽然让人诧异，但也符合其工作原理（scan-to-scan效果很差，这也是不如aloam的地方）；

LEGO-LOAM应该也有scan-to-map的部分，LINS就是对LEGO-LOAM的修改。LEGO-LOAM当时的研究背景是针对野外，所以需要去除地面点（避免野草的干扰）。但是在城市道路上，这种缺乏地面约束，反而带来效果不一定好。但LINS本身的聚类这些都对算法的提升应该有实际帮助。

虽然lego也有scan-to-map，但是在退化场景，如果scan-to-scan 效果不好，对scan-to-map影响很明显； 关于地面约束，loam类方法，都有这类问题；你有没有什么好的解决办法呢？可以讨论一下。

对scan-to-map这里还是持有疑问的。LEGO-LOAM的优化算法好像是自己写的，你可以用ceres重构下，会发现scan-to-map这类算法几乎不受初值影响就可以得到很好的效果（优化的时候要在SE3上）。换句话说就是scan-to-scan可以直接去掉来降低计算开销了。关于地面约束这块：LEGO-LOAM本身是直接去掉地面的，所以肯定不好（至于为什么还能看到部分地面，应该是历史原因，受当时的地面算法约束）。对于地面约束的话，更多感觉应该是和采集设备相关，像你们做实验的小车，就可以直接采用类似零速修正，或者地面限高这样的方法来做。这类算法在LINS当中是有的，可以看看

scan-to-map这里，lego和loam是一致的；我说的受scan-to-scan影响，主要是在退化情况下，会影响； 至于lego的地面约束这块，lego是把地面作为surf特征，一起去约束的（跟loam一致）； 地面限高我可以理解，你说的零速修正，是什么意思？

[Gatsby23]

紧耦合的效果会比松耦合效果要好（约束更多，同样对传感器要求也更高），这个也必将符合预期； lego_loam表现虽然让人诧异，但也符合其工作原理（scan-to-scan效果很差，这也是不如aloam的地方）；

LEGO-LOAM应该也有scan-to-map的部分，LINS就是对LEGO-LOAM的修改。LEGO-LOAM当时的研究背景是针对野外，所以需要去除地面点（避免野草的干扰）。但是在城市道路上，这种缺乏地面约束，反而带来效果不一定好。但LINS本身的聚类这些都对算法的提升应该有实际帮助。

虽然lego也有scan-to-map，但是在退化场景，如果scan-to-scan 效果不好，对scan-to-map影响很明显； 关于地面约束，loam类方法，都有这类问题；你有没有什么好的解决办法呢？可以讨论一下。

对scan-to-map这里还是持有疑问的。LEGO-LOAM的优化算法好像是自己写的，你可以用ceres重构下，会发现scan-to-map这类算法几乎不受初值影响就可以得到很好的效果（优化的时候要在SE3上）。换句话说就是scan-to-scan可以直接去掉来降低计算开销了。关于地面约束这块：LEGO-LOAM本身是直接去掉地面的，所以肯定不好（至于为什么还能看到部分地面，应该是历史原因，受当时的地面算法约束）。对于地面约束的话，更多感觉应该是和采集设备相关，像你们做实验的小车，就可以直接采用类似零速修正，或者地面限高这样的方法来做。这类算法在LINS当中是有的，可以看看

scan-to-map这里，lego和loam是一致的；我说的受scan-to-scan影响，主要是在退化情况下，会影响； 至于lego的地面约束这块，lego是把地面作为surf特征，一起去约束的（跟loam一致）； 地面限高我可以理解，你说的零速修正，是什么意思？

主要针对IMU的，判断是否静止，重新初始化IMU。关于退化场景，我想多问下，你们遇到的退化场景多是什么样的？

[chengwei0427]

get√

退化场景，大多是类似长廊环境或者比较空旷的场景；

[chengwei0427]

紧耦合的效果会比松耦合效果要好（约束更多，同样对传感器要求也更高），这个也必将符合预期； lego_loam表现虽然让人诧异，但也符合其工作原理（scan-to-scan效果很差，这也是不如aloam的地方）；

LEGO-LOAM应该也有scan-to-map的部分，LINS就是对LEGO-LOAM的修改。LEGO-LOAM当时的研究背景是针对野外，所以需要去除地面点（避免野草的干扰）。但是在城市道路上，这种缺乏地面约束，反而带来效果不一定好。但LINS本身的聚类这些都对算法的提升应该有实际帮助。

虽然lego也有scan-to-map，但是在退化场景，如果scan-to-scan 效果不好，对scan-to-map影响很明显； 关于地面约束，loam类方法，都有这类问题；你有没有什么好的解决办法呢？可以讨论一下。

对scan-to-map这里还是持有疑问的。LEGO-LOAM的优化算法好像是自己写的，你可以用ceres重构下，会发现scan-to-map这类算法几乎不受初值影响就可以得到很好的效果（优化的时候要在SE3上）。换句话说就是scan-to-scan可以直接去掉来降低计算开销了。关于地面约束这块：LEGO-LOAM本身是直接去掉地面的，所以肯定不好（至于为什么还能看到部分地面，应该是历史原因，受当时的地面算法约束）。对于地面约束的话，更多感觉应该是和采集设备相关，像你们做实验的小车，就可以直接采用类似零速修正，或者地面限高这样的方法来做。这类算法在LINS当中是有的，可以看看

你好,最近有看lio_sam,有些疑惑,不知道你是什么看法? lio_sam和lego_loam的scan_to_map部分,除了特征提取的差异,其他几乎都是一致的. 其中lio_sam的scan_to_map部分,使用imu积分作为初值,优化后的位姿,又去约束imu预积分的bias.预积分部分并未直接参与scan_to_map的优化; 而lego_loam的scan_to_map是使用scan_to_scan作为初值; 但是两种算法,结果表现差异还是蛮大的. 感觉除了特征的差异，就是初值不同了。 你觉得,是什么原因呢?

[Gatsby23]

我觉得有以下几点：

1. Lego-LOAM去除地面实际上在校园这种城市场景中不太科学的，所以可能会导致z轴发散，所以后面LIO-SAM当中不再做去除地面的操作。 2.bias的约束很重要，我觉得如果约的好的话，IMU剔除bias后的测量可以直接用来累和位姿。 并且不清楚你LIO-SAM开了GNSS没，如果开了GNSS,效果应该更好

[chengwei0427]

我觉得有以下几点：

1. Lego-LOAM去除地面实际上在校园这种城市场景中不太科学的，所以可能会导致z轴发散，所以后面LIO-SAM当中不再做去除地面的操作。 2.bias的约束很重要，我觉得如果约的好的话，IMU剔除bias后的测量可以直接用来累和位姿。 并且不清楚你LIO-SAM开了GNSS没，如果开了GNSS,效果应该更好

1. 如果我没有记错，lego_loam的地面点是放到surf里，参与优化的，所以对地面的约束还是有的。lio_sam的特征提取，相比于lego，去掉了非地面点中的聚类及点数少的点簇移除，移除地面是为了保证靠近地面的点不参与corner特征提取。
2. bias约束，也是为了提高积分的精度，这样lio_sam中的初值会更加准确，但是imu是没有参与优化的，仅提供初值；（实际测试没有用gnss）。

所以，lio_sam和lego_loam的scan_to_map除了特征差别外，就是初值的差异了；这里，是特征的影响大，还是初值的影响更大呢？并且实际测试中，lego相比lio，迭代的次数更多，不收敛的情况也更多

[Gatsby23]

我觉得有以下几点：

1. Lego-LOAM去除地面实际上在校园这种城市场景中不太科学的，所以可能会导致z轴发散，所以后面LIO-SAM当中不再做去除地面的操作。 2.bias的约束很重要，我觉得如果约的好的话，IMU剔除bias后的测量可以直接用来累和位姿。 并且不清楚你LIO-SAM开了GNSS没，如果开了GNSS,效果应该更好

1. 如果我没有记错，lego_loam的地面点是放到surf里，参与优化的，所以对地面的约束还是有的。lio_sam的特征提取，相比于lego，去掉了非地面点中的聚类及点数少的点簇移除，移除地面是为了保证靠近地面的点不参与corner特征提取。
2. bias约束，也是为了提高积分的精度，这样lio_sam中的初值会更加准确，但是imu是没有参与优化的，仅提供初值；（实际测试没有用gnss）。

所以，lio_sam和lego_loam的scan_to_map除了特征差别外，就是初值的差异了；这里，是特征的影响大，还是初值的影响更大呢？并且实际测试中，lego相比lio，迭代的次数更多，不收敛的情况也更多

嗯嗯，多谢提醒，有些忘了Lego-LOAM。如果我没记错的话，LEGO-LOAM的优化是拆开的，所以可能欧拉角拆开来优化并不是一个好结果？我个人觉得特征保下限，初值冲上限。你可以把匹配点关系映射出来看看

[Gatsby23]

我觉得有以下几点：

1. Lego-LOAM去除地面实际上在校园这种城市场景中不太科学的，所以可能会导致z轴发散，所以后面LIO-SAM当中不再做去除地面的操作。 2.bias的约束很重要，我觉得如果约的好的话，IMU剔除bias后的测量可以直接用来累和位姿。 并且不清楚你LIO-SAM开了GNSS没，如果开了GNSS,效果应该更好

1. 如果我没有记错，lego_loam的地面点是放到surf里，参与优化的，所以对地面的约束还是有的。lio_sam的特征提取，相比于lego，去掉了非地面点中的聚类及点数少的点簇移除，移除地面是为了保证靠近地面的点不参与corner特征提取。
2. bias约束，也是为了提高积分的精度，这样lio_sam中的初值会更加准确，但是imu是没有参与优化的，仅提供初值；（实际测试没有用gnss）。

所以，lio_sam和lego_loam的scan_to_map除了特征差别外，就是初值的差异了；这里，是特征的影响大，还是初值的影响更大呢？并且实际测试中，lego相比lio，迭代的次数更多，不收敛的情况也更多

另一个问题：

1. 可以分享你的评测软件吗？
2. 推荐你们增加一组FAST-LIO2的分析，目前我这边的测试来看，FAST-LIO2效果还是最好的？
3. 为什么没有跟真值RTK的对比呢？

[chengwei0427]

1.没有评测软件，只是自己对比分析的。 2.fast_lio2也跑过，目前还没有做传感器的时钟同步，所以基于kf的方法，跑出来的效果并不理想； 3.对比地图就可以了，也没有购买rtk

[Gatsby23]

1.没有评测软件，只是自己对比分析的。 2.fast_lio2也跑过，目前还没有做传感器的时钟同步，所以基于kf的方法，跑出来的效果并不理想； 3.对比地图就可以了，也没有购买rtk

主要觉得你们的图画的都很漂亮，想问下你们是怎么画的？特别是IMU相关的。 我们这边也没有特别去做激光和IMU的硬同步，但是看FAST-LIO2得到结果还可以？你们的IMU是什么牌子？会不会跟IMU的性能有关？

[chengwei0427]

1.没有评测软件，只是自己对比分析的。 2.fast_lio2也跑过，目前还没有做传感器的时钟同步，所以基于kf的方法，跑出来的效果并不理想； 3.对比地图就可以了，也没有购买rtk

主要觉得你们的图画的都很漂亮，想问下你们是怎么画的？特别是IMU相关的。 我们这边也没有特别去做激光和IMU的硬同步，但是看FAST-LIO2得到结果还可以？你们的IMU是什么牌子？会不会跟IMU的性能有关？

我不是这个仓库的相关人员； 我用imu是消费级的，几百块，50hz，最高100hz；猜测应该会跟imu性能有关吧。 你们用的什么牌子的imu，性能如何？

[Gatsby23]

1.没有评测软件，只是自己对比分析的。 2.fast_lio2也跑过，目前还没有做传感器的时钟同步，所以基于kf的方法，跑出来的效果并不理想； 3.对比地图就可以了，也没有购买rtk

主要觉得你们的图画的都很漂亮，想问下你们是怎么画的？特别是IMU相关的。 我们这边也没有特别去做激光和IMU的硬同步，但是看FAST-LIO2得到结果还可以？你们的IMU是什么牌子？会不会跟IMU的性能有关？

我不是这个仓库的相关人员； 我用imu是消费级的，几百块，50hz，最高100hz；猜测应该会跟imu性能有关吧。 你们用的什么牌子的imu，性能如何？

哦哦，那难怪。我们用的是Mti，7000元左右。但是大疆本身激光雷达Avia，Horizon这些自带IMU应该价格也不高，但得到的效果也都很好

[chengwei0427]

这类自带的imu，都做了同步的，并且虽然价格跟单独的imu商品比，价格不算高，不过应该也不会太差；

[chengwei0427]

能介绍一下你们做真值的RTK设备吗？什么牌子，什么型号，大概什么价位？精度如何？

[Gatsby23]

能介绍一下你们做真值的RTK设备吗？什么牌子，什么型号，大概什么价位？精度如何？

我们有几套：一套是百万的测绘车那种。一套是Apollo小车上的星网宇达，差不多10w左右。还有就是卫星接收板来做的。

[chengwei0427]

能介绍一下你们做真值的RTK设备吗？什么牌子，什么型号，大概什么价位？精度如何？

我们有几套：一套是百万的测绘车那种。一套是Apollo小车上的星网宇达，差不多10w左右。还有就是卫星接收板来做的。

测绘的，太贵，不现实。 星网宇达，性能参数怎么样？ 卫星接收板来做的，是结合千寻+imu，自己做的组合惯导吗？

[Gatsby23]

能介绍一下你们做真值的RTK设备吗？什么牌子，什么型号，大概什么价位？精度如何？

我们有几套：一套是百万的测绘车那种。一套是Apollo小车上的星网宇达，差不多10w左右。还有就是卫星接收板来做的。

测绘的，太贵，不现实。 星网宇达，性能参数怎么样？ 卫星接收板来做的，是结合千寻+imu，自己做的组合惯导吗？

嗯嗯，是的，星网宇达我们是接到Apollo系统当中直接用的。卫星是自己来做组合导航。如果有需要，也欢迎你们来我们试验场做测试

[chengwei0427]

Hi， @Gatsby23

最近测试了一下LIO-Livox，觉得效果挺好的。所以就适配了一下传统旋转激光（主要是用lio-sam做的特征提取，激光里程计用LIO-Livox的去做，几乎不用怎么修改）。

用的ouster-64采集的数据，采集速度大概在0.7~1.2m/s（LIO-Livox声称支持50km/h以上的速度进行构图），但是运行一段时间就会出现轨迹漂移（激光10hz和imu数据100hz，都是ouster提供，所以已经是硬件时钟同步，imu-lidar的外参用的单位矩阵，实际上应该是有个小的平移变换的）。

现在卡在这里了，一直没找出问题在哪里？想听听你是什么看法？

可能的原因有：

①激光和imu的外参精度不够导致的。（因为没有标定，直接使用单位阵，而ouster里激光和imu应该也是接近单位阵的，这里的细微差距，对结果影响有多大，看了代码，主要是激光残差部分，如果本身接近单位阵，这里理论上应该影响也很小的）；

②LIO-Livox的紧耦合，受传感器精度影响，特别是imu精度；（ouster内置100hz的imu，并且bias很大，在LIO-Livox中，是两帧的滑窗紧耦合，imu预积分结果受imu精度影响到底有多大呢？）

PS：同样的bag，也测试了lio-sam，效果蛮好的，当然，lio-sam的紧耦合，比较特别。

期待你的回复！

[Gatsby23]

Hi， @Gatsby23

最近测试了一下LIO-Livox，觉得效果挺好的。所以就适配了一下传统旋转激光（主要是用lio-sam做的特征提取，激光里程计用LIO-Livox的去做，几乎不用怎么修改）。

用的ouster-64采集的数据，采集速度大概在0.7~1.2m/s（LIO-Livox声称支持50km/h以上的速度进行构图），但是运行一段时间就会出现轨迹漂移（激光10hz和imu数据100hz，都是ouster提供，所以已经是硬件时钟同步，imu-lidar的外参用的单位矩阵，实际上应该是有个小的平移变换的）。

现在卡在这里了，一直没找出问题在哪里？想听听你是什么看法？

可能的原因有：

①激光和imu的外参精度不够导致的。（因为没有标定，直接使用单位阵，而ouster里激光和imu应该也是接近单位阵的，这里的细微差距，对结果影响有多大，看了代码，主要是激光残差部分，如果本身接近单位阵，这里理论上应该影响也很小的）；

②LIO-Livox的紧耦合，受传感器精度影响，特别是imu精度；（ouster内置100hz的imu，并且bias很大，在LIO-Livox中，是两帧的滑窗紧耦合，imu预积分结果受imu精度影响到底有多大呢？）

PS：同样的bag，也测试了lio-sam，效果蛮好的，当然，lio-sam的紧耦合，比较特别。

期待你的回复！

Hi， @Gatsby23

最近测试了一下LIO-Livox，觉得效果挺好的。所以就适配了一下传统旋转激光（主要是用lio-sam做的特征提取，激光里程计用LIO-Livox的去做，几乎不用怎么修改）。

用的ouster-64采集的数据，采集速度大概在0.7~1.2m/s（LIO-Livox声称支持50km/h以上的速度进行构图），但是运行一段时间就会出现轨迹漂移（激光10hz和imu数据100hz，都是ouster提供，所以已经是硬件时钟同步，imu-lidar的外参用的单位矩阵，实际上应该是有个小的平移变换的）。

现在卡在这里了，一直没找出问题在哪里？想听听你是什么看法？

可能的原因有：

①激光和imu的外参精度不够导致的。（因为没有标定，直接使用单位阵，而ouster里激光和imu应该也是接近单位阵的，这里的细微差距，对结果影响有多大，看了代码，主要是激光残差部分，如果本身接近单位阵，这里理论上应该影响也很小的）；

②LIO-Livox的紧耦合，受传感器精度影响，特别是imu精度；（ouster内置100hz的imu，并且bias很大，在LIO-Livox中，是两帧的滑窗紧耦合，imu预积分结果受imu精度影响到底有多大呢？）

PS：同样的bag，也测试了lio-sam，效果蛮好的，当然，lio-sam的紧耦合，比较特别。

期待你的回复！

几个问题吧：

1. 是我看别人说的：Ouster的世界戳不一定做到了真正硬同步，这个还是要测试看一下，可以把数据采下来后离线观察下？不行的话可以考虑加个插值来平滑下，然后去畸变（不过这个我也是纸上谈兵，具体没操作过）。
2. 外参的问题我觉得你可以跑下FAST-LIO看下结果，看最后是不是收敛就基本上知道这个外参怎么样。我是直接跑FAST-LIO，发现收敛后的平移误差和我标定出来的差不多。
3. LIO-Livox有一个很重要的约束是NHC，用地面来约束角度，所以得看你们录制的数据是不是完全平行于地面？如果抖动比较大的话，也会造成比较大的影响。 最好能上最后的轨迹图来看看，如果说是跑了1KM以上飘的话，还是比较正常的

[chengwei0427]

1.问了一下ouster的技术人员，说是“时间起点都是FPGA去给打印的时间戳，肯定是一致的”；姑且认为是一致的吧。

2. 跑了一下fast_lio（三轴都尽量激励了），结果如下：

平移收敛了，旋转未收敛。不过fast-lio的变换矩阵，受初值影响。

3. NHC是什么？代码没有细看。

就是跑了一个400m的圆环，速度是0.7m/s。大概500s的一个bag，bag从0s开始播放，每次都在大致同一位置出现漂移；如果bag从漂移的位姿，往前推一段时间（50s）开始播放，漂移不会出现。

[chengwei0427]

如上为ouster产品手册里的数据。所以，直接用单位矩阵作为lidar和imu的变换矩阵，应该是有问题的。

你是什么方法标定的lidar和imu？

[Gatsby23]

1.问了一下ouster的技术人员，说是“时间起点都是FPGA去给打印的时间戳，肯定是一致的”；姑且认为是一致的吧。

2. 跑了一下fast_lio（三轴都尽量激励了），结果如下：

平移收敛了，旋转未收敛。不过fast-lio的变换矩阵，受初值影响。 3. NHC是什么？代码没有细看。

就是跑了一个400m的圆环，速度是0.7m/s。大概500s的一个bag，bag从0s开始播放，每次都在大致同一位置出现漂移；如果bag从漂移的位姿，往前推一段时间（50s）开始播放，漂移不会出现。

我们有动捕，直接将动捕放在上面，然后运动一段时间后，直接用轨迹对齐，就能得到。 之前说错了，应该不算NHC，是零速修正，就是它直接把Pitch和Roll给置零了，但地球不是平的，所以不一定是0，可能有误。

不过我觉得看你的轨迹大小和时长，我更倾向于相信的是过程中匹配出现错误比较多，把匹配那个阈值调一下，可能效果更好。 你们的数据包可以上传吗？Fast-LIO效果不好的情况还是比较少见的，我想跑下看看

[Gatsby23]

1.问了一下ouster的技术人员，说是“时间起点都是FPGA去给打印的时间戳，肯定是一致的”；姑且认为是一致的吧。

2. 跑了一下fast_lio（三轴都尽量激励了），结果如下：

平移收敛了，旋转未收敛。不过fast-lio的变换矩阵，受初值影响。 3. NHC是什么？代码没有细看。

就是跑了一个400m的圆环，速度是0.7m/s。大概500s的一个bag，bag从0s开始播放，每次都在大致同一位置出现漂移；如果bag从漂移的位姿，往前推一段时间（50s）开始播放，漂移不会出现。

这个评测软件可以给我参考下吗？感觉画的还挺漂亮的

[chengwei0427]

1. fast_lio跑的效果很好；跑LIO-Livox会有问题；而且LIO-Livox不用imu的情况下，效果蛮好的，结合imu的紧耦合才会出问题。
2. 你说的这个0速矫正，是fast-lio或者LIO-Livox里的吗？我好想没有看到这块，方便指出位置吗？
3. 上面的画图软件，用的是fast-lio里面的，在代码里的log文件夹中plot.py.

[Gatsby23]

LIO-Livox里，这个在LINS里面也有。如果结合IMU紧耦合出问题，我个人觉得还是有可能是IMU预测出来的初值出问题了，包括可能跟场景有关系。比方说像LIO-SAM用在室内的情况下，效果基本上就会崩。因为都是纯几何特征，所以匹配容易报错。如果说是反向过50s再来推算不会有问题的话，我建议把bias打印出来看看，可能之前的运动并没有很好的约束bias，长时间到那里的时候已经漂移了。 LINS本身的精度的确应该比FAST-LIO差的，推荐你们还是用FAST-LIO

[chengwei0427]

fast-lio效果确实蛮好的。最近在研究LIO-Livox，这个方法跟lili-om有些类似； 通过bias怎么分析呢？

[Gatsby23]

fast-lio效果确实蛮好的。最近在研究LIO-Livox，这个方法跟lili-om有些类似； 通过bias怎么分析呢？

你说的应该是https://github.com/Livox-SDK/LIO-Livox这个库吗？不好意思，我之前理解错了，一直以为是另一个。我之前见过大疆同学，如果当时没理解错的话，这里LIO-Livox就是依据FAST-LIO2来改的，再加上些Corner Case的修复。你可以对比下两者算法。我记得没错的话，LIO-Livox还是Filter-based方法，只是前端部分做了改动，类似于将LEGO-LOAM前端放进去，做一个欧式聚类来做分割，去动态物体。你可以把那个关了再试试。 你都提到了如果不用IMU，效果还可以，那代表的意思应该是激光的匹配在匀速运动模型下应该没什么问题，但是当有IMU时候出问题，就代表了IMU提供的预测值错了，导致后面的匹配一错再错。这里的IMU预测值应该受影响最大的就是bias。

[chengwei0427]

LIO-Livox是基于优化的方法，不是基于滤波的方法，跟lili-om有些相似。你可能是看的太多，又搞混了。

这里我是把LIO-Livox的特征提取部分，参考lio-sam的特征提取，修改为支持spinning激光；优化部分几乎没改，用的还是LIO-Livox的poseEstimation，所以大概率不是代码问题，而是我参数的问题，特别是lidar-imu参数。

比较诡异的是，如果我按照ouster内部的lidar-imu参数去设置fast-lio里的初值，稍微一动就会漂移；如果设置lidar-imu里旋转用单位阵，平移给一个参数，效果反而还不错。

[Gatsby23]

LIO-Livox是基于优化的方法，不是基于滤波的方法，跟lili-om有些相似。你可能是看的太多，又搞混了。

这里我是把LIO-Livox的特征提取部分，参考lio-sam的特征提取，修改为支持spinning激光；优化部分几乎没改，用的还是LIO-Livox的poseEstimation，所以大概率不是代码问题，而是我参数的问题，特别是lidar-imu参数。

比较诡异的是，如果我按照ouster内部的lidar-imu参数去设置fast-lio里的初值，稍微一动就会漂移；如果设置lidar-imu里旋转用单位阵，平移给一个参数，效果反而还不错。

不是，我是ICRA上跟大疆的同学交流时候，他们跟我说的。我当时没有自己去深挖过，可能他们发现还是优化会更好一点。第二个外参的问题我也遇到过，不过我倾向于是自己写的代码当中出bug还没找到。但我在写我的算法时候针对外参是这么操作的，你可以试试看： 先用动捕系统估计出来IMU和Lidar的外参。然后录制一段数据，给外参单位阵的情况来跑FAST-LIO。因为FAST-LIO当中对外参也有估计，所以可以将外参结果打印出来，我的结果显示外参结果基本和动捕显示相吻合，所以觉得没问题。

我对IMU和其他传感器融合的理解如下：IMU永远是主线，用简单公式来递推。其余传感器来进行优化IMU的bias。 激光和IMU的融合麻烦之处是在于激光的匹配解算过程中对初值的依赖，而这部分初值又是由IMU来提供（视觉的匹配则是完全独立相关）。基于你之前说的单独使用激光效果好，加上IMU效果不行，我的建议还是把Lidar的匹配打印出来看下。IMU的bias也画成三轴图，看看有没有收敛。

[chengwei0427]

问题找到了，是我特征提取后，发布的数据的时间戳有问题。程序终于可以顺利的跑起来了。开心。

[Gatsby23]

问题找到了，是我特征提取后，发布的数据的时间戳有问题。程序终于可以顺利的跑起来了。开心。

恭喜，恭喜，很棒