Detectie van landingsplat- formen voor drones · 2018-02-12 · Pi instead of an Asus Tinker Board....

FACULTEIT INDUSTRIELE INGENIEURSWETENSCHAPPEN

TECHNOLOGIECAMPUS DE NAYER

Detectie van landingsplat-formen voor drones

Simon VLEUGELS

Promotor: Prof. dr. ir. Toon Goedeme Masterproef ingediend tot het behalen vande graad van master of Science in de

Co-promotoren: Ing. Maarten Vandersteegen industriele wetenschappen: Elektronica-ICTIng. Dries Hulens afstudeerrichting ICT

Academiejaar 2017 - 2018

c©Copyright KU Leuven

Zonder voorafgaande schriftelijke toestemming van zowel de promotor(en) als de auteur(s) is over-

nemen, kopieren, gebruiken of realiseren van deze uitgave of gedeelten ervan verboden. Voor

aanvragen i.v.m. het overnemen en/of gebruik en/of realisatie van gedeelten uit deze publicatie,

kan u zich richten tot KU Leuven Technologiecampus De Nayer, Jan De Nayerlaan 5, B-2860 Sint-

Katelijne-Waver, +32 15 31 69 44 of via e-mail [email protected].

Voorafgaande schriftelijke toestemming van de promotor(en) is eveneens vereist voor het aan-

wenden van de in deze masterproef beschreven (originele) methoden, producten, schakelingen

en programma’s voor industrieel of commercieel nut en voor de inzending van deze publicatie ter

deelname aan wetenschappelijke prijzen of wedstrijden.

Voorwoord

Het schrijven van deze thesis is voor het behalen van mijn diploma master of Science in de in-

dustriele wetenschappen: Elektronica-ICT Optie: ICT. Tijdens dit werk en de vorige jaren heb ik

steeds kunnen rekenen op de steun van mijn promotors, vrienden en familie. Zonder hen zou ik dit

werk nooit gerealiseerd kunnen hebben.

Om te beginnen zou ik in de eerste plaats mijn promotor en co-promotoren, Prof. dr. ir. Toon

Goedeme, ing. Maarten Vandersteegen en ing. Dries Hullens hartelijk willen bedanken voor hun

steun en raad gedurende deze periode.

Daarnaast zou ik ook de onderzoeksgroep EAVISE willen bedanken voor de extra hulp en de op-

portuniteit voor het afleggen van deze thesis.

Ik zou mijn vriendin, familie en vrienden ook willen bedanken voor de mentale steun en het nalezen

en verbeteren van mijn thesis.

Als laatste zou ik ook alle mensen willen bedanken die hier niet expliciet vermeld zijn. Zonder jullie

steun zou ik nooit zo ver geraakt zijn.

Simon Vleugels

Lint, januari 2018

iii

Abstract

In het dagelijkse leven komt het gebruik van drones steeds meer in de belangstelling, zeker de

volledige autonome werking hiervan. Verschillende grote marktleiders zijn hier intensief onderzoek

naar aan het verichten. Dit concept staat nog in zijn kinderschoenen en er zijn slechts enkele tests

uitgevoerd.

In deze thesis wordt er gezocht naar een algoritme voor de autonome landing van drones. Hiervoor

wordt er een landingsplatform gebruikt dat bestaat uit een landingspatroon, dit wordt via real time

image processing gedetecteerd. De drone moet volledig zelfstandig en onafhankelijk van externe

computers werken. Hierdoor moet er gezocht worden naar een geschikt embedded processing

platform dat aan de strikte vereisten (gewicht, verbuik en processing power) voldoet. Tevens is

er een onderzoek gedaan naar de minimale grote van dit landingspatroon, hierin is er rekening

gehouden met de nauwkeurigheid van GPS-systemen, wat toepassingsgericht meestal gebruikt

zal worden om de drone in de buurt van de bestemming te brengen. Een extra toevoeging bij het

concept van volledige autonome werking, is de werking hiervan in alle lichtcondities. Er is in deze

thesis succesvol gezocht naar een goede belichtingstechniek die niet hinderlijk is voor de omge-

ving om zowel overdag als ’s nachts de autonome werking verder te zetten. De resultaten van deze

twee onderzoeken werden samengenomen en toegepast in de ontwikkeling van een landingsplat-

formmodule.

Keywords: Drones, Real time image processing, Marker detection, Embedded

iv

English Abstract

Drones are getting a bigger place in our society, especially the use of drones in autonomous appli-

cations. Many major companies are doing intensive research, but at this point it is still a concept

and only some tests have been done.

In this thesis we will be searching for an algorithm, which should let drones land autonomous on

a landing platform. This landing platform consists of a landing pattern. With the use of real time

image processing we will be able to detect the landing pattern. The drone shall do this completely

independent, without the use of external computers. This brings us in the need to find the best

embedded processing platform while keeping in mind the strict requirements (weight, power usage

and processing power). A research have been done to find the minimal size of the landing pattern.

In this research the accuracy of GPS-systems is a key element, because this system will be mostly

used in applications to bring the drone in the neighbourhood of the landing site. An extra addition

to the concept of autonomous working of drones is the ability to let the drone land in every light

condition. In this thesis we found a good way to lighten up the landing pattern in way which is not

disturbing for the neighbourhood. These two researches have been combined for the development

of a landing platform module.

Keywords: Drones, Real time image processing, Marker detection, Embedded

v

Short summary

The subject of this thesis, the autonomous landing of drones, is proposed by the research group

EAVISE. This research group is specialized in applying state-of-the-art computer vision techniques

to solve industrial problems. The thesis can be divided in multiple different parts. Mainly the

algoritm for the autonomous landing. Researching which embedded processing platform is the best

choice in this application, while keeping in mind the weight, power consumption and processing

power. Analysing different lighting techniques for the landing pattern, to be able to execute the

algoritme in every light condition. And defining the minimal landing pattern size that is necessary

in practical applications.

Algoritm

It was important to find an algoritm which should be capable of detecting a landing pattern and

reposition the drone above this landing patern. For a fluent and accurate movement of the drone,

the drone has to receive 50 times a second data to reposition himself. An AruCo marker is used

as a landing pattern and with an image obtained from a camera mounted underneath the drone we

can calculate the distance between the marker and the camera. With this distance it was possible

to calculate the velocities, which where send to the drone.

Embedded processing platform

For the previously discussed algoritm to be able to run with the asked performance of sending 50

velocities per second to the drone. We were in a need to find a capable embedded processing

platform. Because we are working with a drone, which has a limited amount of battery power, we

had to keep in mind different important aspects. Such as weight (the heavier, the more battery

consumption) and power consumtion (the higher power consumption, the lower the flight time).

Also the embedded processing platform should be powerfull enough to run the algoritm with the

desired performance. After analysing different processing platform, we choose to use a Raspberry

Pi instead of an Asus Tinker Board. The Raspberry Pi can in the future be replaced by the Asus

Tinker Board if the performance is beneath the requirements.

The complete algoritm has been tested with full load on the Raspberry Pi and we can conclude that

the required performance is achieved. Results are shown in Table 1.

vi

vii

Tabel 1 Results performance ROS-framework

1 2 3 Mean What tested?

Camera node 29,9639 29,9674 29,9705 29,9673 Frame´s per second sended

Arucodetection node 5,1702 5,3230 5,2865 5,2599 Times a second searched for a marker

Kalmanfilter node 49,9790 49,9944 49,9805 49,9846 Datasets per second sended

Pidcontrol node 49,9933 49,9957 49,9964 49,9951 Velocities per second sended

Dronecontrol node 50,0000 50,0000 50,0000 50,0000 Velocities per second to Pixhawk

Lighting techniques

To be able to autonomous use the drone in every light condition there was a need to search for a

way to illuminate the landing pattern without disturbing the neighbourhood. We have tested three

different illumination techniques and we can conclude that the third one, which is a combination

of the previous two, the best one is. In Figure 1 you can see the different results, where Figure

1 (c) is the chosen technique. In this technique the marker is placed on a matt plastic sheet with

backlighting infrared LEDs. Infrared LEDs have been chosen because the NIR infrared spectrum

is not visible for a human being, so it is less disturbing for the neighbourhood.

Figuur 1: Lighting techniques

Size landing pattern

If we look to more practical applications, we see that the system to bring the drone nearby the

landing platform will probably be using a GPS-system. Those systems have a limited accuracy,

which lead to the need to determine the minimum altitude a marker should be able to get detected

and determing the minimal size of the pattern. By the used of this limited accuracy combined with

the viewing angle of the camera, we can calculate the height at which the landing pattern in worst

case scenario should be detected. With a function, we determined after analysing the maximum

detection height of 17 different sizes of landing patterns, we have calculated the theoretical size of

the landing pattern. After some practical tests, we have concluded that it is possible to detect the

landing pattern at worst case scenario.

Inhoudsopgave

Voorwoord iii

Abstract vii

Inhoud x

Figurenlijst xii

Tabellenlijst xiii

Symbolenlijst xiv

Lijst met afkortingen xv

1 Situering en Doelstellingen 1

1.1 Situering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Literatuurstudie 4

2.1 Beweging Drones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 ArUco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 ArUco woordenboek generatie . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.2 ArUco marker detectie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.3 ArUco marker detectie voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Pixhawk flightcontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1 MAVLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.2 MAVROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 Near Infrared Light . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.1 Near IR spectrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.2 Belang NIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

viii

INHOUDSOPGAVE ix

2.5 Camera kalibratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5.1 Problemen pinhole camera model . . . . . . . . . . . . . . . . . . . . . . . 13

2.5.2 Kalibratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.6 Tracker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.6.1 Kalman Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.7 PID-controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.7.1 Werking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.7.2 Binnen deze thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.8 Robot Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.8.1 Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.8.2 Topics en messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.8.3 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.8.4 Voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.9 Onderzoek landingsplatformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.10 Embedded processing platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.10.1 Verband gewicht met verbruik . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.10.2 Overzicht embedded processing platformen . . . . . . . . . . . . . . . . . . 24

2.10.3 Selectie embedded processing platform . . . . . . . . . . . . . . . . . . . . 24

3 Landingsplatformen 26

3.1 Analyse belichtingstechnieken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.1 Belichtingstechniek 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26



3.2 Analyse grote van marker tov detectie hoogte . . . . . . . . . . . . . . . . . . . . . 29

3.2.1 Aanpak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2.2 Analyse resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3 Concept landingsplatform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 Behuizing 35

4.1 Gebruikte behuizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2 Concept behuizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5 Communicatie tussen embedded processing platform en Pixhawk flight controller 38

5.1 Poorten Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.2 Poorten Pixhawk flight controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

INHOUDSOPGAVE x

5.3 Verbinding Pixhawk en Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6 ROS-framework 41

6.1 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.2 ROS-nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.2.1 Camera node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.2.2 Livestream node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.2.3 Arucodetection node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.2.4 Kalmanfilter node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.2.5 Pidcontrol node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.2.6 Dronecontrol node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7 Testen 53

7.1 Performantie ROS-framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.2 Verloop snelheid bij verandering van positie camera tov marker . . . . . . . . . . . . 54

7.3 Praktijktest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

8 Resultaten 57

8.1 Embedded processing platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

8.2 Landingsplatformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

8.3 Behuizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

8.4 Communicatie Raspberry Pi en Pixhawk flight controller . . . . . . . . . . . . . . . 58

8.5 ROS-framework en testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

9 Besluit 59

A Resultaten analyse landingsplatformen 64

Lijst van figuren

1 Lighting techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

1.1 Onderdelen thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Verschillende bewegingen van drones . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 ArUco markers met id (a) 1 en (b) 73 . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 Weergave stappen ArUco marker detectie . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Weergave verschil global en adaptive thresholding . . . . . . . . . . . . . . . . . . 8

2.5 Simulatie van drone (a) zwevend boven marker, (b) bewegend naar voren en (c)

bewegend naar rechts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.6 MAVLink protocol pakket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.7 Integratie van MAVLink in MAVROS . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.8 Structuur elektromagnetische golf . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.9 Elektromagnetisch spectrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.10 (a) radiale distortie, (b) tangentiele distortie . . . . . . . . . . . . . . . . . . . . . . 14

2.11 (a) tonvormige distortie, (b) kussenvormige distortie, (b) snorvormige distorsie . . . . 14

2.12 Voorbeeld camera kalibratie, (a) met distortie, (b) zonder distortie . . . . . . . . . . 16

2.13 Kalman filter tijdens occlusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.14 Algemeen werking PID-controller . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.15 Weergave van verschillende nodes en topics van een voorbeeld . . . . . . . . . . . 21

2.16 Landingspatroon van Venugopalan et al. (2012) . . . . . . . . . . . . . . . . . . . . 21

2.17 3D weergave van landingsplatform van Cocchioni et al. (2014) . . . . . . . . . . . . 22

2.18 Landingspatroon van Cocchioni et al. (2014) . . . . . . . . . . . . . . . . . . . . . 23

2.19 (a) Verbruik tov gewicht, (b) vliegtijd tov gewicht van 4 Ipower mt1806 motoren bij

gebruik van 3 cel LiPo batterij . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1 Marker langs onderen belicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Diffracttie effect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3 Marker langs opzij belicht en afgedekt door glas of plastic . . . . . . . . . . . . . . 28

xi

LIJST VAN FIGUREN xii

3.4 Marker langs opzij belicht, belichting is gelegen onder marker . . . . . . . . . . . . 28

3.5 Geplotte resultaten uit Tabel A.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.6 Horizontale positie error GPS-systemen . . . . . . . . . . . . . . . . . . . . . . . . 31

3.7 Extrapolatie van data uit Tabel A.1 verder uitplotten . . . . . . . . . . . . . . . . . . 32

3.8 Marker met zijde 0.24 m experimenteel testen . . . . . . . . . . . . . . . . . . . . . 33

3.9 Concept voor landingsplatform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.10 Uitwerking concept landingsplatform . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1 Behuizing Raspberry Pi (a) en camera (b) . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 Resultaat behuizing Raspberry Pi (a) en camera (b) . . . . . . . . . . . . . . . . . . 36

4.3 Concept behuizing Raspberry Pi en camera . . . . . . . . . . . . . . . . . . . . . . 37

5.1 Raspberry pi (a), mapping gpio-pinnen (b) . . . . . . . . . . . . . . . . . . . . . . . 39

5.2 Pixhawk flight controller bovenaanzicht (a), achteraanzicht (b) . . . . . . . . . . . . 40

5.3 Verbinding componenten drone . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.1 Weergave verschillende onderdelen . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.2 ROS-framework van deze thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.3 Flowchart while-lus kalmanfilter node . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.4 Flowchart while-lus pidcontrol node . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.5 Flowchart werking dronecontrol node met functiebenaming . . . . . . . . . . . . . . 52

7.1 Flowchart while-lus kalmanfilter node . . . . . . . . . . . . . . . . . . . . . . . . . 55

Lijst van tabellen

1 Results performance ROS-framework . . . . . . . . . . . . . . . . . . . . . . . . . vii

2.1 Infrarood spectrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Overzicht verschillende embedded processing platformen . . . . . . . . . . . . . . 24

7.1 Resultaten performantie ROS-framework . . . . . . . . . . . . . . . . . . . . . . . 54

7.2 Resultaten Verloop snelheid bij verandering van positie camera tov marker . . . . . . 55

A.1 Resultaten analyse grote van marker tov detectie hoogte . . . . . . . . . . . . . . . 65

xiii

Lijst van symbolen

c Optisch centrum

f Brandpuntafstand

k Radiale distortie coefficient

n Breedte marker [bits]

p Tangentiele distortie coefficient

q Pixelcoordinaten

r Afstand van optisch centrum tot pixel

rGPS Raduis nauwkeurigheid GPS

s Schaalfactor

xcorrected X pixelcoordinaten zonder distortie

ycorrected Y pixelcoordinaten zonder distortie

D Rotatie invariante Hammingafstand

H Hammingafstandfunctie

Hd Minimale detectiehoogte bij worst case

M Camera matrix

P Rotatiefunctie

Q Wereldcoordinaten

R Rotatie matrix

S Eigen Hammingafstand

