Magnetometer calibration is not always accurate

[chrysolinsudhan]

I'm are woking on an embedded device that needs to know the compass heading. I'm using FXOS8700 for this along with sensor fusion library (thankfully!) for calibrating magnetometer and finding compass heading.

But, the results of calibration are not always reliable. By this, I mean that the compass headings are drifting by +/-40 degrees from correct values after certain calibrations. After some instances of calibration we do get correct compass heading, but after some instances of calibration we don't get correct the compass heading.

In our application, we are not using the calibration function continuously, since it is an application where, unlike a smartphone, the device will not experience change in tilt or intensity of magnetic-field after the device is installed. We do the calibration once initially and store the compensation vectors and matrices, and apply them later.

So, is the calibration algorithm that is implemented in the sensor fusion library expected to return correct calibration values always? If yes, any idea what I could be missing here or how I can get to the bottom of the issue? If no, is there a way to identify a poor calibration and get around it?

A note of some observations, in case they are of help:

1. After a calibration with fit error 2%, compass headings are inaccurate, while after a calibration with fit error 5%, compass headings are quite correct.

2. It is observed that almost always if compass heading is incorrect while pointing device to the north, then while pointing to the south also it is incorrect. Similarly, if the compass heading on pointing to the east is incorrect, then the compass heading on pointing to the west is also incorrect.

3. Test was conducted on the same device, PCB - no hardware changes.

Thanks in advance,

Chrysolin

[michaelestanley · Accepted solution]

Chrysolin,

I'm going to give you a partial answer right away and then consult with a coworker for other portions.

First, how well controlled is the thermal environment of your application?  I ask because sensor readings will change as a result of temperature changes.  With continuous calibration, that issue goes away.  But since you are doing a one time calibration, you will be subject to it.

Next, how magnetically clean is the environment where you are doing testing?  Any ferrous materials not fixed spatially relative to the sensor will throw off readings.  For instance, when I calibrate a sensor in my office, and place it in a certain spot on my wooden desk, readings will vary.  The reason is that there's a bracket made of ferrous material connecting the desktop to the desk leg.  Moving the sensor 6 inches one way or the other on the table top restores correct readings.  The fault here isn't with the sensor or the calibration settings, it's with the environment itself.  We actually have one place in our office area where metal in the building throws the field off by 90 degrees.  I can see the same thing with an old fashioned mechanical compass.

You should not see 40% error in readings immediately after calibration unless there is something in the environment itself.  My standard test is to pick up the sensor and hold in it free space away from interference.

It makes perfect sense that observed errors are symmetric about 180 degrees.  That's a result of how hard/soft iron distortions work.  They (and the algorithms that correct them) are naturally symmetrical.

Regards,

Mike

[chrysolinsudhan]

Thanks a lot, Mike.

Regarding thermal conditions, the faulty compass headings are observed soon after calibration and in the same place where calibration was performed. So, the thermal environment could not have changed.

About influence of ferrous things, I have marked North, East, South and West on my work-desk and experiment there. In the same place, I get the correct compass headings after some calibrations. Also, I have tried holding it in free space. The issue remains.

Thanks,

Chrysolin

[michaelestanley]

Chrysolin,

What does the "magnetic" tab display in the sensor fusion toolbox look like?  Here's one I just captured with my K64F/MULT2-B board combination.

You can use File->Reset to clear the magnetic buffer.  Then rotate the board in as many orientations as you can over a minute or so.  There are actually THREE different magnetic calibation options built into the library.

• The four element solver determines field strength and hard iron vector.  The inverse soft iron matrix is set to the identity matrix.  This is the simplest solver, and is consistent with what you see above.
• The 7 element solver adds non-unity diagonal elements to the inverse soft iron matrix.
• The 10 element solver adds off-diagonal non-zero elements to the inverse soft iron matrix.

The "magnetic calibration" functions start out with the 4 element solver at power up.  When some level of fit is accomplished, it will try the 7 element solver.  If the 7-element does a better job, it will switch to that.  Then it tries the 10 element solver.

In a magnetically perfect environment, you should see circular patterns (like those above) for the X-Y, Y-Z and Z-X figures above.  Hard iron offsets are normal and expected.  If you have some ferrous materials in your device, you will see ellipses in one or more of the above.  If you click the "Calibrated Display" checkbox, you can see how the algorithm maps the raw measurements into calibrated data.

Often this display,  possibly coupled with the "Sensors" tab, will give you the information necessary to diagnose a problem.   I like the "Magnetics" tab, because I can watch how new values map to the ideal sphere in real time.  So move your board around and see what happens.

Speaking of which, what board(s) are you using?

Mike

[chrysolinsudhan]

Thanks, Mike.

I'm developing on a custom board, with a different MCU. So, am not able to use the sensor fusion toolbox GUI with it.

