Multiple magnetometer inconsistency check needs to be revised

[MaEtUgR]

Describe the bug Everyone with an external mag runs into the vehicle not arming for some small mag inconsistency. We should change the check to look at the vector direction and not at the amplitude of each vector component.

[dagar]

The other problem with these checks is that users don't have a clue what to do. If its important enough to block arming we also need to provide next steps.

For debugging these issues I'd also like to start logging all sensor data (minimal rate), which we'll be able to afford to do once https://github.com/PX4/Firmware/pull/12123 is merged.

[MaEtUgR]

That's all true but I was refering to the actual check itself. It can be all fine from what you expect but still fail...

[dagar]

That's all true but I was refering to the actual check itself. It can be all fine from what you expect but still fail...

Completely agree. I'd just like to consider ways to make the feedback useful while working through the underlying problem.

[priseborough]

Yes, the length of the vector difference between the primary and each additional sensor is calculated and the maximum returned. As @MaEtUgR suggests we could calculate the horizontal projection of the field.

However if the vertical component is ignored by the check and has a significant error, then this can cause problems when the vehicle changes roll/pitch orientation. I haven't worked out the geometry, but it should be possible to return the maximum angular difference of the horizontal projection for a specified range of roll/pitch or tilt magnitude and tilt direction.

[LorenzMeier]

Thanks! I think it would be fairly important to get this addressed rather quickly as it is unnerving users, very often in conditions that are totally fine to fly with.

[priseborough]

@dagar From previous experience working on consumer products, typical user facing messaging would be:

Step 1) We tell the user "Magnetic interference detected, pick up vehicle and move to a new location". If the act of picking up clears the error, then the difference was caused by a localised anomaly (eg steel reinforcement bars in floor, etc) and the error will disappear when the vehicle takes off. In this instance the check can be latched as a pass until the next power cycle.

Step 2) If picking up the vehicle doesn't clear the fault condition, then the user is asked to calibrate the magnetometer.

I have started work on the changes to the inconsistency check algorithm.

[priseborough]

Here's the prototype under test. https://github.com/priseborough/Firmware/tree/pr-magPreFltCheck

[MaEtUgR]

@priseborough I didn't think about neglecting the vertical component, I thought about comparing the angle between the 3D vector directions instead of component differences. The logic in your test branch looks rather complicated to me for comparing directions or am I missing the point?

[MaEtUgR]

I started scetching up a simpler check here: https://github.com/PX4/Firmware/compare/mag-consistency-check More to come tomorrow.

[Pedro-Roque]

@MaEtUgR why not use the quaternion distance among all the quaternions?

Check equation 27: https://link.springer.com/content/pdf/10.1007%2Fs10851-009-0161-2.pdf

[MaEtUgR]

@Pedro-Roque I can't read the paper without paying 35$. I guess you mean something like https://math.stackexchange.com/a/90098. But we are comparing the raw magnetometer 3D vectors and not quaternions. Do you suggest to use a computationally more efficient way to calculate the quaternion angle? I could actually implement that in the matrix library.

[Pedro-Roque]

@MaEtUgR if we have the 3D vectors, we can define attitude quaternions for those. Once you have that, I think have the quaternion distance is more correct and extendable across whatever range of measurements we get. And yes, I think it's more efficient, computationally - not sure though about converting to quaternion, but that should not be heavy either