AOA Control of R/C Airplanes

Gary Warner

Date 03/24/05

Being an avid R/C sailplane pilot, I’m always looking for ways to improve the performance of my planes. I fly these planes in a competitive environment which always demands the best of me and my planes. I buy only the best models, use the best techniques and practice when ever I can. Still, to me, it’s not enough. I stand in the winners circle a lot, but I’d like to improve my chances of doing so.

I’ve debated with myself about what can be done to improve my climb rate when flying in lift. You see, the airplane does not fly as precisely as it can. Control inputs that respond to what the plane is doing are a good bit behind the curve. Call it latency if you want. No matter how fast I give a command, it’s not quick enough. It’s always a response to something that takes time for the attitude of the plane to show me that it needs attention. So I began thinking about what could be done on-board the airplane in an ‘automatic’ mode that can help me control the airplane better. Several thoughts and ideas crossed my mind.

First, I thought about airspeed. It’s been done before by other modelers with some success. But the closer I looked into the physics of flight and the affects of (and on) airspeed, it became clear that airspeed was also behind the 8 ball when it comes to precise control. See, the airspeed only changes after another change was made, usually pitch. Also, our sailplanes fly at assorted airspeeds and the examples that have been used by other modelers use a preset airspeed. Changeable on the ground, mind you, but still set for just one speed. I could get around this with any airspeed controller I’d make, but still, the fact that the airspeed was changing only after the fact made me look elsewhere.

In the scheme of things, only one flight condition decides what the most efficient flight attitude is – that’s Angle Of Attack (AOA). Though airspeed can be used to get an idea of what our AOA is, it’s only a close cousin to AOA. The fact is, for any given airfoil there is a particular AOA that represents the best glide, best L/D, stall, etc.. If the plane was to be flown strait and level, in perfectly still air all of its flight, using airspeed control would be ok. But the truth is, our planes fly in a variety of conditions and attitudes.

For example, when a plane banks in a coordinated turn and we wish to maintain the optimum AOA, we must apply up elevator input. This also increases our wing loading. For any given wing loading, the best AOA is still the same angle as when under lighter loadings. But as loading increases, the airspeed will increase, given the AOA stays the same. Since I am trying to maintain the best AOA through all maneuvers, the airspeed must increase in banks. It’s a small amount for most turns, but could be fairly faster for high G turns. All of the airspeed changes makes airspeed sensing and regulation impractical to obtain my ultimate goal – to maintain the best AOA for best sink (or in some cases, the best L/D).

So I’m off to try an AOA feedback system again. I say again, because I’ve done this before. Here’s the basics of what I made and the resulting performance.

In order to sense the AOA, I used a small wind vane (fin) that mounted on the side of the fuselage, a few inches in front of the wing. It was static balanced and operated a torque shaft that went into a sensor. The sensor consisted of a small plastic case which the torque rod passed into. On the rod I fashioned a elliptical disk of sorts that was to be used as a variable light shutter. I used an LED and an LDR mounted on either side of the shutter. As the shaft rotated, it exposed more of less light onto the LDR and this voltage was then sent to the micro controller, conveying the position of the relative wind (AOA).

The micro controller (CPU) was a PIC16C71 with 2K program memory, 32 bytes ram and 4 A/D input channels. The sensor input was sent to one of the A/D inputs. The micro controller then took the input from the elevator channel from the receiver, compared to two pieces of data and then sent out a corrected control signal to the elevator servo.

In flight, I used an extra channel to turn to controller functions on or off, using a micro relay, since I wanted the ability to cut the controller out of circuit, should there be problems. The elevator stick on the transmitter still functioned as the elevator, but it’s best to consider the elevator as ‘setting the AOA’ control. In fact, when I moved the elevator stick, I was only asking the airplane to fly at a new AOA. At first, this might look like the exact same thing as flying without AOA control, but it isn’t. If the elevator was simply moved to a new position and left there, the plane would oscillate around the new target AOA until dampened by the planes stability characteristics. If the vertical velocity of the air changes, which changes the AOA, the plane will (relatively) slowly change it’s pitch to settle on the new AOA. With my system, the plane was to respond to new vertical changes in airspeed (like flying into a thermal) as fast as the servo could move. I still have a bit of latency due to mass inertia of the pitching moment, but still the response was to be very fast.

