First of all, thanks to Peter Hollands, who produced the above picture of a helical flight trajectory from one of his HILSIM test flights of the latest version of fixed wing flight controls for the open source MatrixPilot project, also known as the UAVDevBoard. For the last year or so, Peter has been helping me develop a "helical turn control" for MatrixPilot, starting last summer when I decided to start over on the MatrixPilot fixed wing flight controls, using basic principles. One goal of the new controls was to be able to fly an arbitrary helical trajectory. Peter had some fun producing the above trajectory using XPlane-10 and HILSIM, running the new controls.

The theory of helical turn controls is described in the following three attached documents:

The first document, HelicalTurnPart1Conditions.pdf, describes the conditions that need to be satisfied to achieve a coordinated helical turn.

The second document, HelicalTurnPart2Controls.pdf, describes a simple controller, relying mainly on feedforward and proportional feedback, for satisfying the turn conditions, using matrix-vector computations.

The third document, HelicalTurnPart3AoA.pdf, describes a method for accounting for angle of attack and variation of elevator trim with wing loading and airspeed. Required model parameters are computed automatically from flight data using a program that Peter Hollands wrote.

Helical turn controls has been thoroughly flight tested for over a year, and has been found to perform quite well, including the following advantages, for example:

1. Tight, smooth, aggressive turns in both normal and inverted flight. For an airplane with ailerons, the controls can put the aircraft into a turn in less than 1/4 second, and can provide stable control with a turn rate up to the limits of the ranges of the gyros and accelerometers.
2. Level flight during a 180 degree roll over from normal to inverted flight.
3. Easier low speed hand launches because the controls automatically adjust angle of attack and elevator trim for changing airspeed.
4. Projection of earth frame pitch control onto body frame control surfaces, so pitch control is maintained in any orientation, including knife edge, or during a slow roll.
5. Elimination of the need for integral feedback. Using helical turn control, a combination of feedforward and proportional feedback performs better than conventional PID feedback control. This simplifies the selection of gains. The controls work well over a wide range of proportional feedback gain settings.

Here are a few pictures from recent actual flight testing with my EasyStar. First, a few circuits around a rectangle in waypoint mode are shown. Please note that some of the flight segments and turns were flown inverted:

Next, a close up of the tracks through waypoint 4. Note that there are many tracks and they are all within a few feet of the waypoint, in all three directions:

Finally, a view of a 180 degree roll over from normal to inverted. Note that the controls automatically account for the reversal in sign of the wing loading and adjust the angle of attack and elevator trim to maintain level flight. You can see that the plane quickly pitches up a bit once it becomes inverted:

By the way, one problem I ran into during inverted flight was that the EM506 GPS that I was using stopped working when it was pointed toward the ground. A friend of mine at our flying field, Robert Pixley, suggested a solution that I did not think would work, but it did: mount the GPS vertically instead of horizontally:

What I found was that with a horizontally mounted GPS, there were typically 10 or 11 satellites in view during normal flight, and at most 4 in view during inverted flight. With the vertical mount, there were 8 or 9 satellites in view all of the time.

Finally, a thanks to all of the MatrixPilot developers and users who helped me with this, and a few links to those of you who might be interested in the MatrixPilot project:

MatrixPilot project home page.

UAVDevboard available from SparkFun.

Helical turn controls firmware.

Best regards,

Bill Premerlani

The above flight track highlights the performance of the latest version of the navigation algorithms in MatrixPilot. Flight tracks are from a flight that Peter Hollands conducted. (Thank you, Peter.) The red and the green tracks represent flight segments in opposite directions between the same pair of waypoints. The tracks are nearly perfect straight lines 243 meters long, with deviation between the two tracks of no more than 3 meters, in heavy winds. You will have to look closely at the picture, the two tracks are nearly on top of each other.

Winds are shown in the following picture.

This precision navigation is the result of several recent innovations in the MatrixPilot algorithms. The main innovation is from Paul Bizard, and has to do with using IMU course over ground instead of heading for navigation. (Thank you Paul.) Paul has taken us full circle on this:

1. The first version of MatrixPilot used GPS course over ground for navigation. This had the advantage of not needing wind information, but suffered from GPS latency.

2. The next version of MatrixPilot used IMU heading for navigation. This eliminated GPS latency effects, but required wind to be included in navigation computations.

3. The next version of MatrixPilot used IMU for position estimation.

