2017 International Conference on

Unmanned Aircraft Systems (ICUAS)

June 13-16, 2017, Miami, FL, USA

Heterogeneous Multi-Vehicle Modular Control

Framework With Payload Integration
Cameron T. Rogers, Charles Noren, John Valasek
Vehicle Systems & Control Laboratory
Aerospace Engineering Departemnt
Texas A&M Univeristy
College Station, Texas 77843-3141
Email: {crogers, charles noren, valasek}@[Link]

Abstract—Small unmanned aircraft are being used in an operator workload. HOTL control schemes only require human
increasing number of applications requiring cooperation between supervision or human authorization and function with a great
multiple heterogeneous vehicles. Multi-agent control algorithms deal of autonomy. For the purpose of this paper, HOTL control
can be implemented to control such systems but often require an
underlying communications framework with integrated payloads. schemes are of primary interest.
This paper presents a modular heterogeneous multi-agent control Many HOTL multi-agent control algorithms have been
framework with payload integration. This framework, named developed. All of these algorithms depend on their underlying
Clark, provides a wireless network between agents without rely- communications framework and several of them depend on
ing on pre-existing communications infrastructure and provides integration of sensors and other payloads. One such algo-
software interfaces for connecting to a variety of payloads. Under-
lying design requirements that highlight key features of the Clark rithm was developed for controlling many SUAS as if they
framework are presented, and an overview of the framework and were flocks of birds [9]. Olfati et al. found a peer-to-peer
software architecture is given in the context of fulfilling key design network of agents to be suitable for performing many 2-
requirements. The architecutre is demonstrated with a flight D and 3-D flocking maneuvers. Their proposed algorithms
test of three heterogeneous agents that includes communication were dependent on the peer-to-peer nature of the commu-
performance metrics.
nications framework. Another algorithm was developed for
detecting chemicals in the air with swarms of SUAS [10].
I. I NTRODUCTION
This application clearly depends on integration to chemical
Small unmanned aircraft systems (SUAS) have often been sensors and computational nodes for mapping the chemical
used in applications which are considered, dull, dirty, and cloud. Recently, an algorithm was proposed for real-time task
dangerous [1]. These traditional uses highlight the strengths scheduling for SUAS working in teams on joint goals [11].
of SUAS, such as remote operability and a high level of This algorithm requires computational resources that must be
autonomy. SUAS have also been found to be cost-effective [2] distributed across many SUAS and then communicate as a
and highly flexible platforms that are able to conduct a variety whole. It is important to note the coupling in these examples
of mission sets [3]. However, today there is a growing need between the algorithms, communications frameworks, and
for SUAS in a variety of non-traditional applications including payloads. Therefore, the overhead of developing underlying
parcel delivery, built infrastructure assessment [4], precision communications and payload systems for each controller must
agriculture [5], disaster response [6], search and rescue [7], be minimized in order to test multi-agent controllers more
and traffic monitoring [3]. To maintain a cost advantage, efficiently.
many of these applications will require systems that operate There are several existing system frameworks for the testing
multiple aircraft, cooperate with other vehicles, and minimize of multi-agent control algorithms, and one such system is the
the workload on human operators. For example, it was noted Massachusetts Institute of Technolgy’s Raven platform [12].
in Ref.[4] that the use of multiple vehicles could cut down This system is designed to test heterogeneous vehicle control
on the required time of missions and drastically decrease the algorithms but must be used indoors where agents can be
system requirements for any single vehicle. Likewise, many seen by Vicon MX cameras. Another framework is Stanford
other SUAS applications could better complete their objectives Testbed of Autonomous Rotorcraft for Multi-Agent Control
with the help of multi-agent controllers. (STARMAC) [13]. STARMAC is build upon the open source
Multi-agent controllers can be generally classified as ei- robotic operating system (ROS) [14] and in configurable
ther human-in-the-loop (HITL) or human-on-the-loop (HOTL) for centralized and decentralized controllers. It can be used
schemes [8]. HITL control schemes involve a high degree of outdoors and supports X4 Flyer quadrotor.
human interaction and are not conducive to minimizing human The Vehicle Systems & Control Laboratory (VSCL) at

978-1-5090-4494-8/17/$31.00 ©2017 IEEE 264

