Enabling cloud-based remote application management for drones

(1)

management for drones

Enabling cloud-based remote application

Academic year 2019-2020

Master of Science in de industriële wetenschappen: elektronica-ICT Master's dissertation submitted in order to obtain the academic degree of

Counsellor: Jerico Moeyersons

Supervisors: Prof. dr. Bruno Volckaert, Prof. dr. ir. Filip De Turck

Student numbers: 01607694, 01502070

(2)

(3)

”The author(s) gives (give) permission to make this master dissertation available for consultation and to copy parts of this master dissertation for personal use. In all cases of other

use, the copyright terms have to be respected, in particular with regard to the obligation to state explicitly the source when quoting results from this master dissertation.”

(4)

During the creation of this thesis we have been able to pursue our vision of what we wanted the Ug-One platform to look like and deepen our understanding of some of the most prominent technologies in the world of cloud computing. But this would not have been possible without the trust of our supervisors who allowed us to follow this vision and advised us along the way. For this we would like to thank our supervisors Prof. dr. Bruno Volckaert and prof. dr. ir. Filip De Turck. We would also like to extend our thanks to our counsellor Jerico Moeyersons for always being ready to provide us with feedback, insight and advice.

Martijn Gevaert I would like to extend my deepest gratitude to both my parents for their abundant support during this thesis and the studies that preceded it. It is difficult to understate the importance they have had in bringing both this thesis and the studies that it finalizes to completion. I also owe a great deal of gratitude to Sylvie Benthein for supporting and inspiring me more than she knows along the way.

Friends, family, colleagues, Thank you.

Karl-Erik Réculé First, I would like to profoundly thank my parents for the support, motivation and faith in my abilities they gave me throughout my school career. Thanks to them, I got the chance to study and to develop myself.

I would like to thank my girlfriend Elien Verhoeve for the love, support and help she has given me over these past years.

To my family, friends and colleagues, thank you for everything! Karl-Erik Réculé

(5)

Enabling cloud-based remote application

management for drones

Martijn Gevaert, Karl-Erik R´ecul´e

Supervisors: Prof. dr. Bruno Volckaert, Prof. dr. Filip De Turck Counsellor: ir. Jerico Moeyersons

Abstract—Drones are becoming increasingly ambiguous, capa-ble and more cost effective than ever before, but the continuous advance in drone technology has not necessarily made drone application development easier. While mature Infrastructure as a Service (IaaS) platforms offer features such as hardware abstraction, resource allocation and tools to manage applications remotely, commercial drones often offer a restrictive software environment instead.

Inspired by the technical success and convenience of IaaS platforms, this thesis set out to bring that experience to drones, resulting in the creation of the Ug-One Drones as a Service (DaaS) platform.

Because many of the goals for the DaaS platform aligned with those of an IaaS platform, many of the technologies used in the DaaS platform can be found in the world of Cloud computing as well. Applications created for drones are containerized using Docker and application management can be done through a web interface. The drones host a REST API for platform management and they have a Linux onboard computer. Developers can deploy applications on the drones or forward the required data and deploy their applications on a remote server instead.

This approach has delivered promising results when tested using several reference applications that either represent real world applications such as video streaming and movement control or instead just stress tests to check for resource availability and reliability.

In the end, the Ug-One platform, succeeded in simplifying drone application development and management while main-taining the reliability and versatility required from any drone platform.

Index Terms—Drones, application management, Drones as a Service, Docker, Infrastructure as a Service

I. FLYING A DRONE RELIABLY

As with most aviation systems, drones need to be reliable and thoroughly tested, which slows down development. Each time software or hardware that controls the drone is modified, everything needs to be tested again. To prevent this kind of slowdown, open-source autopilots such as Pixhawk [1] and ArduPilot [2] can be used. With the Pixhawk 4 [3] running the PX4 software [4] being the one used during the development of this platform. By using one of these thoroughly tested, maintained and documented autopilots, developers do not need the time or skills required to create an autonomous drone themselves. Instead they can focus on their applications which are deployed on a separate Linux onboard computer. If the Linux onboard computer fails, the autopilot simply pilots the drone back home.

II. RUNNING DRONE APPLICATIONS

The onboard computer hardware and software can now be optimized for application deployment, performance and efficiency instead of redundancy and reliability at all cost. This allows the usage of mainstream embedded computers such as a Raspberry Pi [5]. Since most of the drone specific challenges are handled by the autopilot, the onboard computer now started to look a lot like a remote deployment server. Even the remote connection to the drone has been implemented using a simple network connection over Wi-Fi during development, but this can be done over cellular as well.

III. DOCKER ON A DRONE

Because the onboard computer now acts as a remote de-ployment server, the software running on it can be developed in a way that takes full advantage of technologies such as Docker [6]. In fact, each platform component or application that runs on the drones is containerized. By doing this, the system becomes inherently more reliable, it has improved hardware compatibility and it is easier to deploy.

It is also much easier to manage the resources available to containerized applications. This is critical as without resource management, any application can utilize as much of the available resources as it wants to use, resulting in applications slowing down or even crashing.

A. Resource management

Resource management is done by a containerized com-ponent running on each Ug-One drone called the Ug-One API. This application, among other responsibilities, exposes a REST API which can be used to easily integrate the drones into a cloud back end. The API is designed to provide all of the Docker functionality that is needed to manage applications on a drone, but with the required limitations to guarantee resources. It also exposes endpoints that provide information on the system such as connected USB devices, available disk space and current memory usage.

While the Ug-One API can guarantee a fixed amount of memory availability to applications, using underlying Docker functionality, it does not guarantee a fixed percentage of CPU time. Instead, it works by allowing developers to assign a CPU priority weight. As long as the CPU is not being used 100%, any application can utilize as much of the CPU as it wants. However, as soon as applications start competing for processing power, the distribution of CPU time will be

(6)

B. Unmanaged resources

While CPU and memory resources are handled by the system, the system still lacks network bandwidth prioritization and disk space limiting. Network bandwidth prioritization is not yet part of Docker [7] and while it is possible to limit the size of a Docker container, it is not yet possible to limit the volume on the host that users can mount.

Despite these shortcomings, the Ug-One API is still capable of reliably managing containers and guaranteeing two critical resources. Because of this, it is used to manage all the components on a Ug-One drone, including itself.

IV. CONTROLLING THE AUTOPILOT

Aside from the onboard computer, each drone also has an autopilot. These autopilots are good at following precise instructions such as follow this path, fly to these coordinates and fly at this speed. These instructions are communicated through the open-source MAVLink protocol [8], which is utilized by the two most popular and advanced open-source autopilot software projects, PX4 [4] and ArduPilot [2].

Since most developers do not have any experience with MAVLink, the open-source MAVSDK library has been created by the team behind Pixhawk [9]. Unfortunately, MAVSDK can not be installed using pip [10] on ARM devices such as the Raspberry Pi 4. Instead, within this thesis, a Docker base image has been created that has a locally built version of MAVSDK installed in it. Fortunately, there is a lot of talk that pip support for ARM is on the way.

V. MAVLINK COMMUNICATION PIPELINE

While MAVSDK can be used to “Talk MAVLink”, a com-munication pipeline between the autopilot and the applications that use MAVSDK is still needed. Between the autopilot and the onboard computer, this happens over UART. On the onboard computer itself, a program called MAVLink-Router [11] then forwards these messages over UDP and routes them to applications on the drone or anywhere else, such as a cloud back end or possibly even another drone.

Because of the containerization of applications on the Ug-One platform, it is possible to run the same application, that communicates with an autopilot, on the drone or any other connected device. This behaviour has been validated by creating reference applications that read out telemetry provided by the autopilot and running them on the onboard computer, the back end and a third device connected over LAN.

To get all these devices to find each other over the internet, each device in the network is connected to a Virtual Private Network using OpenVPN [12].

Since multiple autopilots utilize the MAVLink protocol, it should now also be possible to simply switch out one autopilot with another, or in other words, deploy the same application on multiple drones with different autopilots.

