J Intell Robot Syst

DOI 10.1007/s10846-012-9759-5

A Ground Control Station for a Multi-UAV

Surveillance System
Design and Validation in Field Experiments

Daniel Perez · Ivan Maza · Fernando Caballero ·

David Scarlatti · Enrique Casado · Anibal Ollero

Received: 29 June 2012 / Accepted: 26 July 2012

© Springer Science+Business Media B.V. 2012

Abstract This paper presents the ground control
station developed for a platform composed by
multiple unmanned aerial vehicles for surveillance
missions. The software application is fully based
on open source libraries and it has been designed
as a robust and decentralized system. It allows the
operator to dynamically allocate different tasks to
the UAVs and to show their operational informa-
tion in a 3D realistic environment in real time. The
ground control station has been designed to assist
the operator in the challenging task of managing
a system with multiple UAVs, trying to reduce
his workload. The multi-UAV surveillance system
has been demonstrated in field experiments using
two quadrotors equipped with visual cameras.

D. Perez · I. Maza (B) · F. Caballero · A. Ollero Keywords Multi-UAS platforms · Ground

Grupo de Robotica, Vision y Control, Universidad de control station · Decentralized architectures ·
Sevilla, Seville, Spain
e-mail: imaza@us.es Graphical interfaces
D. Perez
e-mail: dprodriguez.grvc@gmail.com
F. Caballero
e-mail: fcaballero@us.es 1 Introduction
A. Ollero
e-mail: aollero@cartuja.us.es The progress on miniaturization technologies, to-
gether with new sensors, embedded control sys-
D. Scarlatti · E. Casado tems and communication, have boosted the devel-
Boeing Research & Technology Europe, Avenida Sur
opment of many new small and relatively low cost
del Aeropuerto de Barajas 38, Bldg 4, Madrid 28042,
Spain Unmanned Aerial Vehicles (UAVs). However,
constraints such as power consumption, weight
D. Scarlatti
e-mail: David.Scarlatti@boeing.com and size play an important role in the UAVs’
performance, and particularly in small size, light
E. Casado
e-mail: Enrique.Casado@boeing.com and low cost UAVs. Then, the cooperation of
many of these vehicles is the most suitable ap-
A. Ollero proach for many applications. A single powerful
Center for Advanced Aerospace Technology
aerial vehicle equipped with a large array of dif-
(CATEC), Parque Tecnológico y Aeronáutico de
Andalucía, La Rinconada, Spain ferent sensors of different modalities is limited at
e-mail: aollero@catec.aero any one time to a single view point. However, a

