Human Factors Implications of 

Unmanned Aircraft Accidents: 

Flight-Control Problems

Kevin W. Williams

Civil Aerospace Medical Institute

Federal Aviation Administration

Oklahoma City, OK 73125

April 2006

Final Report

DOT/FAA/AM-06/8

Office of Aerospace Medicine

Washington, DC 20591
NOTICE

This document is disseminated under the sponsorship 

of the U.S. Department of Transportation in the interest 

of information exchange. The United States Government 

assumes no liability for the contents thereof.

___________

This publication and all Office of Aerospace Medicine 

technical reports are available in full-text from the Civil 

Aerospace Medical Institute’s publications Web site: 

www.faa.gov/library/reports/medical/oamtechreports/index.cfm
Technical Report Documentation Page 

1. Report No. 2. Government Accession No. 3. Recipient's Catalog No. 

DOT/FAA/AM-06/8 

4. Title and Subtitle 5. Report Date 

Human Factors Implications of Unmanned Aircraft Accidents: Flight- April 2006 

Control Problems 6. Performing Organization Code 

 

7. Author(s) 8. Performing Organization Report No. 

Williams KW 

9. Performing Organization Name and Address 10. Work Unit No. (TRAIS) 

FAA Civil Aerospace Medical Institute 

P.O. Box 25082 11. Contract or Grant No. 

Oklahoma City, OK 73125 

12. Sponsoring Agency name and Address 13. Type of Report and Period Covered 

Office of Aerospace Medicine 

Federal Aviation Administration 

800 Independence Ave., S.W. 

Washington, DC 20591 14. Sponsoring Agency Code 

15. Supplemental Notes 

Work was accomplished under approved task AHRR521 

16. Abstract 

This research focuses on three types of flight control problems associated with unmanned aircraft systems. The 

three flight control problems are: 1) external pilot difficulties with inconsistent mapping of the controls to the 

movement of the aircraft; 2) difficulties associated with the transfer of control from one control location to 

another during the flight; and 3) problems associated the automation of flight control. Specific accidents 

associated with each type of control problem are given as examples. The accidents involve several different 

aircraft systems that are currently in use. Solutions for each type of control problem are offered. 

 

17. Key Words 18. Distribution Statement 

 

 

Unmanned Aircraft Systems, UAV, Flight Controls, 

Accidents, Human Factors 

Document is available to the public through the 

Defense Technical Information Center, Ft. Belvior, VA 

22060; and the National Technical Information 

Service, Springfield, VA 22161 

19. Security Classif. (of this report) 20. Security Classif. (of this page) 21. No. of Pages 22. Price 

Unclassified Unclassified 9 

Form DOT F 1700.7 (8-72) Reproduction of completed page authorized 

Human Factors Implications of Unmanned Aircraft Accidents: 

Flight-Control Problems

Introduction

Unmanned aircraft (UA) have suffered a disproportionately large number of mishaps relative to manned 

aircraft (Williams, 2004). In 1996, the Air Force Scientific 

Advisory Board (AFSAB) identified the human/system 

interface as the greatest deficiency in current UA designs 

(Worch et al., 1996). A recent review of accident statistics 

for military UA lends support to this statement. However, 

the particular interface deficiencies responsible for most 

accidents differed across the various systems (Williams, 

2004).

In reviewing accident data for UA, two approaches 

can be used. The first is to focus on a particular aircraft 

system, noting the deficiencies in the interface design 

for that system that led to individual accidents. The 

second is to look at accidents across systems, focusing 

on categories of mishaps that occur across a variety of 

systems. The first approach can result in specific design 

changes for a particular system. The second can reveal 

basic human factors issues that apply across a variety of 

systems. In this chapter, we will use the second approach 

and look at UA accidents across a variety of systems and 

focus on categories of accidents involving flight control. 

The success or failure of UA will at least in part be determined by how easily they can be flown. Once the pilot 