T Translatie matrix

α Kijkhoek camera

τ Minimale Hammingafstand

τ0 Initiele minimale Hammingafstand

τ Minimale waarde van τ

D ArUco woordenboek

Ψ Aantal iteraties

xiv

Lijst van afkortingen

AVA Applications of Artificial Vision

CSI Camera Serial Interface

EAVISE Embedded Artificially intelligent VISion Engineering

FIR Far Infrared

GPIO General Purpose Input/Output

IR Infrared

LED Light Emitting Diode

LWIR Long Wanelength Infrared

MAVLink Micro Air Vehicle Communication Protocol

MWIR Mid Wavelength Infrared

NIR Near Infrared

ROS Robot Operating System

SAIL Stanford Artificial Intelligence Laboratory

SWIR Short Wavelength Infrared

UAV Unmanned Aerial Vehicles

xv

Hoofdstuk 1

Situering en Doelstellingen

In dit hoofdstuk wordt eerst de situering van drones in Vlaanderen, in Europa en in de wereld be-

sproken, gevolgd door de bespreking van bestaande toepassingen. Nadien wordt de positie van

deze thesis in de gegeven toepassingen beschreven. Ten slotte zullen de verschillende doelstellin-

gen van deze thesis besproken worden.

1.1 Situering

Drones of UAV’s (Unmanned Aerial Vehicles) komen steeds meer voor in de media, echter worden

deze meestal bekeken als speeltjes van hobbyisten of als een manier om vijanden zonder emoties

met een druk op de knop uit te schakelen. UAV’s hebben echter het potentieel om op commercieel

vlak verschillende industrieen van entertainment tot landbouw en van koeriersdienst tot het helpen

bij humanitaire rampen hard te wijzigen.

Het algemeen meest bekende gebruik van UAV’s in commerciele doeleinden is het inzetten van

drones bij de levering van pakketten om zo de leveringstijd te versnellen. De grootste spelers die

hieromtrent onderzoek aan het verichten zijn, zijn Amazon, DHL en UPS. Minder gekend is het

gebruik van drones in de landbouw. Hierbij kunnen drones via image processing bijvoorbeeld het

aantal ontkiemde planten tellen en zo automatisch analyseren of het veld rendabel is. Bij huma-

nitaire rampen, zoals in Haıti (2010), kunnen drones ook instaan voor de levering van medische

hulpmiddelen in gebieden die niet bereikbaar zijn.

In Vlaanderen is de Vlaamse Milieumaatschappij gestart met het gebruik van drones om bij over-

stromingen de overstromingsgevoelige gebieden exacter in kaart te brengen. Maar ook bij energie-

leverancier Eneco worden drones ingezet om via thermische camera’s zonnepanelen te controleren

om snel defecte pannelen op te sporen.

Bij vele van deze toepassingen is de volledig autonome werking van de UAV een belangrijk aspect.

Dit houdt het opstijgen, het vliegen en het landen op de juiste plaats zonder tussenkomst van de

mens in. Dit laatste zal verder besproken worden in deze thesis.

1

HOOFDSTUK 1. SITUERING EN DOELSTELLINGEN 2

1.2 Doelstellingen

Het onderwerp van deze thesis is:

Detectie van landingsplatformen voor drones.

Hierbij zal de drone het landingsplatform, dat bestaat uit een aruco marker, via real time image

processing moeten kunnen detecteren en er zich volledig zelfstandig boven positioneren om na-

dien de autonome landing in te zetten. Omdat bij de verschillende toepassingen niet steeds een

computer aanwezig is die de drone kan aansturen en de lichtcondities niet altijd ideaal zullen zijn,

zal het volledige proces onboard op de drone moeten werken en zal er een techniek bedacht moe-

ten worden zodat het proces in alle lichtcondities werkt. Tevens moet er voor een vlotte werking

50 keer per seconde data naar de drone gestuurd worden zodat deze zich nauwkeurige genoeg

kan herpositioneren. Voor het embedded processing platform en de camera moet er een behuizing

ontwikkeld worden zodat dit onder de drone bevestigd kan worden.

De onderzoeksvraag die we hieruit kunnen halen en trachten te beantwoorden is:

”Wat is een geschikt algoritme om landingsplatformen te detecteren en drones autonoom te laten

landen in alle lichtcondities?”

Deze onderzoeksvraag kunnen we opdelen in meerdere deelvragen, namelijk:

• ”Hoe kan het landingsplatform gedetecteerd worden?”

• ”Welk embedded processing platform is krachtig genoeg om het real time image processing

algoritme uit te voeren?”

• ”Op welke manier kan het embedded processing platform de motoren aansturen?”

• ”Hoe kunnen we ervoor zorgen dat het landingspatroon detectie ook werkt wanneer het

donker is?”

In Figuur 1.1 wordt een ruwe weergave geschetst wat de grote blokken van deze thesis zijn.

Figuur 1.1: Onderdelen thesis

Deze thesis werd in opdracht van EAVISE (Embedded Artificially intelligent VISion Engineering),

een onderzoeksgroep op Campus De Nayer in Sint-Katelijne-Waver, uitgevoerd. Deze onderzoeks-

HOOFDSTUK 1. SITUERING EN DOELSTELLINGEN 3

groep is gefocust op het toepassen van state-of-the-art computer visie technieken op industriele

problemen.

Hoofdstuk 2

Literatuurstudie

In dit hoofdstuk worden verschillende bestaande technieken toegelicht die zullen helpen om de

doelstellingen, zie hoofdstuk 1, te behalen. Eerst wordt er in 2.1 kort besproken welke bewegingen

drones kunnen maken met bijhorende benaming. Gevolgd door een beschrijving van wat ArUco

markers zijn, hoe deze gevormd worden en hoe ze gedetecteerd worden in 2.2. Omdat de motors

van de drone vanaf het embedded processing platform aangestuurd moeten kunnen worden, wordt

in 2.3 besproken hoe dit gebeurt en via welk protocol. De manier die het mogelijk maakt om het

landingsplatform in het donker te detecteren wordt beschreven in 2.4, met in 2.5 een toelichting hoe

de camera die gebruikt wordt, gekalibreerd wordt. In 2.6 wordt er een extra probleem toegelicht

en hoe dit opgelost kan worden via een bestaande techniek. In 2.7 wordt het gebruik van pid-

controllers binnen deze thesis uitgelegd. Waarna er in 2.8 het ROS-framework uitgelegd dat ervoor

zorgt dat de verschillende onderdelen van het algoritme met elkaar kunnen communiceren. Tot slot

zal een onderzoek naar een geschikt embedded processing platform in 2.10 weergegeven worden.

2.1 Beweging Drones

In deze sectie worden de verschillende bewegingen die een drone kan maken uitgelegd, met bijho-

rende benaming. In deze thesis wordt er gebruik gemaakt van drones die bestaan uit vier of meer

motoren waarvan de propellers horizontaal liggen.

Een drone kan op vier verschillende manier bewegen, namelijk yaw, pitch, roll en uplift en downlift.

Deze worden weergegeven in Figuur 2.1. Yaw is de beweging van de drone rond de z-as, zijn

eigen middelpunt. Pitch is de beweging rond de y-as en zorgt ervoor dat de drone naar voor en

achteren beweegt. Roll is de beweging rond de x-as en zorgt ervoor dat de drone naar rechts en

links beweegd. Uplift en downlift is het stijgen en dalen van de drone.

4

HOOFDSTUK 2. LITERATUURSTUDIE 5

Figuur 2.1: Verschillende bewegingen van drones

2.2 ArUco

Zoals in sectie 1.2, besproken bestaat het landingspatroon uit een ArUco marker. Een ArUco

marker is een vierkante binaire afbeelding met een zwarte rand rond waarbij de binnenste binaire

matrix de identifier (id) van de marker is. In Figuur 2.2 zijn twee markers als voorbeeld gegeven.

Deze hebben respectievelijk id 1 en 73. Markers zijn voorgedefinieerd en worden opgeslagen in

een woordenboek. Het genereren van een marker woordenboek wordt besproken in subsectie

2.2.1. Bij de detectie van de ArUco marker kan de volledige positie van de marker op het beeld

bepaald worden net zoals de afstand van de marker tot de camera. Tevens kan de rotatie rond

de x- en y-as ook bepaald worden. De detectie van ArUco markers wordt verder besproken in

subsectie 2.2.2.

Figuur 2.2: ArUco markers met id (a) 1 en (b) 73

2.2.1 ArUco woordenboek generatie

De creatie van een ArUco woordenboek (D) bestaat uit een eindige iteratie van een algoritme.

Iedere iteratie bestaat uit drie delen, respectievelijk het zoeken van een nieuwe marker, controleren


of de marker aan de vereisten voldoet en het toevoegen van de marker aan D.

Het zoeken van een nieuwe marker verloopt volgens een stochastisch proces waarbij markers die

een groot aantal bit transacties hebben, een grotere kans hebben om geselecteerd te worden.

Het groot aantal bit transacties zorgt ervoor dat de waarschijnlijkheid dat markers verward worden

met omgevingsobjecten, geminimaliseerd wordt. Bijvoorbeeld indien een marker enkel uit eenen

(volledig wit) of nullen (volledig zwart) bestaat, kan deze zeer gemakkelijk verward worden met

witte of zwarte objecten.

Hierna wordt er gecontrolleerd of deze marker aan de eisen voldoet. Dit houdt in dat de afstand

tussen de nieuwe marker en alle markers in D groter is dan de minimale waarde τ. Voor deze

afstand worden de markers gezien als een binaire rij, zodat de Hammingafstand bepaald kan

worden. De Hammingafstand geeft het aantal bits die verschillen weer. Bv 1001 en 0011 hebben

een Hammingafstand van 2 want bit 0 en 2 verschillen. Dit geeft volgende formule voor de rotatie

invariante Hammingafstand

D(mi,m j) = mink∈{0,1,2,3}{H(mi,Pk(m j))} (2.1)

Waarbij de functie H de som is van de Hammingafstanden tussen de nieuwe marker en de markers

in D volgens alle rotaties waarbij de functie P deze rotaties weergeeft (kx90◦).Echter moet er ook rekening gehouden worden dat de afstand tussen de nieuwe marker en zijn

eigen rotaties groter is dan τ. De eigen afstand kan weergegeven worden als

S(mi) = mink∈{0,1,2,3}{H(mi,Pk(mi))} (2.2)

De nieuwe marker wordt enkel toegevoegd aan D als D(mi,m j) en S(mi) groter zijn dan τ. Na een

reeks van Ψ iteraties waarbij er geen nieuwe geschikte marker gevonden is, wordt de waarde van

τ met een verlaagd.

De initiele waarde van τ (τ0) blijkt uit een studie van Garrido-Jurado et al. (2016) algemeen bepaald

te worden met

τ0 = 2b4C

3c (2.3)

Waarbij C bepaald wordt met

C = 2bn2

4c (2.4)

Hierin is n de breedte van de marker in bits.

2.2.2 ArUco marker detectie

Het belangrijkste aspect van ArUco markers in deze thesis is de marker detectie. Deze detectie

bestaat uit verschillende stappen die aan de hand van Figuur 2.3 besproken worden.


Figuur 2.3: Weergave stappen ArUco marker detectie

2.2.2.1 Segmentatie beeld

Als eerste stap wordt er via adaptive thresholding de meest opvallende contouren uit de afbeelding

gefilterd. Hierbij wordt er gewerkt met het grijswaarde beeld van het oorspronkelijke beeld. Dit

wordt weergegeven in Figuur 2.3 b. Adaptive thresholding wordt gebruikt bij afbeeldingen die ver-

schillende lichtcondities hebben en in tegenstelling tot global thresholding (een threshold waarde)

heeft adaptive thresholding per deel van de afbeelding een verschillende threshold waarde. Een

voorbeeld van het verschil tussen global en adaptive thresholding wordt weergegeven in Figuur

2.4.


Figuur 2.4: Weergave verschil global en adaptive thresholding

2.2.2.2 Extractie contouren en filteren

Via het algoritme van Suzuki et al. (1985) wordt uit de afbeelding met de gefilterde contouren een

set van echte contouren gevormd (Figuur 2.3 c). Een groot deel van deze set is echter irrelevant

en wordt via het algoritme van Douglas and Peucker (1973) gefilterd. Men weet dat ArUco markers

omrand zijn door een zwarte rand. Hierdoor kan men besluiten dat de contour rechthoekig moet

zijn. Contouren die niet bestaan uit een veelhoek (polygoon) en vier knooppunten (vertexen) van

twee rechte lijnen, worden door het algortme van Douglas-Peucker uit de set gefilterd (Figuur 2.3

d).

2.2.2.3 Extractie marker code

In deze stap worden alle contouren die nog in de set van relevante contouren zitten, bekeken.

Hierbij wordt eerst de perspectieve projectie via homografie verwijderd (Figuur 2.3 e), waarna via

Otsu thresholding een binaire afbeelding gevormd wordt. Volgens de Otsu’s methode wordt er au-

tomatisch een threshold waarde gevonden voor in dit geval de betreffende contour. Deze methode

werkt enkel nauwkeurig op afbeeldingen waarbij het histogram bestaat uit twee pieken.

Hierna wordt de binaire afbeelding opgedeeld in een rechthoekig grid, waarbij elke waarde van het

grid bepaald wordt door het aantal eenen en nullen in dat gebied op de binaire afbeelding (Figuur

2.3 f).

2.2.2.4 Identificatie marker

Vanaf men het grid van de contour heeft, kan men beginnen met de identificatie van de marker.

Een eerste stap hierin is het bekijken van de buitenste rand van het grid. Omdat de marker omrand

wordt door een zwarte rand, moet de buitenste rand van het grid enkel nullen bevatten. Indien

dit niet zo is, kunnen deze contouren al genegeerd worden. Als we kijken naar Figuur 2.3 f zien

we geen eenen in de buitenste rand, waardoor we verder kunnen gaan met de identificatie. In de

volgende stappen worden de verschillende rotaties van het gebied binnen de contour vergeleken


met deze in het marker woordenboek D.

Indien geen match gevonden wordt, gaat men de Hammingafstand tussen het gebied binnen de

contour en de markers in D bepalen zoals in 2.2.1 besproken is. Indien de afstand kleiner is dan

b(τ−1)/2c, waarbij τ de minimale waarde is van τ bij het generen van D, dan concluderen we dat

het gebied binnen de contour en de marker matchen.

Na het detecteren van de marker kan de positie van de marker ten opzichte van de camera bepaald

worden. Hiervoor moet camera omwille van distortie gecalibreerd worden en moet de grootte van

de marker vastgelegd worden.

2.2.3 ArUco marker detectie voorbeeld

In Figuur 2.5 wordt een voorbeeld gegeven van ArUco marker detectie met bijhorende translatie- en

rotatievectoren. Figuur 2.5 a, simuleert een drone die boven de marker zweeft op een hoogte van

1.08 m en afwijking van −0.15 m in y-richting en 0.01 m in x-richting van het optisch centrum. Fi-

guur 2.5 b en c, simuleren een drone die naar voren (b) en rechts (c) beweegt. Bij een voorwaartse

beweging, gaat de drone naar voren hellen. Hierdoor gaat de pitch, besproken in sectie 2.1, van

waarde veranderen. Bij een beweging naar rechts, zal de drone naar rechts hellen, waardoor de

roll gaat wijzigen.

Figuur 2.5: Simulatie van drone (a) zwevend boven marker, (b) bewegend naar voren en (c) bewegend naarrechts


2.3 Pixhawk flightcontroller

PIXHAWK is een autopiloot met een hoge performantie, geschikt voor vliegtuigen,

drones, helikopters, auto’s, boten en andere robotica platformen die kunnen bewegen.

Het is gericht op high-end onderzoek, amateurs en industriele toepassingen.

In deze thesis zal de Pixhawk flightcontroller gebruikt worden om de rotors van de drone aan te

sturen met data die hij ontvangt van het embedded processing platform zoals te zien is op Figuur

1.1.

De communicatie tussen deze twee delen gaat volgens het MAVLink protocol wat uitgelegd is in

subsectie 2.3.1. De integratie van MAVLink in een bruikbaar ROS package wordt verduidelijkt in

