AHRS 1.1 heading drift

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Connect with python graphical interface, allow IMU to warm up / initialize
2. Yaw IMU ~90 deg
3. Observe ~44 deg heading change on screen
4. Yaw IMU ~90 deg additional (total 180 deg heading change)
5. Observe heading change to ~66 deg max from original heading, then drift back 
down to ~44 deg. Same thing happens in other direction.

What is the expected output? What do you see instead?
Expected heading change to match IMU yaw rotation.

What version of the product are you using? On what operating system?
Razor 9DOF, 3.3v FTDI breakout, Win7, AHRS 1.1

Please provide any additional information below.
Could this be a magnetometer calibration issue?

Original issue reported on code.google.com by jmcole...@gmail.com on 2 Nov 2010 at 7:50

[GoogleCodeExporter]

When I enable PRINT_ANALOGS, I get a data stream that appears to be in the 
following order: Accel P Y R, Angle P R Y, Magneto P R Y. This is based on 
which numbers change and how, as I change the board's orientation. It does 
*not* appear to match what the output lines claim to be outputting, which is 
Angle (AN), Accel (ACC), Magneto. The third number in the second triad 
("ACC[2]") does not change appreciably as yaw changes (it fluctuates a bit but 
appears to be within the normal noise for that data triad).

I have made no changes to the AHRS code except to enable PRINT_ANALOGS.

Original comment by jmcole...@gmail.com on 2 Nov 2010 at 8:39

[GoogleCodeExporter]

Please ignore my comment about values being in the wrong order, I went back and 
read the datasheets for the chips and they're correct. Still having heading not 
track properly.

Original comment by jmcole...@gmail.com on 3 Nov 2010 at 4:09

[GoogleCodeExporter]

maybe that's the same issue than "Issue 21: Yaw drifts to SE even when 
stationary"? might have found a solution for that one...

Greetings,
Gerold

Original comment by gerold.h...@gmail.com on 20 Mar 2011 at 10:59