HMC5883L new calibration method (BUG for Alex)

[ciskje]

Hello to all.

The BIAS positive for the HMC5883L are different for X&Y than Z, the field generated for X&Y are 1.16 Gauss, Z have 1.08 Gauss (that is 7% difference) according to datasheet.

This is a method to compensate:

magCal[ROLL] = 1160.0 / abs(magADC[ROLL]);
magCal[PITCH] = 1160.0 / abs(magADC[PITCH]);
magCal[YAW] = 1080.0 / abs(magADC[YAW]);

Also they are different for HMC5843 that is 0.55 gauss for x,y,z.


The perfect calibration can be obtained in this way:

- point to the north 3d in your zone (for europe point north and down, it is near 45 degree down to earth)


- rotate yaw 360 degree (x,y calibration)
- rotate pitch 360 degree (y z calibration)
- point multicopter west
- roll 360 degree (x z calibration)

Why the 3 value taken from MAG are named roll, pitch, yaw instead of x,y,z?

[noobee]

i've some notes about why the current init/calibration code may not be normalizing each sensor axis equally. i think the current scheme works, but can be a little more accurate.

viewtopic.php?f=8&t=1290&start=170#p10652

[ciskje]

yes noobie, There is a problem, searching for min/max and extracting only the zero is not correct, with soft-iron effect the range (also with the test of the fixed field of the BIAS) are different for x,y,z. If you have metallic surface near the sensor (every quad have this problem), the range change for the 3 axis.

if you get for x [1100,-900] and for y [-800,600] extracting the zero is 100 for x, -100 for y that they are correct, but they have different range (+-1000 for x and +-700 for y), so the 3d compass vector is not in the correct direction.

it is better to use directly min max:

(value-min)/(max-min)-0.5

so the vector is [-0.5,0.5] for all 3 axis coherently.
The best overall is that you must use the ellipsoid to correct the soft-iron effect, but the range check are a good approximation.

[timecop]

ciskje, I like your ideas and would like to subscribe to your newsletter.
Would you be interested in improving mag code in STM32 port of MultiWii?
There is no need to worry about atan2f() taking an extra 0.001 microseconds to execute.

[ciskje]

Oh yes! I love to program clean and with FLOATING POINT fully with 32-bit.
You can see my personal multicopter project: http://code.google.com/p/simplo/

[Magnetron]

Oh yes! I love to program clean and with FLOATING POINT fully with 32-bit.
You can see my personal multicopter project: http://code.google.com/p/simplo/

I love IT!!!
I will collaborate with ciskje to develop a better flying system!

[timecop]

Oh yes! I love to program clean and with FLOATING POINT fully with 32-bit.
You can see my personal multicopter project: http://code.google.com/p/simplo/

Nice start, but.. C++ and arduino? OK. Starred the project, anyway.

[ciskje]

no problem with performance, thankfully to the excellent compiler!
No virtual functions so no additional load during runtime, floating point lib in gcc for AVR are really optimized.
It is ready to be used on STM32

New mag initialization inside to return IN TOPIC.