[american institute of aeronautics and astronautics aiaa infotech@aerospace 2007 conference and...

American Institute of Aeronautics and Astronautics

1

A Reconfigurable, Linux-based, Flight Control System for Small UAVs

Robert H. Klenke*, Jefferson McBride†, and Hoan Nguyen† Virginia Commonwealth University, Richmond, VA, 23284

This paper presents an autopilot system for small unmanned aerial vehicles (UAV) that is based on programmable logic devices and the standard Linux operating system. Its basis on programmable logic devices (Field Programmable Gate Arrays – FPGAs) allows custom hardware to perform dedicated functions to be easily added to the system. The use of the standard Linux operating system greatly eases the programming burden and promotes portability to new hardware platforms when they become available. The flexibility and power of the system is illustrated by its application to several different classes of UAVs and also an unmanned ground vehicle (UGV).

I. Introduction The potential uses for small UAVs are quite varied and ever expanding. These range from targeting and even

small weapons delivery in the military arena to sensing, surveying, and search, applications in the civilian arena. This class of UAVs typically has a gross weight of less than 100 lbs and their limited payload capacity, interior volume, and power supply, place significant constraints on on-board systems, including the autopilot system used to control them. On the other hand, the capabilities of the aircraft themselves continue to grow. This class of UAVs includes turbine powered aircraft capable of speeds approaching 300 knots, helicopters and other vertical takeoff vehicles that are dynamically unstable, and aircraft designed to be carried in unique locations on larger launch vehicles that have less than ideal aerodynamic characteristics. This in-turn imposes larger computational requirements on the flight control system portion of the autopilot – that portion of the autopilot system that actually controls the vehicle’s dynamic behavior. At the same time, the computational requirements of the mission software side of the autopilot system – that portion of the autopilot system that controls the vehicle’s actions in response to mission requirements - are also increasing. Mission requirements such as adaptive behaviors, swarming, and in-flight aircraft reconfiguration, all in concert with increasing requirements for vehicle autonomy, require large computational resources.

There are numerous autopilot systems that are available for small (<100 lbs) UAVs. However, if they are commercial systems, they typically use older technology processors and small memory systems, which limits their computational power. They also generally use proprietary software that is written without the benefit of a true operating system, which limits the ease with which they can be adapted to new applications or in some cases, even to different aircraft platforms. Most autopilot systems developed by universities or research labs share some of the same disadvantages. In addition, if they are obtainable at all, they are typically difficult to use or develop new software for, and most are targeted towards a specific research objective and thus lack the flexibility necessary to be utilized in different UAV applications.

This paper presents a UAV flight control system architecture developed specifically for small UAV’s. It uses powerful COT’s processors, a standard operating system, and includes programmable hardware resources in order to maximize its flexibility and the ease with which it can incorporate new hardware components, and be adapted to different autonomous platforms and applications.

* Associate Professor, Department of Electrical and Computer Engineering, School of Engineering, 601 West Main St. † Graduate Research Assistant, Department of Electrical and Computer Engineering, School of Engineering, 601 West Main St.

AIAA <i>Infotech@Aerospace</i> 2007 Conference and Exhibit7 - 10 May 2007, Rohnert Park, California

AIAA 2007-2957

Copyright © 2007 by the American Institute of Aeronautics and Astronautics, Inc. All rights reserved.


2

II. Background Commercial autopilots for UAV’s in this size class include the Micropilot [1], Piccolo [2], and Kestrel [3],

among others. The Micropilot 2128 autopilot uses a 150 MHz Coldfire RISC processor from Freescale Semiconductor. Although a programming environment that allows the addition of user-developed code to the autopilot is available, it is not based on an open operating system and the amount of processor memory is limited. The Piccolo II autopilot, from Cloudcap Technologies, utilizes a 40MHz processor from the Freescale Semiconductor MPC555 family. The Kestrel autopilot from Procerus Technologies uses a 29 MHz, 8-bit Rabbit processor. Neither of these systems are based on an open OS, and both provide only very limited on-board memory for developing additional autopilot capabilities.

In the research arena, there are a number of autopilot systems that have been developed for various applications. A significant number of them, such as the Aesalon UAV, developed by researchers at the University of Wisconsin – Madison [4], and the rotary-wing GTMax UAV developed by researchers at Georgia Tech [5], utilize PC-104-based processors. While a number of high performance processors with a significant amount of memory and utilizing the DOS or Linux operating system are available in the PC-104 form factor, these systems suffer from significant weight, power consumption, and heat dissipation issues that make them less than ideal for small UAV applications. In contrast, the FCS20 flight control system, also developed by the team at Georgia Tech [5], is small and light and offers a great deal of processing power with its 300 MHz Texas Instruments C6713 Digital Signal Processor. However, it too does not include a standard operating system or a significant amount of additional memory for user-developed applications.

III. Hardware The hardware for the on-board flight control system (FCS) portion of the system was selected to provide

maximum processing throughput and memory resources while at the same time providing maximum flexibility and ease of porting new software to it. These goals require that the system have several significant characteristics:

At a minimum, a state-of-the-art, 32-bit processor with a clock speed as high as possible, and if available, a built-in floating point unit,

a large amount of memory, both volatile and non-volatile, to hold the executable code for a large application and the large amount of data used in complex flight control and mission algorithms, and

a large amount of user-configurable I/O resources necessary to interface to a variety of sensors used in flight control systems and mission applications.

In addition, to further increase performance and ease the development of applications for this system, the following characteristics are necessary:

available user-customizable logic which can be used to implement complex logic and state machines that can off-load repetitive or long time scale operations from the processor thereby further increasing available processor resources,

a standard operating system that can provide basic system resource management and functions which can reduce application development time and increase the portability of applications, and

a robust, powerful, and readily available hardware and software development environment with standard hardware cores and software libraries to reduce application development effort and time.

After researching numerous processor boards to satisfy the above requirements, the decision was made to

develop the FCS on the Suzaku processor boards developed by Atmark Techno, Inc. The Suzaku is a complete single-board processor system based on the Xilinx Spartan-3 FPGA. The Spartan-3-based Suzaku board utilizes a 50 MHz, 32-bit processor called the Microblaze. The Microblaze is a soft-core processor. That is, the processor is not actually built in dedicated silicon on the device, but is implemented using standard FPGA logic resources just like user-defined custom logic. This approach makes the processor architecture more flexible in that the application designer can actually change it, but results in lower overall processor performance.

In addition to the Spartan-3 device upon which the Microblaze processor can be implemented, the Suzaku board contains 16 M Bytes of SDRAM and 8 M Bytes of Flash memory. The Spartan-3 device on the Suzaku comes pre-configured with Microblaze processor on it with a micro version of Linux called uCLinux. The GNU tool chain can also be used to develop applications for the Microblaze processor on the Suzaku.

In addition to the Microblaze-based Suzaku board described above, Atmark Techno has developed a more powerful version called the Suzaku V. The Suzaku V is based on the Xilinx Virtex-II Pro XC2VP4-FG256 field programmable gate array (FPGA). The Virtex-II FPGA contains a PowerPC 405 32bit RISC processor operating at 270MHz. In addition, being that it is an FPGA, the Virtex-II device contains user-customizable logic that can be


3

used to implement application-specific functions as in the Microblaze-based Suzaku. The logic can be interfaced to the processor via a built-in On-chip Peripheral Bus (OPB).

In addition to the Virtex-II device, the Suzaku V board contains 32 M Bytes of SDRAM and 8 M Bytes of Flash memory and a 10Base-T/100Base-T Ethernet interface. The PowerPC in the Virtex-II runs Version 2.4 of the Linux kernel. User-defined hardware can be developed for implementation in the FPGA portion of the Virtex-II using Xilinx’s ISE and EDK logic design tools. Like the Microblaze on the Suzaku, software development for the PowerPC is done using the GNU tool chain including a full cross-compiler. The Suzaku and Suzaku V processor boards are shown in Figure 1.

The architecture of the overall FCS is shown in Figure 2. The processor, its associated memory, and the Linux operating system is shown as a separate subsystem in the diagram. With the exception of device drivers needed to interface to peripherals, no modifications to the processor/memory/OS subsystem were made for this application. All of the custom hardware added for this application was interfaced to the processor via an external I/O bus, in the case of the Suzaku boards; this is an implementation of the OPB bus protocol.

Figure 1. The Suzaku and Suzaku V processor boards

Processor System

*Includes SDRAM and Flash memory required to execute Linux OS

UARTUART UARTUART UARTUART

SPIControllerSPIController

Maxstream900 MHz Radio Modem

Analog/DigitalConverter

Analog sensors:• Airspeed pressure sensor• Altitude pressure sensor• Battery voltage• IR attitude sensors• etc.

Link to GroundControl Station

72 MHz Safety/manualpilot link

Custom PWMRead Controller

Custom PWMWrite Controller

ElectrodynamicsUAV Safety

Switch

UAV Control Servos

4 Hz GPS SystemOptional IMU

•Crossbow AHRS400 •Microbotics MIDG II•Microstrain 3DM-GX1

I/O (OPB) Bus

1.0-2.0 ms

20 ms

Servo pulse train from RX to servos

Figure 2. Architecture of the Flight Control System


4

A total of three UART modules were needed for this application to provide RS-232 interfaces to the Ublox Antaris GPS receiver, 900 MHz radio modem to communicate with the ground control station (GCS), and the optional external Inertial Measurement Unit (IMU). Depending on the specific processor board, some of these UARTs were available within the processor itself. Additional UARTs were added to the system by implementing them in the FPGA as required.

In addition to the UARTs, an interface was required to the Analog to Digital Converters (ADCs) used to digitize the outputs of the analog sensors. These analog sensors included the pressure sensors for airspeed and altitude, the IR sensors, where applicable, and the measurement of the state of the onboard batteries. The ADCs are designed to interface to other devices via a Serial Peripheral Interface (SPI) bus. An SPI interface core was implemented in the FPGA resources to manage the SPI communications between the processor and the ADCs. This core allowed the processor to control and received data from the ADCs by performing simple I/O register read and write operations.

In addition to the sensors, the FCS needs to monitor the values of the input commands from the safety pilot. An external UAV switch handles the switching of control from the safety pilot to the FCS. This device, developed by Electrodynamics, Inc. (http://electrodynam.com) allows completely independent operation of the UAV by the safety pilot regardless of the state of the FCS. Switching of the inputs to the servos from the safety pilot receiver to the FCS is controlled by one of the channels from the safety pilot receiver. Thus, the safety pilot can turn over control of the UAV to the FCS and take it back at any time. The requirement for the capability to do this is in a system intended to test unproven hardware, software, and flight control algorithms is obvious.

Even with the UAV switch, however, the FCS still needs to read the inputs from the safety pilot receiver. The state of the channel which controls the safety pilot switch (i.e., the manual/autopilot mode switch) is used to tell the FCS when it should begin execution of the algorithms for control of the aircraft. The values on the channels which control the UAVs control surfaces, such as elevator, aileron, rudder, and throttle, are used by the FCS to determine neutral trim positions, and are telemetered to the ground control station by the FCS for debugging purposes.

The pulse train output by the safety pilot receiver, which normally goes directly to the servos, is shown in Figure 3 as well. This pulse train has a period of 20 ms and the individual pulses are 1.0 ms to 2.0 ms wide. The servo output position is proportional to the width of the individual pulses. Because the period, and even the width of the pulses, is very long with respect to the processor’s clock period, it is not efficient for the processor to be directly involved in reading the width of the individual pulses. Therefore, a custom core was developed using VHDL and the FPGA development tools, to read the incoming pulses from the safety pilot receiver. This core contains a 16-bit counter for each incoming channel. When the start of a control pulse is detected, this counter is started, and when the end of the pulse occurs, the counter is stopped. The input clock to the counter was setup with a period such that the difference between the resulting count for a 1.0 ms pulse and a 2.0 ms pulse resulted in 10 bits of resolution. Once the counter has stopped, the contents of the counter is placed in a register corresponding to the specific channel. To obtain the value of the current command pulse width for any incoming channel from the receiver, all the processor has to do is perform a simple I/O read from a specific I/O address.

In a similar manner, a custom core was developed to generate the required output pulses to operate the UAVs servos when the FCS is operating the aircraft. In this case, the processor performs a simple I/O write operation to the specific address for the servo in question. The core then uses this value to load a counter every 20 ms. This counter is then started and outputs a pulse that begins when the count begins and ends when the count reaches zero. The core repeats this process every 20 ms using the current values stored in each register. Therefore, the processor only needs to write a value out to a specific servo’s control location when it desires to change the value of the current pulse width (i.e., when it wants to move that servo).

In addition to the components described above, additional hardware resources can be added to the user-programmable logic inside the FPGA as required to assist the processor in performing the flight control function. Examples might include custom cores to operate additional types of actuators such as pneumatic or electromagnetic components used in different types of “morphing” aerodynamic structures, custom cores to generate pulse width modulated signals for AC motor control for electric aircraft, or interfaces to complex sensors that use some other communications protocol besides RS-232 or SPI. These cores can be designed and simulated using standard digital design techniques and added to the FPGA as long as additional resources are available within it.


5

A custom printed circuit board (PCB) has been designed and fabricated to integrate all of the components in the system as shown above. This PCB, dubbed the “T board,” provides physical connections and power for the Suzaku board, the 900 MHZ radio modem, and the Ublox GPS. The latter two boards are used in the system in an “OEM configuration,” i.e., they are used without their normal motherboard and enclosure that are required for stand-alone operation. The resulting system is approximately 5” long, 4” wide, and 2” high, and weighs 5 oz.. This configuration, consisting of the T board, the Suzaku, the radio modem, and the GPS module, is shown in Figure 4.

IV. Software There are two major software components in this UAV autopilot system. These are the actual control application

within the on-board FCS, and a Ground Control Station (GCS), which runs on a laptop computer. The two software components communicate over the 900 MHz modem link during system operation.

The FCS software is written in C and runs on the Linux operating system on either the Microblaze or PowerPC processors on the different Suzaku boards. The application consists of three communicating Linux “threads.” One thread monitors the UARTS connected to the GPS receiver, radio modem, and optional IMU unit. Whenever a UART receives a new message, this thread processes and stores the incoming information (e.g., aircraft attitude from the IMU, aircraft position from the GPS, etc.). The GPS system sends a new position information message every 250 ms. Depending on the IMU used, it may send a new attitude information message every 20 ms to 50 ms. The information in these messages are stored in global variables for use in controlling the aircraft’s flight. The GCS sends messages to the FCS as required to update waypoints, modify FCS gain parameters, etc. as required.

A second thread runs on an internally generated 50 ms timer and performs the control loop calculations to actually fly the aircraft. The control loops consist of the internal loops – aileron command from roll angle, elevator command from pitch angle, and throttle command from airspeed, and the outer, “navigation” loops – target roll angle from heading error and target pitch angle from altitude error. These control loops are implemented as Proportional, Integral, Derivative (PID) controllers and in there are “feed-forward” components such as elevator from roll angle to maintain altitude during turns, and throttle from roll angle to maintain airspeed during turns.

Finally, a third thread periodically transmits telemetry messages to the GCS. These messages contain information used to update the GCS display, plus additional performance information from the FCS that is logged for debugging purposes.

The GCS application is implemented using XML and Microsoft’s C# programming environment. XML (Extensible Markup Language) is used to specify the data formats and many of the actual data items for the GCS application. For example, the content and organization of the data packets that are sent between the GCS and FCS software are specified using an XML template. Doing so allows maximum flexibility in adapting the GCS to various

Figure 4. “T board” implementation of the FCS hardware.


6

FCS implementations; i.e., changing the communications packet contents involves a simple edit of the corresponding XML file, not a modification and re-compile of the GCS code. It also allows the GCS to support different FCS versions or FCS modifications for different vehicles, concurrently, using different XML templates.

In order to provide maximum flexibility, the GCS is implemented using a client/server model. The client applications provide the human-machine interface where the operator can monitor and control the UAV and the on-board mission sensors. Any number of clients may connect to the server via a wireless or wired LAN and are grouped into two major varieties: control and mission. Control clients can alter the mission, change the control mode of the UAVs, and view all incoming data (pictures, video feeds, etc.). Mission clients, on the other hand, are optimized for viewing the incoming data. Before it can send any control commands, a client must authorize itself by providing login information; mission data will be available to any client that connects to the server. Figure 5 shows two of the control clients implemented for the UAV application, the Navigation Display Client and the Flight Control Parameter Client

The server handles the actual communication with the UAVs and the synchronization of the clients. Radio

modems using an XML-specified, binary protocol connect the server to the UAVs. Through this link the server can upload flight paths and download status information such as the UAVs’ position, altitude, airspeed, etc. A video feed, used in typical surveillance applications, is downloaded through a separate RF link, but it is also captured by server and streamed to all of the clients. The server can also capture still images from the video stream whenever the plane flies over a target or a client requests a picture.

The server and clients use XML messaging to communicate over a star model LAN. When a control client changes a UAV or mission value (adds a target, changes a PID constant, changes control mode, etc.), the client sends a request message to the server. The server then sends the request onto the appropriate UAV and waits for confirmation. Once confirmation is received, the new status of the UAV is provided back to the client for updating the display. This client/server model provides three very important benefits. First, it allows the client and server to be run on separate computers that can be physically separated by large distances – with the resulting obvious advantages for remote operations. Second, the system can easily be enhanced to control multiple vehicles. The server functionality is independent of the number of vehicles being controlled and new clients can be added to the system as required to manage additional vehicles. Finally, separating the client and server functionality makes it much easier to develop vehicle- or mission-specific clients with dedicated features and capabilities specific to the individual application.

GCS Navigation Display

GCS Flight ControlParameter Display

Figure 5. GCS Control Client Displays


7

Figure 6 shows a typical architecture for the GCS with two fixed-wing aircraft configured with video cameras/transmitters for surveillance operations.

V. Vehicles The system is currently being used or adapted to control several different types of vehicles. This includes

propeller- and turbine-powered and fixed-wing aircraft, rotary-winged aircraft, and ground vehicles.

EthernetNetwork

USB to RS232 Adapter

Radio Modem

Computer running

GCS server

One or more computers

running GCS client software

Video Splitter

USB Video

Capture

MonitorVideo

processor

Video Splitter

Video Receiver

Figure 6. Typical two-UAV GCS configuration for surveillance operations.


8

The primary vehicle for testing the system has been the modified FQM-117B Radio Controlled Miniature Aerial Target (RCMAT). The FQM-117B is a foam aircraft built in the form of 1/9th-scale model of a MiG-27. Several modifications were incorporated into this series of aircraft, dubbed the “Mig,” to make them more suitable for this application. These modifications include strengthening the fuselage and wings for the greater weight load, installation of a larger engine, and installation of tricycle landing gear. In addition, a larger wing has been designed for this aircraft to increase its payload capacity. Figure 7 shows two examples of this aircraft with the stock wing.

To date, over 100 autonomous flights have completed with the Mig airframes. Most of those flights have been

made using the IR sensors for aircraft attitude estimation and control, but recently the Crossbow, Microbotics, and Microstrain IMU’s have been undergoing testing in these platforms with the FCS.

As a follow-on to the Mig aircraft, flight testing of the autopilot system in a turbine-powered UAV has begun. Turbine powered aircraft are of course, much faster than propeller-driven aircraft, and this presents some different challenges for the flight control system. Because the system navigates with reference to the aircraft’s position over the ground, the bank angles that the aircraft must make to capture the same set of waypoints as the propeller-driven aircraft are much higher – necessitating some different control laws in order to make these bank angles correctly. For example, it has been found that the turbine-powered UAV needs a “feed-forward” throttle from pitch angle, and throttle from bank angle, control law in order to maintain proper airspeed during high banked turns and climb and decent phases. Aerodynamic and power plant differences in jet aircraft such as the swept wings, much higher wing loading, and turbine spool-up time, also necessitate much different PID gain values from the propeller-driven Mig aircraft.

The autopilot system described herein has been installed in a turbine-powered UAV derived from a commercially available jet trainer called a DV8R. Although it is a “trainer,” DV8R has a wing loading that is approximately twice that of the Migs and having a top speed of over 140 kts and a cruising speed of 70 kts it is also almost twice as fast. Tuning of the PID parameters and implementation of additional controls laws for the DV8R is currently taking place and thus far, over 10 successful autonomous flights have been completed. The DV8R aircraft is shown in Figure 8.

Body Material: Foam Wingspan: 66” stock, 85” expanded Fuselage Length: 68” Engines: 1.2 ci 4 stroke glow and 20 cc gas Fuel: 15% Nitro Glow Fuel or Gasoline Max Speed: 70 kts – level flight

Figure 7. Modified FQM-117B UAV with stock wing


9

In addition to the fixed-wing aircraft, the autopilot system described in this paper is being integrated into a rotary-winged UAV. This UAV, shown in Figure 9, is an electric-powered Fury Ion sport helicopter manufactured by Miniature Aircraft USA, Inc. The Ion is powered by a brushless electric motor and two 8000 MAh Lithium-Polymer batteries. This combination gives the Ion an endurance of approximately 15 minutes in hover and slightly more in forward flight. The rotor span of the Ion is 1.6 meters and the aircraft, with the FCS installed, weighs approximately 14 lbs.

As with the turbine-powered aircraft, there are some unique handling characteristics of the rotary-winged aircraft that require modifications to the FCS application to support. For example, rotary-winged aircraft are inherently unstable and thus the control laws are much different and actually may have to be run at a faster update rate than for a fixed-wing aircraft. In addition, while a fixed-wing aircraft flys at a limited side-slip angle on its own (i.e., it generally goes where its’ pointed), a helicopter can fly in any direction, regardless of where it’s pointed. Thus, while an on-board heading reference system such as a magnetometer or IMU is an option on a fixed-wing aircraft, it’s a requirement on a helicopter UAV. Initial efforts on the Ion attempted to utilize a single axis magnetometer to provide heading reference and the IR sensors to provide pitch and roll information. However, for better control, a Microstrain IMU is currently being used on the Ion UAV to provide both heading, and pitch and roll attitude to the FCS.

Figure 8. DV8R turbine-powered UAV

Figure 9. Fury Ion Rotary-winged UAV


10

Finally, there has been much interest in the unmanned community towards exploiting the union of UAVs and

unmanned ground vehicles operating in concert. Towards that end, the autopilot system described herein has been adapted to provide a control system for an unmanned ground vehicle (UGV). The UGV under development uses simple GPS guidance for steering commands and includes a rudimentary obstacle detection and avoidance system based on IR and ultrasonic detectors. In the future, a vision-based driving system may be investigated. The UGV is still in the early development stage, but it shows the versatility not only in the FCS with the ease in which it was adapted to this application, but also to the GCS system in that the only modification required was the specification of new message formats in XML and the development of a modified control client to provide the proper operator interface. The UGV under development is shown in Figure 10.

VI. Conclusions and Future Work The authors have developed an FCS for small UAVs that incorporates a standard operating system, portable,

extensible programming paradigms, state-of-the-art embedded processors, and user programmable logic. This approach provides maximum processing power for current applications, portability to various airframes and vehicle types, and extensibility to new sensors and application-specific hardware.

Future work includes using the system to implement complex mission-specific algorithms such as are used in swarming behaviors, on the system, perfecting its use in rotary-winged and jet-turbine powered aircraft, and controlling several different vehicle classes simultaneously.

VII. References [1] Micropilot website, http://www.micropilot.com/

[2] Cloudcap Technology website, http://www.cloudcaptech.com/

[3] Procerus Technologies website, http://www.procerusuav.com/productsKestrelAutopilot.php

[4] R.J. Curtiss, J.R. Dix, A.J. Selvig. “Project Merlin: Development of the Aesalon Unmanned Aerial Vehicle,” Wisconsin Space Conference, Madison, Wisconsin, 2005.

[5] A. A. Proctor, B. Gwin, S.K. Kannan, A.A. Koller, H.B. Christophersen, and E.N. Johnson. “Ongoing Development of an Autonomous Aerial Reconnaissance System at Georgia Tech,” presented at the International Aerial Robotics Competition, Fort Benning, GA, 2003.

Figure 10. Unmanned Ground Vehicle Prototype

[american institute of aeronautics and astronautics aiaa infotech@aerospace 2007 conference and...

Documents