Sigh....I am going to give Peter Hollands an award for finding the "juiciest bug" in the released waypoint firmware for the UAV DevBoard. The bug has been fixed, and the firmware has been re-released as version 1.8b.The bug was in the yaw drift gyro compensation calculation. It would only show up for waypoint legs with a heading between 327 degrees and 360 degrees. The result was that the actual heading would slowly vary between 327 and 360 degrees. The symptoms were barely noticeable.The way that Peter discovered the bug was with a combination of ground testing and telemetry, while he was testing out some really nice programs that he wrote for processing telemetry. Peter noticed an anomoly during ground testing for headings between 327 and 360 degrees.Waypoint firmware for the UAV DevBoard is available in both MatrixNav version 1.8 and AileronAssist version 1.8 from the UAV DevBoard home page, with the following features:• Waypoints are 3D.• Location of the points is specified relative to the initialization location of the board.• You have the option of using either cross-track error navigation, or using navigation toward target waypoints.• Arrival at a waypoint is based on the concept of a "finish line". This produces a reliable assessment of arrival, without any chance of loitering.• The primary source of steering is the direction cosine matrix, so steering continues reliably and smoothly even when the GPS loses lock during banked turns.• Rudder-elevator mixing in MatrixNav, based on the values of the direction cosines, prevents loss of altitude during turns.• You can specify more than 1000 waypoints.Just to be clear, the X and Y coordinates of each waypoint are specified with respect to the power up point. It is not specified with respect to the previous waypoint in the list. The X coordinate is the distance, in meters, along the east direction, from the power up point. The Y coordinate is the distance, in meters, along the north direction, from the power up point.Best regards,Bill Premerlani
I've read about Ultimate performance by MatrixNav rev8 and it indeed is a good job. After reading your comments regarding matrix nav 8 I've decided to give it a try.As I"m a beginner with this platform and I need your help:will you please contact me at h33.migel@yahoo.co.in.
I've read about Ultimate performance by MatrixNav rev8 and it indeed is a good job. After reading your comments regarding matrix nav 8 I've decided to give it a try.As I"m a beginner with this platform and I need your help:will you please contact me at h33.migel@yahoo.co.in.
I've read about Ultimate performance by MatrixNav rev8 and it indeed is a good job. After reading your comments regarding matrix nav 8 I've decided to give it a try.As I"m a beginner with this platform and I need your help:will you please contact me at h33.migel@yahoo.co.in.
Hi Morli,
I see your point about the faster models, such as 60-80 mph.
I will keep the dead reckoning on our list of things to do. If any of the other team members, such as Pete, Rusty, Ben, Bryan, etc., have any interest, I will help them with implementation.
Bill
Thanks Bill for detailed explanation, I am breathing on his(Bryan) back the whole time. Loved the latest video too. Infact his video and other blogs that I have been following made me think in this direction particularly with regard to GPS refresh rate being beaten to death etc.
If I were to argue/discuss( like always with my Gurus), with faster Ublox , the dead reckoning approach the performance advantage is less only when the model/flying platform is slow(20-45 Mph) but would it not make a difference in/for faster model say 60-80 mph( stretched distance/gap between refresh/update points). If so pls do keep the interest in dead reckoning even if it is only at back of your mind, I am sure some day soon , we will reach at the performance boundary of multiplex easy flier/glider and clones and will loose the interest in slow flyers , and then faster toys will be new point of interest in DIY community. Thanks again , have been lurking in shadow for quite some time and will continue to do so for few more months,
Yes, you can do what suggest. In fact, I have done it and tested it, I just did not release it, because it did not improve performance that much at the time, so I took it out. (It turned out there were some other problems, which we finally solved, that were limiting the performance. One of them was an unintentional internal latency of 2 seconds in processing waypoints, the other was an error for headings between 327 degrees and 360 degrees.)
What I implemented was "dead reckoning". That is, I used the IMU to determine attitude of the plane, and integrated the velocity vector to compute the location of the plane, instead of using the GPS. The GPS was used as input to a complementary filter that corrected for drift in the computed values of location and velocity.
The main challenge for me of such a "dead-reckoning" approach is estimating the velocity over ground, particularly when turning into a strong cross wind. You need either a measurement of airspeed, or a good estimate of wind speed.
With the EM406 there is a 2-3 second latency, plus a 1 Hz refresh rate, so for that, a dead-reckoning approach makes some sense, particularly for planes with high airspeeds.
For something like the ublox, there is less point of a dead-reckoning approach, because of its low latency and high refresh rate, you would not get much more performance from a dead-reckoning approach.
I still have some interest in a dead-reckoning approach, but I am not sure if I will ever get around to trying it again, because the recent improvements we have been making in the unreleased versions of the firmware for the UAV DevBoard have been working rather well. For example, you might want to take a look at the latest postings on Bryan Cuervo's latest blog.
Bill,
I have silly/absurd question? Is there a possibility of predicting ETA for next WP / course based on history of GPS readings for slow1/5 Hz refresh rated GPS and using the virtual GPS reading to react for next course of action as per code/flight plan. What is the point? Point is to virtually increase the refresh rate , to be proactive than be reactive to position reports. smoother turns , cleaner course tracks , events/action triggers based on predictive records. The predicted GPS records populating one more matrix which gets corrected/updated/reset by new real readings every 5 seconds or what ever refresh rate is. The point of such excersice is not for attitude stabilization but more towards cleaner entries and exit at WPs. Is this already done else where but beyond scope of this diy AP? I do remember reading in another post few days back some thing similar being done but would like to hear your opinion.
Comments
Dear Rana,
I've read about Ultimate performance by MatrixNav rev8 and it indeed is a good job. After reading your comments regarding matrix nav 8 I've decided to give it a try.As I"m a beginner with this platform and I need your help:will you please contact me at h33.migel@yahoo.co.in.
Dear Rana,
I've read about Ultimate performance by MatrixNav rev8 and it indeed is a good job. After reading your comments regarding matrix nav 8 I've decided to give it a try.As I"m a beginner with this platform and I need your help:will you please contact me at h33.migel@yahoo.co.in.
Dear Rana,
I've read about Ultimate performance by MatrixNav rev8 and it indeed is a good job. After reading your comments regarding matrix nav 8 I've decided to give it a try.As I"m a beginner with this platform and I need your help:will you please contact me at h33.migel@yahoo.co.in.
I see your point about the faster models, such as 60-80 mph.
I will keep the dead reckoning on our list of things to do. If any of the other team members, such as Pete, Rusty, Ben, Bryan, etc., have any interest, I will help them with implementation.
Bill
If I were to argue/discuss( like always with my Gurus), with faster Ublox , the dead reckoning approach the performance advantage is less only when the model/flying platform is slow(20-45 Mph) but would it not make a difference in/for faster model say 60-80 mph( stretched distance/gap between refresh/update points). If so pls do keep the interest in dead reckoning even if it is only at back of your mind, I am sure some day soon , we will reach at the performance boundary of multiplex easy flier/glider and clones and will loose the interest in slow flyers , and then faster toys will be new point of interest in DIY community. Thanks again , have been lurking in shadow for quite some time and will continue to do so for few more months,
Yes, you can do what suggest. In fact, I have done it and tested it, I just did not release it, because it did not improve performance that much at the time, so I took it out. (It turned out there were some other problems, which we finally solved, that were limiting the performance. One of them was an unintentional internal latency of 2 seconds in processing waypoints, the other was an error for headings between 327 degrees and 360 degrees.)
What I implemented was "dead reckoning". That is, I used the IMU to determine attitude of the plane, and integrated the velocity vector to compute the location of the plane, instead of using the GPS. The GPS was used as input to a complementary filter that corrected for drift in the computed values of location and velocity.
The main challenge for me of such a "dead-reckoning" approach is estimating the velocity over ground, particularly when turning into a strong cross wind. You need either a measurement of airspeed, or a good estimate of wind speed.
With the EM406 there is a 2-3 second latency, plus a 1 Hz refresh rate, so for that, a dead-reckoning approach makes some sense, particularly for planes with high airspeeds.
For something like the ublox, there is less point of a dead-reckoning approach, because of its low latency and high refresh rate, you would not get much more performance from a dead-reckoning approach.
I still have some interest in a dead-reckoning approach, but I am not sure if I will ever get around to trying it again, because the recent improvements we have been making in the unreleased versions of the firmware for the UAV DevBoard have been working rather well. For example, you might want to take a look at the latest postings on Bryan Cuervo's latest blog.
Best regards,
Bill
I have silly/absurd question? Is there a possibility of predicting ETA for next WP / course based on history of GPS readings for slow1/5 Hz refresh rated GPS and using the virtual GPS reading to react for next course of action as per code/flight plan. What is the point? Point is to virtually increase the refresh rate , to be proactive than be reactive to position reports. smoother turns , cleaner course tracks , events/action triggers based on predictive records. The predicted GPS records populating one more matrix which gets corrected/updated/reset by new real readings every 5 seconds or what ever refresh rate is. The point of such excersice is not for attitude stabilization but more towards cleaner entries and exit at WPs. Is this already done else where but beyond scope of this diy AP? I do remember reading in another post few days back some thing similar being done but would like to hear your opinion.
You cannot change waypoints, with the DevBoard, in-flight via wireless comms right now. That is on our list of things to do.
Bill
8b does not have racing, it is exactly the same as 8a, except for a minor bug fix.
Best regards,
Billu Bhaiya
-
1
-
2
-
3
-
4
of 4 Next