Johannes Lächele, Development of a Real-Time Simulation Environment

Eberhard Karls Universität Tübingen Fakultät für Informations- und Kognitionswissenschaften Wilhelm-Schickard-Institut für Informatik Max-Planck-Institut für biologische Kybernetik Abteilung für Wahrnehmung, Kognition und Handlung

Diploma Thesis Development of a Real-Time Simulation Environment for multiple Robot Systems Johannes Lächele

11. März 2012

Supervisor

Dr. Paolo Robuﬀo-Giordano Computer Science Engineering Human Perception, Cognition and Action Max Planck Institute for Biological Cybernetics

Referees Prof. Dr. Wolfgang Rosenstiel Prof. Dr. Heinrich H. Bülthoﬀ Computer Science Human Perception, Cognition and Action Wilhelm-Schickard-Institut für Informatik Max Planck Institute for Biological Cybernetics Universität Tübingen Lächele, Johannes: Development of a Real-Time Simulation Environment for multiple Robot Systems Diploma Thesis Computer Science Eberhard Karls Universität Tübingen Thesis period: Apr 2011 - Oct 2011 Abstract

One research interest of the Human Perception, Cognition and Action group at the Max Planck Institute for Biological Cybernetics is the human-in-the-loop bilateral control of a swarm of robots. The human operator may be presented with multiple feedback cues, e.g., visual, vestibular, haptic, auditive or even olfactory stimuli. The goal is to find a general methodology on how to best control multiple robots in a remote environment. The swarm of robots consists of several quadcopters designed and distributed by HiSystems GmbH [12] under the name MikroKopter. Software frameworks simulating a virtual environment are indispensable for this research work. Being able to access all information of an experiment setup is important to gain insights that may prove difficult or impossible to gain otherwise. Furthermore, hardware-in-the-loop and human-in-the-loop scenarios depend on software that is capable of performing calculations in real-time. A process running in simulation must proceed with the same pace as the process in reality. Software suites capable of simulating multiple robots already exist and are widely used in research. Nonetheless, the author was unable to find software that meets all requirements, i.e., real-time execution, realistic, exchangeable visual and physical representation, extendable software architecture and full control over inherent information of all simulated robots. In this thesis a novel simulation environment is presented. SwarmSimX (SSX) is capable of simulating both the visual and physical properties of robots acting in a user-defined environment in real-time. The software architecture allows for an easy exchange of the underlying libraries used for simulation. Shared modules may be loaded at runtime, extending the simulation with new functionality, without the need of recompiling the whole simulation environment. Finally, two experiments have been conducted proving the usefulness of the simulation environment. The first experiment determines how many robots can be added to the scene before computation reaches the limit where the machine is still capable of ensuring RT execution. With timesteps of 0.001 s, 0.002 s, 0.003 s, 0.004 s, SwarmSimX can simulate 10, 13, 14, 14 quadcopters respectively at the same time. The second experiment compares the flight behaviour of a simulated and a real quadcopter. First a real quadcopter tracks two different trajectories, each given by a human operator. The quadcopter was controlled using an external control

i program. The desired trajectory of the human operator was recorded and played back using the same control program. Instead of controlling the real quadcopter, the virtual quadcopter was controlled. For the moderate condition the mean of the position error between the real and the virtual quadcopter is 0.1189 m with a standard deviation of 0.6461 m. For the dynamic condition the mean error is 0.1897 m with a standard deviation of 0.9386 m.

ii Zusammenfassung

Eines der Forschungsziele der Arbeitsgruppe "Human Perception, Cognition and Action" am Max-Planck-Institut für biologische Kybernetik ist die Untersuchung der beidseitige Kontrolle eines Schwarms von Robotern. Dabei steht die mensch- liche Interaktion im Vordergrund der Forschung. Der Pilot des Schwarms kann dabei unter dem Einfluss vieler verschiedener Sinneseindrücke stehen, diese kön- nen Aufschluss über die Situation des Schwarms geben. Zu diesen Einflüssen gehören visuelle, das Vestibularsystem betreffende, haptische, auditive oder so- gar olfaktorische Reize. Das Ziel ist eine allgemeine Methodik zu finden, mit der sich mehrere Roboter in einer entfernten Umgebung am besten steuern las- sen. Der eingesetzte Roboterschwarm besteht aus mehreren Quadrocoptern, die von der Firma HiSystems GmbH [12] unter dem Namen MikroKopter vertrieben werden. Eine Software zu haben, mit deren Hilfe es möglich ist eine virtuelle Umge- bung zu simulieren, ist unverzichtbar für diese Forschungsarbeit. Die Möglich- keit, Zugriff auf alle Informationen eines Experiments zu haben ist wichtig um Erkenntnisse zu erhalten, die ohne diese Kontrolle nur schwer oder unmöglich zu bekommen wären. Darüber hinaus erfordern Szenarios, in denen Menschen und Geräte mit der virtuellen Umgebung interagieren, Software die in Echtzeit aus- geführt werden kann. Das bedeutet, dass ein simulierter Ablauf mit der gleichen Geschwindigkeit voranschreiten muss wie derselbe Ablauf in der Realität. Softwarepackete mit der Möglichkeit mehrere Roboter gleichzeitig zu simulieren existieren bereits und werden in der Forschung auch weithin benutzt. Aller- dings war es dem Autor nicht möglich ein Softwarepacket zu finden, welches alle Anforderungen erfüllt. Zu diesen gehören die Berechnung in Echtzeit, realisti- sche, austauschbare visuelle und physikalische Darstellung, Erweiterbarkeit der vorhandenen Architektur und voller Zugriff auf inhärente Zustände der simulierten Roboter. Im Rahmen dieser Diplomarbeit wurde eine neue Simulationsumgebung er- stellt: SwarmSimX (SSX). SwarmSimX kann die visuellen und physikalischen Eigenschaften von Robotern in Echtzeit simulieren, die in einer benutzerdefinier- ten Umgebung agieren. Die Softwarearchitektur erlaubt den einfachen Austausch von Softwarebibliotheken, die der Simulation zugrunde liegen. Zur Laufzeit der Simulation können dynamische Module geladen werden, die den Funktionsum- fang der Simulation erweitern. Ein erneutes kompilieren der gesamten Simulati- onsumgebung ist dabei nicht nötig. Schließlich wurden zwei Experimente durchgeführt, die den Nutzen der Simula- tionsumgebung zeigen. Das erste Experiment bestimmt die Anzahl der Roboter, die zur Umgebung hinzugefügt werden können, bevor die Rechenkapazität nicht mehr ausreicht um den Echtzeitanspruch zu gewährleisten. Mit Zeitschritten von 0.001 s, 0.002 s, 0.003 s, 0.004 s kann SwarmSimX 10, 13, 14, 14 Quadrocopter gleichzeitig simulieren.

iii Das zweite Experiment vergleicht das Flugverhalten eines simulierten mit dem eines echten Quadrocopters. Zuerst verfolgt ein realer Quadrocopter zwei unter- schiedliche Trajektorien, die beide von einem Piloten vorgegeben wurden. Gesteu- ert wurde der Quadrocopter dabei von einem externen Kontrollprogramm. Die gewünschten Trajektorien des Piloten wurden danach als eingabe für das gleiche Kontrollprogramm benutzt. Allerdings wurde in diesem Fall ein virtueller Qua- drocopter statt des realen Quadrocopters gesteuert. Der mittlere Positionsfehler zwischen echtem und virtuellen Quadcopter beträgt im ersten Fall 0.1189 m mit einer Standardabweichung von 0.6461 m. Im zweiten Fall beträgt der mittlere Fehler 0.1897 m mit einer Standardabweichung von 0.9386 m.

iv Acknowledgements

First of all, I want to thank my supervisor, Dr. Paolo Robuffo-Giordano, for his inestimable advice and support during the course of this project. His confidence in me and the freedom he granted me during this work are things I do not take for granted. Furthermore, I am most grateful to Prof. Dr. Heinrich H. Bülthoff for giving me the opportunity to work on this project at the Max Planck Institute for Biological Cybernetics and Prof. Dr. Wolfgang Rosenstiel for the support on the part of the University of Tübingen. I also want to thank a lot of other people: Antonio Franchi for his help designing the comparison experiment and numerous useful discussions, Joachim Tesch for his advice and support to help me understand rendering technologies, Volker Grabe for his help with Ogre3D, Markus Ryll for the excellent CAD model of the quadcopter, Trevor Dodds for proofreading and helping me master the en- glish language a bit more, Walter Heinz and Mirko Thiesen for providing me with excellent hardware and software support and for being great administra- tors, Martin Riedel for extending the functionality of SwarmSimX with ROS, Marco Cognetti for improving the virtual IMU, Dagmar Maier for the countless times she provided me with help, advice and general support. Furthermore, I want to thank all the colleagues at the Max Planck Institute in general and the Cyberneum in particular for having been such nice coworkers and for all their support: Hyoung Il Son, Carlo Masone, Riccardo Spica, Michael Kerger, Harald Teufel, Ibrahim Lakhdar, Betty Mohler-Tesch, Tobias Meilinger, Rainer Boss, Stephan Streuber, Ivelina Alexandrova, Martin Dobricki, Sandra Holzer, Markus Leyrer, Sally Linkenauger, Christian Neth, Ekaterina Volkova, Paolina Teneva, Sarah Mieskes, Lewis Chuang, Reinhard Feiler, Karl Beykirch, Florian Soyka, Martin Breidt, Frank Drop, Frank Nieuwenhuizen, Alessandro Nesti. I would like to thank all my friends for the discussions, advice and the opportunity to have so many good times with you. I want to thank my partner Maria for her support, confidence, patience, unconditional love and the strength she gave me. Finally and most importantly, I want to thank my parents and my brothers, for the unconditional support and love I have been receiving all my live.

Contents

1 Introduction1

2 Background Information3 2.1 Simulation Environments...... 3 2.2 Existing software...... 4 2.3 Render engines...... 6 2.3.1 Technology review...... 7 2.3.2 Irrlicht...... 7 2.3.3 OpenSceneGraph...... 7 2.3.4 Ogre3D...... 8 2.4 Physics engines...... 9 2.5 Real-Time and Linux...... 10 2.5.1 Measuring time and triggering events...... 11 2.5.2 Stepping the simulation...... 11

3 Software Architecture 15 3.1 Software requirements...... 16 3.2 Overview...... 17 3.3 Specifying object interfaces and interaction...... 19 3.4 Descriptor abstraction...... 20 3.5 RenderEngine abstraction...... 21 3.5.1 RenderNode...... 22 3.6 PhysicEngine abstraction...... 24 3.6.1 PhysicNode...... 25 3.7 Architect...... 25 3.7.1 Artifact...... 26 3.8 Extending the simulation...... 27 3.8.1 The dlopen API...... 27 3.8.2 Driver...... 28 3.8.3 Sensor...... 29

4 Implementation of a quadcopter for SwarmSimX 33 4.1 Motivation...... 33 4.2 Background information...... 34 4.2.1 Notation...... 34

vii 4.2.2 Multi-Agent-Lab...... 35 4.2.3 VICON...... 35 4.3 Visual representation...... 36 4.4 Physical properties...... 38 4.5 Implementing the Driver...... 40 4.6 Implementing a Sensor: virtual IMU...... 42 4.6.1 Noise...... 42 4.6.2 Linear acceleration...... 43 4.6.3 Angular velocity...... 43 4.6.4 Implementation...... 43 4.7 Building the scene...... 44

5 Experiments 45 5.1 Stress testing the simulation...... 46 5.1.1 Results...... 46 5.2 Comparing virtual and real quadcopters...... 47 5.2.1 Results...... 48

6 Summary 53 6.1 Conclusion...... 53 6.2 Discussion...... 53 6.2.1 Descriptor...... 53 6.2.2 RenderEngine...... 54 6.2.3 PhysicEngine...... 54 6.2.4 Architect...... 55 6.2.5 Experiments...... 55 6.3 Outlook...... 56

7 Bibliography 59

viii List of Abbreviations

UAV Unmanned Arial Vehicle IMU Inertial Measurement Unit UDP User Datagram Protocol POSIX Portable Operating System Interface for Unix SSX SwarmSimX RT Real-Time ODE Open Dynamics Engine XML Extensible Markup Language SLAM Simultaneous Localization And Mapping ACE Adaptive Communication Environment MPI Max-Planck-Institute PC Personal Computer API Application Programming Interface CAD Computer Aided Design RAM Random Access Memory CPU Central Processing Unit GPU Graphics Processing Unit MVC Model-View-Controller

1 Introduction