subsectie 2.3.2.

2.3.1 MAVLink

Het MAVLink protocol (Micro Air Vehicle Communication Protocol) is een point-to-point netwerking

protocol en wordt gebruikt om UAV’s draadloos aan te sturen. In onze toepassing wordt in plaats

van draadloze communicatie, seriele communicatie tussen de Pixhawk flightcontroller en het on-

board embedded processing platform gebruikt.

Een MAVLink bericht heeft een minimale lengte van 8 bytes en een maximale lengte van 263 bytes

(afhankelijk van de payload) en wordt bytesgewijs over het gebruikte communicatiekanaal verzon-

den. De laatste bytes van het bericht bestaan uit een checksum die gebruikt wordt voor error

correction. Figuur 2.6 geeft een algemeen beeld van hoe MAVLink berichten zijn opgebouwd.

Figuur 2.6: MAVLink protocol pakket

Het STX veld duidt de start van een nieuw bericht aan, gevolgd door het LEN veld die de lengte van

het veld PAYLOAD geeft. Het veld SEQ geeft het sequentie nummer van het bericht weer en wordt

gebruikt om packet loss te detecteren. SYS en COMP geven weer welk systeem en component

het bericht stuurt. MSG geeft het type van het bericht dat verzonden is en definieert de PAYLOAD.

PAYLOAD is de data van het bericht en hangt af van het MSG veld. CKA en CKB bevatten de

checksum.

Wanneer een nieuw bericht ontvangen wordt, wordt er eerst gekeken of de waarde van het LEN veld

overeenkomt met de positie van de checksum. Indien niet, wordt het bericht genegeerd. Hierna

wordt de checksum gecontroleerd. Als deze klopt, wordt het bericht uitgevoerd en afgehandeld.


2.3.2 MAVROS

MAVROS is een ROS (Robot Operating System) package die communicatie mogelijk maakt tussen

een systeem dat een ROS-framework uitvoert (meer uitleg in sectie 2.8) en een autopiloot zoals de

Pixhawk flightcontroller. In dit package is het MAVLink protocol geıntegreerd. Een schematische

voorstelling van integratie wordt weergegeven in Figuur 2.7.

Figuur 2.7: Integratie van MAVLink in MAVROS

2.4 Near Infrared Light

In dit deel wordt besproken wat het near infrared spectrum is (subsectie 2.4.1) en het belang

hiervan in deze thesis (subsectie 2.4.2).

2.4.1 Near IR spectrum

Licht is een elektromagnetische golf. Een elektromagnetische golf is een vorm van energie die

getransporteerd wordt in de vorm van periodische verstoringen van het elektrische en magnetisch

veld. Dit wordt weergegeven in Figuur 2.8. Deze golven worden gekarakteriseerd door een frequen-

tie en golflengte. De verhouding van deze karakteristieken in de vorm van f requentie x gol f lengtegeeft steeds eenzelfde waarde, namelijk de lichtsnelheid (2.99792458 x 108 m/s).

Er bestaan verschillende soorten elektromagnetische golven, afhankelijk van de golflengte of fre-

quentie. Deze verschillende golflengtes wordt het elektomagnetisch spectrum genoemd en wordt

weergegeven in Figuur 2.9. Het belangrijkste gebied voor de mens binnen het spectrum is het

zichtbaar lichtspectrum dat zich tussen een golflengte van 400 en 700 nm bevindt.

In deze thesis is echter het spectrum tussen een golflengte van 700 nm en 1 mm, namelijk het in-

frarood spectrum, ook zeer belangrijk. Dit spectrum bestaat uit vijf verschillende banden en wordt

weergegeven in Tabel 2.1.


Figuur 2.8: Structuur elektromagnetische golf

Figuur 2.9: Elektromagnetisch spectrum

Tabel 2.1 Infrarood spectrum

Naam Golflengte

Near Infrared (NIR) 700 nm - 1.5 µm

Short Wavelength Infrared (SWIR) 1.5 µm - 3 µm

Mid Wavelength Infrared (MWIR) 3 µm - 8 µm

Long Wanelength Infrared (LWIR) 8 µm - 15 µm

Far Infrared (FIR) 15 µm - 1 mm

Deze vijf banden kunnen onderverdeeld worden in twee groepen, namelijk reflected infrared en

thermal infrared. Thermal infrared (MWIR en LWIR) zijn elektromagnetische golven die uitgestuurd

worden door warmtebronnen zoals mensen en dieren. Deze golven zijn zeer belangrijk voor ther-

mische camera’s die de warmte van objecten weergeven. Golven binnen de reflected infrared (NIR

en SWIR) groep zijn de golven die gereflecteerd zijn op objecten, maar niets te maken hebben met

warmte. Deze golven worden ondermeer gebruikt bij nachtvisie.


2.4.2 Belang NIR

Omdat de landingspatroondetectie in alle lichtcondities moet werken, moet er een manier gevon-

den worden om het landingspatroon op te laten lichten. Een eenvoudige oplossing is om dit met

normale verlichting binnen het zichtbaar specturm te doen. Echter gaan we hier opteren om infra-

rood licht uit het NIR spectrum te gebruiken. Dit licht is niet zichtbaar voor de mens, waardoor er

niets onnodig verlicht wordt en zeker niet storend is voor de mens.

Standaard camera’s beschikken over een infrarood filter die ervoor zorgt dat infrarood licht geblok-

keerd wordt. Dit zou anders een blauwe schijn op de foto’s veroorzaaken. Indien we een camera

gebruiken die dat niet heeft, zoals de PI NoIR camera V21 van Raspberry, en het landingspatroon

verlichten met LEDs (Light Emitting Diode) die IR (Infrared) licht uitstralen met een golflengte van

800 a 900 nm, kunnen we het landingspatroon ook in slechte lichtcondities detecteren.

2.5 Camera kalibratie

Zoals besproken in subsectie 2.4.2 maken we gebruik van de pinhole camera PI NoIR van Rasp-

berry. Dit is een camera die 30 beelden per seconde kan trekken met een resolutie van 480p. Een

pinhole camera is een eenvoudige camera met een heel kleine apperture. Echter heeft het pinhole

camera model enkele problemen die opgelost kunnen worden door de camera te kalibreren. De

problemen worden aangekaart in subsectie 2.5.1 en de kalibratie in subsectie 2.5.2.

2.5.1 Problemen pinhole camera model

2.5.1.1 Distortie

Door het pinhole cameramodel treden er twee soorten lens distorties op, namelijk radiale en tan-

gentiele vervorming.

Radiale distortie wordt veroorzaakt door de vorm van de lens en zorgt ervoor dat rechte lijnen in

de werkelijkheid niet recht afgebeeld worden. Dit effect neemt toe naarmate de lijn verder weg ligt

van het optisch middelpunt van de lens. Dit wordt weergegeven in Figuur 2.10 a. Radiale distortie

kan opgedeeld worden in drie categorien.

• Tonvormige distorsie: hoe verder het object van het optische centrum, hoe boller rechte

lijnen van het object worden. (Figuur 2.11 a)

• Kussenvormige distorsie: hoe verder het object van het optische centrum, hoe holler

rechte lijnen van het object worden. (Figuur 2.11 b)

• Snorvormige distorsie: een combinatie van tonvormige en kussenvormige distorsie. (Fi-

guur 2.11 c)

1https://www.raspberrypi.org/products/pi-noir-camera-v2/


Tangentiele distortie (Figuur 2.10 b) wordt veroorzaakt bij het plaatsen van de lens. Hierbij is de

lens niet volledig parallel met het beeldvlak geplaatst. Hierdoor lijken sommige objecten op het

beeld dichter bij de camera dan ze in werkelijkheid zijn.

Figuur 2.10: (a) radiale distortie, (b) tangentiele distortie

Figuur 2.11: (a) tonvormige distortie, (b) kussenvormige distortie, (b) snorvormige distorsie

2.5.1.2 Wereldcoordinaten

Een tweede probleem is het bepalen van welke wereldcoordinaten overeenkomen met welke pixels.

Hiervoor zijn de extrinsieke en intrinsieke parameters nodig. Deze worden bepaald tijdens de

kalibratie van de camera, wat besproken wordt in subsectie 2.5.2.


2.5.2 Kalibratie

De extrinsieke en intrinsieke parameters worden, zoals eerder besproken, bepaald via kalibratie

van de camera. Hierbij wordt er gebruik gemaakt van een gekende structuur die veel identificeer-

bare punten bevat. Door deze structuur vanuit verschillende hoeken te bekijken, is het mogelijk

om de relatieve positie ten opzichte van de camera en extrinsieke en intrinsieke parameters van de

camera te bepalen. De meest gebruikte structuur is een dambordpatroon met afwisselend witte en

zwarte vierkanten.

Bij de kalibratie zal een eerste stap zijn om de relatie tussen de 3D wereldcoordinaten en de 2D

cameracoordinaten via een matrix weer te geven. Dit wordt gedaan via formules waarin q de

pixelcoordinaten, s de schaalfactor (deze wordt meestal weggelaten) en Q de wereldcoordinaten

zijn.

q = sV Q (2.5)

Q = [X Y Z 1]T (2.6)

q = [x y 1]T (2.7)

Factor V uit formule 2.5 bestaat uit twee delen, de fysieke transformatie en de projectie. De fysieke

transformatie is een combinatie van de rotatie matrix R en de translatie matrix T .

V = [R t] (2.8)

De projectie wordt gezien als de camera matrix M die de intrinsieke parameters van de camera

beschrijft en wordt weergegeven in de vorm van

M =

fx 0 cx

0 fy cy

0 0 1

(2.9)

met fx, fy de brandpuntafstanden van de lens en cx,cy het optische centrum.

Na het aanvullen van de verschillende matrices ziet de formule als volgt uit

q =

xy1

= s.

fx 0 cx

0 fy cy

0 0 1

.[r1 r2 r3 t

].

XY01

(2.10)

Echter wordt de distortie niet op deze manier berekend, maar via de manier van Brown (1966).

Hierbij wordt er gebruik gemaakt van volgende formules: voor de radiale distortie


xcorrected = x(1+ k1r2 + k2r4 + k3r6)

ycorrected = y(1+ k1r2 + k2r4 + k3r6) (2.11)

en voor de tangentiele distortie

xcorrected = x+[2p1y+ p2(r2 +2x2)]

ycorrected = y+[p1(r2 +2y2)+2p2x] (2.12)

waarin xcorrected ,ycorrected de pixelcoordinaten zonder distortie zijn, x,y depixel coordinaten met dis-

tortie, kn de nde radiale distortiecoefficient is, pn de nde tangentiele distortiecoefficient is en r de

afstand vanaf het optisch centrum en de pixel.

Een voorbeeld van de kalibratie van een camera wordt weergegeven in Figuur 2.12. Figuur 2.12 a

geeft het ongekalibreerde beeld weer en Figuur 2.12 b het gekalibreerde beeld zonder distortie.

Figuur 2.12: Voorbeeld camera kalibratie, (a) met distortie, (b) zonder distortie

2.6 Tracker

Volgens het ontwerp moet er 50 keer per seconde data naar de drone gestuurd worden om hem

te herpositioneren, zodat hij zich ten alle tijden boven het landingspatroon bevindt. Echter kan de

camera, zoals in sectie 2.5 besproken, maar maximaal 30 beelden per seconden behalen die gea-

nalyseerd kunnen worden en zodus kan er maar 30 keer per seconde data naar de drone gestuurd

worden. Dit kan opgelost worden door gebruik te maken van een tracker die het landingspatroon

gaat tracken. Dit houdt in dat de positie van het landingspatroon tussen twee beelden geschat

gaat worden aan de hand van de positie van het landingspatroon in vorige beelden en de relatieve

snelheid van het landingspatroon ten opzichte van de camera die berekend is uit vorige beelden.

Dit kan bereikt worden met een Kalman filter. In subsectie 2.6.1 wordt de werking en een algemeen

voorbeeld van de Kalmen filter gegeven.


2.6.1 Kalman Filter

De Kalman filter bestaat al meer dan 50 jaar en is genoemd naar Rudolf E. Kalman. Deze filter is

bruikbaar op verschillende vlakken. Het meest bekende gebruik hiervan is de Apollo missie, die

Neil Armstrong in 1969 op de maan zette. Hierbij werd de Kalman filter gebruikt in de navigatie

computer. Hedendaags wordt deze filter in alle GPS systemen en smartphones gebruikt. De

Kalman filter wordt algemeen gebruikt om ruis in data te elimineren en de toestand van een systeem

te schatten, ookal is het exacte systeem onbekend. In het geval van deze thesis is het hoofddoel

van de Kalman filter om de positie van de ArUco marker te schatten tussen twee beelden van de

camera. Hierbij wordt de tijd tussen twee beelden gezien alsof er een obstakel voor de marker

staat. De Kalman filter levert nog een extra voordeel op. Namelijk indien de ArUco marker detectie

op een beeld, zoals besproken in subsectie 2.2.2, faalt, gaat de filter ervoor zorgen dat er toch een

marker is die gebruikt kan worden om te analyseren en de drone bij te sturen.

2.6.1.1 Werking

De werking van de Kalman filter voor tracking bestaat uit drie stappen:

1. Initialisatie (t = 0): de initiele toestand van het systeem op tijdstip 0 wordt bepaald door het

object dat getrackt wordt te detecteren.

2. Voorspellen (t > 0): afhankelijk van de toestand van het systeem tijdens vorige tijdstippen

kan de nieuwe toestand van het systeem geschat worden.

3. Correctie (t > 0): na het voorspellen wordt er op ieder tijdstip ook de toestand van het

systeem gemeten. Omdat op zowel de geschatte en gemeten toestand ruis zit, wordt de

schatting en meting gecombineerd tot de actuele toestand.

Gedurende het tracken van het object wordt stap 2 en 3 steeds herhaald. Indien er een obstakel

voor staat, zal er enkel gewerkt worden met de geschatte toestand van het systeem. In het geval

van deze thesis zou dat tussen twee beelden zijn.

2.6.1.2 Toepassing

In Figuur 2.13 is een voorbeeld gegeven van de tracking van een bal die gedurende een bepaalde

tijd achter een obstakel beweegt. De rode lijn geeft de geschatte positie weer van de bal. Tijdens de

occlusie kunnen er geen metingen plaatsvinden, waardoor er enkel gewerkt wordt met de geschatte

positie. Hierdoor zal er veel ruis aanwezig zijn, zoals te zien op de figuur.


Figuur 2.13: Kalman filter tijdens occlusie

2.7 PID-controller

In deze sectie wordt de werking van PID-controllers en het gebruik hiervan binnen deze thesis

uitgelegd.

2.7.1 Werking

PID-controllers staat voor Proportional Integral Derivative controllers. Deze controller werkt via een

feedbackmechanisme en wordt niet alleen gebruikt in industriele toepassingen, maar ook in alle-

daagse voorwerpen en toepassingen zoals cruise control en gps. Via het feedbackmechanisme

gaat de controller constant een errorwaarde e(t) berekenen. Deze error is het verschil tussen de

gevraagde r(t) en gemeten waarde y(t), waarop een correctie wordt aangebracht volgens pro-

portional, integral en derivative termen. De output van controller is de som van de output van de

verschillende termen. Deze wordt weergegeven in volgende functie.

u(t) = Kpe(t)+Ki

∫ t

0e(t

′)dt

′+Kd

de(t)dt

(2.13)

Hierin zijn Kp, Ki en Kd coefficienten die via tuning gekozen moeten worden. De algemene werking

met de verschillende onderdelen wordt weergegeven in Figuur 2.14.


Figuur 2.14: Algemeen werking PID-controller

2.7.2 Binnen deze thesis

In deze thesis worden vier PID-controllers gebruikt om de snelheid in x,y,z en yaw richtingen te be-

palen. De drone moet deze snelheden vliegen om zijn doel, de marker, te bereiken. Echter wordt

bij de input van de controllers geen snelheden gebruikt, maar wel afstanden en een hoek, namelijk

de afstanden van de marker tot de camera en de hoek (yaw) van de marker tov de camera. Hier-

omtrent wordt de output van de controllers geschaald, zodat deze een goede grote orde hebben die

