IN DEGREE PROJECT COMPUTER ENGINEERING,FIRST CYCLE, 15 CREDITS

, STOCKHOLM SWEDEN 2018

Exploration of AirSim using C and Rust in the Context of SafetyCritical Systems

DANIEL AROS BANDA

JOEL WACHSLER

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE

Exploration of AirSim using C

and Rust in the context of

Safety-Critical Systems

JOEL WACHSLER

DANIEL AROS BANDA

Bachelor in Computer ScienceDate: June 20, 2018Supervisor: George UngureanuExaminer: Ingo SanderSwedish title: Utforskning av AirSim med hjälp av C och Rust inomramen för Säkerhetskritiska SystemSchool of Electrical Engineering and Computer Science

iii

Abstract

AirSim is a new simulator developed as a plugin for the Unreal En-gine, aiming to be a useful tool aiding the development and testing ofalgorithms for autonomous vehicles. Due to AirSim still being in itsinfancy there is little to none research available of its possibilities ordetailed guidelines and tutorials on how to use its APIs.

Rust is a new systems programming language with the purpose ofbeing safe, practical and concurrent which through design choices cansolve some of the major drawbacks of the C programming languagesuch as memory leaks, thread management, and segmentation faults.

Researching the features of AirSim and its different ways of communi-cating, we determine the possibility of implementing a custom flightcontroller in Rust and C able to control a drone in the simulator andevaluate the capabilities of Rust compared to C. This is conducted byreading available documentation for AirSim, studying the source codeand learning about the communication protocols used by AirSim.

This thesis results in an implementation of a custom flight controllerin Rust and C that controls a drone in AirSim using a communicationprotocol named MAVLink which enables fine-grained control of themotors. The conclusion made about the comparison of Rust and C isthat both languages were able to implement the safety-critical func-tionality of the flight controller and that Rust provided capabilitieswhich could be useful when developing safety-critical systems.

Keywords

AirSim, Simulation, C, Rust, Safety-Critical Systems, Flight Controller,MAVLink

iv

Sammanfattning

AirSim är en ny simulator utvecklad som ett plugin för Unreal Engi-ne, med målet att fungera som ett hjälpmedel inom utveckling ochtestning av algoritmer för autonoma fordon. På grund av att AirSimfortfarande är väldigt ungt finns väldigt lite forskning tillgänglig omdess möjligheter eller detaljerade riktlinjer och beskrivningar för an-vändningen av dess APIer.

Rust är ett nytt programmeringsspråk med målet att vara säkert, prak-tiskt och parallellt vilket genom designval kan lösa några av de störstaproblemen med programmeringsspråket C som till exempel minness-läckor, trådhantering och segmenteringsfel.

Genom att undersöka funktionerna i AirSim och dess olika sätt attkommunicera, utforskar vi möjligheten av att utveckla en egen flyg-kontroller i Rust och C som kan styra en drönare i simulatorn ochutvärdera Rust i förhållande till C. Detta genomförs genom att läsatillgänglig dokumentation för AirSim, studera källkoden och lära ossde kommunikationsprotokoll som används av AirSim.

Denna avhandling resulterar i implementationen av en egen flygkon-troller i Rust och C som styr en drönare i AirSim med kommunika-tionsprotokollet MAVLink, vilket möjliggör en noggrann kontroll avmotorerna. Slutsatsen gällande Rust och C är att båda språken fun-gerade väl för implementationen av säkerhetsritiska funktioner i flyg-kontrollern samt att Rust erbjöd förmågor som kan visa sig vara an-vändbara vid utveckling av säkerhetskritiska system.

Nyckelord

AirSim, Simulering, C, Rust, Säkerhetskritiska System, Flygkontroller,MAVLink

Contents

1 Introduction 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.6 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . 41.7 Document overview . . . . . . . . . . . . . . . . . . . . . 4

2 Background 6

2.1 AirSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.1 AirSim architecture . . . . . . . . . . . . . . . . . . 72.1.2 Flight controllers . . . . . . . . . . . . . . . . . . . 82.1.3 Vehicles . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Flight controller . . . . . . . . . . . . . . . . . . . . . . . . 92.2.1 Aircraft principal axes . . . . . . . . . . . . . . . . 102.2.2 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.3 PID controller . . . . . . . . . . . . . . . . . . . . . 11

2.3 RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4 MAVLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5 Safety-critical systems . . . . . . . . . . . . . . . . . . . . 132.6 The C programming language . . . . . . . . . . . . . . . . 13

2.6.1 Memory management . . . . . . . . . . . . . . . . 132.6.2 Dangling pointers . . . . . . . . . . . . . . . . . . 14

2.7 The Rust programming language . . . . . . . . . . . . . . 152.7.1 Ownership . . . . . . . . . . . . . . . . . . . . . . . 152.7.2 Borrowing . . . . . . . . . . . . . . . . . . . . . . . 162.7.3 Memory management . . . . . . . . . . . . . . . . 16

v

vi CONTENTS

3 AirSim 18

3.1 AirSim settings . . . . . . . . . . . . . . . . . . . . . . . . 183.2 AirSim API using RPC . . . . . . . . . . . . . . . . . . . . 193.3 AirSim API using MAVLink messages . . . . . . . . . . . 20

3.3.1 MAVLink messages used by AirSim . . . . . . . . 213.4 The notion of time . . . . . . . . . . . . . . . . . . . . . . . 24

4 AirSim findings and controller implementation 25

4.1 System requirements . . . . . . . . . . . . . . . . . . . . . 254.1.1 Operating System and setup . . . . . . . . . . . . 26

4.2 Communication . . . . . . . . . . . . . . . . . . . . . . . . 264.2.1 RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.2 MAVLink . . . . . . . . . . . . . . . . . . . . . . . 274.2.3 Network communication . . . . . . . . . . . . . . 304.2.4 Serial communication . . . . . . . . . . . . . . . . 31

4.3 Enabling the MAVLink distance sensor . . . . . . . . . . 314.4 Multiple vehicle simulation . . . . . . . . . . . . . . . . . 324.5 Custom flight controller . . . . . . . . . . . . . . . . . . . 33

4.5.1 Choosing API . . . . . . . . . . . . . . . . . . . . . 344.5.2 Architecture using MAVLink messages . . . . . . 344.5.3 Implemented functionality . . . . . . . . . . . . . 36

4.6 Code examples . . . . . . . . . . . . . . . . . . . . . . . . 38

5 Evaluation and conclusions 39

5.1 AirSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2 Rust and C in safety-critical systems . . . . . . . . . . . . 405.3 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.4 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.4.1 Rust and C comparison . . . . . . . . . . . . . . . 435.4.2 Flight controller . . . . . . . . . . . . . . . . . . . . 435.4.3 Multiple vehicle simulation . . . . . . . . . . . . . 435.4.4 AirSim . . . . . . . . . . . . . . . . . . . . . . . . . 44

Bibliography 45

List of Figures

2.1 Realistic graphics in AirSim provided by Unreal Engine . 72.2 Core components of the AirSim architecture . . . . . . . . 82.3 The car vehicle in the default environment of AirSim . . 92.4 The drone vehicle in the default environment of AirSim . 92.5 Principal axes of an aircraft . . . . . . . . . . . . . . . . . 102.6 Block diagram of a Proportional Integral Derivative (PID)

controller with a feedback loop . . . . . . . . . . . . . . . 112.7 RPC procedure call overview . . . . . . . . . . . . . . . . 122.8 MAVLink message transportation overview . . . . . . . . 13

3.1 RPC takeoff procedure call example . . . . . . . . . . . . . 203.2 MAVLink message sensing and receiving in AirSim . . . 22

4.1 Spawning multiple vehicles in AirSim . . . . . . . . . . . 334.2 Flight controller (FC) functionality summary . . . . . . . 334.3 How simple flight, AirSim and Remote procedure call

(RPC) are connected . . . . . . . . . . . . . . . . . . . . . 344.4 Custom flight controller architecture . . . . . . . . . . . . 354.5 The drone hovering above the takeoff position using the

custom FC . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

vii

Listings

2.1 Heap memory allocation in C . . . . . . . . . . . . . . . . 142.2 Dangling pointer in C . . . . . . . . . . . . . . . . . . . . . 152.3 Ownership in Rust . . . . . . . . . . . . . . . . . . . . . . 162.4 Borrowing in Rust . . . . . . . . . . . . . . . . . . . . . . . 162.5 Rust compiler preventing a dangling pointer . . . . . . . 172.6 Heap memory management in Rust . . . . . . . . . . . . 173.1 AirSim settings file example . . . . . . . . . . . . . . . . . 193.2 Changing the port of the default Application Program-

ming Interface (API) server . . . . . . . . . . . . . . . . . 193.3 AirSim settings to enable MAVLink communication . . . 213.4 AirSim settings to set the simulation clock to Scalable-

Clock and change its speed to a factor 2 . . . . . . . . . . . 244.1 AirSim API communication in C++ . . . . . . . . . . . . . 274.2 MAVLink message parsing in C . . . . . . . . . . . . . . . 274.3 Example of decoding common MAVLink message sent

by AirSim in C . . . . . . . . . . . . . . . . . . . . . . . . . 284.4 Receiving, parsing and decoding common MAVLink mes-

sages sent by AirSim in Rust . . . . . . . . . . . . . . . . . 284.5 Actuator controls messaging in C . . . . . . . . . . . . . . 294.6 Actuator control messaging in Rust . . . . . . . . . . . . . 304.7 AirSim settings for over the network control . . . . . . . 314.8 AirSim settings to enable serial communication . . . . . . 31

viii

List of Tables

3.1 MAVLink messages AirSim is listening for . . . . . . . . 213.2 MAVLink messages sent by AirSim . . . . . . . . . . . . . 223.3 Fields of a HIL_ACTUATOR_CONTROLS message . . . . 233.4 Fields of a HIL_SENSOR message . . . . . . . . . . . . . . 23

ix

Acronyms