Texas A&M University developed a framework to support the • The wired network shall use MAVLink over serial as the
operation of multi-agent controllers and quickly test various protocol to connect to the autopilot
control designs. This requires a great deal of integration • The system mission abstraction layer shall provide easy
with a variety of payloads and modularity within the control access to messaging and commanding function for ease
architecture. Called Clark, it is a framework designed to of controller integration
provide underlying communication between autopilots, sensor The requirement for a mission computer was driven by the
payloads, and various radio transceivers on a number of agents. need to minimize external infrastructure such as computational
Several features make the Clark framework advantageous clusters. The addition of a mission computer also allows each
in its ability to support the testing of heterogeneous multi- agent to perform high level logic and decision making provid-
agent controllers. First, Clark allows for easy integration of ing a potential HOTL system. Based upon the requirement for
autopilots, sensor payloads, and various radios because of its a mission computer, the analysis of the requirement led to the
open architecture. Second, control algorithms can be easily requirement to use UNIX-based operating systems for ease of
changed because it provides an abstraction layer for inte- integration with payloads and radio transceivers. Simplified
grating various controllers into the underlying communication integration and reconfigurability of the control abstraction
framework. Finally, Clark is well-suited for outdoor use by layer were key to providing Clark with advantages, as opposed
maintaining all computational resources onboard the agents to using a system such as ROS where developments would be
and by eliminating the need for pre-existing communications necessary. The requirement to support wireless communica-
infrastructure. tions at a range of up to one mile was driven by the legal
This paper is outlined as follows: Section II highlights limitation that SUAS must be flown within line-of-sight of
the key design constraints used in developing the framework. the pilot. Although the intent of this framework is to test
Section III details the framework layout as well as the software HOTL controllers that could be operated beyond line-of-sight,
architecture. Section IV identifies the selected hardware for it is still necessary by law to operate vehicles within line-of-
the prototype system. Section V discusses the selected SUAS sight and use a pilot who can take control of the vehicle for
and mission control station used in testing. Section VII gives safety. The next three requirements extended from different
results from a three-agent test as well as performance charac- Derived Requirements but are driven by the same need, which
teristics of the system. Section VIII presents conclusions and is making the system capable of interchanging hardware.
section IX proposes extensions that can be made using Clark. These requirements begin to constrain what hardware can be
II. D ESIGN R EQUIREMENTS used, based upon the underlying communications protocol.
However, these requirements capture the sensors, payloads,
In line with the design methodology of systems
radios, and autopilots used by the VSCL and many other users
engineering[15], the Clark framework was designed through
on SUAS. The final requirement defines the purpose of this
the observance of specific system requirements. After identify-
work. It enforces that the framework provide an abstraction
ing a Need, a Concept of Operations (ConOps) was developed
layer for controller integration, thereby making it a modular
and subsequent Defined Requirements and Derived Require-
control architecture. The abstraction layer does not come with
ments. Through an iterative process the requirements were
a controller built in and hence it is a framework. In addition,
refined through analysis and comparison of the requirements
the peripheral components of the framework provide this
to the Needs Statement. In the end, Design Requirements
abstraction layer with all available data and an assortment of
were generated, which serve as the primary design points
functions for implementing multi-agent control.
of the Clark architecture. The design requirements are of
great importance because they determine how the framework
III. T HE C LARK F RAMEWORK AND S OFTWARE
will integrate many different payloads and support a modular
A RCHITECTURE
control architecture. The following list contains several of the
most important Design Requirements. A key attribute of Clark is the integration of a wireless
• The system shall be able to be implemented on different vehicle network and a payload network aboard each vehicle.
types of vehicles For the purposes of this paper, agents will be considered to be
• Each vehicular agent within the system shall have a any autonomous vehicle that can be commanded through an
mission computer onboard autopilot. Figure 1 depicts how the framework may connect
• Each mission computer shall operate a UNIX based vehicles. The wireless network is a mesh topology allowing
operating system the system to expand without network reconfiguration. Addi-
• The agent shall support wireless communications at a tionally, it provides several ”self-healing” properties provided
range of up to one mile by mesh networks. Figure 2 shows how the framework may
• The interface to the wireless transceiver shall be modular connect payloads to the mission computer. The protocol for
and therefore able to swap varying wireless hardware connecting these payloads can vary as described in the pre-
components vious section. The payload network must route all data back
• The interface to payloads shall support TCP/IP and serial to the mission computer if that data is to be used by another
connections agent because it is the access point to the wireless network.

