Multiple UAVs Autonomous Mission Implementation ...

2 downloads 0 Views 1MB Size Report
to the receive pin (RX) on the GumStix and vice versa by using a molex cable, serial interface can be established between the two hardware. Fig. 7 illustrates the ...
Multiple UAVs Autonomous Mission Implementation on COTS Autopilots and Experimental Results Norman H. M. Li∗, Hugh H. T. Liu†, Ernest J. P. Earon‡, Cameron D. Fulford§, Rajibul Huq¶and Camille A. Rabbathk

In this paper, an autonomous, multi-agent mission controller is developed on GumStix computer to control commercial off-the-shelf autopilots for multiple Unmanned Aerial Vehicles (UAVs) to complete coordinated flights. The design, which uses a distributed control approach without the need for a base station, can be easily expanded to different classes of aircraft and experiments. Using the GumStix for high level mission control allows engineers to rely on the autopilot’s capabilities to perform low level tasks while the mission programmer concentrates on high level decision making to complete given missions. The wireless vehicle-to-vehicle communication enabled through the GumStix computers onboard the vehicles in ad-hoc network mode allows coordinated and cooperative missions of multiple agents to be executed efficiently. The system is verified experimentally through actual coordinated flight experiments using two flying wing UAVs with the Procerus Kestrel autopilot. Finally, the system is integrated with the Quanser Cooperative Control Framework (QCCF) to allow high-level mission programming through MATLAB Simulink blocksets. ∗

N. Li is with The Institute for Aerospace Studies, University of Toronto, 4925 Dufferin Street, Toronto, Canada M3H 5T6 [email protected] † H. Liu is with The Institute for Aerospace Studies, University of Toronto, 4925 Dufferin Street, Toronto, Ontario, Canada M3H 5T6 [email protected] ‡ E. Earon is with Quanser Consulting Inc., 119 Spy Court, Markham, Ontario, Canada L3R 5H6

[email protected] §

C. Fulford is with Quanser Consulting Inc., 119 Spy Court, Markham, Ontario, Canada L3R 5H6

[email protected]

R. Huq is with Quanser Consulting Inc., 119 Spy Court, Markham, Ontario, Canada L3R 5H6

[email protected] k

C.

A.

Rabbath

is

with

Defence

[email protected] 1 of 20

Research

and

Development

Canada

I.

Introduction

Unmanned Aerial Vehicles (UAVs) have seen rapid development in a wide variety of areas,1 from surveillance2 to search and rescue missions3 to geographic studies4–6 and military and security applications.7–10 As more and more commercial off-the-shelf (COTS) UAV systems and autopilots for different types of aircraft become available, the complexity of coordinated flights for multiple UAVs increases and the ability to quickly deploy and execute missions with these vehicles (see Fig. 1) becomes important.11

Figure 1. An autonomous aircraft with COTS autopilot prepares to land after completing a mission (Courtesy of E. Earon)

The commercial autopilots in the market currently have certain common features and capabilities. Most important of all, they provide stabilization control for the UAVs based on sensor inputs with their internal controllers. Most of the autopilots and their corresponding software also provide navigation functions such as waypoint and loiter. However, there is a lack of high level decision making onboard for mission control.11 A typical solution to the mission control problem is to develop a centralised controller on a ground station to handle the high level decisions for the vehicles. Through wireless communication with the aircraft, the ground station receives vehicle information and generates commands necessary for the vehicle to complete the mission based on the current status of 2 of 20

