William Premerlani's Posts (34)

Sort by

Helical turn controls

3689655567?profile=originalFirst 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

Read more…

3689531408?profile=originalThe 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.

3689531081?profile=originalThis 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

Read more…

global waypoint range for MatrixPilot


UAVDevBoard users:


MatrixPilot trunk, r1817 now has global waypoint range, provided that:

1. You use absolute waypoints. Specify longitude, latitude, and altitude for each waypoint.
2. Each pair of points in the sequence, including first and last, should be no farther apart than 20 miles.
3. When you engage waypoint control mode, the aircraft must be within 20 miles of the first waypoint.

A couple of things to be careful with:
1. RTL will not work if the aircraft is beyond 20 miles of the RTL point.
2. Be aware of how your Rx failsafe works.
3. It is highly recommended that you do ground testing with HILSIM before any long mission.

Also, please be aware of, and comply with rules and restrictions that apply to you. If it is not possible for you to actually conduct a long mission, you still might want to conduct simulated flights.

Regarding failsafe, for a long mission you should set your Rx failsafe up to simply maintain waypoint mode, with trim values for all control surfaces, and maximum throttle.

Also, when you plot your flight log, ignore the IMU path, plot GPS only, because the IMU path will wrap.

The above flight track is for a 40 minute HILSIM test flight of a Boeing 747 which took off from Schenectady County Airport in autonomous mode, flew around Saratoga lake, then flew south toward New York City at about 400 miles per hour, west over the Catskill Mountains toward Binghamton NY, then back to Saratoga Lake, NY.

Keep in mind that versions of MP prior to r1817 will not work properly if any of the waypoints are farther than 20 miles from the origin. I have verified that to be the case with HILSIM.

I would eventually like to relax all waypoint range restrictions. I am not sure when that might be, but I will make an announcement when I do that. It does not look like it will be very hard to do, It will simply require several 32 bit integers in places where we are now using 16 bit integers, and a few 64 bit integers instead of 32 bit.

Best regards,
Bill Premerlani
Read more…



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,


Read more…



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,


Read more…

Magnetometer alignment


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:

3689428770?profile=originalThe 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


Read more…

Magnetometer offsets revisted

3689428499?profile=originalThe 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


Read more…
3689412338?profile=originalThis is an update of a previous post, with a link to a report that I promised that I would write. The above plot shows the results of the automatic calibration of the Z axis gyro during tests of methods to improve the performance of attitude estimation during sustained, high rate rotations. In this case, calibration was computed to better than 0.5%. The following is the original post:

3689412424?profile=originalNo, 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:

3689412455?profile=originalSimilar 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:

3689412449?profile=originalCoincidentally, 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:

3689412395?profile=originalHere is the track reported by the "dead-reckoning" algorithm:

3689412566?profile=originalAnyway, 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,

Read more…

A simple dead-reckoning algorithm




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,


Read more…

landing altitude control

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

Read more…

rudder-roll stabilization

If you are flying a UAV DevBoard in a plane without ailerons, you should be interested in a recent revision to MatrixPilot that will tighten the turns in waypoint mode, without overshoot. The above picture is the track of a portion of a test flight in an EasyStar. The control mode was switched from stabilized mode to waypoint mode with the EasyStar flying away from the first waypoint. So the controls performed a tight (less than 15 meter radius) "snap-turn", with very little overshoot.
Up until now, the only way to prevent turning overshoot with MatrixPilot was to use a large value for the yaw damping parameter. Although that certainly prevented overshoot, it made the turns very wide. The latest revision prevents overshoot, while still enabling tight turns.
The revision is rather simple: an optional negative feedback term equal to a gain times the roll has been added to the rudder control. The effect is to reduce the steering time constant. It is equivalent to controlling the roll rather than the yaw rate. It is something that has been on my list to do for a long time, I finally got around to it. Rana and Sid have been using this feature unofficially for some time, they encouraged me to add it. Also, there have been posts from time to time from other authors recommending roll-based steering. MatrixPilot has always used roll-based steering with ailerons, but until now, for mostly historical reasons, it used yaw-based steering with rudder.
The new parameter is ROLLKP_RUDDER in the options.h file of MatrixPilot. It is now available in MatrixPilot2.5 in the branches directory, or in the "developers" version in the project main trunk, or as a version 2.5.1 zip file. If you want to try it out, to start with set ROLLKP_RUDDER to the same value as YAWKP_RUDDER. For an EasyStar, set them both to 0.15, and set YAWKD_RUDDER to 0. For now, leave "dead-reckoning" and "cross-tracking" turned off, I am working on improving the performance of both of those. Right now they are not performing up to their potential.
The following is a portion of the track during a test with an EasyStar in which ROLLKP_RUDDER was deliberately set to 0, with YAWKP_RUDDER = 0.15, and a modest value of YAWKD_RUDDER (I forgot what it was.) to show what happens without rudder-roll stabilization. Note the large amount of slowly decaying overshoot after the snap turns.
So, if you are using MatrixPilot in a plane without ailerons, I highly recommend trying this new feature, it should improve waypoint performance.
Best regards,

