7 3D Simulation of Unmanned Aerial Vehicles Massimiliano De Benedetti, Fabio D’Urso, Fabrizio Messina, Giuseppe Pappalardo, Corrado Santoro University of Catania – Dept. of Mathematics and Computer Science Viale Andrea Doria, 6 — 95125 - Catania, ITALY {m.debenedetti, durso, messina, pappalardo, santoro}@dmi.unict.it Abstract—This paper describes the software architecture of a simulator must also be able to emulate the real physics of multi-agent simulator specifically designed to simulate Unmanned involved entities, handle collisions and use real-world mea- Aerial Vehicles (UAVs). The simulator has the aim of helping surement units, in order to let the developer design her/his a developer to design a multi-agent application in which a algorithms as close as possible to the reality. team or flock of UAVs are employed for a certain mission in an environment. The basic feature of the described tool is the The work presented in this paper belongs to the out- ability to simulate the real physics and dynamics of the entities lined context: the paper describes a software simulator for involved (UAVs), not only by emulating real reactions to forces multi-agent/UAV applications developed by authors and able and torques but also showing the UAVs in a 3D view. The to take into account the physical model and constraints of simulator provides the basic classes handling stabilization and the simulated entities, thus aiming at proving a scenario as control of a quadrotor UAV and let the developer to design her/his application by concentrating only on behavioral aspects realistic as possible. The tool is able to simulate the UAVs of the entities. As usual in multi-agent applications, in order to according to the behavior implemented by the developer; it handle interactions among UAVs, a set of classes is included to not only considers navigation and movement but includes also simulate a wireless communication system with a certain latency interaction and (wireless) communication, which are treated and packet loss probability. The simulator can be also executed emulating latencies and limited-range broadcasting. In order to without the visualization engine in order to run simulations (that evaluate the effectiveness of the developed algorithms, some could require a long time to complete) in headless servers. The performance indexes can be computed during simulation and paper also includes a case-study of a flocking application. exported to proper result files. I. I NTRODUCTION The simulator is developed in C++ and presents a modular structure able to offer an adequate flexibility to the developers; In the recent years, aerial monitoring and inspection of the core provides the basic classes defining the simulation geographic areas is often performed by means of Unmanned world and the abstract agents; here dynamics and collisions Aerial Vehicles (UAVs) [8] that are able to perform flight are handled by a real-time physics simulation library, which missions in a complete autonomy. Furthermore, the recent is Bullet [5]; the uav module provides the real UAVs, imple- appearance in the market of small multirotors (the so-called mented as quadrotor VTOL vehicles, with all the needed PID “drones”) along with the availability of high performance and controllers to perform in-flight stabilization and navigation; low-cost sensor and control boards, and high capacity batteries, 2D/3D visualization is also possible, and handled by exploiting make these unmanned aircrafts a very interesting solution for OpenGL [16], it is an optional feature than can be enabled of such kind of applications. the basis of developer desires: indeed graphic display can be disabled in order to run long-term batch simulations. UAVs present other problems that, in the current stage, do not permit them to be a complete replacement of manned The paper is structured as follows. Section II outlines aircrafts. The aspect of application testing is one of the most the background and discusses the related literature in the important: when designing the algorithms to drive one or more field. Section III present the main aspects of the simulator, UAV in performing a mission, a software bug could provoke a while Section IV describes a case-study. Section V reports our crash, thus causing the loss of the UAV and the data gathered; conclusions. in the same way, tuning the parameters of a e.g. a flocking algorithm [14], [9], [3], [7], [6] is quite hazardous when done II. R ELATED W ORK “in-flight”, since a wrong parameter could have dangerous consequences. The literature reports a large number of agent simulation environments but only few of them considers physical envi- For these reasons, the use of software simulators becomes ronments, physical constraints and provides 2D/3D display mandatory, and helps to verify the correctness, effectiveness capabilities. and performances of a navigation or collective behavior algo- rithm before make it run on-board. However, the key require- NetLogo [17] is one of the most popular toolkits for agent ments of a simulation approach or tool for UAV applications simulation; it is Java-based and is able to perform simulation of are not only related to the sole behavior aspect: many “real- a large number of agents. Agents live in a virtual environment world” issues, like the physics and dynamics of such kind of which is bi-dimensional and discretised into small square cells: objects (which are indeed characterized by a high inertia), can each cell can be occupied by a (static) environment element affect quite a lot the performances of algorithms, which, in or by a (mobile) agent. Ad an-hoc language is provided to turn, must consider the physical constraints of the UAVs and model the behavior of agents that can live, move and interact their ability to perform certain kind of maneuvers. A good in the 2D environment. Beside these simple environmental 8 Fig. 1. Simplified Class Diagram of the Simulator aspects, NetLogo is not able to simulate real-world physics made of joints. It offers the ability to drive joints with forces and dynamics of entities nor to provide a 3D display. or torques and integrates the definition of sensors to let the robot perceive the environment. Behavior programming can be Tridimensional capabilities are instead provided by done by means of external software interacting with Gazebo Breve [10], a 3D environment for the simulation of decen- by means of its API. A ROS [13] interface is also available. tralized systems and artificial life. It allows the designer to simulate continuous time and 3D space by including an inter- A tool similar to Gazebo is VREP [4], a commercial preted object-oriented language, an OpenGL display engine, as simulator also available in a free educational (and limited) well as the support for body physical simulation and collision license. From a certain point of view, it offers more features resolution. Agent behavior is implemented in Python [1] or than Gazebo: indeed VREP has a quite friendly user interface by another easy-to-use language named “steve”. Breve is no that can be used to both define robot structure—by means longer maintained since 2009, but the simulation environment of plug-and-play action for robot components—and program is still used, thus the author of Brave has partially restored the the behavior. Programming can be performed by means of the website1 . built-in Lua interpreter (which is however a little bit weird) or by using a C/Python API. PALAIS [15] is another 3D simulation tool for prototyp- ing, testing, visualization and evaluation of AI algorithms With respect to the solution reported in this paper, the for games; the designer can define the game by executing cited simulators are more general purpose, while our work arbitrary three-dimensional scenes and behaviors. A scripting focuses mainly on multi-rotor UAVs. Therefore, while, in our environment and a simple programming interface are also simulator, UAV models and all the UAV stabilization and provided for simulation control and data visualization. This navigation algorithms are ready to use, in the other tools not scripting interface is minimal and can be also accessed via only the UAV model must be designed, but also the control JavaScript. One of the interesting feature of PALAIS is the algorithms must be specifically written and tuned. Therefore, in ability of sharing a project in order to, e.g., collaborate with our solution the designed can only concentrate on “high-level” peers and build up showcases for algorithms and behaviors. behavior and interaction aspects rather than control issues. ARGoS [12] is an open source, modular, multi-robot sim- III. A RCHITECTURE OF THE S IMULATOR ulator to simulate real-time large heterogeneous swarms of robots. User can easily add custom features and allocate further The software simulator described in this paper is written computational resources where needed, moreover multiple in C++; its simplified class diagram is reported in Figure 1. it physics engines can be used and assigned to different parts is composed of three main modules: Core, Uav and Gui. of the environment. A. The Core Gazebo [11] is an open-source 3D robotic simulator, able to simulate the physics and dynamics of any mechanical structure The Core consists of the classes that represents the basic entities of the simulator. Mission is the main class that has 1 www.spiderland.org the responsibility of instantiating the simulator and starting the 9 overall system; indeed it reads a configuration file (in “.INI” and altitude. Both kind of agents are characterized by a certain format) that specifies all the parameters of the simulation, location in the physical space that resembles the geographical including the type of the agents employed, the presence of the coordinates of a real environment; this location (as well as all GUI, the size of the environment and other mission-specific the other physical parameters) are updated by the Bullet library items. This class creates, at start-up, an instance of class on the basis of the movements of the UAV body. Simulator, which is a container that refers all the Agents instantiated in the simulation and the World, which is the class handling the physics and dynamics of agents; thus class World relies on the Bullet library. Simulation execution is performed by World by using a discrete-time approach2 ; for each time interval, this class triggers the invocation of callback methods of the simulated entities as well as the updating of data on their dynamics (via the Bullet library); indeed, an event delegation model is adopted by the definition of two listeners, PreTickListener and PostTickListener that are triggered respectively before and after the update of the physics of the agents. The Core includes also the abstract classes Agent and PhysicalAgent that must be extended in order to im- plement the specific user-defined agent behavior. These two classes are designed to make a distinction between logical and physical agents: the latter category includes agents located at a precise point in the simulated space/environment and with the ability to move, while the former category refers to other not location-aware entities that however live in the environment Fig. 2. The graphical model of the UAV implemented in the simulator and needs to be simulated. Each agent is uniquely identified by an id (class AgentIdType) that is indeed an integer. The UAV modeled is a classical X-shaped quad-rotor whose graphical model is depicted in Figure 2. To simulate Interaction among agents is also handled in the Core. Since it, the classes of the uav module implement all the control the aim is the simulation of physical entities, the communica- algorithms needed to perform in-flight stabilization and navi- tion is modeled by simulating a wireless transmission channel gation. Motors are modeled by applying a certain drag force with a configurable latency and loss probability. Agents have to the points of the body where motors themselves are placed; the capabilities to communicate with their peers by means a such drag forces are determined on the basis of the outputs short distance communication, and with a possible base station of the control algorithms and using a simplified mathematical through a long-range system; both kind of channels support model for motors and propellers. unicast and broadcast communication. These kind of commu- nication are handled by classes MessageTransceiver and Different control modes are implemented. In manual mode MessageDispatcher. The former is a class associated to (Figure 3), the input throttle, pitch, roll and yaw values are each agent and basically implements the message reception directly sent to the mixer that calculates the power to apply queue. The latter is a singleton that has the objective of to the motors. In attitude mode (Figure 4), pitch and roll collecting sent messages thus delivering them to receiving are controlled by means of two PID4 controllers that compare transceivers. A message is characterized by the ids of sender target (desired) angle values with the real ones returned by the and receiving agents (or only sender, is the message is sent in Bullet physical engine; these PIDs are thus used to perform broadcast) and the payload which can be any C++ type3 . in-flight stabilization. B. Unmanned Aerial Vehicles The objective of the simulator is to study the behavior of UAV-based applications, therefore the uav module provides all the necessary classes to simulate the behavior and dynamics of UAVs. Two kind of UAVs are simulated, which differ on the basis of the commands that can handle. Class UavAgent implements a UAV that can be externally controlled through the imposition of certain Euler angles to the airframe—i.e. roll, pitch and yaw—and a certain amount of power for propulsion (thrust). On the other hand, class AutonomousUavAgent Fig. 3. Manual mode can be controlled by directly imposing target horizontal speeds vx and vy of the UAV (relative to the body frame), heading When GroundSpeedAndVertSpeed mode is selected (Fig- 2 In the implementation, time tick is fixed to 2.5 ms, which is the sampling ure 5), targets are given in terms of speeds relative to the body time usually employed in control loops of flight algorithms for multi-rotors. frame vx , vy and vz ; such speeds are compared with the actual 3 Indeed, since the simulator uses the Qt library, the payload is implemented using a QVariant type. 4 Proportional-Integral-Derivative 10 ones (determined by Bullet) and the differences are sent to collisions or be configured to occur in a UAV with a certain speed PIDs which, in turn, drive the PIDs on Euler angles. probability; the latter feature is used to simulate problems in hardware (e.g. propeller breaking, battery drain, etc.) or in software (e.g. bugs in flight control stack). In both cases, UAVs involved in the fault are killed and removed from the simulation. Collisions are handled at each simulation step by retrieving, from Bullet engine, information about all intersec- tions among rigid bodies and then killing the relevant agents. In order to perform tests, the GUI also allows the user to kill an agent manually. Fig. 4. Attitude mode Fig. 5. GroundSpeedAndVertSpeed mode Fig. 8. A screenshot of the Simulator In GroundSpeedAndAltitude mode, an altitude PID is included to the previous mode to control the target height of C. The Graphical User Interface the UAV (Figure 6). Finally, with GroundSpeedAltitudeAndHeading, control The Gui module provides the Graphical User Interface with on target heading is included with respect to the previous mode capabilities to visualize the physical environment, the agents, (Figure 7). and to inspect their state. A screenshot is shown in Figure 8. In order to understand the real behavior of UAVs by looking at its flight, several windows can be opened with different point of views of the physical scenario: (i) the overall scene in 3D; (ii) a 2D display from the top; (iii) a 3D subjective view with respect to a specific agent. In all the windows, the view camera can be moved by using the mouse. Physical and graphical models are loaded from geometry definition files (OBJ) that can be generated by 3D graphic modelers, such as Blender [2]. From the software point of view, the Gui is composed of two basic classes. WorldRenderer has the task of Fig. 6. GroundSpeedAndAltitude mode performing the display of the UAVs and the background and exploits the OpenGL library. MissionGui, on the other hand, provides the necessary code to display the list of agents and interact with the simulation (starting/stopping the simulation, inspecting the agents, opening new views, killing agents); it is based on the QT5 library. As the architecture of Figure 1 shows, the graphical inter- face is separated from the simulation engine: this is needed to perform batch simulation on headless high-performances servers and then gather results. Fig. 7. GroundSpeedAltitudeAndHeading mode IV. C ASE S TUDY: S IMULATION OF A UAV F LOCKING During the development of a certain specific behavior A PPLICATION algorithm, it has been helpful to take a manual control of In this section we describe the case-study of a flocking agents. For this reason, the simulator includes also a graphical application where a set of UAVs are employed to perform virtual joystick as well as the interface to a real USB joystick. aerial inspection of a specific zone of terrain. The aim is to Classes of the uav module also implement fault detection. monitor an area using a set of UAVs each equipped with a Faults can occur due to UAV-to-UAV and UAV-to-terrain camera sensor able to take aerial pictures. The idea is to have 11 a collaborating application so that, should an UAV fail, the [AreasToExplore] other ones can identify the fault and try to recover data lost size=1 ; Rectangle count by performing a re-scouting of the areas relevant to the faulty 1\areaId=1 agent. To this aim, UAVs organise themselves in a flock that 1\rectCenter=@Point(50 50) scouts the area on the basis of a leader-followers approach. 1\rectSize=@Size(80 100) 1\rectHeading=60 The algorithm used is fully described and evaluated in [7], [6], so we concentrate here on simulation aspects rather than the flocking approach itself. V. C ONCLUSIONS AND FUTURE WORK Implementing the simulation requires to write some classes that extend the basic classes of the simulator, This paper has described the architecture of multi-agent i.e. AutonomousUavAgent, Mission and MissionGui. simulator specifically designed for unmanned aerial vehicles. In our case, the FullAgent class extends the first one The tool described is able to simulate the physics and dynamics of the previous three and implements the behaviour of the of several quadrotor UAVs engaged in a cooperative mission. flocking and area coverage algorithms. The Mission class is The simulator is written in C++ and the designer can use it instead extended in order to provide mission-specific code: the and implement the desired behavior by simply subclassing extended class will have the task of creating the agents (by the AutonomousUavAgent. Since all aspects related to reading the configuration file described below) and start the navigation, stabilization and control of the UAV are already simulation. Finally, the mission-specific MissionGui needs provided by the basic classes of the simulator, the designer can to be written in order to include the basic code for agent concentrate only on the “high-level” behavior of the agents and rendering and other GUI aspects, if needed. All of these classes their mutual interaction. A 3D display engine is also provided, (together with the other code needed for the simulation) are in order to visualize the UAVs flying in the environment then compiled into a shared-object in order to take advantage and thus make it possible to verify, at sight, the real agent’s of the plug-in feature of the simulator: the shared-object is behavior. Indeed, the display engine can be disabled in order to loaded by the simulator at run-time on the basis of a certain run the simulation in a headless server and then gather output field present in the configuration file; in this way it is easy to results. guarantee the coexistence of different simulative algorithms, As future work, we plan to include a scripting language along with the ability to select at runtime the desired mission in order to let developers to implement their own simulation approach. by means of a simple approach rather than being involved in Simulation parameters are specified by means of text files writing and compiling C++ source code. (INI format). Listing 1 shows a part of the configuration used in the flocking application. The INI file is composed of three VI. ACKNOWLEDGEMENTS sections: (i) global parameters (section [Global]); (ii) list of agents to instantiate at the beginning of the simulation (sec- This work is partially supported by projects PRISMA tion [Uavagents]); and (iii) list of areas to explore, along PON04a2 A/F and CLARA funded by the Italian Ministry of with related coordinates (section [AreasToExplore]). University, and FIR-2014 funded by the University of Catania. In the first section, parameter missionType represents the model to adopt for the UAV and actually represents the R EFERENCES name of the dynamic library that contains the customized [1] “The python language reference manual,” 2016, code of a specific mission to run; parameter autoStart https://docs.python.org/3/reference/index.html. instead affects non-batch simulations, on which the GUI is [2] Blender Foundation, “Blender,” https://www.blender.org. activated. The second section ([Uavagents]) specifies the [3] N. Bouraqadi and A. Doniec, “Flocking-based multi-robot exploration,” number of agents and the initial position and heading, as well in Proceedings of the 4th National Conference on Control Architectures as the identifier, of each of them. Finally, the third section of Robots, Toulouse, France, 2009. specifies the areas to explore, their location, and the parameter [4] Coppelia Robotics, “V-rep - virtual robot experimentation platform,” http://www.coppeliarobotics.com/. rectHeading, which is the direction agents will follow while [5] E. Coumans et al., “Bullet physics library,” Open source: bullet- exploring. physics.org, 2013. Listing 1. Sample configuration [6] M. De Benedetti, F. D’Urso, F. Messina, G. Pappalardo, and C. Santoro, [Global] “Uav-based aerial monitoring: A performance evaluation of a self- organising flocking algorithm,” in 2015 10th International Conference missionType=uav/FullAgentWithBaseStation on P2P, Parallel, Grid, Cloud and Internet Computing (3PGCIC). autoStart=false ; start simulation automatically IEEE, 2015, pp. 248–255. [7] M. De Benedetti, F. DUrso, F. Messina, G. Pappalardo, and C. Santoro, [UavAgents] “Self-organising uavs for wide area fault-tolerant aerial monitoring,” in size=10 ; Total number of UAVs XVI Workshop ”Dagli Oggetti agli Agenti”. CEUR-WS, 2015. 1\agentId=1; [8] S. Gupte, P. I. T. Mohandas, and J. M. Conrad, “A survey of quadrotor 1\initialPos=@Point(0 0) unmanned aerial vehicles,” in Southeastcon, 2012 Proceedings of IEEE. 1\initialHeading=0 IEEE, 2012, pp. 1–6. 2\agentId=2 [9] Gbor Vsrhelyi, Csaba Virgh, Gerg Somorjai, Norbert Tarcai, Tams 2\initialPos=@Point(2 2) Szrnyi, Tams Nepusz and Tams Vicsek, “Outdoor flocking and forma- 2\initialHeading=0 tion flight with autonomous aerial robots,” in Submitted for publication ; ... to the IEEE/RSJ International Conference on Intelligent Robots and Systems, ser. IROS ’14, Chicago, IL, USA, 2014. 12 [10] J. Klein, “Breve: a 3d environment for the simulation of decentralized systems and artificial life,” in Proceedings of the eighth international conference on Artificial life, 2003, pp. 329–334. [11] Open Source Robotic Foundation, “Gazebo simulator,” http://www. gazebosim.org. [12] C. Pinciroli, V. Trianni, R. O’Grady, G. Pini, A. Brutschy, M. Brambilla, N. Mathews, E. Ferrante, G. Di Caro, F. Ducatelle et al., “Argos: a modular, multi-engine simulator for heterogeneous swarm robotics,” in 2011 IEEE/RSJ International Conference on Intelligent Robots and Systems. IEEE, 2011, pp. 5027–5034. [13] 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,” in ICRA Workshop on Open Source Software, 2009. [14] C. Reynolds, “Flocks, herds and schools: A distributed behavioral model,” in Proceedings of the 14th Annual Conference on Computer Graphics and Interactive Techniques, ser. SIGGRAPH ’87. New York, NY, USA: ACM, 1987, pp. 25–34. [15] P. Schwab and H. Hlavacs, “Palais: A 3d simulation environment for artificial intelligence in games,” in Proceedings of the AISB Convention, 2015. [16] D. Shreiner, G. Sellers, J. M. Kessenich, and B. Licea-Kane, OpenGL programming guide: The Official guide to learning OpenGL, version 4.3. Addison-Wesley, 2013. [17] S. Tisue and U. Wilensky, “Netlogo: Design and implementation of a multi-agent modeling environment,” in Proceedings of agent, vol. 2004, 2004, pp. 7–9.