has been separated from the aircraft, designers are faced 

with the basic problem of how to control the aircraft 

during the flight.

Three flight-control categories have been selected for 

review. The first category involves the use of an external 

pilot (EP) to control the flight of the aircraft. Basically, 

an EP is a pilot that controls the aircraft using direct 

line-of-sight, similarly to radio-control aircraft hobbyists. 

Flight using an EP represents the most basic solution 

to the problem of separating the pilot from the aircraft 

while still enabling the pilot to monitor the location and 

attitude of the aircraft. Pilot perspective is changed from 

an egocentric to an exocentric point of view. The problems 

that this change creates will be discussed later.

The second category concerns the transfer of control 

during flight. While transfer of control can occur within 

a manned cockpit, it does not entail the difficulty or variety of methods encountered with UA systems. Transfer 

of control can occur in a number of different ways, as 

will be discussed below. In addition, the protocol for 

transferring control from one pilot to another can differ 

radically from system to system. Almost every current 

system has encountered mishaps associated with transfer 

of control. We will review these problems and look at 

potential solutions for them.

The third flight-control category is the automation 

of flight control. Perhaps because the pilot has been removed from the aircraft, there seems to be an unspoken 

goal of UA designers to remove the pilot altogether from 

the system. This involves automating all of the flight 

control responsibilities. One of the latest military UA, 

the Global Hawk, is totally automated from initial taxi 

and takeoff to landing. However, the implementation of 

automation has not prevented the occurrence of mishaps 

attributed specifically to the automation. It will be useful to review some of these mishaps for ideas on how to 

improve these systems.
Rather than just a statistical summary of accident data 

related to UA, which can be found elsewhere (Manning, 

Rash, LeDuc, Nobak, & McKeon, 2004; Williams, 

2004), this chapter will include reviews of a number of 

specific accidents related to the categories listed above. 

The intent is to suggest possible interventions to prevent 

such accidents from occurring. 

External Piloting

The most basic solution for monitoring the position 

and attitude of an UA is through direct line-of-sight. A 

pilot that maintains direct line-of-sight with the aircraft 

is usually referred to as the external pilot (EP), as opposed to an internal pilot (IP) that obtains position and 

attitude information electronically. Maintaining visual 

contact with the UA, the EP can control the aircraft 

using a hand-held radio-control box. Many of these control boxes are similar to those used by radio-controlled 

aircraft hobbyists and provide direct control of the flight 

surfaces of the aircraft through the use of joysticks on the 

box (see Figure 1). Very little automation is involved in 

the use of such boxes, which control the flight surfaces 

of the aircraft.

For those systems that require an EP, statistics show that 

controlling the UA during landing is a difficult problem 

(Gawron, 1998; Williams, 2004). For example, with the 

Hunter system flown by the U.S. Army, 47% of the human-factors-related accidents occurred while landing the 

aircraft. An additional 20% of the accidents involved an 

error by the EP during takeoff (Williams, 2004). Likewise 

the Pioneer, which also uses an EP, experiences a proportionately large number of accidents during landing. A 

recent analysis of accident data for the Pioneer revealed 

that the largest percentage of human factors accidents 

(68%) was associated with difficulties experienced by the 

EP while landing the aircraft (Williams, 2004).

Probably the main reason for EP control difficulties is 

that there is an inconsistent mapping between the movement of the joystick and the response of the aircraft. The 

failure of a flight control to perform consistently (from 

the perspective of the pilot) is a violation of the human 

factors principle of motion compatibility (McCarley 

& Wickens, 2005; Wickens & Hollands, 2000). For 

example, when the aircraft is approaching the EP, the 

control inputs to maneuver the aircraft left and right are 

opposite what they would be when the aircraft is moving 

away from the EP. This inconsistent mapping problem is 

present for any UA operated using a traditional control 

box via visual contact.

Many current systems have eliminated the need for an 