kunnen dienen als snelheden. In deze thesis is voor de x-,y- en z-snelheden de gevraagde waarde

r(t), 0 in alle richten, en de gemeten waarden y(t) de afstanden van de marker tot de camera.

Voor de yaw snelheden wordt er naar 180◦ gestreven. Hierbij is de bovenkant van de marker ook

de bovenkant van het beeld. De error voor de yaw snelheden is dus het verschil tussen de actuele

yaw en 180◦.

Drones worden in de buitenwereld gebruikt. Er moet dus rekening gehouden worden met wind-

snelheden. Indien de wind sterk is, is het mogelijk dat de drone hierdoor gedwarsboomd wordt

en mogelijk niet op zijn bestemming geraakt. Dit wordt veroorzaakt omdat de windsnelheid ten

opzichte van de gewenste snelheid van de drone te groot is, waardoor de drone niet verder zal

kunnen vliegen. Dit probleem kan opgelost worden wanneer we voor een controller zouden kiezen

waarbij de snelheid niet enkel bepaald wordt door de error, maar ook door de totale som van de

errors. Hierdoor gaat de snelheid toenemen wanneer de error niet kleiner wordt, bijvoorbeeld dmv

van hevige wind, waardoor de drone zijn doel wel zal kunnen bereiken. Dit is de reden waarvoor er

gekozen zal worden voor PID-controllers.

2.8 Robot Operating System

ROS (Robot Operation System) is een veel gebruikt framework in robotica. De algemene filoso-

fie hierachter is het maken van software of functionaliteiten die gemakkelijk overgenomen kunnen

worden voor andere robots, waarbij maar weinig aanpassingen moeten gebeuren. ROS is oor-

spronkelijk ontwikkeld in 2007 door het Stanford Artificial Intelligence Laboratory (SAIL).

Het ROS framework bestaat uit verschillende componenten, die in de volgende onderdelen bespro-

ken worden.


2.8.1 Nodes

Het ROS-framework bestaat uit verschillende nodes, waarbij nodes processen zijn die berekenin-

gen uitvoeren en elk een eigen functionaliteit hebben. Dit zijn bijvoorbeeld camera, ArUco-marker

detectie en motor besturing die elk een eigen proces hebben. Hierdoor wordt het groter geheel

opgedeeld in kleinere delen die zelfstandig werken. Het voordeel hiervan is dat niet iedereen die

meewerkt aan het ROS-framework kennis moet hebben van elke node. Verschillende nodes com-

municeren met elkaar via het TCP/IP netwerk, waardoor het mogelijk is dat deze op verschillende

processing platformen kunnen werken. Bijvoorbeeld de cameranode en motorbesturingsnode kun-

nen onboard werken en ArUco-marker detectie offboard op een krachtiger processing platform.

Nodes worden geschreven in c++ of python.

2.8.2 Topics en messages

Indien nodes met elkaar willen communiceren, moet er eerst een topic gevormd worden. Verschil-

lende nodes kunnen naar eenzelfde topic luisteren of er iets naar toe sturen. Dit gebeurt door

het publishen en subscriben op het topic. Echter kan het onderwerp van een topic niet veranderd

worden. De cameranode kan bijvoorbeeld geen beelden versturen op het topic dat gebruikt wordt

door de ArUco-marker detectie node om data door te sturen naar de motorbesturingsnode.

Aan elke topic is een functie gebonden die opgeroepen wordt indien er via het topic data ontvan-

gen wordt. De node die iets op het topic verstuurt gaat niet wachten tot de functie die opgeroepen

wordt door de ontvangende node afgehandeld is. Met andere woorden, de nodes kunnen parallel

werken.

Een message is de data die over een topic gestuurd wordt en heeft een vast type afhankelijk van

het topic. Het type van de message kan een standaard ROS message type zijn of kan een zelf

gedefinieerd type zijn.

2.8.3 Services

Wanneer we van bepaalde nodes een bepaald antwoord willen krijgen, kunnen we gebruik maken

van services. Indien we een service aanspreken, zullen de nodes die de service aanbieden een

antwoord sturen. Hierbij wordt in tegenstelling tot een topic wel gewacht tot het antwoord ontvangen

is. Services worden meestal gebruikt om snel met elkaar te communiceren.

2.8.4 Voorbeeld

Een voorbeeld van een ROS-framework wordt weergegeven in Figuur 2.15. Dit is een eenvoudig

framework waarbij de node, capture node, een node is die foto’s gaat trekken en deze als message

gaat publishen op het topic camera image. De node, livestream node, gaat op zijn beurt subscriben

op het topic camera image en de messages met de foto’s ontvangen. Steeds als er een message

ontvangen is, zal er automatisch een functie opgeroepen worden die de foto zal weergeven.


Figuur 2.15: Weergave van verschillende nodes en topics van een voorbeeld

2.9 Onderzoek landingsplatformen

In het volgende deel worden een aantal onderzoeken over landingsplatformen, die reeds uitge-

voerd zijn, beschreven. In veel bestaande commerciele toepassingen waarbij drones autonoom

landen, wordt er geen gebruik gemaakt van landingspatronen maar van GPS (Global Positioning

System). Echter is de nauwkeurigheid die met GPS behaalt wordt vergeleken met het gebruik van

landingspatronen zeer slecht.

Een eerste onderzoek, dat kort weergegeven wordt, is dat van Venugopalan et al. (2012) waarbij

de bedoeling ondermeer was om een drone autonoom te laten landen op een kayak in het water.

Hierbij wordt er een landingspatroon gebruikt dat bestaat uit twee rechthoeken, een grote rode en

een kleine centraal gelegen groene, zoals te zien is op Figuur 2.16. Deze kleuren werden ge-

kozen omdat deze gemakkelijk te onderscheiden zijn van de blauwige kleur van water. De grote

rechthoek is zichtbaar van op grote hoogtes en gaat de drone op de grote hoogtes helpen met her-

positioneren. De kleine rechthoek wordt gebruikt op lage hoogtes om de drone te herpositioneren,

waarbij de grote rechthoek niet meer zichtbaar is. Via een kleur detectie algoritme wordt het rode

en groene deel als afzonderlijke objecten gedetecteerd. Hierna wordt er gekeken of deze objecten

rechthoeken zijn en of de zwaartepunten van beide objecten in eenzelfde punt vallen. Indien dit

klopt, kan het landingsalgoritme starten.

Figuur 2.16: Landingspatroon van Venugopalan et al. (2012)

Het onderzoek van Bartak et al. (2014) heeft als doel het vinden van een eenvoudig landingspa-

troon dat gemakkelijk en betrouwbaar geıdentificeerd kan worden. Hierin worden verschillende

landingspatronen en manieren om deze te detecteren onderzocht. De onderzochte landingsplat-

ronen zijn respectievelijk een heliport, omgekeerde T, twee rechthoeken van dezelfde kleur maar

verschillende grootte en twee cirkels met verschillende kleur en eenzelfde grootte. Hierop zijn tem-

plate matching, feature detection en matching en blob detection uitgetest. Als conclusie werd er

gekozen om een patroon te gebruiken met twee cirkels die een verschillende kleur en eenzelfde


grootte hebben. Via blob detection en een combinatie van erosion en dilation kan het landingspa-

troon eenvoudig gedetecteerd worden.

Een laatste onderzoek dat bekeken wordt, is dat van Cocchioni et al. (2014) waarbij er niet enkel

onderzocht werd naar een manier om autonoom te vliegen, maar ook naar een manier om de

drone zelfstandig zijn accu te laten opladen. Dit aspect zou de volledige autonome werking van

drones bij bijvoorbeeld het autonome toezicht van een groot gebied, verbeteren. Hierbij zal de

juiste positie van de drone een zeer belangrijk onderdeel zijn, zodat de accu van de drone kan

opgeladen worden. In het onderzoek werd er een 3D landingsplatform ontwikkeld dat bestaat uit

vier omgekeerde holle kegels. De drone, die een speciaal gevormde landingsgestel heeft, landt

op het platform en via de zwaartekracht glijdt de drone met zijn landingsgestel tot de onderkant

van de kegels. Hierdoor is de maximale fout zeer klein. Figuur 2.17 geeft een weergave van dit

landingsplatform.

Figuur 2.17: 3D weergave van landingsplatform van Cocchioni et al. (2014)

Het landingsplatform moet uiteraard ook autonoom gedetecteerd kunnen worden. Dit gaat doordat

twee cirkels en twee driehoeken aanwezig zijn, zoals weergegeven in Figuur 2.18. De grote cirkel

zorgt ervoor dat de drone op grote hoogte zich kan herpositioneren en de grote driehoek zorgt

ervoor dat de drone in de juiste richting gedraaid is. De kleine cirkel en driehoek hebben dezelfde

functie, maar worden gebruikt bij lage hoogte. De manier waarop de drone gedraaid is, is in dit

onderzoek zeer belangrijk aangezien de juiste oplaadpunten met het juiste landingsgestel contact

moet hebben om correct op te laden.


Figuur 2.18: Landingspatroon van Cocchioni et al. (2014)

2.10 Embedded processing platform

Om de volledig autonome werking van de drone te verwezelijken, moet er gezocht worden naar

een geschikt embedded processing platform. Hierbij moet er zeker rekening gehouden worden

met verschillende aspecten, namelijk het gewicht, het verbruik en moet er nagegaan worden of

het krachtig genoeg is om het algoritme met gevraagde performatie uit te voeren. In deze sectie

wordt eerst het verband tussen gewicht en verbruik besproken, gevolgd door een overzicht van

verschillende platformen, waarna een geschikt platform gekozen wordt.

2.10.1 Verband gewicht met verbruik

Een belangrijk verband bij het gebruik van UAV’s is het verband tussen gewicht en verbruik. Naar-

mate het gewicht van de UAV toeneemt, gaat het verbruik ook toenemen, waardoor de opperatio-

nele tijd van de UAV korter wordt. Deze opperationele tijd kunnen we vergroten door een batterij

te selecteren met een grotere capaciteit. Dit gaat echter weer gepaard met een verhoging van het

gewicht. In Figuur 2.19 (a) wordt het verbruik van vier Ipower mt1806 motoren tov het gewicht weer-

gegeven. Uit deze waarden kunnen we de theoretische vliegtijd tov het gewicht bepalen (Figuur

2.19 (b)). Hiervoor wordt er gebruik gemaakt van een lithium-ion-polymeer batterij met 3 cellen

(12.3 V) en een capaciteit van 2200 mAh. We kunnen hieruit concluderen dat een kleine stijging

van gewicht, een grote vermindering van vliegtijd veroorzaakt. We moeten dus bij het kiezen van

een geschikt embedded processing platform opteren naar een keuze die zo min mogelijk weegt,

maar toch een voldoende performantie heeft.


Figuur 2.19: (a) Verbruik tov gewicht, (b) vliegtijd tov gewicht van 4 Ipower mt1806 motoren bij gebruik van3 cel LiPo batterij

2.10.2 Overzicht embedded processing platformen

In onderstaande tabel (Tabel (2.2)) wordt een overzicht gegeven van de onderzochte embedded

processing platformen.

Tabel 2.2 Overzicht verschillende embedded processing platformen

Raspberry pi 3 Asus Tinker board ODROID-XU4 ODROID-C2

CPU Cortex-A53 (1,2 GHz, Quad core) Cortex-A17 (1,8 GHz, Quad core) A15 Quad 2.0GHz/Cortex-A7 Quad 1.4GHz Cortex-A53 1,5 GHz, Quad core)

GPU Videocore IV (400 MHz) Mali-T764 GPU (600MHz) ARM Mali-450

RAM 1 GB 2 GB 2 GB LPDDR3 2 GB DDR3

WiFi Ja Ja Nee Nee

CSI Ja Ja Nee Nee

Verbruik idle 230 - 290 mA (1,15 - 1,45 W) 500 mA (2,5 W) 840 mA (4,2 W) 330 - 350 mA (1,65 - 1,75 W)

Verbruik max 800 mA (4 W) 1000 mA (5 W) 2633 mA (13,2 W) 840 - 880 mA (4,2 W - 4,4 W)

Voeding 5V/2-2,5A 5V/2-2,5A 5V/4A 5V/2A

Gewicht 41.2 g 55 g zonder cooling 38 g, met 60 g zonder cooling 40 g, met 56 g

Gewicht camera 3.4 g 3.4 g 35 g met frame 35 g met frame

OS Raspbian jessie (Linux v4.9) Tinker OS v2.01 (BETA) (Linux v4.4) Ubuntu 16.04 Ubuntu 16.04

Prijs 45 EUR 70 EUR 59 EUR 46 EUR

2.10.3 Selectie embedded processing platform

Zoals besproken in subsectie 2.10.1 is gewicht een zeer belangrijk aspect bij het selecteren van een

geschikt processing platform. Als we kijken in Tabel 2.2 zien we dat de Raspberry pi3 en de Asus

Tinker board de twee zwaarste platformen zijn. Wanneer we echter de camera, die zeer belangrijk

is in deze thesis, in rekening brengen, kunnen we concluderen dat beiden ODROID platformen

de zwaarste zijn. De ODROID platformen beschikken tevens niet over een csi aansluiting en wifi,

waardoor we genoodzaakt zullen zijn om de camera via USB aan te sluiten en een extra wifi dongle


aan te sluiten om voor de veiligheid toch in verbinding te kunnen staan met de UAV. Hierdoor komt

er nog extra gewicht bij.

Wanneer we verder kijken naar de Raspberry Pi en de Asus Tinker Board en deze benchmarken

met behulp van Geekbench2, zien we dat de Asus Tinker board een veel hogere score haalt (3633)2

ten opzichte van de Raspberry pi 3 (2108)3. Voor deze benchmark wordt er vergeleken met een

Mac G5 uit 2003 die 1000 punten haalt. Een score van 2000 geeft weer dat het systeem een

performantie heeft die dubbel zo goed is. Uit deze resultaten kunnen we concluderen dat de Asus

Tinker board de betere optie is op vlak van performantie, maar we toch de Raspberry pi 3 gebruiken

gezien deze op vlak van verbruik beter scoort. Indien er toch een probleem voordoet door een

gebrek aan performantie, kan er steeds overgeschakeld worden naar de Asus Tinker board.

2https://browser.geekbench.com/geekbench2/26314823https://browser.geekbench.com/geekbench2/2633138

Hoofdstuk 3

Landingsplatformen

Omdat het volledige algoritme in alle lichtcondities moet werken, worden er in dit hoofdstuk eerst

verschillende uitgeteste belichtingstechnieken besproken, gevolgd door een onderzoek naar de

ideale marker grootte. Daarna wordt een concept voor een volledig landingsplatform uitgewerkt.

3.1 Analyse belichtingstechnieken

In volgende sectie wordt een analyse beschreven waarbij drie verschillende belichtingstechnieken

van het landingsplatform onderzocht werden. Daarna wordt de beste geselecteerd.

3.1.1 Belichtingstechniek 1

Voor de eerste belichtingstechniek wordt gebruik gemaakt van een marker. Deze ligt op melkglas,

dat als diffuser dient, en langs onderen belicht wordt door een array IR-LED’s. Het resultaat is

weergegeven in Figuur 3.1. Hierop is echter duidelijk het effect ’light bloom’ te zien. Dit effect

wordt veroorzaakt door de diffractie van lichtgolven, waarbij de golf gaat afbuigen langs een on-

doordringbaar obstakel. Dit wordt weergegeven in Figuur 3.2. Door het optreden van dit effect is

deze techniek echter niet geschikt voor het belichten van onze marker.

26

HOOFDSTUK 3. LANDINGSPLATFORMEN 27

Figuur 3.1: Marker langs onderen belicht

Figuur 3.2: Diffracttie effect


Voor een tweede beelichtingstechniek wordt gebruik gemaakt van een marker die lager gelegen

is en langs de zijkant belicht wordt door IR-LED’s. De belichting en marker zijn afgeschermd door

glas of plastic, zodat deze beschermd worden tegen regenval. Het resultaat van deze techniek is

te zien in Figuur 3.3. Op deel (a) van Figuur 3.3 is te zien dat de intensiteit van de belichting niet

