MOBILITY ENGINEERING Produced by SAE Media Group
MOBILITY ENGINEERING
Magazines
Magazine cover

Current Issue

Archives

Magazine cover

Current Issue

Archives

Magazine cover

Current Issue

Archives

Magazine cover

Current Issue

Archives

Two-Processor Autopilot System for a UAV

The two-processor architecture offers advantages over the prior one-processor architecture.

A two-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 single-processor 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 field-programmable 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 combat-support 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 mission-processor 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 mission-processor 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 www.defensetechbriefs.com  under the Information Sciences category. ARL-0004

Topics:
Aircraft Architecture Automatic pilots Avionics Buses Computer software and hardware Control systems Flight control systems Information Technology Sensors and actuators Unmanned aerial vehicles Vehicles
This Brief includes a Technical Support Package (TSP).
Document cover
Two-Processor Autopilot System for a UAV

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

Don't have an account?

More From SAE Media Group

    Magazine cover
    Defense Tech Briefs Magazine

    This article first appeared in the February, 2007 issue of Defense Tech Briefs Magazine (Vol. 1 No. 1).

    Read more articles from the archives here.

    Overview

    The document is a final report prepared by Virginia Commonwealth University for the Army Research Laboratory, detailing the development of an operational Flight Control System (FCS) for small Unmanned Aerial Vehicles (UAVs). The project, under Research Agreement No. W911NF-05-1-0324, was completed by July 5, 2006, and focuses on creating an advanced autopilot system tailored for UAV applications.

    The report outlines the tasks undertaken during the project, including the creation of a requirements document that specifies the needs for each component of the autopilot system. A significant aspect of the project involved surveying available off-the-shelf CPU systems to identify suitable candidates for the mission processor board. Key factors in this selection process included processing power, form factor, development environment, operating system, availability, and cost. The outcome of this task was the selection, purchase, and setup of the mission processor board, which was essential for implementing the complete autopilot system.

    Additionally, the report discusses the development of comprehensive documentation for the autopilot system, which includes a user’s guide, a reference guide detailing the hardware and software implementation, and a guide for demonstration algorithms. This documentation is intended to assist users in understanding how to operate the autopilot system, program it, and integrate additional hardware components.

    The report also notes that the initial funding and timeline allowed for the completion of only the first two tasks, which focused on the development of the FCS and the Ground Control Station (GCS). The FCS is elaborated upon in a separate final report, while the GCS report provides insights into the software's startup and configuration for flight operations. It is assumed that users are already familiar with operating remote-controlled aircraft, so detailed instructions on that aspect are not included.

    Overall, the document serves as a comprehensive overview of the project’s objectives, methodologies, and outcomes, emphasizing the importance of developing a robust autopilot system to meet the growing demands of UAV technology in various applications, including military and civilian uses.

    Top Stories

    INSIDERDefense

    Feature Image F-35 Proves Nuke Drop Performance in Stockpile Flight Testing

    INSIDERMaterials

    Feature Image Using Ultrabright X-Rays to Test Materials for Ultrafast Aircraft

    INSIDERManufacturing & Prototyping

    Feature Image Stevens Researchers Test Morkovin's Hypothesis for Major Hypersonic Flight...

    INSIDERManufacturing & Prototyping

    Feature Image New 3D-Printable Nanocomposite Prevents Overheating in Military Electronics

    INSIDERRF & Microwave Electronics

    Feature Image L3Harris Starts Low Rate Production Of New F-16 Viper Shield

    INSIDERRF & Microwave Electronics

    Feature Image F-22 Pilot Controls Drone With Tablet

    Webcasts