API Application Programming Interface. 2–5, 7, 8, 18–20, 25, 26, 29–31, 40, 42, 44

CC Companion computer. 7

FC Flight controller. 1–4, 7–12, 18, 22, 24–27, 30, 37–40, 42–44

GC Garbage Collector. 14, 17

GCS Ground Control Station. 12

GPS Global Positioning System. 10–12, 27

IDE Integrated development environment. 41

IMU Inertial Measurement Unit. 10, 12

JSON JavaScript Object Notation. 18

MAVLink Micro Air Vehicle Link. 8, 12, 18–23, 26–36, 40, 42–44

PID Proportional Integral Derivative. 11, 27, 38, 43

RC Remote control. 7–9

RPC Remote procedure call. 8, 12, 19, 20, 26, 30, 31

segfault Segmentation fault. 14, 17, 39, 41

UART Universal asynchronous receiver-transmitter. 43

UDP User Datagram Protocol. 20, 31, 35, 43

x

Chapter 1

Introduction

Developing software systems where the consequences of failure mayresult in death, damage to the environment or serious financial loss,known as safety-critical systems [7], usually have a high cost of verifi-cation and validation [19]. Simulating these systems can reduce thesecosts by finding design flaws in the early stages of development andengineers being able to model the system without resorting to proto-typing [8].

1.1 Background

AirSim is a new open source simulator developed by Microsoft AI &Research [18]. The goal of this simulator is to be a useful tool in the de-velopment of autonomous vehicles and the gathering of training datafor machine intelligence [15]. Connecting the simulator to a safety-critical system, in the form of a Flight controller (FC), developed inthe C programming language and the new programming languageRust [9] the suitability for each of these languages in the context ofsafety-critical systems can be compared and evaluated without the us-age of a real drone.

1.2 Problem

Due to the young age of AirSim, there is little to none research basedupon the simulator, making it unclear of its potential and capabilities.Therefore this thesis seeks to explore the functionality and features

1

2 CHAPTER 1. INTRODUCTION

AirSim offers and how to best take advantage of these by answeringhow AirSim is structured and what it can be used for.

The programming languages C and Rust have many features whichare well suited for the development of safety-critical systems but dueto the fact that Rust is relatively new, there is little research comparingthese languages.

To research AirSim and compare the C and Rust programming lan-guages in the context of safety-critical systems this thesis seeks to an-swer if and how low-level communication, i.e. accessing sensor read-ings and controlling each individual motor of a vehicle, can be donein AirSim with these languages, if its possible to develop a custom FCwith them and if its possible to port the custom FC to a microcontroller.

1.3 Purpose

New technologies such as a new simulator or a new programminglanguage are usually accompanied by claims of their capabilities butmay not always live up to them. Unbiased information can sometimesbe hard to find for these new technologies due to the lack of researchregarding them. The main purpose of this thesis is therefore to providea clearer picture of what is possible in AirSim and how it is achievable.This will lay the foundation for future research projects which maywish to use AirSim and provide a simple introduction to the relevantareas. The thesis also seeks to contribute to a better understanding ofthe advantages and disadvantages of the new programming languageRust compared to C in the context of safety-critical systems.

1.4 Goals

The problems presented in section 1.2 are divided into three parts,where the first two are primary goals and the third is secondary goals.First, we determine the possibilities in AirSim by discovering whatAPIs are available and how to interact with them. Second, we evalu-ate the two studied languages in the context of safety-critical systemsby implementing a custom FC using the APIs available. These twoparts are summarized as the following sub-goals:

CHAPTER 1. INTRODUCTION 3

• Understanding the architecture of AirSim and how its compo-nents interact with each other.

• Researching what AirSim APIs are available, what do they pro-vide and how do we communicate with them and determine if itis possible to access these APIs with the two studied languages(Rust and C)

• Evaluate the support for simulating multiple vehicles and con-trolling them with different controllers

• Research what notions of time AirSim have

• Implement a custom FC in C and Rust performing basic function-ality such as taking off, landing and pitch, roll, yaw and altitudestabilization

• Evaluate the current state of Rust compared to C within the con-text of safety-critical systems.

Third, we improve the custom controller by porting it to a microcon-troller and implement more advanced functionality and features. Thisis split into the following sub-goals:

• Port the FC to a microcontroller

• Implement waypoint functionality for the FC

• Implement collision detection for the FC

• Control a vehicle in AirSim over the network

1.5 Method

The basic categories of research methods are Quantitative researchmethod and Qualitative research method where quantitative appliesto projects that are numerical and qualitative to non-numerical projects [4].The quantitative method requires the hypothesis to be measurable withquantifications, evaluable and answerable [4]. The qualitative methodconcerns understanding meanings, opinions and behaviors to reachtentative hypotheses and theories or to develop computer systems andinventions [4].

4 CHAPTER 1. INTRODUCTION

Due to the nature of these two categories, we decided to use a qualita-tive research method because it is best suited to reach the goals listedpreviously. Different research methods among this category were ex-amined such as fundamental research, conceptual research and ap-plied research among others. Applied research and conceptual re-search were deemed unsuitable because applied research builds uponexisting research and applies data from the real work to solve prob-lems and develop practical applications, and conceptual research isused for developing new concepts or interpreting existing concepts [4].Therefore, fundamental research was chosen as it involves fundamen-tal principles and theories resulting in innovation and solutions to oldproblems which allow new theories to be developed. An inductive re-search approach was chosen due to it involving forming theories fromobservations and also being able to be used in the development of ar-tifacts [4]. Further, the research strategy of exploratory research waschosen due to it identifying key issues and variables to define goalsinstead of providing definite answers to specific issues [4].

1.6 Delimitations

The purpose of this thesis is to present some of the features, APIs, andways of communicating with AirSim relevant to FC implementations,and the use of C and Rust in the context of safety-critical systems.Therefore this thesis will not go into the inner workings of AirSim,how to extend its functionality or detailed description of the higherlevel API functionality provided, but will instead focus on the APIsneeded to implement a custom FC. This thesis is also not a tutorial onthe specifics of how to implement an FC or a C or Rust tutorial. Itinstead only presents the possibility of implementing a safety-criticalsystem in the form of a custom FC in the specified languages with thehelp of AirSim.

1.7 Document overview

Chapter 2: Background introduces the topics this thesis will cover andexplains the basic theory behind the different protocols and APIs used.

CHAPTER 1. INTRODUCTION 5

Chapter 3: AirSim describes the research conducted in order to com-municate with AirSim.

Chapter 4: AirSim findings and controller implementation containsthe findings of this thesis by presenting system requirements, how touse the APIs, enable the distance sensor, communication with AirSimover the network, and the description, implementation, and result ofthe custom flight controller.

Chapter 5: Evaluation and conclusions evaluates the project and itsresults and suggest possible future improvements on the research donein the thesis.

Chapter 2

Background

2.1 AirSim

AirSim [18] is a new open source simulator developed by Microsoft asan open source plugin for Unreal Engine [22]. It was publicly madeavailable in February of 20171 and it aims to help the development ofautonomous vehicles by trying to narrow the gap between simulationand reality [16].

Unreal Engine [22] is a game engine available on all major platformssuch as Windows, Linux and, Mac. It has open source code access,making the source code accessible without being an open source project,and offers visually realistic graphics by offering modern graphics fea-tures such as photometric lights, planar reflections, lit translucencyamong others [6], see figure 2.1, and a marketplace2 for assets suchas environments, animations, textures among others. Due to the factthat AirSim is a plugin for the Unreal Engine, it can be used in anyenvironment developed for the Unreal Engine, such as those availablein the marketplace. Figure 2.1 shows AirSim as a plugin for an envi-ronment retrieved from the marketplace.

1Initial commit of AirSim: https://github.com/Microsoft/AirSim/commit/bf3dcf9b5b6a236b88cb590c5cf0e466d480b2ae

2Marketplace is found at https://www.unrealengine.com/marketplace

6

CHAPTER 2. BACKGROUND 7

Figure 2.1: Realistic graphics in AirSim provided by Unreal Engine

2.1.1 AirSim architecture

AirSim consists of six core components namely the; vehicle model,environment model, sensor models, physics engine, rendering engineand a public API layer, see figure 2.2.According to the developers of AirSim [17] running the simulation re-sults in the FC, which will be discussed in section 2.2, shown in thepreviously mentioned figure being continuously fed with sensor datafrom the sensor model and the controller can, in turn, calculate actu-ator signals. These signals are handled by the vehicle model whichin turn computes forces and torques generated by the simulated actu-ators such as thrust generated by the rotors of a drone. The vehiclemodel also contains data about the vehicle such as mass, inertia, drag,and friction.

The forces and torques calculated in the vehicle model together withthe data about the vehicle are passed as input to the physics enginewhich together with environmental models for gravity, air density, airpressure, magnetic field and global coordinates calculates the kine-matic states of vehicles and other bodies in the simulated environment.These kinematic states are passed to the sensor model which processesthese states into sensor data.

The desired state input for the FC can be provided either by an Re-mote control (RC) or by a Companion computer (CC). The RC com-municates with the FC directly and the CC communicates via the API

8 CHAPTER 2. BACKGROUND

Perception data

Kinematics

Pose

Forces, Torques

Estimated state, sensor and perception data

Desired state

Sensor data

Sensor data

Gravity, Air pressure etc

Estimated state

Actuator signals

Flightcontroller

Simulator

API Layer

Sensor model

Vehicle model

Renderingengine

Physics engine

Environmentmodel

Desired stateCompanion computer

Figure 2.2: The core components of the AirSim architecture and theirinteractions. Inspired by the architecture overview presented in Air-Sim: High-Fidelity Visual and Physical Simulation for AutonomousVehicles [17]

layer which provides the CC with sensor data, estimated vehicle stateand commands to move the vehicle. A CC can perform more complexcalculations such as computing mission planning by for example bydetermining the next waypoint or computing desired trajectory.

2.1.2 Flight controllers

