Detectie van locatie en activiteit van een gebruiker via GPS en bewegingsdata Ewout Meyns
Promotor: prof. dr. ir. Luc Martens Begeleiders: Toon De Pessemier, Kris Vanhecke Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen
Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen en Architectuur Academiejaar 2010-2011
Detectie van locatie en activiteit van een gebruiker via GPS en bewegingsdata Ewout Meyns
Promotor: prof. dr. ir. Luc Martens Begeleiders: Toon De Pessemier, Kris Vanhecke Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen
Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen en Architectuur Academiejaar 2010-2011
Voorwoord Sinds het ontstaan van Google Android ben ik enorm gefascineerd door het framework. Ik heb het geluk gehad er mijn volledige masterproef te mogen aan wijden, waardoor ik een jaar lang vol enthousiasme aan het onderzoek heb gewerkt. Uiteraard zou mijn masterproef zonder een aantal personen niet zo vlot verlopen zijn. Ik wil dan ook mijn promotor prof.
dr.
ir.
Luc Martens en mijn begeleiders Toon De
Pessemier en Kris Vanhecke van harte bedanken omdat ze mij dit onderwerp voorstelden, alsook voor de hulp bij het onderzoek. Verder wil ik mijn ouders en vriendin bedanken voor de jarenlange steun tijdens mijn universiteitsjaren, alsook de 11 personen die tijd vrijgemaakt hebben om op te treden als testpersoon. Ook wil ik Annelies Pascal, Bart Meyns en Charlotte Pascal bedanken voor het nalezen.
Ewout Meyns, mei 2011
i
Toelating tot bruikleen
De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.
Ewout Meyns, mei 2011
ii
Detectie van locatie en activiteit van een gebruiker via GPS en bewegingsdata door Ewout Meyns
Afstudeerwerk ingediend tot het behalen van de graad van Master in de ingenieurswetenschappen: computerwetenschappen Academiejaar 2010-2011 Universiteit Gent Faculteit Ingenieurswetenschappen en Architectuur Vakgroep informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Promotor: prof. dr. ir. Luc Martens Begeleiders: Toon De Pessemier, Kris Vanhecke
Samenvatting Webontwikkelaars maken reeds enige tijd gebruik van contextgebaseerde informatie om gepaste aanbevelingen te presenteren aan de gebruiker. Mobiel internet, dat de laatste jaren een enorme groei kent, brengt nieuwe mogelijkheden met zich mee om meer inzicht te verwerven in de huidige context van de gebruiker. Het zou misschien zelfs mogelijk kunnen zijn om de huidige activiteit van de gebruiker te herkennen. Dit onderzoek bespreekt een framework waarmee enerzijds basisactiviteiten zoals stilstaan, wandelen, lopen of etsen kunnen herkend worden en anderzijds complexere activiteiten. Het framework is makkelijk uitbreidbaar en kan dus geïntegreerd worden met andere aanbevelingsapplicaties.
Trefwoorden:
activiteitsdetectie, Google Android, versnellingsmeter, mobiel toestel,
support vector machines, sensoren, contextgebaseerde informatie.
iii
Activity detection from a user via GPS and movement data using Google Android Ewout Meyns Supervisor(s): prof. dr. ir. Luc Martens, Toon De Pessemier, Kris Vanhecke Abstract— The mobile internet brings with it new opportunities to gain insight in the current user’s environment. This additional context based information can be used to improve current recommendation algorithms. The article describes a framework to detect the current activity of the user by analyzing data retrieved from different sensors available on mobile devices. The framework can easily be extended to detect custom activities and is built in a generic way to ensure easy integration with other applications. Keywords— Activity detection, Google Android, Accelerometer, Mobile device, Support vector machines, Context based information.
I. I NTRODUCTION A. Problem definition Mobile internet has shown massive growth in the last years. Web developers have for some time used context based information to generate useful recommendations for their users. However, via mobile internet more context based information is available than currently exploited by most recommendation algorithms. The user is carrying his device with him, resulting in additional information such as location, speed, environment ... It might even be possible to detect his current activity. B. Objective The main goal of this research is to detect the user’s current activity. The first part needs to cover the detection of basic activities such as walking, running, cycling by analyzing the acceleration of the mobile device. In the second part it should be possible to detect more complex activities like ”walking to a station while it’s rainy”. II. L ITERATURE REVIEW The literature review section introduces the available sensors in the Google Android Framework, some applications that use recommendations, relevant services that can be used and a few interesting articles. III. D ETECTING BASIC ACTIVITITIES This section describes the used process to detect the basic activities of the user. Under basic activities one can understand: standing still, walking, running and cycling. The implementation happened on the Google Android platform. Almost every Google Android device has a built-in accelerometer which is capable of capturing the device’s acceleration on three axes every 20 ms. First, accelerometer data from 11 different users performing the four activities was collected. It was clear that each activity lead to different device movements. Running, e.g., yields more energy than walking, which is quite obvious. For each of these 44 datasets 5 relevant features were generated and passed to a classification algorithm for training a model. Support
vector machines with an RBF-kernel proved to give good results. Every of the 44 monitored activities could be determined by an SVM model trained with data from other users. IV. T HE DETECTION FRAMEWORK Detecting basic activities is only one part of the research. The main goal is to build a framework that is capable of detecting more complex activities, e.g., ”The user is walking to a station while it’s rainy” and that is easy to use in new applications which need to know the current activity of the user. The framework consists of three components: monitoring component, processing component and analyzing component. A. Monitoring The monitoring component collects raw data from sensors. Not every activity is useful for the external application. Important to know is that only data that is really needed is collected. Custom monitors can be added to the framework. B. Processing Different processors transform the raw uncompressed sensor data to useful data. Every processor operates on data from one sensor. The SVM technique explained in section III is housed in one processor. Other processors are ,e.g., calculating the current speed of the user, checking if the user arrives at or is moving to one of the hotspots ... C. Analyzing The underlying idea of the analyzing component is the ability to split a complex activity into different smaller activities which have some relation with each other. For example, ”The user is walking to a station while it’s rainy” can be split into ”the user is walking”, ”The user is moving to a station” and ”it’s rainy”. The common relation between the activities is the fact that they need to occur at the same time. The external application can add new relevant activities to the framework by constructing them with existing or new building blocks (= smaller activities). Two approaches for detecting if a user is taking the train are proposed. V. I NTEGRATION An important requirement that was kept in mind while designing the framework is easy integration with other applications. Activity detection itself is not very useful, but in combination with an application that, e.g., provides interesting recommendations in function of the current activity might be very useful. This section explains how such an external application can make use of the framework.
VI. D EMO APPLICATION To make the integration process more tangible, a simple, but realistic example is worked out.The demo application shows live train information from neighboring stations or from a station where the user is currently heading to. Two activities need to be detected within the framework: ”the user is moving to a station” and ”the user is in the neighborhood of a station”. Only the relevant monitors and processors are used. VII. P ERFORMANCE Battery lifetime is a crucial issue for mobile devices. Since the framework makes use of some battery eating sensors, optimalisations are very important. In this section the used optimalisations and their impact on the battery lifetime are introduced and discussed. Also a few empiric experiments on detecting if the user is taking the train and their results are discussed. VIII. C ONCLUSION The detection of basic activities by using the support vector machines with a particular configuration seems to deliver good results. All 44 activities can be determined by using a model trained by data from other users. The built framework is able to detect complex activities. Other applications can easily use and extend the framework to detect custom activities. R EFERENCES [1]
Ling Bao and Stephen S. Intille. Activity recognition from userannotated acceleration data. 2004. http://citeseerx.ist. psu.edu/viewdoc/download?doi=10.1.1.68.5133&rep= rep1&type=pdf. [2] Gregory Biegel and Vinny Cahill. A framework for developing mobile, context-aware applications. 2004. http: //citeseerx.ist.psu.edu/viewdoc/download?doi= 10.1.1.5.605&rep=rep1&type=pdf. [3] Matthias B¨ohmer, Moritz Prinz, and Gernot Bauer. Contextualizing mobile applications for context-aware recommendation. 2010. http: //www.appazaar.net/. [4] A.J. Bernheim Brush, Amy K. Karlson, James Scott, Raman Sarin, Andy Jacobs, Barry Bond, Oscar Murillo, Galen Hunt, Mike Sinclair, Kerry Hammil, and Steven Levi. User experiences with activity-based navigation on mobile devices. 2010. http://www.rantuniverse.com/ activitybasednavphones.pdf. [5] Tanzeem Choudhury and Sunny Consolvo. An embedded activity recognition system. 2008. http://citeseerx.ist.psu. edu/viewdoc/download?doi=10.1.1.141.6348&rep= rep1&type=pdf. [6] Andy Favell. Global mobile statistics 2011. http://mobithinking. com/mobile-marketing-tools/stats-corner. [7] Hans-W. Gellersen, Albrecht Schmidt, and Michael Beigl. Multisensor context-awareness in mobile devices and smart artefacts. 2002. http://citeseerx.ist.psu.edu/viewdoc/download? doi=10.1.1.19.3987&rep=rep1&type=pdf. [8] Google. Android developers guide. http://developer.android. com/guide/index.html. [9] Mi hee Lee, Jungchae Kim, Kwangsoo Kim, Inho Le, Sun Ha Jee, and Sun Kook Yoo. Physical activity recognition using a single tri-axis accelerometer. 2009. http://www.iaeng.org/publication/ WCECS2009/WCECS2009_pp14-17.pdf. [10] Chih-Wei Hsu, Chih-Chung Chang, and Chih jen Lin. A practical guide to support vector classification. 2010. http://www.csie.ntu.edu. tw/˜cjlin/papers/guide/guide.pdf. [11] Jennifer R. Kwapisz, Gary M. Weiss, and Samuel A. Moore. Activity recognition using cell phone accelerometers. [12] Christy Pettey and Ben Tudor. Gartner says android to become no. 2 worldwide mobile operating system in 2010 and challenge symbian for no. 1 position by 2014. http://www.gartner.com/it/page.jsp? id=1434613.
[13] Paulo Pombinho, Ana Paula Afonso, and Maria Beatriz Carmo. Indoor positioning using a mobile phone with an integrated accelerometer and digital compass. 2010. http://xldb.fc.ul.pt/xldb/ publications/Pombinho.etal:IndoorPositioning: 2010_document.pdf. [14] Nishkam Ravi, Nikhil Dandekar, Preetham mysore, and Michael L. Littman. Activity recognition from accelerometer data. 2005. http://citeseerx.ist.psu.edu/viewdoc/download? doi=10.1.1.92.1333&rep=rep1&type=pdf. [15] Chris Veness. Calculate distance, bearing and more between latitude/longitude popints. http://www.movable-type.co.uk/ scripts/latlong.html.
Inhoudsopgave 1 Inleiding
1
1.1
Probleemstelling
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Doelstelling
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2 Literatuurstudie
2
2.1
Het Google Android framework
. . . . . . . . . . . . . . . . . . . . . . . .
2
2.2
Detectie van activiteit binnen hedendaagse mobiele applicaties . . . . . . .
3
2.2.1
Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2.2
Aloqa
4
2.2.3
Appazaar
2.2.4
Locale
2.2.5
Places Directory
2.2.6
Geoloqi
2.3
2.4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
Interessante services
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3.1
Gowalla
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3.2
Foursquare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3.3
Google Places API
. . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.4
Google Geocoding API . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.5
iRail API
6
2.3.6
WikiLocation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.7
Google Weather API . . . . . . . . . . . . . . . . . . . . . . . . . .
7
Gerelateerd werk
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.4.1
Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.4.2
'Activity recognition from accelerometer data'
7
2.4.3
'Activity recognition from Cell Phone Accelerometer data'
2.4.4
'Contextualizing mobile applications for context-aware recommendations'
2.4.5
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
8
'Indoor positioning using a mobile Phone with an integrated accelerometer and digital compass' . . . . . . . . . . . . . . . . . . . . .
vi
8
3 Detectie van basisactiviteiten
9
3.1
Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.2
De versnellingssensoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.3
Verzamelen van data
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.4
Transformatie van de data . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.5
Analyse van de data
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
Support vector machines . . . . . . . . . . . . . . . . . . . . . . . .
15
3.5.1 3.6
Resultaat
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Het detectieframework
20
21
4.1
Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.2
Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.3
Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.3.1
Werking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.3.2
Periodieke monitors . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.3.3
Permanente monitors . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.3.4
Een overzicht van alle monitors
. . . . . . . . . . . . . . . . . . . .
23
4.3.5
Klassenstructuur
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.3.6
Het resultaat
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.4.1
Een overzicht van alle verwerkingseenheden . . . . . . . . . . . . . .
30
4.4.2
Klassenstructuur
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.4.3
Het resultaat
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.5.1
Werking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.5.2
Een overzicht van de verschillende doelen en condities . . . . . . . .
36
4.5.3
Klassenstructuur
37
4.5.4
Implementatie van doelen en condities
4.5.5
Voorbeelden van complexere activiteiten
4.4
4.5
Verwerking
Analyse
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
. . . . . . . . . . . . . . .
39
5 Integratie
46
5.1
Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.2
Integratie met andere applicatie . . . . . . . . . . . . . . . . . . . . . . . .
46
5.3
Werking
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.4
Overzicht
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
vii
6 Demoapplicatie
49
6.1
Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
6.2
Opbouw
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
6.2.1
Benodigde monitors . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
6.2.2
Benodigde verwerkingseenheden . . . . . . . . . . . . . . . . . . . .
50
6.2.3
Benodigde activiteiten
. . . . . . . . . . . . . . . . . . . . . . . . .
50
6.2.4
Werking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
6.3
Resultaat
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 Performantie 7.1
7.2
Batterij verbruik
51
53 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
7.1.1
Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
7.1.2
Proef 1: geen optimalisatie . . . . . . . . . . . . . . . . . . . . . . .
54
7.1.3
Proef 2: schermoptimalisatie . . . . . . . . . . . . . . . . . . . . . .
55
7.1.4
Proef 3: periodiek monitoren . . . . . . . . . . . . . . . . . . . . . .
56
7.1.5
Proef 4: geen gebruik van gps
. . . . . . . . . . . . . . . . . . . . .
57
7.1.6
Proef 5: adaptatie aan externe applicatie . . . . . . . . . . . . . . .
58
7.1.7
Conclusie
59
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Treindetectie: enkele empirische proeven
. . . . . . . . . . . . . . . . . . .
60
7.2.1
Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
7.2.2
Overzicht van de proeven . . . . . . . . . . . . . . . . . . . . . . . .
60
7.2.3
Resultaat
60
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8 Conclusies
63
8.1
Algemeen besluit
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
8.2
Verdere ontwikkelingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
Bibliogra e
66
viii
L¼st van guren 3.1
De drie assen waarlangs de versnelling van het mobiel toestel berekend kan worden.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.2
Printscreen van de hulpapplicatie
3.3
Voorbeeld van 10 samples van de accelerometer
. . . . . . . . . . . . . . .
11
3.4
Versnellingsdata bij het neerzitten . . . . . . . . . . . . . . . . . . . . . . .
12
3.5
Versnellingsdata bij het wandelen
. . . . . . . . . . . . . . . . . . . . . . .
12
3.6
Versnellingsdata bij het joggen . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.7
Versnellingsdata bij het etsen . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.8
Overzicht van de gebruikte parameters
. . . . . . . . . . . . . . . . . . . .
14
3.9
SVM gra sch weergegeven . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.10 Projectie van samples naar een hogere dimensionale ruimte . . . . . . . . .
17
3.11 Score op 45 bij verschillende combinaties van C en gamma
19
. . . . . . . . .
3.12 Score op 45 bij verschillende combinaties van C en gamma (2)
11
. . . . . . .
19
. . . . . . . . . . . . . . . . . . . . . .
22
4.1
Opbouw van de achtergrondservice
4.2
Overzicht van de monitors
. . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.3
De verschillende waarden voor de urbanisatieparameter . . . . . . . . . . .
25
4.4
De urbanisatieparameter bij enkele voorbeeldlocaties
. . . . . . . . . . . .
26
4.5
Broncode om nieuwe monitor toe te voegen . . . . . . . . . . . . . . . . . .
28
4.6
Klassenstructuur van het monitoring gedeelte
. . . . . . . . . . . . . . . .
29
4.7
Opbouw van het verwerkingsgedeelte
. . . . . . . . . . . . . . . . . . . . .
31
4.8
Klassenstructuur van het verwerkingsgedeelte
. . . . . . . . . . . . . . . .
33
4.9
Broncode om nieuwe processor toe te voegen . . . . . . . . . . . . . . . . .
34
4.10 Fundamentele werking van het analysegedeelte . . . . . . . . . . . . . . . .
35
4.11 Overzicht van de verschillende doelen en condities . . . . . . . . . . . . . .
36
4.12 Klassenstructuur van het analysegedeelte . . . . . . . . . . . . . . . . . . .
38
4.13 Implementatie van een doel
39
. . . . . . . . . . . . . . . . . . . . . . . . . .
4.14 Implementatie van een conditie
. . . . . . . . . . . . . . . . . . . . . . . .
4.15 Activiteit: de gebruiker neemt de trein
ix
. . . . . . . . . . . . . . . . . . . .
39 40
4.16 Broncode: de gebruiker neemt de trein
. . . . . . . . . . . . . . . . . . . .
4.17 Verdeling van maximale afstanden tot het dichtste buurtstation
40
. . . . . .
41
. . . . . . . . . . . . . . . . . . . . . . . . .
42
4.19 Activiteit: de gebruiker neemt de trein (tweede aanpak) . . . . . . . . . . .
43
4.20 Broncode: de gebruiker neemt de trein (tweede aanpak) . . . . . . . . . . .
43
4.21 Activiteit: de gebruiker wandelt naar een station . . . . . . . . . . . . . . .
43
4.22 Broncode: de gebruiker wandelt naar een station . . . . . . . . . . . . . . .
44
4.23 Activiteit: de gebruiker etst in de stad bij regenachtig weer
. . . . . . . .
44
4.24 Broncode: de gebruiker etst in de stad bij regenachtig weer
. . . . . . . .
44
4.25 Activiteit: de gebruiker wandelt in de namiddag in de stad . . . . . . . . .
44
4.26 Broncode: de gebruiker wandelt in de namiddag in de stad . . . . . . . . .
45
5.1
Sequentie diagram van het gehele systeem
. . . . . . . . . . . . . . . . . .
48
6.1
Demoapplicatie: toevoegen van monitors
. . . . . . . . . . . . . . . . . . .
50
6.2
Demoapplicatie: toevoegen van processors
. . . . . . . . . . . . . . . . . .
50
6.3
Demoapplicatie: toevoegen van activiteiten . . . . . . . . . . . . . . . . . .
50
6.4
Demoapplicatie: overzicht
. . . . . . . . . . . . . . . . . . . . . . . . . . .
51
6.5
Demoapplicatie: screenshot
. . . . . . . . . . . . . . . . . . . . . . . . . .
52
7.1
Batterijlevensduur proef 1 + Google Navigation . . . . . . . . . . . . . . .
54
7.2
Batterijlevensduur proef 2 + proef 1
. . . . . . . . . . . . . . . . . . . . .
55
7.3
Batterijlevensduur proef 3: periodiciteit . . . . . . . . . . . . . . . . . . . .
56
7.4
Batterijlevensduur proef 4: geen gps
57
7.5
Batterijlevensduur proef 5: adaptatie aan externe applicatie
7.6
Batterijlevensduur: overzicht alle resultaten
4.18 Werking CellIdMovingToGoal
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
. . . . . . . . . . . . . . . . .
59
7.7
Resultaten: detectie trein bij zes proeven . . . . . . . . . . . . . . . . . . .
61
7.8
Proef 6: Cell-ID updates na vertrek uit Brussel-Zuid
62
x
. . . . . . . . . . . .
Gebruikte afkortingen API
application programming interface
GUI
graphical user interface
RBF
radial base function
SVM
support vector machines
URL
uniform resource locator
xi
Hoofdstuk 1 Inleiding 1.1
Probleemstelling
Mobiel internet kent de laatste jaren een enorme groei. Wereldwijd zijn er ondertussen ongeveer 5 miljard gebruikers van mobiele toestellen, waarvan meer dan 20 % toegang heeft tot snel mobiel internet (3G of hoger) [1]. Webontwikkelaars maken reeds enige tijd gebruik van contextgebaseerde informatie over de gebruiker om gepaste aanbevelingen te presenteren. Een voorbeeld hiervan is het weergeven van advertenties die inspelen op de noden van de gebruiker. Via mobiel internet is echter meer contextgebaseerde informatie ter beschikking dan via vast internet. De gebruiker draagt het mobiel toestel namelijk vaak bij zich, waardoor extra informatie zoals zijn huidige locatie, snelheid, omgeving ... opgevraagd kan worden. Men kan zelf een stap verder gaan en de huidige activiteit van de gebruiker detecteren. Deze extra gegevens laten toe om recommandaties te verrijken. Momenteel worden ze echter zelden in rekening gebracht.
1.2
Doelstelling
Het doel van de masterproef is het detecteren van de huidige activiteit van de gebruiker. In een eerste gedeelte zou de detectie van basisactiviteiten zoals stilstaan, wandelen, lopen of etsen aan de hand van versnellingsdata van het toestel mogelijk moeten zijn. Een volgende stap is het detecteren van complexere activiteiten zoals 'de gebruiker wandelt naar een station'.
Dit gebeurt via een framework waar externe applicaties op een een-
voudige manier gebruik van kunnen maken. Zodoende kunnen deze applicaties gepaste stappen ondernemen naargelang de huidige activiteit van de gebruiker. Een applicatie die bijvoorbeeld informatie uit de buurt aanbeveelt, kan dan alvast de gepaste treininformatie inladen voor de gebruiker die op weg is naar het station.
1
Hoofdstuk 2 Literatuurstudie 2.1
Het Google Android framework
Google Android is een Java gebaseerd open source platform voor mobiele telefoons ontwikkeld door Google. Volgens een studie van Gartner [2], een gerenommeerd onderzoeksbureau, is Android momenteel het tweede meest gebruikte framework voor smartphones met een marktaandeel van maar liefst 25 %.
Gartner verwacht dat dit marktaandeel
alleen maar zal toenemen, wat Android binnenkort tot marktleider op het gebied van besturingsystemen voor gsm's kan maken. Verschillende grote gsm producenten zoals HTC of Samsung ontwikkelen momenteel mobiele toestellen met Android. Mobiele toestellen bevatten vandaag de dag verschillende sensoren. Deze sensoren kunnen aangewend worden om de huidige activiteit van de gebruiker te detecteren. Volgende sensoren kunnen aangesproken worden via het Google Android framework:
•
Accelerometer Via de accelerometer kan de versnelling van het toestel langs drie assen opgevraagd worden.
•
Gyroscoop Via de gyroscoop kan de oriëntatie van het toestel langs drie assen opgevraagd worden.
•
Lichtsensor De lichtsensor geeft de hoeveelheid licht in de omgeving van het toestel aan.
•
Magnetisch veld sensor Deze sensor berekent de vector van het magnetisch veld van de aarde en kan dus gebruikt worden als kompas.
2
•
Druksensor De druksensor geeft aan hoe hard de gebruiker drukt op het scherm.
•
Nabijheidssensor De nabijheidssensor is een lichtsensor met binaire uitvoer en geeft aan of er zich iets voor de sensor bevindt of niet.
•
Temperatuursensor Via de temperatuursensor kan de huidige temperatuur van de batterij opgevraagd worden.
•
Gps-ontvanger De gps-ontvanger kan de huidige locatie van de gebruiker tot op enkele meters nauwkeurig bepalen.
Niet elk mobiel toestel bevat alle sensoren. Hierna volgt een overzicht van de sensoren bij enkele veel gebruikte toestellen:
•
Google G1 (september 2008) Accelerometer, digitaal kompas, gps-ontvanger
•
Google G2 (november 2010) Accelerometer, digitaal kompas, gps-ontvanger
•
HTC Nexus One (januari 2010) Accelerometer, gyroscoop, lichtsensor, digitaal kompas, gps-ontvanger
•
HTC Desire (april 2010) Accelerometer, gyroscoop, lichtsensor, digitaal kompas, temperatuursensor, gpsontvanger.
Zowat elk toestel dat Google Android gebruikt heeft de accelerometer, digitaal kompas en gps-ontvanger ingebouwd.
2.2
Detectie van activiteit binnen hedendaagse mobiele applicaties
2.2.1
Inleiding
Applicaties die louter de activiteit van de gebruiker voorspellen zijn niet relevant. De gebruiker weet zelf ook wel waar hij zich de voorbije uren mee bezig heeft gehouden. Detectie
3
van de activiteit kan echter zeer interessant worden wanneer op basis van deze activiteit bepaalde acties ondernomen kunnen worden. Bijvoorbeeld het aanleveren van treininformatie wanneer de gebruiker op weg is naar een station. In hedendaagse applicaties wordt detectie veelal op een zeer simplistische manier gebruikt. Vaak wordt bijvoorbeeld enkel gebruik gemaakt van de locatie van de gebruiker en enkele interesses om zo bepaalde aanbevelingen te doen. Dit zorgt in de praktijk voor minder relevante aanbevelingen en een lagere voldoening bij de gebruiker. In wat nu volgt worden enkele voorbeelden gegeven van applicaties die interessante aanbevelingen aanleveren bij de gebruiker.
2.2.2
Aloqa
Aloqa is een mobiele applicatie die gebruikers op de hoogte houdt van interessante locaties en activiteiten in de buurt. Het systeem komt de interesses te weten door gebruikers te laten inschrijven op verschillende kanalen. Zo bouwt het een pro el op en kan het proactief aanbevelingen geven. Aloqa is momenteel beschikbaar op zowat elk type mobiel toestel: Google Android, Blackberry, Apple iPhone, Windows Mobile, Nokia en Sony Ericsson. Belangrijk om op te merken is dat Aloqa dus enkel gebruik maakt van de locatie en gebruikersinvoer om tot interessante aanbevelingen te komen.
2.2.3
Appazaar
Appazaar is een applicatie ontwikkeld voor Google Android die in de duizenden andere Androidapplicaties op zoek gaat naar deze die interessant kunnen zijn voor de gebruiker. Het baseert zich vooral op de applicaties die de gebruiker frequent hanteert om tot interessante aanbevelingen te komen. Verder maakt het ook gebruik van de locatie omdat deze vaak gepaard gaat met het type applicatie die gebruikt wordt op dat moment.
2.2.4
Locale
Locale is een Androidapplicatie die gebruikers de mogelijkheid biedt om de instellingen van het mobiel toestel te wijzigen naargelang de situatie waarin de gebruiker zich bevindt. Er kan dus bijvoorbeeld ingegeven worden dat de beltoon automatisch moet gedempt worden wanneer de gebruiker toekomt op het werk of dat een melding gegeven wordt indien de batterij bijna plat is op het moment dat de gebruiker zijn huis binnenwandelt.
Locale
stelt ook een Developer API ter beschikking waarmee ontwikkelaars zelf nieuwe condities en instellingen kunnen toevoegen.
4
2.2.5
Places Directory
Places Directory is een Android applicatie ontwikkeld door Google waarmee doorheen nabije locaties in verschillende categorieën zoals restaurants, hotels, stations gebladerd kan worden. Er kunnen foto's en ratings opgevraagd worden en de mogelijkheid tot het bellen naar een bepaalde locatie is ook aanwezig.
2.2.6
Geoloqi
Geoloqi is een mobiele applicatie die gebruik maakt van de locatie van de gebruiker om bepaalde acties te ondernemen. Een actie kan bijvoorbeeld het ontvangen van een sms zijn wanneer vlakbij appartementen verhuurd worden of het automatisch versturen van een e-mail naar je baas indien je om 9 uur nog niet op het werk bent. Geoloqi stelt een API ter beschikking waarmee developers een callback url kunnen laten oproepen wanneer de gebruiker aankomt op of vertrekt van een speci eke locatie.
2.3
2.3.1
Interessante services
Gowalla
Gowalla is een internet service, opgericht in 2007, waar gebruikers op eenvoudige wijze hun huidige locatie kunnen delen met elkaar. Gebruikers kunnen inchecken op locaties die zich reeds in de Gowalla databank bevinden of zelf nieuwe locaties toevoegen. Dit kan vanaf de website of via een mobiel toestel. Ondertussen wordt Gowalla gebruikt door meer dan 600 000 actieve gebruikers. Dit gigantische aantal heeft geleid tot een zeer omvangrijke database van locaties over de hele wereld. Ook in België is Gowalla zeer populair. Quasi elke bakker, winkel, hotel, restaurant, treinstation . . . is ondertussen met beschrijving en exacte locatie terug te vinden via de databank. Gowalla is in het kader van dit onderzoek vooral interessant omdat het een uitgebreide API bevat. Via deze API is het mogelijk nabije spots op te zoeken via een kernwoord of categorie. Aan de hand van de plaatsen in de buurt kan een betere inschatting gemaakt worden van de omgeving waar de gebruiker zich bevindt.
2.3.2
Foursquare
Foursquare is opgericht in 2009 en is de grote concurrent van Gowalla.
Op wereldvlak
is Foursquare ondertussen een stuk groter geworden dan Gowalla. In België is Gowalla echter nog steeds marktleider.
5
Foursquare heeft meer dan acht miljoen leden en kan gebruikt worden via quasi elke smartphone. Het stelt net als Gowalla een uitgebreide API ter beschikking voor programmeurs.
2.3.3
Google Places API
Via de Google Places API kunnen ontwikkelaars van mobiele applicaties informatie over nabije locaties aanbieden aan hun gebruikers. Google Places API maakt het dus mogelijk alle inhoud die op Google Maps terug te vinden is op te vragen en te verwerken. De API is echter nog in volle ontwikkeling en momenteel slechts gelimiteerd te gebruiken na invitatie. Dit maakt deze API niet echt bruikbaar voor het onderzoek.
2.3.4
Google Geocoding API
Geocoding is het omzetten van adressen in geogra sche coördinaten en omgekeerd. De Google Geocoding API biedt dit proces aan en maakt het dus mogelijk via het gps-signaal van de gebruiker de naam van de straat of gemeente waar de gebruiker zich bevindt te weten te komen. De API is gelimiteerd tot 2500 requests per dag.
2.3.5
iRail API
Momenteel is het als ontwikkelaar niet mogelijk de data van de NMBS zoals treinuren, vertragingen op te vragen. iRail.be is ontwikkeld door derden en maakt het opvragen van deze data wel mogelijk. In eerste instantie werd deze service door de NMBS aangeklaagd en stopgezet omdat het onwettig gebruik zou maken van hun data. Ondertussen is iRail terug actief en heeft het een eigen advocaat in de arm genomen die kan aantonen dat het wettelijk gezien niets verkeerd doet. De NMBS heeft zich ondertussen dan ook soepeler opgesteld. De iRail API maakt het dus mogelijk om eenvoudig alle treininformatie in een bepaald station op te vragen of om een volledige route te plannen tussen twee stations.
2.3.6
WikiLocation
WikiLocation is een internetservice die alle Wikipedia-artikels verwerkt om een geogecodeerde database op te bouwen. Dit maakt het mogelijk om artikels op te zoeken aan de hand van de huidige locatie. Gebruikers kunnen zo bijvoorbeeld beschrijvingen lezen over toeristische plaatsen in de buurt. De API maakt het ook mogelijk artikels op te zoeken aan de hand van een Foursquare of Gowalla ID.
6
2.3.7
Google Weather API
Via de Google Weather API is het mogelijk het huidige en toekomstige weer op te vragen aan de hand van een locatie.
Deze locatie kan een postcode, adres, gemeente ...
zijn.
Aangezien het weer mee de huidige context bepaalt waar de gebruiker zich in bevindt kan deze API zeker nuttig zijn.
2.4
2.4.1
Gerelateerd werk
Inleiding
Rond het thema activiteitsdetectie is reeds enig onderzoek verricht. Deze sectie bevat een overzicht van de meest interessante artikels die gebruikt werden ter nagslagwerk. Andere geraadpleegde publicaties zijn terug te vinden in de bibliogra e.
2.4.2
'Activity recognition from accelerometer data'
In deze paper [3] worden resultaten voorgesteld van een onderzoek waarbij activiteiten zoals wandelen, stilstaan, lopen, tanden poetsen, trap bestijgen . . . gedetecteerd worden met behulp van versnellingsdata afkomstig van 5 accelerometers die zich op verschillende delen van het lichaam bevinden. Uit deze versnellingsdata worden enkele parameters geëxtraheerd (gemiddelde, standaardafwijking, energie en correlatie). Vervolgens worden hierop enkele classi catiealgoritmen losgelaten. Voorbeelden van gebruikte algoritmes: decision tables, decision tree, plurality voting, support vector machines. Indien het systeem toegepast wordt op een nieuwe gebruiker wordt een maximale nauwkeurigheid van 73,3 % behaald met behulp van het support vector machines algoritme.
2.4.3
'Activity recognition from Cell Phone Accelerometer data'
Het framework beschreven in [4] maakt in tegenstelling tot het onderzoek in [3] gebruik van de accelerometer in een mobiel toestel. Het volgt echter wel ongeveer dezelfde werkwijze. Er werden data verzameld van 27 proefpersonen. Deze werden geaggregeerd tot enkele parameters zoals gemiddelde, standaardafwijking, tijd tussen pieken . . . Algoritmes zoals J48, logistic regression, multilayer perceptron en straw man werden gebruikt om tot een goede voorspelling te komen. Via het multilayer perceptron algoritme wordt er een gemiddelde nauwkeurigheid behaald van 91,7 % . Het framework is het resultaat van ondermeer assistent professor Gary M. Weiss (Fordham
7
University, New York). Na contact op te nemen bleek dat het nog in volle opbouw is en dus niet publiek ter beschikking gesteld kan worden.
2.4.4
'Contextualizing mobile applications for context-aware recommendations'
Deze paper [5] hoort bij de applicatie Appazaar. Tot nu toe wordt de voortdurend veranderende context van mobiele gebruikers weinig in rekening gebracht bij het aanbevelen van informatie. Als antwoord hierop wordt er een context bewust aanbevelingssysteem voorgesteld die drie grote componenten bevat: client-logeenheid (service), serververwerkingseenheid en client-applicatie.
De client-logeenheid is een service die zoveel
mogelijk gegevens verzameld over de context van de gebruiker.
Deze gegevens worden
vervolgens verwerkt op een server waarna de client-applicatie op de hoogte gebracht wordt van de contextwijziging. Voorbeeld van contextuele data zijn locatie, versnelling en geluidsniveau.
2.4.5
'Indoor positioning using a mobile Phone with an integrated accelerometer and digital compass'
Gps-signalen op mobiele toestellen kunnen binnenshuis vaak niet ontvangen worden. Applicaties kunnen dan ook geen gebruik maken van de locatie binnenshuis. Deze paper [6] stelt een systeem voor die aan de hand van de ingebouwde versnellingsmeter en digitaal kompas de locatie toch zo goed mogelijk probeert te benaderen. Het maakt gebruik van een grondplan om het resultaat te ver jnen. Deze detectie verloopt niet altijd even correct aangezien het moeilijk is om onderscheid te maken tussen de grootte van de voetstappen en de snelheid van verschillende gebruikers.
8
Hoofdstuk 3 Detectie van basisactiviteiten 3.1
Inleiding
Een eerste stap in het onderzoek is het detecteren van de basisactiviteit van de gebruiker. Onder de basisactiviteit van de mobiele gebruiker wordt verstaan: stilstaan, wandelen, lopen of etsen. De implementatie hiervan is gebeurd op het Google Android framework. Google Android is een rijk platform waarbij het mogelijk is om quasi elk hardware onderdeel van het mobiel toestel aan te spreken. Zo kunnen verschillende types van sensoren gebruikt worden tijdens het ontwerpen van een eigen applicatie. Enkele voorbeelden van sensoren die interessant zijn in het kader van deze studie: de nabijheidssensor, de versnellingssensor en de gps-sensor. De versnellingssensoren blijken zeer geschikt voor het detecteren van de basisactiviteit van de gebruiker. De andere sensoren zijn dan weer meer geschikt voor het detecteren van de context waarin deze basisactiviteit zich voordoet.
3.2
De versnellingssensoren
Quasi elk Google Android toestel bevat versnellingssensoren. Dit zijn drie sensoren die de versnelling van het toestel langs drie assen doorheen de ruimte meten. Deze versnelling wordt uitgedrukt in
m en kan ongeveer elke 20 ms opgevraagd worden. Dit interval van s2
20 ms maakt het niet echt mogelijk om hieruit de eectieve snelheid van het toestel te berekenen, maar zorgt er wel voor dat we mogelijks een patroon kunnen herkennen in de beweging van het toestel.
Een gebruiker die loopt veroorzaakt namelijk een andere
beweging met meer energie dan een gebruiker die stilstaat of wandelt. Op dit verschil is de detectie van de basisactiviteit gebaseerd. Figuur 3.1 is een gra sche weergave van de drie assen waarlangs de versnelling kan berekend worden.
9
Figuur 3.1: De drie assen waarlangs de versnelling van het mobiel toestel berekend kan worden.
3.3
Verzamelen van data
Een eerste belangrijke stap was het verzamelen van meetdata van verschillende proefpersonen. Hiervoor werd een hulpapplicatie gebouwd die dit verzamelen zeer eenvoudig maakte. De proefpersoon kan een beschrijving van de komende activiteit ingeven en op de startknop drukken, waarna hij een goede 5 seconden tijd heeft om het toestel op te bergen in zijn broekzak en zijn activiteit te starten. Na deze 5 seconden weerklinkt een luide toon.
Op dat moment begint het toestel de data op te meten.
Na ongeveer 10
seconden weerklinkt een tweede toon die aangeeft dat de meting beëindigd is.
Hierna
worden de data automatisch in het juiste formaat doorgemaild. Zie guur 3.2 voor een screenshot van deze hulpapplicatie.
10
Figuur 3.2: Printscreen van de hulpapplicatie Een voorbeeld van deze data is terug te vinden in guur 3.3 (10 samples). De waarden zijn telkens de versnelling in
m . s2
Figuur 3.3: Voorbeeld van 10 samples van de accelerometer Telkens werd aan de proefpersonen gevraagd om een meting uit te voeren tijdens het neerzitten, het wandelen, het joggen en het etsen. Ter illustratie worden de data van 1 proefpersoon gra sch weergeven. Zie guur 3.4 voor het neerzitten, guur 3.5 voor het wandelen, guur 3.6 voor het joggen en guur 3.7 voor het etsen. Telkens worden de versnellingen (250 samples) langs de drie assen weergegeven.
11
Figuur 3.4: Versnellingsdata bij het neerzitten
Figuur 3.5: Versnellingsdata bij het wandelen
12
Figuur 3.6: Versnellingsdata bij het joggen
Figuur 3.7: Versnellingsdata bij het etsen Vooral bij het etsen is een mooie periodieke beweging te herkennen. De frequentie van de beweging ligt een stuk hoger bij het lopen. Verder is het duidelijk dat lopen en wandelen een behoorlijk verschil in energie omvat. Het is ook belangrijk op te merken dat bij de verschillende activiteiten het verschil tussen de minimum- en maximumversnelling
13
afwijkt van elkaar (bij stilstaan ligt dit lager dan bij wandelen, bij wandelen lager dan bij lopen . . . ). Uiteindelijk werden 45 experimenten uitgevoerd door 11 personen. In deze groep van 11 personen vinden we zowel mannen als vrouwen terug uit de leeftijdscategorie 16 tot 50 om zodoende de algemeenheid van de data te garanderen. Telkens werd het mobiel toestel door de proefpersoon zelf bediend en werd hun louter gevraagd om een bepaalde activiteit uit te voeren, zonder hierbij verdere instructies te geven. Dit om te garanderen dat de activiteit zo natuurlijk mogelijk uitgevoerd werd.
Quasi alle proefpersonen borgen het
toestel tijdens de meting in hun broekzak op, uitgezonderd 1 vrouwelijke proefpersoon die het toestel in een zijzak van haar kleedje opborg. Dit verschil is belangrijk aangezien het toestel in een broekzak veel meer de beweging van de benen volgt dan een toestel in een kleedje.
3.4
Transformatie van de data
Uiteraard kan met deze ruwe versnellingsdata weinig aangevangen worden.
Daarom is
het belangrijk enkele relevante parameters af te leiden uit deze data. Bij het vastleggen van deze parameters werd voornamelijk aandacht besteed aan het feit dat ze voor de vier verschillende basisactiviteiten zo'n verscheidend mogelijke waarde moeten aannemen. De parameters zijn dus voornamelijk gebaseerd op de energie van de data, de pieken en de mate waarin de data veranderen doorheen de tijd. Zie guur 3.8 voor een overzicht van de gebruikte parameters. Enkele van deze parameters (1 tot 3) zijn gebaseerd op het onderzoek van [4]. Anderen werden toegevoegd door op zoek te gaan naar wat de typische verschillen zijn tussen de vier gebruikte basisactiviteiten (4 en 5).
Figuur 3.8: Overzicht van de gebruikte parameters De gemiddelde resulterende versnelling stelt de versnelling langs de drie assen voor als drie vectoren in een ruimte en berekent hieruit de energie van de resulterende vector. De gemiddelde absolute afwijking geeft een eerste indicatie van de mate waarin de snelheid van het toestel langs een bepaalde as verandert doorheen de tijd. De som van de kwadraten
14
van de afwijkingen vormt een mooi beeld van de energie van de versnellingen. Hoe hoger dit getal ligt, hoe meer het toestel bewogen heeft. Het verschil tussen de minimum- en maximumversnelling vormt een duidelijk beeld van hoe snel het toestel beweegt. Bij etsen zal dit opmerkelijk lager liggen dan bij lopen. De graad van verandering vergelijkt elk sample met het sample die drie tijdseenheden later gemeten wordt. Drie tijdseenheden bleek proefondervindelijk een goede waarde te zijn. Opeenvolgende samples vergelijken bleek te weinig verschil te bevatten om een accuraat beeld te vormen van de verandering. Deze vijf parameters bleken een goede combinatie te zijn om de verschillen tussen deze vier basisactiviteiten zo goed mogelijk in kaart te brengen. Parameter 4 en 5 werden pas tijdens een tweede iteratie van het onderzoek geïntroduceerd wat tot opmerkelijk betere resultaten leidde.
3.5
Analyse van de data
De volgende stap is het a eiden van de correcte basisactiviteit uit deze 5 parameters. De bedoeling is een systeem te ontwerpen die aan de hand van de data van de proefpersonen in staat is om een zo accuraat mogelijke voorspelling te maken van de activiteit van een niet gekende gebruiker.
Feitelijk is dit een classi catieprobleem.
Op basis van enkele
parameters moet bepaald worden tot welke klasse de data behoort. Een zeer geschikte techniek voor classi catie van data zijn support vector machines (SVM).
3.5.1
Support vector machines
Support vector machines zijn een set van methoden om data te analyseren en patronen te herkennen, meestal gebruikt voor classi catie van data. Via SVM is het mogelijk een model te trainen op basis van een reeks testdata en hun bijhorende klassen. Vervolgens kan van nieuwe data de klasse (bijvoorbeeld wandelen) bepaald worden door deze te testen tegen het getrainde model. Een SVM-model stelt de parameters feitelijk voor als een punt in een meerdimensionale ruimte.
In dit geval is dit een punt in een vijfdimensionale ruimte.
Eenmaal de data
van elke activiteit van de proefpersonen voorgesteld is als een punt in de ruimte gaat SVM op zoek naar hyperplanes die de punten van verschillende klasses zo goed mogelijk onderscheiden van elkaar. Met zo goed mogelijk wordt bedoeld dat de hyperplanes een zo groot mogelijke kloof moeten vormen tussen punten van verschillende klassen. Figuur 3.9 maakt dit gra sch duidelijk.
15
Figuur 3.9: SVM gra sch weergegeven Deze hyperplanes kunnen vervolgens voorgesteld worden als een set van punten waarvan het innerproduct met een vector in die ruimte constant is. Deze punten vormen het getrainde model.
Hoe beter de klassen van elkaar onderscheiden kunnen worden, hoe
betrouwbaarder het getrainde model is. Om vervolgens de klasse te kunnen bepalen van een nieuwe dataset bijvoorbeeld horende bij een activiteit gemeten bij een nieuwe gebruiker wordt simpelweg gecontroleerd binnen welke grenzen van hyperplanes het punt horende bij deze nieuwe parameterwaarden valt. Het is niet altijd mogelijk om de verschillende klassen lineair te onderscheiden van elkaar. Dit kan opgelost worden door de samples te projecteren in een hoger dimensionale ruimte. Figuur 3.10 maakt dit proces duidelijk.
16
Figuur 3.10: Projectie van samples naar een hogere dimensionale ruimte Om tot een goede con guratie van SVM te komen werd de methode in [7] gevolgd. Deze methode wordt in volgende onderdelen uitvoerig besproken.
Stap 1 - Transformeren van de data Zoals reeds eerder vermeld worden alle data getransformeerd tot vijf parameterwaarden. Aangezien dit telkens reële nummers zijn, staan deze parameterwaarden reeds in het correcte formaat.
Stap 2 - Schalen van de data Het schalen van de data is belangrijk. Dit is om te vermijden dat parameterwaarden uit grotere numerieke ranges andere parameterwaarden overtreen. De som van de kwadraten zal bijvoorbeeld een veel grotere waarde aannemen dan de gemiddelde resulterende versnelling. We schalen de parameterwaarden door de grootste waarde gelijk te stellen aan 1 en de kleinste waarde aan -1. Tussenliggende waarden worden verhoudingsgewijs geschaald naar dit nieuwe interval. Het is belangrijk naast het model ook bij te houden hoe de data geschaald worden, zodat nieuwe toekomstige data op dezelfde manier kunnen geschaald worden.
17
Stap 3 - Gebruik maken van de RBF-kernel De RBF-kernel werd gekozen als kernel voor SVM. De RBF-kernel projecteert namelijk de samples naar een ruimte met een hogere dimensie. Zoals eerder vermeld kunnen hiermee klassen op niet lineaire manier onderscheiden worden van elkaar. Na onderzoek in [7] bleek dat de RBF-kernel tot betere prestaties leidt indien het aantal parameterwaarden aanzienlijk kleiner is dan het aantal datasets. Wat hier zeker het geval is (45 datasets ten opzichte van 5 parameterwaarden). Aangezien de lineaire kernel dan ook nog eens een speciaal geval is van de RBF-kernel, is dit zeker een goede keuze.
Stap 4 - Op zoek naar de beste parameters voor de RBF-kernel De RBF-kernel heeft twee parameters: C en gamma. Voor elk gegeven probleem is een andere combinatie van waarden voor C en gamma optimaal. De eerste stap was dan ook het op zoek gaan naar de beste waarden voor beide parameters. Hiertoe werd een hulpframework gebouwd die het mogelijk maakte zeer eenvoudig alle data van elke activiteit in te lezen, de data te transformeren naar de 5 parameters om vervolgens support vector machines er op los te laten met verschillende combinaties van parameters om zo de ideale combinatie te vinden. Om de validatie van een bepaalde combinatie zo correct mogelijk te laten verlopen werd gebruik gemaakt van crossvalidatie. We beschouwden de dataset van 45 activiteiten. Deze set werd vervolgens opgedeeld in een aantal kleinere groepjes van activiteiten. Vervolgens werd 1 groepje geïsoleerd van de rest en werd via support vector machines met die bepaalde combinatie van parameters voor C en gamma een model getraind op basis van de data van de resterende groepjes. Eenmaal dit model getraind was, werd getest of de data in het afgezonderde groepje correct voorspeld kon worden.
Dit proces voor die combinatie van C en gamma werd
herhaald tot elk groepje eenmaal voorspeld was door een model gebaseerd op de andere groepjes. Zo werd per combinatie van C en gamma een score op 45 gehaald of dus het aantal correct voorspelde activiteiten op basis van een model opgebouwd via data van andere activiteiten. Dit zorgt voor een betrouwbare validatie van de parameters aangezien de voorspelling steeds gebeurt aan de hand van een onafhankelijk model. Volgende waarden werden getest voor C:
2−5 · · · 215
en voor gamma:
2−15 · · · 23 .
Dit zijn
een totaal van 399 combinaties en dus 399 testen die door het framework uitgevoerd werden. Figuur 3.11 is een driedimensionale weergave van de score op 45 die elk van de 399 testen behaald heeft. Het valt op dat naar mate de parameters grotere waarden aannemen de score ook hoger ligt. Enkele testen behaalden zelf de maximale score van 45/45.
18
Figuur 3.11: Score op 45 bij verschillende combinaties van C en gamma Er wordt dan ook gekozen om voortaan
C=2^15 en gamma=2^3 te kiezen bij de
opbouw van het SVM-model voor het detecteren van basisactiviteiten. Ter vergelijking wordt in guur 3.12 het resultaat weergegeven indien slechts de eerste 3 parameters (op basis van het onderzoek van [4]) gebruikt worden. Met deze parameters wordt slechts een maximale score van 41/45 behaald. De twee parameters die zich focussen op typische verschillen tussen de vier basisactiviteiten zijn dus onmisbaar.
Figuur 3.12: Score op 45 bij verschillende combinaties van C en gamma (2) 19
3.6
Resultaat
Als proef op de som werd met deze optimale C en gamma een model opgebouwd zonder wandel-, loop- of etsdata van 1 speci eke persoon. Vervolgens werden de data van deze persoon getest tegen dit model. Dit proces werd herhaald voor ieder van de 11 personen. Telkens kon elke activiteit voorspeld worden.
20
Hoofdstuk 4 Het detectieframework 4.1
Inleiding
Nu het mogelijk is de basisactiviteit van de gebruiker te detecteren, kan deze aangevuld worden met heel wat contextuele informatie.
Thuis neerzitten is namelijk verschillend
aan neerzitten op de trein. Het doel van dit gedeelte is het opbouwen van een framework in Google Android die het mogelijk maakt complexere activiteiten te herkennen. Dit gebeurt op een exibele manier zodat nieuwe activiteiten opgebouwd en toegevoegd kunnen worden. Externe applicaties kunnen gebruik maken van de diensten van het framework om de huidige activiteit te detecteren en zo gepaste stappen te ondernemen. Deze extra contextuele informatie zal verzameld worden via verschillende sensoren die ter beschikking zijn op een mobiel toestel.
4.2
Architectuur
Zoals reeds eerder vermeld kan in het Google Android platform geluisterd worden naar heel wat sensoren. Aangezien het verzamelen van data van deze sensoren en de verwerking ervan een intensief proces kan zijn, werd er gebruik gemaakt van een Android Service. Zo'n service wordt typisch gebruikt bij operaties van langere duur. Het grote voordeel is dat deze volledig in de achtergrond kunnen draaien. Wanneer de gebruiker van het mobiel toestel andere applicaties aan het gebruiken is, kan het dus rustig verder data verzamelen. Er werd gekozen om deze service te laten draaien in de foregroundstatus. Dit betekent dat een klein icoontje wordt weergeven in de statusbalk van het mobiel toestel. Die zorgt ervoor dat het draaien van de applicatie transparant gebeurt zodat de gebruiker er steeds van op de hoogte is. Hij kan dan zelf beslissen de service te stoppen wanneer hij dat wil. Een tweede voordeel is dat de service niet plotseling zal ophouden te bestaan wanneer het Android framework te intensief belast wordt. Bij een hoge belasting zal Android namelijk
21
Figuur 4.1: Opbouw van de achtergrondservice te intensieve services automatisch uitschakelen. Dit is niet mogelijk bij services die in de foregroundstatus draaien. Het detectieframework bestaat uit drie grote delen. Het eerste deel omvat alles in verband met het uitlezen van de data van de sensoren. Dit zijn ruwe data en niet direct bruikbaar om activiteiten te herkennen.
Een tweede deel bespreekt het verwerken van deze ruwe
data tot bruikbare data om dan tenslotte in het derde gedeelte deze verwerkte data te analyseren. Zodoende kan men de huidige activiteit(en) van de gebruiker te weten komen. Dit is schematisch weergegeven in guur 4.1.
4.3
4.3.1
Monitoring
Werking
Het monitoringgedeelte van het framework omvat alles in verband met het luisteren naar de sensoren. Het is belangrijk twee types sensoren te onderscheiden binnen het Google Android framework. Enerzijds zijn er sensoren die continu data aanleveren. Een voorbeeld hiervan is de gps-sensor.
Deze zal naargelang de con guratie ongeveer elke 20 ms een
nieuwe update van de locatie van de gebruiker meedelen. Een tweede type sensoren zijn degene die enkel een signaal geven indien de waarde verandert. Een voorbeeld hiervan is de nabijheidssensor.
Deze kan aangeven of er een voorwerp voor het mobiel toestel
gehouden wordt of niet. Deze sensor wordt binnen Google Android vooral gebruikt om te detecteren wanneer het toestel aan het oor gehouden wordt om te bellen. Zodoende kan tijdens het bellen het scherm uitgeschakeld worden om de batterij te besparen. Deze sensor zal enkel een signaal geven op het moment dat er iets voor komt of indien de sensor terug vrij komt. Waarom is dit onderscheid belangrijk? Bij het tweede type sensoren is het niet mogelijk om slechts af en toe te luisteren naar de sensor.
De laatste waarde kan namelijk niet
opgevraagd worden. Ze kan enkel gedetecteerd worden tijdens een verandering. Het is dus belangrijk constant te luisteren naar deze sensor om telkens de actuele waarde te kunnen bijhouden. Het eerste type sensoren zijn vaak veel intensiever omdat ze voortdurend data aanleveren.
22
Het is dus niet aan te raden er te veel naar te luisteren. Om dit onderscheid in rekening te brengen worden twee types monitors geïntroduceerd: periodieke monitors en permanente monitors.
4.3.2
Periodieke monitors
De periodieke monitors worden af en toe gelanceerd. Ze verzamelen gedurende een korte periode hun data om vervolgens terug vernietigd te worden. Er werd een onderscheid gemaakt tussen actieve en passieve periodieke monitors. de actieve wordt op voorhand vastgelegd hoeveel samples ze zullen verzamelen.
Bij
Bij de
passieve is het aantal samples niet zo belangrijk. De passieve monitors worden dan ook afgesloten zodra de laatste actieve monitor ophoudt met monitoren.
Deze keuze werd
gemaakt om makkelijk contextuele data te verzamelen horende bij bijvoorbeeld de beweging van het toestel.
Tijdens het verzamelen van bijvoorbeeld bewegingsdata voor het
detecteren van de basisactiviteit, zoals in het eerste deel van dit onderzoek uitgelegd, kunnen dan bijvoorbeeld gps-data verzameld worden om de snelheid van de activiteit te bepalen. Indien echter langer gps-data verzameld worden dan bewegingsdata kan dit tot een verkeerde snelheid leiden horende bij de gemeten basisactiviteit.
De GPSMonitor
wordt dus een passieve monitor en de AccelerationMonitor een actieve monitor.
4.3.3
Permanente monitors
De permanente monitors zijn eenvoudig in gebruik.
Zij worden gelanceerd bij het op-
starten van de service en blijven gedurende de levensduur van deze service draaien. Op willekeurige momenten kan de huidige status van de sensor opgevraagd worden. Dit zal telkens gebeuren wanneer de periodieke monitors klaar zijn met het verzamelen van data om zo tot een pakket te komen met alle gegevens van alle sensoren.
4.3.4
Een overzicht van alle monitors
Een overzicht van alle monitors die gebruikt werden in dit systeem zie je in guur 4.2.
1. AccelerationMonitor De AccelerationMonitor zal zoals beschreven in het vorige hoofdstuk de versnelling van het toestel meten langs drie assen. 2. GPSMonitor De GPSMonitor zal indien een gps-signaal ter beschikking is alle locatie-updates van de gebruiker monitoren.
23
Figuur 4.2: Overzicht van de monitors 3. CellIDMonitor DeCellIDMonitor luistert naar wijzigingen in het Cell-ID. Een Cell-ID is een unieke verwijzing naar een gsm-mast. De gsm-mast die zich het dichtst bij de gebruiker bevindt zal telkens dit id meesturen. Via dit id kan de locatie van de desbetreende gsm-mast opgevraagd worden. Dit geeft een ruwe aanwijzing voor de huidige locatie van de gebruiker. 4. ProximityMonitor De ProximityMonitor luistert naar updates van de nabijheidssensor.
Deze sensor
wordt binnen Google Android vooral gebruikt om te controleren of een gebruiker aan het bellen is. Op dat moment kan het scherm uitgeschakeld worden om de batterij te sparen. In het algemeen is dit een soort van lichtsensor die een signaal geeft als een voorwerp zich voor de sensor bevindt of terug verdwijnt. In dit framework is de waarde van de ProximityMonitor vooral belangrijk omdat hiermee met zekerheid te weten kan gekomen worden of een gebruiker zijn toestel niet aanwezig is in zijn broekzak.
Indien de ProximityMonitor aangeeft dat er zich niets voor de sensor
bevindt, dan kan met zekerheid vastgesteld worden dat het toestel zich niet in de broekzak kan bevinden, waardoor de data verzameld door de AccelerationMonitor sowieso foutief zal zijn.
Het omgekeerde is natuurlijk niet mogelijk.
Indien het
toestel bijvoorbeeld omgekeerd op tafel ligt kan niet bepaald worden of deze zich nu
24
in de broekzak of ergens anders bevindt. Wat in dit geval trouwens geen probleem is omdat het resultaat ook correct zou zijn (de gebruiker staat stil). 5. BatteryMonitor De BatteryMonitor luister naar broadcasts die verstuurd worden door het Androidsysteem en betrekking hebben tot de batterij.
Deze monitort bijvoorbeeld of de
batterij momenteel opgeladen wordt. 6. UrbanizationMonitor De UrbanizationMonitor zal aan de hand van een locatie verkregen via het CellID een zo goed mogelijke inschatting proberen te maken van hoe verstedelijkt de omgeving van de gebruiker is. Hiervoor wordt gebruik gemaakt van de Gowalla API. De Gowalla databank is enorm uitgebreid en bevat de locaties van bijna alle winkels, restaurants, hotels ...
Daardoor kan men aan de hand van het aantal Gowalla
spots die zich in de buurt bevinden een behoorlijk goede inschatting maken van hoe verstedelijkt de omgeving is. Via het aantal spots wordt een urbanisatieparameter berekend voor de huidige locatie. Met hoeveel spots elke waarde van de parameter overeenstemt ziet u in guur 4.3.
Figuur 4.3: De verschillende waarden voor de urbanisatieparameter Deze indeling werd proefondervindelijk opgebouwd en bleek een goeie afstelling te zijn. Ter illustratie toont de tabel in guur 4.4 voor enkele locaties de urbanisatieparameter.
25
Figuur 4.4: De urbanisatieparameter bij enkele voorbeeldlocaties Belangrijk hierbij is dat deze monitor de parameter enkel opnieuw zal berekenen indien de locatie van de gebruiker drastisch wijzigt.
Dit om het aantal oproepen
naar de Gowalla API zoveel mogelijk te beperken. 7. WeatherMonitor De WeatherMonitor zal de locatie van de gebruiker (latitude en longitude) via de Google Geocoding API omzetten naar een adres. Vervolgens zal uit het adres de postcode geëxtraheerd worden om vervolgens via de Google Weather API het huidige weer op te vragen. Het resultaat is een monitor die telkens op de hoogte is van de weersomstandigheden. Net als de UrbanizationMonitor zal deze enkel een update van het weer vragen indien de locatie drastisch wijzigt of indien meer dan 2 uur verstreken is. 8. TrainStationMonitor Het doel van de TrainStationMonitor is het ter beschikking stellen van een lijst met stations. Doorheen de ontwikkeling van het framework is de werkwijze hiervoor aangepast. Een eerste idee was het opvragen van de 10 dichtstbijzijnde stations via de Gowalla Api. Probleem hierbij is echter dat het een extra internetverbinding vraagt. Ook is deze lijst niet altijd volledig correct. Gowallagegevens worden namelijk door gebruikers zelf ingevoerd, waardoor soms fouten optreden. Daarom werd op zoek gegaan naar een betere oplossing.
Via de iRail API blijkt
het mogelijk te zijn een lijst op te vragen van alle stations in België met bijhorende locaties.
Dit telkens opvragen is praktisch niet haalbaar.
in de applicatie zelf ingevoegd.
De lijst werd dan ook
De TrainStationMonitor hoeft dus niet echt nog
te monitoren, maar zal louter deze lijst registreren als beschikbare hotspots in het framework.
Het is belangrijk op te merken dat bij de drie laatst besproken monitors geen gps nodig is. Deze monitors werken meer dan voldoende met een ruwe inschatting van de locatie aan-
26
gezien het weer en de dichtsbijzijnde stations niet zomaar wijzigen één kilometer verder. Voor het batterijverbruik is dit goed nieuws.
4.3.5
Klassenstructuur
Figuur 4.6 toont een overzicht van de klassenstructuur van het monitoring gedeelte. Het framework werd zo generiek en exibel mogelijk opgebouwd zodat zonder veel extra code nieuwe monitors kunnen toegevoegd worden. Een overzicht van enkele interessante klassen:
•
Monitor De klasse Monitor is de interface boven alle types monitors. Aan elke monitor kan de bijhorende tag opgevraagd worden.
•
PeriodicMonitor Extensie van de Monitor interface bestemd voor periodieke monitors. Bijkomende mogelijkheid is het nagaan of de periodieke monitor al dan niet passief is.
•
PermanentMonitor PermanentMonitor is een extensie van de Monitor interface bestemd voor permanente monitors. Aan een permanente monitor kan gevraagd worden of zijn resultaat accuraat is. Het kan namelijk zijn dat de monitor nog geen data van de sensor ontvangen heeft (bijvoorbeeld indien nog geen batterij update verstuurd werd door het Android systeem). Indien het resultaat wel accuraat is, kan deze opgevraagd worden via getLastResult()". Verder wordt bij elke nieuwe lancering van de periodieke monitors de reset()"methode aangeroepen voor het geval bepaalde gegevens binnen de monitors elke cyclus gereset hoeven te worden. Zo kan tijdens een reset beslist worden om verouderde locaties die niet meer relevant zijn te wissen.
•
BasicMonitor BasicMonitor is een abstracte extensie van de Java klasse Thread. De run methode werd abstract gemaakt zodat de implementatie lager in de structuur kan gebeuren. BasicMonitor heeft een verwijzing naar objecten van het type MonitorCallback.
•
MonitorCallBack De interface MonitorCallBack heeft twee methoden die door het detectieframework automatisch aangeroepen worden op het moment dat een monitor opgestart en afgesloten wordt.
De achtergrondservice zelf zal deze interface implementeren en
wordt zo telkens op de hoogte gehouden van welke monitors opgestart worden. Bij het afsluiten krijgt deze telkens het resultaat van de monitor terug.
27
•
BasicPeriodicMonitor De BasicPeriodicMonitor is een abstracte implementatie van PeriodicMonitor. De run()-methode wordt geïmplementeerd en zal eerst de callback op de hoogte brengen dat het monitoren zal starten, vervolgens de abstrace methode doInBackgroundoproepen om tenslotte terug de callback op de hoogte te brengen van het resultaat. Dit zorgt ervoor dat de monitors zich niet hoeven aan te trekken van enige callback oproepen. Zij kunnen louter hun resultaat verzamelen. Het framework zorgt voor de rest.
•
BasicPermanentMonitor BasicPermanentMonitor is gelijkaardig aan basicPeriodicMonitor, maar dan voor periodieke monitors.
•
MonitorResult MonitorResult is een abstractie van elk mogelijk resultaat van de verschillende monitors. Via de tag kan het verwerkingsgedeelte te weten komen van welke monitor het resultaat komt en dus het resultaat op de correcte wijze interpreteren.
Een nieuwe monitor toevoegen aan het framework kan door de klasse van deze monitor en 1 regel code toe te voegen (zie guur 4.5).
Figuur 4.5: Broncode om nieuwe monitor toe te voegen
4.3.6
Het resultaat
Elke monitor zal de waargenomen data verzamelen in een pakketje. Dit pakketje krijgt een bijhorende tag die het type data re ecteert en kan vervolgens eenvoudig gebruikt worden in het volgende gedeelte van de background service: het verwerkingssysteem.
28
Figuur 4.6: Klassenstructuur van het monitoring gedeelte
29
4.4
Verwerking
Werking Het doel van het verwerkingsgedeelte is de ruwe data die verzameld werden door het monitoring gedeelte om te zetten naar bruikbare data.
Deze bruikbare data kunnen
vervolgens veel eenvoudiger geanalyseerd worden. Het verwerkingsgedeelte bestaat uit een aantal verwerkingseenheden (processors).
Elk
van deze eenheden kan geregistreerd worden bij het framework via een tag die aangeeft op welke data de verwerkingseenheid zal inwerken. heel exibel.
Dit maakt het verwerkingsgedeelte
Het is mogelijk om meerdere eenheden te registreren bij dezelfde data.
Eenmaal ruwe data van de monitors ter beschikking zijn, worden deze pakket per pakket doorgegeven aan de overeenkomstige verwerkingseenheid. Deze verwerkt de data en maakt op zijn beurt een nieuw pakketje met het resultaat en een bijhorende tag die overeenkomt met het type verwerkingseenheid. Er worden 9 verwerkingseenheden gebruikt.
4.4.1
Een overzicht van alle verwerkingseenheden
Een overzicht van het verwerkingsgedeelte wordt gra sch weergeven in guur 4.7.
1. MovingToProcessor Zoals eerder uitgelegd wordt door het framework een lijst van interessante hotspots bijgehouden. De TrainStationMonitor zorgt ervoor dat in deze lijst telkens de 10 meest dichtstbijzijnde stations aanwezig zijn. Zoals in guur 4.7 duidelijk gemaakt wordt, maakt de MovingToProcessor gebruik van het resultaat van de GPSMonitor. Aan de hand van locatie-updates van de bewegende gebruiker zal deze verwerkingseenheid nagaan welke hotspots de gebruiker aan het naderen is. Voorwaarden zijn dat de gebruiker minstens 10 meter dichterbij komt en maximum 3 kilometer verwijderd is van de hotspot. Dit is om te vermijden dat kleine wijzigingen in de locatie van de gebruiker aanleiding geven tot heel wat benaderingen. In het analysegedeelte zal duidelijk worden dat heel wat meer eisen kunnen opgelegd worden (bijvoorbeeld: een locatie wordt pas als benaderd gezien indien de gebruiker over een langere periode continu aan het naderen is). Het resultaat is een pakketje met een lijst van hotspots die de gebruiker aan het naderen is. 2. SpeedProcessor Deze eenheid maakt gebruik van het resultaat van de GPSMonitor en zal de snelheid van de gebruiker berekenen aan de hand van de laatste locatie-updates en hun
30
31
Figuur 4.7: Opbouw van het verwerkingsgedeelte
tijdstippen. Deze locatie-updates zijn punten op de aardbol uitgedrukt in longitude en latitude. Via volgende wiskundige formule volgens [8] kan de afstand tussen twee zo'n punten gevonden worden:
R = Straal aarde(= 6371km) 4lat = lat2 − lat1 4long = long2 − long1 4long 4lat ) + cos(lat1 ).cos(lat2 ).sin2 ( ) a = sin2 ( 2 2 q √ distance = R.2.atan2 ( a, (1 − a)) Eenmaal de afstand tussen opeenvolgende punten gevonden is, kan op triviale wijze de snelheid afgeleid worden. 3. HotSpotProcessor De HotSpotProcessor maakt gebruik van zowel de gps-data als de Cell-ID-data om na te gaan wat de afstand van de gebruiker tot elke hotspot is. Dit betekent dus dat indien gps niet beschikbaar is op het toestel of uitgeschakeld wordt, deze verwerkingseenheid toch een resultaat zal genereren op basis van Cell-ID. Indien gps wel beschikbaar is, zal het resultaat voor beide ter beschikking zijn. Uiteraard is het mogelijk om in beide gevallen (gps of Cell-ID) een verschillende tolerantie te gebruiken. Gps bepaalt de locatie namelijk tot op enkele meters nauwkeurig, terwijl locatie op basis van Cell-ID tot meer dan een kilometer verkeerd kan zijn.
In de
huidige status van het framework kan met de HotSpotProcessor dus gecontroleerd worden of een gebruiker aangekomen is in een station. De afstand waaraan voldaan moet worden kan zelf opgegeven worden (zie later). 4. CellIDProcessor De CellIDProcessor heeft als invoer een lijst met recente locaties berekend door de CellIDMonitor. Deze zal hieraan twee parameters toevoegen. Het aantal eectieve veranderingen van Cell-ID plus de maximaal overbrugde afstand door de gebruiker. 5. ProximityProcessor De ProximityProcessor zal niets meer toevoegen of wijzigen aan de gegevens van de ProximityMonitor. 6. BatteryProcessor De BatteryProcessor zal niets meer toevoegen of wijzigen aan de gegevens van de BatteryMonitor.
32
7. AccelerationProcessor De AccelerationProcessor is veruit de belangrijkste verwerkingseenheid in het systeem. Deze zal het volledige svm-algoritme (beschreven in hoofdstuk 3) uitvoeren op de data verkregen van de monitor.
Het resultaat is de basisactiviteit van de
gebruiker. 8. UrbanizationProcessor De UrbanizationProcessor zal niets meer toevoegen of wijzigen aan de gegevens van de UrbanizationMonitor. 9. WeatherProcessor De WeatherProcessor zal niets meer toevoegen of wijzigen aan de gegevens van de WeatherMonitor.
4.4.2
Klassenstructuur
Figuur 4.8 toont een overzicht van de klassenstructuur van het verwerkingsgedeelte.
Figuur 4.8: Klassenstructuur van het verwerkingsgedeelte Veel uitleg is hier niet nodig.
Elke processor is een implementatie van de interface
Processor. Deze heeft een process"methode die als invoer het resultaat van een monitor vraagt en als uitvoer het resultaat van de verwerking teruggeeft. Voor de duidelijkheid werd elke implementatie van ProcessorResult weggelaten, maar net als in het monitoring
33
gedeelte is het zo dat elke verwerkingseenheid zijn eigen type resultaat teruggeeft.
De
verschillende types voldoen wel steeds aan dezelfde interface. Een nieuwe processor toevoegen gebeurt door deze te registreren op een bepaald type monitor data (zie guur 4.9).
Figuur 4.9: Broncode om nieuwe processor toe te voegen
4.4.3
Het resultaat
Het resultaat is per verwerkingseenheid een pakketje met data. Net zoals in het monitoring gedeelte krijgt elk pakket een tag die overeenstemt met het type verwerkingseenheid. Zo kan deze data eenvoudig opgevraagd worden in het analysegedeelte.
34
4.5
4.5.1
Analyse
Werking
Het analysegedeelte analyseert het resultaat van het verwerkingsgedeelte om zodoende tot een zo correct mogelijke voorspelling van de huidige activiteit(en) van de gebruiker te komen. De werking van het analysegedeelte steunt op het feit dat een activiteit vaak kan opgesplitst worden in een aantal basisblokken.
Wandelen in de stad bevat bijvoorbeeld de
onderdelen 'wandelen' en 'in een stad aanwezig zijn'. Tussen deze twee basisblokken kan een bepaalde relatie toegeschreven worden. In dit geval is de relatie 'gebeurt op hetzelfde moment'. Het framework zal via deze werkwijze controleren of de gebruiker op het huidige moment een bepaalde activiteit aan het uitvoeren is. Elk van die basisblokken kan in code beschreven worden als een doel waaraan voldoen moet worden. De relatie tussen twee doelen is een overgang die getest wordt. Figuur 4.10 is een gra sche weergave van dit systeem. Er wordt gecontroleerd of de gegevens die uit het verwerkingsgedeelte komen (ProcessorPackageResult) voldoen aan het opgegeven doel. Zoja, wordt er gecontroleerd of er voldaan is aan de conditie, vooraleer het volgende doel gecontroleerd kan worden. Eenmaal alle doelen bereikt zijn, kan met zekerheid gezegd worden dat de bijhorende activiteit is voldaan. Indien een activiteit dus maar uit 1 basisblok bestaat, hoeft geen conditie gecontroleerd te worden.
Figuur 4.10: Fundamentele werking van het analysegedeelte Het is belangrijk op te merken dat de ketting van doelen en condities niet in 1 keer hoeft doorlopen te worden. Indien na een eerste meting het eerste doel voldaan is, maar de conditie nog niet, kan het bijvoorbeeld voorkomen dat na een tweede meting de tweede conditie en het tweede doel bereikt worden.
Na twee metingen kan dan met zekerheid
gezegd worden dat de gebruiker de activiteit aan het uitvoeren is.
Eenmaal een doel
bereikt is, blijft deze ook bereikt. Bij de tweede meting zal dit eerste doel dus niet meer
35
gecontroleerd worden. Wanneer blijkt dat één van de condities onmogelijk nog bereikt kan worden, wordt de volledige ketting gereset en zijn alle doelen en condities terug vrij. Dit systeem maakt het framework zeer exibel in de opbouw van nieuwe activiteiten. Nieuwe doelen, nieuwe condities en dus nieuwe activiteiten kunnen toegevoegd worden.
4.5.2
Een overzicht van de verschillende doelen en condities
Figuur 4.11 toont een overzicht van de doelen en condities die momenteel aanwezig zijn in het systeem.
Figuur 4.11: Overzicht van de verschillende doelen en condities Hierna volgt een korte beschrijving van de doelen:
•
BasicActivityGoal Kan gebruikt worden om te bepalen of een gebruiker aan het wandelen, lopen, etsen of stilstaan is.
•
CityGoal Bepalen of de gebruiker in een stad aanwezig is of niet.
•
BatteryPluggedGoal Testen of de batterij momenteel aan het opladen is.
•
CellIDGoal Aantal Cell-ID wijzigingen en minimaal afgelegde afstand kan hiermee gecheckt worden.
36
•
TrainCellIdGoal Extensie van CellIDGoal die standaard de parameters (aantal vereiste wijzigingen in Cell-ID in 5 minuten tijd + minimaal afgelegde afstand) invult.
Met dit doel
kan gecontroleerd worden of deze Cell-ID wijzigingen overeenkomen met typische wijzigingen wanneer een gebruiker zich op de trein bevindt.
•
TimeGoal Met dit doel kan eenvoudig het tijdstip getest worden. Mogelijkheden zijn: weekdag, weekend, kantooruren, ochtend, middag, avond, nacht, zondag.
•
HotspotGoal Controleren of de gebruiker op een speci eke locatie of een soort locatie (vb station) aangekomen is.
•
MovingToGoal Controleren of de gebruiker op weg is naar een speci eke locatie of een soort locatie.
•
SpeedRangeGoal Met dit doel kan gecontroleerd worden of de snelheid van de gebruiker voldoet aan een bepaalde range.
•
WeatherConditionGoal Controleren op speci eke weersomstandigheden. Mogelijkheden zijn: zonnig, meestal zonnig, bewolkt, gedeeltelijk bewolkt, grotendeels bewolkt, regen, lichte regen, kans op regen, motregen ...
Een korte beschrijving van de twee condities die momenteel aanwezig zijn:
•
ParallelCondition Standaard ingebouwde conditie die controleert of twee basisblokken zich op hetzelfde moment voordoen.
•
TimeCondition Met deze conditie kan een tijdsinterval opgegeven worden met een minimum en maximum tijdsinterval tussen de twee opeenvolgende basisblokken.
4.5.3
Klassenstructuur
Figuur 4.12 toont een overzicht van de gebruikte klassenstructuur in het analysegedeelte. Ook hier worden voor de overzichtelijkheid enkel de meest relevante methodes voorgesteld. Elk doel voldoet aan de interface ActivityGoal". Deze bevat twee interessante methodes. Via de methode addNextïs het mogelijk een nieuw doel toe te voegen aan de ketting.
37
Telkens een nieuw doel wordt toegevoegd, moet een bijhorende conditie meegegeven worden. Deze methode geeft als returnwaarde het doel zelf, waardoor een ketting opgebouwd kan worden.
De tweede methode is de goalIsReached-methode waarmee gecontroleerd
kan worden of een doel bereikt is. Merk ook de abstracte klasse BasicActivityGoal op die feitelijk alle intelligentie van het analysegedeelte bevat. Deze klasse zal de methode goalIsReached"van de interface implementeren en zal bijhouden of het doel reeds voldaan is of niet. Indien het voldaan is hoeven de voorwaarden niet meer gecontroleerd te worden. Indien niet voldaan wordt de abstracte methode checkGoal"getest. Elk doel zal in deze methode louter en alleen de voorwaarden controleren. In de klasse BasicActivityGoal zal indien het doel voldaan is ook de conditie naar het volgende doel getest worden. Is deze ook positief wordt de goalIsReached-methode van het volgende doel aangesproken. Alle logica in verband met het doorlopen of het resetten van de ketting gebeurt dus in de abstracte klasse BasicActivityGoalën aldus verborgen voor de eectieve implementaties van de doelen.
Figuur 4.12: Klassenstructuur van het analysegedeelte
38
4.5.4
Implementatie van doelen en condities
Zoals gezegd is het framework ontworpen met het oog op exibiliteit en eenvoudige uitbreiding. Ter illustratie wordt in guur 4.13 een gedeelte van de broncode van de klasse SpeedRangeGoal"getoond. Buiten dit stuk code is in deze klasse enkel een constructor aanwezig met twee parameters (minSpeed & maxSpeed). In de methode checkGoal wordt eerst het resultaat van de SpeedProcessor opgevraagd via de tag SPEED_RESULT". Vervolgens kan dit resultaat gebruikt worden om te controleren of de snelheid van de gebruiker tussen de opgegeven grenzen ligt.
Figuur 4.13: Implementatie van een doel Figuur 4.14 toont de implementatie van een conditie, namelijk TimeCondition". Via een conditie kan aan de hand van het resultaat van twee verwerkingscycli een bepaalde conditie getest worden. In dit geval wordt getest of de meting van de tweede cyclus zich voordeed binnen een bepaalde tijdslimiet na de eerste cyclus.
Figuur 4.14: Implementatie van een conditie
4.5.5
Voorbeelden van complexere activiteiten
In wat nu volgt worden ter illustratie enkele speci eke voorbeelden gegeven van complexere activiteiten en hoe ze gedetecteerd kunnen worden door het framework. Telkens worden de basisblokken en de implementatie besproken.
De gebruiker neemt de trein - Aanpak 1 Detecteren of een gebruiker de trein neemt is niet zo eenvoudig.
Gps is op een trein
meestal niet ter beschikking, waardoor de snelheid en de richting moeilijk bepaald kun-
39
nen worden. Zelf als deze te weten gekomen kan worden, is het nog niet echt mogelijk om hieruit af te leiden of de gebruiker aan het bewegen is over treinsporen of bijvoorbeeld met de auto aan het rijden is op een parallelle autosnelweg. Een andere aanpak is dus nodig. Doorheen het onderzoek werden twee mogelijke benaderingen uitgewerkt, waarbij de tweede benadering een optimalisatie is van de eerste benadering. Eerst wordt de eerste aanpak besproken. Gps is wel ter beschikking op het moment dat de gebruiker aankomt in een station.
De locaties van de verschillende stations kunnen
zoals eerder beschreven opgevraagd worden. Het is dus mogelijk te weten te komen dat een gebruiker arriveert in het station.
Vervolgens kan nagegaan worden of binnen een
korte periode het Cell-ID van de gebruiker en de bijhorende locatie aanzienlijk wijzigt. Een trein zoeft namelijk meestal in een rechte lijn door het landschap wat voor behoorlijk wat veranderingen in het Cell-ID zorgt. Deze twee onderdelen (arriveren in een station, wijzigingen in Cell-ID) vormen de twee basisblokken van de activiteit 'de gebruiker neemt de trein'. De conditie die hiermee gepaard gaat is een TimeCondition die bepaalt dat het tweede gedeelte van de activiteit zich moet voordoen binnen het uur. Het systeem heeft dus na het arriveren van de gebruiker in het station één uur de tijd om de wijzigingen in het Cell-ID te detecteren. Dit lijkt lang, maar er moet rekening gehouden worden met het feit dat de wijzigingen in het Cell-ID pas opgemerkt kunnen worden op het moment dat de trein al eventjes onderweg is. Een ruime tijdsmarge is dus onontbeerlijk. Figuur 4.15 is hier een gra sche weergave van. Het eerste doel is een HotspotGoal met hotspots van het type train station", het tweede doel is een TrainCellIDGoal.
Figuur 4.15: Activiteit: de gebruiker neemt de trein De broncode om deze activiteit op de bouwen ziet u in guur 4.16.
Figuur 4.16: Broncode: de gebruiker neemt de trein Na het uitvoeren van verschillende testen bleek dat deze aanpak toch redelijk wat beperkingen heeft. Het controleert enkel of er genoeg Cell-ID wijzigingen gebeuren nadat de gebruiker in het station is toegekomen. Als de gebruiker dus met zijn wagen passeert aan een station en vervolgens verder rijdt zou het framework dit ook beschouwen als
40
de trein nemen, aangezien bij het verder rijden ook verschillende Cell-ID updates zullen geregistreerd worden. Een tweede en intelligentere aanpak drong zich dus op.
De gebruiker neemt de trein - Aanpak 2 De tweede aanpak maakt gebruik van de locaties van Belgische stations om zo na te gaan of een gebruiker werkelijk op een trein zit of niet.
Er zal gecontroleeerd worden of de
beweging geregistreerd via Cell-ID wel degelijk in de richting van een station is. Hiervoor kan niet elk station onder de loep genomen worden, want om het even welke richting men gaat, zal men steeds wel op weg zijn naar een bepaald station in België. Enkel stations die zich in een bepaalde straal rond de gebruiker bevinden mogen dus in rekening gebracht worden. Indien de straal echter te groot genomen wordt, zal soms onterecht beslist worden dat de gebruiker op weg is naar een stations, maar indien de straal te klein genomen wordt kan het zijn dat de stations buiten de straal vallen. Om tot een goede waarde voor deze straal te komen werd van elk Belgisch station berekend wat zijn maximale afstand is tot zijn dichtste buur. Zo kan men te weten komen hoeveel kilometer er maximum tussen een station en zijn buurtstation kan liggen. Figuur 4.17 deel A toont de procentuele verdeling van de maximale afstanden tot dichtste buurtstations.
Figuur 4.17: Verdeling van maximale afstanden tot het dichtste buurtstation Het is duidelijk dat de meeste stations behoorlijk dicht bij elkaar liggen. Meer dan 94% van de stations ligt minder dan 7 kilometer verwijderd van zijn dichtste buur. Wanneer een gebruiker met de trein vertrekt vanuit een station is dit natuurlijk niet altijd naar het dichtste station. Stations staan vaak in verbinding met een of meerdere andere stations. Stel dat de gebruiker in het slechtste geval vertrekt naar het derde dichtste station dan zal dit in 73% van de gevallen op minder dan 7 kilometer liggen. Als daarbij nog rekening gehouden wordt dat er pas een Cell-ID update komt nadat de
41
gebruiker al één of meerdere kilometers uit het vertrekstation verwijderd is (en dus al een stukje dichter is bij het andere station) zou zoeken in een straal van 7 km naar een volgend station realistisch moeten zijn. Om dit te realiseren wordt een nieuwe Goal gebouwd: CellidMovingToGoal. Deze zal aan de hand van Cell-ID updates onderzoeken of de gebruiker een hotspot aan het naderen is die zich binnen een opgegeven straal bevindt van de laatste Cell-ID update. Dit wordt gra sch weergegeven op guur 4.18.
Figuur 4.18: Werking CellIdMovingToGoal De gebruiker vertrekt in station 1 en reist met de trein naar station 2. De gele bol is de huidige locatie van de gebruiker op de spoorlijn. De groene bollen geven de tijdens het reizen gedecteerde celtorens weer. Op dit moment zijn drie Cell-ID locaties bepaald. De CellIdMovingToGoal zal vervolgens elk station binnen een straal van 7 km beschouwen en kijken of de gebruiker er naar op weg is. Station 2 voldoet aan deze voorwaarden. Station 4 ligt ook binnen een straal van 7 km, maar het is duidelijk dat met de huidige Cell-ID updates de gebruiker niet aan het bewegen is richting dit station. Station 3 ligt dan wel weer in de goede richting, maar valt buiten de straal van 7 km. Verder eist de CellIdMovingToGoal dat de gebruiker minstenst een afstand van 2 kilometer heeft afgelegd voordat een beslissing wordt genomen.
Dit om te vermijden dat
een gebruiker die wandelt vanaf een station in de richting van een ander station direct beschouwd wordt als een gebruiker op de trein. Een tweede item waarmee rekening gehouden wordt in de tweede aanpak is het feit dat gps op de trein niet beschikbaar is en in de wagen wel. Indien de gebruiker dus een gpssignaal aan het ontvangen is, kan met behoorlijke zekerheid beslist worden dat hij zich niet op een trein kan bevinden. Behoorlijk omdat er wel gps ontvangst mogelijk is indien de gebruiker zijn mobiel toestel tegen het raam houdt, waar bij normaal dagelijks gebruik
42
niet van uit gegaan kan worden. Om dit te controleren werd opnieuw een tweede Goal gemaakt: GPSActiveGoal. Hiermee kan naargelang de parameter gecontroleerd worden of gps actief is of niet. De volledige activiteit bestaat nu uit drie bouwblokken. Het resultaat is te zien in guur 4.19. De bijhorende broncode in guur 4.20.
Figuur 4.19: Activiteit: de gebruiker neemt de trein (tweede aanpak)
Figuur 4.20: Broncode: de gebruiker neemt de trein (tweede aanpak) De tweede aanpak is correcter en sneller dan de eerste aanpak. Er zijn minder Cell-ID updates nodig dan bij de eerste aanpak, waardoor sneller tot een resultaat kan gekomen worden. Er moet ook geen minimum afstand overbrugd worden vooraleer bepaald kan worden of de gebruiker op de trein zit. In hoofdstuk 7 worden de twee werkwijzes vergeleken met elkaar in de vorm van enkele reële proeven.
De gebruiker wandelt naar een station Zoals verteld in 4.3 is het framework telkens op de hoogte van de 10 dichtstbijzijnde stations.
De activiteit 'de gebruiker wandelt naar een station' kan opgesplitst worden
in de twee basisblokken 'de gebruiker wandelt' en 'de gebruiker beweegt richting een station'. De tussenliggende conditie is van het type ParallelCondition. Dit wordt gra sch weergegeven in guur 4.21. De broncode die gepaard gaat met het opbouwen van deze ketting is terug te vinden in guur 4.22.
Figuur 4.21: Activiteit: de gebruiker wandelt naar een station
43
Figuur 4.22: Broncode: de gebruiker wandelt naar een station
De gebruiker etst in de stad bij regenachtig weer Deze activiteit bestaat uit drie basisblokken:
' etsen', 'in een stad aanwezig zijn' en
'regenachtig weer'. De gra sche weergave is terug te vinden in guur 4.23 en de broncode in guur 4.24.
Figuur 4.23: Activiteit: de gebruiker etst in de stad bij regenachtig weer
Figuur 4.24: Broncode: de gebruiker etst in de stad bij regenachtig weer
De gebruiker wandelt in de namiddag in de stad Ook hier zijn er drie basisblokken: 'wandelen', 'in een stad aanwezig zijn' en 'tijdstip is namiddag'. Zie guur 4.25 voor een gra sche weergave en guur 4.26 voor de broncode.
Figuur 4.25: Activiteit: de gebruiker wandelt in de namiddag in de stad
44
Figuur 4.26: Broncode: de gebruiker wandelt in de namiddag in de stad
45
Hoofdstuk 5 Integratie 5.1
Inleiding
In het vorige hoofdstuk werd een gedetailleerde beschrijving van het detectieframework gegeven. Dit framework is uiteraard slechts handig wanneer het gebruikt wordt in combinatie met een andere applicatie die relevante acties onderneemt op basis van de huidige activiteit van de gebruiker. In dit hoofdstuk wordt dieper ingegaan op hoe een externe applicatie kan gebruik maken van de diensten van het framework.
5.2
Integratie met andere applicatie
Het framework zoals beschreven in hoofdstuk 4 bevat heel wat monitoren die luisteren naar verschillende sensoren en heel wat verwerkingseenheden die de data van deze sensoren verwerken om zo te controleren of een gebruiker een bepaalde activiteit uitvoert. Vaak is echter slechts data van één sensor nodig voor het detecteren van een activiteit.
Het
zou dan ook enorm veel overbodige rekentijd en batterijverbruik vragen indien nodeloos naar alle sensoren geluisterd wordt. Ook is het niet nodig om alle mogelijke activiteiten te controleren indien de externe applicatie slechts interesse heeft in enkele activiteiten. Het framework werd dan ook opgebouwd zodat enkel de benodigde operaties uitgevoerd worden.
5.3
Werking
Een eerste stap voor de externe applicatie is het lanceren van de achtergrondservice. Aangezien binnen Android niet rechtstreeks gecommuniceerd kan worden met een Service gebeurt de initiële communicatie via de statische klasse "Manager". De applicatie kan via
46
deze klasse aangegeven dat het op de hoogte wil gebracht worden van het moment waarop de achtergrondservice startklaar is. Dit gebeurt door de applicatie te laten luisteren naar de status van de service. Eenmaal de service paraat is, kan de applicatie de benodigde monitors, verwerkingseenheden, analyse-eenheden en activiteiten toevoegen aan het framework. Zo zal het framework enkel gebruik maken van de benodigde eenheden en wordt de batterij niet onnodig gebruikt. De applicatie heeft dus zelf alle controle over welke sensoren aangesproken worden en welke activiteiten getest hoeven te worden. Vervolgens moet de applicatie luisteren naar updates van het framework. Deze updates bevatten de huidige activiteit(en) van de gebruiker.
Dit luisteren kan gebeuren in een
aparte thread. Aangezien deze updates vaak een verandering van de GUI in de applicatie teweeg zullen brengen, wordt hier best gebruik gemaakt van een AsyncTask. Deze klasse is speci ek ontworpen voor het veilig uitvoeren van langere achtergrondoperaties die de UI thread wijzigen. Deze thread kan zich via de manager registreren om updates in verband met de activiteit van de gebruiker te ontvangen en kan deze tenslotte doorgeven aan de applicatie.
5.4
Overzicht
Figuur 5.1 toont aan de hand van een vereenvoudigd sequentiediagram een overzicht van de gehele werking.
Periodische monitors worden gelanceerd, verzamelen hun data
en bezorgen die aan de BackgroundService. Deze vraagt vervolgens het meeste recente resultaat van de permanente monitors op. Het geheel wordt doorgegeven aan het verwerkingsgedeelte om de ruwe sensordata om te vormen tot bruikbare data. Deze data worden bezorgd aan het analysegedeelte die de huidige activiteit(en) bepaalt. Vervolgens zal de BackgroundService dit resultaat melden aan elke geïnteresseerde partij. In dit geval is dit de Noti er thread die de bijhorende applicatie op de hoogte zal brengen van de nieuwe activiteit.
47
48
Figuur 5.1: Sequentie diagram van het gehele systeem
Hoofdstuk 6 Demoapplicatie 6.1
Inleiding
Ter illustratie werd een eenvoudige demoapplicatie gebouwd die gebruik maakt van de diensten van het framework. Het is belangrijk te vermelden dat het een applicatie betreft die slechts gebruik maakt van een beperkt aantal mogelijkheden van het framework. Dit louter om de integratie te bespreken en niet om de mogelijkheden van het framework weer te geven.
Het doel van de applicatie is het weergeven van alle treininformatie van een
station dat mogelijks interessant kan zijn voor de gebruiker. Met interessant wordt bedoeld een station dat zich in de nabije omgeving van de gebruiker bevindt of een station dat de gebruiker op dat moment aan het naderen is. De weergegeven treininformatie bevat alle informatie die wordt getoond op de schermen in een station: de bestemming, het tijdstip, het perron en de eventuele vertraging.
6.2
6.2.1
Opbouw
Benodigde monitors
Voor de applicatie zijn drie types monitors vereist: CellIdMonitor, GPSMonitor en TrainStationMonitor. De TrainstationMonitor is nodig om alle stations te kunnen raadplegen, de CellIdMonitor is nodig omdat de ruwe locatie van de gebruiker van belang is en de GPSMonitor is nodig omdat moet kunnen gedetecteerd worden of de gebruiker op weg is naar een station. Zie guur 6.1 voor de benodigde broncode om dit te realiseren.
49
Figuur 6.1: Demoapplicatie: toevoegen van monitors
6.2.2
Benodigde verwerkingseenheden
De data van de drie gekozen monitors zal verwerkt worden door 2 types verwerkingseenheden: CellIdProcessor en HotspotProcessor. De HotSpotProcessor zal zowel de data van de CellIdMonitor als deze van de GPSMonitor verwerken. De benodigde broncode is terug te vinden in guur 6.2.
Figuur 6.2: Demoapplicatie: toevoegen van processors
6.2.3
Benodigde activiteiten
De derde stap is het registreren van de benodigde activiteiten bij het framework. Twee activiteiten zijn voor de demoapplicatie van belang.
Dit is de activiteit 'de gebruiker
bevindt zich in de buurt van een station' en 'de gebruiker is op weg naar een station'. Voor de eerste activiteit kan een HotSpotGoal gebruikt worden.
Bij een HotSpotGoal
kunnen drie parameters ingesteld worden: de maximale afstand tot de hotspot op basis van gps, de maximale afstand tot de hotspot op basis van cellid en het type hotspot. De eerste twee de niëren de maximale afstand die een gebruiker verwijderd mag zijn van een hotspot.
Voor de demoapplicatie wordt gekozen om stations weer te geven die zich op
minder dan 5km afstand bevinden. De tweede activiteit kan beschreven worden aan de hand van een MovingToGoal met als parameter opnieuw het type hotspot. Beide activiteiten kunnen binnen de externe applicatie opgebouwd worden en met de code in guur 6.3 toegevoegd worden aan het framework.
Figuur 6.3: Demoapplicatie: toevoegen van activiteiten
50
6.2.4
Werking
Een overzicht van de ow die binnen het framework opgebouwd wordt door het uitvoeren van de hiervoor vermelde broncode wordt weergegeven in guur 6.4.
Figuur 6.4: Demoapplicatie: overzicht Het framework zal telkens een nieuwe cyclus van metingen uitvoeren en de applicatie op de hoogte brengen van het resultaat. Dit gebeurt in de vorm van een lijst met activiteiten. Elke activiteit bevat ook zijn eigen parameters die door de applicatie kunnen opgevraagd worden. Deze parameters kunnen door de doelen toegevoegd worden. In dit geval zou een parameter bijvoorbeeld een lijst kunnen bevatten van alle stations die een rol spelen in de activiteit. Als de demoapplicatie dus een lijst krijgt met bijvoorbeeld enkel de activiteit 'de gebruiker bevindt zich in de buurt van een station' zal deze activiteit ook de lijst bevatten met alle stations die zich in de buurt van de gebruiker bevinden. Deze stations zullen vervolgens worden gesorteerd volgens afstand. Van de drie dichtstbijzijnde stations worden via de iRail API de huidige treinuren opgevraagd.
Eenmaal
ontvangen worden ze weergegeven voor de gebruiker.
6.3
Resultaat
Het resultaat is een eenvoudige applicatie die telkens de drie dichtstbijzijnde stations weergeeft. De gebruiker kan eenvoudig wisselen tussen de treinuren van de verschillende stations. Indien de gebruiker beweegt in de richting van een station dat zich verder dan 5 kilometer bevindt, komt deze ook in de lijst terecht. Een screenshot van de applicatie is terug te vinden in guur 6.5
51
Figuur 6.5: Demoapplicatie: screenshot
52
Hoofdstuk 7 Performantie 7.1
7.1.1
Batterij verbruik
Inleiding
De levensduur van de batterij bij smartphones is een cruciale parameter voor de performantie van een applicatie. Vaak worden door applicaties onnodige operaties uitgevoerd of blijven de applicaties overbodig functioneren in de achtergrond. Het resultaat is een mobiel toestel dat vaak na enkele uren al met een lege accu geconfronteerd wordt. Het framework beschreven in hoofdstuk 4 maakt gebruik van heel wat batterijverslindende hardware zoals bijvoorbeeld het aanspreken van de verschillende sensoren of het versturen en ontvangen van data via het internet. Doorheen het ontwikkelingsproces heeft het framework echter verschillende ingrepen ondergaan om het batterijverbruik zoveel mogelijk te beperken. Deze ingrepen en hun invloed op het batterijverbruik worden in dit hoofdstuk besproken. Alle proeven zijn uitgevoerd op een HTC Desire. Om het batterijverbruik zo nauwkeurig mogelijk te meten, werd gebruik gemaakt van de BatteryMonitor van het eigen framework.
Deze kan tot op één percentage nauwkeurig de wijzigingen in het batterijniveau
registreren. Telkens werd er voor gezorgd dat geen andere applicaties actief zijn en werd het batterijverbruik over een bepaalde periode gemeten. De gegevens van deze periode werden vervolgens geëxtrapoleerd, zodat de totale levensduur van de batterij berekend kan worden indien de applicatie constant draait. We bespreken eerst de performantie van de applicatie zonder optimalisaties en maken dan geleidelijk aan de vergelijking met extra optimalisaties.
53
7.1.2
Proef 1: geen optimalisatie
In Google Android is het niet mogelijk om updates van de sensoren te ontvangen indien het scherm niet actief is. Dit om de gebruikers te beschermen tegen applicaties die onnodig gegevens verzamelen in de achtergrond en zo het batterijverbruik verhogen. Aangezien het framework nutteloos is zonder data van de sensoren was een eerste oplossing ervoor te zorgen dat het scherm steeds actief blijft. Dit kan binnen Android gerealiseerd worden
1
via een WakeLock . Bij een smartphone is het scherm echter één van de grootste energieverbruikers. Het spreekt voor zich dat in verdere optimalisaties dit verholpen zal worden. Bij deze eerste proef zal het framework constant gegevens monitoren en activiteiten bepalen. Gps zal ook actief zijn en zoals uitgelegd blijft het scherm tijdens het uitvoeren steeds aan. Om de performantie beter te kunnen inschatten, werd de vergelijking gemaakt
2
met de reeds bestaande applicatie Google Navigation . Deze zal net als ons framework het scherm steeds actief laten (de gebruiker moet namelijk de route kunnen volgen) en maakt ook constant gebruik van gps. De resultaten zijn weergegeven in guur 7.1. Google Navigation kan 2 uren en 36 minuten op volle kracht draaien. Bij het framework zonder optimalisaties gaat de batterij 3 uren en 32 minuten mee. Dit is uiteraard niet voldoende om het framework in de praktijk bruikbaar te maken.
In de volgende secties worden
enkele optimalisaties besproken die de batterijduur aanzienlijk verhogen.
Figuur 7.1: Batterijlevensduur proef 1 + Google Navigation 1 Via een WakeLock kan controle verkregen worden over de status van het vermogenverbruik van het mobiel toestel. Er kan geopteerd worden om het scherm en/of het toestenbord actief te houden.
2 Google Navigation is een gps-navigatiesysteem voor Google Android toestellen.
54
7.1.3
Proef 2: schermoptimalisatie
Het scherm continu aan laten zodat de data van de sensoren kunnen verzameld worden, is behoorlijk absurd. Een betere oplossing is het scherm dimmen. Hierdoor zal het scherm oplichten met een zeer lage helderheid. Wat er op het scherm gebeurt, is bij het gebruik van het framework toch niet relevant. Indien de gebruiker het toestel wil gebruiken tijdens het monitoren is dit geen probleem. Op het moment dat de gebruiker begint te werken op het toestel wordt de helderheid van het scherm terug normaal. Het is pas vanaf dat de gebruiker even zijn toestel niet gebruikt dat het scherm terug gedimd zal worden. Een tweede aanpassing die doorgevoerd werd, zorgt ervoor dat het scherm enkel zal oplichten indien werkelijk data van de sensoren opgevraagd worden. Als dus op een bepaald moment geen enkele monitor actief is, zal het scherm volledig uitgaan. Op dit moment heeft dit nog niet veel invloed aangezien quasi constant data gemonitord worden. In de volgende secties zal het nut hiervan wel blijken. De resultaten worden weergegeven in guur 7.2. vergelijking ook weergegeven.
Het resultaat van proef 1 wordt ter
Na de schermoptimalisatie gaat de batterij 4 uren en 6
minuten mee. Dit is een verbetering van 16 % ten opzichte van het vorige resultaat.
Figuur 7.2: Batterijlevensduur proef 2 + proef 1
55
7.1.4
Proef 3: periodiek monitoren
Tot nu toe waren de monitors quasi constant actief. In de praktijk is dit echter meestal niet nodig. Denk bijvoorbeeld aan de NMBS Liveboard applicatie. Indien deze om de drie minuten een update krijgt van de nieuwe stations in de buurt is dit zeker ruim voldoende. Het framework is dan ook zodanig ontworpen dat ingesteld kan worden hoeveel tijd tussen elke cyclus gepauzeerd mag worden. Tijdens deze pauze zullen alle monitors slapen en kan het scherm gerust uitgeschakeld worden. Op dat moment wordt quasi geen batterij verbruikt. Proef 3 meet de invloed hiervan op het batterijverbruik. Als eerste luik werd het batterijverbruik gemeten indien telkens 30 seconden gepauzeerd wordt tussen elke monitorcyclus. Het tweede luik last een pauze van 60 seconden in. Het resultaat is terug te vinden in guur 7.3. We zien dat de ingreep een enorme invloed heeft op het batterijverbruik.
De eerste staaf is het resultaat na schermoptimalisatie
(proef 2). De tweede staaf toont aan dat het framework 5 uren en 56 minuten kan draaien indien 30 seconden pauze genomen wordt.
Dit is nogmaals een verbetering van 22 %.
De derde staaf toont de levensduur van maar liefst 11 uren en 30 minuten indien een pauze van 60 seconden genomen wordt. Dit is een extra verbetering van 229 %. Voor de volgende optimalisaties gaan we echter telkens uit van een pauze van 30 seconden.
Figuur 7.3: Batterijlevensduur proef 3: periodiciteit
56
7.1.5
Proef 4: geen gebruik van gps
Gps staat na het scherm aan kop als batterijverbruiker. Gebruik hiervan kan dus best vermeden worden. Het framework werd opgebouwd met de bedoeling zo weinig mogelijk gebruik te maken van gps. Voor het detecteren van de basisactiviteiten wordt bijvoorbeeld geen gebruik gemaakt van de snelheid van de gebruiker, enkel van de versnelling van het toestel. Hierdoor kunnen deze gedetecteerd worden zonder gps-signaal. Het framework maakt voor veel resultaten enkel gebruik van een ruwe locatie bekomen via het Cell-ID. Zo is bijvoorbeeld voor de detectie van naburige stations en detectie van het weer geen gebruik gemaakt van de locatie bekomen via gps. Met andere woorden, het merendeel van de functionaliteit van het framework is zonder gps-signaal nog steeds werkzaam. Enige uitzondering hierop is het bekomen van de snelheid van de gebruiker en het exact testen van een hotspot. Hotspots kunnen echt ook minder nauwkeurig getest worden via Cell-ID. Figuur 7.4 toont het verschil tussen gebruik maken van het gps-signaal (linkerstaaf ) en geen gebruik maken van het gps-signaal (rechterstaaf ).
Indien geen gebruik gemaakt
wordt van gps kan het framework 16 uren en 2 minuten ononderbroken draaien.
Dat
is drie maal zo lang als met gps-signaal. Gebruik van het framework is na de hiervoor vernoemde optimalisaties dus zeker bruikbaar in de praktijk.
Figuur 7.4: Batterijlevensduur proef 4: geen gps
57
Figuur 7.5: Batterijlevensduur proef 5: adaptatie aan externe applicatie 7.1.6
Proef 5: adaptatie aan externe applicatie
In de vorige proeven draaide het framework constant op volle kracht.
Hiermee wordt
bedoeld dat elke monitor en elke verwerkingseenheid beschreven in hoofdstuk 4 actief was.
Vaak zal een externe applicatie slechts een klein gedeelte van deze functionaliteit
nodig hebben.
Zoals al even vermeld in hoofdstuk 6 is het mogelijk vanuit de externe
applicatie zelf de benodigde monitors, verwerkingseenheden en activiteiten toe te voegen. Dit maakt het mogelijk om enkel de data te verzamelen die werkelijk nodig zijn voor de externe applicatie. De NMBS Liveboard applicatie zal bijvoorbeeld enkel gebruik maken van de CellIdMonitor, de GPSMonitor en de TrainStationMonitor. De NMBS Liveboard applicatie is zelf nog niet geoptimaliseerd.
Deze zal, telkens een
nieuwe activiteit ter beschikking is (ongeveer elke 30 seconden), de nieuwe treininformatie opvragen via het internet. Ook als dit niet echt nodig is. Indien we de applicatie laten draaien met het framework op volle kracht zal de batterij na 5 uren en 34 minuten opgebruikt zijn. Uiteraard kan dit alleen al enorm verbeterd worden indien de treininformatie enkel opgevraagd wordt indien echt nodig. In deze proef wordt echter nagegaan wat het eect is op de batterij indien enkel de benodigde monitors actief zijn. Het resultaat is te zien in guur 7.5. De totale levensduur van de batterij verlengt aanzienlijk, namelijk tot 13 uren en 12 minuten.
58
7.1.7
Conclusie
Figuur 7.6 toont voor de overzichtelijkheid een vergelijking van alle resultaten ten opzichte van elkaar. De verschillende optimalisaties zorgen ervoor dat de levensduur van de batterij enorm toeneemt wat de bruikbaarheid in de praktijk aanzienlijk verhoogt. Sensorgegevens worden nu enkel verzameld indien ze werkelijk nodig zijn voor de externe applicatie en dit op periodieke basis. Het scherm zal enkel oplichten indien eectief data van de sensoren verzameld worden.
Figuur 7.6: Batterijlevensduur: overzicht alle resultaten
59
7.2
Treindetectie: enkele empirische proeven
7.2.1
Inleiding
In dit gedeelte worden enkele werkelijkheidsgetrouwe proeven uitgevoerd om de performantie van het detectiesysteem met betrekking tot het detecteren van het nemen van een trein te meten.
Hiervoor draaide het framework - tijdens het nemen van de trein - op
de HTC Desire en werd telkens zowel bij aanpak 1 als aanpak 2 (zie hoofdstuk 4) getest hoe lang het duurde voor deze kon vaststellen dat de gebruiker de trein nam, indien dit mogelijk was. In het totaal werden zeven proeven uitgevoerd.
7.2.2
Overzicht van de proeven
Hieronder volgt een overzicht van de verschillende proeven die uitgevoerd werden:
•
Proef 1: intercity: trein Brugge - Gent
•
Proef 2: intercity: trein Gent - Brugge
•
Proef 3: intercity: trein Gent - Brugge
•
Proef 4: intercity: trein Gent - Brugge
•
Proef 5: lokaal: Brugge - Gent Deze trein stopt bij elke halte.
Moeilijkheid is het feit dat slechts traag nieuwe
Cell-ID updates komen omdat de trein vaak stilstaat en trager rijdt.
•
Proef 6: intercity: trein Brussel-Zuid - Gent Trein vertrekt vanuit Brussel centrum en volgt zeer grillige route om uit Brussel te geraken.
•
Proef 7: Tram in Gent Ter illustratie werd een test bijgevoegd waarbij de gebruiker niet op een trein zit, maar op een tram.
7.2.3
Resultaat
Een overzicht van de resultaten is weergegeven in guur 7.7. Telkens wordt per proef en per aanpak getoond hoe lang het duurt voor beslist kan worden dat de gebruiker op de trein zit. Indien het detecteren niet lukt, wordt dit weergegeven met een zwarte balk.
60
Figuur 7.7: Resultaten: detectie trein bij zes proeven Bij elke proef is aanpak 2 sneller of even snel als aanpak 1.
Bij proef 5 waarbij de
gebruiker zich in een P trein bevond, slaagt aanpak 1 niet in de detectie. Dit omdat telkens na vertrek uit een station slechts traag en weinig Cell-ID updates geregistreerd worden. De tweede aanpak ondervond hier geen last van, omdat met weinig Cell-ID updates nog steeds kan gedecteerd worden of de gebruiker op weg is naar een station. Bij proef 6 slaagt geen enkele aanpak in de detectie. Bij het nader bekijken van de gevolgde route door de trein en de geregistreerde Cell-ID locaties blijkt dit logisch te zijn. De trein maakt namelijk na vertrek uit Brussel-Zuid een bocht van 180 graden. Dit wordt voor alle duidelijkheid gra sch weergegeven in guur 7.8. De oranje lijn stelt de gevolgde route van de trein voor, de groene cirkels zijn de gedecteerde Cell-ID locaties. Het is duidelijk dat uit deze vijf samples geen richting kan gehaald worden zodat ook geen volgend station gedetecteerd kan worden. Detectie zal pas plaatsvinden nadat de trein Brussel verlaten heeft en een rechte koers aanneemt. Bij de tweede aanpak werd via de techniek beschreven in sectie 4.5.5 bij elke proef één of twee stations gevonden waarnaar de trein ook eectief op weg was. Het zou dus mogelijk kunnen zijn in combinatie met treintabellen te achterhalen op welke trein de gebruiker nu precies zit.
61
Figuur 7.8: Proef 6: Cell-ID updates na vertrek uit Brussel-Zuid De resultaten van proef 7 zijn niet terug te vinden in guur 7.7.
Het resultaat bij
proef 7 is dat beide systemen de tramrit niet detecteren als zijnde een trein nemen, wat dus correct is. Voor aanpak 1 wordt namelijk een te kleine afstand afgelegd om de Cell-ID wijzigingen te associëren met het nemen van een trein. Bij aanpak 2 was er gps-ontvangst gemeten en was er geen naburig station in de richting die de tram nam.
62
Hoofdstuk 8 Conclusies 8.1
Algemeen besluit
Het doel van de masterproef bestond uit twee grote luiken: detectie van basisactiviteiten en het bouwen van een framework waarmee complexere activiteiten gedetecteerd kunnen worden. Het detecteren van de vier vooropgestelde basisactiviteiten aan de hand van versnellingsdata bleek goede resultaten op te leveren bij een bepaalde con guratie van support vector machines. Dit resultaat werd vooral bekomen door op zoek te gaan naar parameters die de verschillen in de metingen van de activiteiten zo goed mogelijk benadrukten. Zo zullen de versnellingsdata van de ene activiteit bijvoorbeeld een periodiekere vorm aannemen of meer energie bevatten. Uiteindelijk werd een reeks parameters gevonden die elk van de 45 activiteiten van de proefpersonen kon voorspellen aan de hand van het getrainde model. Het gebouwde framework is in staat complexere activiteiten te detecteren. Dit gebeurt door ruwe data van de benodigde sensoren te verzamelen en deze om te vormen tot bruikbare data. Vervolgens kan het framework elk onderdeel van een complexere activiteit en het onderliggend noodzakelijk verband controleren. Momenteel kan het framework rekening houden met de snelheid van de gebruiker, zijn locatie, de omliggende treinstations en andere interessante plaatsen. Ook het weer, de beweging van het toestel en de status van de batterij kan in rekening gebracht worden. Zo is het herkennen van subactiviteiten, zoals: 'in de stad zijn', 'het weer is goed', 'op weg naar het station', 'batterij aan het opladen', 'aan het etsen' ... mogelijk. Deze subactiviteiten kunnen gecombineerd worden tot complexere activiteiten. Het aantal mogelijke combinaties is legio. Een voorbeeld is het detecteren dat de gebruiker de trein neemt. Externe applicaties kunnen het framework gebruiken en zelf extra monitors, verwerkingseenheden en activiteiten toevoegen. Zoals besproken in hoofdstuk 7 zal het framework enkel operaties uitvoeren die werkelijk nodig zijn en dit op een performante wijze.
63
Zo
wordt getracht de batterij van het mobiel toestel zoveel mogelijk te sparen.
8.2
Verdere ontwikkelingen
Tijdens het ontwikkelen lag de nadruk vooral op het uitwerken van de functionaliteit en het inbouwen van genoeg exibiliteit om verdere uitbreidingen mogelijk te maken.
Zo
kunnen bijvoorbeeld nog meer monitors en verwerkingseenheden toegevoegd worden om meer complexiteit in te bouwen. Alsook kunnen de huidige elementen gebruikt worden in nieuwe combinaties om bijvoorbeeld te detecteren dat een gebruiker in de le staat, zich in een luidruchtige omgeving bevindt ... Momenteel is het framework geheugenloos. Hiermee wordt bedoeld dat geen echte historiek van activiteiten bijgehouden wordt. Activiteiten kunnen wel gegevens gebruiken die verzameld zijn over verschillende cycli, maar het is niet mogelijk gegevens van een langere tijd terug op te vragen. Dit zou bijvoorbeeld handig kunnen zijn om de woonplaats van de gebruiker te detecteren. De woonplaats zal vaak de plaats zijn waar de gebruiker zich 's nachts bevindt (indien er geen beweging wordt gedecteerd) of waar de gsm opgeladen wordt. Eenmaal men de woonplaats kent, kan het mogelijk zijn te detecteren dat de gebruiker zich in een andere stad bevindt. Indien hij dan op weg is naar een station kunnen bijvoorbeeld al de treinuren naar zijn thuislocatie opgevraagd worden. Het detectieframework zou kunnen gecombineerd worden met een serverapplicatie die de activiteiten van elke gebruiker registreert. De serverapplicatie kan gebruikers die hetzelfde patroon volgen groeperen en bepaalde aanbevelingen sturen naar elke groep (bijvoorbeeld interessante plaatsen in de buurt). De reactie van elke gebruiker op de aanbeveling zal meer info vrijgeven over welke recommandaties interessant zijn voor welke groep.
Zo
zullen gebruikers die hoofdzakelijk met de trein reizen op die momenten misschien meer geïnteresseerd zijn in nieuwsberichten. Gebruikers die ver van hun thuislocatie in een stad wandelen zullen bijvoorbeeld meer interesse vertonen voor toeristische plaatsen.
1
Applicaties zoals Appazaar
kunnen andere applicaties voorstellen wanneer de gebruiker
de trein aan het nemen is, dan wanneer die zich thuis bevindt.
1 Appazaar onderzoekt in welke applicaties de gebruiker interesse heeft en stelt zo nieuwe applicaties voor.
64
Bibliogra e [1] Andy
Favell.
Global
mobile
statistics
2011.
http://mobithinking.com/
mobile-marketing-tools/stats-corner. [2] Christy Pettey and Ben Tudor.
Gartner says android to become no. 2 worldwide
mobile operating system in 2010 and challenge symbian for no. 1 position by 2014.
http://www.gartner.com/it/page.jsp?id=1434613. [3] Nishkam Ravi, Nikhil Dandekar, Preetham mysore, and Michael L. Littman. Acti-
http://citeseerx.ist.psu.edu/ viewdoc/download?doi=10.1.1.92.1333&rep=rep1&type=pdf.
vity recognition from accelerometer data. 2005.
[4] Jennifer R. Kwapisz, Gary M. Weiss, and Samuel A. Moore.
Activity recognition
using cell phone accelerometers. [5] Matthias Böhmer, Moritz Prinz, and Gernot Bauer. Contextualizing mobile applications for context-aware recommendation. 2010. [6] Paulo Pombinho, sitioning
using
a
http://www.appazaar.net/.
Ana Paula Afonso,
and Maria Beatriz Carmo.
Indoor po-
mobile
an
and
phone
with
integrated
accelerometer
digital
http://xldb.fc.ul.pt/xldb/publications/Pombinho.etal: IndoorPositioning:2010_document.pdf. compass.
2010.
[7] Chih-Wei Hsu, Chih-Chung Chang, and Chih jen Lin. A practical guide to support vector classi cation. 2010.
http://www.csie.ntu.edu.tw/~cjlin/papers/guide/
guide.pdf. [8] Chris Veness. Calculate distance, bearing and more between latitude/longitude popints.
http://www.movable-type.co.uk/scripts/latlong.html.
[9] Gregory Biegel and Vinny Cahill. A framework for developing mobile, context-aware
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10. 1.1.5.605&rep=rep1&type=pdf. applications. 2004.
65
[10] Ling Bao and Stephen S. Intille. Activity recognition from user-annotated accelera-
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1. 1.68.5133&rep=rep1&type=pdf. tion data. 2004.
[11] Tanzeem Choudhury and Sunny Consolvo.
An embedded activity recognition sy-
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1. 141.6348&rep=rep1&type=pdf. stem.
2008.
[12] Hans-W. Gellersen, Albrecht Schmidt, and Michael Beigl.
Multi-sensor context-
http://citeseerx.ist. psu.edu/viewdoc/download?doi=10.1.1.19.3987&rep=rep1&type=pdf.
awareness in mobile devices and smart artefacts.
2002.
[13] Mi hee Lee, Jungchae Kim, Kwangsoo Kim, Inho Le, Sun Ha Jee, and Sun Kook Yoo. Physical activity recognition using a single tri-axis accelerometer. 2009.
http:
//www.iaeng.org/publication/WCECS2009/WCECS2009_pp14-17.pdf. [14] A.J. Bernheim Brush, Amy K. Karlson, James Scott, Raman Sarin, Andy Jacobs, Barry Bond, Oscar Murillo, Galen Hunt, Mike Sinclair, Kerry Hammil, and Steven Levi. User experiences with activity-based navigation on mobile devices. 2010.
http:
//www.rantuniverse.com/activitybasednavphones.pdf. [15] Google. Android developers guide.
http://developer.android.com/guide/index.
html.
66
