augmented reality voor interventieploegen · 2017-09-27 · abstract in deze thesis wordt...

FACULTEIT INDUSTRIELE INGENIEURSWETENSCHAPPEN

TECHNOLOGIECAMPUS DE NAYER

Augmented Reality voorInterventieploegen

Timothy CALLEMEIN

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

Co-promotor(en): ir. Inge Coudron industriele wetenschappen: MasterElektronica-ICT ICT

Academiejaar 2015 - 2016

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. Vooraanvragen 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, schakelingenen programma’s voor industrieel of commercieel nut en voor de inzending van deze publicatie terdeelname aan wetenschappelijke prijzen of wedstrijden.

Dankwoord

Ik zou van de gelegenheid gebruik willen maken om enkele personen te bedanken die het medemogelijk hebben gemaakt deze thesis tot het huidige resultaat te brengen. Mijn dank gaat naarmijn promotor Prof. ir. Goedeme die het mogelijk heeft gemaakt om aan een thesis te mogenwerken dat dichtbij mijn interesse ligt. Ook mijn co-promotor ir. Coudron wil ik bedanken voor deinzichten van 3D en begeleiding bij het schrijven van mijn thesis. Zonder hen was van deze thesisgeen sprake geweest.

Tot slot wil ik mijn vrienden en familie bedanken die tijdens mijn academische carriere hulp bodenwaar nodig. Zij hielpen bij het nalezen van deze thesis en zonder hen zou het huidige resultaatmeer fouten hebben bevat. In het bijzonder wil ik mijn moeder Edith Vanfleteren bedanken die mijgeholpen heeft te geraken waar ik nu sta.

Timothy Callemein

v

Abstract

In deze thesis wordt onderzocht of het mogelijk is interventieploegen te assisteren met augmentedreality. De eerste stappen bestonden uit het bepalen hoe we augmented reality wilden toepassen.We hebben gebruik gemaakt van een virtual reality bril in combinatie met een RGB-D camera daterop werd gemonteerd, om augmented reality te simuleren. Nadat we beschikten over de nodigehardware, werd beslist wat we wilden visualiseren met augmented reality. Er werd besloten degebruiker toe te laten in een omgeving features te selecteren op een grondplan. Wanneer een in-terventielid vervolgens door de omgeving loopt, zal in het beeld op de bril een aanduiding zichtbaarworden, waar die features zich bevinden. Om het mogelijk te maken de omgeving te visualiserenen onze locatie te bepalen, hebben we gebruik gemaakt van een SLAM algoritme. Dit algoritmevoorziet ons van de omgeving in een 3D-kaart en onze locatie erin, door enkel data te gebruikendat afkomstig is van de RGB-D camera. De 3D-kaart vormde we om in een 2D-grondplan, waarinfeatures konden worden geplaatst. Daarna was het mogelijk om deze features te visualiseren opde virtual reality bril (Oculus DK2). Om de verschillende onderdelen onderling met elkaar te latencommuniceren hebben we gebruik gemaakt van het ROS framework.

Het resultaat van deze thesis is een werkend systeem met beperkingen. Het simuleren van aug-mented reality met een virtual reality bril en een camera brengt vertraging met zich mee. Daarnaastbeperkt Linux ons om de hardware van de Oculus volledig te benutten, ten nadele van het 3D-naar-2D algoritme. Toch is het mogelijk om de bril te gebruiken voor simpele aanduidingen.

vii

English Abstract

In this thesis contains research on how we can assist intervention teams with augmented reality.The first steps consist on determinating how we want to implement augmented reality. We’ve de-cided to use a virtual reality head mounted display with a mounted RGB-D camera to simulateaugmented reality. After we got hardware that was able to provide us with augmented reality, we’vestarted deciding what we wanted to visualize. We decided that the user will be able to place featuresin the ground plan of the environment. Then when a team member walks through the environmenthe’ll see the features in the 3D-space, on the virtual reality HMD. To make it possible to visualizethe map and our location in it, we’ve used a SLAM algoritme. This algoritm provides us of a map ofthe environment with our location in that map, with only the use of the RGB-D input. The 3D-mapwas projected into a 2D ground plan, on which it was possible to place features on. Afterwardsthese features were send to the virtual reality HMD (Oculus DK2). We used the ROS framework toallow the multiple software parts of the thesis to communicate.

The result of this thesis is a working system with some limitations. The simulation of augmentedreality through virtual reality with a RGB-D camera introduces latency. Also the limitation of Linuxto fully utilize the Oculus DK2 sensor information made the 3D-to-2D algoritm less accurate. Yetthe result was a simple system with augmented reality that shows features.

ix

Short Summary

In this thesis, proposed by the research group EAVISE, we research how we can assist interventionteams with augmented reality. The research group specilizes in implementing vision based soluti-ons for industrial problems. This thesis consists out of different parts. The HMD (’Head MountedDisplay’) to provide us of a way to use augmented reality. In combination with a RGB-D camera toprovide us with information to use in a SLAM algoritm. The SLAM algoritm will try to build a mapof the environment and provide us of our location at the same time. While the user will be able toplace features in that map that will be made visible through augmented reality.

HMD

We started by looking into different ways to implement augmented reality. Since this is a newindustry that is trying to break through. Yet there hasn’t been a lot of research done as a causeof that. The Hololens that was presented at the start of this year has just been rolling out it’sfirst versions to developers. Just as other firms that are implementing augmented reality who juststarted provided consumer models of AR HMD’s. Thus we looked for an alternative to the realaugmented reality hardware and came upon the idea of simulating it with a camera on a virtualreality HMD.

The Oculus DK2 is the second version and was released in 2014. In this thesis we chose to usethe Oculus DK2 in combination with a camera that was mounted on top of it. The images that comefrom the camera are being send to the HMD, with extra information to act as augmented reality.This introduced some challanges, because the Oculus is widely available for Windows, the supportfor Linux is minimal. Next to the limited support on Linux, there is lens distortion that needs to becompensated and latency between the camera and the Oculus to keep in account.

RGB-D

In the previous section we determinated the need of RGB images to simulate the augmented reality.One of the requirements set for this thesis was the use of a RGB-D camera, that provided depthinformation next to the usual RGB information. This to minimize the computation power neededby a computer to calculate depth out of the RGB-information. There are currently two techniquesthat provide depth and are integrated on a webcam sized device. There is structured light, wherea infrared pattern is projected into the room. While the projection reaches objects in the room,part of the reflection will be visible for the camera. By doing calculations on the deformations ofthat pattern, it is possible to estimate the depth of those objects in the room. Another technologythat provides depth is Time-of-Flight (ToF). Here a infrared sine is send into the room. Again the

xi

xii

reflection of the sine with a certain phase shift can provide us of depth information. In this thesiswe used a Depthsense DS325 and a Kinect 360. The Depthsense turned out to have a to smallrange to use in big rooms. While the Kinect had nog problem with bigger distances.

SLAM

We now posses a stream of RGB-D data that can be used to build a 3D-map. To do this we lookedinto some SLAM algoritms that use RGB-D information. SLAM basicly uses the RGB image tofind features and connects depth information to that feature. Then in the next frame it does thesame, but compares the current frame features and the previous frame features. Between bothframes will be a translation and rotation. This can be calculated out of both frames. This is calledvisual odometry, using images to calculate our position changes. Meanwile the features of bothframes are bundled into a bigger set of features that fit together and eventually form a 3D-map. Bigdifferences between SLAM algoritmes are the application, for example underwater SLAM. Whileanother difference is the processing of the loop-closure. Loop-closure is very important, because itprovides a form of error check and improvement. While mapping an area it’s likelly that we returnto the same point at one point. Yet because of errors in the sensors and calculation margins it’spossible that the 3D position is not where it’s expected to be. By computing the possible error andbacktracking it’s possible to improve the whole map.

Two algoritms fullfilled the requirements to be fast and able to map big environements with onlyRGB-D data, RGBDSLAM and RTABMAP. Yet through experimentation RTAP seemed like the beterof the two. This because the techniques used provide a real-time proces. It uses a loop-closuredetection inspired by psychology. It’s based on the basic principle that the time we spend in anarea is also an indication on how important that area is for loop-closure detection. The less timewe spend there, the less likely we’ll be there in the future. Next to the SLAM application, is thelocalization option. It’s possible to only localize yourself in the 3D map with the RTABMAP algoritm.Thus there is no need to implement another algoritm that finds our location in a map, becauseRTABMAP is able to do that. The only downside is that it uses a 3D map, instead of a 2D groundplan.

Mapping

The SLAM algoritm provides us of a 3D map, but we’re interested in the ground plan. Because on aground plan it’s possible te select points of interest or features, that can be visulized by augmentedreality. To do so we’ve developed an algoritm that makes a 2D heatmap from the 3D map, with aprojection on the xy-plane. So the more points there are in the z-axis, the higher the value on theheatmap. This because a ground plan normally shows how the structure of the area, thus the walls.A wall will have a lot of points present in the z-axis, because most walls go from the floor to theceiling. This introduces a problem when the axisses of the map don’t correspond with the actualaxisses. Making sure the first frame’s axisses correspond with the actual axisses helps. But theinformation from the gyroscoop on the Oculus would improve the result even more. Yet the supporton Linux is limited and thus no access to the gyroscoop has been provided.

xiii

Features

Once we have the ground plan it’s possible to click on the map and create features. Those featureswill then be saved into the map. When the user of the HMD’s field of view includes the feature thatis present on the map, it’ll be made visible on the HMD as an yellow beam. The beam will changein opacity the closer of futher you go from the feature. Also the width of the feature beam will varydepending on the distance between the user and the feature.

Conslusion

We can conclude that it’s possible to simulate AR with an VR HMD and a mounted camera. Butwith a little lack in user experience because of the latency. The speed of the algoritm is good, yetmoving fast may cause the algoritm to lose it’s position. So the final conclusion is that the simpleversion of the thesis may be considered achieved, while there is still room for improvement.

Inhoudsopgave

1 Situering en Doelstelling 1

2 Literatuurstudie 5

2.1 Augmented Reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 VR HMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 Video HMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.3 AR HMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.4 AR via VR implementeren . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 RGB-D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 RGB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.2 Diepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.3 Toepassingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.4 Camera’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 SLAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.1 Wat is SLAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.2 SLAM kenmerken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.3 Algoritmes om aan SLAM te doen . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.4 3D-informatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.5 Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4 ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4.1 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4.2 Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4.3 Topic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4.4 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4.5 Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 AR via VR 25

3.1 Wat simuleren en wat niet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.1 Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.2 Gezichtsveld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.3 Stereo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

xv

xvi INHOUDSOPGAVE

3.1.4 Lens Distortion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 AR-componenten in het zicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.1 Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 SLAM 33

4.1 Systeem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2 RGBDSLAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.1 Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.2 Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3 RTABMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.3.1 Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.3.2 Lokaliseren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3.3 Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5 Mapping 41

5.1 3D naar 2D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1.1 Muren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1.2 Positie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1.3 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2 Conslusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6 Conclusie 49

Lijst van figuren

1.1 Voorbeeld van AR voor Interventieploegen . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Thesis Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Assen van de bewegingssensoren aanwezig op de Oculus Rift . . . . . . . . . . . . 6

2.2 Pincushion Distortion met Oculus Lens . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Pincushion en Barrel Distortion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 AR Optica Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5 Oculus Rift DK2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.6 CMOS en CCD Principe van Litwiller Litwiller (2001) . . . . . . . . . . . . . . . . . 11

2.7 Voorbeeld Structured Light techniek Geng (2011) . . . . . . . . . . . . . . . . . . . 12

2.8 Principe Time of Flight techniek Hansard et al. (2012) . . . . . . . . . . . . . . . . . 13

2.9 SLAM algoritme verloop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.10 Cumulatieve positie error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.11 Loop-Closure principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.12 RTABMAP geheugen schema uit Labbe and Michaud (2013) . . . . . . . . . . . . . 19

2.13 Octomap voorstelling van 3D-data Wurm et al. (2010). a) 3D-voorstelling van deboomstructuur. b) Boomstructuur van de data met onderliggende punten c) Array-voorstelling van de boomstructuur . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.14 Octomap voorstelling van een tafel in 3D-data Wurm et al. (2010). . . . . . . . . . . 21

2.15 ROS Nodes, Topics, Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Gezichtsveld met verschillende Camera’s . . . . . . . . . . . . . . . . . . . . . . . 26

3.2 Oculus Rift Lens setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 Pincushion Distortion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4 Pincushion Compensation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5 Barrel Distortion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.6 Feature zichtbaar in de ruimte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.7 Feature bericht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1 RGBDSLAM op de Kamer-dataset zonder vertraging . . . . . . . . . . . . . . . . . 35

4.2 RGBDSLAM op de Kamer-dataset met vertragingsfactor 20 . . . . . . . . . . . . . 36

4.3 Procestijd RGBDSLAM zonder loop-closure . . . . . . . . . . . . . . . . . . . . . . 37

xvii

xviii LIJST VAN FIGUREN

4.4 Procestijd RGBDSLAM met loop-closure . . . . . . . . . . . . . . . . . . . . . . . 37

4.5 Procestijd RGBDSLAM Kamer dataset . . . . . . . . . . . . . . . . . . . . . . . . 38

4.6 Procestijd Detail RGBDSLAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.7 RTABMAP Kamer 3D-kaart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1 Afronden van punt coordinaten leidt tot raster vorming. . . . . . . . . . . . . . . . . 42

5.2 Het grondplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.3 Het grondplan met onze locatie en kijkrichting . . . . . . . . . . . . . . . . . . . . . 44

5.4 Een cilinder evenwijdig met de z-as dat wordt geprojecteerd op het xy-vlak. . . . . . 45

5.5 Een cilinder niet evenzijdig aan de z-as dat wordt geprojecteerd op het xy-vlak. . . . 46

5.6 Grondplan met twee features op aangeduid . . . . . . . . . . . . . . . . . . . . . . 47

Lijst van acroniemen

Acroniemen

AR Augmented RealityCCD Charge-coupled deviceCCNY City College of New YorkCMOS Complementary Metal Oxide SemiconductorDK Developer KitFOV Field of View, GezichtsveldFPS Frames per secondHMD Head Mounted DisplayHZ HertzPCL Point Cloud LibraryPPI Pixels per InchPTAM Parallel Tracking and MappingRGB-D Red Green Blue - DepthRTAB-MAP Real-Time Appearance-Based MappingSLAM Simultaneous Localization And MappingVR Virtual Reality

