The above is a plot of the 3 components of estimated magnetometer offsets computed during spin tests at 78 RPM of an improved method for estimating and removing magnetometer offsets. There is a report available with theory and implementation. The method will work equally well for fixed wing aircraft, multicopters, and helicopters. It makes no assumptions about the dynamics of the airframe.

The idea for the new method came to me while I was recently working on a method to detect and compensate for magnetometer misalignment errors. I realized the method that I had been using for offset compensation was sensitive to misalignment between the magnetometer axes and the gyro axes, so I thought about ways to compute offsets that would ignore misalignment. I found a good way to do it that turned out to be more accurate and easier to implement than the method that I was using.

I also figured out a slick way to detect and adjust for magnetometer misalignment, I will be publishing a report in a few days on that subject. The method will compensate in flight for any amount of magnetometer misalignment, including a 180 degree yaw mounting error. In other words, the algorithm can figure out that you mounted your magnetometer backwards and apply a rotation matrix to the magnetometer vectors to put them into the correct reference frame. Stay tuned....

[Here is the technique for doing inflight magnetometer alignment. - WJP]

Best regards,

Bill Premerlani

 

Views: 2844

Tags: UDB, magnetometer, offsets

Comment by Bot Thoughts on October 14, 2011 at 11:43pm

Wow, nice! Eager to see if I can implement any of this for my ground vehicle.

Comment by ionut on October 15, 2011 at 12:04am

Rana you can get a picture of him and start worship him.


Developer
Comment by Mark Colwell on October 15, 2011 at 6:14am

Sweet, now we can just mount mag where EMF is lowest and not worry about orientation !


T3
Comment by William Premerlani on October 15, 2011 at 6:44am

Hi Mark,

The amount of time that it takes for the auto-alignment algorithm to converge is proportional to the amount of misalignment. So the best thing to do is to orient the magnetometer at least approximately, within 10 degrees would be a good idea.

Another approach if you really want to be able to orient the magnetometer any way at all would be to rotate the aircraft several times around each axis with the IMU and magnetometer mounted in place, and then record the alignment information reported by the algorithm, and use it as the starting point on subsequent initializations.

Also keep in mind that right now the algorithm is running only in MatrixPilot. I don't know if and when the ArduPilot team will want to incorporate it in ArduPilot.

Best regards,

Bill

Comment by Andrew Zaborowski on April 28, 2012 at 6:33pm

WOW, this is an incredibly simple formula, much less room for programmer error and much easier on my poor flight computer 8bit chip.  It's simple enough that I implemented it in the last 1h in my firmware and it works!

I used a 1.0 gain.  My main issue was when I close the top cover on my airplane model, which is secured with three strong magnets, so independently of what magnetometer constant offset I use, it'll be wrong either with the hatch open or closed.  Now it converges after maybe 5s of moving the airplane around after closing the cover.  I stop integrating the offset values once the (max measured field magnitude / min magnitude) is > 0.95 in a period where the gyro reports at least 60deg pitch and 60deg yaw variation.  If at any later point the magnitude becomes > 1.05 or < 0.95 of the calibration value, the autopilot goes back to integration mode and temporarily stops using the magnetometer input for the AHRS quaternion correction.

Also this method may be very useful on devices without a gyro.  I have a feeling that the previous method you presented (2010) converged a little quicker by using the gyro input.  Both are incredibly clever ideas though, which should probably be taught in robotics classes.

Out of curiosity on the horizontal axis in your graph is this the revolutions count, time in seconds, or the number of integration steps?

Also in the implementation example in the PDF you seem to be saving "magFieldBodyPrevious" and "magFieldBodyMagnitudePrevious" between loop iterations.  But the value of that vector is R * b_0 + R^T  * b_E. The problem I see is that b_0 changes between loop iterations.  Would it not be more correct to save the raw measurement between iterations, and subtract only the current b_0 from b_B1 and b_B2?  This is what I did in my case.