overal constant is. Uit testen blijkt dat dit voor de markerdetectie in deze opstelling geen problemen

veroorzaakt. Indien we Figuur 3.3 (b) kijken, zien we dat de afscherming van glas of plastic overdag

reflecties veroorzaakt. Hierdoor zal de markerdetectie falen en zullen we deze belichtingstechniek

niet gebruiken.


Figuur 3.3: Marker langs opzij belicht en afgedekt door glas of plastic


De laatste belichtingstechniek is een combinatie van vorige twee technieken. Hierbij wordt gebruik

gemaakt van een marker op melkglas en wordt deze belicht langs opzij Deze belichting is lager

gelegen. Door deze manier van belichten wordt de marker onrechtstreeks belicht, wat een meer

gelijke belichting creeert en minder ’light bloom’ veroorzaakt, zoals besproken in subsectie 3.1.1.

Het resultaat van deze techniek wordt weergegeven in Figuur 3.4. In Figuur 3.4 (b) is te zien dat

deze techniek van belichten geen last heeft van reflecties.

Omdat deze belichtingstechniek geen last heeft van de knelpunten die vorige twee belichtingstech-

nieken hadden, zal deze manier van belichten verder gebruikt worden in deze thesis.

Figuur 3.4: Marker langs opzij belicht, belichting is gelegen onder marker


3.2 Analyse grote van marker tov detectie hoogte

In volgende sectie wordt een onderzoek beschreven waarin er op zoek gegaan wordt naar de beste

markergrootte. Deze marker moet groot genoeg zijn, zodat deze op grote hoogte detecteerbaar is.

Deze mag ook niet te groot zijn. Een te grote marker komt op een kleine hoogte niet volledig in

beeld en kan dan ook niet meer gedetecteerd worden. In volgende subsecties worden de aanpak

van het onderzoek, de resultaten en een geschikte markergrootte besproken. Daarna wordt de

gekozen marker grootte experimenteel uitgetest.

3.2.1 Aanpak

Er werden van 17 verschillende groottes van markers datasets gecreeerd. Voor deze datasets

werd er steeds op eenzelfde hoogte gestart, waarna de camera langzaam zakte tot op de marker.

Dit dalen werd volledig gefilmd, waarna de video door een algoritme werd gehaald. In dit algoritme

werd er in elke frame gezocht naar een marker. Dit gaf als resultaat de hoogte van de eerste en de

laatste detectie, het aantal frames waarin een marker is gedetecteerd, het totaal aantal frames en

de verhouding van het aantal frames met gedetecteerde marker ten opzichte van het totaal aantal

frames terug. Per grootte van de marker werd dit proces drie keer herhaald, waarna de gemiddelde

resultaten bepaald werden. Dit om afwijkende waarden te minimaliseren. De resultaten van het

algoritme worden weergegeven in Tabel A.1.

3.2.2 Analyse resultaten

Wanneer we de hoogste en laagste detectiehoogte uit Tabel A.1 per grootte van marker gaan

plotten, verkrijgen we de grafiek in Figuur 3.5. Hierin is het oranje gedeelde de hoogtes waarbij

de marker detecteerbaar is en de groene lijn de laagste detectie van alle markers. Omdat de

testopstelling beperkt was tot een hoogte van ongeveer 3.5 m, zien we dat vanaf marker met zijde

0.09 m de maximale detectiehoogte ongeveer gelijk blijft. Via extrapolatie kan de maximale detectie

hoogte van markers met zijde groter dan 0.09 m geschat worden. Dit wordt weergegeven door de

blauwe lijn in Figuur 3.5. Deze lijn wordt weergegeven door de functie

y = 36,638∗ x+0,22198 (3.1)

Zoals besproken in de inleiding van deze sectie, moet er bij de keuze van de grootte van de marker

gekeken worden naar zowel de maximale, als de minimale detectiehoogte. Er zal echter toepas-

singsgericht gekeken moeten worden naar de manier waarop drones werken bij de volledige auto-

nome werking. Er wordt meestal gebruik gemaakt van een GPS, die de drone in de buurt van de

bestemming gaat brengen. Daarna kan er overgeschakeld worden op visie gestuurd landen voor

een grotere nauwkeurigheid. Deze GPS’en hebben echter ook een beperkte nauwkeurigheid die

zeker in rekening gebracht moet worden bij de bepaling van de hoogte waarop een marker gede-

tecteerd moet kunnen worden. Deze nauwkeurigheid wordt verder besproken in subsectie 3.2.2.1,

waarna in subsectie 3.2.2.2 de minimale detectiehoogte bepaald wordt. Uit een combinatie van


de resultaten van dit onderzoek en de minimale detectiehoogte wordt er in 3.2.2.3 de theoretische

grootte van de marker bepaald, waarna deze experimenteel getest wordt.

Figuur 3.5: Geplotte resultaten uit Tabel A.1

3.2.2.1 Nauwkeurigheid GPS

In een onderzoek door Hughes (2017) werd de horizontale positie error van GPS’en bepaald. Hier-

bij werd er op 28 plaatsen in Noord-Amerika gedurende twee maanden de positie bepaald via GPS.

Uit de exact geweten positie en de bepaalde positie via GPS werd de fout van de bepaalde positie

berekend. De resultaten van dit onderzoek worden weergegeven in Figuur 3.6. Hierin wordt een

histogram gegeven van het aantal samples per afwijking. Uit de resultaten blijkt dat 95% van de

samples een afwijking heeft van kleiner dan 1.891 m. Dit wilt zeggen dat we om de hoogte te

bepalen, waarop een marker gedetecteerd moet kunnen worden, rekening moeten houden dat het

gezichtsveld van de camera op deze hoogte een minimale radius heeft van 1.891 m.


Figuur 3.6: Horizontale positie error GPS-systemen

Bij dit onderzoek wordt er gebruik gemaakt van GPS’en van zeer hoge kwaliteit. Voor onze toepas-

singen is deze kwaliteit echter niet haalbaar en gaan we de nauwkeurigheid gebruiken van GPS’en

die meer aanleunen bij de GPS’en die gebruikt worden voor de consumentenklasse. Voor de con-

sumentenklasse valt deze nauwkeurigheid gemiddeld op 4 m. Dit wilt zeggen dat indien de drone

autonoom via GPS naar een geselecteerde locatie vliegt, de marker in een radius van 4 m rond

de drone kan liggen. Deze waarde zal verder meegenomen worden in sectie 3.2.2.2), waarin de

hoogte bepaald wordt waarop een marker gedetecteerd moet kunnen worden.

3.2.2.2 Bepalen detectie hoogte

Zoals besproken in 3.2.2 wordt de minimale detectiehoogte bepaald door de nauwkeurigheid van

GPS’en. Met deze nauwkeurigheid van 4 m en het gezichtsveld van de camera wordt deze detec-

tiehoogte via goniometrie eenvoudig bepaald, wat weergegeven wordt in vergelijking 3.2. Hierin is

rGPS de radius van de nauwkeurigheid, α de kijkhoek van de camera en Hd de minimale detectie-

hoogte.

Hd =rGPS

tan(α

2 )(3.2)

De camera die in deze thesis gebruikt wordt (Raspberry Pi NoIR camera) heeft een kijkhoek van

62.2 x 48.8 graden. Voor het bepalen van de detectiehoogte wordt de kleinste hoek gebruikt


(48.8◦). Ingevuld in vergelijking 3.2 geeft dit 8.818 m, zoals te zien in vergelijking 3.3.

4tan(48.8◦

2 )= 8.818m (3.3)

3.2.2.3 Selectie marker grootte

Indien we de minimale detectiehoogte, gevonden in subsectie 3.2.2.2, gaan vergelijken met de

gevonden resultaten van het onderzoek op Figuur 3.5, zien we dat de geschatte maximale detec-

tiehoogte via extrapolatie voor een marker met zijde 0.20 m beperkt is tot 7.5496 m. Dit is echter

kleiner dan onze berekende minimale detectiehoogte van 8.818 m. Indien we de functie 3.1, die

gevonden is door extrapolatie van de resultaten, verder gaan uitplotten, kunnen we voor grotere

zijdes dan 0.20 m zien wat de theoretische maximale detectiehoogte is. Dit is weergegeven op de

grafiek in Figuur 3.7. Hieruit halen we dat wanneer we een marker van 0.24 m nemen, we theo-

retisch een maximale detectiehoogte van 9.0151 m hebben. Deze is groter dan de 8.818 m die

berekend is, waardoor deze grootte geschikt is voor gebruik.

Figuur 3.7: Extrapolatie van data uit Tabel A.1 verder uitplotten

3.2.2.4 Experimenteel testen

In volgend experiment wordt bepaald of de gekozen marker uit 3.2.2.3 met grootte 0.24 m wel

daadwerkelijk geschikt is om in de praktijk te gebruiken. In dit experiment wordt er eenvoudigweg

met de drone vanop de marker gestart, waarna de drone gaat opstijgen tot een bepaalde hoogte.

Deze vlucht wordt volledig gefilmd met de Raspberry pi en camera die aan boord aanwezig zijn. De

video van de vlucht wordt door hetzelfde algoritme gelopen als de datasets uit sectie 3.2.1. Uit deze

dataset zien we, zoals in Figuur 3.8, dat de maximale detectiehoogte 9.54476 m is. Deze waarde

is groter dan geschatte waarde van 9.0151, wat te verwachten was omdat we gebruik maakten


van extrapolatie om de functie 3.1. Deze waarde is dan ook uiteraard groter dan de minimale

detectiehoogte van 8.818 m, wat weergeeft dat de marker met een zijde van 0.24 m zeker geschikt

is voor gebruik bij praktische toepassingen. De laagste hoogte waarop een marker gedetecteerd

is, is tevens 0.3245 m. Deze waarde is op eenzelfde manier bepaald als beschreven staat in sectie

3.2.1.

Figuur 3.8: Marker met zijde 0.24 m experimenteel testen

3.3 Concept landingsplatform

In deze sectie wordt een concept uitgewerkt voor een volledig landingsplatform, waarbij er gebruik

gemaakt wordt van besluiten die in vorige secties genomen werden.

Het concept wordt weergegeven in de schets op Figuur 3.9. Hierbij ligt de marker, met de grootte

die in 3.2.2.3 geselecteerd is, in het midden op melkglas en wordt belicht volgens de belichtings-

techniek besproken in 3.1.3. Bovenaan op het landingsplatform is een plaats voorzien voor een

lichtintensiteitsmodule. Deze module bestaat uit een lichtweerstand die de lichtintensiteit meet en

via een transistor de stroomtoevoer naar de IR-LEDs kan onderbreken. Dit gaat ervoor zorgen

dat indien het buiten licht genoeg is om de marker zonder extra belichting te detecteren, de LEDs

uitgeschakeld worden. Hierdoor kan er op elektriciteit bespaard worden. Eventueel is het ook mo-

gelijk om onderaan in het landingsplatform een batterij te plaatsen, zodat het landingsplatform ook

gebruikt kan worden wanneer er geen voedingsnet aanwezig is.

Het volledig uitgewerkte concept is te zien op Figuur 3.10. Figuur 3.10 (c) geeft het landingsplat-

form in het donker weer.


Figuur 3.9: Concept voor landingsplatform

Figuur 3.10: Uitwerking concept landingsplatform

Hoofdstuk 4

Behuizing

Een van de doelstelling van deze thesis was het ontwerpen van een behuizing voor het embedded

processing platform en de camera, zodat deze onder de drone bevestigd kan worden. De drone die

gebruikt wordt heeft echter een klein landingsgestel waardoor de drone zeer dicht tegen de grond

ligt. Dit maakt het niet mogelijk om zowel het embedded processing platform, als de camera onder

de drone te bevestigen. De manier waarop het embedded processing platform en de camera op

onze drone bevestigd is, wordt besproken in 4.1. In 4.2 wordt er toch een concept weergegeven

waarbij de beide onderdelen in een behuizing zitten.

4.1 Gebruikte behuizing

Zoals in de inleiding van dit hoofdstuk besproken, is de drone die gebruikt wordt in deze thesis

niet geschikt voor het gebruik van een behuizing voor beide componenten. Daarom is er een idee

uitgewerkt en getest om beide componenten apart op de drone te bevestigen. Hierbij wordt de

camera in een omhulsel gestoken die de camera moet beschermen. Dit omhulsel, weergegeven in

Figuur 4.1 (b), wordt onderaan in het midden van de drone bevestigd. Het embedded processing

platform (Raspberry Pi) wordt gemonteerd op een verbeterde versie van het omhulsel dat reeds op

de drone stond, waarbij er bevestigingspunten voor het embedded processing platform aanwezig

zijn. Dit omhulsel is een redelijk open omhulsel, zodat tijdens het testen alle poorten nog gemak-

kelijk bereikbaar zijn. Dit omhulsel wordt weergegeven in Figuur 4.1 (a). Het resultaat van deze

behuizingen zien we in Figuur 4.2.

35

HOOFDSTUK 4. BEHUIZING 36

Figuur 4.1: Behuizing Raspberry Pi (a) en camera (b)

Figuur 4.2: Resultaat behuizing Raspberry Pi (a) en camera (b)

4.2 Concept behuizing

Er is een concept uitgedacht waarbij het embedded processing platform en de camera in een

behuizing zitten. Hierin zit de camera naar onderen gericht onderaan in de behuizing, waarbij

er een opening is voorzien voor de lens. Het embedded processing platform, in dit geval een

Raspberry Pi, wordt (met voldoende plaats tussen) boven de camera geplaatst. In de bovenkant

van de behuizing is een kleine opening voorzien voor de voeding en datakabels. De volledige

behuizing heeft een afmetingen van 7 cm x 11 cm x 4 cm. Dit concept wordt volledig weergegeven

in de schetsen van Figuur 4.3.

HOOFDSTUK 4. BEHUIZING 37

Figuur 4.3: Concept behuizing Raspberry Pi en camera

Hoofdstuk 5

Communicatie tussen embeddedprocessing platform en Pixhawk flight

controller

In dit hoofdstuk wordt de manier waarop het embedded processing platform, in dit geval een Rasp-

berry Pi, verbonden is met de Pixhawk flight controller behandeld, zodat deze met elkaar kunnen

communiceren. Hiervoor wordt eerst besproken welke poorten beide componenten beschikken,

waarna de verbinding tussen beide wordt weergegeven.

5.1 Poorten Raspberry Pi

Het embedded processing platform, geselecteerd voor deze thesis, is de Raspberry Pi. Het se-

lectieproces, wordt weergegeven in de literaturrstudie in sectie 2.10.3, beschikt over een breed

gamma aan poorten. Voor deze thesis wordt echter enkel gebruik gemaakt van de csi-poort en

enkele gpio-pinnen.

De csi-poort (Camera Serial Interface) wordt gebruikt voor de communicatie met de camera. Deze

poort wordt gekozen in plaats van een USB poort omdat bij gebruik van USB de CPU deze poorten

zal moeten aansturen, in tegenstelling tot de csi-poort die aangestuurd wordt door de GPU. Hier-

door wordt een deel van load op de CPU overgedragen aan de GPU, waardoor de CPU zich meer

kan bezighouden met het algoritme. Deze poort wordt weergegeven op Figuur 5.1 (a) met nummer

1.

Voor de voeding van de Raspberry Pi en de communicatie met de Pixhawk flight controller worden

gpio-pinnen gebruikt (General Purpose Input/Output). Deze worden voorgesteld in Figuur 5.1 (a)

met nummer 2. De mapping van de gpio-pinnen worden weergegeven in Figuur 5.1 (b). Voor de

voeding wordt er gebruik gemaakt van een 5V-pin (pin 2) en een GND-pin (pin 6). Deze zijn recht-

streeks verbonden met de Pixhawk. De seriele verbinding om data naar de Pixhawk te sturen en

data te ontvangen wordt gerealiseerd door de UART TX- en RX-pin (pin 8 en 10).

38

HOOFDSTUK 5. COMMUNICATIE TUSSEN EMBEDDED PROCESSING PLATFORM EN PIXHAWK FLIGHT CONTROLLER 39

Figuur 5.1: Raspberry pi (a), mapping gpio-pinnen (b)

