[There is now a better method for removing offsets in flight. See this discussion. - WJP]

The picture shows a UAV DevBoard connected to Jordi's magnetometer breakout board.

First, since my discussions tend to get long winded, if you want to "cut to the chase", you might want to read this.

I recently integrated Jordi's HMC5843 magnetometer breakout board with the UAV DevBoard (UDB).

Jordi's board is really great, having the onboard bidirectional level shifters and builtin pullup resistors made it possible to simply connect Jordi's board directly to the I2C pins in the programming connector. Thank you very much, Jordi.

So, heli and quadcopter pilots who are using the UDB would do well to buy Jordi's board, my plan is to integrate it into the heli firmware that is being developed for the UDB. There is now a magnetometer demo and instructions for the UDB.

But that is all besides the point of this discussion....

Along the way to implementing the magnetometer demo, I realized the hardest part was going to be determining the offsets of the magnetometer. The integration of the magnetometer itself into the DCM algorithm was trivial, but what to do about the offsets?

The HMC5843 has a self calibration feature, so you can determine the gains just fine. But the first magnetometer I bought had rather large offsets. So I bought 3 more (1 more from Jordi, and 2 more from Sparkfun). It turned out that all 4 units had some offsets. Even if they did not have offsets, it would still be possible for stray magnetic fields in the aircraft to create offsets.

So, some sort of procedure is needed to null the offsets.

I thought of several manual ways to do that, and I read several postings on the subject....

Then I wondered if there might be some way to use the direction cosine matrix to automatically compute the offsets in flight. And there is....even for dynamically changing offsets, such as from power leads to the motors...

The basic idea is the following...

When the aircraft is rotating, the offset fields rotate with the aircraft, while the earth's magnetic field is stationary. So it should be possible to use the direction cosines to separate the two fields.

The basis of the idea is the same as flipping the magnetometer exactly 180 degrees along one of the axis and averaging the two readings. The result is the offset.

The idea can be extended to rotations other than 180 degrees, even small rotations, by using the direction cosine matrix and some vector algebra.

The resulting theory and implementation is described here, and it has been tested. It works rather well.

It was interesting to watch the computations of the offsets during the tests. A few random turns along a couple of the axes was all that was needed to compute the offsets. So, you can either null the offsets prior to takeoff by rotating your aircraft a bit, or simply let it happen automatically during the first few turns of the flight.

It was also interesting to see what would happen if I deliberately manually set the offsets to the wrong values, they would quickly reset to the correct values after a few turns.

The bottom line is that now both the calibration and the nulling of offsets can be done completely automatically, without any manual operations or entry of measurements. It is possible to extend any DCM-based IMU, such as the ArduIMU, to use this method to simplify the integration of a magnetometer.

Best regards,
Bill

Tags: DCM, DevBoard, UAV, magnetometer

Views: 4822

Reply to This

Replies to This Discussion

Hi Behnam,

I am not sure which posting you are replying to, so please forgive me if I am repeating anything.

The 9 elements of the direction cosine matrix are not constants, they change as the attitude of the aircraft changes. Each element of the matrix is the cosine of the angle between a pair of earth and the aircraft axes that correspond to the row and column of the matrix. For more information on DCM, see the summary document.

Most navigation and control computations can be expressed in terms of vector operations involving rows and columns of the matrix. Some pilots prefer Euler angles. The conversion between the two representations is described here.

Best regards,
Bill
Hi
Thank you Bill, that was exactly what I needed.

So, as I understood we should have this rotation matrix from other sensors or it should be a fixed orientations?

Thank you
Behnam
Bill

A brilliant and simple solution to find and correct soft magnetic offsets. Do you plan to include this in the firmware for the SF 9DOF Razor AHRS?

I am working through your first paper 'Direction Cosine Matrix IMU: Theory'. It mentions a further paper 'how to implement the DCM algorithm in C code', is this paper available yet, draft or final will do?

Thanks
Hi Tomas,

I am not the one who wrote the firmware for the SF 9DOF Razor AHRS, I cannot answer your question about that.

Regarding a paper on the implementation of the DCM algorithm in C, I never got around to writing it, it is on my list of things to do, but not many people have asked about it, so it fell to the bottom of my priorities.

If you want to see an fixed point implementation, take a look at the file rmat.c in MatrixPilot.

If you want to see a floating point implemenation, take a look at the code for the ArduIMU.

Best regards,
Bill
Hi,

Ingineous Work.

Could you enlight me where do you apply the declination vector? I don't find it in the algorithm, just on the code displayed.

Thks in advance.
Hi Virgilio,

I did not discuss the declination vector for two reasons:

1. It was outside of the main focus of the magnetic offset compensation algorithm.

2. The definition of the declination angle is well known. For example, take a look at the wikipedia entry.

Basically, the declination angle is the angle between magnetic north and true north. When you are compensating for yaw drift, you want to align the direction cosine matrix elements to true north. The implementation of the algorithm uses a declination vector to account for the declination angle.

Best regards,
Bill
Thanks for your answer Bill.

I roughly know what is the declination angle, my previous questions was more related with knowing how do you specify the declination vector (1x3) knowing the declination angle.

Regards, V.
Hi Virgilio,

The declination vector is a 1x2 vector:

void dcm_init_rmat( void )
{
#if ( MAG_YAW_DRIFT == 1 )
declinationVector[0] = cosine(DECLINATIONANGLE) ;
declinationVector[1] = sine(DECLINATIONANGLE) ;
#endif
}

Here is how it is used:

mag_error = 100*VectorDotProduct( 2 , magFieldEarth , declinationVector ) ;
VectorScale( 3 , errorYawplane , &rmat[6] , mag_error ) ;

Best regards,
Bill
Thanks again for your answer.

Enlight me on this...

In equation 11 you use the magnetic field measurement in body frame for time steps 1 and 2, But in the code displayed you have:

MatrixMultiply(1,3,3,rmatTransposeMagField,magFieldEarthPrevious,rmat) ;

Using the magnetic field measurement in the Earth Frame.

Why is this?

Thanks.

Ab. V.
Hello, I need some help here about the magnetometer. I have a HMC5843 (the red board) from Sparkfun and I would like to reset de magnetometer to its factory default state, because after a setup error, the magnetomer gives me now bad values (I.e.: MagX:-32, MagY:32, MagZ:-32,)...

Could someone can give me the procedure to reset the HMC5843 to the factory default setup ?
Thanks for your help,
Jean-Louis
Good evening Jean-louis, I found some documents on this component, if that can help you Regard
DODY
http://www.ssec.honeywell.com/magnetic/datasheets/HMC5843.pdf
Hello Dody, thanks for your answer... Now, I have solved my problem...After some troubles with my HMC5843 triple axis magnetometer due to a programming error during a test. My magnetometer has lost its working setup and has given crazy datas... So, I have needed to build a special programm to put the correct factory setup... Now, my HMC5843 is working properly and able to give good datas... You will find my HMC5843 setup and test program here...
Regards, Jean-Louis

RSS

© 2014   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service