AIAA Infotech@Aerospace Conference
and
AIAA Unmanned...Unlimited Conference 6 - 9 April 2009, Seattle, Washington

AIAA 2009-1963

Evaluation of a COTS Autopilot and Avionics System for UAVs Hou In, Leong 1 and Shahriar Keshmiri 2 The University of Kansas, Lawrence, KS, 66045 Rylan Jager 3 The University of Kansas, Lawrence, KS, 66045

This paper summarizes an investigation report of a UAV flight incident operation due to communication issues. A commercial off-the-shelf autopilot system was tested on a RC airplane in support of an ongoing UAV development program. During final approach of a flight test, the communication link dropped and the pilot lost control of the aircraft causing it to impact the runway. An extensive investigation was conducted and all available flight test data were examined. An unexpected and frequent data drop out was observed in each flight data, droving the team to conduct twenty-one laboratory tests to investigate the cause of the data drop. The final results show that the autopilot system has an inherent and inevitable communication drop out problem which behaves unpredictably. The communication drops exist on both uplink and downlink which in turn cause the pilot handling qualities to suffer significantly due to the random, temporary loss of control. It is concluded that the autopilot system cannot meet the safety requirements to operate the UAV and therefore is no longer considered for the UAV development program.

I. Introduction

I

t has been predicted that, in the near future, UAVs will be the fastest growing segment in the aerospace industry. The University of Kansas is a leading research and integrated education center1 in design, build, fly activities for projects ranging from remote sensing to intelligent transportation systems. The Meridian2 is an Uninhabited Aircraft System (UAS) currently under development at the Department of Aerospace Engineering, University of Kansas (KUAE) for use in Polar Regions for science missions.1 The Meridian will fly under the autonomous control of an autopilot. Designing a new autopilot in-house from the ground up requires a great deal of development time, resources, and man power with numerous risks to the flight test program. Commercial off-the-shelf (COTS) autopilots are available at relatively low cost to support a short design cycle UAV development programs. In order to choose an appropriate autopilot system for the Meridian, a deliberate test and evaluation process is developed to determine if the autopilot system can satisfy all of the requirements to safely operate the aircraft and perform the science mission. The initial choice of autopilot system was extensively tested on a low cost, one-third scale Yak-54 RC model airplane in order to evaluate its performance in multiple perspectives including command, stability, control, and communication. This paper focuses on the communication system of the autopilot.

II. Architecture of the Communication System for the Autopilot It is extremely vital for an UAS to have a reliable communication link between the ground pilot, ground crew, and the aircraft to ensure operational safety. This is especially true for those that rely on the ground pilot to manually control the aircraft during take off and landing, as is intended for the Meridian. The autopilot uses either a 900MHz or 2.4MHz Michrohard Systems, Inc.3 transceiver with a maximum power output of one Watt. In this research the 2.4GHz transceiver was used. The system provides up to 40K baud of

1

Graduate Student, Department of Aerospace Engineering, AIAA Student Member. Assistant Professor, Department of Aerospace Engineering, [email protected], AIAA Member. 3 Graduate Student, Department of Aerospace Engineering, AIAA Student Member. 1 American Institute of Aeronautics and Astronautics 2

Copyright © 2009 by Shahriar Keshmiri. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.

throughput and transfers data packages including control, autopilot telemetry, payload data, differential GPS corrections, and pilot in the loop command between the autopilot and ground station. The autopilot uses a stream manager to control the multiplexing, de-multiplexing, and packet protocol onboard the avionics. The uplink transmission rate supports up to 10Hz. The downlink supports two types of frame rates, slow (1 Hz) and fast (20 Hz), selectable by the user. Fast frames are designed to support high frequency, low latency applications like pilot in the loop commands. Slow frames sacrifice latency in order to move data more efficiently. The transmit stream manager sends the high priority streams first at the available outgoing bandwidth on the link. These stream buffers are examined in a specific order, first the autopilot buffer, then the CAN buffers, and finally any user defined buffers. Although sending packets are prioritized, all buffers are sent via a same outgoing bandwidth so any drop out can scare the pilot’s control on the aircraft. Figure 1 shows the high level layout of the communication structure operated in this autopilot system. A. Signal Strength Monitoring System The health of the transmission signals between the ground station and the avionics is monitored through the RSSI (Receive Signal Strength Indicator) signal. When the onboard avionics receives data stream from the ground station, it constantly detects the signal strength and will report back the RSSI signal. The RSSI signal is defined from -71dBm (strongest signal) to -115dBm (no signal). The avionics and ground station will determine the RSSI signal being seen by each other, and both RSSI signals are shown on the ground station operational interface for the flight test engineer to monitor the link performance in real-time. Only the RSSI signals reported by the avionics are recorded in the telemetry file.

