INOM
EXAMENSARBETE TEKNIK OCH EKONOMI, GRUNDNIVÅ, 15 HP
STOCKHOLM SVERIGE 2020,
Visualisering av vägdata i en AR-app
IDA NYQVIST LI STRANDBERG
KTH
SKOLAN FÖR KEMI, BIOTEKNOLOGI OCH HÄLSA
Visualisering av vägdata i en AR-app Visualization of Road Data in an AR app
LI STRANDBERG IDA NYQVIST
Examensarbete inom Datateknik och ekonomi Grundnivå, 15 hp
Handledare på KTH: Leif Lindbäck Examinator: Ibrahim Orhan TRITA-CBH-GRU-2020:254 KTH
Skolan för kemi, bioteknologi och hälsa 141 52 Huddinge, Sverige
Sammanfattning
I och med smarttelefonens intåg i våra liv har Augmented Reality (AR) kommit att bli en teknik i ropet. Många företag och utvecklare är intresserade av att undersöka dess potentiella användningsområden för just deras nisch. Men det är inte bara fantasin som sätter gränser - även hårdvaran.
2018 lanserades ARCore, en uppsättning utvecklingsverktyg för att bygga AR-appar för Android-smartmobiler. ARCore i sig har inte stöd för att bygga positionsbaserade appar, men i och med att smartmobiler och surfplattor är utrustade med GPS och kompass för att kunna avgöra sin position och orientering, syftar detta arbete till att utreda hur en platsbaserad AR-app för Android kan utvecklas, med målet att visa vägdata som AR-objekt.
Projektet inleddes med en litteraturstudie för att undersöka teorierna bakom AR, positionsteknik och redan existerande platsbaserade AR-appar. Vidare genomfördes en fallstudie av att utveckla en AR-app för att visa utvald vägdata i stadsmiljö. Appen testades i stadsmiljö, där det upptäcktes att enhetens platsnoggrannhet var för dålig för att kunna placera och visa AR-objekt någorlunda verklighetstroget. Därefter gjordes en uppföljande litteraturstudie på området positionsteknik och platsnoggrannhet hos dagens mobila enheter för att undersöka vilka faktorer som påverkar enheters förmåga att bestämma sin position. Den uppföljande litteraturstudien visade att platsnoggrannheten framförallt påverkas av höga byggnader i närmiljön.
Nyckelord
Augmented Reality, positionsteknik, ARCore, Android, apputveckling
Abstract
The introduction of the smartphone as we know it today, has made Augmented Reality (AR) a hot technology. Many companies and developers want to explore its potential uses within their area of interest. But not only does the imagination set the limits – the hardware does too.
In 2018, ARCore was launched, a software development kit (SDK) for building AR apps for Android smartphones. ARCore itself does not provide support for building location-based apps, but since smartphones and tablets are equipped with a GPS and compass to determine their position, this project aims to explore how to develop a location-based AR app for Android, with the goal of visualizing road data as AR objects.
The project started with a literature study to explore the theories behind AR, location technology and pre-existing location-based AR apps. This was followed by a case study of building an AR app to display selected road data in an urban environment. Tests with the app in an urban environment revealed that the location accuracy of the device was too poor to display AR objects in their correct position. To explore the major factors affecting a device’s capability to determine its position, a second literature study was conducted in the area of location technology in practice and accuracy of mobile devices. The second literature study showed that the location accuracy is mainly affected by tall buildings in the nearby area of usage.
Keywords
Augmented Reality, location technology, ARCore, Android, app development
Förord
Tack till Fadil Galjic, Leif Lindbäck, Viktor Mattsson, Ibrahim Orhan, Carina Palmqvist, Peter Sillén och Kave Silverklippa.
Innehållsförteckning
1 Introduktion ... 1
1.1 Bakgrund ... 1
1.2 Problem ... 2
1.3 Syfte ... 2
1.4 Mål ... 2
1.5 Metod ... 3
1.6 Avgränsningar ... 3
1.7 Författarnas bidrag till examensarbetet ... 3
1.8 Disposition ... 3
2 Teoretisk bakgrund ... 5
2.1 Augmented Reality ... 5
2.1.1 Marker-based, markerless och platsbaserad AR ... 6
2.1.2 ARCore ... 7
2.2 Positionsteknik ... 8
2.2.1 Plats ... 8
2.2.2 Riktning ... 9
2.3 Vägdata ... 10
2.3.1 Dataformat ... 11
2.4 Relaterade arbeten ... 11
2.4.1 GeoAR Android App and Backend POI Helper ... 11
2.4.2 Where’s my cAR ... 12
2.4.3 Platsbaserad AR för navigering ... 12
3 Metodologi ... 15
3.1 Undersökningsstrategi ... 15
3.1.1 Kvantitativa och kvalitativa metoder ... 15
3.1.2 Induktiv och deduktiv approach ... 15
3.1.3 Fallstudie ... 16
3.1.4 Tillämpning av metoder ... 16
3.2 Undersökningsfaser ... 16
3.2.1 Litteraturstudie ... 17
3.2.2 Fallstudie ... 18
3.2.3 Tester ... 18
3.2.4 Uppföljande litteraturstudie ... 18
3.3 Mjukvaruutveckling ... 18
3.3.1 Iterativ utveckling ... 19
3.3.2 Programmeringsspråk och utvecklingsmiljö ... 19
3.3.3 Urval och hämtning av vägdata ... 19
4 Vägdata och utveckling av AR-app ... 21
4.1 Analys av mjukvara som använts som hjälp ... 21
4.1.1 Android Solar system ... 22
4.1.2 Where’s my cAR ... 22
4.1.3 GeoAR Android app and backend POI helper ... 23
4.2 Val och analys av vägdata ... 23
4.3 Appens struktur ... 24
4.3.1 Hämtning och inläsning av vägdata ... 24
4.3.2 Bestämma en intressepunkts position ... 26
4.3.3 AR ... 27
4.4 Sammanställning ... 28
5 Begränsningar vid användning av positionsteknik ... 29
5.1 Testning av appen ... 29
5.1.1 Genomförande ... 29
5.1.2 Testresultat ... 30
5.1.3 Utvärdering av testresultat ... 34
5.2 Positionsteknikens begränsningar ... 35
5.2.1 Platsnoggrannhet hos smartmobiler i stadsmiljö ... 35
5.2.2 Dual-frequency ... 36
5.3 Sammanställning ... 37
6 Diskussion ... 39
6.1 Utvärdering av metoder ... 39
6.1.1 Metoder för genomförande ... 39
6.1.2 Utvärdering utifrån reliabilitet och validitet ... 40
6.2 Utvärdering utifrån frågeställningar och resultat ... 41
6.2.1 Hur kan vägdata hanteras för att visualiseras i en AR-app? ... 41
6.2.2 Vilka begränsningar har positionstekniken i dagens smarta enheter? 42 6.3 Ekonomisk aspekt ... 42
6.4 Hållbarhet ... 43
6.4.1 Samhälleligt och etiskt perspektiv ... 44
6.4.2 Miljömässigt och ekonomiskt perspektiv ... 44
6.5 Framtida forskning ... 45
6.6 Summering ... 45
7 Slutsats ... 47
Referenser ... 49
Ord och koncept
App Applikation för smarta enheter AR-vy/scen Virtuellt vylager ovanpå kameravyn
Intressepunkt Point of Interest (POI). Koordinat som även kan relateras till information som t.ex. namn och typ
Plats Placering i ett koordinatsystem Platsprecision/
platsnoggrannhet Hur väl en enhets uppfattning om sin plats överensstämmer med verkligheten
Position Plats i kombination med orientering Positionsteknik/
positionstjänst
Hårdvara och mjukvara som används för att bestämma en enhets position
SDK Software Development Kit. En uppsättning
utvecklingsverktyg
Smartmobil Smartphone. Avser även surfplattor
Vägdata Data om vägnätet samt de grundläggande egenskaper och objekt som knyts till vägnätet
1
Kapitel 1
Introduktion
Augmented Reality (AR) har gått från att vara en vision till en bekant teknik för vanliga mobilanvändare. Numera återfinns AR i mobilappar både för praktiska vardagsbestyr och det enkla nöjets skull. AR är en teknik som kombinerar verkliga och virtuella tredimensionella objekt i realtid. De virtuella objekten kan presentera information om den verkliga världen, eller representera föremål som om de var en del av den. Att det sker i realtid innebär att hårdvaran fångar användarens omgivning med en kamera eller genom en optisk huvudmonterad display [1].
Syftet är att förstärka verkligheten, precis som namnet antyder. Termen AR myntades 1992 [2] vid ett projekt på Boeing, där arbetarna med hjälp av en huvudmonterad digital display fick guidning i att montera elektriska kablar på flygplan.
Så, att AR skulle vara ett nytt koncept är en vanlig missuppfattning. Den första kända skildringen av AR som vi känner det idag, återfinns i en barnbok från början av 1900-talet [2]. Det senaste decenniets utveckling av mobila enheter med kameror har gett tekniken ett uppsving. Idag har nio av tio svenskar en smartphone [3] och därmed tillgång till AR.
1.1 Bakgrund
Det finns många potentiella användningsområden för AR. Några områden som har börjat använda sig av tekniken är militär, medicin, arkitektur, utbildning och spel.
Inom spel lanserades AR-mobilspelet Pokémon Go 2016 [4]. Spelet går ut på att användaren tar sig runt och fångar virtuella Pokémon som finns utplacerade på olika platser, världen över, för att träna och strida med dessa mot andra spelares.
Pokémon Go är en platsbaserad AR-app, vilket innebär att den använder sig av enhetens platsinformation när spelaren orienterar sig med hjälp av en tvådimensionell karta. När spelaren närmar sig en Pokémon öppnas enhetens kameravy, Pokémon visar sig i scenen och spelaren har möjlighet att fånga den.
2019 utökade navigeringsappen Google Maps sin funktionalitet med AR- navigering [5]. Detta ger användaren möjlighet att guidas till sitt mål med hjälp av virtuella vägvisare, som komplement till den tvådimensionella kartvyn. När
2
användaren startar AR-navigeringsläget öppnas kameravyn, och användaren måste svepa telefonen runt sig för att låta appen läsa in omgivningen och avgöra mer exakt var den befinner sig.
1.2 Problem
Företaget Norconsult Astando bygger IT-system för att hantera vägdata. Den gemensamma nämnaren för de så kallade vägdata de arbetar med, är att den innehåller information om geografisk plats. En del av denna vägdata kan lämpa sig för att visa som AR-objekt – men vilken data som faktiskt lämpar sig för detta kräver en vidare undersökning inom förutsättningarna för platsbaserad AR.
Avsnitt 1.1. beskrev hur Pokémon Go visar en tvådimensionell karta tills spelaren når sitt mål, samt hur Google Maps AR-navigering kräver att användaren skannar av sin omgivning innan positionen kan fastställas. Dessa detaljer väcker frågor om vilka begränsningar som finns för platsbaserade AR-appar och hur man kommer runt dem.
Detta examensarbete syftar till att besvara följande frågeställningar:
RQ1. Hur kan vägdata hanteras för att visualiseras i en AR-app?
RQ2. Vilka begränsningar har positionstekniken i dagens smarta enheter?
1.3 Syfte
Syftet med examensarbetet är att undersöka och utvärdera de praktiska och tekniska begränsningarna, respektive möjligheterna, hos de tekniker som kan användas för att konstruera en platsbaserad AR-app.
Arbetet är även tänkt att användas som underlag av Norconsult Astando för att avgöra huruvida AR kan användas som ett verktyg i deras direkta eller indirekta verksamhet.
1.4 Mål
Målet med projektet är att utveckla en platsbaserad AR-app för Android-enheter, med stöd av ramverket ARCore. Appen ska läsa in vägdata och avgöra vilka av dessa som finns inom ett visst avstånd från enheten. De vägdata som befinner sig i närheten ska presenteras som virtuella intressepunkter i form av skyltar. Dessa visas med illusionen av att de finns på den plats där intressepunkten är placerad i
3
verkligheten. Skyltarna ska visa ytterligare information om intressepunkten, till exempel en adress eller avståndet till enheten.
1.5 Metod
Till att börja med genomförs en litteraturstudie för fördjupning inom området och för att ta del av resultat från liknande projekt. Vidare genomförs en fallstudie för att implementera appen utifrån de teorier och projekt som hittas under litteraturstudien. Därefter testas appen på mobil och surfplatta i sin tänkta användningsmiljö, för att utvärdera dess eventuella användbarhet. Slutligen görs en uppföljande litteraturstudie för att undersöka de begränsningar hos positionstekniken som identifierats vid testning av appen.
1.6 Avgränsningar
Projektets huvudsakliga mål och syfte är att skapa en prototyp av en platsbaserad AR-app för att utvärdera bakomliggande funktionalitet – därför kommer inte användargränssnitt och användarupplevelse hanteras. Urval och hämtning av data kommer ske manuellt, och lagras på enheten.
1.7 Författarnas bidrag till examensarbetet
Författarna har arbetat tillsammans med litteraturstudier, fallstudie och rapportskrivning under examensarbetets gång. Stundtals har dock Ida Nyqvist haft mer fokus på utveckling, medan Li Strandberg har haft mer fokus på rapportskrivning. Företagshandledaren har huvudsakligen stöttat med information om Norconsult Astando och en av deras kunders verksamhet, samt hjälpt till vid urval och hämtning av vägdata.
1.8 Disposition
Rapporten är disponerad enligt följande. Kapitel 2, Teoretisk bakgrund, går igenom den teoretiska bakgrunden för att förstå process, resultat och diskussion av arbetet. Detta inkluderar resultat från litteraturstudien kring AR, positionsteknik, vägdata samt relaterade arbeten och liknande appar.
Kapitel 3, Metodologi, motiverar de metoder som använts i projektet – både deras teoretiska bakgrund och hur de tillämpats praktiskt med avsikt att besvara
4
projektets frågeställningar. Processen och dess faser beskrivs och däribland de datainsamlings- och mjukvaruutvecklingsmetoder som varit centrala i arbetet.
Kapitel 4, Vägdata och utveckling av AR-app, ger en genomgång av funktionalitet och konstruktion av appen som utvecklats under projektets fallstudie. Här beskrivs och analyseras inledningsvis de appar och mjukvaror som använts som hjälp för att ta fram AR-appen för vägdata.
Kapitel 5, Begränsningar vid användning av positionsteknik, presenterar resultat av tester med appen som konstruerades under fallstudien och analys av dessa. Även resultat från den uppföljande litteraturstudien av positionsteknik presenteras här. Detta för att ge en mer nyanserad bild av vad positionsteknikens brister leder till i praktiken.
Kapitel 6, Diskussion, diskuterar och utvärderar genomförandet av projektet och dess metoder samt resultat och slutsats. Även en ekonomisk aspekt på arbetet, etik och hållbarhet relaterat till projektet och framtida forskning tas upp i detta kapitel.
Kapitel 7, Slutsats, sammanfattar projektets resultat.
5
Kapitel 2
Teoretisk bakgrund
Detta kapitel går igenom den teoretiska bakgrunden till examensarbetet. Detta innefattar sammanfattningar av vad AR, ARCore, positionsteknik och vägdata är.
2.1 Augmented Reality
Augmented Reality (AR) är en visuell upplevelse som kombinerar den verkliga världen med digital data. För att åstadkomma detta används en kamera för att läsa av omgivningen. Systemet processar dessa bilder och adderar sedan datorgenererade grafiska inslag. Sammanslagningen av den verkliga omgivningen och den virtuella världen kallas ofta för en scen [2].
Figur 2.1 visar ett enkelt AR-system. Bilden är hämtad från rapporten Theory and Applications of Marker-based Augmented Reality och beskrivs med att capturing module hanterar bilden från kameran, tracking module beräknar plats och orientering för det virtuella lagret, rendering module kombinerar originalbilden och de virtuella komponenterna med hjälp av den beräknade orienteringen och renderar en förstärkt (eng. augmented) bild, eller scen, som sedan visas på displayen. [2]
Figur 2.1: Flödesschema för ett AR-system
AR kan delas in i tre typer: marker-based, markerless respektive platsbaserad AR. Dessa typer skiljer sig åt genom hur det digitala innehållet triggas till att visas i scenen [6], och bygger därmed på olika tekniker. Beroende på en applikations tänkta användningsområde, baseras teknikerna i sin tur på vilka objekt, samt hur, när och varför dessa objekt ska presenteras i scenen.
6
2.1.1 Marker-based, markerless och platsbaserad AR
Marker-based AR använder bildigenkänning för att placera AR-objekt i scenen [2]. Markören kan vara en tvådimensionell bild, se figur 2.2, eller ett distinkt objekt, till exempel ett bokomslag eller en läskburk med en specifik grafisk formgivning. Detta triggar det virtuella objektet att placeras ut vid markören i scenen.
Figur 2.2: Ett exempel på marker-based AR [7]
Markerless AR använder tvärtom inte markörer för att identifiera var ett virtuellt objekt ska placeras. Ofta placeras objektet i scenen så att det ser ut att hänga i luften, eller så detekteras plana ytor i bilden där objektet placeras. Detta gör det enkelt att låta användaren interagera med applikationen genom att placera och förflytta AR-objekt i scenen [6]. En app som bygger på denna teknik är IKEA Place som lanserades 2017 [8]. IKEA Place låter användaren placera ut virtuella IKEA- möbler för att se hur de skulle se ut i en viss omgivning, se figur 2.3.
Figur 1.3: AR-appen IKEA Place
Platsbaserad AR använder enhetens platsinformation, och ibland riktning, för att visa och förankra AR-objekt till en fysisk plats [6]. Exempel på appar som bygger
7
på denna teknik är Pokémon Go och AR-navigeringsläget i Google Maps som nämndes i avsnitt 1.1.
2.1.2 ARCore
Mars 2018 lanserade Google ARCore, ett SDK (Software Development Kit) för att utveckla AR-appar för Android-enheter. Det består av klasser som kan användas för att hantera det visuella och skapa en AR-upplevelse. ARCore har stöd för att bygga marker-based och markerless AR-appar, men inte platsbaserade appar. För att kunna skapa en AR-app som visar virtuella objekt utplacerade vid verkliga koordinater behövs ett API eller en modul som hanterar den positionstekniska delen av appen.
Centralt i ARCore är anchors (ankare). Dessa gör det möjligt att placera virtuella objekt med illusionen att de behåller sin plats relativt den verkliga världen [9]. ARCore håller koll på enhetens rörelse och förflyttning och med detta kan anchors se till att 3D-objektens position och orientering över tid följer enhetens rörelse. Om ett virtuellt objekt placeras på ett bord, till exempel, så ska det se ut som att det virtuella objektet står upprätt även om användaren vrider enheten åt något håll, samt anpassar sig skalenligt om användaren går närmre eller längre ifrån.
Sceneform är ett ramverk och en del av ARCore. Sceneform används för att skapa och integrera 3D-objekt och AR-upplevelser i en app, utan att ställa krav på användaren att fördjupa sig i grafik och OpenGL [10], ett avancerat verktyg för bland annat rendering av 3D-objekt och scener.
ARCore använder sig av sin förståelse av omgivningen för att slå samman virtuella objekt med enhetens kamerabild för att rendera ett virtuellt lager ovanpå enhetens kameravy [11]. För att skapa sig denna uppfattning om omgivningen används följande tre tekniker.
Rörelsespårning
ARCore använder en process som kallas SLAM (Simultaneous Localization And Mapping) för att skapa sig en uppfattning om omvärlden. Med detta byggs en bild upp genom att använda input från enhetens sensorer. ARCore kan uppfatta distinkta visuella egenskaper i bilden från kameran och använda sig av dessa visuella egenskaper, eller punkter (feature points), för att beräkna hur enheten förflyttar sig. Den visuella informationen kombineras med data från
8
tröghetsmätaren (IMU – Inertial Measurement Unit) för att estimera kamerans pose i relation till omvärlden [12].
Läsa av omgivningen
ARCore letar efter kluster av visuella punkter, som ligger i linje antingen horisontellt eller vertikalt, och på så vis upptäcka plana ytor, som väggar och bord, för att kunna placera virtuella objekt på dessa [12].
Ljusestimering
Information om ljussättning i omgivningen kan ge en uppfattning om ljusstyrka och färgkorrektion. Detta kan användas för att kasta rätt ljus på de virtuella objekten för att öka den realistiska upplevelsen [12].
2.2 Positionsteknik
En platsbaserad app kan använda sig av enhetens geografiska position för att bistå användaren med information om dess omgivning. Detta genom att i sin tur ta reda på exempelvis platsens väder, hur användaren förflyttar sig och i vilken hastighet, närliggande evenemang, händelser, trafik samt andra realtidsuppdateringar.
Detta avsnitt beskriver tekniken som används för att fastställa enhetens position, men även riktning, eftersom positionen ju inte säger något om enhetens kompassriktning.
2.2.1 Plats
GNSS (Global Navigation Satellite Systems) är ett samlingsnamn för navigations- och positionsbestämningssystem. Smartmobiler är utrustade med GNSS- mottagare, vilka kan ta emot radiosignaler som skickas ut av satelliter som ingår i GNSS, och användas för att mäta avståndet till satelliter och därigenom bestämma enhetens position på Jorden [13].
Det mest kända satellitsystemet är GPS (Global Positioning System), vilket utvecklades av militären i USA och idag har 24 satelliter som kretsar kring Jorden två gånger varje dygn [14]. I Europa har satellitsystemet Galileo tagits fram som ett civilt initiativ. Det kommer bestå av 30 satelliter och förväntas ha bättre täckning i norra Europa än GPS och Glonass när det är helt färdigställt någon gång
9
under år 2020 [15]. Glonass är det ryska systemet, också ursprungligen framtaget för militärt bruk. I Kina finns satellitsystemet vid namn BeiDou [16].
De flesta smarttelefoner har stöd för både Glonass och GPS, och nyare modeller har även stöd för Galileo. De använder sig dessutom nästan alltid av A- GPS (Assisted GPS) för att bestämma telefonens plats med hjälp av mobilnätverket. Detta genom att nätverkets basstationer kan ta emot och vidarebefordra GPS-signaler [17]. Figur 2.4 illustrerar signalflödet mellan mobiltelefoner, basstationer och satelliter för platsinformation.
Figur 2.4: Signalflödet mellan mobila enheter, basstationer och satelliter (figur från https://en.wikipedia.org/wiki/Assisted_GPS)
2.2.2 Riktning
För att bestämma enhetens riktning (nord, syd, väst, öst) används data från den geomagnetiska fältsensorn och accelerometern. Figur 2.5 illustrerar det treaxliga koordinatsystem som används för att beskriva en position relativt jordens yta.
- y-axeln pekar mot norr längs med jordens yta - x-axeln är i 90 grader från y och pekar mot öster
- z-axeln pekar upp mot atmosfären, ett negativt värde pekar ner i marken
A-GPS Server
Stationary ReceiverGPS
Handset with GPS and GSM
GPS Satellites
SignalGPS
SignalGPS
Assistance Information
StationBase MSC StationBase
10
Figur 2.5: Jordens koordinatsystem, relativt till jordens yta
Den geomagnetiska fältsensorn mäter styrka och riktning hos magnetfältet kring telefonen. Men liksom hos vanliga kompasser kan den störas av element i omgivningen, som till exempel metallföremål och elledningar. Därför kombineras data från de båda sensorerna för att få en mer korrekt uppfattning om enhetens riktning [18].
För att avgöra sin egen rörelse har enheten ett koordinatsystem som också består av tre axlar, x, y och z. Figur 2.6 beskriver relationen mellan dessa.
Figur 2.6: Telefonens koordinatsystem, relativt till enhetens skärm
2.3 Vägdata
Detta avsnitt tar upp och förklarar de data och format som används, eller har utvärderats för användning, i projektet. Vägdata kallas data om vägnätet samt de egenskaper och objekt som knyts till det [19]. Den representerar fysiska ting både i gatumiljö och under mark samt administrativa egenskaper, till exempel väghinder, hastighetsgränser, brunnar, skyltar, nedgrävda kablar, tillstånd för uteserveringar med mera. Gemensamt för all vägdata är att den innehåller information om föremålens geografiska plats.
Till stor del är det Trafikverket som sammanställer och tillhandahåller vägdata, men även Sveriges Kommuner, Lantmäteriet, Skogsnäringen och Transportstyrelsen förser en gemensam databas, Nationella Vägdatabasen (NVDB), med detta [19].
11 2.3.1 Dataformat
Vägdata finns i flera olika format beroende på användningsområde. De vanligaste formaten är GML (Geography Markup Language) och GeoJSON (Geographic JavaScript Object Notation).
XML (eXtensible Markup Language) är ett märkspråk som anger regler för hur ett dokument ska märkas upp, eller kodas, för att vara läsbart för både människor och datorer. XML-taggar används för att identifiera data i ett dokument, för att kunna lagra och organisera denna, och mer generellt för att skilja på innehåll och presentation [20] [21].
Det finns flera varianter av XML, anpassade för att beskriva och hantera olika typer av information. GML är en variant som används för att representera världsliga objekt i spatiala termer. Alltså geografisk information som beskriver egenskaper och geometri hos föremål och företeelser i vår omgivning [21].
JSON (JavaScript Object Notation) är ett dataformat med JavaScript- syntax, men som kan användas oberoende av JavaScript. Många språk har möjlighet att parsa och generera JSON, och det är framförallt vanligt i webbapplikationer. Liksom XML används det för att beskriva och organisera data [22].
GeoJSON är baserat på JSON, och liksom GML används det för att representera geografiska data och egenskaper [23].
2.4 Relaterade arbeten
Detta avsnitt tar upp tre projekt som vart och ett har utvecklat en platsbaserad AR- app. Det första projektet består av en teknisk rapport, medan det andra projektet har utvecklats av ett företag och har en sammanfattande redogörelse för projektet på sin hemsida. Det tredje och sista projektet skildras från två olika perspektiv i två vetenskapliga artiklar.
2.4.1 GeoAR Android App and Backend POI Helper
Agrawal et al. beskriver utvecklingen av en open source platsbaserad AR-app för Android. Appen hämtar data från en server om intressepunkter i enhetens omgivning och presenterar dessa i kameravyn i form av 3D-träskyltar, se figur 2.7.
Appen är tänkt att hjälpa användaren identifiera bibliotek, caféer, akademiska byggnader med mera på University of California, Santa Cruz Campus. Träskyltarna visar platsernas namn och ytterligare information om man trycker på skylten.
12
Agrawal et al. påpekar i sin rapport att ARCore inte har stöd för att utveckla platsbaserade AR-appar, vilket inte heller senaste versionen av ARCore har.
Projektet är därför delvis ett experiment i att försöka integrera en AR-app med Androids Location API och sensorer för att skapa en platsbaserad AR-app med ARCore.
Av resultaten att döma lyckas de få appen att fungera väl, men å andra sidan presenteras och diskuteras inte eventuella problem med tekniken de använt eller urvalet av data att visualisera.
Det finns andra SDK som har stöd för att utveckla platsbaserade AR-appar, till exempel Wikitude och Vuforia. Men dessa kostar, och som Agrawal et. al [24]
påpekar i sin rapport så ger dessa lösningar inte insikt i bakomliggande funktionalitet, eller möjligheten att anpassa det man utvecklar för ett specifikt syfte.
Figur 2.7: Skärmdump från GeoAR Android App
2.4.2 Where’s my cAR
Företaget Appoly har genomfört en fallstudie av att skapa en platsbaserad AR-app.
Appen registrerar att man åker bil, när man stannar bilen och kliver ut, och sparar då platsen för där man verkar ha parkerat bilen [25]. För att hitta tillbaka till bilen kan man använda sig av en AR-vy, eller ett blandat läge med 2D-karta och AR-vy.
De har dock ingen publicerad rapport om arbetet för att presentera sina slutsatser närmare. Men de tar upp i beskrivningen av projektet att det i ARCore inte finns stöd för att presentera platsbaserade objekt i AR. De nämner även
13
bristerna hos platsnoggrannheten i mobila enheter som ett problem för att skapa bra platsbaserade AR-upplevelser.
Appen finns att ladda ner i Google Play Store och källkoden för appen finns tillgänglig på Github [26].
2.4.3 Platsbaserad AR för navigering
Till studien Comparative study of user experience on mobile pedestrian navigation between digital map interface and location-based augmented reality [41], har en prototyp av en platsbaserad AR-app för navigering utvecklats. Appen är tänkt att guida användaren till busshållplatser i Taiwan med stegvisa vägbeskrivningar i form av AR-objekt, se figur 2.8.
Figur 2.8: Skärmdump från platsbaserad AR-app för navigering
I det taiwanesiska distriktet där appen har utvecklats finns det hundratals busslinjer som var och en består av många busshållplatser. I den relaterade studien An effective approach to develop location-based augmented reality information support, lyfter samma författare just problemet med att vanliga platsbaserade AR- appar för navigering visar för många AR-objekt samtidigt i scenen [42]. Dom menar att detta gör appar svåranvända och svåra att förstå, vilket förtar syftet med denna typ av app. Av denna anledning har dom valt en stegvis navigering och att endast ta fram intressepunkter för en, av användaren vald, busslinje åt gången.
Hämtning av relevanta intressepunkter sker genom webbserviceanrop.
Därefter extraheras intressepunkternas platsinformation och konverteras till
14
virtuella intressepunkter. Appen använder sig därefter av mobilens sensorer för att identifiera enhetens position samt riktning och därmed bestämma placeringen av dom virtuella intressepunkterna i scenen. Tyvärr går ingen av studierna in på tekniska detaljer kring utvecklingen av den platsbaserade AR-appen, men resultaten visar att det är möjligt.
15
Kapitel 3
Metodologi
Detta kapitel beskriver metoder och strategier som har använts under projektet, processen för genomförandet och hur datainsamling skett för att besvara arbetets frågeställningar.
3.1 Undersökningsstrategi
Detta avsnitt förklarar grundläggande forskningsmetoder så som kvantitativa och kvalitativa metoder, induktiva och deduktiva förhållningssätt samt fallstudier.
Slutligen redogörs kort för hur dessa metoder har tillämpats i arbetet.
3.1.1 Kvantitativa och kvalitativa metoder
Undersökningsmetoder för ett vetenskapligt arbete sägs ofta vara kvalitativa eller kvantitativa. Kvantitativa metoder utmärks av att de utgår från data i form av mätvärden från statistik, frågeformulär, hårda fakta och experiment med beräkningar. Kvalitativa metoder fokuserar snarare på ord, mjuka fakta och kontextuell förståelse där data samlas in genom exempelvis intervjuer och observationer [27].
3.1.2 Induktiv och deduktiv approach
En induktiv approach kan ses som att man jobbar nerifrån och upp och bygger upp en teori eller hypotes genom att analysera empiriska data som samlats in. Med förhoppning att kunna ta fram en teori som förklarar företeelser och mönster som identifieras [27].
Med ett deduktivt angreppssätt jobbar man från andra hållet – uppifrån och ner, där en hypotes formuleras utifrån tillgängliga teorier och fakta. För att verifiera om hypotesen stämmer eller ej genomförs tester [27].
16 3.1.3 Fallstudie
En fallstudie är en strategi för att utvärdera och undersöka ett fenomen på nära håll. Den är centrerad till ett eller flera specifika fall för att ta reda på mer fakta och samla in data om dessa. En kvantitativ fallstudie kan till exempel genomföras med hjälp av en enkätundersökning för att försöka mäta företeelser hos en population.
En kvalitativ fallstudie fokuserar snarare på en djupare förståelse av en företeelse än mätbarhet. Det är inte möjligt att dra statistiska slutsatser när man kollar på ett eller några få specifika fall. Men man kan använda sig av jämförelser och extrapolering för att analysera och dra slutsatser som gäller liknande fall - om fallstudien är väl genomförd [27].
3.1.4 Tillämpning av metoder
Projektet genomfördes som en fallstudie för att utforska möjligheterna att visa vägdata i en AR-app, och hur detta går till. Detta med kvalitativt fokus på beskrivningar snarare än mätningar och statistisk data. Inledningsvis hade vi en deduktiv approach för att bevisa hypotesen att det går att skapa en AR-app för att visa vägdata, och med det besvara RQ1. Senare besvarades RQ2, för att ta reda på mer om begränsningarna i positionsteknik, med en induktiv approach där information från andra studier samlades in och analyserades för att ge svar på frågeställningen.
3.2 Undersökningsfaser
Detta avsnitt summerar arbetsprocessen. Figur 3.1 illustrerar processens 4 faser.
17
Figur 3.1: Flödesdiagram för projektets arbetsprocess
3.2.1 Litteraturstudie
Syftet med den inledande litteraturstudien har varit att fördjupa oss inom AR och besvara generella frågor som vad AR är, hur det fungerar, hur det har utvecklats, bakomliggande teknik med mera. Men även för att besvara RQ1. Hur kan vägdata hanteras för att visualiseras i en AR-app? Tidigare forskning och liknande arbeten studerades och analyserades.
Målet med litteraturstudien var även att hitta källkod till en eller flera appar för att se hur andra har valt att strukturera appar med syfte liknande vårt. För detta har vi främst sökt på Github efter projekt med nyckelord som: location based, geolocation, position based.
Även vägdata och dataformat undersöktes under den här fasen. Resultatet av den inledande litteraturstudien presenteras i kapitel 2. Det ledde även fram till en definition av det fall som kom att undersökas under fallstudien, utifrån de appar vi inspekterat.
18 3.2.2 Fallstudie
För att ta reda på möjligheten att visualisera vägdata i en AR-app genomfördes en fallstudie av att utveckla en app. Under litteraturstudien hittade vi tre arbeten som utvecklat appar med tekniker som stödde att det skulle vara möjligt att utveckla en app med den funktionalitet vi tänkt och anpassa efter våra önskemål och data. Två av dessa appar, se avsnitt 2.4.1 och 2.4.2, inspekterades noggrant och delar av apparna testades och användes som hjälp vid utvecklingen av vår egen app. Vidare tittade vi på vägdata och vilken typ av data som skulle vara bäst att visa i appen för att kunna testa dess funktionalitet. Kriterier för detta presenteras i 3.3.3.
Appen utvecklades i 3 delar, som 3 komponenter (AR, vägdata och positionsteknik), som till slut sammanställdes till en sammanhängande app.
3.2.3 Tester
Appen testades utomhus i stadsmiljö, på några utvalda platser med varierande omgivning. Vi gick dit med enheter som hade appen installerad. Appens funktionalitet testades och resultatet dokumenterades med skärmdumpar. Appen utvärderades efter detta utifrån vår upplevelse om hur trovärdigt AR-objekt placerades vid fysiska intressepunkter. Detta ledde fram till funderingar kring positionsteknik och platsnoggrannhet och frågeställning 2 formulerades.
3.2.4 Uppföljande litteraturstudie
För att ta reda på vad som påverkade platsnoggrannheten, och vilken precision vi kunde förvänta oss av enheterna genomfördes en uppföljande litteraturstudie.
Denna bedrevs liksom den första med att leta fakta och information, med fokus på positionsteknik hos dagens smarta enheter.
Efter detta kunde vi dra slutsatser kring inte bara vår egen app, utan även det som begränsar positionsbestämningen hos enheterna generellt.
3.3 Mjukvaruutveckling
Detta avsnitt beskriver de metoder och verktyg som har använts under arbetet med att utveckla appen.
19 3.3.1 Iterativ utveckling
Iterativa och agila metoder delar upp projektet i korta faser med frekvent utvärdering av projektets utveckling. Detta för att enkelt och flexibelt kunna anpassa det till ändrade förutsättningar samt minimera risker i eller för projektet [27].
För att säkerställa att “rätt” produkt utvecklas valde vi att arbeta med en iterativ modell. Där stegen för planering, implementering och utvärdering repeterades för att kunna anpassa projektet efter nya idéer och kunskaper. Också för att kontinuerligt föra en dialog med företaget om utveckling och få hjälp med val av olika inriktningar under projektets gång, samt ge dem en inblick i projektets gång.
3.3.2 Programmeringsspråk och utvecklingsmiljö
AR-appen är skriven i Java, vilket också är det officiella programmeringsspråket för utveckling av Android-appar.
Utvecklingen gjordes i Android Studio, en integrerad utvecklingsmiljö avsedd för att bygga appar till Android-enheter. Android Studio inkluderar bland annat verktyg för att bygga det grafiska gränssnittet, emulering, debugging samt ytterligare verktyg för utveckling och analys.
Två Android-enheter användes under utvecklingen och testningen av appen.
För att kunna använda ARCore på en enhet krävs det att enheten har Androids operativsystem version 7.0 Nougat (API nivå 24) eller högre. De enheter som har använts för utvecklingen är följande:
- Smarttelefon: Samsung Galaxy A5 (2017) - Surfplatta: Samsung Galaxy Tab S6
3.3.3 Urval och hämtning av vägdata
Urvalet av data gjordes manuellt, där vi i diskussion med företaget kom fram till följande kriterier för data:
- Punktformad
- På marknivå - helst alltid på samma höjd - Stor utbredning i Stockholms innerstad - Verklig storlek på högst ca 1 meter
Detta för att göra det enkelt att utvärdera precisionen vid placering av AR-objekt i scenen under testningen av appen.
20
Data hämtades genom anrop till GeoServer, en server för spatiala data[28], och formaten som finns att välja mellan för de datamängder vi tittade på är GeoJSON och GML.
21
Kapitel 4
Vägdata och utveckling av AR-app
Detta kapitel redogör för utvecklingen av appens huvudsakliga delar och ämnar besvara RQ1. Frågan kan delas in två områden – vägdata och AR, och då vägdata innehåller platsinformation kom detta att bli en central del i arbetet. Vidare är appens syfte att kombinera dessa tre för att undersöka hur vägdata kan presenteras i en AR-app.
4.1 Analys av mjukvara som använts som hjälp
Detta avsnitt tar upp de mjukvaruprojekt vi utgått från och använt som hjälp vid utveckling av vår app. Vi sökte efter och inspekterade AR-appar där objekt verkade placeras ut på ett visst avstånd från enheten, alltså inte genom att läsa av plana ytor eller andra feature points var objekten ska placeras. Däribland hittade vi Androids exempelprojekt Solar System som byggts med ARCore, vilket presenteras i detta avsnitt. Tre andra appar, som baseras på positionsteknik, har tagits upp i kapitel 2, men här ges en grundligare genomgång av hur två av dessa fungerar utifrån sin källkod. Den tredje appen har inte haft sin källkod tillgänglig och inte heller redogjort för tekniken bakom appen. Avsnitten är uppdelade efter apparnas hantering av intressepunkter, position respektive AR.
Figur 4.1: Skärmdump från appen Solar System efter att solsystemet har placerats ut
22 4.1.1 Android Solar system
I Solar System kan man med hjälp av AR titta på ett litet skalenligt solsystem i 3D i sin kameravy. Det ger upplevelsen av att solsystemet hänger i luften i rummet, se figur 4.1.
I projektet används anchors (som är ett internt icke visuellt objekt) för att placera och hantera de virtuella objekten. När man trycker på skärmen skapas en anchor vid den punkt man tryckt på, där 3D-objektet som illustrerar solen läggs till och kopplas till detta anchor. Planeterna läggs sen till i scenen som noder till sol-objektet, med hårdkodade skalenliga värden för sitt avstånd till solen. Att de virtuella 3D-objekten hanteras av en anchor gör att ramverket håller reda på dess placering i den fysiska världen, och när de placerats stannar de där så att man kan gå närmre eller runt objekten och interagera med dem.
Appen gav en god förståelse för Sceneforms anchor-objekt, avståndsbestämningen för dessa och hur de kan relatera till varandra om man har flera stycken samtidigt i samma scen.
4.1.2 Where’s my cAR
Enligt beskrivningen ska appen registrera att man färdas med bil, och när man sen stannar bilen och kliver ur sparas då platsen i appen för där man verkar ha stannat eller parkerat bilen. För att hitta tillbaka till bilen kan man använda sig av AR-vy, eller ett blandat läge med 2D-karta och AR-vy. Men vid inspektion av appen hittades inget blandat läge eller komponent som avgör huruvida enheten förflyttar sig gåendes eller med bil.
Intressepunkter
En lista med intressepunkter finns lokalt och temporärt i programmet.
Position
Avstånd och riktning till intressepunkter beräknas och uppdateras var femte sekund, därmed läses enhetens position och riktning in. De har inte gjort några anpassningar i appen för platsnoggrannhet, men användningsområdet för appen kräver inte exakt position. Tanken är att man ska hitta tillbaka till sin parkerade bil, troligen räcker det då med en precision på +/- 10 meter, vilket är ungefär den felmarginal positionstjänsterna har [32].
23 AR
Projektets AR-del är baserat på Solar system-appen för att hantera och visa virtuella 3D-objekt. När enheten befinner sig inom ett visst avstånd från en intressepunkt renderas dess 3D-objekt och läggs till i scenen.
4.1.3 GeoAR Android app and backend POI helper
En beskrivning av hur appen har löst inläsning av intressepunkter och position samt hantering av AR.
Intressepunkter
Appen har en komponent de kallar “Backend POI helper”, som har anslutning till en server varifrån de hämtar närliggande intressepunkter. Enhetens koordinater skickas då till servern som returnerar en lista av intressepunkter som ska visas i appen.
Positionskomponent
Appen använder Androids inbyggda Location API, som hämtar data från enhetens GPS för att bestämma plats. Riktning hämtas med Androids Orientation API.
Appen ”lyssnar” efter förändringar i enhetens position. Det vill säga, så fort man vrider eller förflyttar sig, kommer avstånd och riktning till intressepunkter räknas om.
AR
När projektet genomfördes (2017) hade ARCore ännu inte lanserat Sceneform.
Appen använder därför OpenGL för att rendera 3D-objekt. Då OpenGL är ett mer avancerat verktyg än Sceneform så utgör det en stor del av koden till appen.
4.2 Val och analys av vägdata
Urval av data gjordes manuellt, för att hitta något som skulle passa vid utvärderingen av den egenutvecklade appen i sin användningsmiljö. Utifrån de
24
kriterier vi kom fram till i avsnitt 3.3.3, föll valet på data som representerar parkeringsautomater. Detta eftersom den vägdatan inte innehåller information om höjd, alla parkeringsautomater är identiska och alltid placerade på marken. Samt att parkeringsautomater har en bra storlek, är enkla att se och upptäcka på gatan.
4.3 Appens struktur
Övergripande struktur för vår AR-app följer densamma som i GeoAR och Where’s my cAR, som beskrivits i tidigare avsnitt. Den kan delas in i framförallt tre delar – AR, position och intressepunkter, där intressepunkterna består av vägdata.
Funktionsmässigt har appen i uppgift att läsa in enhetens position och kontrollera om det finns intressepunkter inom ett visst avstånd från den. Om det finns så ska de visas som virtuella skyltar i appens kameravy. Se figur 4.2 för en illustration av systemet.
Figur 4.2: Flödesdiagram av AR-appen
4.3.1 Hämtning och inläsning av vägdata
Vägdata som visas i appen har hämtats från GeoServer och lagrats lokalt på enheten som en fil i GeoJSON-format. Java-biblioteket Jackson används för att konvertera GeoJSON till Java-objekt i programmet. Vi valde bort att använda
M bil enhe
Kame a Bild
V gda a Vi ell
3D- bjec
A d be k i g
Re de i g m d l A gme ed
Image Scen Di la
Pla - a e O ien e ing -
p a e
25
GML, eftersom vi inte lyckades konvertera vägdata i GML-format till Javaobjekt.
Inom tidsramen för projektet hade vi inte tid att göra en djupare felsökning i varför det inte gick med den data vi försökte parsa.
Varje parkeringsautomat är en intressepunkt och i programmet ett Java- objekt med information om parkeringsautomatens adress och koordinater.
Följande anrop gjordes till GeoServer för att hämta data om parkeringsautomater inom ett bestämt område i Hammarby Sjöstad. Se tabell 4.1 för en beskrivning av de olika parametrarnas samt deras värden.
http://<adress till GeoServer>/lv_gis/
ows?service=WFS&version=1.0.0&request=GetFeature&
typeName=lv_gis:Parkeringsautomat&srsName=EPSG:4326&
bbox=155765.08,6577054.37,156044.45,6577372.64
Tabell 4.1: Värden för och beskrivning parametrarna som har använts vid anrop till GeoServer
Namn Värde Beskrivning
service WFS Web Feature Service
version 1.0.0
request GetFeature Anger att en samling av features ska returneras
typeName lv_gis:Parkeringsautomat Feature type
outputFormat application%2Fjson Anger att feature types ska vara i JSON-format
srsName EPSG:4326 Anger koordinaterna som latitud och longitud enligt WGS 84
bbox a1: 155765.08
b1: 6577054.37 a2: 156044.45 b2: 6577372.64
Bounding Box, definierar ett
rektangulärt område avgränsat av fyra koordinater
26
Figur 4.3: En visuell beskrivning av parametern bbox (bounding box) som använts vid anrop till GeoServer
4.3.2 Bestämma en intressepunkts position
För att bestämma det verkliga avståndet mellan intressepunkter och enhet behöver man läsa in enhetens aktuella plats. Denna fås genom att använda Androids Fused Location Provider API som kombinerar data från GPS, wifi, nätverk, accelerometer, gyroskop och magnetometer [29] för att få en så exakt position som möjligt.
Figur 4.4: Skärmdump från appen
För testbarhetens skull valde vi att ha en knapp för att läsa in den aktuella platsen. Knappen ”Uppdatera position” syns uppe i vänster hörn på figur 4.4. Vi ansåg att det blev enklare att testa appen om det gick att själv avgöra när enhetens
27
position och närliggande intressepunkter skulle läsas in och uppdateras. Detta eftersom vi visste att precisionen i enhetens uppfattning om sin plats varierade en del. Tanken var att kunna läsa in intressepunkter när man befann sig på en plats där enheten hade bra platsnoggrannhet, och kontrollera detta med Google Maps.
Utifrån enhetens platskoordinater kontrolleras filen med hämtad vägdata för att se om någon av dessa ligger inom ett visst avstånd från enheten. För de intressepunkter som ligger inom rätt avstånd beräknas sedan bäringen – ett vinkelmått inom navigation, för att beskriva en vinkel mellan riktning till ett föremål, eller en punkt, och nordriktningen [30]. Se figur 4.5. Detta för att kunna placera AR-objektet i en riktning som motsvarar intressepunkten från enheten sett. Som beskrivits i avsnitt 2.2.2 har enheten ett 3-axligt koordinatsystem, med hjälp av vilket ARCore kan placera ett objekt var som helst 360° runt enheten.
Enhetens riktning, eller orientering, fås genom att använda Androids Orientation API som läser av geomagnetiska fältsensorn[31].
Figur 4.5: Bäringen till en intressepunkt - relativt nordriktningen utifrån enhetens plats
4.3.3 AR
Det virtuella objektet renderas med hjälp av Sceneform, och knyts till ett anchor- objekt som läggs till i scenen. Vårt virtuella objekt är en röd tvådimensionell rektangel, som är fördefinierad i en XML-fil, med en platshållare för text.
Information från data om intressepunkten hämtas, i vårt fall en adress, som läggs till i textfältet. Anchor-objektet innehåller information om avstånd mellan sig själv och sitt parent-anchor. Ett parent-anchor placeras där enheten befann sig vid inläsning av position och beräkning av avstånd till intressepunkter, och uppdateras om man trycker på ”Uppdatera position”-knappen. ARCore hanterar skalning och position av anchor-objekten, vilket ger illusionen av att de är placerade i verkligheten.
28
4.4 Sammanställning
I detta kapitel har två platsbaserade AR-appar beskrivits. Båda hanterar datapunkter innehållande verklig geografisk information och visar dessa som 3D- objekt i appens kameravy. Vi har utgått från dessa två appar när vi utvecklat vår app under projektet, med syftet att utforska hur vägdata kan hanteras för att visualiseras i en AR-app, alltså RQ1. I kapitlet redogörs för struktur och de komponenter som utgör vår app, vilket bevisar att det med framgång har gått att hämta och läsa in riktig vägdata och visa dessa som virtuella objekt i en AR-app.
Vi kan konstatera att appen har följande funktionalitet:
1. Läser in enhetens position
2. Läser in närliggande intressepunkter
3. Beräknar vilka intressepunkter som ligger inom ett visst avstånd från enheten
4. Placerar ut virtuella intressepunkter - i rätt riktning, på rätt beräknat avstånd
5. Visar virtuella intressepunkter i kameravyn
29
Kapitel 5
Begränsningar vid användning av positionsteknik
Detta kapitel beskriver testningen av den egenutvecklade appen och utvärderar resultaten utifrån trovärdighet. Testresultaten väcker frågan om positionsteknikens begränsningar, projektets andra frågeställning, vilket leder till en uppföljande litteraturstudie på ämnet.
5.1 Testning av appen
Detta avsnitt beskriver hur tester med appen har genomförts, samt redogör för och analyserar några av de tester med tillhörande resultat som har dokumenterats under arbetets gång.
5.1.1 Genomförande
För att utvärdera den egenutvecklade appen och dess användbarhet har flera tester genomförts, både dokumenterade och odokumenterade. Det exakta antalet tester noterades aldrig, men uppskattas till ett tjugotal. Samtliga tester har gjorts utomhus i olika delar av Stockholms innerstad, framförallt i Hammarby Sjöstad och på Kungsholmen. För att få en varierad bild av appens beteende i olika slags stadsmiljöer genomfördes testerna på platser som vi valde att kategorisera som
”inne på gata, mellan höghus” respektive ”öppen plats”.
I testmiljön ”inne på gata, mellan höghus” står varje parkeringsautomat vid en husvägg, placerad mellan flervåningshus med cirka 5 våningar. I testmiljön
”öppen plats” är parkeringsautomaterna placerade på flera meters avstånd från omkringliggande byggnader.
Mobilen, med appen installerad, togs med till de platser med parkeringsautomater som appen kunde läsa in och visa som AR-objekt. Vi ställde oss på cirka 50–100 meters avstånd från en parkeringsautomat, väntade och tryckte sedan på knappen ”Uppdatera position” i appen. Då visades närliggande intressepunkter, motsvarande parkeringsautomater, som små röda skyltar i scenen. Vi gick sedan runt och närmare dom virtuella skyltarna, för att bedöma hur verklighetstrogen placeringen var i förhållande till dom verkliga
30
parkeringsautomaterna. Testerna genomfördes alltså stegvis där vi efter initiala mätpunkten förflyttade oss ett par meter sidledes eller i riktning mot parkeringsautomaten, väntade och tryckte på knappen ”Uppdatera position” igen.
Vi gjorde cirka tre sådana här mätpunkter för varje test. Vi avvaktade minst en minut mellan varje steg i testningen för att ge enheten tid och därmed säkerställa att inläsningen av intressepunkter verkligen utgick från enhetens faktiska position.
Detta upprepades minst en gång per parkeringsautomat och utfallen var snarlika.
5.1.2 Testresultat
Följande tester genomfördes i Hammarby Sjöstad hösten 2019. De utgör ett urval av de tester som genomförts. Vi valde att dokumentera dessa tester efter att vi genomfört ett flertal tester tidigare med samma resultat och upptäckt att de här två miljöerna gav tydligast utslag. Testresultaten har sorterats efter typ av omgivning. Varje resultat presenteras med en figur: till vänster är en skärmdump från Google Maps satellitvy, och till höger är en skärmdump från appens kameravy.
Skärmdumparna från Google Maps visar parkeringsautomatens plats med en gul skylt, smartmobilens egen uppfattning om sin position med en blå prick, samt smartmobilens verkliga position, varifrån skärmdumpen med appens kameravy är tagen, med en orange skylt. Dessa skärmdumpar togs alltså i samma veva som skärmdumparna från appens kameravy.
I skärmdumparna från appens kameravy syns virtuella skyltar som en röd ruta, tänkt att representera parkeringsautomatens plats. En gul ellips är inritad i efterhand för att tydligt visa var parkeringsautomaten befinner sig, och följaktligen var den virtuella skylten bör vara placerad.
Inne på gata, mellan höghus
Till vänster i figur 5.1 nedan ser vi att platsen som enheten tror sig vara på är fel, eftersom den blå pricken och den orangea skyltens positioner inte sammanfaller.
Till höger i figur 5.1 ser vi att den virtuella skyltens placering i scenen är fel, alltså inte placerad vid parkeringsautomaten. Att läsa in enhetens position igen hjälpte inte. Att förflytta sig hjälpte inte heller. Förflyttningarna som gjordes följde inte ett bestämt mönster utan genomfördes slumpmässigt på plats, men gemensamt för dom var att vi förflyttade oss ca 2-3 meter åt gången, sidledes eller i riktning mot parkeringsautomaten.
31
Figur 5.1: Testresultat från Henriksdalsallén 37
Till vänster i figur 5.2 nedan ser vi att enheten återigen läst in sin plats fel.
Till höger i figur 5.2 ser vi att skyltens placering i scenen också är fel. Att förflytta sig, ca 2-3 meter sidledes eller i riktning mot parkeringsautomaten, eller att läsa in positionen på nytt gav ungefär samma resultat.
32
Figur 5.2: Testresultat från Lugnets Allé 55
Öppen plats
Första testet genomfördes vid en park och det andra testet vid en parkeringsplats, se figurerna 5.3 och 5.4 nedan. Båda testerna visar till vänster i sin respektive figur att enheten har läst in sin position korrekt. Till höger i figurerna visas att den virtuella skylten är placerad rätt, vid parkeringsautomaten.
33
Figur 5.3: Testresultat från Anders Franzéns park vid Båtklubbsgatan 3
34
Figur 5.4: Testresultat från parkering vid Stapelgatan 5
5.1.3 Utvärdering av testresultat
Testresultaten utvärderas utifrån trovärdighet, vilket syftar till hur väl dom virtuella intressepunkterna, alltså röda skyltarna, är placerade i förhållande till dom fysiska intressepunkterna, alltså parkeringsautomaterna.
Samtliga tester som har genomförts har visat samma eller åtminstone väldigt snarlika resultat, det vill säga dålig precision på gator nära eller mellan höga byggnader, men bättre, och ibland riktigt bra, precision på öppna platser.
Inne på gata, mellan höghus
Kartbilderna för testerna ”inne på gata, mellan höghus”, visar att enhetens egen uppfattning om var den befinner sig är fel. Detta gör att avstånd och riktning till den fysiska intressepunkten, parkeringsautomaten, blir felberäknade. Detta, i sin tur, leder till att AR-objektet placeras fel. Testresultatet för placering av AR-objekt vid fysiska intressepunkter ”inne på gata, mellan höghus” visar därmed på låg trovärdighet.
35 På öppen plats
När enheten kunde avgöra sin position korrekt, kunde avstånd och riktning till intressepunkter beräknas korrekt likaså. Därmed har placeringarna av de virtuella skyltarna hög trovärdighet, eftersom de stämmer överens med verkligheten.
Sammanfattningsvis så varierar platsnoggrannheten med miljön som appen används i, och därmed trovärdigheten. Då appens användbarhet är direkt kopplad till hur trovärdigt AR-objekten kan placeras i kameravyn, kan vi konstatera att precisionen hos den positionsteknik som finns tillgänglig inte duger.
5.2 Positionsteknikens begränsningar
Testresultaten visar alltså att enhetens uppfattning om sin position påverkas av omgivningen – platsnoggrannheten är högre på öppna platser och lägre på platser nära bebyggelse. Detta avsnitt presenterar därför resultat från en uppföljande litteraturstudie om positionsteknikens begränsningar i praktiken, och lite närmre om hur den fungerar och påverkas av stadsmiljö. Vi har tagit del av en studie som bekräftar våra iakttagelser och sammanfattar den samt två artiklar, World’s first dual-frequency GNSS smartphone hits the market respektive Market understands value of dual-frequency, som tar upp utvecklingen av, samt ny teknik för positionstjänster.
5.2.1 Platsnoggrannhet hos smartmobiler i stadsmiljö
Ämnet platsnoggrannhet hos en smartmobil behandlas i studien Smartphone GPS accuracy study in an urban environment [32]. Studien genomfördes 2018 av Krista Merry och Pete Bettinger på University of Georgia i USA. Rapporten presenterades i juli 2019. Merry och Bettinger undersökte alltså platsnoggrannheten hos en iPhone 6 i stadsmiljö, två gånger om dagen under två årstider.
Studien konstaterar att precisionen i genomsnitt inte verkar påverkas av årstid eller väderförhållanden, varken vid användning av enbart GPS eller med både GPS och WiFi aktiverat. Platsnoggrannheten förbättrades dock under dagens gång, framåt eftermiddagen. Även om studien inte kunde avgöra i vilken utsträckning en iPhone 6 använder sig av WiFi för att bestämma sin plats, så kunde man se att precisionen förbättrades av att ha WiFi aktiverat. Platsnoggrannheten förbättrades även när fler WiFi-användare befann sig i närheten. Varför mängden
36
WiFi-användare påverkade precisionen kunde dom inte förstå, men rekommenderade det som ett ämne för framtida forskning.
De kunde även se tendensen att närliggande höghus försämrade platsnoggrannheten hos iPhone:n, och att den vid mätstationer på öppna platser förbättrades. Från detta drog de slutsatsen att höga byggnader har den främsta inverkan på precisionen i en smartmobils GPS-data i stadsmiljö.
Merry och Bettinger konstaterar att resultaten från studien stämmer överens med resultat från liknande studier. Däribland att platsnoggrannheten hos en iPhone 6 motsvarar platsnoggrannheten hos GPS-mottagare i låg- och mellanklass (t.ex. aktivitetsklockor av märken som Garmin och Magellan) i omgivningar med hög flervägsutbredning (eng. multipath), i detta fall stadsmiljö med höga byggnader. Hög flervägsutbredning innebär att signaler riskerar att studsa mot t.ex. höga byggnader, och att signalen då bryts innan den når fram till en enhets GNSS-mottagare.
5.2.2 Dual-frequency
Den första smarttelefonen med dual-frequency GNSS-mottagare lanserades i maj 2018 och allt fler telefontillverkare utrustar idag sina enheter med detta.
Efterfrågan har ökat, både från användare och utvecklare, för att få bättre precision vid platsbestämningen i olika typer av platsbaserade appar, till exempel AR-, navigerings- eller karttjänster [33].
Dual-frequency innebär att GNSS-mottagaren kan hantera dubbla signaler med olika frekvens, från varje satellit. För GPS heter signalerna L1 och L5, och för Galileo heter signalerna E1 och E5a. En fördel med dual-frequency är att det går att välja den signal som är bäst, alltså den med högst precision. En annan fördel är i situationer då ena signalen faller bort. Signalerna E5a och L5 har lägre frekvens och påverkas därför mindre av störningar från flervägsutbredning, jämfört med L1 och E1. Vi har tidigare sett att flervägsutbredning skapas i urban miljö med många och/eller höga byggnader, som ju är det som ger upphov till dålig platsnoggrannhet. I dagsläget kan felmarginalen variera flera meter, men med dual-frequency beräknas den vara högst ett par decimeter. Detta illustreras i figur 5.5. Dual frequency räknas fungera särskilt bra med det europeiska satellitsystemet Galileo eftersom det har ett större antal dual frequency-satelliter än övriga satellitsystem [34].
37
Figur 5.5: Signaler från satelliter och dess flervägsutbredning (figur från European GNSS Agency)
5.3 Sammanställning
RQ2. Vilka begränsningar har positionstekniken i dagens smarta enheter?
Tester som både vi och andra har genomfört visar att platsnoggrannheten hos dagens smarta enheter i stadsmiljö främst påverkas av höga byggnader i närmiljön.
För en platsbaserad AR-app som är tänkt att användas i just stadsmiljö är denna faktor kritisk.
Precisionen kan inte påverkas genom utveckling av programvara, utan snarare den hårdvara som enheterna är utrustade med. Yttre faktorer spelar också roll, som WiFi-sändare, antalet WiFi-användare, samt globala satellitsystem.
39
Kapitel 6
Diskussion
Detta kapitel analyserar valda metoder och deras inverkan på resultatet, samt lyfter problem och lösningar som hanterats under arbetets gång. En ekonomisk aspekt på arbetet samt etik och hållbarhet diskuteras, och kapitlet avslutas med en summering av slutsatser från projektet och framtida forskning på området.
6.1 Utvärdering av metoder
Detta avsnitt diskuterar de metoder som använts vid projektets genomförande, samt deras validitet och reliabilitet.
6.1.1 Metoder för genomförande
Nedan diskuteras de metoder som har valts och använts under projektets gång.
Litteraturstudie
På grund av vår begränsade erfarenhet av apputveckling för Android och AR inleddes projektet med en litteraturstudie inom dessa områden. Då AR för smartmobiler är ett nytt tillämpningsområde av tekniken, var det svårt att hitta bra dokumenterade exempel på AR-appar, än mindre för platsbaserade sådana.
De exempel vi hittade belyste inte heller hur platsnoggrannheten påverkade resultatet och användarupplevelsen av AR för platsbaserade appar. Men de studier och exempel vi hittade antydde ändå på att med en kombination av tekniker skulle det gå att bygga den app vi ville.
Fallstudie: vägdata visualiserad i AR-app
Att utveckla en egen app var nödvändigt för att kunna anpassa den till att visa vägdata. Även för att kunna redovisa vilka komponenter som krävs för en platsbaserad AR-app. Också för att kunna utvärdera om den fungerade för det tänkta användningsområdet.
