# Tilt compensated compass algorithms

This Sparkfun product does it with 3-axis magnetometers + 3-axis accelerometers: http://www.sparkfun.com/commerce/product_info.php?products_id=8656

I have both 3-axis magnetometers and 3-axis accelerometers but I'm unsure what algorithm I could use to get a steady heading output. Any ideas?

(I also have a 3-axis gyro and Kalman filter running so I have pitch and roll--although I can't seem to debug why pitch is laggy and roll is instant with the exact same code.)

Views: 2354

Tags: compass, heading, imu, magnetometer, yaw

Comment by Tim Trueman on August 7, 2009 at 5:43pm
After a lot of searching it seems this IEEE paper talks about it using CORDIC: http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F4534149%2F4541329%2F04541636.pdf%3Farnumber%3D4541636&authDecision=-203

"In a 3-axis compass, the system tilt of the sensors needs to be compensated to calculate the heading of the compass correctly. A novel tilt compensation algorithm using the CORDIC algorithm is presented. Only five 2D-CORDIC operations are needed to ac quire the heading angle from three components of magnetic and acceleration data. This can be useful in ASIC and FPGA designs where the compass data needs to be compensated efficiently in terms of area and power. It is also possible to implement the correction algorithm in a micro-controller without a multiplier. The algorithm was tested in practice using a 3-axis magnetometer, a 3-axis accelerometer and FPGA."

Developer
Comment by Ryan Beall on August 7, 2009 at 7:31pm
Tilting the mag flat is pretty easy if you have the pitch angle and roll angle from the Kalman. http://www.magneticsensors.com/datasheets/sae.pdf
As far as the Kalman question...It really depends upon how your are implementing the Kalman. If it's a fixed gain filter then just change the gain on the appropriate axis. A laggy axis really sounds like some sort of wierd implementation. Like low passed or something but the general idea is that you should be reading 99% of the integrated gyro rates. Lean more on the gyros...Hope the paper helps man
Comment by Tim Trueman on August 7, 2009 at 7:56pm
Awesome that paper seems to have what I need (although I haven't verified it yet). Thank you!

I've got a Kalman filter library for Arduino that I wrote in C but what puzzles me is how two instances of it behave so differently:

pitch = pitchFilter.filter(ratex, accy, accz);
roll = rollFilter.filter(ratey, accx, accz);

I'm going to step through is look at the variables to figure out what's going on, but I'm sure I can fix it.

I'm tempted to check out DCM…there's isn't an Arduino port yet is there?

Developer
Comment by Ryan Beall on August 8, 2009 at 12:02pm
My guess is just by looking at your function call that you are taking the same approach that I did when I started. You are porbably missing a lot of equations. ie: not really following the 6deg of freedom equations. I have seen a lot of guys claiming they have kalmans working and what they are doing is not exactly right....(which is what I started copying and soon found out why they were in correct) What seems to my just by looking at your function calls is you are doing the same as I did. Roll actually should get calculated first and then your pitch is a function like this

pitch = pitchFilter.filter(ratex, accy, accz,roll);

Also these functions aren't accounting for centripetal which you will find once you test fly this thing will kick your filters butt reguardless of the gains you use. So in actuallity you are missing more equations for that too is seems unless your variables are global. The best way I can describe it....because it took me a long time to convince myself that (your method same as mine) the method was flawed. Correction its right but only when the platform is straight and level and nothing else....so yeah not so good. But here goes

look at it this way.....if roll is 90deg wing up....and you are integrating pitch gyro (rate x) you are only changing the aircrafts heading and nothing else however your equations/functions apear to disconnected from eachother and would pitch the airplane even though by definition the pitch isn't changing....At 90deg roll you would want to integrate the yaw gyro for pitch....make sense.. so the 6dof equations set up all the cos and sin functions for every combination in between so you apply the right integrated rates to get the right attitudes out. Once I saw that one extreme it all made sense and I switched to a cascaded approach using the 6dof and it makes hella more sense
Comment by Tim Trueman on August 8, 2009 at 12:57pm
Yeah… I'm still trying to figure things out. I'm pretty new to this.

Do you have any links to theory or code I could get started on? The idea of cascading makes a lot of sense.
Comment by Tim Trueman on August 8, 2009 at 3:55pm
This PDF describes a cascading approach: http://openuav.astroplanes.com/library/docs/attitudeKF_dev.pdf
Comment by Tim Trueman on August 8, 2009 at 4:53pm
Actually this one is better: http://contentdm.lib.byu.edu/ETD/image/etd1527.pdf

Developer
Comment by Ryan Beall on August 8, 2009 at 9:05pm
There you go man...You work the math on that and you'll be there!

Comment

Join DIY Drones

1

2

3

4

5

6

7

8

9

10

## 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

78 members

24 members

51 members

682 members

184 members