Docstoc

DIGITAL AUTOPILOT TEST PLATFORM WITH REFERENCE DESIGN AND

Document Sample
DIGITAL AUTOPILOT TEST PLATFORM WITH REFERENCE DESIGN AND Powered By Docstoc
					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 University of Illinois at Urbana-Champaign

ii

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
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 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 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 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 COSTS ............................................................................................................................................... 19 CONCLUSIONS ................................................................................................................................ 20 6.1 Accomplishments ...................................................................................................................... 20 6.2 Challenges and Uncertainties .................................................................................................... 20 6.3 Future Work and Possibilities.................................................................................................... 20 REFERENCES ................................................................................................................................... 21

2

3

4

5 6

7

1

1 1.1 Motivation

INTRODUCTION

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 wingleveler 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
Altitude (Response to 50 foot altitude change)

Characteristic
Rise Time (90%) Maximum Overshoot Settling Time (10%) Steady State Error Damping Avg. Vertical Speed

Specification
<10 [sec] < 50 [ft] < 60 [sec] < 25 [ft] ―good‖ 450 – 550 [ft/min]

Vertical Speed (500 ft/min climb)

4

2 2.1 Component Selection

DESIGN PROCEDURE

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 elevatoronly 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.

G(s) 

 (s) 160 s 2  512 s  280  4  ( s ) s  5.03 s 3  40 .21s 2  1.5s  2.4

(2.3.1)

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.1: RESPONSE SPECIFICATIONS

Controller
Altitude

Characteristic
Rise Time (90%)

Value
10 [sec]

Basis for choice of specification
Realistic time for 50 foot altitude change in a Cessna 172 Traffic separation; Passenger comfort

(Response to 50 foot altitude change)

Max. Overshoot Settling Time (10%) Stead State Error Damping

<50 [feet] <60 [sec] <25 [feet] Good / Little oscillation 2 [sec]

Passenger comfort

Vertical Speed

Rise Time (90%)

Max. Overshoot Settling Time (10%) Stead State Error Damping

<100 [fpm] <4 [sec] <50 [fpm] Good / Little oscillation <1 [sec]

Realistic time for vertical speed change in a Cessna 172 Passenger comfort Predictability of timeto-target-altitude Passenger comfort

Pitch Controller

Rise Time (90%)

Max. Overshoot Damping

<10 [%] Good (aim for damping ratio of 0.7)

Realistic time for small pitch change in a Cessna 172 Passenger comfort Passenger comfort; outer loop controllers

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.
D p (s)  K sz ,pz s p

(2.3.2)

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.

8 Equation 2.3.3 shows the generic transfer function of the PI controller. Adding derivative feedback theoretically would have resulted in better damping, but didn’t work well in practice due to the approximate differentiator used.
Dv ( s)  k p  ki 1 s

(2.3.3)

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.
Da ( s)  k p  kd s  ki 1 s

(2.3.4)

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.
s 2 1  z 1 T 1  z 1

(2.3.5)

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
1 TX (S erial Out) 2 RX (S erial In) 1 2 5 6 7 8 18 17 12 EN 14 RS 4 DB7 3 DB6 6 DB5 5 DB4

VDD

1 VDD

Keypad

3 4 5 6 7 8

BS2

16 15 14 13

LCD

9
10 11 12

GND 2

GND 23

Figure 3.1: 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
1

The remaining figures in this chapter appear at the end of the chapter.

10 controller occurs 50 feet from the target altitude. Saturation blocks were added to limit the 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.1: CONTROLLER PARAMETERS

Controller
Pitch

Controller Type
Lead Compensator

Parameter
K z p kp ki kp kd ki

Value
1.5 3 20 0.0020 0.0008 0.30 0.80 0.01

Vertical Speed

PI

Altitude

PID

The controller transfer functions are thus given by the following equations.
D p ( s)  1.5 s3 ,pz s  20 1 Dv ( s)  0.002  0.0008 s 1 s

(3.3.1) (3.3.2) (3.3.3)

Da ( s)  0.3  0.80s  0.01

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.8625z  0.6375 (3.3.4) z z 1 (3.3.5) Dv ( s)  0.002  0.0004 z 1 z 1 z 1 (3.3.6) Da ( s)  0.3  16  0.005 z 1 z 1 D p ( z) 

The difference equations used to implement these controllers in software are easily obtained by inspection to be:

evvel(n)  vvelactual (n)  vvelt arget (n) vvelp (n)  0.002evvel(n) vveli (n)  0.0004evvel(n)  evvel(n  1)  yvvel(n  1) yvvel(n)  vvelp (n)  vveli (n)
ealt (n)  altactual (n)  altt arget (n) alt p (n)  0.3ealt (n) alti (n)  0.008ealt (n)  ealt (n  1)  yalt (n  1) altd (n)  16ealt (n)  ealt (n  1)  yalt (n  1) yalt (n)  alt p (n)  alti (n)  altd (n)

(3.3.7 a-d)

(3.3.8 a-e)

e pitch (n)  pitchactual (n)  pitcht arget (n) y pitch (n)  0.575e pitch (n)  0.425e pitch (n  1)

(3.3.9 a,b)

12

Figure 3.2: Software Flowchart

13

Figure 3.3: Scan_Keypad Subroutine

14

Figure 3.4: Simulink Model

Figure 3.5: 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 XPlane’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 XPlane 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.1: X-PLANE AND SIMULINK RESPONSE CHARACTERISTICS

Response from
SIMULINK Altitude Controller (Response to 50 foot altitude change)

Characteristic
Rise Time (90%) Maximum Overshoot Settling Time (10%) Steady State Error Avg. Vertical Speed

Value
3.8 [sec] 9 [ft] 37 [sec] 0 [ft] 495 [ft/min]

Vertical Speed Controller (500 ft/min climb) X-Plane (Cessna 172) Altitude Controller (Response to 50 foot altitude change)

Rise Time (90%) Maximum Overshoot Settling Time (10%) Steady State Error Avg. Vertical Speed

5.0 [sec] 13.8 [ft] 41 [sec] 5 [ft] 505 [ft/min]

Vertical Speed Controller (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 XPlane 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 3

Figures appear at the end of the chapter. 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.1: Altitude Profile (Simulink & X-Plane)

Figure 4.2: Altitude Response

18

Figure 4.3: Additional Variables

19

5

COSTS

TABLE 5.1: PROJECT COSTS

Part Name
X-Plane 6.51 RabbitCore2200 Crossover Ethernet Cable BASIC Stamp 2 30kΩ Resistor, 0.25W Keypad (Grayhill) LCD (Alesis) Parallax Serial Cable TOTAL Parts

Part Number
RCM2200

Unit Cost
$59.99 $239.00 $5.00

Quantity
1 1 1

Total Cost
$59.99 $239.00 $5.00

BS2-IC 96BB2-006-R 9-40-1381-C 800-0003

$49.00 $0.15 $16.08 $59.00 $10.00

1 8 1 1 1

$49.00 $1.20 $16.08 $59.00 $10.00 $439.27

Payroll
Michael Frutiger Charles Kim TOTAL Payroll GRAND TOTAL

Hourly Salary
$50 $50

Hours
80 40 *2.5 *2.5

Total Cost
$10,000 $5,000 $15,000 $15,439.30

20

6 6.1 Accomplishments

CONCLUSIONS

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/IARCLaunchPoint.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.


				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:48
posted:11/28/2009
language:English
pages:24