If you downloaded MatrixNav from this page before 4/29/2009, you should be aware that there is a newer version of the firmware, MatrixNavRv2, that reduces the GPS latency, and will perform much better than the first version.

I have been working with Paul Bizard on something we call the "Premerlani-Bizard robust direction cosine matrix estimator". It is based on the work of Mahony et al. The idea is to continuously update the 3X3 matrix that defines the relative orientation of the plane and ground reference frames, using GPS and 3 gyros and accelerometers. The basic idea is to use gyro information as the primary link between the two reference frames, and to use GPS and accelerometer information to compensate for gyro drift. We are working on the theory together. Paul is performing simulations. I am testing ideas in my UAV DevBoard. We have made a great deal of progress. There are demos available, and control and navigation firmware is available. The steps of the algorithm are:
1. Use the gyro information to integrate the nonlinear differential equations for the time rate of change of the direction cosines.
2. Renormalize the matrix to guarantee the orthogonality conditions for a direction cosine matrix.
3. Use speed and gyro information to adjust accelerometer information for centrifugal effects.
4. Use accelerometer information to cancel roll-pitch drift.
5. Use GPS information to cancel yaw drift.

By the way, the algorithm should work in any GPS, gyro, accelerometer nav system on a plane. Without magnetometer information, it will not work on a helicopter.

This discussion will provide progress reports from time to time. At this point we have completed all steps. Firmware and documentation for various demos and flight firmware are available on the UAV DevBoard main page.

Firmware and documentation of a roll-pitch-yaw demo program are available. There is also a first draft of an explanation of the algorithm.

If you have a UAV DevBoard, I highly recommend that you try the demo program, it is very easy to use, and runs without a GPS. During its development, I found that the gyro drift was much less than I thought it would be. After I added the drift compensation, the resulting roll-pitch peformance is nothing less than astounding.

Flight testing of "MatrixNav" is also complete. Firmware and documentation are available on the UAV DevBoard main page for stabilization and return-to-launch functions for inherently stable aircraft that are controlled by elevator and rudder. MatrixNav is implemented with a direction cosine matrix, and supercedes GentleNav. Anyone who has GentleNav should replace it with MatrixNav. Pitch stabilization is excellent under all conditions. Return to launch performance is excellent under calm conditions, and good under windy conditions. If you have the UAV DevBoard and an inherently stable plane, you will definitely want to try out MatrixNav.

Finally, AileronAssist, for the stabilization and RTL aircraft that have ailerons, is available.

What Paul and I are going to tackle next is altitude control.

Bill Premerlani

Views: 24444

Reply to This

Replies to This Discussion

Hi Bill

I have been trying to write a matlab code using the dcm imu theory. i had one question though. Is yaw angle and heading of the aircraft same? As in isnt it possible for and aircraft to point in one direction and have an overall heading in another... if so is there anyway to find the heading from the pitch, roll and yaw?

Regards

Naomi

Naomi,

Yaw angle is heading, which is the direction the aircraft is pointing, which is not the same as which direction the aircraft is moving (course over ground) because of the wind. You can compute one from the other if you know the airspeed of the aircraft and the wind vector.

The earliest version of MatrixPilot used GPS course over ground for navigation, which does not need to concern itself with the wind. However, GPS has latency.

So, we switched to heading, because that comes from IMU without latency. But for that you need to compensate for wind.

Two years ago we were able to achieveIMU "dead reckoning", which provides course over ground without any latency. So we switched back to course over ground for navigation in MatrixPilot, providing better navigation performance.

Best regards,

Bill

Hey Bill

Thank you so much for your reply. It makes sense now. Been looking for this answer everywhere. Thanks a lot.

Regards

Naomi

Dear Bill 

I'm reading your perfect paper(DcmDraft2)

please let me ask a problem if I may.

in the paper, we got "a convenient matrix form" in Eqn 17

we know the new "DCM“ is not a definite  DCM for its magnitude is not 1 ,and each vector member is not orthogonality.so the next step is "Renormalization"

In my understand ,although we get a new definite DCM after renormalization,but it is still an approximate one  to the  true accurate dcm. anyway this renormalized DCM is acceptable in such a little time slice(eg: 0.02s)

However, I wonder  that there will be an apparent error(or deviation) after a long time 's calculation.

(we assume that the gyro output is very accurate)

I mean every renormalization process will create deviation,and these deviation will accumulate into a "big" DCM error.

Is it possible? 

sorry for my poor english.

Thanks.

Dear  Bill

quote:

the bottom row of the direction cosine matrix should be aligned with the vector produced by the accelerometers

May I know the reason why these two vectors should be aligned ?under what condition?

because,from the earth frame. the plane also can own an acceleration other than the Z-axis(earch reference). it is a normal case i think.

so i am confused why we know it is a gyro drift when there two vectors are not aligned

maybe gyro has no drift ,and currently the plane is accelerating in some direction .therefore 

the accelerateometer's output is also not aligned to earth Z-axis

Thanks

Dear

Regarding the Eqn 26 in the paper(DcmDraft2)

I think 

the acceleromter is aligned with the plane(body).so its output is the combination result of gravity and centrigual acceleration.

and we only need the gravity acceleration as our reference vector.

so the equation should be (Vector) as follows?

g_reference = Acceleration - centrigual acceleration

I confused with the Eqn26

Thanks.

Additions:

for example. the x-axis has the whole Centrigual acceleration(Vector C). the Gravity works in z-axis (Vector G)

under this condition. the Accelerometer will output the result  Vetor  A = C + G

so if we want to get the G, we need A-C,but the Eqn.26 shows G= A+C

may I know the reason?

sorry for the stupid question .

I have known it . 

the sign is negative if exchange the cross product of them

Johnson,

Thanks for your questions.

Regarding renormalization introducing drift, in practice, it does not create much drift. I have done static (motionless) tests on the UDB5 hardware with drift correction turned off and measured the residual drift from all sources (such as noise, renormalization, offset shift) to be on the order of one degree per minute. There are much larger sources of error in flight due to gyro calibration errors. See for example:

http://diydrones.com/profiles/blogs/sustained-rotations-pushing

In any case, you need to apply continual drift compensation in flight to prevent accumulation of attitude estimation error. This is done with the aid of known reference vectors.

Regarding the bottom row of the matrix, it represents the image of the earth vertical axis in the body frame. You can use the accelerometer as a reference vector for vertical if you compensate for centrifugal acceleration. There are a couple of ways of doing that, DCMDraft2 describes one way to do it, the following describes another way:

http://diydrones.com/forum/topics/an-improved-method-for-accounting...

Regarding the interpretation of the sign of the accelerometer data, depending on your preference, you can think of it as producing gravity minus acceleration, or acceleration minus gravity. I have been told by some of the members of the MatrixPilot team that the way that I think of it is opposite to the rest of the world, so I apologize if I have confused you.

Finally, here is another source of information on this subject, it is nicely organized, fun to read and easy to understand:

http://www.starlino.com/dcm_tutorial.html

Best regards,

Bill

Dear

Thanks very much for your elaborate answer.

I can understand it now.

Thanks

Dear I reviewed the Eqn14~17 which someone feels confused maybe. would it be better if we add some tips or comments about this setction
1. the θ(x/y/z) in the matrix of Eqn 17 stands for the magnitude of the Vector : dt * W(x/y/z) X r(t)
not the angel between the r(t) and r(t+dt)
while the definite DCM use the cosin of this angle.

2. I draw a draft and try to distinguish them
and I am not sure it is correct but i think so. I hope this will help other readers

new draft

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service