the vehicle. However, this limits the travel range of the agents to the limit of the wireless connectivity, and there is the potential for communication loss and overhead time in sending information back and forth between the vehicle and ground station. The focus of the system described in this paper is to address this challenge by integrating the mission control onboard the vehicle to interface with the autopilot directly, thus creating a distributed control architecture. In this paper, we present an autonomous and high level mission controller implemented in a multi-threaded architecture on a GumStix computer12 for controlling UAVs’ onboard autopilots to rapidly execute predefined missions, utilizing existing capabilities of the UAVs as long as the interfaces to the autopilot are defined. The additional hardware integrated onboard the vehicle allows native communication between the GumStix and the autopilot, eliminating possible overhead and loss in communication that are present when the mission control resides on a ground station. The optional wireless capability also enables vehicle-to-vehicle communication for coordinated flights of agents. Actual flight test results demonstrate the effectiveness of the developed flight control architecture. The remainder of this paper is organized as follows. In Section II, detailed information on the GumStix hardware is provided and the interface used to allow GumStix to communicate with the autopilot is discussed. The software architecture and high level implementation of the autonomous mission controller is described in Section III. Flight test results of actual UAVs are given in Section IV. Section V describes the integration of the mission control system with Quanser Cooperative Control Framework (QCCF). Finally, Section VI offers conclusions and future research possibilities.

II.

Hardware

This section describes the additional onboard hardware needed to implement the control system as well as the hardware interface to the existing vehicle autopilot. In this paper, the Procerus Kestrel autopilot is used, but the design is similiarly applicable to other vehicle/autopilot platforms.11 A.

GumStix Embedded Computer

The GumStix computer used in this paper to develop the mission controller is a small form factor miniature computer. It is integrated on each UAV for controlling the onboard autopilot.

3 of 20

The GumStix used in this study consists the verdex XL6P motherboard that provides a Marvell XScale PXA270 processor running at 600MHz with 128MB of SDRAM. The GumStix embedded computer runs a full Linux environment with C/C++ library and a 802.11(b)/802.11(g) wireless expansion board (netwifimicroSD-vx) can be connected to the verdex motherboard through the 120 pin connector to enable wireless capabilities. The wireless board is included to enable communication with optional ground control station if necessary, and also to allow the possibility of incorporating additional vehicles for coordinated flights and missions when wireless vehicle-to-vehicle communication is required. The code for the mission controller and drivers for sending commands to the autopilot is written in C++ on the GumStix. Fig. 2 shows the additional hardware to be added on the vehicle: the GumStix verdex motherboard and the wireless expansion board.

(a) GumStix verdex motherboard

(b) Wireless expansion board

Figure 2. GumStix hardware to control UAV autopilot

There are several advantages in using the GumStix as the high level control. The GumStix board has a small form factor that has minimal effect to the dynamics of the vehicle when it is integrated onboard. Also, the high level mission controller is implemented on the GumStix and since the GumStix can interface with the autopilot directly, information from the autopilot and commands from the controller can be passed back and forth natively through hardware. The implementation of the controller on the GumStix onboard the vehicle itself minimizes the overhead and delays that are present when the controller is implemented on a ground station, where vehicle information is required to be transmitted to ground station and the commands sent back to the vehicle in the same manner. Finally, the

4 of 20

wireless board connected to the GumStix on each vehicle allows communication between the agents directly if there are multiple aircraft involved. This reduces delays and noise by eliminating a central gateway for communication between the vehicles, such as a ground control station, and provides a more flexible communication structure. As an additional benefit, the GumStix is targettable by the QCCF, an existing multi-vehicle framework,11 and can later be integrated into the QCCF to allow mission programming from MATLAB Simulink. The system architecture of the GumStix hardware implementation for the mission controller on the vehicles is illustrated in Fig. 3. The complete vehicle system 1 is sufficient for the single vehicle case and the connection to additional vehicles for coordinated missions is also shown in the diagram.

Complete vehicle system 1

Complete vehicle system i…n

UAV 1

UAV i

COTS Autopilot

COTS Autopilot

Wired serial communication GumStix with Wifi Mission Controller

Wireless communication

Wireless communication (if required )

Ground Control

Wired serial communication GumStix with Wifi Mission Controller

Wireless communication

(optional for real time vehicle monitor and data display ) Figure 3. System architecture of implementation with GumStix

5 of 20

B.

Procerus Kestrel Autopilot

In this paper, the autopilot used is the Kestrel system and the vehicle is a flying wing Zagi UAV, shown in Fig. 4 and Fig. 5 respectively. Both the autopilot and the vehicle are manufactured by Procerus Technologies.

