# ArduIMU v1.1 (Now v1.2) Questions and Answers and More Questions

Hello All,

I am going through the ArduIMU v1.1 software and getting ready to start modifying it for my own purposes. I am pretty excited about this IMU and think there are some really cool, creative things that can be done with it.

I keep generating questions that people are helping me find the answers. I've decided to update this top post as questions get answered so that it will be a bit of a FAQ,

I know there are others than me digging in to the code, so post your questions and answers as comments and I'll keep the FAQ at the top updated :)

Doug

CURRENT QUESTIONS:

#define Kp_YAW 0 //.5Yaw Porportional Gain
#define Ki_YAW 0 //0.0005Yaw Integrator Gain
so the values in use as downloaded are zero and there is no yaw drift correction. Has anyone tried out the values in the comments? What testing did you do and what were the results?

Q I have been looking at the accelerometer data to see if I could use it to integrate velocity, but it looks much too coarse, and despite claims that accelerometers don't drift mine have some poor behavior that I would either call drift or hysteresis. For example, using groundtest.vi and looking at the accelerometer data - With the IMU sitting on my desk the raw accelerometer data should be (and initially is) 0, 101, 0. However, after moving the IMU around and then bringing it back to rest I might see data of 1, 101, 2, or 0, 101, -3, and those readings might persist for quite some time (>20 seconds). If you work the math on 0, 101, 3 it works out to indicating a velocity of 13 miles per hour in the z direction after 20 seconds. So, the question is: Is this hardware any good for inertial navigation applications???

Q Where is the yaw drift correction??? Am I correct in thinking that it is not included in this release of the software?
A - No - the yaw drift correction is handled in the roll_pitch_drift() routine. However, note that the P and I coefficients are set to zero in the v1.1 download. You will need to change them. I haven't tested values out yet.

Q Why is Gyro_Scaled(x) defined as x*((Gyro_Gain*PI)/360) instead of x*((Gyro_Gain*2*PI)/360) or x*((Gyro_Gain*PI)/180)?
A Well, because the factor of 2 is incorporated in the Gyro_Gain (we think)

Q Why the procedure in setup() of reading the adc's 75 times? From the filtering it looks like 3 or 4 times should be sufficient as the value after any read is 90% the most recent measurement and only 10% previous averaged measurements.
A I looked at the raw data and for some reason the data is pretty goofy the first 5+ times through the loop, almost like you need to warm up the AD converters. Can't explain it, but that is probably why 75 samples are taken even though 5 would be sufficient with the filtering used.

Q Why is AN_OFFSET[4]=AN[4]+GRAVITY instead of AN_OFFSET[4]=AN[4]-GRAVITY?
A Because gravity works to lessen the value of the raw data in the y axis, so GRAVITY is added back to get the "zero gravity" offset. It is just a matter of the direction and sign.

Views: 247

Tags: ArduIMU

3D Robotics
Comment by Chris Anderson on October 8, 2009 at 5:42pm
Yaw drift is done with GPS. Jordi can answer the other questions.
Comment by automatik on October 8, 2009 at 6:19pm
something to ponder while Jordi answers:

- Gyro scaling (or conversion to radians question): I noticed that too but figured Jordi is playing with factor of 2 in scaling and was simplifying code

- I guess set up is called numerous times to insure 'good' offset values (3 or 4 times might be too few but am not sure what is optimal number - Jordi and Bill P. might have a good reason for 75)

- gravity: Accelerometers give you gravity minus acceleration. In order to account for centrifugal acceleration and get back gravity estimate (since that is what you want) you need to add gravity to the plane frame

my \$0.02 untill Jordi or Bill replies

Developer
Comment by Doug Weibel on October 8, 2009 at 8:53pm
@automatik

Thanks, I suspected that the 2PI thing might be related to the 2.5 scaling factor. It would have been clearer to stick with the standard formula.

On the gravity thing I think it was a matter of my thinking about the sign backwards. When I looked at the raw data I see that gravity reduces the raw data, so it is added back to come up with a zero gravity baseline for the reading. I was assuming that gravity would be increasing the raw reading. Made sense once I got the direction correct.

