Autopilot design

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
474
Points
83
Website
orbit.medphys.ucl.ac.uk
I am currently trying to set up an atmospheric autopilot for the Deltaglider (mainly as an example for an embedded script interface, but it wouldn't hurt if it actually did something useful).

Since I am new to the autopilot designer's club, I would like to tap into other people's experience on this.

The basic idea is to have autopilot functions for altitude, airspeed and heading. The feedback system is provided via a basic damped oscillation setup:

d2x/dt2 = - a dx/dt - b (x-x0)

where x is the control parameter (e.g. speed), x0 is the target value, dx/dt is the rate of change, d2x/dt2 is the second derivative, and a and b are design parameters.

So for example for an altitude autopilot function, x would be current altitude, x0 would be target altitude, dx/dt is vertical speed, and the left-hand side is (approximately) the elevator setting. Parameters a and b would be chosen for the aperiodic limit (no creep, no oscillation).

For speed and altitude this setup works quite nicely, but heading seems a bit more tricky. For starters, which control elements should be manipulated by the autopilot? For a turn, you need to control both ailerons and elevators, but in what relation to each other?

My idea was to set up two independent control loops: the heading autopilot on its own controls only the ailerons (the bank angle), but at the same time the hold-altitude AP is active as well. As soon as the bank angle increases, the altitude begins to drop, and the altitude AP starts to engage the elevators, thus contributing to the turn. It appears to work more or less, but occasionally I seem to get instabilities (diverging oscillations in the bank angle - it looks a bit like a resonance between the two control systems). Also, if the speed gets too low to hold the altitude, the whole control system breaks down, so I might need to simultaneously activate the speed AP as well.

Any thoughts on this? What algorithms do other people use for their autopilots?
 
Any thoughts on this? What algorithms do other people use for their autopilots?

Sounds like you over-regulate, so you should maybe lower some coefficients.

I prefer the classic of control loop design: Proportional (control output ~ error), Proportional+Integrative (control output ~ error + Int(Error)dt), PID-T1 (Proportional+Integrative+Derivative with time delay).

Your control loop is basically a PD (proportional + derivative). This kind of controller likes to overreact, as the D component reacts on increasing error rate.

For your scenario, I would create two stages:

1. Altitude error -> Vertical speed command. Can be done proportional with limits.
2. Vertical speed command -> Control surface deflection. I would use either PI or PID-T1 for this. PI needs longer to regulate the error, but is simpler to design. Fine tuning a PID loop is always some sort of magic art.
 
Some autopilots feed the absolute value of bank angle into the pitch control law to help it hold altitude.

Also look at feeding back washed-out pitch in the altitude-hold control law to help with stability.

Also, be aware of non-linear behavior - you may need to compensate for it. Also, gain scheduling based on dynamic pressure is very common due to it's affect on control surface effectiveness.

Rotating parts can also cause effects that the autopilot designer may need to compensate for. I am aware of one aircraft where the twin high-bypass jet engines acted as gyros and created enough torque to cause pitch change to induce yaw moments. I am also aware of a twin turboprop where the props did not counter-rotate. The resulting asymentric airflow over the aft fusalage was enough that thrust changes caused significant yaw moments.

Finally, pitch and thrust are inexorably linked leading to "total energy control" algorithms. A delta-wing aircraft would be an excellent candidate for this kind of system.
 
What I done back when I was working on an atmospheric autopilot was, without much knowledge in calculus, fiddle around until I achieved a control loop that didn't run away.

For that, I relied on logics to regulate the control loop, ie to recognize a runaway condition and do something safe about it.

I basically ended up coding what you do in a real aircraft, that is to control vertical velocity with power and airspeed with pitch. Another parameter I used was to keep track of the effectiveness of the control surfaces. That is, I kept a record of how much rate of change in pitch (or bank) a given control surface setting was giving in relation to the dynamic pressure. With this value, the algorithm could preset the ailerons to a guesstimated value based on the dynamic pressure and target roll or pitch rates and then adjust itself if it was overshooting or undershooting the target rate of change.

Sorry I don't have the code anymore, it went down in a harddrive crash...:(
 
Cairan is right:

Shoot for a numerical method to solve and update the State Vectors.

The problem is too is that you are missing the Energy from the Mean Air Chord, or how much lift you are producing. When the wing turns it is basically stalling the wing in order to turn, however the dynamic pressure plus G give the aircraft new CG values and therefore still need to be within the 25% limit of the CG.

One option is to measure the amount of energy produced by the lifting vector of the lifting body (wether the wing or body) Once the vector coming off the wing is decreased take the absolute value ( I think someone said this) and it would be the desired lift, in real life the wing turns and the flight computers take over making very, very, small corrections, due to the fact that once you turn the X turns into the Y and the Y turns into the Z, so then the acceleration produces the lift off the body, the ailerons turn into the rudder and the rudder tries to control the lift (whatever it can usually not very much).

The other option is the measurement of the Magnitude coming off of the turn, if MagV (dx/dt) does not = (2nd derivative) then you need power. A basic rudimentary system, but effective.
 
I may be stating the blatantly obvious here, but have you considered looking at code from Dan's DGIV? It is obviously similar in many respects to the default Delta Glider and it has an excellent atmospheric autopilot, but I'm not sure if it is the "type" of autopilot code you want.
 
Testing Notes:
Early on, you might try using your God like powers to turn off some of the dynamics. ;)
A DG example might be holding the speed constant, NOT integrating the position, and just working with the attitude dynamics (e.g.: just rotate the fixed length velocity vector based on the speed and normal forces) . If your attitude controller won't work in this mode, it won't work in the more complicated 6+DOF mode either where there is some coupling. Once your angle of attack controller is solid in this environment, you can then take it out into the 6DOF world where speed changes and "phugoid happens" and so on.

