Roll-pitch-yaw demo of the direction cosine matrix is complete.

Comment by John_Mac on March 16, 2009 at 1:42pm

This is quite a setup! I have used gyros and accelerometers in various setups and the accuracy is impressive. Is there any benchmarking info on how this system compares to the ArduPilot using IR sensors? There is quite a cost differential, but bet the performance is much better.

Comment by William Premerlani on March 16, 2009 at 3:23pm

John,
I do not have any experience with IR sensors, so I cannot make any comparison. I can only comment on the performance of the algorithm and hardware that I am using.
Accuracy in the estimation of roll, pitch, and yaw is about 1 degree. Transient response is 0.025 seconds. I plan to use this system for aerobatics, possibly even stabilizing a Harrier Jump Jet.
By the way, it is my understanding that the ArduPilot has the ability to interface to a 6 degree of freedom IMU. If so, it would be possible to port my algorithm to the ArduPilot, if anyone cares to do it.

Bill

Comment by John_Mac on March 16, 2009 at 7:13pm

Thanks Bill

I hope to follow your work.

Comment by Mitch on March 19, 2009 at 8:31pm

How does this compare to, say, a Sparkfun 5DOF with the open source Propeller Kalman filter?

Comment by William Premerlani on March 20, 2009 at 5:53am

Mitch,
This method is superior to a Kalman filter approach, because it fully respects the non-linearities of the rotation group. It has better transient response and is more accurate. For more information, you might want to read a paper on the subject published by Mahony et al.

Comment by Alvin Tan on March 28, 2009 at 8:34pm

Bill,

I am an undergraduate at Carnegie Mellon working together with Matthew Lim on our heli stabilization project. I was reading through your adj_accel() function and I had a couple of questions. If I'm not wrong, you're computing the centrifugal effects using gps information. If the gps unit is not hooked up to the board, adj_accel() will not adjust the variables gplane[0] and gplane[1]. If so, is there anyway you can account for the centrifugal effects without using gps information?

Also, I'm a little confused about your output_matrix(void) function. In your comments, you mentioned that you would be setting the three servos to the three values in the diagonal of the matrix. If I understand how you're representing your matrix correctly, shouldn't the diagonal be rmat[0],[4],[8] or rmat[2],[4],[6], as opposed to rmat[6],[7],[4] as written in your code?

Alvin Tan

Comment by William Premerlani on March 29, 2009 at 2:08am

Alvin,
Regarding my output_matrix(void) comment, you are 100% correct. There was a time when I output rmat[0],[4],[8]. However, during my testing, I changed which elements I output many times, and I didn't change the comments. Sorry.
Regarding centrifugal effects, you can ignore transient centrifugal acceleration, because the low gain of the drift adjustment feedback loop filters them out. It is only sustained acceleration that you need to worry about, which arises in a plane at high speed in a continuous turn. You will not need to worry about centrifugal acceleration in a hover, so you could operate without a GPS and not do the centrifugal adjustment, provided you did not attempt to do sustained high speed flight in a continuous turn.
Bill

Comment by UFO-MAN on March 31, 2009 at 12:55pm

Hi Bill, I am trying to understand your code (I didn't understand the stuff on page 4,5,6 in the MahonyChaHamel article at the moment unfortunately so I need your help).

It looks like these functions are the core workers in the loop:

read_gyros() ;
read_accel() ;
adj_accel() ;
rupdate() ;
normalize() ;
roll_pitch_drift() ;
yaw_drift() ;
output_matrix() ;

I am trying to understand the main overall DATAFLOW in your code and I have understood that the data is stored in matrixes. However, is it possible for you to explain what the columns in the rows and columns in the matrixes contain?

For example, lets take rmat[] = { a ,b , c , d , e , f , g , h , i }; (the letters is put there by me)
Is this actually a 3x3 matrix where each column with three rows is a vector? The path from the origin to the tip are represented by the vector tip coordinates stored in row 1,2,3 in each column in fixed point format?
Something like this
a d g
b e h
c f i

Vector 1 is (a,b,c)
Vector 2 is (d,e,f)
Vector 3 is (g,h,i)

If this is correct: are those three vectors stored in that matrix supposed to be orthoginal (90 degree relationship)?

Is the gist of the algorithm that this "three vector system" (that is supposed to always be normal to each other) is rotating when the plane rotates and we assume that the earth reference frame is fixed? The algorithm is basically a numerical vector updating (integration) and housekeeping (normalization) engine?

Questions:

How does the data propagate from the accellerometers, gyros and gps into the matrix? How is that handled? In small time steps? Each delta T the change in the gyros and accelerometers is updated into the matrix?

How does the corrections for drift as well as GPS data occur?

Suggestion:
Is it possible for you to make a FLOW DIAGRAM with matrixes drawn in graphically so that I can understand how the data propagates? (Would it be possible to do it on a piece of paper that you scan ?). Alternatively, is it possible to make a short pre version of your paper?

I cant wait to work on this. I have both a heli and a plane that waits for this.


UFO-MAN

Comment by muhammad jawad majid malik on April 8, 2009 at 9:37pm

UFO-MAN
Hi
Are you planning to use the Dev Board for your Heli?
I have also a Heli waiting to be installed with the Dev Board for stabilization purposes-initially!
I would like to keep in contact with you and may like to benefit from your experience,kindly.
Sincerely,
muhammad

Comment