Uplink at 10Hz (max) update rate. Manual pilot command packet included.

900 MHz or 2.4 GHz Pilot command transmits through ground station Telemetry date at downlink. 1Hz or 20Hz update rate selected by user. RSSI signal to be monitored.

Figure 1. Layout of Communication System for the Autopilot

B. Actions for Loss of Communication As explained above, the pilot-in-the-loop command is sent through the ground station to the onboard avionics, which totally relies on either the 900MHz or 2.4GHz transmission. If the communication drops, the pilot will lose the control of the aircraft. The autopilot system provides two action plans in the case of the loss of communication. The procedures are explained below, and the triggering time to activate the action plans are defined by the users. 1). The Pilot Timeout The pilot timeout defined the amount of time that the system will remain in manual flight mode when losing the manual pilot command update. If this timeout elapses the system will switch to autopilot mode automatically and will attempt to reach the last autopilot command. The manual pilot packet is sent through the uplink with other data packets and is given high priority to get through. The pilot timeout was set for 0.2 seconds for flight testing 2 American Institute of Aeronautics and Astronautics

2). The Communication Timeout If the entire communication link is lost completely for the amount of time defined by the communication timeout, the autopilot will immediately switch to the autopilot mode and will fly the emergency flight plan predefined by the user. This flight plan should be set in a safe area such that the flight operators could attempt to reestablish the communication link. The communication timeout was set for 5.0 seconds for flight testing.

III. Flight Tests Using the COTS Autopilot To evaluate the performance of the COTS autopilot system, the KUAE flight test team had conducted several semiautonomous pilot-in-loop flight tests on a one-third scale Yak-54 model UAV from Augest-2007 to March2008. On the March 13th, 2008 flight test, three separated flights were performed. During final approach of the third flight the pilot lost the control of the aircraft when it was only a few feet above the ground, causing the aircraft to impact the runway. Due to this flight incident, a investigation was conducted. The telemetry data shown in the following sections are all from the March 13th flight test. A. Taxi Test Before the aircraft took off, a taxi test was performed on the runway as part of the pre-flight check list item for the purpose of checking the integrity, functionality, and communication performance of the autopilot system. The aircraft was taxied from one end of the runway to the other several times to check the communications. The telemetry data was then pulled out and the history of the RSSI signals were plotted to inspect the performance of the link using a MATLAB4 script.

RSSI Signal - Flight Test Date : Thu Mar 13 2008; Time : 08-09-13 RSSI (dBm)

-70 -80 -90 -100 -110 -120 0

200

400

600

800 Time (sec)

1000

1200

1400

1600

Figure 2. RSSI Signal for the Taxi Test Figure 2 plots the RSSI signals from a roughly twenty-six minutes taxi test data. The “X” marks shown in green color represent the data when autopilot mode is on, and the rest of the data indicate manual mode. The RSSI signals reveal an exceptional communication performance that mostly remained at the strongest signal strength (-71 dBm) throughout the entire test except for few seconds where signals were dropped to -79 dBm. As this signal drop is remained within the safe region, the communication check was approved and the aircraft was ready for the flight test. B. 1st Take-off Flight During the closing minutes of the first flight test the pilot reported a temporary loss of control of the aircraft. The pilot immediately ended the flight test and the Yak-54 was landed safely. Instantly after the landing, the telemetry data was processed to check the RSSI signal. Figure 3 plots the RSSI signal for the entire first flight, and Fig. 4 shows the RSSI during the time the pilot reported a loss of control. A 2.5 seconds communications drop out was observed and the link was regained at the lowest signal strength of -108 dBm. Note that the autopilot mode was activated by the system right before the drop out occurred due to the pilot timeout event. It indicates that the pilot command signals were dropped before the complete communication link was lost It was also observed that occasional communication loss occurred even though the RSSI signals remained in safe region for most of the flight. As the pilot was able to regain the control of the airplane, the flight test continued.