Advances in robotics technology are becoming more and more widespread in our society. The automation of production processes might have been the starting point in history that led to faster and cheaper production of goods. The automation of production may have started with robots replacing human constructors at constructing belts in the car industry. This idea spread easily to other con- struction areas, triggering the development of ever more sophisticated, versatile and autonomous robots. The advances in mobile robotics are gaining more and more ground in society. Automatic parking systems are a perfect example for this. To increase the safety of the driver and others, breaking systems slow down the car without the assis- tance of the driver. Another example is presented by Fang et al. [10]. On-board cameras can detect road signs and alert the driver in case of wrong behaviour, e.g., exceeding maximum speed limits . All of those systems have in common that they heavily rely on computer systems. The exponentially growing processing power of computers allows us to perform fast and complex computations. These are usually fast enough to support controlling robotic systems in real-time. Meaning the time for calculation is small enough to be able to react on-line to the knowledge of the world acquired from the available sensors. However, powerful computers are also extremely useful during design and development phases. For example, the processing power can be used to simulate the behavior of specific machines under a variety of conditions, in particular those resulting from the interaction of the machine, i.e. robot, with its environment. These conditions result from the interaction of the system being analyzed and the environment. This possibility makes it easier to actually deploy autonomous systems in the real world, since their behavior can be analyzed in depth before- hand. This is the purpose of simulation environments in a robotics context: a software suite that allows us to simulate the interaction of a robot with its environment, including also other robots. Depending on the robot, such simulation software needs to fulfill different requirements. Software meant for developing new robotic structures are more focused on the accuracy of the results. An increase of the computation time is of secondary im- portance w.r.t. a corresponding increase of the simulation accuracy. On the other hand, simulating hardware-in-the-loop or human-in-the-loop interactions needs fast and deterministic (real-time) calculations. The reason for this is mainly

1 because the real-world counterpart of the simulation (the external hardware or human user) operates in the "real-world", and therefore it needs to be interfaced with a simulation running at the same pace. In this thesis, I will describe the development of a simulation environment tai- lored for multi-robot simulations. The main focus will be on a deterministic real- time behaviour that is mandatory for hardware-in-the-loop or human-in-the-loop scenarios. Maintaining deterministic behaviour is hard to achieve, especially in a multi-threaded software design. Instead, in this Thesis deterministic behaviour is understood to have a certain slack to it and with the goal to minimize the variance. An extensible framework allows for replacement of the underlying software libraries needed for visualisation and physics calculations. The simulation environment is not limited to a speciﬁc group of robots, e.g. ground, stationary, ﬂying robots and may be extended with dynamically loadable modules representing the program logic of any robot.

2 2 Background Information

2.1 Simulation Environments

In the process of developing new systems it is important to test how this system behaves under different conditions. Here a system has several meanings. It could be a prototype of an new vehicle like a car or a plane. It could also be a single rotary joint that may be a part of a bigger system. It could also be of a more abstract kind. A novel algorithm or a specific piece of software also needs proper testing before being used. For testing new systems a framework or testbed is needed where the inputs and disturbance on the system can be controlled. From possible scenarios in the real world a set of different influences is derived and applied to the system. Given this input the tested system changes inner states, e.g., velocity or orientation. With the possibility to access those states from the framework, correct behaviour can be evaluated and possible errors detected. This information helps understanding whether the system behaves correctly or reaches states that could lead to unwanted behaviours in the real world. This definition of a simulation framework can be further expanded to allow for multiple systems to be tested at the same time. Now not only the inherent states are important to simulate, but also the interaction between those systems. I will denote such a framework as Simulation environment if it is capable of simulating several systems, including their interaction, at the same time. In the case of simulating multiple robots interacting in an environment we need a set of tools that allow for a realistic representation. A simulation environment can be divided into three main parts. First the visual parts, e.g., all parts visible to the experimenter, the robots, etc. This can be a gray cube representing an obstacle, the body of a robot or lights within the scene. Independent from the visual representation we also need a physical representation for a realistic simulation. This representation is defined by the mass, inertia, size, etc. At simulation time those values are used to calculate the movements based on newton dynamics. The visual and the physical representation need to be defined independently from each other. Some objects only need one type of representation, since the other is not needed to fulfill the task of the object. A light in a room only needs a visual representation, i.e., the definition of the light itself: brightness, color, etc. A physical representation is not necessary, as physical properties like mass are

3 not needed to illuminate a scene. Adding those properties would unnecessarily increase the CPU load. The last part is the time and inherent to that the repeatability or determinism. The timing of the steps of the simulation needs to be very precise. In particular, time passed within the simulation needs to be synchronized with time passed in reality. This is especially important with hardware-in-the-loop scenarios. In the following chapters I will elaborate those diﬀerent systems and discuss the pros and cons of each of the solutions.

2.2 Existing software

Using a simulation environment to develop or test one or multiple robots is not a new idea. Software that is capable of simulation multiple robots has already been developed and is widely used in research, industry or schools. The focus of the simulation environment may be on very different aspects of simulating single or multiple robots. Also the extent of the functionality provided differs from software to software. Most simulation environments are software frameworks that provide a complete set of tools for developing new algorithms, hardware layouts of single robots, etc. This packed simulation environment has the main advantage that it can be used right away. After the initial learning phase no extra software is needed to start simulating a custom environment. In addition it also ensures the exchangeability between different organizations, like research departments, schools, etc. But this may also be a disadvantage. Consider the case where some part of the simulation software starts becoming obsolete, as new developments provide better solutions for the same problem. An example could be the technique used to render the scene. Over the past few years the development proved to be very fast with changes released almost on a monthly basis. With a packed simulation environment the user is locked with the old technique and no possibility to change this. To the authors knowledge the most widespread and established packed simulation environments are Webots [19], USARSim [6] and Gazebo [15]. Webots and Gazebo rely on the wellknown ODE library for physics simulation. USARSim utilizes the Unreal Engine [9] to calculate the physics simulation. A complete review of the state-of-the-art in robot simulation is beyond the scope of this thesis. I refer to the review of presented by Kramer and Scheutz [16], which also includes a scheme on how to assess the quality of a simulation environment. Although all three provide a nice interface to access the information of the physical simulation, the user is stuck in using this particular software. A fairly new approach to solve this issue was presented by Pinciroli et al. [24]. The completely modular software ARGoS allows for loading several, different physics

4 engines at the same time. Depending on the use case of the simulation the best fitting engine may then be used. This approach has some similarities to the architecture of SwarmSimX. Creating, Switching and deleting instances of different physics engines at runtime calls for a good interface definition as the basis for this architecture. Also the decomposition of a virtual robot in controllable, embodied, etc. entities follows the same architectural design idea of SwarmSimX which led to the concepts of Artifacts, Drivers and Sensors. The same is true for the visualization of the world. Different engines, i.e., libraries, may be utilized by implementing an abstract interface representing the render engine. ARGoS is designed for scalability and extensibility, capable of simulating thousands of robots simultaneously. It is not designed to be used in a human-in-the- loop scenario. The possible applications of ARGoS presented in Pinciroli et al. [24] are based solely on robot-robot-interaction of heterogeneous swarm robotics. Real-Time characteristics are therefore not considered in the design of ARGoS. In contrast to a packed solution a modular simulation environment allows for replacing certain parts of the simulation. Those parts could be the rendering or the core that calculates the physics. Modular simulation environments can have a very broad range of functionality. MATLAB R and Simulink R both developed by The MathWorks, Inc.[28, 29] provide a very vast and general mathmatical tool set that can be used to implement any kind of simulation environment. The drawback here is that everything needs to be implemented by hand. Simulat- ing the physics involves creating software tool set first that allows for creating objects with their physical properties. With this solution the time used to create objects, environments, etc. counteracts the freedom gained from this very general approach. An alternative that has been explored in this thesis is the use of game engines. Over the recent years game engines evolved into highly sophisticated software, capable of rendering a multitude of objects and characters at the same time. Game engines themselves also differ in the features already included. Software like the Unreal Engine, Unity [31] and the cryENGINE [8] provide a packed solution for creating games. Although game engines are updated quite regularly, this limits the freedom of the user to choose the software parts of the simulation. Instead a semi modular approach has been chosen for SwarmSimX. Swarm- SimX provides all the libraries to run a simulation setup with no additional implementation needed. The work implementing a custom robot can start right after installation. However, each of the main features, e.g., visual and physical representation, is implemented utilizing third party software libraries. Encapsu- lating each of these features ensures the modularity. This way some or all of the features can be replaced by a custom implementation. In Craighead et al. [7] several different approaches for simulation have been presented and discussed. Their conclusion is that using a modular approach should be favored in research as the requirements to the environment changes fairly often. A setup built for an experiment may not be applicable for the

5 succeeding experiment. One important additional topic that needs to be addressed is the possibility to access the source code of the project. Having access to the source code may be important. It is necessary, if the user wishes to extend the current software by special features or wishes to replace a module, like the rendering of the simulation. Relying on open source software only is considered as optional for this project. The main libraries used for simulating the environment are replaceable. Users that wish to use open source only software can therefore exchange the corresponding parts. In the end the decision which software to use boils down to the dilemma whether to buy software that needs less time to get started, or to use software that has no initial cost, but needs time (and therefore money) until it is pro- ductive. In this Thesis a middle way is presented that does not try to create a simulation environment from scratch. Instead several already available software libraries that provide some of the functionality are combined to build the whole environment. The problem of extensibility and exchangeability is addressed by providing a general interface for each of the subsystems. This can be used by the user to provide custom implementations.

2.3 Render engines

In a simulation environment, many different objects need to be displayed at once. Software that manages the display of different objects is called render engine. Objects that can be rendered in a scene can be divided into a limited number of classes. First of all we need to be able to create a camera that shows how the current scene looks like. This camera also needs to be controlled by the experimenter, so he/she can easily look around within the environment. Additional cameras can also be added to the environment, e.g., to simulate an on-board camera of a robot. The next class contains all objects that have a visual representation. Independent of the engine used, objects of this class are often defined by a mesh, color, texture, scale, etc. The last class contains the lights of the environment. Lights have many different attributes like type, color, brightness or opening angle, but also render specific attributes like whether or not the light omitted casts shadows. Combining objects together to form an environment is called creating the scene. Choosing a Render Engine has been an important step in this project. One goal is to support software that can be accessed with no cost, preferably the source code needs to be accessible. Another goal is to be able to use the rendering capabilities of the engine easily. The following subsections discuss different technologies.

6 2.3.1 Technology review For this thesis three diﬀerent rendering libraries have been considered. Those are Ogre3D [30], Irrlicht [14], OpenSceneGraph [23] Only render engines that can be obtained free of charge have been considered. This is mandatory as SSX will be available for free. All of the above libraries are open source and can be downloaded from their respective websites. The design of SwarmSimX itself allows it to run on diﬀerent operating systems. All three render engines can be compiled for the three most common systems, Microsoft Windows R , Mac OS and GNU/Linux. A lot of render engines only support the Microsoft DirectX R API which prohibits the use of this library on Mac OS and Linux systems and therefore prohibiting the use of SSX on these operating systems. All mentioned render engines provide support for DirectX R and OpenGL.

2.3.2 Irrlicht Irrlicht is a real-time 3D rendering engine that is designed to be used on multiple operating systems. It provides an easy-to-use high level API in C++ for creating 2D as well as 3D applications. The main features that can useful for the simulation environment presented in this work are as follows. Rendering can be done using DirectX R or OpenGL. When using the Irrlicht engine the user can decide which API to use. A layer of abstraction ensures that the rest of the engine is independent from the lower level API used. When none of the above low level APIs are available, a software rendering library is available as part of the Irrlicht render engine. From a visualization point of view the Irrlicht engine has all the state-of-the-art features available. Those include dynamic shadows, particle systems, character animation, indoor and outdoor technology. Special eﬀects also include sphere mapping, bump mapping, animated water, dynamic lights, particle systems and many more. Often, Irrlicht is used for developing games. However, Ogre3D is supported by a larger community than Irrlicht. As both engines provide a similar feature pack, this fact leads to the decision to use Ogre3D instead.

2.3.3 OpenSceneGraph OpenSceneGraph is an open source 3D Graphics toolkit written entirely in C++ using OpenGL as the underlying low level technology. It has been successfully ported to a lot of diﬀerent operating systems like Microsoft Windows R , Mac OS, Linux, IRIX, Solaris, HP-UX, AIX and FreeBSD. This software library is mostly used for simulation programs. Several ﬂight and driving simulators use OpenSceneGraph for the visualization of the scene.

7 Other projects use the features for creating terrains in general or cities with buildings in particular. The visualization features of OpenSceneGraph can be compared to the set of features of Irrlicht and Ogre3D. All of the state-of-the-art features like bump mapping, shader scripts, etc. are present and can be accessed through the C++ interface. Missing features can be added to the project by building a plugin that can be linked into the project. However, less projects rely on OpenSceneGraph than on Ogre3D. A larger community using and supporting the project guarantees fast and reliable help while developing. For this reason OpenSceneGraph was not chosen for use in SwarmSimX.

2.3.4 Ogre3D

Ogre3D is a library framework with the aim of providing a free rendering engine architecture. The project exists since 1999 and has been extended ever since. As with all the presented render engines one of the main aspects of Ogre3D is the independence of the underlying operation system. The low-level technique used to render the scene is easily exchangeable as they are compiled as loadable modules that get plugged in at the startup of the program. This way code that uses the Ogre3D-library can easily be ported to other systems. It has a lot in common with the other two libraries presented, but some features are implemented in an easier to use fashion. The first mentionable feature is the way material declarations are handled. A powerful material language allows to administer all the needed assets outside of the C++-source. Changing the material definition of objects within the scene requires no recompilation. With this language, shader programs can be loaded and attached to materials at runtime. Supported languages are assembler, Cg [21], DirectX R 9 HLSL [20] and OpenGL SL [22]. Other features that can be considered as the state-of-the-art in rendering techniques are also available. Some of them are bump mapping, dynamic shadows and particle systems. The main reason why Ogre3D has been chosen as the render engine is the fact that a lot of projects use this library. The number exceeds the number of projects using Irrlicht or OpenSceneGraph. This is a good indication for the quality of the library. However, it is important to note that SwarmSimX does not depend on Ogre3D or any other rendering engine. An additional abstraction layer encapsulates the rendering. So the choice of using Ogre3D is not final. If users wish to use a different library this abstract interface can be reimplemented to provide a different render engine.

