Transcript Prosjektrapport - Geomatikk

Norges teknisk-naturvitenskapelige universitet
Eksperter i Team – Fremtidens Kart
Prosjektrapport
Bård Haaheim, Mats Hallén, Lars Haraldsen,
Saywan Ghaderzadeh & Roy Sindre Norangshol
2010.5
Forord
Denne rapporten er en del av besvarelsen for emnet "Eksperter i
Team". Faget er et tverrfaglig prosjekt, der arbeidsteamet har bestått
av en dataingeniør, en byggingenør, en fra informatikk, en fra elektronikk
og en geograf. Vi har jobbet opp mot ere mulige idéer, og til slutt landet
på en problemstilling vi mener alle kunne delta i. Med tanke på vekten
av Gløshaugenstudenter ble prosjektet tilrettelagt mot det tekniske, men
med gode muligheter for implementering av kartdata. Det var viktig for
oss å skape en problemstilling der alle i gruppen kunne føle tilhørlighet til
oppgaven. Resultatet reekterer og viser alles kompetanse og ferdigheter
fra de forskjellige studieretningene.
2
Innhold
1 Sammendrag
4
2 Problemstilling
4
3 Eksisterende systemer
4
4 Systemløsninger
5
5 Teori
9
5.1 GIS - Geograske Informasjonssystemer . . . . . . . . .
5.1.1 Datum, koordinatsystem og prosjeksjon . . . . .
5.1.2 Datainnsamling . . . . . . . . . . . . . . . . . . .
5.1.3 Terrengmodell . . . . . . . . . . . . . . . . . . .
5.1.4 Georeferering . . . . . . . . . . . . . . . . . . . .
5.1.5 Digitalisering . . . . . . . . . . . . . . . . . . . .
5.2 Dijkstra's Algoritme og dets rolle i vårt system . . . . .
5.3 Elektroniske komponentløsninger . . . . . . . . . . . . .
5.3.1 Valg av topologi . . . . . . . . . . . . . . . . . .
5.3.2 Utviklingsmiljø og prosess . . . . . . . . . . . . .
5.3.3 Beregning av posisjon . . . . . . . . . . . . . . .
5.3.4 Resultat . . . . . . . . . . . . . . . . . . . . . . .
5.3.5 Evaluering av posisjonsberegning og nøyaktighet
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
10
11
12
12
13
14
15
16
16
17
18
18
6 Arbeidsprosess
20
7 UML
22
8 Prototype
24
9 Fremtidsvisjoner og samfunnsnytte
24
10 Konklusjon
26
A Lister over gurer og tabeller
28
3
1 Sammendrag
Vi planla et prosjekt der teamet skal ende opp med et produkt som fungerer.
Underveis i prosjektet fant vi ut at bruker- og funksjonskravene vi hadde satt
oss i begynnelsen ble for ambisiøse. Det har uten tvil vært tiden som har satt en
stopper for primærkravene våre, men likevel føler vi oss godt fornøyde med det
vi har fått til. Prosjektetresultatet ble mindre, men samtidig dannet gruppen
ere fremtidige visjoner og muligheter for videre utvikling.
Prosjektet vårt går ut på å lage et kart der aktøren skal få opp en video med
pilveivisning fra et punkt A til et annet punkt B. Visningen skal foregå på en
mobil og være i 3D. Vi innsnevret prosjektet til bare et kart over Realfagsbygget
på Gløshaugen, for å minske arbeidsmengde og få størst utbytte av resultatet.
Teamet kk på plass alt av kartdata, søking av korteste vei fra A til B og en simpel applikasjon som fungerte. For å beregne hastighet og koordinater til aktøren
brukes et aksellerometer. Disse beregningene/koordinatdataene aksellerometeret
skulle levere og selve logikken bak videoen, var de største problemene vi møtte
på. Utover dette har vi vurdert og illustrert fremtidige muligheter og laget visualisering av vår applikasjon slik den er nå. Med tanke på den korte tiden vi
har hatt til disposisjon og at halvparten av prosjektet skal brukes til prosess og
samarbeid, er gruppen meget fornøyd med det resultatet vi har oppnådd!
2 Problemstilling
Hovedproblemstillingen er å lage en applikasjon for innendørs navigering som
muliggjør enkel navigasjon fra A til B.
Denne løsningen skal være mobil og lett tilgjengelig, med fokus på fortløpende
oppdatert posisjonering innenfor et bygg. Det vektlegges også enkel og intuitiv
bruk, slik at ulike graske representasjoner som 3D, bilde og video skal vurderes. Basisløsningen skal være brukervennlig og billig, men skal ha muligheter
for videre utvikling og mer avanserte funksjoner. Systemet er tenkt som et "allemans eie" og bør således utnytte de teknologier som er tilgjengelig og mest vanlig idag. Samtidig skal det også fokuseres på fremtidig bruk og tenkte nyttige
funksjoner.
3 Eksisterende systemer
I dag nnes det mange ulike innendørs navigasjonssystemer, men de este av
disse er svært dyre å implementere eller gir for liten nøyaktighet til den tiltenkte bruken[4]. Systemer som benytter ultralyd, laser og RFID innehar svært høy
4
presisjon, men den sostikerte og omfattende strukturen nødvendig for posisjonberegningene, gjør implementering av dette i en større skala svært urealistisk
med tanke på nyttebruk opp mot omkostningene. Allikevel vil man snart nne
slike systemer innenfor spesielle institusjoner som sykehus hvor presisjon og effektivitet vil kunne bidra til å redde menneskeliv. Systemer som kan bruke eksisterende infrastruktur, slik som WLAN, GPS og GSM, vil billig kunne utnyttes
til posisjonering ved hjelp av ny programvare, men fordi disse radiosystemene
benytter frekvenser som reekteres lett av omkringliggende hindere som deriblant vegger, blir posisjoneringen med disse innendørs unøyaktig i det beste. Det
mest lovende av disse systemene i dag er WLAN, da denne standarden har vært
svært økende i popularitet og således økt kraftig i antall aksesspunkter. Alle
teknologiene presentert ovenfor er basert på elektromagnetiske signaler og blir
således en avveining av ønsket rekkevidde, gjennomtrengelighet/nøyaktighet og
kostnad. En annen og mindre utbredt metode, er å benytte akselerasjonsmålere,
kompass og gyroskop, såkalte IMSer1 , til å angi relativ posisjon og dermed absolutt posisjon ved en gitt referanse. Denne metoden har vært lite testet frem til
nå fordi disse komponentene ikke har kunnet gi tilstrekkelig nøyaktighet, men
i dag viser ere ulike studier[2] at posisjonering innenfor mindre tidsintervaller
vil kunne la seg realisere.
4 Systemløsninger
Vi valgte å benytte oss av verktøyet Java SDK2 til utviklingen, da dette språket
er det vi hadde mest erfaring ved. Java har sine fordeler ved at koden fungerer
på kryss av platformer3 og ikke minst lett å jobbe med. En annen fordel er
at vi i fremtiden ønsker at applikasjonen vår skal bli tilgjengelig via Androidplatformen, da denne er den fremtidsrettede platformen til smarte mobiler. Det
vil i årene fremover bli muligheter for raskere og mer nøyaktig akselerometer.
Dette vil hjelpe oss med veiberegningsvektoren. Android-platformen er også
bygget på Java, noe som gjør det enklere å ytte koden vår fra java til en annen
platform. Android SDK har i tillegg behagelige API4 som gjør at det er enkelt
å ta i bruk data fra aksellerometeret og kameraet på den mobile enheten.
Med tanke på at dagens smarte mobiler ikke har akselorometer som er nøyaktige nok for posisjonering, har vi valgt å benytte/utnytte elektroingeniøren Bård
for å utarbeide en microchip som gir oss data fra aksellerometerne. Denne
skal lage en retningsvektor som kan benyttes til navigering og posisjonering.
1 IMS - Internal Measurement System
2 Software Development Kit
3 Videodriverkodingen er spesikt kodet
erativsystemer/platformer også.
4 Application Programming Interface
mot linux, men dette lar seg ordne for andre op-
5
Mikrochipen er programmert i språket C, og har et grensesnitt for å eksportere
dataene til vår Java-applikasjon i sanntid for posisjoneringsoppdatering.
Nedenfor illustrerer vi hvordan applikasjonen vår fungerer. Den skal ta brukeren fra et startpunkt A til et endepunkt B. Hvert bilde viser antall meter igjen
til nærmeste sjekkepunkt (som brukes for å nne neste retning), og hvor mange
meter det er igjen til mål. Pilens retning regnes ut fra en retningsvektor som vi
oppdaterer ut fra forrige sjekkpunkt og fra dataene systemet får fra microchipen.
Figur 1: Vi står i begynnelsen av ruten, og får følgende informasjon representert
på skjermen: Vi må bevege oss fremover 3 meter for å nå neste sjekkepunkt, og
det igjenstår 11 meter før vi når vårt mål.
6
Figur 2: Vi har beveget oss igjennom døren, og ser at vi har passert sjekkepunktet vi hadde i sted. Vi har fått et nytt sjekkepunkt og det er 6 meter til neste
sjekkepunkt. Applikasjonen regner så ut at vi må snu oss 90 grader til høgre for
å forsette i riktig retning. Vi legger også merke til at vi har gått 3 meter, og
sluttdestinasjonen har da oppdatert seg til å vise 8 meter igjenstår. (11-3 = 8).
Figur 3: Vi har snudd oss 90 grader og startet å bevege oss fremover. Vi har
beveget oss nye 5 meter, og vi ser at navigasjonspilen har rettet seg opp og hvor
mange det er igjen til mål er oppdatert.
7
Figur 4: Vi er ganske nærme neste sjekkepunkt, og vi legger merke til at navigasjonspilen vil vi skal rotere oss 90 grade til høyre..
Figur 5: .. og støter på den døren vi skal gå igjennom. Vi åpner så døren, og
støter på neste sjekkepunkt og forsetter 2 meter frem og har da kommet til mål.
8
Figur 6: Mål
5 Teori
Denne seksjonen presenterer de ulike teoretiske aspektene som ligger til grunn
for utviklingen av prosjektet, og brukes således gjennom hele rapporten for å
begrunne de valg som er gjort.
5.1 GIS - Geograske Informasjonssystemer
Et geogrask informasjonsystem er en programvare som gjør det mulig å jobbe
med digitale kart framfor papirkart. GIS gjør det mulig å lagre geometriske data og beskrivende egenskaper i samme database. Det spesielle med geograske
informasjonssystemer er da at en kan foreta romlige analyser på de stedfestede
dataene. Man kan for eksempel nne raskeste kjøreveg mellom to punkter eller
kjøre spørringer mot befolkningsdata. Den største fordelen med GIS knyttet opp
mot vår oppgave, er å kunne digitalisere veilinjer innendørs i realfagsbygget på
Gløshaugen. Som sagt gjør GIS det mulig å lagre og bearbeide geometriske data.
GIS gjør det mulig å gjengi virkeligheten i tekst, tall og bilder. Dette er på mange
måter en forenklet modell av virkeligheten, fordi man velger å ta med objekter som er viktige for det man ønsker å beskrive. De geometriske egenskapene
kan tegnes som punkt, linjer eller ater. Vi ønsker å digitalisere veilinjer, og
9
for at disse veilinjene skal knyttes opp mot vårt studieområde Realfagsbygget,
Gløshaugen, må linjene bestå av koordinater.
Fordi realfagsbygget
er såpass lite i utstrekning så kunne vi valgt å bruke et lokalt koordinatsystem istedenfor et nasjonalt. Dette kunne vi ha fått til ved å lage vårt eget
referansesystem(aksesystem), men da måtte vi ha målt opp realfagsbygget sin
utstrekning for hånd eller med en totalstasjon. Det ville ikke ha blitt like overførbart å operere med et lokalt datum, hvis vi skulle utvidet navigeringen til å
omfatte hele Gløshaugen området. Dessuten kunne det oppstått feil som ikke
hadde latt seg korrigere, med tanke på bygninger sin beliggenhet i forhold til
hverandre. Det vi ønsker er at våre koordinater skal være overførbare til større
områder enn kun Realfagsbygget og dette er hovedgrunnen til at vi valgte å
georeferere plantegninger til et eksisterende koordinatreferansesystem.
Valg av datum, koordinatsystem og pro jeksjon:
5.1.1
Datum, koordinatsystem og prosjeksjon
For å bestemme nøyaktig posisjon på jordens overate må en kjenne
den eksakte formen til jorden.Jorden er ikke en perfekt kule, men mer en rotasjonsellipsoide med attrykking ved polene. Det geosentriske datumet WGS84
angir at radiusen til den store halvakse er på 6378137.0 m. Flattrykningen ved
polene er på 298.257 m.
Et datum er angitt ved:
Datum
1. Størrelsen og formen til ellipsoiden, det vil si angivelse av store halvakse
(ekvator) og lille halvakse (polene).
2. Posisjonering av koordinatsystemet i forhold til den fysiske jorden ved et
såkalt fundamentalpunkt.
3. Orientering av koordinatsystemet i forhold til den fysiske jorden.
I vår oppgave benytter vi WGS84 (World Geodetic system 1984) som er et vanlig
benyttet globalt og geosentrisk datum. Georefering ved bruk av GPS er basert
på datumet WGS84.
Datumet sørger for å knytte koordinatsystemet til jorden.
Geosentriske koordinater er basert på et treakset rettvinklet koordinatsystem
med origo i jordens sentrum, og posisjonen angis med x-, y- og z- koordinater.
Fordelen med geosentriske koordinater er at de dekker hele jorden og benyttes
av blant annet GPS.
Koordinatsystem
10
Figur 7: UTM-sonene i Europa/Asia.
For at stedfestede data i form av koordinater skal tegnes på en
plan ate og ikke jordens krumme må vi velge riktig kartprojeksjon. For å hindre
deformasjon av den krumme jordoveraten så må man alltid ta hensyn til de
ulike projeksjonstypene. Det mest kjente koordinatsystemet er UTM - Universal Transverse Mercator. UTM baserer seg på en sylinderprojeksjon som kutter
jorden ved polene. UTM dekker jorden fra 84 grader nord til 80 grader syd.
Rundt jorda blir det totalt 60 soner når hver sone er på 6 grader, og ganget med
20 belter (fra Nordpolen til Sydpolen) får man totalt 1200 soner i koordinatsystemet UTM. Ut ifra denne informasjonen vet vi at Realfagsbygget tilhører
WGS_1984_UTM_Zone_32N. Se gur 7
Pro jeksjon
5.1.2
Datainnsamling
Første steg i GIS er å hente kartdata, Kartdataene har vi fått fra N50 kartdata:
Vi valgte å bruke følgende datalag som datagrunnlag for digitaliseringen i GIS:
• Flatetema for alle bygninger i Trondheim kommune.
• Høydepunkter for Trondheim kommune.
• Høydekurver for Trondheim kommune.
11
Figur 8: Terrengmodell over Gløshaugen
• Flatetema for vann i Trondheim kommune.
• Flatetema for veger.
5.1.3
Terrengmodell
Etter datainnsamlingen genererte vi en terrengmodell (Se gur 8). Terrengmodellen heter TIN og består av linjer som danner et nettverk av ikke- overlappende
triangler. For å lage en TIN trenger vi høydedata for å kunne trekke linjer
som danner triangeler. Desto ere høydepunkter, desto bedre virkelighetsmodell. Vann ble tegnet etter middelvannstand, bygninger ble tegnet som hard clip
og veier som soft clip. Hard clip vil si at bygningene blir tegnet etter egne høydeverdier og ikke høydeverdiene i terrenget, som ellers ville sørget for at bygninger
blir tegnet skjevt, eller forsvinne i terrenget, i spesielle tilfeller der det ikke er
nok høydedata. Soft Clip vil si at veiene blir tegnet oppå terrengmodellen.
5.1.4
Georeferering
Målet med å bruke GIS som verktøy, er at vi skal få ut nøyaktige linjekoordinater
for realfagsbyggets mange rom og ganger. Derfor kk vi først tak i atetegninger
for Realfagsbygget på NTNU sine nettsider5 . Etasjeplan 1 og U1 ble lagret som
.ti og deretter åpnet i ArcMap som er det GIS vi bruker. Bygningslen tilhører
riktig koordinatreferansesystem og vi trengte å georeferere etasjeplan i forhold
til disse bygningene. For å få dette så nøyaktig som mulig ble det satt opp 7
5 http://www.ntnu.no/etasjeplan/vis_etgplan.php3?bygg=real/
12
Figur 9: Georeferering av Realfagsbygget på Gløshaugen, NTNU.
Figur 10: Plantegning av Realfagsbygget, sammen med veiene.
kontrollpunkter i hjørnene og i midten av bildelen. Med en RMS (Root mean
square) på kun 0,15 cm så må dette sies å være en overkommelig feilmargin. Se
gur 9
5.1.5
Digitalisering
Da begge etasjeplanene var georeferert gjensto digitaliseringen. Vi tegnet linjer oppå atetegningene (etasjeplanene) og ga hver linje en romlig kode. Koden
forteller hvilket rom linjen ender opp i. Når alle linjene for begge etasjene var
digitalisert (se gur 10) kjørte vi en "calculate geometry" operasjon på egenskaplen (se gur 11 ) til linjene. Alle linjene kk tildelt x- og y- koordinater for
start og sluttpunkt, deretter ble avstanden beregnet. Tilslutt ble egenskapslen
overlevert til Roy Sindre som skulle bruke disse koordinatene i en "korteste-vei"
algoritme.
Figur 11: Egenskaper til hver linje i veinettet.
13
Figur 12: Djikstra's algoritme for korteste vei fra et punkt til et annet.
5.2 Dijkstra's Algoritme og dets rolle i vårt system
I systemet vårt er det nødvendig å nne korteste vei mellom to 'sjekkpunkter'.
Kartet skal tross alt brukes til å hjelpe brukeren å komme fra A til B på kortest
mulig tid. Vi har kartlagt bygningen og mappet alle 'sjekkpunkter' vi trenger til
applikasjonen. I tilegg vet vi hvor langt det er mellom hvert checkpoint. Dermed
har vi laget et kart (en type graf), hvor Dijkstra's algoritme kan hjelpe oss å
nne den korteste veien mellom to vilkårlige punkter i kartet vårt.
Se gur 126 som skal illustrere hvordan Dijkstra jobber for å komme fra A
til B. Vi har ulike muligheter, men hver vei vi kan gå er et visst antall meter og
vi ønsker til slutt den korteste. Tallene fra 1-6 er stoppepunkter (checkpoints
i vår applikasjon), og vi starter i punkt 1. I mellom hvert checkpoint har vi et
gitt antall meter. På denne guren ser vi det er syv meter mellom 1 og 2, ni
meter mellom 1 og 3 og fjorten meter mellom 1 og 6. Beregningene begynner for
eksempel for node 3. Altså at vi skal nne korteste vei fra 1 frem til 3. Ettersom
vi starter i 1 må vi sjekke alle mulige veier frem til 3. 1-6-3 vil aldri bli en
mulighet, ettersom det er 14 meter fra 1-6 og allerede lenger enn den direkte
veien 1-3. Neste mulighet er 1-2-3. Vi ser at 1-2 har syv meter. Det betyr at
dersom vi nner en vei fra 2 til 3 som har under 2 meter, så har vi funnet en
kortere vei. Det er ikke slik denne gangen.
Etter vi har funnet korteste vei til 3, vil den nne korteste vei til 4 og 6 og
til slutt 5. Algoritmen går igjennom samtlige veier, til den til slutt har funnet
6 Se
http://roysn.tihlde.org/stu/Dijksta_Anim.gif i nettleseren for en animert utgave.
14
den optimale (altså raskeste) veien.
Dijkstra's algoritme er sentral for løsningen vår. Ut fra GIS får vi eksportert
digitaliserte veilinjer (polylinjer) for "veier" innendørs i realfagsbygget på Gløshaugen. De digitaliserte veilinjene inneholder metadata som beskriver start og sluttpunkt
på linjen ved koordinater, og noe mer hjelpende metadata som navn / identikator og lengden til linjen. Ut fra disse dataene, altså fra GIS-programvaren,
bearbeider vi de og oppretter en "node" for starten på linjen og en for slutten
av linjen. Dette utføres på alle de digitaliserte veilinjene som er gitt fra GIS
dataene. I tillegg vektlegges kanten (strekningen) mellom disse to nodene, og
nodene får egenskaper for nøyaktig koordinater av nodeposisjonen. Ut fra dette
får vi laget en nodegraf (les gjerne bykart) av alle nodene og strekningene i
mellom nodene, og kan dermed benytte oss av Dijkstra's algoritme for å nne
korteste vei mellom to noder.
Etter kjøring av algortimen vil vi få en en veibeskrivelse som forteller oss
hvilke noder vi må besøke for å komme oss raskest frem til måldestinasjonen.
For hjelp til navigeringen har vi ønsket oss et 3d-kart. Dette har vi løst med å
koble til et webcamera til pc'en og laget et miniprogram om kommuniserer med
videodriveren for å få bildedata fra kameraet. Bildestrømmen manipulerer vi
ved å sette inn piler som peker i den retningen aktørenskal gå. Denne retningen
nner vi ved bruk av enkel vektorregning, ettersom vi vet lengden og start og
sluttnoden til vektoren. Denne prosessen gjøres ved hvert "sjekkepunkt", og vi
får vite nøyaktig hvilken retning neste punkt vil være.
Helt til slutt vil aksellerometerene fortelle oss hvilken retning og fart vi
beveger oss i. Ut fra dette beregner vi en vektor for bevegelsen til aktøren.
Videre benyttes denne til beregning av den nye retningsvektoren ved neste
sjekkepunkt.
5.3 Elektroniske komponentløsninger
Det nnes ere ulike typer elektriske komponenter som kan detektere rotasjon
og translasjon. Av de mest sentrale, nner man akselerasjonsmålere, gyroskop
og kompass. Disse kommer i mange ulike størrelser og prisklasser, og er i sterk
korrelasjon med nøyaktigheten og målefrekvensen til komponenten. De kommer
også med ere typer grensesnitt, der de digitale typisk er mye lettere og raskere å
implementere, men samtidig dyre. Valg av komponenter må derfor være en nøye
avgjørelse mellom tilgjengelig utviklingstid, budsjett og krav til nøyaktighet.
Generelt i dag er akselerasjonsmålere de billigste komponentene av denne, typen
sett i forhold til nøyaktighet.
15
5.3.1
Valg av topologi
Ut fra den teoretiske bakgrunnen innenfor eksisterende systemer og mulige
elektroniske løsninger, ble det valgt å teste en løsning for posisjonering som
bare benytter akselerasjonsmålere. Dette fordi det er gjort få liknende forskningsstudier, og at de som er gjort viser et stort potensiale for denne type
teknologi. For å få til posisjonering i tre dimensjoner valgte vi å utvikle en egen
databrikke i stedet for å bruke eksisterende løsninger, som for eksempel nnes i
mange av dagens mobiltelefoner. Brikkene som benyttes i mobiltelefoner består
oftest av et billig akselerometer og et gyroskop, hvilket utgjør et system som
ikke innehar tilstrekkelig nøyaktighet for å realisere ett posisjoneringssystem.
Vi valgte derfor å teste en løsning med re akselerasjonsmålere satt opp i ett
kvadratisk mønster slik gur 13 på neste side viser. At dette er en løsning som
fungerer var en antakelse, og var derfor en del av prosjektet med høy risiko. Den
ble likevel valgt fordi nøyaktig posisjonering er viktig for at systemet skal fungere. Studier[2] viser at ett akselerometer kan nne posisjonen sin i planet med
en feilmargin på 16 meter i timen for et fritt bevegelig objekt, og tilnærmet null
for bevegelse i én dimensjon, hvilket er mer enn godt nok for vår applikasjon.
5.3.2
Utviklingsmiljø og prosess
Da utviklingstiden for brikken måtte være kortest mulig for at systemet skulle
kunne bli realisert før endt prosjekttid, ble det valgt å bruke Proteus som
utviklingsmiljø for kretskortet til systemet, et program som er relativt enkelt
og raskt i bruk. Figur(ref:over) er et 3D-animert bilde av kretsen generert av
Proteus. Utlegget var ferdig i uke 5 og ble sendt til produksjon i Kina gjennom
bedriften PCBCart. På grunn av høytid i Kina samt lav prioritet på grunn av et
lite bestillingskvantum, var ikke kretskortet ferdig montert og for vår hånd før i
uke 10. For prosessering av akselerasjonsdata og videresending til datamaskin,
ble en mikrokontroller fra Atmel valgt. Programmering av denne ble gjort gjennom Atmels egne utviklingsmiljø, AVRStudio 4. Det første programmet som ble
laget, sendte bare akselerasjonsdataen direkte til en seriellport og ble lagret i
Excel-ler på den tilkoblede pcen. Dette ble gjort for å lettere kunne behandle
dataene og teste ulike algoritmer for utregningen av posisjon. Ved å føre brikken
i bestemte avstander, retninger og vinkler, ble stabil testdata hentet. Fordi disse
testdataene er fra kjente bevegelser, kan enkle matematiske formler brukes for
å beregne posisjon slik neste avsnitt viser. Dette ble benyttet for å se på hvor
nøyaktig posisjonen kan beregnes.
16
Figur 13: Microchippen
Figur 14: Microchip input/output.
5.3.3
Beregning av posisjon
Vi begynte med å prøve og sette opp formler som kan regne translasjonen langs
og rotasjonen om rommets tre akser. Data som kan fås ut fra et akselerometer
er akselerasjonen langs, på tvers og normalt på planet akselerometeret ligger.
Det er re akselerometre på brikken slik som gur 13 viser. Da blir det tolv
akselerasjonsverdier som skal brukes for å regne translasjon og rotasjon om tre
akser. Disse kan videre brukes for å regne ut hvordan man har beveget seg og
hvor lang er strekning som er tilbakelagt.
Etter å ha sett en del på det ble vi overbevist om at det er både tidskrevende
og også komplisert med tanke på våre matematiske kunnskaper. Derfor ble det
valgt å forenkle og gjøre noen antagelser for å kunne gå videre. Derfor så vi
17
på bevegelser langs det horisontale planet. Det tilsvarer translasjon langs to
akser og rotasjon om en akse som står normalt på de to horisontale aksene. Vi
har tatt utgangspunkt i den vanlige formelen for beregning av strekning ut fra
akselerasjon og fart.
ˆ
S(t) = S(0) +
5.3.4
ˆ
V (t)dt +
a(t)tdt
Resultat
Fra testoppsettet ble store mengder
akselerasjonsdata hentet inn fra forskjellige tester. En kort grask oppsummering av de viktigste resultatene er gitt i gurene 15a og 15b.
Grafen i gur 15a er hentet ut fra en måleserie der brikken først har ligget i
ro for så å bli yttet langs en rett linje ca. 5 cm. Flyttingen av brikken er gjort
for hånd langs en linjal og er således relativt unøyaktig og ment mer som et bevis
av konseptet fremfor nøyaktig beregning. Det er også benyttet et lavpasslter på
dataen for å fjerne raske endringer i akselerasjonen, ofte forbundet med målestøy,
for å generere en "glattere" bevegelse. Figur 15b viser en graf hentet fra en brikke
som først lå stille i 3 sekunder for så å bli vekselvis spunnet rundt og stoppet
av en saktegående drill.
Måledata fra akselerometerbrikken
Nøyaktighetsberegninger
Fordi måleseriene er så unøyaktige som de er, er
det vanskelig å si noe konkret om nøyaktigheten det er mulig å oppnå med
denne typen brikke. Under er likevel et grovt estimat av feilen gjort ved en rett
bevegelse.
e(t) =
((0.05 ± 0.002) − 0.052)
∗ tsec
5s
emax = −2.88[
5.3.5
meter
]
time
Evaluering av posisjonsberegning og nøyaktighet
Som gur 15a og 15b viser, kan posisjon beregnes ut i fra akselerasjonsdataene
under gitte omstendigheter. Feilestimatet viser et potensiale på under tre meter
feil i timen og er derfor et mer enn godt nok resultat for punktnavigasjon innendørs. Da man har avgrensede steder man kan gå i et bygg, vil systemet kunne
korrigere for drifting ved å sørge for å "snappe" til gangen man går i og lagre
dieransen til målt posisjon. Også der ganger skifter retning, vil man kunne få
korrigert feilen fordi systemet vet at personen må svinge når svingen kommer,
18
(a) 5cm bevegelse i x-retning.
(b) Rotasjon i planet.
Figur 15: Måledata fra akselerometerbrikken
19
og dermed kan systemet merke når personen endrer retning og igjen er den absolutte posisjonen kjent. Det som lager usikkerhet i forhold til nøyaktigheten
er at disse dataene er sterkt påvirket av jordens gravitasjon. For testscenarioet er påvirkningen fra gravitasjonen på akselerasjonen kjent. Når brikken ikke
lenger har en fast vinkel vil bidraget fra gravitasjonen være en variabel som
funksjon av utregninger fra tre forskjellige dimensjoner. Dette vil gjøre feilen
større. Jordens gravitasjon på 1G7 utgjør så mye som 50% av oppløsningen til
akselerometerene, og vil derfor trolig være den største bidragsyteren til akselerasjonene i alle retningene fordi brikken sjelden vil ligge helt i vater. Av denne
grunnen er beregning av vinklene til brikken svært viktig, og feilen vil trolig
ligge rundt 2.883 = 23.89 meter i timen. Da dette er sagt, vil en slik feil også
trolig være godt innenfor det akseptable for et innendørs posisjoneringssystem.
Dette fordi det er svært kort avstand mellom navigeringspunktene og mange
av disse vil kunne brukes som referansepunkter da man innendørs ikke kan gå
utenfor gangene systemet er programmert med.
6 Arbeidsprosess
I begynnelsen av et prosjekt settes standarden for hvordan prosjektet utvikles
senere. Det er her planlegging av arbeidsprosessen tar sted. Hvordan og når man
skal arbeide, samt hvordan bestemmelser skal taes til en hver tid avgjøres, og
ofte blir det utviklet en samarbeidskontrakt for dette. Ettersom EiT tar for seg
samarbeidsmetodikk like mye som selve prosjektet brukte vi mye tid på dette i
startfasene. Prosjektet begynte med vurderinger av ere mulige arbeidsprosesser
og metodikker. Alle medlemmene i gruppen har jobbet med en eller annen form
for teamarbeid før. De største utfordringene vi støtte på var derfor rundt det
tverrfaglige; forskjellige bakgrunner og timeplaner. Vi så på arbeidsmetodikker
som vannfallsmetoden og SCRUM. Ettersom dette var et prosjekt som omhandler femti prosent prosess og femti prosent prosjekt, tillot vi oss å utvikle/bruke
en egen metodikk der vi forbeholdt en at lederstruktur og fast avtalte arbeidsdager. Lederstrukturen endret seg utover prosjektet, noe vi har gått nærmere
inn på i prosessrapporten. Helt i starten av alle prosjekter setter man ofte opp
en risikoanalyse. Det gjorde også vi i dette prosjektet. Risikoanalyse er evnen til
å vurdere og sannsynligjøre mulige fremtidige problemer og i hvor stor grad de
stopper utviklingen av prosjektet. Risikoanalysen bør også oppdateres i løpet
av prosjektfasen.
Ut fra tabell 1 på neste side vurderer vi alt fra sykdom til at mikrochippen ikke ankommer til riktig tid og hvor store konsekvensene blir av dette.
7 1G
= jordgravitasjonen = 10 sm2
20
21
Aktivitet
Hele prosjektet
Hele prosjektet
Alle andre
All
Ønsket produkt, testing
Hele prosjektet
Applikasjon/Microbrikke
Digitale kartet
Microbrikke
Hele prosjektet
Nr
1
2
3
4
5
6
7
8
9
10
Risikofaktor
Gruppemedlemmer gjør ikke jobben sin
Uenighet innenfor gruppen
Sykdom/fravær
Dårlig kommunikasjon innad i gruppen
Microbrikke blir ikke levert
Mister repositoriet med alt arbeid
Tar for lang tid med programmering
Blir for mye jobb
Feildesignet av oss
For lite kompetanse
H
H
M
H
M
H
H
L
M
H
Konsekvens
Strategi for løsning
Løs så fort som mulig. Motiver hverandre. Ta opp i felleskap
Søke hjelp hos studasser, kompromiss
Fordele arbeid. Ha ere som jobber med det samme
Ha møter regelmessig, jobbe sammen
Skriver det teoretiske rundt det
Oppdatare og 'commite' ofte
1) Alle hjelper til. 2)Fokusere mer på det skriftlige
Fokusere på et mindre område
Må redesigne /modisere - sette av ekstra tid til dette
Redusere kompleksitet og arbeidsmengde
Tabell 1: Risikotabell
L
L
M/H
L
L
L
M
M
L/M
M
Sannsynlighet
Handling
Reduser/Unngå
aksepter/reduser
Aksepter
Unngå
Aksepter
Aksepter
1)reduser 2) aksepter
aksepter
aksepter
aksepter
alle
alle
alle
alle
Bård
alle
Roy Sindre, Lars
Mats
Bård
alle
Ansvar
Figur 16: Domenemodell
Vi diskuterte også tiltak for å kunne løse disse problemene og hvem som har
ansvaret om uhellet skjer. For eksempel har vi hatt tilfeller av sykdom gjennom
prosjektet. Dette påvirket gruppen, og førte til at andre måtte overta arbeid og
jobbe ekstra. I tillegg viste det seg at mikrobrikken kom mye senere enn planlagt. Heldigvis kom den i god nok tid til at vi kk jobbet med den og brukt den
til en viss grad i prosjektet vårt. Uansett er det viktig å være forberedt og ha
en plan i bakhånd når slike ting dukker opp. I dette prosjektet visste vi hva vi
kunne gjøre da uhellet var ute, noe som resulterte i at vi var bedre forberedt og
klarte å håndtere situasjonene på en bra måte.
7 UML
I starten av prosjektet, modellerte vi frem en domenemodell og klassediagram
over hvordan vi planla for systemene å kommunisere med hverandre. Se gur 16
og 17. Disse viser en hovedoversikt og et mer detaljrikt oversikt over systemet
vårt.
22
Figur 17: ASM
23
Ut fra den faktiske implementasjonen har vi fjernet ekstra funksjonaliteter
som "Finn en venn" og "Finn ledig rom", på grunn av tidsmangel. Helt i starten
av prosjektet laget vi oss en plan over arbeidet som skulle gjøres. En slik plan er
meget nyttig med tanke på gjennomføring av arbeid og holde tidsfrister. I gur
18 vises planen i et Gantt-diagram.
Selv med en slik plan var det vanskelig å overholde alle frister. Det ble noe
sykdom og dessuten kk vi tak på microchippen senere enn planlagt. Dette
resulterte i noen forskyvninger i diagrammet. Vi velger likevel å vise den opprinnelige planen vår her, ettersom vi mer eller mindre har holdt oss til den hele
veien.
8 Prototype
Vi henviser til videoen8 vår som demostrerer vår prototypeapplikasjon som navigerer oss fra et sjekkpunkt i gangen og over til R54.
9 Fremtidsvisjoner og samfunnsnytte
Systemet vi har laget er et system som kunne være realistisk å realisere innenfor
tidsrammene til EiT. Det ble fremmet mange forslag i utviklingsfasen, men de
este ble lagt til siden på grunn av tidsmangel. Første og viktigste steg i utviklingen vil være å portere systemet til mobile applikasjoner. For å kunne få til dette
må nye enheter utvikles med tilstrekkelig nøyaktighet i akselerometrene, samt
at koden vi har skrevet må endres til å være mer eektiv slik. Når først et slikt
system er oppe vil mange nyttige utvidelsesfunksjoner kunne lages, funksjoner
som vil gjøre systemet til en ressurs og forhåpentligvis et ønske av folk est.
Mange idéer til utvidelsesfunksjoner er fremmet og under følger de mest sentrale.For bruk i oentlige bygg som skoler kan tilleggsinformasjon rundt rom og
ressurser legges til, slik at man for eksempel kan nne nærmeste ledige grupperom eller plass på lesesal. Vi har også tenkt på en typisk venne-funksjon som
skal lokalisere alle venner på kartet. Planen var å kunne integrerere dette opp
mot applikasjoner som Facebook og Twitter. Muligheten ligger der. Systemet
slik vi har laget det, har i seg selv begrenset samfunnsnytte. Dette kommer av
tiden vi har hatt til disposisjon ikke var nok for en så stor applikasjon som
vi prøvde oss på. Når det er sagt har systemet slik vi hadde tenkt det kunne
bli, ere gode samfunnsnyttige funksjoner. Tenk for eksempel i områder ved snøeller gruve-ras. Dersom man kartlegger slike områder kan man til enhver tid vite
hvor arbeiderne/kompisene benner seg og dermed gjøre lokaliseringsjobben en8 http://roysn.tihlde.org/stu/eit2010-fk-howitworks.avi
24
25
Figur 18: GANTT-diagrammet
klere dersom noen skulle bli tatt av ras. Et annet eksempel er rullestolbrukere
som trenger å nne korteste rullestolvei. De vil selvfølgelig ikke ned vanskelige trapper. Dersom man kartlegger områder rundt kjøpesentre, eldrehjem og
sykehus kan dette forenkles for funksjonshemmede.
10 Konklusjon
I løpet av EiT har vi utarbeidet en prototype av et system for navigasjon og
posisjonering innendørs. Vi har realisert posisjoneringsystemet i form av en
nyutviklet databrikke bestående av re aksellerometere. Denne brikken sender
posisjonsdata til et Java-program som synkroniserer dette opp mot veien som er
valgt. Dataprogrammet henter mulige veier å gå fra en database laget i GIS og
behandler disse dataene med Dijkstras algoritme for å nne korteste vei mellom
punktene brukeren har valgt. Visuelt blir veien vist med en pil på skjermen.
Til dags dato er det matematikken og logikken bak nåværende akselleromtere
som er den begrensende faktoren i systemet vårt. Status for systemet nå er en
applikasjon som beviser konseptet. Vi har bevist at idéen kan fungere, og at det
ikke er vanskelig å forbedre den. Videre tenkte vi på ere ideer til utvidelser og
forbedringer av systemet, som navigering i sykehus og nne korteste rullestolvei
er to muligheter. Vi ser et stort utviklingspotensiale i produktet men også at
veien til et ferdig produkt er lang. Basert på arbeidet vårt og de undersøkelser
vi har gjort mener vi det er mulig å utvikle en fullt fungerende mobil enhet, og
det eneste som setter en stopper er tid og ressurser.
26
Referanser
[1] Tor. Bernhardsen. Bernhardsen, Tor. 2006: Geograske informasjonssystemer. 4. Utgave. Vett & Viten, Nesbru. 2006.
[2] Ching-Hsien
Hsu
and
Chia-Hao
Yu.
An
Accelerometer
Based
Approach
for
Indoor
Localization,
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5319234.
5 May 2010.
[3] Sarah Cornelius Heywood, Ian. An introduction to geographical information
systems . 3rd ed. Harlow : Pearson Prentice Hall ISBN 978-0-13-129317-5 ,
ISBN 0-13-129317-6. 2006.
[4] Rainer Mautz.
Overview of Current Indoor Positioning Systems,
http://www.gc.vgtu.lt/upload/geod_zurn/geodezija%202009%201%2003%20mautz.pdf.
5 May 2010.
27
A Lister over gurer og tabeller
Tabeller
1
Risikotabell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figurer
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Vi står i begynnelsen av ruten, og får følgende informasjon representert på skjermen: Vi må bevege oss fremover 3 meter for å
nå neste sjekkepunkt, og det igjenstår 11 meter før vi når vårt mål.
Vi har beveget oss igjennom døren, og ser at vi har passert
sjekkepunktet vi hadde i sted. Vi har fått et nytt sjekkepunkt og
det er 6 meter til neste sjekkepunkt. Applikasjonen regner så ut at
vi må snu oss 90 grader til høgre for å forsette i riktig retning. Vi
legger også merke til at vi har gått 3 meter, og sluttdestinasjonen
har da oppdatert seg til å vise 8 meter igjenstår. (11-3 = 8). . . .
Vi har snudd oss 90 grader og startet å bevege oss fremover. Vi
har beveget oss nye 5 meter, og vi ser at navigasjonspilen har
rettet seg opp og hvor mange det er igjen til mål er oppdatert. .
Vi er ganske nærme neste sjekkepunkt, og vi legger merke til at
navigasjonspilen vil vi skal rotere oss 90 grade til høyre.. . . . . .
.. og støter på den døren vi skal gå igjennom. Vi åpner så døren,
og støter på neste sjekkepunkt og forsetter 2 meter frem og har
da kommet til mål. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mål . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UTM-sonene i Europa/Asia. . . . . . . . . . . . . . . . . . . . . .
Terrengmodell over Gløshaugen . . . . . . . . . . . . . . . . . . .
Georeferering av Realfagsbygget på Gløshaugen, NTNU. . . . . .
Plantegning av Realfagsbygget, sammen med veiene. . . . . . .
Egenskaper til hver linje i veinettet. . . . . . . . . . . . . . . . .
Djikstra's algoritme for korteste vei fra et punkt til et annet. . .
Microchippen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Microchip input/output. . . . . . . . . . . . . . . . . . . . . . . .
Måledata fra akselerometerbrikken . . . . . . . . . . . . . . . . .
Domenemodell . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ASM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GANTT-diagrammet . . . . . . . . . . . . . . . . . . . . . . . . .
28
6
7
7
8
8
9
11
12
13
13
13
14
17
17
19
22
23
25