4. Recently, Paul pointed out that the MatrixPilot IMU furnishes course over ground, and that would be much better than heading for navigation. So we went full circle, we are back to course over ground. But now it comes from the IMU, not GPS, so there are no latency effects.

We also made several other improvements to the navigation algorithms:

1. We totally eliminated the use of angles in the navigation computations, everything is now based on vectors or matrices.

2. We are using 32 bit integer arithmetic in several places. This combines ultra-fine resolution with wide range.

3. We added a cross-track velocity damping term. This allows the cross tracking gains to be turned up without inducing a "dutch roll".

For more information on MatrixPilot, see its diydrones page, or its website.

Best regards,

Bill Premerlani

UAVDevBoard users:

Team,

I have recently performed flight tests on a major change in the way acceleration is accounted for in performing roll-pitch drift compensation from accelerometer measurements. The theory behind the idea was recently published in a discussion on this website. Since then, I have made a couple of refinements to the idea, the latest version is documented here.

Implementation in MatrixPilot is shown here. There is one slight "tweak" in the implementation that is not covered in the theory paper: although in principle the new method can provide yaw drift information, in the implementation I have used it for roll and pitch only.

I put off posting a blog entry until I had flight test data, which I now have. The above picture is from one of several recent test flights with a UAVDevBoard running MatrixPilot on an EasyStar, that shows that the idea works. What is shown is a comparison of the GPS track and the "dead-reckoning" computation. The yellow arrows indicate the wind direction and the plane icons indicate the attitude of the plane. The fact that the two tracks match rather closely is an indication that the estimated attitude matches the actual attitude, otherwise there would be a large discrepancy.

A major advantage of the new method is that it does not require a model for computing aerodynamic forces, nor does it make any of the approximations that previous methods do. It is based on kinematics only, and does not make any approximations. Therefore, it will provide accurate acceleration compensation for any platform, including quads, cars, motorcycles, baseballs, anything you want to attach an IMU to. (For anything but fixed wing, it does require a magnetometer.)

Now, some more pictures.

The next picture is taken from a portion of the flight in which the EasyStar flew in a tight circle for several minutes. Both GPS and dead-reckoning tracks are plotted. Two out of many revolutions are shown. It is during circling flight that it is particularly critical that acceleration be correctly accounted for. As can be seen, GPS and dead-reckoning match, indicating that attitude estimate is correct.

The final picture is the track of the entire 20 minutes of one of the test flights, in which I did my best to "break" the algorithm.

Best regards,

Bill

Team,

Presently I am doing work on multicopter modeling and control. One topic of interest to me is how can the tilt dynamic model of a multicopter be accurately determined from flight data, without disabling the controls or injecting any sort of intrusive signals. It turns out it can be done from normal flight data using a few basic concepts from signal processing. The method is described here. The above plot is the measured pitch dynamic impulse response of my draganflier. The x axis is time. The y axis is the pitch rate impulse response to an impulse command sent to the ESC. There are two curves in the plot. h(t) is the response, computed from flight data. H(t) is an exponentially decaying sinusoid fitted to the measurement. In this case, the Laplace transform of the impulse response is 5/(s*s+4*s+29), which is of exactly the form you would expect to arise from an analysis of fixed pitch control. Basically, in the case of my draganflier, there is about a 0.25 second delay between the time a new tilt rate is commanded to the motors and when quad begins tilting. I have measured a similar delay for the ArduCopter. The cause of this delay is mainly the inertia of the propellers, which delays the response of propeller thrust to change in motor torque, and the inertia of the quad, which delays the tilt rate response of the quad to propeller thrust.

As a check on the accuracy of the method, it is possible to convolve H(t) with control inputs to predict tilt rate. The following is a comparison of measured and predicted pitch rate during a flight of my draganflier.

Don't get too excited about the way the model seems to predict the high frequency features. If you are curious about that, read my report.

From the form of the tilt dynamic model it is possible to determine the form of an optimal feedback controller. It is not a PID controller. But that will be the subject of another report.

Best regards,

Bill

Team,

The above picture shows an interesting side effect of magnetometer misalignment: complete reversal of the measured horizontal component of the earth's magnetic field.

The effect was discovered by Peter Hollands during his analysis of the data from one of Ric Kuebler's flights. Ric was using the UAV DevBoard (UDB) with MatrixPilot autopilot software. The airplane icons in the picture indicate the estimated orientation of the plane. The blue arrows indicate the estimated direction of the horizontal component of the measured magnetic field, in the earth frame of reference.