8 2.4 Physics engines

The physics engine is responsible for calculating the newton dynamics of objects defined in the environment. In addition, it checks for collisions and the appropriate response to a collision is calculated. The physics engine is the sole source of all movements within the simulation. Objects are driven either in a kinematic way, by setting velocities, or they are moved by setting forces/torques. In a Model-View-Controller (MVC) sense, the physics engine represents the model of SSX. Therefore it has no knowledge of how to display the results from the calculations. To update the position and orientation of objects in the environment, a callback object may be registered that is notified every time the state of the physical object changes. In addition methods for polling the internal information are also provided. The physics engine can be understood as the core of the simulation environment. To ensure a deterministic behaviour, a reliable triggering of each physics simulation step needs to be implemented. In particular, with a preconfigured timestep τ the actual time passed should be exactly the same. A more detailed description on triggering the simulation is given in section 2.5.2. Some game engines like the Unreal Engine, Unity and the cryENGINE use a custom implementation of the physics simulation that is already included and tightly coupled with the rest of the library. Objects defined in this environment have properties from both engines. Since the goal of SwarmSimX is to be modular and have indepedant libraries this kind of system is not applicable. Boeing and Bräunl [3] compared the performance of several physics engines. The focus of the evaluation was the application of physics engines in simulation environments. The evaluated engines were Ageia PhysX Engine (also referred to as Novodex that later became the NVIDIA PhysX engine), Bullet Physics Library, JigLib, Newton, Open Dynamics Engine (ODE), Tokamak and True Axis. Five tests were performed to evaluate the performance of the engines. These were integrator, material, constraint, collision and stacking tests. Although some of the engines performed very good in some of the tests, no engine performed best in all tests. Boeing and Bräunl [3] conclude that depending on the purpose of the simulation the corresponding engine should be selected to gain the best results. The purpose of SSX is to simulate multiple robots in a potentially vast and cluttered environment. However, this is computationally very expensive as many physical objects need to be simulated at once. The NVIDIA PhysX engine is the only engine that provides fast calculations performed on the GPU rather than the CPU. This way thousands of objects can be simulated simultaneously. As a result, the decision has been made in favor for the NVIDIA PhysX engine. This poses somewhat a tradeoff. The library is free to use even for commercial products, but the source code itself is not available for free. The internals of the engine are not visible to the user, posing this part of the simulation as a black

9 box. Also modifying the library itself, e.g., to add features, is not possible. The gain from this decision is the high performance of the engine, which is achieved by performing some of the calculations on the GPU. Nonetheless, it is still possible to use open source software only, if the user wishes to do so. As with the render engine the physics is encapsulated into an abstract C++-interface that can be reimplemented using a library that is open source, e.g., ODE.

2.5 Real-Time and Linux

Real-Time (RT) is an expression that is widely used in computer science and engineering. Although it is used very often, the definition of RT differs depending on the application. In computer graphics and virtual reality RT expresses the capability of a program to run fast enough to create a smooth visualisation of the scene. A minimum update rate of the animated scene presented is necessary to create the illusion of continuous movements for the human. Often this minimum update rate is considered to be between 30-60 frames per second. Programs that can render the scene with this update rate are considered to run in RT. This definition can be generalized to any kind of system, like a program or a operating system. If any kind of operation returns before a predefined deadline every time it is called, the operation is considered to run in RT. Two distinctions are made regarding the handling of exceeding the time limit. Hard Real-Time systems stop the execution of the program after such an error. Exceeding the limit is considered as a fatal error that cannot be recovered from. A system like this ensures that all deadlines are met. As long as the system runs the results from the calculations have the highest quality and can be repeated in the exact same way. Soft Real-Time systems on the other hand are less strict. It is still considered as an error, but execution of the program is not stopped. The quality of the calculations after not having met the deadline can be considered close to zero. This may have an impact on the determinism of the running system, e.g., the results of two runs may not be comparable if errors occurred. In a GNU/Linux environment RT-capabilities can be achieved in different ways. The most intuitive is the use of a RT-kernel. RT-kernels can be compiled by applying a PREEMPT_RT patch set, which enables the RT-features of the kernel. Other projects provide custom RT-schedulers that are added to the kernel. The Xenomai project is one example for this approach. SwarmSimX was developed on a computer with the Ubuntu OS installed. Ubuntu [5] is a Linux distribution with the support of installing multiple different Linux kernels, depending on the purpose of the computer in use. Parallel to the default generic kernel, a Real-Time-kernel has been installed that enables the use of Real-Time-schedulers at runtime.

10 The RT-kernel provided by the Ubuntu repositories has the PREEMPT_RT patchset applied, therefore it provides a soft RT-environment.

2.5.1 Measuring time and triggering events Machine time is read by utilizing the capabilities of modern CPUs and recent kernels. A RT-capable clock that has a CPU-clock independent pace is read by using the function clock_gettime (clockid_t cId, struct timespec *tp) This method is a requirement by the first amendment of the POSIX standard [27] which requires the timers to be in nanosecond precision. Intel R CPUs provide a register called Time Stamp Counter (TSC) which is 64 bit long and is present since the Pentium series. It can be accessed with the RDTSC instruction, further information can be found in the manual provided by Intel R [13]. Other CPU manufacturers may also provide this instruction. The implementation of the clock_gettime method utilizes this feature , if the CPU is capable of this instruction. It also manages possible flaws with modern CPUs that allow for frequency scaling, resulting in TSC tick rates changing over time. Note that this only happens on CPUs that do not have constant tick rate TSCs. Scheduling a method call that gets triggered in a certain time from now is done by utilizing the ualarm capabilities defined in the POSIX standard [27]. ualarm allows for scheduling the raise of the SIGALRM flag after x ms. This signal gets caught by a signal handling method. The system API defined by the POSIX standard has been wrapped in a C++- interface as part of the ADAPTIVE Communication Environment (ACETM) which is a dependancy of SwarmSimX. ACETM has been initially developed by Douglas C. Schmidt to provide a high-performance communication framework that encapsulates the complexity of network programming [25, 26]. ACETM is an open-source object-oriented C++framework that implements many Patterns found in [4, 11, 25, 26]. It is crucial for Real-Time simulation that the timing of each simulation step is correct. Therefore the current time of the simulation is tracked and compared with the time of the machine running the simulation.

2.5.2 Stepping the simulation To understand how the stepping of the simulation is done the simulation is idealized with the following two assumptions.

1. The time needed to calculate a timestep tstep is always less than the timestep τ, for a reasonable timestep τ.

2. A step scheduled in τ s will be triggered in treal = τ s

11 Figure 2.1 shows how the stepping in an ideal scenario looks like. The horizontal bars indicate the length of calculating a single timestep. The diﬀerence of two timesteps t0, t1 is τ = t1 − t0.

t0 t1 t2

Figure 2.1: Ideal case of how the simulation is triggered

Let us look at the second assumption first; it is directly connected to the RT attributes of the system. A perfect RT-platform can always ensure that the alarm set to a specific time will cause the triggering of a simulation timestep at correct time. In reality of course this is not true. Small variances in the timing of the steps need to be addressed in the simulation. Every time a step is triggered the actual time passed treal is measured. In the next step the number of full timesteps treal+taccu,n-1 n = τ , with τ being the timestep and taccu,n-1 the remaining time from the previous triggered step, is calculated and n timesteps are performed. Finally the remaining time taccu,n = treal−n·τ is calculated and stored for the next triggered step. This way no time "gets lost" by simply assuming that the timing is correct, as taccu,k always stores the remaining time. Note that −τ < taccu,k < τ is true for all steps k ≤ n as long as the first assumption is not broken. This leads us to the first assumption, which implies that the calculations are deterministic. The time to calculate a step does not vary independent of the dynamics within the simulation environment. This however may not always be the case. Consider the following scenario. Within the simulation a stack of boxes begins to fall over after a sphere crashes into the base of the stack. Before the crash, the boxes are in a sleep state. In sleep state the physics engine does not consider the boxes as moving parts, therefore no calculations are needed to update states like velocities or position. Also no collision check for the sleeping objects are performed. When the tower falls the boxes are woken up again causing a lot of computations. The physics engine needs to check for collisions, apply forces, friction and recalculate the position, velocity, etc. After all boxes have fallen on the ground the computation time reduces again, as the number of collisions decreases and the objects return to the sleep state again. The time needed to calculate the steps of this scenario varies heavily and may exceed τ several times. This breaks the first assumption. Figure 2.2 shows a horizontal bar exceeding the time τ of

12 a single timestep, causing the subsequent step to be delayed by ∆t.