Figure 4. Kestrel autopilot13

Figure 5. Procerus flying wings

The Kestrel autopilot allows an external onboard computer or microcontroller to be connected through a serial port.13 The autopilot will accept and reply to commands on the port. Fig. 6 shows the location of the programming serial port (Serial port A) on the 6 of 20

autopilot used to connect to the GumStix.

Modem Port 6-DOF IMU

GPS Port Programming Port (Serial A) External Servo Port (Serial E)

Airspeed Port

External Servo Ports

Altitude Port

Power Port

Analog Input Port

Figure 6. Location of progrmaming serial port on Kestrel13

On the other hand, the serial communication functionality on the GumStix can be enabled by connecting the 60 pin Hirose connector on the verdex motherboard to a breakout board that provides serial pinouts. Therefore, by connecting the transmit pin (TX) on the autopilot to the receive pin (RX) on the GumStix and vice versa by using a molex cable, serial interface can be established between the two hardware. Fig. 7 illustrates the physical connection between the Kestrel autopilot and the GumStix board, by the serial connection cable. With the serial connection, data can be sent between the GumStix and autopilot. The other requirement is to determine how the autopilot understands commands and what protocol is being used, which is the software interface to the autopilot. However, this information is often proprietary to the manufacturers of the autopilot system. Therefore, agreement must be reached in order to obtain and use the communication protocol. Usually, the autopilot communicates the flight commands and responses through the form of data packets. Specific start and end bytes indicate the structure of a packet and error checking such as checksum is performed to verify the data in the packet is intact upon receive. Therefore, a part of the development is dedicated to implementing driver functions to assemble and decode command specific packets according to the specifications of the communication protocol of the autopilot. Thus, the complexity and completeness of commands depend on what the autopilot offers. Using these driver functions, high level commands generated from the mission controller are interpreted and communicated to the vehicle autopilot, commanding the UAV to perform certain tasks based on high level decisions. The 7 of 20

Figure 7. Physical connection between Kestrel and GumStix

next section describes the software architecture and interface to the autopilot.

III.

Software Architecture

This section describes the general software architecture for our onboard distributed control system. A.

High Level Vehicle Commands

The advantage of using a COTS autopilot to control a vehicle is that the low level stabilization control of the vehicle is handled by the autopilot. Researchers can focus on the development of high level commands for vehicles to complete missions without extensive knowledge of the avionics of the aircraft. For the experiments in this paper, the following list contains some of the commands developed for controlling a flying wing UAV through a COTS autopilot. These commands are general and some may not be supported by all autopilots. Get Vehicle data This command requests telemetry data from the vehicle during flight and the data is then used by the mission controller to decide what the vehicle should do to complete the mission. 8 of 20

Takeoff to specified location Command takes latitude, longitude and altitude coordinates as inputs. Vehicle is then launched (hand launch in the case of the Zagi) and the autopilot will command the vehicle to reach the specified location. The command is completed when the vehicle is within 10 meters of the destination. Land at specificed location Similar to the takeoff command, a latitude and longitude location is specified. The vehicle is commanded to land at that location with altitude set to 0 meters. The command is completed when the vechile is within 1 meter of the calibrated ground. Waypoint This command will cause the autopilot to maneuver the vehicle to the specified latitude, longitude and altitude. The path planning is handled by the autopilot. Loiter With this command, the autopilot will loiter the vehicle at the given latitude, longitude and altitude location for a specified time. Similar to the waypoint command, the path planning is handled by the autopilot. Tracking vehicle states Vehicle states such as airspeed, altitude, pitch, roll and heading etc. can be tracked by the autopilot using this command. The states and their desired values are provided as the inputs. Home A latitude, longitude and altitude coordinate is given as input to set a Home position for the vehicle. This home position is mainly used in emergency handling, with mission controller onboard the vehicle periodically calculating its distance from home. When a maximum distance threshold is exceeded, the vehicle is commanded to head back to the home position and land.

B.

Vehicle-To-Vehicle Communication