But, I've observed the graphs on the GUI with KL25Z/FXS-MULT1-RevC.

Thanks,

Chrysolin

[michaelestanley]

Was your KL25Z encountering the same problem when using our reference code?  That shouldn't happen unless you've got a really ugly magnetic field.  This is one reason we built all the visualization functions into the toolbox.  It's really tough to debug otherwise.  Unless your product includes a magnetic charging film or similar material, I DO expect that about 5 degrees accuracy is about the best that most people will see out of the magnetic calibration.  Under 10 should not be hard.  Over ten, keep working.

FYI,  If you have flash space on your MCU, and a spare UART, you can drop in the serial interface from one of our reference projects.  The toolbox graphic display will be of the wrong board, but the other features should work ok.

Another thing to check is that all your sensors have the same physical orientation as those on the reference boards.  You can get very weird behavior out of fusion routines if the sensors don't have a consistent frame of reference.  The good news is that is easy to fix in the code if your board doesn't match.  Look for the HAL, or hardware abstraction code.

[chrysolinsudhan]

Hi Mike,

Thanks a lot for the inputs.

I've been exploring and trying out a few things. A few questions

1. The stopping condition I'm using for the one-time calibration is: fit-error going less than 5%. Is fit-error a good means to know whether the calibration is good enough? Is there any other way to verify if the calibration is good?

2. About the HAL, it looks like the ApplyHAL() functions in sensor fusion library are dependent on the co-ordinate system of the OS, rather than the hardware. The Freescale Sensor Fusion for Kinetis Product Development Kit User Guide document seems to suggest other-wise, though. So, is there a version of code I'm supposed to be using? I'm currently using build422 - Nov2014.

3. Right now, I'm using the HAL that is available in the sensor fusion library (THISCOORDSYSTEM defined as WIN8), because I'm getting reasonably correct compass headings. If I want to make a HAL for the orientation of the chip on my PCB, is there a guide? I'm using a single chip (FXOS8700).

4. In 7 and 10 element calibration functions, the eigen vectors and values are 0/Infinity's. Eventually, these functions return no useful calibration solutions. Is this expected? When I checked, fmatA matrix does actually have non-zero eigen values and vectors, but the function eigencompute() gives the eigen values and vectors as 0/Infinity's only.

I'm not facing the issues while using KL25Z. Here's my screenshot:

Thanks,

Chrysolin

[michaelestanley]

Chrysolin,

Is the figure you included for KL25Z, or your board?

Generally we do rely on the fit error, but also look to make sure we like the look of the plots above ("Calibrated" displays should be circular).

There are two sets of issues to consider for the hardware abstraction level: physical orientations of the sensors and which global frame of reference you want to use.  Since you are using only the 8700 sensor, you're probably not having HAL problems.  The various settings are self-consistent for that device for all the desired frames of reference.  If you had separate mag and accel and/or gyro, you sometimes need to adjust the hardware abstraction levels to make sure the physical sensors map into a consistent frame of reference.  That discussion is probably beyond what I can do in the discussion board.

Are you using just our magCal, or the full eCompass implementation?

There is now a version 5.00 of the library, and we will be taking 4.22 down in a few weeks.  There are some bare-metal, non-RTOS versions of eCompass in the new version.  So you might want to upgrade anyway.  The new version is on freescale.com/sensorfusion.

I'll have to check with my math expert on the eigenvalue question.  He'll have a more intelligent answer than I can come up with.

Mike

[michaelestanley]

Chrysolin,

I confirmed with my expert that those functions should NOT be returning zeros/infinities.   Are you sure they are being fed with correct data?

I'm assuming the plots you have above are for your KL25Z running the canned project, as they look fairly reasonable.  I would really like to suggest that you do your debugging of this issue on that platform so you can immediately see the effects of your changes on the code.  Start with the working (continuously calibrated) project.  Confirm you get OK results, and then start making incremental changes & confirmation of results at each step.

Mike

[chrysolinsudhan]

Thanks, Mike.

Yes, that figure was for KL25Z. I'm using both magCal and eCompass.

I was setting up the development environment with freedom board. But... the issue seems to be partially fixed by simply changing the oversampling ratio back to 8. Since the time gap between two compass headings is too high (40ms) for the application, I had earlier reduced the oversampling ratio to 2. So, now, after moving back to oversampling ratio of 8, I'm getting maximum error of +/-15 degrees only :smileyhappy: .  This should be good enough, provided it doesn't climb up with more adverse magnetic material on the device in the future.

Thanks a lot for the support :smileyhappy:

Btw, I've got a question about tweaking OSR and ODR. Will open a fresh discussion for it. Thanks again.

Thanks,

Chrysolin

[michaelestanley]

Thanks for letting me know of your progress.

Regards,

Mike