AirSim has a default FC called simple flight3 requiring configuration touse. This FC can be controlled either via an RC or programmaticallythrough the API layer with the use of RPC, which is explained in detailin section 2.3. Third party FCs can be used if they support communica-tion through Micro Air Vehicle Link (MAVLink) messages, explainedfurther in section 2.4, and these can be configured to be controlled ei-ther via RC or programmatically as well.

3Simple flight documentation: https://github.com/Microsoft/AirSim/blob/b97d57b7dfe66b76c304eeb022f98a06cf2c6de6/docs/simple_flight.md

CHAPTER 2. BACKGROUND 9

2.1.3 Vehicles

There are currently two vehicles available by default in AirSim: a carand drone, see figure 2.3 and 2.4 respectively. The car can be controlledprogrammatically or with a regular keyboard and the drone can be ei-ther controlled programmatically or with a connected RC. In this the-sis, we will only look at how to control the drone and will not use thecar vehicle at all.

Figure 2.3: The car vehicle in the default environment of AirSim

Figure 2.4: The drone vehicle in the default environment of AirSim

2.2 Flight controller

In this thesis, a Flight controller (FC) will refer to a system stabilizingan aerial vehicle in flight when controlled through an RC or autopilot.It estimates a current state of the vehicle by reading various sensordata and tries to achieve the desired state by controlling actuators onthe vehicle, such as the motors in a drone. In this section, it will explainthe kinds of sensors and devices an FC might use to estimate its currentstate and how this state is represented.

10 CHAPTER 2. BACKGROUND

2.2.1 Aircraft principal axes

An aerial vehicle in flight can move around 3 axes generally referredto as pitch, roll, and yaw, see figure 2.5 where a visual representationof the 3 axes are shown. Maintaining the stability of these 3 axes at thedesired angle while in flight is the main task of the FC.

Figure 2.5: A visual representation of the principal axes of an aircraft.The red rotors are at the front of the drone and the white is at the rear

2.2.2 Sensors

An FC uses a combination of sensors usually referred to as an Iner-tial Measurement Unit (IMU) to retrieve data required to estimate itscurrent state such as the rotational angle around a certain axis, currentheading or acceleration known as inertial navigation [25]. An IMUcommonly consists of three orthogonal gyroscopes and three orthogo-nal accelerometers which measure angular velocity and linear acceler-ation respectively [25]. The third kind of sensor, the magnetometer, issometimes found in an IMUs which measure magnetic field strengthin a given direction. The magnetometers allow the north direction tobe found, and are sometimes used to together with the gyroscopes andaccelerometers to reduce the impact of random errors from the sensors[26].

Advanced FCs may also utilize a Global Positioning System (GPS) sen-sor receiving information from satellites resulting in the drone to be

CHAPTER 2. BACKGROUND 11

able to determine its global position in the form of latitude and longi-tude coordinates, altitude and velocity [3]. An FC with the access toa GPS with the mentioned functionality can perform complex opera-tions such as stabilizing a drone at a certain height or moving it to aspecified location.

2.2.3 PID controller

In order to stabilize the roll, pitch and yaw angle a PID controller maybe used. It is a simple controlling algorithm able to solve a great num-ber of controller problems without resorting to complex control the-ory [23]. In general, a PID controller works by using a combinationof the desired state called the setpoint and the current state called thefeedback, see figure 2.6. The goal of the PID controller is to make thecurrent state come as close as possible to the desired state in the short-est amount of time without over- or undershooting the setpoint. Thisis done by using the difference of the setpoint and feedback as the er-ror and acting on it with the three parts of the PID controller which areas follows:

• Proportional: acting on the current error

• Integral: acting on the long-term error by summing all previouserrors

• Derivative: acting on the current change of the error

These three parts are summed resulting in an output. The three partsof the PID controller are tuned with constants in order to improve theperformance.

desiredstate error Integral

Proportional

Derivative

output

feedback

System

Figure 2.6: Block diagram of a PID controller with a feedback loop

12 CHAPTER 2. BACKGROUND

2.3 RPC

Remote procedure call (RPC) involves a computer program invokinga procedure to execute in a different program, which is not limited tothe current computer [13]. An example of how a RPC call may be usedis shown in figure 2.7 where the client creates a procedure call whichis encoded and sent over, for example, ethernet or serial to a serverthat decodes, parses and processes the requested procedure. After theprocedure is finished the server will return a value from the call as aresponse to the client.

Figure 2.7: RPC procedure call overview

Create

Client

Receive

Receive

Ethernet/Serial

Return value

Server

Parse

Encode

Procedure call

Send

Return value Binaryencoded

procedure call

Send

Decode

Binaryencoded

procedure call

Return value

Parse

Procedurecall

2.4 MAVLink

Micro Air Vehicle Link (MAVLink) is a message marshalling library,which is the process of transforming a memory representation of anobject to a data format suitable for storage of transmission. It is usedfor message communication between small unmanned vehicles, inter-communication with subsystems within a vehicle and between vehi-cles and ground computers giving commands to unmanned vehiclesalso known as a Ground Control Station (GCS) [10]. This communica-tion can for example be; GPS readings, IMU readings, actuator controlvalues etc.

An example of how a MAVLink message is transported is shown in fig-ure 2.8 where the message is created by the flight controller, encodedto binary form in order to be transferred over ethernet or serial andreceived by the GCS which decodes and parses the message. The GCScan also send messages to the FC which is also shown in the figure.

CHAPTER 2. BACKGROUND 13

Figure 2.8: MAVLink message transportation overview

Create

Flight Controller

Create

GCS

Receive

Receive

Ethernet/Serial

EncodeMAVLinkmessage

Send

Binary encodedMAVLink message

Parse

MAVLinkmessageDecodeBinary encoded

MAVLink message

Decode Binary encodedMAVLink message Encode MAVLink

message

Send

Binary encodedMAVLink message

Parse

MAVLinkmessage

2.5 Safety-critical systems

A safety-critical system is a system whose failure may result in death,damage to the environment or serious financial loss [7]. Examples ofthese systems are; medical devices, aircraft flight control, weapons andnuclear systems [21]. Because the nature of a failure in a safety-criticalsystem the verification and validation costs of such systems are usu-ally high [19]. To decrease the risk of failure these systems are oftendeveloped using older techniques where the strength and weaknessesare known, rather than newer technologies where the long-term prob-lems are unknown [19]. Because of this, the C programming languageis the go-to language for many organizations when it comes to the de-velopment of these systems [5] because of its long history, extensivetool support such as code analyzers, debuggers and test support tools,and the choice of mature and stable compilers [5].

2.6 The C programming language

The C programming language first appeared in the early 70s [14] andhas since become one of the most widely used programming languageof all time [20]. One of the spirits of this language is according to theC89 Committee to "Trust the programmer" [11] and some of the resultsof this rationale will be presented in the following subsections.

2.6.1 Memory management

Heap memory management in C is handled manually by the program-mer. For example, if a programmer wants to create and return an array

14 CHAPTER 2. BACKGROUND

from a function, he or she is responsible for allocating and deallocatingthe heap memory, as can be seen in listing 2.1.

