eskf-gps-imu-fusion icon indicating copy to clipboard operation
eskf-gps-imu-fusion copied to clipboard

使用误差状态卡尔曼滤波器融合GPS和IMU,实现更高精度的定位

Results 14 eskf-gps-imu-fusion issues
Sort by recently updated
recently updated
newest added

首先在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. 精确速度微分建模”下的模型。

当前主分支eskf.cpp第12行,g_初始化为(0,0,-9.78),是不是在NED系下应该初始化为正的9.78,ENU下才是-9.78吧?第221、222行程序里用的是减去g_,反而结果是对的:)

eskf.cpp(当前主分支150行),计算R_nm_nm_1时,用angle_axisd对应的旋转矩阵的transpose,210行在使用R_nm_nm_1时,又transpose了一下,这是误操作?还是姿态解算方程使然?

eskf.cpp(当前主分支192行),第一分量用了Rn,第二分量用了Rm,这两个曲率半径是不是写反了?