of the Ug-One platform, several reference implementations are created. These have the added benefit of demonstrating how certain applications can be implemented by developers that want to start developing for the Ug-One platform.

A. Video streaming

First of, a reference implementation is created that connects to an onboard camera and streams video to both onboard and off-board applications. While this implementation can still be optimized significantly, it was already capable of providing a high-resolution stream to onboard and low-resolution stream to off-board applications, reducing bandwidth and battery usage.

B. Stress testing

The second application was created to simply run a stress test and use as much resources as possible. This application was used to validate the resource management capabilities of the Ug-One drones. As expected, these applications could never exceed their memory limit and could only claim CPU time in relation to their weight. This means that no critical container with a significantly higher CPU share value, or weight, ever experienced any real slowdowns while a stress tests was running.

C. MAVLink application

Finally, as mentioned before, one of the reference applica-tions was a container that reads out telemetry data provided by the autopilot over MAVLink.

VII. SYSTEM OVERVIEW

By now multiple components of the Ug-One platform have already been covered, but as depicted in Figure 1, these were mostly components that are part of the Ug-One drone. The second part of this abstract focusses on the bottom half of Figure 1, the Ug-One backend.

VIII. MANAGING A DRONE FLEET

A user can deploy and manage their applications, request system resources and more through the REST API on the drone. But this way of working is not user-friendly and certainly not when multiple applications need to be managed on multiple drones. To be able to manage those applications in a fast and easy way, a cloud infrastructure is needed. The proposed cloud infrastructure that was created offers a web application that enables users to easily deploy applications, keep an overview of their drone fleet, manage resources on the drones, etc. Because the web interface shows dynamic content to the users, there is also a need for a back-end API and a database. This back-end API is the central unit of the cloud infrastructure which sends and receives requests to and from the web server, database, drones, API servers, etc. Next to the web server, back-end API and database, there is one last component present on the cloud, an UDP Port Forward Server. This component offers the possibility to create dynamically

(7)

Fig. 1. Ug-One system components overview

connections between the drones and the client’s devices. In this way one-to-one, one-to-many, one and many-to-many connections can be set up. The components front-end, back-end API, database and UDP Port Forward Server are discussed in more detail in the following sections.

A. Front-end

To ensure that users can easily manage their drones and their applications, a web application is created. Through the web application, different Docker applications can be deployed on the drone. It is also possible to retrieve information, stop, restart and delete these Docker applications. Through the web application, Docker images, which can be stored on Docker Hub or GitLab, can be linked to the cloud. Those linked images can then be used with the deployment of the Docker applications on the drone. To create this web application, several front-end frameworks were studied and the choice was made to use the framework React. React [13] is not a real framework but a UI library that uses a component-based architecture as for example Angular. React is characterized by several features such as one-way-databinding [14], JSX [15] and the Virtual DOM [16].

Unlike the Angular framework, React does not have an app-level state. All the states are stored in all the different components of the web application. When a component wants to use information in another component, different components must pass their state to each other so that these components

in their turn will pass their state to other components and so on. For larger projects, this can lead to errors and difficulties to manage the application. This problem can be solved by using Redux [17, 18] or Context API [19]. Redux and Context API [20] use certain structures and components to manage the app-level state. They also offer the possibility to work more conveniently by using this one central unit to store the state. When creating the web application, a combination of Redux and Context API was used [21, 22]. The Context API methods are used to recreate the structure and components of Redux. Redux itself is not easy to understand and to use. The combination of both app-level state managers makes it easier and faster for a developer to create a web application with an app-level state. But when creating a bigger more complex web application, Redux is recommended because it can manage the data better and clearer and offers tools to help manage the app-level sate.

When React has been installed with the npm module create-react app [23], a development server is included within this module. This development server allows developers to set up and test their web application. When the web application wants to be used in production, a more reliable server must be chosen. Because of this, different web servers have been studied [24]. For the deployment of the web server, NGINX was chosen [25]. This web server has a low memory load, is lightweight and has the basic functionalities to host a web server.

B. Back-end API

To ensure that the front-end can obtain dynamic content from the database, API servers as from the drones, there is a need for a central unit that will retrieve this information. This unit also needs to ensure that the drones can extract data from the database and make it possible that drones can configure themselves with this unit. This central unit is the Back-end API which is created by a Node.js server and the npm module Express [26]. Through research, different frameworks were studied and Express.js [27] was chosen because it offers a myriad of HTTP utility methods and middleware on top of the Node.js existing features.

To make a connection with the database, drones and API servers, several node modules are used. The first node module is Axios [28] which is a promise-based HTTP client npm module for the browser and Node.js. Through Axios, it is possible to retrieve information from the drones, manage the applications and request resources by using their Ug-One API. Via the node module docker-hub-api [29], information of Docker Hub images from a public registry can be retrieved. To retrieve information from a Docker Image on GitLab, an attempt was first made to access it via a node module. These node modules were node-gitlab [30] and gitlab [31]. Due to lack of documentation and the absence of features which can retrieve Docker images, the GitLab API is chosen. With the GitLab API server [32], the different Docker images as their information could be retrieved. The Mongoose node

(8)

C. UDP Port Forward Server

When the drone is configured and starts up, it is able to send MAVLink messages through the UDP Protocol to an application on a client’s device such as a ground control sta-tion. A ground control station is a typical software application that runs on a computer on the ground. Through wireless telemetry, the computer on the ground communicates with the UAV (unmanned aerial vehicle). A ground control station can display real-time data about the performance, position, altitude, etc. of the UAVs. It can also be used to control an in-flight UAV, upload new mission commands and set parameters like altitude [34, 35]. When the drone is ready to fly, one possibility is to send his MAVLink messages directly to the client’s device. But this has a couple of disadvantages. When the drone boots up, an IP address must be given to the drone to send his MAVLink messages to. This IP address cannot be changed when the drone is active so when the IP address of the user changes, the connection with the drone will be lost. Also, when another user wants to take over the drone, this architecture prevents the user from controlling the drone. Another drawback is when multiple drones are sending their MAVLink messages to the same endpoint of an application or on the back-end. One can choose to try to distinguish the MAVLink messages from the different drones in that endpoint, but this can lead to complex systems within the endpoint. To solve these problems of the direct drone-client connection architecture, a protocol between the drone and the Back-end API has been set up and an UDP Port forward server is created. To make sure that not all drones send their MAVLink messages to the same port on the back-end, a protocol between the drone and the back-end is created. At the startup of the drone, the IP address of the back-end is given, which always has the same IP address. But a solution has to be found to which port the drone has to send his data to. Not all drones can sent their data to the same port because that will be difficult to manage. The solution that is used in this thesis is to link each drone to one specific port on the back-end. When a drone starts up, one of the first actions it performs is to send a request to the Back-end API to negotiate for a MavlinkPort. When the drone is registered to the platform, it receives a MavlinkPort. This Mavlinkport is the port on the UDP Port Forward Server to which the drone needs to send his MAVLink messages to. This MavlinkPort makes sure that only that specific drone is allowed to send to that specific port. This solves the problem that different drones would send their MAVLink messages to the same endpoint.

To solve the issues when a client IP address changes or another client wants to take over the drone, an UDP Port Forward Server is created. As the name implies, this server will forward UDP messages to another port on a different IP address. To configure the forwarding of the UDP messages, a REST request must be sent to the UDP Port Forward Server. This REST request will dynamically open or close the ports

messages to the server and it forwards them to the right device of the client. Through the web application, the user can make sure that these MAVLink messages arrive on the application on the client’s device or on an application on the back-end. The web application sends a request to the back-end API with the configuration data. The back-end API will in turn extract additional data from the database and send it to the UDP Port Forward Server. Using this configuration data, the UDP Port Forward Server can open the MavlinkPort as well as a ClientPort on the UDP Port Forward Server. The ClientPort is a port that is used to send data from the client back to the MavlinkPort on the drones IP Address. This way, multiple drones can connect to the cloud and users can monitor all their drones with a ground control station.

