Detectie van landingsplat- formen voor drones · 2018-02-12 · Pi instead of an Asus Tinker Board....
Transcript of 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.1.2 Belichtingstechniek 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.3 Belichtingstechniek 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
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
HOOFDSTUK 2. LITERATUURSTUDIE 6
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.
HOOFDSTUK 2. LITERATUURSTUDIE 7
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.
HOOFDSTUK 2. LITERATUURSTUDIE 8
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
HOOFDSTUK 2. LITERATUURSTUDIE 9
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
HOOFDSTUK 2. LITERATUURSTUDIE 10
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.
HOOFDSTUK 2. LITERATUURSTUDIE 11
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.
HOOFDSTUK 2. LITERATUURSTUDIE 12
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.
HOOFDSTUK 2. LITERATUURSTUDIE 13
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/
HOOFDSTUK 2. LITERATUURSTUDIE 14
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.
HOOFDSTUK 2. LITERATUURSTUDIE 15
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
HOOFDSTUK 2. LITERATUURSTUDIE 16
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.
HOOFDSTUK 2. LITERATUURSTUDIE 17
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.
HOOFDSTUK 2. LITERATUURSTUDIE 18
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.
HOOFDSTUK 2. LITERATUURSTUDIE 19
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.
HOOFDSTUK 2. LITERATUURSTUDIE 20
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.
HOOFDSTUK 2. LITERATUURSTUDIE 21
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
HOOFDSTUK 2. LITERATUURSTUDIE 22
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.
HOOFDSTUK 2. LITERATUURSTUDIE 23
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.
HOOFDSTUK 2. LITERATUURSTUDIE 24
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
HOOFDSTUK 2. LITERATUURSTUDIE 25
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
3.1.2 Belichtingstechniek 2
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.
HOOFDSTUK 3. LANDINGSPLATFORMEN 28
Figuur 3.3: Marker langs opzij belicht en afgedekt door glas of plastic
3.1.3 Belichtingstechniek 3
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
HOOFDSTUK 3. LANDINGSPLATFORMEN 29
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
HOOFDSTUK 3. LANDINGSPLATFORMEN 30
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.
HOOFDSTUK 3. LANDINGSPLATFORMEN 31
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
HOOFDSTUK 3. LANDINGSPLATFORMEN 32
(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
HOOFDSTUK 3. LANDINGSPLATFORMEN 33
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.
HOOFDSTUK 3. LANDINGSPLATFORMEN 34
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.
HOOFDSTUK 6. ROS-FRAMEWORK 43
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
HOOFDSTUK 6. ROS-FRAMEWORK 44
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,
HOOFDSTUK 6. ROS-FRAMEWORK 45
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
HOOFDSTUK 6. ROS-FRAMEWORK 46
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
HOOFDSTUK 6. ROS-FRAMEWORK 47
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
HOOFDSTUK 6. ROS-FRAMEWORK 48
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.
HOOFDSTUK 6. ROS-FRAMEWORK 49
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
HOOFDSTUK 6. ROS-FRAMEWORK 50
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
HOOFDSTUK 6. ROS-FRAMEWORK 51
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.
HOOFDSTUK 6. ROS-FRAMEWORK 52
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.
HOOFDSTUK 7. TESTEN 55
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.
HOOFDSTUK 7. TESTEN 56
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
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.
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