team of aerial vehicles can simultaneously collect
information from multiple locations and exploit
the information derived from multiple disparate
points to build models that can be used to take
decisions. Team members can exchange sensor
information, collaborate to identify and track tar-
gets and perform detection and monitoring activ-
ities among other tasks [1, 2]. Thus, for example,
a team of aerial vehicles can be used for explo-
ration, detection, precise localization, monitoring
and measuring the evolution of natural disasters,
such as forest fires. Furthermore, the multi-UAV
approach leads to redundant solutions offering
greater fault tolerance and flexibility.
An efficient user friendly Ground Control Sta-
tion (GCS) is a crucial component in any Un-
manned Aerial System (UAS) based platform.
The GCS gathers all the information about the
UAV status and allows to send commands ac-
cording to the specified missions. It is remarkable
that most of the stations include a common set
of components, such as artificial horizons, battery
and IMU indicators and lately 3D environments
[3–5], as generally accepted useful elements for
the operators.
The operator’s workload grows exponentially
with the number of UAVs operating/flying in
the platform. Due to the critical nature of the
unmanned flights, there has been a continuous
effort to improve the capabilities of the GCSs
managing multiple UAVs. The use of multimodal
technologies begins to be usual in current GCSs
[6, 7], involving several modalities such as posi-
tional sound, speech recognition, text-to-speech
synthesis or head-tracking. The level of interac-
tion between the operator and the GCS increases
with the number of information channels, but
these channels should be properly arranged in
order to avoid overloading the operator.
In [8] some of the emerging input modalities for
human-computer interaction (HCI) are presented
and the fundamental issues in integrating them
at various levels—from early “signal” level to in-
termediate “feature” level and to late “decision”
level—are discussed. The different computational
approaches that may be applied at the different
levels of modality integration are presented, along
with a briefly review of several demonstrated mul-
timodal HCI systems and applications.
J Intell Robot Syst
Reference [9] provides a survey on relevant
aspects such as the perceptual and cognitive issues
related to the interface of the UAV operator,
including the application of multimodal technolo-
gies to compensate for the dearth of sensory in-
formation available. The decrease on the reaction
time of the operator adding modalities such as au-
ditory information (3D audio), speech synthesis,
haptic feedback and touch screens are analyzed
in [10].
It is possible to find commercial GCSs for
multi-UAV systems ranging from the advanced
proprietary and closed solution by Boeing for
the X-45 [11, 12] to open source solutions as
QGroundControl [5] or the Paparazzi System [13]
used in [14].
This paper presents the ground control station
developed for a platform composed by multiple
unmanned aerial vehicles in surveillance missions
demonstrated in field experiments. The applica-
tion is fully based on open source libraries and it
has been designed as a robust and decentralized
system. It allows to allocate different tasks to the
UAVs and shows their operational information in
a 3D realistic environment in real time.
2 Multi-UAV Surveillance System Architecture
The system used to validate the ground control
station is composed by a team of UAVs, a network
of ground cameras and the station itself. The over-
all software architecture of the system is shown in
Fig. 1, where different independent processes can
be identified. Each software component can be
transparently executed in the same machine or in
different computers thanks to the communication
functions provided by the YARP library. The only
exception is the UAV position/orientation con-
troller that must be executed on its corresponding
on-board computer.
In each UAV, there are two main levels: the
Automatic Decision Level (ADL) and the pro-
prietary Executive Level (EL). The former deals
with high-level decision-making whereas the lat-
ter is in charge of the execution of the so-called
elementary tasks (land, take-off and go-to). In
the interface between both levels, the ADL sends
task requests and receives the execution state of
J Intell Robot Syst

Fig. 1 Decentralized
software architecture.
The boxes and ellipses
represent the ground and
flying segment processes
respectively. In each
UAV, there are two main
levels: the Automatic
Decision Level (ADL)
and the proprietary
Executive Level (EL).
The gray arrows
represent XBee
communication links.
Finally, the YARP based
communications are
represented by black
(video transmission) and
white (non-video) arrows

each task and the UAV state. For distributed
decision-making purposes, interactions among the
ADLs of different UAVs are required. Finally,
the position/orientation controller is running on
the hardware on-board the UAV. The main el-
ements of this architecture are described in [1],
which summarizes the functionalities endowed at
each level.
The ground control station allows the user to
specify the missions and tasks to be executed by
the platform, and also to monitor the execution
state of the tasks and the status of the different
components of the platform. On the other hand,
the ground camera network provides images from
the area of interest for surveillance purposes.
An useful capability of the system is the possi-
bility to operate in simulation mode. The EL and
ADL can simulate a virtual UAV that is treated
like a real one by the GCS. From the point of view
of the GCS and its operator, it is transparent if
the UAV is real or simulated using a computer.
In simulation mode, the operator can increase his
skills with the platform and the GCS, improv-
ing his reaction times and situation awareness
during the design and execution of surveillance
missions.
The next section is focused on the design and
implementation of the GCS and its interaction
with the rest of components.
3 Ground Control Station Design
and Implementation
The main goal in the design of the GCS was to
simplify the command and control of a multi-
UAV surveillance system in order to keep the
workload of the operator below a certain level.
The system was designed to be controlled by a
single user, who must be able to command several
interacting UAVs in order to perform coordinated
missions. In addition, the following aspects have
been considered in the design:
– The GCS should automatically detect inser-
tions or removals of UAVs in the system,
following a plug-and-play paradigm.
– The GCS should provide visual alerts as a
response to different events that may happen
during the operation of the system, such as a
low battery level or a problem with the video
transmission of a ground camera.