xix

Hoofdstuk 1

Situering en Doelstelling

Dagelijks zetten interventieploegen zich in voor de veiligheid van de samenleving. Zij komen vaakterecht in gevaarlijke situaties zoals bijvoorbeeld een brand. Met deze thesis genaamd ’Augmen-ted Reality voor interventieploegen’ onderzoeken we een visueel technologisch hulpmiddel dat hetrisico voor de hulpverleners moet verminderen.

Tijdens de eerste minuten nadat een brand uitbreekt is het belangrijk de juiste inschatting te makenvan de situatie. Waar moeten de brandweerwagens staan? Waar zijn gevaarlijke stoffen aanwe-zig? Hoe ziet het gebouw en de omgeving eruit? Dit zijn vragen dat tijdens een interventie zeersnel beantwoord moeten worden. Met het hulpmiddel dat we in deze thesis onderzoeken proberenwe daar deels op te antwoorden.

De twee grote onderdelen van deze thesis zijn het verzamelen van de informatie en het overbren-gen van die informatie. Voor dat laatste maken we gebruik van extra hardware om de informatie tevisualiseren. Aangezien het systeem eenvoudig te dragen moet zijn, hebben we gekozen voor eenAR HMD (augmented reality head mounted display), dat bijvoorbeeld in een helm kan worden inge-bouwd. AR is een techniek dat wordt gebruikt om informatie toe te voegen aan ons zicht. Daardoorkunnen we naast beelden van de omgeving ook extra informatie weergeven zoals bijvoorbeeld depositie van de hulpverlener in het gebouw.

Naast de HMD voor de visualisatie, gebruiken we een RGB-D (’Red Green Blue - Depth’) cameraom ons systeem van data te voorzien. Om RGB-D informatie te verzamelen kunnen we verschil-lende technieken en sensoren gebruiken. Daarom zullen we eerst enkele type camera’s vergelijkenom vervolgens een keuze te maken.

De focus van dit onderzoek zal voornamelijk de onbekende omgeving zijn dat we willen visualise-ren. Om informatie te verzamelen over de omgeving maken we gebruik van een algoritme dat aanSLAM doet. SLAM (simultaneous localization and mapping) is het tegelijk lokaliseren en mappenvan een omgeving. In deze thesis vergelijken we enkele SLAM algoritmes dat gebruik maken vaneen RGB-D camera.

We nemen aan dat voor de interventieploeg de omgeving onbekend is. Maar we beschikken welover een kaart van de omgeving. Deze twee onderdelen willen we aan elkaar linken zodat deomgeving bekend wordt. Een interventielid draagt het systeem dat met een RGB-D camera hetSLAM algoritme van informatie voorziet. Waarna het algoritme een deel van zijn omgeving eruit

1

2 1 Situering en Doelstelling

kan halen. Dit deel proberen we te matchen op de volledige kaart. Wanneer we een overeenkomstgevonden hebben, kunnen we de volledige kaart visualiseren op de HMD. Hierdoor wordt de om-geving voor het interventielid bekend. Wanneer we meerdere systemen aan elkaar linken kunnenwe de volledige interventieploeg en zijn locatie in kaart brengen. Ook brandblussers, nooddeurenen zelfs personen kunnen we als beter weergeven. Uiteindelijk zouden we dan kunnen evoluerennaar een volledig systeem, zoals in Figuur 1.1 zichtbaar is.

Figuur 1.1: Voorbeeld van AR voor Interventieploegen

De onderzoeksvraag dat we in deze thesis trachten te beantwoorden is: ’Hoe kan een 3D-cameragebruikt worden om augmented reality te realiseren als hulpmiddel voor interventieploegen?’ Uitdeze onderzoeksvraag destilleerden we enkele deel-onderzoeksvragen: Hoe gaan we de positiebepalen van een interventielid? Wat willen we voorzien van informatie en hoe gaan we dat projec-teren? Welke technologie is momenteel beschikbaar om dit te verwezelijken?

Deze thesis werd uitgevoerd in opdracht van de onderzoeksgroep EAVISE (Embedded Artificiallyintelligent VISion Engineering) op campus De Nayer van de KU Leuven. De focus van de onder-zoeksgroep is visiesystemen onderzoeken en ontwikkelen voor industriele problemen.

In Figuur 1.2 is een schema te zien dat als leidraad kan dienen tijdens het lezen van deze scriptie.In de figuur zijn de vier onderdelen zichtbaar, met de onderwerpen dat onderzocht werden tijdensdeze thesis. Onder RGB-D camera zijn de twee camera’s te zien dat werden gebruikt tijdens hettesten. Bij SLAM staan de twee algoritmes dat we vergeleken hebben. Daarnaast is ook te zienhoe de communicatie tussen de verschillende onderdelen gebeurt.

1 Situering en Doelstelling 3

Figuur 1.2: Thesis Schema

Hoofdstuk 2

Literatuurstudie

Deze thesis bestaat uit verschillende onderdelen dat apart onderzocht werden. Daarna lag de focusop het combineren van de verschillende onderdelen. De literatuurstudie begint met het onderzoe-ken van augmented reality (AR). Er wordt bekeken welke AR-technieken en apparaten we kunnengebruiken, waarna een deel volgt waarin de RGB-D camera’s beschreven worden. De RGB-Dcamera’s zullen gebruikt worden om informatie te verzamelen over de omgeving. De informatiedie verkregen wordt, wordt gebruikt door een SLAM-algoritme. De mogelijke algoritmes behande-len we in de volgende paragraaf. Tot slot bekijken we het ROS-framework dat al de verschillendecomponenten met elkaar laat communiceren.

2.1 Augmented Reality

2.1.1 VR HMD

Bij ’VR HMD’ staat de ’VR’ voor ’Virtual Reality’, een term die vooral in de computerspellen ge-kend is. In een computerspel zitten de spelers meestal in een andere, virtuele wereld. Om despelervaring te verbeteren, werden de spelletjes doorheen de jaren dan ook realistischer. Het isbijvoorbeeld mogelijk in het spel terug te keren in de tijd of naar de toekomst te gaan. De spelerkan dan een personage spelen dat in een andere periode leeft. De spellen worden hierdoor veelgroter en complexer.

Het verwerken van al die informatie is mogelijk doordat computers evolueerden in rekenkracht. Eris nu minder tijd nodig om iets te visualiseren dat veel meer detail geeft, dan drie jaar geleden.De software is dus doorheen de jaren sterk geevolueerd. De hardware is echter tot hiertoe steedsbeperkt gebleven, doordat het spelen nog steeds gebeurd op een scherm waarop 3D objecten opeen 2D scherm worden geprojecteerd. Met een VR HMD proberen we het spel nog realistischerte maken doordat we een illusie van 3D nabootsen. Virtual reality blijft een recentere technologie,daardoor is nog weinig onderzoek gepubliceerd met een VR HMD. Het concept is wel reeds deelsbeschreven door Burdea and Coiffet (2003).

Het HMD-gedeelte uit ’VR HMD’ staat voor Head Mounted Display. Kort gezegd betreft het duseen beeldscherm dat op het hoofd van de gebruiker staat. Het ’traditionele’ scherm op het bureauwordt vervangen door een draagbaar scherm. Dit concept bestaat al langer dan de meeste men-sen denken, maar wordt nu pas aanvaard. Vroeger waren de schermen groot, zwaar en duur. Het

5

6 2 Literatuurstudie

Tabel 2.1: Oculus Developer Kit PPI overview

Oculus Versie Jaar van uitgave PPIDK1 2012 251DK2 2014 441

dragen ervan was dus niet mogelijk zonder een blessure. Een studie in 2000 door Patrick et al.(2000) toonde aan dat een projector en scherm de kwaliteit van een HMD oversteeg. Door de jarenheen is de kwaliteit van het scherm sterk verbeterd. In Tabel 2.1 is een overzicht te zien van tweeHMD’s geproduceerd door Oculus, de DK1 en de DK2 (’Developer Kit’), met hun jaar van uitgaveen PPI (’Pixels per Inch’). We kunnen afleiden dat in twee jaar tijd de schermen bijna verdubbeldzijn in PPI, een verbetering in kwaliteit.

Een apparaat met schermen is niet voldoende om een ’virtuele realiteit’ te maken. Het zou immersinhouden dat de persoon van dichtbij kijkt op een scherm, zonder meer. Zonder aanvullingen is ditniet veel verschil met het gewone scherm. Met het oog op een meer realistische ervaring werdensensoren toegevoegd aan de VR HMD’s. Enkele mogelijke sensoren die in een VR HMD-toestelkunnen zitten zijn onder andere een 3-assen-gyroscoop, een versnellingsmeter en een magneto-meter. In Figuur 2.1 is te zien in welke informatie de sensoren van de Oculus DK2 voorzien. Dezeinformatie is te vinden hoe ons hoofd georienteerd is. Als we recht voor ons kijken, richting hetnoorden, zijn alle sensorwaardes zeer laag. Van zodra we het hoofd draaien, zullen de de waardenwijzigen. In een computerspel wordt meestal een muis gebruikt om rond te kijken in de virtuelewereld. De ingebouwde sensoren in de HMD kunnen de muis vervangen. Ze laten de gebruikertoe rond te kijken zoals we dat gewoon zijn in de echte wereld. Dit zorgt voor een realistischergevoel terwijl we rondkijken.

Figuur 2.1: Assen van de bewegingssensoren aanwezig op de Oculus Rift

Tijdens het maken van de HMD was het draagcomfort een groot werkpunt. Het is namelijk debedoeling dat de HMD langdurig gedragen kan worden. Hierdoor werd rekening gehouden met hetgewicht van het toestel. Daarnaast werd het comfort van de ogen ook bestudeerd. Bij het dragenvan de HMD, wordt ons zicht immers volledig vervangen door een scherm, waardoor ons normalezicht op dat moment beperkt wordt. Om een goede ervaring van VR te hebben, zou een grootscherm met veel detail nodig zijn om de realiteit na te bootsen. Een groot scherm weegt echterveel en zou te zwaar worden om te dragen. Daarom zijn optische lenzen aanwezig tussen onzeogen en het scherm. De eigenschappen van de lenzen zorgen ervoor dat we de illusie ervarente kijken op een groot scherm. Het gebruik van lenzen heeft wel een nadeel: ze zorgen voor


vervormingen van het beeld.

In realiteit zijn de cellen van het raster in Figuur 2.2 even hoog en even breed. Door de lenzen zijnde lijnen echter vervormd. Deze vervorming willen we graag wegwerken, zodat de verhoudingen inhet beeld correct zijn. Om dit effect weg te werken, moeten de beelden anders weergegeven wor-den. De vervorming die veroorzaakt wordt door de lenzen wordt ’pincushion distortion’ genoemd of’speldenkussenvervorming’. Op Figuur 2.3 staan twee rasters met een bepaalde vervorming. Hetlinkse raster visualiseert een mogelijke speldenkussenvervorming.

Er wordt eerste een omgekeerde vervorming toegevoegd aan het beeld, waarna de lenzen hetbeeld zullen vervormen tot het beeld dat we oorspronkelijk wilden weergeven. De omgekeerdevervorming staat rechts op Figuur 2.3 en wordt ’Barrel Distortion’ genoemd. De beelden die nuworden geprojecteerd zullen dus eerst een distortie in de software krijgen, gevolgd door een inversedistortie door de lenzen. Dit zal er voor zorgen dat de beelden correct worden weergegeven.

Figuur 2.2: Pincushion Distortion met Oculus Lens

Figuur 2.3: Pincushion en Barrel Distortion

2.1.2 Video HMD

Naast de VR HMD’s bestaan er ook gewone video HMD’s die sterk lijken op VR HMD’s. Toch ziter belangrijk verschil tussen: VR HMD’s zijn speciaal ontwikkeld om ons in een virtuele realiteitte laten rondlopen, terwijl video HMD’s ontwikkeld zijn om video’s te bekijken. Ze bevatten netals de VR HMD een beeldscherm met lenzen, maar zonder de sensoren. Er moet immers enkelgekeken worden naar video, bijvoorbeeld een film, waardoor de sensoren overbodig zijn. Doordatde doelgroep beperkt is, werden deze brillen niet zo vaak verkocht. Het is per slot van rekeninggezelliger om met meerdere mensen samen naar een film op een scherm te kijken dan alleen.


Ondertussen zijn er eveneens filmproducenten die interesse getoond hebben in films specifiek vooreen VR HMD. In die films zou de kijker kunnen rondkijken in de wereld waarin de film zich afspeelt,wat de kijker de ultieme filmbeleving biedt. Om de hoofdbeweging van de kijker te kunnen volgen,zijn dan wel sensoren nodig. Die sensoren zitten al in VR HMD’s, waardoor een nieuw soort filmwordt geproduceerd. VR films waarin je het gevoel hebt een rol te spelen in de film.

2.1.3 AR HMD

We hebben in de vorige paragraaf gezien dat het met een VR HMD mogelijk is in een andereomgeving aanwezig te zijn. Wanneer we de omgeving willen gebruiken en aanvullen met virtueleobjecten is een andere soort HMD nodig. In plaats van VR is bestaat er ook ’AR’, of ’AugmentedReality’ (’uitgebreide realiteit’). In het VR-hoofdstuk werd gezegd dat dat een volledig nieuwe reali-teit wordt gevisualiseerd. Dit is bij AR niet het geval,we kunnen de omgeving zien en breiden die uitmet extra informatie. Om dit te kunnen doen is een ander soort HMD nodig dan bij VR. Een HMDwaar geen schermen met lenzen ertussen voor de ogen worden geplaatst, maar met een speciaalglas voor onze ogen, waarop we dingen kunnen projecteren.

