GPS Altitude Hold

[Dan_Jones]

Just when I was about to abandon the GPS altitude hold project, it finally works! Initially, it appeared that the GPS was too slow and to inaccurate to control the altitude from.

Airframe: Multiplex Easy Star
GPS: EM401
Control: Throttle and Elevator
Gyros: Rudder and Elevator
Logging: Zlog
Processor: ATmega128
Target Alt: 70m A.G.L.

The first graph shows what the altitude was when I initially got it to work. The pitch was controlled with the GPS and a gyro. The throttle would turn on full blast and it would shoot past the desired altitude. Then it would turn off and glide down past the setpoint and the process would repeat. Even though it looks dramatic in the graph, it wasn't that evident in the air due to the airplane circling. I tightened the control parameters and adjusted the throttle control until it finally worked. The bulk of the altitude hold is performed by the throttle since the airplane was balanced. However, the elevator is moved slightly depending on how bad the cituation is.

I was just about to start implementing it using a pressure sensor, but they are expensive and I really didn't want to add more cost to the project.

The final graph shows a very straight line. There was a very slight breeze and it is evedent in the graph. I did get one or two points that looked like radio glitches but very well could have been air pockets. The only control during the flight was to the rudder to make sure it didn't end up in the next county. Since the GPS and Zlog are not connected, the graph has a slight downward slant, but it is most likely because of the seperate sensors. Overall I am pleased with the result. It turned out better than I initially thought it would.

[vector_vortex]

I don't know what you class as expensive but I got some pressure sensors from futurlec http://www.futurlec.com/Pressure_Sensors.shtml they are cheap and work pretty well, I have one on the ground and one on the plane to sense differential pressure.

Regards

Joel

[Dan_Jones]

That is cheap! Thank you very much for the link! I've ordered one already. The expensive part that I was referring to was a $10+ sensor plus a $8+ 16 bit ADC. So my solution was a minimum of $20 and possibly as high as $35 to add the components to the board. I suppose that wasn't too bad, but the altitude data was already provided by the GPS.

I do like the idea of using multiple sensors and at under $6, the pressure sensors will be very cheap and very easy to integrate - not to mention much faster.

[eladiomf]

Just when I was about to abandon the GPS altitude hold project, it finally works! Initially, it appeared that the GPS was too slow and to inaccurate to control the altitude from.

Airframe: Multiplex Easy Star
GPS: EM401
Control: Throttle and Elevator
Gyros: Rudder and Elevator
Logging: Zlog
Processor: ATmega128
Target Alt: 70m A.G.L.

The first graph shows what the altitude was when I initially got it to work. The pitch was controlled with the GPS and a gyro. The throttle would turn on full blast and it would shoot past the desired altitude. Then it would turn off and glide down past the setpoint and the process would repeat. Even though it looks dramatic in the graph, it wasn't that evident in the air due to the airplane circling. I tightened the control parameters and adjusted the throttle control until it finally worked. The bulk of the altitude hold is performed by the throttle since the airplane was balanced. However, the elevator is moved slightly depending on how bad the cituation is.

I was just about to start implementing it using a pressure sensor, but they are expensive and I really didn't want to add more cost to the project.

The final graph shows a very straight line. There was a very slight breeze and it is evedent in the graph. I did get one or two points that looked like radio glitches but very well could have been air pockets. The only control during the flight was to the rudder to make sure it didn't end up in the next county. Since the GPS and Zlog are not connected, the graph has a slight downward slant, but it is most likely because of the seperate sensors. Overall I am pleased with the result. It turned out better than I initially thought it would.

Hi Dan

Great Job. I think that you are one of the first in implement GPS altitude control.

So, with GPS altitude information you are controlling 2 channels? Elevator and throttle. If so, what it's the proportion of control of each channel?

I suposse you are using a PID control.

You are in USA, I think that here in Europa GPS information have less accuracy.

Eladio

[toxicmouse]

maybe it is only where i am but there is no way i could implement GPS altitude hold, i often get glitches of more than 20m in altitude. Dan, do you have a figure for your GPS VDOP (vertical dilution of precision)? anyway, well done.

[zlite]

maybe it is only where i am but there is no way i could implement GPS altitude hold, i often get glitches of more than 20m in altitude. Dan, do you have a figure for your GPS VDOP (vertical dilution of precision)? anyway, well done.

Those glitches are pretty common. We got around that in our GPS altitude project by just averaging over multiple readings. It helps if you've got a GPS sensor that you can read at 4 hz or better.

Our project is here: diydrones.com (http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A731)

[Dan_Jones]

I don't have a figure for the GPS VDOP during the flights with the posted graphs. I suspect that there are going to be lots of altitude glitches. At this point, I'm not that picky so 20m isn't such a bad thing. As I get tighter control with the pressure sensors I ordered, I will definatly want to use a low pass filter on the GPS and a high pass filter on the pressure sensor. I believe this is similar to a washout filter.

The throttle was tricky to get to work because I couldn't turn it all the way on or off. I basically had to limit the range of the throttle to limit the rise/fall rate. This was very necessary because of the slow update rate of the GPS. The elevator control needs some attention as well since it does pull out of dives - just not as fast as I want it too. I'm still undescided how to fully utilize the elevator.

PID? Sort of... The throttle is proportional and the elevator kinda works like a D value limiting the rise and fall rates. (The gyro does that). Not quite that good yet, but getting there. The I value will definatly need to be on the throttle, but from what I have seen so far the best an I value could do would be to eventually get 5 to 10 meters closer to the target altitude. In a wildly dynamic system like this, I'm not sure that kind of accuracy is needed when there are more important issues to fix. I'll save that one for a windy day. :)

The other nice to have feature is to incorporate my airspeed sensor with the throttle. This would be used to keep air speed to avoid a stall.

[toxicmouse]

i am not sure that a PID loop is necessary for the loose altitude control that we are dealing with. i have assigned 8 altitude states, with appropriate climb rate settings for each.

for cruising the aircraft is trimmed and this becomes the default position in the middle altitude state.

[Dan_Jones]

That seems like a very good method! I'm not convinced that Kalman filtering and using a full PID loop is going to make much difference for what I intend to get out of the algorithm. The way I have it now, when the GPS data arrives, the throttle is updated. And since that occurs at 1 second intervals, it sounds like there are 8 or 10 steps in the motor throttle. I may as well have states too. :)

I'll let you know when I get the pressure sensors and give them a try. I expect the control to be better, but I don't expect any better of a result. With the better control, I hope to be able to open up the throttle limitations I have set right now to make the algorithm less airframe dependant.