Sensor Data Fusion Multi Sensor Data Fusion Claus Myglegaard Vagner og Jacob von Eyben IT University of Copenhagen Rued Langgards vej 7 2300 Copenhagen S Denmark (15 ECTS) Side 1
Inspiration til opbygning af abstract: Abstract http://www.ece.cmu.edu/~koopman/essays/abstract.html Side 2
1 Indledning... 5 1.1 Formål... 5 1.2 Motivation... 5 1.3 Problemformulering... 6 1.4 Overblik over rapporten... 6 2 Lokationsbestemmelse... 7 2.1 Teknologi... 8 3 Case... 9 3.1 Arkitektur overblik... 9 3.2 Udviklede komponenter... 10 3.2.1 Mobilapplikation...10 3.2.2 Fusionsapplikation...11 3.3 Anvendt infrastruktur... 11 3.3.1 Eventbus...11 3.3.2 Blipsystem...12 4 Sensor Data Fusion... 13 4.1 Fusiontyper... 13 4.2 Sensor kommunikation... 13 4.3 Centralized vs. Decentralized... 14 4.4 Problemstillinger... 14 4.4.1 Fælles repræsentation...14 4.4.2 Fusionfrekvens...14 4.4.3 Timing...14 4.4.4 Støj...14 4.5 Begreber... 14 4.5.1 Diskret vs. kontinuer lokationsbestemmelse...14 4.5.2 Klassifikation...15 4.5.3 Markov model...15 5 Design... 16 5.1 Design kriterier... 16 5.2 Fusionsparametre... 17 5.3 Dataopsamling... 17 5.4 Fusionsapplikation... 18 5.4.1 Dataflow...19 5.4.2 Reflektioner...21 5.5 Event fusioner... 21 5.5.1 Klassificering og træning...21 5.5.2 Nearest Neighbor søgning...22 5.5.3 Variationsanalyse...23 5.5.4 Markov model...25 5.5.5 Udenfor klassificerede zoner...26 5.5.6 Rutediagram...27 5.6 Konfiguration og datalager... 27 5.7 Støjreduktion... 29 5.8 Fælles koordinatsystem... 30 5.8.1 Transformation...30 5.8.2 Transformationsværdier...31 5.9 Testbarhed... 31 Side 3
5.10 Slutapplikationen... 32 6 Afprøvning... 33 6.1 Analyse af sensorkvalitet... 33 6.2 Klassifikations analyse... 33 6.3 Analyse af event fusioner... 35 6.3.1 Analyse af sensorer...35 6.3.2 Analyse af fusioneringsfrekvens...36 6.3.3 Analayse af nedre lighedsgrænse...38 6.3.4 Analyse af markov model...38 7 Diskussion... 40 7.1 Mobilapplikation... 40 7.1.1 Overvejelser omkring batteriforbrug...40 7.1.2 Alternativ sensor...41 7.2 Eventdistribution... 41 7.3 Fusionsapplikation... 42 7.3.1 Klassifikation...42 7.3.2 Variationsanalyse...43 7.4 Evaluering af sporingstjenesterne... 44 8 Konklusion... 45 9 Litteraturliste... 46 10 Bilag... 47 10.1 Fælles koordinatsystem... 47 10.1.1 Offset...47 10.1.2 Skaleringsfaktor...48 10.1.3 Rotationsvinkel...49 10.1.4 Beregnede værdier...50 10.2 Gennemløb... 50 10.2.1 Gennemløb 1...52 10.2.2 Gennemløb 2...52 10.2.3 Gennemløb 3...52 10.2.4 Gennemløb 4...53 10.2.5 Gennemløb 5...53 10.2.6 Gennemløb 6...53 10.2.7 Gennemløb 7...53 10.2.8 Gennemløb 8...54 10.2.9 Gennemløb 9...54 10.3 Empiri med Blipsystemet... 54 10.4 Resultater af forsøg... 56 10.5 Empiri med GPS sensoren... 57 11 Processrapport... 59 11.1 Eventbussen... 59 Side 4
1 Indledning Denne rapport vil beskæftige sig med fusion af data fra forskellige sensorer og vise hvorledes dette kan gøres samt hvordan fusioneret data kan udtrykkes og anvendes. Rapporten vil konkret beskæftige sig med hvordan man kan opsamle sensor data, en metode for hvordan det kan fusioneres og til sidst vise et eksempel på anvendelse af data repræsenteret i et fælles format på tværs af sensorer. Den anvendte metode for fusionering vil gennem empiriske forsøg blive evalueret. Det opsamlede data udgøres alt sammen fra sensorer, der i forskellig omfang, giver mulighed for at opnå en lokation for en interagerende enhed som f.eks. en mobiltelefon. Konkret handler dette om data fusionering mellem GPS, WiFi hotspots og Blipnoder (bluetooth) hvis fusioneret resultat udgøres af et geografisk koordinat som kan placeres på et kort. Gennem brug af dette fusionerede data kan der i en slutapplikation leveres kontekst relevant information i forhold til den opnåede lokation. 1.1 Formål Formålet med rapporten er således at undersøge hvorvidt det er muligt, at fusionere data fra forskellige sensorer til at give et bredere og mere præcist datagrundlag for beregning af en lokation for en mobil enhed samt eftervise at denne lokation kan bruges i en applikation, der intet kender til dataoprindelsen. 1.2 Motivation Vores motivation for at lære mere om sensorfusion generelt bygger på at det anvendes i mange forskellige systemer lige fra software til at dimensionerer kloaksystemer til avanceret cutting-edge software i jagerfly (Hackett & Grant, 2010). Derfor er sensorfusion, efter vores mening, et emne og et værktøj som bør ligge i en systemudviklers værktøjskasse og er derfor noget, vi gerne vil opnå et dybere kendskab til. Med ovenstående som udgangspunkt har vi i denne rapport været motiveret for at finde en løsning med sensorfusion til hvordan man kan spore en mobilenhed ude såvel som inde i bygninger, hvor der ikke er GPS dækning og udvikle et system der giver applikationer mulighed for at hente og bruge dette data. Side 5
1.3 Problemformulering Hvorledes kan fusioneret lokationsdata fra forskellige sporingsteknologier (som GPS, Wifi, Bluetooth) sendt fra en Android mobil enhed anvendes som kontekst i en lokationsbaseret applikation serviceret gennem den event orienteret Informations Bus (http://www.itu.dk/people/frza/infobus)? 1 Vi vil være i stand til at forklare de centrale problemstillinger i sensorfusion. Vi vil være i stand til at kunne designe en mobil applikation der kan indsamle og viderebringe lokationsbaseret information fra flere kilder til Informations bussen. Vi vil udvikle en applikation som kan modtage og behandle det indsamlede data. Udfra vores praktiske erfaringer vil vi være i stand til at kunne evaluere kvaliteten af de benyttede sporingstjenester. 1.4 Overblik over rapporten Afsnit 2 Lokationsbestemmelse: Beskæftiger sig overordnet med emnet og kommer ind på hvorfor det er relevant at kunne lokationsbestemme. Afsnit 3 Case: Beskriver casen for denne rapport og hvor involverede komponenter ligeledes beskrives. Afsnit 4 Sensor Data Fusion: Beskriver problemstillinger og begreber omkring sensor data fusion relevant for denne rapport i forhold til den valgte case. Afsnit 5 Design: Beskriver hvorledes vi har implementeret hele casen lige fra opsamling af data til fusion og til sidst anvendelse. Afsnit 6 Afprøvning: Præsenterer vores praktiske forsøg og analysen af disse. Konklusioner på baggrund af disse forsøg har dannet grundlag for vores design. Afsnit 7 Diskussion: Diskuterer og evaluere emner i rapporten. Afsnit 8 Konklusion: Konkludere på resultaterne i rapporten og besvarer problemformuleringen. 1 Eventbussen er udviklet af Francesco Zanitti som er Ph.D. studerende på IT- Universitet i København. Side 6
2 Lokationsbestemmelse At kende en telefon eller anden teknisk enheds placering kan være relevant i mange sammenhænge. Dette er også grunden til, at der i dag findes indbygget GPS i en lang række telefoner. Specielt inden for reklame og markedsføringsbranchen er det at kende en modtageres placering yderst interessant, da det i så fald vil være muligt at bringe et kontekst afhængigt budskab. Facebook 2 og Foursquare 3 er to virksomheder der allerede i dag bygger dele af deres forretning på at kende deres brugeres placering. Denne information formidler de til virksomheder der så kan målrette deres markedsføringsindsats. Dette data indsamles ved at brugeren tilkendegiver hvor vedkommende befinder sig gennem forslag der afhænger af deres placering indsamlet fra telefonen. Ovenstående kræver brugeren tilkendegiver og ikke mindst VED hvor vedkommende befinder sig, hvis den kontekst relevante information skal være korrekt. Der kan være flere årsager til at inddrage brugeren, ikke mindst etiske og juridiske, men et teknisk problem der løses, ved netop at inddrage brugeren, er den manglende indendørs GPS dækning således at brugeren inde i bygninger selv tilkendegiver en placering. Men hvad i de tilfælde hvor brugeren ikke præcist ved hvor vedkommende befinder sig, og der samtidig ikke er tilstrækkelig GPS dækning? Efter vores mening vil det næste skridt være at lokationsbestemmelse også rykker indendørs. Det vil sige, at man ikke alene skal kunne lokationsbestemme ude men også når brugeren rykker indenfor i bygninger. To tænkte men realistiske scenarier kunne være: Museum Det ville være interessant hvis det var muligt at guide en museumsbesøgende rundt uden at vedkommende havde kendskab til alle rum og seværdigheder på forhånd og uden at den besøgende var helt klarover hvor på museet vedkommende befandt sig. Hvis det ligeledes kunne krydres med kontekst afhængig information så som tekst eller lydfiler der forklarede detaljer om det udstillede. Zoologisk have I stil med museet kunne det være interessant at fortælle en besøgende detaljer om det dyr vedkommende betragtede, samt guide vedkommende til hvor den næste fodring eller lignende finder sted. I zoo er der både indendørs og udendørs seværdigheder, så for at kunne afgøre en besøgendes mere præcise placering når vedkommende f.eks. befinder sig i Elefanthuset, er det nødvendigt at fusionere GPS signalet med en anden sporingsteknologi. 2 Se www.facebook.com for yderligere information om virksomheden. 3 Se www.foursquare.com for yderligere information om virksomheden. Side 7
2.1 Teknologi Der findes mange teknologier der kan benyttes til at bestemme en lokation for en håndholdt enhed. Nedenfor er nævnt en række forskellige teknologier som lokationsbestemmelse kan baseres på. De kan inddeles i to typer af infrastruktur (King, Kopf, & Effelsberg, 2005): Dedikeret Infrastruktur Infrastruktur der eksisterer med det formål at foretage lokationsbestemmelse. GPS: Satelitbaseret positionerings system der i dag bruges i vidt omfang i blandt andet bil navigatorer. Active Badge: Er baseret på infrarøde signaler. (Roy Want, 1992) RFID: Radiobølge baseret lokationsbestemmelse. (Jensen, La, & Yang, 2010) Eksisterende Infrastruktur Infrastruktur der eksisterer i forvejen og benyttes i anden sammenhæng, men som også kan bruges til at foretage lokationsbestemmelse. FM Radio: RightSPOT er en algoritme der foretager lokationsbestemmelse ud fra signalstyrker på FM- radiostationer(j. Krumm, 2003). TV- signaler: Virksomheden Rosum har udviklet et system der kan lokationsbestemme ved hjælp af signalstyrker fra tv antenner. Bluetooth: Blipsystems har udviklet et system der udnytter den eksisterende bluetooth protokol til at lokationsbestemme. Dette gøres ved opsætte en række sensorer der registrer enheder i området. NFC: NFC teknologien er en tovejs kommunikations teknologi der på rygtebasis bliver implementeret i næste generation af mobiltelefoner. Kan i stil med Bluetooth benyttes til at foretage lokationsbestemmelse. WiFi: Virksomheden Skyhook 4 foretager lokationsbestemmelse udfra WiFi hotspots. 4 Se http://www.skyhookwireless.com/ for yderligere information om virksomheden. Side 8
3 Case Vi har valgt at fokuserer på at udvikle et system der kan afgøre placeringen af en mobiltelefon både inde og uden for bygninger, ved at kombinere dedikeret infrastruktur i form af GPS signalet, med signaler fra allerede eksisterende infrastruktur i form af Wifi hotspots og det bluetooth baserede Blipsystem der er opsat på IT- Universitetet. På baggrund af den afgjorte geografiske lokation, leverer systemet kontekst relevant information tilbage til telefonen. Konkret har vi valgt at definere en række forskellige zoner på og omkring ITU. Med udgangspunkt i disse zoner kan vi leverer diskret lokationsdata, der fortæller i hvilken zone telefonen befinder sig i. Vi har valgt at benytte nearest neighbor klassifikation til at afgøre telefonens placering. Dertil har vi implementeret en markov model der til en hvis grad hjælper med at højne selve hitraten, men i højere grad illustrerer hvorledes den kan være med til at nedbringe den samlede afvigede afstand. I det følgende vil vi beskrive de involverede komponenter og til dels teknologier som er anvendt i casen. 3.1 Arkitektur overblik Side 9
Figur 1 viser de involverede moduler og hvorledes de taler sammen igennem en eventbus. Figur 1: Overblik over den generelle system opbygning Yderst til venstre er illustreret hvorledes en mobilapplikation samt en bluetooth blipnode sender events til en eventbus. Eventbussen distribuerer denne information videre til data fusions komponenten, der ses midt i billedet. Herfra bliver de forskellige indsamlede informationer fusioneret til ét lokations event der udtrykker mobiltelefonens nuværende geografiske placering. De fusionerede events sendes tilbage ind i eventbussen, og modtages en mobilapplikation som præsenterer brugeren for kontekst afhængige beskeder. Den samlede systemarkitektur består af en egenudviklet mobil applikation, samt en fusionsapplikation. De resterende dele er eksisterende infrastruktur vi gør brug af. 3.2 Udviklede komponenter 3.2.1 Mobilapplikation En mobil applikation udviklet og installeret på en Android baseret HTC Desire telefon. Denne applikation består af to dele: En del der sender events til eventbussen, om tilgængelige Wifi hotspots, samt GPS signaler. Samtidig vil den være Bluetooth discoverable, hvilket gør det muligt for blipsystemet at spotte den, og fortælle om dens placering. En anden del der modtager events om telefonens placering og præsenterer denne placering på et kort sammen med en kontekst relevant besked. I vores tilfælde er det en lille tekst der fortæller hvor vedkommende befinder sig. Android Som platform for mobiludvikling har vi baseret os på Googles mobile software platform kaldet Android. Platformen er Open Source og kræver ikke nogle start omkostninger for at komme i gang med udvikle applikationer, som det f.eks. gør hvis man vil udvikle applikationer til Apples iphone. Side 10
Android er udelukkende en software platform som bygger på et Linux kernebaseret operativsystem og leverer en brugergrænseflade, indbyggede applikationer, kode biblioteker, multimedia support m.m. (Ableson, Collins, & Sen, 2009). Applikationer udvikles i programmeringssproget Java som oversættes til byte kode der bliver afviklet i en virtuel maskine kaldet Dalvik. (Ableson, Collins, & Sen, 2009). 3.2.2 Fusionsapplikation Fusionsmodulet er koblet til eventbussen og lytter efter events fra blipsystemet, samt registrerede mobil klienter. Fusionsmodulet afgøre en mobilklients placering ud fra de på forhånd definerede zoner. Når data fra mobiltelefonen og blipsystemet er fusioneret og en placering er afgjort, sendes der et event tilbage til eventbussen med information om telefonens placering. 3.3 Anvendt infrastruktur 3.3.1 Eventbus Eventbussen er udviklet af en Ph.d. studerende på IT- Universitetet og drives ligeledes på IT- Universitetet. Den har til formål at distribuere beskeder imellem de involverede komponenter. Blipsystemet, som er beskrevet nedenfor, sender allerede i dag events til denne eventbus, så for at gøre det muligt at få informationer fra dette system, har vi valgt at bygge vores system på denne eventbus. Eventbussen er webbaseret og er i stand til at formidle events i JSON format 5. Eventbussen understøtter i skrivende stund tre protokoller. Websockets: Der giver mulighed for full- duplex kommunikation over én TCP socket. En Comet 6 baseret protokol kaldet bayeux som gennem HTTP og javascript giver mulighed for to- vejs kommunikation imellem en webserver og en webbrowser. En almindelig request/response via HTTP. Der er to måder at sende events til eventbussen. Der kan registreres en event generator, der supportere de to førstnævnte protokoller, eller der kan sendes enkeltstående events via et HTTP post. For at modtage events skal der registreres en eventlistener. En eventlistener modtager de events der matcher det mønster der er angivet ved registrering af 5 http://www.itu.dk/people/frza/infobus/#documentation 6 http://en.wikipedia.org/w/index.php?title=comet_%28programming%29 Side 11
listeneren. Det er igennem disse mønstre at brugerne af eventbussen kan afgøre hvilke events de er interesseret i at modtage. 3.3.2 Blipsystem På IT- Universitetet er der opstillet en række bluetooth noder fra virksomheden BlipSystems. Disse noder kan sættes sammen i klynger der tilsammen danner en zone kaldet BlipZone. Blipnoderne skanner efter bluetooth enablede enheder og via event generatorer sendes der events til eventbussen, når en enhed befinder sig i en zone, eller bevæger sig ind og ud af de dækkede zoner 7. Figur 2: Oversigt over blipnode placeringen på ITU viser en oversigt over hvor på ITU de forskellige blipnoder er placeret, samt en ca. deæknings radius. Figur 2: Oversigt over blipnode placeringen på ITU 7 Se virksomhedens hjemmeside for flere detaljer omkring blipzoner og noder: http://www.blipsystems.com Side 12
4 Sensor Data Fusion Følgende afsnit giver en introduktion til lokationsbaseret sensor data fusion. Derudover vil vi komme ind på generelle problemstillinger samt forklare de begreber vi benytter i rapporten. 4.1 Fusiontyper Der findes i grundtræk fire former for fusions typer, der kort er beskrevet nedenfor (Mitchell, 2007): Fusion over flere sensorer: Fusionering der involverer flere sensorer der måler de samme typer attributter, der til sammen kan dække et større område. Fusion over forskellige attributter: Sensorer måler forskellige attributter indenfor det samme område. Det kan f.eks. være forskellige lokationsbaserede sensorer der fusioneres til en placering, som det ses i denne rapport. Fusion over forskellige domæner: En række sensorer der måler de samme attributter over et større område. Fusion over tid: Fusion der betragter nuværende måleværdier og fusionerer det med historiske data. En fusions applikation vil altid indeholde en eller flere typer af fusion. 4.2 Sensor kommunikation I grundtræk kan der foretages to former for kommunikation når der kommunikeres med sensorer. Eventbaseret Ikke deterministisk da der ikke er garantier for om eller hvornår næste besked bliver leveret. Besked forekommer ved specifikke hændelser. F.eks. ved skift i placeringen af en mobil enhed. Tidsbaseret En deterministisk besked levering, da der bliver leveret data med faste tidsintervaller, uanset om der er ændret i tilstanden eller ej. Hvilken form for kommunikation der foretrækkes afhænger ofte af hvilken kontekst data skal bruges i. Er der tale om et tids kritisk system er det ofte at foretrække en tidsbaseret kommunikation, da intervallet mellem beskeder er deterministisk (Mitchell, 2007). Samme tankegang kan også projiceres over på hvorledes en sensor fusions arkitektur opbygges, da denne i sidste ende også kan betragtes som en sensor benyttet i anden sammenhæng. Side 13
4.3 Centralized vs. Decentralized 4.4 Problemstillinger 4.4.1 Fælles repræsentation Beskriv hvad der kendetegner en fælles data repræsentation og hvorfor den er vigtig for at kunne sammenligne forskellige sensortyper. <jacob: da vi bruger klassifikation og dermed ikke tager udgangspunkt i selve sensorenes placering, er dette ikke afgørende. Omvendt vil vi gerne gøre det transparent at vi benytter klassifikation, hvorfor vi angiver et koordinat og en accuracy (zonens størrelse)> 4.4.2 Fusionfrekvens 4.4.3 Timing Når observationer forekommer fra flere forskellige sensor kilder, er der behov for at styre <Mitchel skriver om timing på side 19: Når dette afsnit skrives, er det samtidigt værd at nævne i et passende afsnit længere nede at vi ikke er gået i dybten med dette, men blot konstateret via empiriske forsøg at eventbussen synes at have konstant leveringstid, samt at intervallet for blip events er nogenlunde konstante.> 4.4.4 Støj Informationer fra sensorer er ofte behæftet med en hvis mængde støj, som det er relevant at få reduceret. <jacob: kan vi sige i vores designafsnit at vi benytter likeliness threshold til at begrænse dette?> Event filter 4.5 Begreber 4.5.1 Diskret vs. kontinuer lokationsbestemmelse En diskret placering er en placering der afgøres ud fra et defineret sæt af zoner. Diskret placeringen kendetegnes ved at en placering enten er inde eller uden for en angivet zone. Med diskret lokationsbestemmelse er granulariteten af lokationsbestemmelsen altså afgjort af zonerne. Jo mere finkornede zoner, desto mere præcis en lokationsbestemmelse er det muligt at foretage. Diskret lokationsbestemmelse kan f.eks. opnås ved at benytte klassifikation. Her kræves der ikke forudgående kendskab til hvor de involverede sensorer er placeret. Ligeledes er der heller ikke krav til at benytte en fælles data repræsentation på tværs af sensortyper, da en klassifikation blot består af registrerede signaler fra sensorer i en given zone. Kontinuer lokationsbestemmelse bygger ikke på et fastsat antal placeringsmuligheder. Her er der tale om at åbent område, hvor der ud fra Side 14
triangulering mellem en række forskellige sensorer kan afgøres en placering, hvilket kræver en viden om hvor hver involveret sensor er placeret. <reference> 4.5.2 Klassifikation Multi class versus binær Fordele/ulemper ved klassifikation <jacob: vi skal skrive hvad klassifikation er for noget> Nearest neighbor søgning Kort beskrevet betegnes en Nearest neighbor søgning ved at der foretages en sammenligning mellem en temporal model over input parametre og en række på forhånd definerede klassifikationer. Den klassifikation som den givne model ligner mest, betegnes som den klassifikation input data tilhøre. k-nearest Neighbor (k-nn) Hvis en given klassifikation indeholder mere end et eksempel, er der mulighed for at foretage, hvad der betegnes som k- Nearest Neighbor søgning, hvor k antager værdien for hvor mange eksempler der skal danne grundlag for den endelige klassifikation. Figur 3 viser et eksempel på en 3- NN søgning. De røde trekanter og de blå firkanter illustrerer eksempler inden for to klassifikationer. Den grønne prik illusterer input data. Figur 3: Eksempel på en 3-NN søgning (kilde: http://en.wikipedia.org/wiki/k-nearest_neighbor_algorithm) Som eksemplet viser, så er der to røde trekanter og en blå firkant bland de 3 fundende naboer. Da der er en overvægt af eksempler fra den røde klassifikation, betegnes inputdata til at tilhøre denne klassifikationen med de røde trekanter. Temporal Model Beskriv hvordan input data bliver til klassifikation. 4.5.3 Markov model Hvad gør den og hvad er fordele og ulemper ved denne? Afvigelsesfaktor Hvad gør den Side 15
5 Design Følgende afsnit beskriver designet af vores system, samt hvilke overvejelser der ligger bag. Ligeledes er der beskrevet styrker og svagheder ved vores valg. Vi har i denne løsning valgt at klassificere et fast antal zoner i og uden for IT- Universitet. Dette har vi gjort ved at optage hvilke sensor events der modtages af alle typer i hver zone over en periode på ca. 2 minutter. Det opsamlede datasæt er således en repræsentation/klassifikation for denne zone. Under fusioneringen opbygges en temporal model/klassifikation af input data som sammenlignes med de fast definerede klassifikationer. Den klassifikation som ligger tættest op af den temporale model antages at være nearest neighbor. Ligeledes har vi benyttet en Markov model, hvor de forskellige zoner er forbundet med en vægtning for hvor sandsynligt det er at telefonen flytter sig imellem to zoner. 5.1 Design kriterier Vores beslutninger omkring designet af det samlede sensorfusions system er taget ud fra følgende designkriterier: Fusionskvalitet Konfigurerbart Testbart Genbrugeligt Vores definition af høj fusionskvalitet er følgende: Levering af minimum et korrekt fusioneret event per zone der passeres. Laveste fejlrate baseret på det højeste antal leverede lokations events. Lige god support for alle brugsmønstre: Løbende, gående, stående, ude/inde. Vi findet det vigtigt at vores system er konfigurerbart. Forstået på den måde at det efter udviklingen af systemet er muligt at tilføje eller ændre definerede zoner, samt tilføje helt nye bygninger til sensorfusionen. Det har i mindre grad været vigtig at tilføje nye typer sensorer, da vi er overbevist om at det under alle omstændigheder vil kræve afprøvning og nyudvikling i selve applikationskernen. For at kunne finde frem til den bedste fusionskvalitet er det vigtigt at systemet kan optage forskellige brugsmønstre af systemet for derefter at kunne afspille og teste fusionsalgoritmen med disse optagelser. Vi udvikler en case der bruger vores fusionerede resultat, men det er vigtigt at det fusionerede resultat også kan bruges i applikationer vi endnu ikke er bekendt med. Derfor er det vigtigt at vi vælger et standardformat til at udtrykke en lokation. Side 16
5.2 Fusionsparametre For at kunne opfylde vores design kriterier for en god fusionering, er der behov for at kunne stille på følgende parametre: Brug af sensorer: Hvilke sensorer skal danne grundlag for vores klassifikationer? Fusioneringsfrekvens: Hvilken fusioneringsfrekvens skal der benyttes? Nedre lighedsgrænse: Hvad skal den nedre lighedsgrænse mellem den temporale model og klassifikationer være før vi med overvejende sandsynlighed kan klassificere input data? Brug af Markov: Kan en Markov model øge præcisionen og i hvilke tilfælde skal man kunne afvige fra denne model? 5.3 Dataopsamling En mobilapplikation står for at opsamle data og sende det til eventbussen. I det følgende vil vi gøre redde for hvordan vi har designet denne applikation og hvilke overvejelser der ligger bag. GPS I mange mobiltelefoner og i særdeleshed i såkaldte smartphones, er der i dag en GPS sensor. Gennem Android API et kan sensoren bruges på flere måder. Den kan konfigureres til at give positioner efter et tidsinterval eller efter telefonen har rykket sig et antal meter fra sidste position (Ableson, Collins, & Sen, 2009). Denne applikation er konfigureret til at få GPS positioner når man rykket sig minimum to meter fra sidste position. De to meter er vurderet efter hvad der passer i forhold til zonernes størrelse. WiFi For at få WiFi hotspot data bruger man telefonens trådløse netkort til at skanne efter WiFi hotspots. Dette gøres i applikationen hvert andet sekund og det er hermed applikationen der selv styrer hvornår data skal være til rådighed til videre forsendelse. Bluetooth For at blive opdaget af Blipsystemet på IT- Universitet skal telefon være bluetooth discoverable. Dette betyder blot at den kan blive skannet af andre bluetooth enheder som f.eks. blipnoderne. Når man aktiverer discoverable tilstanden på en Android platformen kommer der en dialog frem, hvor man skal bekræfte at man vil sætte telefonen i discoverable tilstand. Dette er en sikkerhedsforanstaltning i selve android platformen, som man ikke kan slippe for. Ydermere kan man maksimalt få lov til lade den blive i den tilstand i 5 minutter. Herefter skal man på ny bekræfte indstillingen. For at omgå dette har vi udviklet applikationen således at man bliver promptet hvert 5. minut for en fornyelse af discoverable perioden. Dette er ikke det mest optimale hvis man tænker på applikationen brugt i en rigtig situation, men det var vores bedste bud på en fornuftig løsning. Der er en enkelt mulighed for at omgå dialogen og sætte telefonen i bluetooth discoverable hele Side 17
tiden, men det er ikke noget den almindelige bruger kan da det kræver en modificering af selve android styresystemet på telefonen. 8 Upload af data til eventbussen Applikationen sender data til eventbussen, lige så snart det er tilgængeligt. Dette sker med en HTTP POST. Da applikations brugergrænsefladen kører i den samme tråd for Android applikationer (Ableson, Collins, & Sen, 2009) er det vigtigt, at alt kommunikation med eventbussen kører asynkront i en separat tråd da brugergrænsefladen ellers ville låse helt mens der bliver sendt data. 5.4 Fusionsapplikation Som det fremgår af Figur 1 under afsnit 0, så foregår selve fusioneringen af data i en fusionskomponent. Denne komponent er en applikation i sig selv, men vil i praksis fungerer som en middleware komponent da dens formål er at stille fusioneret data til rådighed for andre applikationer. I hovedtræk foretager applikationen en fusionering af det opsamlede data ved at opbygge en temporal model over opsamlet data og sammenligne denne ved at foretage multiklasse klassifikation mod samtlige zoner. Der benyttes en Markov model samt en nedre lighedsgrænse for at øge præcisionen i de fusionerede resultater. Vi vil i dette afsnit beskrive designet og virkemåden for denne applikation. Figur 4 illustrerer det generelle design og flow i applikationen. 8 http://blag.tsukasa.net.au/2009/08/25/always- discoverable- on- android/ beskriver hvorledes en telefonen kan sættes til bluetooth discoverable hele tiden. Side 18
Figur 4: Design for fusionsapplikationen Applikationen er bygget op omkring et alment kendt samtidigheds designmønster kaldet producer/consumer (Oaks & Wong, 2004). Designet bygger på at man har producere som producerer data til en kø som behandles af consumere. Data producering og behandling foregår asynkront i afkoblede eksekverings tråde hvor kommunikationen mellem producer og consumer foregår gennem den førnævnte data kø. Vi har fundet dette designmønster passende for applikationen, da der er behov for at kunne producere data samtidig med at data behandles. Typisk vil det være meget hurtigt at lægge modtaget events i kø til processering og hermed kan data behandlingen ske i sit eget tempo af consumeren uden at blokere produceren for at modtage flere events. Hvis vi ikke havde denne afkobling og hermed producerede og behandlede data i samme eksekverings tråd ville der ikke kunne tilføjes flere events til processering før den første klump af events var behandlet færdigt og der ville være potentiale for at tabe events fra eventbussen. 5.4.1 Dataflow Figur 4, som illustrerer designet i applikationen, er markeret med nogle tal som vi vil bruge som henvisningspunkter i den følgende beskrivelse af hvordan dataflowet er i applikationen. 1: Når applikationen startes bliver Event Queue Produceren som noget af det første også startet. Produceren laver en websocket forbindelse til eventbussen og er hermed klar til at modtage events fra de forskellige sensorer som GPS, Wifi og Bluetooth som eventbussen sender. 2: Når et event bliver modtaget lægger produceren det i en kø til behandling. Inden et event bliver lagt i kø til behandling bliver det dog kørt igennem et filter som afgør om det er et event som skal behandles. Kriterierne for om et event skal behandles går på om det kommer fra en Wifi hotspot eller Blipnode som Side 19
fusioneren kender. Måden hvorpå dette bestemmes er ud fra sensorens id (en MAC adresse i dette tilfælde) som bliver sendt med i eventet fra eventbussen. Et modtaget event er fra eventbussens side genereret ud fra en klient enhed som f.eks. en mobiltelefon. For hver unik enhed oprettes ikke kun en specifik kø men også en specifik consumer således at data behandling kan ske samtidigt for forskellige enheder. Det er producerens ansvar at oprette en event kø men også at starte en consumer for hver ny enhed der modtages events får. 3: Når en consumer er startet er den knyttet sammen med en enhed og den vil ud fra et konfigurerbart interval kigge efter events i køen som skal behandles. Events, der tages til behandling, vil samtidigt blive fjernet fra køen. Vi havde i denne situation to muligheder for hvordan applikations arkitekturen skulle implementeres. Under afsnit 2 blev det beskrevet at man enten kunne lave en event- eller tidsbaseret arkitektur. I denne applikation kan det mappes over til hvornår vi skal forsøge at fusionere data. Skal det ske lige når vi modtager events (eventbaseret) eller skal det ske efter et bestemt tidsrum (tidsbaseret). Vi har valgt at bruge en tidsbaseret arkitektur hvor der forsøges fusion efter et tidsinterval men hvor man kan konfigurere hvor ofte det skal ske. Med dette har vi større sikkerhed for, at der vil være flere events af gangen at fusionere med hvilket jf. måden der fusioneres på (se afsnit 5.5) skal være med til at give et bedre resultat i form af en større præcision når vi forsøger at lokalisere enhederne på ITU. Udfordringen ved dette er at finde det optimale tidsinterval for hvornår der fusioneres. Alternativet havde været den eventbaseret arkitektur hvor der fusioneres efter et bestemt antal events. Det kunne f.eks. være efter hvert modtaget event, men dette ville ikke hænge godt sammen med måden vi har valgt at fusionere data på. At lave en klassifikation ud fra f.eks. 1 wifi event ville være meget svær at få rigtig. Hvis man f.eks. ventede på 10 events inden de blev fusioneret var der mere data til rådighed og grundlag for en bedre fusionering/klassifikation men problemet her er, at de 10 events i teorien kan være kommet over en længere periode mens vedkommende vi forsøger at lokalisere kan have bevæget sig gennem flere zoner hvilket gør det svært at fusionere til et præcist resultat. En anden fremgang vi kunne have valgt for både en tidsbaseret som en eventbaseret arkitektur var at kigge på historiske events ved fusionering. F.eks. kunne man kigge 10 events tilbage eller et på alle events indenfor de seneste 2 sekunder, hver gang man forsøgte at fusionere for at se om det gav et bedre resultat. Det er dog ikke en fremgangsmåde vi har valgt at bruge i dette projekt. 4: Når konsumeren har taget et sæt events fra køen, videregives de til Event Fusioneren som har til ansvar at lave den egentlige fusionering af sensor events. 5: Side 20
Event fusioneren bliver konfigureret med en xml fil som den bruger til at lave fusionering. Denne konfigurering læses ind ved opstart af applikationen og bruges under fusionering. 6: Når event fusioneren har opnået et resultat på baggrund af de leverede events sendes det fusionerede event til eventbussen gennem en generator som andre applikationer således kan lytte efter. Koordinaterne i det fusionerede event er baseret på longitude, latitude og altitude. Hvorledes selve zonerne oversættes til dette format, kan læses i afsnit 0. 5.4.2 Reflektioner I denne arkitektur er der kun én producer (se kassen Event Queue Producer på Figur 4) men flere consumere (se kassen Event Queue Consumer for Device X på Figur 4). Vi kunne have valgt en arkitektur hvor der var en producer for hver enhed vi behandlede events for således, at der ville være et 1-1 forhold mellem producer og consumer. Det kunne muligvis give bedre ydeevne ved meget store datamængder, hvor der er mange enheder, vi forsøger at lokalisere. Men for dette projektet, hvor vi har opereret med én telefon som har installeret mobilapplikationen, så det har i praksis ikke været noget problem med én producer. Et andet aspekt er eventbussen, som i tilfælde af vi havde flere producere skulle understøtte, at vi kunne lave mange websocket forbindelser til den. 5.5 Event fusioner Selve fusioneringen af events bliver aktiveret ved at en device event consumer, leverer en række events til event fusioneren (se trin 4 i Figur 4). Der bygges en temporal model/klassifikation over de modtagende events. Der tages ved hver klassifikation udgangspunkt i hvad der kan betegnes som en baseline klassifikation. Kendetegnet ved en baseline klassifikation er at den indeholder alle kendte sensorer, men ingen måleværdier. Det er afgørende at danne et kendt fælles grundlag for vores klassifikationer og vores temporale model, for at kunne foretage en variationsanalyse. Vi har implementeret et eventfilter der sikre at det udelukkende er events fra kendte sensorer, der bliver lagt i device event køerne. Dette er implementeret i trin 2 i Figur 4. For at en sensor betragtes som kendt, skal den indgå i mindst én klassifikation. Filteret sikre at vi ikke danner et sammenligningsgrundlag baseret på events der er ukendte for fusionsalgoritmen. Der er også den fordel at ukendte events for sensorer der ikke indgår i klassifikationerne udelukkende ville skabe støj og sløre variationsværdierne. 5.5.1 Klassificering og træning Med udgangspunkt i vores definerede zoner i afsnit 3, har vi foretaget klassifikationer af de forskellige zoner. Vi har valgt at lade de fysiske rammer afgøre hvor zonerne skal placeres uden at kigge på om det rent signalmæssigt kan lade sig gøre at differentierer denne zone tilstrækkeligt til at den kan få et stærkt kendetegn i forhold til andre zone klassifikationer. Side 21
Vi har trænet vores klassifikationer ved at i ca. to minutter at bevæget os tilfældigt rundt i en zone defineret af en cirkel med radius af ca. 3 meter. Imens har vi optaget alle events fra de registrerede sensorer. Ved at lave en model over det indsamlede data, er den enkelte klassifikation fremkommet. Når vi har valgt en strategi hvor de fysiske rammer bestemmer hvor der laves en klassifikation, er det relevant at undersøge hvorvidt vores klassifikationer for de valgte zoner adskiller sig tilstrækkeligt fra hinanden til at vi kan foretage en præcis klassifikation. Hvis to klassifikationer varierer i særlig lille grad, er det et udtryk for at der bør gøres en indsats for at øge denne variation. F.eks. kan der monteres en ekstra sensor i en af de pågældende zoner for at øge variationen. Figur 5 viser hvorledes en indbyrdes vægtet variation blandt alle klassifikationer fordeler sig. Vægtningen af de forskellige sensortyper er valgt ud fra metoden hvor hver sensortype vægtes efter forekomst i de to klassifikationer der sammenlignes. Figur 5: Viser fordelingen af de vægtede variationer blandt alle klassifikationer Som det fremgår af vores klassifikationsanalyse i afsnit 6.2, er det vores overbevisning at variationsfordelingen er tilstrækkelig til at vi bør kunne opnå en fornuftig præcision under vores fusionering. 5.5.2 Nearest Neighbor søgning Vores klassifikationsform benytter nearest neighbor søgning da vi til en hver tid klassificerer telefonen til at befinde sig i den zone der varierer mindst fra vores temporale model. Da vi kun har defineret ét eksempel pr. klassifikation, vil vi kun kunne foretage en 1- NN søgning. Side 22
Måden hvorpå vi finder en passende klassifikation til vores temporale model, er ved at foretage en lineær søgning igennem samtlige kendte klassifikationer og foretage en variationsanalyse mellem den temporale model og hver enkelt klassifikation. 5.5.3 Variationsanalyse Hvorvidt vores temporale model og en klassifikation ligner hinanden skal ses ud fra hvor meget de varierer. Hvor meget to klassifikationer varierer afgøres ved at analysere de registrerede antal måleenheder for hver konkrete sensor i henholdsvis den temporale model og den pågældende klassifikation. Et konkret eksempel på en variationsberegning er illustreret nedenfor, hvor to forsimplede klassifikationer er sammenlignet og deres variation præsenteret. Den ene klassifikation kunne passende være en temporal model over input data. Eksemplet indeholder otte sensorer. En GPS lokation, fire WiFi sensorer samt tre Blipnoder. Figur 6: et eksempel på en klassifikation Figur 7: et andet eksempel på en klassifikation Side 23
Figur 8: Variationen mellem de to klassifikationer vist i Figur 6 og Figur 7 Figur 6 og Figur 7 illustrerer to klassifikationer der indeholder de samme sensorer, men forskellige måleværdier. Der er tale om at der er målt et gennemsnitligt GPS signal i klassifikationerne, samt varierende værdier for de fire WiFi sensorer samt de tre Blipnoder. Indenfor hver sensortype - GPS, WiFi, og Blip kan den samlede vægtning af måleværdierne summeres op til 100%. Dermed udtrykkes hvor stor en sandsynlig fordeling der skal forekomme af de givne sensorer for at den ligner en given klassifikation. Figur 8, udtrykker variationen imellem de to klassifikationer. Det ses at der ikke er fundet en variation for GPS sensoren, mens der er afvigelser indenfor både WiFi og Blip. Det ses at tredje WiFi sensor afviger med 10.5%, og ligeledes afviger første og anden Blipnode med henholdsvis 31.4% og 22.9%. På trods af den høje variation blandt et par af sensorerne fremgår det af Figur 8 at den samlede variation er beregnet til 13.96%. Det skyldes at den enkelte sensortype kan vægtes forskelligt og dermed være med til at påvirke den samlede variation. I dette eksempel er alle sensortyper vægtet lige med en tredjedel hver. Hvorledes variationen indenfor den enkelte sensortype beregnes kan ses nedenfor: Variationsberegning for GPS sensor Figur 9 illustrerer hvorledes GPS sensorer sammenlignes: Figur 9: Viser eksempler på GPS sensor sammenligning To klassifikationer betegnes som 100% varierende i gps sensor værdien, hvis følgende er tilfældet: Side 24
Kun den ene af de to klassifikationer indeholder et gps signal. Begge klassifikationer indeholder et gennemsnitligt gps signal, men afstanden imellem de to punkter overstiger summen af måleusikkerheden for de to signaler. Der betegnes 0% variation i de tilfælde, hvor: der ikke er målt GPS signal i nogen af de to klassifikationer. der er målt GPS i begge klassifikationer, og hvor afstanden mellem de to sensorværdier er mindre en summen af måleusikkerheden for de to signaler. Variationberegning for wifi og blip sensorer Disse to sensortyper benytter samme variationsberegning. Vi kigger alene på procentandelen af en given sensor indenfor en sensortype. Hvis vi eksempelvis betragter de to første wifi sensorer på henholdsvis Figur 6 og Figur 7 ses det på Figur 8 at denne sensor forekommer 2% mere i første klassifikation end i den anden. 5.5.4 Markov model Som nævnt tidligere har vi implementeret en markov model over de klassificerede zoner. Denne markov model indeholder samtlige tænkte udfaldsmuligheder. Markov modellen bruges i samspil med vores variationsanalyse til afgøre placeringen af telefonen. Ved at betragte den seneste afgjorte placering af den enkelte telefon, kan der i Markov modellen aflæses sandsynligheden for næste trin i fusioneringen. Sammenholder vi denne sandsynlighed med vores resultater fra variationsanalysen af den temporale model og klassifikationerne, fremkommer den samlede sandsynlighed for næste placering af telefonen. Side 25
Figur 10: Markov model hvor alle kanter er vægtet lige. Figur 10 viser vores samlede Markov model. Figuren illustrerer at der er lige sandsynlighed for at navigere imellem hver node i modellen. Hvad figuren ikke viser, men som er tilfældet i vores model, er at sandsynligheden altid er 1, for at forblive i den pågældende zone. Vores implementation af Markov modellen ser det udelukkende som sandsynligt at telefonen flytter sig imellem zoner der er direkte forbundne. Markov modellen har den fordel at vi kan forhindre urealistiske spring imellem zoner. F.eks. er zoner der er adskilt af vægge eller loft ikke forbundet. Da vores Markov model indeholder samtlige mulige udfald, og den samtidigt bruges til at finde næste mulige udfald udfra nuværende placering og dets naboer, betegnes modellen en Markov kæde 9. Der behov for at kunne afvige fra denne model, da den kan begrænse os hvis f.eks. en zone springes over, eller vi får et forkert udgangspunkt, således at det den næste afgjorte placering ikke længere grænser op til den nuværende. Vi har derfor implementeret en regel der sikre at hvis den mindst varierende klassifikation 2 gange i træk ikke befinder sig blandt naboerne til den zone telefonen befinder sig i på det givne tidspunkt, tillader vi at afvige og flytte telefonen til den zone der varierer mindst. Dette skal være med til at sikre at vi stadig fjerner støj, da enkeltstående helt forkerte klassificerede zoner ikke kommer i betragtning, men at vi samtidig bevarer muligheden for at komme tilbage ind i kæden hvis vi af den ene eller anden årsag befinder os et forkert sted i modellen. 5.5.5 Udenfor klassificerede zoner Da der ikke findes klassificerede zoner der dækker hele vores valgte geografiske koordinatsystem, er det afgørende, at vi kan håndterer de tilfælde hvor telefonen befinder sig væk fra vores zoner. En telefon befinder sig væk fra vores klassificerede zoner, når den beregnede variation mellem den temporale model og klassifikationerne ligger under den fastsatte nedre lighedsgrænse på 60 procent. Når den temporale model og en given klassifikation ikke ligner hinanden tilstrækkelig til at vi med overvejende sandsynlighed kan placerer telefonen en given klassifikation, er der to udfaldsmuligheder: Vi kan placerer telefonen i en uklassificeret zone. Det er en zone som indeholder koordinater, men som ikke er en del af de klassificerede zoner. Telefonen placeres i denne zone, hvis den temporale model indeholder et eller flere GPS events. Placeringen afgøres som et gennemsnit for alle de givne GPS events. Placeringen af telefonen kan være helt ukendt. Det sker hvis den temporale model ikke indeholder GPS events. I det tilfælde har vi ikke 9 Definition af Markov kæde: http://en.wikipedia.org/wiki/markov_chain Side 26
mulighed for at angive en sandsynlig placering af telefonen, hvorfor der ikke forekommer noget resultat af fusioneringen. 5.5.6 Rutediagram Figur 11 viser et rutediagram for hvordan fusionsprogrammet eksekverer. Figur 11: Rutediagram for FusionEngine og Classifier 5.6 Konfiguration og datalager Fusionsalgoritmen bliver som tidligere beskrevet startet op med en konfigurations fil som i dette tilfælde er udtrykt i XML. I denne fil er alle zoner, som vi klassificerer, defineret. Filen fungerer ikke alene som konfiguration, men også som datalager for klassifikationerne. Klassifikationsdata er således også indeholdt i denne fil, som indlæses i applikationen ved opstart. Det generelle formål med denne fil er at skabe uafhængighed mellem fusionsmotoren og det data den skal bruge således at data kan ændres uden det kræver ændret kode i fusionsmotoren. Dette resulterer i at nye zoner kan komme til og klassifikationer kan laves om løbende. Her et eksempel på en zone definition: Side 27
<zones name="groundfloor"> <coordinate> <scale metersprunit="0.032006299"></scale> </coordinate> <zonedef z="0" y="312" x="822" radius="5" name="2b" /> <zones> I ovenstående eksempel er der defineret en zone kaldet 2B. Zone definitionen befinder sig hierarkisk under et zones element som f.eks. i en bygning kunne udgøres af en etage. Zone definitionen indeholder relativt information for angivelse af zonen i et lokalt koordinatsystem. Ved angivelse af passende transformations faktorer, kan dette konverteres til latitude, longitude, altitude. Dvs. zoner fra andre bygninger kan tilføjes uden ændring i fusionsmotoren. I vores eksempel er metersprunit defineret som meter pr. pixel på et mål fast kort over en etage på ITU. Her et forkortet eksempel på en zone definition med klassifikations data: <zonedef z="0" y="312" x="822" radius="5" name="2b" > <zoneclassification> <wificlassification weight="90.02"> <wifihotspot weight="2.77" level="-85.33" ssid="eduroam" id="00:21:f7:11:d5:68"/> <wifihotspot weight="2.31" level="-87.40" ssid="itu" id="00:21:f7:11:d5:6a"/> <wifihotspot weight="0.46" level="-88.00" ssid="itu" id="00:21:f7:11:d5:82"/> <wifihotspot weight="3.23" level="-87.14" ssid="eduroam" id="00:21:f7:fb:3c:1c"/> <wifihotspot weight="3.70" level="-86.75" ssid="itu" id="00:21:f7:fb:3c:1e"/> <wifihotspot weight="0.46" level="-90.00" ssid="eduroam" id="00:21:f7:fb:3c:8c"/> <wifihotspot weight="0.46" level="-91.00" ssid="itu" id="00:21:f7:fb:3c:8e"/> <wifihotspot weight="1.39" level="-89.67" ssid="eduroam" id="00:21:f7:fb:3c:94"/> <wifihotspot weight="0.46" level="-92.00" ssid="itu" id="00:21:f7:fb:3c:96"/> <wifihotspot weight="0.69" level="-86.33" ssid="eduroam" id="00:21:f7:fb:3c:9c"/> <wifihotspot weight="1.62" level="-85.29" ssid="itu" id="00:21:f7:fb:3c:9e"/> <wifihotspot weight="6.70" level="-76.10" ssid="eduroam" id="00:21:f7:fb:3c:ac"/> <wifihotspot weight="6.70" level="-75.69" ssid="itu" id="00:21:f7:fb:3c:ae"/> <wifihotspot weight="3.70" level="-90.63" ssid="eduroam" id="00:21:f7:fb:3c:b4"/> <wifihotspot weight="2.77" level="-90.17" ssid="itu" id="00:21:f7:fb:3c:b6"/> <wifihotspot weight="4.39" level="-84.32" ssid="eduroam" id="00:21:f7:fb:3c:c0"/> <wifihotspot weight="4.62" level="-85.40" ssid="itu" id="00:21:f7:fb:3c:c2"/> 20 wifihotspots mere </wificlassification> <bluetoothclassification weight="4.98"> <bluetoothscanner weight="100.00" rssi="-63.5" zone="itu.zone2.zone2b" id="00:0e:a5:00:50:d2"/> </bluetoothclassification> <gpsclassification weight="5.00"> <gpslocation accuracy="18.63" altitude="65.04878048780488" longitude="12.591602351607346" latitude="55.65937875247583"/> </gpsclassification> </zoneclassification> </zonedef> I ovenstående eksempel indeholder elementet <zoneclassificaton> data som klassificere zonen. Som det fremgår for denne eksempel zone er der data fra alle tre sensorer som er med til at klassificere zonen. Hver sensor klassifikation har defineret en vægt som udtrykker hvorledes data fra de forskellige sensorer skal vægtes indbyrdes. I dette tilfælde er vægten beregnet ud fra antallet af events fra sensorerne, men det kunne være at man ville definere dette anderledes ud fra kendskab til den fysiske kontekst hvor zonen befinder sig. Side 28
Det vil sige, at denne zone klassificeres ved at 90.02 procent af events er fra wifi, 4.98 fra bluetooth og 5.00 fra GPS. Bemærk at for GPS events, er der kun angivet ét <gpslocation> element hvor gennemsnittet af latitude, longitude, altitude over disse events er beregnet. Dog er vægten på 5 procent beregnet ud fra hvor mange GPS events der blevet modtaget ved klassifikationen. Data fra den samme sensor er også vægtet indbyrdes på samme måde gennem antallet af modtaget events fra f.eks. hver wifihotspot. F.eks. er 2.77 procent af modtaget wifi events fra et hotspot med MAC adressen 00:21:f7:11:d5:68. En <gpslocation> har ikke angivet en vægt da der altid kun er én (det samme som en vægt på 100%). Hvordan alt dette data mere i detaljer bliver brugt kommer vi ind på i afsnit 5.5. Måden hvorpå zoner er forbundet, for at opbygge Markov modellen, er ligeledes defineret gennem konfigurations filen, så hvis man tilføjer en zone kan forbindelserne til andre zoner sættes op på følgende måde: <zonedef name= 2B > <markovchain-edges> <edge to="2b_1_3_hall" weight="1"/> <edge to="2b_2c" weight="1"/> </markovchain-edges> </zonedef> Ovenstående eksempel viser at zone 2B grænser op til både 2B_1_3_hall og 2B_2C. Vægten, som er defineret her, er sat til 1 hvilket indikerer at der er lige stor sandsynlighed for at gå til enten 2B_1_3_hall eller 2B_2C fra 2B. For at kunne definere indgangene i Markov modellen har vi specificeret en unclassified zone. Denne zone er udtryk for at vi ikke kunne bestemme en placering for telefonen til en af de definerede zoner, men at vi har afgjort at telefonen befinder sig et uklassifiseret rum f.eks. udenfor bygningen. <unclassified-zonedef name="unclassified"> <markovchain-edges> <edge to="vindfang_outside" weight="1"/> <edge to="canteen_outside_east" weight="1"/> <edge to="canteen_outside_south" weight="1"/> <edge to="canteen_outside_west" weight="1"/> <edge to="doersyd" weight="1"/> </markovchain-edges> </unclassified-zonedef> For at sikre at XML konfigurations filen er opbygget i et korrekt og forventet format således at fusionsmotoren kan indlæse den, er der udviklet et XML Schema 10 som filen kan valideres op i mod. 5.7 Støjreduktion Vi har minimal støjreduktion på sensor niveau gennem brug af et event filter der sikre at det kun er sensorer som indgår i klassifikationerne er tages i betragtning 10 http://www.w3.org/xml/schema Side 29