You are on page 1of 24

DIGITAL AUTOPILOT TEST PLATFORM WITH REFERENCE DESIGN

AND IMPLEMENTATION OF A 2-AXIS AUTOPILOT FOR SMALL


AIRPLANES

By

Michael Frutiger

and

Charles Kim

ECE345
TA: Paul Leisher
May 6, 2003

Project #45

Department of Electrical and Computer Engineering


ii

University of Illinois at Urbana-Champaign


ABSTRACT

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

DIGITAL AUTOPILOT TEST PLATFORM WITH REFERENCE DESIGN AND


IMPLEMENTATION OF A 2-AXIS AUTOPILOT FOR SMALL AIRPLANES......................................I
ABSTRACT...............................................................................................................................................II
TABLE OF CONTENTS..........................................................................................................................III
1 INTRODUCTION....................................................................................................................................1
1.1 Motivation.........................................................................................................................................1
1.2 Project Goals and Overview..............................................................................................................1
1.2.1 Main Goals & Subsystems.........................................................................................................1
1.2.2 System Overview.......................................................................................................................2
1.3 Specifications....................................................................................................................................2
1.3.1 Autopilot Test Platform..............................................................................................................2
1.3.2 Hardware User Interface............................................................................................................3
1.3.3 Autopilot....................................................................................................................................3
2 DESIGN PROCEDURE...........................................................................................................................4
2.1 Component Selection.........................................................................................................................4
2.1.1 Flight Simulator (PC-Based)......................................................................................................4
2.1.2 Autopilot Platform.....................................................................................................................4
2.1.3 Hardware User Interface............................................................................................................4
2.1.3.1 Microcontroller...................................................................................................................4
2.1.3.2 Keypad/LCD.......................................................................................................................5
2.2 Autopilot Platform X-Plane Interface Software.................................................................................5
2.3 Autopilot...........................................................................................................................................5
2.3.1 Airplane Control Basics.............................................................................................................5
2.3.2 Control Loops............................................................................................................................6
2.3.3 Controller Design.......................................................................................................................6
2.3.4 Discrete-Time Implementation...................................................................................................8
3 DESIGN DETAILS..................................................................................................................................9
3.1 Autopilot Platform X-Plane Interface Software.................................................................................9
3.2 Hardware User Interface....................................................................................................................9
3.2.1 Hardware....................................................................................................................................9
3.2.2 Software ....................................................................................................................................9
3.3 Autopilot...........................................................................................................................................9
3.3.1 Control Loops............................................................................................................................9
3.3.2 Controller Design.....................................................................................................................10
3.3.3 Discrete-Time Implementation.................................................................................................10
4 DESIGN VERIFICATION.....................................................................................................................15
4.1 Autopilot Platform X-Plane Interface Software...............................................................................15
4.2 Hardware User Interface..................................................................................................................15
4.3 Autopilot.........................................................................................................................................15
4.3.1 Test Procedure..........................................................................................................................15
4.3.2 Results......................................................................................................................................16
5 COSTS....................................................................................................................................................19
6 CONCLUSIONS....................................................................................................................................20
6.1 Accomplishments............................................................................................................................20
6.2 Challenges and Uncertainties..........................................................................................................20
6.3 Future Work and Possibilities..........................................................................................................20
7 REFERENCES.......................................................................................................................................21
1

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.

1.2 Project Goals and Overview


1.2.1 Main Goals & Subsystems
The first goal was to create a platform on which digital autopilots can be implemented and
tested. The platform is to consist of a microcontroller that hosts the autopilot code and interfaces
with an advanced PC-based flight simulator. To facilitate entering settings into the autopilot, a
hardware user interface consisting of a keypad and LCD display is also required.

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.

1.2.2 System Overview


Figure 1.1 gives a high-level overview of the complete system.

Figure 1.1: System Overview

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:

1. Needs to provide an interface to a realistic and accurate PC-based flight simulator


2. Needs to allow autopilot to be implemented in standard C language, with little knowledge
of the underlying flight simulator interface
3. Needs to allow the hardware module (microcontroller and supporting hardware) to be
used in an actual autonomous aircraft
4. Needs to be able to accommodate high enough and constant sampling rates to make
digital autopilot implementation possible
3

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.3.2 Hardware User Interface


The Hardware User Interface subsystem is fairly simple. Its only requirements are to allow the
user/pilot to enter autopilot commands and parameters, and then deliver these to the autopilot.
Similarly, it needs to be able to display parameters sent to it by the autopilot. In the specific
instance of the autopilot described in the next section, the requirements are:

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.

TABLE 1.1: RESPONSE SPECIFICATIONS

Controller Characteristic Specification


Altitude Rise Time (90%) <10 [sec]
(Response to 50 foot Maximum Overshoot < 50 [ft]
altitude change) Settling Time (10%) < 60 [sec]
Steady State Error < 25 [ft]
Damping “good”