To achieve coordinated flight with multiple vehicles, vehicle-to-vehicle communication is desirable to eliminate overhead from communicating through a ground station. This communication link is established by the additional GumStix hardware with wireless ethernet 9 of 20

capability onboard each vehicle through the TCP/IP protocol. However, a wireless access point has to be present when working under normal TCP/IP mode to act as a gateway for the communication. The disadvantage is all agents must be in the wireless range of the access point in order to successfully establish communication between the agents. Since the wireless range using ethernet is approximately in the order of 100 meters, then working with normal TCP/IP mode in missions involving multiple UAVs will not be feasible as the UAVs will have the possibility of traveling out of the wireless range of the access point. Furthermore, additional delays are present when data has to be transmitted through an access point to arrive at the destined vehicle. The solution to the problem is to enable the ad-hoc network mode for TCP/IP. In this network mode, there is no centralized access point required and each mobile agent itself can be considered as an individual access point with a fixed IP address. It is a self-configuring network and the agents in the network are free to move randomly and organize themselves arbitrarily. When multiple agents come within the wireless range of each other, a network will be automatically established between them. This network scheme is especially suitable for cooperative missions of multiple vehicles due to its capability of connecting agents automatically and dynamically when they are in range. Another advantage of the ad-hoc network is the data transmission does not need to go through any centralized gateway except the agents themselves, enabling direct communication between the vehicles and eliminating additional delays. This mode can be configured on the GumStix network protocol section, and with the advantages of the communication scheme, it is chosen to be the network setup for vehicle to vehicle communication. C.

Implementation of High Level Autonomous Mission Controller

This section describes the software architecture that defines the algorithm to execute UAV missions autonomously. Since the GumStix computer being integrated onto the vehicle has a Linux environment with full C/C++ library, the flight control is then developed in C++. The mission controller is implemented using a multi-threaded architecture. The essential parts of the controller are developed in three separate threads for them to execute simultaneously. The overall architecture of the implementation is shown in Fig. 8. The main thread executes the mission controller and performs high level decisions. It also initializes the serial and wireless communication threads. At the start of this main thread, the flight plan of the mission is uploaded into a linked list structure. This linked 10 of 20

Main thread

Serial Communication thread

Wireless Communication thread

Serial Communication thread starts

Wireless Communication thread starts

Main thread starts

Load flight plan

Is current command last command? No

Yes

Is current command last command?

Yes

Server vehicle waits for connection

Client vehicle tries to communicate with server

No

Save next command data in send buffer

Send telemetry requests to autopilot

Read vehicle state and data

Send command in send buffer

Is connection established ? No

No

Is current command completed ?

Yes

Receive telemetry responses from autopilot

Yes Wireless Communication thread ends

Decode responses and store vehicle data Serial Communication thread ends

Main thread ends

Figure 8. Multi threaded architecture of flight controller

11 of 20

list is parsed and the appropriate commands are then sent to the autopilot at certain times in order for the vehicle to complete the mission. The commands sent are stored in a buffer and it is up to the serial communication thread to actually send the commands through to the autopilot. The main thread also checks if a command has been completed, usually by observing the vehicle’s states and telemetry data, so that the next command can be invoked. The program executes until the last command in the flight plan is completed. All the flight data can be stored on a micro-SD storage device via the card slot on the GumStix. When the last command is completed, the main thread shuts down all the existing threads and exits. The serial communication thread concentrates on handling the communication with the onboard autopilot through the serial port on the GumStix. It periodically sends telemetry requests to the autopilot, obtains the responses and stores the vehicle data in structures. It also sends the commands stored by the main thread in the send buffer to the autopilot. This thread runs until the last command in the flight plan is completed. The wireless communication thread sets up wireless communication between vehicles if necessary. This is an optional thread. In the case of multiple UAVs, vehicles can be designated as servers or clients depending on the network setup of the aircraft. The server vehicles listen and wait for the communication request by the clients, while the client vehicles periodically try to establish a connection with the server(s). When communication is first established, the clients’ wireless communication thread exits since there will be no need for the vehicles to try to establish communication again as they are in ad-hoc network mode (where network will be configured automatically when vehicles are in range). The vehicles can then use the socket set up by this thread to communicate with each other. Since the vehicles are autonomous when the mission controller is executed and there is always the possibility of unexpected behaviors during flights, safety measures are implemented in the code to land the vehicle at a specified location when failures occur to avoid damage and even loss of vehicles. An example of the failsafe is the setup of a an emergency landing override when the vehicle travels beyond a predetermined distance from the home position. The home position is fixed based on the test site coordinates and the high level controller continually calculates the actual distance of the vehicles to the home position. When the position of the vehicle exceeds the maximum distance allowed from the home position, an emergency landing command is sent to the autopilot and all subsequent mission commands are ignored. The vehicle then returns and lands safely at the designated landing site.

