Professional Documents
Culture Documents
By
Michael Frutiger
and
Charles Kim
ECE345
TA: Paul Leisher
May 6, 2003
Project #45
In this report, we present the design and construction of a test platform for digital autopilots, as
well as a reference design and implementation of a 2-axis autopilot for use with this platform.
The platform is targeted at the educational market (for use in control systems laboratory
courses), and builders of unmanned aerial vehicles (such as participants in the annual Aerial
Robotics Competition). The platform consists of a micro-controller board, which hosts the
autopilot, and a PC running the commercial X-Plane flight simulator. The two components are
interfaced via Ethernet. With this set-up, autopilot prototypes can be tested with X-Plane’s
sophisticated flight- and atmospheric models. The reference 2-axis autopilot is designed for
small aircraft and features altitude control, vertical speed control, as well as a wing leveler. The
functionality of the platform is demonstrated by comparing the response of a Cessna 172 under
control of the autopilot to the expected theoretical response obtained from SIMULINK
simulation using the linearized model.
iii
TABLE OF CONTENTS
1 INTRODUCTION
1.1 Motivation
There are two situations that motivated the creation of the project:
1. Aircraft Autopilots are often used in university control system courses and textbooks as
motivating examples. Unfortunately, most university laboratory settings do not make it
possible for students to gain hands-on experience in the design, implementation, and
testing of such systems. While students could always design an autopilot in a simulation
package such as Matlab/Simulink, they generally lack the opportunity to see how their
newly designed autopilot performs on a realistically simulated aircraft in a realistic
environment.
2. Autonomous Aircraft are rising in popularity. Many universities participate in the annual
Aerial Robotics Competition [1] in which teams compete against each other in
completing certain tasks using autonomous aircraft of their design. By definition, such
aircraft require an autopilot. Flight-testing is generally used early on to test the newly
designed autopilot system. Without the ability of testing it first with a realistically
simulated version of the aircraft, such flight-tests often result in a crash and damage to
the aircraft.
In order to address both of these issues, we designed and implemented a platform for
implementing and testing digital autopilots. In addition, we designed an autopilot for a small
airplane and implemented and tested it on the platform.
The second goal was to design an autopilot for a Cessna 172SP Skyhawk airplane, and then
implement and test it on the platform. We chose to create a 2-axis autopilot consisting of an
altitude and vertical speed controller, as well as a wing-leveler. The purpose of the altitude and
vertical speed controllers is to cause the airplane to climb or descend at a desired vertical speed
until a desired target altitude is reached and then keep the airplane at this altitude until a new
command is issued. At the same time, the wing-leveler will, as the name implies, keep the
airplane in level flight. The design of the wing-leveler will not be discussed in this report, since it
is used only to make testing of the other controllers possible.
2
The project thus can be viewed as consisting of three subsystems: The Autopilot Test Platform,
the Hardware User Interface, and the Autopilot. The structure of the following chapters will
reflect this view.
The following section discusses the specifications for each subsystem. Chapters 2 and 3 discuss
the component selection and design in detail. Chapter 4 covers the testing and verification of the
system. Chapter 5 itemizes the costs associated with this project.
1.3 Specifications
1.3.1 Autopilot Test Platform
The Autopilot Test Platform has the following requirements:
Items two and three are crucial if our system is to be adopted by autonomous aircraft builders,
since it means that the autopilot code has to be written only once, and in a standard programming
language. The importance of item four will be discussed in some detail in chapter 4.
1. Provide an on/off command for the altitude/vertical speed controllers, and the wing-
leveler
2. Allow the user/pilot to enter desired values for target altitude and vertical speed
3. Display the current settings on the LCD
4. Display arbitrary messages from the autopilot on the LCD
1.3.3 Autopilot
There is considerable flexibility in defining the specifications for an autopilot. Table 1.1 lists the
response specifications of the altitude and vertical speed controllers. The specifications were set
by considering practicality, airplane vertical separation practices, and aircraft performance. The
average vertical speed tolerance listed assumes a desired vertical speed of 500 feet per minute,
the standard rate for most small aircraft. More detailed technical specifications for the individual
controllers are introduced in chapter 2.
2 DESIGN PROCEDURE
2.1.3.2 Keypad/LCD
The keypad’s function was not limited to entering parameter values. It also had to turn the
autopilot on/off and select the mode. Thus, besides cost-efficiency, the only factor in choosing a
keypad was the number of keys it had. The Grayhill 96BB2 was chosen because it offered 16
keys—digits 0-9, star, pound, and letters A-D. The only quality needed in the LCD was enough
display space. The Alesis G8 is capable of displaying 2 rows of 16 characters each.
The X-Plane Interface Software on the Rabbit2000 receives UDP packets from X-Plane, extracts
flight parameters from it, and passes these on to the autopilot routine, which calculates the
control inputs for the next time step. It then assembles control inputs from the autopilot into a
UDP packet and sends that off to X-Plane. This process then repeats with the arrival of the next
packet.
2.3 Autopilot
2.3.1 Airplane Control Basics
Altitude and vertical speed control both involve controlling the airplane’s longitudinal motion.
The airplane’s vertical movement is controlled mainly by the engine throttle. Increasing the
throttle setting will generally cause the airplane to climb, while decreasing the throttle setting
will cause it to descend. Given an adequate throttle setting, however, changing the pitch angle
using the elevator can be used to cause a change in the vertical movement. A simple elevator-
only change may also be used without a change in throttle setting for small altitude changes.
Using just only the elevator for altitude control results in a fast response, trading airspeed for
altitude. The pilot must therefore make sure that the throttle setting is adequate at all times in
order to prevent the airplane from becoming too slow during elevator-only altitude changes. In
small airplanes, such as the Cessna 172, the autopilot does not have access to the throttles. As a
result, all longitudinal control is accomplished by changing the elevator deflection angle only.
Equation 2.3.1 represents the elevator angle to pitch angle linearized transfer function of a Piper
Dakota airplane as given in [3]. We used this model in the design of our Cessna 172 autopilot
under the assumption that the two airplanes are fairly similar.
It is important to note that the relationship between elevator angle and pitch angle depends on
airspeed. It has been determined that equation 2.3.1 is approximately correct for airspeeds close
6
to 90 knots in the Cessna 172. For an in-depth treatment of the derivation of this transfer function
and longitudinal aircraft motion in general, the reader is referred to [4].
The wing-leveler controls the lateral movement of the aircraft (specifically, it tries to maintain
zero bank angle). The airplane’s bank angle is controlled primarily by the ailerons.
1. There wouldn’t be a direct way to limit the airplane’s pitch to reasonable limits. This
could result in unusual airplane attitudes.
2. Altitude is less sensitive to elevator changes than pitch. This would potentially degrade
the performance of the system
The altitude controller’s input is the difference between the target altitude and the actual current
altitude. The actual altitude is obtained from the airplane’s altimeter. The controller outputs a
desired pitch angle, which is fed into the pitch controller.
The vertical speed controller’s input is the difference between the desired vertical velocity and
the actual current vertical velocity of the airplane. The actual vertical velocity of the aircraft is
obtained by differentiating the altitude reading and proper scaling.
During a climb or descent, the vertical speed controller will switch over to the altitude controller
when the actual altitude gets close to the target altitude.
The pitch controller was designed using the frequency domain / Bode method. The outer loops
contain non-linear elements in their feedback path, making analytical design techniques difficult.
As a result, a Simulink model of the system has been created. Each controller’s parameters were
then tweaked until the simulated response met or exceeded the time domain response
specifications listed in table 2.1.
7
Pitch Controller Rise Time (90%) <1 [sec] Realistic time for small
pitch change in a
Cessna 172
Max. Overshoot <10 [%] Passenger comfort
For the pitch controller, a lead compensator was chosen to increase the phase margin (to meet the
damping specification) of the system. Equation 2.3.2 shows the generic transfer function of the
lead compensator.
s +z
D p (s) = K , p >z (2.3.2)
s+p
For the vertical speed controller, PI (Proportional, Integral) control was chosen. Integral
feedback is used to meet the maximum steady state altitude error constraint. In a continuous
controller, properly designed PI control guarantees perfect reference tracking, as well as zero
steady state error under the influence of constant disturbances (though in the discrete
approximation, this is not exactly true, since it effectively introduces a high-frequency rolloff).
This constant disturbance immunity also compensates for slight modeling errors, such as the
constant airspeed assumption, and the crude approximation of the pitch-altitude relation. Most
importantly, it compensates for the fact that with the real (and X-Plane) airplane, the pitch angle
for zero elevator deflection is not zero, contrary to what our model (equation 2.3.1) says.
Equation 2.3.3 shows the generic transfer function of the PI controller. Adding derivative
8
feedback theoretically would have resulted in better damping, but didn’t work well in practice
due to the approximate differentiator used.
1
Dv ( s ) = k p + k i (2.3.3)
s
For the altitude controller, PID (Proportional, Integral, Derivative) control was chosen.
Derivative control was added in order to achieve good damping. Equation 2.3.4 shows the
generic transfer function of the PID controller.
1
Da ( s ) = k p + k d s + k i (2.3.4)
s
2 1 − z −1
s= (2.3.5)
T 1 + z −1
After making this substitution, the difference equation describing each controller can be read off
from the discrete transfer function in z. It should be noted that due to the dependence on T, a
change in the sample period requires recalculating the coefficients of the difference equation.
The actual difference equation for each controller is calculated in chapter 3.
One consideration when using an approximation method is the fact that it usually only yields
reasonable results with sample rates greater than 20 times the closed-loop bandwidth of the
system. At lower sample rates, better results may sometimes be obtained using direct digital
design, as described in any digital controls text.
9
3 DESIGN DETAILS
+5V
30k
24
VDD
1 TX (Serial Out)
1
2 RX (Serial In)
VDD
18 12 EN
1 5
2 6 17 14 RS
3 7
BS2
Keypad 4 8
16 4 DB7
LCD
5 9 15 3 DB6
6 10
14 6 DB5
7 11
8 12 13 5 DB4 GND
2
GND
23
3.2.2 Software
The BASIC Stamp (BS2) served 3 primary functions: serial communication with the Rabbit,
encoding of the keypad bits, and writing to the LCD. Figures 3.21 and 3.3 show the program
flow of the BS2 code.
3.3 Autopilot
3.3.1 Control Loops
Figure 3.4 shows the SIMULINK model of the autopilot. The switches shown are used to switch
between the vertical speed and altitude controllers. The switch from the vertical speed to altitude
controller occurs 50 feet from the target altitude. Saturation blocks were added to limit the
1
The remaining figures in this chapter appear at the end of the chapter.
10
commanded pitch to +/- 5 degrees, and commanded elevator deflection to +/- 15 degrees for
safety. Figure 3.5 shows the inside of the altitude PID controller. The vertical speed controller is
similar in structure, but lacking the derivative action. The switch there is to prevent the integrator
from saturating before the altitude controller is switched to.
The controller transfer functions are thus given by the following equations.
s +3
D p ( s ) = 1 .5 ,p>z (3.3.1)
s + 20
1
Dv ( s ) = 0.002 + 0.0008 (3.3.2)
s
1
Da ( s ) = 0.3 + 0.80 s + 0.01 (3.3.3)
s
After making the substitution described by equation 2.3.5 with T=0.1 in each controller transfer
function, we obtain the following discrete controller transfer functions.
11
0.8625 z − 0.6375
D p ( z) = (3.3.4)
z
z +1
Dv ( s ) = 0.002 + 0.0004 (3.3.5)
z −1
z −1 z +1
Da ( s ) = 0.3 + 16 + 0.005 (3.3.6)
z +1 z −1
The difference equations used to implement these controllers in software are easily obtained by
inspection to be:
4 DESIGN VERIFICATION
4.3 Autopilot
4.3.1 Test Procedure
The autopilot was tested by comparing the altitude response to desired altitude change of X-
Plane’s Cessna 172 controller by our autopilot to that obtained from the SIMULINK simulation.
While the degree to which the altitude profile in response to the autopilot meets the
specifications outlined in chapter 1, other variables were also compared to those from the
SIMULINK simulation. These include vertical velocity and pitch. Looking at these additional
parameters is helpful for identifying possible problems.
16
4.3.2 Results
Figure 4.12 shows the altitude profile for a climb from 267 feet to 1000 feet. The responses from
X-Plane and SIMULINK are overlayed. The two responses look very similar, and it is clear that
the autopilot is functional. There are some small differences, however. The most prominent
difference is the presence of some slight oscillations in the X-Plane response. This is most
apparent in the first 20 seconds. The altitude seems to initially increase slightly faster in the X-
Plane response compared to that from Simulink. After about 40 seconds, however, the responses
are parallel. Figure 4.2 shows just the part of the responses for the time after the vertical speed
controller is switched over to the altitude controller. Table 4.1 summarizes the response
characteristics obtained from this plot. Comparison with table 1.1 shows that all specifications
have been met.
Figure 4.3 shows plots of the additional parameters mentioned in the previous section: pitch3 and
vertical velocity4. It’s quite obvious that the pitch and, as a result, the vertical velocity from X-
Plane has relatively large oscillations compared to the Simulink results. This helps explain the
initial oscillatory trend in the altitude profile. Overall, the altitude profile isn’t affected much by
this, since the pitch and vertical velocity match closely on average. These oscillations can be
shown to be due to inadequate damping of the discrete pitch controller, which is in turn due to
our low sampling rate (roughly three times the bandwidth). As discussed in chapter 2, in order to
get an adequately damped response using the discrete approximation of the continuous
controller, the sample rate should be at least 20 times as large as the bandwidth. A faster
microprocessor would allow an increased sampling rate. The difference equations could be easily
updated to reflect the new sample rate, and the oscillatory behavior is expected to disappear.
2
Figures appear at the end of the chapter.
3
The reason for the vertical offset for the pitch angle from X-Plane vs. SIMULINK is discussed in section 2.3.3.
4
The vertical velocity plot from X-Plane data is only valid before the time the altitude controller is switched to. The
reader should thus ignore the constant part at the end.
17
5 COSTS
6 CONCLUSIONS
6.1 Accomplishments
The project successfully addresses the situations mentioned in section 1.1. It is demonstrated that
it is possible to design an autopilot system using Matlab/SIMULINK, implement it on the
platform in the standard C language, and find that it performs using X-Plane’s aircraft as
expected. The small size and large number of connectivity options of the Rabbit makes it
possible to remove it from the platform and use it in an actual autonomous aircraft without
having to rewrite the autopilot code.
7 REFERENCES
[1] Association for Unmanned Vehicle Systems, Georgia Institute of Technology, “Aerial
Robotics Competition,” April 2003, http://avdil.gtri.gatech.edu/AUVS/IARCLaunch-
Point.html.
[4] J. B. Russel, Performance and Stability of Aircraft. New York: John Wiley & Sons, 1996.