1 int* foo() {2 int* array = malloc(sizeof(int) * 2); // Allocate 2 integers on the heap3 array[0] = 1; // Assign the first integer on the heap to 14 array[1] = 2;56 return array;7 }89 int main() {

10 int *array = foo(); // Call the function `foo`11 printf("First element: %d, Second element: %d\n", array[0], array[1]);12 free(array); // Deallocate the heap memory13 }

Listing 2.1: Heap memory allocation in C

An advantage of being responsible for memory management is thatthe execution time of the program is more predictable since the mem-ory management is handled manually and not by a Garbage Collector(GC). A GC handles the deallocation of unused heap memory auto-matically and may run at any given time without the knowledge ofthe programmer. A disadvantage is if the memory is not deallocated,and the reference to it is lost, it cannot be reclaimed resulting in what iscalled a memory leak. Memory leaks can lead to the system running outof memory which could cause the program or even the system runningit to crash.

2.6.2 Dangling pointers

A dangling pointer is a pointer that refers to invalid data. This prob-lem occurs when a pointer referencing invalid data is dereferenced.This will lead to undefined behavior in C and may result in either thewanted data or garbage data being retrieved or in worse cases Seg-mentation fault (segfault) which is an error occurring when a processtries to access data it is now allowed to access. An example of how adangling pointer can occur is shown in listing 2.2.

CHAPTER 2. BACKGROUND 15

1 int* foo() {2 int array[2]; // Create an integer array on the stack3 array[0] = 10; // Assign the first value of the array to 1045 return array; // Return a pointer to the array6 } // The content of the `array` variable is deallocated from the stack78 int main() {9 int* array = foo(); // Call the `foo` function and store its return pointer in the

10 // `array` variable1112 // Accessing the content of the `array` variable pointer is undefined behaviour13 // because the content got deallocated from the stack when the scope of14 // the `foo` function ended15 printf("Array[0]: %d\n", array[0]);16 }

Listing 2.2: Dangling pointer in C

2.7 The Rust programming language

Rust is a new programming language [9] with the goals of being safe,concurrent and practical without sacrificing efficient code and provid-ing a comfortable level of abstraction. According to the developers ofRust, other languages with the same abstraction level as Rust do ei-ther; pay too little attention to safety, have poor concurrency support,are not practical or offer limited control over resources [2].

2.7.1 Ownership

One of the central features of Rust is a featured called ownership. Own-ership applies a set of rules [24]:

1. Each resource has a variable called its owner.

2. There can only be one owner at a time, but this ownership can betransferred.

3. When the owner goes out of scope, i.e. the region where vari-ables are valid, the resource will be deallocated.

Examples of these rules are shown in listing 2.3 where the first rule isshown on line; 1, 2 and 8, the second rule on line; 2 and 14, and thethird rule on line 7 to 10.

16 CHAPTER 2. BACKGROUND

1 let str = "Hello!"; // Declare a new variable called `str`, owned by the current scope2 let len = calculate_length(str); // Pass ownership of the `str` variable to the3 // scope of the `calculate_length` function and store4 // the result in the current scope in the `len` variable5 // owned by the current scope67 { // Declare a new scope8 let my_num = 5; // Declare a new immutable variable called `my_num` where9 // the current scope is the owner

10 } // The scope is over and `my_num` is deallocated1112 // compilation error: value moved (`str` is no longer accessible/owned by this scope13 // because the ownership was transferred when `calculate_length` was called)14 println!("The length of '{}' is {}", str, len);

Listing 2.3: Ownership in Rust

2.7.2 Borrowing

Giving away ownership of resources is not always the best choice. Anexample of this is if further access to the variable is needed, see list-ing 2.3 line 3 and 13. To solve this there exists another way of pass-ing around variables without giving up ownership known as borrow-ing [12]. This works by passing the reference of the resource to anotherscope and promising not to use the resource while it is active in theother scope. While the resource is active in another scope it is knownas being frozen in the owner’s scope and an example of how this worksis shown in listing 2.4.

1 let str = "Hello!";2 let len = calculate_length(&str); // Passing the reference of `str`, denoted by the `&`3 // symbol, to `calculate_length`, also known as borrowing.4 // While `str` is used in `calculate_length` the current5 // scope is not allowed to use it, the resource is known as6 // being `frozen`78 // No compilation error because `str` became `unfrozen` when9 // `calculate_length` finished

10 println!("The length of '{}' is {}", str, len);

Listing 2.4: Borrowing in Rust

2.7.3 Memory management

The result of using the ownership model described in subsection 2.7.1and 2.7.2 is that Rust guarantees memory safety by preventing seg-faults without the need of a GC, see listing 2.5.

The Rust compiler can also reason about resources stored on theheap without a GC or manual memory management by deallocatingresource without an owner, see listing 2.6.

CHAPTER 2. BACKGROUND 17

1 let ptr: &i32; // Declare an integer pointer23 { // Declare a new scope4 let ptr2: i32 = 10; // Declare a new integer with a value of 105 ptr = &ptr2; // Make `ptr` borrow `ptr2`, this results in `ptr2` being frozen6 } // Compile error: `ptr2` is frozen and at the same time being removed from7 // the stack, this is not allowed by the Rust compiler89 // `ptr` is a dangling pointer pointer here meaning its resource

10 // is undefined (because the resource it was pointing to, `ptr2`, is gone),11 // luckily a compile error occurred before the next line got executed12 println!("ptr: {}", *ptr);

Listing 2.5: The Rust compiler preventing a potential seg-fault/dangling pointer

1 let item1 = Box::new(10); // Allocating a new integer on the heap, `Box` is a variable2 // type for a pointer on the heap3 let item4: Box<i32>;45 { // Declare a new scope6 let item2 = Box::new(20); // Allocating a new integer on the heap7 let item3 = Box::new(30);8 item4 = item3; // Ownership of `item3` is passed to `item4`9 } // The `item2` now out of scope and there is no owner of the heap

10 // resource, this results in the resource being deallocated1112 // output: `Item4: 30`13 println!("Item4: {}", item4);

Listing 2.6: Heap memory management in Rust

Chapter 3

AirSim

In this chapter the information gathered regarding AirSim and its fea-tures is described. It will explain how the simulator can be customizedusing its settings in section 3.1, the different APIs available and howthey are used in section 3.2 and 3.3, and what notion of time it offers insection 3.4. This information was gathered by reading the documenta-tion, issues posted by other users in AirSim’s GitHub repository andby studying the source code.

3.1 AirSim settings

AirSim allows extensive customization through the use of its settingsfile1 for various components such as the vehicle, physics engine, FCetc. These settings are managed in a JavaScript Object Notation (JSON)formatted file named settings.json located in the AirSim folder createdby AirSim when started for the first time. An example of the contentsof this settings file is shown in listing 3.1.The content of this example settings file will tell AirSim to use the Mul-tirotor vehicle (drone) as default on line 3 instead of having to chose be-tween the Multirotor and Car when initializing a new simulation. Thecommunication setting loaded for this the current vehicle is defined bythe DefaultVehicleConfig entry on line 4. This entry tells AirSim to usethe settings of the PX4 autopilot which is a third party FC/autopiloton line 6. Because this FC uses MAVLink messages, presented in sec-

1A list of the available settings and their defaults can befound at https://github.com/Microsoft/AirSim/blob/361b538ac6cc306c889b48021eb8b381108cee99/docs/settings.md

18

CHAPTER 3. AIRSIM 19

1 {2 "SettingsVersion": 1.0,3 "SimMode": "Multirotor",4 "DefaultVehicleConfig": "MyCustomSettings",5 "MyCustomSettings": {6 "FirmwareName": "PX4"7 }8 }

Listing 3.1: AirSim settings file example

tion 3.2, to communicate, AirSim will switch to that way of commu-nication by sending and receiving MAVLink messages. AirSim alsoprovides commonly used predefined settings. Two of these settingsare named PX4 and SimpleFlight and can be enabled by changing theDefaultVehicleConfig entry to their name. Any setting not defined in thesettings file will contain the default values described in the settingsdocumentation.

3.2 AirSim API using RPC

AirSim exposes an API accessible through RPC on localhost port 41451by default. To change the port number for the RPC server providingaccess to this API the settings file needs to be changed according tolisting 3.2 where the port is changed to 41600.

1 {2 "SettingsVersion": 1.0,3 "SimMode": "Multirotor",4 "DefaultVehicleConfig": "SimpleFlight",5 "SimpleFlight": {6 "ApiServerPort": 416007 }8 }

Listing 3.2: Changing the port of the default API server

The procedures exposed by this API are implemented by the defaultflight controller, simple flight, and some of them are:

• armDisarm: enables the usage of the motors on the drone

• takeoff : makes the drone take off to the provided altitude

• land: lands the drone

• hover: hovers the drone at the current altitude

20 CHAPTER 3. AIRSIM

• moveToPosition: moves the drone to the provided destination

The official documentation2 for the procedures available only describesthe most common procedures but provides no detailed description ofwhat these procedures do or how to use them. To discover all theavailable procedures one must go through the source code3

Figure 3.1: RPC takeoff procedure call example

takeoff

Client

Receive

Receive

Ethernet

Return true/false

AirSim RPCserver

true/false

Encode

Procedure call

Send

Return value Binaryencoded

procedure call

Send

Decode

Binaryencoded

procedure call

Return value

takeoff

Procedurecall

As previously mentioned, these messages are transferred via RPC toAirSim and a visualization of how this is done is presented in fig-ure 3.1. This figure shows how the takeoff command is created bythe user, binary encoded, transferred over ethernet and then decoded,parsed and processed by AirSim. After AirSim has processed the pro-cedure call it will return true or false whether the call succeeded orfailed respectively by sending the response back to the user.

3.3 AirSim API using MAVLink messages

Changing the AirSim settings to what is shown in listing 3.3 results inAirSim sending MAVLink messages on localhost port 14560. Line 6of the listing enables the MAVLink message API, line 7 makes AirSimsend the MAVLink messages over User Datagram Protocol (UDP) in-stead of serial and line 8 changes the port where MAVLink messagesare sent and received.

2AirSim RPC API documentation: https://github.com/Microsoft/AirSim/blob/b97d57b7dfe66b76c304eeb022f98a06cf2c6de6/docs/apis.md

3Most drone procedures are available in the DroneControllerBase headerfile in AirSim: https://github.com/Microsoft/AirSim/blob/b97d57b7dfe66b76c304eeb022f98a06cf2c6de6/AirLib/include/vehicles/multirotor/controllers/DroneControllerBase.hpp#L70

CHAPTER 3. AIRSIM 21

1 {2 "SettingsVersion": 1.0,3 "SimMode": "Multirotor",4 "DefaultVehicleConfig": "PX4",5 "PX4": {6 "FirmwareName": "PX4",7 "UseSerial": false,8 "UdpPort": 145609 }

10 }

Listing 3.3: AirSim settings to enable MAVLink communication

3.3.1 MAVLink messages used by AirSim

There is no documentation available for what MAVLink messages areused by AirSim, but by inspecting the source code of the MAVLinkmessage handler4 it is discovered that AirSim is listening for the mes-sages listed in table 3.1 and sending5 the messages listed in table 3.2.

Table 3.1: MAVLink messages AirSim is listening for. Descriptionsource: MAVLink common message set [1]

Message Description

HEARTBEAT The heartbeat message shows that asystem is present and responding.

STATUSTEXT Status text messageCOMMAND_LONG Send a command with up to seven pa-

rameters to the MAVHIL_CONTROLS Hardware in the loop control outputsHIL_ACTUATOR_CONTROLS Sent from autopilot to simulation (re-

placement for HIL_CONTROLS)

4MAVLink message handler in AirSim: https://github.com/Microsoft/AirSim/blob/361b538ac6cc306c889b48021eb8b381108cee99/AirLib/include/vehicles/multirotor/controllers/MavLinkDroneController.hpp#L565

5MAVLink sensor message sender: https://github.com/Microsoft/AirSim/blob/361b538ac6cc306c889b48021eb8b381108cee99/AirLib/include/vehicles/multirotor/controllers/MavLinkDroneController.hpp#L776

22 CHAPTER 3. AIRSIM

Table 3.2: MAVLink messages sent by AirSim. Description sourcefor all messages except DISTANCE_SENSOR: MAVLink common mes-sage set [1]

Message Description

HIL_SENSOR The IMU readings in SI units in NED bodyframe

DISTANCE_SENSOR Sends the readings of a distance sensorHIL_GPS The global position, as returned by the Global

Positioning System (GPS)

An example of how these MAVLink messages are sent and receivedfrom AirSim is shown in figure 3.2. This figure shows how a messageis created by the FC and encoded to binary before being sent to AirSimwhich decodes the message and is able to read its content. AirSim alsosends messages in the same manner back to the FC.

HIL_ACTUATOR_CONTROLS

Flight Controller

HIL_SENSOR

AirSimMAVLinkserver

Receive

Receive

Ethernet/Serial

EncodeMAVLinkmessage

Send

Binary encodedMAVLink message

HIL_ACTUATOR_CONTROLS

MAVLinkmessageDecodeBinary encoded

MAVLink message

Decode Binary encodedMAVLink message Encode MAVLink

message

Send

Binary encodedMAVLink message

HIL_SENSOR

MAVLinkmessage

Figure 3.2: HIL_ACTUATOR_CONTROLS message sending andHIL_SENSOR receiving example

The number of parameters and what they do differs for each MAVLinkmessage, the HIL_ACTUATOR_CONTROLS, for example, takes 4 pa-rameters (see table 3.3) where the controls parameter is a float arraytaking 16 values from -1 to 1 where each value is mapped to an actua-tor, with the purpose of for example controlling the thrust of a motoron a drone in AirSim. This results in this message supporting up to 16actuators on the controlled vehicle.

Another MAVLink message example is the HIL_SENSOR message tak-ing 15 parameters (see table 3.4) which includes sensor reading for the;accelerator sensor, gyro sensor, magnetic field sensor, pressure sensorand temperature sensor.

CHAPTER 3. AIRSIM 23

Table 3.3: Fields of a HIL_ACTUATOR_CONTROLS message. Source:MAVLink common message set [1]

Field Name Type Description

time_usec uint64_t Timestamp (Units: us)controls float[16] Control outputs -1 .. 1. Channel assign-

ment depends on the simulated hardware.mode uint8_t System mode, includes arming state.flags uint64_t Flags as bitfield, reserved for future use

Table 3.4: Fields of a HIL_SENSOR message. Source: MAVLink com-mon message set [1]

Field Name Type Description

time_usec uint64_t Timestamp (Units: us)xacc float X acceleration (m/s^2) (Units: m/s/s)yacc float Y acceleration (m/s^2) (Units: m/s/s)zacc float Z acceleration (m/s^2) (Units: m/s/s)xgyro float Angular speed around X axis in body frame

(rad / sec) (Units: rad/s)ygyro float Angular speed around Y axis in body frame

(rad / sec) (Units: rad/s)zgyro float Angular speed around Z axis in body frame

(rad / sec) (Units: rad/s)xmag float X Magnetic field (Gauss) (Units: gauss)ymag float Y Magnetic field (Gauss) (Units: gauss)zmag float Z Magnetic field (Gauss) (Units: gauss)abs_pressure float Absolute pressure in millibar (Units: mbar)diff_pressure float Differential pressure (airspeed) in millibar

(Units: mbar)pressure_alt float Altitude calculated from pressuretemperature float Temperature in degrees celsius (Units:

degC)fields_updated uint32_t Bitmask for fields that have updated since

last message

24 CHAPTER 3. AIRSIM

3.4 The notion of time

AirSim offers the possibility of using two different types of clocks; ascalable and steppable clock. The scalable clock allows us to changethe speed of the Simulation Clock relative to that of a wall clock. Forexample, if the Simulation clock speed is set to 5.0 it would yielda factor of 5 compared to the Wall clock, meaning that if 5 secondselapse in the simulator, only 1 second would have elapsed in the realworld. Contrarily if the Simulation clock is set to something lowerthan 1, such as 0.1, the Simulation clock would be a factor 10 slowerthan the Wall clock. This allows us to set the speed of the simulationat will, providing the possibility of performing more simulations inlesser time if wanted.

The disadvantage of running the Simulation clock at a faster rate thanthe wall clock results in the simulation becoming less accurate. Forexample, while running the simulation at higher speeds may resultin collision detection for artifacts not register properly. However, ifthe clock is set to a slower rate the simulation will generally yield amore accurate simulation. This is explained in the documentation forsettings6 under the “Clock” section.

The steppable clock is only usable by the default FC (simple flight).This clock allows the simulation to be stopped at any point and steppedthrough step by step if desired. To change the clock speed the fieldClockSpeed needs to be added to the settings file as shown in listing3.4. This field can hold a value between 0.1 to the maximum value ofa float and is the factor by which the simulation speed will run.

1 {2 "SettingsVersion": 1.0,3 "SimMode": "Multirotor",4 "ClockType": "ScalableClock",5 "ClockSpeed": 26 }

Listing 3.4: AirSim settings to set the simulation clock to ScalableClockand change its speed to a factor 2

6The documentation for settings in AirSim: https://github.com/Microsoft/AirSim/blob/b97d57b7dfe66b76c304eeb022f98a06cf2c6de6/docs/settings.md

Chapter 4

AirSim findings and controller

implementation

This chapter presents the results and findings of this thesis. The sys-tem requirements to be able to use AirSim are presented in section 4.1.How to use the different APIs available in AirSim, and the differentkinds of communication AirSim can use are explained in section 4.2.In section 4.3 it is explained how to enable AirSim to send data from adistance sensor. Section 4.4 presents how to simulate multiple vehiclesand lastly the design, implementation and results of the custom flightcontroller are presented in section 4.5

4.1 System requirements

Because of the graphics requirements of Unreal Engine, the initial com-puters used were not powerful enough for the most basic environ-ment. One of the developers of AirSim answered a question regardingthe system requirements for AirSim where he said: "For Neighbour-hood Pack described in docs, a discrete GPU with minimum of 4GBRAM is a must"1. This means a quite powerful computer is needed inorder to run AirSim. One of the systems used by us had the followingspecs:

• CPU: Intel Core i7-8700k (6 cores and 12 threads running at 5GHz)

• RAM: 16 GB DDR41Issue where the system requirements for AirSim is asked: https://github.

com/Microsoft/AirSim/issues/17

25

26 CHAPTER 4. AIRSIM FINDINGS AND CONTROLLERIMPLEMENTATION

• GPU: NVidia GTX 660

• HDD: Samsung EVO 960 (SSD)

This setup worked well although the GPU usage was constantly at100%. AirSim was tested on a system without a solid state drive re-sulting in long starting times.

4.1.1 Operating System and setup

AirSim works on Windows, macOS, and Linux as mentioned in sec-tion 2.1, although running AirSim on Linux means that the Unreal En-gine needs to be compiled from source. This took up to 4 hours onsome machines used during the project. When using AirSim on Win-dows 10 there is the possibility of installing the Unreal Engine withouthaving to compile it from source. There is also a complete setup tuto-rial for AirSim2 on Windows by one of the developers of AirSim.

4.2 Communication

As mentioned in section 3.2 and 3.3 exposes AirSim two APIs. The firstone implements its functionality by using the built-in FC, simple flight.This API is accessible through RPC and practical usage of this API isshown in section 4.2.1. The second API communicates through theusage of MAVLink messages and although it does not have the samefunctionality implemented as the first one it allows for individual mo-tor control and practical usage of this API is shown in section 4.2.2.

4.2.1 RPC

The default API exposes multiple procedures provided by the defaultFC, simple flight, in AirSim. Accessing this API with the programminglanguage C is hard which led us to use the same library used by AirSimto expose the API. This library is called rpclib3 and an example of howto use it to communicate with AirSim is shown in listing 4.1.

2AirSim setup tutorial by Chris Lovett on Windows 10: https://www.youtube.com/watch?v=1oY8Qu5maQQ

3https://github.com/rpclib/rpclib

CHAPTER 4. AIRSIM FINDINGS AND CONTROLLER IMPLEMENTATION27

1 // Creating a connecting to AirSim on localhost port 41451 using rpclib2 rpc::client client("127.0.0.1", 41451);34 // Tell the AirSim controller to enable API controls5 client.call("enableApiControl", true);6 // Arm the drone in AirSim, this means we are alllowed to use the motors7 client.call("armDisarm", true);8 // Takeoff to 5m and hover there9 client.call("takeoff", 5.0);

Listing 4.1: Communication with AirSim using the default RPC API inC++ with rpclib. This code connects to the AirSim RPC server and callsprocedures resulting in the drone hovering at an altitude of 5 meters

4.2.2 MAVLink

This section presents how to create MAVLink messages used for re-ceiving and sending data to AirSim. Examples of how this is done inC and Rust are shown in the following subsections by giving practicalcode examples.

4.2.2.1 Receiving messages in C

By using the settings shown in section 3.3 AirSim will send MAVLinkmessages over UDP on port 14560. In order to receive these messageswe have to listen for them on the specified socket address, store it in abuffer and parse a MAVLink message from the buffer. This is done byusing the parse char function which is defined in the MAVLink library.An example of how to parse a MAVLink message stored in a buffer isshown in listing 4.2.

1 for (int i = 0; i < BUFFER_SIZE; i++) {2 // The mavlink_parse_char will try to parse the MAVLink message one char at a time3 // and return true when the whole message has been decoded and the message could4 // be validated against the CRC.5 if (mavlink_parse_char(6 MAVLINK_COMM_0, // ID of the current channel. This allows parsing of different7 // channels8 buffer[i], // The char to parse9 msg, // Where to place the parsed message

10 &status // Will contain the stats of the channel if a message could11 // be decoded12 )) {13 // A MAVLink message has been successfully parsed and put at the location of14 // the msg pointer15 break;16 }17 }

Listing 4.2: Example of parsing a MAVLink message and placing it ina MAVLink message struct

28 CHAPTER 4. AIRSIM FINDINGS AND CONTROLLERIMPLEMENTATION

After receiving a MAVLink message we have to determine what typeof message it is. This is done by looking at the id of the message anddecoding it accordingly, as shown in listing 4.3.

1 // Check the id of the MAVLink message to decode it accordingly2 switch (msg.msgid) {3 case MAVLINK_MSG_ID_HIL_SENSOR:4 mavlink_hil_sensor_t sensor_msg;5 mavlink_msg_hil_sensor_decode(&msg, &sensor_msg);6 ...7 break;8 case MAVLINK_MSG_ID_HIL_GPS:9 mavlink_hil_gps_t gps_msg;

10 mavlink_msg_hil_gps_decode(&msg, &gps_msg);11 ...12 break;13 ...14 }

Listing 4.3: Example of decoding common MAVLink message sent byAirSim in C

4.2.2.2 Receiving MAVLink messages in Rust

To receive MAVLink messages in Rust we use a MAVLink library4

which handles the socket connection, parsing, encoding and decodingof messages. An example of its usage is shown in listing 4.4.

1 // Use the MAVLink library to receive a message and place it in the `msg` variable2 let msg = connection.recv().unwrap();34 // Check if the message received is any of the ones we are looking for5 match msg {6 MavMessage::HIL_GPS(gps_msg) => {7 // The gps_msg variable contains the MAVLink message8 ...9 break;

10 },11 MavMessage::HIL_SENSOR(sensor_msg) => {12 // The sensor_msg variable contains the MAVLink message13 ...14 break;15 },16 MavMessage::DISTANCE_SENSOR(distance_msg) => {17 // The distance_msg variable contains the MAVLink message18 ...19 break;20 },21 _ => continue, // Do not care about other messages22 }

Listing 4.4: Receiving, parsing and decoding common MAVLink mes-sages sent by AirSim in Rust

4MAVLink library in Rust: https://github.com/3drobotics/rust-mavlink

CHAPTER 4. AIRSIM FINDINGS AND CONTROLLER IMPLEMENTATION29

4.2.2.3 Sending MAVLink messages in C

In order to be able to send MAVLink messages they have to first becreated and then encoded into a suitable format for transmission. Themessage used to control the vehicle in AirSim is the actuator controlsmessage5. This message defines the actuator controls signals for eachmotor of the vehicle and is defined using the actuator controls packfunction which will pack the control signals into a MAVLink messagestruct. To send this message over a socket or serial they have to beencoded into a suitable format and this is done by using the send bufferfunction. This results in the encoded MAVLink message being storedin a buffer variable which can be transmitted through a socket or serialconnection. An example of this is shown in listing 4.5.

1 // Control outputs (-1 .. 1) to control the motors of the vehicle.2 float controls[] = {3 1.0, // In AirSim this is the north east motor4 1.0, // In AirSim this is the south west motor5 1.0, // In AirSim this is the north west motor6 1.0, // In AirSim this is the south East motor7 -1.0, // Motor not in use8 -1.0, // Motor not in use9 -1.0, // Motor not in use

10 -1.0, // Motor not in use11 -1.0, // Motor not in use12 -1.0, // Motor not in use13 -1.0, // Motor not in use14 -1.0, // Motor not in use15 -1.0, // Motor not in use16 -1.0, // Motor not in use17 -1.0, // Motor not in use18 -1.0, // Motor not in use19 };2021 // Packs the HIL_ACTUATOR_CONTROLS into a MAVLink message22 mavlink_msg_hil_actuator_controls_pack(23 SYSTEM_ID, // ID of the system sending this message24 COMPONENT_ID, // ID of the component sending this message25 &msg, // A pointer to a mavlink_message_t struct where the mavlink message will26 // be stored27 current_time, // The current time since system start, in microseconds28 controls, // The actuator controls29 mode, // System mode, includes arming state30 flags // Flags, reserved for future use31 );3233 // Encode the MAVLink message and send it to the provided buffer (data in the buffer is ready34 // for transportation over-the-wire)35 mavlink_msg_to_send_buffer(buffer, &msg);

Listing 4.5: Creating and encoding an actuator controls message in C,the message definition is listed in table 3.3

5Actuator controls message documentation found at https://mavlink.io/en/messages/common.html#HIL_ACTUATOR_CONTROLS

30 CHAPTER 4. AIRSIM FINDINGS AND CONTROLLERIMPLEMENTATION

4.2.2.4 Sending messages in Rust

The creation of MAVLink messages in Rust is done by using the pre-viously mentioned MAVLink library and create a structure with theactuator controls data. This structure is used in combination with theconnection to encode and transmit it, an example of this is shown inlisting 4.6.

1 // Control outputs (-1 .. 1) to control the motors of the vehicle.2 let controls: Vec<f32> = vec![3 1.0, // In AirSim this is the north east motor spinning4 1.0, // In AirSim this is the south west motor spinning5 1.0, // In AirSim this is the north west motor spinning6 1.0, // In AirSim this is the south East motor spinning7 -1.0, // Motor not in use8 -1.0, // Motor not in use9 -1.0, // Motor not in use

10 -1.0, // Motor not in use11 -1.0, // Motor not in use12 -1.0, // Motor not in use13 -1.0, // Motor not in use14 -1.0, // Motor not in use15 -1.0, // Motor not in use16 -1.0, // Motor not in use17 -1.0, // Motor not in use18 -1.0, // Motor not in use19 ];2021 msg = MavMessage::HIL_ACTUATOR_CONTROLS(HIL_ACTUATOR_CONTROLS_DATA {22 time_usec, // AirSim does not care about the current time23 flags, // Flags, reserved for future use24 controls, // The actuator controls25 mode, // System mode, includes arming state26 });2728 // Send the MAVLink message over the socket.29 connection.send(&msg).ok();

Listing 4.6: Creating and sending an actuator controls message in Rust

4.2.3 Network communication

To control a drone over the network the AirSim settings have to beupdated with values presented in listing 4.7. First, the vehicle config-uration has to be specified to be that of PX4 which will enable AirSimto send MAVLink messages required for the control of the drone. Thesetting of UseSerial needs to be set to false which will make AirSimcommunicate over the network by sending UDP packets containingthe MAVLink messages to the specified IP and port declared underthe settings UdpIp and UdpPort. AirSim will also listen for incomingmessages on UdpPort where the commands to control the drone shouldbe sent. The setting of LocalHostIp needs to be set to the IP of the hostcomputer AirSim is running to enable it to communicate with a remotecomputer instead of to the hosting computer.

CHAPTER 4. AIRSIM FINDINGS AND CONTROLLER IMPLEMENTATION31

1 {2 "SettingsVersion": 1.0,3 "SimMode": "Multirotor",4 "DefaultVehicleConfig": "PX4",5 "PX4": {6 "UseSerial": false,7 "LocalHostIp": "HOST_IP",8 "UdpIp": "CONTROLLER_IP",9 "UdpPort": "CONTROLLER_PORT"

10 }11 }

Listing 4.7: AirSim settings for over the network control

4.2.4 Serial communication

AirSim can communicate with MAVLink messages over serial by us-ing the settings presented in listing 4.8. This listing enabled serial com-munication by setting the UseSerial entry to true, sets the serial speedby changing the SerialBaudRate and the serial communication port bychanging the SerialPort entry.

1 {2 "SettingsVersion": 1.0,3 "SimMode": "Multirotor",4 "DefaultVehicleConfig": "PX4",5 "PX4": {6 "UseSerial": true,7 "SerialBaudRate": 115200,8 "SerialPort": "COM_PORT"9 }

10 }

Listing 4.8: AirSim settings to enable serial communication

By using these settings on the computer running AirSim a microcon-troller can be connected enabling the ability to read and write MAVLinkmessages used to control a vehicle in the simulator.

4.3 Enabling the MAVLink distance sensor

AirSim does not send the MAVLink messages for the distance sensorby default. It is not possible at the time of writing to enable it by chang-ing the settings file, however, we did find a temporary workaround bychanging the source code of AirSim. This is done by changing the Mul-tiRotorParams.hpp6 file in the AirSim source code where a structure is

6The multirotor parameter file: https://github.com/Microsoft/AirSim/blob/b97d57b7dfe66b76c304eeb022f98a06cf2c6de6/AirLib/include/vehicles/multirotor/MultiRotorParams.hpp#L36

32 CHAPTER 4. AIRSIM FINDINGS AND CONTROLLERIMPLEMENTATION

found, containing the settings for what sensors are active. The defaultvalue for the distance sensor is false (inactive) and changing this valueto true (active) results in AirSim sending out MAVLink messages con-taining distance sensor readings.

4.4 Multiple vehicle simulation

The ability to spawn and control multiple vehicles was found to bepossible at one in AirSim by reading the documentation for multiplevehicles7. This documentation is however outdated resulting in thefunctionality to control multiple vehicles in AirSim to not be workingas of writing, but the ability to spawn multiple vehicles is still possibleby following the instructions provided in figure 4.1. The functional-ity of controlling multiple vehicles with different controllers is said tobe fixed and currently, there is a workaround available requiring themodification of the AirSim source found in an issue8.

7Outdated documentation on how to spawn multiple ve-hicles: https://github.com/Microsoft/AirSim/blob/b97d57b7dfe66b76c304eeb022f98a06cf2c6de6/docs/multi_vehicle.md

8Issue regarding controlling multiple vehicles and a temporary workaround inAirSim: https://github.com/Microsoft/AirSim/issues/1008

CHAPTER 4. AIRSIM FINDINGS AND CONTROLLER IMPLEMENTATION33

Figure 4.1: Spawning multiple drones is done by; 1, clicking onthis button, 2, clicking on the “Blueprints” and 3, dragging the“BP_FlyingPawn” model into the view where the drones are shownin this figure

4.5 Custom flight controller

Figure 4.2 presents a summary of the implemented functionality forthe custom FC which includes; take off, landing, stabilization and nav-igation as it is some of the most fundamental functionality of a FC.

Figure 4.2: FC functionality summary

Take off

Landing

Waypoint navigation

WaypointAltitude

stabilization(hover)

Roll, pitch andyaw stabilization

34 CHAPTER 4. AIRSIM FINDINGS AND CONTROLLERIMPLEMENTATION

4.5.1 Choosing API

The default API, as mentioned in section 3.2, provides powerful func-tionality. This functionality is implemented by the default FC, simpleflight, and an example how the default API, AirSim and simple flightis connected is visualized in figure 4.3.

AirSim

takeoff moveToPosition

RPC server

Simple flight

takeoff

movetoPositionRPC client

User

Figure 4.3: How simple flight, AirSim and RPC are connected

The problem with the default API is that it does not expose proceduresfor individual motor control, making it unsuitable for the custom FCimplementation. MAVLink, as mentioned in section 3.3, does not in-clude the functionality provided by the default API as it is not backedby an FC implementation, however, it does provide access to individ-ual motor control and sensor reading and is the reason why MAVLinkis going to be focused, and used from here on out to implement thecustom FC.

4.5.2 Architecture using MAVLink messages

The general architecture for the implemented FC in C and Rust isshown as a block diagram in figure 4.4.This figure presents how the controller is divided into two major lay-ers. The first layer is the communication layer, handling the communica-tion with AirSim and parsing commands from the user and the secondlayer is the PID Controller layer.

The communication layer consists of two parts, one that communicateswith AirSim and one that parses commands from the user. The com-munication with AirSim is done by listening for the sensor and GPSmessages sent from AirSim in the form of MAVLink messages andsending actuator control messages to control the motors of the drone.

CHAPTER 4. AIRSIM FINDINGS AND CONTROLLER IMPLEMENTATION35

Custom flight controller

Actuator calculator

Altitude

Actuator signals

Actuatorsignal sender

Sensor signals

Longitude

GPS signals

Latitude

Messagelistener

Communication layer

Pitch outputPID pitch

Roll outputPID roll

Yaw outputPID yaw

Throttle outputPID altitude

Sensor data

AirSim

Yaw setpoint

Orientation calculator

Actuator signals

Pitch angle

Roll angle

Yaw angle

Angle calculator

Pitch setpoint

PID latitude

Roll setpoint

PIDlongitude

PID controller layer

Latitude setpoint

Longitude setpoint

Altitude setpoint

Command handler Altitude

command

Position commandUser

Figure 4.4: The architecture presenting the core components of the cus-tom FC and the data flow between them

The second part handles commands input by the user and executesthem. These commands consist of the position command, which pro-vides the target position the drone should move to, and the altitudecommand, which provides the desired altitude for the drone to fly at.

The second layer is the PID controller layer, where each PID controllerhandles the following:

• PID pitch: Stabilizes the pitch of the drone to the desired setpoint

• PID roll: Stabilizes the roll of the drone to the desired setpoint

• PID yaw: Stabilizes the yaw of the drone to the desired setpoint(in this case it is the output of the Orientation calculator resultingin the drone always pointing north)

• PID altitude: Stabilizes the altitude of the drone to the desiredsetpoint

• PID latitude: Moves the drone in the latitude direction by chang-ing the setpoint of the PID pitch controller

• PID longitude: Moves the drone in the longitude direction bychanging the setpoint of the PID roll controller

36 CHAPTER 4. AIRSIM FINDINGS AND CONTROLLERIMPLEMENTATION

To simplify the functionality of moving the drone to a target positionwe set it to always point north at 0 degrees allowing us to map thelatitude and the longitude to the pitch and roll angles respectively.

Between the two layers, there are three modules used for hardwaresignal conversions. These are:

• Actuator calculator: converts yaw pitch, roll, and altitude to ac-tuator signals (motor control output) sent to AirSim using theHIL_ACTUATOR_CONTROLS message

• Orientation calculator: calculates the compass readings of thedrone by using magnetometer sensor readings provided by theHIL_SENSOR MAVLink message

• Angle calculator: calculates the pitch, roll and yaw relative fromthe starting position by using gyroscope and accelerometer sen-sor reading provided by the HIL_SENSOR MAVLink message

4.5.3 Implemented functionality

The core functionality of the FC was successfully implemented in bothlanguages and provides stabilization functionality for; pitch, roll, yaw,and altitude. Figure 4.5 shows the drone hovering above the takeoffposition using the custom FC.

Figure 4.5: The drone hovering above the takeoff position using thecustom FC

CHAPTER 4. AIRSIM FINDINGS AND CONTROLLER IMPLEMENTATION37

A graph presenting the performance of the custom FC which was de-rived by logging the altitude of the drone while taking off and stabi-lizing itself at an altitude of 10 meters is shown in figure 4.5.3.

0 2 4 6 8 10 120

5

10

15

Time (seconds)

Alti

tude

(met

ers)

Drone altitude using the PID controller with a target altitude of 10m

Drone altitude in CDrone altitude in Rust

In this figure it is shown that it takes the custom FC roughly 8 secondsto make the drone reach the target altitude and will continue to hoverthere with an interval of ± 10 centimeters. The custom FC is capable ofhandling disturbances such as wind gusts or similar that might other-wise make the drone tip to one side. The behavior of this functionalityis similar in both C and Rust.

The waypoint functionality using latitude and longitude which is usedto either keep the drone stable at a certain position or move it to anew location is not fully functional. This is due to the calibration ofthese PID controllers proved more difficult than those of the angle oraltitude. It currently allows us to keep the drone stable by hoveringat the takeoff location without it drifting and can be used to move thedrone to a new location, although the further away that location is,the longer it takes to stabilize at the new waypoint and over time thedrone will become unstable.

The implementation of the custom FC is similar in both Rust and C,although Rust did provide a feature we were unaware of which wasthat Rust, in development mode, is able to determine if an integer has

38 CHAPTER 4. AIRSIM FINDINGS AND CONTROLLERIMPLEMENTATION

been overflown. This was discovered in the implementation of the FCin Rust where the runtime told us a variable was overflown. This wasnot discovered in the C implementation and may have gone unnoticedif the Rust controller had not been implemented. Something to alsonote is the lack of segfaults or memory leaks. We did not encounterany of these problems in the C implementation.

4.6 Code examples

The resulting implementations of our custom FC and other exampleprograms developed during the exploration of AirSim can be foundon an open GitHub repository with an open source license allowingfor the free use of all available source code. This repository is namedairsim-examples9 and contains programs and documentation for basicMAVLink communication in C and Rust, RPC communication in C++and the implementation of our flight controller using MAVLink in bothC and Rust.

9GitHub repository containing the applications developed during this project:https://github.com/JoelWachsler/airsim-examples/

Chapter 5

Evaluation and conclusions

This chapter evaluates and concludes what has been learned aboutAirSim by discussing its pros and cons in section 5.1, how Rust com-pares to C in the context of safety-critical systems by discussing our ex-perience implementing the custom FC in both languages in section 5.2,evaluating what goals were met in section 5.3 and how the informationpresented in this thesis can be used in future projects in section 5.4.

5.1 AirSim

Much of the documentation in AirSim is either outdated or missingand some documented functionality being broken can make it quitehard to use. An example of this is the documentation regarding howto simulate multiple vehicles. Although the individual control of eachdrone was described in the documentation we discovered this func-tionality is currently broken and may only be used by modifying thesource code for AirSim. There was no information of what kind ofMAVLink messages AirSim uses or what can be done with them andthere is no documentation detailing all procedures accessible by thedefault API. As mentioned in section 4.1 the Unreal Engine is demand-ing resulting in the need of a powerful setup in order to run AirSim.

Although these problems exist there is always the possibility to fixthe problems or extend the functionality of AirSim by modifying thesource code. Something to also note is that the community aroundAirSim is helpful when it comes to questions regarding the simulatoror if something is not working correctly. The functionality working

39

40 CHAPTER 5. EVALUATION AND CONCLUSIONS

does so well and we had no problems using it once AirSim was upand running.

To conclude what we think about AirSim is that it has great potentialto be a great simulator, but as of current is quite lacking when it comesto documentation and therefore the user often has to go through thesource code and debug AirSim in order to find out how things areworking and how to use them. Because of this, the initial time to getinto AirSim can be larger than expected.

5.2 Rust and C in safety-critical systems

Because of Rust being a new language introducing a lot of new con-cepts such as ownership and borrowing makes it a quite hard to learnif the programmer is not used to these ideas from before. There is alsono dedicated Rust Integrated development environment (IDE) avail-able resulting in the programmer having to solely rely on the compiler.This is a major flaw compared to C which has a lot of great IDEs avail-able such as CLion or Visual Studio. These IDEs help the programmerby providing for example; code completion, member and, parameterlisting.

Although these issues are present in Rust it does provide safety whenit comes to segfaults, dangling pointers, memory leaks and overflowswhich could result in the failure of safety-critical systems which is notacceptable. The compiler is also helpful by providing easy to under-stand errors and telling exactly what is causing errors and how to fixthem which was not always the case in C. The Rust language also pro-vides a package manager providing simplifying the use of third-partypackages. This was a big drawback when using C where the depen-dency had to be done manually.

Even though there is no IDE for Rust we believe it is a great lan-guage. The compiler provides safety crucial in the development ofsafety-critical systems and great error messages making it easy to fixproblems and makes development pleasant.

CHAPTER 5. EVALUATION AND CONCLUSIONS 41

5.3 Goals

This section summarizes what goals presented in section 1.4 were metand not. It will explain how they were met or why they were not.

Understanding the architecture of AirSim and how its components

interact with each other.: an overview of the architecture is shownin figure 2.2 and is described in section 2.1.1. The interaction of themodels during a simulation is described, but no details regarding theactual implementation are covered due to it being out of the scope ofthis thesis.

Researching what AirSim APIs are available, what do they provide

and how do we communicate with them and determine if it is pos-

sible to access these APIs with the two studied languages (Rust and

C): the available APIs has been presented in section 3.2 and 3.3.Where to find the available procedures for the default API has beenpresented in section 3.2 and a simple code example of how to use thisAPI in C++ is shown in listing 4.1. C++ was not one of the languagesstudied but as mentioned in section 4.5.1 this API is not suitable for im-plementing an FC and therefore the choice was made to give a simpleexample of how to access this API without investing time in findinglibraries for Rust and C.The MAVLink messages sent and received by AirSim is presented intable 3.1 and 3.2 respectively. Examples of the fields for the two mostcommon used messages by us in the custom FC implementation isshown in table 3.3 and 3.4. An example of how to use these messagesare shown with code examples in both C and Rust in section 4.2.2.

Evaluate the support for simulating multiple vehicles and control-

ling them with different controllers: this has been achieved by thepresentation and explanation on the current documentation and cur-rent accuracy of it in section 4.4. We explained how you can spawnmultiple vehicles but can currently not control them individually, al-though the developers of AirSim have said that this will be imple-mented in the near future.

Evaluate the current state of Rust compared to C within the context

of safety-critical systems: we have presented the result of implement-

42 CHAPTER 5. EVALUATION AND CONCLUSIONS

ing an FC in these languages in section 4.5 and evaluated what wethink about them in section 5.2.

Research what notions of time AirSim have: this has been describedin section 3.4, where it is shown that AirSim has various settings forthe speed of simulation and different simulation clocks available de-scribing their different functionality.

Implement a simple FC in C and Rust performing basic function-

ality such as taking off, landing and pitch, roll, yaw and altitude

stabilization: this custom FC has been implemented as shown in sec-tion 4.5. This custom FC provides the desired functionality and keepsthe drone stable hovering at the given altitude.

Port the FC to a microcontroller: this was not achieved due to timeconstraints, however we were able to send and receive MAVLink mes-sages from a microcontroller using Universal asynchronous receiver-transmitter (UART) with the settings presented in listing 4.8.

Implement waypoint functionality for the FC: this was partly achievedby us implementing PID controllers acting on the latitude and longi-tude but this did not result in the desired functionality as the dronewas not able to stabilize itself over the desired waypoint correctly andbecame unstable over time.

Implement collision detection for the FC: this was not implementeddue to us not discovering how to enable MAVLink distance sensormessages to be sent by AirSim until late in the project. This sensor isnot enabled by default and there was no documentation on it exist-ing or how to enable it. The only way we found for enabling AirSimto send the readings of this sensor was to change the source code toenable it by default as described in section 4.3.

Control a vehicle in AirSim over the network: We were able to con-trol a drone in AirSim over the network by doing what is describedin 4.2.3 and changing the settings of AirSim to what is shown in 4.7.This allowed us to run an FC on a computer that was not running asimulation of AirSim, which communicated with AirSim by sendingand receiving UDP packets on the specified ports.

CHAPTER 5. EVALUATION AND CONCLUSIONS 43

5.4 Future work

This thesis has laid the groundwork for what is needed to use AirSimby presenting what APIs are available, how to communicate with themin different languages and a proof of concept showing the possibilityof implementing a custom FC using the MAVLink message API. Thereare many paths to continue this work and we will go through some ofthem in the following subsections.

5.4.1 Rust and C comparison

This thesis has been able to evaluate some aspects of the languagesRust and C but it has, due to time constraints, not been able to exten-sively compare them in all their regards. Therefore there is much to bedone in the area of comparing these two languages such as looking attheir performance, compilation times, readability etc.

5.4.2 Flight controller

Our FC implementation is only a proof of concept presenting the pos-sibility of implementing a custom FC being able to communicate withAirSim. A problem with this controller is the implementation of thewaypoint navigation system which is barely working. Another prob-lem is the controller not utilizing sensor messages resulting in the dronecrashing whenever it encounters an object. The controller was also notsuccessfully ported to a microcontroller which would be able to beused in the simulator communicating either over ethernet or serial.

5.4.3 Multiple vehicle simulation

AirSim offers the possibility of simulating multiple vehicles but as ofwriting this does not work but it probably will in the future. Futureprojects could, therefore, compare controllers and how they interactwith each other by connecting them to different vehicles in AirSim.These controllers could also work together to perform more complextasks.

44 CHAPTER 5. EVALUATION AND CONCLUSIONS

5.4.4 AirSim

AirSim is a good simulator despite its lacking of documentation attimes. It has very realistic graphics and uses a very stable engine. Itsmodular design allows for both adding new models and functional-ity and to reuse the already developed models in other applications.There are many possible projects AirSim can be a part of, both as atool in projects or to further develop AirSim. It could be used in thedevelopment of algorithms for autonomous vehicles as a tool, or inthe further improvement of it by contributing to the development ofnew functionality and vehicles. These contributions are often encour-aged by the developers who wish to create a community around thissimulator.

Bibliography

[1] common.xml · MAVLink Developer Guide. URL: https://mavlink.io/en/messages/common.html (visited on 06/07/2018).

[2] Frequently Asked Questions The Rust Programming Language. URL:https://www.rust-lang.org/en-US/faq.html#what-is-this-projects-goal (visited on 06/08/2018).

[3] GPS sensor. URL: https://msdn.microsoft.com/en-us/library/gg650245.aspx (visited on 06/08/2018).

[4] Anne Håkansson. “Portal of Research Methods and Methodolo-gies for Research Projects and Degree Projects”. eng. In: DIVA.CSREA Press U.S.A, 2013, pp. 67–73. URL: http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-136960 (visitedon 06/07/2018).

[5] Gerard J. Holzmann. “The Power of Ten–Rules for DevelopingSafety Critical Code”. In: (). URL: http://spinroot.com/gerard/pdf/P10.pdf (visited on 06/04/2018).

[6] Brian Karis and Epic Games. “Real shading in unreal engine 4”.In: Proc. Physically Based Shading Theory Practice (2013).

[7] J. C. Knight. “Safety critical systems: challenges and directions”.In: Proceedings of the 24th International Conference on Software En-gineering. ICSE 2002. May 2002, p. 547. ISBN: 1-58113-472-X. URL:https://ieeexplore.ieee.org/document/1007998/.

[8] P. Li and W. Zhang. “Test Simulation An Effective Approach toReduce Development Cost of Mobile Phone”. In: 2010 Second In-ternational Conference on Computer Modeling and Simulation. Vol. 2.Jan. 2010, pp. 489–492. DOI: 10.1109/ICCMS.2010.107.

45

46 BIBLIOGRAPHY

[9] Nicholas D. Matsakis and Felix S. Klock II. “The Rust Language”.In: Proceedings of the 2014 ACM SIGAda Annual Conference on HighIntegrity Language Technology. HILT ’14. New York, NY, USA: ACM,2014, pp. 103–104. ISBN: 978-1-4503-3217-0. DOI: 10.1145/2663171.2663188. URL: http://doi.acm.org/10.1145/2663171.2663188 (visited on 04/25/2018).

[10] MAVLink Developer Guide. URL: https://mavlink.io/en/(visited on 04/26/2018).

[11] Rationale for International Standard—Programming Languages—C.Tech. rep. Apr. 2003, p. 3. URL: http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf (visitedon 06/01/2018).

[12] References & Borrowing - The Rust Programming Language. URL:https://doc.rust-lang.org/book/second-edition/ch04-02-references-and-borrowing.html (visited on06/08/2018).

[13] “Remote Procedure Call”. en. In: The JR Programming Language.The International Series in Engineering and Computer Science.Springer, Boston, MA, 2004, pp. 91–105. ISBN: 978-1-4020-8085-2978-1-4020-8086-9. DOI: 10.1007/1-4020-8086-7_8. URL:https://link.springer.com/chapter/10.1007/1-4020-8086-7_8 (visited on 06/07/2018).

[14] Dennis M. Ritchie. “The development of the C language”. In:ACM Sigplan Notices 28.3 (1993), p. 1.

[15] Shital Shah et al. “AirSim: High-Fidelity Visual and Physical Sim-ulation for Autonomous Vehicles”. In: Field and Service Robotics.2017, p. 1. URL: https://arxiv.org/abs/1705.05065.

[16] Shital Shah et al. “AirSim: High-Fidelity Visual and Physical Sim-ulation for Autonomous Vehicles”. In: Field and Service Robotics.2017, p. 2. URL: https://arxiv.org/abs/1705.05065.

[17] Shital Shah et al. “AirSim: High-Fidelity Visual and Physical Sim-ulation for Autonomous Vehicles”. In: Field and Service Robotics.2017, pp. 3–4. URL: https://arxiv.org/abs/1705.05065.

[18] Shital Shah et al. AirSim: Open source simulator based on Unreal En-gine for autonomous vehicles from Microsoft AI & Research. original-date: 2017-02-14T00:52:29Z. June 2018. URL: https://github.com/Microsoft/AirSim (visited on 06/07/2018).

BIBLIOGRAPHY 47

[19] Ian Sommerville. Critical systems. en-US. July 2014. URL: http://iansommerville.com/software-engineering-book/web/critical-systems/ (visited on 06/01/2018).

[20] TIOBE Index | TIOBE - The Software Quality Company. May 2018.URL: https://www.tiobe.com/tiobe-index/ (visited on06/01/2018).

[21] L. A. Tuan, M. C. Zheng, and Q. T. Tho. “Modeling and Verifica-tion of Safety Critical Systems: A Case Study on Pacemaker”. In:2010 Fourth International Conference on Secure Software Integrationand Reliability Improvement. June 2010, pp. 23–32. DOI: 10.1109/SSIRI.2010.28.

[22] Unreal Engine. en-US. URL: https://www.unrealengine.com/ (visited on 06/08/2018).

[23] Tim Wescott. “PID without a PhD”. In: Embedded Systems Pro-gramming 13.11 (2000), p. 1. URL: https://www.robotshop.com/letsmakerobots/files/userpics/u1069/f-wescot-PID_without_PHD.pdf.

[24] What is Ownership? - The Rust Programming Language. URL: https://doc.rust-lang.org/book/second-edition/ch04-01-what-is-ownership.html (visited on 06/08/2018).

[25] Oliver J. Woodman. An introduction to inertial navigation. en. Tech.rep. UCAM-CL-TR-696. University of Cambridge, Computer Lab-oratory, 2007, p. 5. URL: http : / / www . cl . cam . ac . uk /techreports/UCAM-CL-TR-696.html (visited on 06/07/2018).

[26] Oliver J. Woodman. An introduction to inertial navigation. en. Tech.rep. UCAM-CL-TR-696. University of Cambridge, Computer Lab-oratory, 2007, p. 33. URL: http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-696.html (visited on 06/07/2018).

TRITA EECS-EX-2018:180

www.kth.se