Comment by Andrew Zaborowski on April 28, 2012 at 6:41pm

b_0 * R^T * b_E is what I meant (i.e. offset estimation + raw value from magnetometer)


T3
Comment by William Premerlani on April 29, 2012 at 5:30pm

Hi Andrew Z,

I am very pleased to hear that this method works for you, and that you were able to implement it quickly. I don't know if either method is taught in robotics classes, but this latest method is so accurate and elegant, that I think sooner or later it will catch on widely. It was recently incorporated into ArduPilot.

The previous method, which converged at about the same rate as this one, was more sensitive to magnetometer misalignment, and tended to cross couple with the inflight magnetometer alignment algorithm. This algorithm has less cross coupling.

On my graph, the horizontal axis is the number of magnetometer readings, at 4 readings per second.

Regarding your last question, yes, what you are suggesting would be "more correct", but it would not be any more or less accurate then the implementation example. Both methods will converge to the same result. That is because as the algorithm converges, the values of b_0 stop changing, so both methods converge to the same value.

There are several variations on the basic idea that would work just as well as long as they converge toward the correct value.

The reason that I implemented the algorithm the way that I did was for convenience: I subtract b_0 in the magnetometer driver, so that its removal is transparent to all the computations that depend on the magnetic measurement.

Best regards,

Bill Premerlani

Comment by BertzillAvionics on February 28, 2014 at 2:00am

Hi Gents,

As you are much more closer to APM magnetometer capabilities then me I'd like to ask you somthing. I am trying to find a oportunity to 'grab' a magnetometer data from APM for additional feeding alexmos 3-axis gimball controller. It would be great to support particulary yaw axis of alexmos controller with APM magnet data as the controller has no its own magnetometer. The position of the gimball in Z axis is only calculated from IMU sensor data and has a continuous time and temp drift.

I've read both manuals - alexmos and apm. The alexmos manual points that external data from FC's (like APM) can be used to support a special mode of gimball called "follow". As APM can send the roll and pith frame inclination via 10 and 11 pins to the gimbal servos - I tried to use it. I transfered the roll data thru the 11pin to the alexmos FC_roll pin and mix the signals from APM and alexmos. Follow mode really works. It means that - opposite to the info on the www.copter.ardupilot.com e.g. "As with the (...) gimbal, ArduCopter, ArduPlane, ArduRover currently only support passing through a pilot desired roll or pitch angle (...)" - a gimball can also support a passing through a APM desired frame inclination.

So maybe the question is: 'where to catch a data from magnetometer to be sent to alexmos, if the data from APM IMU can be catched on 10 and 11 pins?'

How do you think?

Regards

Bert 

Comment by Fabrizio on March 20, 2014 at 6:31am

Hi William, 

your work is great :) 

I was reading your small report of 2010
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&sou...

Premerlani Report 2010

and I didn´t understand how do you arrive from equation 6 to equation 8. Can you please explain it to me? 

Thanks a lot, 

Fabrizio.


T3
Comment by William Premerlani on March 23, 2014 at 5:46pm

Hi Fabrizio,

Actually, as I mentioned at the beginning of this posting, I recommend using the method described in my 2011 report, instead of the one in my 2010 report. It is simpler to implement, and the math is easier to understand.

Regarding the steps involved in going from equation 6 to equation 8 in my 2010 report, I am so sorry to say I cannot find my handwritten math transformations for that. (My desk is covered with piles of my handwritten solutions to various math problems related to UAVs.) I do recall that it took several pages to go from equation 6 to equation 8, and I do recall that equation 8 is an exact solution to equation 6, but sorry to say I do not recall the steps any longer.

I don't think I threw my notes for my 2010 report out. Next time I sort through the piles of papers on my desk, I will look for them, and publish the solution. In the meantime, I suggest you forget about my 2010 report and read my 2011 report.

Best regards,

Bill

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Drone Delivery Challenge, is here

© 2014   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service