265
 work assumes that the autopilots can function independently
of payloads. This assumption is supported by the fact that
many autonomous SUAS flight tests can be performed using
only an autopilot. Therefore, it should be noted that the entire
framework can continue to function independently of the pay-
loads. All the peripherals all modular, meaning that they only
need to supply a few functions to the Clark class in order to
function. With the Clark class and the communication interface
classes Clark is able to support implementation of multi-
agent controllers without having to build up communications
interfaces around it. These controllers will relay on the same
set of functions and data provided by Clark and could be
Fig. 1. Clark connects vehicles wirelessly in a mesh topology interchanged without further changes. This demonstrates the
modular design of the framework.
To account for the necessity of hardware changes, the
framework is built from a selection of interchangeable Python
modules. This is accomplished through use of application
program interfaces (APIs) which are maintained constant
across various interfaces. These interchangeable classes are
the radio interface class, the payload interface class, and
the autopilot interface class. A hypothetical example use of
this interchangeability could be as follows: initial tests are
completed with a payload requiring a serial connection, but
the original payload is later swapped for another payload
which requires a UDP/IP connection. In this example a new
Fig. 2. Clark connects payloads to a mission computer on each agent
radio interface class would need to be used in support of the
new protocol, but provides the same API. Then both payloads
would be completely interchangeable. This same modularity
The framework features a two-level modular architecture can be found with all of the peripheral classes, making the
written in the Python language (Python 2.7). Python 2.7 was Clark framework an open architecture.
selected due to several dependencies only being supported in
this version of Python. All software outlined in this paper is IV. H ARDWARE
executed by the mission computer on each agent. Figure 3 The framework is demonstrated by selecting hardware to
shows the two levels with peripheral software around it. At meet the requirements listed in Section II. The framework
the core of the framework is the Clark class. The Clark class is not limited to one specific hardware set because of the
modularity detailed previously. For the remainder of this paper
the hardware set will consist of: a mission computer, an
autopilot, a radio, and a computational payload.

A. Mission Computer
A Raspberry Pi 2 [16] is selected as the mission computer
because of the UNIX-based operating system (OS) support,
the large number of input/output pins and ports, high perfor-
mance processor, small footprint, light weight, and low power
consumption. The Raspberry Pi 2 is commercially available
for $35 and can be configured with a number of UNIX-
Fig. 3. The software consists of two levels and peripherals allowing for high based OS. It has a 900 MHz quad-core ARM Cortex A7 with
modularity four universal serial bus (USB) ports and 17 general purpose
input/output pins. The Raspberry Pi 2 weighs 45 grams with
is responsible for routing all data between the communication a 85.6 mm x 56.5 mm footprint, and requires less than 1 W
interface and the mission class. Additionally, all data handling of power.
is also done within this part of the software. The peripherals
to the Clark class are the communication interface classes. B. Autopilot
These allow Clark access to the wireless network, the payload The Pixhawk [17] is selected as the autopilot because
network, and the autopilot. The autopilot interface class is of its use of the micro air vehicle communication protocol
separated from the payload interface class because the frame- (MAVLink), its support of multiple vehicle platforms and

