T3

09038-1_i_ma.jpg

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
E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

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.

  • T3
    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
  • T3
    Morli,

    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
  • T3
    J. Tess,

    You cannot change waypoints, with the DevBoard, in-flight via wireless comms right now. That is on our list of things to do.

    Bill
  • Does anyone know if you can change waypoints, with the DevBoard, in-flight via wireless comms?
  • T3
    Hi Rana,

    8b does not have racing, it is exactly the same as 8a, except for a minor bug fix.

    Best regards,
    Billu Bhaiya
  • Billu Bhaiya,

    Does 8b have racing by default or we can disable it if not required.

    Thanks & Best Regards

    Rana
  • T3
    Sid, Rana, Bryan, Peter, Paul, Ben, Scouser, and all of my other "test-pilots". You know who you are.

    I want to thank you all again for all the test-flights that you have made for me. You are truly "test-pilots". I appreciate the time and care that you have put into this project.

    Bill Premerlani
This reply was deleted.