-
Notifications
You must be signed in to change notification settings - Fork 13.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ekf2-mag_auto: always use mag 3D after takeoff #22752
Conversation
Update EKF2_MAG_ACCLIM description? PX4-Autopilot/src/modules/ekf2/ekf2_params.c Lines 505 to 516 in c697c03
|
@bresch I tested this PR with the deadreckoning scenario and it seems to work fine, I was not able to introduce the position jumps anymore, and in general the dead-reckoning performance is much better. |
Great, thanks. I just need to investigate the optical flow unit test failure and we should be good to go. |
c697c03
to
8c7d684
Compare
8c7d684
to
7fe2e68
Compare
@@ -45,13 +45,12 @@ void Ekf::controlMag3DFusion(const magSample &mag_sample, const bool common_star | |||
|
|||
resetEstimatorAidStatus(aid_src); | |||
|
|||
const bool wmm_updated = (_wmm_gps_time_last_set > aid_src.time_last_fuse); | |||
const bool wmm_updated = (_wmm_gps_time_last_set >= aid_src.time_last_fuse); // WMM update can occur on the last epoch, just after mag fusion |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if we even need this given the updated WMM is immediately used in by limitDeclination in fuseMag(). Something to review later.
Solved Problem
The mag heading fusion might be more robust in some cases, but doesn't consider the mag bias uncertainty and is affecting the heading quite strongly (because it is a direct heading observation, without bias). To prevent this, we're currently allowing it to fuse a mag sample only if the heading uncertainty is becoming too large.
This protection has other sides effects as it under-constrains the heading when the mag bias have been correctly estimated. This degrades dead-reckoning performance and creates large position corrections every time a new mag sample is fused.
Solution
Mag 3D fusion is the ideal way of fusing magnetometer measurements in an EKF as the original measurement is fused (instead of preprocessing it using the states -> correlation with the filter). Since the mag bias uncertainty is initially large, the heading isn't over-constrained at takeoff and an incorrect initial heading can easily be corrected through GNSS fusion or angular motions.
As a first step, this PR changes the mag "auto" logic to switch into mag 3D fusion right after the "in flight mag reset" occurring at 1.5m after takeoff. If no issue is observed, I would like to completely remove the mag heading fusion feature as this would greatly simplify the code and remove complicated code paths.
Changelog Entry
For release notes:
Alternatives
I tried to compute the actual mag heading uncertainty using the quaternion and mag bias covariance, but the result is still under-estimated.
Test coverage
SITL tests:
Initial heading error of 90 degrees due to wrong mag bias calibration (0.2Gs on x and y). Heading and mag biases are quickly corrected.
Incorrect mag data plumbing (mag_x = -mag_y, mag_z = mag_z - mag_x); tested with and without GNSS fusion. In this case, the mag fusion is easily rejected; the attitude is not affected and the heading is correct when fusion is active.