Support magnetometer compensation based on throttle / current

[RomanBapst]

Sometimes design constraints prevent magnetometers to be placed further away on the vehicle and there is a clear correlation between vehicle throttle demand or measured vehicle current and mag hard iron effects.
I would like to implement a simple compensation (hard iron effect).
The main question is where to implement this and for which magnetometers:

Idea:

• implement only for mag0 and this is the one that is normally used?
• add parameter which defines the type of compensation (none, throttle based, current based)
• add 3 parameters which define the linear relationship between throttle/current and the offset on each axis

[tstastny]

@AdyashaDash did quite some work on this type of mapping during her Masters Thesis at ETH, maybe you could chat with her on how to implement? ;)

[dagar]

Now that I think of it, won't this need to handled per mag, or at least a known set? Thinking of internal vs external.

[RomanBapst]

@dagar You could do that. The most important thing is definitely to make sure that you only apply the correction to the mag for which the calibration is meant.

[RomanBapst]

@tstastny Thanks for the info!
@AdyashaDash I'd love to hear your input on this one :)

[AdyashaDash]

@tstastny thanks for drawing my attention! I wanted to take a look at the latest master before summarizing my thoughts. Some comments from my side @RomanBapst:

• Regd no. of parameters: ultimately a parameter per each axis (so 3 per mag) is probably the most useful and flexible, so can recommend this approach. For our specific application, I was more focused on getting a stable mag norm, so having a single offset per mag worked in that scenario. For the general case, I assume it is more important to apply correction to the individual axes for a more accurate heading measurement ultimately, so it would make sense to have a compensation parameter per axis.
• In terms of code structure, would make sense to reuse the structure of temperature_compensation (perhaps even subclass temperature and hard iron compensation from a compensation base class?). Conceptually as well, I think it makes sense to apply the two compensations at the level of sensors module, rather than the driver itself.
• Regd whether compensation should be done for primary mag or all mags: from my observation, it was quite difficult to get the compensation coefficients for internal mags on the pixracer (mag1 and mag2) because of heavy noise, so I ultimately only implemented it for the external mag. On the other hand, do not see a downside to giving users the option to compensate any mag that they want to (except an increase in number of parameters, of course). The implementation itself should also be fairly straightforward too (just checking if the compensation parameter is non-zero for the mag that is currently being used).
• Regd adding a parameter that defines which type of compensation is being applied (current or throttle): I think it's probably useful to have this parameter. Then you can listen to the corresponding topic/measurement based on the parameter, and pass it to the function/method that applies the actual compensation (keeping the implementation of the compensation itself more general and abstract).
• Out of curiosity, are you planning on calculating the coefficients for current compensation online too, or is it assumed that the user has the model coefficients already? I have drafted my observations assuming the user already has the coefficients.

Let me know if this helps already, @RomanBapst, otherwise happy to have a quick chat over coffee to flesh out the details. Would be glad to help out with reviewing too in case you go ahead with the implementation!

[RomanBapst]

@AdyashaDash Thanks for you input!

ultimately a parameter per each axis (so 3 per mag) is probably the most useful and flexible, so can recommend this approach

Yes, my plan was to implement this as a first step.
I think that there are systems where it can be beneficial to have a per motor calibration instead of only taking into the total thrust or current. Image you have the magnetometer located close to the power cable going to a specific motor controller. In that case probably the signal going to that motor controller would best describe the interference seen on the mag.
But let's start with the more simple approach first and see what we get.

it was quite difficult to get the compensation coefficients for internal mags on the pixracer (mag1 and mag2) because of heavy noise, so I ultimately only implemented it for the external mag

Yeah, I can confirm this observation. However, if the mean of the signal still reflects a somewhat accurate signal then you could maybe still get away with it, at least for the sake of navigation. It would maybe require the noise param of the ekf to be adjusted. And probably you would not be able to use this heading for e.g. accurate gimbal pointing but maybe for navigation it would be ok.
If we start by implementing this compensation for mag0 then we can just not connect an external mag and try it with the internal one. Let's see how it goes :)

Out of curiosity, are you planning on calculating the coefficients for current compensation online too, or is it assumed that the user has the model coefficients already? I have drafted my observations assuming the user already has the coefficients

For now I was not planning to calculate the coefficients online. The only easy way I can image at the moment how this could be done is strap the drone down and perform a calibration process where you increase throttle from 0 to 100% and capture the data. Then you could perform a linear fit and directly apply the params. I will not work on this for now.

Let me know if this helps already, @RomanBapst, otherwise happy to have a quick chat over coffee to flesh out the details. Would be glad to help out with reviewing too in case you go ahead with the implementation!

That would be awesome!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[RomanBapst]

@Stale get lost

[dagar]

How's this going?

[ryanjAA]

I’m pretty interested in this too.

Would this be similar in practice to what compassmot does on Ardupilot?

[RomanBapst]

@ryanjAA I can give it a rebase if you can test it.

Would this be similar in practice to what compassmot does on Ardupilot?

I'm not familiar with what they do but I suppose it's something similar. You could go one level fancier and make the model depend on the current of each ESC (or use the pwm output going to the ESC).

[dMarragonis]

@RomanBapst We plan to use this kind of compensation for our small 23cm frame which suffers of magnetic disturbances.
We use uavcan escs with current measurement on each motor. so we could base our correction on the current rather than on the PWM, I think this approach will allow a better precision.
if you have something to share with us we could test it with pleasure.

[RomanBapst]

@dMarragonis Glad to hear you are interested in this.
I've actually made a pull request which implements mag compensation based on throttle here
I think it would not be hard to use total current from the ESCs instead.
Do you want to give that a shot?

[RomanBapst]

@dMarragonis It would be great if you could share a log file which contains data that can be used to proof the effectiveness of this approach. You should strap the vehicle down somewhere, arm, and apply combinations of thrust, roll, pitch and yaw. Since we know the initial magnetic field vector before there is any current flowing we can easily verify how well the per motor current model performs.

[dMarragonis]

Yes sure, i think i can do that on the next week, i travelling this week.

[dMarragonis]

I think it would not be hard to use total current from the ESCs
instead

I did not think to use the total current of the escs but the independent current of each escs

[RomanBapst]

@dMarragonis Sorry, I meant individual current.

[dMarragonis]

Ok 👍

[bresch]

done (#12329 (comment))