Vertical Speed Avg. Vertical Speed 450 – 550 [ft/min]


(500 ft/min climb)
4

2 DESIGN PROCEDURE

2.1 Component Selection


2.1.1 Flight Simulator (PC-Based)
There are various PC-based flight simulators on the market. The major ones are Microsoft Flight
Simulator, FlightGear, and X-Plane [2]. FlightGear is a freely available open-source program.
This was initially our flight simulator of choice, since having the ability to change the source
code would guarantee access to any internal flight and simulation parameters we need. However,
we chose the commercial X-Plane simulator for our project because it has the most realistic
flight and atmospheric models and has the built-in capability to exchange flight parameters with
external applications via a variety of protocols. In addition, X-Plane includes an easy-to-use
program for creating one’s own aircraft model. This provides builders of autonomous aircraft the
ability to quickly create an X-Plane model of their aircraft for use with the platform.

2.1.2 Autopilot Platform


As mentioned in chapter 1, the microcontroller should be programmable in the standard C
language. We initially proposed using a Texas Instruments TMS320C67x series DSP board
because of our past experience with this architecture and its solid C compiler. However, it was
lacking the digital Input/Output capabilities to allow a timely implementation of the connection
to X-Plane. Instead, we chose the RabbitCore RCM2200 C-Programmable Microcontroller
Module with Ethernet. The module features the Rabbit 2000, an 8-bit microcontroller with
256Kbytes of Flash memory running at 22.1Mhz. The availability of onboard Ethernet makes it
possible to communicate with X-Plane using the UDP (Uniform Datagram Protocol).

2.1.3 Hardware User Interface


2.1.3.1 Microcontroller
The first step in implementing the interface was choosing the microcontroller. The desired
functions did not require an overly sophisticated microprocessor, so one that was cost-effective,
yet versatile, was ideal. For this reason and because of its small size, the BASIC Stamp by
Parallax was chosen. The other viable options were the TI-54 and the Motorola HC-12.
However, in a design that does not particularly necessitate fast processor speed, these
microcontrollers can present more drawbacks than benefits. Even after the BASIC Stamp was
chosen, there were options as to which version to utilize. The BASIC Stamp 2 (BS2) seemed to
offer the best combination of features. Ample memory space was necessary and the 32 Bytes of
RAM as well as 2K Bytes of EEPROM offered by the BS2 were sufficient. The microprocessor
would serve to not only operate the keypad and LCD, but to also exchange information with the
Rabbit. Therefore, one with a serial port as well as a good number of I/O pins was needed. The
BS2 had 16 I/O pins plus 2 dedicated serial pins. And although processor speed was not a
priority, the 20 MHz speed was nice to have. In addition to all this, the BS2 is especially
attractive because it is easy to program--it is run in PBASIC (Parallax’s simplified version of
BASIC).
5

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.

2.2 Autopilot Platform X-Plane Interface Software


X-Plane has the built-in capability of transmitting flight parameters at a set interval over Ethernet
using UDP (Uniform Datagram Protocol). UDP is well suited for our purpose because it has low
overhead. Similarly, X-Plane accepts UDP packets sent to it for modifying X-Plane flight
parameters, or any other exportable variable.

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.

ρ( s ) 160 s 2 + 512 s + 280


G (s) = = 4 (2.3.1)
φ( s ) s + 5.03 s 3 + 40 .21 s 2 +1.5s + 2.4

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.

2.3.2 Control Loops


The autopilot has a total of three control loops for longitudinal control (vertical speed and
altitude). Figure 3.4 at the end of chapter 3 shows these loops. As described in section 2.3.1, the
autopilot makes changes to vertical speed and altitude by changing the pitch angle of the
airplane. Thus, we have at the heart of the longitudinal control the pitch controller. It controls the
elevator angle to achieve a desired reference pitch angle. The user/pilot doesn’t have the ability
to command pitch directly using the pitch controller. It is merely used as an inner loop for the
vertical speed and altitude controllers. This inner loop could be removed, letting the vertical
speed and altitude controllers directly control the elevator. This, however, would have several
drawbacks:

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.

2.3.3 Controller Design


Most literature on aircraft control uses continuous control system design techniques. In fact,
many aircraft still feature autopilots based on analog amplifier circuits. Because of this, and also
due to our background in continuous control, we decided to design continuous controllers, even
though the software implementation ultimately requires a discrete controller (section 2.3.4
describes how the transformation from continuous to discrete time is done).

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

TABLE 2.2: RESPONSE SPECIFICATIONS

Controller Characteristic Value Basis for choice of


specification
Altitude Rise Time (90%) 10 [sec] Realistic time for 50
foot altitude change in
a Cessna 172
(Response to 50 foot Max. Overshoot <50 [feet] Traffic separation;
altitude change) Passenger comfort
Settling Time (10%) <60 [sec]
Stead State Error <25 [feet]
Damping Good / Little Passenger comfort
oscillation