Do "step responses": test scenarios where you increase the commanded pitch, roll or angle-of-attack by 5 degrees, then drop it to -5 degrees then back up, etc. Do this at various speeds/dynamic pressures/fuel loads, etc. to test your gain scheduling.

Test with "gain margin": multiply your gains (usually b above) by say a factor of 3 (usually only the proportional gain "b" when a reasonable level of a/b is chosen, see below): does it still work OK? If it is unstable at the higher gains, then you may be trying to control too fast for your dynamics, or you may be saturating (say an elevator hits its limit). if you can't handle a gain margin of 3 in a soft quiet test condition, then you don't have much margin saved for any wierd couplings or hard usage or untested corner of the envelope in your 6DOF situation (basically anything not modeled properly in the simplistic model.)

Be aware that using your controller form (proportional and derivative control only) that you should expect certain kinds of errors. For example, in cases where the command is slowly changing (for example a "ramp" input), you would expect to see a "standoff" error: the controller never catches up.

Using a and b as above might be making it harder to analyze. What is really important when picking the gains is b, and the ratio a/b. (Basically, for this simple problem b determines how fast you respond or go unstable ;) (that is, the frequency), and a/b will affect how oscillatory it is (the damping).) Understanding this can help when you do your "gain scheduling" (changing gains with changing operating states).

For attitude dynamics, the gains might be scaled based on the ratio of moment/inertia. (More moment available (e.g. faster speed so more control moment from the elevator) means you could reduce the gains if you want to keep the same response characteristics. More inertia means you aren't going to respond as fast so you could increase the gains to keep the same feel. The point isn't exactly what choice you make here, but that you don't have to analyze these effects separately because (simplistically) they only enter the dynamics of the "plant" together as the ratio. For example, if you are barely stable in some nominal condition at 3 times your gains you know a priori that if you halve your inertia (empty tanks condition) and fly 22.5% faster (square root of 1.5) you are going to be on the edge unless you schedule your gains down per these state changes. This is because the vehicle is going to respond 3 times faster for the same elevator deflection.

This kind of stuff pops out of the equations when you do the simple first year "flight controls" analysis type modeling. As a physicist, you have the math so it would be mostly learning the terminology and analysis techniques. A lot of time can be spent guessing at appropriate gains where a couple of hours of analysis instead could give you a plan for a large part of the flight envelope given the simple dynamics Orbiter uses. (No sensor problems or real disturbances to worry about.)


-----Posted Added-----


Rats. Too little thought and no sketch ;). The closed loop damping ratio for a simplistic "double integrator" plant system varies more like 0.5*a/sqrt(b)
(not a/b)