The magnetometer is mounted separately from the UDB. It turns out that there was a small roll misalignment of the magnetometer in Ric's setup. Ric aligned his magnetometer more carefully, and the flipping disappeared on subsequent flights. But there was a nagging issue.

Because of the large vertical component of the earth's magnetic field in many parts of the world, magnetometer-based yaw information is particularly vulnerable to misalignment. In my neighborhood, the vertical magnetic field is three times as large as the horizontal field. As a result, a little bit of mechanical misalignment of the magnetometer, and certain attitudes of the aircraft can cause complete flipping of the measured magnetic field.

It is not all that easy to align a separately mounted magnetometer. Even a 5 degree misalignment is too much. I wondered if there might be a way to solve the problem with software....

While I was analyzing the data from Ric's flight, on a hunch, I plotted the measured horizontal magnetic field against the heading:

The plot told me two things. First, it told me that there was a misalignment issue. But it also told me how much the misalignment was. If that could be determined from the flight data from a post-flight analysis, it should be possible to figure it out in flight as well. So I set out to find a way to determine magnetometer misalignment in flight, and automatically compensate for it. The theory, implementation, and testing are reported here.

The method works much better than I originally thought it might. It will automatically and exactly compensate for any amount of roll, pitch, and yaw misalignment between a magnetometer and its partner IMU, including 180 degrees.

Best regards,

Bill Premerlani



The above is a plot of the 3 components of estimated magnetometer offsets computed during spin tests at 78 RPM of an improved method for estimating and removing magnetometer offsets. There is a report available with theory and implementation. The method will work equally well for fixed wing aircraft, multicopters, and helicopters. It makes no assumptions about the dynamics of the airframe.

The idea for the new method came to me while I was recently working on a method to detect and compensate for magnetometer misalignment errors. I realized the method that I had been using for offset compensation was sensitive to misalignment between the magnetometer axes and the gyro axes, so I thought about ways to compute offsets that would ignore misalignment. I found a good way to do it that turned out to be more accurate and easier to implement than the method that I was using.

I also figured out a slick way to detect and adjust for magnetometer misalignment, I will be publishing a report in a few days on that subject. The method will compensate in flight for any amount of magnetometer misalignment, including a 180 degree yaw mounting error. In other words, the algorithm can figure out that you mounted your magnetometer backwards and apply a rotation matrix to the magnetometer vectors to put them into the correct reference frame. Stay tuned....

[Here is the technique for doing inflight magnetometer alignment. - WJP]

Best regards,

Bill Premerlani

No, thats not the light at the end of the tunnel, that is a time exposure of a spinning UAV DevBoard (UDB) during some research that I have been doing recently.
The goal of the research was to push the envelope of the sustained rotation limits of the direction-cosine-matrix algorithm. The idea is to be able to maintain highly accurate estimation of attitude during sustained (meaning forever) high speed rotation (maximum rating of the gyros) around any axis, such as a continuous turn, or multiple barrel rolls, or a spin, without  sacrificing any performance during straight-line flight or interfering with
any other function, such as wind estimation.
So, I put a UDB on an old record player spinning at 78 RPM (468 degrees per second), let it spin for 20 minutes, and measured, analyzed, and corrected various sources of errors that arise during high speed, sustained rotation, including:

Accumulation of numerical errors in the drift integrators.
The linear approximation to the rotation matrix in the DCM algorithm.
Latency in magnetometer measurements.
Gyro calibration errors.

The first picture was taken during measurement of magnetometer latency, in which a special test program flashed an LED on the board as it spun. The test was inspired by the strobe light method of measuring engine timing. By photographing the pattern at both low speed and high speed rotation, it is possible to determine the latency. In the first picture, the board was spinning very slowly, so this picture was a benchmark. The board was rotated a little more than two revolutions. The "dot" points to true north.

Then the board was spun at 78 RPM, and a similar picture was taken, only with more revolutions. It was easy to determine that, in the case of UDB + MatrixPilot, there is a delay of 0.085 seconds (40 degrees at 78 RPM) between the time the magnetometer makes a measurement, and when it is used in the yaw calculations. It was a simple matter to compensate for the delay in software, and another picture was taken at 78 RPM to verify the improvement:

Similar tests were performed to measure the other sources of error and to verify that the methods I developed to eliminate them actually worked, including a method for automatically calibrating the gyros in flight. I plan to explain these techniques in reports to be posted here, when I find some time to write them up.