Een van de fabrikanten dat bezig is met AR is Microsoft met de ontwikkeling van de ’Hololens’.Er wordt gebruik gemaakt van een projector die gericht op een speciaal glas. De geprojecteerdebeelden worden dan via het glas getransporteerd naar het glas dat zich voor de ogen bevindt. Daarzijn lenzen aanwezig die het beeld vergroten en in ons zicht projecteren. Een dergelijke techniek iszichtbaar op Figuur 2.4. We zien dat aan beide kanten van het hoofd kleine projectoren geplaatstworden. Het glas direct na de projector is een lens dat de beelden fixeert, waarna het door eengolfgeleider naar het zocht wordt gebracht en weergegeven. De golfgeleider heeft een dubbelewerking, enerzijds moet het een deel van het licht in de omgeving onvervormd zichtbaar maken.Daarnaast moet het extra licht informatie kunnen toevoegen afkomstig van een projector. Beidebronnen van licht worden dan gebundeld en geprojecteerd op de ogen van de gebruiker.

Figuur 2.4: AR Optica Principe


2.1.4 AR via VR implementeren

Voor deze thesis zou het gebruik een AR HMD aangewezen zijn. Aangezien de Microsoft en ookandere bedrijven nog maar net bezig zijn met de ontwikkeling van de AR HMD’s, werd besloten omin huidige toepassing geen gebruik te maken van een AR HMD. In plaats daarvan kiezen we ervoorom een VR HMD te gebruiken die beelden van een RGB-D camera weergeeft. Hierdoor hebbenwe ook een AR met een VR HMD en een camera.

Er werd voor deze thesis gekozen voor de Oculus Rift DK2, zichtbaar op Figuur 2.5. Een volledigebeschrijving van de hardware is te vinden in Desai et al. (2014), hier worden de verschillen tussende DK1 en DK2 duidelijker. Aan deze VR HMD is de fabrikant al geruime tijd bezig met ontwikkelen.Hierdoor kent deze versie al verschillende verbeteringen, want de vorige versie kon al door heel watontwikkelaars getest worden. De feedback van ontwikkelaars werd bij de tweede versie ingebracht,met de DK2 als gevolg. Het was bij de start van deze thesis het enige toestel dat momenteel inruime hoeveelheden aanwezig is en stabiel draait. Ook heeft het toestel al een ruime communityter ondersteuning. Een groot nadeel is het gebrek aan een echte Linux implementatie. Dit komtdoordat VR HMD’s gericht zijn op computerspellen en op vlak van computerspellen is Windows vanMicrosoft populairder. Dit heeft als gevolg dat bijna alle ondersteuning voor VR HMD’s eerst voorWindows komt en pas erna voor Linux.

Figuur 2.5: Oculus Rift DK2

2.2 RGB-D

Aangezien we gebruik willen maken van een VR HMD, moeten we een camera gebruiken. Inplaats van een gewone RGB-camera, wordt gebruik gemaakt van een RGB-D camera. De termRGB-D is de afkorting van ’Red Green Blue - Depth’ (’Rood Groen Blauw - Diepte’). Naast hetkleurenbeeld voorziet de camera dus ook diepte-informatie. Die diepte stelt de aftand tussen decamera en een plaats in het beeld voor. De diepte-informatie is nodig om het SLAM algoritme teontlasten van rekenvermogen. Het SLAM onderdeel komt aan bod in de volgende paragraaf. Indeze paragraaf halen we kort aan hoe de RGB-beelden verkregen worden, via CMOS of CCD.Daarna kijken we naar manieren om de diepte-informatie te verkrijgen. Enkele toepassingen vaneen RGB-D camera volgen hierop. Tot slot bekijken we kort een overzicht van enkele camera’s,de Depthsense DS325 en Kinect 360 in het bijzonder. Het doel is dit apparaat op de VR HMD temonteren, om zo beeldinformatie te voorzien om AR te verkrijgen. Dus de grote en het gewicht


moeten we beperkt houden.

2.2.1 RGB

Om RGB-beelden op te vangen zijn er twee manieren: CMOS (’Complementary Metal Oxide Se-miconductor’) en CCD (’Charge-coupled device’). Het fundamentele verschil tussen de CMOS enCCD is de manier waarop de beeldinformatie van de lichtgevoelige cellen gehaald wordt. Beidemanieren hebben voordelen en nadelen. Bij CCD wordt via een overloopsysteem de informatievan de lichtgevoelige cellen doorgeschoven. Dit terwijl de cellen nog altijd gevoelig zijn aan licht endus informatie toevoegen bij het overlopen van cel. Terwijl bij CMOS elke cel apart toegankelijk isvia een array systeem van transistoren. Het voordeel bij CCD is dat de cellen zeer dicht bij elkaarkunnen staan, terwijl bij CMOS transistoren rondom de cellen nodig zijn. In een vergelijking vanLitwiller (2001) wordt in detail het verschil uitgelegd. Uit de paper kunnen we halen dat CMOSde voordelen van CCD ook nastreeft en zelfs bereikt. Hierdoor worden de nadelen van CMOSingeperkt en wordt er meer voor CMOS gekozen. In Figuur 2.6 staan beide manieren in blokkenonderverdeeld, bovenaan staat CCD en onderaan wordt CMOS afgebeeld.

2.2.2 Diepte

Naast de kleureninformatie willen we ook de diepte van onze omgeving achterhalen. Dit kan opverschillende manieren verkregen worden. In de volgende paragrafen komen enkele technologieenaan bod met de focus op een compact apparaat.

Stereo beeld

Bijna iedereen beschikt over een ’dieptemeter’, namelijk onze ogen. Doordat we twee ogen hebbendie op een bepaalde vaste afstand staan ten opzichte van elkaar, kunnen we de diepte inschatten.Een geoefend oog kan dit zeer precies. Iedereen kan het verschil in afstand tussen een voorwerpdicht of ver maken, doordat we vanuit twee perspectieven kijken naar hetzelfde object. De herse-nen verwerken beide perspectieven en kunnen daaruit een diepte halen.

Hetzelfde principe kan toegepast worden op een computer om 3D-informatie te verkrijgen. Tweecamera’s, op een vaste afstand van elkaar. Die beelden worden gebruikt om berekeningen opte maken. Eerst wordt gezocht naar ’unieke features’. Diezelfde features zijn te vinden op beidebeelden en corresponderen met elkaar. Door deze correspondenties te gebruiken, samen met deverschuivingen op elk beeld, verkrijgen we diepte-informatie.

Een nadeel is dat deze techniek veel rekenkracht nodig heeft. Daarnaast werkt het niet zondervoldoende features in het beeld. De features worden gebruikt als correspondentie in de tweebeelden. Die correspondenties worden aan elkaar gekoppeld om de berekeningen te kunnen doen.Wanneer er te weinig correspondenties aanwezig zijn, zal dit ervoor zorgen dat de foutmarge groteris. Het gebrek aan features komt bijvoorbeeld voor op een witte egale muur. Op die muur zijn weinigfeatures te vinden, maar wanneer we naar een tafel kijken, vinden we hoeken, kleurovergangenen misschien een uniek patroon terug. Deze features zijn uniek aan de tafel en zijn gemakkelijkterug te vinden in meerdere beelden. Die informatie verwerken neemt natuurlijk wel tijd in beslag.


Figuur 2.6: CMOS en CCD Principe van Litwiller Litwiller (2001)

Daarnaast streven we naar een compact apparaat terwijl deze techniek minstens twee camera’snodig heeft. Dit is nog een extra nadeel en daarom kijken we liever naar een alternatief.

Structured light

Een mogelijk alternatief is ’structured light’. Bij structured light wordt gebruik gemaakt van een ge-controleerd lichtpatroon. Dit patroon wordt geprojecteerd op de ruimte waarnaar de camera kijkt.Vervolgens bekijken we met de camera vanuit een ander standpunt naar de projectie in het beeld.Aan de hand van de vervormingen die de camera ziet in het patroon, kan een diepteberekeningworden gemaakt. Deze berekening is eenvoudig en neemt minder tijd in beslag dan het zoekennaar features en correspondenties.

Een voorbeeld van deze techniek is zichtbaar in Figuur 2.7. Hierop is te zien hoe een patroonwordt geprojecteerd op een object. Wanneer in een object diepteverschillen zijn, zal het patroon


vervormen. Door deze vervorming te bekijken, is het mogelijk de diepte informatie te berekenen.Dit patroon is meestal niet statisch, maar kunnen we veranderen terwijl we ernaar kijken. Zohebben we meerdere patronen en vervormingen om berekeningen op te doen. De techniek wordtvaak toegepast om diepte te verkrijgen. Een volledige beschrijving van deze techniek is zichtbaarin de tekst geschreven door Geng (2011). Een voordeel van structured light is de stabiliteit van dediepte informatie. De vervormingen zijn licht onderhevig aan ruis, maar dit heeft slechts een kleineinvloed op het resultaat. Het nadeel is dat voor grote afstanden meestal veel energie nodig is omhet patroon te projecteren. Ook is het niet mogelijk reflecterende objecten te meten.

Figuur 2.7: Voorbeeld Structured Light techniek Geng (2011)

TOF

Een andere en recentere techniek om diepte-informatie te verkrijgen is ToF (’Time-of-Flight’). Dezetechniek lijkt zeer sterk op de techniek die toegepast wordt bij een radar, waarbij een elektrischsignaal de lucht in wordt gestuurd. Dit signaal kan bijvoorbeeld tegen een vliegtuig botsen en ge-deeltelijk reflecteren naar de oorsprong. Door de reflectie te analyseren kan de afgelegde afstandberekend worden. Bij ToF passen we dit ook toe. Er wordt dus, net als bij structured light, eenlichtsignaal gestuurd. In tegenstelling tot structured light is het signaal geen patroon, maar eensinus. Tegelijk met het projecteren van de sinus, wordt ook het beeld bekeken en gesampled.

In het gesampled beeld vinden we het sinussignaal terug, hetwelk een faseverschuiving heeft door-dat er diepteverschillen aanwezig zijn in het beeld. Een object dat dichtbij is, zal het licht snellerterugsturen, dan een object dat ver is. Om de diepte-informatie te verkrijgen moeten we dus kijkennaar de faseverschuivingen. Dit gecombineerd met enkele berekeningen bezorgt ons de diepte.In Figuur 2.8 wordt een sinus (rood) naar een object gestuurd. Dit signaal wordt voor een deelgeabsorbeerd en gereflecteerd (blauwe sinus). Door te kijken naar de faseverschuiving van hetblauwe signaal, ten opzichte van het rode signaal, kunnen we de diepte berekenen. Deze data iswel afhankelijk van diverse factoren en vaak is een aanpassing op het beeld nodig, zoals beschre-ven door Hansard et al. (2012).

Een voordeel van ToF is de kleine rekenkracht die nodig is om een diepte te verkrijgen. Het grotenadeel is dat voor grote afstanden veel meer energie nodig is, dan bij structured light. Het licht isveel gevoeliger aan ruis en zal veel meer schommelen.


Figuur 2.8: Principe Time of Flight techniek Hansard et al. (2012)

2.2.3 Toepassingen

Een RGB-camera komt vaak voor en heeft tegenwoordig bijna iedereen op zak, in de smartphone.Ook laptops en de meeste beveiligingssystemen worden voorzien van camera’s. Hier is wel noggeen diepte-informatie bij nodig. Toch kent ook een RGB-D-camera verschillende toepassingen,die geleidelijk aan tot de consument komen. Bijvoorbeeld een auto die door handbewegingenkan worden bediend, momenteel onderzocht door Ohn-Bar and Trivedi (2014). Daarnaast zorgt decompactheid ervoor dat ze kunnen worden ingezet om drones autonoom te laten vliegen, toegepastdoor Huang et al. (2011). Verder zijn er diverse toepassingen in de robotica.

2.2.4 Camera’s

Er bestaan dus meerdere technologieen om een dieptebeeld te verkrijgen. In dit onderzoek werdvooropgesteld geen gebruik te maken van meerdere camera’s, dus de keuze ligt bij Structured Lightof Time of Flight camera’s. In de Tabel 2.2 staat een overzicht van veel gebruikte camera’s met huneigenschappen. Recentere camera’s maken vaker gebruik van ToF. In het labo van EAVISE wasde DepthSense DS325 aanwezig. We gaan dus kijken om hiermee te werken. Maar we kijken ooknaar de Kinect 360 die een groter bereik heeft en met Structured light werkt. In de tabel 2.2 zienwe dat de Kinect de zwaarste is. De Asus Xtion pro Live is veel lichter dan de Kinect en maaktgebruik van dezelfde chip als de Kinect, maar is niet meer beschikbaar. Daarom gebruiken we ookde Kinect, om de werking te vergelijken met dat van een ToF camera.

Camera Type Gewicht Resolutie BereikKinect 360 Structured Light 1,4 Kg RGB - SXGA / D - QVGA 50 cm - 5 mKinect One ToF 1,37 Kg RGB - 1080p / D - 512x424 40cm - 4,7 mAsus Xtion pro Live Structured Light 0,22 Kg RGB - SXGA / D - VGA 80 cm - 3,5 mCreative Senz3D ToF 0,27 Kg RGB - HD 720p / D - QVGA 15 cm - 99 cmDepthsense DS325 ToF 0,24 Kg RGB - HD 720p / D - QVGA 15 cm - 99 cm

Tabel 2.2: Overzicht van camera’s


2.3 SLAM

Zoals in de inleiding vermeld werd, wil deze thesis de onbekende omgeving visualiseren. Hiervoormoet de onbekende omgeving eerst verkend worden. Als we doormiddel van een algoritme in staatzijn een klein gedeelte van de omgeving te kennen. Dan kunnen we dat klein gedeelte proberente vinden in het grondplan dat voorzien is. In deze paragraaf worden de principes van SLAMoverlopen. Daarna bekijken we enkele SLAM algoritmes die momenteel beschikbaar zijn.

2.3.1 Wat is SLAM

SLAM staat voor ’Simultaneous Localization and Mapping’ (’Tegelijk Lokaliseren en Mappen’). EenSLAM-algoritme zal met andere woorden de omgeving in kaart brengen en tegelijk berekenen waarwij ons bevinden in die omgeving. Er kan op verschillende manieren een SLAM implementatiegerealiseerd worden, want het is een manier van denken, niet een algoritme op zich. In Figuur 2.9is een voorbeeld verloop te zien van een SLAM algoritme. In het begin beschikken we over weiniginformatie, maar uiteindelijk komt de kaart duidelijk in beeld.