When the IP address of the user changes or when another user wants to monitor or control the drone, this is no problem anymore. By reconfiguring the ports and IP addresses of the UDP Port Forward Server, a user can reconnect with their drone or another user can take control of a drone. For the creation of such an UDP Port Forward Server, research was done and a solution was found. The first solution was to use a Router of which the Routing- and IPTables could be modified [36, 37]. This solution had one drawback, the router had to be rebooted every time the UDP Port Forward Server would set up new forwarding connections. The solution that was used for the cloud application is an API Server. On this server, UDP sockets (ports) can dynamically be opened and closed. Also, incoming requests with the configuration details can be handled and setup the ports. For simplicity, Express.js was also used to set up an API Server. To forward the UDP Messages, several possibilities were evaluated. Eventually the node module dgram [38] became the choice to forward UDP messages. It contains an extensive documentation and can be configured easily.

D. Database

For the development of a cloud platform, a database is not to be missed out. For the cloud infrastructure, only one database was chosen for simplicity, but multiple types of databases can be used. Before a database can be deployed, research was done to determine which database is best suited for the cloud platform [39, 40, 41]. By weighing up the advantages and disadvantages, a choice was made to choose for a NoSQL database. NoSQL databases are easier to scale horizontally than SQL databases [42] because a NoSQL database ensures that if the data that needs to be stored grows, the database can easily be expanded. Also, there is no need to create a pre-defined schema and NoSQL databases are more suited to handle big data then SQL databases [41]. This is important because different applications on the drones, can store many different types of data in different structures. By comparing the different NoSQL databases and taking the CAP theorem [43] into account, the MongoDB database has been chosen. The CAP theorem states that it is difficult for a distributed datastore

(9)

to simultaneously provide more than two out of the following elements: consistency, availability and partition tolerance. For the cloud infrastructure of the Ug-One platform, consistency and partition tolerance are the two most important elements. Therefore, MongoDB was chosen because it offers consistency (all nodes see the same data at the same time) and partition tolerance (the system must work continuously without the loss of messages or partition failure).

MongoDB [44] is a document store database where doc-uments are grouped in collections. These docdoc-uments may vary in structure. MongoDB contains different nodes and for each MongoDB node only 2GB can be stored. The reason for this is the memory usage because if the performance wants to be increased, the data files will be mapped in the memory. For setting up the MongoDB database, the Cloud Atlas platform [45] was first used. For a free tier of 512 MB storage, shared RAM and shared vCPU, the MongoDB database can be used free of charge forever. This MongoDB database can be hosted on the servers of AWS, Google Cloud Platform or Azure. Cloud Atlas is a good way to deploy a database for an application in development. But it is not suitable for production, so in order to remove the restrictions on storage, RAM and vCPU, the MongoDB database was virtualized via Docker. This ensured that these limitations were gone.

IX. CONCLUSION

By researching and combining already existing

technologies and ideas from the world of cloud computing, a new DaaS platform has been created, allowing developers with no previous drone experience to develop and deploy applications on drones. While the platform offers the convenience of application and drone management through a web interface, it continues to be modular and very capable as well. Applications can run on any drone that has the required hardware components and often can run on the back-end as well with little to no modification. If the goal was to create a platform that is usable and reliable enough so that researchers and developers can start using it, then it seems that this goal has been achieved.

REFERENCES

[1] (2020) Pixhawk. [Online]. Available: https://pixhawk.org/

[2] (2020) Ardupilot. ArduPilot. [Online]. Available: https://ardupilot.org/

[3] PX4 Dev Team. (2020) Pixhawk 4 autopilot. [Online]. Available: https:

//docs.px4.io/v1.9.0/en/flight controller/pixhawk4.html [4] P. D. Team. (2019) Px4 documentation v1.10.1.

[Online]. Available: https://docs.px4.io/v1.10/en [5] (2019) Raspberry pi website. Raspberry Pi Foundation.

[Online]. Available: https://www.raspberrypi.org/ [6] (2020) Docker. [Online]. Available:

https://www.docker.com/

[7] vincentwoo. (2020) Proposal: Docker should assist in bandwidth limiting containers. [Online]. Available: https://github.com/moby/moby/issues/26767

[8] (2020) Mavlink developer guide. Dronecode. [Online]. Available: https://mavlink.io/en/

[9] (2020) Mavsdk documentation. Dronecode. [Online]. Available: https://mavsdk.mavlink.io/develop/en/ [10] (2020) pip- the python package installer. Python

Software Foundation. [Online]. Available: https://pip.pypa.io/en/stable/

[11] “Mavlink router,” Intel Corporation. [Online]. Available: https://github.com/intel/mavlink-router [12] (2020) Openvpn. Openvpn Inc. [Online]. Available:

https://openvpn.net/

[13] A. D. Madhuri A. Jadhav, Balkrishna R. Sawant, “Single page application using angularjs,” Department of Computer Engineering Lokmanya Tilak College of Engineering Koparkhairane, Navi.

[14] (2020) Data binding. angularjs. [Online]. Available: https://docs.angularjs.org/guide/databinding

[15] (2020) What is jsx. react enlightment. [Online]. Available: https://www.reactenlightenment.com/ [16] (2020) Understanding the virtual dom. bitsofcode.

[Online]. Available:

https://bitsofco.de/understanding-the-virtual-dom/ [17] (2020) Redux in react. Reactredux. [Online]. Available:

https:

//react-redux.js.org/introduction/why-use-react-redux [18] M. K. Caspers, “React and redux,” Department of

Computer Science, Carl von Ossietzky University of Oldenburg, Germany.

[19] (2020) Context in react. Reactjs. [Online]. Available: https://reactjs.org/docs/context.html

[20] A. B. Thakur. (2020) Redux vs context api. [Online]. Available: https:

//dev.to/ayushmanbthakur/redux-vs-context-api-3182 [21] T. Media. (2020) Node.js & express api — expense

tracker. [Online]. Available: https://youtu.be/KyWaXA NvT0

[22] P. Ranasinghe. (2019) Build a redux-like store with react context and hooks. [Online]. Available: https://bit.ly/36pGxAJ

[23] (2020) Creating a react app. codecademy. [Online]. Available: https://www.codecademy.com/articles/ how-to-create-a-react-app

[24] D. A. Nayyar. (2020) Open-source webservers in 2019. [Online]. Available: https://opensourceforu.com/2020/ 02/the-top-10-open-source-web-servers-in-2019/ [25] (2020) Nginx web server. NGINX. [Online]. Available:

https://www.nginx.com/

[26] (2020) Express. express. [Online]. Available: https://expressjs.com/

[27] C. Peters, “Building rich internet applications with node.js and express.js,” Department of Computer Science, Carl von Ossietzky University of Oldenburg, Germany.

(10)

[29] (2020) Docker-hub-api. npm. [Online]. Available: https://www.npmjs.com/package/docker-hub-api [30] (2020) node-gitlab. npm. [Online]. Available:

https://www.npmjs.com/package/node-gitlab

[31] (2020) node module gitlab. npm. [Online]. Available: https://www.npmjs.com/package/gitlab

[32] (2020) Projects api. gitlab. [Online]. Available: https://docs.gitlab.com/ee/api/projects.html [33] (2020) npm mongoose. npm. [Online]. Available:

https://www.npmjs.com/package/mongoose

[34] (2020) Uav ground control station. Unmanned system technology. [Online]. Available:

https://www.unmannedsystemstechnology.com/category/ supplier-directory/ground-control-systems/

ground-control-stations-gcs/

[35] (2020) Ground control station. wikipedia. [Online]. Available:

https://en.wikipedia.org/wiki/Ground control station [36] E. Ma. (2019) Port forwarding using iptables. [Online].

Available: https:

//www.systutorials.com/port-forwarding-using-iptables/ [37] P. S. (2019) Iptables tutorial. [Online]. Available:

https://www.hostinger.com/tutorials/iptables-tutorial [38] (2020) Udp/datagram sockets. Node.js. [Online].

