zm0612
commented
5 months ago hello，
-
关于第一个问题，旋转矩阵不正交的问题。也确实有一些人会旋转对其进行归一化，这个我没有进行过细致的测试对比，我只能根据我目前的使用经验，给出一些经验性的建议。Eigen库数据类型是支持模板定义的，我在代码中都是使用的double类型，当然如果是数值计算的场景，我也建议你都是用double类型。目前的计算机中double类型几乎都是64位存储的，它的有效数字是15位，所以通常转置和求逆是可能带来一些差异的，具体差异有多少，我未进行过比较，但是我大胆的猜测，他们不会有明显的差别，甚至不会在最终的实际物理层面给数值结果带来影响。我们在工业应用中，即使进行厘米级别的位姿求解，也未发现，Eigen的数据截断给实际应用带来任何影响。
-
关于第二个问题，我在写eskf的代码时，IMU纯积分只是作为我IMU解算是否正确的一个验证。所以我并未对IMU的纯积分做特别细致的建模。你提到的用到了经纬度的问题，我会记录下来，找时间看一下。如果你需要对IMU的纯积分进行细致的研究的话，需要结合一些别的材料，我这里对纯积分的使用偏向于简单化了，只适用于一般精度的IMU。
-
第三个问题，关于比力方程简化导致的精度损失，确实是会存在的。因为我假设的是，大家使用的是消费级别的IMU，多数情况下消费级别的IMU，自身的噪声已经大过了地球自转引起的一些加速度，所以我这里做了简化处理。对于低精度的IMU，实际更细致的建模对精度没有明显提升。另外我使用的是仿真的数据，你可以尝试仿真高精度的IMU数据，然后在我的基础之上，尝试使用更复杂的惯性比力方程等进行速度和位移的更新，最好也能分享一些你的对比结果，因为我没有进行这一步对比，也方便我学习，哈哈。
zaixialipu
lyfadvance
首先在eskf.cpp中updateOdomEstimate中，是由于Eigen库中的数据的截断误差，导致 在eskf.cpp中的R_nm_nm_1不完全正交，在这里我做了较多的尝试，使用svd分解等方法都不能得到一个较好的结果，因此我直接使用了inverse()，虽然运算速度上有损失，但是毕竟效果会更好一点。 第二个部分是eskf.cpp中关于角速度更新的部分，在ComputerNavigationFrameAngularVelocity中，对于纬度和高度直接使用了卫星的真值，这里当然是可以的，但是对于纯积分来说，没有GPS，因此最好加一个if的判断，没有GPS，直接使用上一时刻的imu的数据。（目前正在修改中） 第三个部分是在eskf.cpp中ComputePosition中，关于惯性比力方程，完整的公式需要扣除地球自转引起的加速度与对地向心加速度，但是在unbias_accel_0与unbias_accel_1求解的过程中，均采用了简化模型，这里可能有精度损失。我的公式和您的一样，就是您的博客“https://blog.csdn.net/u011341856/article/details/132948044#comments_31875260”中“2.速度更新a. 精确速度微分建模”下的模型。