Automatic nulling of magnetometer offsets
[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
Replies to This Discussion
-
Permalink Reply by William Premerlani on -
Hi Thomas,
Thank you very much, too.
Bill
-
Permalink Reply by William Premerlani on
-
Dave,
Thank you very much.
Bill
-
Permalink Reply by Paul G. on -
1. We want to produce another major release of MatrixPilot for the existing UDB before the new board comes out. I am not sure what features will be there, that will be up to the team. Certainly, we will consider your ideas, but I cannot promise what will be in, and what will be out. There are a lot of things on the list, some things will get cut in the interest of a timely release.
Do tell :) Is the plan short term or longer ? If longer I'll do it, meaning if you have a reasonably set idea of what you want in there and how you want it connected I can start right now - have some experience in the field and would dearly like to see some more pins with such awesome firmware :)
-
Permalink Reply by William Premerlani on
-
Paul,
If you are asking about the new board, attached is the schematic. We have prototypes, we will probably go through a couple of revisions before we release it.
Best regards,
Bill - Attachments:
-
-
UDB2-v10_1.pdf, 35 KB -
UDB2-v10_2.pdf, 63 KB
-
UDB2-v10_3.pdf, 44 KB
-
-
Permalink Reply by Thomas Kindler on
-
Hi Bill!
Have you considered using an ITG-3200 instead of the two discrete gyros?!
I'm using one in my own project, and it works just great! It also has an integrated temperature sensor, and can be calibrated for almost zero drift. The I2C bus is there anyways, and it would free 3 additional A/D inputs.
Also, I see you're using an EEPROM. How about a MicroSD-Slot for logging data instead?
Best regards,
Thomas
P.S.: If anyone's interested, I can post a temperature vs. zero rate plot of the ITG-3200. Just made that yesterday.
-
Permalink Reply by Paul G. on
-
Hi Thomas
Simple answer on the gyro's is bandwidth :) we'll that's my educated guess anyways.
You do however mention MicroSD and that's something I'm looking at too - do you have any example of electrical connection and / or code for PIC's ?
Paul
-
Permalink Reply by Thomas Kindler on
-
Hi Paul!
I've implemented the DCM method as described in Bill's paper, and did not experience any bandwidth problems with the ITG-3200. You can have up to 1600 samples per second, and selectable digital filters when using a lower rate.
It's mounted on a Quadrocopter with lots of vibration (by which the ITG's output is not disturbed at all), and performs just fine.
You should give it a try! SparkFun even has breakout boards in stock.
For the MicroSD stuff, I think Chan's FatFS is the most popular solution. You should find a PIC project somewhere on the net:
http://elm-chan.org/fsw/ff/00index_e.html
-
Permalink Reply by William Premerlani on
-
Hi Thomas,
Regarding the MicroSD for logging data, the team likes that idea a lot. We have been leaning in that direction almost as soon as the prototype was built, so the final design will probably have one.
Best regards,
Bill
-
ModeratorPermalink Reply by Morli on -
Why only for logging data? Can we not think of using SD card for mission specific data ( like WP and option file etc ) in SD card and insert it for specific type of mission instead of programming the UDB every time we change some waypoint or some common parameters etc. SD cards are cheap and we can have few with standard sequences tuned for our airframes( just swap the card to change the mission). Just thinking loud. thanks.
-
Permalink Reply by William Premerlani on
-
Paul,
One more file.
Bill - Attachments:
-
-
UDB2-v10_4.pdf, 31 KB
-
-
Permalink Reply by Paul G. on
-
Looks really good - about 6 months ago I started doing almost exactly that - well same pic but different sensors. Now I wish I had finished it because I'd have a board in my hands now :) Can I send you a friend request ?
-
Permalink Reply by Alex Zarenin on -
Hi Bill,
In the board I am working on I would like to use 3-axis magnetometer in addition to the 3-axis accelerometer to compensate for gyro drift and achieve yaw lock. In implementing this algorithm I am following your outline as discussed in “DCMDraft2” and “MagnetometerOffsetNullingRv2”.
For the part related to accelerometer I follow the DCMDraft2. For the magnetometer I implement the following algorithm:
1. When the board powers up I measure magnetic vector M; assuming that the board is stable and horizontal this measurement (in the body frame) is assumed to be the estimate of the true magnetic vector in the Earth frame Me-c.
2. On each subsequent step n I use the transpose of the rotation matrix from the previous step R(T)n-1 and the stored value of the magnetic vector in the Earth frame Me-c to calculate an estimate of the magnetic vector in the body frame M’b-n.
3. The vector cross product of this estimate M’b-n and the measured value of the magnetic vector in the body frame from the magnetometer Mb-n represents an error, which is being passed to the PI controller to generate an adjustment based upon the magnetometer.
4. This adjustment is combined with the roll-pitch adjustment from the accelerometer and the rotation vector from gyros to generate the “infinitesimal” rotation matrix, which is being applied to Rn-1 to generate new rotation matrix Rn in accordance with the algorithm from DCMDraft2.
5. The New rotation matrix Rn is being normalized (again, in accordance with DCMDraft2) – and the firmware is ready to do the next cycle returning to the Step 2 of the algorithm.
However I see a drift creeping in due to the magnetometer offset – the measured magnetic vector is not originated at {0, 0, 0}, but has some offset from the beginning of the coordinate system. Naturally I would like to eliminate this offset using the algorithm described in your article “MagnetometerOffsetNullingRv2”. And this is where I got stuck!
If on the n-th step I have an estimate of the offset as Mo-n, how should I proceed calculating the estimate of the rotation error based upon the magnetometer? It looks from equations (10) and (3) in “MagnetometerOffsetNullingRv2” I need to take a cross product of
Mb-n = Mmagnetometer – Mo-n
and
M’b-n = Mo-n + R(T)n-1*Me-c
Please advise whether my interpretation is correct.
Thank you,
--Alex
Social Networking
Top Content
Contests
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.A list of all T3 contests is here.
Groups
-
ArduCopter User Group
1286 members
-
ArduCopter Italian Group
87 members
-
techpod users
39 members
-
Moderators
24 members
-
Turkish Ardu Group
5 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