Available: https://nodejs.org/api/dgram.html [39] I. Lawel. (2019) Sql vs nosql. [Online]. Available:

https://geekflare.com/sql-vs-nosql/

[40] C. Arsenault. (2017) Pros and cons of 8 popular databases. [Online]. Available:

https://www.keycdn.com/blog/popular-databases [41] M. D. Vatika Sharma, “Sql and nosql databases,”

Department of CSE, Jagan Nath University, Jaipur, India.

[42] A. Korpal. (2019) Scaling horizontally and vertically for databases. [Online]. Available: https://bit.ly/2Bas3sJ [43] R. Greiner. (2014) Cap theorem: Explained. [Online].

Available:

https://robertgreiner.com/cap-theorem-explained/ [44] J. B. Veronika Abramova, “Nosql databases: Mongodb

vs cassandra,” Coimbra Institute of Engineering Rua Pedro Nunes, Portugal.

[45] (2020) Cloud atlas. [Online]. Available: https://www.mongodb.com/cloud/atlas

(11)

Cloud-gebaseerd applicatiemanagement voor drones

Martijn Gevaert, Karl-Erik R´ecul´e

Promotors: Prof. dr. Bruno Volckaert, Prof. dr. Filip De Turck Begeleiders: ir. Jerico Moeyersons

Abstract—Drones worden meer en meer alomtegenwoordig, capabel en kost effici¨ent dan ooit tevoren, maar de constante vooruitgang in drone technologie heeft zich niet duidelijk vertaald in het makkelijker ontwikkelen van drone applicaties. Terwijl mature Infrastructure as a Service (IaaS) platformen function-aliteiten aanbieden zoals hardware abstractie, resource allocatie en tools om applicaties van op afstand te managen, bieden commerci¨ele drones vaak een restrictieve software omgeving aan. Ge¨ınspireerd door het technisch succes en gebruiksgemak van IaaS platformen werd in deze thesis het doel voor ogen gehouden om die ervaring te brengen naar drones. Dit resulteerde in de creatie van het Ug-One Drones as a Service (DaaS) platform.

Omdat veel van de doelen voor het DaaS platform overeenkwa-men met deze van een IaaS platform koovereenkwa-men ook veel van de technologie¨en gebruikt in het DaaS platform uit de wereld van Cloud computing. Applicaties die gecre¨eerd worden voor drones zijn geplaatst in containers aan de hand van Docker en applicatie management kan gedaan worden via een web interface. De drones hosten een REST API voor platform management en ze hebben een Linux computer aan boord. Developers kunnen applicaties deployen op de drones, of ze kunnen de nodige data doorsturen en hun applicaties op een remote server plaatsen.

Deze aanpak heeft veelbelovende resultaten opgeleverd wan-neer deze werd getest aan de hand van meerdere referentie appli-caties die enerzijds real-world appliappli-caties zoals video-streaming en drone besturing nabootsten, of anderzijds simpelweg stress testen die het systeem controleerden op vlak van betrouw-baarheid en beschikbetrouw-baarheid van resources.

Uiteindelijk slaagde het Ug-One platform erin om drone applicatieontwikkeling, deployment en management te vereen-voudigen terwijl het wel de onderhoudbaarheid, betrouwbaarheid en veelzijdigheid behoudt die vereist is van eender welk drone platform.

Index Terms—Drones, applicatie management, Drones as a Service, Docker, Infrastructure as a Service

I. EEN DRONE BETROUWBAAR DOEN VLIEGEN

Zoals bij de meeste luchtvaartsystemen moeten drones betrouwbaar en grondig getest zijn, maar dit vertraagt on-twikkeling. Iedere keer als software of hardware die de drone aanstuurt aangepast wordt moet alles opnieuw getest worden. Om dit soort vertragingen te voorkomen kunnen open-source autopiloten zoals Pixhawk [1] en ArduPilot [2] gebruikt worden, met de Pixhawk 4 [3] en de PX4 software [4] degene die gebruikt werd tijdens de ontwikkeling van dit platform. Door ´e´en van deze grondig geteste, onderhouden en gedocumenteerde autopiloten te gebruiken hebben developers niet meer de tijd of vaardigheden nodig om zelf een autonome drone te ontwikkelen. In de plaats daarvan kunnen ze zich focussen op hun applicaties die geplaatst worden op een aparte onboard Linux computer. Als de Linux computer faalt, dan zal de autopilot de drone simpelweg terug naar huis brengen.

II. DRONE APPLICATIES DRAAIEN

De onboard computer hardware en software kan nu geop-timaliseerd worden voor applicatie deployment, performantie en effici¨entie in de plaats van redundantie en betrouwbaarheid. Dit zorgt ervoor dat nu ook mainstream ingebedde computers zoals een Raspberry Pi [5] kunnen gebruikt worden.

Aangezien de meeste van de drone specifieke uitdagingen nu worden opgelost door de autopiloot begint de onboard computer sterk te lijken op een remote deployment server. Zelfs de connectie naar de drone wordt nu ge¨ımplementeerd aan de hand van een simpele netwerkverbinding. Dit werd gedaan aan de hand van Wi-Fi tijdens de ontwikkelingsfase van het platform, maar de drones kunnen even goed aan een mobiel netwerk verbonden worden.

III. DOCKER OP EEN DRONE

Omdat de onboard computer nu de rol op zich neemt van een remote deployment server kan de software die er op draait nu ten volle genieten van de voordelen van technologie¨en zoals Docker [6]. Dit gaat zo ver dat iedere component of applicatie die draait op de drones, draait in een container. Door dit te doen wordt het systeem niet alleen stabieler, maar het verbeterd ook de hardware compatibiliteit en het maakt het makkelijk om het systeem op te zetten.

Het is ook veel eenvoudiger om de resources te managen die beschikbaar zijn voor applicaties in containers. Dit is kritiek gezien zonder resource management iedere applicatie zo veel resources kan gebruiken als die wil. Dit kan resulteren in applicaties die trager werken dan verwacht, of zelfs crashen.

A. Resource management

Resource management en applicatie management worden gedaan aan de hand van een component die Ug-One API noemt en op iedere Ug-One drone draait in een container. Naast andere verantwoordelijkheden, maakt deze een REST API beschikbaar die kan gebruikt worden om makkelijk de drones te integreren in een cloud backend. De API is ont-worpen om alle Docker functionaliteiten aan te bieden die nodig zijn om applicaties te managen, maar met de nodige beperkingen om resources te kunnen garanderen. De API biedt ook enkele endpoints aan die informatie aanbieden over de drone zoals de verbonden USB-toestellen, beschikbare schrijfruimte en het huidige geheugen gebruik.

De Ug-One API kan een vaste hoeveelheid geheugen garan-deren voor iedere applicatie aan de hand van onderliggende Docker functionaliteiten, maar deze kan geen vast percentage CPU tijd garanderen. In de plaats daarvan biedt deze de

(12)

gebruikt wordt, kan iedere applicatie zo veel CPU rekenkracht gebruiken als deze wil. Echter, zodra er competitie ontstaat tussen applicaties, zal de CPU tijd verdeeld worden aan de hand van het gewicht dat toegewezen werd aan iedere applicatie die op dat moment rekenkracht wil.

B. Niet gemanagede resources

CPU en geheugen worden gemanaged door het systeem, maar wat het systeem niet kan is netwerk bandbreedte toewi-jzen en schijfruimte beperken. Netwerk bandbreedte toewitoewi-jzen is op dit moment nog geen deel van Docker [7] en terwijl het mogelijk is om de totale grote van een Docker containers te beperken, is het nog niet mogelijk om het volume dat gebruikers op de host kunnen mounten te beperken.

Ondanks deze tekortkomingen is de Ug-One API nog steeds in staat om betrouwbaar containers te managen en twee kritieke resources te garanderen. Daarom wordt deze gebruikt om alle applicaties te managen op een Ug-One drone, inclusief zichzelf.

IV. DE AUTOPILOOT BESTUREN

