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***************
COGX = cos(ToRad(ground_course));
COGY = -sin(ToRad(ground_course));
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_Add(Omega_P,Omega_P,Scaled_Omega_P);//Adding Proportional.

Vector_Scale(&Scaled_Omega_I[0],&errorYaw[0],Ki_YAW);//.00001Integrator
Vector_Add(Omega_I,Omega_I,Scaled_Omega_I);//adding integrator to the Omega_I

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

• ‹ Previous
• 1
• 2
• 3
• …
• 7
• Next ›
• Page