Once everything seemed to work ok on my record player, the next step was flight testing. I turned to Ric Kuebler, (thank you, Ric) who did the following flight test on 4 separate flights, 2 with EM406 GPS, and 2 with uBlox GPS, without magnetometer, with his FunCub:

Circle 30 times at 12 RPM.
Spinning vertical dive at 90 RPM, 30 complete revolutions.
Pull out into level flight and switch to waypoint mode.

Telemetry showed that attitude estimation tracked perfectly the entire time, and then the controls transitioned smoothly into waypoint mode immediately after the spinning dive. Here is the track while Ric was pulling his plane out of the spinning dive:

Coincidentally, Ric's flight was a good test of the "dead-reckoning" algorithm that is used in MatrixPilot. Here is a portion of the reported track from the EM406 at 12 RPM:

Here is the track reported by the "dead-reckoning" algorithm:

Anyway, version 949 of MatrixPilot in the code repository contains the improvements that have been made to compensate for the errors that arise during sustained high rate rotations. With it, you can spin around any axis at 500 degrees/second for as long as you like.

Best regards,
Bill

Team,

After experimenting with several dead-reckoning algorithms over the past 2 years, I finally have a simple algorithm that I like. The above pictures show a comparisons of a GPS reported trajectory (without compensation for GPS latency), with the corresponding dead-reckoning (IMU) computed trajectory (which includes compensation for GPS latency). In the first picture, the GPS is an EM406 reporting locations at 1 Hz. The IMU is computing locations at 40 Hz. The IMU track is plotted at 4 Hz. The aircraft is an EasyStar flying at 8 meters/second in gusty, 4 meters/second winds from the northeast. The autopilot is the UAVDevBoard running "MatrixPilot" with both wind estimation and dead reckoning turned on. At the beginning of this flight segment, the plane was flying away from waypoint 0 in stabilized mode, and was commanded to fly to waypoint 0. It made a smooth "U" turn, was buffeted by gusty winds after it crossed over the tree line, and then recovered.

The second picture is taken from one of Ric Kuebler's flights of his FunCub (thank you, Ric), flying at about 20 meters/second in winds with peak gusts of 10 meters per second.

The code for the algorithm is attached, deadReckoning.c. It is trivially simple:

1. Use the direction cosine matrix to transform body frame accelerometer measurements into earth frame, and account for gravity. (not shown in the code.)

2. Integrate the acceleration to get velocity in earth frame. Integrate velocity to get location.

3. Compute the difference between GPS and IMU velocity and position. Use simple proportional feedback to acceleration and velocity to close the loop and prevent drift.

Actually, I had tried this algorithm once before, and it did not work very well in heavy winds, so I put it on the shelf and tried some other techniques, which did not work either. I recently realized that the key to making any dead-reckoning algorith work is to have accurate values for roll and pitch and GPS latency effects to start with. So, my recent efforts have been to improve the fundamentals in MatrixPilot. Here are two key recent changes:

1. An improved method for accounting for GPS latency. It is a non-linear "feed-forward" technique, based on geometrical concepts that take into account forward velocity and turning rate.

2. An improvement in accounting for forward and centrifugal acceleration effects. I have known for some time that acceleration adjustments should be based on air speed, not ground speed, but the first version of MatrixPilot was using ground speed because at the time I had not yet figured out how to estimate wind speed. I finally got around to making the necessary revisions, and it has made a huge improvement in performance.

By the way, MatrixPilot does not have a direct measurement of airspeed. It infers it from wind speed and ground speed using a "wind estimation" algorithm. If you have a direct airspeed measurement, the algorithm should perform even better.

Best regards,

Bill

There is a simple control technique to get good altitude control during autonomous landings. Turn off the throttle and follow a glide path defined by 2 waypoints. The first point is the approach point, and should be about 10 meters above the beginning of the runway. The second point defines the glide path, and should have a negative height, and be unreachable.

Whenever the plane is above the desired landing glide path, the pitch altitude control should be programmed to engage. Whenever the plane is below the desired glide path, altitude control should simply maintain level pitch, that will keep the unpowered plane from stalling.

If the plane is landing against the wind, it will land close to the first waypoint. If it is landing with the wind, it will land where the glide path intersects the ground.

The above pair of tracks were recorded during 8 autonomous flights of an EasyStar that I made today. Waypoint7 is the approach point, and waypoint8 defines the glide path. The two landings were within 7 meters of each other, and close to the intended landing point.

Best regards,

Bill Premerlani

Hi guys,