3 American Institute of Aeronautics and Astronautics

RSSI Signal - Flight Test Date : Thu Mar 13 2008; Time : 08-43-28 RSSI (dBm)

-70 -80 -90 -100 -110 -120 0

100

200

300

400

500 Time (sec)

600

700

800

900

1000

Figure 3. RSSI Signals for the Entire 1st Flight RSSI Signal - Flight Test Date : Thu Mar 13 2008; Time : 08-43-28 RSSI (dBm)

-70 -80 -90 -100 -110 -120 838

838.5

839

839.5

840

840.5 Time (sec)

841

841.5

842

842.5

843

Figure 4. Communications Drop Out in the1st Flight C. 2nd Flight Test During the second flight the pilot once again reported a temporary loss of control. After a few seconds the pilot regained manual control and the flight test continued as normal. Figure 5 shows the RSSI signals over the entire flight, and the drop out period reported by the pilot is shown on Fig. 6. RSSI Signal - Flight Test Date : Thu Mar 13 2008; Time : 09-21-31 RSSI (dBm)

-70 -80 -90 -100 -110 -120 0

200

400

600

800 Time (sec)

1000

1200

1400

Figure 5. RSSI Signals for the Entire 2nd Flight RSSI Signal - Flight Test Date : Thu Mar 13 2008; Time : 09-21-31 RSSI (dBm)

-70 -80 -90 -100 -110 -120 729.5

730

730.5

731

731.5

732 732.5 Time (sec)

733

733.5

Figure 6. Communications Drop Out in the 2nd Flight

4 American Institute of Aeronautics and Astronautics

734

734.5

735

Similar to the case of first flight, the autopilot mode was once again triggered before the drop out occurred due to the pilot timeout event, and the signal was regained after 2 seconds at the weakest signal strength level. After discussion with the pilot, it was decided that this temporary drop out was manageable by pilot skills. Therefore, the flight test was once again decided to resume testing. D. 3rd Flight Test A temporary loss of control was once again reported by the pilot during the 3rd flight. Similar to the previous flights, the flight test proceeded as planned despite the temporary drop out. However, during final approach when the Yak-54 was just a few feet above the ground, the communication link was lost again. The autopilot mode was triggered due to the pilot timeout and the aircraft attempted to reach the last autopilot command, a 70 knot airspeed command, which caused the aircraft to nose down with full throttle. As a result, the Yak-54 plunged into the ground. Figure 7 shows the RSSI drop out during final approach, and Fig. 8 shows the engine RPM and throttle position when the drop out occurred. The RPM value showed as zero when the signal was back because the communication was not reacquired successfully until after the crash.

RSSI Signal - Flight Test Date : Thu Mar 13 2008; Time : 10-02-05 RSSI (dBm)

-70 -80 -90 -100 -110 -120 1095

1096

1097

1098 Time (sec)

1099

1100

1101

Figure 7. Communication Drop Out in the 3rd Flight during Final Approach

Throttle Position (%)

Engine Data - Flight Test Date : Thu Mar 13 2008; Time : 10-02-05 4 3.5 3 2.5 1095

1096

1097

1098

1099

1100

1101

1099

1100

1101

Time (sec)

Engie RPM

4000 3000 2000 1000 0 1095

1096

1097

1098 Time (sec)

Figure 8. Engine Data during the Communication Drop Out in the 3rd Flight Post flight inspection to the communication components showed no damage to the aerial or ground antenna and cables. From the drop outs observed in the figures above, the final signals always maintained at the highest signal strength of -71 dBm right before the communication was completely lost. From the final approach event, it 5 American Institute of Aeronautics and Astronautics

indicates that the signal drop out could occur even when the ground station and airborne antennas were in very close proximity. In order to find the real cause of the incident, a detailed investigation was carried out and the details are presented in the following sections.