Naast de onboard computer heeft ieder drone ook een eigen autopiloot. Deze autopiloten zijn goed in het volgen van precieze instructies zoals volg dit pad, vlieg naar deze co¨ordinaten en vlieg aan deze snelheid. Deze instructies worden gecommuniceerd aan de hand van het open-source MAVLink protocol [8], dat gebruikt wordt door de twee meest populaire en geavanceerde open-source software autopiloot projecten, PX4 en ArduPilot [2].

Aangezien de meeste software developers weinig ervaring hebben met het MAVLink protocol werd de open-source MAVSDK gecre¨eerd door het team achter Pixhawk [9]. Jam-mer genoeg kan MAVSDK niet ge¨ınstalleerd worden aan de hand van pip [10] op ARM-toestellen zoals een Raspberry Pi 4. Om dit op te lossen werd binnen deze thesis een Docker base image gemaakt die een lokaal gebouwde versie van MAVSDK ge¨ınstalleerd heeft staan. Er is echter veel com-municatie terug te vinden online dat pip ondersteuning voor ARM onderweg is.

V. MAVLINK COMMUNICATIE PIJPLIJN

Terwijl MAVSDK kan gebruikt worden om “MAVLink te praten”, moet er nog steeds een communicatie pijplijn aanwezig zijn tussen de autopiloot en de applicaties die MAVSDK gebruiken. Tussen de autopiloot en onboard com-puter wordt dit gedaan aan de hand van een UART-verbinding. Op de onboard computer zelf runt MAVLink-Router [11], een programma die dan de berichten doorstuurt via UDP naar applicaties op de drone zelf of eender waar anders, zoals een cloud back-end of zelfs een andere drone.

Vanwege dat alle applicaties in containers draaien op het Ug-One platform is het mogelijk om eenzelfde applicatie die communiceert met de autopiloot te draaien op de drone zelf, of eender welk ander verbonden toestel. Dit gedrag werd

loot. Deze applicatie werd gedraaid op de onboard computer, de back-end en een derde toestel dat verbonden werden over LAN.

Om al deze toestellen mekaar te laten vinden over het inter-net is ieder toestel verbonden aan een Virtual Private Network, op de drones was dit aan de hand van OpenVPN [12].

Gezien meerder autopiloten het MAVLink protocol ge-bruiken zou het mogelijk moeten zijn om eenvoudig een autopiloot te vervangen door een andere, of in andere woorden, dezelfde applicatie voor verschillende drones met verschil-lende autopiloten gebruiken.

VI. REFERENTIE IMPLEMENTATIES EN VALIDATIE

Om de functionaliteiten van het Ug-One platform te valid-eren en demonstrvalid-eren werden meerdere refvalid-erentie applicaties gemaakt. Deze hebben het bijkomende voordeel dat ze demon-streren hoe bepaalde applicaties kunnen ontwikkeld worden door developers die willen applicaties maken voor het Ug-One platform.

A. Video streaming

De eerste applicatie was een applicatie die verbind met een onboard camera en dan video streamed naar onboard en off-board applicaties. Deze applicatie kan nog significant geoptimaliseerd worden, maar was toch al in staat om een hoge resolutie stream aan te bieden aan onboard applicaties en een lage resolutie stream aan off-board applicaties. Dit reduceerde bandbreedte en batterij verbruik.

B. Stress testen

Het doel van de tweede applicatie was om simpelweg een stress test te runnen en zo veel mogelijk resources te gebruiken. Deze applicatie werd gebruikt om de resource management functionaliteiten van de Ug-One drones te valid-eren. Zoals verwacht lukte het deze applicatie nooit om zijn geheugen limiet te overschrijden en kon deze enkel CPU tijd opeisen in verhouding met het toegewezen gewicht.

Dit betekent dat geen enkele kritieke container met een sig-nificant hoger CPU gewicht ooit een vertraging heeft ervaren terwijl de stress test aan het lopen was.

C. MAVLink applicaties

De laatste applicatie is een container die telemetrie data kan uitlezen aan de hand van MAVSDK en het MAVLink protocol, maar deze is reeds eerder besproken.

VII. SYSTEEM OVERZICHT

Op dit moment zijn reeds meerdere componenten van het Ug-One platform al besproken, maar zoals zichtbaar in Figuur 1, zijn dit vooral componenten die onderdeel zijn van de drones zelf. Het tweede deel van dit abstract zal zich meer focussen op de tweede helft van Figuur 1, de Ug-One backend.

(13)

Fig. 1. Ug-One systeem componenten overzicht

VIII. MANAGEN VAN EEN DRONE FLEET

Een gebruiker kan zijn applicaties deployen en beheren, resources opvragen en meer via de REST API op de drone. Maar deze manier van werken is niet gebruiksvriendelijk en zeker niet wanneer meerdere applicaties op meerdere drones moeten worden beheerd. Om die applicaties op een snelle en eenvoudige manier te kunnen beheren is een cloud infras-tructuur nodig. De voorgestelde cloud infrasinfras-tructuur die werd gecre¨eerd biedt een webapplicatie aan die gebruikers in staat stelt om eenvoudig applicaties te implementeren, overzicht te houden over hun dronefleet, resources te beheren op de drones, enz. Omdat de webinterface dynamische content laat zien aan de gebruikers, is er ook behoefte aan een back-end API en een database. Deze back-end API is de centrale unit van de cloud-infrastructuur die de verzoeken stuurt en ontvangt van en naar de webserver, database, drones, API-servers, enz. Naast de webserver, back-end API en database is er nog een laatste component aanwezig op de cloud, een UDP Port Forward Server. Deze component biedt de mogelijkheid aan om dynamisch verbindingen te maken tussen de drones en de devices van de gebruiker. Op deze manier kunnen one-to-one, one-to-many, many-to-one and many-to-many verbindingen worden opgezet. De componenten front-end, back-end API, database en UDP Port Forward Server worden in de volgende paragrafen nader besproken.

A. Front-end

Om ervoor te zorgen dat gebruikers hun drones en hun applicaties makkelijk kunnen beheren, werd er een webap-plicatie gemaakt. Via de webapwebap-plicatie kunnen verschillende Docker-applicaties op de drone worden gedeployed. Het is ook mogelijk om van deze Docker-applicaties informatie op te halen, te stoppen, te herstarten en te verwijderen van de drone. Via de webapplicatie kunnen Docker-images, die op Docker Hub of GitLab worden opgeslagen, aan de cloud wor-den gekoppeld. Die gekoppelde images kunnen dan gebruikt worden bij de deployment van de Docker-applicaties op de drone. Om deze webapplicatie te maken zijn verschillende front-end frameworks bestudeerd en is de keuze gemaakt om de React framework te gebruiken. React [13] is geen echt framework maar een UI-bibliotheek die gebruik maakt van een component-gebaseerde architectuur zoals bijvoorbeeld An-gular. React wordt gekarakteriseerd door verschillende func-ties zoals one-way-databinding [14], JSX [15] en de Virtual DOM [16].

In tegenstelling tot het Angular framework heeft React geen app-level state. Alle states moeten worden opgeslagen in de verschillende componenten van de webapplicatie. Deze verschillende componenten moeten hun state doorgeven aan andere componenten, zodat deze op hun beurt hun state door kunnen geven aan andere componenten en zo verder. Voor grotere projecten kan dit leiden tot fouten en problemen bij het beheer van de applicatie. Dit probleem kan worden opgelost door gebruik te maken van Redux [17, 18] of Context API [19]. Redux en Context API [20] gebruiken bepaalde structuren en componenten om de globalstate van de app te beheren. Ze bieden ook de mogelijkheid aan om eenvoudiger te werken door deze ene globalestate. Bij het maken van de webapplicatie werd een combinatie van Redux en Context API gebruikt [21, 22]. De Context API methodes worden gebruikt om de structuur en componenten van Redux na te maken. Redux zelf is niet eenvoudig te begrijpen en te gebruiken. Door beide app-level state managers te combineren, is het voor de developer makkelijker en sneller om een webapplicatie met een app-level state te ontwikkelen. Toch moet er worden opgemerkt dat bij het ontwikkelen van grotere, complexere webapplicaties, Redux zeker aan te raden is omdat het de data beter en duidelijker kan beheren en tools aanbiedt voor het managen van de app-level state.