Fig. 2 Ground control
station main layout. Four
main areas have been
numbered: 1 UAV
selector, 2 detailed UAV
information, 3 map area
and 4 tab widget
– The GCS should display all the information
required to be aware of the state of each
UAV. However, the information must be
carefully selected in order to avoid overload-
ing the operator.
– A certain level of decisional autonomy is as-
sumed on-board each UAV (see Section 2),
so that the user should not pay continuous
attention to the state of all the UAVs in the
system.
The resulting layout of the GCS is depicted
in Fig. 2, where four main areas have been
numbered:
1. UAV selector. One click on the UAV’s iden-
tifier (or its shortcut) selects the UAV, updat-
ing the area 2 in Fig. 2 with its information and
making an automatic zoom over its location
on the map. The layout of the current version
of the GCS has been designed to support four
UAVs in terms of selectors, shortcuts, etc.
However, the software can be easily adapted
to support more UAVs, being the workload of
the operator the limiting factor regarding the
maximum number of UAVs to handle from
the GCS.
2. Detailed information of the selected UAV.
These indicators show all the information
J Intell Robot Syst
required to localize the selected UAV on any
point on the Earth. It contains information
about GPS latitude, longitude, and altitude,
heading, barometric altitude and the number
of available GPS satellites being used by the
UAV on-board controller. The UAV status
shows its current mode of operation and the
level of the battery (voltage and intensity). A
visual/sound alarm is triggered when the bat-
tery reaches a critical level and a red LED is
turned on. Additionally, it shows information
coming from the Inertial Measurement Unit
(IMU).
3. Map area. This is an interactive map that
displays important information such as the
locations of UAVs, alarms or motion tasks.
4. Tab Widget. It contains all the widgets of the
application (logging, sensor visualization, etc),
except the map widget.
The common cycle of operation is simple. After
the initial setup (detecting screens on the station,
activating the sound, etc.) an automatic updating
process is executed every ten seconds in order
to detect the addition/extraction of components
(such as UAVs and cameras) in the system. If a
new component is detected, a thread showing its
information is launched at a refresh rate of 10 Hz,
while in parallel the GCS updates the different
widgets. The overall process is shown in Fig. 3.
J Intell Robot Syst

Fig. 3 A scheme of the

main execution loop of
the ground control station
software. The different
events or tasks are
treated in their specific
slots, in parallel to the
main loop execution

The selection criteria for the libraries used in
the software implementation was based on:
– Widely contrasted usage in the community
and reliability.
– Well documented APIs.
– Open source.
– Multiplatform.
– C++ based.
According to these prerequisites, the following
decisions were taken in the design:
– The Graphical User Interface (GUI) was de-
veloped using the Qt library [15], that allows
an easy development of user interfaces due to
its signals and slots connection method [16].
It provides its own IDE and easy integration
with other C++ libraries.
– The video image treatment was based in the
Intel’s OpenCV library [17], a fact standard in
digital image processing.
– The integration of the map was solved using
the Marble library [18] that provides a fully
compatible Qt widget.
– A realistic 3D environment was developed
using the OpenSceneGraph [19] and the OSG
Earth [20] libraries.
– Finally, interprocess communication was
solved by using the YARP library [21].
YARP is an open source code framework,
multiplatform, almost written in C++, that
supports distributed computation in a very
efficient way.
During the software development stage, the
main difficulties were found in the asynchronous
nature of the system with multiple UAVs, tasks
and associated events. In addition, several issues

