andreabelles / Time-Synch

0 stars 0 forks source link

EKf tested with real data #12

Open andreabelles opened 3 years ago

andreabelles commented 3 years ago

These figures have been obtained with the code from the branch feature/testEKFRealData (commit ID: 28fd0a6c9c52bb72ff834e46b351a64874b40759).

posRef_posIMU_posGPS truePos_vs_estimatedPos IMU_only_errors EKF_estimatedPos_errors EKF_estimatedPos_errors_3sigmaCovEKF EKF_stateVector_posErrors EKF_stateVector_posErrors_accumulated

The figure named "EKF state vector accumulated errors" is obtained from adding at each iteration of the KF the error state vector to the previous value of the state vector. We're not sure if this is the plot you requested because we also have run the KF removing the initialization of the error state vector to zero; however, the EKF estimation of the position accumulating the errors at each iteration did not make sense for us.

jtec commented 3 years ago

Hi guys,

so what I suggested was to check whether in open loop (i.e. the INS integrates away, and the EKF estimates the INS error) the EKF manages to properly track the INS error, at least as long as the error stays small. To ensure that the error stays small over a longer time, simply initialize the INS at the true state and remove biases, leaving only a random walk on heading and velocity. Maybe plot the INS error and the estimated error in the same axes?

jtec commented 3 years ago

Also, make sure to plot the GNSS position in the same axes as the EKF position estimate to check whether actually any filtering takes place, i.e. the EKF estimate is smoother than the GNSS position.

You can also look at the INS error before EKF updates, which should become smaller over time as the EKF converges, reducing the effect of the INS integrating in the "wrong direction" and integrating bias errors. The EKF can sometimes hide serious bugs in both the INS mechanization and the estimation part by simply "correcting away" INS errors at each update.