Wanneer React is ge¨ınstalleerd met de npm module create-react-app [23], wordt een developmentserver bij deze module meegeleverd aan de developer. Met deze developmentserver kunnen developers hun webapplicatie ontwikkelen en testen. Wanneer de webapplicatie gebruikt wil worden in productie, moet een meer betrouwbare server gekozen worden. Daarom zijn er verschillende webservers bestudeerd [24]. Voor de deployment van de webserver is er gekozen voor NGINX [25]. Deze webserver heeft een lage memory load, is lightweight en heeft de basisfunctionaliteiten om een webserver te hosten.

(14)

uit de database, API-servers als uit de drones, kan halen, is er nood aan een centrale unit die deze informatie ophaalt. Deze unit moet er ook voor zorgen dat de drones gegevens uit de database kunnen halen en het mogelijk maakt dat drones zichzelf hiermee ook kunnen configureren. Deze centrale unit is de Back-end API, die gemaakt is door een Node.js server en de npm module Express [26]. Door onderzoek te verrichten zijn verschillende frameworks bestudeerd en het framework Express.js [27] is gekozen omdat het een groot aantal HTTP utility methodes en middleware biedt bovenop de bestaande Node.js functies.

Om een verbinding te maken met de database, drones en API servers, worden verschillende node modules gebruikt. De eerste node module is Axios [28], wat een promise-based HTTP client npm module is voor de browser en Node.js. Via Axios is het mogelijk om informatie op te halen, de applicaties te beheren en resources op te vragen door gebruik te maken van de drones hun Ug-One API. Via de node module docker-hub-api [29] kan informatie van Docker Hub images uit een public register worden opgehaald. Om informatie van een Docker Image op GitLab op te halen, is eerst geprobeerd om opnieuw de informatie via een node-module te verkrijgen. Deze node modules waren node-gitlab [30] en gitlab [31]. Vanwege het gebrek aan documentatie en het ontbreken van functies die Docker images kunnen ophalen, is er gekozen voor de GitLab API. Met de GitLab API server [32], kunnen de verschillende Docker images als hun informatie worden opgehaald. De Mongoose node module [33] wordt gebruikt om toegang te krijgen tot de MongoDB database in de cloud zodat de data kan beheerd worden alsook de database structuur aan te passen.

C. UDP Port Forward Server

Wanneer de drone geconfigureerd en opgestart is, is het in staat om MAVLink-berichten te versturen via het UDP-protocol naar een applicatie op het apparaat van een gebruiker, zoals een ground control station. Een ground control station is een typische softwaretoepassing die op een computer op de grond draait. Via draadloze telemetrie communiceert de computer op de grond met de UAV (unmanned aerial vehicle). Een ground control station kan real-time gegevens over de prestaties, positie, hoogte, enz. van de UAV’s weergeven en het kan ook worden gebruikt om een UAV tijdens de vlucht te besturen, nieuwe missiecommando’s te uploaden en param-eters in te stellen zoals de vlieghoogte [34, 35]. Als de drone klaar is om te vliegen, kan hij zijn MAVLink-berichten direct naar het apparaat van de client sturen. Maar deze directe drone-gebruiker verbinding heeft een aantal nadelen. Wanneer de drone is opgestart, moet er een IP-adres aan de drone worden meegegeven om zijn MAVLink berichten naartoe te sturen. Dit IP-adres kan niet worden gewijzigd wanneer de drone actief is, dus wanneer het IP-adres van de gebruiker verandert, zal de verbinding met de drone verloren gaan. Ook wanneer een andere gebruiker de drone wil overnemen, voorkomt deze

turen naar eenzelfde endpoint van een applicatie of de back-end. Er kan gekozen worden om te proberen de MAVLink-berichten te onderscheiden van de verschillende drones die naar dat endpoint sturen, maar dit kan leiden tot complexe systemen binnen deze endpoint.

Om deze verschillende problemen op te lossen, werd er een protocol tussen de drone en back-end opgezet en een UDP Port Forward Server gecre¨eerd. Het protocol houdt in dat wanneer een drone opstart, een van de eerste acties die deze zal uitvoeren het sturen is van een request naar de Back-end API om te onderhandelen over een MavlinkPort. Wanneer de drone is geregistreerd op het platform, zal deze een MavlinkPort ontvangen. Deze Mavlinkport is de poort op de UDP Port Forward Server of applicatie waarnaar de drone zijn MAVLink-berichten moet naar toe sturen. Deze MavlinkPort zorgt ervoor dat enkel maar die ene drone naar die ene poort mag sturen. Dit lost het probleem op dat verschillende drones naar dezelfde endpoint zouden sturen.

Zoals de naam van de UDP Port Forward Server al aangeeft, zal deze server UDP-berichten doorsturen naar een andere poort op een ander IP-adres. Om het doorsturen van de UDP-berichten te configureren, moet een REST-request worden verzonden naar de UDP Port Forward Server. Deze REST request zal de poorten dynamisch openen of sluiten en het doorstuurmechanisme configureren. Via deze UDP Port For-ward Server kunnen meerdere drones hun MAVLink-berichten naartoe sturen en zal de server ze doorsturen naar de juiste ge-bruiker. Via de webapplicatie, kan de gebruiker ervoor zorgen dat deze MAVLink-berichten aankomen op het apparaat van de gebruiker waarop de applicatie draait. De webapplicatie stuurt een request naar de back-end API met de configuratiegegevens. De back-end API zal op zijn beurt extra gegevens uit de database halen en deze naar de UDP Port Forward Server sturen. Met behulp van deze configuratiegegevens kan de UDP Port Forward Server zowel de MavlinkPort als een ClientPort op de UDP Port Forward Server openen. De ClientPort is een poort die wordt gebruikt om de data van de gebruiker door te sturen naar de MavlinkPort op het IP-adres van de drone. Op deze manier kunnen meerdere drones verbinding maken met de cloud en kunnen gebruikers al hun drones monitoren met een ground control station.

Wanneer het IP-adres van de gebruiker verandert of wanneer een andere gebruiker de drone wil monitoren of controleren, is dit geen probleem meer. Door de poorten en IP-adressen van een drone en een gebruiker opnieuw te configureren op de UDP Port Forward Server, kan een gebruiker opnieuw verbinding maken met zijn drone, kan een andere gebruiker de controle van een drone overnemen of de data van de drone forwarden naar een andere applicatie. Voor het maken van zo’n UDP Port Forward Server is onderzoek gedaan en een oplossing gevonden. De eerste oplossing was een router te gebruiken waarvan de Routing- en IPTables konden worden aangepast [36, 37]. Deze oplossing had ´e´en nadeel, de router moest iedere keer opnieuw worden opgestart als de UDP Port

(15)

Forward Server nieuwe doorstuurverbindingen zou opzetten. De oplossing die werd gebruikt voor de cloud applicatie is een API Server. Op deze server kunnen UDP-sockets (poorten) dy-namisch worden geopend en gesloten. Ook kunnen inkomende requests met configuratiedetails worden afgehandeld en de poorten worden ingesteld. Voor de eenvoud is Express.js ook gebruikt om een API Server te deployen. Om de UDP-berichten door te sturen, werden verschillende mogelijkheden ge¨evalueerd. Uiteindelijk werd de node module dgram [38] gekozen. Het bevat een uitgebreide documentatie en kan eenvoudig worden geconfigureerd.

D. Database

