Atwo-processor autopilot control system for an unmanned aerial vehicle (UAV) has been proposed and partly developed. Relative to prior such systems, this would be a lightweight, inexpensive autopilot system offering enhanced computational power and flexibility that would enable the use of the system in a variety of advanced UAVs. The two-processor architecture represents a significant departure from most prior single-processor UAV-autopilot architectures. Moreover, because this particular two-processor architecture is an open one, based on the use of commercial- off-the-shelf (COTS) processors and other COTS electronic subsystems, the system could easily be upgraded to take advantage of available state-of-the-art equipment.

The Two-Processor Autopilot System could readily be expanded, updated, and adapted to use in a variety of UAVs.

In addition to incorporating 8- or 16- bit microcontrollers and associated equipment that are becoming increasingly dated, most commercial UAV autopilot systems are based on a singleprocessor architecture. In such a system, the single processor must execute both the flight-control software and the mission application software. This engineering compromise necessary for using the single processor to perform both functions can significantly reduce the performance of the autopilot system below the levels desired for both functions.

In the proposed system, one processor, denoted the flight-control-system (FCS) processor, would execute the flight-control software; the other processor, denoted simply the mission processor, would execute the mission application software. Each processor would be optimized to perform its specific function. The two processors would communicate via a dedicated bus. A software application programming interface (API) would facilitate development or porting of flight-control and mission application software to the processors. In addition to being open, the architecture would be completely documented, facilitating addition of functionality to the system or porting the system completely to new processor architectures as they become available.

In the proposed system, each processor and its input/output subsystems would likely be mounted on its own board (see figure), which could be a COTS board. Typically, the software running in the FCS processor would implement proportional + integral + derivative (PID) control loops that would measure the roll, pitch, yaw, horizontal position, speed, and altitude of the aircraft along with the rates of change of these quantities, and would determine the required positions of the control surfaces of the aircraft to bring the aircraft to a desired state of heading, speed, position, and altitude.

Along with the FCS processor, the FCS board would hold the associated memory and input/output subsystem. Most likely, the FCS processor would be a microcontroller designed for use in realtime control systems. Also included on this board would be user-programmable custom hardware in the form of a fieldprogrammable gate array (FPGA), which would be used to implement custom interfaces to UAV sensors and to other UAV systems with which the FCS is required to communicate. These UAV systems would include (1) a COTS remote-control (RC) receiver of a type commonly used for remote manual control of UAVs and (2) COTS RC servos of a type commonly used to actuate the control surfaces of UAVs. For reasons that must be omitted for the sake of brevity, the use of custom interfaces between the FCS processor and the RC receiver and servos could enable the use of more channels of input/output control information, increase flexibility, and enable significant reductions in processing time and complexity of software.

The mission processor would, as its name indicates, execute the application software necessary to make the UAV complete its mission. This software could perform such functions as implementing complex search algorithms to find the shortest flight path to visit a specific set of waypoints for surveillance, developing the most efficient search pattern under given current wind and weather conditions, or implementing adaptive, artificial-intelligence control algorithms for autonomous, collaborative swarming of multiple UAVs in combatsupport operations.

The mission processor would be of a high-performance type capable of executing the complex algorithms inherent in the application software. As such, it would likely have a much higher clock speed and processing throughput and a larger memory system than does the FCS processor. The mission processor would run a full operating system (e.g., Linux or Windows CE) and would be equipped with a powerful and robust software development system based on the C or C++ computing language. The missionprocessor board would hold one or more high-speed universal asynchronous receiver/transmitters (UARTs) or an Ethernet (or equivalent) system that could be used to communicate, via a radio modem, with a ground control station (GCS). The GCS would be used to monitor the performance of the autopilot and the aircraft; however, the system would be capable of operating autonomously without communicating with the GCS. Finally, the missionprocessor board might also hold interfaces to mission-related sensors, which could include high-resolution video cameras. The data from these sensors might be processed on the mission processor board (e.g., to perform, image recognition for targeting), or might be compressed and/or stored onboard or transmitted directly to the GCS.

Between the FCS and mission processor boards there would be a data-transmission interface in the form of a bus. This could be a standard bus or a custom bus implemented by use of general-purpose digital input/output circuits in the two processors.

This work was done by Robert Klenke of Virginia Commonwealth University for the Army Research Laboratory. For further information, download the free white paper at under the Information Sciences category. ARL-0004

This Brief includes a Technical Support Package (TSP).
Two-Processor Autopilot System for a UAV

(reference ARL-0004) is currently available for download from the TSP library.

Don't have an account? Sign up here.

Defense Tech Briefs Magazine

This article first appeared in the February, 2007 issue of Defense Tech Briefs Magazine.

Read more articles from the archives here.