12 of 20

IV.

Flight Tests

Flight tests involving cooperative missions are conducted with actual flying wing UAVs to verify the effectiveness of the developed control architecture. Prior to the tests, it is determined that the controller executes and communicates with the Kestrel autopilot at approximately 10Hz through timing analysis. This is an acceptable rate since most mission commands take longer than 0.1 seconds to complete and the update of information from the autopilot is also slower than 0.1 seconds (The onboard GPS unit updates information at 2Hz). Using the high level vehicle commands from section A, we develop two test missions to verify the control system architecture. It is essential to enable vehicle-to-vehicle communication in cooperative UAV control, thus the first mission conducted is the two vehicles communication test. In order to demonstrate multi-agent functionality, the following mission scenario is envisioned. TEST 1 - Two Vehicles Communication Test: One vehicle, U AV1 is launched and assumes a fixed loiter position to emulate the functionality of a persistent communications relay link, for example. U AV2 is then launched to perform a thorough search of an area. When U AV2 has completed its mission, it flies to U AV1 to announce the completion of the mission and to command U AV1 to land. The communication test is run with two Procerus flying wings. The purpose of the test is to observe the range and feasibility for multi agent missions of the Wi-Fi communication between the vehicles. The communication test scenario is executed as follows:

1. U AV1 is launched to loiter at (x0 , y0 , 80)m. This location is approximately 1km away from base station 2. U AV1 is waiting for communication request 3. U AV2 is launched 4. U AV2 travels in search pattern at an altitude of 60m and tries to establish communication with U AV1 5. The vehicles establish communication through Wi-Fi 6. U AV1 exits loiter and lands 13 of 20

7. U AV2 is commanded to land

Fig. 9 and Fig. 10 illustrate the result from the communication test. Fig. 9 shows the xy trajectories of the vehicles and Fig. 10 shows the U AV s’ distance from the home base station. From the plot, it can be seen that U AV1 is launched first and is sent to loiter at around 1km from the home position. U AV2 is launched after U AV1 to perform a search pattern and tries to establish communication with U AV1 . When the vehicles are around 300m from each other, seen in Fig. 10, communication is established and both aircraft are commanded to return and land. This test provides an approximate range for the Wi-Fi communication between the vehicles. As expected, the range is in the order of hundreds of meters for the TCP/IP ad-hoc network mode.

Communication experiment of UAVs

44.036 UAV1 UAV2

Latitude (degrees)

44.034

44.032

44.03

44.028

Vehicle−to−Vehicle communication established. UAV1 commanded to exit loiter and land. UAV2 commanded to land also.

UAV1 loiter location

44.026

44.024 −79.548 −79.546 −79.544 −79.542 −79.54 −79.538 −79.536 −79.534 −79.532 Longitude (degrees)

Figure 9. Communication experiment of multiple vehicles

The previous test demonstrates the feasibility of communication between the vehicles. Another coordinated flight test conducted is the two vehicles rendezvous test. Rendezvous missions are common in multi-agent control. Typically, the agents execute rendezvous to 14 of 20

Distance of UAVs from home position 1200 UAV1 UAV2

Communication established between UAVs. Both UAVs are commanded to land

UAV1 loitering

Distance from home (m)

1000

800 UAV1 launched 600

400

200

0 200

UAV2 launched 300

400

