Happy new year, everyone!
I went through EKF3, traced the location update and populated the inner workings in the previous, aggregate post.
Please correct me if I have misunderstood any part of it.
The inner position state and output are expressed in NED and in meters, in float32. This means that there is plenty of resolution to accept RTK accuracy, being a bit conservative to account for flat-Earth modeling.
However, the GPS location is read from the GPS driver as the well-known int32_t degree*10^7 representation which kills all resolution below 11cm.
From my point of view, if somehow the GPS drivers could offer higher resolution, the EKF could happily oblige and produce better results.
One more thing: During the measurement update, the used position accuracy is set to:
float alpha = constrain_float(0.0002f * (lastTimeGpsReceived_ms - secondLastGpsTime_ms),0.0f,1.0f);
[...]
gpsPosAccuracy *= (1.0f - alpha);
float gpsPosAccRaw;
if (!gps.horizontal_accuracy(gpsPosAccRaw)) {
gpsPosAccuracy = 0.0f;
} else {
gpsPosAccuracy = MAX(gpsPosAccuracy,gpsPosAccRaw);
gpsPosAccuracy = MIN(gpsPosAccuracy,100.0f);
}
meaning that, depending on the size of gpsPosAccuracy its value may overshadow a better RTK accuracy.
On the other hand, if gpsPosAccuracy is actually smaller than the actual RTK accuracy, then the truncated RTK values, there is a mismatch between the final measurement uncertainty gpsPosAccuracy and the actual resolution of the GPS position.
This may result in an underperforming filter.
Of course, all of the above is probably already known to the EKF developers, but it was a good exercise for me and a piece of documentation I could not find elsewhere.