∆t z}|{ t

0 t0 t1 t1 t2

Figure 2.2: Realistic triggering behaviour of the simulation

A maximum of nmax timesteps are calculated like this posing a tradeoff between RT-requirements and non-deterministic behaviour within the simulation. In some cases treal + taccu,n-1 is bigger than nmax · τ. This might be the case if the calculations take longer than nmax · τ or the timing of the triggering is delayed by the kernel. In such a case an error is printed and only nmax timesteps are calculated. In any case taccu,n holds the remaining time that "did not fit". See figure 2.3 for an illustration of a timestep taking too long.

∆t ∆t ∆t ∆t ∆t ∆t ∆t z}|{ z}|{ z}|{ z}|{ z}|{ z}|{ z}|{ t

0 t0 t1

Figure 2.3: Calculating one timestep exceeds the regular triggering several times, causing undesired, nondeterministic behaviour

If the calculation of a step always takes longer than τ, taccu,n accumulates to inﬁnity. The time within the simulation has an increasing oﬀset compared to the wall clock time. It is therefore very important to track whether timing errors occur. Increasing the timestep τ or reducing the CPU load are the only ways to solve this issue. CPU load can be reduced by decreasing the number of Artifacts in the simulation, reducing the total number of sensors and drivers or by reducing the complexity of the calculations of sensors and drivers. Increasing the timestep causes the Drivers attached to Artifacts to be updated less often. Time depending algorithms, e.g., for controlling a robot, messaging, need to be adjusted, if the timestep is increased.

3 Software Architecture

In the process of constructing a new system, the developer is often faced with challenges he/she has faced before. The developer will then use the solution or a similar solution that he/she used the last time. The knowledge how to tackle challenges or problems in an elegant way, is what makes this developer an expert. Going beyond the point of recognising similar problems and describing the problem and the corresponding solution in an abstract way leads to the concept of patterns. Alexander deﬁned patterns in his book The Timeless Way of Building [2] as a three-part rule: a relation between a certain context, a problem, and a solution.

The pattern is, in short, at the same time a thing, which happens in the world, and the rule which tells us how to create that thing, and when we must create it. It is both a process and a thing; both a description of a thing which is alive, and a description of the process which will generate that thing.

Alexander defined patterns in the context of architecture. But defining and using patterns is not restricted to architecture. Buschmann et al. [4], Gamma et al. [11] and others applied this concept in the design process of software, leading to Software Architecture. Many patterns have been defined providing both, efficient and elegant solutions. Following the evolution of software libraries over the past years shows that progress is moving very fast. Very often techniques or capabilities of computers change and not following the developments may cause libraries to be outdated. This fact has a high impact on how software needs to be designed. If a simulation environment is heavily dependant on a specific library used for simulation and this library shows to be outdated, the simulation environment itself can be considered as outdated. Modifying the whole software to include a different kind of technology can be as troublesome as designing a new simulation environment from scratch. But software can be designed to prevent scenarios like that. One important principle is encapsulation which introduces an additional layer of abstraction. The functionality needed by the rest of the system is described with an abstract interface. The implementation of this interface may then use any library that provides the functionality. This way the implementation of the interface is independent from the rest of the system and can be exchanged as needed.

15 This approach of designing software has been explained superbly in Gamma et al. [11]. The book states that not only the implementation should be encapsulated but also no information of inner states of the classes may be exposed to the client using it. Clients remain completely unaware of how the classes used work internally. The principle behind this is reduced to the single statement,

Program to an interface, not an implementation

3.1 Software requirements

Stating requirements to the software early on in the process of software design is an important step. Stating the requirements helps to define how the general layout of the software will (i.e., must) look like. In Alexander [2] requirements are named as forces. Forces "push" the layout of the software into certain directions. Finding a correct "spatial configuration" that satisfies all requirements is the key element of elegant software. The most important forces identified for SSX, acting on the design process are as follows.

Extensibility Exchanging parts of the implementation to cope with new techniques is highly advantageous. The possibility to add new virtual hardware, e.g., sensors or robots must be given.

Physical fidelity "Physical fidelity is defined as the degree to which the physical simulation looks, sounds, and feels like the operational environment" [1]

Functional Fidelity "The degree to which the simulation acts like the operational equipment in reacting to the tasks executed by the trainee [or robot]" [1]

Ease of development Creating Robots and the emulated equipment needs to be easy. This requires a simple and well deﬁned interface provided by a library that comes with the simulation.

Ease of deployment The goal here is to interface programs that work together with the simulation and with the real equipment/robots as easily as possible. In a perfect scenario no code modiﬁcation or even recompilation should be needed.

Ease of communication Controlling multiple robots requires reliable communication channels. An easy and intuitive interface for communicating is crucial for deﬁning those channels.

Real-Time capabilities Building RT-capable software depends heavily on the capabilities of the OS used. Using the capabilities provided in an eﬃcient and reliable way is a main force.

16 Independence and Freedom The simulation environment will be used in research projects. Its very important to guarantee that research is not inﬂuenced by any kind of external entity. Using software libraries that are available freely without any restrictions is therefore very important.

Investigating the forces shows that most of them are opposing to at least one other force. Writing in an extensible fashion forces the design to use abstract definitions of classes that are defined independently of the implementation. En- capsulation ensures that the representation of data from the implementation stays within the boundaries of the class. Additional classes that need to follow strict design principles may increase the complexity too much. This clearly opposes the Ease of development force stated above. Some of this complexity can be reduced with a clear definition of the interfaces. Clear documentation provides information about the design idea and principle behind an interface rather than only defining the input/output of method calls or the purpose of a specific class. Increasing the physical or functional fidelity often comes with the cost of CPU time, which in turn can break the RT capabilities. Finding a balance is dependant on the scenario being simulated. Simulating a single robot is always less time consuming than simulating multiple robots of the same type. Finding a balance can be done by exploiting the possibility to adjust some of the parameters influencing the physical and functional fidelity and the "strictness" of RT-capabilities before running the simulation. Some of the parameters are the timestep, the "slack" given for the triggering preciseness, etc. Independence and freedom of software can only be guaranteed with the correct license model. The desired license may not limit the use of the software or library for non-profit applications. Initial or recurring costs to use the software are undesirable as it excludes research groups that do not have the budget for this or just want to test SwarmSimX. A less important requirement is to use open-source software. This is optional as it does not necessarily limit the use of the software itself, if the first two requirements to the software models are given and if the simulation environment can be extend independently of this software.

3.2 Overview

The simulation environment can be divided into three main parts. Those parts are the visual representation, physical representation and the creation part. Fig- ure 3.1 gives an overview of the elements used in the simulation and how they are related. In the nomenclature of SSX, the visual representation is managed by the RenderEngine. RenderNodes are used to deﬁne individual elements of the RenderEngine. In a symmetric way the physical representation is managed by

17 Figure 3.1: Overview of the software architecture of SwarmSimX the PhysicEngine and the individual parts are called PhysicNode. Both, Physic- and RenderNodes can be connected to form tree structures. Child nodes are de- ﬁned (i.e., represented by position, orientation, mass, etc.) w.r.t. to the parent node to which they are connected. The visual and physical representations are related to each other, as the physical representation is used to perform the actual simulation and the visual displays the behaviour of the objects being simulated. This relationship is expressed in the parallel structure of the design layout. At every timestep of the simulation the execution of logical modules is triggered. These modules can perform any kind of calculation and are used to extend the simulation with custom logic or custom functionality. They are called Driver and Sensor. Drivers represent the behaviour of objects within the simulation environment. E.g. a Driver can represent the attitude controller of a Unmanned Arial Vehicle (UAV) ﬂying in simulation that receives desired angles and adds forces/torques to the physical object being controlled. Another example is the logical module of an automated door that opens whenever an object moves within a certain range and closes after 5 s with no sensor input.

18 Sensors are used whenever information of objects within the simulation or the simulation itself needs to be retrieved. E.g. a sensor could emulate the expected values of a real sensor. This way a control algorithm implemented for a real microcontroller can be used with this sensor output, without modifying the code or the algorithm of the microcontroller code. Also omnipotent sensors can be implemented that measure the state of all simulated robots in the simulation. This kind of sensor may not exist in reality, but may prove helpful while developing new algorithms. All those parts are stored together into a single object called Artifact. An Artifact has at least a RenderNode and PhysicNode, both may have an empty definition. Sensors and Drivers are not mandatory. It is possible to simulate several different Artifacts simultaneously. Artifacts state the main concept of SwarmSimX. Everything that can be placed in the simulation environment is defined as an Artifact.

3.3 Specifying object interfaces and interaction

In this document I will follow the conventions used by Gamma et al. [11] and Buschmann et al. [4]. Classes and their interfaces will be defined using a class diagram. Figure 3.2 shows how classes, objects and the corresponding design layout will be described. Abstract and specific classes will be represented by boxes and a normal font. Object references, aggregations of objects and the creation of objects will be represented by different line connections. All those connections can have either a one-to-one or a one-to-many relationship. Class inheritance will be represented by a connection that has a triangle in the middle. Methods defined in the interface will be represented by a box and a font in italics. In some cases a sample pseudocode implementation will be provided in a box with monospace font. Variables on the other hand will be defined in a box with normal font below the class-name-box. The sole purpose of class diagrams like the one in figure 3.2 is to show the interfaces and the relationships of classes and objects. The interaction over time is not possible to visualize with this kind of diagram. For this the interaction diagram will be used. The example in figure 3.3 shows the creation of an object of Type anotherObject and a call to an operation that in turn calls DoOperation() on itself. The length of each of the bars shows how long an object will be active. Note that this has no correlation to the actual length it takes for certain methods to be computed. Figures like that will not be used to visualize an algorithm, instead the purpose is to help understand how certain applied patterns or a design in general works.

19 Figure 3.2: Example of how Objects and their relationships are be displayed in this Thesis.

Figure 3.3: Example of an interaction diagram between objects.

3.4 Descriptor abstraction

Since the engines are encapsulated by an abstract layer, the creation of objects needs to be done independently of the concrete engine used. Since it cannot be known what kind of information the engine needs it is not possible to deﬁne an

20 interface that directly uses this information as arguments. This problem has been solved by introducing the Descriptor class. A De- scriptor is a virtual interface that is used to describe objects although it may be unclear what information is needed by the concrete classes. An additional feature is that the Descriptor class allows for saving the instances of child De- scriptors. With this capability tree structures like the ones used for RenderNodes and PhysicNodes can be represented. Figure 3.4 shows the schematics of the De- scriptor class

Figure 3.4: Schematic of the Descriptor class

The interface uses key-value pairs to store and retrieve information. This information is expressed by the C++-class std::string. Stored information can easily be retrieved by calling a method and providing the correct key. If a key does not exist an empty string will be returned. This interface definition is a tradeoff, as it forces the client to stick to this implementation, while it provides a good common representation for all kinds of information. With this general concept it is possible to store the information which is specific for the Render- or PhysicEngine used, in order to create an object. Since the user of the interface already knows which engines are used, the information needed can be provided at runtime. With the information being stored as strings and children that can be registered, it is reasonable to use XML as the internal representation. The open source library tinyXML originally written by Lee Thomason [17] has been used in this project to provide XML support.

3.5 RenderEngine abstraction

The design of engines assumes that all engines have a similar lifecycle. The engine can be started using the runEngine method. It is up to the user to implement this method according to the desired behaviour of the Render-Engine. One possible behaviour could be that the method triggers the rendering of one frame. This

21 way the method would be nonblocking and needs to be called repeatedly by a mechanism within the simulation environment. Another possibility, which was also used by SSX, is to have a blocking call. This will render frames continuously until the user desires to stop the rendering and the method returns. After a call to stopEngine, it is important to clean up used memory. For this the method cleanupEngine needs to be implemented. Figure 3.5 shows the layout of the Render-Engine.

Figure 3.5: Schematic of the RenderEngine

3.5.1 RenderNode All render engines have a set of objects defined that are responsible for rendering a scene. Those RenderNodes have several different purposes. Many engines store the nodes defined in a tree structure, called scene graph. Child objects are defined locally w.r.t. the parent node. To cope with this approach all RenderNodes can have a set of child nodes. This design decision has been made although a render engine may not represent a scene using trees. In such a case the infrastructure for handling child and parent references will not be used. It is important to note that the overall system will work nonetheless. From the initial RenderNode a set of more specific nodes can be derived. The most important node type is the VisualRenderNode that represents any kind of visual object in the scene. The implementation of this node is highly dependant on the specific engine used. In the case of Ogre3D those nodes are defined by a

22 Figure 3.6: Interaction diagram of a VisualRenderNode is created at runtime. mesh that can be loaded at runtime. Ogre3D uses a mesh definition that consists of a series of triangles that are saved in a specific XML-format in binary form. Additionally a material name is stored leading to a material definition that gets loaded at startup of the render engine. The next type of RenderNode is the LightRenderNode. It can be used to add different types of lights to the scene. Lights have many different attributes that change the effect of the lighting dramatically. Since those nodes can also be children of a visual node, the global position of these nodes will change with the movements of the parent node. This way nice visual effects can be established. The last type of RenderNode is the CameraRenderNode. This node is special compared to the other nodes, as it allows to retrieve images from the rendered scene. The scene can be displayed from different viewing angles at the same time using this node, which enables the implementation of virtual cameras attached to robots. The creation of any kind of RenderNodes need to be in a complete asyn- chronous and nonblocking fashion. This leads to two difficulties. First, after calling the create method a reference needs to be returned that has to be fully functional. This might be problematic because this reference may not be correctly initialized yet, as the engine is in a state where creation is not possible. Second is the problem of creating RenderNodes that need access to the implementation of the RenderEngine although the interface is defined to not allow access. Both problems are solved by implementing a special RootRenderN- odeOGRE3D that has the responsibility to provide functionality to the user creating a RenderNode. It also has the responsibility to create all children by providing information about the internals of the RenderEngine. Note that this

23 class is part of the implementation and not of the general, abstract interface. All those nodes are created in a similar fashion, ﬁgure 3.6 shows the example of how a VisualRenderNode is created at runtime of SSX. First a RootRenderN- odeOGRE3D is created that gets returned immediately. At a later point in time, as soon as the engine is in a state that allows to create new objects, all child nodes are created. Only at this point in time a visual representation will be available to the user.

3.6 PhysicEngine abstraction

The interface layout of the PhysicEngine is almost identical to the interface of the RenderEngine. The design of the PhysicEngine has the same underlying life cycle. Methods for initializing, running, stopping and cleaning up are provided. Only the method for running the engine has a different behaviour. Instead of blocking until the user wishes to stop the simulation it executes just one step of the physical simulation. This method needs to be called precisely at the frequency defined in the configuration. This defines the repeatability, i.e., the determinism, of any experiment conducted within this simulation. See Section 3.7 for the classes responsible for this and 2.5.2 for an explanation on how the stepping is performed. The layout provided in figure 3.7 shows how the PhysicEngine is connected with PhysicNodes that represent physical objects in the world.

Figure 3.7: Schematic of the PhysicEngine

24 3.6.1 PhysicNode PhysicNodes represent physical objects in the world. In general they can be defined by their shape, mass, position and orientation. Those values can be set in the description of the object before starting the simulation. However, they can also be set at runtime. In addition to that methods for setting the velocity, angular velocity and methods for adding forces or torques are provided. PhysicNodes represent the model in a MVC pattern context. Changes in the internals states that are important to update the visual representation are propagated to all registered PhysicNodeCallBacks. Decoupling the physical objects from their visual representation is very important. Using the PhysicEngine in a different context would not be possible otherwise. For that reason the Artifact implements the very small PhysicNodeCallBack interface and passes the position and orientation on to the visual representation. This visual representation must not necessarily be the RenderEngine, but could also be the terminal output or a file logging the information. The connection between the PhysicEngine, the PhysicNodes and their call- backs is shown in figure 3.7. Artifacts are described more in detail in section 3.7.1.

3.7 Architect

The Architect plays a central role in SwarmSimX. The Architect class is responsible for starting, configuring, running and stopping the simulation. It is responsible for creating, configuring and starting the Engines that are used for the simulation. It reads the configuration to know which engines to create, although currently only the Ogre3D based Engine for the rendering and the NVIDIA PhysX-based Engine for the physics simulation can be set in SSX. The interaction between Artifacts, Drivers, Sensors, Render- and PhysicEngine is done with the aid of the Architect. It implements the Environment interface which provides methods for retrieving information of the simulation. Figure 3.8 shows how this very slim Interface is defined. Retrieving the simulation time and a reference to a set of currently active Artifacts are the main methods frequently used. Providing information by delegating some or all of the requests follows the design principle of the Facade pattern described by Gamma et al. [11]. This way the Architect provides a single-point-of-contact to a variety of different classes from any point of the simulation environment. Tracking the simulation time and triggering the timesteps of the PhysicEngine is done as described in section 2.5.2. The techniques provided by the OS have been implemented in ACETM with the ACE_Timer_Heap that is used by the class ACE_Thread_Timer_Queue_Adapter that dispatches the execution of the timed events in a separate thread. This implies that all triggered steps of

25 Figure 3.8: Schematic of the Environment the PhysicEngine are called from a separate thread instead of the main process thread. This way the execution of a single physical timestep is decoupled from the execution of the rest of the simulation. This independence is important to ensure a deterministic and reliable physical simulation.

3.7.1 Artifact Any entity that the user wishes to place in the environment is represented using Artifacts. Artifacts can be created at startup of the simulation by adding the definition to the scene description (see chapter4 for an example). Or the Artifact is created at runtime of the simulation, by providing a Descriptor. The latter case is used less often, as the simulation environment is usually provided as a XML file. This gets loaded by the SceneLoader at startup. The XML file defines the position and orientation of the Artifacts to be included. Artifacts are referred to with the filenames of the Artifact XML file. The responsibility of the Artifact is to provide a point of access to the Render- and PhysicNodes representing the Artifact. It gets notified by the PhysicNode every time the position and orientation of the PhysicNode changes. This is passed on to update the position of the visual representation of the Artifact. This approach ensures the loose coupling between the PhysicEngine and the RenderEngine. Implementing a dummy RenderEngine that provides no visual display of the scene could prove useful in some cases where the visual part is not necessary. Estimating the future attitude of a robot may be an application of

26 this approach.

3.8 Extending the simulation

By defining Artifacts and placing them in the world any custom scene can be created. Artifacts may have a physical or visual representation and can interact with the environment, but so far only in a passive way. Artifacts that represent robots, for example, cannot be controlled in their movements. Artifacts also provide no information about themselves or their surrounding, which is crucial for any kind of control algorithm. A program that can control the Artifact and sensors gaining information about internal or external states are needed. With the help of both acting robots can be added to the scene. Furthermore Artifacts that need some kind of program logic can be implemented. A perfect example for this are automatic sliding doors that open whenever an object is in their proximity. A sensor is needed that can detect new objects in the closer area and reports this to a control program. The program must be able to move the door so that it opens in case the sensor reports a new object and closes it again after some time. The goal of being able to create custom robots with sensors attached and program logic demands that the custom parts are independent from the simulation environment. Recompiling the whole simulation environment after adding new robots is time consuming and redundant. Even worse, exchanging projects between different users may prove difficult, as the code is tightly coupled to a certain simulation environment. SwarmSimX provides the possibility to load program code at runtime by introducing Drivers and Sensors. In both cases an abstract interface defines methods for creating, configuring, running and destroying the class representing the program logic. Drivers are always associated with an Artifact and only one Driver per Artifact may be defined. Sensors are always associated with a Driver that may have references to many Sensors.

3.8.1 The dlopen API The C language provides an easy to use library for loading and calling external libraries dynamically, i.e., at runtime. A call to the function dlopen opens an external library and a handle is returned. With this handle and the name of the function contained in the library, a reference to the function can be received with a call to dlsym. The loaded library can be closed with the handle provided earlier and a call to dlcose. With the introduction of overloaded functions, i.e., functions with the same name but diﬀerent parameters, in C++ the symbols created in the compile process are not unique. To cope with this a name mangling process has been introduced

27 that creates unique symbols for the functions defined. The name mangling algorithm itself is not standardized and may change between different compiler versions, e.g. g++ 2.x and g++ 3.x. The dlopen API only supports loading functions. But C++ libraries are mostly defined by a set of classes. Receiving an instance of a class externally defined in a library is therefore not possible in a direct way. Both challenges can be met with the help of the extern "C" statement and the polymorphism of C++-classes. Functions defined in a extern "C" {..} block are treated as regular C functions by the compiler. The name mangling algorithm referred to earlier does not apply for these functions. Polymorphism describes the feature of classes to have multiple "forms". Gain- ing a second "form", i.e., type, is done by deriving from another interface. De- pending on the context, an instance of this class may then be treated like an instance of the initial or the derived type. The context can be changed by casting the instance to the type desired. In both cases, two functions are defined in a extern "C" {}-block that are responsible for creating and destroying the concrete class. The class itself derives from the Driver or Sensor abstract class that defines all needed methods in a virtual way. The instance will be created in the context of the dynamically loaded library. All memory allocated in this context may only be freed again in the same context. Using the provided destructor function is therefore very important. Not following this principle will result in segmentation faults, causing a crash of the whole simulation. The dlopen API is encapsulated in the DriverLoader and SensorManager classes. They have the responsibility of loading/unloading libraries, creating/destroying instances and taking care of any errors along the way.

3.8.2 Driver The interface definition of the Driver is very slim compared to other classes. Methods for configuring the Driver using a Descriptor, setting the associated Artifact and Environment, and calculating a simulation step are provided. In addition of the interface definition, figure 3.9 shows C code (see blue boxes) that needs to be implemented for every Driver. As mentioned before these two functions are necessary to dynamically load libraries and create instances of any Driver implemented by the user. Artifacts are responsible for creating their Driver defined by the Artifact XML file. Figure 3.10 shows the interaction involved in creating a Driver. First an Artifact requests a Driver instance given the name. The DriverLoader loads the library, calls the creator-method and provides the Driver with the instance to the Environment class. The Artifact sets the reference to itself and configures the Driver.

28 Figure 3.9: Speciﬁcation of the Driver interface. Boxes in blue represent C code needed for dynamic creation of a ConcreteDriver class.

The DriverLoader itself is responsible for freeing all Driver instances created while running the simulation. This is done when the singleton instance is closed down at the end of the simulation. It is important to note that freeing the Drivers can only be done after shutting down the RenderEngine and PhysicEngine. This ensures that no method call will reach an already freed Driver, which may cause a segmentation fault. The doTimeStep()-method gets called after every timestep. All custom logic deﬁning the behaviour of the Artifact can be implemented here. Drivers have access to the Artifact they are associated with and can therefore also access the RenderNode and PhysicNode accompanied with the Artifact. Adding forces, setting velocities or the global pose of the PhysicNode will allow the Artifact to be moved in a way very similar to reality.

3.8.3 Sensor Sensors provide information about the simulation environment. Utilizing the Environment reference Sensors can access both engines and gain access to all created Artifacts of the simulation. All possible information is therefore provided to the Sensor. Information provided by the Sensor is distributed to all registered SensorCallBacks. This implementation follows the Observer Pattern [11] which allows for distributing information without the need of polling for data. In this

29 Figure 3.10: Interaction involved when creating a ConcreteDriver that implements the Driver interface and the create, destroy functions both defined in an extern "C" {}-block. case the Sensor itself is responsible for triggering the update process. It is also responsible for defining the data structure of the information provided by the sensor. Figure 3.11 shows how a Sensor is specified. Sensors can be loaded at runtime in a similar way like Drivers. The blue boxes in figure 3.11 show code defined in an extern "C"-block that is responsible for creating and deleting the concrete Sensor. All Sensors are associated with their Artifact, but the Driver is responsible for registering SensorCallbacks. This can either be a separate class handling the sensor output or the Driver itself that manages this responsibility. As described earlier, Drivers have access to the Environment and therefore access to all Artifacts created in the virtual environment. The Sensor class does not check affiliation of the registered SensorCallBack. It is possible to register a callback at a Sensor that is associated with a different Artifact. This allows for a unique and very fast way of sharing information between Robots. No data needs to be copied, serialized or transmitted to other robots represented by their Drivers. Sensors follow a different paradigm for the update process, when compared to Drivers. Drivers always need to be updated after each physics timestep as they always have the same timestep as the simulation. On the other hand, Sensors may have different update rates. Instead of calling the update()-method after each

30 Figure 3.11: Specification of the Sensor interface. Boxes in blue represent C code needed for dynamic creation of a ConcreteSensor class. timestep a separate ACE_Thread_Timer_Queue_Adapter is used for triggering the update steps of Sensors. The ACE_Thread_Timer_Queue_Adapter is provided by the ACETM library, which is already used by the Architect for timing the physics steps. After creating and configuring a Sensor it is added to the queue by the Architect. After this the timer queue is responsible for calling the handle_timeout method with a rate that is defined by the Sen- sor. The abstract interface of the Sensor already defines this callback-method handle_timeout which in turn calls the virtual update-method of the Sensor. The relation between the Artifact, the Environment and the Sensor is shown in figure 3.12.

31 Figure 3.12: Interaction involved when creating a ConcreteSensor that implements the Sensor interface and the create, destroy functions both deﬁned in an extern "C" {}-block.

32 4 Implementation of a quadcopter for SwarmSimX

4.1 Motivation

The Human Perception, Cognition and Action of the Max Planck Institute for Biological Cybernetics is currently working on the formation control of multiple UAVs. The UAVs currently in use are quadcopters produced by HiSystems GmbH [12]. The picture in ﬁgure 4.1 shows one of the MikroKopters used.

Figure 4.1: Picture of one of the quadcopters with reﬂective markers attached to it, used for tracking the global pose.

The goal of this chapter is to create a virtual quadcopter that reacts as close as possible as the real quadcopter. In general the real quadcopter is controlled by a high level controller. This controller calculates the desired roll-, pitch-angles, yaw-rate and the thrust needed to ﬂy a given trajectory. The trajectory is either given by the input of a human controller or by a predeﬁned trajectory. This high level controller receives the global attitude of the quadcopter as input from the VICON system (Please refer to section 4.2.3 for additional information.).

33 The quadcopters receive the desired input values as input using a wireless se- rial communication channel. The on-board attitude controller calculates the rotational speeds of the four motors needed to reach the desired angles and speeds. Those resulting motor setpoints are sent to the motor controllers controlling the brushless motors. The parts responsible for the behaviour of the quadcopter are the readings from the IMU, the calculations from the attitude controller, the behaviour of the motor controllers, external noise (e.g., turbulence), the readings from the VICON system and the high level controller. All those parts need to be simulated to create a virtual quadcopter with a behaviour as close as possible to the real counterpart. To validate the ﬂight behaviour an experiment has been conducted, which compares the ﬂight behaviour of the real quadcopter with the one from the virtual quadcopter. See section 5.2 for details.

4.2 Background information

4.2.1 Notation Before going into detail on how a quadcopter and the corresponding environment can be created, it is important to define the reference frames. Before the engines get started a configuration step is made, which allows modifying the reference frame used in the environment. For this a correction Matrix, Mcorr needs to be defined. Initially the world orientation frame is defined as follows. Let W be the initial world reference frame. All frames are defined to be right handed. By default axis Wx points to the front and Wy points up. In aerospace engineering the world reference frame is defined with Wx pointing to the front and Wy pointing to the right. The correction Matrix Mcorr (see 4.1) configures the simulation to use a new definition for the reference frames.

 1 0 0  Mcorr =  0 0 −1  (4.1) 0 1 0

Figure 4.2 illustrates the rotation of the initial frame W to the frame used in the simulation environment. After setting up the world reference frame, the body frame of the quadcopter can be deﬁned. Let W be the world reference frame as deﬁned above after Mcorr has been applied. I will denote V as the reference frame attached to the body center of the vehicle w.r.t. W. Furthermore I will denote the transformation from a frame A to a frame B by B B a rotation RA and a translation TAB expressed in frame B.

34 y

 1 0 0  x Mcorr =  0 0 −1  x 0 1 0

z y

Figure 4.2: Reference frames deﬁned in the simulation before and after applying Mcorr.

4.2.2 Multi-Agent-Lab Most of the experiments of the group for Human Perception, Cognition and Action are performed in the Multi-Agent-Lab (MAL). The MAL is a room with the size of 7.55 m × 6.18 m × 3.5 m (length × width × height). For the safety of the conductor of the experiment, possible bystanders and the quadcopter itself, a net has been mounted 0.3 m away from the walls of the room. If the quadcopter is malfunctioning and not controllable any longer this net will catch it, preventing it to crash into the wall and reducing the damage dealt to the quadcopter. The ﬂoor has a protective layer of a soft packaging material, also used to reduce the damage dealt to the quadcopter in case of complete power failure of the quadcopter while ﬂying. Figure 4.3 shows a collection of pictures of the MAL with its protective systems. Also visible is the control table with the control PC and the VICON computer.

4.2.3 VICON The position and orientation of objects within the MAL can be tracked with an optical tracking system. The VICON Bonita camera system captures the whole room up to a height of 3 m with 6 cameras that have been mounted near the ceiling of the MAL. The infrared video capture is used to track the position of reﬂective balls mounted on the quadcopter. Figure 4.1 shows the quadcopter

35 d)→