500 Time (s)

600

700

800

Figure 10. Vehicles’ distance from home

share information with each other and decide the actions to be taken next. TEST 2 - Two Vehicles Rendezvous Test: The rendezvous test is run with two Procerus flying wings. The purpose of the test is to have two vehicles arrive at a certain xy location at the same time cooperatively. The mission scenario is executed as follows:

1. U AV1 is launched to loiter at (x0 , y0 , 80)m 2. U AV2 is launched to loiter at (x0 , y0 , 60)m 3. The vehicles establish communication through Wi-Fi 4. The vehicles execute the rendezvous algorithm. Vehicle-to-vehicle communication is enabled in the algorithm to have U AV1 arrive at (x1 , y1 , 80)m and U AV2 arrive at (x1 , y1 , 60)m at the same time

15 of 20

5. Vehicles are commanded to land

Fig. 11 and Fig. 12 show the result from the rendezvous flight test. Fig. 11 illustrates the xy trajectories of the two vehicles when they are executing the rendezvous algorithm. The start and end times are given in the plot. It can be seen that the vehicles reach the rendezvous point at approximately the same time.

Rendezvous experiment of multiple UAVs 300 UAV2 start: 387.966752s (76.6930m, 255.8124m)

250 200

UAV1 start: 387.495166s (43.0146m, 220.4401m)

150

y (m)

100 50 0

UAV1 UAV2

UAV2 end: 445.98423s −50

(33.0600m, −181.4903m) UAV1 end: 445.502331s (40.3383m, −180.5837m)

−100 −150 −200

−200

−100

0

100

200

300

x (m)

Figure 11. Rendezvous experiment of multiple vehicles

In Fig. 12, it can be observed that once the rendezvous algorithm is executed, the vehicles attempt to eliminate the xy distance between them, so at the end when the destination point is reached, they will have achieved the rendezvous objective. The two tests detailed in this paper serve as verification that our distributed design works as expected and has the potential for developing more complex multi-agent missions. Multi-agent missions development is ongoing and the upcoming tests planned for the control platform include formation flights with flying wings14 and survey missions with fixed wings 16 of 20

x position of UAVs (m)

x position of UAVs during rendezvous 100

50

0

−50

UAV1 UAV2 0

10

20

30

40

50

60

50

60

y position of UAVs (m)

y position of UAVs during rendezvous 400

200

0

−200

0

10

20

30 Time (s)

40

Figure 12. XY position of UAVs during rendezvous

and rotary aircraft. The next section briefly describes how the architecture developed in the previous sections of this paper can be applied to a more extensible multi-agent framework.

V.

Integrating the system with the QCCF

The QCCF, outlined in,15 provides a robust, uniform, multi-agent control framework designed for use with embedded systems such as the GumStix. The QCCF is designed as an extensible framework that allows COTS autopilots to be integrated and utilized together from a uniform user interface. From the mission programmer’s perspective, the vehicles can be controlled through a set of high level Simulink blocks. Missions are developed on a PC using MATLAB Simulink and then compiled and downloaded seamlessly onto the target embedded GumStix, allowing the mission to execute remotely onboard the vehicle. The core interface between the high level blockset and the autopilot (vehicle hardware) is the Vehicle Abstraction Layer (VAL),15 as shown in Fig. 13. As seen in Fig. 13, the VAL primitives match closely with the high level commands listed

17 of 20

Figure 13. VAL interface between Simulink and vehicle drivers

in section A. Thus, it is simply a matter of wrapping the high level commands to conform to the VAL API to create a VAL driver. Now the missions are developed through MATLAB Simulink using the QCCF VAL blockset as outlined in.15 Since the framework developed in this paper is easily ported to the QCCF, the utility of the design is further validated.

VI.

Conclusions and Future Work

In conclusion, by implementing a mission controller on GumStix to execute high level decisions for commercial-off-the-shelf UAV autopilots, engineers can utilize existing autopilot capabilities to execute low level commands and focus on mission development. Furthermore, since mission control is executed onboard each vehicle, the distributed control network pro18 of 20