IV. Investigation Procedures and Results It is learned from the incident that checking the RSSI data cannot predict the drop out. The RSSI is shown only when the link is active. When a drop out occurred, the signal was completely gone and no telemetry data was received until normal communication was resumed. When plotting the RSSI data in a long flight time history, as shown in Fig. 2, a few seconds drop out cannot not be seen due to the high density of the data. For these reasons, an accurate and efficient method is demanded to inspect and quantify these drop outs. A. Time Step Analysis Method Considering the transmission rate on downlink (telemetry data) is set to 20Hz, it is expected that the telemetry data will be received on a normal time step (Gt) of 0.05 second. If a time step (Gt) greater than 0.05 second is observed, it indicates that a drop out occurred, and the length of the time step will quantify the duration of this drop out. In addition, since the duration of the entire data is known, the expected data points can be calculated. By comparing that with the final available data points from the telemetry data, the total lost data points can be obtained for each flight. Using this time step analysis technique, the taxi test data, as shown in Fig.2, are now analyzed again and are shown in Fig. 9.

RSSI Signal - Flight Test Date : Thu Mar 13 2008; Time : 08-09-13 RSSI (dBm)

-70 -80 -90 -100 -110 -120 0

200

400

600

800 Time (sec)

1000

1200

1400

1600

200

400

600

800 Time (sec)

1000

1200

1400

1600

2.5 G t (sec)

2 1.5 1 0.5 0 0

Figure 9. Time Step Analysis Result for the Taxi Test From the time step plot as shown in Fig. 9, it unveils all the drop out cases that were not discovered from the RSSI analysis. Many drop outs that lasted between 0.5 to 2 seconds existed in this taxi test. This reveals three essential messages: 1) checking the RSSI signal from a long time history can not disclose the drop out issue. 2) the RSSI signal does not provide any prediction or real time alert that a drop out is going to occur. In this case, the RSSI signal always remained at -71 dBm before and after a communication loss. 3) the drop out occurs frequently even in the close proximity of a taxi test. The analysis of the flight test data from the March 13th 2008 flight are now repeated using the time step approach. The distribution of the RSSI data as well as the drop out data points are compared with each flight and the results are shown in Fig. 10. The statistical analysis shows that the average data drop out points are about 2.7% on the ground and 4.4% for flight tests.

6 American Institute of Aeronautics and Astronautics

March 13th, 2008 Flight Test RSSI Signals Distribution (%) - (2.4GHz at 20Hz Update Rate) Taxi Test

100

1st Flight

Signals Distribution (%)

90

2nd Flight 3rd Flight

80 70 60 50 40 30 20 10 0

-71

-79

-86

-93

-101

-108

-115

Taxi Test

96.5844

0.6489

0

0

0

0

0.0035

Signal Lost 2.7631

1st Flight

54.3841

38.3038

2.1347

0.3758

0

0.4645

0.0731

4.2641

2nd Flight

54.1862

36.7397

2.5871

2.0748

0

0.1507

0.0043

4.2572

3rd Flight

56.8031

32.3086

3.5631

2.0675

0

0.58

0.0083

4.6694

RSSI Signals (dBm)

Figure 10. RSSI Distribution for March 13th 2008 Flight Test The duration for each drop out event is also analyzed for the March 13th flight and the results are shown on Fig. 11. The data reveal that most drop outs did not last more than 0.5 second that even the pilot could not sense it. That explains why the pilot did not frequently report the loss of control in each flight. However, there are several drop outs that are greater then one second.

March 13th, 2008 Flight Test Signal Drop Out Statistics - (2.4GHz at 20Hz Update Rate)

Numbers of Drop Out Events

800

Taxi Test

700

1st Flight

600

2nd Flight 3rd Flight

500 400 300 200 100 0

ೇ 0.5

0.5~1.0

1.0~1.5

1.5~2.0

2.0~2.5

2.5~.3.0

Taxi Test

432

21

16

2

0

0

0

1st Flight

476

14

5

2

1

0

0

2nd Flight

732

7

6

0

1

0

0

3rd Flight

592

16

12

1

0

0

2

Duration of Drop Out Time (sec) Figure 11. Numbers of Drop Out Events and its Duration

7 American Institute of Aeronautics and Astronautics

> 3.0

B. Investigation of Previous Flight Test Data Up to this point the investigation shows that the drop out issue constantly occurred in each flight at the March 13th test. The question of whether the communication loss is a unique event of the March 13th flight or not drives the team to investigate the flight test data from all previous flights. The same analysis method is utilized and the results are summarized in Fig. 12. The results clearly reveal that the drop out was inevitable for each individual flight test and the pilot handling qualities suffered significantly due to this random drop out behavior. Based on all the flight test data analysis results, a summary can be given as follows: Signal drop out exists in every signal flight. About 3~5% of data was lost in each test. About 10% of data drop outs lasted longer than 0.5 seconds. During taxi tests, the average drop out times is about 2.0 seconds per minute. During flight tests, the average drop out times is about 2.8 seconds per minute.