a)→

c2) c1) ↓ ↓

b)→

Figure 4.3: The Multi-Agent-Lab with the protective net a), soft packaging material on the ﬂoor b) and the control table c) with the PCs running the control program c1) and VICON c2), connected with the VICON Bonita camera system d). with 5 reﬂective markers attached. Video streams of each of the cameras enable the VICON system to calculate the position and orientation of several tracking objects in real-time. This data is then received by the control program that utilizes a library provided by VICON. While maintaining high update rates of up to 240 Hz the system is able to provide very accurate data about the pose of several objects in the tracking space.

4.3 Visual representation

We start the development of the virtual quadcopter with the visual representation. This will be helpful to understand how and where the quadcopter moves in simulation. The render engine used is the Ogre3D render engine that needs a loadable mesh to render. This mesh can be created in different ways. The general workflow is as follows. First a model is created using any 3D modeling software that is supported. Table 4.1 shows a list of supported 3D modeling software and file types that can be converted. The exported or converted meshes are added to the project together with the corresponding material files. It is important to let Ogre3D know where to find

36 the new files. This needs to be adjusted in the configuration file resource.cfg by defining an extra path or by storing the files in a path already present.

Table 4.1: 3D modeling software and ﬁle types that can be converted to Ogre3D *.mesh ﬁles supported 3D model types Available support 3D Studio Max exporter, converter Blender importer, exporter, converter Google Sketchup exporter Maya exporter Softimage/XSI exporter Wings 3D exporter, converter Cinema 4D exporter DeleD exporter VRML converter LightWave converter Bioware converter

