Skip to content
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

Merged
merged 4 commits into from
Feb 27, 2024
Merged

Conversation

bresch
Copy link
Member

@bresch bresch commented Feb 14, 2024

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:

Motion is no longer required to start mag 3D fusion; it will now automatically start after the in-air mag reset and stay ON.
New parameter: removed `EKF2_MAG_YAWLIM`
Documentation: No

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.
    Screenshot from 2024-02-14 16-57-38

  • 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.

@bresch bresch added the EKF2 label Feb 14, 2024
@bresch bresch requested a review from dagar February 14, 2024 16:02
@dagar
Copy link
Member

dagar commented Feb 14, 2024

Update EKF2_MAG_ACCLIM description?

/**
* Horizontal acceleration threshold used by automatic selection of magnetometer fusion method.
*
* This parameter is used when the magnetometer fusion method is set automatically (EKF2_MAG_TYPE = 0). If the filtered horizontal acceleration is greater than this parameter value, then the EKF will use 3-axis magnetometer fusion.
*
* @group EKF2
* @min 0.0
* @max 5.0
* @unit m/s^2
* @decimal 2
*/
PARAM_DEFINE_FLOAT(EKF2_MAG_ACCLIM, 0.5f);

@RomanBapst
Copy link
Contributor

@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.

@bresch
Copy link
Member Author

bresch commented Feb 16, 2024

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.

@@ -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
Copy link
Member

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.

@dagar dagar merged commit 28db3e1 into main Feb 27, 2024
91 of 92 checks passed
@dagar dagar deleted the pr-ekf-continuous-mag-3d branch February 27, 2024 17:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: ✅ Done
Development

Successfully merging this pull request may close these issues.

None yet

3 participants