external pilot either by automating the takeoff and landing process or by providing adequate visual, positional, 

and attitudinal information and control to the internal 

pilot to accomplish these tasks. Another solution is to 

make improvements to the control interface for the 

external pilot. Quigley, Goodrich, and Beard (2004) 

designed and tested a variety of control interfaces for 

improving the performance of the external pilot. These 

interfaces included a direct manipulation interface that 

presents a fixed-horizon, wing-view representation from 

the viewpoint of an observer behind the aircraft, a voicecontrolled interface, and a physical-icon interface that 

is basically a hand-held model of the aircraft that, when 

manipulated, sends control signals to the aircraft that 

mimic the attitude of the model.

Each of the interfaces provided some benefit to the EP, 

but each also had drawbacks. The physical icon interface 

had the fastest response time but did not resolve the issue of inconsistent mapping. The direct manipulation 

interface provided consistent mapping of the controls 

but required frequent visual accommodation adjustments 

between the interface and the aircraft. Finally, the voice 

interface resolved the mapping issue, as long as the commands were world-centered (e.g., “go north”), but was 

not as reliable or responsive as the other interfaces.

Transfer of Control

One of the activities unique to remotely piloted aircraft 

is the transfer of control from one controlling system to 

another. Transfer of control is usually required in UA at 

some point during the flight because of the limited range 

of the control station and/or stationary pilot. This transfer 

can occur in one of several ways. Control can be transferred from an external pilot to an internal pilot, from an 

internal pilot in one ground control station to a pilot in 

a second ground control station, and from one side of a 

ground control station to a set of duplicate controls within 

the same station. In addition, transfer of control during a 

Figure 1: Radio flight-control box. 


flight can occur from one pilot to another, analogous to 

a crew change in a manned aircraft. However, even this 

control transfer is different in a remotely piloted aircraft 

because the replacement crew does not have to have been 

present in the control area during the flight. 

The difficulty in the transfer of control is demonstrated 

by the fact that problems with control transfer occur in 

almost every UA system. It will be informative to review 

various mishaps involving the transfer of control in different systems to see if there are any constants across 

these mishaps.

Two mishaps involving the Army’s Hunter system 

were related to the transfer of control of the aircraft (U.S. 

Army, 2004). In the first mishap, a maintenance crewman 

turned off the autopilot capability of the aircraft during 

routine maintenance of the aircraft but inadvertently failed 

to restore the autopilot functionality prior to returning 

the aircraft to flight status. The aircraft took off under 

the control of the EP who did not use the autopilot and 

was thus unaware that it was nonfunctional. The mishap 

occurred after control of the aircraft was handed off from 

the EP to the IP. The IP is usually given control of the 

aircraft with the autopilot functioning since the primary 

means of control by the IP is through the use of knobs 

and dials for setting the aircraft heading, airspeed, and 

altitude. Because the IP was not expecting a nonfunctional autopilot, he failed to notice that the aircraft was 

descending and was unable to recover the aircraft before 

it crashed.

In the second Hunter mishap, control of the aircraft 

was being transferred from one EP to another during 

training. The EP receiving control neglected to complete 

all control box checks and failed to notice that one of 

the switches on the box was in the wrong position (Williams, 2004).

In the case of a U.S. Army Shadow system, two aircraft were damaged during a single mission. The first 

was damaged due to a failure of the automated landing 

system. After the accident, the ground control station 

(GCS) crew issued a command to the damaged aircraft 

to kill its engine, but because of damage to the antenna 

the command was not received. That same GCS was then 

tasked with controlling a second Shadow on an approach. 

Unfortunately, after taking control of the second Shadow, 

the aircraft received the “engine kill” command that 

was still waiting for an acknowledgment from the GCS 

software, causing the second Shadow to also crash. This 

accident was classified as both a procedural error (because 

the crew failed to follow all checklist items prior to the 

transfer of control of the second aircraft) and a display 