Anyway, the thesis is it's worth doing the back-of-the-envelope analysis at some point, to save overall time. This particular analysis can be used as a first cut at simplistic aerodynamic attitude control, thrust vector attitude control, hover attitude and hover translational control, ... They all have roughly the same dynamics in their most simplistic uncoupled forms.
 
Here is a little more on the math for choosing gains for a very simple plant model. The math is pretty simple, but the concepts are more complex and are covered early in an undergraduate course
in control theory. One would need undergraduate engineering mathematics including calculus, linear algebra, rigid body dynamics, Laplace transforms, etc. to really make use of an undergraduate
control theory text book. I'm pointing this post at someone with serious high school+home study or early undergraduate mathematics knowledge who might like to have a cook book (but math based)
method to design controller gains, even if all the ideas aren't perfectly clear. If someone were to pick up an introductory control theory book, this might show you the "good parts" ;) to study
heavily. You can then go back to using all the real "cook book" methods out on the internet, but perhaps starting a lot closer to a useful set of gains, making the searching around for good values
less annoying.

It is also very hard to do it in words and one picture instead of lots of equations. Sorry about the length of this post.

The way I'm doing it here is "classical control theory" in the "frequency domain" (you are concerned at controlling the way things oscillate.) The other more modern technique is called "Modern
Control Theory" ') and involves creating linear models and lots of matrix multiplications and solving these matrix equations. The MatLab tool (for example) applied to control problems can attack
the problem using either paradigm.

The very simple plant model is a "double integrator". This means that the vehicle's attitude accelerates proportional to some command from the controller. (That is, the vehicle physical systems
effectively double integrates some control moment's (torque) attitude acceleration to get back to the way the attitude changes.) An example would be an RCS attitude control system in vacumn. A
thrust level command from the controller becomes attitude rocket thrust that creates a moment, and the moment accelerates the vehicle's attitude. Put another way, the controller commands thrust
level scaled from zero to 1, and the rest of the physical system turns it into an attitude acceleration (radians/second/second). The resulting attitude profile is two integrations of the attitude
acceleration.

See the figure for a Block Diagram and some equations:


Xc, the commanded attitude (for example, an Euler angle) enters from the left. The feed back position measurement is subtracted from it to get the error signal delta-X which is fed into the
controller.

The Laplace Transform of the controller Martin mentioned in the original post is: Gc(s) = a*s + b (This is one of those "trust me" things, see below)
The 'a' gain is the derivative gain. Multiplying by s in this domain is just differentiation. So 'a' multiplies the derivative of the error signal delta-X (that is, the attitude rate), and the
proportional gain 'b' multiplies the error signal itself. So this is just a Laplace transform model of the controller Martin mentioned up above. We are going to multiply another simple Laplace
transform model of the whole vehicle's position response to this farther down, then feed back the position to get the model of the closed loop system. The "closed loop" system response is the way
the vehicle responds with the attitude controller active, which is what we are concerned with improving.

The Laplace transform of the plant is Ka / s^2 (that is, s squared). When you "take the Laplace transform of a function" you get an equation in the complex variable 's' (just take this on faith
for now if you haven't studied it.) Dividing by s in this domain is integration, so this means the plant is simply a "double integrator": the control output of the controller (greek delta in the
figure) is some control effector state: elevator position, RCS thrust level, etc.