5.2 Poorten Pixhawk flight controller

De Pixhawk flight controller die de motoren van de drone gaat aansturen met data, ontvangen

van de Raspberry Pi, wordt weergegeven in Figuur 5.2. Deze wordt gevoed via de power-poort

(nummer 1 op (a)). Omwille van veiligheidredenen is er een veiligheidsknop aanwezig, wat het

mogelijk maakt om de datatoevoer naar de motoren te onderbreken. Deze knop wordt aangesloten

op de switch-poort (nummer 2 op (a)). De laatste poort in het bovenaanzicht, die gebruikt wordt, is

de TELEM2-poort (Telemetry) (nummer 3 op (a)). Dit is een seriele poort die gebruikt wordt voor

MAVLink communicatie. Via deze poort is de Pixhawk verbonden aan de TX- en RX-pinnen van de

Raspberry Pi. Over dit kanaal wordt de data tussen beiden uitgewisseld.

In Figuur 5.2 (b) wordt het achteraanzicht van de Pixhawk weergegeven. Hier bevinden zich 16

sets pinnen met elk een voeding-, grond- en signaalpin. Van deze 16 sets worden er vier gebruikt

(nummer 1 op (b)) voor de communicatie met de motoren en een voor de voeding van de Raspberry

Pi (nummer 2 op (b)), waarbij wordt enkel de voeding- en grond-pin gebruikt worden en verbonden

zijn met de 5V-pin en de GND-pin van de Raspberry Pi. De Raspberry Pi is echter ook te voeden

met de TELEM2-poort. De maximale stroom die deze poort kan leveren is te klein indien de Pi op

volle capaciteit draait. Een laatste set pinnen worden gebruikt voor RC input (nummer 3 op (b)) en

zijn verbonden met de Futaba R6106HFC ontvanger voor radiogestuurde communicatie.

HOOFDSTUK 5. COMMUNICATIE TUSSEN EMBEDDED PROCESSING PLATFORM EN PIXHAWK FLIGHT CONTROLLER 40

Figuur 5.2: Pixhawk flight controller bovenaanzicht (a), achteraanzicht (b)

5.3 Verbinding Pixhawk en Raspberry Pi

In onderstaande figuur, Figuur 5.3, wordt de gemaakte verbinding weergegeven tussen de Pixhawk

flight controller, Raspberry Pi, motoren en Futaba ontvanger.

Figuur 5.3: Verbinding componenten drone

Hoofdstuk 6

ROS-framework

In dit hoofdstuk wordt het ROS-framework toegelicht. Eerst wordt er een overzicht gegeven van de

verschillende onderdelen, waarna elk onderdeel afzonderlijk besproken wordt.

6.1 Overzicht

Het volledige algoritme kan opgedeeld worden in kleinere onderdelen, welke worden weergege-

ven in het schema op Figuur 6.1. Op dit schema is te zien dat het geheel opgedeeld wordt in 5

verschillende hoofdonderderdelen, met bijgevoegd de functie en een extra onderdeel. Dit extra

onderdeel, de livestream, is in principe niet nodig maar geeft het actuele beeld van de camera van

de drone weer. De verschillende onderdelen bestaan elk uit een ROS-node. De filosofie achter

ROS is reeds beschreven in sectie 2.8 van de literatuurstudie. Deze nodes vormen samen met de

topics, die nodes onderling verbinden, het ROS-framework. Het ROS-framework van deze thesis

wordt weergegeven in het schema op Figuur 6.2. Hierin worden de nodes voorgesteld in een ovaal

en de topics in een rechthoek.

Figuur 6.1: Weergave verschillende onderdelen

41

HOOFDSTUK 6. ROS-FRAMEWORK 42

Figuur 6.2: ROS-framework van deze thesis

6.2 ROS-nodes

Elke node, waarin het volledige algoritme is opgedeeld, wordt in deze sectie besproken. Hierbij

wordt er steeds de functie in het grotere geheel, het algoritme aan de hand van pseudocode en

verschillende gebruikte topics beschreven.

6.2.1 Camera node

De camera node heeft als functie beelden te nemen met de onboard camera. Deze beelden zijn

van uiterste belang in het gehele algoritme voor de realtime positie bepaling van het landingsplat-

form ten opzichte van de drone. Voor deze node wordt er gebruik gemaakt van de Raspicam library.

Deze library is ontwikkeld door de onderzoeksgroep AVA (Applications of Artificial Vision) van de

universiteit in Cordoba en maakt het mogelijk om eenvoudig de Raspberry Pi camera in te stellen

en te gebruiken.

Bij de start van de node wordt de publisher en camera geınitialiseerd. Hierbij worden 30 beelden

per seconde gepublished op het camera frame topic en worden enkel de afmetingen van de frame

naar 640x480 pixels aangepast. De rest (witbalans, contrast, saturatie en sluitertijd) wordt op de

standaardwaarden gehouden. Er werd voor deze afmetingen gekozen omdat deze nog een goede

beeldkwaliteit geeft, maar het algoritme niet extra belast wordt door de grote hoeveelheid pixels bij

grotere afmetingen.


Data: beelden camera

Result: published message op camera frame topic

while nodehandler is oke do

neem foto (openCV image);

converteer foto naar ROS image;

image als message publishen;

spinOnce();

endAlgorithm 1: Camera node

Het algoritme om foto´s te trekken wordt weergegeven in de pseudocode 1 en bestaat uit een while-

lus. Deze wordt pas onderbroken als de node gestopt wordt. In deze lus worden openCV images

genomen. Het is echter niet mogelijk om in ROS openCV images te verzenden. Als oplossing

kan deze images omgezet worden naar een ROS image. Hierbij wordt er gebruik gemaakt van het

cv bridge package voor de omzetting en het image transport package om de foto te verzenden.

6.2.2 Livestream node

De livestream node heeft geen belangrijke functie en wordt enkel gebruikt om het actuele beeld

van de drone weer te geven. Deze node bestaat uit een initialisatie van een subsciber op het

camera frame topic en een callback functie. De callback-functie wordt steeds opgeroepen wanneer

de subscriber een nieuw message van het camera frame topic ontvangen heeft. Hierbij wordt de

ROS image uit de message weer omgezet in een openCV image door het cv bridge package, om

nadien weergegeven te worden.

6.2.3 Arucodetection node

In de arucodetection node wordt in de ontvangen beelden, die door de camera node zijn doorge-

stuurd, gezocht naar een aruco marker. Hierbij wordt er gebruik gemaakt van de AruCo library,

die door de AVA onderzoeksgroep ontwikkeld is. Dit detectieproces wordt uitgelegd in sectie 2.2

van de literatuurstudie. Bij het toepassen van deze library wordt van elke gedetecteerde marker de

translatie- en rotatievector gevormd. Uit de translatievector wordt de positie van de marker ten op-

zichte van de drone bepaald. Deze wordt later gebruikt om de drone bij te sturen. De rotatievector

geeft de rotatie van de marker tov van de camera rond zijn assen weer. Deze worden tevens later

gebruikt bij de bepaling of het landingsplatform geschikt is om te landen.

Deze node bestaat uit een initialisatie van een subscriber op het topic camera frame en een pu-

blisher op het topic aruco position en uit een callback-functie. De callback-functie wordt steeds

opgeroepen indien de subscriber een nieuw message ontvangen heeft van het camera frame to-

pic. Deze functie wordt weergegeven door de pseudocode uit 2. Hierin wordt de ontvangen image

omgezet in een openCV image en wordt er met behulp van de camera parameters AruCo markers


gedetecteerd. Het is mogelijk dat markers met verschillende id’s worden gedetecteerd. Enkel de

marker met het gezochte id is nuttig. In een for-lus worden alle gedetecteerde markers gecontro-

leerd of hun id overeenstemt met het gezochte id. Indien dit het geval is, wordt van deze marker via

het rodrigues algoritme de gevonden rotatie vector omgezet naar een rotatiematrix. Uit de transla-

tievector worden de x,y en z positie van de marker tov de camera gehaald. Hierna wordt de for-lus

onderbroken. Indien de gezochte marker niet gevonden is, wordt de yaw, pitch en roll op 0 gezet.

Anders wordt er uit de rotatie matrix de Euler hoeken berekend volgens de manier van Slabaugh

(1999). Wanneer de gezochte marker gevonden is, worden daarna alle waarden in een message

gestoken en gepublished op het topic aruco position.

Data: beelden camera, id gezochte marker, camera parameters

Result: positie marker tov camera, yaw, pitch, roll gepublished op aruco position topic

converteer ROS image naar openCV image;

camera parameters inlezen;

markers detecteren in image;

for alle gevonden markers do

if id marker == id gezochte marker then

converteer rotatie vector naar rotatie matrix;

x,y,z afstanden uit translatie vector halen;

gezochte marker gevonden = true;

break;

end

end

if gezochte marker niet gevonden then

yaw, pitch, roll = 0;

else

yaw, pitch, roll berekenen uit rotatie matrix;

end

if gezochte marker gevonden then

x,y,z in message plaatsen;

yaw, pitch, roll in graden zetten en in message plaatsen;

message publishen op aruco position topic;

endAlgorithm 2: Callback-functie arucodetection node

6.2.4 Kalmanfilter node

Zoals besproken in sectie 1.2 van de situering, werd er opgelegd om voor een vlotte werking 50

keer per seconde data naar de drone te sturen. Echter, zoals gezegd in sectie 6.2.1, gaat de ca-

mera aan 30 Hz foto’s trekken, waardoor kan er de arucodetection node maar uit 30 beelden per

seconden de positie van de marker ten opzichte van de camera bepaald worden. Hieruit volgt dat,


indien op elk beeld een marker wordt gedetecteerd, maar maximaal 30 keer per seconde data naar

de drone gestuurd kan worden. Dit zijn 20 datasets per seconde te weinig. Toch is het mogelijk om

het aantal datasets van 30 naar 50 keer per seconde up te samplen met behulp van een kalman fil-

ter, die in sectie 2.6 van de literatuurstudie besproken is. Dit is tevens ook de functie van deze node.

Data: positie van marker tov camera

Result:

afstanden in x,y,z uit message in variabelen plaatsen;

newMessage = true;Algorithm 3: Callback-functie kalmanfilter node

Deze node bestaat naast de standaard initialisaties van subscribers en publishers, uit twee func-

ties, een callback functie en een functie voor de kalmanfilter zelf. Tijdens de initialisatie wordt een

subsciber op het topic aruco position en een publisher op het topic drone position geınitialiseerd.

Het topic aruco position levert aan 30 keer per seconde de actuele positie van de marker tov de

camera aan. Via het drone position topic wordt de upgesamplede datasets 50 keer per seconde

gepublished.

De callback functie wordt automatisch opgeroepen indien er messages ontvangen worden van het

aruco position topic. Hierin worden de ontvangen waarden uit het message in globale variabelen

geplaatst. Daarna wordt tevens de globale boolean newMessage op true gezet, zodat de rest van

het algoritme weet dat er nieuwe waarden zijn ontvangen. Deze functie wordt weergegeven in

pseudocode 3.

De functie die de kalman filter bevat bestaat uit een initialisatie van de kalman filter, het aanmaken

van een matrix voor de metingen en actuele state, een boolean (eersteMessage), die weergeeft

of er de afgelopen 25 periodes nieuwe data is binnengekomen, een counter (geenNieuweMessa-

ges) die bijhoudt hoeveel achtereenvolgende periodes er geen nieuwe data is binnen gekomen

en de initialisatie van het aantal periodes per seconde (50). Hierna start er een while-lus die pas

beeindigd wordt wanneer de node gestopt wordt.

Deze while-lus wordt weegegeven in pseudocode 4. Ze werkt volgens het principe dat wanneer de

afgelopen 25 perioden een message ontvangen is, de nieuwe state voorspeld wordt, waarna deze

waarden in een message geplaatst worden en deze wordt published. Indien er gedurende deze pe-

riode geen nieuwe message ontvangen is, wordt er een counter verhoogd. Wanneer deze counter

groter of gelijk is aan 25 (dus 25 opeenvolgende periodes geen nieuwe message ontvangen) wordt

de boolean, eersteMessage, op false gezet. Hierdoor worden er geen messages met data meer

verstuurd. Indien de counter kleiner is dan 25, wordt de actuele state gezien als de gecorrigeerde

state. Wanneer er echter wel een nieuw message ontvangen is, wordt de counter op 0 gezet en

worden de waarden van de message in de matrix voor de metingen geplaatst. Hierna wordt er ge-

controleerd of er de afgelopen 25 periodes een eerste message ontvangen is. Zo niet, worden de

waarden uit de metingmatrix in de actuele state matrix geplaatst en wordt de actuele state gezien

als de gecorrigeerde state. EersteMessage krijgt waarde true omdat er een message ontvangen is.

Wanneer er de afgelopen 25 perioden al wel een eerste message ontvangen is, wordt de actuele


state gecorrigeerd door de metingen. Op het einde van de while-lus gaat de node gedurende een

bepaalde tijd in slaapmodus zodat er gezorgd wordt dat er strikt 50 periodes per seconden zijn.

Omdat dit een redelijk ingewikkeld algoritme is, wordt er in Figuur 6.3 een flowchart weergegeven

om de werking van de kalman filter te verduidelijken.

Data: positie marker uit messages

Result: 50 Hz dataset op topic drone position

initialisatie kalman filter;

meting en actuele state matrix aanmaken;

eersteMessage = false;

counter geenNieuweMessages = 0;

loop rate(50);

while zolang node niet gestopt wordt do

if eersteMessage == true then

state voorspellen en in state matrix plaatsen;

waarden state matrix in message plaatsen;

message publishen op topic drone position;

end

if newMessage == false then

counter geenNieuweMessages verhogen;

if counter >= 25 then

eersteMessage = false;

else

de actuele state matrix in kalman filter als gecorrigeerde state;

end

else

counter geen NieuweMessages op 0;

nieuwe metingen in meting matrix plaatsen;

if eersteMessage == false then

meting matrix in state matrix plaatsen;

de actuele state matrix in kalman filter als gecorrigeerde state;

eersteMessage == true;

else

kalman filter corrigeren met meting matrix;

end

newMessage = 0;

end

spinOnce();

sleep();

endAlgorithm 4: Filter-functie kalmanfilter node


Figuur 6.3: Flowchart while-lus kalmanfilter node

6.2.5 Pidcontrol node

Om de drone te besturen wordt er gebruik gemaakt van snelheden in x-,y- en z-richting in plaats

van afstanden. Het is echter mogelijk om deze afstanden, gevonden in arucodetection node om te

zetten in snelheden. Gezien een drone in de buitenwereld te maken kan krijgen met hevige wind,

is het niet mogelijk om een constante snelheid te gebruiken omdat de drone door de hevige wind

mogelijks niet vooruit geraakt. Wanneer we echter een variabele snelheid gebruiken, waarbij er re-

kening gehouden wordt met snelheid waarmee de afstand tot de marker vermindert, is het mogelijk

dat de drone een hogere snelheid gaat ontvangen bij zware tegenwind en toch zal kunnen bewe-

gen. Om dit te verwezelijken kan er gebruik gemaakt worden van PID-controllers. De bepaling van

de snelheid via de PID-controllers zal gedaan worden door deze node.

Deze node bestaat uit verschillende functies. In een eerste functie wordt bij de start van de

node twee subscribers op de topics drone postion en pid start en een publisher op het topic

drone snelheden topic aangemaakt. Elke richting (x,y,z en yaw) heeft een eigen structure. Deze

structure bestaat uit verschillende variabelen, namelijk error, vorigetijd, somError, vorigeError en

snelheid. Deze variabelen worden gebruikt door de pid-controllers. Door het gebruik van struc-

tures is het mogelijk om een algemene pid-controller functie voor de verschillende snelheden


te gebruiken. Na de initialisatie van de subscribers en publishers worden tevens de structures

geınitialiseerd. Omdat de node twee subscribers bevat, zijn er ook twee callback-functies aan-

wezig. Er is een callback-functie die bij het binnen komen van messages op het drone position

topic de ontvangen afstanden in globale variabelen gaat steken. Tevens wordt een globale boolean