vides a flexible control architecture without the need for a common base station. Actual flight tests have proved the development to be a valuable tool for testing UAV missions effectively. This technique can be easily expanded to multiple and different classes of vehicles for coordinated missions as long as the interfaces to communicate with the autopilots are known. The software is easily integrated into an extensible multi-agent control framework, the QCCF, which further validates the design. Future work includes developing drivers for other classes of autopilots such as a rotorcraft. Additional flight tests can also be performed to ensure the coordinated missions involving multiple vehicles can be achieved with the implementation. At UTIAS, implementation on a set of flying wing UAVs with the Procerus Kestrel autopilot is underway where vehicle-to-vehicle wireless communication is required. The purpose is to verify a formation flight controller developed at UTIAS and study its effectiveness and feasibility in real flight scenarios.

References 1

Ryan, A., Zennaro, M., Howell, A., Sengupta, R., and Hedrick, J. K., “An overview of emerging results in cooperative UAV control,” IEEE Conference on Decision and Control , Vol. 1, Atlantis, Paradise Island, Bahamas, December 14-17 2004, pp. 602–607. 2

Lazarus, S., Shanmugavel, M., Tsourdos, A., Zbikowski, R., and White, B. A., “Airborne mapping of complex obstacles using 2D splinegon,” American Control Conference, Seattle, WA, June 11-13 2008, pp. 1238–1243. 3

Pratt, K., Murphy, R., and Stover, S., “Requirements for semi-autonomous flight in miniature UAVs for structure inspection,” AUVSI North America 2006 , Orlando, FL, 2006. 4

Davis, R. and Holmgren, P., “Remote sensing and forest monitoring in FRA2000 and beyond,” Forest resources assessment working paper - 008, Forestry Department, Food and Agriculture Organisation of the United Nations, Rome, 1999. 5

Tomppo, E., Czaplewski, R., and Makisara, K., “The role of remote sensing in global forest assessment,” Background paper for Kotka IV Expert Consultation, Kotka, Finland, July 2002. 6

Maslankik, J., “Polar remote sensing using an unpiloted aerial vehicle (UAV),” Seminar, ATOC7500, November 2002. 7

Klesh, A., Girard, A., and Kabamba, P. T., “Path planning for cooperative time-optimal information collection,” American Control Conference, Seattle, WA, June 11-13 2008, pp. 1991–1996. 8

Lechevin, N., Rabbath, C. A., Shanmugavel, M., and amd Brian A. White, A. T., “An integrated decision, control and fault detection scheme for cooperating unmanned aerial vehicle formations,” American Control Conference, Seattle, WA, June 11-13 2008, pp. 1997–2002. 9

Karaman, S. and Frazzoli, E., “Complex mission optimization for multiple-UAVs using linear temporal logic,” American Control Conference, Seattle, WA, June 11-13 2008, pp. 2003–2009.

19 of 20

10

Serchele, R., Cataldo, L., Smith, B., and Ostis, F., “Smart wide area munitions for UAVs,” AUVSI North America 2006 , Orlando, FL, 2006. 11

Earon, E. J. P., Li, N. H. M., Fulford, C. D., Huq, R., Apkarian, J., and Rabbath, C.-A., “Autonomous cooperative UAV control platform,” International Conference on Instrumentation, Control and Information Technology, Chofu, Japan, August 20-22 2008. 12

GumStix Inc., GumStix Computers, 2008.

13

Procerus Technologies, Kestrel Autopilot System User Guide, 1st ed., August 2007.

14

Li, N. H. M. and Liu, H. H. T., “Formation UAV flight control using virtual structure and motion synchronization,” American Control Conference, Seattle, WA, June 11-13 2008, pp. 1782–1787. 15

Fulford, C. D., Li, N. H. M., Earon, E. J. P., Huq, R., and Rabbath, C.-A., “The Vehicle Abstraction Layer: A simplified approach to multi-agent, autonomous UAV systems development,” System Simulation and Scientific Computing, ICSC 2008 , Beijing, China, October 10-12 2008.

20 of 20