related to the integration of the different libraries
had to be solved.
Finally, it should be mentioned that the design
and implementation of the GCS has no limitation
in terms of the number of UAVs that can be man-
aged. In this paper, the screenshots correspond
to a platform composed by four UAVs, but the
layout of the interface can be directly and easily
configured for a higher number of UAVs. In this
point, the limit is given by the capabilities of the
human operator when dealing with an increasing
number of UAVs.
In the following subsections, the main widgets
of the GCS are described along with their usage
by the operator to control several UAVs.
3.1 Marble Map Widget
The map widget is an important component in
any GCS that shows the position and orientation
of the UAVs on a global map, updating them in
real time. It shows also additional information,
such as areas of interest, intruders, waypoints,
trajectories, video streaming from the UAVs, etc.
The widget is based on the Marble Library, and
the geographical information is provided by the
Open Street Maps project [22]. This combination
has proven to be an interesting option compared
to Google Maps, with an important advantage: it
does not require access to the Internet during the
operation of the system (it is possible to pre-cache
the areas of interest in disk).
Fig. 4 Left Example of
the SVG widgets used in
the ground control. Right
UAV control panel that
integrates buttons for the
different tasks, a
mini-HUD and a classical
mission time counter
J Intell Robot Syst
The map widget is completely interactive and
the user can perform different operations: zoom
in/out, move around, follow the selected UAV,
generate missions and pathways, choose the ele-
ments to be displayed (UAVs, waypoints, camera
projections, intruders or surveillance zones), get
coordinates, etc.
3.2 SVG Widgets
Some information components, such as the bat-
tery levels, are represented using SVG widgets
(see Fig. 4, left) to simulate a cockpit environment
that can be more intuitive for the operator. These
widgets are based on the Qt Embedded Widgets
Demo [15].
3.3 OSG Earth Widget
The OSG Earth widget shows a 3D real size model
of the Earth, with the geographical information
also provided by the Open Street Map Project.
Over the Earth model, the system draws the
UAVs and other relevant elements to the mission
such as the waypoints, lines from the UAV to the
next scheduled waypoint, planes perpendicular to
the surface of the Earth showing the remaining
trajectory, etc.
Additional 3D models of buildings, bridges,
monuments, etc can be displayed on the terrain
to increase the realism of the environment and to
improve the situational awareness of the remote
J Intell Robot Syst

Fig. 5 Screenshot of the

OSG Earth widget used
in the ground control
station. The camera can
be configured to be
controlled by the
operator or to follow the
UAV automatically from
a chase or top view. It is
also possible to switch to
a virtual view of any of
the available ground
cameras

operator. These objects can be loaded from a
COLLADA model [23]. Figure 5 shows a screen-
shot of the widget.
3.4 Multi-UAV Control Panel Widget
When an UAV is added to the system, a new
UAV control panel widget is created with an
unique color code identifier. The control panel
shows the UAV number and a LED with the
status of the communication link. There are also
eight buttons to send the following tasks to the
UAV (from left to right according to Fig. 4, right):
– Row 1: TAKE-OFF, LAND, RETURN-HOME,
GO-TO.
– Row 2: SURVEILLANCE, WAIT, TAKE-
IMAGES, RECHARGE.
It is important to highlight that the disposition
of the command buttons and the information sim-
plify the work of the operator. The task buttons
included in the panel allows to build complex
missions based on the combination of different
tasks. In addition, the ADL and EL on-board
the UAV (see Section 2) checks the different
specified missions against inconsistencies and un-
safe trajectories.
Finally, a mini Head-Up Display (HUD) with
a classical artificial horizon level has been devel-
oped and integrated. It shows the orientation of
the UAV with respect to the horizon, and the
indicators of the altitude, heading and speed. This
information is overlaid on the images from an on-
board camera if it is available. This widget has
been developed from scratch using the graphical
capabilities provided by the Qt library [15].
3.5 Graphs Widgets
The graphs widget plots graphics of data from
different sensors of the selected UAV in real time.
Available measurements are yaw, pitch and roll
angles, speed vector and battery levels. It also
plots the trajectory followed by the UAV in Carte-
sian coordinates [x,y] (as it can be seen in Fig. 6),
so the operator can track its flight path during the
execution of the mission.
3.6 OSD Notifications and Alarms
The different events that may occur during the
execution of a mission are notified to the oper-

