关于eskf公式论文与代码不一致的问题, 求捞

[iwander-all]

有一个疑惑我困扰了很久， 就是在lio部分状态量的增量是solution = K meas_vec + vec - K Hsub vec.block<12, 1>(0, 0)(1) (即dx = K H^T (-Z) - (I-G)(state_cur-state_last))， 但是论文fast-lio公式(18)(或fast-lio2公式(14))和代码似乎是正负号相反的， 如果按照论文，应该是solution =- K meas_vec - vec + K Hsub vec.block<12, 1>(0, 0)(2)， 在阅读fast-livo和r3live的代码，发现它们的lio部分都是与(1)一致，而vio部分与(2)一致，请问作者如何理解

[xuankuzcr]

Hello，vio部分和（2）不太一样，其中第一项是负号，第二项应该是正号，最后一项应该是负号。至于和（1）为什么第一项符号相反，可以看下面这行代码，lio部分的meas_vec用的是负值，但vio用的是正值。 https://github.com/hku-mars/FAST-LIVO/blob/a8918c23dc4dba7d98fa723a9fa0fc2cbdf4d977/src/laserMapping.cpp#L1627

[iwander-all]

谢谢大佬回复得这么快。 我大概明白了，我上面写的公式(2)是r3live的代码。 我的理解是， 第一项的正负号取决于残差的正负号， 第二项和第三项的正负号取决于vec是state_propagat - state(FAST-LIVO,R3LIVE的LIO)还是 state-state_propagat (R3LIVE的VIO)。 我刚刚改了一下LIO的代码基本上能验证这个思路。

另外有一个好奇，就是请问为什么您和R3LIVE的作者都不约而同的选择了手写esikf而不是沿用fastlio2惊为人天的ikfom，是因为ikfom不方便加入vio部分的优化吗？ 我在您在别的issue里说手写esikf和ikfom是一样的，但是根据我的实验，手写esikf性能是要差于ikfom的，在我的数据集有一个隧道的数据，其它条件一样，ikfom能穿过去，而手写esikf会飘掉。ikfom中update_iterated_dyn_share_modified()的代码量比手写esikf复杂得多，虽然没有看懂，但是一个朴素的想法就是ikfom会比手写的esikf更强，请问一下原作者对这俩怎么理解的。

感谢！！

[xuankuzcr]

第一个问题不用ikfom的原因是，当时这几个工作是并行的，当时我们还是用的内测的fast-lio，那时还是用的手写ikfom。对于我们LVI融合的工作，scope不在于LIO是什么样，而是在于怎么融合的，融合完是否有正优化。 第二个问题 “ 在我的数据集有一个隧道的数据，其它条件一样，ikfom能穿过去，而手写esikf会飘掉。” 我觉得这个实验现象还不足以说明谁更好，不知道你是否有控制其他噪音参数完全一样，而且手写ekf的lio版本是否比较落后，这些都是变量。但二者数学上是等价的。

[iwander-all]

再次醍醐灌顶，豁然开朗，如慕春风！！