I practice, I found some problems with my system. First off I used a linear response to changes in pitch. What would happen is that if the plane was disturbed in level flight, it would set up oscillations that resemble pilot induced oscillations (PIO). The servos could not respond fast enough (or were responding too fast) to offset the inertia latency. In fact at certain speeds, the latency was 180 degrees out of sync. Another issue was my design of the wind vane fin. It was flat, blade shaped and had a triangle shaped trailing edge. I was trying to keep positive pressure on both the upper and lower surfaces at all times with the triangle trailing edge. What I learned is that I had the right idea, just the wrong application. This was part of the oscillation problems. I now know that the entire flying surface of the fin should be wedge or V shaped, not just the trailing edge. Also, the total mass of the wind vane assembly, though light, was still too heavy. Once the vane was disturbed, it tended to overshoot the correct AOA, taking a bit of time to settle into the correct AOA air stream. So one of the changes I’m going to make is to construct the wind vane with much smaller and lighter materials with a pronounced V shape. I’ve seen somewhere where a modeler in Europe made a vane (for slip/yaw sensing) and it was very small diameter wire with a piece of Mylar bent into the shape of the V. Where my version was about 1.5 ounces, his was probably only a few grams, if that. Keeping the total mass of the vane assembly at a minimum will reduce overshoot errors, reduce weight and allow for a smaller vane fin.

All that being said, the AOA sensor allowed me to fly the plane without touching the elevator. I even winch launched to plane and it was a perfect max alpha climb, though it’s odd to push down on the elevator to ‘climb’ on the zoom. It turned in thermal turns just as well as I could and the sink rate was about the same as I could manually fly the plane. I know the idea works and feel that the performance can be improved if I can stop the oscillations.

As I said before, another problem was the CPU code response curve was linear. That is, the correction rate was in direct proportion to the vanes position in the air stream. At first this didn’t look like a big issue, but I feel it at least 50% of the problem in the oscillations. Here’s my thoughts on this.

When the plane is flying along and it encounters a new AOA as inputted from the fin, the servo is asked to correct for the new AOA and to re-establish the correct AOA. But due to the pitch inertia and the fact that the change in vertical airflow might only be for a very short time, the plane tends to overshoot the corrected AOA, setting up oscillations. If the response curve could be reduced when only small changes are needed, this oscillation problem could be reduced, if not eliminated. But, if a quick response to obtain a new AOA was needed, like say entering or exiting an aggressive roll, the response would be too late, resulting in speed changes that would be chased by oscillations in pitch.

The ideal solution would be to program an algorithm that resembled something like an elliptical curve. I’m going to try to code the processor so that it closely resembles this curve, though it’s beyond my scope at this time. The idea here is to reduce the correction to the elevator for small changes in AOA either by conditioning the fin input signal and/or condition the elevator servo output signal. The first method (conditioning the fin input signal) is likely my first choice. Also, I want to have the response curve increase in response the longer and farther away from the intended AOA error is sensed. Tricky at best.

I’d also like to make changes to the sensor pickup arrangement. Though the optical pickup was in the end, flawless, it was a real pain to manufacture and to calibrate. This time I’m going to use a linear Hall sensor, with temperature compensation. It’s the Analog Device’s AD22151. It has programmable scaling and offset which will reduce my efforts to get a signal the CPU can use.

I think with these three major changes (fin design, sensor design and coding for a variable response curve) will make this system practical and useful. Maybe even marketable.

The basic code used to read the receiver signal, the output pulse generator and A/D input from the sensor are all satisfactory at this time. Here’s how the code process works, in general.

The CPU polls the input from the receiver elevator signal until it sees a pulse edge (can’t remember if it was positive or negative going – but what ever). Once the pulse was detected, a timer was started and then stopped when the pulse reversed. This data collected represents the stick position of the elevator stick. Then the sensor was read on an A/D input port. This is the AOA fin position. The fin data was added to or subtracted from the incoming stick position data to derive the new servo output position. Then the corrected data was used to output a servo drive pulse, again using timers. All timers and data was cleared and reset, waiting for the next input pulse change from the receiver.

The CPU ran at 20MHZ allowing for a .2us resolution and executes 10,000,000 instructions per second. The output pulse was sent out less than a millisecond after the end of the incoming pulse train. Lots of CPU headroom on the CPU at these speeds. The CPU drew 18ma and that included the LED sensor. The onboard receiver battery pack was shared for the CPU on a 5 cell pack, running through a low drop-out 5 volt regulator. The system also ran on a 4 cell pack, but I was concerned about the voltage dropping below 5 volts, thus changing the intensity of the LED and screwing up my sensor data.

That’s all for today. I want to first produce a better fin assembly and sensor, than I’ll address the coding issues. I might be moving into a slightly bigger CPU, as I used 1900+ lines of code on the last CPU, and the limit for the PIC16C71 is 2000 lines of code. Off hand, I’m thinking a CPU with 4000 lines of code.