(newMessage) op true gezet, zodat de rest van het algoritme weet dat er een nieuw message ont-

vangen is. Een tweede callback-functie wordt opgeroepen bij het ontvangen van een message op

het topic pid start, afkomstig van dronecontrol node. Hierbij wordt er enkel een boolean (start) op

true gezet.

De algemene functie van deze node bestaat uit een while-lus en wordt weergegeven in pseudo-

code 5. Deze lus wordt uitgevoerd zolang de node niet gestopt is en de drone niet geland is. Het

eerste deel van deze lus is ook weer een lus die wordt uitgevoerd zolang de node loopt en er geen

startsignaal vanuit de dronecontrol node gegeven is. Hierin worden steeds alle structures gereset

en geupdatet met de actuele tijd. Na het startsignaal wordt er gecontroleerd of er een message

met afstanden is ontvangen. Indien wel, zal, zoals besproken in sectie 2.7 van de literatuurstudie,

de afstanden in x- en y-richting en yaw als error gebruikt worden.Hierna zal de pidcontroller-functie

opgeroepen worden.

Indien er nog niet gestart is met landen, zal de z error afhangen van de ingestelde zweefhoogte,

waarna ook de pidcontroller-functie voor de z snelheid opgeroepen worden. Om te bepalen of de

landing mag gestart worden, wordt er gekeken of de x- en y-afstand van de marker binnen de ge-

vraagde nauwkeurigheid liggen. Wanneer dit een x aantal opeenvolgende keren voorkomt, wordt

er na de hellingscontrole, de landing gestart en de startlandingstijd ingesteld op de actuele tijd.

Indien de x-, y-afstanden buiten de nauwkeurigheid ligt, wordt de nauwkeurigheidcounter terug op

0 gezet. Als de landing al wel gestart is, is de snelheid in z richting de voorgedefinieerde landings-

snelheid.

Indien er geen nieuwe message ontvangen werd en de landing al gestart is, wordt de snelheid in

alle richtingen, behalve z-richting, 0. Wanneer de drone al te laag is om markers te detecteren,

daalt de drone recht naar beneden. De landing wordt beeindigd nadat het verschil tussen de actu-

ele en de startlandingstijd 15 seconden is. Na het oproepen van de doorstuur-functie gaat de node

in een slaapmodus zodat deze lus ook weer maximaal 50 keer per seconde uitgevoerd wordt.

In de doorstuur-functie worden er eenvoudigweg de snelheden uit de structures in een message

geplaatst, waarna deze gepublished worden op het drone snelheden topic.

De controller-functie heeft dezelfde werking zoals besproken in sectie 2.7 van de literatuurstu-

die. Echter wordt de uitkomst nog geschaald met vooropgestelde waarden. Omdat bij het stan-

daardcoordinatenstelsel de oorsprong linksboven ligt, gaan we, wanneer de marker voor de drone

ligt (hoger in het beeld), een negatieve afstand hebben. Dit veroorzaakt een negatieve snelheid,

waardoor de drone naar achteren zal vliegen, wat niet de juiste richting is. Als oplossing kunnen we

eenvoudig de snelheden inverteren. Om veiligheidsredenen wordt er ook een maximale snelheid

gedefinieerd.

In 5 wordt een flowchart afgebeeld om de werking van deze while-lus duidelijker weer te geven.


Data: positie van marker tov camera

Result: snelheden in x-,y-,z en yaw-richting

counter nauwkeurigheid;

loop rate(50);

while zolang node niet gestopt wordt en drone niet geland do

while zolang node niet gestopt wordt en geen startsignaal do

struct snelheden resetten en updaten met actuele tijd;

spinOnce();

end

if newMessage then

x,y struct error updaten met x,y afstand tot marker;

yaw struct error updaten met 180+-yaw van marker (afhankelijk of yaw kleiner of

groter is dan 0);

controller functie oproepen met x,y,yaw struct, resultaat in x,y,yaw snelheden

plaatsen;

if nog niet gestart met landing then

z struct error updaten met ZWEEFHOOGTE-hoogte marker;

controller functie oproepen z struct, resultaat in z snelheid plaatsen;

if x,y afstand binnen gevraagde nauwkeurigheid then

counter nauwkeurigheid verhogen;

if counter == THRESHOLDSTARTLANDING then

if roll en pitch marker <MAXHELLING then

startlanding = true;

startlandingstijd instellen op actuele tijd;

else

startlanding = false;

end

end

else

counter nauwkeurigheid = 0;

end

else

z snelheid = LANDINGSSNELHEID;

end

else

if geen newMessage en landing is gestart then

x,y,yaw snelheden = 0;

end

end

if actuele tijd - startlandingstijd >15 seconden en landing is gestart then

drone is geland;

end

doorsturen();

sleep();

endAlgorithm 5: While-lus pidcontol node


Figuur 6.4: Flowchart while-lus pidcontrol node

6.2.6 Dronecontrol node

De dronecontrol node is de laatste node in het ROS-framework. Ze heeft als functie de snelheden,

die berekend zijn in de pidcontrol node, door te geven aan de Pixhawk zodat deze de motoren juist

kan aansturen. Om de Pixhawk aan te sturen vanuit een programma is men genoodzaakt om van

mode te veranderen, namelijk naar offboard-mode. Het is echter niet mogelijk om de drone hand-

matig aan te sturen wanneer hij in deze mode zit. Dit kan voor gevaarlijke en ongecontroleerde

toestanden leiden. Hierdoor is er een extra functionaliteit toegevoegd waarbij er steeds naar de


RC ingang geluisterd wordt. Indien een schakelaar naar een uiterste toestand gezet wordt, wordt

er tussen offboard- en manual-mode gewisseld waarna de drone terug manueel bestuurd kan wor-

den. Deze omzetting duurt maximaal 1 seconde.

Deze node bestaat zoals gewoonlijk uit een initialisatie-functie waarbij verscheidene subscribers en

publishers aangemaakt worden voor de communicatie met de pidcontrol node en mavros functio-

naliteiten. Er zijn tevens ook enkele callback-functies toegevoegd. Ondermeer een callback-functie

die uitgevoerd wordt bij een message op het topic, drone snelheden. Deze gaat de snelheden uit

de message halen en in globale variabelen steken. Er is ook een callback-functie aanwezig die

gebruikt wordt bij een message op een mavros topic. Dit message bevat de status van de Pixhawk

met onder andere de mode in. Welke gebruikt wordt bij het switchen tussen modes. Als laatste

callback-functie is er de functie die opgeroepen wordt bij een message op een mavros topic, die de

RC input weergeeft. Deze wordt gebruikt om de waarde van een bepaalde schakelaar te controle-

ren en te detecteren indien er van mode veranderd moet worden.

Er zijn ook twee functies aanwezig die de Pixhawk van mode laten veranderen. Na de initialisatie

bij de start van de node, wordt, afhankelijk van de stand van schakelaar die de Pixhawk van node

laat veranderen, een van deze twee functies gestart. Een functie wordt gebruikt om van offboard

naar manueel te switchen. Hierbij wordt er gedurende het switchen een extra functie (zweven) op-

geroepen. Dit omdat het switchen naar een andere mode een bepaalde tijd duurt en de Pixhawk

minstens twee berichten per seconde moet ontvangen. Anders wordt de pixhawk gedisarmed.

Deze extra functie gaat messages met snelheden publishen op een mavros topic. Deze snelheden

zijn in alle richtingen 0 m/s zodat de drone tijdens het veranderen van mode, op eenzelfde plaats

blijft zweven. Na het aanpassen van de mode naar manueel, blijft de node in een while-lus zolang

er niet naar offboard mode geswitch wordt. Een tweede functie die de mode gaat veranderen, gaat

de mode naar offboard veranderen. Dit werkt volgens hetzelfde principe als de vorige functie, maar

hier wordt ook een startsignaal gegeven naar de pidcontrol node, zodat deze messages met snel-

heden begint te sturen. Na het publishen van dit bericht wordt er een laatste functie opgeroepen.

Deze laatste functie heeft als nut snelheden messages aan te maken en in te stellen met de ont-

vangen snelheden van het drone snelheden topic. Deze messages worden gepublished op het

mavros topic, genaamd mavros/setpoint raw/local. In Figuur 6.5 wordt een flowchart weergegeven

van de werking van deze node. De callback-functies en zweef-functie worden hier niet in getoond.


Figuur 6.5: Flowchart werking dronecontrol node met functiebenaming

Hoofdstuk 7

Testen

In dit hoodstuk worden van twee verschillende testen de resultaten weergegeven en besproken. In

een eerste test wordt de performantie van de verschillende nodes in het ROS-framework onderder-

zocht. Een tweede test geeft het verloop van de bepaalde snelheid bij wijzigingen van de positie

van de drone ten opzichte van de AruCo marker weer. Op het einde van dit hoofdstuk wordt kort

besproken waarom het niet mogelijk was om het volledige ROS-framework in de praktijk te testen.

7.1 Performantie ROS-framework

In deze test wordt de performantie van de verschillende nodes binnen het ROS-framework beke-

ken. Hierbij wordt er nagegaan of de cruciale nodes wel de gevraagde performantie bereiken. Dit

wil zeggen dat de drone per seconde 50 messages met snelheden moet ontvangen om zich te

kunnen herpositioneren. Dit werd gerealiseerd door ofwel het aantal publicaties van messages,

ofwel het aantal keer er naar een marker gezocht werd of het aantal keer een while-lus doorlopen

was te vergelijken met het verschil tussen eind- en starttijd van de node. Tijdens deze test werd het

volledige ROS-framework gelijktijdig getest. Er werd dus met de maximale load op de Raspberry

Pi, die in de praktijk ook zou aanwezig zijn, getest. Deze test werd drie keer uitgevoerd, waarna

het gemiddelde werd genomen.

De resultaten van deze test worden weergegeven in Tabel 7.1. Hierbij wordt er per node de drie re-

sultaten en het gemiddelde ervan weergegeven. In de laatste kolom wordt een extra uitleg gegeven

over wat getest is per node. In de tabel is te zien dat de dronecontrol node 50 keer per seconde

messages met snelheden naar de Pixhawk stuurt. Deze waarde is perfect afgerond op 50,0000.

Dit komt omdat de node zelf geen berekeningen moet doen en enkel ontvangen waarden door

moet geven aan de Pixhawk. Dit is tevens ook de gewenste snelheid die in de doelstellingen 1.2 in

hoofdstuk 1 opgedragen werd. Een ander resultaat dat opvalt, is dat van de arucodetection node

(5,2865). Deze lage waarde wordt veroorzaakt door het AruCo detection algoritme gecombineerd

met het lagere processing power van de Raspberry pi. Dit is een zeer intensief algoritme waarbij

de uitvoertijd zeer hard toeneemt naarmate het aantal pixels van het inputbeeld stijgt. Ter vergelij-

king hebben we het geheel ook getest met lagere resolutie, namelijk 100x100 pixels. Dit gaf een

53

HOOFDSTUK 7. TESTEN 54

resultaat van 11,5321.

De overige resultaten zijn de resultaten die we gepland hadden.

Tabel 7.1 Resultaten performantie ROS-framework

1 2 3 Gemiddelde Extra uitleg

Camera node 29,9639 29,9674 29,9705 29,9673 Foto´s per seconde verzonden

Arucodetection node 5,1702 5,3230 5,2865 5,2599 Keer per seconde naar marker gezocht

Kalmanfilter node 49,9790 49,9944 49,9805 49,9846 Datasets per seconde verzonden

Pidcontrol node 49,9933 49,9957 49,9964 49,9951 Snelheden per seconde verzonden

Dronecontrol node 50,0000 50,0000 50,0000 50,0000 Snelheden per seconde naar Pixhawk

7.2 Verloop snelheid bij verandering van positie camera tov marker

In een volgende test wordt het verloop en de verandering van de berekende snelheid bij een ver-

andering van de positie van de camera ten opzichte van de marker weergegeven. Hierbij werd de

drone in de y-richting over de marker bewogen. Hieruit werden vanuit de picontroller node snel-

heden bepaald en gekeken naar het verloop van de snelheid indien de drone steeds verder weg

van de marker zou bewegen. De resultaten van deze beweging worden weergegeven in Tabel

7.2. Wanneer we het geheel vanuit bovenaanzicht bekijken, moet theoretisch gezien de snelheid

positief zijn wanneer de drone zich onder (ten zuiden) de marker bevindt. Dit is een voorwaartse

beweging. En negatief indien de drone zich boven (ten noorden) de marker bevindt. Dit is een

achterwaartse beweging. Naarmate de drone dichter bij de marker komt zou de snelheid naar nul

moeten gaan en naar +∞ of −∞ wanneer de drone verder weg van de marker beweegt.

Omdat deze tabel redelijk onduidelijk is om het verloop van de snelheid weer te geven, zijn in Figuur

7.1 een aantal resultaten (in de tabel vet gedrukt) visueel weergegeven. Hierin wordt de snelheid

op verschillende afstanden van de marker geplot, waarbij de drone van links naar rechts vliegt en

rechts de voorkant is van de drone. We zien dat bij de start de snelheden positief zijn en naar nul

gaan wanneer we dichter bij de marker komen. Wanneer we dan de marker passeren, wordt de

snelheid negatief en naarmate we verder blijven weggaan van de marker, verhoogt de snelheid.

Dit is het verloop van de snelheid bij verandering van de positie tov de marker, die we theoretisch

gezien, wilden behalen. Hieruit kunnen we concluderen dat het algoritme werkt.

Er zijn echter enkel bewegingen in de y-richting getest. Aangezien de andere richtingen volgens

hetzelfde pricipe en dezelfde code werken, kunnen we analoge resultaten verwachten bij de andere

richtingen.


Tabel 7.2 Resultaten Verloop snelheid bij verandering van positie camera tov marker

Yerror (m) Ys (m/s)

-0.0444177 0.0530767

-0.0423595 0.0454362

-0.0396735 0.0426926

-0.0565039 0.0645432

-0.0889554 0.101122

-0.0878087 0.0917957

-0.118071 0.130205

-0.0660797 0.0578159

-0.0498149 0.0506072

-0.0196695 0.0170409

-0.00398139 0.00497707

0.022305 -0.0240147

0.0439391 -0.0445955

0.0186303 -0.00759759

-0.00817728 0.0196051

-0.0403169 0.0531785

-0.0768336 0.0909816

-0.0145983 0.00409481

0.0156081 -0.0181434

0.0471645 -0.0501551

0.0654747 -0.0653175

0.0126307 0.00528339

-0.0075673 0.0173389

-0.071545 0.0924404

-0.032436 0.0276407

0.0145428 -0.0213419

0.0853093 -0.0982686

0.0850554 -0.0804722

Figuur 7.1: Flowchart while-lus kalmanfilter node

7.3 Praktijktest

Ondanks dat het volledige ROS-framework af was, is het toch niet mogelijk geweest om dit te testen

in de praktijk. Er werden enkele tests gedaan waarbij het volledige ROS-framework gebruikt werd

en er succesvol overgeschakeld werd op de volledige autonomische werking. De drone voerde

echter niet de gewenste bewegingen uit, waardoor er nooit een succesvolle landing is geweest.


Een ander idee was om vanuit een dataset, waarbij een landing gefilmd werd, te gebruiken als data

voor het algoritme en naar berekende snelheden te kijken. We bekwamen geen geschikte resul-

taten om te analyseren omdat we met pid-controllers werken die, indien de uitgevoerde beweging

niet de geplande beweging is, zeer snel de maximale snelheden als resultaat hebben.

We zullen na de deadline van deze thesis verderwerken en proberen een werkend resultaat te

verwezenlijken.

Hoofdstuk 8

Resultaten

Deze thesis bestond uit een aantal afzonderlijke onderdelen waarnaar er onderzoek is verricht. De

resultaten worden in volgende secties nog eens kort overlopen.

8.1 Embedded processing platform

Uit het onderzoek in sectie 2.10 van de literatuurstudie werd gekozen voor het gebruik van de

Raspberry Pi, waarbij er gekeken werd naar gewicht, prijs, verbruik, processing power. Qua gewicht

en prijs waren de Raspberry Pi en Asus tinker board ongeveer even goed. De Tinker board is echter