Voor de ontwikkeling van een cloudplatform mag een database niet ontbreken. Voor de cloud infrastructuur is er gekozen voor slechts ´e´en database, maar er kunnen meerdere soorten databases worden gebruikt. Voordat een database kan worden ingezet, is onderzocht welke database het meest geschikt is voor het cloud platform [39, 40, 41]. Door het afwe-gen van de voor- en nadelen, is er gekozen voor een NoSQL database. NoSQL databases zijn gemakkelijker horizontaal te schalen dan SQL databases [42] omdat een NoSQL database ervoor zorgt dat als de data die moet worden opgeslagen groeit, de database gemakkelijk kan worden uitgebreid. Ook is het niet nodig om een voorgedefinieerd schema te maken en NoSQL databases zijn meer geschikt voor het verwerken van grote hoeveelheden data dan SQL databases [41]. Dit is belangrijk omdat verschillende toepassingen op de drones, veel verschillende soorten gegevens met verschillende structuren zal opslaan. Deze data kan op de drone maar ook in de database worden opgeslagen.

Door de verschillende NoSQL databases te vergelijken en rekening te houden met de CAP stelling [43], is gekozen voor de MongoDB database. De CAP stelling stelt dat het moeilijk is voor een gedistribueerde datastore om meer dan twee van de volgende elementen terzelfdertijd te leveren: consistentie, availability en partitietolerantie. Voor de cloud infrastructuur van het Ug-One platform zijn consistentie en partitietoler-antie de twee belangrijkste elementen. Daarom is gekozen voor MongoDB omdat het consistentie biedt (alle nodes zien dezelfde data op hetzelfde moment) en partitietolerantie (het systeem moet continu werken zonder dat er berichten verloren gaan of dat de partitie uitvalt).

MongoDB [44] is een document stored database waar doc-umenten worden gegroepeerd in collecties. Deze docdoc-umenten kunnen vari¨eren in structuur. MongoDB bevat verschillende nodes en voor elke MongoDB-node kan slechts 2GB worden opgeslagen. De reden hiervoor is het geheugengebruik zodat als de prestaties willen worden verhoogd, de documents in het geheugen opgeslagen worden. Voor het opzetten van de MongoDB database is eerst gebruik gemaakt van het Cloud Atlas platform [45]. Voor een gratis tier van 512 MB opslag, gedeeld RAM en gedeelde vCPU kan de MongoDB database voor altijd gratis gebruikt worden. Deze MongoDB database kan worden gehost op de servers van AWS, Google Cloud Platform of Azure. Cloud Atlas is een goede manier om een

database op te zetten voor een applicatie in ontwikkeling. Maar het is niet geschikt voor productie, dus om de beperkingen op het gebied van opslag, RAM en vCPU weg te nemen, is de MongoDB-database gevirtualizeerd via Docker. Dit zorgde ervoor dat deze beperkingen wegvielen.

IX. CONCLUSIE

Door het onderzoeken en combineren van reeds bestaande technologieën en ideeën uit de wereld van cloud computing is een nieuw DaaS-platform gecreëerd, waardoor developers zonder eerdere drone-ervaring applicaties op drones kunnen ontwikkelen en deployen. Hoewel het platform het gemak van applicatie- en dronemanagement via een webinterface biedt, blijft het ook modulair en zeer betrouwbaar. Applicaties kunnen draaien op elke drone die de vereiste hardwarecomponenten heeft en kunnen vaak ook op de back-end draaien met weinig tot geen aanpassingen. Als het doel was om een platform te creëren dat bruikbaar en betrouwbaar genoeg is zodat onderzoekers en developers het kunnen gaan gebruiken, dan lijkt het erop dat dit doel is bereikt.

REFERENCES

[1] (2020) Pixhawk. [Online]. Available: https://pixhawk.org/

[2] (2020) Ardupilot. ArduPilot. [Online]. Available: https://ardupilot.org/

[3] PX4 Dev Team. (2020) Pixhawk 4 autopilot. [Online]. Available: https:

//docs.px4.io/v1.9.0/en/flight controller/pixhawk4.html [4] P. D. Team. (2019) Px4 documentation v1.10.1.

[Online]. Available: https://docs.px4.io/v1.10/en [5] (2019) Raspberry pi website. Raspberry Pi Foundation.

[Online]. Available: https://www.raspberrypi.org/ [6] (2020) Docker. [Online]. Available:

https://www.docker.com/

[7] vincentwoo. (2020) Proposal: Docker should assist in bandwidth limiting containers. [Online]. Available: https://github.com/moby/moby/issues/26767

[8] (2020) Mavlink developer guide. Dronecode. [Online]. Available: https://mavlink.io/en/

[9] (2020) Mavsdk documentation. Dronecode. [Online]. Available: https://mavsdk.mavlink.io/develop/en/ [10] (2020) pip- the python package installer. Python

Software Foundation. [Online]. Available: https://pip.pypa.io/en/stable/

[11] “Mavlink router,” Intel Corporation. [Online]. Available: https://github.com/intel/mavlink-router [12] (2020) Openvpn. Openvpn Inc. [Online]. Available:

https://openvpn.net/

[13] A. D. Madhuri A. Jadhav, Balkrishna R. Sawant, “Single page application using angularjs,” Department of Computer Engineering Lokmanya Tilak College of Engineering Koparkhairane, Navi.

[14] (2020) Data binding. angularjs. [Online]. Available: https://docs.angularjs.org/guide/databinding

(16)

[16] (2020) Understanding the virtual dom. bitsofcode. [Online]. Available:

https://bitsofco.de/understanding-the-virtual-dom/ [17] (2020) Redux in react. Reactredux. [Online]. Available:

https:

//react-redux.js.org/introduction/why-use-react-redux [18] M. K. Caspers, “React and redux,” Department of

Computer Science, Carl von Ossietzky University of Oldenburg, Germany.

[19] (2020) Context in react. Reactjs. [Online]. Available: https://reactjs.org/docs/context.html

[20] A. B. Thakur. (2020) Redux vs context api. [Online]. Available: https:

//dev.to/ayushmanbthakur/redux-vs-context-api-3182 [21] T. Media. (2020) Node.js & express api — expense

tracker. [Online]. Available: https://youtu.be/KyWaXA NvT0

[22] P. Ranasinghe. (2019) Build a redux-like store with react context and hooks. [Online]. Available: https://bit.ly/36pGxAJ

[23] (2020) Creating a react app. codecademy. [Online]. Available: https://www.codecademy.com/articles/ how-to-create-a-react-app

[24] D. A. Nayyar. (2020) Open-source webservers in 2019. [Online]. Available: https://opensourceforu.com/2020/ 02/the-top-10-open-source-web-servers-in-2019/ [25] (2020) Nginx web server. NGINX. [Online]. Available:

https://www.nginx.com/

[26] (2020) Express. express. [Online]. Available: https://expressjs.com/

[27] C. Peters, “Building rich internet applications with node.js and express.js,” Department of Computer Science, Carl von Ossietzky University of Oldenburg, Germany.

[28] (2020) axios. npm. [Online]. Available: https://www.npmjs.com/package/axios

[29] (2020) Docker-hub-api. npm. [Online]. Available: https://www.npmjs.com/package/docker-hub-api [30] (2020) node-gitlab. npm. [Online]. Available:

https://www.npmjs.com/package/node-gitlab

[31] (2020) node module gitlab. npm. [Online]. Available: https://www.npmjs.com/package/gitlab

[32] (2020) Projects api. gitlab. [Online]. Available: https://docs.gitlab.com/ee/api/projects.html [33] (2020) npm mongoose. npm. [Online]. Available:

https://www.npmjs.com/package/mongoose

[34] (2020) UAV ground control station. Unmanned system technology. [Online]. Available:

https://www.unmannedsystemstechnology.com/category/ supplier-directory/ground-control-systems/

ground-control-stations-gcs/

[35] (2020) Ground control station. wikipedia. [Online]. Available:

https://en.wikipedia.org/wiki/Ground control station

//www.systutorials.com/port-forwarding-using-iptables/ [37] P. S. (2019) Iptables tutorial. [Online]. Available:

https://www.hostinger.com/tutorials/iptables-tutorial [38] (2020) Udp/datagram sockets. Node.js. [Online].

