Bachelor Informatica
Extended tracking in
archeologische omgevingen
Sander Hansen
22 juni 2019
Begeleiders: dhr. dr. R.G. Belleman, dhr. T.J.R. Lanjouw & dhr. drs. J. Waagen
Inf
orma
tica
—
Universiteit
v
an
Ams
terd
am
Samenvatting
In het archeologische onderwijs wordt Augmented Reality gebruikt om historische data helder en overtuigend te visualiseren. Om virtuele modellen op de juiste plaats te weergeven worden de locaties van deze modellen relatief aan een vooraf gedefinieerd visueel herken-ningspunt, een marker genaamd, gekoppeld. De marker moet in beeld blijven om het object correct te plaatsen. Dit maakt het niet mogelijk om modellen die vele malen groter zijn dan de marker te plaatsen, een wenselijke functie voor archeologisch onderwijs. Om een model te blijven plaatsen als de marker uit beeld verdwenen is, kan extended tracking worden gebruikt, een methode die geen marker nodig heeft om het model te plaatsen. Dit onder-zoek vergelijkt verschillende beschikbare technieken die extended tracking mogelijk maken op nauwkeurigheid. Uit dit onderzoek blijkt dat VINS-mono de meest betrouwbare techniek is die extended tracking mogelijk maakt voor het archeologie domein.
Inhoudsopgave
1 Inleiding 7 1.1 Context . . . 7 1.2 Probleemstelling . . . 9 1.3 Toepassing . . . 10 1.4 Gerelateerd werk . . . 10 2 Theoretische achtergrond 11 2.1 SLAM . . . 11 2.2 Quaternion . . . 11 2.2.1 IMU . . . 13 3 Implementatie 15 3.1 Assumpties . . . 15 3.2 Algoritmes . . . 15 3.2.1 ORB-SLAM . . . 15 3.2.2 DSO . . . 17 3.2.3 VINS-mono . . . 18 3.3 Basis applicatie . . . 19 3.3.1 ARCore . . . 19 3.3.2 Initialisatie . . . 20 3.3.3 Markerless tracking . . . 21 3.3.4 Metingen . . . 21 4 Experimenten 23 4.1 Opzet . . . 23 4.2 Data . . . 23 4.2.1 Dataset . . . 23 4.2.2 Eigen data . . . 24 4.3 Experimenten . . . 26 4.3.1 Datasets . . . 26 4.3.2 Eigen data . . . 26 4.4 Resultaten . . . 26 4.4.1 TUM VI Benchmark . . . 30 4.4.2 PennCOSYVIO . . . 30 4.4.3 Translatie- en rotatiesnelheid . . . 35 4.4.4 Eigen data . . . 38 5 Conclusie 39 5.1 Toekomstig werk . . . 39 Bibliografie 40HOOFDSTUK 1
Inleiding
1.1
Context
Visualisatie is een belangrijk onderdeel voor het analyseren van archeologische data, door arche-ologische en (kunst)historische objecten en gebouwen te reconstrueren kan men een beter inzicht krijgen in de wereld van het verleden [Lanjouw, 2018]. Al sinds het begin van de twintigste eeuw worden maquettes en tekeningen gebruikt om historische contexten te visualiseren en sinds ongeveer tien jaar wordt steeds meer gebruikgemaakt van virtuele reconstructies [Pfeiffer et al., 2013]. Waar dit eerst alleen mogelijk was in een puur virtuele omgeving, maken technologische ontwikkelingen dit ook mogelijk in een zogenaamde mixed reality omgeving.
Figuur 1.1: Virtualiteit Continum zoals gedefinieerd door [Milgram and Kishino, 1994]. Door [Milgram and Kishino, 1994] wordt Mixed Reality gedefinieerd zoals in figuur 1.1. Het is een verzamelnaam voor de verschillende methodes die zich tussen de daadwerkelijke omgeving en de virtuele omgeving bevinden. Augmented Virtuality wordt gezien als een realtime representatie van echte objecten in de virtuele wereld en Augmented Reality als het samenvoegen van virtuele objecten in de echte wereld.
Binnen het archeologie domein worden regelmatig 3D-modellen gemaakt van reconstructies. Deze modellen kunnen in een puur virtuele omgeving goed worden geobserveerd. Wanneer deze echter in context geplaatst moeten worden, zal de omgeving van het model ook in de virtuele omgeving moeten worden nagebouwd. Augmented Reality kan hier de oplossing voor zijn door de virtuele omgeving met de echte omgeving samen te voegen met behulp van een camera [Lanjouw, 2018].
Dit samenvoegen gebeurt op een dusdanige manier dat het model van de reconstructie correct gepositioneerd wordt ten opzichte van de echte wereld die opgenomen is door een camera. Dit kan met behulp van een marker, deze marker kan een simpele 2D-afbeelding zijn of een complexer 3D-object [Amin and Govilkar, 2015]. Nadat de marker gedetecteerd is kunnen we aan de hand
van de 2D-o¨ordinaten in het beeld en de bij behorende 3D-co¨ordinaten van de marker in het
model de projectiematrix p schatten. Deze matrix zet 3D-co¨ordinaten van het model om naar
2D-co¨ordinaten in het beeld. Het model kan correct geplaatst worden met behulp van deze
matrix.
Momenteel wordt Augmented Reality bij archeologie voornamelijk gebruikt voor voorlichtings-en onderwijsdoeleindvoorlichtings-en, in onderzoek is de toepassing veel minder frequvoorlichtings-ent. De wijze van gebruik tussen onderwijs en onderzoek verschilt, zoals ook gesteld in [Eggert et al., 2014]. Uit een ge-sprek met digitaal archeologisch onderzoeker dhr. drs. J. Waagen blijkt dat de meerwaarde van
Augmented Reality voor onderzoekers nog een discussiepunt is, maar mochten zij gebruik willen maken van deze toepassing dan moet hier een applicatie voor beschikbaar zijn waar interactief onderzoek mee gedaan kan worden. Bij het onderwijs ligt de nadruk vooral op het helder en overtuigend visualiseren van kennis [J. Waagen, persoonlijke communicatie, 5 juni 2019].
Figuur 1.2: Augmented Reality zoals gebruikt in een van de Blended Learning modules in het onderwijs van de opleiding archeologie op de Universiteit van Amsterdam. Met van rechts naar links; Model van de huidige bebouwing dat als marker wordt gebruikt, model van de reconstructie van bebouwing uit een eerder tijdperk, de reconstructie gevisualiseerd op de huidige bebouwing met behulp van Augmented Reality. Uit [Lanjouw, 2018].
Op de Universiteit van Amsterdam wordt door de studie Archeologie gebruikgemaakt van realtime Augmented Reality om historische en archeologische reconstructies over het huidige
straatbeeld en objecten in musea heen te projecteren [Lanjouw, 2018]. Een voorbeeld is te
zien in figuur 1.2 waar een 3D-model van de huidige bebouwing als marker wordt gebruikt om bebouwing uit een eerder tijdperk overheen te plaatsen. Het virtuele object wordt op de juiste positie gehouden doordat het gebruikmaakt van de marker. Zodra de marker niet meer goed te observeren is door de camera verdwijnt ook het virtuele object.
Bij archeologisch onderzoek of onderwijs komt het voor dat de marker vele malen kleiner is dan het virtuele object [Lanjouw, 2018]. Denk hierbij aan gedeeltelijk verwoeste gebouwen waar de gehele historische bebouwing op geprojecteerd moet worden, ook als de marker niet meer in beeld is of aan kleine archeologische objecten die als marker dienen voor een grotere virtuele scene. Voordat Augmented Reality ook gebruikt kan worden door de archeologische experts, is een applicatie nodig die het model op de correcte positie kan blijven visualiseren ook al is de marker uit het zicht verdwenen.
1.2
Probleemstelling
In 2015 vergeleken Amin en Govilkar meerdere Augmented Reality platformen en beschreven verschillende technieken voor de registratie van de marker en het correct plaatsen van het virtuele object ten opzichte van de marker [Amin and Govilkar, 2015]. Zo kan gebruik worden gemaakt van 2D-markers waarbij voornamelijk naar contrast gekeken wordt of van 3D-markers waarbij met behulp van randdetectie de modellen in de camera gevonden kunnen worden. Deze technieken kunnen niet meer gebruikt worden wanneer de marker uit beeld verdwijnt.
Figuur 1.3: Uitvoer van Augmented Reality met schematische uitleg. Boven zien we een rotatie van de camera waardoor de marker (het Cola blik) uit beeld verdwijnt en hiermee ook de visu-alisatie niet meer kan worden weergegeven. Onder de schematische weergave met in het rood de marker, bruin de visualisatie, blauw de camera en zwarte lijnen die het gezichtsveld van de camera representeren.
Boven in figuur 1.3 is te zien hoe de marker (het Cola blik) uit beeld verdwijnt en hiermee ook het model niet meer correct geplaatst kan worden. In de eerste afbeelding is de marker goed in beeld en wordt een gedeelte van het model weergegeven. Bij de tweede afbeelding is de camera zo geroteerd dat de marker nog gedeeltelijk in beeld is en een groter gedeelte van het model kan worden weergegeven. In de laatste afbeelding is de marker niet meer te zien en is ook het model verdwenen, terwijl deze in theorie nog in beeld zou moeten zijn. De rotatie is schematisch weergeven onder in figuur 1.3, waar te zien is hoe de virtuele blokken eigenlijk hadden moeten worden weergegeven.
Het bepalen van de plaatsing van het virtuele object, terwijl er geen marker in beeld is, wordt ook wel markerless tracking genoemd [Comport et al., 2006]. Dit samen met het originele initiali-satieproces waarbij wel een marker in beeld is, noemen we extended tracking [Vuforia, Extended Tracking, 2019]. Binnen extended tracking wordt overgeschakeld naar markerless tracking zodra de originele marker uit beeld verdwijnt.
Het voordeel van extended tracking is dat wanneer moet worden overgeschakeld op markerless tracking al veel informatie beschikbaar is. Zo is informatie over de absolute schaal en de laatste positie van de camera bekend vanuit het moment dat de marker wel in beeld was.
Voor de toepassing binnen het archeologie domein moet de oplossing van het extended
trac-king aan een aantal randvoorwaarden voldoen. Zo moet het met een hedendaagse telefoon
uitgevoerd kunnen worden. Hiermee hebben wij bijvoorbeeld beschikking over de instrumenten die zich in deze telefoon bevinden, denk hierbij aan een camera maar ook een gyroscoop en versnellingsmeter.
De probleemstelling leidt tot de vraag: welke technieken kunnen gebruikt worden om extended tracking mogelijk te maken voor het archeologie domein? Uit het antwoord op deze vraag moet
een techniek voortvloeien waarmee we het mogelijk kunnen maken om de virtuele omgeving correct weer te geven voor de toepassing binnen het archeologie domein.
1.3
Toepassing
De verschillende technieken zullen worden onderzocht en er zal worden gekeken hoe goed ze daadwerkelijk toepasbaar zijn binnen het archeologie domein. Aan de hand van het resultaat van dit onderzoek kunnen de juiste technieken worden geselecteerd om zo een applicatie te maken die door studenten gebruikt kan worden zoals in figuur 1.2.
1.4
Gerelateerd werk
Bij dit onderzoek worden technieken onderzocht die extended tracking mogelijk maken. De
techniek moet het model correct blijven plaatsen in een situatie overeenkomend met het gebruik van de afdeling Archeologie.
In het verleden zijn verschillende onderzoeken geweest die deze technieken vergelijken [Joshi et al., 2019]. Echter hebben deze onderzoeken zich niet toegespitst op het domein archeologie en
worden commerci¨ele platformen achterwege gelaten.
De afdeling Archeologie maakt gebruik van het Augmented Reality platform Vuforia in Unity. Deze maakt het mogelijk om 3D-objecten als marker toe te voegen en deze te detecteren. Ook is een vorm van extended tracking ingebouwd, het is echter niet bekend van welke technieken gebruik wordt gemaakt tijdens het markerless tracken [Vuforia, Extended Tracking, 2019]. Google heeft ook een uitgebreid Augmented Reality platform ARCore genaamd waarin extended tracking mogelijk is, maar waar de technieken achter het markerless tracken wederom onbekend zijn [ARCore, 2019]. Idealiter zouden we de losse markerless tracking technieken testen om te kijken welke het meest geschikt zijn voor de toepassing binnen het archeologie domein.
HOOFDSTUK 2
Theoretische achtergrond
2.1
SLAM
Met behulp van een marker kan zoals beschreven in 1.1 de projectiematrix worden geschat die het model op de juiste locatie visualiseert. Deze methode wordt bij de afdeling van archeologie op de Universiteit van Amsterdam al gebruikt terwijl extended tracking tot nu toe nog achterwege is gelaten[Lanjouw, 2018]. Om extended tracking mogelijk te maken zal er een vorm van markerless tracking moeten worden ge¨ımplementeerd.
Om met behulp van markerless tracken het model op de juiste plaats te visualiseren, is
een projectiematrix nodig die de 3D-c¨oordinaten van het model juist weet om te zetten in de
2D-c¨oordinaten van het beeld. Om deze projectiematrix te schatten, kunnen we de locatie en
ori¨entatie (vanaf nu pose genaamd) van de camera ten opzichte van het model gebruiken. De
initi¨ele pose kan worden verkregen vanuit het moment dat de marker nog in beeld was.
Zodra de marker uit beeld is verdwenen moet deze pose bijgehouden worden om het model op de goede plek weer te blijven geven. Dit kan met behulp van een zogenaamd Simultaneous Localization and Mapping (SLAM) algoritme. Een algoritme dat tegelijkertijd een kaart van de omgeving bijhoudt en het apparaat hierin lokaliseert. Door de kaart continu te updaten, kan de positie van het apparaat nauwkeurig worden geschat.
SLAM is volgens [Bailey and Durrant-Whyte, 2006] in 1986 ontstaan op de IEEE Robotics and Automation Conferentie in San Fransisco. Hier werd het als probleem beschreven voor het verplaatsen van autonome robots, inmiddels wordt de benaming gebruikt voor de technieken die het probleem oplossen.
Binnen de term kunnen we twee categorie¨en onderscheiden, Visual SLAM (VSLAM) en
Vi-sual Inertial SLAM (VISLAM). VSLAM maakt alleen gebruik van de camera om informatie te verzamelen waar VISLAM ook gebruikmaakt van de gyroscoop en versnellingsmeter. De algorit-mes werken in het algemeen met een front- en een backend. Waarbij de frontend de data van de sensoren interpreteert en de backend uit deze data de omgeving en de positie bepaalt [Cadena et al., 2016].
Niet alle oplossingen voor het SLAM-probleem zijn bruikbaar binnen Augmented Reality. Zo moet het algoritme niet alleen realtime gebruikt kunnen worden, maar zijn ook de resources van een telefoon beperkt.
De bijgehouden poses kunnen vervolgens gebruikt worden om het model te projecteren naar het beeld. Hoe nauwkeuriger de poses worden geschat, hoe nauwkeurig de projectiematrix kan worden berekend en het model kan worden geplaatst.
2.2
Quaternion
De resultaten die uit de SLAM-algoritmes verzameld worden, kunnen worden gebruikt om de
nauwkeurigheid van de algoritmes te bepalen. Deze poses bestaan uit de x-, y- en z- co¨ordinaten
vergelijken zal de afstand tussen de x-, y- en z- co¨ordinaten en het verschil in ori¨entatie moeten worden berekend.
De ori¨entatie wordt bijgehouden in een quaternion en niet in een rotatie om de x-, y-, en
z-as. Een rotatie om de assen kan namelijk verschillende problemen opleveren. De ori¨entatie
hangt af van de volgorde waarin rotaties om de assen zijn uitgevoerd, rotaties in 3D zijn dus niet commutatief. Een voorbeeld hiervan is te zien in figuur 2.1. We nemen een rotatie van 90 graden om zowel de z- als de x-as. Het blauwe hart wordt eerst om de z-as en dan om de x-as geroteerd
terwijl het roze hart eerst om de x-as en dan om de z-as geroteerd wordt. De ori¨entatie van de
twee harten verschilt.
Figuur 2.1: Weergave van de niet-commutativiteit van een rotatie met behulp van een rotatie van 90 graden van harten om de z- en x-as. Bij de bovenste rij wordt eerst om de z-as geroteerd vervolgens om de x-as, bij de onderste rij eerst om de x-as en daarna om de z-as.
Om de ori¨entatie goed bij te houden kan, gebruikgemaakt worden van Eulerhoeken waarbij
rekening gehouden wordt met de volgorde van de rotatie[Weisstein, 2009]. Eulerhoeken worden uitgedrukt in drie rotaties (φ, θ, ψ) waar rotatiematrixen uit gevormd kunnen worden.
Echter schept deze weergave een nieuw probleem, een zogenaamde Gimbal lock kan optreden. Zoals te zien in afbeelding 2.2 kunnen twee assen samenvallen. Dit heeft tot gevolg dat we een vrijheidsgraad minder hebben en een rotatie niet meer correct uitgevoerd kan worden.
Figuur 2.2: Links een assenstelsel zonder rotatie, rechts dusdanig geroteerd dat een Gimbal lock optreedt. Uit [Wikipedia, the free encyclopedia, 2019].
Dit probleem kan voorkomen worden door gebruik te maken van de eerder genoemde
qua-ternionen. Quaternionen zijn objecten die bestaan uit vier variabelen ´e´en uit de daadwerkelijke
dimensie en drie uit de imaginaire dimensies.
Allereerst wordt een as bepaald waarover met een bepaalde hoek wordt geroteerd. Deze as wordt dan als unit vector met imaginaire componenten omschreven zoals te zien in vergelijking
2.1.
u = xi + yj + zk (2.1)
Een rotatie van een hoek van w graden kan beschreven worden door middel van de cosinus
van de helft van deze hoek van het re¨ele gedeelte plus de sinus van de helft van deze hoek maal
het imaginaire gedeelte. Dat maakt dat we met vergelijking 2.2 de quaternion voor een rotatie hebben beschreven.
q = (cosw°
2 + sin
w°
2 (u)) (2.2)
Als we punt p, bestaande uit x, y en z met imaginaire componenten willen roteren over deze as naar punt p2 dan voeren we vergelijking 2.3 uit [Kuipers et al., 1999].
p2 = q ∗ p ∗ q−1 (2.3)
Samen met de posities kunnen per tijdstip de ori¨entaties worden vergeleken op
nauwkeurig-heid. Wanneer de resultaten van deze testen een hoge nauwkeurigheid hebben, kan het virtuele object juist ten opzichte van de camera geplaatst worden.
2.2.1
IMU
De VISLAM algoritmes zoals beschreven in sectie 2.1 maken naast de camera ook gebruik van de gyroscoop en versnellingsmeter. In een telefoon, waar we met de toepassing van archeologie beschikking over hebben, is vaak een intertial measurement unit (IMU) beschikbaar. Een inertial measurement unit (IMU) is een apparaat dat bestaat uit een gyroscoop, versnellingsmeter en een magnetometer. De IMU kan zijn eigen versnelling en rotatie meten [Starlino, 2019].
HOOFDSTUK 3
Implementatie
3.1
Assumpties
Zoals eerder beschreven is het om extended tracking mogelijk te maken noodzakelijk om gebruik te maken van markerless tracking. In dit onderzoek zullen we alleen markerless tracking vergelij-ken omdat we aannemen dat de huidige technievergelij-ken voor het tracvergelij-ken met een marker al voldoende ontwikkeld zijn. Dit maakt het mogelijk om te focussen op SLAM-algoritmes.
In dit onderzoek gaan we er tevens vanuit dat het overschakelen van het tracken met mar-ker naar het marmar-kerless tracken correct verloopt. Er is dus informatie over de absolute schaal beschikbaar en het SLAM-algoritme is al ge¨ınitialiseerd.
De implementatie van de algoritmes is gedaan op een laptop en niet op een mobiele telefoon zoals voor het gebruik gewenst is. Hiermee testen we de nauwkeurigheid van de algoritmes en laten we de prestaties achterwege. Het is wel bekend dat van de drie algoritmes mobiele versies beschikbaar zijn [ORB-SLAM Android, 2018], [DSO mobile demo, 2017] en [Android-VINS, 2017] maar deze zijn voor dit onderzoek dus niet getest.
3.2
Algoritmes
Er zijn veel open-source SLAM-algoritmes te vinden, echter komt de front- en backend soms gedeeltelijk overeen. Daarom moet een keuze worden gemaakt waarin algoritmes worden gebruikt die verschillen in de interpretatie en verwerking van de beschikbare data. Tijdens de keuze is gekeken naar eerdere vergelijkingen zoals ook genoemd in sectie 1.4 en de papers van de hierna besproken algoritmes om te bepalen wat de algoritmes uniek en voor archeologie toepasbaar maken.
In tabel 3.1 is een overzicht te vinden van de verschillende eigenschappen per algoritme. De relevante eigenschappen van de algoritmes worden verder uitgelegd in secties 3.2.1, 3.2.2 en 3.2.3.
Tabel 3.1: Unieke eigenschappen van de ORB-SLAM, DSO en VINS-mono algoritmes ten op-zichte van elkaar.
Algoritme SLAM Direct/Indirect Visuele tracking Loop-detectie
ORB-SLAM Visual Indirect ORB-features Ja
DSO Visual Direct Inverse diepte Nee
VINS-mono Visual Inertial Indirect KLT Sparse Optical Flow Ja
3.2.1
ORB-SLAM
ORB-SLAM is een visual SLAM-algoritme; het maakt dus alleen gebruik van visuele aspecten. Het algoritme haalt ORB-features uit beelden en lokaliseert hiermee de camera. Met behulp van
Bundle Adjustment wordt een kaart van de omgeving gemaakt. Bovendien gebruikt ORB-SLAM loop detectie om de locatie en map aan te passen wanneer eerder gepasseerde punten worden herkend.
In de schematische weergave in figuur 3.1 zijn drie aan elkaar gelinkte onderdelen te zien, deze onderdelen tracking, local mapping en loop closing kunnen parallel aan elkaar worden uitgevoerd.
Figuur 3.1: Een schematische weergave van de componenten van het ORB-SLAM-algoritme. Uit [Mur-Artal et al., 2015].
Tracking en mapping
ORB staat voor Oriented FAST and Rotated BRIEF. Om een SLAM-algoritme realtime uit te voeren is het nodig om snel features uit een beeld te verkrijgen. Daarbij moeten de features rotatie- en schaalinvariant zijn, wanneer de camera gedraaid wordt of dichterbij komt, moeten dezelfde features herkend worden. De aanpassingen die ORB aan FAST doet, zorgen ervoor dat het algoritme sneller, rotatie en gedeeltelijk schaal invariant wordt. De feature wordt opgeslagen in een aangepaste BRIEF-feature, een feature waarmee snel gerekend kan worden maar die niet rotatie invariant is. Het ORB-algoritme zorgt dat de features rotatieinvariant zijn [Rublee et al., 2011].
Voor elk frame wordt tracking uitgevoerd, ORB-features worden gezocht en gelinkt aan de vorige keyframes. De verplaatsing van de features bepalen de geschatte beweging en de locatie van de camera wordt berekend. Het algoritme bepaalt vervolgens of het frame uniek genoeg is om een keyframe aan te maken. Keyframes zijn de frames die gebruikt worden om de kaart te updaten. Door dit niet voor elk frame te doen, heeft het algoritme minder rekenkracht nodig.
Als er een nieuw keyframe wordt aangemaakt, wordt de kaart ge¨updatet. Met behulp van een
Bundle Adjustment algoritme wordt de meest aannemelijke kaart berekend. Van de keyframes wordt de locatie opgeslagen en daarmee ook welke features op dat moment in beeld waren. Tevens wordt er een optimalisatie uitgevoerd waardoor overbodige features in de kaart worden verwijderd.
Loop closing
In het loop closing proces wordt telkens als een nieuw keyframe wordt aangemaakt, gezocht naar loops, ofwel, bevindt de camera zich op een plek waar hij eerder is geweest. Als dit zo is, wordt de kaart herberekend met behulp van een similarity transformatie en worden dubbele punten en onnodige keyframes verwijderd [Mur-Artal et al., 2015].
Resultaat
Als resultaat van het algoritme krijgen we de camera poses terug van het moment dat ze berekend waren. Loop closing heeft dus effect, maar alleen op de punten die gevonden zijn nadat een loop gevonden is. Dit is het gewenste resultaat, het virtuele object kan in real-time immers niet met terugwerkende kracht worden verplaatst.
Het algoritme is met name uniek door de loop closing en het gebruik van de ORB-features. Loop closing kan bij grote verplaatsingen van de camera een uitkomst bieden en het model terug op de juiste plaats plaatsen, een eigenschap wenselijk voor de afdeling Archeologie.
3.2.2
DSO
DSO staat voor Direct Sparse Odometry en is net als ORB-SLAM een visual SLAM-algoritme. In plaats van gebruik te maken van indirecte features werkt DSO met een directe aanpak. Dit houdt in dat het gebruikmaakt van de volledige afbeelding, de intensiteit van pixels, om de locatie en omgeving te bepalen. Deze methode kan daardoor met meer data werken dan een methode die de afbeeldingen opslaat als een een lijst van features. Een schematische weergave van het verschil is te zien in afbeelding 3.2.
Figuur 3.2: Het verschil tussen een SLAM-algoritme op basis van features en een directe aanpak schematisch weergeven. Uit [Engel et al., 2015].
Tracking en mapping
DSO bepaalt de locatie door het minimaliseren van de fotometrische fout van punten ten opzichte van een eerder verwerkt frame. De fotometrische fout van een punt wordt berekend met behulp van een gewogen sum of squared differences (SSD) over een kleine subset van pixels. De SSD berekent een optelling van het kwadraat van het verschil van intensiteit van de pixels tussen twee afbeeldingen. Het punt wordt vervolgens gekarakteriseerd met de inverse diepte van de pixel.
De tracking vindt net als bij ORB-SLAM plaats ten opzichte van vorige keyframes. De trac-king gebeurt zoals hierboven beschreven per frame met behulp van de fotometrische fout. Als er
een nieuw keyframe wordt aangemaak,t zal de kaart worden ge¨update met de extra diepteinfor-matie uit het nieuwe keyframe.
Bij DSO worden maximaal zeven keyframes bewaard in plaats van dat ze pas verwijderd worden als ze als nutteloos worden beschouwd. Dit wordt ook wel een sliding window genoemd. Hierdoor kan DSO geen gebruikmaken van loop closing; de historie die wordt bijgehouden is maar beperkt [Engel et al., 2017].
Resultaat
Omdat geen gebruikgemaakt wordt van loop closing kunnen we direct de cameraposities van het algoritme gebruiken voor de vergelijking. Deze verkrijgen we door alle keyframe posities tussentijds op te slaan, deze zijn immers gelijk aan de camerapositie van dat moment.
Doordat het algoritme een directe in plaats van indirecte aanpak heeft, zou het met name in situaties met minder textuur een ander resultaat moeten opleveren dan de overige twee algorit-mes. Iets wat voor kan komen als we bijvoorbeeld in een omgeving in de buitenlucht Augmented Reality willen gebruiken.
3.2.3
VINS-mono
VINS-mono maakt naast de camera ook gebruik van de IMU van een telefoon. Hiermee is het dus een Visual Inertial SLAM-algoritme. Voor het visuele aspect maakt VINS-mono gebruik van het KLT-optical flow algoritme. Net als bij ORB-SLAM wordt Bundle Adjustment gebruikt om een kaart van de omgeving te maken voor het visuele gedeelte. De metingen uit de IMU worden samengevoegd met de visuele schatting en er vindt herlokalisatie plaats. In afbeelding 3.3 is een schematische weergave van het algoritme te zien.
Figuur 3.3: Een schematische weergave van de componenten van het VINS-mono-algoritme. De secties in de afbeelding zijn de originele secties uit de paper waarin het algoritme wordt gepresenteerd. Uit [Qin et al., 2018].
Tracking en mapping
Het tracken gebeurt met behulp van het KLT-optical flow algoritme, dat bestaande features vanuit het laatste keyframe probeert te zoeken in het nieuwe frame.
Optical flow berekent de beweging van objecten in beelden. Wanneer de camera beweegt, zullen objecten die zich dichter bij de camera bevinden sneller door het beeld bewegen dan objecten die zich verder weg bevinden. Op die manier kan de relatieve afstand tussen deze objecten en de camera worden geschat. De KLT-feature tracker maakt hier gebruik van door op
Een nieuw keyframe wordt aangemaakt als deze volgens de tracking ver genoeg van het vorige
keyframe af ligt of een minimale hoeveelheid rotatie heeft plaatsgevonden. Mochten weinig
features gevonden worden dan wordt het frame ook automatisch als keyframe behandeld. De metingen van de IMU gebeuren op een hogere frequentie dan dat de frames
binnenko-men. Verschillende metingen worden om die reden aan ´e´en frame gekoppeld. Vervolgens worden
de kaart en positie van de camera geoptimaliseerd met behulp van een visual inertial Bundle Adjustment algoritme.
Loop closing
Net als bij ORB-SLAM wordt telkens wanneer een nieuw keyframe aangemaakt wordt, gekeken of een loop heeft plaatsgevonden. Dit gebeurt op basis van extra features die worden opgeslagen als BRIEF features. Wanneer een loop wordt gevonden zal de kaart worden uitgelijnd [Qin et al., 2018].
Resultaten
Ook bij dit algoritme gebruiken we voor de vergelijking de cameraposes op het moment dat ze werden berekend.
Het unieke aan dit algoritme is dat het gebruikmaakt van zowel de IMU als de camera, iets wat de nauwkeurigheid zou moeten verhogen ongeacht wat voor beelden te zien zijn.
3.3
Basis applicatie
Om ongeacht het resultaat van dit onderzoek extended tracking mogelijk te maken voor de afdeling Archeologie van de Universiteit van Amsterdam is er een basis applicatie ontwikkeld. Deze applicatie moet naast het markerless tracken ook de overige tracking functies van een extended tracking applicatie uitvoeren.
Momenteel maakt de afdeling Archeologie van de Universiteit van Amsterdam gebruik van
Augmented Reality platform Vuforia in combinatie met Unity. Extended tracking is hierin
mogelijk maar het platform heeft limieten met het aantal markers dat gebruikt kan worden [Vuforia, Extended Tracking, 2019].
Het is wenselijk om het verschil tussen de oude en de nieuwe applicatie voor de gebruikers die de modellen aan de markers moeten koppelen zo klein mogelijk te houden. Om die reden is het wenselijk om de applicatie wederom in Unity te ontwikkelen. Daarom is er gekozen om te werken met Augmented Reality platform ARCore. ARCore werkt ook in combinatie met Unity maar onderscheidt zich van Vuforia door het niet hebben van limieten [ARCore, 2019].
3.3.1
ARCore
ARCore is het Augmented Reality platform dat ontwikkeld is door Google. Zelf deelt Google het platform op in drie onderdelen, motion tracking, environmental understanding en light estimation. Motion tracking wordt beschreven als concurrent odometry and mapping iets wat we als bredere term van SLAM kunnen interpreteren. Motion tracking gebeurt aan de hand van de camera en de IMU.
Environmental understanding probeert vlakken te herkennen om hier tijdens de Augmented Reality interactie mee uit te voeren. Hiermee wordt de visualisatie zo realistisch mogelijk gemaakt en kan er bijvoorbeeld gebruik worden gemaakt van occlusie.
Ook light estimation draagt bij aan de hoeveelheid realisme die de virtualisatie heeft. Door het correct schatten van het licht kunnen 3D-modellen betere interactie uitvoeren met de omgeving. Naast dat ARCore voor Unity beschikbaar is zou het ook gebruikt kunnen worden op iOS, Unreal Engine, Android NDK en Android. Een nadeel van ARCore is dat alleen door Google goedgekeurde telefoons gebruik mogen maken van ARCore. De lijst met goedgekeurde telefoons groeit weliswaar maar bestaat voornamelijk uit nieuwe high-end modellen [ARCore, 2019].
3.3.2
Initialisatie
De initialisatie is gebaseerd op de in 2018 ontworpen methode door Canella [Cannella, 2018]. Hierin wordt het detecteren van vlakken gecombineerd met het herkennen van markers om de
juiste ori¨entatie te bepalen.
Allereerst wordt de ori¨entatie van de grond bepaald. Dit gebeurt met behulp van vlakken
die ARCore in het beeld zoekt. Zoals te zien in de linker afbeelding van figuur 3.4 worden de horizontale vlakken die ontdekt worden door de applicatie gevisualiseerd. De gebruiker selecteert
het vlak dat dezelfde ori¨entatie heeft als de grond. Deze ori¨entatie wordt gebruikt om de assen
van het model uit te lijnen, de verticale as komt loodrecht op het vlak te liggen.
Figuur 3.4: Initialisatie van de ARCore basis applicatie. Links is te zien hoe ARCore het
gedetecteerde vlak visualiseert. De rechter afbeelding is wat de gebruiker te zien krijgt na het selecteren van het grondvlak. De gebruik wordt gevraagd de marker uit te lijnen met de witte hoeken die te zien zijn in het scherm.
Daarna wordt er gebruikgemaakt van een marker waarvan de afmetingen bekend zijn. Het middelpunt van deze marker moet worden neergelegd op de plek waar het nulpunt van het model in de visualisatie terecht moet komen zoals te zien in de rechter afbeelding van figuur 3.4. Zodra ARCore de marker herkent, kan de juiste schalingsfactor worden berekend, het is immers bekend hoe groot de marker in de fysieke wereld is. Met de informatie over de marker uit het beeld kan ook de juiste positie van het model worden bepaald. Het laatste wat wordt berekend is de
ori¨entatie om de verticale as ten opzichte van het grondvlak. Hiervoor wordt de pose quaternion
van het grondvlak naar de pose quaternion van de marker geroteerd waarna alleen de y component uit deze rotatie gebruikt wordt.
Het model kan dan worden weergeven zoals te zien in de linker afbeelding van figuur 3.5.
3.3.3
Markerless tracking
ARCore maakt op de positie van de marker een zogeheten anker aan. Deze marker is het
referentiepunt van ARCore voor het plaatsen van het model. Wanneer de marker niet meer in beeld is, berekent ARCore de locatie van het anker aan de hand van omliggende features. Het model kan op deze manier nog steeds op de juiste positie worden geplaatst zoals te zien in de rechter afbeelding van figuur 3.5. ARCore is dus in staat om extended tracking uit te voeren.
Figuur 3.5: De visualisatie van een model aan de hand van een marker. Links is de marker in beeld en wordt het model hierop geplaatst. Rechts is de marker niet meer in beeld maar de visualisatie wordt met behulp van markerless tracking alsnog correct weer gegeven.
3.3.4
Metingen
Om de basis applicatie te kunnen vergelijken met de open-source algoritmes die in dit onderzoek gebruikt worden, zal de pose van de applicatie opgeslagen moeten worden. De Frame klasse die zich in Unity bevindt, wordt hiervoor gebruikt. Deze klasse bevat tot op vijf centimeter precies
de pose van het apparaat ten opzichte van de Unity Co¨ordinaten. Samen met de tijd-stempel
HOOFDSTUK 4
Experimenten
4.1
Opzet
De verschillende algoritmes zullen aan een aantal testen worden onderworpen om de nauwkeu-righeid te vergelijken. Uit elk algoritme verkrijgen we een reeks poses zoals ook beschreven in sectie 2.2. Van elke pose is ook het tijdstip bekend.
ORB-SLAM en DSO maken alleen gebruik van de camerabeelden terwijl VINS-mono en ARCore ook de IMU-data gebruiken. Als we de nauwkeurigheid van de algoritmes willen testen, hebben we de groundtruth (daadwerkelijke waarheid) van deze data nodig. De berekende poses kunnen dan met de groundtruth poses worden vergeleken om hierover een oordeel te vormen.
De experimenten kunnen we in twee categorie¨en verdelen. Allereerst zullen we de drie
open-source algoritmes, ORB-SLAM, DSO en VINS-mono, testen met behulp van een aantal datasets. Deze datasets bevatten een accurate groundtruth voor de evaluatie.
In het tweede soort experiment zullen we de applicatie zoals beschreven in sectie 3.3 testen ten opzichte van de drie algoritmes. Aangezien ARCore niet met van te voren gegenereerde
datasets kan werken, cree¨eren we voor de tweede reeks testen zelf een dataset terwijl de basis
applicatie live wordt uitgevoerd. De gegenereerde dataset kan dan achteraf gebruikt worden op de andere drie algoritmes. De groundtruth hiervan is een stuk minder accuraat omdat we dit slechts baseren op een beperkt aantal punten.
4.2
Data
De data die we in dit onderzoek gebruiken, moet te vergelijken zijn met data die zou worden verkregen door een toepassing zoals beschreven in sectie 1.1. Om hiermee overeen te komen stellen we vier criteria op:
1. De data moet in een omgeving buiten zijn opgenomen.
2. De data moet opgenomen zijn door een in de hand gehouden apparaat. 3. De data moet zowel translatie als rotatie bevatten.
4. Over het gehele traject is een continue groundtruth beschikbaar.
4.2.1
Dataset
Voor het VINS-mono algoritme is naast camera ook IMU-data nodig. De dataset moet dus geschikt zijn om visual-inertial SLAM mee uit te voeren.
Op basis hiervan zijn twee datasets geselecteerd, de TUM VI Benchmark for Evaluating Visual-Inertial Odometry [Schubert et al., 2018] en de PennCOSYVIO Dataset [Pfrommer et al., 2017].
Figuur 4.1: Een still uit scene room1 uit de TUM VI Benchmark dataset. Uit [Schubert et al., 2018]
De TUM VI Benchmark bestaat uit 28 scenes waarvan er van zes een groundtruth beschikbaar
is met ´e´en millimeter nauwkeurigheid voor het gehele traject. Van de andere scenes bestaat
slechts een gedeeltelijke groundtruth, deze zullen we dan ook niet gebruiken. De zes scenes die we gebruiken zijn opgenomen met een in de hand gehouden apparaat en bevatten zowel translatie als rotatie. De scenes zijn binnen opgenomen, hierdoor voldoen deze scenes alleen aan punt 2, 3 en 4 van de opgestelde criteria. Een still uit een van de gebruikte scenes is te zien in figuur 4.1.
Figuur 4.2: Een still uit een bscene a fast uit de PennCOSYVIO dataset. Uit [Pfrommer et al., 2017]
Uit de PennCOSYVIO Dataset gebruiken we de scenes die vanuit de hand buiten zijn op-genomen. De data bevat translatie en rotatie maar is met vijftien centimeter een stuk minder nauwkeurig dan de TUM VI Benchmark. We stellen daarom dat de dataset voldoet aan punt 1, 2, 3. Ongeacht de nauwkeurigheid stellen we dat hij ook voldoet aan punt 4, we dienen echter wel rekening te houden met de afwijking bij het verwerken van de resultaten. Een still uit een van de gebruikte scenes is te zien in figuur 4.2.
4.2.2
Eigen data
De eigen data wordt verkregen door de camera-, gyroscoop- en versnellingsmeter data van een Xiaomi Mi 9 op te nemen. Dit gebeurt met behulp van de Android applicatie Multisensor-grabber
nemen en te koppelen aan een afbeelding met tijd-stempel. De data is buiten opgenomen met behulp van een telefoon en er vindt zowel translatie als rotatie plaats.
De eigen data wordt ook getest door onze ARCore basis applicatie op een Galaxy S8. Omdat ARCore geen functionaliteit biedt om vooraf gegenereerde data te gebruiken wordt tegelijkertijd met het opnemen van de dataset een basis ARCore applicatie uitgevoerd.
Figuur 4.3: 3D-geprint mobiele houder om met twee telefoons tegelijkertijd opnamens te kunnen maken.
De twee telefoons die gebruikt zijn, zijn in een 3D-geprinte houder geplaatst zoals ook te zien in figuur 4.3 waardoor de twee telefoons synchroon zullen bewegen. Op de grond is een rooster
aangebracht met vakken van ´e´en meter bij ´e´en meter met elke 50 centimeter een markering
zoals te zien in 4.4. Over dit rooster is een route uitgevoerd waarbij de camera stil staat op
verschillende kruispunten. Op de kruispunten wordt het tijdstip en de ori¨entatie genoteerd. De
groundtruth die hiermee wordt gecre¨eerd is een stuk minder accuraat dan bij de eerder genoemde
datasets en is niet continu en voldoet niet aan criteria 4. De data voldoet wel aan de punten 1, 2 en 3. Een overzicht van de datasets en de genoemde criteria is te vinden in tabel 4.1.
Figuur 4.4: Locatie waar de eigen data verkregen is. Op de grond is een raster met vakken van ´
Tabel 4.1: Overzicht van de criteria uit de lijst in sectie 4.2. Dataset 1. Buiten opgenomen 2. In de hand gehouden 3. Translatie en rotatie 4. Continue groundtruth
TUM VI Benchmark Nee Ja Ja Ja (1 mm)
PennCOSYVIO Dataset Ja Ja Ja Ja (15 cm)
Eigen verkregen data Ja Ja Ja Nee
4.3
Experimenten
4.3.1
Datasets
De data uit de datasets kan vervolgens worden verwerkt door de drie verschillende algoritmes. De algoritmes worden alle drie uitgevoerd op een laptop omdat deze flexibiliteit biedt in het
aanleveren van tevoren gegenereerde beelden. Voor alle hierna genoemde experimenten zijn
de standaard parameter instellingen van de algoritmes gebruikt, dit houdt in dat ORB-SLAM en DSO beide 2000 punten tegelijkertijd tracken en VINS-mono er 150 bijhoudt. De overige standaard parameters voor ORB-SLAM, DSO en VINS-mono zijn respectievelijk te vinden in [ORB-SLAM parameter file, 2016], [DSO parameter file, 2016], en [VINS parameter file, 2018].
Voor het uitvoeren van de algoritmes zijn verschillende parameters nodig. De intrinsieke parameters van een camera bevatten de brandpuntafstand en het optisch middelpunt. Met deze
parameters kunnen cameraco¨ordinaten worden omgezet in pixelco¨ordinaten. Distortieparameters
worden gebruikt om het beeld van bijvoorbeeld een fish-eye te corrigeren. De parameters worden door de dataset aangeleverd.
Voor VINS-mono zijn ook nog de extrinsieke parameters nodig die de camera transleren en
roteren naar de IMU zodat met hetzelfde co¨ordinatenstelsel gerekend wordt.
De resultaten zijn lijsten met tijdstippen en quaternionen van de geschatte locatie en ori¨entatie.
De resultaten van ORB-SLAM en DSO zijn echter niet geschaald, aangezien deze geen notie van absolute maar alleen van relatieve schaal hebben. Daarom worden deze voor de evaluatie ge-schaald, getrans- en geroteerd naar de groundtruth met behulp van het Least-Squares Estimation of transformation parameters algoritme. Dit algoritme zoekt de transformatie die de twee tra-jecten het beste met elkaar overeen laat komen, zonder dat er relatief gezien in het traject iets verandert [Umeyama, 1991]. VINS-mono weet dankzij het gebruik van de IMU wel de absolute schaal en hoeft hierdoor alleen maar te worden getrans- en geroteerd.
4.3.2
Eigen data
Voor de eigen gecre¨eerde data moeten de parameters worden berekend. Dit gebeurt met behulp
van Kalibr [Kalibr, 2018]. Vervolgens worden de drie open-source algoritmes op deze data uitge-voerd. De resultaten hiervan kunnen worden vergeleken met de live verkregen data van Google ARCore en de genoteerde groundtruth.
Het schalen en transleren van de resultaten gebeurt op basis van de groundtruth met wederom het Least-Squares Estimation of transformation parameters algoritme [Umeyama, 1991]. Belang-rijk om mee tenemen in de evaluatie is dat de data verkregen uit ARCore een nauwkeurigheid van vijf centimeter heeft, nauwkeuriger kan de data niet worden verkregen.
4.4
Resultaten
De resultaten worden op verschillende manier ge¨evalueerd om de nauwkeurigheid te bepalen.
Voor zowel de resultaten uit de TUM VI Benchmark en de PennCOSYVIO zullen we eerst de
absolute ori¨entatiefout (APE, Absolute Pose Error) van zowel de translatie als de rotatie bepalen.
Deze fout geeft aan hoeveel meter of graden verschil er is met de ori¨entatie op dit tijdstip met
de groundtruth. Voorbeelden van de evolutie van de APE over tijd van een scene uit de TUM VI dataset zijn te zien in figuren 4.5 (translatie) en 4.6 (rotatie).
De tweede evaluatie van dezelfde datasets is de relatieve ori¨entatiefout (RPE, Relative Pose Error), hiermee wordt per tijdvak de zogeheten drift berekend. Hoeveel meter of graden afwijking is er in dat tijdvak ontstaan. Voorbeelden van de evolutie van de APE over tijd van een scene uit de TUM VI dataset zijn te zien in figuren 4.7 (translatie) en 4.8 (rotatie). De resultaten komen
als poses en zowel de co¨ordinaten als de quaternionen zullen met elkaar vergeleken moeten worden
om de RPE en APE te verkrijgen. Deze resultaten worden vervolgens ge¨evalueerd met behulp
van Evo [Grupp, 2017].
Vervolgens zullen we de RPE die verkregen is in de TUM VI Benchmark evaluatie uitzetten tegenover de snelheid om te bepalen of translatie- en rotatiesnelheid van invloed is op de fout.
Van de resultaten die verkregen worden uit de eigen data wordt bekeken of ze de punten van de groundtruth hebben gepasseerd, als dit zo is worden ze meegenomen in de vergelijking. Vanwege de onnauwkeurigheid van de groundtruth en het geringe aantal punten in de groundtruth kan er geen betrouwbare RPE of APE worden berekend. Om deze reden zal ARCore verder alleen tegen de drie algoritmes worden uitgezet.
Alle drie de open-source algoritmes zijn non-deterministisch mede dankzij het gebruik van multi-threading en de geforceerde realtime uitvoer [Caruso et al., 2015]. Elk algoritme wordt daarom vijf keer uitgevoerd waarna het gemiddelde van de gemiddelde kwadratische fout per scene wordt berekend.
De RPE wordt vervolgens gebruikt om te kijken hoeveel invloed snelheid en rotatie op de drift hebben.
20 40 60 80 100 120 140 t (s) 0.00 0.05 0.10 0.15 0.20 0.25 APE (m)
Absolute Ori¨entatie Fout van translatie in meters
ORB DSO VINS
Figuur 4.5: De Absolute Ori¨entatie Fout (APE) van translatie van ORB-SLAM, DSO en
VINS-MONO ten opzichte van de groundtruth tegenover de tijd in scene room1 van [Schubert et al., 2018]. 20 40 60 80 100 120 140 t (s) 0 1 2 3 4 5 6 APE (deg)
Absolute Ori¨entatie Fout van rotatie in graden
ORB DSO VINS
Figuur 4.6: De Relatieve Ori¨entatie Fout (RPE) van rotatie met een delta van ´e´en meter van
ORB-SLAM, DSO en VINS-MONO ten opzichte van de groundtruth tegenover de tijd in scene room1 van [Schubert et al., 2018].
20 40 60 80 100 120 t (s) 0.00 0.05 0.10 0.15 0.20 RPE (m)
Relatieve Ori¨entatie Fout van translatie in meters met delta = 1 (meter)
ORB DSO VINS
Figuur 4.7: De Absolute Ori¨entatie Fout (APE) van translatie van ORB-SLAM, DSO en
VINS-MONO ten opzichte van de groundtruth tegenover de tijd in scene room1 van [Schubert et al., 2018]. 20 40 60 80 100 120 140 t (s) 0 1 2 3 4 5 6 RPE (deg)
Relatieve Ori¨entatie Fout van rotatie in graden met delta = 1 (graden)
ORB DSO VINS
Figuur 4.8: De Relatieve Ori¨entatie Fout (RPE) van rotatie met een delta van ´e´en graden van
ORB-SLAM, DSO en VINS-MONO ten opzichte van de groundtruth tegenover de tijd in scene room1 van [Schubert et al., 2018].
4.4.1
TUM VI Benchmark
De gemiddelde resultaten van het vijf keer het uitvoeren van de algoritmes voor de APE en RPE van de translatie en rotatie zijn te vinden in figuren 4.9, 4.10, 4.11 en 4.12. Voor de RPE is een
delta van ´e´en meter bij translatie en ´e´en graden bij rotatie gebruikt.
4.4.2
PennCOSYVIO
De gemiddelde resultaten van het vijf keer het uitvoeren van de algoritmes voor de APE en RPE van de translatie en rotatie zijn te vinden in figuren 4.13, 4.14, 4.15 en 4.16. Voor de RPE is een
delta van ´e´en meter bij translatie en ´e´en graden bij rotatie gebruikt.
Het ORB-SLAM-algoritme slaagde er geen enkele keer in om de tracking tot het einde vast
te houden. De tracking is verloren gegaan op het punt dat er een rotatie van meer dan 360°
plaatsvond. Hetzelfde geldt voor het DSO-algoritme waarbij dit in scene a fast en b fast gebeurde.
Bij b slow raakte de tracking drie van de vijf keer verloren bij de draai van 360° en twee keer bij
een latere draai van 270°. Bij scene a slow slaagde DSO er wel in om vijf keer het gehele traject
room1 room2 room3 room4 room5 room6 0 5 10 15 20 APE (cm)
Absolute Ori¨entatie Fout van translatie in centimers
(gemiddelde rmse van vijf uitvoeringen) ORB-SLAM
DSO VINS-MONO
Figuur 4.9: De gemiddelde Absolute Ori¨entatie Fout (APE) van translatie als rmse in centimeters
van vijf uitvoeringen van de zes verschillende scenes van de TUM VI Benchmark. De zwarte streep weergeeft de standaardafwijking van de uitvoeringen.
room1 room2 room3 room4 room5 room6 0 1 2 3 4 5 6 7 APE van rotatie (graden)
Absolutie Ori¨entatie Fout van rotatie in graden
(gemiddelde rmse van vijf uitvoeringen) ORB-SLAM
DSO VINS-MONO
Figuur 4.10: De gemiddelde Absolute Ori¨entatie Fout (APE) van rotatie als rmse in graden van
vijf uitvoeringen van de zes verschillende scenes van de TUM VI Benchmark. De zwarte streep weergeeft de standaardafwijking van de uitvoeringen.
room1 room2 room3 room4 room5 room6 0 2 4 6 8 10 12 RPE van rotatie (cm)
Relatieve Ori¨entatie fout van translatie in centimeters
delta = 100 (centimeter) (gemiddelde rmse van vijf uitvoeringen)
ORB-SLAM DSO VINS-MONO
Figuur 4.11: De gemiddelde Relatieve Ori¨entatie Fout (RPE) van translatie als rmse in
centime-ters met een delta van 100 centimeter van vijf uitvoeringen van de zes verschillende scenes van de TUM VI Benchmark. De zwarte streep weergeeft de standaardafwijking van de uitvoeringen.
room1 room2 room3 room4 room5 room6 0.0 0.2 0.4 0.6 0.8 1.0 1.2 RPE van rotatie (graden)
Relatieve Ori¨entatie Fout van rotatie in graden
delta = 1 (graden) (gemiddelde rmse van vijf uitvoeringen)
ORB-SLAM DSO VINS-MONO
Figuur 4.12: De gemiddelde Relatieve Ori¨entatie Fout (RPE) van rotatie als rmse in graden van
vijf uitvoeringen met een delta van ´e´en graden van de zes verschillende scenes van de TUM VI
a fast a slow b fast b slow 0 100 200 300 400 500 APE (cm)
Absolute Ori¨entatie Fout van translatie in centimers
(gemiddelde rmse van vijf uitvoeringen)
DSO VINS-MONO
Figuur 4.13: De gemiddelde Absolute Ori¨entatie Fout (APE) als rmse in centimeters van vijf
uitvoeringen van vier verschillende scenes uit de PennCOSYVIO dataset. De zwarte streep
weergeeft de standaardafwijking van de uitvoeringen.
a fast a slow b fast b slow 0 5 10 15 20 25 30 APE van rotatie (graden)
Absolutie Ori¨entatie Fout van rotatie in graden
(gemiddelde rmse van vijf uitvoeringen)
DSO VINS-MONO
Figuur 4.14: De gemiddelde Absolute Ori¨entatie Fout (APE) als rmse in graden van vijf
uit-voeringen van van vier verschillende sc`enes uit de PennCOSYVIO dataset. De zwarte streep
a fast a slow b fast b slow 0 50 100 150 200 250 RPE van rotatie (cm)
Relatieve Ori¨entatie fout van translatie in centimeters
delta = 100 (centimeter) (gemiddelde rmse van vijf uitvoeringen)
DSO VINS-MONO
Figuur 4.15: De gemiddelde Relateieve Ori¨entatie Fout (RPE) van translatie als rmse in
centime-ters met een delta van 100 centimeter van vijf uitvoeringen van van vier verschillende sc`enes uit de
PennCOSYVIO dataset. De zwarte streep weergeeft de standaardafwijking van de uitvoeringen.
a fast a slow b fast b slow 0 1 2 3 4 RPE van rotatie (graden)
Relatieve Ori¨entatie Fout van rotatie in graden
delta = 1 (graden) (gemiddelde rmse van vijf uitvoeringen)
DSO VINS-MONO
Figuur 4.16: De gemiddelde Relatieve Ori¨entatie Fout (RPE) van rotatie als rmse in graden
van vijf uitvoeringen met een delta van ´e´en graden van van vier verschillende sc`enes uit de
4.4.3
Translatie- en rotatiesnelheid
De RPE die verkregen is uit de TUM VI Benchmark scenes is uitgezet tegen zowel de translatie-als de rotatiesnelheid. De translatiesnelheid is berekend met behulp van de groundtruth en vervolgens zijn de paren tussen waar de RPE is berekend gekoppeld aan de juiste snelheid aan de hand van de tijd-stempel. De resultaten voor de translatiesnelheid zijn te vinden in figuur 4.17. In figuur 4.18 staat de rotatie RPE uitgezet tegen over de rotatiesnelheid. Elk algoritme bepaalt op verschillende punten en dus op verschillende snelheden zijn pose. Hierdoor verschillen de hoeveelheid metingen per snelheidsreeks en kan het voorkomen dat niet elk algoritme voor elke snelheidsreeks een fout kan bepalen.
0.00-0.10 0.10-0.20 0.20-0.30 0.30-0.40 0.40-0.50 0.50-0.60 0.60-0.70 0.70-0.80 0.80-0.90 0.90-1.00 1.00-1.10 1.10-1.20 1.20-1.30 1.30-1.40 1.40-1.50 1.50-1.60 1.60-1.70 1.70-1.80 1.80-1.90 1.90-2.00 2.00-2.10 2.10-2.20 2.20-2.30 2.30-2.40 2.40-2.50 2.50-2.60
T
ransla
ti
es
nelheidsreeks
(m/s)
0 .000 0 .025 0 .050 0 .075 0 .100 0 .125 0 .150 0 .175 0 .200RPE(m)
Relatieve
Ori
¨entatie
F
out
p
er
translatiesnelheidsreeks
delta
=
1
(meter)
ORB-SLAM DSO VINS-MONO
4.17: Gemiddelde Relatiev e Ori ¨en tatie F out (RPE) v an translatie p er translatiesnelheidsreeks gebaseerd op de b erek ende RPE v an de TUM VI hmark met een delta v an ´e ´en meter. De middellijn p er b o x is de mediaan, w aar na z ic h het eerste en derde kw artiel aan de buitenzijde v an de b o x evinden. De w h isk ers gev en de minimale en de maximale geobs erv eerde w aarde aan met een maxim um v an 1.5 k eer de b o xgro otte.
0.00-2.00 2.00-4.00 4.00-6.00 6.00-8.00 8.00-10.00 10.00-12.00 12.00-14.00 14.00-16.00 16.00-18.00 18.00-20.00 20.00-22.00 22.00-24.00 24.00-26.00 26.00-28.00 28.00-30.00 30.00-32.00 32.00-34.00 34.00-36.00 36.00-38.00 38.00-40.00 40.00-42.00 42.00-44.00 44.00-46.00 46.00-48.00 48.00-50.00 50.00-52.00
Rotatiesnelheidsreeks
(graden/s)
0 .00 0 .02 0 .04 0 .06 0 .08 0 .10 0 .12RPE(graden)
Relatieve
Ori
¨entatie
F
out
p
er
rotatiesnelheidsreeks
delta
=
1
(gr
a
den)
ORB-SLAM DSO VINS-MONO
Figuur 4.18: Gemiddelde Relatiev e Ori ¨en tatie F out (RPE) v an rotatie p er rotat ie snelheid sreeks gebase erd op de b erek ende RPE v an de TUM VI Benc hmark met ee n delta v an ´e ´en graden. De middellijn p er b o x is de mediaan, w aarna zic h het eerste en derde kw artiel aan de b uitenzijde v an de b o x b evinden. De whisk ers gev en de minimale en de maximale geobserv eerde w aarde aan met een maxim um v an 1.5 k eer de b o xgro otte.
4.4.4
Eigen data
ORB-SLAM verloor de tracking tijdens het uitvoeren van de eigen dataset. Zowel VINS-mono als DSO wisten de scene wel vijf maal te voltooien. Deze algoritmes en de ARCore applicatie hebben allen de tien punten uit de groundtruth doorkruist.
In figuur 4.19 is een voorbeeld te zien van hoe de x- en y- en z-co¨ordinaten van de open-source
algoritmes zich in verloop van tijd ontwikkelen tegenover dezelfde co¨ordinaten van de uitvoer van
de ARCore basis applicatie.
−4 −2 0
x
(m)
Verplaatsing over de x-as ten opzichte van de tijd
ARCore VINS-mono DSO −0.6 −0.4 −0.2 0.0 y (m)
Verplaatsing over de y-as ten opzichte van de tijd
0 20 40 60 80 100 120 140 t (s) −2 0 2 4 6 z (m)
Verplaatsing over de z-as ten opzichte van de tijd
Figuur 4.19: De verplaatsing over de x-, y-, en z-as in meters van het ARCore, VINS-mono en DSO algoritme op de eigen verkregen data.
HOOFDSTUK 5
Conclusie
Om extended tracking mogelijk te maken, moet de locatie en ori¨entatie van het gebruikte
ap-paraat realtime bijgehouden worden. Voor de toepassing binnen het archeologie domein hebben wij hiervoor beschikking over een camera, gyroscoop en versnellingsmeter die zich in een telefoon bevinden.
Met behulp van deze databronnen kunnen SLAM-algoritmes worden ingezet om het mar-kerless tracking onderdeel op te pakken. De drie open-source algoritmes, ORB-SLAM, DSO en VINS-MONO lossen het SLAM-probleem elk op hun eigen manier op.
Uit de metingen van hoofdstuk 4 blijkt dat VINS-mono de hoogste gemiddelde APE van translatie heeft. DSO heeft in de meeste situaties van de TUM VI Benchmark de laagste gemid-delde APE van zowel translatie als rotatie zoals te zien in figuren 4.9 en 4.10. Uit figuur 4.11 blijkt dat de gemiddelde RPE van translatie per meter voor ORB-SLAM tussen de 1.6 en 9.1 centimeter ligt. Voor DSO is de gemiddelde RPE van translatie maximaal 5,9 centimeter en voor VINS-mono 6,4 centimeter. Wat DSO en VINS-mono in termen van drift een stuk nauwkeuriger maakt dan ORB-SLAM.
In figuren 4.17 en 4.18 is te zien dat een hogere translatie- of rotatiesnelheid bij VINS-MONO meer onnauwkeurige data veroorzaakt dan bij DSO. Echter is VINS-MONO het enige algoritme dat in staat is de tracking te blijven vervolgen na een grote rotatie. Zowel DSO als ORB-SLAM wisten de tracking niet in elke situatie te behouden zoals blijkt uit de metingen van sectie 4.4.2. Van de geteste open-source algoritmes is VINS-MONO het enige algoritme dat betrouwbaar gebruikt kan worden. De resultaten zullen in sommige gevallen beter zijn met het gebruik van DSO maar er wordt geen risico gelopen om de tracking compleet te verliezen.
De vergelijking met ARCore laat zien dat de resultaten van ARCore grotendeels gelijk lopen met die van VINS-mono en DSO. Een gebrek aan een goede groundtruth maakt het echter onmogelijk om te bepalen welk algoritme in deze situatie de minst grote fout geeft.
VINS-mono is de meest betrouwbare open-source techniek die in dit onderzoek is vergeleken en kan gebruikt worden om extended tracking mogelijk te maken in het archeologie domein zonder hierbij een grote relatieve fout te introduceren.
5.1
Toekomstig werk
In dit onderzoek zijn zowel VISLAM en VSLAM als indirecte en directe algoritmes onderzocht. Een combinatie van VISLAM en de directe aanpak is echter niet meegenomen. Gezien de pres-taties van DSO en VINS-mono relatief goed waren ten opzichte van de indirecte VSLAM zou een vergelijking met een direct VISLAM algoritme tot nieuwe inzichten kunnen leiden.
ARCore is niet even nauwkeurig getest als de drie open-source algoritmes waardoor hier geen goede conclusie over getrokken kan worden. In een vervolgonderzoek kan dit samen met de prestaties van de algoritmes op een mobiele telefoon worden gekoppeld om te analyseren welk algoritme in de praktijk het beste gebruikt kan worden.
toepasbaar is binnen het onderzoek. Aanpassingen aan de applicatie zijn hier nog wel voor nodig, de groep van archeologische experts wil immers ook aantekeningen kunnen maken en data op een overzichtelijke manier kunnen opslaan en presenteren [Eggert et al., 2014].
Bibliografie
[Amin and Govilkar, 2015] Amin, D. and Govilkar, S. (2015). Comparative study of augmented reality sdks. International Journal on Computational Science & Applications, 5(1):11–26.
[Android-VINS, 2017] Android-VINS (2017). Android-vins. https://github.com/
heguixiang/Android-VINS. Username: heguixiang.
[ARCore, 2019] ARCore, G. (2019). Arcore overview. https://developers.google.com/ar/ discover/.
[Bailey and Durrant-Whyte, 2006] Bailey, T. and Durrant-Whyte, H. (2006). Simultaneous loca-lization and mapping (slam): Part ii. IEEE Robotics & Automation Magazine, 13(3):108–117. [Cadena et al., 2016] Cadena, C., Carlone, L., Carrillo, H., Latif, Y., Scaramuzza, D., Neira, J., Reid, I., and Leonard, J. J. (2016). Past, present, and future of simultaneous localization and mapping: Toward the robust-perception age. IEEE Transactions on robotics, 32(6):1309–1332. [Cannella, 2018] Cannella, M. (2018). Arcore google - augmented reality in the archaeological
site of selinunte with google arcore.
[Caruso et al., 2015] Caruso, D., Engel, J., and Cremers, D. (2015). Large-scale direct slam for omnidirectional cameras. In 2015 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pages 141–148. IEEE.
[Comport et al., 2006] Comport, A. I., Marchand, E., Pressigout, M., and Chaumette, F. (2006). Real-time markerless tracking for augmented reality: the virtual visual servoing framework. IEEE Transactions on visualization and computer graphics, 12(4):615–628.
[DSO mobile demo, 2017] DSO mobile demo (2017). Dsodemo. https://github.com/
striversist/DSODemo. Username: aarontang.
[DSO parameter file, 2016] DSO parameter file (2016). Dso parameter file. https:
//github.com/JakobEngel/dso/blob/master/src/util/settings.cpp. Commit:
5fb2c065b1638e10bccf049a6575ede4334ba673.
[Eggert et al., 2014] Eggert, D., H¨ucker, D., and Paelke, V. (2014). Augmented reality
visuali-zation of archeological data. In Cartography from Pole to Pole, pages 203–216. Springer. [Engel et al., 2017] Engel, J., Koltun, V., and Cremers, D. (2017). Direct sparse odometry. IEEE
transactions on pattern analysis and machine intelligence, 40(3):611–625.
[Engel et al., 2015] Engel, J., St¨uckler, J., and Cremers, D. (2015). Large-scale direct slam
with stereo cameras. In 2015 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pages 1935–1942. IEEE.
[Grupp, 2017] Grupp, M. (2017). evo: Python package for the evaluation of odometry and slam. https://github.com/MichaelGrupp/evo.
[Joshi et al., 2019] Joshi, B., Rahman, S., Kalaitzakis, M., Cain, B., Johnson, J., Xanthidis, M., Karapetyan, N., Hernandez, A., Li, A. Q., Vitzilaios, N., et al. (2019). Experimental comparison of open source visual-inertial-based state estimation algorithms in the underwater domain. arXiv preprint arXiv:1904.02215.
[Kalibr, 2018] Kalibr (2018). The kalibr visual-inertial calibration toolbox. https://github. com/ethz-asl/kalibr. Username: ethz-asl.
[Kuipers et al., 1999] Kuipers, J. B. et al. (1999). Quaternions and rotation sequences,
vo-lume 66. Princeton university press Princeton.
[Lanjouw, 2018] Lanjouw, T. (2018). Augmented reality in humanities education 4d research lab. http://www.4dresearchlab.nl/augmented-reality-in-humanities-education/. [Milgram and Kishino, 1994] Milgram, P. and Kishino, F. (1994). A taxonomy of mixed reality
visual displays. IEICE TRANSACTIONS on Information and Systems, 77(12):1321–1329. [Multi-Sensor Grabber, 2018] Multi-Sensor Grabber (2018). Multi-sensor grabber. https://
github.com/TobiasWeis/android-multisensorgrabber-2. Username: TobiasWeis.
[Mur-Artal et al., 2015] Mur-Artal, R., Montiel, J. M. M., and Tardos, J. D. (2015). Orb-slam: a versatile and accurate monocular slam system. IEEE transactions on robotics, 31(5):1147– 1163.
[ORB-SLAM Android, 2018] ORB-SLAM Android (2018). Orb-slam2-based-ar-on-android.
https://github.com/muziyongshixin/ORB-SLAM2-based-AR-on-Android. Username: Mu-ziyongshixin.
[ORB-SLAM parameter file, 2016] ORB-SLAM parameter file (2016). Orb-slam parameter
file. https://github.com/raulmur/ORB_SLAM2/blob/master/Examples/Monocular/TUM1.
yaml. Commit: 8ce6680f2ff836f705cb05b49c68ab825e2f5213.
[Pfeiffer et al., 2013] Pfeiffer, M., Carr´e, C., Delfosse, V., Hallot, P., and Billen, R. (2013).
Vir-tual leodium: from an historical 3d city scale model to an archaeological information system. ISPRS Annals–Volume II-5/W1, 2013.
[Pfrommer et al., 2017] Pfrommer, B., Sanket, N., Daniilidis, K., and Cleveland, J. (2017). Pen-ncosyvio: A challenging visual inertial odometry benchmark. In 2017 IEEE International Conference on Robotics and Automation, ICRA 2017, Singapore, Singapore, May 29 - June 3, 2017, pages 3847–3854.
[Qin et al., 2018] Qin, T., Li, P., and Shen, S. (2018). Vins-mono: A robust and versatile
monocular visual-inertial state estimator. IEEE Transactions on Robotics, 34(4):1004–1020. [Rublee et al., 2011] Rublee, E., Rabaud, V., Konolige, K., and Bradski, G. R. (2011). Orb: An
efficient alternative to sift or surf. In ICCV, volume 11, page 2. Citeseer.
[Schubert et al., 2018] Schubert, D., Goll, T., Demmel, N., Usenko, V., St¨uckler, J., and
Cre-mers, D. (2018). The tum vi benchmark for evaluating visual-inertial odometry. In 2018 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pages 1680– 1687. IEEE.
[Shi and Tomasi, 1993] Shi, J. and Tomasi, C. (1993). Good features to track. Technical report, Cornell University.
[Starlino, 2019] Starlino (2019). A guide to using imu (accelerometer and gyroscope
de-vices) in embedded applications. https://library.vuforia.com/articles/Training/
Extended-Tracking.
[Umeyama, 1991] Umeyama, S. (1991). Least-squares estimation of transformation parameters between two point patterns. IEEE Transactions on Pattern Analysis & Machine Intelligence,
[VINS parameter file, 2018] VINS parameter file (2018). Vins parameter file. https://github. com/HKUST-Aerial-Robotics/VINS-Mono/blob/master/config/tum/tum_config.yaml. Commit: 3a95302540ade3a485bd6470a8b6e446f37165e9.
[Vuforia, Extended Tracking, 2019] Vuforia, Extended Tracking (2019). Extended tracking.
https://library.vuforia.com/articles/Training/Extended-Tracking. [Weisstein, 2009] Weisstein, E. W. (2009). Euler angles.
[Wikipedia, the free encyclopedia, 2019] Wikipedia, the free encyclopedia (2019). No gimbal