design problem (because there was not a clear indication 

to the crew of the status of the “engine kill” command 

that had been issued; Williams, 2004).

A more recent crash was that of a Helios UA in June 

2003. The Helios (Figure 2) is intended to fly for extended lengths of time at very high altitudes. During a 

flight test of the Helios in June 2003, the aircraft flew 

into turbulence that exceeded the maximum capability of 

Figure 2: Helios UA. 
the aircraft, and it broke apart. According to the accident 

report, at least one contributing factor to the accident 

was the high workload associated with the control handoff procedure. “Approximately 10 minutes prior to the 

event, the pilot was progressively becoming task-saturated 

with multiple demands on his attention. This included 

concurrent concerns with the flight hand-off procedure” 

(Noll et al., 2004, p. 84).

Yet another instance of a problem with the control 

handoff occurred during the test of an Altair UA in 

July 2004. The Altair is a derivative of the Predator B 

unmanned aircraft. The control station for the Altair 

normally consists of two pilot stations side by side, which 

allows control of the aircraft to be transferred from one 

side to the other during flight. During a flight test, the 

left pilot console malfunctioned. The crew proceeded 

to switch control to the right seat pilot console. The 

switchover took time to accomplish and during that 

period the aircraft went into its lost-link mode. Uplink 

was re-established, but as the right seat pilot console came 

online, the engine shut down. Accounts of the event from 

observers suggested that the cause of the shutdown was 

a fuel control switch that was not in the correct position 

on the right seat console. Fortunately, the pilot used his 

checklist to perform an engine restart and managed to 

successfully restart the engine and return to the original 

altitude (Randy Sundberg, personal communication). 

A common theme across most of these reported mishaps 

is a lack of awareness of system settings on the part of the 

receiving crew. Sometimes this is because checklists are not 

properly followed. Other times the displays did not adequately present system status information to the pilot. 

Automation

As UA continue to proliferate, the technology involved 

with the flight-control system continues to become 

more and more sophisticated. The ultimate solution 

seen by many to the problem of flight control of UA is 

to automate the control. One reason for the tendency 

to automate is the difficulties experienced by pilots in 

controlling the aircraft. External pilots have the problems 

of limited range and inconsistent control mapping, as 

was discussed earlier. Internal pilots have the problems 

of delayed control feedback, poor visual imagery, a small 

field of view, and a general lack of sensory cues (McCarley & Wickens, 2005). The degree of automation varies 

a great deal from system to system, with some systems 

having the capability to be “hand-flown”(e.g., Predator) 

while other systems have flight control totally automated 

from takeoff to landing (e.g., Global Hawk). 

Accidents involving flight-control automation suggest 

that it is difficult to anticipate all possible contingencies 

that can occur during a flight and that even if the automation functions as intended, unintended consequences 

can occur because of events that are not anticipated. A 

few examples of unintended consequences will illustrate 

this point.

The first accident involves the crash of a Navy-owned 

Vertical Take-off and Landing Tactical Unmanned Aerial 

Vehicle (VTUAV), called the Fire Scout (see Figure 3).

The investigation of the accident, which occurred on 

November 4, 2000, revealed that human error associated with damage to onboard antennas during ground 

handling led to the accident. Because of the damage to 

the antennas, an incorrect signal was emitted, causing the 

Figure 3. The U.S. Navy Fire Scout (RQ-8A). 
radar altimeter system to incorrectly track the altitude. 

The antennas gave a false reading that indicated that the 

Fire Scout was at an altitude of two ft above the ground 

when, in fact, it was hovering at an altitude of 500 ft 

(Strikenet, 2001). After the “land” command was given, 

the aircraft descended two ft to 498 ft AGL. The guidance 

and control system interpreted the incorrect altitude signal 

as an indication that the Fire Scout had already landed 

and, performing as designed, shut down the engine. The 