266
its commercial availability. An autopilot using the MAVLink
protocol is a requirement, as stated in Section II. It can be
configured with the APM firmware stack, which supports
aircraft (ArduPlane), rotorcraft (ArduCopter), and ground ve-
hicles (ArduRover). It is commercially available for $300.
The Pixhawk offers many flight modes in addition to safety
failsafes.
C. Radio
The XBee Pro 900HP [18] is selected as the radio
transceiver because it utilizes the DigiMesh protocol, has a
small footprint, low power consumption, and a range of up
to four miles with a relatively high bandwidth of 200 Kbps.
The DigiMesh protocol treats all connected radio modules as
routers, making for simple configuration and easy expansion
of the network. Messages can be sent to specific radios on the
network or broadcast throughout. The XBee has footprint of
22mm x 33mm and consumes less than 1W. The XBee Pro
900HP is commercially available for $39.
D. Payload
A Raspberry Pi 2 with a Raspberry Pi camera [19] is Fig. 4. The DJI F-450 was used in the Clark framework demonstration
selected as the payload. The camera is five mega pixel fixed-
focus sensor. It is capable of taking still images or video and
connects to the Raspberry Pi through a ribbon cable. It is
commercially available for approximately $25.
V. AGENTS
Three agents are selected for testing the framework: a DJI
F-450 rotorcraft [20], a Ready Made RC Anaconda [21], and
the Dell Laptop [22] mission control station (MCS). With three
agents, Clark can be proven to be a multi-agent framework.
A. Rotorcraft SUAS
The small DJI F-450 quadcopter is selected to highlight the Fig. 5. Ready Made RC Anaconda used in the Clark framework demonstration
small footprint and weight of the Clark system. The F-450
(see Figure 4) has a wheelbase of 450mm with a maximum
payload weight limit of 800 - 1200 g including the primary VI. T EST O BJECTIVES AND P ROCEDURES
flight batteries. Even with such payload constraints, the Clark
system can be utilized. The quadcopter can be configured with The purpose of the flight test was to verify the ability to
lithium polymer batteries to fly for up to fifteen minutes. The communicate data between three agents during flight: a DJI
F-450 was outfitted with the Raspberry Pi 2 mission computer, F450 rotorcraft, a Ready Made RC Anaconda, and the Dell
Pixhawk autopilot and XBee radio transceiver. Laptop as a MCS. The MCS is used to supervise during test-
ing. The information of interest is GPS coordinates, altitude,
B. Fixed-wing SUAS heading, velocity, and autopilot flight mode. This information
The Ready Made RC Anaconda (see Figure 5) is selected for is contained in two data packet: the agent status data packet
its larger payload capacity that is needed in order to carry two and the image capture packet. The agent status packets were
Raspberry Pis, and because the VSCL has conducted over 200 transmitted at one hertz and the image capture packets once
flights with this aircraft. The Ready Made RC Anaconda has every five seconds. Testing was conducted by initialing com-
a 2m wingspan and is 1.4m long. It can be custom configured munication between all agents and then manually operating all
with lithium polymer batteries to fly up to 45 minutes. vehicles on predetermined missions lasting five minutes. The
pilot flew the Anaconda in large oval circuits with varying
C. Mission Control Station altitude and radius while taking images every five seconds.
The Dell 14 Rugged laptop (see Figure 6) is selected solely For safety purposes the quadcopter was tethered to the ground
to supervise the Clark framework during the demonstration. about 20 meters from the MCS and was to hover at an altitude
Any computer with Python 2.7.13 could be used for this less than 30 meters. A five minute mission is selected to allow
purpose. a sample size of at least 300 GPS coordinates and 60 images

267
Fig. 6. The Dell laptop functioned as the mission control station (MCS) in
the Clark framework demonstration

to be collected. A longer mission time was not selected in

order to maintain a large margin of safety in the quadcopter’s
maximum flight time of 15 minutes. During the mission, each
agent records data transmitted by the other two agents. Table
I lists the hardware components which are installed on the
agents prior to testing. Fig. 7. Google Earth plots of the Anaconda (red) and F450 (blue) flight paths.
The cyan point marks the location of the MCS.
TABLE I
L IST OF HARDWARE USED FOR TESTING C LARK
dropped packet can be seen in the lower plot of Figure 7 where
Function Hardware Make Agent
and Model there are sharp turns in the Anaconda’s reported flight path.
This data loss tended to be at greater relative distances where
Autopilot 3DR Pixhawk F-450 & Anaconda
Mission Computer Raspberry Pi 2 F450 & Anaconda the radio signal may have been attenuated. Other factors such
Radio Digi XBee Pro 900HP All agents as vehicle orientation and antenna orientation may have also
Payload Raspberry Pi 2 with camera Anaconda contributed to the loss of signal.