Today MatrixPilot controlled three more autonomous flights. All three flights were executed with the transmitter turned off. The picture above is the track of the first landing. It was aiming for the midpoint between the two fields, along a line that connects the centers of those two circles.

Recently I posted three flights of my GentleLady flying with MatrixPilot running on a UAV DevBoard, but I was not able to take a video at that time. The weather cleared today, so I thought I would get three more flights, this time with the EasyStar, and with a video camera documenting the hands off takeoffs and landings. This time, since I had the video camera as proof that the plane was able to take off again after each landing, I cycled the power on the plane between flights, but all three flights were with the same battery.

The first flight was just a test flight, without the video being recorded. Wouldn't you know it, it was the best of the three. Here is the GoogleEarth kmz file of the first flight: LOG00080.kmz. It includes waypoints, attitude information, wind estimation, and the track. You can animate the flight to re-create it, using the GoolgeEarth animation tool.

The following is a picture of the track of the first flight.

The second flight was the first flight that was captured on video. It was the most interesting of the three flights because it includes a missed approach. The plane was coming in high, and it looked to me that it might land on the busy highway to the northwest of field, so I cycled the power on the transmitter on and off to reset the controls. The plane then started all over again through the pattern, with the transmitter off, this time making a successful landing. Here is the kmz file: LOG00083.kmz The following is the track of the landing:

The third flight was executed immediately after the second flight. Here is the kmz file: LOG00084.kmz Here is a picture of the landing:

The third landing was actually right at the edge of the field. The plane came to rest against a fence post, but there was not any damage done.

The target for each landing was the point midway between the centers of the two fields. The distances between the landing point and the target for each flight were:

Flight#1: 34 meters

Flight#2: 38 meters

Flight#3: 80 meters

I will leave it up to the judges which flights to include in the average. Only two flights are needed for the contest, but it is not clear to me which ones qualify:

Flight#1: "clean flight", but no video

Flight#2: autonomous takeoff, manually commanded landing abort, then a complete autonomous flight. video recorded.

Flight#3: "clean flight", landed short. Bumped into a fence post, but no damage.

Now, the video:

Autonomous Flights of EasyStar with UAV DevBoard from William Premerlani on Vimeo.

/**********************************************************************************/

Team,

Here are three more videos. The quality is much better, my son, Brian, took most of it. I was not going to publish them, because they were from an unsuccessful flight. But now that I think about it, I think you would enjoy them more, watching me make a "rooky" mistake.

Here is what happened...on the day of my first few autonomous flights, I did not get video for the first 3 flights, dead batteries in the video camera.

So, later on in the day, armed with fresh batteries, I decided to try again. This time I took my son, Brian with me to help take the videos. You will see him. We thought it was fitting for him to finally appear, since he was the one who got me started in this hobby. If it were not for him, I would be doing something else instead of diydrones. Just in case there is any confusion about who is who, I am the good looking one, he is the young one.

Between the time of the first flights and when we got back to the field, the wind direction had shifted. We would now be taking off and landing with the wind. Bad idea. I knew better. But I really wanted to get some video, so I fooled myself into thinking that, although the wind was in the wrong direction, it was not too strong. Wrong!!

So, we gave it a shot. Here is the video. Things were going fine until final approach. It was landing with the wind, coming in high and fast. I could see it was going to go long. I had to make a fast decision. The camera was rolling, and I was determined to get my video. So, I let the plane try for an automatic go around. It reached the landing waypoint, powered back up, turned toward the trees, and started to climb. It almost cleared the trees. Almost...

If you listen, you can hear the plane smack into the tree at the end. Brian says it is the sound of wood embracing wood. Oh, and cover your ears at the end, I never imagined I would ever publish this one:

Gentle Lady's flight into the trees. from William Premerlani on Vimeo.

After the GentleLady smacked into the tree, Brian and I walked down to see what we could see....It was way up in the tree, about 60 feet up.

Brian is an avid climber, I bought him a membership in an indoor rock climbing club, so he volunteered to climb up and fetch it. It wasn't easy, but he did it. He went up as high as he could, he was still about 10 feet too low. With a GentleLady, the wing is held on with rubber bands, which had popped off. Brian shook the tree, the wing finally shook loose and fell. But the tree had a firm grip on the tail, so Brian climbed up another 10 feet to fetch the rest of the plane. Here is what he looked like 60 feet up in the tree:

Brian rescues the Gentle Lady from a tree from William Premerlani on Vimeo.