aircraft quickly lost altitude and crashed.

 A mishap of a Global Hawk occurred when the 

aircraft suffered an inflight problem with temperature 

regulation of the avionics compartment and landed at 

a preprogrammed alternate airport for servicing. After 

landing, the aircraft was commanded to begin taxiing. 

Unknown to the crew, a taxi speed of 155 knots had 

been entered into the mission plan at that particular 

waypoint by the automated mission planning software in 

use at the time. The mission planning software had been 

programmed to set the descent speed of the Global Hawk 

to 155 knots. Any time that two consecutive waypoints 

varied in altitude by more than a specified amount, the 

software set the speed to be established between those 

waypoints at 155 knots. What was not anticipated by 

the software developers however was two consecutive 

taxi waypoints on the ground differing by more than 

the specified amount in altitude. The software, performing as designed, had inserted an airspeed of 155 knots 

between the waypoints. The aircraft accelerated to the 

point where it was unable to negotiate a turn and ran 

off of the runway, collapsing the nose gear and causing 

extensive damage to the aircraft. 

The final example is in regard to the previously 

mentioned mishap involving the Helios system. After 

it entered turbulent conditions, the Helios pilot was 

unable to provide adequate control inputs to avoid the 

breakup of the aircraft. According to the mishap report, 

“The pilot’s control panel was designed to provide only 

standard “autopilot type” mode and navigation inputs; it 

was not designed to provide for direct pilot-in-the-loop 

control of attitude nor was it designed to provide the pilot 

[with the] capability to recognize an impending departure 

from controlled flight or to stabilize the aircraft” (Noll 

et al., 2004, p.81).

In all of these examples, we see evidence that the 

developers of the automation were unable to predict all 

possible contingencies. This led to situations in which 

the automation performed as designed but not as anticipated.

Summary and Conclusions

In this chapter we have seen examples of three types 

of UA accident categories. All three categories focus 

around a type of control problem. External pilot control 

problems are related to the inconsistent mapping of the 

control box to the movement of the aircraft. At least 

two solutions present themselves. The first solution is 

to design the control box in such a way as to achieve a 

consistent mapping. Quigley et al. (2004) looked at the 

use of several options for controlling the aircraft, but all 

had drawbacks. A second solution is to eliminate the 

need for an external pilot by automating those portions 

of flight that currently require an external pilot or by 

moving the flight control to an internal pilot. Such a 

solution has been accomplished with several current UA 

systems. But the use of an internal pilot is affected by 

factors such as a limited field-of- view, delayed control 

response and feedback, and a lack of sensory cues. In 

addition, the implementation of automation presents its 

own problems. Thus, it cannot be expected to provide 

a perfect solution. 

The problem of transfer of control centers around the 

fact that the receiver of control is not always fully aware 

of the status of the system. The problem can be solved 

by designing the displays in such a way that all critical 

system parameters are available to the pilot during the 

transfer. Most research on display design has focused on 

the task of navigation (e.g., Henry, 2001). Additional 

research is needed to determine the types of information 

required during the transfer of control and useful ways 

to depict that information.

Another method for reducing problems related to 

transfer of control is a yoked interface between control 

stations performing a handoff. Basically, the idea consists 

of establishing a protocol between two control stations (or 

within stations if the goal is to transfer control from one 

side to the other) that ensures that all system parameters 

of the receiving station match those of the sending station. Transfer of the data could be accomplished either 

through the aircraft data link or directly between the 

stations as technology permitted.

Automation problems occur because not all circumstances can be predicted. The inability to anticipate all 

possible contingencies leads to situations in which the 

system behaves as it was designed but not in a manner 

that was expected. There are at least two solutions to this 

problem. The first is to design the system in a way that 

keeps the pilot more aware of what the aircraft is going to 

do during the flight. This requirement, of course, assumes 

that the pilot will also have the ability to intercede in the 
automated task that is being performed. In implementing 

this solution, we have to deal with what is usually called 