Vertical Speed Rise Time (90%) 2 [sec] Realistic time for


vertical speed change
in a Cessna 172
Max. Overshoot <100 [fpm] Passenger comfort
Settling Time (10%) <4 [sec]
Stead State Error <50 [fpm] Predictability of time-
to-target-altitude
Damping Good / Little Passenger comfort
oscillation

Pitch Controller Rise Time (90%) <1 [sec] Realistic time for small
pitch change in a
Cessna 172
Max. Overshoot <10 [%] Passenger comfort

Damping Good (aim for Passenger comfort;


damping ratio outer loop controllers
of 0.7)

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.3.4 Discrete-Time Implementation


In order to implement the continuous controllers discussed above in software, they must be
converted to approximate discrete systems. Commonly used approximation methods are the
Bilinear Transform and the Matched Pole-Zero Method, both of which are similar in accuracy.
The Bilinear Transform was chosen for our autopilot since it is easier to calculate. The
transformation simply involves making the substitution shown in equation 2.3.5 in the controller
transfer functions. The constant T is the sample period.

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

3.1 Autopilot Platform X-Plane Interface Software


Detailed information regarding the X-Plane Interface Software for the Rabbit is best obtained by
examining the commented source code, which can be found in the Appendix (see project
website).

3.2 Hardware User Interface


3.2.1 Hardware
Figure 3.1 shows the circuit schematics for the interface hardware.

+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

Figure 3.2: Circuit Schematic

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.

3.3.2 Controller Design


The designed continuous controllers all exceed the specifications (as summarized in table 2.1).
Table 3-1 lists the values chosen for the controller parameters. Preview: Figures 4.1 – 4.3 show
the SIMULINK generated responses.

TABLE 3.3: CONTROLLER PARAMETERS

Controller Controller Parameter Value


Type
Pitch Lead Compensator K 1.5
z 3
p 20

Vertical Speed PI kp 0.0020


ki 0.0008

Altitude PID kp 0.30


kd 0.80
ki 0.01

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

3.3.3 Discrete-Time Implementation


The sample period was chosen as small as possible. The limiting factor was the time required for
the Rabbit processor to receive and send a UDP packet. A sample period of 0.1 seconds was
chosen (this is equivalent to a 10 Hz sample rate). As seen in section 3.3.2, this is only about
three times the closed-loop bandwidth of the pitch controller (3.04 Hz). This relatively low
sample rate results in decreased damping of the discrete pitch controller, the effects of which are
discussed in chapter 4.

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:

evvel ( n) = vvel actual ( n) − vvel t arg et ( n)


vvel p (n) = 0.002 evvel (n)
(3.3.7 a-d)
vvel i ( n) = 0.0004 [evvel (n) + evvel (n −1) + yvvel (n −1)]
yvvel (n) = vvel p (n) + vvel i (n)

ealt ( n) = alt actual ( n) − alt t arg et ( n)


alt p ( n) = 0.3ealt ( n)
alt i ( n) = 0.008 [ ealt ( n) + ealt ( n −1) + yalt ( n −1) ] (3.3.8 a-e)
alt d ( n) =16 [ ealt ( n) − ealt ( n −1) − yalt ( n −1)]
yalt ( n) = alt p ( n) + alt i ( n) + alt d ( n)

e pitch ( n) = pitch actual ( n) − pitch t arg et (n)


y pitch ( n) =0.575 e pitch ( n) −0.425 e pitch ( n −1) (3.3.9 a,b)
12

Figure 3.3: Software Flowchart


13

Figure 3.4: Scan_Keypad Subroutine


14

Figure 3.5: Simulink Model

Figure 3.6: Altitude PID Controller


15

4 DESIGN VERIFICATION

4.1 Autopilot Platform X-Plane Interface Software


The basic operation of the X-Plane Interface Software was verified by simply sending known
parameters in both directions and making sure they are received correctly. In order for the
discrete time approximation of the controllers to perform well, a constant sample period is
required. In order to make sure this assumption is true, the time between the arrivals of
successive UDP packets was measured. At our sample rate of 10Hz, the time between arrivals
was accurate to within the clock resolution used (1 millisecond). A crossover Ethernet cable
between the Rabbit and X-Plane was used for this test, with no other network traffic.

4.2 Hardware User Interface