krachtiger, maar verbruikt meer dan de Raspberry pi. Er werd geopteerd voor lager verbruik van

de Raspberry Pi, omdat het knelpunt bij drones de beperkte batterij is.

8.2 Landingsplatformen

In de doelstellingen werd er aangehaald dat er gezocht moest worden naar een manier om het

landingsplatform in alle lichtcondities te kunnen detecteren. Hiervoor zijn in sectie 3 verschillende

belichtingstechnieken uitgewerkt waarna er gekozen werd om een belichting te gebruiken waarbij

de marker op melkglas ligt en via een kader van IR-LED’s langs onderen belicht wordt. Tevens werd

er ook toepassingsgericht gekeken om de beste grootte van marker te selecteren. Hierbij werd er

rekening gehouden met de nauwkeurigheid van GPS’en. Door deze nauwkeurigheid te combineren

met de kijkhoek van de camera kon via goniometrie de minimale detectiehoogte berekend worden.

Na het invullen van deze hoogte in een functie die bepaald is dmv enkele testen, kon de grootte

van de marker bepaald worden. Deze marker is in de praktijk getest en gaf een positief resultaat

terug, maw de marker was op de minimale detectiehoogte detecteerbaar.

57

HOOFDSTUK 8. RESULTATEN 58

8.3 Behuizing

Voor de Raspberry Pi en de camera zijn er twee behuizingen bedacht. Een ervan is enkel concep-

tueel uitgewerkt. Hierbij zijn camera en Raspberry Pi in een omhulsel gestoken. Door een te klein

landingsgestel van de drone was het niet mogelijk om dit omhulsel onder de drone te monteren.

Een tweede behuizing waarbij camera en Raspberry Pi apart gemonteerd werden, is wel volledig

uitgewerkt en gebruikt in alle testen.

8.4 Communicatie Raspberry Pi en Pixhawk flight controller

Het was belangrijk om een methode te vinden waarmee het embedded processing platform en Pix-

hawk flight controller met elkaar konden communiceren. Deze methode is gevonden en succesvol

uitgetest.

8.5 ROS-framework en testen

Er werd een heel algoritme met extra veiligheidsmaatregelen ontwikkeld dat het mogelijk maakt

om, aan de gewenste 50 keer per seconde, data naar de drone te sturen om deze te herpositio-

neren. Uit enkele testen bleek dat het aantal keer per seconde dat er een message met gewenste

snelheden naar de drone gestuurd werd, overeenstemde met de opgelegde waarden. Tevens werd

er getest of de Raspberry Pi het hele ROS-framework gelijktijdig kon uitvoeren. Dit gaf ook weer

een positief resultaat terug.

Hoofdstuk 9

Besluit

Voordat we een besluit gaan nemen, kijken we eerst terug naar de doelstellingen. Er werd gezocht

naar een manier om een drone volledig autonoom te herpositioneren boven een bepaalde locatie

en de drone, indien de nauwkeurigheid goed genoeg is, te laten landen. Hierbij moest de drone

zelfstandig de locatie detecteren met behulp van een bepaald type marker. De drone moest vol-

ledig onafhankelijk zijn van externe computers. Hierdoor moest er dus gezocht worden naar een

geschikt embedded processing platform dat krachtig genoeg is om real time het landingsplatform

te detecteren en 50 keer per seconde de drone aan te sturen. Tevens moet het algoritme werken

in alle lichtcondities.

Deze doelstellingen hebben we opgedeeld in verschillende onderdelen. Er werd gestart met het

schrijven van het algoritme, waarna de onderdelen van het algoritme apart getest werden. Voor de

communicatie tussen het embedded processing platform en de drone werden verschillende test-

programma’s gemaakt en getest voordat dit toegevoegd werd tot het grotere geheel. Tussendoor

werd er aan het ontwerp en montage van de behuizing voor de camera en het embedded proces-

sing platform gewerkt, waarbij we heel wat problemen hadden met het loskomen van bouten door

trillingen en de beperkte sterkte van het materiaal. Nadien hebben we verschillende belichtings-

technieken getest, de minimale grootte van de marker berekend en in de praktijk uitgetest. Op het

einde is de performantie van het gehele ROS-framework op het embedded processing platform en

de berekende snelheden die de drone moet uitvoeren, geanalyseerd.

We zijn echter enkel in de mogelijkheid geweest om in de praktijk tijdens het vliegen met de drone

te switchen naar automatische werking en omgekeerd. Hierbij deed de drone niet de bewegingen

die we wensten te doen, waardoor we het geheel niet hebben kunnen testen en dus ook geen

succesvolle landing hebben kunnen maken.

Uit verschillende testen kunnen we concluderen dat we de meeste doelstellingen hebben bereikt.

Toekomstig werk

Wat zeker nog gedaan kan worden, is het verder uitwerken van de communicatie tussen de Rasp-

berry Pi en de Pixhawk flight controller zodat het toch mogelijk zou kunnen zijn om met de drone

59

HOOFDSTUK 9. BESLUIT 60

te doen landen.

Verdere uitbreidingen zou het toevoegen van laadpunten in het landingsplatform kunnen zijn, zodat

de batterij kan opgeladen worden. Het volledig waterdicht maken, zou ook een goede oplossing

kunnen zijn zodat de drone niet enkel overdag en ’s nachts bij droog weer kan gebruikt worden. Dit

is toepassingsgericht zeker een goede uitbreiding.

Bibliografie

Ali, N. H. and Hassan, G. M. (2014). Kalman filter tracking. International Journal of Computer

Applications, 89(9).

Bamburry, D. (2015). Drones: Designed for product delivery. Design Management Review,

26(1):40–48.

Bartak, R., Hrasko, A., and Obdrzalek, D. (2014). On autonomous landing of ar. drone: Hands-on

experience. In FLAIRS Conference.

Brown, D. C. (1966). Decentering distortion of lenses. Photogrammetric Engineering and Remote

Sensing.

Cocchioni, F., Mancini, A., and Longhi, S. (2014). Autonomous navigation, landing and recharge

of a quadrotor using artificial vision. In Unmanned Aircraft Systems (ICUAS), 2014 International

Conference on, pages 418–429. IEEE.

CRISP (18 november 2017). Elektromagnetic waves. https://crisp.nus.edu.sg/

˜research/tutorial/em.htm.

Cuevas, E. V., Zaldivar, D., and Rojas, R. (2005). Kalman filter for vision tracking.

Douglas, D. H. and Peucker, T. K. (1973). Algorithms for the reduction of the number of points

required to represent a digitized line or its caricature. Cartographica: The International Journal

for Geographic Information and Geovisualization, 10(2):112–122.

F. van Diggelen, P. E. (2015). The worlds first gps mooc and worldwide laboratory using smartpho-

nes. Proceedings of the 28th International Technical Meeting of The Satellite Division of the

Institute of Navigation (ION GNSS+ 2015), pages 361–369.

Faragher, R. (2012). Understanding the basis of the kalman filter via a simple and intuitive derivation

[lecture notes]. IEEE Signal processing magazine, 29(5):128–132.

Garrido-Jurado, S., Munoz-Salinas, R., Madrid-Cuevas, F. J., and Marın-Jimenez, M. J. (2014).

Automatic generation and detection of highly reliable fiducial markers under occlusion. Pattern

Recognition, 47(6):2280–2292.

61

https://crisp.nus.edu.sg/~research/tutorial/em.htm

https://crisp.nus.edu.sg/~research/tutorial/em.htm

BIBLIOGRAFIE 62

Garrido-Jurado, S., Munoz-Salinas, R., Madrid-Cuevas, F. J., and Medina-Carnicer, R. (2016). Ge-

neration of fiducial marker dictionaries using mixed integer linear programming. Pattern Recog-

nition, 51:481–491.

Hamme, M. V. (25 september 2017). Eneco zet drones in voor

controles van zonne-installaties. https://eneco.prezly.com/

drones-controleren-alle-zonne-installaties-van-eneco.

Hughes, W. J. (2017). Global positioning system (gps), standard positioning service (sps), perfor-

mance analysis report. pages 20–29.

Kaehler, A. and Bradski, G. (2016). Learning OpenCV 3: Computer Vision in C++ with the OpenCV

Library. ”O’Reilly Media, Inc.”.

Martinez, A. and Fernandez, E. (2013). Learning ROS for robotics programming. Packt Publishing

Ltd.

Marty, J. A. (2013). Vulnerability analysis of the mavlink protocol for command and control of

unmanned aircraft. Technical report, AIR FORCE INSTITUTE OF TECHNOLOGY WRIGHT-

PATTERSON AFB OH GRADUATE SCHOOL OF ENGINEERING AND MANAGEMENT.

O’Kane, J. M. (2014). A gentle introduction to ros.

OpenCV (13 november 2017b). Detection of aruco markers. http://www.tonybenn.com/

reco.html.

OpenCV (13 november 2017c). Sorts thresholding. https://docs.opencv.org/3.2.0/

d7/d4d/tutorial_py_thresholding.html.

OpenCV (19 november 2017a). Camera calibration. https://docs.opencv.org/3.3.0/

dc/dbb/tutorial_py_calibration.html.

Pixhawk (16 november 2017a). Mavros mavlink. https://dev.px4.io/en/ros/mavros_

installation.html.

Pixhawk (16 november 2017b). Pixhawk flightcontroller. https://pixhawk.org/modules/

pixhawk.

Rao, B., Gopi, A. G., and Maione, R. (2016). The societal impact of commercial drones. Technology

in Society, 45:83–90.

Rousseau, S. (25 september 2017). Drone vervangt helikopter bij over-

stromingen. https://www.tijd.be/tech-media/technologie/

Drone-vervangt-helikopter-bij-overstromingen/9924797?ckc=1&

ts=1508935023.

Slabaugh, G. G. (1999). Computing euler angles from a rotation matrix. Retrieved on August,

6(2000):39–63.

https://eneco.prezly.com/drones-controleren-alle-zonne-installaties-van-eneco

https://eneco.prezly.com/drones-controleren-alle-zonne-installaties-van-eneco

http://www.tonybenn.com/reco.html

http://www.tonybenn.com/reco.html

https://docs.opencv.org/3.2.0/d7/d4d/tutorial_py_thresholding.html

https://docs.opencv.org/3.2.0/d7/d4d/tutorial_py_thresholding.html

https://docs.opencv.org/3.3.0/dc/dbb/tutorial_py_calibration.html

https://docs.opencv.org/3.3.0/dc/dbb/tutorial_py_calibration.html

https://dev.px4.io/en/ros/mavros_installation.html

https://dev.px4.io/en/ros/mavros_installation.html

https://pixhawk.org/modules/pixhawk

https://pixhawk.org/modules/pixhawk

https://www.tijd.be/tech-media/technologie/Drone-vervangt-helikopter-bij-overstromingen/9924797?ckc=1&ts=1508935023



BIBLIOGRAFIE 63

Suzuki, S. et al. (1985). Topological structural analysis of digitized binary images by border follo-

wing. Computer vision, graphics, and image processing, 30(1):32–46.

Tripicchio, P., Satler, M., Dabisias, G., Ruffaldi, E., and Avizzano, C. A. (2015). Towards smart far-

ming and sustainable agriculture with drones. In Intelligent Environments (IE), 2015 International

Conference on, pages 140–143. IEEE.

Venugopalan, T., Taher, T., and Barbastathis, G. (2012). Autonomous landing of an unmanned

aerial vehicle on an autonomous marine vehicle. In Oceans, 2012, pages 1–9. IEEE.

64

HOOFDSTUK A. RESULTATEN ANALYSE LANDINGSPLATFORMEN 65

Bijlage A

Resultaten analyse landingsplatformen

Tabel A.1 Resultaten analyse grote van marker tov detectie hoogte

Marker *1 *2

Frames Det Frames Percentage Hoogte H Hoogte L Frames Det Frames Percentage Hoogte H Hoogte L

0,04 971 172 17,7137 1,37408 0,193629 944 144 15,2542 1,40839 0,284908

0,05 773 178 23,0272 1,92784 0,196406 854 175 20,4918 1,3892 0,160064

0,06 910 296 32,5275 2,08352 0,223283 948 263 27,7426 2,36439 0,201159

0,07 904 252 27,8761 2,82433 0,193463 931 368 39,5274 2,30747 0,151862

0,08 884 451 51,0181 2,95112 0,18841 1008 399 39,5833 2,99388 0,187921

0,09 942 532 56,4756 3,24532 0,194352 789 346 43,853 3,27571 0,261685

0,10 1080 496 45,9259 3,33737 0,22727 899 502 55,8398 3,19828 0,162007

0,11 816 463 56,7402 3,26629 0,243172 1007 599 59,4836 3,26726 0,173284

0,12 783 465 59,387 3,23793 0,194341 967 467 48,2937 3,25844 0,302698

0,13 849 551 64,8999 3,24597 0,209069 916 642 70,0873 3,27302 0,218035

0,14 1010 715 70,7921 3,25819 0,21129 980 749 76,4286 3,23128 0,212835

0,15 841 634 75,3864 3,20982 0,280582 921 736 79,9131 3,30637 0,270352

0,16 957 678 70,8464 3,20751 0,291843 945 736 77,8835 3,28028 0,502304

0,17 1105 836 75,6561 3,22625 0,285613 1178 1071 90,9168 3,22742 0,299915

0,18 1006 761 75,6461 3,26616 0,359631 1045 668 63,9234 3,2495 0,489779

0,19 1120 931 83,125 3,24368 0,386521 1142 904 73,1594 3,32862 0,355647

0,20 1177 1009 85,7264 3,23063 0,260246 1116 861 77,1505 3,2529 0,263125

Marker *3 GEMIDDELDE

Frames Det Frames Percentage Hoogte H Hoogte L Frames Det Frames Percentage Hoogte H Hoogte L

0,04 991 153 15,4389 1,58281 0,218806 968,7 156,3 16,1356 1,4551 0,2324

0,05 1058 246 23,2514 1,91782 0,17205 895,0 199,7 22,2568 1,7450 0,1762

0,06 1060 267 25,1887 2,30803 0,197531 972,7 275,3 28,4863 2,2520 0,2073

0,07 899 344 38,2647 2,566 0,205867 911,3 321,3 35,2227 2,5659 0,1837

0,08 1066 333 31,2383 2,53479 0,198856 986,0 394,3 40,6132 2,8266 0,1917

0,09 815 374 45,8896 3,32288 0,258255 848,7 417,3 48,7394 3,2813 0,2381

0,10 689 375 54,4267 3,25606 0,178757 889,3 457,7 52,0641 3,2639 0,1893

0,11 711 465 65,4008 3,25687 0,193592 844,7 509,0 60,5415 3,2635 0,2033

0,12 793 418 52,7112 3,234 0,228573 847,7 450,0 53,4640 3,2435 0,2419

0,13 1013 662 65,3504 3,25488 0,22274 926,0 618,3 66,7792 3,2580 0,2166

0,14 969 681 70,2786 3,28739 0,228302 986,3 715,0 72,4998 3,2590 0,2175

0,15 990 745 75,2525 3,25555 0,258203 917,3 705,0 76,8507 3,2572 0,2697

0,16 856 609 71,1449 3,25792 0,282558 919,3 674,3 73,2916 3,2486 0,3589

0,17 1163 956 82,2012 3,258 0,258651 1148,7 954,3 82,9247 3,2372 0,2814

0,18 942 772 81,9532 3,28103 0,354923 997,7 733,7 73,8409 3,2656 0,4014

0,19 1129 784 69,442 3,28709 0,352623 1130,3 873,0 75,2421 3,2865 0,3649

0,20 1178 906 76,91 3,23982 0,352293 1157,0 925,3 79,9290 3,2411 0,2919

FACULTEIT INDUSTRIELE INGENIEURSWETENSCHAPPEN TECHNOLOGIECAMPUS DE NAYER

Jan De Nayerlaan 5 2860 SINT-KATELIJNE-WAVER, België

tel. + 32 15 31 69 44 [email protected]

www.iiw.kuleuven.be

Date post:	04-Jul-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Detectie van landingsplat- formen voor drones · 2018-02-12 · Pi instead of an Asus Tinker Board....

Documents