The model used in this thesis was designed using the CAD software Autodesk R Inventor R 1. The final model was then exported to a *.max file that can be opened with 3D Studio Max. In the last step an exporter transforms the *.max file to an Ogre3D-mesh. The result can be seen figure 4.4.

Figure 4.4: Mesh of the quadcopter visible in the scene of SwarmSimX

In the next step we need to create a XML ﬁle that gets loaded by SSX. One part of it deﬁnes the visual representation of the quadcopter. As explained before 1Courtesy to Markus Ryll for modeling the visual representation

37 any object that can be added to a scene in the environment is called Artifact. Artifacts are defined using XML files which have a single root node of type Artifact . Listing 4.1 shows the minimal XML-definition of the Artifact file that represents the quadcopter in the simulation. The root node Artifact needs at least the name attribute. Position, Orientation are optional parameters. Artifacts can be configured using the Config node and any attribute value pair. One attribute used by SSX is the isRobot attribute. If this is set to 1 or true the Artifact is considered to be a robot. This information can be used by special sensors added later to the Artifact that retrieve the nearest neighbours of a robot. In addition to the Artifact node a visual root node has been defined. The sole responsibility of the visual root node is to manage child visual nodes. The visual root node has one child visual node defined that is of type Mesh. This indicates to SSX to expect a mesh to be loaded. The information which mesh to use is stored within a Config node. In addition, a translation and orientation - both defined w.r.t. V, the body center of the Artifact - are set. In this case a rotation is used to align the reference frame defined within 3D Studio Max with the one defined in SSX. The Scale attribute is optional and can be used to stretch objects in Vx, Vy, Vz direction. It has been added to this example for completeness. Note that all nodes have an attribute name. This attribute can be used at runtime to retrieve the nodes with the corresponding name. This can be exploited to create custom effects, like moving parts (e.g., propellers) or redefine the overall visual representation of any Artifact at runtime. The information provided here to define visual representations is specific for Ogre3D. When the user desires to switch the RenderEngine with a different implementation this definition needs to be adjusted, in order to provide all the information needed for the new implementation.

4.4 Physical properties

To obtain comparable results the physical properties of the real quadcopter were measured. Table 4.2 shows the parts that have been modeled with their physical properties. Depending on the shape of the individual part, different values need to be defined. All shapes are defined by their extent. A Box is defined by its length, width and depth of the box divided by 2. A sphere just needs one value defined, namely the radius. The last possible shape is the capsule which is defined with by the radius and the length of the central segment. This shapes has not been used in this example. With this table we can add similar XML-code as shown in Listing 4.2 to the definition of our virtual quadcopter. The listing shows an excerpt of the definition added to the minimal example defined in listing 4.1. It can be added right after

38 Listing 4.1: Minimal structure of a quadcopter Artifact XML ﬁle including the visual representation 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 < /Config> 18 19 20

the last statement in the example provided.

With the optional Config node the properties of the PhysicNode created can be adjusted. If it is not provided the default values are used. The attributes LinearDamping and AngularDamping can be used to simulate the drag of the real quadcopter ﬂying in air. The Type attribute deﬁnes whether this object can move in the scene or not. If set to Dynamic this object can move by setting velocities or adding forces. Static objects - the default value - can be used to build obstacles that do not move but will still collide with other objects. If the Type is set to Static, the values for damping and mass will not be used, as they will not be needed.

39 Table 4.2: Parts of the quadcopter and their physical properties. Part Mass Type Extent Position arm 1 0.05 kg Box 0.285 m × 0.005 m × 0.005 m [0, 0, −0.005] arm 2 0.05 kg Box 0.005 m × 0.285 m × 0.005 m [0, 0, −0.005] board 0.05 kg Box 0.05 m × 0.05 m × 0.005 m [0, 0, −0.02] tracker 0.07 kg Box 0.02 m × 0.02 m × 0.02 m [0, 0, −0.06] battery 0.245 kg Box 0.07 m × 0.05 m × 0.01 m [0, 0, 0.01] motor 1 0.1 kg Sphere 0.02 m [0.24, 0, −0.01] motor 2 0.1 kg Sphere 0.02 m [0, 0.24, −0.01] motor 3 0.1 kg Sphere 0.02 m [−0.24, 0, −0.01] motor 4 0.1 kg Sphere 0.02 m [0, −0.24, −0.01] lander 1 0.001 kg Sphere 0.045 m [0.24, 0, 0.045] lander 2 0.001 kg Sphere 0.045 m [0, 0.24, 0.045] lander 3 0.001 kg Sphere 0.045 m [−0.24, 0, 0.045] lander 4 0.001 kg Sphere 0.045 m [0, −0.24, 0.045]

Listing 4.2: Excerpt of the XML-deﬁnition representing the physical aspects of the quadcopter 1 2 < /Config> 3 4 5 6 7 8 9 10 11 12 . 13 . 14 . 15

4.5 Implementing the Driver

At this point the quadcopter deﬁned can interact with the simulation in a purely passive way only. Starting the simulation now would create the quadcopter and it would immediately fall to the ground. Since we do not add any forces or set

40 any velocities the quadcopter will stay there until we stop the simulation. In order to control the quadcopter we need to be able to add forces to the quadcopter depending on the control input of the control program. The quadcopter needs to be able to receive the same data as the real quadcopter would receive. This ensures that the control program does not need to be switched or recompiled when switching from controlling the real to controlling the virtual quadcopter or vice versa. The simulation itself does not provide any interfaces to change the states of Artifacts within the simulation. For this we need to create a Driver that extends the functionality of the simulation. A Driver is part of an Artifact and can access the RenderNodes and PhysicNodes associated with it. The Driver built for this example uses sockets to communicate with the control program. With this socket messages will be passed back and forth from and to the control program. The two most important message types represent the internal state of the quadcopter (global pose, velocities, acceleration, etc.) and the control commands that are used to add forces to the quadcopter body. Other messages provide information about the nearest robots in the simulation, simulate a laser range sensor, provide the n closest points on obstacles in the environment. The Driver gets loaded by the simulation at runtime. To tell the simulation environment which Driver to load we need to add a small XML-node to the Artifact definition of the quadcopter. Listing 4.3 shows the code needed to add a driver to the Artifact. With this definition SwarmSimX will look for a library module called libMKDriver.so and load it at runtime. The prefix lib and the suffix .so are automatically added to the specified Driver. In the main Config.xml the pre- and suffix can be defined to cope with different operating systems that may name modules differently. Also the folder where SSX looks for the modules can be adjusted.

Listing 4.3: Snippet showing how to add the driver to the Artifact XML ﬁle 1 2 3 4

Implementing a Driver from scratch is rather simple, as only a small interface needs to be implemented. But one needs to be aware of some common pitfalls. It is important that all objects created on the memory heap from "within" the module also gets deleted there. In addition to that no memory allocated in the simulation environment may be deleted in the module. Not following these rules will result in memory leaks and possible crashes. Those crashes may not occur in a reproduceable fashion, making it very hard for the user to debug the code. Let us take a second look at the XML-snippet from listing 4.3. Notice the

41 Config node, which defines the UDPListenerPort attribute. This Config node will be translated into a Descriptor object by the simulation and handed to the driver at the time when the configure-method gets called. The UDPListenerPort is used to configure a port of a socket used to communicate with the controller program. The Messages are represented as classes and can be translated into a stream of bytes that get sent over the socket. Those classes need to be accessible from two points. The first is the Driver and the second is the control program. This is why all the Messages are compiled into a library on its own. The Driver and the control program both link this library into their binaries. New messages or changes in the internal representation of some message classes will be propagated to both places simultaneously.

4.6 Implementing a Sensor: virtual IMU

Inertial measurement units (IMUs) are electronic devices that measure angular velocities and linear accelerations at a given rate with a certain precision. Here a virtual IMU is presented with the possibility to adjust several parameters of the output. Noise, bias, output rate and a transformation w.r.t. the vehicle body center can be configured to match a real IMU as close as possible. Additionally several non-physical aspects can be configured, like scaling factors, limits, and the possibility to enable quantization of the output. Let the reference frames be defined as in section 4.2.1. Let I be the reference frame attached to the IMU w.r.t. the vehicle frame. It is important to model sensors as good as possible, meaning that the output of a virtual sensor should not be distinguishable from the output of the real counterpart. This allows for a very realistic behaviour within the simulation. SwarmSimX utilizes NVIDIA PhysX to simulate accurate physical behaviour of objects within a simulation environment. All physical interaction within NVIDIA PhysX is represented using velocities. Therefore it is not possible to directly read the acceleration or forces acting on the physical objects. By calculating the finite difference quotient of the velocity the accelerations can be obtained.

4.6.1 Noise

In this thesis noise will be denoted as NOISEσ,µ. Further, I assume that the noise of a real IMU follows a Gaussian distribution with the parameters σ, µ ∈ R3, deﬁning the standard deviation and the mean (or bias) of the sensor output. Those values are deﬁned by the real sensor and need to be obtained by measuring the output with the quadcopter being switched on. Note that for most IMUs the measurements of the accelerometer is not biased (µ = 0). In contrast the bias of the gyroscopes usually is µ 6= 0.

42 4.6.2 Linear acceleration For computational reasons the internal states of objects within the PhysX Engine are calculated based on their momentum. Therefore it is not possible to directly read the acceleration of the object. To be obtain the acceleration the finite difference quotient of the linear velocity is calculated at every timestep. The finite difference quotient for the linear velocity is :

V∆v Va = ∆t The ﬁnite diﬀerence quotient for the angular velocity:

V∆ω Vω˙ = ∆t We can now calculate the output of the accelerometer:

I I V V V I V I V a = RV a + ω × ω × TV + ω˙ × TV − g + NOISEσ1,µ1 (4.2)

V V with gravity deﬁned in the body frame g = RW gW and for matching param- 3×3 3 eters σ1 ∈ R , µ1 ∈ R deﬁning the standard deviation and mean value of the measured acceleration.

4.6.3 Angular velocity The angular velocities of frame V w.r.t. W can be obtained directly from the simulation environment. For a more realistic behaviour noise is added to the calculation.

I I ω = RV ωV + NOISEσ2,µ2 (4.3)

3×3 3 The parameters σ2 ∈ R , µ2 ∈ R deﬁne the standard deviation and mean value of the angular velocity. These values need to be measured from the real IMU.

4.6.4 Implementation The calculations performed will be done using floating point arithmetic. However the values given by the real sensor are integers. To increase the realism of the virtual IMU, quantization effects can be enabled. If enabled the Sensor outputs the floor of a given real number. The range of the values of the real sensor may also be limited due to the constructional design of the sensor. The virtual IMU can be configured with a scaling factor to spread the results to a wider range and the minimum, maximum values can be defined, to copy this behaviour.

43 4.7 Building the scene

The goal is to simulate quadcopters flying in the MAL. Since the quadcopter is ready to be used, next the MAL needs to be modeled. This is done in basically the same way. We create an Artifact that is defined in XML. The visual representation of the MAL is created using 3D Studio Max. Exporting the objects with the appropriate exporter creates the .mesh files needed for Ogre3D. To increase the realism of the room two light sources are added, illuminating the scene in a similar fashion as the lights in the real MAL. If the user wishes, shadows can also be added increasing the realism even further. The physical definition of the room is very easy compared to the quadcopter itself. The room needs four walls and a ceiling, defining a box in which the quadcopter flies. The walls will not be moving, so we define them to be Static rather than Dynamic. Sensors or Drivers will not be needed as the room is completely passive. How- ever, in some cases this may be desired. Consider the case of a ventilation shaft in the ceiling of the room. If the quadcopter flies beneath it, it will be disturbed by the turbulence of the downstream of the wind. One way to implement this behaviour would be to use a Sensor that checks for Artifacts that are close to the ventilation shaft and propagates their names to a Driver. The Driver uses this information to add a fluctuating downward force to the Artifact with a magni- tude depending on the distance of the Artifact and the variance of the turbulence itself. With the Artifact file ready, the scene itself can be set up. For this a scene XML file needs to be created that contains the source shown in Listing 4.4. Scene files are defined by a single -node that contains a set of - nodes. The -node may contain the three attributes FileName, Position and Orientation. The latter two are optional and default to "0 0 0" and "1 0 0 0 1 0 0 0 1" respectively. Values already defined in the corresponding Artifact XML files get overridden, if defined in the scene XML file. Else the values of the Artifact XML file will be used.

Listing 4.4: Scene XML ﬁle used to simulate a quadcopter ﬂying in the MAL 1 2 3 4

In the main Config.xml file the Value-attribute of the - node can be set to point to the desired scene file. For each experiment a different scene file can be configured to allow easy switching between different setups.

44 5 Experiments