Average Drop Out Time (sec/min)

Average Drop Out (sec/min) in Different Flight Tests Date (2.4GHz at 20Hz Update rate) 4 Mar-13-08

3.5

Feb-29-08

3

Dec-20-07

2.5

Aug-31-07

2

Jun-19-07

1.5 1 0.5 0

Taxi Test

Flight Test

Mar-13-08

1.68

2.66

Feb-29-08

2.88

2.82

Dec-20-07

1.72

3.19

Aug-31-07

1.10

Jun-19-07

4.34

Test Item Figure 12. Average Signal Lost in Different Flight Test Date

C. Laboratory Tests There are many factors that may affect the performance of the communication system in a RF environment. The engine, the ignition system, the line of sight, the RF signals from the outside environment, and other electrical systems onboard, all could contribute some at some level to poor communication performance. It is possible to isolate all these factors by conducting a test in a RF clean chamber to validate the functionality of the system. However, it may not be practical as this does not represent the true environment that the autopilot system is operated and surrounded. The intention of the lab test is to evaluate the drop out issue of the communication system when the aircraft is stable on the ground. The autopilot unit was installed on the Yak-54 in the same manner as it was in the flight test. The airplane was about 10 feet away from the ground station and sat on the floor inside a hangar. To reproduce the scenario of a flight test, all the ground station equipment, such as the ground station computers, the antenna, etc. were laid out identically to the flight test set up. The tests were done in 21 different configurations to evaluate the possible causes due to different set up. The test configurations are listed in Table 1 in details, and the test results are summarized in Fig. 13.

8 American Institute of Aeronautics and Astronautics

Table 1. Different Configurations for Laboratory Tests Operated Telemetry Autopilot Unit Tested Conditions Frequency Update Rate (S/N) 2.4GHz 20 Hz 1027 Manual mode 2.4GHz 20 Hz 1024 Manual mode 2.4GHz 1 Hz 1027 Manual mode 2.4GHz 1 Hz 1024 Manual mode 2.4GHz 20 Hz 1027 Autopilot mode On 2.4GHz 20 Hz 1024 Autopilot mode On 2.4GHz 1 Hz 1027 Autopilot mode On 2.4GHz 1 Hz 1024 Autopilot mode On 2.4GHz 20 Hz 1027 Radio module switch b/s two units 2.4GHz 20 Hz 1024 Radio module switch b/w two units 2.4GHz 1 Hz 1027 Radio module switch b/w two units 2.4GHz 1 Hz 1024 Radio module switch b/w two units 2.4GHz 20 Hz 1027 No networking b/w two GS laptops 2.4GHz 20 Hz 1024 No networking b/w two GS laptops 2.4GHz 20 Hz 1027 No servo power connected 2.4GHz 20 Hz 1024 No servo power connected 2.4GHz 20 Hz 1027 Bench power to autopilot unit 2.4GHz 20 Hz 1024 Bench power to autopilot unit 2.4GHz 20 Hz 1027 Wall power to ground station unit 900 MHz 20 1027 Manual mode 900 MHz 1 Hz 1027 Manual mode

Test Item

Average Drop Out Time (sec/min)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

Average Signal Drop Out (sec/min) Comparison in Different Lab Tests Setup

3

1027 20Hz 1024 20Hz 1027 1HZ 1024 1HZ

2.5 2 1.5 1 0.5 0 Manual Mode

Manual Mode Radio Switch

Autopilot Mode

No Networking

No Servo Power

Bench Power to Autopilot

1027 20Hz

2.38

1.93

0.02

2.35

2.66

1.85

1024 20Hz

2.31

2.57

0.02

2.21

2.19

2.14

1027 1HZ

0

0

0

1024 1HZ

0

0

0

Wall Power to 900 MHz Ground Transmission Station 2.64

2.36 0.06

Test Items Figure 13. Average Signal Lost in Different Lab Tests Setup

