If you have a UAV DevBoard, and are anxious to do some flying with it, you should skip the GentleNav firmware and wait for MatrixNav, it is almost done, and will perform a couple of orders of magnitude better than GentleNav.GentleNav was originally developed for my previous board, which used the ET312 GPS, 2 gyros, and 2 accelerometers. The algorithm was rather simple, but worked well enough and I used it for several years.This season I decided to design a better board to use 3 gyros and 3 accelerometers to improve performance. Recently, I have been working with Paul Bizard on a "direction cosine matrix" approach to estimating orientation. It shows great promise, and is almost done.In the meantime, I thought that owners of the new board would want something to fly with, so I ported the GentleNav firmware from my previous board to the new one. Today was the first day I actually flew it, up until now I have been doing bench testing.Well, GentleNav does not work as well on the new board as it did on the old board. I traced the problem to the EM-406. It turns out that the dynamic response of the EM-406 is not nearly as good as that of the ET312. It takes the EM-406 around 15 seconds to respond to a 90 degree turn, while the ET312 responds almost instantly. Because of this large dynamic time lag, the GentleNav firmware is not stable in the return-to-launch mode.I could probably experiment with the feedback gains and get GentleNav to work with the EM-406, but since MatrixNav is almost done, I have decided to declare GentleNav to be obsolete and to focus my time on finishing MatrixNav, which should be available in a few days, a couple of weeks at the most. MatrixNav will completely resolve the issue with the dynamic delay, since it uses mainly the gyros rather than the GPS for direction information. The direction cosine matrix algorithm has a convenient way to compensate for GPS delay. MatrixNav is almost done, but I want to perform extensive flight testing before releasing it.So I suggest you wait for MatrixNav before using your UAV DevBoard in flight. Of course, if you do not want to wait, you are welcome to experiment with GentleNav, but I do not recommend it.In the meantime, you might want to try the roll-pitch-yaw demo to gauge what the performance of MatrixNav might be.Bill Premerlani
John,
All of my control and navigation code is going to be in Cartesian coordinates. Everything that I want to do can be done there. If there is anything that I need to use that is in polar, such as course over ground, the first thing I do is do convert it to Cartesian.
Everything from there is done in terms of vector cross and dot products.
I find it somewhat ironic that the one course I hated most in college, Vector Algebra, is the one thing that is now serving me so well in what I am doing with DCM.
Best regards,
Bill
I thought a transform back to Euler angles might be needed to do the PID since these map pretty directly to the servos....but I will await your release and pour thru the code...I figured you had it all worked out!
Regarding John's question about the EM406 versus the ET312 with respect to response latency in reporting course over ground, it is my impression that the ET312 is being discontinued, and that the EM406 is now the "workhorse". In any case, since Paul and I have figured out a way to work around the latency using the direction cosine matrix, I have put the issue of GPS latency at a low priority for now.
However, I encourage anyone else who is interested to look into the issue. I spoke with Louis LeGrand today, he is planning a comparative study of the latency characteristics of several GPS radios. In particular, he volunteered to take a closer look at the EM406. Possibly its latency in reporting course over ground may depend on which message you are using. I am using the course-over-ground navigation information. Louis is going to take a look at whether Vx, Vy, Vz in ECEF coordinates might have a shorter latency. Lets hope.
I also offer the observation that there are lots of people using Chris Anderson's ArduPilot and an EM406, so the response of the EM406 must be good enought to build an autopilot around it.
I think I read your post incorrectly, I need to remember to not use the internet when I wake up! You are right that the DCM is used for control, but it might be interesting to use quaternions in the control loop. Always impressed with your work though!
On the question of which is the "best" representation to work in, I believe there is a singularity in the DCM c33 element due to a sec(theta) term. I have seen some work arounds for this, but is mostly an issue for 3D maneuvers where the pitch can go straight up or down. My hope was that the new system would in fact be useful for 3D. It also raises the question of Taylor expansions (if used) to linearize the equations...could be a problem.
Quaternion representation has it's own problems, like spreading the error from one Euler angle to all since the elements are linear combinations of all of them. So just have to see what works best for this application.
I think it's a valuable discussion to have, since I really see the benefit of all of these open source developments as more than just getting a black box that works, but an educational process for those that want to understand things at a fundamental level.
I have been impressed with what I have seen from Bill and Paul so far, so I'm sure they have thought of all this. I just need to wait and see the release.
Is there a reason to go to the EM406 over the ET312 if it suffers from this major delay? I would probably use the GPS unit for more than the UAV Dev Board and would like to buy only one...and get the best one for the money.
Actually you don't need the DCM for the body transformation, you can use the elements of the quaternion vector for the entire transformation matrix. And since its all linear operations, it is faster. The singularity in the DCM comes when the pitch angle approaches 90 degrees. I have seen this many times in multiple autopilots as well as simulations. Usually not a concern for UAV's obviously.
Bill, with the hardware you have, you do have a lot of space available, I didn't realize you were using a dsPIC. But again, the quaternion can be used for everything on the navigation side, not sure on the control side since I don't cover that yet.
Again, there is never a need to go quaternion to DCM on the guidance and navigation side, and probably not on the control side with some careful writing of the control laws. Just something to think about, and certainly for people using less powerful hardware.
Hi octane,
I agree with Paul's comments. In addition, the direction cosines are natural for other calculations, particularly in transforming between body and earth coordinate systems or for control or navigation. For example, for navigation, it is straightforward to take cross and dot products of one of the columns of the DCM with the direction of travel vector to determine how much to turn the aircraft to get it back on course.
Regarding computational power, I have done some measurements that show that DCM takes only 2% of the CPU power of the dsPIC30F4011, with a 16MHz clock. Since I also have the option of clocking up to 120MHz, there is CPU power to spare.
If I were squeezed for computational requirements, then I might do a side by side comparison of DCM and quaternions, but I do not think there would be much difference.
I have followed the progress of your hardware for a couple of years now, I have a suggestion for you though. Instead of the DCM approach, you may want to consider quaternions. They are much faster computationally, although not as intuitive. If you wish to discuss more, let me know. I have been developing the theory for simulation and would be willing to share with you. let me know if you are interested.
Comments
All of my control and navigation code is going to be in Cartesian coordinates. Everything that I want to do can be done there. If there is anything that I need to use that is in polar, such as course over ground, the first thing I do is do convert it to Cartesian.
Everything from there is done in terms of vector cross and dot products.
I find it somewhat ironic that the one course I hated most in college, Vector Algebra, is the one thing that is now serving me so well in what I am doing with DCM.
Best regards,
Bill
However, I encourage anyone else who is interested to look into the issue. I spoke with Louis LeGrand today, he is planning a comparative study of the latency characteristics of several GPS radios. In particular, he volunteered to take a closer look at the EM406. Possibly its latency in reporting course over ground may depend on which message you are using. I am using the course-over-ground navigation information. Louis is going to take a look at whether Vx, Vy, Vz in ECEF coordinates might have a shorter latency. Lets hope.
I also offer the observation that there are lots of people using Chris Anderson's ArduPilot and an EM406, so the response of the EM406 must be good enought to build an autopilot around it.
Bill
I think I read your post incorrectly, I need to remember to not use the internet when I wake up! You are right that the DCM is used for control, but it might be interesting to use quaternions in the control loop. Always impressed with your work though!
Spencer
Quaternion representation has it's own problems, like spreading the error from one Euler angle to all since the elements are linear combinations of all of them. So just have to see what works best for this application.
I think it's a valuable discussion to have, since I really see the benefit of all of these open source developments as more than just getting a black box that works, but an educational process for those that want to understand things at a fundamental level.
I have been impressed with what I have seen from Bill and Paul so far, so I'm sure they have thought of all this. I just need to wait and see the release.
Is there a reason to go to the EM406 over the ET312 if it suffers from this major delay? I would probably use the GPS unit for more than the UAV Dev Board and would like to buy only one...and get the best one for the money.
Bill, with the hardware you have, you do have a lot of space available, I didn't realize you were using a dsPIC. But again, the quaternion can be used for everything on the navigation side, not sure on the control side since I don't cover that yet.
Again, there is never a need to go quaternion to DCM on the guidance and navigation side, and probably not on the control side with some careful writing of the control laws. Just something to think about, and certainly for people using less powerful hardware.
Cheers,
Spencer
I agree with Paul's comments. In addition, the direction cosines are natural for other calculations, particularly in transforming between body and earth coordinate systems or for control or navigation. For example, for navigation, it is straightforward to take cross and dot products of one of the columns of the DCM with the direction of travel vector to determine how much to turn the aircraft to get it back on course.
Regarding computational power, I have done some measurements that show that DCM takes only 2% of the CPU power of the dsPIC30F4011, with a 16MHz clock. Since I also have the option of clocking up to 120MHz, there is CPU power to spare.
If I were squeezed for computational requirements, then I might do a side by side comparison of DCM and quaternions, but I do not think there would be much difference.
Best regards,
Bill
I have followed the progress of your hardware for a couple of years now, I have a suggestion for you though. Instead of the DCM approach, you may want to consider quaternions. They are much faster computationally, although not as intuitive. If you wish to discuss more, let me know. I have been developing the theory for simulation and would be willing to share with you. let me know if you are interested.
Spencer
-
1
-
2
of 2 Next