Fig. 6 An example of a graph widget showing the trajectory followed by the UAV in Cartesian coordinates [x,y]
ator in different ways. At the top level, an On
Screen Display (OSD) system has been devel-
oped, popping-up the notifications to the user in
a partially transparent window, as it can be seen
in Fig. 7.
Events with higher priority or with the need
of an interactive answer by the operator are dis-
played in a pop-up window, as it is shown in
Fig. 12. Sounds can be also linked to both types
of alarms.
3.7 Log Player Widget
The log player widget is a tool very useful to
replay previous flights and experiments for mis-
sion debriefing purposes. The operator only have
to select a log file, corresponding to a previous
mission, to replay it using the common multimedia
controls (play, stop, etc).
Fig. 7 An example of the OSD notification system that
uses a partially transparent window to keep the operator
informed about the different events
J Intell Robot Syst
4 GCS Testing in Field Experiments
The ground control station was tested in field
experiments on November 2011 in Seville. The
overall multi-UAV surveillance system architec-
ture described previously along with the devel-
oped GCS were used in two types of missions with
with two customized quadrotors.
4.1 Hardware Setup
The UAVs integrated in the system were two
quadrotors of the model Pelican manufactured by
Ascending Technologies [24]. This quadrotor had
available enough payload (500 g) for executing
different missions. It is equipped with an Intel
Atom on-board which allows to connect add-on
sensors and cameras, mainly via mini USB inter-
faces. The UAV has a flight autonomy of approx-
imately fifteen minutes at full payload.
A customized Ubuntu Linux distribution was
installed on the Atom board and configured with
several watchdogs processes in order to guarantee
the wireless LAN communication and the alloca-
tion of identifiers to the devices on-board. Each
quadrotor was equipped with a high definition
webcam, a XBee-PRO radio data link and a GPS
receiver for telemetry, all of them connected to
the Atom board with customized mini USB con-
nections (see Fig. 8). The captured images were
transmitted to the ground through the wireless
LAN connection, whereas the on-board position
and orientation controller used the XBee radio
J Intell Robot Syst

and both EL/ADLs) on a single laptop. However,

looking for an improved supervision during the
field experiments, it was decided to use three dif-
ferent laptops: two of them running the EL/ADL
associated to each quadrotor and the third one to
execute the GCS.
The next sections describe the two types of
missions carried out in Seville in November 2011
to test the developed multi-UAV GCS.

4.2 Mission 1: Camera Network Dynamic

Repairing

The objective of this mission is to use the IP

