Efficient Position Updating Pervasive Positioning, Q3 2010 Lasse H. Rasmussen, 20097778 Christian Jensen, 20097781 12-03-2010
1 Introduktion Denne rapport har til formål at beskrive implementeringen og evalueringen af forskellige strategier til effektiv positionsopdatering på en mobiltelefon. Opgaven går ud på at implemtere et system bestående af server PC og en mobil-klient. På serveren skal et program implementeres, som skal kunne modtage positionsopdateringer fra mobilklienten og logge disse i en.kml-fil samt logge antallet af beskeder fra mobilklienten. Til den mobile enhed skal et program implementeres, som understøtter forskellige strategier for en effektiv positions-opdatering- og rapportering via den indbyggede GPS og en dataforbindelse via GSM. Herved vil mobiltelefonens batterilevetid kunne forlænges og dataforbruget nedsænkes. Den anden del af opgaven går ud på at afprøve de implementerede strategier ved forskellige eksperimenter. Ekspterimenterne munder ud i kortoversigter med de rapporterede positioner til serveren samt den reelle rute og slutteligt sammenligningnes de forskellige strategier ved anvendelse af de fremkomne resultater. Mobiltelefonen er en Android Dev Phone 1 (T-Mobile G1) kørende operativsystemet Android 1.6, og programmet implementeres i Java. Serverprogrammet udvikles ligeledes i Java, men dog på normal java platform til anvendelse på PC. 1
2 Implementering Dette afsnit beskriver implementeringen af server og klient samt opståede problemer og løsningerne på disse. 2.1 Mobil-klient Til eksekveringen af de forskellige strategier på den mobile klient, er der udviklet en GUI, hvori man kan vælge imellem de forskellige strategier og angive de tilhørende parametre. Denne GUI kan ses på Figur 1. For hver af de implementerede strategier gemmes antallet af GPS fixes i en fil på telefonens hukommelseskort. Disse anvendes til en sammenligning af de forskellige strategier, hvilket beskrives i afsnittet Evaluering. Implementeringen af de forskellige strategier findes i følgende underafsnit. Figur 1: GUI til mobilapplikationen 2.1.1 Indlæsning af GPS-position For at kunne implementere de påkrævede strategier, kræver dette først og fremmest, at det er muligt at indlæse GPS koordinater. Dette voldte større problemer end det umiddelbart burde, da adgangen til telefonens GPS er stærkt begrænset i Android. Det viste sig, at man ikke eksplicit kan tænde og slukke for GPS en, og ligeledes kan man ikke direkte få ét og kun ét GPS fix. GPS en tilgås igennem en manager klasse, hvor man kan tilmelde sig, når et nyt GPS fix er foretaget. Her har man valget imellem periodisk opdatering eller opdatering når en vis afstand er passeret (altså to af opgavens krav). Denne indbyggede funktionalitet blev dog ikke benyttet, da vi selv skulle udvikle strategierne. Indlæsningen af en enkelt GPS-position blev implementeret ved først at tilmelde sig GPS-opdateringer, give tid til et GPS-fix kan opnås, og derefter afmelde sig opdateringerne. 2
2.1.2 Periodisk Den simpleste strategi er den periodiske, hvor der foretages et GPS fix i et givent interval, hvilket derefter sendes til serveren. Implementeringen er simpel udvidelse af indlæsningen af et GPS-koordinat, hvor intervallet imellem indlæsninger blot sættes til den angive værdi som parameter. 2.1.3 Afstands-baseret Til den afstandsbaserede strategi, skal der sendes en positionsopdatering til serveren, når GPSkoordinaterne viser, at enheden har flyttet sig en givet afstand. Dette er implementeret ved tage udgangspunkt i en GPS position, hvortil der løbende beregnes afstande til nye GPS fixes. Når afstanden er nået, begyndes denne rutine forfra, med sidst kendte position som start-position. Afstandende er beregnet ved brug af længde- og breddegrad for GPS-positionerne, som er anvendt i en formel til afstandsberegning. Denne formel kaldes Haversine-formlen og tager jordens krumning i betragtning. Intervallet imellem GPS er sat til 1 sek, og antallet af GPS fixes gemmes lokalt på mobiltelefonen. 2.1.4 Afstands-baseret med maks imal hastighed Denne strategi er baseret på den ovenstående, men i stedet for at tage et GPS fix hvert sekund, anvendes en angivet maksimal hastighed til at beregne, hvor lang tid der kan ventes indtil næste GPS fix inden for den angivne afstand. Dog er der endnu en variation i algoritmen, da når der beregnes afstand, og afstanden er mindre end den angivne afstands-parameter, skal intervallet imellem GPS fixes løbende indskrænkes ved at se på den nuværende afstand og afstandsparametren. Dette er gjort ved anvendelse af formlen: t =, hvor t = tid, s = den paramater-angive afstand, s 0 = den nuværende afstand og v = hastighed. Heraf findes tiden, som er den tid, der ventes imellem GPS fixes. 2.1.5 Afstands-baseret med bevægelses-detektering Denne strategi er baseret på samme afstands-algoritme som i afsnit 2.1.3. Denne strategi skiller sig ud ved at gøre brug af det indbyggede accelerometer til at detektere at brugeren er i bevægelse. Når brugeren er detekteret i bevægelse, skal der foretages GPS fixes, og når brugeren står stille skal ingen forespørges. Dette er implementeret ved at aflæse de 30 seneste målinger for hver akse, og se på om ændringen for hver akse er større end 0,3 m/s 2. Hvis dette er tilfældet, antages det at telefonen er i bevægelse. Værdien på denne ændring kommer af, at accelerometeret er forholdvis billigt, og derfor varierer værdierne konstant pga. støj, hvor selve støjen kan give udsving på op imod 0,2 m/s 2. Derfor kunne grænsen ikke sættes længere ned. Selve bevægelses detekteringen vil kunne optimeres ved i stedet for at kigge på den enkelte akse, at kigge samlet set på alle 3 akser og deres variationer. Den implementerede metode har dog vist sig at være tilstrækkelig til eksperimenterne. 3
2.2 Server Serveren har en åben TCP forbindelse, hvorigennem klienten kan sende GPS-positioner i formatet longitude;latitude som tekststrenge. Disse positioner gemmes i en.kml fil for hver session, indeholdende GPS-positioner for en angivet strategi. Samtidig logges antallet af beskeder fra telefon til server, som anvendes til sammenligning i næste hovedafsnit. Serveren er implementeret i klassen ServerClass.java og anvender som default portnummer 9999 alternativt kan det specificeres som første argument. Server applikationen er vedlagt i filen Server.jar, som kan eksekveres ved java -jar Server.jar eventuelt efterfulgt af portnummer. 4
3 Evaluering Dette afsnit beskriver og illustrerer vha. screenshots genereret ud fra de forskellige.kml filer, resultaterne fra de forskellige strategier. Slutteligt vil resultaterne fra de forskellige strategier sammenholdes og kommenteres. 3.1 Periodisk Parameter: Periode = 1 sekund Det ses tydeligt at denne strategi ved en lav hastighed, har mange tætliggende plots. Ved en periodisk rapportering med 1 sekunds mellemrum, bliver tætheden mellem plots faktisk mindre end GPSusikkerheden, da man ikke når at bevæge sig betydeligt på 1 sekund. Vi ser desuden en afvigelse i positionerne fra vores rute på visse strækninger. Det er specielt tilfældet på de strækninger hvor bygninger står meget tæt at usikkerheden er størst. Derimod kan vi også se at i de områder hvor der er mere fri plads omkring og derved bedre GPS-dækning ligger vores placemarks også tættere på ruten. Det er ikke umiddelbart til at se udfra billedet, at vi på de 2 pausepositioner modtager fixes selvom vi står stille. Dette er selvfølgeligt forventet, men en unødvendighed, som de andre strategier undgår. 5
3.2 Afstandsbaseret Parameter: Afstand = 50 m Ved den afstandsbaserede strategi med en distance-threshold på 50 meter kan vi følge GPS-enheden med en sikkerhed på 50 meter. De plottede placemarks ligger med en pæn afstand fra hinanden og at afstanden mellem dem passer meget godt på 50 meter, hvilket indikerer at nøjagtigheden på de 50 meter fungerer efter hensigten. Vi kan desuden se, at specielt ved bevægelse rundt om hjørner, kan en afvigelse i positionen betyde enten kortere eller længere til næste position (alt efter hvilken side af hjørnet afvigelsen ligger). Igen er der større usikkerhed i positioneringen i områder med tætliggende og høje bygninger end i de mere fritliggende pladser. 6
3.3 Afstandsbaseret med maksimal hastighed 1 Parametre: Afstand = 50 m Maks hastighed = 37 km/t (~10,44 m/s) Her forventer vi at se nogenlunde det samme som ved den afstandsbaserede strategi; placemarks med ca 50 meters mellemrum. Dog betyder en betydelig afvigelse i Fix 1 at antallet af placemarks bliver en smule højere, da vi på en kortere afstand fra starten vil have bevæget os 50 meter fra første placemark. Igen kan det underbygges at GPS-nøjagtigheden er ringere på strækningen fra start til første hjørne, hvor der er tæt liggende høje bygninger. 7
3.4 Afstandsbaseret med maksimal hastighed 2 Parametre: Afstand = 50 m Maks hastighed = 7 km/t (~2 m/s) I forhold til de billeder for de 2 foregående afstandsbaserede strategier kan der ses en forskel i afstanden mellem placemarks. Specielt 2-6 ligger med større afstand end ellers forventet. Dette kan skyldes en usikkerhed i GPS aflæsningen. Det kan også skyldes udregningen for det delay, der indsættes mellem fixes for at beregne hvornår de 50 m er nået. Endnu en mulighed kan være at vi under eksperimentet har bevæget os hurtigere end maksimum-hastigheden, hvilket lige præcis vil forsage en sådan afvigelse. Den sidste mulighed synes den mest sandsynlige, da vi yderligere kan se at placemark 7-12 ligger med en fornuftig afstand fra hinanden og at vi på den distance muligvis har nedsat hastigheden. 8
3.5 Afstandsbaseret med bevægelses-detektering Parameter: Afstand = 50 m Der er som forventet en lighed mellem billedet for eksperimentet for de andre afstandsbaserede strategier og denne. Afstanden mellem placemarks synes fornuftig og endnu engang er der større afvigelse i nøjagtigheden på den lange strækning med bygninger på begge sider af vejen. Fordelen ved denne strategi er ikke til at se ud fra billedet; nemlig det, at der ikke forespørges på GPS-målinger når enheden ikke er i bevægelse. 9
3.6 Sammenligning Strategy GPS Fixes Reports Time Span Fixes/sec Reports/sec #1 Periodic (1 s.) 483 483 8:06 0.994 0.994 #2 Distance Based (50 m.) 470 13 8:27 0.927 0.026 #3 Distance Based (50 m.) 248 14 8:57 0.462 0.026 Max Speed (37 km/t) #4 Distance Based (50 m.) 31 12 8:53 0.058 0.023 Max Speed (7 km/t) #5 Distance Based (50 m.) Accelerometer trigger 488 14 8:46 0.923 0.027 De forskellige eksperimenter bliver herunder nævnt som #1 - #5. Vi kan se ud fra tabellen, at de eksperimenter hvor der foretager flest fixes/sec er #1, #2 og #5. Det er også meget forventet, da alle disse 3 konstant forespørger for GPS fixes. Der burde dog være flere fixes/sec for #2 og #5, men der er indlagt en fast tid på 1 sekund for hvor ofte der kan forespørges for GPS fixes på Android-telefonen, hvilket fjerner forskellen. Forskellen ville blive tydelig hvis man anvendte en periodisk forespørgsel med en større periodetid end 1 sekund. Der burde være et synligt lavere antal fixes/sec for #5, da der ikke forespørges på GPS fixes i de 2 indlagte pauser på ruten. En sandsynlig grund til at dette ikke er tilfældet er, at pauserne har været for korte 10 sekunder og er derfor ikke betydelige i det samlede resultat. Eksperiment #3 har et halvt så højt antal fixes/sec i forhold til de førnævnte. Dette er som forventet, da vi kun forespørger for GPS-fix når vi forventes at have nået distancen. Grunden til at det stadig er relativt højt i forhold til #4 er, at vi meget sjældent (aldrig) vil bevæge os med en så høj hastighed, og vil derfor forespørge på GPS-fix oftere end nødvendigt. Det laveste antal fixes/sec er eksperiment #4. Dette er også helt som forventet, da den maximale hastighed matcher vores faktiske hastighed godt. Dog kan vi se at antallet af GPS fixes overstiger antallet af reports hvilket modstrider den tidligere nævnte teori om at vi kan have bevæget os hurtigere end maks hastigheden. Så der er muligvis et problem i implementeringen, vi ikke har været opmærksomme på, eller en uheldig afvigelse i GPS-nøjagtigheden under målingen. Det højeste antal reports/sec er som forventet #1, som er den eneste strategi, der rapporterer til serveren ved hvert fix. De 4 andre eksperimenter ligger meget tæt på hinanden, hvad angår reports/sec. Dette burde også være tilfældet, da de alle bør rapportere ved hver tilbagelagt 50 meter. #4 er en lille smule lavere, hvilket også må forventes eftersom det på billedet fra eksperimentet ser ud til at der er længere mellem nogle placemarks. 10
4 Konklusion I denne opgave er der udviklet fire rapporteringsstrategier til en effektiv positionsopdatering fra en Android mobiltelefon til en server en såkaldt reporting protokol. Da den indbyggede GPS er anvendt til positionering og GSM-netværket som kommunikationsvej til server, reduceres mobiltelefonens batterilevetid betydeligt. Samtidigt kan hyppige rapporteringer til en server med mange klienter overbelaste en server. Derfor har disse faktorer været omdrejningspunkterne i de udviklede strategier. Det er påvist, at det er muligt at reducere brugen af GPS ved anvendelse af periodisk- og afstandsbaseretrapportering. Især ved at kombinere en afstandsbaseret strategi med en forudsigelse af, hvor langt brugeren kan have bevæget sig med en maksimal hastighed, kan antallet af GPS fixes reduceres markant. Antallet af GPS-fixes kan også reduceres ved at stoppe for GPS-opdateringer, når brugeren står stille. Disse metoder er dog ikke perfekte, da det er svært at forudsige brugerens færden (hastighed, retning etc). Endvidere har GPS ikke en høj præcision og specielt i byområder opstår der yderlige komplikationer i form af bygninger, som både skærmer og reflekterer signalet. Metoderne har dog den klare fordel, at de ikke kræver yderligere infrastuktur, hvilket fx udendørs WiFi-baseret positionering ville have gjort i form af wardriving. Derfor er GPS-baserede reporting protokoller let anvendelige udendørs, men for pålidelige resultater kræves mange hensyn. 11