Implementation of the direction cosine matrix is complete. Firmware and documentation are available. Those of you who have purchased a UAV development board are definitely going to want to try the demo to gauge the possibilities for IMU based flight control. Performance is impressive.The picture above is the setup that I used to test the firmware. There are 3 servos, a GPS, the board, and a battery that are attached with velcro to stiff cardboard. I used it to walk the board around the neighborhood. I also attached the whole thing to my car dashboard with velcro, and went around a local traffic circle as fast as I could.Best regards,Bill Premerlani
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
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:
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.
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
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?
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.
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.
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.
Comments
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
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
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
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
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.
I hope to follow your work.
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