Figuur 2.9: SLAM algoritme verloop

2.3.2 SLAM kenmerken

Het doel van SLAM-algoritmes is het voorzien van een kaart van de omgeving en onze locatie indeze map. Om dat te kunnen berekenen hebben de algoritmes informatie nodig van de omge-ving dat wordt verzameld door sensoren. De sensor keuze hangt deels af van de toepassing. Detoestands-en de afstandsinformatie zijn meestal een onderdeel van een SLAM-algoritme. Daar-naast is er meestal een vorm van ’loop-closure detectie’ aanwezig. De drie onderdelen worden inde volgende paragrafen verder uitgelegd.


Toestandsinformatie

Wanneer we ons verplaatsen in een ruimte hebben we een bepaalde stapgrootte en ook eenorientatie in de ruimte. Dit kan gemeten worden aan de hand van twee sensoren: een gryro-scoop kan onze verdraaiing ten opzichte van de aarde meten, terwijl wiel-encoders de afstand vande robotwielen kan meten. Dit wordt ook ’odometrie’ genoemd. Daarnaast kunnen we ook gebruikmaken van ’GPS’ of de Europese variant ’Galileo’ om onze toestand of positie te bepalen.

Met het oog op de toekomst hebben we gekozen het systeem te bouwen op een linux besturings-systeem. Dit belemmert ons wel de Oculus HMD gyroscoop te gebruiken, omdat het frameworkvoor linux nog in ontwikkeling is en de informatie niet toegankelijk is. Daarnaast heeft de fabrikantvan de Oculus ervoor gekozen de ontwikkeling van de SDK te onderbreken voor onbepaalde tijd.

Afstandsinformatie

Naast de toestandsinformatie is ook een afstandsmeting nodig. Het is namelijk niet voldoende omenkel de positie of orientatie te kennen, maar ook meer informatie over de omgeving zelf. Hiervoorhebben we nood aan bepaalde sensoren, anders moeten we de de ruimte aftasten. Er bestaanverschillende manieren en sensoren die ons kunnen voorzien van afstandsinformatie of diepteinformatie in de omgeving. Enkele technieken die reeds in paragraaf 2.2 werden aangehaald zijnToF en Structured light. Daarnaast bestaat ook ’Lidar’, dat door middel van een laserpunt en dereflectie ervan een afstand kan berekenen. Ook een sonar of radar kan worden gebruikt, afhankelijkvan de toepassing. In deze thesis werd beslist om ons enkel te baseren op visuele informatie,bijvoorbeeld met een RGB-D camera. Dit beperkt ons tot een bepaald aantal technieken. In devolgende paragraaf zullen we de verschillende algoritmes die gebruik maken van RGB-D overlopenen een keuze maken.

Loop-Closure

SLAM algoritmes trachten een kaart op te bouwen vanuit informatie die werd verzameld van sen-soren. Doordat sensoren ook ruis detecteren en zelf ook een bepaalde foutmarge bevatten kunnenfouten worden gemaakt bij het bouwen van de kaart. Een fout van 1cm bij een RGB-D camera-beeld, in een ruimte van 3m bij 4m lijkt op het eerste zicht onschuldig, maar wanneer verschillendeframes gecombineerd worden met een foute frame als referentie, cumuleert de fout. Dit is te zienin Figuur 2.10 waarop een groene lijn te zien is met de normale looprichting. Doordat we onszelfpositioneren ten opzichte van het huidige frame en de huidige positie, zal een fout mee groeien.Na 100 frames kan een fout van 1cm gegroeid zijn naar een fout van 1m.

Ook de hoeken kunnen veranderen in een ruimte, waardoor de uiteindelijke positie volledig ver-keerd is. In Figuur 2.11 zijn twee positiegrafieken getekend, de juiste in het groen, de geschattedoor het algoritme in het rood. Wanneer we uiteindelijk rondom zijn gegaan en terug eindigen bijde beginpositie, detecteren we een ’loop-closure’. De posities komen echter niet overeen, als ge-volg van fouten door sensoren en afrondingen in het algoritme. Omdat we de juiste positie kennenkan wel terug gekeken worden naar de fout en eventueel een rechtzetting gebeuren. Doordat alde punten relatief van elkaar werden opgebouwd zal de volledige rode lijn dichterbij de groene lijnkomen te staan en derhalve correcter zijn.

Samengevat is een ’loop-closure’ het terugkeren naar een eerder bezochte locatie in de omge-


ving. Doordat we een verschil in locatie waarnemen in de opgebouwde kaart kan er een correctieuitvoeren op alle punten die gebruikt werden om de kaart op te bouwen.

Een groot nadeel aan loop-closure is dat het rekenintensief is om een overeenkomst te vinden. Eencomputer kan niet weten dat de groene cirkel en rode cirkel op Figuur 2.11 dezelfde zijn, zonderbeide frames te nemen en ze te vergelijken. Toch wordt nog gezocht naar een optimale manier omdit te detecteren, ook aan 30 fps camera informatie.

Figuur 2.10: Cumulatieve positie error

Figuur 2.11: Loop-Closure principe

2.3.3 Algoritmes om aan SLAM te doen

Momenteel zijn er verschillende SLAM-algoritmes beschikbaar. Een verschil tussen de algoritmeswordt onder andere bepaald door de input gegevens die ze gebruiken om SLAM toe te passen.Nog een factor is de omgeving waarvan het algoritme een kaart moet opbouwen, bijvoorbeeld deoceaan waar sonar mogelijk is. Een SLAM algoritme maakt onder andere gebruik van afstandsen toestands informatie met een loop-closure detectie om fouten te corrigeren. Daaruit volgt dater verschillende algoritmes ontwikkeld zijn dat gebruik maken van deze technieken. In deze thesiswillen we enkel de algoritmes bestuderen dat gebruik maken van een RGB-D camera. We gaandus geen gebruik maken van odometrie-sensoren, maar van visuele odometrie berekent uit de ca-mera beelden. Visuele odometrie zoals beschreven in Scaramuzza and Fraundorfer (2011) vraagtextra rekenvermogen, maar omdat het systeem draagbaar moet zijn voor mensen, zijn er weinigalternatieven. Enkele SLAM-algoritmes die enkel visuele informatie gebruiken komen aanbod in devolgende paragrafen. Op http://www.openslam.org staan echter nog meer SLAM-frameworks en-algoritmes te vinden.


PTAM - SLAM

PTAM SLAM staat voor ’Parallel Tracking and Mapping’ en is vooral bedoeld om de locatie vande camera te vinden in een kleine omgeving. Het algoritme werd voorgesteld door Klein andMurray (2007). Ze maken enkel gebruik van RGB-camerabeelden. Het algoritme neemt tweeachtereenvolgende beelden en berekent van elk beeld de features. Het lijkt op de manier om dediepte te achterhalen met stereo camera’s, maar hier gaat men er van uit dat de twee beelden directachter elkaar worden genomen. Tussen deze twee beelden wordt de verplaatsing gezocht. Tijdensdit proces wordt gekeken naar de beelden en wordt berekend of het huidige beeld een nieuw keyframe 1 is. Indien het een bestaand key frame is, zal extra stereo-informatie worden toegevoegdaan het key frame. Wanneer het beeld veel nieuwe features bevat, zal het een nieuw key frameopbouwen. Door de key frames samen te nemen, bekomen we een map van de omgeving. Door deinformatie die we binnenkrijgen, kunnen we ons lokaliseren ten opzichte van de key frames en ookbepalen op welke key frame we ons bevinden. Dit is een algoritme dat gebruik maakt van een uniekconcept, maar sterk afhankelijk is van features. Een nadeel is dat veel rekenwerk en beeldanalysenodig is om diepte te herkennen. Toch is door een afsplitsing van mapping en tracking een real-time werking van het algoritme. Daarnaast is het algoritme gemaakt voor kleine omgevingen, nietvoor grote omgevingen, waarvoor wij een SLAM-algoritme willen gebruiken. We zoeken naar eenalgoritme dat ook in staat is om grote kaarten te kunnen opbouwen. Aangezien PTAM - SLAM hierniet toe in staat is, is het niet geschikt om te gebruiken in deze thesis.

LSD - SLAM

LSD-SLAM staat voor ’Large Scale Direct’- SLAM, of ’Directe op grote schaal’-SLAM. De LSDstaat niet voor een specifiek algoritme, maar voegt een kenmerk toe. Momenteel zijn er meerdereLSD-SLAM algoritmes beschreven. Een voorbeeld hiervan is een stereocamera implementatieLSD-SLAM algoritme door Engel et al. (2015). De hardware binnen deze thesis willen we be-perken tot een enkele RGB-D camera, terwijl er bij stereo twee camera’s nodig zijn. Een andervoorbeeld is ’Direct Monocular SLAM’, zoals beschreven in een paper door Engel et al. (2014). Ditalgoritme bouwt verder op de principes en werkwijze van PTAM-SLAM met enkel RGB als input.Daarnaast beantwoordt het aan de vraag om grotere omgevingen te kunnen verwerken. Toch is ernet zoals bij PTAM meer rekenkracht nodig om de diepte betrouwbaar te berekenen. Omdat hetalgoritme gebruik nog steeds meerdere RGB beelden gebruit om de diepte te berekenen. Er werdtoorspronkelijk gekozen om met een RGB-D camera te werken. De extra hardware die aanwezigis op dergelijke camera vermindert de gevraagde rekenkracht en bezorgt ons alsnog betrouwbarediepte informatie.

CCNY

Het CCNY (’City College of New York’) heeft een algoritme ontwikkeld dat ook gebruik maakt vaneen RGB-D camera en staat beschreven in Dryanovski et al. (2013). Uit de 2D-RGB-beeldenworden features gehaald en samen met de informatie van het diepte beeld wordt een 3D-beeldgevormd. Dit 3D-beeld wordt daarna vergeleken met de volledige 3D-kaart. Wanneer voldoendefeatures matchen tussen het beeld en de 3D kaart, zal het beeld toegevoegd worden op die plaats.

1Een key frame is in deze context een frame dat bijna uniek is in de omgeving. Een foto van een huis of eenappartement zal op veel vlakken verschillen. Terwijl een foto van 2 verschillende ramen van een appartement minderuniek zijn. Ergens zal een grens liggen tussen hetzelfde frame als een key frame of een key frame op zich.


De map met de nieuwe feature data zal vervolgens de nieuwe volledige map worden en het procesherhaalt zich vanaf het begin. Om de features te matchen wordt gebruik gemaakt van Gaussiansemodellen en de Kalman-filter Kalman (1960). Tijdens het ontwikkelen van het algoritme werd defocus gelegd op een verwerking van beelden aan minimum 30 Hz. De frequentie werd afgestemdop die van de camera, 30 fps. In kleine omgevingen zou de 30 Hz geen probleem zijn en zonderGPU gerund kunnen worden, dit op een single thread van een gewone desktop. Alhoewel hetalgoritme snel werkt in kleine ruimtes, zoeken we voor deze thesis een algoritme die ook groteomgevingen snel kan mappen. Dit algoritme voldoet door de beperking in omgevingsomvang nietaan de eisen.

DVO

Bij DVO dat werd voorgesteld door Kerl et al. (2013), wordt gebruik gemaakt van RGB-beeldendat om worden gezet naar grijswaarde-beelden. Daaraan wordt vervolgens diepte informatie ge-koppeld om een 3D-beeld te bouwen. Daarna wordt het huidige beelde met de grijswaarden ge-matched in de volledige 3D-kaart. Deze manier verschilt met de andere algoritmes omdat het nietgebruik maakt van features maar van volledige frame vergelijkingen.

RGB-D SLAM

We zijn op zoek naar algoritmes dat volledig gebruik maken van een RGB-D camera en geschiktzijn om grote ruimtes te mappen. Het algoritme voorgesteld door Endres et al. (2014) voldoet aandeze citeria. De focus bij dit algoritme is de positie van de camera in de 3D-kaart. Vandaar wordtinformatie vergeleken en eventueel toegevoegd aan de 3D-map. Net zoals bij de andere algoritmesmaakt het gebruik van visuele odometrie met RANSAC om features te vergelijken. De basiswerkingvan het algoritme lijkt zeer sterk op dat van LSD-SLAM, met het verschil dat het verwerken van dediepte wordt overgelaten aan de RGB-D camera waaruit een diepte gehaald wordt. In de paperstaat dat bij grote ruimtes (3256 frames) zonder loop detectie, een verwerkingssnelheid van 6 Hzgehaald werd. Dit is op het eerste zicht niet zo snel, maar zeker een algoritme om te vergelijkenmet het volgende algoritme.

RTAB-MAP

Nog een algoritme dat met een RGB-D camera werkt, is het RTAB-MAP (Real-Time Appearance-Based Mapping) algoritme beschreven in Labbe and Michaud (2014). Het implementeert de basis-principes van de bovenstaande algoritmes en verschilt vooral in de afhandeling van loop-closurezoals beschreven door Labbe and Michaud (2013). Bij de vorige algoritmes werden de key frameswillekeurig geselecteerd en gecontroleerd op een overeenkomst met het huidige frame. Terwijl bijRTAB-MAP het zoeken niet willekeurig verloopt, maar gebaseerd op gespendeerde tijd op een be-paalde locatie. Tijdens het ontwikkelen van het algoritme stond real-time centraal en werd gezochtnaar performantie. Veel tijd gaat immers verloren aan de detectie naar loop-closure. Vooral omdater niet doelgericht wordt gezocht naar een loop-closure. Bij het ontwikkelen van RTABMAP hebbenze dit proberen te minimaliseren. Eerst werd gekeken hoe mensen een omgeving in kaart brengenen onszelf erin lokaliseren. Uiteindelijk bleek uit psychologisch werk (door Atkinson and Shiffrin(1968) en Baddeley (1997) ) dat de hoeveelheid tijd die we spenderen op een bepaalde plaats eengrote factor is. De kans is groter dat we aanwezig zijn in een ruimte waar we reeds veel tijd inhebben doorgebracht.