Available: https://nodejs.org/api/dgram.html [39] I. Lawel. (2019) Sql vs nosql. [Online]. Available:

https://geekflare.com/sql-vs-nosql/

[40] C. Arsenault. (2017) Pros and cons of 8 popular databases. [Online]. Available:

https://www.keycdn.com/blog/popular-databases [41] M. D. Vatika Sharma, “Sql and nosql databases,”

Department of CSE, Jagan Nath University, Jaipur, India.

[42] A. Korpal. (2019) Scaling horizontally and vertically for databases. [Online]. Available: https://bit.ly/2Bas3sJ [43] R. Greiner. (2014) Cap theorem: Explained. [Online].

Available:

https://robertgreiner.com/cap-theorem-explained/ [44] J. B. Veronika Abramova, “Nosql databases: Mongodb

vs cassandra,” Coimbra Institute of Engineering Rua Pedro Nunes, Portugal.

[45] (2020) Cloud atlas. [Online]. Available: https://www.mongodb.com/cloud/atlas

(17)

List of Figures

Chapter 2

2.1 System components overview . . . 35 2.2 Raspberry Pi 4B [1] . . . 36 2.3 OpenVPN logo [2] . . . 39 Chapter 3

3.1 Pixhawk logo [3] . . . 42 3.2 Navio2 Raspberry Pi shield . . . 43 3.3 Pixhawk 4 autopilot . . . 44 3.4 Holybro PMO7 Power Management Board . . . 45 3.5 Included GPS module . . . 45 3.6 PX4 logo [4] . . . 46 3.7 Quadcopter yaw, pitch and roll . . . 48 3.8 MAVLink logo . . . 49 3.9 MAVSDK logo [5] . . . 52 Chapter 4

4.1 Flask logo [6] . . . 59 4.2 Docker logo [7] . . . 62 4.3 Javascript Object Notation (JSON) Schema logo [8] . . . 72 4.4 Open API and Swagger logo [9] . . . 74 4.5 Endpoints overview . . . 75 4.6 Ping endpoint overview . . . 75 4.7 Ping endpoint response model . . . 76 4.8 A swagger-UI generated example body . . . 76 4.9 Flask RESTX logo [10] . . . 77 Chapter 5

5.1 Automatically negotiated MAVLink port on web interface . . . 90 22

(23)

LIST OF FIGURES 23 Chapter 6

6.1 Use case: new year in Shanghai [11] . . . 102 6.2 Overview of the most important information of the Drone . . . 104 6.3 Location of the Drone . . . 105 6.4 Overview of the hardware mounted on the drone . . . 106 6.5 Overview of the resources on the drone . . . 106 6.6 Overview of the available Docker containers on a drone . . . 107 6.7 Info of an available image linked to the system . . . 108 Chapter 7

7.1 Static versus Dynamic websites: Requesting webpages [12] . . . 111 7.2 Multi-page applications and single-page applications Life cycle [13] . . . 113 7.3 Logo Angular [14] . . . 114 7.4 One-way data binding [15] . . . 115 7.5 Two-way data binding [16] . . . 115 7.6 Vue Logo [17] . . . 116 7.7 React Logo [18] . . . 117 7.8 Ember.js Logo [19] . . . 119 7.9 npm trends React-Vue-Angular-Ember in the past two years[20] . . . 120 7.10 DOM tree of a webpage [21] . . . 123 7.11 Visualization React app without or with Redux [22] . . . 126 7.12 Redux flow [23] . . . 127 7.13 Web Server Basic HTTP Request [24] . . . 134 7.14 Top 6 Different Web Servers [25] . . . 135 Chapter 8 8.1 Logo Laravel [26] . . . 141 8.2 Logo Django [27] . . . 141 8.3 Model-View-Template architecture [28] . . . 142 8.4 Logo Ruby-on-Rails [29] . . . 143 8.5 Logo Express.js [30] . . . 143 8.6 Logo Spring Boot [31] . . . 144 8.7 Stack Overflow questions per month about the different back-end frameworks [32] 145 8.8 Scheme how node.js processes incoming requests [33] . . . 146 8.9 Example Scheme how Express.js handles incoming requests and how it requests

data from the MongoDB database [34] . . . 147 Chapter 9

(24)

9.1 Screenshot Mission Planner Ground Control Station [35] . . . 157 9.2 Screenshot APM Planner 2.0 Ground Control Station [36] . . . 158 9.3 Screenshot Mavproxy Ground Control Station [37] . . . 159 9.4 Screenshot QGroundControl application on a pc [38] . . . 160 9.5 Screenshot QGroundControl application on a smartphone [39] . . . 160 9.6 Screenshot Universal Ground Control Station [40] . . . 162 9.7 Communication drone and client without UDP Port Forward Server . . . 164 9.8 Communication drone and client with UDP Port Forward Server . . . 166 9.9 Create dynamically an UDP Socket on the UDP Port Forward Server . . . 171 9.10 Remove a UDP Socket on the UDP Port Forward Server . . . 173 Chapter 10

10.1 Vertical versus Horizontal Scaling [41] . . . 178 10.2 Logo MySQL [42] . . . 178 10.3 Logo PostgreSQL [43] . . . 179 10.4 Logo Oracle database [44] . . . 180 10.5 CAP principle [45] . . . 181 10.6 Logo MongoDB [46] . . . 182 10.7 Logo Firebase [47] . . . 183 10.8 Logo Apache CouchDB [48] . . . 183 10.9 Logo Cassandra Apache [] . . . 184 10.10Database SQL vs NoSQL structure [49] . . . 186 10.11Step one: setup a MongoDB database on Cloud Atlas [50] . . . 189 10.12Step two: Choose cluster resources . . . 190 10.13Setup finished . . . 190 10.14Connection possibilities with Cloud Atlas MongoDB . . . 191 10.15Get MongoDB connectionString suited to the chosen driver . . . 192 10.16Example data in the MongoDB database in Cloud Atlas . . . 193 Chapter 11

11.1 Logo Postman [51] . . . 199 11.2 Swagger of the Back-end API . . . 200 11.3 Different components in the React development tool [52] . . . 201 Chapter 12

12.1 Brushless drone motor [53] . . . 204 12.2 standalone Universal Battery Eliminator Circuit (UBEC) [54] . . . 205 12.3 Add a drone . . . 208 12.4 Hardware of the drone . . . 209

(25)

LIST OF FIGURES 25 12.5 Resources of the drone . . . 209 12.6 Adding Docker images to the platform . . . 210 12.7 Overview of the containers on the drone . . . 212 12.8 Add a container on the drone . . . 212 12.9 Collection infodrones of the Database MongoDB. . . 213 12.10Linking the MAVLink messages from the drone to the client’s ground control station214 12.11Setup QGroundControl (QGC) Part 1 . . . 215 12.12Setup QGC Part 2 . . . 215 12.13Setup QGC Part 3 . . . 216 12.14Setup QGC Part 4 . . . 216

(26)

List of Tables

3.1 Pixhawk and competition comparison . . . 46 3.2 MAVLink Router idle endpoint resource usage . . . 51 5.1 UV4L streaming resource usage . . . 96 7.1 Pros and Cons of AngularJS . . . 115 7.2 Pros and Cons of Angular . . . 116 7.3 Pros and Cons of Vue.js . . . 117 7.4 Pros and Cons of React . . . 118 7.5 Pros and Cons of Ember.js . . . 119 10.1 Pros and Cons of MySQL [55, 56, 57] . . . 179 10.2 Pros and Cons of PostgreSQL [55, 56, 57] . . . 179 10.3 Pros and Cons of Oracle Database [55, 56, 57] . . . 180 10.4 Pros and Cons of MongoDB [55, 56, 57, 58] . . . 182 10.5 Pros and Cons of Firebase [55, 56, 57, 58] . . . 183 10.6 Pros and Cons of CouchDB [55, 56, 57, 58] . . . 184 10.7 Pros and Cons of Cassandra Apache [55, 56, 57, 58] . . . 185