Up to this point a simulation environment has been constructed that allows for custom environments. Artifacts can be added to this environment that represent objects with their visual and physical properties. Those Artifacts can be extended to run custom code. Drivers and Sensors form the last part that is needed to implement acting and sensing autonomous robots. But can the results from the simulation be used to assume the same behaviour in reality? Let us first take a look again at the goals stated earlier. The first goal was to simulate robots in Real-Time. The time in simulation needs to proceed in the same speed as the wall clock time. This requirement is fulfilled as long as the time needed to calculate a timestep is smaller than the timestep τ itself. Exceeding τ results in less accurate calculation and a less deterministic behaviour of the simulation. Depending on the experiment goal this may be tolerated. However, if the calculation time exceeds τ all the time, errors eventually add up, resulting in a crash of the simulation. In the first experiment it is tested how many quadcopters can be added to the scene, before the simulation RT assumption can not be maintained anymore. The quadcopters are programmed to reach a goal position 2 m above their starting position. Counting how often the calculation takes longer than τ and tracking the error between the actual and the desired position throughout the experiment will be used as a measure of performance. Another requirement states that the behaviour of a robot in simulation needs to be close to the behaviour of the real robot. In the final experiment the flight of a real quadcopter controlled by a pilot has been recorded. The recorded control commands are then played back to the control program that controls a simulated rather than a real quadcopter. The perfect simulation will present no errors between the flight behaviour of the real quadcopter and the simulated one. The errors in Position between the real and the virtual as well as the errors in the orientation between both will be used as a measure of how well the behaviour of the virtual quadcopter can be transferred to the real quadcopter. The machine used for all the experiments is equipped with an Intel R Xeon R W3520 CPU, 12 GB RAM and a nVidia Corporation GeForce 9800 GT GPU. All programs were executed on the operating system Ubuntu 10.04, with the optionally available RT-kernel (2.6.31-11-rt) installed.

45 5.1 Stress testing the simulation

The purpose of this experiment is to measure the maximum number of robots that can be added to the scene. Increasing the number of robots increases the computational load, eventually causing the simulation to stop working. Measur- ing the maximum number of robots has been tested with the simulation running at the timesteps τ1 =0.001 s, τ2 =0.002 s, τ3 =0.003 s and τ4 =0.004 s. The quadcopters added to the scene use the same visual and physical representation as the quadcopters described in chapter4. The Driver implemented in the chapter has been extended by a high-level controller that calculates the input of the low-level controller given a desired position. The desired position is calculated by translating the start position of each of the quadcopters by −2 m along the Wz-axis. The start position is set in the scene configuration file of this experiment. With this approach all calculations regarding the quadcopter are enclosed in the Driver. No external software is needed for this experiment that could potentially interfere with the simulation environment. The maximum number of quadcopters is determined by gradually increasing the number of quadcopters. The simulation needs to run for at least 60 s without any of the simulated quadcopters loosing control. Additionally, the offset between wall clock time and simulation time may not increase to infinity. The number of quadcopters is increased until any of the two conditions breaks.

5.1.1 Results

By gradually increasing the number of quadcopters the author was able to simulate 10, 13, 14, 14 quadcopters with the simulation configured to use four different timesteps τ =0.001 s, τ =0.002 s, τ =0.003 s, τ =0.004 s. Adding Artifacts to the scene of the simulation environment increases the computational load. The increase is reflected in the higher chance of the calculation time for a single step exceeding τ. As described in section 2.5.2 this can be tolerated as long as the calculation time for the consecutive steps is smaller than τ. If the calculation time exceeds nmax · τ, a violation of the tolerated slack given for the stepping of the simulation is recorded. Dividing the number of violations by the total number of timesteps yields the number of relative violations. The blue bars in figure 5.1 show the number of relative violations given the timesteps τ =0.001 s, τ =0.002 s, τ =0.003 s, τ =0.004 s. The green bar shows the mean position error of all quadcopters currently in the scene. The red bar shows the standard deviation of the mean position error of the quadcopters in the scene.

46 0.1

0.09

0.08

0.07

0.06

0.05

0.04

0.03

0.02

0.01 violations [%], mean error [m], std error [m]

0 0.001 0.002 0.003 0.004

τ [s]

Figure 5.1: The blue bar denotes the number of violations relative to the total number of simulation steps. The green bar denotes the absolute mean position error of all quadcopters during the experiment. The red bar denotes the standard deviation of the mean position error of the quadcopters.

5.2 Comparing virtual and real quadcopters

The goal of using a simulation is to test new ideas, e.g., new algorithms, different sensors, etc. before using them in reality. This approach implies that the results gained from the simulation are comparable with results from experiments conducted in the real world. However, this may not always be the case. De- pending on the software used for simulation, simplifications have been made to reduce CPU load and speed up the simulation. This approach is at the expense of realism which can cause the assumption to break. It is therefore very important to compare the behaviour of real objects with the behaviour of their virtual counterparts. To be more precise, the flight behaviour of a real quadcopter needs to be very close to the flight behaviour of the quadcopter flying in a virtual environment. To compare both, a simple experiment has been conducted. The idea is that a predefined trajectory of desired positions is used to command both, a real and a virtual quadcopter. The output of the system, i.e., the quadcopter, is recorded and used to compare the behaviour of the real and the virtual quadcopter. First a real quadcopter has been commanded by a human pilot. The desired position given as input from the joystick has been recorded. With the aid of an optical tracking system, VICON, the flight of the quadcopter has been recorded. In a second step the recorded input of the human is played back using the same

47 control program. But instead of controlling the real quadcopter, the virtual quadcopter presented in chapter4 has been controlled. The control program outputs the roll and pitch angles, the yaw rate and the thrust using a goal position as input. The desired values are then send to a low level attitude controller running on-board of the quadcopter. Together with the readings of an IMU, the low level controller commands the rotational speeds of the propellers. The quadcopter will then eventually reach the goal position. To ensure that the results are comparable the on-board low level controller of the real quadcopter has been ported to run as part of the Driver of the virtual quadcopter. As the low level controller is written in C, no major adjustments were necessary to cope with different data types or structures. The virtual IMU described in section 4.6 has been utilized to simulate the sensor data of a real IMU. Two different trajectories have been recorded. The first shows a very aggressive flight with many direction changes causing the quadcopter to fly very fast and dynamic. The second trajectory is slower with a less dynamic flight behaviour. With those two trajectories the whole range of desired flight manoeuvres is covered. If the assumptionis correct that the simulation yields comparable results, the same output can be expected.

5.2.1 Results To compare the two flight behaviours the position and orientation of the quadcopter has been recorded. The recordings of the virtual flight had a time offset which resulted from a different startup procedure in simulation compared to the real setup. This has been adjusted by shifting the recordings to match the real with the recorded data. Please note that for the same reason the beginning and the end of the recordings were not considered in the analysis. In all of the following figures a solid line denotes the real quadcopter and a the dashed line denotes the virtual quadcopter. Figures 5.2, 5.3, 5.4 show the position, orientation and the commanded control values of both, the real and the virtual quadcopter given a the moderate trajectory. Figures 5.5, 5.6, 5.7 show the same information but with the dynamic trajectory. For better visualization the commanded angles shown in the figures are filtered using a moving average filter over the last 5 samples. For the moderate condition the mean of the position error between the real and the virtual quadcopter is 0.1189 m with a standard deviation of 0.6461 m. For the dynamic condition the mean error is 0.1897 m with a standard deviation of 0.9386 m. Two videos with a quadcopter flying in the MAL have been uploaded to YouTube. The first video1 shows the quadcopter flying the dynamic trajectory.

1http://www.youtube.com/watch?v=Sa02oZUpu94

48 The second video2 shows the same setup, but the quadcopter is controlled using the moderate trajectory. Both videos are recorded from the same viewpoint, a link to a video taken from another viewpoint can be found in the description of the videos.

3 2 1 0 [m] −1 x −2 −3 0 10 20 30 40 50 60

3 2 1 0 [m]

y −1 −2 −3 0 10 20 30 40 50 60

3 2 1

[m] 0

z −1 −2 −3 0 10 20 30 40 50 60

time [s]

Figure 5.2: Position of the real and the virtual quadcopter given the same moderate speed trajectory. The position of the real quadcopter is drawn with solid lines; the position of the virtual quadcopter in dashed lines. x, y, z-components are color-coded in red-green-blue.

2http://www.youtube.com/watch?v=K0biif13l4A

49 0.5

0 [rad] φ

−0.5 0 10 20 30 40 50 60

0.5

0 [rad] ψ

−0.5 0 10 20 30 40 50 60

0.5

[rad] 0 θ

−0.5 0 10 20 30 40 50 60

time [s]

Figure 5.3: Attitude of the real and the virtual quadcopter given the same moderate speed trajectory. The orientation of the real quadcopter is drawn with solid lines; the orientation of the virtual quadcopter in dashed lines. φ, ψ, θ angles are color-coded in red-green-blue.

0.5

0 [rad] φ

−0.5 0 10 20 30 40 50 60

0.5

0 [rad] ψ −0.5 0 10 20 30 40 50 60

0.5

0 [rad] ˙ θ

−0.5 0 10 20 30 40 50 60

−5 [N] −10 τ

−15 0 10 20 30 40 50 60

time [s]

Figure 5.4: Commands sent to the real quadcopter versus the commands sent to the virtual quadcopter. The continuous line depicts the real quadcopter, the dashed line depicts the virtual quadcopter. φ, ψ, θ,˙ τ- components are color-coded in red-green-blue-black.

50 3 2 1 0 [m] −1 x −2 −3 0 10 20 30 40 50 60

3 2 1 0 [m]

y −1 −2 −3 0 10 20 30 40 50 60

3 2 1

[m] 0

z −1 −2 −3 0 10 20 30 40 50 60

time [s]

Figure 5.5: Position of the real and the virtual quadcopter given the same dynamic trajectory. The position of the real quadcopter is drawn with solid lines; the position of the virtual quadcopter in dashed lines. x, y, z-components are color-coded in red-green-blue.

0.5

0 [rad] φ

−0.5 0 10 20 30 40 50 60

0.5

0 [rad] ψ

−0.5 0 10 20 30 40 50 60

0.5

[rad] 0 θ

−0.5 0 10 20 30 40 50 60

time [s]

Figure 5.6: Attitude of the real and the virtual quadcopter given the same dynamic trajectory. The orientation of the real quadcopter is drawn with solid lines; the orientation of the virtual quadcopter in dashed lines. φ, ψ, θ angles are color-coded in red-green-blue.

51 0.5

0 [rad] φ

−0.5 0 10 20 30 40 50 60

0.5

0 [rad] ψ −0.5 0 10 20 30 40 50 60

0.5

0 [rad] ˙ θ

−0.5 0 10 20 30 40 50 60

−5 [N] −10 τ

−15 0 10 20 30 40 50 60

time [s]

Figure 5.7: Commands sent to the real quadcopter versus the commands sent to the virtual quadcopter. The continuous line depicts the real quadcopter, the dashed line depicts the virtual quadcopter. φ, ψ, θ,˙ τ- components are color-coded in red-green-blue-black.

52 6 Summary

6.1 Conclusion

In this thesis a simulation environment for multiple robots has been designed and implemented. The design of the software allows that the main parts, e.g., the render and physics engines, can be replaced with custom implementations. This encapsulation allows for an extensible framework that is not limited to current software that may become outdated. Multiple robots can be added to the environment. These so called Artifacts are deﬁned using XML-code that gets interpreted at runtime. No extra compi- lation is needed if properties of Artifacts change. Custom code can be loaded at runtime extending the functionality without the need of recompiling the whole simulation environment. This custom code may represent the behaviour of robots or virtual sensors that both have the possibility to access the information within the simulation. All computation is performed in Real-Time, utilizing the capabilities of a RT- kernel running the Linux operating system. It is possible to set up hardware-in- the-loop or human-in-the-loop scenarios with the simulation providing information. The current status of SwarmSimX allows it to be used for several diﬀerent projects within the Human Perception, Cognition and Action group of the Max Planck Institute for Biological Cybernetics. This proves that the simulation can be used in a research environment as a useful tool in the developing process. However, some features of the simulation environment are not fully implemented yet or simply missing. Those will be implemented as soon as the need rises, the work on SwarmSimX will be continued.

6.2 Discussion

6.2.1 Descriptor Descriptor instances are used almost everywhere in the system. The decoupling of information used for describing objects and the corresponding implementation for representing this data proved to be a powerful tool in the architecture of the simulation environment.

53 The interface itself is defined with virtual methods. This way the concrete implementation and the usage of this class are also Independent. Currently only one implementation exists that uses XML-code as a basis, but other ways for defining data can also be implemented. Nonetheless, the use of std::string as a container to receive and provide data may lead to unnecessary overhead in memory and CPU usage. All data is stored in the form of strings with each character using 1 b. Some data types, e.g., double precision values, may need more memory when stored in this form. As an example, the value 23.42424242 needs 11 b of memory, while the double precision representation of this value always occupies 8 b. In addition the double value needs to be serialized into a string and back every time a get-/set-method is called. This takes time and may reduce the overall performance, therefore limiting the use of Descriptors. It is important to keep in mind that the get-/set-methods of Descriptors must not be called to often. It may prove worthwhile to explore whether a modified interface with template methods removes unnecessary serialization and redundant memory usage.