Om deze manier van herkennen te implementeren in RTABMAP werd gekozen om met een werkgeheugen te werken, met daarnaast een lang termijn geheugen waar de kans klein is op een loop-closure. In Figuur 2.12 is een schema te zien met daarop de voorstelling van geheugens. Webeschikken dus over een afbeelding dat in het sensor geheugen terecht komt. Daarna in het kortetermijn geheugen, als buffer om features op te vinden. Dit frame wordt daarnaast ook vergelekenmet key frames uit het werkgeheugen. Wanneer een frame in het werkgeheugen niet vaak wordtgematched, transfereren we het naar het lange termijn geheugen. Wanneer een bepaalde keyframe in het werkgeheugen wordt gematched, zullen naburige frames uit het lange termijn geheu-gen worden gehaald. De kans is groter dat daar ook een loop-closure mee zal worden gevormd. Zozorgt het algoritme ervoor dat er altijd een beperkt werk geheugen is waarin gekeken moet worden.

Figuur 2.12: RTABMAP geheugen schema uit Labbe and Michaud (2013)

Naast de controle van loop-closure gecombineerd met de tijd we in een ruimte spenderen, is er ookeen tijdslimiet opgesteld. Dit is er om toch snel genoeg te kunnen werken en de tijd dat het algo-ritme gebruikt om te zoeken naar een loop-closure te limiteren. Het algoritme is zo opgebouwd datwanneer het tussen frames geen match heeft gevonden, het zal stoppen met zoeken en dat frametransfereren naar het lange termijn geheugen. De tijd die werd gehanteerd tijdens de experimentenin de paper was 0,7 seconden.

De focus ligt voornamelijk op real-time toepassingen, dit gecombineerd met grote omgevingenzorgt voor veel uitdagingen. In een poging om dit aan te pakken werd de werkwijze van mensenbestudeerd om grote omgevingen te mappen. Om snel een omgeving te doorzoeken, kunnenmeerdere mensen helpen bij verkennen van de omgeving. Dit principe werd ook in het algoritmeingewerkt. Het is dus mogelijk met meerdere bronnen een kaart op te bouwen, waarna de datavan de verschillende deel kaarten kan worden samengebracht tot een globale kaart. Dit maakthet mogelijk om aan elk verschillend lid een scan te laten doen van een deel, waarna door kaar-optimalisatie al de informatie voor de volledige ploeg beschikbaar wordt. Naast leden van de ploegkunnen bijvoorbeeld ook drones worden ingeschakeld om de omgeving deels in kaart te brengen.Daarnaast is het niet verplicht om enkel met een RGB-D camera te werken. Stereo camerabeeldenen odometrie kunnen ook worden gebruikt als input.

Samengevat is dit een goed algoritme om mee aan de slag te gaan. Het is mogelijk om meerdere


delen van een grote omgeving samen te brengen tot een groot geheel. Met het gebruik van eenRGB-D camera, maar ook andere sensor soorten. Dit algoritme zullen we dan ook zeker testen inhet kader van deze thesis.

2.3.4 3D-informatie

Een SLAM-algoritme kan op verschillende manieren worden toegepast en met verschillende soor-ten data worden uitgevoerd. Toch is een vereiste van een SLAM-algoritme het opbouwen van eenkaart en die ter beschikking stellen. Daarnaast zal een SLAM-algoritme ook lokalisatie-informatievoorzien. Met het SLAM-algoritme willen we een deel van de omgeving in kaart brengen, om zodat deel te linken in een grote kaart. Daarom moeten we ook kijken naar de manier hoe de 3D-kaart wordt voorgesteld. De meeste algoritmes die 3D-informatie verwerken maken gebruik vaneen ’Octomap’ voorgesteld door Wurm et al. (2010). Later werd PCL (Point Cloud Library) doorRusu and Cousins (2011) voorgesteld met het doel functies te voorzien om met 3D-informatie omte gaan. Dit omdat de vraag naar een soortgelijk framework groter werd tijdens de opmars van3D-sensoren.

Octomap

Een Octomap is een datastructuur en framework dat werd voorgesteld door Wurm et al. (2010)en Hornung et al. (2013) met het doel 3D-kaart informatie op te slaan en voor te stellen. Op ditframework is PCL gebouwd om de data te verwerken. Binnen in Octomap is gekozen om te werkenmet een boomstructuur van 3D-punten, zoals zichtbaar is in Figuur 2.13. De boomstructuur heeftverschillende niveau’s met een een 3D-coordinaat en waarde als blad of een nieuwe vertakking.Er is pas een nieuwe vertakking mogelijk als er minstens een 3D-coordinaat onder die tak valt. Zois het mogelijk om af te ronden op een bepaalde grote van blok of tak, om eventueel geheugen tebesparen of het zoekwerk te verkleinen. In Figuur 2.14 is een houten structuur te zien dat doormiddel van een Octomap wordt voorgesteld. De kleur in de Octomap is verbonden aan de positievolgens de z-as. Het is ook mogelijk een kleurwaarde te geven aan een 3D punt van de Octomap,om zo de kleur van de omgeving te kunnen voorstellen.

Figuur 2.13: Octomap voorstelling van 3D-data Wurm et al. (2010). a) 3D-voorstelling van de boomstruc-tuur. b) Boomstructuur van de data met onderliggende punten c) Arrayvoorstelling van deboomstructuur


Figuur 2.14: Octomap voorstelling van een tafel in 3D-data Wurm et al. (2010).

2.3.5 Implementatie

De verwerking van alle beeldinformatie moet snel genoeg werken omdat we enkel vertrouwenop camera beelden als zicht. Tijdens het vergelijken van de algoritmes zal dat dus zeker eenbelangrijke factor zijn. Daarnaast willen we hardware gebruiken dat diepte informatie voorziet alsondersteuning voor het algoritme. Dit om rekentijd uit te sparen en te kunnen spenderen aanSLAM zelf. Dit zou volgens de resultaten van het RGBDSLAM algoritme aan een frequentie van 6Hz mogelijk zijn, ook in grote ruimtes. Terwijl het RTABMAP algoritme daarnaast vooral gefocust isop een real-time werking van het algoritme. Dit wel ten koste van enkele loop-closure-detecties diekunnen worden overgeslagen. Beide algoritmes voldoen volgens de voorgestelde resultaten aande verwachtingen. Daarom zullen we beide algoritmes testen op snelheid en precisie.

2.4 ROS

In de vorige hoofdstukken hebben we reeds overlopen welke informatie we willen voorzien aan hetSLAM algoritme. Alsook de RGB-D camera en de Oculus HMD kwamen aanbod om te bekijkenwelke de informatie we verkrijgen en moeten projecteren. Momenteel beschikken we dus al overenkele blokken dat enkel nog elkaar moeten worden verbonden. In deze paragraaf bespreken wehoe ROS (Robot Operating System) de communicatie zal verzorgen.

2.4.1 Framework