@Chris - I know it is (or will be) done with GPS, but I'm pretty sure there is no code in there at present to do it. The routines called in the main loop implement the DCM numerical integration, the normalization, and the pitch/roll drift correction, but there is no function call and no corresponding function for yaw drift correction. Also the P and I factors for the yaw correction feedback loop are set to zero. I was surprised it was not implemented after hearing the story about Bill and Jordi zooming around the traffic circle. Sounded like yaw drift correction testing to me.....
Comment by Dan Wilson on October 8, 2009 at 10:59pm
It looks like yaw drift compensation occurs in roll_pitch_drift(). The yaw drift gains may be set to zero for indoor testing.
Comment by Lorentz on October 9, 2009 at 5:06am
@Doug
I'm trying to port ArduIMU code to an ARM Cortex M3: I can confirm that roll_pitch_drift() does the yaw drift compensation too. Everything works fine until now, pitch - roll drift compensation included, but haven't tested yaw drift yet. In the next days I'll test the yaw drift compensation, by now I suspect that it depends on "speed3d" being = 0.
Comment by Michael Zaffuto on October 9, 2009 at 6:07am
Pyramid style ArduiIMU mounting as a possible solution for static Yaw drift. The Yaw's drift correction is dependent on the active GPS vector. It is a consequence of the lack of observability of the gravity vector for the yaw gyro and accelerometer during stationary, level at rest conditions. Typically, we mount the 6dof ArduIMU flat, in its strapdown orientation so that all the sensors fit our concept of alignment with the usual x,y,z axis. If the 6dof cube was mounted on one of its "points", there would be the sqr(x^2+y^2+z^2) vector from all three accelerometers sensing gravity at rest. Each accelerometer would see it's percentage of the total gravity vector and so the usual routines for Gyro drift compensation could be used on all three gryos. All 3 Gyro axis would be stabilized at rest or in the QuadCopter hover application. The matrices that define x,y,z would need to account for their new "static" initial rotation to describe it's orientation with the body axis as each body vector would use a contribution of the sensors. Nothing major really changes with the routines and the GPS corrections regarding DCM would still be all the same. A nice method to hold the cube in the new orientation would be needed, possibly made of 2 FR-4 pcbs.

Developer
Comment by Doug Weibel on October 9, 2009 at 7:16am
@Dan and Lorentz - Thanks, I have found the code now. Stupid of me to assume that roll_pitch_drift could not mean roll_pitch_yaw_drift.... Lorentz, not sure I understand your comment about "speed3d", but it seems that the yaw correction code should have some logic in it that only attempts to apply the correction if the ground speed > 0. If the ground speed is zero the ground course will be an unreliable/noise measurement that would induce a yaw error rather than correct it.

@Michael - Thank you for your idea of mounting the IMU "pyramid style". I had had that idea but hadn't really worked through it in my mind. In addition to playing with the IMU for autopilot use I am interested in it for an experimental full scale aircraft avionics project. Maybe you have an idea for another issue I have there which is handling the offsets at startup if the IMU is not in a "stabilized" attitude at start-up. For example think of the IMU mounted in the panel of a taildragger airplane. At rest on the ground it is in a pitch up attitude. You know the angle, so you could account for the angled gravity vector and calculate the offsets. But then what if you park your airplane on a 5% slope?? I am looking for an idea on how to handle the offsets when the initial attitude is not precisely known. The particular application I am thinking of could see pitch and roll off by up to maybe 15 degrees at startup.
Comment by Lorentz on October 9, 2009 at 11:34am
@Doug - sorry, my fault: I was mislead by line 95 in file ArduIMU_DCM_V11.pde:

float speed_3d=0; //Speed (3-D) (not used)

Instead speed_3d is updated inside the GPS.pde file (which I didn't consider because I use different GPS parsing code). OTOH Premerlani's code has this estYawDrift() function that returns course over ground coming from GPS only if GPS has valid data, otherwise it returns a filtered version of the direction coming from DCM matrix itself.
Comment by Michael Zaffuto on October 9, 2009 at 3:05pm
@Doug - It may be possible to use a 3-axis magnetometer, for use only at initial startup of IMU, to calulate the taildraggers angles and heading. No electrical interference would be present at that point. The data would be used by the Pyramidally mounted IMU to determine the relative amount of the gravity each of the 3 accelerometers should be seeing and thus calibrate. The gryos could then be given the appropriate initial angle, the gryos angle rotated from level flight seen at rest. After that, ignore the magnetometer and take off!
Comment by Mitch on October 9, 2009 at 4:53pm
Yaw drift occurs in roll_pitch_drift():

//*****YAW***************
errorCourse=(DCM_Matrix[0][0]*COGX) - (DCM_Matrix[1][0]*COGY); //Calculating YAW error
Vector_Scale(errorYaw,&DCM_Matrix[2][0],errorCourse); //Applys the yaw correction to the XYZ rotation of the aircraft, depeding the position.

Vector_Scale(&Scaled_Omega_P[0],&errorYaw[0],Kp_YAW);//.01proportional of YAW.

Vector_Scale(&Scaled_Omega_I[0],&errorYaw[0],Ki_YAW);//.00001Integrator

I'm in the process of modifying it to work with a 3-axis manometer instead of GPS. It is coming along quite well, I'll post soon.

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

111 members

137 members

1299 members

48 members

693 members