Archive for October, 2009

DIY Drones T3 contest – Round 2

Thursday, October 22nd, 2009

This month’s DIY T3 contest was definitively more challenging. I was only able to have one attempt due to the weather and a few other projects that kept me busy. I got first place on this round as well!

This time the challenge was that on each waypoint the altitude would change. I was able to hit the target altitude within 5m at each waypoint, it was a clean run. This attempt was without using the airspeed and altimeter sensors (not implemented at the time).

Screenshot-2

Screenshot

Flight testing of new Paparazzi altitude and airspeed control loops

Sunday, October 4th, 2009

Today it was the perfect day to test the new airspeed and altitude control loops. The wind was very gusty and with an average wind speed of 10 m/s, normally I would avoided flying my EasyStar in a day like that but what a better way to test the sensors and control loops! I had a few flights the day before in more mild conditions and had a chance to tune the altimeter and airspeed gains (see previous post for implementation details). The GPS only vertical control loops do a very good job when the wind is not too gusty, usually in days like today I would have to modify my airframe configuration to force the throttle to higher values than usual. With the airspeed sensor this is no longer needed, it will keep the airspeed in changing wind or attitude (e.g. climbing).

The following plots is from today’s flight. I was flying an oval against and with the wind, wind speed was about 10 m/s. Altitude hold was done with the barometric altitude sensor.

Screenshot1

For comparison the GPS altittude is also shown. Aggressive climb mode is still not enabled. The EagleTree altimeter is read at 20Hz and the existing Kalman filter is used to calculate the rate of climb. What I found interesting was that the pitch and altitude gains had to be increased considerably when the barometric altitude was used instead of the GPS. I am not sure why, it might have something to do with the update rate or the slightly modified Kalman filter parameters. After some tuning, I am fairly satisfied with the altitude hold (+/- 2m from setpoint for most of the flight), especially considering the effects of the high wind speeds.

09_10_04__17_50_27_alt2

The airspeed hold was the main reason I started this project and the benefits are obvious in this example. The throttle adjusts to keep the airspeed close to the setpoint. This time the airspeed deviation from the setpoint was higher than the last flight, the gains were the same so I believe the winds gusts might be to blame. I will try to see if I can improve the gains in the next flight.

09_10_04__17_50_27_as1

The new airspeed and altitude control loops will come in handy in the next DIY Drones T3 contest! Since endurance and not speed is the next objective, optimized throttle control will be essential.

I have a total of about 10 flights with the modified code and the EagleTree sensors with no major problems. I will be submitting my changes to SVN in the next few days. I still need to look into the following (hopefully in the next few weeks):

  • Test EagleTree sensors in 3rd party mode
  • Revert to GPS measurements if any of the sensors fail

Update on airspeed integration in the Paparazzi code

Friday, October 2nd, 2009

I was able to do a test flight with the airspeed sensor and the modified airspeed and altitude control loops. Some further tuning is required, but I am fairly happy with the results I got so far. First a brief description of the modifications made.

Besides the drivers for the EagleTree airspeed sensor, I had to modify the vertical control loops to make use of the airspeed. Since the actual airspeed is now known, I decided to try separating the altitude and airspeed loops as shown in the diagram below. Basically the throttle and pitch are now controlled independently and are not coupled in the control loops (of course one affects the other but the control loops are independent). The airspeed is controlled by two cascaded PI loops, the first is used to regulate the ground speed and the second the airspeed. This is needed to ensure that if the ground speed drops below a certain value the airspeed will be increased to compensate (in order to maintain a valid GPS heading).

Airspeed

I did some basic testing on the simulator (using airspeed = ground speed) and it worked well enough to fly test and tune. The following two plots are from an actual test flight after spending some time setting the loop gains (the real-time tuning through the GCS is a time saver!). The plane was flying circles at a constant altitude (except in the end). The wind was about 5 m/s, judging from the ground speed variations. In the middle there is an example of what happens when the ground speed falls below the setpoint. Finally the altitude setpoint was changed to verify that the airspeed will be maintained while climbing.

PlotAS

The altitude gains were the easiest to tune. Altitude is maintained fairly decently, at the end the altitude setpoint was changed (aggressive climb mode was disabled). This is still using the GPS altitude, barometric altitude has been implemented but not tested yet (Kalman parameters may need some tuning)

09_10_01__18_19_21_alt

Considering this is the first flight test I am fairly happy with the results. I would like to see if I can get the airspeed to hold closer to the setpoint, the reading is inherently noisy so either some additional filtering or further tuning of the gains might help. As soon as everything is tested I will submit to SVN. Remaining items that need testing:

  • Aggressive climb mode
  • Altitude control using barometric sensor
  • Test airspeed and barometric sensors in 3rd party mode (in the default mode the sensors will output raw values where in the 3rd party mode they will output converted values)