An executive summary can be given according to the lab test results: The drop outs did not occur when the telemetry update rate was set at 1 Hz. A very low signal lost rate was observed when the system was operated at autopilot mode. Except the above two cases, the systems constantly suffered signal loss. The signal drop out is unpredictable and random. The average signal lost time is about 2 to 2.5 seconds per minute of received data. The drop outs problems DO NOT relate to: 1) range, 2) power setup, 3) networking setup, 4) autopilot unit, 5) radio module, 6) transmission frequency. 9 American Institute of Aeronautics and Astronautics

When operated at a 1 Hz update rate, the amount of data required to transmit are reduced significantly. In that case, more buffers are available in the transmission stream that allows data to be transmitted smoothly with a higher success rate. Therefore, the probability of signal drop outs occurring are minimized. That is also true in the case of autopilot mode because less data are required to send during autopilot mode operation. For instance, the avionics is no longer listening to the pilot command signal during the autopilot mode. This also implies that the communication module used in this autopilot system is overloaded when operated in manual mode at a 20 Hz update rate. D. Pilot Communications Loss During the manual mode lab test No.3, as shown in Table 1, it was observed that an autopilot mode was triggered by the system. Figure 14 presents the data that reveals this issue. It is ensured that the autopilot mode was not activated by person accidentally. This event indicates that the pilot command signal transmitted through the uplink was lost at least for 0.2 seconds, triggering the autopilot mode due to the pilot time out setting, as described in Section II.B.

Lab Test Results - S/N: 1027; 1 Hz Update Rate; Manual Mode RSSI (dBm)

-70 -80 -90 -100 -110 -120 554

556

558

560

562

564

566

562

564

566

Time (sec)

G t (sec)

4 3 2 1 0 554

556

558

560

Time (sec) Figure 14. Autopilot ON due to Pilot Comm Out in Lab Test No. 3 Note that the downlink signal remained connected at the highest signal strength while the pilot command signal was dropped. It is a crucial discovery because it reveals that the uplink performance cannot be detected or monitored either by the RSSI signal or time step analysis method. The flight test engineer has no means to monitor the system and prevent losses from happening. This pilot communication problems can only be seen from the unintended autopilot mode event in data processing. Due to the concerns aroused by this issue, all the lab tests and previous flight tests data were once again inspected to look for the pilot time out event. The findings are summarized in Table 2. It clearly shows that the uplink signals were dropped frequently which in flight causes the pilot handling qualities to suffer significantly.

Table 2. Pilot Time Out Events Jun/Aug-07 Dec-20-07 Feb-29-08 Flight Tests Flight Tests Flight Tests Numbers of Autopilot ON due to Pilot Comm Out

0

20

8

10 American Institute of Aeronautics and Astronautics

Mar-13-08 Flight Tests

Lab Tests

14

2

V. Conclusion According to the investigation results, it is concluded that the cause of the March 13th flight incident was due to the pilot communication timeout which triggered the autopilot mode right before touch down. The system attempted to reach the last autopilot command, a 70 knot airspeed command, that drove the Yak-54 to pitch down with full throttle. As a result, the aircraft plunged into the runway. The pilot communication timeout event is caused by the pilot command signal drop outs in the uplink and is not related to range, pilot or ground crew error, system configurations issues, power setup, or ground station setup. This pilot communication timeout problem is unpredictable and can only be discovered by pilot report so no appropriate approach can be applied to prevent unintended autopilot activation. In addition, random communication loss problems were observed among all of the flight test data. From the lab tests results, it shows that the drop outs issue could be mitigated when operated at either 1Hz telemetry update rate or autopilot mode. However, the uplink performance is not necessarily improved when operating at 1 Hz update rate. Due to the inevitable communication problem inherits to the COTS autopilot system, it is concluded that the system cannot satisfy the Meridian safety requirements. Therefore, it is decided that this COTS autopilot system is no longer acceptable for the Meridian UAS program.

Acknowledgments This research is made possible by the support from the Center or Remote Sensing of Ice Sheets (CReSIS) program funded by the NSF Grant number AST-042-4589.

References 1

“Center for Remote Sensing of Ice Sheets,” http://www.cresis.ku.edu/. 2 W.R. Donovan and R.D. Hale, “The Design of an Uninhabited Air Vehicle for Use in Polar Research Utilizing and Efficient and Effective Multi-Disciplinary Design Process,” The University of Kansas. 3 “Microhard Systems Inc.,” http://www.microhardcorp.com/. 4 “The Math Works” http://www.mathworks.com/.

11 American Institute of Aeronautics and Astronautics