6.2.2 RenderEngine The RenderEngine interfaces allow for an entirely decoupled use of a rendering engine. Instances that are part of the rendering can be created and used without any information about the concrete implementation. Creating instances needs information speciﬁc for the implementation. Descriptors encapsulate the information needed and simultaneously they decouple the information from the rest of the system. The RenderEngine itself is independent from other classes of the simulation, allowing it to be used in a diﬀerent context. SwarmSimX implements the interfaces using the Ogre3D rendering engine, proving the usability of this approach. However, the current status of the RenderEngine interface does not cover all aspects of state-of-the-art render engines. Only cameras, lights and visual objects may be placed in the rendering scene. More advanced topics like actors and animations are still missing.

6.2.3 PhysicEngine The PhysicEngine is one of the core elements of SwarmSimX. All simulated robots may be controlled by inﬂuencing the physical representation of the robot. Forces and torques can be applied to move the robot in the desired direction. However, the PhysicEngine may also be used outside of SwarmSimX. The interfaces are speciﬁcally designed to be decoupled from the rest of the system. This allows the PhysicEngine to be used in other projects, e.g. motion planning. Currently, all the important parts of a physics engine are covered by this interface. Static and dynamic compound shapes may be added to the scene.

54 Also ray casting including a callback interface is provided. Although with these tools a lot of robots can be simulated, some features of state-of-the-art physics engines are missing. Those are vehicles, cloth, soft bodies and ﬂuids. Especially the vehicle representation will be very helpful in designing ground robots.

6.2.4 Architect The Architect is the central piece in SwarmSimX. It creates, conﬁgures and runs the engines, manages the time and timing of the simulation and creates all important facilities needed to run the simulation. This includes the conﬁguration, communication, etc. That is why it needs to be tightly coupled to the implementation of all abstract interfaces. However, this is not desirable in a modular and decoupled framework. The Architects use is limited to this particular Render- and PhysicEngine. It is planned to refactor this part of the system into a more independent structure. Removing the responsibility of creating the engines will remove some of the tight coupling. Instead the user will have the responsibility of instantiating and destroying both engines. Furthermore, other paradigms for stepping the simulation may decouple the Architect even further from the rest of the system. The role of the Architect can then be shifted to a pure delegating instance in SwarmSimX. Patterns like Micro- kernel from Buschmann et al. [4] or Facade from Gamma et al. [11] may provide a useful architectural design, solving the design problems described earlier. Currently the timing of the simulation steps and the update calls of sensors and drivers are triggered by a TimerQueue which is part of the ACETM library. The functionality of precise RT triggering is provided by system libraries that in turn depend on a RT-kernel. Replacing this dependency with a custom implementation of an abstract interface will allow SSX to run on non-Linux systems, like Microsoft Windows R or Mac OS.

6.2.5 Experiments The results of the stress test experiment show that SwarmSimX is capable of simulating multiple robots simultaneously. With the timestep set to 0.003 s or higher the maximum number of quadcopters seems to stagnate. On the other hand the mean error decreases together with the number of violations. A possible explanation may be that in the ﬁrst two conditions the physics engine may be the computational bottleneck. A timestep of τ = 0.002 or less may not suﬃce for the physics engine to complete the calculations, leading to the high number of violations. With a bigger timestep this bottleneck disappears. Instead the control algorithm of the quadcopters start to become unstable. This is because the gain

55 values of the control program were not adjusted to cope with the decreased update rate of the control loop. With the control program being unstable a small number of violations is enough to cause some or all of the quadcopters to crash. Adjusting the gain values of the control program may increase the stability of the controller. This in turn will allow for adding more quadcopters to the scene. In the second experiment the flight behaviours of a real and a virtual quadcopter are compared. In both experiment setups the same trajectories and the same control program were used. The only difference is the physical objects being controlled, with one being the real and the other the virtual quadcopter. The virtual quadcopter tracks the desired positions given by the trajectory in a very similar fashion as the real quadcopter does. This fact leads to a very similar behaviour regarding the control output of the control program, as can be seen in figures 5.4 and 5.7. Only the control outputs for the yaw angle do not match. This may be explained by a broken gyroscope of the quadcopter used for the experiments, this caused very noisy sensor output and therefore an unstable attitude control behaviour. Although the good performance of the virtual quadcopter allows it to be used for developing experiment setups, the error may be reduced even further by finding a set of parameters. Some are the low-level and high-level gains, physical parameters, etc. Further experiments are necessary to validate whether such a model can be constructed.

6.3 Outlook

SwarmSimX is currently used in several experiments at the Max Planck Institute for Biological Cybernetics. New algorithms controlling a swarm of quadcopters are being tested in simulation and validated with real quadcopters. But this does not necessarily have to be the only application of SwarmSimX. With the possibility of adding cameras to the scene visual SLAM algorithms may be implemented, tested and validated. It is also possible to add other types of robots to the simulation. Ground robots (KUKA youBot [18]), service robots (PR2 [32]) or even cars (Google’s autonomous cars), are currently hot topics in robotics research. With SwarmSimX different environments can be created specifically for those robots. These are just some examples of how the simulation could be used in the future. All of those examples have robots as the main focus of research. But what about human-machine interaction? Additional visual information can be presented to the user controlling or interacting with a single or multiple robots. The effect of different visual cues representing the same constellation of robots or environment may then be investigated. One can think of a swarm of robots, ground and airborne, that autonomously rearrange the formation to maximize the information presented to a human op-

56 erator. The operator in turn may then improve the performance of a task he/she was presented with. Let us assume a coverage task, meaning that each of the robots needs to position itself so that the overall coverage of the cameras is op- timal. The human does not directly control each of robots, instead he defines a point or region of interest that needs to be covered. In addition the controller has no knowledge about how many robots are actually in the swarm. This number may even change while flying the swarm, as some robots become redundant and return to a base station. For this kind of setup, many possible aspects can be investigated further. What kind of information needs to be provided to the user so that the task of the human becomes as easy as possible? Does the user need a 3D representation of the environment, automatically reconstructed from the video feeds of each of the robots or are simple top-down-views, similar to blueprints, enough? Can the task be simplified even further by adding some kind of haptic feedback, which may be provided by the control device, or will this additional information increase the workload of the human, resulting in an overall loss in performance? The full control over the scene currently simulated and the possibility to measure interesting effects with no additional cost are among the most important tools that simulation environments provide. The author of this thesis is certain, that simulation environments in general and SwarmSimX in particular will help in the effort of answering these questions.

7 Bibliography

[1] Amy L. Alex, Tad Brunyé, Jason Sidman, Shawn A. Weil, Aptima Inc, and Woburn Ma. From gaming to training: A review of studies on fidelity, immersion, presence, and buy-in and their effects on transfer in PC-based simulations and games, November 2005. [2] Christopher Alexander. The Timeless Way of Building. Oxford University Press, 1979. ISBN 9780195024029. [3] Adrian Boeing and Thomas Bräunl. Evaluation of real-time physics simulation systems. In Proceedings of the 5th international conference on Com- puter graphics and interactive techniques in Australia and Southeast Asia, GRAPHITE ’07, pages 281–288, New York, NY, USA, 2007. ACM. ISBN 978-1-59593-912-8. [4] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal, and Michael Stal. Pattern-Oriented Software Architecture Volume 1: A System of Patterns. Wiley, first edition, August 1996. ISBN 9780471958697. [5] Canonical Ltd. Ubuntu. http://www.ubuntu.com, Accessed October 2011. [6] Stefano Carpin, Mike Lewis, Jijun Wang, Stephen Balakirsky, and Chris Scrapper. USARSim: a robot simulator for research and education. Pro- ceedings 2007 IEEE International Conference on Robotics and Automation, pages 1400–1405, 2007. ISSN 10504729. URL http://ieeexplore. ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4209284. [7] J. Craighead, R. Murphy, J. Burke, and B. Goldiez. A survey of commercial & open source unmanned vehicle simulators. In Proc. IEEE Int Robotics and Automation Conf, pages 852–857, April 2007. URL http://ieeexplore.ieee.org/lpdocs/epic03/wrapper. htm?arnumber=4209196. [8] CRYTEK. cryENGINE 3. http://www.crytek.com/cryengine, Ac- cessed September 2011. [9] Epic Games, Inc. Unreal Engine. http://www.unrealengine.com/, Accessed September 2011.

59 [10] Chiung-Yao Fang, Sei-Wang Chen, and Chiou-Shann Fuh. Road-sign detec- tion and tracking. Vehicular Technology, IEEE Transactions on, 52(5):1329 – 1341, September 2003. ISSN 0018-9545. [11] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, ﬁrst edition, November 1994. ISBN 9780201633610. [12] HiSystems GmbH. MikroKopter. http://www.mikrokopter.de, Ac- cessed October 2011.

[13] Intel R 64 and IA-32 Architectures Developer’s Manual: Combined Vols. 1, 2A, 2B, 3A and 3B. Intel Corporation, May 2011. URL http://www.intel.com/content/www/us/en/processors/ architectures-software-developer-manuals.html. [14] Irrlicht. Irrlicht Engine. http://irrlicht.sourceforge.net/, Ac- cessed September 2011. [15] N. Koenig and A. Howard. Design and use paradigms for gazebo, an open- source multi-robot simulator. 2004 IEEERSJ International Conference on Intelligent Robots and Systems IROS IEEE Cat No04CH37566, 3:2149– 2154, 2004. URL http://ieeexplore.ieee.org/lpdocs/epic03/ wrapper.htm?arnumber=1389727. [16] James Kramer and Matthias Scheutz. Development environments for autonomous mobile robots: A survey. Autonomous Robots, 22(2):101–132, 2007. ISSN 09295593. URL http://www.springerlink.com/index/ 10.1007/s10514-006-9013-8. [17] Lee Thomason. tinyXML. http://www.grinninglizard.com/ tinyxml/, Accessed September 2011. [18] Locomotec. KUKA youBot. http://www.youbot-store.com, Ac- cessed October 2011. [19] Olivier Michel. Cyberbotics Ltd. Webots TM : Professional Mobile Robot Simulation. International Journal of Advanced Robotic Systems, 1:39–42, 2004. URL http://citeseerx.ist.psu.edu/viewdoc/summary? doi=10.1.1.86.1278. [20] Microsoft. Programming Guide for HLSL. http://msdn.microsoft. com/en-us/library/bb509635%28v=VS.85%29.aspx, Accessed September 2011. [21] NVIDIA Corporation. Cg Toolkit. http://developer.nvidia.com/ cg-toolkit, Accessed September 2011.

60 [22] OpenGL. OpenGL Shading Language. http://www.opengl.org/ documentation/glsl/, Accessed September 2011.

[23] OpenSceneGraph. http://www.openscenegraph.org/projects/ osg, Accessed September 2011.

[24] Carlo Pinciroli, Vito Trianni, Rehan O’Grady, Giovanni Pini, Arne Brutschy, Manuele Brambilla, Nithin Mathews, Eliseo Ferrante, Gianni Di Caro, Frederick Ducatelle, Timothy Stirling, Álvaro Gutiérrez, Luca Maria Gambardella, and Marco Dorigo. ARGoS: a modular, multi-engine simulator for heterogeneous swarm robotics. In Proceedings of the IEEE/RSJ Inter- national Conference on Intelligent Robots and Systems (IROS 2011), pages 5027–5034. IEEE Computer Society Press, Los Alamitos, CA, September 2011.

[25] Douglas C. Schmidt and Stephen D. Huston. C++ Network Programming, Volume 1: Mastering Complexity with ACE and Patterns. Addison-Wesley Professional, ﬁrst edition, December 2001. ISBN 9780201604641.

[26] Douglas C. Schmidt and Stephen D. Huston. C++ Network Programming, Volume 2: Systematic Reuse with ACE and Frameworks. Addison-Wesley Professional, ﬁrst edition, November 2002. ISBN 9780201795257.

[27] Technical Committee on Operating Systems and Operational Environments. Information Technology-Portable Operating System Interface (Posix : Part 1 : System Application Program Interface). Inst of Elect & Electronic, ﬁrst edition, October 1990. ISBN 9781559370615.

[28] The MathWorks, Inc. MATLAB. http://www.mathworks.com/ products/matlab/, Accessed September 2011.

[29] The MathWorks, Inc. Simulink. http://www.mathworks.com/ products/simulink/, Accessed September 2011.

[30] Torus Knot Software Ltd. Ogre3D. http://www.ogre3d.org/, Ac- cessed September 2011.

[31] Unity Technologies. Unity 3. http://unity3d.com/, Accessed Septem- ber 2011.

[32] Willow Garage. PR2. http://www.willowgarage.com/pages/pr2/ overview, Accessed October 2011.

Selbständigkeitserklärung

Hiermit versichere ich, dass ich die vorliegende Diplomarbeit selbständig und nur mit den angegebenen Hilfsmitteln angefertigt habe und dass alle Stellen, die dem Wortlaut nach anderen Werken entnommen sind, durch Angaben von Quellen als Entlehnung kenntlich gemacht worden sind. Diese Diplomarbeit wurde in gleicher oder ähnlicher Form in keinem anderen Studiengang als Prüfungsleistung vorgelegt.

Ort, Datum Unterschrift