the “out-of-the-loop” syndrome (Endsley & Kiris, 1995; 

Moray, 1986; Wickens & Hollands, 2000). The out-ofthe-loop syndrome refers to the finding that humans 

working with automation have a diminished ability to 

detect system errors and respond to them by performing 

the task manually.

The second solution to the automation problem is to 

design the automation to be more flexible so that, even 

when a particular contingency has not been anticipated, 

the system is still able to generate an appropriate response. 

This is a challenge for those developing “intelligent” 

systems, and this field is still in its infancy.

One conclusion that can be derived from the mishaps 

presented in this chapter is that flight control of UA is 

problematic. Understanding the specific issues discussed 

here should help reduce those accidents. However, as 

the interfaces of these aircraft continue to evolve, other 

issues will appear. Much work remains to improve the 

user interface for UA. New displays, control-interface 

concepts, and improved automation systems remain to 

be developed.

References

Endsley, M.R. & Kiris, E.O. (1995). The out-of-theloop performance problem and level of control in 

automation. Human Factors, 37(2), 381-94.

Gawron, V.J. (1998). Human factors issues in the development, evaluation, and operation of uninhabited 

aerial vehicles. AUVSI ’98: Proceedings of the Association for Unmanned Vehicle Systems International, 

Huntsville, AL, 431-8.

Henry, M. (2001). GUI techniques for assessing autonomous 

vehicle behavior. Air Force Research Laboratory/

HECI Technical Report #CSC-01-333-F.

Manning, S.D., Rash, C.E., LeDuc, P.A, Noback, R.K., 

& McKeon, J. (2004). The role of human causal 

factors in U.S. Army unmanned aerial vehicle accidents. U.S. Army Aeromedical Research Laboratory 

Report # 2004-11.

McCarley, J.S. & Wickens, C.D. (2005). Human factors implications of UAVs in the national airspace. 

University of Illinois Institute of Aviation Technical 

Report (AHFD-05-5/FAA-05-1). Savoy, IL: Aviation Human Factors Division. 

Moray, N. (1986). Monitoring behavior and supervisory 

control. In K. Boff (Ed.), Handbook of perception 

and human performance (pp. 40/1-51). New York: 

Wiley.

Noll, T.E., Brown, J.M., Perez-Davis, M.E., Ishmael, 

S.D., Tiffany, G.C., & Gaier, M. (2004). Investigation of the Helios prototype aircraft mishap: Volume 

I, mishap report. Downloaded on 9/2004 from URL 

www.nasa.gov/pdf/64317main_helios.pdf. 

Quigley, M., Goodrich, M.A., & Beard, R.W. (2004). 

Semi-autonomous human-UAV interfaces for fixedwing mini-UAVs. Proceedings of IROS 2004, Sep 

28 – Oct 2, Sendai, Japan.

Strikenet (2001). VTUAV P1 accident investigation 

board report. Downloaded on 4/15/2004 from 

URL www.strikenet.js.mil/pao/vtuav_crash_invest_news_release.html.

U.S. Army (2004). Risk Management Information System Web site. Downloaded on 9/2004 from URL 

https://safety.army.mil/home.html.

Wickens, C.D., & Hollands, J.G. (2000). Engineering 

psychology and human performance (3rd ed.). Atlantic 

City, NJ: Prentice Hall.

Williams, K.W. (2004). A summary of unmanned aircraft 

accident/incident data: Human factors implications.

Washington, DC: U.S. Department of Transportation, Federal Aviation Administration, Office of 

Aerospace Medicine. Technical Report Publication 

No. DOT/FAA/AM-04/24. 

Worch, P.R., Borky, J., Gabriel, R., Heiser, W., Swalm, T., 

& Wong, T. (1996). United States Air Force Scientific Advisory Board Report on UAV technologies and 

combat operations. SAB-TR-96-01, Washington, 

DC: Government Printing Office.