Yaw drifts to SE even when stationary

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Compiled/uploaded the SF9DOF_AHRS_1_1.zip contents
2. Change Com port value in python script
3. Powered on the 9dof and ran the python script

What is the expected output? What do you see instead?
Yaw started at around zero but drifted to 130 within the first 200 data output 
cycles then settled at around 135 (Pointing South East) after about another 100 
cycles. Meanwhile the 9dof didn't move and was always pointing North. Turning 
the 9dof changes the heading but when you stop turning the values drift back to 
135 hence pointing South East.

What version of the product are you using? On what operating system?
SF9DOF_AHRS_1_1 running on 9dof hardware version V14 connected to PC via 3.3v 
FTDI - Python running on Win7 Ultimate. 

Please provide any additional information below.
Attached are the logs. At first the IMU isn't moved. The values creep to 135. I 
then turn the IMU clockwise (around 40 deg) and stop there. The values creep 
back to 135.
Any help would be greatly appreciated.

Original issue reported on code.google.com by pdf...@gmail.com on 7 Mar 2011 at 4:03

Attachments:

• Serial1299513326.51.txt

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Same issue with using SF9DOF_AHRS_1_0 and also SF9DOF_AHRS_1_1 on Sparkfun from 
12/28/09 (can't find a revision number) with Ubuntu 10.10

BTW... If i set OUTPUTMODE==0, the mentioned Issue doesn't occur... but than of 
course there is  the drifting of the sensors...

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

[GoogleCodeExporter]

OK... i may have found the problem... Am i right, that they changed the baud 
rate in a newer version code? nevermind...
They might forgot a delay command after they set the HMC-chip to continuous 
mode. I think due to the slower baud rate they had before it hasn't been an 
issue until now...

SOLUTION:
Either you turn down the baud rate, or you add a delay command to the 
compass_init() in the file I2C.pde to give the chip enough time to set the mode 
in the register:
--------------------------------------------------------------
void Compass_Init()
{
  Wire.beginTransmission(CompassAddress);
  Wire.send(0x02);   
  Wire.send(0x00);   // Set continouos mode (default to 10Hz)
  Wire.endTransmission(); //end transmission
  delay(5); // <===
}
--------------------------------------------------------------
damn it took me the whole saturday yesterday... and suddenly today after half 
an hour work, i could get it work :D
Hope it works for you too

Greeting, Gerold

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

[GoogleCodeExporter]

I have recently purchased the Razor 9 DoF and the FTDI 3.3v interface. Have 
experienced that pitch and roll accurately follow the movement of the IMU 
however yaw changes values between 45 digs and 135 digs even when IMU 
stationary. In fact yaw angle output does not seem to correspond to IMU yaw 
angle at all!
Have tried suggested mod in Compass_Init which didn't seem to have any effect!. 
I am not using the python code, am using the arduino dev die on a Mac book pro 
and using the serial monitor to view the measured roll, pitch and yaw angles.
If there are no further suggestions I will start analysing the code - hopefully 
to understand the method and deduce what the problem might be
Regards,
Bernir

Original comment by bermat...@gmail.com on 9 Sep 2011 at 1:15

[GoogleCodeExporter]

if u check all 9 values of the sensors (change the output mode on the IMU), 
check if the magnetic values follow the movement. Mine had constantly a max 
value (due to the mentioned initialization problems i guess) and therefore the 
drift correction of the yaw was corrected to a non-sense value.
Rgds, Gerold

Original comment by gerold.h...@gmail.com on 9 Sep 2011 at 2:34

[GoogleCodeExporter]

Thanks for that, I did look at the mag outputs, more specifically the Magnetic 
Heading calculated,
I expected this to follow the movement of the IMU with respect to North (in 
heading) - it didn't!,
so I have been trying to disable the drift corrections to first establish that 
the basic gyro calculation is
correct (ignoring any drift). I have not achieved this yet but may try later...

I am quite impressed with the stability of the pitch and roll outputs

My daytime job involves the simulation of guided missiles so I have some 
experience of using 6 DoF IMUs
(no magnetometers though)

Bernie

Original comment by bermat...@gmail.com on 9 Sep 2011 at 5:32

[GoogleCodeExporter]

Under further investigation I note that my raw gyro data seems to be all zero! 
Is this a problem you experienced?
Bernie

Original comment by bermat...@gmail.com on 10 Sep 2011 at 8:44

[GoogleCodeExporter]

no i don't remember having that issue. but i don't think that is an 
initialization problem as the gyro communication is analog unlike the magn. and 
accel. sensors are I2C. Sorry, can't help u with that, as i don't have the IMU 
here anymore.
rgds, Gerold

Original comment by gerold.h...@gmail.com on 10 Sep 2011 at 8:50

[GoogleCodeExporter]

I'll tag on to issue 28 which reports the same gyro problem,
Thanks

Original comment by bermat...@gmail.com on 10 Sep 2011 at 8:59

[GoogleCodeExporter]

Hello Gerold,
I am also facing the yaw settling to SE problem. I tried changing to lower baud 
rates and also added the delay in compass init but did not work for me. It 
worked for a moment but it stopped working. This hardware revision and code of 
SF1.1 has this SE problem. Happened with the other IMU that I had. So could you 
tell me what could be wrong and how can I solve it? Such issue is not there 
with drift correction off but then again you wont get corrected values.  I 
guess it has got to do with the frequency of the sub loops running and their 
coherence with the updated sensor values.

Original comment by infi...@gmail.com on 5 Dec 2011 at 5:10

[GoogleCodeExporter]

setting KP_Yaw to 0.02 instead of the default 1.2 and adding a 100 Uf cap to 
the Vcc and Gnd of the Z gyro make yaw more stable.

Original comment by infi...@gmail.com on 5 Dec 2011 at 6:01

[GoogleCodeExporter]

The capacitor prevents frequent maxing out of the Z gyro.

Original comment by infi...@gmail.com on 5 Dec 2011 at 6:04

[GoogleCodeExporter]

I have somehow overcome the issue using FreeIMU and cutting out the gyro error 
feedback. Not the best think in the world but it somehow solves it. Check out 
http://simplesensors.co.uk/2011/12/9dof-imu-solving-drift-on-yaw-workaround/ 

Original comment by ep...@yahoo.com on 28 Dec 2011 at 10:31