TABLE II
VII. R ESULTS AGENT STATUS MESSAGE COMMUNICATION
Flight testing was conducted on 19 April 2017 at Texas MCS F450 Anaconda
A&M ’s RELLIS campus located at site 83TX. The Anaconda Total agent status
flew for approximately six minutes and 45 seconds, recording packets transmitted 0 49 417
83 images with the Raspberry Pi camera. The F450 flew for 45 Agent status packets
received from F450 49 (100%) N/A 49 (100%)
seconds and then due to high winds was landed prematurely. Agent status packets
Figure 7 shows the flight path of the F450 and a portion of received from Anaconda 369 (88%) 48 (96%) N/A
the Anaconda’s flight path as recorded by the MCS.

A. Communication of GPS Position B. Communication of Image GPS Position

GPS coordinates were communicated between all agents In addition to recording the GPS position of all other
using the agent status packets and recorded for review. Table agents, the Anaconda transmitted the GPS coordinates of
II shows the number of packets sent and received by both each location where images where taken by the Raspberry
vehicles and the MCS. 100% of data transmitted by the Pi camera. The picture specific data packets included not
quadrotor was received by both the MCS and Anaconda. This only the GPS coordinates, but also a time stamp of when
was expected due to the close proximity and low speed of the image was taken. Analysis of the flight logs shows that
the vehicles during the short duration of the quadrotor’s flight. a total of 83 images were taken during the flight. Onboard the
The Anaconda communicated 96% of the first 50 packets with Anaconda, the Raspberry Pi acting as the payload successfully
the F450 and 88% of all 417 packets sent to the MCS. The communicated each of those images with its own mission

268
computer. The mission computer in turn transmitted all of the was set to one hertz. This method of measuring is very useful
image packets to the other two agents. The F450 received to a control law designer because it captures the latency of
8 image capture packets before having to land. In that time packing and unpacking performed by the framework and not
span only 8 packets were sent, therefore 100% of the image just the hardware latency. A five minute test was conducted
data packets were successfully communicated to the F450. The with three agents. The average latency measured was 1.07
MCS received 73 image capture packets or 88% of the total seconds.
packets sent. Both the F450 and Anaconda recorded GPS co-
ordinates, altitude, and time of capture for each image. Figure VIII. C ONCLUSIONS
8 shows all of the locations and altitudes of image captures. Flight test results presented in the paper demonstrate that
The yellow markers indicate the image capture packets that the Clark framework is a modular system upon which multi-
were successfully transmitted while the red markers indicate agent controllers can be tested, with the capability to easily and
image capture packets that were dropped. The green marker effectively communicate between agents and payloads. The
indicates the location of the sample image seen in Figure 9. design of the control abstraction layer provides modularity in
The blue path is the flight path of the quadrotor and the cyan multi-agent control law implementation. Clark supports com-
marker is the location of the MCS. munication between multiple heterogeneous agents and some
payloads with a modular mission-level controller interface. To
enable more payloads to be integrated, more payload interfaces
can be developed. The framework proves to be independent
of external infrastructure with the exception of a mission
control station which is used for supervision and intervention.
Currently Clark can accept and support only TCP/IP, UDP/IP,
and serial connections.

IX. F UTURE W ORK

The suite of payload interfaces can be expanded to support
various types of payloads that can be integrated into the frame-
work. Future work will include testing of such controllers. One
area of interest is payload-directed multi-agent flight. Another
Fig. 8. Plot of image capture locations. Yellow markers indicate successful area of interest is multi-agent computational intelligence based
communication of image capture packet. Red markers indicate failed commu- controllers, such as those based on deep reinforcement learning
nication of image capture packet. The green marker indicates the location of or artificial neural networks.
image seen in Figure 9.

ACKNOWLEDGMENT
The authors would like to thank Zeke Bowden for serving
as the pilot for the referenced test flights.