Fig. 8 Customized quadrotor of the model Pelican by
Ascending Technologies equipped with a high definition
webcam, a XBee-PRO radio data link and a GPS receiver
for telemetry, all of them connected to the Atom board
with customized mini USB connections
link to send the telemetry data to its EL/ADL
processes (running on a laptop). This hardware
setup is summarized in Fig. 9.
Due to the decentralized software design, it
is also possible to run all the processes (GCS
cameras on-board the UAVs to provide images
of an area in which a ground camera is damaged
or temporally offline. Thus, the system must be
able to detect the potential failures of the ground
cameras and to schedule the required tasks to
allow the UAV cover the area around the non-
working camera location.
If the signal from one camera of the network
(or its datalink) is lost, an alarm is triggered on
the GCS map as it is shown in Fig. 10. Then, the
operator is asked to confirm an automatic task for

Fig. 9 Hardware setup

used in the field
experiments. The
captured images were
transmitted to the ground
through the wireless LAN
connection, whereas the
on-board position and
orientation controller
used the XBee radio link
to send the telemetry data
to its EL/ADL processes
(running on a laptop).
The Linksys E4200 dual
band router was used to
support LAN
communication between
the ground
computers/cameras and
wireless communication
with the on-board IP
cameras

Fig. 10 If a camera of the ground network (or its datalink)
is lost, an alarm is triggered on the GCS map. The operator
is asked to confirm an automatic task for the UAVs in
order to cover the area lost by the camera
the UAVs in order to cover the area lost by the
camera.
The task is allocated to one of the UAVs ac-
cording to its available capabilities that depends
on the location, flight endurance and sensors on-
board. The UAV takes-off, flies to the selected
location and sends the images to the GCS until
the ground camera link is restored (see Fig. 11).
If the UAV’s autonomy is below a certain thresh-
old, the GCS will detect it and will communicate
a RETURN-HOME task to get the UAV back. In
this case, the original task can be automatically
transferred to another UAV in order to continue
with the mission.
Fig. 11 UAV-1 is
hovering on the area
previously covered by the
lost camera to restore the
surveillance
J Intell Robot Syst
4.3 Mission 2: Cooperative Area Surveillance
In this mission, the area of interest was automati-
cally split in subareas taking into account the num-
ber of available UAVs in order to efficiently pa-
trol it. The mission was launched by the GCS (un-
der the operator’s supervision) when an intruder
was detected and localized by the ground camera
network. The intruder alarm was displayed on
the interactive map of the GCS as it is shown in
Fig. 12. Then the operator had two options:
1. Allow the automatic generation of a surveil-
lance task around the area in which the in-
truder was detected.
2. Set different waypoints manually around the
area of interest.
In the field experiments conducted, the oper-
ator always selected the first option in order to
test the autonomous capabilities of the system.
Thus, a surveillance area task was automatically
requested by the GCS to the ADLs, that replied
with the subareas and waypoints for each UAV
considering the operational constraints, such as
battery levels or distances to the subareas. These
subareas and waypoints were displayed on the
GCS to be validated (see Fig. 13). Then, the op-
erator could have modified or removed the differ-
ent tasks allocated to each UAV. Once the plan
J Intell Robot Syst
Fig. 12 Automatic intruder alarm window. The operator
has the option to allow the automatic generation of a
surveillance task around the area in which the intruder was
detected
was completed, the operator validated it and the
autonomous execution of the mission started.
The IP cameras on-board were pointing down-
wards sending images through the wireless link
Fig. 13 Resulting automatic area partition and list of
waypoints
Table 1 Web links to several videos showing different
GCS capabilities: widgets described from Sections 3.1–
3.6, simulation involving four UAVs and field missions
(Mission 1 and Mission 2) carried out in November 2011
using a team of two quadrotors
Widgets http://grvc.us.es/GCS/gcs_widgets.wmv
Simulation http://grvc.us.es/GCS/gcs_sim.avi
Mission 1 http://grvc.us.es/GCS/gcs_mission1.wmv
Mission 2 http://grvc.us.es/GCS/gcs_mission2.wmv
to the GCS and the operator could supervise the
area searching for other potential intruders. The
workload of the operator was low during the exe-
cution, as he only had to attend the images from
the cameras displayed on the map.
Table 1 contains web links to the following
videos:
– Widgets: Video showing all the widgets de-
scribed from Sections 3.1–3.6.
– Simulation: A simulation of a mission involv-
ing four UAVs.
– Mission 1: Mission described in Section 4.2.
– Mission 2: Mission described in Section 4.3.
5 Conclusions and Future Work
The design adopted on the system architecture
has demonstrated to be an efficient solution to
achieve a rapid deployment of a multi-UAV sur-
veillance system. The design of the GCS exploited
the autonomous capabilities of the multi-UAV
system to decrease the workload of the operator.
Thus, the developed GCS allowed to use most
of the capabilities that the autonomous multi-
UAV system could provide, while at the same
time offered an user-friendly and easy-to-operate
interface.
Future work will be focused on the next lines:
– Integration of the information from other sen-
sors in the GCS such as LIDAR, seismic,
smoke detectors, etc.
– Possibility of executing the GCS station from
a remote location through internet.
– Customize several GCS interfaces in order
to satisfy different user profiles: engineer,
surveillance operator or strategic mission
planner.

Acknowledgements This work has been developed in the
framework of the ADAM and CLEAR (DPI2011-28937-
C02-01) Spanish National Research projects. The authors
would also like to thank the Boeing Research and Tech-
nology Europe company for their financial and technical
support.
References
1. Maza, I., Caballero, F., Capitan, J., de Dios, J.M.,
Ollero, A.: A distributed architecture for a robotic
platform with aerial sensor transportation and self-
deployment capabilities. J. Field Robot. 28(3), 303–328
(2011). doi:10.1002/rob.20383
2. Bernard, M., Kondak, K., Maza, I., Ollero, A.: Au-
tonomous transportation and deployment with aerial
robots for search and rescue missions. J. Field Robot.
28(6), 914–931 (2011). doi:10.1002/rob.20401
3. Jovanovic, M., Starcevic, D.: Software architecture for
ground control station for unmanned aerial vehicle. In:
Tenth International Conference on Computer Model-
ing and Simulation, 2008. UKSIM 2008, pp. 284–288
(2008)
4. Dong, M., Chen, B., Cai, G., Peng, K.: Development
of a real-time onboard and ground station software
system for a uav helicopter. JACIC 4(8), 933–955
(2007)
5. QGroundControl: Open source MAV ground control
station. http://qgroundcontrol.org (2010). Accessed 15
May 2012
6. Lemon, O., Bracy, A., Gruenstein, A., Peters, S.: The
WITAS multi-modal dialogue system I. In: Proceed-
ings of the 7th European Conference on Speech Com-
munication and Technology (EUROSPEECH), pp.
1559–1562, Aalborg, Denmark (2001)
7. Ollero, A., Maza, I. (eds): Multiple Heterogeneous Un-
manned Aereal Vehicles. ser. Springer Tracts on Ad-
vanced Robotics. ch. Teleoperation Tools, pp. 189–206.
Springer, New York (2007)
8. Sharma, R., Pavlovic, V.I., Huang, T.S.: Toward multi-
modal human-computer interface. Proc. I.E.E.E. 86(5),
853–869 (1998)
9. McCarley, J.S., Wickens, C.D.: Human Factors Impli-
cations of UAVs in the National Airspace. Institute
of Aviation, Aviation Human Factors Division, Uni-
J Intell Robot Syst
versity of Illinois at Urbana-Champaign, AHFD-05-
5/FAA-05-1. Tech. Rep. (2005)
10. Maza, I., Caballero, F., Molina, R., Pena, N., Ollero, A.:
Multimodal interface technologies for UAV ground
control stations. A comparative analysis. J. Intell. Ro-
bot. Syst. 57(1–4), 371–391 (2010). doi:10.1007/s10846-
009-9351-9
11. Boeing: X-45 Unmanned aerial combat system. http://
www.boeing.com/history/boeing/x45_jucas.html (2012).
Accessed 15 May 2012
12. Boeing: Ground control station for multiple X-
45 Unmanned Aerial Combat Systems. http://www.
youtubewatch?v=ilyUNkjKlPM.com/ (2012). Accessed
15 May 2012
13. The Paparazzi Project: Free and open-source hardware
and software autopilot system. http://paparazzi.enac.fr
(2012). Accessed 15 May 2012
14. Brisset, P., Hattenberger, G.: Multi-UAV control with
the paparazzi system. In: Proceedings of the First Con-
ference on Humans Operating Unmanned Systems
(HUMOUS’08). Brest, France, 3–4 September 2008
15. N. Corporation: Qt reference documentation. http://
doc.qt.nokia.com/4.6 (2012). Accessed 4 Mar 2012
16. Blanchette, J., Summerfield, M.: C++ GUI Program-
ming with Qt 4. Prentice Hall, Englewood Cliffs, NJ
(2006)
17. OpenCV: Open source computer vision. http://opencv.
willowgarage.com (2012). Accessed 15 May 2012
18. The Marble Project. KDE Educational Project (2005–
2011). Available Online: http://edu.kde.org/marble
(2012). Accessed 4 Mar 2012
19. Open Scene Graph. Open source 3d graphics
toolkit (2005–2011). Available Online: http://www.
openscenegraph.org (2012). Accessed 4 Mar 2012
20. OSG Earth. Terrain rendering toolkit. Pelican Map-
ping (2005–2011). Available Online: http://osgearth.
org/ (2012). Accessed 4 Mar 2012
21. Metta, G., Fitzpatrick, P., Natale, L.: Yarp: yet another
robot platform. Int. J. Adv. Robot. Syst. 3(1), 043–048
(2006)
22. The Open Street Map Project (2005–2011). Avail-
able Online: http://www.openstreetmap.org (2012). Ac-
cessed 15 May 2012
23. COLLADA - Digital Asset and FX Exchange Schema.
Available Online: https://collada.org (2012). Accessed
15 May 2012
24. Ascending Technologies (2011). Available Online:
www.asctec.de (2012). Accessed 4 Mar 2012