Het oorspronkelijk doel van ROS bestond uit het voorzien van redundantie bij een robotsysteem. Ernamelijk een storing optreden waardoor de sensor het begeeft. Op een robot met diverse sensorenmag dit niet altijd betekenen dat het volledige programma stopt, toch niet zonder een bepaaldeprocedure te volgen. Bijvoorbeeld een robot met een warmtesensor dat niet juist functioneert.Hierop is ROS voornamelijk een antwoord. ROS is in wezen een framework met diverse functiesom de communicatie tussen verschillende programma’s te verzorgen. Naast die functies is dewebsite van ROS (’http://www.ros.org’) de aangewezen locatie geworden om ROS componenten tevinden die gebouwd worden door ontwikkelaars. Aangezien de communicatie eenvoudig is kunnenhardware ontwikkelaars eenvoudig een ROS programma voorzien die data voorziet via ROS. Zokan een andere ontwikkelaar zonder voorkennis van de hardware aan de slag gaan. Dit kan tevensin twee talen, C++ of Python.


2.4.2 Nodes

Het ROS-framework zelf wordt voornamelijk gebruikt om robots aan te sturen. Om de redundantiete garanderen is het handig om verschillende processen iets kleins te laten doen. Dit is bijvoorbeeldde camera en motoraansturing met een afgescheiden proces op dezelfde of een andere computeruitvoeren. Een node in ROS is zo’n proces en heeft net zoals een gewoon C++ programma of Py-thon programma, een main routine. Nodes zijn dus programma’s die volledig op zelfstandig werkenen meestal een specifieke functie uitvoeren. De node zorgt dus voor een klein deel van het grotegeheel. Dat heeft als voordeel dat wanneer een node wegvalt, het volledige systeem daardoor nietstopt met functioneren. Wanneer de motoraansturingsnode wegvalt, zal de motor wegvallen, maarde camera nog altijd functioneren. De nodes communiceren met voorziene functies in ROS, via hetTCP/IP netwerk. Zo is het ook mogelijk om met andere apparaten in een netwerk te communice-ren. Bijvoorbeeld twee robots die de omgeving scannen, terwijl een grote computer de verwerkingdoet van de gegevens.

2.4.3 Topic

In Figuur 2.15 staat een schematische voorstelling van twee ROS nodes. Wanneer we een commu-nicatie willen starten tussen meerdere ROS-nodes, moet hierover een topic aangemaakt worden.Topics zijn gelijkaardig aan een gespreksonderwerp, met de beperking dat het onderwerp niet kanwijzigen. Als er gecommuniceerd wordt met camerabeelden, kunnen berichten van bijvoorbeeldeen warmtesensor niet via deze topic gecommuniceerd worden. Verschillende nodes kunnen naareen topic luisteren of er iets naartoe sturen. Het versturen of beluisteren gebeurt met een ’mes-sage’. Een message is een container van bepaalde data dat vooraf gedefinieerd werd. Het is eencontainer met een vooraf gedefinieerd data type. In de Figuur 2.15 is te zien hoe een ’Node B’ eentopic van data voorziet, die van de camera komt. Dit wordt in een message gestopt en verstuurtnaar een topic. Dit topic wordt beluisterd door ’Node A’. Die krijgt de data en kan er verder iets meedoen. Meer info is te vinden in het boek Enrique Fernandez and Martinez (2015);

Wanneer we kiezen voor topics gebeurt de communicatie ’event based’. Dit betekent dat wanneereen message binnenkomt bij de node dat geaboneerd is op de topic een onderbreking teweegbrengt. Aan de topic is een vooraf ingestelde functie verbonden. Deze functie zal worden aan-geroepen waarna hij terug de normale werking van de node opstarten. Verschillende nodes opdezelfde computer zijn verschillende threads. Waardoor een parallel systeem beschikbaar is, maarmet de topics niet gewacht wordt. De data is gebroadcast en de broadcaster vervolgt zijn werking,zonder te wachten.

2.4.4 Service

Een alternatief van een ROS-topic, dat met events werkt, is een ROS-service. Wanneer we eenROS-service aanspreken zal de node die deze service aanbiedt, daarop reageren en een antwoordsturen. Het lijkt op het aanroepen van een functie van een andere node, met argumenten en eenrespons. Met het verschil dat de node die de service aanroept zal wachten op een respons vande service node. Dit wordt meestal gebruikt om korte communicatie te verzorgen, bijvoorbeeldinstellingen aanpassen.


Figuur 2.15: ROS Nodes, Topics, Messages

2.4.5 Implementatie

Toen we onderzochten welke componenten we gingen hanteren als RGB-D camera en SLAM al-goritme kwam de term ’ROS’ vaak aan bod. Het bedrijf achter de softkinetic heeft een ROS im-plementatie voorzien naast een linux SDK. Ook voor de Kinect van microsoft is een ROS nodeaanwezig, OpenNI. Beide SLAM algortimes waarmee we experimenten willen uitvoeren zijn ookvolledig beschikbaar in ROS, RTABMAP en RGBDSLAM. Enkel de HMD kent nog geen ROS im-plementatie, dit zullen we dan zal ontwikkelen. Daarnaast zal ons programma om de features ineen kaart aan te duiden ook een ROS node zijn die we zelf ontwikkelen. De overige componentenzijn reeds beschikbaar gemaakt onder de OpenSource licentie.

Hoofdstuk 3

AR via VR

Het doel van deze thesis is het zoeken naar een manier om informatie te voorzien via AR. Tijdensde literatuurstudie werd een overzicht gegeven van de beschikbare AR-hardware, met ernaast dealternatieven. Toen werd besloten dat we tijdens deze thesis gebruik gaan maken van VR hardwarewaarop AR gesimuleerd wordt. Dit kunnen we door gebruikt te maken van een RGB-D camera, dieop de VR hardware kan worden bevestigd. In dit hoofdstuk gaan we dieper in op de facetten vanhet simuleren van AR op VR en de uitdagingen ervan.

3.1 Wat simuleren en wat niet

We hebben gekozen om AR te simuleren met een VR HMD. Omdat we gebruik maken van eencamera dat de omgeving weergeeft op de HMD zal hierdoor een vertraging optreden. Dit fenomeennoemt men latency of delay en heeft een invloed op het gebruik van deze techniek. Naast latencybeperken we doormiddel van een camera ook ons gezichtsveld of ’FoV’ (’Field of View’). Naast hetgezichtveld dat beperkter wordt door het gebruik van een camera, zullen we het niet beschikkenover stereo beeld. We beschikken over een camera en dus maar een perspectief van de ruimte.Tot slot zitten in de HMD lenzen tussen onze ogen en het scherm. De lenzen veroorzaken distortiewaarvoor we een oplossing zullen moeten vinden. Deze vier problemen komen in deze paragraafvoor en zullen onderzocht worden met conclusie per onderdeel.

3.1.1 Latency

Latency is een belangrijke factor bij het simuleren van AR. Het is niet de bedoeling dat de gebruikerreeds tegen de muur zit alsvoren de muur dichtbij is in zijn beeld. Bij de HMD die we in dit onderzoekgebruiken, de Oculus Rift DK2, zit een latency-test ingebouwd. Doordat dit enkel beschikbaar isin hun eigen SDK, op Windows, kunnen we onze software moeilijk testen op latency. Daarommaken we gebruik van een simpele test, waarop we een klok filmen die ook wordt weergegevenom het scherm. De camera neemt het beeld binnen en geeft het weer op de HMD. Doordat wemet een afzonderlijke camera beide beelden opnemen, kunnen we het beeld even pauzeren en detwee tijden bekijken. Het verschil van deze tijden, heeft ons een indicatie van de latency die op datmoment aanwezig is. We nemen verschillende momentopnames en nemen hieruit het gemiddelde.De resultaten van deze test zijn te vinden in Tabel 3.1.

De studie van Li et al. (2015) is gebaseerd op een AR toepassing waarin men de invloed van

25

26 3 AR via VR

Tabel 3.1: Latency test Camera’s

Camera Gemiddelde LatencySoftkinetic DS325 250 ms

Kinetic 360 196 ms

system latency wilde meten. Uit dit onderzoek bleek dat de vertraging een belangrijke factor haden een negatieve invloed had op de gebruikerservaring. Er werd gekeken naar de invoed van 100ms en 200 ms, beiden bleken aanvaardbaar met een voorkeur op 100 ms. Dit is al een indicatie dateen goede gebruikservaring gekoppeld is aan een maximum latency van 200 ms. We zien in Tabel3.1 dat de Softkinetic gemiddel 50 ms boven de maximum ligt van 200 ms. Terwijl de Kinect 360gemiddeld 4 ms onder de maxima ligt. De Kinect voldoet dus aan de grenzen van dit onderzoek.

3.1.2 Gezichtsveld

Naast de latency van de opstelling, zal ook het gezichtsveld worden beperkt. De camera waarvoorwe gekozen hebben is de Depthsense, later tijdens deze thesis bleek deze camera niet voldoende.Daarom hebben we ook gebruik gemaakt van de Kinect 360 van Microsoft. In de Tabel 3.2 is eenoverzicht van enkele camera’s en hun kijkhoeken. Het nieuwe model van Microsoft, de Kinect One,heeft een beter FoV. Om het simuleren van AR via VR moet het FoV het natuurlijke bereik zo dichtmogelijk benaderen. Er zijn onderzoeken door de jaren heen gebeurt rond het menselijk zicht.Veel van die resultaten zijn gebundeld in Strasburger et al. (2011), met de verschillende factorenwaarvan het randzicht afhangt. Uit enkele onderzoeken is gebleken dat het FoV is opgedeeld inverschillende bereiken en zones. Deze zones zijn zichtbaar gemaakt in Figuur 3.1. Hier zien wedat we een dicht randzicht hebben bij 60 ◦, met een midden randzicht van nog eens 30 ◦aan beidekanten. Dit is een totaal van 120 ◦waarin we een aangenaam zouden kunnen voorzien. Op figuur3.1 is een overzicht gemaakt van de verschillende hoeken die net werden vermeld. Daarop zien wedat de Microsoft Kinect One het grootste FoV heeft. Terwijl de andere camera’s een aanvaardbareFoV hebben.

Figuur 3.1: Gezichtsveld met verschillende Camera’s

3 AR via VR 27

Tabel 3.2: Overzicht FoV

H VSoftkinetic DS325 (DS525) 74 ◦ 58 ◦

Microsoft Kinect 360 62 ◦ 48 ◦

Microsoft Kinect One 84 ◦ 53 ◦

3.1.3 Stereo

We hebben problemen met latency en het gezichtsveld in de vorige paragrafen besproken. Indeze paragraaf bespreken de afwezigheid van stereo beelden, die de gebruiker voorziet van eendieptezicht. Zelf hebben we twee beelden van een verschillend perspectief nodig om diepte tekunnen waarnemen. In deze thesis hebben we gekozen om een RGB-D camera te gebruiken.Dit voorziet ons van een RGB en een diepte beeld, maar niet van stereobeelden. Met enkeleberekeningen zouden we in staat kunnen zijn stereo beelden te genereren uit een RGB-D beeld,maar dit valt buiten deze thesis. In deze thesis gaan we gebruik maken van een beeld dat identiekis voor beide ogen.

3.1.4 Lens Distortion

Tot slot moeten we rekening houden met de lenzen die in de HMD aanwezig zijn. In de literatuur-studie hebben we reeds aangehaald dat het gebruik van lenzen nodig is. De lenzen zorgen ernamelijk voor dat we een illusie ervaren van een zeer groot scherm, terwijl het scherm zich beperktin grootte om het draagbaar te houden. Dit fenomeen is zichtbaar in Figuur 3.2, waarop de tweelenzen te zien zijn met de lijnen die beeldinformatie voorstellen. Het gebruik van de lenzen brengteen distortie met zich mee waarmee we rekening moeten houden. In Figuur 2.3 zijn de twee dis-torties weergegeven waarmee we te maken krijgen. In de volgende paragrafen bekijken we hoe wein detail dat hebben aangepakt.

Pincushion en Barrel Distortion

De eigenschappen van de lenzen in de Oculus Rift zorgen voor een Pincushion distortie. Ditkunnen we afleiden uit Figuur 3.2, omdat we een groot beeld focussen op een kleiner punt. Diteffect is niet wenselijk, omdat de randen van het beeld relatief groter zijn dan het center van hetbeeld. Het effect op een raster is te zien in Figuur 3.3. Het effect op camera beelden is vergelijkbaar.Het creeert namelijk het gevoel dat we kijken door een vergrootglas. We hebben dus gezocht naareen techniek om dit te vermijden.

Om de pincushion distortie te compenseren, moeten we gebruik maken van barrel distortie. Barreldistortie is het omgekeerde van pincushion distortie. In Figuur 3.4 beschikken we over een rasterdat vervormd is met pincushion distortie. Hierop voeren we barrel distortie uit, met als resultaat hetoorspronkelijk raster. Als we dus willen zorgen voor het oorspronkelijk beeld door de lenzen, moe-ten we softwarematig het beeld vervormen met barrel distortie. Daarna zullen de lenzen pincushiondistortie veroorzaken op dat beeld, met als resultaat het oorspronkelijke beeld. Deze manier vanwerken hebben we toegepast in deze thesis, een schema is te vinden in Figuur 3.5.

28 3 AR via VR

Figuur 3.2: Oculus Rift Lens setup

Distortion implementeren

In het vorige paragraaf werd ons duidelijk dat we de beelden eerst moeten voorzien van barreldistortion. Hiervoor bestaan verschillende aanpakken. Het is mogelijk om op iedere pixel vanhet beeld een barrel distortie toe te passen. Daarnaast kan ook een gegroepeerde aanpak, metgroepen van pixels, die tegelijk door de barrel distortie worden verplaatst. Dit heeft voordelen inde game wereld, omdat bij games de pixels niet van een bron komen, maar gerenderd wordendoor 3D naar 2D-tranformatie. Wij beschikken over een 2D-beeld, met de 3D-projectie reeds inverwerkt aangezien het van een camera komt. Dus een pixel barrel distortie is een eenvoudigereimplementatie.

3.2 AR-componenten in het zicht

Nadat we in het vorige hoofdstuk gekeken hebben naar de uitdagingen die zich vormen bij hetsimuleren van AR via een VR HMD, bekijken we hoe we de informatie gaan visualiseren. Wehebben besloten dat we het beeld afkomstig van de RGB-D camera twee keer naast elkaar gaanvisualiseren. Om zo beide ogen van een beeld te voorzien, op dit beeld wordt extra informatiegeprojecteerd. De mogelijkheden van projecteren beperken zich momenteel tot een gekleurdeverticale strook in het beeld. Deze strook noemen we een ’feature’, die we via een ROS berichtzullen verkrijgen. Daarnaast is ook een ROS service beschikbaar gemaakt met een functie. Omeen goede AR simulatie weer te geven hebben onderzochten we verschillende onderdelen. Dezeonderdelen worden in de volgende paragrafen verder onderzocht.

In Figuur 3.6 is een frame zichtbaar waarop manueel een feature is geprojecteerd. De gele strookis een aanduiding in de 3D omgeving dat via het grondplan werd geplaatst. Hoe dichterbij de locatie

3 AR via VR 29

Figuur 3.3: Pincushion Distortion

Figuur 3.4: Pincushion Compensation

hoe breder de strook.

3.2.1 Feature

De camera voorziet ons van een beeld met een bepaalde FoV. Voor de Softkinetic bedraagt dit74◦, dus 37◦aan beide zijdes van het centerpunt. Daarnaast staat de 74◦gelijk aan 1280 pixels,met 640 pixels aan beide kanten. Wanneer we berekenen hoeveel graden we zien in een pixelkomen we op ongeveer 0,057 graden. We willen wel duidelijk genoeg zijn bij het visualiseren vande strook. Om te garanderen dat altijd een strook zichtbaar is, zullen we 10 pixels breedte nemenals minimum, bijvoorbeeld om features die ver zijn toch nog goed weer te geven. Dit resulteert ineen nauwkeurigheid van ongeveer 0,6◦bij de Softkinetic. Wanneer we dezelfde methodiek volgenvoor de Kinect 360 komen we op 0,5◦nauwkeurigheid bij een breedte van 1280 pixels en een FoVvan 62◦. Met deze berekeningen weten we hoeveel pixels we van het center moeten afwijken omeen bepaalde hoek te verdraaien.

We beschikken momenteel over een manier om een feature weer te geven. De informatie diegebruikt wordt om de feature te visualiseren, halen we uit de ’feature-berichten’.

30 3 AR via VR

Figuur 3.5: Barrel Distortion

Figuur 3.6: Feature zichtbaar in de ruimte

Feature Berichten

De berichten die we ontvangen bevatten enkel de features die momenteel aanwezig zijn in onszicht. In Figuur 3.7 is te zien hoe een feature-bericht eruitziet. Er is een RGB-informatie aanwezig,zodat iedere feature een bepaald kleur kan weergeven. Daarnaast is er een alpha voorzien, datde doorzichtigheid bepaald van de feature. De alpha werd afgeleid uit de afstand van ons tot defeature. Tot slot is er een beta-component die de hoek voorstelt vanaf het center van ons beeld.Deze hoek kunnen we dan met voorgaande berekeningen voorstellen in ons beeld.

Figuur 3.7: Feature bericht

Het is mogelijk dat er meerdere features tegelijk aanwezig zijn in ons zicht. Deze features wordenweergegeven, met elk hun alpha waarde en afstand tot het center van het beeld. Wanneer opdezelfde plaats twee features aanwezig zijn, zullen ze over elkaar geprojecteerd worden.

3 AR via VR 31

Feature Buffer

In pragraaf 2.4.3 werd uitegelegd hoe de berichten worden doorgestuurd. De features dat door denode moeten worde weergegeven worden achter elkaar worden doorgestuurd. De tijd tussen hetversturen en ontvangen van de pakketten, wordt door ROS geregeld. Dit om de vertraging minimaalte houden. Dit brengt wel mee dat we de features moeten bufferen. Daarnaast moeten we ook eensignaal kunnen sturen om de buffer leeg te maken. Hierdoor kan het voorkomen dat een framezichtbaar wordt gemaakt als vorens al de nieuwe features verzonden zijn. Om dit probleem in teperken hebben we gebruik gemaakt van een swap buffer. Dit zorgt ervoor dat de vorige featuresnog zichtbaar zijn, tot er weer een swap gebeurt. Dit zorgt ervoor dat we op elke frame een feature,of swap feature zien.

Hoofdstuk 4

SLAM

Naast het simuleren van de AR hebben we ook een algoritme nodig dat ons voorziet van informatieover de omgeving. In de literatuurstudie kwam reeds aan bod dat algoritmes onder de categorieSLAM ons hiervan voorzien. Tijdens dit onderzoek hebben we gekeken naar twee algoritmes, hetRTABMAP-algoritme en het RGBDSLAM-algoritme. Beide hanteren gemeenschappelijke visueletechnieken, maar verschillen voornamelijk in de verwerking en opslag van die informatie. Eerstzullen we het RGBDSLAM algoritme van Endres et al. (2014) bekijken gevolgd door het RTABMAPalgoritme van Labbe and Michaud (2014), met de nadruk op real-time. Daarna zullen we een keuzemaken om gebaseerd op hun resultaat verder te bouwen.

4.1 Systeem

Om testen uit te voeren hebben we gebruik gemaakt van twee systemen. Een desktop om zwareberekeningen en vergelijkingen op uit te voeren. Daarnaast een laptop dat gebruikt werd om in deruimte te kunnen rondlopen met het uiteindelijke programma. Een klein overzicht van de gebruiktesystemen is zichtbaar in Tabel 4.1

4.2 RGBDSLAM

Het RGBDSLAM-algoritme heeft een implementatie in ROS Indigo dat via github beschikbaar is op’http://felixendres.github.io/rgbdslam v2/’. Het algoritme is door de onderzoeksgroep van Endreset al. (2014) zelf getest met een Kinetic 360. Onze initiele test gebeurde met de DS325 van Soft-kinetic, dat gebruik maakt van ToF. De resultaten van de test van het SLAM-algoritme waren zeerslecht. Dit doordat het bereik van de DS325 maximum 2,4m was met veel ruis vanaf 1m. Hierdoorheeft het algoritme moeilijkheden om de 3D-kaart op te bouwen. Wanneer we binnen het bereik

Tabel 4.1: System specificaties

Hardware Desktop LaptopCPU Intel Q9650 Intel i5-3337URAM 8Gb (4 x 2Gb ) @ 1066 MHz 4Gb + 2Gb @ 1600 MHzVideo GT 430 3rd Gen Core Processor (On Chip)

33

34 4 SLAM

van 1m blijven worden de resultaten beter, maar regio’s verder dan 1m vertonen veel ruis. Wehebben daardoor de conclusie gemaakt dat de DS325 geen geschikt toestel is om grote ruimtes inkaart te brengen.

Er werd besloten verder te werken met de Kinect 360 waarmee het algoritme oorspronkelijk werdontwikkeld. De resultaten zijn hierdoor veel verbeterd en de ruis is beperkt. Bij structured lightwordt de diepte berekend uit de vervorming van een patroon, terwijl bij ToF iedere pixel een dieptewaarde krijgt en ruis dus op pixel niveau kan voorkomen. De Kinect heeft eerder blokken vanonzekerheid in tegenstelling tot pixels van onzekerheid.

4.2.1 Topics

Het algoritme maakt gebruik van de volgende topics om de informatie van de camera te ver-zamelen. De ’/camera/rgb/camera info’ topic bevat informatie over ieder RGB frame dat wordtverstuurd, zoals resolutie on distortie model. Deze topic wordt daarnaast gebruikt als heart-beat voor het algoritme, zonder zal er geen data verwerkt worden. De tweede topic ’/camera/rg-b/image color’ wordt gebruikt om rauwe RGB beelden door te sturen. Vervolgens zal de ’/came-ra/depth registered/sw registered/image rect raw’ topic gebruikt worden om diepte beelden door testuren.

4.2.2 Resultaten

Het RGBDSLAM-algoritme wordt getest met drie verschillende datasets, waaronder deze van eenkamer. De twee overige datasets zijn afkomstig van de onderzoeksgroep dat het RGBDSLAM-algritme heeft ontwikkeld en verder beschreven in Sturm et al. (2012). Een van de twee datasetsdie we hebben gebruikt, heeft een loop-closure, de andere niet. Van alle drie de datasets zal eenresultaat in een grafiek worden weergegeven. Toch merkten we tijdens het testen dat bij het uitvoe-ren van het algoritme met de datasets geen duidelijke 3D-kaart geproduceerd werd. Dit lag aan desnelheid waaraan we de informatie van de dataset leverde aan het algoritme. De data werd anderste snel doorgestuurd, waardoor niet alle frames worden behandeld. Daarom werd besloten enkelcijfers weer te geven die een aanvaardbare 3D-kaart als resultaat hadden. Daarvoor hebben wede snelheid waaraan informatie werd aangeleverd, vertraagd met een factor 20.

In Figuur 4.1 is te zien wat het resultaat is van het algoritme wanneer de data wordt aangeleverdzonder vertraging. Er zijn verschillende stukken die niet juist worden geplaatst en daardoor is veelonzekerheid aanwezig. In Figuur 4.2 zien we het resultaat van dezelfde kamer-dataset met eenvertragingsfactor van 20 tijdens het afspelen. We zien een duidelijk verschil met het resultaat zon-der vertraging en kunnen een betere inschatting geven van de ruimte zonder veel foutieve delen.Dit is wel een offline verwerking van informatie en is moeilijk real-time te realiseren.

De gedetecteerde features en de manier van extraheren worden beide door de ORB-techniek uit-gevoerd, zoals voorgesteld door Rublee et al. (2011). In Figuur 4.4 en in Figuur 4.3 zijn de pro-cestijden tussen iedere frame weergegeven voor beide datasets. In Tabel 4.2 is een overzichtvan interessante gegevens uit de resultaten. Zoals het aantal frames dat werden verwerkt voordatmeer dan 1s aan procestijd tussen twee frames nodig was. Daarnaast zijn ook de maxima tijdenprocestijden tussen frames weergegeven die voorkwamen bij het inladen van de volledige dataset.

In de grafieken is in het begin een vlakke trend te zien, met een plotse stijging naar 1s procestijd.

4 SLAM 35

Figuur 4.1: RGBDSLAM op de Kamer-dataset zonder vertraging

Dit wordt beter weergegeven in Figuur 4.6 waarin het begin van het procestijden verloop van beidedatasets wordt weergegeven. De conclusie na deze test is dat een verwerkingstijd van 6Hz, zoalsvoorgesteld in de paper van Endres et al. (2014) op het desktop systeem niet wordt gehaald metdeze dataset.

In de volgende sectie 4.3 wordt duidelijk dat deze datasets slecht functioneren in het RTABMAP-algoritme dat beschreven wordt in paragraaf 4.3. Daarom hebben we besloten een eigen datasetaan te maken van een ruimte, waarvan we nog live beelden kunnen maken. Deze dataset vaneen kamer hebben we ook getest op het RGBDSLAM-algoritme, de maximum procestijd is ookvermeld in Figuur 4.2. In Figuur 4.6 is de detail-weergave ook zichtbaar. We zien dat de datasetvan Freiburg zonder loop-closure en onze dataset gelijkenissen vertonen.

In Figuur 4.5 is de volledige grafiek zichtbaar met ook een stijgende trend. Op sommige plaatsenin de grafiek is een plotse daling naar nul. Dit komt voor omdat de frames dat verwerkt werdenonvoldoende features bevatte om te vergelijken. Wanneer dit voorvalt is er geen procestijd nodigom te zoeken naar een loop-closure.

36 4 SLAM

Figuur 4.2: RGBDSLAM op de Kamer-dataset met vertragingsfactor 20

Tabel 4.2: Maxima waardes procestijd datasets met aantal features

Dataset frames (<1s) Max. Procestijd tussen framesZonder loop-closure 77 11,82s

Met loop-closure 77 15,58sKamer 51 6,70s

4.3 RTABMAP

Het tweede algoritme dat we onderzochten is het RTABMAP-algoritme ontwikkeld door Labbe andMichaud (2014) dat ook een ROS integratie ter beschikking heeft. In deze sectie zullen we ook dedatasets van Freiburg testen om een vergelijking te kunnen maken met het RGBDSLAM-algoritme.De procestijd is moeilijk te meten omdat RTABMAP een maximum procestijd hanteert. Het verge-lijken zal dus voornamelijk visueel de 3D-kaart zijn van beide algoritmes. Wel zal bij dit algoritmede dataset aan de oorspronkelijke datastroom worden ingeladen, zonder vertraging. Daarna gaanwe dieper in op de lokalisatie mogelijkheid die ingebouwd zit in het algoritme.

4.3.1 Topics

Het algoritme maakt gebruik van dezelfde topics als het RGBDSLAM algoritme. Het enige verschilis dat het RTABMAP algoritme ook gebruik maakt van de /tf topic. Dit is een speciale topic waarinverschillende transformaties in de 3D-ruimte worden geplaatst, samen met een tijd. Deze tijd is

4 SLAM 37

Figuur 4.3: Procestijd RGBDSLAM zonder loop-closure

Figuur 4.4: Procestijd RGBDSLAM met loop-closure

speelt in dit algoritme een belangrijke rol om de loop-closure in tijd te beperken. Om te werkenmet de dataset moet deze tijd altijd correct zijn, daarom hebben we gebruik gemaakt van eentijd simulator tijdens het inladen van de datasets. Daarnaast moesten we ook meegeven aan hetalgoritme dat we gebruik gaan maken van een gesimuleerde tijd, dit kan als parameter.

4.3.2 Lokaliseren

Het RTABMAP-algoritme beschikt over meerdere gebruiksmanieren. Naast het opbouwen van de3D-kaart van de omgeving, kan het algoritme enkel lokaliseren in de 3D-kaart. Hiervoor maakthet programma gebruik van de reeds bestaande loop-closure detectie. Het kan dus even durenvoordat de actuele locatie gevonden is in de kaart. Dit hebben we eveneens getest door middelvan drie kleinere datasets van beelden in de kamer. Door deze in te laden terwijl het algoritme inlokalisatie modus staat, laten we het algoritme zoeken naar onze locatie in de 3D-kaart. Naast hetgebruiken van de dataset hebben we ook live de lokalisatie in de omgeving getest, met succes.

38 4 SLAM

Figuur 4.5: Procestijd RGBDSLAM Kamer dataset

Figuur 4.6: Procestijd Detail RGBDSLAM

4.3.3 Resultaten

Het is niet mogelijk om live aanwezig te zijn op de locatie waar de twee datasets van de onder-zoeksgroep in Freiburg werd opgenomen. Ook daarom was een eigen dataset eenvoudiger ennodig om de ingebouwde lokalisatie te testen van RTABMAP. De kamer-dataset is de enige da-taset dat ook kon worden gebruikt om lokaliseren te testen. Deze dataset hebben we ook getestmet het RGBDSLAM-algoritme om ook de procestijden te kunnen vergelijken. Naast het niet-liveaanwezig zijn op de locatie in Freiburg, is het niet gelukt een deftige 3D-kaart op te bouwen metde datasets die werden aangeleverd door de onderzoeksgroep. Het RTABMAP-algoritme heeft hetmoeilijk de frames te synchroniseren met de /tf ROS topic. De resultaten van het RGBDSLAM-algoritme met deze datasets zijn echter ook zeer onbeduidend. We hebben besloten dit probleemniet op te lossen, omdat de 3D-kaart geen meerwaarde gegeven zou hebben. Daarom werd enkelverder getest met de kamer-dataset.

In Figuur 4.7 is het resultaat te zien van het RTABMAP-algoritme met de kamer-dataset. Dit geeftvergelijkbaar resultaat als dat van RGBDSLAM. Wel zijn sommige stukken uit de 3D-ruimte ver-plaatst en verdraaid zijn ten opzichte van elkaar. Bijvoorbeeld een kast dat uit meerdere delenbestaat. Toch is het een werkbare 3D-kaart dat real-time werd opgesteld. Wel werkt het algoritmemet een beperkte loop-closure. Dit heeft als gevolg dat bij plotse bewegingen geen loop-closure

4 SLAM 39

meer heeft en stopt met het mappen of lokaliseren tot het terug een loop-closure kent. Daarnaastfunctioneerde het algoritme ook niet meer wanneer weinig features voorkwamen in het beeld. In hetalgoritme zit een bepaalde threshold van overeenkomsten om de visuele odometrie te volbrengen.Wanneer het aantal features daalt, zal het aantal mogelijke overeenkomsten mee dalen. Hierdooris het mogelijk dat het algoritme het huidige frame niet kan verbinden aan het vorige en stopt metfunctioneren.

Figuur 4.7: RTABMAP Kamer 3D-kaart

4.4 Conclusie

Het testen van de twee algoritmes heeft duidelijk gemaakt dat naarmate de kaart groter wordt,het RGBDSLAM-algoritme trager functioneert. Het RTABMAP-algoritme heeft hier minder last van,hoewel nog steeds een probleem zal worden gevormd wanneer plotse bewegingen of weinig featu-res voorkomen. Dit geeft wel als gevolg dat het algoritme stopt met functioneren en brengt met zichmee dat er minder foutieve informatie zal worden opgenomen in de 3D-kaart. Dit in tegenstellingtot het RGBDSLAM algoritme dat alles toevoegt aan de 3D-kaart, met een mogelijke optimalisatieachteraf doordat meer informatie een loop-closure teweeg brengt. In het kader van het onder-zoek kozen we voor het RTABMAP algoritme. De snelheid van het algoritme weegt op tegen deonzekerheid dat het introduceert.

Hoofdstuk 5

Mapping

Het RTABMAP-algoritme verzorgt de lokalisatie en het in kaart brengen van de omgeving. Oor-spronkelijk gingen we de 3D-kaart vergelijken met een bestaand grondplan, om dat grondplante visualiseren. Maar doordat een lokalisatie algoritme beschikbaar was binnen het RTABMAP-algoritme, werd beslist hiermee verder te werken. Dit betekent wel dat we niet beschikken over een2D grondplan, maar een 3D-kaart waarin het algoritme kan zoeken naar overeenkomsten. Deze3D-kaart zal dus worden geprojecteerd op een 2D vlak, om zo extra informatie erop te kunnenplaatsen zoals features. In dit hoofdstuk gaan we kijken naar hoe we de 3D-kaart omvormen totgrondplan met alsook een aanduiding waar de gebruiker zich bevindt.

5.1 3D naar 2D

Op een grondplan staan verschillende dingen zoals muren, nooduitgangen en brandblussers ver-meld. Hetgeen wij willen bereiken komt neer op het bekend maken van de omgeving, met demogelijkheid om features toe te voegen en weer te geven in de omgeving wanneer in de richtingvan die feature wordt gekeken. Momenteel beschikken we over een 3D-kaart die eigenlijk bestaatuit meerdere 3D-punten. Om een beeld te krijgen van de omgeving zijn de muren een goed refe-rentiepunt. Als we de muren uit een 3D-reeks kunnen halen en die visualiseren, zal de gebruikerzich een beeld kunnen voorstellen van de omgeving.

5.1.1 Muren

Om de muren te kunnen filteren uit een reeks 3D-punten, hebben we onderzocht wat de eigen-schappen van muren zijn. Een eigenschap waarvan we gebruik hebben gemaakt is de aanwezig-heid in de z-as. Een muur zal meestal starten aan de grond en eindigen aan het plafond. Dit wilzeggen dat in de z-as op bepaalde plaatsen veel meer punten aanwezig zijn.

Een eerste aanpak is kijken naar punten met veel naburige punten. Dit bleek heel wat rekenver-mogen te vragen omdat we over veel punten beschikken en voor ieder punt moesten alle puntennagekeken worden of deze binnen een bepaalde grens lag. Een betere en snellere aanpak is afron-den op de x-as en y-as. De punten zijn gedefinieerd op een grote nauwkeurigheid met vier cijfersna de komma. Wanneer we al deze punten afronden tot twee cijfers na de komma, zullen naburigepunten dezelfde x en y-waarde hebben, maar eventueel een andere z-waarde. Bijvoorbeeld depunten met coordinaten (1,2385; 2,3456; 1) en (1,2354; 2,3456; 1) zijn verschillend, maar wanneer

41

42 5 Mapping

we afronden tot op twee cijfers na de komma, worden beide punten (1,24; 2,35; 1). In Figuur 5.1zien we een verloop van afronding. Bovenaan is het originele raster met de eronder mogelijkeafrondingen en hun effect. We zien dat hoe meer afgerond wordt, hoe meer een groter raster wordtopgebouwd met verschillende punten die op elkaar komen te staan volgens de z-as. Wanneer wedit toepassen op een 3D-kaart zullen alle punten ook in een groter raster worden geplaatst. Daarnabouwen we een heatmap van het raster met het aantal punten volgens de z-as. Hoe meer punten,hoe groter de waarde. Muren beschikken over veel punten volgens de z-as en zullen bijgevolg eenhogere waarde hebben. Met een threshold zouden we muren eenvoudig kunnen detecteren. Hetnadeel dat volgt uit het vergroten van het raster door afronding, is het verminderen van de resolutie.Wanneer we afronden met geen cijfers na de komma, vallen veel punten op dezelfde plaats. Ditstelt uiteindelijk geen muur meer voor maar een punt. Ergens moet een grens gelegd worden totwaar we kunnen afronden, zonder veel verlies van details.

In Figuur 5.2 is een heatmap zichtbaar van de kamer-dataset. Deze werd opgebouwd met eenprecisie van 0,005. Hierdoor was het aantal punten in de z-as maximaal 6. Dit is een klein aan-tal overeenkomstige punten en is niet voldoende om een threshold op te plaatsen. Wel zorgdedeze afronding ervoor dat nog steeds een duidelijke weergave van de omgeving beschikbaar was.Momenteel is het voldoende een perceptie van de omgeving te kunnen maken uit de heatmap.Uiteindelijk kan verder onderzocht worden hoe we de muren als lineaire lijnen aanduiden.

Figuur 5.1: Afronden van punt coordinaten leidt tot raster vorming.

Rotatie z-as

Tijdens het opstellen van de 3D-kaart wordt enkel gebruik gemaakt van een RGB-D camera. Ditkan resulteren in een probleem bij het mappen volgens de z-as. Het eerste frame dat door hetSLAM-algoritme wordt verwerkt is namelijk de assenreferentie. Dit betekent dat wanneer het eerstebeeld niet loodrecht op de grond staat, of evenwijdig met de muur, de z-as een verdraaiing kent tenopzichte van effectieve z-as. Wanneer muren de z-as niet volledig volgen, maar we wel aannemendat muren in de z-as sterk aanwezig zijn, is een heatmap geen goede oplossing. In Figuur 5.4 iseen cilinder te zien in een 3D-ruimte. Deze cilinder wordt vervolgens geprojecteerd op het xy-vlak.Doordat de lengte van de cilinder evenwijdig is het de z-as, zal op het xy-vlak enkel de bovenkant

5 Mapping 43

Figuur 5.2: Het grondplan

te zien, een perfecte cirkel. In Figuur 5.5 daarentegen is ook een cilinder te zien dat niet evenwijdigstaat met de z-as. Wanneer deze geprojecteerd wordt op het xy-vlak zien we naast de bovenkantook een stuk van de onderkant. Daarnaast is het geprojecteerde bovenvlak geen perfecte cirkelmeer, maar een ellips geworden. Hetzelfde fenomeen verkrijgen we met muren die niet evenwijdigstaan, het grondvlak en bovenvlak zorgt voor een dikkere puntengroep dat minder geconcentreerdis.

Compensatie z-as

Om een correctere weergave te hebben van ons grondplan hebben we gezocht naar manieren omhet probleem te compenseren. Omdat het om een initiele fout gaat bij het eerste frame, kunnenwe zorgen dat het eerste frame loodrecht op het xy-vlak staat. Dit is manueel en zorgde vooreen heatmap dat te zien is in Figuur 5.2. Een betere optie is het gebruikmaken van de gyroscoopdie aanwezig is in de Oculus HMD. Als de RGB-D camera correct is gemonteerd ten opzichte

44 5 Mapping

Figuur 5.3: Het grondplan met onze locatie en kijkrichting

van de HMD, kunnen we de rotatie-assen van de gyroscoop gebruiken in plaats van de visuelerotatie-assen van de RGB-D camera. Bij het verwerken van frames kan het SLAM algoritme opelk moment gebruik maken van een accurate gyroscoop meting. Dit zou er ook voor zorgen datde virtuele assen beter overeenkomen met de echte assen, maar de ontwikkelingen van het HMDSDK laten dit niet nog toe op Linux.

Een derde optie is het zoeken van het correcte xy-vlak in de 3D-kaart. Bijvoorbeeld de laagstepunten zoeken en uit drie punten een vlak construeren. Dit is ook een mooi concept, maar depunten aanwezig in de 3D-kaart zijn niet altijd correct. De aanwezigheid van ruis maakt het moeilijkde juiste punten te selecteren uit de 3D-kaart. De algemene verdraaiing zorgde ervoor dat enkelemuren evenwijdig met de z-as kwamen te liggen, terwijl andere muren nog meer verspreid werdendoor de verdraaiingen. Een algemene verdraaiing blijkt niet de oplossing te zijn.

Momenteel hebben we gekozen om manueel te zorgen dat de z-assen evenwijdig liggen vanaf heteerste frame.

5 Mapping 45

Figuur 5.4: Een cilinder evenwijdig met de z-as dat wordt geprojecteerd op het xy-vlak.

5.1.2 Positie

Het RTABMAP-algoritme voorziet dus van een 3D-kaart, maar tegelijk ook van onze positie in dezekaart. Dit wordt verstuurd via de /tf topic waarop ook de camera informatie voorziet. Het bleekniet zo eenvoudig om de informatie van deze topic te halen. Voorheen hebben we gezien dat eenROS-topic een event in werking doet treden, met het uitvoeren van een vooraf ingestelde functieals gevolg. Dit is niet mogelijk de de /tf topic en moet op een andere manier worden aangepakt.Om informatie van de /tf topic te halen moet een apart tf listener object worden aangemaakt, methet enige doel te luisteren naar de /tf topic. Van zodra een bericht wordt ontvangen dat een be-paald ID heeft, zal de tf listener een bepaalde functie aanroepen. Hiervoor werd een aparte nodeaangemaakt dat als doel heeft te luisteren naar de /tf topic. Van zodra een positie wordt ontvangenvan de gebruiker zal deze worden doorgestuurd via een andere topic naar node die de 2D-heatmapopbouwt. Deze node zal op de heatmap dan de locatie van de gebruiker weergeven. In Figuur 5.3is dezelfde heatmap als Figuur 5.2 te zien, met de huidige locatie en kijkrichting van de gebruikerop gevisualiseerd in het rood.

5.1.3 Features

Om de heatmap te visualiseren maken we gebruik van het OpenCV-framework. Met OpenCVwordt een venster aangemaakt om online de heatmap op weer te geven met de actuele locatie vande gebruiker. Wanneer op deze afbeelding met de linker muisknop wordt geklikt, zal een featureworden aangemaakt. Deze feature zal vervolgens zichtbaar worden op de heatmap als een geelpunt.

Om te controleren naar welke features de gebruiker aan het kijken is, hebben we de positie enkijkrichting van de gebruiker nodig en de positie van de feature. In Figuur 5.6 is een grondplante zien. Op dit grondplan zijn twee features aanwezig. Beide features staan in het zicht van degebruiker. Om dit te detecteren bij het overlopen van iedere feature, trekken we een hulplijn. Dezelijn is in het figuur blauw, start bij de positie van de gebruiker en volgt de richting. De lengte maaktniet veel uit, maar werd bepaald op 10 om eenvoudig te kunnen debuggen. Daarna hebben we

46 5 Mapping

Figuur 5.5: Een cilinder niet evenzijdig aan de z-as dat wordt geprojecteerd op het xy-vlak.

twee vectoren met een gemeenschappelijk punt.

Het scalair product van twee vectoren is evenredig met de cosinus. Terwijl de determinant van tweevectoren evenredig is met de sinus. Wanneer we beschikken over zowel een sinus als een cosinus,is het mogelijk een hoek te bepalen met een tangens. Uit de tangens krijgen we vervolgens eenhoek tussen +π en −π in radialen. Wanneer we deze hoek vergelijken met de kijkhoek van decamera, kunnen we bepalen of de feature in het beeld staat en op welke afstand. Van zodra eenfeature binnen de kijkhoek ligt van de camera, zullen de gegevens van de feature via de topicworden verstuurd. De node verantwoordelijk voor het visualiseren, is geabonneerd op deze topicen zal de feature vervolgens weergeven in het beeld op de juiste locatie.

5.2 Conslusie

We merken dat het aanklikken van het grondplan een tijdelijke maar praktische manier is om fea-tures aan te duiden. Naar de toekomst toe zou het aanklikken kunnen worden vervangen dooreen intelligent systeem dat zelf features toevoegt. Het detecteren van features die effectief in dekijkhoek van de camera aanwezig zijn is aanpasbaar voor iedere camera en moet wel in wordengesteld. Bij het opbouwen van het grondplan door middel van een heatmap vertoont wat problemenbij een assenstelsel dat niet evenwijdig is aan de assen in de wereld. Dit zou in de toekomst geenprobleem meer vormen, van zodra de sensor die aanwezig is in de HMD ons ook van informatievoorziet.

5 Mapping 47

Figuur 5.6: Grondplan met twee features op aangeduid

Hoofdstuk 6

Conclusie

Uit het onderzoek is gebleken dat het mogelijk is om AR te simuleren met VR. Wel is er eenvertraging of latency aanwezig dat dicht bij de maxima ligt. Dit zorgt ervoor dat het gebruiksgemakdaalt. Naast de latency is het wel mogelijk een grondplan te verkrijgen van een 3D kaart dievooraf moet worden opgesteld. Deze kaart zal wel niet precies zijn doordat er enkel gebruik wordtgemaakt van visuele odometrie, zonder ondersteuning van een gyroscoop.

49

Bibliografie

Atkinson, R. C. and Shiffrin, R. M. (1968). Human memory: A proposed system and its controlprocesses. The psychology of learning and motivation, 2:89–195.

Baddeley, A. D. (1997). Human memory: Theory and practice. Psychology Press.

Burdea, G. and Coiffet, P. (2003). Virtual reality technology. Presence: Teleoperators and virtualenvironments, 12(6):663–664.

Desai, P. R., Desai, P. N., Ajmera, K. D., and Mehta, K. (2014). A review paper on oculus rift-avirtual reality headset. arXiv preprint arXiv:1408.1173.

Dryanovski, I., Valenti, R. G., and Xiao, J. (2013). Fast visual odometry and mapping from rgb-d data. In Robotics and Automation (ICRA), 2013 IEEE International Conference on, pages2305–2310. IEEE.

Endres, F., Hess, J., Sturm, J., Cremers, D., and Burgard, W. (2014). 3-d mapping with an rgb-dcamera. Robotics, IEEE Transactions on, 30(1):177–187.

Engel, J., Schops, T., and Cremers, D. (2014). LSD-SLAM: Large-scale direct monocular SLAM.In European Conference on Computer Vision (ECCV).

Engel, J., Stuckler, J., and Cremers, D. (2015). Large-scale direct slam with stereo cameras.In Intelligent Robots and Systems (IROS), 2015 IEEE/RSJ International Conference on, pages1935–1942. IEEE.

Enrique Fernandez, Luis Sanchez Crespo, A. M. and Martinez, A. (2015). Learning ROS for Ro-botics Programming - second edition. Packt Publishing.

Geng, J. (2011). Structured-light 3d surface imaging: a tutorial. Advances in Optics and Photonics,3(2):128–160.

Hansard, M., Lee, S., Choi, O., and Horaud, R. P. (2012). Time-of-flight cameras: principles,methods and applications. Springer Science & Business Media.

Hornung, A., Wurm, K. M., Bennewitz, M., Stachniss, C., and Burgard, W. (2013). OctoMap: Anefficient probabilistic 3D mapping framework based on octrees. Autonomous Robots. Softwareavailable at http://octomap.github.com.

Huang, A. S., Bachrach, A., Henry, P., Krainin, M., Maturana, D., Fox, D., and Roy, N. (2011). Visualodometry and mapping for autonomous flight using an rgb-d camera. In International Symposiumon Robotics Research (ISRR), pages 1–16.

51

http://octomap.github.com

52 BIBLIOGRAFIE

Kalman, R. E. (1960). A new approach to linear filtering and prediction problems. Journal of basicEngineering, 82(1):35–45.

Kerl, C., Sturm, J., and Cremers, D. (2013). Dense visual slam for rgb-d cameras. In IntelligentRobots and Systems (IROS), 2013 IEEE/RSJ International Conference on, pages 2100–2106.IEEE.

Klein, G. and Murray, D. (2007). Parallel tracking and mapping for small AR workspaces. In Proc.Sixth IEEE and ACM International Symposium on Mixed and Augmented Reality (ISMAR’07),Nara, Japan.

Labbe, M. and Michaud, F. (2013). Appearance-Based Loop Closure Detection for Online Large-Scale and Long-Term Operation. IEEE Transactions on Robotics, 29(3):734–745.

Labbe, M. and Michaud, F. (2014). Online Global Loop Closure Detection for Large-Scale Multi-Session Graph-Based SLAM. In Proceedings of the IEEE/RSJ International Conference onIntelligent Robots and Systems, pages 2661–2666.

Li, M., Arning, K., Vervier, L., Ziefle, M., and Kobbelt, L. (2015). Influence of temporal delay anddisplay update rate in an augmented reality application scenario. In Proceedings of the 14thInternational Conference on Mobile and Ubiquitous Multimedia, pages 278–286. ACM.

Litwiller, D. (2001). Ccd vs. cmos. Photonics Spectra, 35(1):154–158.

Ohn-Bar, E. and Trivedi, M. M. (2014). Hand gesture recognition in real time for automotive inter-faces: A multimodal vision-based approach and evaluations. Intelligent Transportation Systems,IEEE Transactions on, 15(6):2368–2377.

Patrick, E., Cosgrove, D., Slavkovic, A., Rode, J. A., Verratti, T., and Chiselko, G. (2000). Usinga large projection screen as an alternative to head-mounted displays for virtual environments.In Proceedings of the SIGCHI conference on Human Factors in Computing Systems, pages478–485. ACM.

Rublee, E., Rabaud, V., Konolige, K., and Bradski, G. (2011). Orb: an efficient alternative to siftor surf. In Computer Vision (ICCV), 2011 IEEE International Conference on, pages 2564–2571.IEEE.

Rusu, R. B. and Cousins, S. (2011). 3d is here: Point cloud library (pcl). In Robotics and Automation(ICRA), 2011 IEEE International Conference on, pages 1–4. IEEE.

Scaramuzza, D. and Fraundorfer, F. (2011). Visual odometry.

Strasburger, H., Rentschler, I., and Juttner, M. (2011). Peripheral vision and pattern recognition: Areview. Journal of vision, 11(5):13–13.

Sturm, J., Engelhard, N., Endres, F., Burgard, W., and Cremers, D. (2012). A benchmark for theevaluation of rgb-d slam systems. In Proc. of the International Conference on Intelligent RobotSystems (IROS).

Wurm, K. M., Hornung, A., Bennewitz, M., Stachniss, C., and Burgard, W. (2010). Octomap: Aprobabilistic, flexible, and compact 3d map representation for robotic systems. In Proc. of theICRA 2010 workshop on best practice in 3D perception and modeling for mobile manipulation,volume 2.

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

augmented reality voor interventieploegen · 2017-09-27 · abstract in deze thesis wordt...

Documents