Read more…

Invensense gyros in the UAV DevBoard

UAV Devboard users,

The UAV Devboard, version 3, is now available from SparkFun. It is the same as version 2, except it replaces the LISY gyros with Invensense 500 degree gyros, which are practically vibration proof. Also, now you can use higher rotation rates in your flights without saturating the gyros. The previous gyros had a maximum range of 300 degrees per second.

The board has been flight tested by the team. All firmware for the UDB2 will work on the UDB3 without changing any parameters except the board type.

In MatrixPilot, you should select RED_GREEN_BOARD (even though the board is entirely red!) as the board type. If you are using any of the heli firmware, the board type depends on what version you are running. In the latest heli firmware, set the board type to INVENSENSE_BOARD. In either case, the configuration file that should be pulled is "IXZ500.h"

The "bigger and better" version of the UDB is still in the design pipeline, and is expected to be available in the spring of 2011.

Best regards,
Read more…

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.



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

Read more…

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:


There is an excel spreadsheet with key telemetry items:


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

Read more…

Programmers for the UAV DevBoard


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

Read more…


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
Read more…

AileronAssist versions 1.7 and 1.8 released


UAV DevBoard pilots:This is an update of a previous post.I deleted version 1.6 of AileronAssist firmware and released version 1.7.The reason is that I noticed that the firmware fail safe does not work in version 1.6. Although the commanded return to launch will work just fine in version 1.6, loss of signal return to launch does not. If you turn off your transmitter, and if your radio does not have a fail safe, its not going to be pretty.If you are using a radio with its own fail safe, it does not matter whether you use version 1.6 or 1.7 of AileronAssist. But if you might ever use a radio that does not have fail safe, you should use version 1.7.Previous versions of AileronAssist are fine. It is only version 1.6 that is affected.I never noticed it before, because I no longer use radios that do not have built in fail safe.Also, version 1.8 of AileronAssist, with waypoint processing, was just released. It supercedes both version 1.6 and 1.7Best regards,Bill Premerlani
Read more…

Altitude hold for UAV DevBoard


UAV DevBoard pilots,I am putting the most recent releases of MatrixNav and AileronAssist back on line. I briefly reverted to the previous releases while I investigated a system issue that I just ran into.I just bought an EasyStar, ready to fly, with radio, servos, ESC, and radio already installed. I did some flying with MatrixNav. Most of the time it worked fine, but once in a while there were problems that popped up at random. Once in a while the firmware believed the radio signal is lost, and reverts to return to launch mode. Sometimes the elevator will work in only "bang-bang" control mode, responding to manual control by going either full up or full down. Typically, the problems arise at random, after about 10 minutes of flying.After some investigation, I discovered a system issue that a few of you have already run into. It turns out that low battery voltage will cause a "brownout" situation for the CPU. It turns out there was a problem with the ESC. Although the CPU did not reset, some of the hardware configuration registers reverted to their default values. This will cause the firmware to think the radio signal is lost, and it will go into return to launch mode. This will happen with any of the releases of MatrixNav or AileronAssist.When I have some time, I will take a closer look at handling low battery voltage.In the meantime, be sure to use good batteries and a quality ESC.Best regards,Bill PremerlaniAltitude hold is now available as an option in the most recent releases of the control and navigation firmware for the UAV DevBoard, MatrixNav1.7, and AileronAssist1.6. Both are available from the UAV DevBoard home page.The altitude hold function has been tested by both Sid and myself. According to Sid, it is "precise".During my tests, AileronAssist was able to hold my Goldberg Endurance in a turn at a 45 degree bank angle, at constant altitude, for 30 minutes.Next, I am going to implement waypoints.Best regards,Bill Premerlani
Read more…

UAV DevBoard firmware progress report


UAV DevBoard pilots,This is an update on a few UAV DevBoard related activities.There is a new release (1.6) of MatrixNav, that now includes rudder-elevator mixing, and yaw stabilization in both stabilized and and RTL mode. It is available under the UAV DevBoard tab.Ben Levitt just created a couple of groups in the DevBoard code repository. The groups are intended for open source development of firmware for the board. Anyone interested in helping or in monitoring our activities is invited to join the groups. There are several activities on the near horizon, including telemetry, waypoints, helicopter control, and altitude hold, for example.Also, Ben has figured out how to use the spare pins on the board to implement extra interrupt-driven PWM inputs and outputs, bringing the total to 5 PWM inputs and 6 PWM outputs. This considerably opens up the the possible applications of the board. Ben has implemented and tested the firmware for the extra channels, but has not yet released it. It will be available soon. You can see his code here.Best regards,Bill Premerlani
Read more…