The next question was what to do next. Brian vetoed the idea that we would try to complete the flight. It turned out the motor was running when the GentleLady landed in the tree, it was burned out. So, how to get the plane down? The only way was to throw it, as near as we could see. Brian was not signing up to climb down with the plane in one hand. Ever thoughtful, he took out the electronics first, and then dropped it straight down. It landed in the low branches of the tree. Here is the final step of the rescue:

Gentle Lady: the low hanging fruit from William Premerlani on Vimeo.

Aside from the burned out motor, there was not much damage to the GentleLady. A new motor, a couple of drops of glue, she was out flying again the next day.

Best regards,

Bill Premerlani, June 26, 2010

Yesterday, my GentleLady sailplane, under the guidance of MatrixPilot running on a UAV Devboard with an EM406 GPS and Jordi's magnetometer, achieved 3 consecutive autonomous flights, with the transmitter off most of the time. The above picture shows the tracks of the three landings. Waypoints 18 and 19 were arranged so that the plane was supposed to land halfway between them. The closest landing was 6 meters from the target, the farthest was 21 meters.

Here is how the flight sequence worked:

1. Power up with Tx on.

2. Shut off Tx, this causes the fail safe on my Rx to trigger MatrixPilot to go into waypoint mode.

3. Hand launch the sailplane.

4. Sailplane makes two circuits around the field and lands.

5. Turn on the Tx, this puts MatrixPilot back in manual mode.

6. Turn off Tx, this puts MatrixPilot back in waypoint mode.

Repeat 3 times.

Here are the three flight paths around the field:

Here is the side view of the landings:

You can watch an animated view of the flight track on Google Earth with this kmz file: LOG00122.kmz.

The kmz files are produced by a tool that Peter Hollands put together that reads the telemetry and generates the kmz file. It has some nice features, including displaying the orientation of the plane, the waypoints, the wind vectors, and magnetic field vectors.

Simply download the kmz file and double click on it, Google Earth will open it. You will not see any flight tracks when you open it, but there will be an animation tool visible that you can use to animate the tracks, and/or select portions for viewing.

There will also be items in the layers visibility for you to turn the display of the tracks, waypoints, etc., on and off.

If you are interested in looking at them, here are two other files associated with the flights.

First, there is the raw telemetry file:

LOG00122.txt

There is an excel spreadsheet with key telemetry items:

LOG00122.csv

I want to thank all of the members of the UDB team for their contributions, especially Ben, Peter, Adam, Ric, Sid, and Rana. You guys are always there for me. Thank you Jordi, for your magnetometer breakout board.

And thank you very much, Chris Anderson, for your encouragement and for this website.

Best regards,

Bill Premerlani

UAV DevBoard pilots:

SparkFun is out of stock for both their Olimex ICD2s, which is what I've been recommending to program the UAV DevBoard, as well as their Olimex PICPOCKET, which I do not have enough information right now to provide any recommendations one way or another. SparkFun is discontinuing the ICD2, it is their intent to sell the PICPOCKET instead. Those are out of stock right now. As soon as they get some in, they told me they will test a few with the UAV DevBoard to assure compatibility.

In the meantime, there are 4 programmers that I can recommend, that you can buy from Microchip.

ICD2 - Its around $200. I have used it, it works fine. You will need to buy either an adapter from SparkFun or an adapter from Microchip to go from the RJ11 connector on the ICD2, to the ICSP connector on the DevBoard. Microchip discourages you from buying the ICD2, because they are phasing it out, but it works just fine.

ICD3 - Similar to ICD2. Its also around $200. Its the newer version of the ICD2. I have also used it, it works fine. You will need to buy either an adapter from SparkFun or an adapter from Microchip to go from the RJ11 connector on the ICD2, to the ICSP connector on the DevBoard.

PICkit3 - Its around $45. I have not used it. I have heard of some complaints, but there are reports that it works ok with the UAV DevBoard. It has an ICSP connector, and you can plug it directly into the DevBoard. There are various packages that Microchip offers that include the PICkit3, including a "PICkit3 Debug Express" for $70, but all you need is the "PICkit3 only" package.

PICkit2 - Its around $35. I have used it, it works ok. It has an ICSP connector, and you can plug it directly into the DevBoard. Microchip discourages you from buying this one, because they are discontinuing it, but it works just fine. Really, its the best one to go with.

Here is a link to the information on Microchip's website. If you buy any of their programmers, go with just the bare bones programmer. They offer other packages with various accessories, but all you need is a programmer.

Best regards,

Bill Premerlani