R EFERENCES
[1] P. Van Blyenburgh, “Uavs: an overview,” Air & Space Europe, vol. 1,
no. 5, pp. 43–47, 1999.
[2] U. Ozdemir, Y. O. Aktas, A. Vuruskan, Y. Dereli, A. F. Tarhan,
K. Demirbag, A. Erdem, G. D. Kalaycioglu, I. Ozkol, and G. Inalhan,
“Design of a commercial hybrid vtol uav system,” Journal of Intelligent
& Robotic Systems, vol. 74, no. 1-2, pp. 371–393, 2014.
[3] K. Kanistras, G. Martins, M. J. Rutherford, and K. P. Valavanis, “Survey
of unmanned aerial vehicles (uavs) for traffic monitoring,” in Handbook
of Unmanned Aerial Vehicles. Springer, 2015, pp. 2643–2666.
[4] J. V. Henrickson, C. Rogers, H.-H. Lu, J. Valasek, and Y. Shi,
“Infrastructure assessment with small unmanned aircraft systems,” in
Unmanned Aircraft Systems (ICUAS), 2016 International Conference
on. IEEE, 2016, pp. 933–942.
[5] Y. Shi, J. A. Thomasson, S. C. Murray, N. A. Pugh, W. L. Rooney,
Fig. 9. Sample image taken during the flight test S. Shafian, N. Rajan, G. Rouze, C. L. Morgan, H. L. Neely et al., “Un-
manned aerial vehicles for high-throughput phenotyping and agronomic
research,” PloS one, vol. 11, no. 7, p. e0159781, 2016.
[6] R. Murphy, J. Dufek, T. Sarmiento, G. Wilde, X. Xiao, J. Braun,
C. Communication Time Delay L. Mullen, R. Smith, S. Allred, J. Adams et al., “Two case studies
Additional ground testing was conducted to quantify the and gaps analysis of flood assessment for emergency management with
small unmanned aerial systems,” in Safety, Security, and Rescue Robotics
communication latency. The measured latency included the (SSRR), 2016 IEEE International Symposium on. IEEE, 2016, pp. 54–
sampling period of the control abstraction layer itself, which 61.

269
 [7] A. N. Chaves, P. S. Cugnasca, and J. Jose, “Adaptive search control
applied to search and rescue operations using unmanned aerial vehicles
(uavs),” IEEE Latin America Transactions, vol. 12, no. 7, pp. 1278–
1283, 2014.
[8] S. Nahavandi, “Trusted autonomy between humans and robots: Toward
human-on-the-loop in robotics and autonomous systems,” IEEE Systems,
Man, and Cybernetics Magazine, vol. 3, no. 1, pp. 10–17, 2017.
[9] R. Olfati-Saber, “Flocking for multi-agent dynamic systems: Algorithms
and theory,” IEEE Transactions on automatic control, vol. 51, no. 3, pp.
401–420, 2006.
[10] M. A. Kovacina, D. Palmer, G. Yang, and R. Vaidyanathan, “Multi-
agent control algorithms for chemical cloud detection and mapping
using unmanned air vehicles,” in Intelligent Robots and Systems, 2002.
IEEE/RSJ International Conference on, vol. 3. IEEE, 2002, pp. 2782–
2788.
[11] D. Budaev, K. Amelin, G. Voschuk, P. Skobelev, and N. Amelina, “Real-
time task scheduling for multi-agent control system of uav’s group based
on network-centric technology,” in Control, Decision and Information
Technologies (CoDIT), 2016 International Conference on. IEEE, 2016,
pp. 378–381.
[12] J. How, “Raven: Testbed for autonomous uavs,” 2007. [On-
line]. Available: [Link]
no4/[Link]/
[13] G. Hoffmann, D. G. Rajnarayan, S. L. Waslander, D. Dostal, J. S. Jang,
and C. J. Tomlin, “The stanford testbed of autonomous rotorcraft for
multi agent control (starmac),” in Digital Avionics Systems Conference,
2004. DASC 04. The 23rd, vol. 2. IEEE, 2004, pp. 12–E.
[14] O. S. R. Foundation. (2016) Is ros for me? [Online]. Available:
[Link]
[15] M.-S.-B. J. O. W. Group, “Mil-std-499b,” Andrews AFB, Washington,
D.C. 20331, Tech. Rep., 1993.
[16] R. P. FOUNDATION. Raspberry pi 2 model b. [Online]. Available:
[Link]
[17] Pixhawk autopilot. [Online]. Available:
[Link]
[18] Digi xbee-pro 900hp. [Online]. Available:
[Link]
modems/xbee-pro-900hp
[19] Camera module. [Online]. Available:
[Link]
[20] F450 arf kit. [Online]. Available: [Link]
m-lite-gps-landing-gear
[21] Rmrc anaconda. [Online]. Available:
[Link]
[22] New latitude 14 rugged. [Online]. Available:
[Link] ck=bt

270