The Ka is an acceleration gain: the control effector state is multiplied by Ka to get the resulting attitude acceleration (radians per second per second). For an RCS system in vacumn, (this
matches this simplistic model most closely) Ka would equal the full thrust moment of the RCS system in the axis considered, divided by the inertia about that axis.

So the whole Orbiter vehicle is modeled just by Ka/s^2 ! Very simplistic, and only really fitting for something like a vacumn RCS controller, or a hover yaw controller with not very much
aerodynamic damping, etc. But it is a useful approximation for many other situations. More complex plant models obviously make the math harder to use, but the concept is the same. (One would tend
to use some modeling program like MatLab for a case any more complex, actually.)

H(s) is an optional feedback model. In this case, set H(s) = 1 (no effect here. You could use this for a complex sensor model.)
I included H(s) in the drawing because the equation for the Closed Loop Transfer Function (CLTF) of the model form shown in this figure is straight out of control theory texts. (I won't try to
derive it here.)

The characteristic equation is the denominator of the CLTF. The solutions of the characteristic equation (complex number 's' values for which the characteristic equation = 0 is true) are where
the "poles" of the closed loop system are in the complex (complex numbers, that is) frequency plane. The location of the poles of the model is a "Big Deal". :) The pole positions summarize how the
whole systems acts. (See a controls text. Sorry, some concepts just need to descend into jargon and mathematics ;) )

Since the highest power of s in the characteristic equation is 2, this is a second order model.

This means we can easily physically interpret the systems dynamics just from the characteristic equation. The Laplce transform equation of a simple oscillator is known to be (see a controls text,
again):
s^2 + 2 zeta omega s + omega^2 = 0

Where omega is the frequency in radians per second and zeta is the damping ratio. You use these to solve for equations for the frequency and damping as functions of the gains and Ka. One way to
use this information is to pick 'b' to obtain a (conservative,and probably unfortunately slow) frequency you want the system to respond at, and then set the 'a' gain to get a useful damping ratio
(0.7, for instance). The higher your 'b' proportional gain, teh faster it will act: but it might go unstable if you try and control it too fast.

Notice that because the omega and zeta are also functions of Ka, that changing the moment capability or the inertia will change the closed loop system's dynamics, unless you adjust your gains to
compensate in some way (this is "Gain Scheduling"). For the simple vacumn RCS, you might (for example) allow a faster frequency at empty tank inertia (Ka is higher), but adjust the 'a' gain to
keep a good damping ratio.

Phyically, in the complex plane the plant model starts out with two poles at the origin: it is on the border between stable and unstable. If you disturb it, it will just drift off.

Adding the 'a' and 'b' gains in the controller causes the system response to change. Ideally, the gains will be chosen to move the poles left (more stable so disturbances damp out quickly) and
they also will likely move off of the real axis (meaning the system becomes oscillatory: There Ain't No Such Thing As A Free Lunch.) The "closed loop" response to a disturbance (or a change in the
commanded attitude) with the controller operating becomes a second order oscillator, as shown. You would like this to have a fast frequency (acts fast to disturbances or command changes) and well
damped (any oscillations dies out after a few wiggles so the passengers don't get sick.) ;) Unfortunately, if you make the gains too high, you will start commanding beyond the RCS system's
maximum thrust. ("Saturate" the controls.) If this happens, you will command so much rotation rate as you speed up your maneuver that you can't slow down in time as you approach the desired
attitude. You will oscillate forever, or worse be actually unstable with each oscillation being bigger than the previous. This happens because this very real physical limit of the maximum thrust
isn't included in this simplistic analysis ;), so don't get too near to the limit, or else. (In practice, this means your controller gains will be set such that the system won't act as fast as you
might otherwise prefer.)
The last paragraph went into jargon again, sorry. Hopefully it was sort of useful anyway.
 
Back
Top