The three basic functions of the Basic Stamp 2 (BS2) were first written as separate programs and
then tested independently, before being implemented together. Displaying flight parameters sent
from the Rabbit was the first sub-algorithm tested. For testing sake, flight parameters were set
constant, if/then statements were fixed to ensure the scrolling flight status display was
functioning. The DEBUG window in the BASIC Stamp Editor was used to mimic the LCD
display. Actual communication with the Rabbit itself was allowed for in the code, but was not
tested in real-time. For the keypad, the algorithm for encoding the keys had to be tested first.
Initially, testing was focused on making sure the correct row was designated. Once this was
found functional, the program was tested for correct column placement. Minor logic flaws, as
well as key reconfiguration, were added to accurately display the correct key. In order to
conserve pin usage, the LCD was designed to run in 4-bit interface mode. The LCDwr (LCD
write) subroutine was tested by fixing the character value. Each of the other functions, such as
moving the cursor, shifting the display, and clearing the display, were each tested in turn.
After each of these sub-algorithms was functioning properly, they were combined. Rabbit
communication was still simulated (by fixing parameter values), but the rest of the program was
tested completely. Proper LCD operation could not be verified, and as a result, the DEBUG
window was used to simulate it. With the DEBUG window, the rest of the program was verified
to be functional. The proper flight parameters and status values were displayed and scrolled
through. When the MODE key was pressed, the scrolling display was interrupted, and the user
was prompted to enter new altitude and vertical speed values. Once these were entered, the
display resumed, with the new values displayed.

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.

TABLE 4.4: X-PLANE AND SIMULINK RESPONSE CHARACTERISTICS

Response from Characteristic Value


SIMULINK
Altitude Controller Rise Time (90%) 3.8 [sec]
(Response to 50 foot Maximum Overshoot 9 [ft]
altitude change) Settling Time (10%) 37 [sec]
Steady State Error 0 [ft]

Vertical Speed Controller Avg. Vertical Speed 495 [ft/min]


(500 ft/min climb)

X-Plane (Cessna 172)


Altitude Controller Rise Time (90%) 5.0 [sec]
(Response to 50 foot Maximum Overshoot 13.8 [ft]
altitude change) Settling Time (10%) 41 [sec]
Steady State Error 5 [ft]

Vertical Speed Controller Avg. Vertical Speed 505 [ft/min]


(500 ft/min climb)

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

Figure 4.7: Altitude Profile (Simulink & X-Plane)

Figure 4.8: Altitude Response


18

Figure 4.9: Additional Variables


19

5 COSTS

TABLE 5.5: PROJECT COSTS

Part Name Part Number Unit Cost Quantity Total Cost


X-Plane 6.51 $59.99 1 $59.99
RabbitCore2200 RCM2200 $239.00 1 $239.00
Crossover Ethernet $5.00 1 $5.00
Cable

BASIC Stamp 2 BS2-IC $49.00 1 $49.00


30kΩ Resistor, 0.25W $0.15 8 $1.20
Keypad (Grayhill) 96BB2-006-R $16.08 1 $16.08
LCD (Alesis) 9-40-1381-C $59.00 1 $59.00
Parallax Serial Cable 800-0003 $10.00 1 $10.00

TOTAL Parts $439.27

Payroll Hourly Salary Hours Total Cost


Michael Frutiger $50 80 *2.5 $10,000
Charles Kim $50 40 *2.5 $5,000

TOTAL Payroll $15,000

GRAND TOTAL $15,439.30


20

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.

6.2 Challenges and Uncertainties


There are still a couple of challenges and uncertainties remaining. As was seen in chapter 4, it is
necessary to increase the sample rate of the system. While it can be shown using simulations that
merely doubling the sample rate results in greatly improved performance for the Cessna 172
autopilot, a much higher sampling rate needs to be supported in order for the platform to be of
general use. Whether or not this can be accomplished using the faster Rabbit 3000
microcontroller is unclear at this time. Another option would be to replace the UDP link with a
high-speed serial connection. This would eliminate the computational overhead for UDP
communications on the Rabbit and may make higher sampling rates possible. The exact tradeoffs
between the two solutions would need to be explored further. In addition, the hardware user
interface unit still needs to be debugged further in order to pinpoint why the LCD was only
working intermittently.

6.3 Future Work and Possibilities


After resolving the uncertainties mentioned above, the platform can be advertised and
demonstrated to builders of autonomous aircraft builders such as the University of Illinois’
Aerial Robotics team. In order to be of the most use in this setting, possibilities must be
investigated for linking the autopilot platform to navigational equipment such as a Global
Positioning Receiver or even a full-fledged Flight Management System. The platform could also
be shown to control system faculty at the University of Illinois in order to explore the possibility
of incorporating it into the laboratory for student projects.
21

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.

[2] Laminar Research, “X-Plane Description,” April 2003, http://www.x-plane.com/


descrip.html.

[4] J. B. Russel, Performance and Stability of Aircraft. New York: John Wiley & Sons, 1996.

[5] J. H. Blakelock, “Longitudinal Dynamics,” in Automatic Control of Aircraft and Missiles.


New York: John Wiley & Sons, 1991, ch. 2, pp. 7-61.