UAV DevBoard Pilots,If you are using a version of MatrixNav or AileronAssist on a "redboard" that was released before August 5, 2009, there are a couple of revisions that you can make that will improve overall performance.First, you should modify the definition of RADPERSEC in the file optionsRmat.h to:#define RADPERSEC ((long long)5632.0/SCALEGYRO)Just change the definition of RADPERSEC that is already there.In the previous releases, SCALEGYRO was not included, so the scaling in the centrifugal acceleration compensation was correct for the green board only. Many thanks to Sid, who was never quite satisfied with the high acceleration behavior of the red board firmware, for motivating me to find out why. If you include SCALEGYRO in the definition of RADPERSEC, you will improve the performance of the red board firmware for high acceleration applications. Green board firmware will not be affected.Also, you should modify the rmat.c file to use the following values of the drift correction PI gains:#define KPROLLPITCH 256*10#define KIROLLPITCH 256*2#define KPYAW 256*4#define KIYAW 32Just edit the definitions that are already in rmat.c to use the above values.Based on a lot of simulations done by Paul Bizard, and a lot of flight testing by Sid, we have concluded that these values will produce the best performance possible for the red board.The gains in the first release of the firmware for the green board are very low. Although these values provide great accuracy for the green board, when I designed the red board, I was concerned about the security of locking, particularly with the 4X change in the gyro gains, so I decided to use much larger gains for the red board.The gains in the released firmware for the red board are very high. Although this provides secure locking, it is not as accurate, leading to pitch and roll errors during rapid turns at high speed.The latest values provide a much better compromise between accuracy and security.The changes described in this post have been included in MatrixNav and AileronAssist release 1.5, August 5, 2009.Thanks again to Paul Bizard and Sid for their hard work.Best regards,Bill
Read more…T3
The UAV Devboard is back in stock at SparkFun, with a new design.The reason for the design change is that Analog Devices no longer makes the gyro that we were using on the previous board, so we have switched the design to the LISY300AL. Paul Bizard and I have thoroughly tested the new board on fixed-wing aircraft, the LISY300ALs work just great with DCM.We have modified all of our existing firmware to be able to run on either board, and will make sure that all future firmware will also work on either board. If you have written firmware for the UAV dev board, you will only have to make a few minor changes to run it on the new one. The two board designs are nearly identical. The only differences are:1. The new board uses LISY300AL gyros instead of the ADXRS401, and the 6g range instead of the 1.5g range for the accelerometers. This will allow you to provide aerobatic control without saturating the sensors.2. The gyros, the accelerometers, and the A/D reference voltage are all tied to the 3.3 volt regulated supply. This will totally eliminate drift of gyros and accelerometers due to supply voltage changes.Each firmware project now has both a "green" version for the previous board and a "red" version for the new board.
Read more…T3
Flight testing of "AileronAssist" is complete. This is the firmware that I had in mind when I started out. It controls ailerons and elevator to stabilize neutrally stable aircraft and performs return to launch. I was able to use it to fly a Goldberg Endurance with some confidence and ease. This is an aircraft that I crashed 5 times last summer. I have finally soloed with it, though most of the credit goes to "AileronAssist", to Paul Bizard, and to everyone else who has helped me so far.Above is a picture of my Endurance, with the electronics mounted on top with velcro, just like I tell everyone else not to doThe firmware and documenation is available on the main page for UAV DevBoard. For those of you who have the board and have tried MatrixNav, the next step is to try AileronAssist in a neutrally stable aircraft. I think you are going to like it. Its smoother and more precise than I ever imagined it could be.The weather is good today, I am going to get out of here and go do some flying.Best regards to everybody,Bill PremerlaniPS For those of you waiting for restocking of the UAV DevBoard, the first board off the production line is on its way to me. When it arrives, I am going to do thorough flight testing with it before releasing it. I will make an announcement.
Read more…T3
Revision 2 of MatrixNav firmware has been flight tested and is now released. The documentation and operation stays the same as for the previous version. The link on the main page for the UAV DevBoard points to the new version. The documentation is available there, also.The baud rate for the binary serial interface to the GPS has been raised in this version from 4,800 to 19,200. This eliminates a 12 second delay in the GPS information that was present in the previous version. As a result, performance in windy conditions has been improved.If you are using the previous version of MatrixNav, replace it with this version. If you made any changes to the control gains in the file controlGains.h, be sure to either save your existing file, or record the values that you are using, and edit the controlGains.h file that is part of the new firmware.The YAWKP and YAWKD gains in the new version have been lowered from the previous version by a fair amount, so that the turns are wider and smoother. In the previous version, a switch to RTL mode would result in your plane "turning on dime". In one of the comments below, Sid recommends lowering the gains. Just so there is no confusion, you should understand that they have been lowered.Also, in the previous version of MatrixNav, YAWKP and YAWKD were postive. In this version they inadvertently wound up to be negative. So if your plane is already set up with the previous version, either make YAWKP and YAWKD positive, or toggle the position of switch SR1 on your board.Bill Premerlani
Read more…T3
I have the issue of the latency in the dynamic response of the EM406 GPS in binary mode finally resolved: you have to run at 57,600 baud in binary mode. Apparently there is a large communications buffer in the EM406 that gets flushed by the carriage return/line feeds in NMEA mode, but which does not get flushed in binary mode, unless you run at 57,600 baud. There must have been a memo on this, but I missed it.I will revise the MatrixNav code and release it as soon as I can give it a test flight. The drop in latency from 12 seconds to a few seconds should vastly improve the performance in windy conditions.Thank you all for your help, especially Chris Anderson, Jack Crossfire, and automatik.I should have listened to you, Jack. Next time I will.By the way, the EM-406A performs very well with respect to sensitivity and fast response. Now that I have resolved the binary interface issue, it performs as well as any of the other GPS radios that I tested. I plan to continue using it in future designs. There really is no point to using GPS units with reporting rates that are faster than 1 Hz. As far as I can tell, all they do is interpolate.Bill Premerlani
Read more…T3
The mystery of the 12 second latency in the dynamic response of the EM406 GPS is solved.Recently, I stirred up a debate about whether or not the EM406 has a 12 second latency or not. A few of us were seeing a 12 second latency. The majority of EM406 users were not seeing it.It turns out that the dynamic performance of the EM406 depends on which interface you use, NMEA or binary. If you use binary, there is a 12 second latency, then a 3 second "smoothing" transient.If you use NMEA, there is a smoothing transient only. The NMEA interface to the EM406 provides dynamic performance as good as the LOCOSYS or the ET312.It is my speculation that "track smoothing" is turned on in the EM406 for the binary interface, and either it is always on, or I have not figured out how to turn it off. If anyone knows how to turn track smoothing off in the binary interface for the EM406, please let me know so that I do not have to scrap my binary interface and start over on a NMEA interface.
Read more…T3
Louis Legrand recently ported the direction-cosine-matrix firmware that Paul Bizard and I developed to the "IMUDOT", and made a video of a demo.Louis, thank you so much. Thank you.The video speaks for itself.Bill Premerlani
Read more…T3
Successful flight testing of MatrixNav is complete. MatrixNav is open source C firmware for the UAV DevBoard that provides pitch stabilization and return to launch functions for inherently stable aircraft that are controlled by rudder and elevator. MatrixNav is built on top of a method for integrating gyro signals into orientation information called direction-cosine-matrix (DCM). Flight tested firmware and documentation are available.A dozen test flights were made with an electric powered Gentle Lady under the following conditions:1. Both calm and windy conditions.2. Powered and gliding.3. Return to launch with the plane pointing away, toward, or perpendicular to me.4. Circling behavior under RTL control after the plane crosses the launch point.5. Hand launch in both manual and pitch stabilized modes.6. Landings with pitch stabilization turned on.MatrixNav completely solves an issue that I wrestled with in previous versions of my firmware: gyro cross coupling during a banked turn. If you attempt to use a pitch gyro signal to stabilize the pitch of a plane, it will measure a portion of the turn rate of the plane during a banked turn, and will cause the plane to dive into a turn if the bank angle is too great. The use of direction cosines eliminates the cross coupling and makes it simple to achieve a level turn at any bank angle.Furthermore, since MatrixNav relies mostly on gyros, not accelerometers, I was finally able to turn on pitch stabilization during hand launch.I added a feature to give the plane a kick during return to launch: you can program in the return to launch pitch angle. By deliberately pitching the nose down a bit, you can increase the return speed to better penetrate the wind.MatrixNav is intended for you to either use as-is, or to serve as the starting point for your own projects. So if you have a UAV DevBoard and want to use it to do some flying of an inherently stable plane, you will definitely want to try out MatrixNav.By the way, the MatrixNav documentation is not up-to-date about what the LEDs will do. Sorry about that, I really don't look at the LEDs anymore, they are usually hidden in my plane. Here is what they do:1. The LED on the EM406 will go out entirely, because MatrixNav puts the GPS communications in binary mode.2. Both LEDs on the the dev board will come on briefly during power up, to self test them.3. After power up, the green LED, stat2, will indicate whether or not MatrixNav is receiving valid pulses. It will be on continuously if there are valid pulses, otherwise it will go out.4. After power up, the red LED, stat1, will flash a few times, and then go out until the GPS is locked, and then it will resume flashing.After power up, MatrixNav goes through an initialization process that waits for both GPS lock and valid radio pulses. When pulses are received and when there is GPS lock, the rudder will wag a few times. When it stops wagging, MatrixNav records the present location as the return to launch point and you are cleared for takeoff.Bill Premerlani
Read more…T3
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
Read more…T3
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
Read more…T3
For those of you who bought a UAV DevBoard and who also live some place too cold to fly yet, I just finished a "roll-pitch-yaw demo" that you can use to show off your board. Firmware, documentation, and more details are available in a discussion of a direction cosine matrix estimator.Also, here is the firmware and documentation.The demo is rather impressive. It is a milestone in the project that I am presently working on with Paul Bizard. It uses mostly gyro information to compute the direction cosine matrix that specifies the relative orientation of two cartesian coordinate systems. In the demo, the cosines of the angles between the axes of the board and the vertical ground axis are output to 3 servos. Roll-pitch performance is smooth, accurate, and drift-free.The demo is fun and easy to run, does not require a GPS radio, does not require you to go outside, and will impress your friends.Bill Premerlani
Read more…T3
This is an update on two topics.1. A minor revision to GentleNAV RTL firmware.2. Progress to date on an algorithm to combine 3 axes gyro, accelerometer, and GPS information.1. While working on my next project, I discovered a minor error in the GentleNAV RTL firmware that runs on the UAV DevBoard.There are adjustments in the GentleNAV firmware to the pitch and yaw gyro signals to compensate for variation in A/D conversion of the gyro signals due to changes in battery voltage. Unfortunately, in doing the port from my previous board to the new board, I added the correction instead of subtracting. I did not notice the error during testing because I supply my board with regulated 5 volts from my electronic speed control.Anyway, I have revised both the code and the documentation.2. In case you are wondering what my next project is, I am presently working with Paul Bizard on a simple, fast, accurate algorithm for combining gyro, accelerometer, and GPS information into an estimate of the orientation of a plane. We do not have all of the details worked out, but we are making good progress.Today I implemented one of the components of the algorithm. Paul and I refer to it as update and normalization. It is a routine that uses gyro information only to update a matrix of direction cosine factors and maintains the orthogonality conditions. It works quite well, the drift is extremely low, on the order of a degree per minute. I can spin the board 10 revolutions forward and then 10 back, and the orientation estimate returns to the starting point.The bulk of the implementation uses vector and matrix library routines furnished by MicroChip that they tailored to the dsPIC30 hardware. Execution is very fast. Total execution time so far is 200 microseconds every 20 milliseconds using the 16 MHz clock.The next step is to adjust roll and pitch drift with accelerometer information. When I get that done, I will make that firmware available here as a demo.After that we will adjust yaw drift, and make adaptive gyro gain adjustments. We do not have all of the details worked out, but because of the astounding precision of the unadjusted algorithm, I do not think it will be very difficult.Bill Premerlani
Read more…T3
The UAV development board is back in stock at SparkFun.SparkFun also plans to eventually carry 12" cables for the GPS connection, which could be used for the UAV development board, as well as for Chris Anderson's ArduPilot. Sparkfun also plans to eventually carry 12" servo cables for connecting from the board to the RC receiver.Presently, there is C code available for getting you started with the UAV development board. There are two separate programs. One is for simply making sure that the board is working, used at SparkFun to test the boards before they ship. This one is available both at SparkFun and on this website, and is the program that is in the board when it is shipped. There is also a program that I call "GentleNav", available on this website only. It is a port of the program that I have been using for a couple of years on my previous hardware platform. It performs pitch stabilization and/or RTL for an electric sailplane.By the way, there is a "feature" of most GPS radios that you should be aware of if you plan to use both programs. If you command GPS radios to switch baud rate or between NMEA and binary formats, they only listen at the new baud rate and in the new format. If you run the "GentleNAV" program, it will switch to binary format with an NMEA command. If you then run the self test program, which trys to communicate in NMEA format, the GPS radio will ignore all commands, and the self test will indicate a failed GPS. If you plan to switch back and forth, you should revise the self test program to have it send the GPS command in binary format to switch to NMEA. With older GPS radios that I have used, they eventually default back to NMEA. The EM-406 somehow seems to forever remember the commands to switch, it will never switch back. I eventually plan to revise the self test program. In the meanwhile, it might be a good starting point for you to revise the self test program to send a binary command to the GPS to switch to NMEA format, its not hard to do.You should also be aware that the status light on the EM-406 only works when the radio is in NMEA mode. At least I haven't figured out how to make it light in the binary mode, it just goes out. It resumes operation when you switch back to NMEA.Presently, I am working on two projects related to the UAV development board. First, I am finishing up the documentation for the "GentleNav" firmware. Its taking longer than I thought. I will post a blog when it is done.Second, I am working with Paul Bizard to develop theory and implementation for "artificial horizon" firmware for the UAV development board. It will combine gyro, accelerometer, and GPS information into a stable, responsive, accurate representation in matrix format of the orientation of the plane that it is mounted in. We believe we have a method that will work, but we have a few more details to work out. We will publish the theory when we have something we are satisfied with, and tested code some time later. What we have in mind is an algorithm that will maintain the 3X3 direction cosine matrix that describes the relative orientation of the plane and ground. Each entry in the matrix is the cosine of the angle between an axis on the plane and an axis on the ground.Best regards to everyone, and acknowledgements to Chris Anderson, Paul Bizard, and all the staff at SparkFun for their help.Bill Premerlani
Read more…
