=Paper=
{{Paper
|id=Vol-2215/paper2
|storemode=property
|title=Integrating Heterogeneous Tools for Physical Simulation of multi-Unmanned Aerial Vehicles
|pdfUrl=https://ceur-ws.org/Vol-2215/paper_2.pdf
|volume=Vol-2215
|authors=Fabio D'Urso,Corrado Santoro,Federico Fausto Santoro
|dblpUrl=https://dblp.org/rec/conf/woa/DUrsoSS18
}}
==Integrating Heterogeneous Tools for Physical Simulation of multi-Unmanned Aerial Vehicles==
https://ceur-ws.org/Vol-2215/paper_2.pdf
Integrating Heterogeneous Tools for Physical
Simulation of multi-Unmanned Aerial Vehicles
Fabio D’Urso, Corrado Santoro, Federico Fausto Santoro
University of Catania
Department of Mathematics and Informatics
Viale Andrea Doria, 6
95125 - Catania, ITALY
EMail: {durso,santoro}@dmi.unict.it, federico.santoro@unict.it
Abstract—This paper presents a multi-layer software archi- path commands to UAVs; while these solutions can guarantee
tecture to simulate, in a accurate and realistic way, a set of optimality in UAVs distribution or area coverage, they have
unmanned aerial vehicles (UAVs) operating in a specific mission. the drawback of presenting a single point of failure, that is
A set of tools are employed, each one to simulate a specific
part of the overall UAV hardware and software structure: a the central entity itself. Distributed approaches are based on
3D visualization engine, a physical simulator, the flight stack algorithms that let UAVs (by interacting) self-organise and
and a network simulator to handle interactions among UAVs. self-maintain the flock, and usually exploit the classical sep-
A software architecture able to orchestrate and coordinate such aration, alignment and cohesion rules [17] that are proper of
tools is proposed, based on multiple layers of processes divided flocking [10], [9]; these approaches, that indeed are preferred
into two categories. The described approach is based on a
protocol system for exchanging messages to synchronize the to centralised ones, are surely more fault-tolerant but often are
various simulation tools. The simulation of the unmanned aerial not able to achieve optimality, since each UAV performs its
vehicles can therefore be performed on a single machine or evaluation of flight path basing on the information, coming
distributed on several machines in order to create a distributed from other UAVs, that could not be complete or updated.
simulation and spread the workload. In this way, it is possible As a result, UAV flocking integrates concepts, techniques
to simulate the behavior of the UAVs and also to reason about
the problems due to network communications. and solutions proper of control systems, wireless communica-
tion, coordination and agreement and self-organisation: the
I. I NTRODUCTION natural consequence of this statement is that implementing
Recent research in the field of ummanned aerial vehicles such kind of systems is quite far from a simple task. And
(UAVs) shows a trend to investigate approaches and algorithms to make things yet more complicated, testing UAV-based
for autonomous flights in flocks [17], [19], [6], [8], [10], [14], solutions is particularly hazardous: flying machines have the
[5], [9], [11], [16], [20], [7], [22], [21], [3]. Such a research bad characteristic, when a fault occurs (and during testing
area implies the integration of different technologies. this could be a common case), of falling into the ground,
First of all, UAVs must be made able to fly more or less thus provoking crashes and the need to repair or rebuild the
autonomously; to achieve this objective, a proper CPU-based mechanical frame1 . For this reason, the common approach is to
flight control system must be employed, implementing all make extensive simulation campaigns before testing solutions
the control algorithms to perform UAV stabilisation, position on real UAVs.
control, path following, etc. In addition, since UAVs of a Simulators are thus key tools in this research field, but, in
flock should be able to communicate to each other in order to order to be as realistic as possible, they must integrate all the
perform coordination, a “inter-UAVs” wireless communication technology aspects cited above plus another not less important
system is mandatory, together with an adequate protocol one: the physical behaviour of the UAVs.
guaranteeing a communication which is reliable to a certain Indeed, UAVs are weird mechanical system with a dynamics
extent. Often also an interaction with a base station is required, that tends to oscillation or instability, above all in presence of
in order to obtain telemetry data and let operators to have specific environmental conditions (e.g. wind or turbulence).
a form a mission control; this requires obviously a wireless Unfortunately, a simulator able to integrate all of this aspects
communication channel that, however, could have different does not exist, but there are many simulators implementing
characteristics with respect to the inter-UAV system. Flocking each one of the specific aspects described: an integration of
not only implies the presence of communication channels but all of them is the simplest way, but it is not straightforward
also—and this is indeed more important—a flocking algorithm and often requires hacks or instrumenting the code in order to
able to drive UAVs in forming and maintaining the flock shape achieve the objective.
and, altogether, perform the flight mission; in this sense the This paper goes in this last direction: it presents a technique
literature reports many approaches that can be mainly subdi- to integrate different simulation tools in a single large envi-
vided in centralised and distributed. Centralised approaches
adopt on a central entity that elaborates and sends flight or 1 When such crashes are not hazardous for people.
10
ronment able to simulate: UAV physics, UAV control, wireless or slower than a wall-clock time source) without affecting
communication, flocking algorithms. In particular, the tools accuracy of the simulated system.
employed are Gazebo [12] (for physics), ArduPilot [1], as
flight control platform and ns-3 [18], for wireless network B. ArduPilot
simulation. All of them are integrated into a large system that ArduPilot [1] is a control stack for UAVs (with the Ar-
coordinates them and the simulation. The adopted solution duCopter subproject) and UGVs. It is an open-source product
is also modular and distributed: while a 3D visualisation with a wide community of developers and, together with
environment is provided (by Gazebo), it can also be disabled PX4 [13], is one of the most widely used flight control stacks
in order to perform batch simulations and gather specific for drones. It runs upon a variety of hardware platforms and
numerical results; moreover, since in the presence of a good provides all the algorithms to control stability and flight of
number of UAVs the CPU cost of simulation could become a UAV, including the autonomous flight over a path of GPS
very high, the various parts can be also split over several waypoints.
interconnected computers. ArduPilot can be externally interfaced (via serial line or
The paper describes the software architecture we used in TCP connection) by means of an ad-hoc protocol called
implementing such an integrated simulator and is organised as MAVLink [4] that is specifically designed to connect a Ground
follows. Section II describes the single simulation tools used Control Station (for telemetry or set-up operations) or an
in the integration. Section III presents the integrated simulator. external computer that implements high-level mission control.
Section IV provides our conclusions. In addition, ArduPilot provides support for Software In The
Loop (SITL) simulations through the Gazebo simulator; SITL
II. T OOLS is a very useful tool because it enables to test the high-level
logic using the same interface a real UAV would offer (i.e.
A. Gazebo
MAVLink).
Gazebo2 [12] is a 3D robotic simulator with a physical An interesting additional tool that is often integrated with
engine capable of simulating, in efficient and accurate way, ArduPilot is DroneKit [2], a set of applications, libraries
a large number of robot types. Simulations can be performed and APIs, provided for various programming languages and
by simulating both an indoor or outdoor environment. Gazebo platforms, that implement the MAVLink protocol and allow
also provides the support to simulate various types of sensors, developers to easily write high-level applications for drones
actuators and interfaces. that run the ArduPilot stack.
Robot models are designed by means of an XML file
that defines the structure in terms of fixed parts, joints with C. Network Simulator 3
their physical parameters (geometry and dynamics), driving Network Simulator 3 (ns-3) [18] is a network simulator
characteristics, and specific sensors. Robots in Gazebo can be capable of simulating several types of infrastructures and their
controlled externally by means of software plugins; the model network protocols.
is based on a publisher-subscriber paradigm that lets plugins Compared to the its previous version (ns-2), which was
obtain data from sensors and intervene on actuators by sending written in C++ but required simulations to be written in object-
proper commands or set-points. oriented Tcl (o-Tcl), the new version lets a programmer define
The software structure of Gazebo is designed to keep a simulation directly in C++ or Python, whereas ns-2’s mixture
separated the 3D visualisation part (called gzclient) from the of o-Tcl and C++ was hard to debug and unfamiliar to most
physical engine (called gzserver). A simulation can be exe- people. Ns-3 is designed to run “pure C++”-based models,
cuted without display (this is useful to run batch simulations) for greater performance, and it also provides a Python-based
and both parts can run in two different computers in order scripting API that allows ns-3 to be integrated with other
to take advantage of a distributed environment (both parts are Python-based environments or programming models. Users of
CPU-intensive tasks thus the execution in different servers can ns-3 can write their simulations as either C++ main() programs
speed-up the simulation). or Python programs.
This simulator is widely used to test new algorithms in The new version has been developed to be as modular as
virtual environments and to analyse robots’ behaviors. In possible. Indeed, the structure of ns-3 makes it simple to
addition, Gazebo takes advantage of multiple physical engines develop new models of simulations or customise existing ones.
and provides an extensive library of ready-to-use robot models. The simulator supports most wired, wireless and mobile
Of course, the simulator also allows one to build customised network protocols as well as routing protocols. Furthermore,
models. Gazebo is also fully integrated with the ROS sys- ns-3 supports interactions with the “real world”, such as the
tem [15] thus allowing users to use the same code tested on creation of a simulated network where nodes can actually ping
Gazebo directly on the physical robot. a server on the Internet.
A peculiar aspect of this type of simulations is that it
III. T HE I NTEGRATED S IMULATION E NVIRONMENT
is possible to run them in non real-time (i.e. either faster
The tools briefly presented in Section II are the basic blocks
2 http://gazebosim.org/ to build a complete simulation environment for a flock of
11
Ns-3 process
Phase 1 UAV UAV UAV
Gazebo process subscription node node node
(gzserver) (TCP)
ArduCopter-
UDS
ExternalSyncManager
PluginSyncUDS ArduCopter process MAVLink (TCP)
gzuavchannel High-level logic
channels (TCP)
instance (in SITL mode)
#1
UDS
Phase 0 subscription (TCP)
ArduCopter- UDS
PluginSyncUDS
instance UDS TCP
ArduCopter process MAVLink (TCP)
High-level logic
UDS (in SITL mode)
gzuavchannel Phase 0 subscription (TCP)
ArduCopter- #2
PluginSyncUDS
instance UDS
ArduCopter process MAVLink (TCP)
High-level logic
(in SITL mode)
Phase 0 subscription (TCP)
Fig. 1: Software Architecture of the Integrated Simulator
UAVs interconnected through a wireless network; the main The ArduCopter process is a stand-alone process running
issue with such tools is that they are not designed to work an instance of the ArduPilot flight stack which is specifically
together in an integrated manner. Other than the obvious compiled to support the “software-in-the-loop” (SITL) mode.
problems regarding the way in which these tools should In a similar way, the High-level Logic (HLL) is a process
exchange data, there are important issues related to clock implementing the mission control for the single UAV; in the
synchronization: indeed, since all the tools are designed to case of flocking, the HLL implements the specific flocking
provide a simulation which is more realistic as possible, each algorithm and path planning, as well as the functionalities
of them includes its own notion of time that is (i) rather related to UAV interaction and messaging, which are then
different than wall-clock time and (ii) tied to the events they simulated by means of ns-3. The HLL interacts with the flight
simulate. However, the overall integrated environment must stack through the MAVLink channel that, in the simulated
have a common notion of time, otherwise the simulation will environment, is made of a TCP connection (this interface is
not proceed realistically. The aim of our integrated environ- supported by means of the DroneKit library).
ment is thus a set of modules and a proper protocol that lets the Finally, the UAV node represents the communication end-
employed tools interact and proceed in a strictly synchronised point (i.e. the wireless interface) of the UAV; it is an object that
way. runs within ns-3, which enables the simulation of the wireless
communication channel.
A. Software Architecture
The overall software architecture of the simulator is depicted B. Interaction and Synchronization
in Figure 1 and described below. Each UAV is represented by All the software modules cited so far are responsible to
the following software modules: simulate or implement specific parts of the overall behaviour
1) Gazebo model of each UAV; however they must be coordinated in such a way
2) ArduCopterPluginSyncUDS as to let them proceed in a strictly synchronized way and with
3) ArduCopter process a common notion of simulation time.
4) High-level Logic In our environment, this task is performed by
5) UAV node GZUAVCHANNEL, a software module which mainly
For each simulated UAV, an instance of all the software serves as a clock synchroniser in case of multiple UAVs.
modules above is created; each instance runs within its specific GZUAVCHANNEL also defines a protocol for external
environment (e.g. Gazebo or ns-3) or as a stand-alone process. processes to connect, be notified of changes in the position
All modules are then coordinated by some GZUAVCHAN- of UAVs, and synchronise their own clocks as well. Each
NEL processes according to a schema and protocol which is process intending to take part in the simulation performs a
described in Section III-B. subscription to the GZUAVCHANNEL, specifying its type;
The first two models are related to the graphical and in particular, we identified two classes of external processes:
physical simulation and run inside Gazebo. The Gazebo model • Type 0 subscribers: processes that logically run inside
represents the definition of the frame and inertia of the UAV, the simulated environment, e.g. a DroneKit-based process
which, in our experiments, is a quadri-rotor VTOL aerial that connects to ArduPilot via MAVLink and implements
vehicle. The ArduCopterPluginSyncUDS is a Gazebo plugin the high-level logic of an autonomous UAV;
that interacts with the simulated model by directly driving • Type 1 subscribers: processes that implement part of the
the motors of the quadri-rotor and reading its pose (absolute simulation environment, e.g. the ns-3 network simulator.
position, euler angles, angular rates, etc.). Depending on its type, during the simulation each process
12
ArduCopter Phase 0 subscriber Phase 1 subscriber
gzuavchannel ArduCopterPluginSyncUDS
instance (high-level logic) (ns-3)
BEGINTICKAC
BEGINTICKAC
BEGINTICK0
ENDTICKAC ENDTICK0
BEGINTICK1
ENDTICK1
ENDTICKAC
For each UAV (in parallel)
Fig. 2: Sequence diagram showing messages exchanged among processes for each simulation step
receives a specific notification from the GZUAVCHANNEL; of messages; these operations are performed during this phase
to this aim, GZUAVCHANNEL coordinates the overall sim- by means of DroneKit, for the set-points or any other of
ulation execution so that all Type 0 subscribers can proceed interaction with ArduCopter, and by interacting with ns-3 to
in parallel while Type 1 subscribers are blocked and, vice simulate message exchange through the network. In particular,
versa, when all Type 1 subscribers run in parallel, Type 0 in this phase, HLL processes can send data over the network
subscribers are blocked, in an alternating fashion (Figure 2). by providing ns-3 a packet through the ENQUEUE-NS3
Type 1 subscribers also receive the position of all UAVs message, as detailed in Figure 3a; here the message is not
at the beginning of each simulation step. Communication really processed but only placed in a queue: the simulated
between GZUAVCHANNEL and Type 0/1 subscribers uses a transmission and delivery are not performed by ns-3 until
TCP channel. In addition, the internal architecture lets several Phase 1.
GZUAVCHANNELs interact (also via TCP); this is useful When the HLL process completed its step, it replies to
when, to reduce the computational load, a distributed system is GZUAVCHANNEL with an END-TICK-0 message. In the
used to perform simulation. In this case, the various processes same way, when ArduCopter processes have completed their
taking part to the simulation can be split over different simulation steps, they reply to GZUAVCHANNEL with an
machines of a distributed system and can be coordinated by END-TICK-AC message. When all such replies have been
the various GZUAVCHANNELs running upon such machines. gathered, the Phase 0 is completed.
Synchronisation of the activities of a simulation is initiated After that, the GZUAVCHANNEL starts the Phase 1 by
by the physical engine of Gazebo (gzserver) which, since it sending BEGIN-TICK-1 to all subscribed Type 1 processes
manages the physics of the agents, is the entity in charge and waiting for END-TICK-1. As Figure 3b shows, during
of governing the simulation clock. At the beginning of each Phase 1, ns-3 is asked to do its simulation step by processing
time step, the various instances of ArduCopterPluginSyncUDS enqueued messages and delivering them (if necessary) to
within Gazebo send a BEGIN-TICK-AC message to the HLL processes. Only when all END-TICK-1 messages have
GZUAVCHANNEL that starts coordinating activities of the been received, GZUAVCHANNEL delivers the END-TICK-
simulation according to the protocol depicted in the sequence AC messages to Gazebo, allowing it to proceed to the next
diagram in Figure 2. The BEGIN-TICK-AC is first sent to simulation step.
the relevant ArduCopter instance which performs a step of its
control activities3 ; in parallel, GZUAVCHANNEL announces C. Manging Simulations in a Distributed Environment
the start of Phase 0 by sending a BEGIN-TICK-0 message
to all subscribed Type 0 processes. Phase 0 is particularly The way in which the GZUAVCHANNEL is designed
important since it is the moment in which all Type-0 processes allows a user to distribute the simulation over different in-
can execute their simulation step: it is in this phase that HLL terconnected servers, in order to take advantage of a multi-
processes (for example) execute one step of their flocking (or node environment and reduce CPU load. In this way, the
other) algorithm. This phase can also include an interaction computational workload can be spread over a network, by
with the flight stack or the network; indeed, the algorithm e.g. partitioning the set of UAV into a number of groups, each
surely would include the computation of next speed or position controlled by a different GZUAVCHANNEL instance on a
set-points for the UAV, as well as the transmission or reception dedicated computational node. As it is reported in Figure 4,
in the most general form, a tree can be created, in which
3 See http://ardupilot.org/dev/docs/apmcopter-programming-attitude-control-2. the nodes are GZUAVCHANNEL instances and the edges are
html for the details about the control loops of ArduCopter. TCP connections; in such a tree, the root is represented by
13
gzuavchannel High-level logic ns-3 gzuavchannel High-level logic ns-3
BEGINTICK0 BEGINTICK1
ENQUEUENS3 ENQUEUEHLL
For each For each
message message
ACK ACK
ENDTICK0 ENDTICK1
(a) Messages sent by UAVs are enqueued in ns-3 during Phase 0 (b) Ns-3 runs the network simulation, including the delivery of mes-
sages to UAVs, during Phase 1
Fig. 3: Interactions between high-level logic UAV processes and ns-3
Node B
Node A UDS
ArduCopter process
(in SITL mode)
because it is necessary to synchronise their clocks as well (so
Gazebo process
(gzserver)
gzuavchannel
UDS
ArduCopter process
(in SITL mode)
that the timing of commands such as “take-off, then pause for
ArduCopter-
PluginSyncUDS
instance
ArduCopter-
PluginSyncUDS
instance
UDS
TCP
#2 UDS
ArduCopter process
(in SITL mode) 5 seconds, then go to a given GPS point” stays coherent to the
ArduCopter process
UDS
ArduCopter-
PluginSyncUDS
ArduCopter-
PluginSyncUDS
UDS
UDS
(in SITL mode)
simulated environment). We developed a Python module that
instance instance
Node D
ArduCopter- ArduCopter-
UDS
Node C UDS
ArduCopter process
subscribes to Phase 0 and overrides sleep() and time() with
PluginSyncUDS PluginSyncUDS UDS gzuavchannel TCP (in SITL mode)
instance
ArduCopter-
instance
ArduCopter-
UDS #1
gzuavchannel UDS
ArduCopter process
(in SITL mode)
versions that use the simulation clock. The Python language
PluginSyncUDS PluginSyncUDS UDS gzuavchannel
instance
ArduCopter-
instance
ArduCopter-
UDS
TCP #3
#4 UDS
ArduCopter process
(in SITL mode) was chosen because of the availability of the DroneKit library,
ArduCopter process
UDS
PluginSyncUDS
instance
PluginSyncUDS
instance
UDS
UDS (in SITL mode)
which greatly simplifies the tasks of connecting to ArduPilot,
ArduCopter- ArduCopter-
Node E
PluginSyncUDS
instance
PluginSyncUDS
instance
UDS
UDS
TCP
UDS
ArduCopter process
sending and receiving MAVLink messages (offering the same
(in SITL mode)
gzuavchannel
UDS
ArduCopter process
(in SITL mode)
interface both for a real and a simulated UAV).
#5 UDS
ArduCopter process
(in SITL mode)
ArduCopter process
UDS (in SITL mode)
IV. C ONCLUSIONS
Fig. 4: Architecture of the Integrated Simulator in a Distributed
Environment The ability to manipulate and test algorithms in a simulated
physical environment greatly facilitates software development
and validation phases of autonomous UAVs. ArduPilot and
the instance directly connected to Gazebo, while the leaves Gazebo are two software solutions that, if used together, offer
are connected to ArduCopter processes. a solid and accurate UAV simulation toolkit.
In a distributed environment, the dynamics of interaction are In the context of UAV flocks, each UAV also needs to
quite similar to the centralised case; coordination is performed be able communicate (either with a base station or a among
by using the messages BEGIN-TICK-AC and END-TICK- UAVs themselves), using wireless networking hardware and
AC that are exchanged by GZUAVCHANNELs. In detail, protocols. However, wireless communications are often far
when the first BEGIN-TICK-AC is received from the root from ideal, and the need for accurate network modelling and
GZUAVCHANNEL, it is forwarded to children nodes, down simulation tools arises.
to the leaves of the tree. Each GZUAVCHANNEL thus The proposed multi-layered software structure combines
behaves according to the protocol in Figure 2, coordinating Gazebo, ArduPilot and the ns-3 network simulator, resulting
the processes which it is has the responsibility for. Finally, in a complete tool that enables not only to physically simulate
when Phases 0 are completed, the END-TICK-AC message the flight of UAVs, but also to integrate, in a realistic way,
is generated by leaf nodes and forwarded along the tree until several wireless networking technologies that real UAVs are
the root is reached, thus signalling Gazebo the end of the usually equipped with.
simulation tick. The described architecture has been implemented and val-
idated (see Figure 5). The next steps will be the implemen-
D. Implementation Issues tation of a full-fledged flocking and area coverage algorithm
The framework user can either directly interact with ArduPi- (e.g. [9]), in order to test the solution in a complex and realistic
lot, employing its built-in capability to take-off and follow scenario, and the comparison of numerical results to those of
preprogrammed paths of GPS waypoints, or use an external a real flock of UAVs.
system (usually a companion computer) to send position/speed
targets in real-time according to a custom high-level logic. The V. ACKNOWLEDGMENTS
latter scenario offers greater flexibility and it is the only way
to program UAVs with complex behaviors. However, it is non- This work is supported by project CLARA SCN 00451
trivial to integrate such external systems into the simulation, funded by the Italian MIUR.
14
Fig. 5: Screenshot of a run of Gazebo, ArduCopter and ns-3 with several UAVs
R EFERENCES [15] M. Quigley, K. Conley, B. P Gerkey, J. Faust, T. Foote, J. Leibs,
R. Wheeler, and A. Y Ng, “Ros: an open-source robot operating system,”
[1] Ardupilot open source autopilot. [Online]. Available: http://ardupilot.org/ 01 2009.
[2] Dronekit: Developer tools for drones. [Online]. Available: http: [16] S. A. Quintero, G. E. Collins, and J. P. Hespanha, “Flocking with
//python.dronekit.io fixed-wing uavs for distributed sensing: A stochastic optimal control
[3] “Locust: Autonomous, swarming uavs fly into the future,” approach,” in American Control Conference (ACC), 2013. IEEE, 2013,
http://www.onr.navy.mil/Media-Center/Press-Releases/2015/ pp. 2025–2031.
LOCUST-low-cost-UAV-swarm-ONR.aspx. [17] C. Reynolds, “Flocks, herds and schools: A distributed behavioral
[4] Mavlink micro air vehicle communication protocol. [Online]. Available: model,” in Proceedings of the 14th Annual Conference on Computer
http://mavlink.org/ Graphics and Interactive Techniques, ser. SIGGRAPH ’87. New York,
[5] M. D. Benedetti, F. D’Urso, F. Messina, G. Pappalardo, and C. Santoro, NY, USA: ACM, 1987, pp. 25–34.
“Uav-based aerial monitoring: A performance evaluation of a self- [18] G. F. Riley and T. R. Henderson, The ns-3 Network Simulator. Berlin,
organising flocking algorithm,” in 2015 10th International Conference Heidelberg: Springer Berlin Heidelberg, 2010, pp. 15–34.
on P2P, Parallel, Grid, Cloud and Internet Computing (3PGCIC), Nov [19] G. Vásárhelyi et al., “Outdoor flocking and formation flight with
2015, pp. 248–255. autonomous aerial robots,” in IEEE/RSJ International Conference on
[6] N. Bouraqadi and A. Doniec, “Flocking-based multi-robot exploration,” Intelligent Robots and Systems, ser. IROS ’14, Chicago, IL, USA, 2014,
in Proceedings of the 4th National Conference on Control Architectures pp. 3866–3873.
of Robots, Toulouse, France, 2009. [20] C. Virágh et al., “Flocking algorithm for autonomous flying robots,”
[7] G. Cai, J. Dias, and L. Seneviratne, “A survey of small-scale unmanned Bioinspiration & biomimetics, vol. 9, no. 2, p. 025012, 2014.
aerial vehicles: Recent advances and future development trends,” Un- [21] Y. Wei, M. B. Blake, and G. R. Madey, “An operation-time simulation
manned Systems, vol. 2, no. 02, pp. 175–199, 2014. framework for uav swarm configuration and mission planning,” Procedia
[8] G. Chmaj and H. Selvaraj, “Distributed processing applications for Computer Science, vol. 18, pp. 1949–1958, 2013.
uav/drones: a survey,” in Progress in Systems Engineering. Springer, [22] L. Weng, Q. Liu, M. Xia, and Y. Song, “Immune network-based swarm
2015, pp. 449–454. intelligence and its application to unmanned aerial vehicle (uav) swarm
[9] M. De Benedetti, F. D’Urso, G. Fortino, F. Messina, G. Pappalardo, and coordination,” Neurocomputing, vol. 125, pp. 134–141, 2014.
C. Santoro, “A fault-tolerant self-organizing flocking approach for uav
aerial survey,” J. Netw. Comput. Appl., vol. 96, no. C, pp. 14–30, Oct.
2017. [Online]. Available: https://doi.org/10.1016/j.jnca.2017.08.004
[10] M. De Benedetti, F. D’Urso, F. Messina, G. Pappalardo, and C. Santoro,
“3d simulation of unmanned aerial vehicles,” in XVIII Workshop ”Dagli
Oggetti agli Agenti”. CEUR-WS, 2017.
[11] J. Gonçalves and R. Henriques, “Uav photogrammetry for topographic
monitoring of coastal areas,” ISPRS Journal of Photogrammetry and
Remote Sensing, vol. 104, pp. 101–111, 2015.
[12] N. Koenig and A. Howard, “Design and use paradigms for Gazebo,
an open-source multi-robot simulator,” in International Conference on
Intelligent Robots and Systems, Sendai, Japan, 2004, pp. 2149–2154.
[13] L. Meier, D. Honegger, and M. Pollefeys, “PX4: A node-based mul-
tithreaded open source robotics framework for deeply embedded plat-
forms,” in Robotics and Automation (ICRA), 2015 IEEE International
Conference on, may 2015.
[14] P. Pace, G. Aloi, G. Caliciuri, and G. Fortino, “A mission-oriented
coordination framework for teams of mobile aerial and terrestrial smart
objects,” Mobile Networks and Applications, vol. 21, no. 4, pp. 708–725,
2016.
15