Trådlös trygghetslarm för en Androidenhet

(1)

Trådlös trygghetslarm för en Androidenhet

Kristoffer Hansson

Civilingenjörsexamen Teknisk fysik och elektroteknik

Luleå tekniska universitet Institutionen för system- och rymdteknik

(2)

Wireless Panic Alarm for an Android unit

Kristoffer Hansson

Lule˚ a University of Technology

Dept. of Computer Science, Electrical and Space Engineering

13th August 2012

(3)

(4)

S AMMANFATTNING

En olycka kan snabbt vara framme. För äldre personer kan ett fall vara tillräckligt för att skada sig rejält och inte ha möjlighet att komma ˚at ett kommunikationsmedel, till exempel en telefon. Detta är i dagens samhälle ett stort folkhälsoproblem som b˚ade orsakar lidande och stora kostnader.

Infinner sig känslan av otrygghet kan det underlätta och framförallt hjälpa vid överfall att snabbt kunna tillkalla uppmärksamhet fr˚an omgivningen men ocks˚a familjemedlemmar eller vänner.

För att lösa dessa problem har ett säkerhetslarm utvecklats till en Android-telefon. Detta larm har i uppgift att p˚akalla omgivningens uppmärksamhet genom ljudsignaler men ocks˚a kontakta anhöriga. Ett textmeddelande skickas till den anhöriga med information om vad som hänt och en adress var personen befinner sig.

Alarmapplikationen löser delen med kommunikation mot omvärlden men det är inte alltid det bästa alternativet att ha telefonen i handen. Framförallt är det inte ett alternativ d˚a det kommer till äldre människor. Därför har en tr˚adlös enhet utvecklats, denna enhet har som uppgift att baserat p˚a rörelser aktivera alarmet i telefonen.

En algoritm för att känna av fall och andra rörelsemönster utvecklades för att kunna klassificera olika rörelser och sammanhang utifr˚an accelerometerdata. Denna algoritm implementerades i MATLAB och fungerade tillfredsställande när test med den utvecklade enheten utfördes. En implementation för sensorn bör dock göras i framtiden om produkten ska kunna utnyttjas i sin helhet.

Den utvecklade sensorenheten har möjlighet att mäta acceleration som en person utsätter den för och därefter kommunicera med andra enheter över Bluetooth. Den är dock inte optimerad för massproduktion. Skall enheten användas i ett kommersiellt syfte bör vissa komponenter bytas ut och enheten bör krympas i allmänhet.

iii

(5)

(6)

A ^BSTRACT

If an elderly people fall they can get injured and lose their ability to get help. This is a major health problem in the society today which generates great expenses and suffering.

Today smart phones are both cheap and are used by more and more people. These phones have the ability to get the users current location and communicate with other devices.

In this thesis a smart phone has been used as an alarm. If the alarm is triggered the application starts an alarm sound and gets the user’s position. This position is then converted to an address and sent to an ”in case of emergency” number.

The alarm application solves the problem how to contact the surroundings but the most optimal way is not to have the phone in your hands all the time. With a wireless sensor the phone can be use independently and a sensor can be made smaller which make it easier to attach and won’t interfere with the user as much as a phone.

A sensor unit that can communicate with the smart phone through Bluetooth has been developed. This unit is supposed to classify the user’s motion pattern, via an accelerometer, and start the alarm in the phone when an certain motion is detected, such as a fall.

An algorithm that can classify falls and motion patterns from the accelerometer was developed. The developed algorithm did work satisfying when tests were preformed with the sensor unit. The algorithm was however only developed and tested in MATLAB since this made it easier to evaluate the result. Due to time restrictions the algorithm was never implemented on the sensor and if the sensor is supposed to work with the alarm application as expected this must be done.

The developed device has the ability to do all the required calculations and is able to pair and send all needed data to a smart phone. The device is however not made for production since the size and price of the components have not been optimized.

v

(7)

(8)

F ¨ ^ORORD

Denna rapport gjordes som en del av ett examensarbete inom Civilingenjörsprogrammet Teknisk fysik och elektroteknik med inriktning Elektroniksystem. I dagens informations- samhälle används mer och mer sensorer av olika slag för att samla in data. Ett sätt att använda denna information kan vara att bedöma skador efter olyckor.

Företaget Neava har idag en säkerhetsapplikation som kan bedöma om en bil har krockat och utifr˚an detta sl˚a larm. Denna applikation ville de utvidga funktionaliteten p˚a genom att lägga till en extern källa som kan trigga alarmet. Jag är mycket intresserad av b˚ade utveckling av inbyggda system och programmering av dessa. D˚a jag dessutom gärna vill utvecklas och lära mig mer om detta bestämdes det, tillsammans med Neava, att genomföra idén om en rörelsesensor som ett examensarbete.

Jag vill börja med att tacka Neava för att jag f˚att chansen till att göra detta examensarbete det g˚angna halv˚aret hos dem och för allt de har tillhandah˚allit i materiell väg.

Utöver detta vill jag rikta ett särskilt tack till min handledare p˚a Neava, Pierre Sund- berg, för att ha ställt upp som bollplank och framförallt varit snabb med att införskaffa materiell som behövts.

Vill ¨aven tacka min interna handledare p˚a LTU, Jens Eliasson, som tillf¨ort nyttig information d˚a det kommer till inbyggda system och skrivandet av rapporten.

Utöver detta vill jag tacka mina närmsta vänner, ingen nämnd ingen glömd men ni vet vilka ni är, som har hjälpt mig genom detta halv˚ar b˚ade i diskussioner om mitt examensarbete men ocks˚a de g˚anger de lyckats f˚a mig att släppa det ifr˚an mig och tänka p˚a n˚agot annat.

vii

(9)

(10)

I ^NNEH ALL ˚

Kapitel 1 – Introduktion 1

1.1 Bakgrund . . . 1

1.2 Neava . . . 1

1.3 Syfte och m˚al . . . 2

1.4 Tidigare arbeten . . . 2

1.5 Avgr¨ansningar . . . 3

1.6 Metodik . . . 4

Kapitel 2 – R¨orelseklassificering 5 2.1 Begr¨ansningar . . . 5

2.2 Positionering av sensor . . . 6

2.3 Filtrering av data . . . 7

2.4 Skilja p˚a aktivitet och vila . . . 7

2.5 Kroppspositioner . . . 8

2.6 Fall . . . 9

2.7 Implementation . . . 10

2.8 Sammanfattning . . . 10

Kapitel 3 – H˚ardvara 13 3.1 Specifikationer . . . 13

3.2 Val av komponenter . . . 14

3.2.1 Microkontroller . . . 14

3.2.2 Accelerometer . . . 15

3.2.3 Bluetooth . . . 16

3.2.4 Strömförsörjning . . . 17

3.2.5 Lysdioder . . . 17

3.3 Proof of concept-modul . . . 18

3.3.1 Dotterkort . . . 19

3.4 Sammanfattning . . . 20

Kapitel 4 – Mjukvara 23 4.1 Sensorkortet . . . 23

4.1.1 Utvecklingsmilj¨o . . . 23

4.1.2 Reaktiv programmering . . . 24

(11)

4.2 Programmering av smartphone . . . 26

4.2.1 Val av plattform . . . 27

4.2.2 Utvecklingsmilj¨o . . . 27

4.2.3 Anv¨andargr¨anssnitt . . . 28

4.2.4 Bluetooth-kommunikation . . . 28

4.2.5 Alarm . . . 29

Kapitel 5 – Utv¨ardering 31 5.1 H˚ardvara . . . 31

5.2 Mjukvara . . . 32

5.2.1 Android . . . 32

5.2.2 MSP430 . . . 33

5.3 R¨orelsealgoritm . . . 33

5.3.1 Datainsamling . . . 34

5.3.2 Datasammanst¨allning . . . 35

Kapitel 6 – Diskussion och Slutsats 39 6.1 H˚ardvara . . . 39

6.2 Mjukvara . . . 40

6.2.1 Android . . . 40

6.2.2 MSP430 . . . 41

Kapitel 7 – Framtida arbete 43 7.1 H˚ardvara . . . 43

7.2 Mjukvara . . . 44

7.2.1 Android . . . 44

7.2.2 MSP430 . . . 44

Appendix A – Komponentlista 45 Appendix B – L˚agpassfilter i MATLAB 47 B.1 MATLAB r¨orelseklassificering . . . 47

B.2 MATLAB l˚agpassfilter . . . 51

Appendix C – Kopplingsschema 53

x

(12)

C.1 Kopplingsscheman . . . 53 C.2 Kortlayout . . . 57

Appendix D – Dotterkort 59

D.1 Schema f¨or dotterkort . . . 59 D.2 Layout p˚a dotterkort . . . 60

xi

(13)

(14)

K APITEL 1 Introduktion

1.1 Bakgrund

I dagens samhälle är en stort hälsoproblem fallolyckor som i framförallt drabbar äldre personer. Dessa olyckor orsakar stora kostnader men framförallt stort lidande för den som drabbas. Enligt socialstyrelsen [1] drabbas ca 18000 personer varje ˚ar av höftfrakturer där de allra flesta har orsakats av en fallolycka. Utöver detta dör ca 3 personer om dagen p˚a grund av dessa olyckor enligt folkhälsoinstitutet [2]. Dessa olyckor kan ge stora bekymmer men ocks˚a psykologiska besvär. För att snabbare kunna f˚a hjälp, vilket underlättar b˚ade medicinskt och psykologiskt till en viss grad, vill Neava komplettera sina redan befintliga trygghetsapplikationer med ett tr˚adlös sensorenhet.

Andra användningsomr˚aden kan vara som överfallslarm p˚a väg hem fr˚an krogen eller för yrkeschaufförer inom bland annat taxibranschen. Som överfallslarm, speciellt för taxi- chaufförer, räcker det dock inte med att detektera fall varför andra rörelsemönster ocks˚a bör vara möjliga att detektera.

1.2 Neava

Neava är ett företag inom IT-branschen där de bland annat har ett avknoppningsföretag som heter Neava Applications. Denna avknoppning har som huvudm˚al att utveckla diverse applikationer till handh˚allna och portabla enheter och dagsläget läggs de största

1

(15)

resurserna ner p˚a diverse s¨akerhetsapplikationer. En av de st¨orre produkter de har idag

är en krockövervakningsapplikation, [3]. Denna applikation sl˚ar larm till närst˚aende med information vart personen befinner sig om en bilolycka skulle vara framme.

1.3 Syfte och m ˚al

Syftet med detta projekt var att utveckla en prototyp till en tr˚adlös sensor som skulle kunna komplettera Neavas trygghetsapplikationer. Utöver det har projektet best˚att av programmering av den tr˚adlösa sensorn s˚aväl som en frist˚aende applikation för en Android-enhet. Dessutom har reaktiv programmering av systemet använts för att p˚a s˚a sätt kunna spara s˚a mycket ström som möjlig genom att lägga processorn i vila d˚a denna inte har n˚agra beräkningar att utföra.

M˚alet var att färdigställa en ”proof of concept”-enhet som skulle kunna utföra de efter- fr˚agade funktionerna och även vara s˚a strömsn˚al att man kan driva enheten fr˚an ett litet smidigt batteri i minst en dag.

1.4 Tidigare arbeten

Det har genom ˚aren utvecklats en rad olika sensorenheter för att upptäck just olika rörelser. Bland annat har en sensor för höjdmätning av ett hopp utvecklats p˚a Lule˚a tekniska universitet [4]. Denna enhet stödjer Bluetoothstandarden och använder en relativt strömsn˚al processor. Däremot utvecklades den enbart p˚a ett testkort vilket gjorde enheten stor och dessutom sv˚artillgänglig för detta projekt.

En annan enhet specifikt för fallövervakning har utvecklats p˚a Trentos universitet i Italien [5]. Denna enhet är relativt stor fast den har tillverkats p˚a ett specialbyggt mönsterkort.

Utöver detta stödjer den inte heller Bluetoothstandarden eller n˚agot annat tr˚adlöst protokoll som dagens mobiltelefoner har stöd för.

Wocketen [6] ¨ar en enhet som utvecklats p˚a MIT, Massachusetts Institute of Technology.

Denna har utvecklats i syfte att övervaka en persons aktiviteter i realtid. Den är designad för att vara billig d˚a man med hjälp av flera sensorer räknar ut hur en person rör sig.

Detta kan dock vara en nackdel d˚a användare förmodligen har tillräckligt jobbigt att komma ih˚ag att använda en enhet. Sensorn är dessutom baserad p˚a en ˚atta bitars AVR- arkitektur fr˚an ATMEL [7] som är relativt begränsad i beräkningskapacitet och dessutom

(16)

1.5. Avgr¨ansningar 3

inte är strömsn˚alare än andra mikroprocessorer med betydlig högre kapacitet.

BTNode [8] är även denna en enhet som baserats p˚a AVR-arkitekturen likt Wocketen [6]. Den drivs p˚a vanliga AA-batterier vilket kan vara till en fördel men gör att enheten inte är s˚a liten och dessutom är inte batteritiden den mest optimala.

Mulle [9] och Shimmer [10] är tv˚a andra enheter som är väldigt kompetenta. Mullen som utvecklats p˚a Lule˚a tekniska universitet är väldigt strömsn˚al och liten i formatet.

Shimmer är även denna väldigt strömsn˚al om än designad p˚a en annan plattform än Mullen. Dessa tv˚a är dock nackdelen att de kostar en del d˚a de har m˚anga funktioner som inte skulle behövas till det tilltänkta ändam˚alet.

1.5 Avgr ¨ansningar

M˚alet med examensarbetet var inte att arbeta fram en slutgiltig produkt utan istället visa hur problemet skulle kunna lösas och berätta p˚a vilka sätt detta skulle kunna förbättras.

Därför lades inte allt för stor vikt vid att göra den tr˚adlösa enheten s˚a liten som en kommersiell produkt skulle behöva vara.

I projektet användes en Bluetoothenhet med färdig Bluetoothstack även fast detta skulle kunna göras av mikroprocessorn som hela systemet baseras p˚a. Detta för att det skulle ta för l˚ang tid att skriva en egen Bluetoothstack till plattformen.

D˚a handh˚allna Android-enheter med Bluetooth Smart-standarden inte fanns i tillgängligt kommersiellt vid starten av detta examensarbete sattes Bluetooth 2.1 som Bluetoothstan- dard. Detta satte begränsningar i strömbesparing vilket resulterade i att inte lika stor vikt lades p˚a strömbesparingen som det hade önskats.

(17)

1.6 Metodik

Vid projektstarten p˚abörjades litteraturstudier som i största del bestod av att studera tidigare lösningar vilka problem dessa haft och hur dessa har utförts. Detta gav ett bra underlag för hur h˚ardvaran kunde utvecklas men ocks˚a vilken h˚ardvara som skulle behövas.

Utöver detta studerades även sätt att lösa rörelseklassificering via diverse vetenskapliga artiklar vilket gav en hel del idér p˚a hur detta kunde lösas p˚a ett tillfredsställande och resurssn˚alt sätt.

Efter litteraturstudien delades projektet i tre större delar nämligen programmering, h˚ardvaruutveckling, och utveckling av rörelsealgoritm. Uppdelningen gjordes för att un- derlätta planering av jobbet men ocks˚a för att p˚a detta sätt ta bort s˚a mycket beroende som möjligt och p˚a detta sätt f˚a ett jämnt arbetsflöde.

F¨orsta steget som utf¨ordes var tester med h˚ardvara och programmering av denna.

Samtidigt som detta utf¨ordes p˚ab¨orjades implementeringen av en applikation till en smartphone.

Andra steget var att ta den testade h˚ardvaran vid steg ett ner till ett mönsterkort för att f˚a ett smidigt system att kunna testa rörelseklassificering med.

Det sista steget i projektet var att utveckla en rörelseklassificeringsalgoritm och utföra empiriska tester p˚a för att verifiera att allt fungerade korrekt.

Projektet avslutades med att sammanst¨alla veckorapporter som gjorts, via e-mail till handledare, och anv¨anda dessa till att slutligen skriva en rapport.

(18)

K APITEL 2 R ¨orelseklassificering

I detta kapitel framförs en algoritm som utifr˚an accelerometerdata kan bestämma vilken position bäraren av sensorn har. Dessutom g˚ar det att bestämma vilken aktivitet bäraren av sensorn har utfört utifr˚an analyser av rörelsemönstren.

2.1 Begr ¨ansningar

För att spara ström p˚a den bärbara sensorenheten skall s˚a f˚a meddelanden som möjligt skickas över Bluetooth. För att undvika detta m˚aste klassificering av aktiviteter och positionering g˚a att utföra direkt p˚a mikroprocessorn. Detta medför, d˚a mikroprocessorn har väldigt lite minne och dessutom begränsad beräkningskapacitet, att algoritmen m˚aste h˚allas enkel och dessutom inte behöva utföra tunga beräkningar för ofta.

En lösning p˚a detta problem är att använda ett ”sekund för sekund”-schema. I korthet betyder detta att en g˚ang under varje period, där periodtiden h˚alls konstant, beräknas och undersöks beräknade variabler för att uppskatta vad som inträffat. I detta fall användes just 1 sekund som periodtid d˚a studier av Mathie et al. [11] visar att för rörelsemönster

¨ar de optimala tidsf¨onstret n˚agonstans mellan 0.8 till 1.4 sekunder.

Alla rörelse som en kropp utför är i ca 99% av fallen under 20Hz i frekvens enligt [11].

Detta medför att, med Nyquists-samplingsteorem vilket anger att sampling bör ske med minst dubbla frekvensen än vad som skall mätas, samplingar bör utföras i ˚atminstone 40 Hz. I detta fall valdes att använda en samplingsfrekvens p˚a 100Hz d˚a uträkningarna

5

(19)

skulle göras i MATLAB och p˚a grund av att accelerometern därtill har en inbyggd funktion för att sampla i den hastigheten. Denna hastighet bör dock vid implementering i programspr˚aket C minskas till cirka 50Hz för att till˚ata mikroprocessorn g˚a i vila oftare d˚a färre beräkningar behövs.

2.2 Positionering av sensor

För att data som g˚ar att bearbeta ska kunna samplas och analyseras är en av förut- sättningarna att veta ungefär vad accelerometern kommer mäta. En arm rör sig, vid till exempel ett fall, väldigt oförutsägbart vilket medför att det inte är en s˚a god idé att sätta en sensor p˚a handleden om man vill upptäcka en s˚adan rörelse. M˚alet med denna rapport var framförallt att upptäcka fall men även positionering av kroppen. Därför behövdes en plats p˚a kroppen som inte rör sig annat än vid vanliga rörelser; en s˚adan plats är bland annat vid bäckenbenet. Eftersom denna plats är väldigt stilla och dessutom p˚averkas en del av kroppens positionering som till exempel vid sittande, st˚aende och liggande ställning är det en bra placering vilket stämmer bra överens med andra publikationer som gjorts [11, 12, 13]. Accelerometern fixerades med hjälp av tejp direkt p˚a försökspersonens bälte som i sin tur justerades för att sitta stabilt och p˚a rätt ställe. Accelerometerns axelriktningar d˚a den var fäst p˚a försökspersonen kan ses i figur 2.1.

Figur 2.1: Placering av sensorn med accelerometerns riktningsaxlar utm¨arkta.

(20)

2.3. Filtrering av data 7

2.3 Filtrering av data

Data som samplas inneh˚aller alltid en viss mängd brus och filtrering bör därför alltid ske. För att f˚a bort tvära spikar och felmätta värden används ett medianfilter. Ju störra filter desto bättre för en jämnare signal; detta kommer vid användning av stora filter att ta bort alla spikar till exempel vid fall. Storleken har dessutom betydelse när filtret senare ska implementeras till mikroprocessorn; dels att det tar minne att ha l˚anga filter men ocks˚a att det tar betydlig mycket mer resurser att beräkna medianen p˚a stora filter.

Med tanke p˚a detta och att mätvärdena var relativt stabila valdes ett kort medianfilter med längden 3. Detta filter är lätt att implementera i C-kod d˚a väldigt f˚a jämförelser behövs jämfört med de n˚agot större medianfiltren och fungerar bra vid tester vilket ocks˚a Mathie et al. [11, 14] har kommit fram till.

Det intressanta vid mätningar av en persons aktivitet är accelerationen kroppen utsätter sensorn för. En accelerometer mäter dock även accelerationen fr˚an jordens gravitation vilket medför problem d˚a denna kraft inte kommer fr˚an användaren av sensorn. Kraften fr˚an jordens gravitation kan ocks˚a vara bra att veta d˚a denna kan hjälpa till vid identifi- ering av kroppsposition. De tv˚a komponenterna, kropps- och jordens kraftkomponenter,

¨

overlappar varandra b˚ade i tids- och i frekvensdomänen vilket gör det sv˚art att separera dessa. Med ett l˚agpassfilter, LPF, kan gravitationsp˚averkan approximeras och när detta

är gjort g˚ar det räkna ut den kroppsliga p˚averkan. Ett l˚agpassfilter med brytningsfre- kvensen 0.25 Hz [11, 14], fungerar bra för att separera ut gravitationskomponenterna.

Denna kan sedan subtraheras fr˚an det filtrerade data, som erh˚allits fr˚an medianfiltret, f¨or att f˚a fram kroppskomposanterna. F¨or implementering av l˚agpassfiltret i MATLAB se appendix B.2.

2.4 Skilja p ˚a aktivitet och vila

För att skilja p˚a om en person är aktiv eller i vila behövs ett mätvärde som tar hänsyn till alla tre axlarna p˚a en accelerometer d˚a kroppen skapar krafter ˚at alla olika riktningar.

Ett lämpligt m˚att är enligt [11, 14] och [15] den normaliserade signalmagnitudens area (SMA). I ekvation 2.1 ses hur SMA-värdet beräknas där x(t), y(t) och z(t) är kroppskomposanterna av accelerationen som erh˚allits efter att den l˚agpassfiltrerade komposanten subtraherats fr˚an det medianfiltrerade datat.

SM A = 1 t

Z t 0

|x(t)| dt + Z t

0

|y(t)| dt + Z t

0

|z(t)| dt

(2.1)

(21)

Beräkningar av SMA-värdet görs, som nämnts tidigare i kapitel 2.1, p˚a sekundbasis.

Eftersom mätvärden f˚as med en konstant ström, samma tid mellan dem, är det enkelt att beräkna integralen. Detta görs genom att summera alla mätpunkter under den g˚angna sekunden och multiplicera summan med tiden mellan varje mätning. Detta medför att det är enkelt att utföra p˚a begränsade system som till exempel en mikrokontroller.

För att skilja p˚a aktivitet och vila används sedan ett tröskelvärde som jämförs mot SMA- värdet. Detta värde testades fram genom att bland annat falla, g˚a, sitta och ligga och jämföra de olika resultaten, tillvägag˚angsättet liknar mycket det Mathie et al. använt i [14] och Jeon et al. [15] . Tröskelvärdet valdes till 0,2 g efter diverse olika tester. Ett högre värde fungerar bättre om falska ”vilopauser”inte vill upptäckas när vissa typer av g˚ang utförs. Ett lägre värde kommer dock att ge fler aktivitetsutslag d˚a det inte behövs samma mängd rörelser för att uppn˚a tröskelvärdet. Detta ger i sin tur fler falska aktiviteter vid vila och därför var en avvägning tvungen att göras.

2.5 Kroppspositioner

En människokropps olika positioner kan urskiljas genom att besk˚ada kroppens relativa vinkel mot gravitationen. När en person st˚ar upp är gravitationsvektorn parallell med kroppen medans om personen ligger är den vinkelrät mot kroppen. Mathie et al. har i en artikel [11] konstaterat att 20^◦ eller mindre beskriver en st˚aende person medans en sittande person befinner sig n˚agonstans under 60^◦. Detta medför att dessa tv˚a positioner

överlappar varandra n˚agot men b˚ade studier gjorda p˚a denna algoritm av Mathie et al.[11] och denna rapport visar p˚a att det dock är stor sannolikhet att algoritmen f˚ar rätt. En sittande position anses ligga mellan 20^◦ och 60^◦. Utöver dessa tv˚a positioner g˚ar det även att bestämma om en person ligger ner d˚a detta sker vid vinklar större

än 60^◦. För en sammanfattning av dessa vinklar se figur 2.2 . För att beräkna vinkeln konstaterades att den negativa y-axeln, se figur 2.1, bör beaktas vilket ger ekvation 2.2, där y är kroppskomposanten som filtrerats fram av l˚agpassfiltret, se 2.3. Istället för att använda ekvation 2.2 i mikroprocessorn kommer senare tröskelvärden som motsvarar de eftersökta vinklarna att användas vid jämförelser p˚a y-axeln. Detta för att de relativt tunga beräkningarna inte skall behöva utföras och dessutom kommer tröskelvärden att ge exakt samma svar. MATLAB-skriptet som kördes p˚a en PC använde dock den exakta formeln för att kunna ˚ask˚adliggöra vinkeln i till exempel en graf.

Eftersom gravitationskomponenterna redan har filtrerats fram med hj¨alp av ett l˚agpassfilter, se kapitel 2.3, g˚ar en ekvation av vilken vinkel gravitationen har mot en axel p˚a accelerometern att h¨arleda, se ekvation 2.2.

(22)

2.6. Fall 9

Figur 2.2: Avläsning av en persons position utifr˚an gravtitationsvektorn. Bilden är hämtad fr˚an artikel skriven av Mathie et al. [11].

Φ = arccos(−y) (2.2)

Utöver detta skulle samma vinkelberäkningar kunna utföras p˚a x- och y-axeln för att bestämma vilken position en person har d˚a denne ligger ner. Detta ans˚ags inte relevant i sammanhanget, d˚a information om att personen ligger ner är tillräckligt för att uppskatta att ett fall skett, men mer information om detta finns tillgänglig i en artikel skrivern av Mathie et al. [11].

2.6 Fall

För att bestämma om ett eventuellt fall har skett behövs n˚agot slags m˚att p˚a storleken av alla krafter som kroppen har utsatt accelerometern för. Här blir signalvektorns magnitud, SVM, relevant. I ekvation 2.3 ses hur detta m˚att beräknas där x_i, y_i och z_i är den momentana accelerationen som kroppen utsätter accelerometern för, det vill säga det värde som f˚as efter l˚agpassfiltret.

(23)

SV M = q

x²_i + y_i²+ z_i² (2.3)

SVM-värdet jämförs sedan med ett tröskelvärde. Om detta tröskelvärde överskrids med mer än tv˚a p˚a varandra följande mätpunkter tilldelas det p˚ag˚aende tidsintervallet ett möjlig fall. Ett tröskelvärde testades fram via ett flertal olika fall fr˚an olika positioner och mot olika underlag. I enlighet med [11] var de bästa tröskelvärdet 1,8 g.

2.7 Implementation

Som n¨amnts tidigare i detta kapitel valdes att i detta projekt implementera

rörelseklassificeringsalgoritmen i MATLAB [16]. Detta var ett val som gjordes bland annat därför att det g˚ar lätt att komma ig˚ang med den seriella kommunikationen i Windows.

Det medför att man i realtid kan ta emot data fr˚an enheten och analysera informationen som det skulle ha gjorts p˚a ett inbyggt system. Det är dessutom lätt att spara undan data och information för att analysera i efterhand. Sparat data fr˚an varje körning g˚ar lätt att sammanställa i grafer vilket kan underlätta felsökning men ocks˚a underlätta diskussioner och slutsatser om det resultat som f˚as.

2.8 Sammanfattning

För att systemet skall kunna känna av alla ovan nämnda situationer m˚aste de göras tillsammans i en algoritm. Som tidigare nämnts filtreras först data via ett medianfilter som i sin tur delas upp i gravitations- och kroppskomposanter. Efter detta beräknas SMA- värde för att bestämma om personen utför en aktivitet eller om den har en viloposition.

Om en aktivitet har utförts, det vill säga ett SMA-värde över tröskelvärdet 0,2 g, jämförs SVM-värdet mot ett tröskelvärde p˚a 1,8 g för att kontrollera om ett fall har skett. Har inte ett fall skett bestäms vinkeln mot gravitationskomponenten ,Φ, för att se om personen

¨ar aktiv i liggande eller uppr¨att position.

Har inte en aktivitet utförts, det vill säga ett SMA-värde under tröskelvärdet 0,2g, kon- trolleras kroppspositionen via gravitationens vinkel mot den negativa y-axeln. Utifr˚an denna bestäms sedan kroppens position.

För en översk˚adlig bild av hela algoritmförloppet, se figur 2.3.

(24)

2.8. Sammanfattning 11

F¨or en MATLAB implementation se appendix B.1.

Figur 2.3: Flödesschema över rörelsealgoritmen.

(25)

(26)

K APITEL 3 H ˚ardvara

Detta kapitel behandlar h˚ardvarans funktioner och hur den designats utifr˚an uppsatta specifikationer.

3.1 Specifikationer

För att överhuvudtaget kunna mäta rörelser för att känna av till exempel ett fall eller en speciell rörelse med handen m˚aste det för det första finnas en sensor för rörelser. En sensor som accelerationen krafter den utsätts för är accelerometern. För att kunna mäta rörelser i alla tre dimensionerna behövs en tri-axial accelerometer. Samlingsfrekvensen p˚a accelerometern uppskattades till att behöva sampla uppemot 100 Hz.

För att kunna lösa ut ett larm när en speciell rörelse upptäcks av enheten s˚a m˚aste den kommunicera med smartphone i fr˚aga, mer specifikt i denna rapport en Android- telefon. S˚adana mobiler har i skrivande stund tillg˚ang att kommunicera via Bluetooth, där version 2.1 är vanligast, Wi-Fi och över telefonnätet. Att g˚a över telefonnätet är för de första kr˚angligt och för de andra blir de dyrt d˚a ett abonnemang m˚aste användas i b˚ada ändpunkter. Att använda mobilens Wi-Fi som ett nätverk ihop med sensor-enheten

är ett alternativ. Detta skulle tyvärr göra det onödigt kr˚angligt att använda internet i mobilen samtidigt som sensor-enheten d˚a Android-telefoner använder antingen Wi-Fi eller telefonnätet för att komma ˚at internet. Dessutom är Wi-Fi mindre energieffek- tivt än andra alternativ. Bluetooth är relativt strömsn˚alt, speciellt den nya ”Bluetooth smart-standarden. Utöver detta stöds SPP, serial port profile [17], för att simulera seriell

13

(27)

kommunikation och haren r¨ackvidd p˚a 10 meter.

För att driva systemet behövs n˚agon slags strömförsörjning. Eftersom enheten skall vara tr˚adlös och mäta rörelser används ett batteri till detta ändam˚al. Spänningen fr˚an batteriet regleras sedan för att f˚a en stabil spänning p˚a rätt niv˚a.

3.2 Val av komponenter

I denna sektion diskuteras varf¨or de viktigaste komponenterna valdes och vilka avv¨agningar som gjordes.

3.2.1 Microkontroller

Mikroprocessor, skulle stödja att sampla i 100Hz men dessutom hinna göra beräkningar emellan˚at och utöver detta h˚alla koll p˚a bland annat batteriet. Dessutom var ström- effektiviteten ett krav som stod högt p˚a listan. För att kunna vara strömsn˚al och g˚a i vila när MCUn inte används är reaktiv programmering en förutsättning. P˚a LTU används TinyTimber [18, 19] för detta ändam˚al och denna kärna har stöd för ett antal olika plattformar, se TinyTimber tabell 3.1. Dessutom var kravet att de skulle vara enkelt att komma ig˚ang med, däribland möjligheten att f˚a tag p˚a utvecklings kort snabbt. Därför valdes Texas Instruments MSP430 som arkitektur. Denna enhet är mycket strömsn˚al [20], har fem olika strömsparlägen och stöd för alla protokoll som behövs, se kapitel 3.2.2 och 3.2.3. Dessutom är den relativt beräkningskraftig d˚a det är ett 16-bitarssystem jämfört med till exempel AVR som är 8 bitar och därför kräver fler cykler för tyngre beräkningar.

Tillg¨angliga arkitekturer f¨or TinyTimber.

ARM7

AVR 8-bitars GBA

M16C MIPS MSP430 PIC18

Tabell 3.1: Arkitekturer som st¨ods av TinyTimber-k¨arnan [19]

(28)

3.2. Val av komponenter 15

Ett utvecklingskort MSP430P1611, se figur 3.1, k¨optes in fr˚an Olimex [21] bestyckad med en

MSP430F1611 processor. Denna processor har tillg˚ang till relativt mycket minne, tv˚a UART moduler, Universal Asynchronous Receiver/Transmitter, som utöver seriell kommunikation kan konfigureras att köra SPI, Serial Peripheral Interface [22], eller I²C , Inter-Integrated Circuit [23]. Den har dessutom tillg˚ang till ˚atta olika analoga ing˚angar, ADC pinnar, 16 olika externa interrupting˚angar och utöver detta en hel del generella utg˚angar. För utvecklingen av ”proof of concep”-enheten valdes det att fortsätta med MSP430f1611-processorn d˚a all kod var skriven specifikt för denna processor och att den dessutom kommer med mycket minne tillgängligt utan att behöva lägga till externa komponenter.

Figur 3.1: Utvecklingskortet fr˚an Olimex [21], som anv¨ants vid diverse tester.

3.2.2 Accelerometer

Enligt specifikationerna skulle en accelerometer med tre axlar och som kunde sampla i minst 100 Hz användas. Här finns det tv˚a olika vägar att g˚a, i det första tillvägag˚angssättet används en analog accelerometer och mätningar p˚a spänning den avger sker med mikroprocessorns inbyggda ADC; Analoga till Digital Converter. Det andra alternativet är att använda en digital accelerometer som kommunicerar digitalt med mikroprocessorn vanligtvis via SPI, Serial Peripheral Interface [22], eller I²C , Inter-Integrated Circuit [23]. Fördelen med den analoga accelerometern är att det är ganska lätt att f˚a information fr˚an den när väl ADC fungerar p˚a mikroprocessorn, vilket ofta är en enkel bit att

(29)

komma ig˚ang med. Nackdelen är dock att dessa tar mer ström än en digital. De digitala accelerometrarna är strömsn˚ala och allt som oftast har de inbyggda funktioner som kan underlätta mätningar, till exempel översamplings-buffertar, buffertar för att spara undan värden s˚a att avläsningar inte behöver ske lika ofta etcetera. Dessutom har de ofta ett ställbart mätintervall vilket underlättar d˚a information om maximala krafterna är okända. Nackdelen med de digitala accelerometrarna är att de brukar vara dyrare än de analoga.

Efter övervägande av ovanst˚aende och med tanke p˚a att systemet ska vara s˚a strömsn˚alt som möjligt för att kunna f˚a längre batteritid valdes en digital accelerometer. I detta fall mer specifikt ADXL345 för att denna är en av de mest strömsn˚ala och stödjer b˚ade I²C och SPI, se [24]. Den samplar dessutom i hastigheter mellan 6.25 till 3200 Hz vilket uppfyller kraven p˚a de 100 Hz som eftersträvades.

3.2.3 Bluetooth

Som tr˚adlös modul skulle Bluetooth användas och eftersom detta examensarbete hade ganska begränsad tillg˚ang av tid s˚ags ingen möjlighet till att skriva en hel Bluetooth- stack till mikroprocessorn för kommunikationen. Därför bestämdes det ganska fort att en Bluetooth-enhet med inbyggt dito skulle användas. En annan fördel med att använda färdiga produkter är att enheten annars inte f˚ar användas utanför labbmiljöer före den har blivit CE-godkänd. Enheten bör stödja SPP d˚a detta är ett av de lättaste sätten att kommunicera över Bluetooth. kommunikationsmodulen ska även stödja kommunikation med mikroprocessorn antingen via ett av de tidigare nämnda protokollen I²C, SPI eller ocks˚a seriell kommunikation,UART (Universal Asynchronous Receiver/Transmitter).

Tv˚a enheter fr˚an Roving Networks fanns tillgängliga som hade stöd för de funktioner som behövdes, RN-41 [25] och RN-42 [26]. Vid prototypbygge användes RN-41 d˚a denna gick att f˚a tag i färdigmonterad p˚a ett mönsterkort med alla utg˚angar till stiftlister, för att underlätta kopplingar till bland annat ett utvecklingskort. Vid ”proof of concept”- enheten användes den senare, RN-42, d˚a denna är mer strömsn˚al men dock har lite kortare räckvidd, RN-41 har ca 100 meter medans RN-42 cirka 10 meter. Om mer räckvidd senare skulle behövas, vilket är ganska osannolikt d˚a telefonerna inte har s˚a l˚ang räckvidd,

är b˚ada enheterna pin-kompatibla vilket medför att det g˚ar använda b˚ada enheterna p˚a det utvecklade mönsterkortet.

(30)

3.2. Val av komponenter 17

3.2.4 Str ¨ omf ¨ ors ¨ orjning

Eftersom enheten ska vara tr˚adlös valdes ett batteri som strömförsörjning. För att förenkla användningen av enheten s˚a används ett uppladdningsbart batteri och en laddningskrets p˚a kortet. För att f˚a s˚a l˚ang batteritid som möjligt med ett litet batteri bestämdes det att ett Litium-polymer batteri skulle användas. Dessa batterier har en av det högsta energi-densiteterna av dagens batterier och har dessutom väldigt l˚ag självurladdning.

Li-Po-batterier har dock nackdelar däribland att de lätt kan g˚a sönder om de under- laddas/överladdas och om inte laddning sker p˚a korrekt sätt kan brand uppst˚a. Därför valdes ett batteri med inbyggd över- och underspänningsskydd samt överströmsskydd.

För att ladda batteriet valdes en färdig laddkrets som under laddningsförloppet mäter spänningen p˚a batteriet och följer sin laddningsalgoritm utefter detta. Den specifika laddningskretsen som valdes var MCP73831 fr˚an Microchip, [27]. Denna laddningskrets är väldigt billig, liten, kräver f˚a andra komponenter för att fungera och har stöd för laddning via USB. För att lätt kunna stödja laddning s˚a valdes ing˚angen till en micro-USB kontakt. Micro-USB valdes därför att alla dagens mobiltelefoner i EU ska stödja laddning via denna port vilket medför att de flesta har tillg˚ang till en s˚adan sladd.

D˚a mikroprocessorn, accelerometern och Bluetooth-enheten bör drivas med spänningar mellan 3,0-3,3V och batteriet levererar 3,7V i nominalspänning s˚a m˚aste denna spänning regleras. Detta görs mest effektivt via en LDO-regulator, Low Dropout, i detta fall en TPS76933DBVT fr˚an Texas Instruments som reglera spänningen till 3,3V. För att vara p˚a den säkra sidan d˚a de gällde Bluetoothkommunikationen valdes regulatorspänningen till 3,3V men enheten skall enligt specifikation, se [25], klara ner till 3,0V.

Utöver dessa komponenter lades en MOSFET, en spänningsstyrd transistor, till. Denna hade som uppgift att stänga av strömmen till Bluetooth-modulen utifall att batteriet skulle f˚a för l˚ag spänning. Detta för att inte ladda ur batteriet allt för fort vid l˚aga spänningar. Se appendix C för mer detaljer om hur detta gjordes.

3.2.5 Lysdioder

För att kunna f˚a information direkt till användaren fr˚an kortet används tv˚a lysdioder, Light emitting diodes (LEDs), men ocks˚a en RGB-LED, röd grön bl˚a LED. De tv˚a vanliga lysdioderna används till att visa Bluetooth-modulens status. Den första visar direkt om Bluetooth-modulen är uppkopplad mot n˚agot eller inte och den andra vilken status modulen har genom att blinka i olika frekvenser. RGB-LEDen som egentligen bara

är tre lysdioder i samma skal används för att visa batteristatus. Grön d˚a batteriet laddas.

(31)

När batteriet inte laddas mäts spänningen för att kunna avgöra hur mycket batteri som finns kvar. Vid nära nog fullt lyser dioden bl˚att, vid halv fullt batteri lyser den lila och när det är nära slutet lyser den rött, se tabell 4.1 för en sammanställning. Alla dess LEDs är kopplade till mikroprocessorn s˚a man vid behov kan byta ut funktionerna de har. De är kopplade s˚a att katoden g˚ar till processorn via ett motst˚and och matning hela tiden ligger p˚a via anoden, se appendix C.4. Detta kan kännas lite bakvänt d˚a en hög utsignal fr˚an mikroprocessorn kommer ge en släckt diod medan en l˚ag utsignal kommer tända dioden. Hade inte dioden tänts p˚a detta sätt hade en transistor behövt användas d˚a processorn inte orkar driva den ström som skulle behövas men den klarar däremot att ta emot betydligt högre strömmar. Att lägga till transistorer hade b˚ade ökat priset, komplexiteten och utrymmet av prototypen s˚a när det är s˚a enkelt att lösa p˚a annat sätt var det aldrig ett alternativ.

3.3 Proof of concept-modul

För att f˚a produkten mindre och mer användbar till tester utvecklades en ”proof of concept”-enhet. Denna enhet har som m˚al att vara s˚a liten och smidig som möjligt men samtidigt vara relativt enkel att löda och mäta saker p˚a. För att programmera MSP430f1611-processorn behövs en JTAG-kontakt, Joint Test Action Group. Denna kontakt best˚ar av vanliga ”pin-headers” i en matris p˚a 2x10 pinnar. Med 2.54 mm mellan varje ben betyder det att bredden p˚a kortet m˚aste vara ˚atminstone 25.4mm vilket är aningen stort. Dessutom om fler utg˚angar för diverse mätningar skulle behövas s˚a m˚aste fler pinnar till vilket kommer öka storleken p˚a antingen längden eller bredden av kortet.

För att f˚a ut s˚a m˚anga signaler som möjligt valdes därför att istället satsa p˚a en kortkontakt, s˚a kallad card edge. Den modell som valdes var samtec MEC1 [28] , vilken har cirka 1 mm mellan varje utg˚ang. MEC1 har dessutom utg˚angar p˚a b˚ada kortsidorna och är polariserad s˚a det inte g˚ar ansluta kortet fel. För att kunna använda denna kortkontakt skapades ett dotterkort, se kapitel 3.3.1. kortkontakten satte dock även den begränsningar p˚a bredden för prototypen. Dessutom lägger denna kontakt p˚a ganska mycket p˚a längden d˚a den har ett stort ”jack” för att skapa polariseringen, se figur 3.2. Bluetooth-modulen

är annars den enskilt största komponenten och skulle förmodligen sätta begränsningen p˚a storleken om en mindre processor, d˚a det finns betydligt mindre processorer i MSP430 serien, och mindre komponenter i allmänhet hade valts.

För att underlätta tillverkningen av ”proof of concept”-enheten designades ett mönsterkort, printed circuit board (PCB), i CAD-programmet EAGLE [29] vilket är ett program specifikt för att designa mönsterkort. B˚ade huvudkortet, se appendix C.1, och dotterkortet, se appendix D, designades i detta program. För att spara tid och undvika problem som kan uppst˚a när man etsar kort själv beställdes korten fr˚an en tillverkare. Eftersom till-

(32)

3.3. Proof of concept-modul 19

Figur 3.2: Det färdiga mönsterkortet där kortkontakten är p˚a vänstra sidan.

verkningen av korten skulle göras av ett externt företag gjordes kortet p˚a tv˚a lager. Detta eftersom leveranstiden kunde h˚allas kort, de är billigare att beställa prototyper p˚a tv˚a lager och att storleken inte var av största vikt i detta skede. Hade däremot storleken och massproduktion varit ett m˚al hade det funnits större motiv att överg˚a till ˚atminstone fyralagers kort.

3.3.1 Dotterkort

För att kunna programmera ”proof of concept”-enheten lades en s˚a kallad kortkontakt till. Med hjälp av denna kan de nödvändiga utg˚angarna för programmering via JTAG, Joint Test Action Group, f˚as till ett dotterkort, se figur 3.3. P˚a detta dotterkort kan andra nödvändiga utg˚angar ocks˚a f˚as för externa mätningar eller andra sorters test om de skulle behövas. För ett kopplingsschema och bilder p˚a layouten se appendix D.

(33)

Figur 3.3: Dotterkort f¨or anslutning av sensorkortet och en JTAG.

3.4 Sammanfattning

Till en b¨orjan testades alla komponenter tillsammans med hj¨alp av ett utvecklings kort.

Dessa komponenter anv¨andes senare vid bygget av ”proof of concept”-enheten. De huvudsakliga komponenterna som anv¨andes var:

MSP430f1611 Mikrokontroller som har den fina egenskapen att vara str¨omsn˚al.

RN-42 Bluetooth-enhet med inbyggd Bluetooth-stack.

ADXL345 Digital accelerometer som ¨ar str¨omsn˚al.

Strömförsörjning Best˚ar av lite olika delar för att kunna ge en jämn ström men ocks˚a för att kunna ladda enheten vid behov.

Li-Po batteri Batteri med relativt h¨og energidesitet.

MCP73831 Laddningskrets f¨or Li-Po-batterier. Tar str¨om fr˚an en micro-USB port.

TPS76933DBVT , reglerar sp¨anningen fr˚an batteriet till 3.3V.

Lysdioder F¨or status av Bluetooth och batteriets h¨alsa.

En blockdiagram ¨over de signalerna och protokoll som anv¨ands mellan de olika komponenterna kan ses i figur 3.4

(34)

3.4. Sammanfattning 21

Figur 3.4: Blockdiagram ¨over kommunikationssignaler mellan de olika komponenterna.

För fullständig komponentlista se appendix A, för kopplingsschema och layout C.1 re- spektive D.1.

(35)

(36)

K APITEL 4 Mjukvara

I detta kapitel kommer utvecklingen av programkoden f¨or b˚ade Android-telefoner och f¨or kodningen av mikroprocessorn MSP430 att behandlas.

4.1 Sensorkortet

För att enkelt kunna samla information fr˚an en accelerometer och dessutom kunna skicka meddelande behövs n˚agon sorts inbyggd ”intelligens”. För att kunna göra detta direkt p˚a ett litet smidigt kort används en mikrokontroller. Dessa finns i väldigt m˚anga olika storlekar, snabbhet och funktioner. För ändam˚alet som diskuteras i denna rapport används en MSP430 mikrokontroller som är relativt strömsn˚al och dessutom har m˚anga olika funktioner tillgängliga.

4.1.1 Utvecklingsmilj ¨ o

För att programmera mikroprocessorer används för det mesta programmeringsspr˚aket C och s˚a även i detta fall. För att underlätta programmeringsdelen används en IDE, ”In- tegrated Development Environment”, eller p˚a svenska integrerad utvecklingsmiljö. En ofta använd miljö till diverse olika programmeringsspr˚ak är Eclipse [30] d˚a den är gratis och relativt enkelt att skriva plugins till. I detta fall användes Eclipse tillsammans med en verktygskedjan MSPGCC [31], vilket bland annat inneh˚aller kompilator för MSP430

23

(37)

serien. Detta tillsammans med MSPdebug [32] gör det möjligt att b˚ade programmera processorn men även att debugga den via JTAG-gränssnittet. För installationsinstruk- tioner av dessa verktyg i Eclipse användes en färdig guide [33]. Ett annat alternativ till detta som eventuellt kunnat förkorta uppstarten av projektet hade varit att använda IAR Embedded Workbench, [34]. Detta har dock sina nackdelar i att den finns i antingen en betalversion, som förvisso g˚ar att köra i 30 dagars test version, eller köra en gratis version som begränsar programstorleken.

4.1.2 Reaktiv programmering

För att kunna spara ström behöver processor g˚a i viloläge s˚a ofta som möjligt. Det- ta görs enklast genom att använda s˚a kallad reaktiv programmering, ocks˚a känt som händelsestyrd programmering. Kortfattat innebär detta att processorn alltid sover utom vid tillfällen d˚a de finns olika händelser som är inplanerade eller vid externa interrupt.

För att kunna skriva reaktiva program behövs en kärna, ett operativsystem, att bygga sina program runt. I detta fall användes en ”realtidskärna” utvecklad p˚a Lule˚a tekniska universitet, LTU, vid namn TinyTimber. Fördelen med att använda denna realtidskärna istället för en av de m˚anga andra som finns var till största delen att hjälp var lättillgänglig d˚a utvecklarna fanns tillgängliga p˚a universitetet för fr˚agor. Utöver detta tar TinyTimber, förkortat tT, relativt liten plats jämfört med andra kärnor och det har väldigt hög noggrannhet p˚a hur precist de schemalagda hädelserna kan utföras enligt en undersökning av Lindgren et al [19]. För lite mer information och exempel p˚a hur TinyTimber har används finns till exempel i ett licentiat skriver av Johan Eriksson [35].

En annan fördel med att använda tT är att det redan fanns fördefinierad inställningar specifikt för processorn MSP430f1611 som användes i projektet. Detta medförde att bland annat UART-inställningar, klockinställningar etcetera var förinställda. Allt detta hade dock redan gjorts i syfte att lära sig om MSP430 arkitekturen innan en kärna skulle användas, dels för att det underlättar att kunna systemet om problem skulle uppst˚a men ocks˚a för att veta att allt fungerar utan kärnan till en början.

4.1.3 Basfunktioner

För att systemet skall vara lättare att använda och samtidigt ge ett bättre intryck är det bland annat bra att ge lite information till användaren av produkten. Här ing˚ar till exempel att visa att enheten är uppkopplad mot en annan enhet eller att den väntar p˚a att n˚agon ska försöka ansluta. Bluetooth-modulen som använts, RN-42 [26], i ”proof of

(38)

4.1. Sensorkortet 25

concept”-enheten har utg˚angar för att visa b˚ada dessa statusar och dessa användes till att trigga en interrupt i mikroprocessorn s˚a att denna kan styra indikationen. Information om att enheten inte är kopplad kan bland annat utnyttjas till att försöka para med en förutbestämd enhet etcetera.

Annan information som ocks˚a är lätt att visa via lysdioder och framförallt nyttig att ha för användaren är batteristatus. Detta löstes genom att använda mikroprocessorns inbyggda analoga till digitala omvandlare, ADC (Analog to Digital Converter). ADCn i mikroprocessorn kan dock bara mäta upp till samma spänningen som processorn drivs med, i detta fall 3,3V, och d˚a batteriets nominalspänning ligger p˚a 3,7V m˚aste en spänningsdelare användas. Spänningsdelaren valdes att halvera spänningen s˚a den mätta spänningen är hälften s˚a stor som den verkliga, se formel 4.1 för uträkning av batterispänningen utifr˚an uppmätta spänningen. I formeln är Vmatning matningen till mikroprocessorn p˚a 3,3V och ADC_v¨_arde är det momentana värdet som mätts medans ADC_max är de maximala värdet.

ADC_max var i det här fallet 4095 d˚a mätningarna gjordes med hjälp av en 12-bitars ADC. Denna information visades sedan p˚a en flerfärgad lysdiod, RGB-LED, genom att lysa i olika färgkombinationer, se tabell 4.1. Information om batteriet laddas tas direkt via en interrupt ing˚ang fr˚an laddningskretsen vilken har en anpassad utg˚ang just för detta ändam˚al.

V_bat =ADC_v¨_arde∗ 2 ∗ V_matning ADC_max

=ADC ∗ 2 ∗ 3, 3 4095

(4.1)

Batteristatus F¨arg p˚a RGB-LED

Laddar Gr¨on

>90% Bl˚a

<90% och >25% Lila

<25% R¨od

Tabell 4.1: Tabell för att avläsa batteristatus utifr˚an RGB-LEDens färg.

4.1.4 Kommunikation

För att kunna skicka data över Bluetooth användes i detta fall det digitala kommuni- kationsprotokollet UART, som diskuterats i kapitel 3.2.3. Eftersom mikroprocessorn har

(39)

en inbyggd UART-enhet handlar programmeringen av UART om att ställa in kommu- nikationsfrekvenser och sedan skicka data till enheten som representeras av ett register s˚a sköter mikroprocessorn kommunikationen. Detta underlättades en hel del av att det dessutom fanns färdiga ”drivrutiner” för detta inbyggt i TinyTimber-kärnan vilket kunde användas som exempel innan kärnan användes fullt ut.

För att avläsa informationen fr˚an accelerometern fanns tv˚a protokoll att välja mellan, SPI och I²C. SPI [22] har fördelen att det stödjer högre överföringshastigheter medans I²C [23] har fördelen att färre ledare behövs. Utöver detta stödjer I²C adressering med förinställda adresser om flera enheter skulle användas i samma kedja medan SPI behöver en ing˚ang p˚a varje enhet som säger om enheten ska användas, en s˚a kallad ”chip select ing˚ang”. Med fördelen att I²C kräver färre ledare och att de högsta hastigheterna inte var av större vikt började implementering av I²C att ske. Efter försök att implementera I²C hittades en errata till MSP430F1611-processorn , [36]. Med hjälp av denna kunde ett tiotal fel p˚a I²C-enheten konstateras och det beslutades d˚a att SPI var ett bättre alternativ.

SPI-kommunikationen var lätt att f˚a ing˚ang när väl protokollet förstods. Ett problem som orsakades av detta var d˚a avläsning av data skulle ske. Detta kräver p˚a MSP430- enheten att, efter registervärdet som skall avläsas skickats, denna skickar n˚agot ut˚at för att starta klocksignalen som tillhandah˚alls av mikroprocessorn. Klocksignalen behövs för att accelerometern skall kunna skicka tillbaka data och när inte detta gjordes korrekt returnerade accelerometern aldrig n˚agon data.

4.2 Programmering av smartphone

I denna sektion kommer programmeringen av en enkel säkerhetsapplikation att diskuteras. Idén med denna applikation är att när ett speciellt meddelande tas emot över Bluetooth fr˚an sensorenheten skall ett SMS, Short Message Service, med platsangivel- se skickas till ett nödnummer som anges i applikationens inställningar. Denna position hämtas i bästa fall fr˚an en GPS, Global Positioning System, som de flesta av dagens smartphones har inbyggt. Finns ingen GPS-data att hitta, vid till exempel d˚alig mottag- ning, s˚a används en uppskattad position utifr˚an mobilnätet. Den information som erh˚alls sl˚as sedan upp emot en karta vilket ger en adress som är lättare att först˚a för en mänsklig mottagare.

(40)

4.2. Programmering av smartphone 27

4.2.1 Val av plattform

P˚a dagens smartphonemarknad finns ett antal operativsystem att v¨alja p˚a. De vanligaste

är i skrivande stund iOS, Android och Symbian där de tv˚a förstnämnda är de betydligt vanligaste [37, 38]. Symbian är ett operativsystem som mer eller mindre har övergivits av de stora mobiltelefontillverkarna idag och är därför inte en av de bättre plattformarna att satsa p˚a.

För att utveckla applikationer till en iPhone, som kör iOS, behövs tillg˚ang till en Mac- dator, som egentligen är en PC specialanpassad för Apples egna operativsystem MAC OS X. En licens för att f˚a tillg˚ang till Apples utvecklingsprogram för iOS-enheter m˚aste köpas, kostar$99, och dessutom m˚aste en iPhone,Ipad eller iPod touch finnas tillgänglig.

Ut¨over detta st¨aller Apple krav p˚a vilka Bluetooth-enheter som f˚ar paras med enheten.

Detta gör det sv˚art att p˚a prototypniv˚a testa Bluetooth-kommunikation med en IOS enhet eller s˚a sätts restriktiva krav p˚a vilka färdiga Bluetooth-enheter som g˚ar använda.

Android som är en av de mest använda operativsystemet har fördelen att all kod är

öppen och att komma ig˚ang med programmeringen g˚ar fort, inte ens en enhet behövs d˚a emulator g˚ar använda till att testa de flesta applikationer. Nackdelen med Android är däremot att enheterna är ganska segmenterade, det vill säga att det finns m˚anga olika enheter med mycket skillnader i h˚ardvara vilket kan medföra strul om bak˚atkompatibilitet till äldre versioner av Android skall stödjas. För applikationen som är tänkt användas mot sensor-noden är detta inte ett problem d˚a varken höga krav p˚a prestandan eller höga krav p˚a utseendet av appen behövs. Utöver detta är m˚alet med detta exjobb att utöka Neavas säkerhtsapplikationer som i dag är gjorda till Android-enheter. Allt detta tillsammans med att en enhet redan ägdes av rapportskrivaren gjorde valet föll p˚a Android som plattform.

Ar m˚¨ alet en slutgiltig produkt bör en satsning dock göras för att ˚atminstone kunna köra applikationen p˚a b˚ade iPhone och Android för att n˚a ut till den breda massan. Det är inte heller en nackdel att n˚a fler segment som till exempel Windows Mobile som idag är p˚a frammarsch.

4.2.2 Utvecklingsmilj ¨ o

Aven h¨¨ ar, som vid MSP430 programmeringen, användes Eclipse som utvecklingsmiljö men istället för spr˚aket C s˚a användes Java. Tillsammans med Androids egna SDK, Software Development Kit, finns alla tillgängliga API:er, Application Programming In- terface, för Android-enheter tillgängliga. Denna SDK ger även tillg˚ang till en emulator

(41)

för att simulera en enhet direkt p˚a datorn för att lättare kunna felsöka eller när ingen telefon finns att tillg˚a. Denna funktion är dock inte optimal vid programmering och tester av mobiltelefonernas Bluetooth-modul d˚a emulatorn inte kan simulera Bluetooth- kommunikation och därmed alltid skapar en applikationskrasch. Detta löstes mycket lätt genom att alla tester och debuggningar enkelt kan köras fr˚an utvecklingsmiljön direkt p˚a en fysisk enhet.

4.2.3 Anv ¨andargr ¨anssnitt

Eftersom den tänkta trygghetsapplikationen skall ligga och vänta p˚a ett Bluetooth- meddelande och i detta fall utlösa ett alarm s˚a är behovet av ett användargränssnitt ganska litet. Det som behövs är en inställningsmeny, n˚agonstans att ställa in uppkopp- lingen mot Bluetooth-enheter och en vanlig knapp som startar applikationen.

Fr˚an den enkla huvudskärmen g˚ar det med hjälp av menyknappen, h˚ardvaruknappar p˚a alla Android-enheter som kom innan Android version 4.0 och därefter mjukvaruknapp, snabbt och enkelt att n˚a en meny, se figur 4.1a. Denna meny ger tillg˚ang att ansluta till/koppla fr˚an en Bluetooth-enhet eller göra inställningar. Används knappen för att ansluta en Bluetooth-enhet listas tillgängliga enheter som g˚ar att ansluta till, se figur 4.1b. Inställningsknappen leder vidare till en inställningsskärm, se figur 4.1c, där bland annat mottagarens telefonnummer g˚ar knappa in. Här g˚ar även att välja om den inbyggda GPS:en ska användas eller inte.

4.2.4 Bluetooth-kommunikation

För att snabbt och enkelt komma ig˚ang med Bluetooth-kommunikationen i Android användes ett kodexempel vid namn Bluetoothchat [39]. Detta exempel behövde dock modifierades en aning för att kunna stödja bland annat SPP.

I grund och botten skapas en egen tr˚ad för Bluetooth-kommunikationen s˚a att framförallt inte användargränssnittet tappar kapacitet och blir okontaktbart. Skulle användar- gränssnittet vara okontaktbart en längre stund, en längre stund är för Androidsystemet cirka 5 sekunder, kommer operativsystemet automatiskt stänga ner applikationen d˚a det anser att programmet har hängt sig. Denna tr˚ad bevakas sedan av huvudtr˚aden för att kunna uppdatera olika statusfält som till exempel om n˚agon enhet h˚aller p˚a att kopplas upp, är uppkopplad eller om den är fr˚ankopplad. Bevakningen av Bluetooth-tr˚aden tar

även emot meddelandena, som i sin tur kommer fr˚an en annan Bluetooth-enhet, och utifr˚an detta bestäms vad som skall göras (till exempel sl˚a p˚a larmet).

(42)

4.2. Programmering av smartphone 29

(a) Huvudskärmen med me- nyfältet öppnat.

(b) Skärm över möjliga enheter att ansluta till.

(c) Inst¨allningsmenyn.

Figur 4.1: Skärmdumpar fr˚an användargränssnittet av den utvecklade applikationen

4.2.5 Alarm

När ett förutbestämt meddelande tas emot av Bluetooth-tr˚aden, se kapitel 4.2.4 för mer information, skall ett larm utlösas. Detta larm har i uppgift att b˚ade meddela personer i omgivningen om att n˚agot har hänt och att kontakta närst˚aende via SMS, Short Message Service, med platsbeskrivning med mera.

För att meddela omgivningen att n˚agot har hänt används en alarmsignal. Denna startas i en egen tr˚ad för att inte belasta användargränssnittet d˚a ljud spelas upp.

P˚a samma sätt som ljudtr˚aden skapas en tr˚ad för att skicka SMS. Denna tr˚ad börjar med att kolla om GPS:en är tillgänglig och om den är detta börjar den söka efter satelliter.

Finns inte GPS:en tillgänglig eller om det tar för l˚ang tid att hitta en GPS-signal, satt till 30 sekunder vid test, s˚a används istället telefonnätet för att uppskatta en position.

Oavsett vart ifr˚an positionsdatat kommer ifr˚an s˚a används det för att sl˚a upp en platsbeskrivning som är lättare för en människa att först˚a. I detta fall användes Androids inbyggda API för ”Geocoding” [40]. Denna fungerar s˚a att med hjälp av en adress g˚ar det att hämta ut latitud och longitud eller som i denna applikation hämta ut en adress

(43)

eller platsbeskrivning utifr˚an latitud och longitud.

B˚ada de h¨ar tr˚adarna kan anv¨andaren stoppa, till exempel vid oavsiktlig aktivering.

Detta g¨ors via en knapp i applikationen.

(44)

K APITEL 5 Utv ¨ardering

I detta kapitel tas resultaten av de olika delarna upp d¨ar b˚ade det som fungerar och det som har varit problem tas upp.

5.1 H ˚ardvara

D˚a h˚ardvaran nästan uteslutande hade testats p˚a en labbkort innan designen för mönsterkortet gjordes fungerade de mesta smärtfritt direkt efter att allt hade blivit monterat p˚a det designade kortet. En sak som inte fungerade som det var tänkt var den MOSFET som skulle kunna stänga av Bluetooth-enheten. Detta berodde p˚a att fel variant av MOSFET hade valts och denna byttes snabbt ut fr˚an en N- till en P-kanals MOSFET, en N-kanals MOSFET hade givetvis g˚att använda men hade behövt vara p˚a jordsidan av Bluetooth- enheten. Efter detta byte fungerade allt p˚a kortet i enlighet med specifikationerna. I figur 5.1 kan det monterade kortet ses.

31

(45)

(a) ¨Oversidan p˚a kortet med batteriet liggandes bredvid. (b) Undersidan p˚a kortet.

Figur 5.1: Monterad ”proof of concept”-enhet.

5.2 Mjukvara

5.2.1 Android

Applikationen som programmerades till Android-telefonen fungerade som det var t¨ankt.

Eftersom algoritmen för rörelseigenkänning aldrig gjordes i C s˚a utfördes tester som istället för att larma vid specifika rörelser larmade vid ett klick p˚a accelerometern. Detta utlöste en alarmsignal som skickades till Androidapplikationen via Bluetooth och som i sin tur startade SMS-tjänsten. SMS-tjänsten i sin tur hämtade GPS-data, om GPS var vald, och slog upp adressen som motsvarar positionen. Om en GPS-signal inte fanns tillgänglig eller enheten inte var vald hämtades en approximerad position utifr˚an telefonnätet som

¨aven denna slogs upp korrekt mot en verklig adress. Det senare fallet ger dock en v¨aldigt approximerad position men denna information inkluderas i det skickade SMS:et.

(46)

5.3. R¨orelsealgoritm 33

5.2.2 MSP430

Att skicka data över Bluetooth-enheten gick snabbt att komma ig˚ang med d˚a det enda som krävdes var en fungerande UART-kommunikation. Efter att länge ha försökt hämta data fr˚an accelerometern över I²C-protokollet upptäcktes det att de fanns ett tiotal h˚ardvarufel i mikroprocessorn som gjorde att den inbyggda I²C-modulen i stort sett var obrukbar. Det fanns d˚a tv˚a alternativ som innebar att antingen använda en vanlig port och simulera I²C-protokollet via detta eller överg˚a till SPI. Det senare valdes d˚a detta medför att betydligt högre överföringsfrekvenser kan uppn˚as och att den inbyggda SPI- enheten kunde ta hand om det inkommande paketet. Efter detta problem var löst var de i stort sett inga problem med programmeringen av MSP430 plattformen.

Efter allt ovan var testat beslutades att en realtidsk¨arna skulle k¨oras p˚a processorn.

Detta för att spara energi när inget körs, det vill säga g˚a ner i vila, och för att kunna schemalägga händelser s˚a de utförs regelbundet. För att göra detta valdes, som nämnts i tidigare kapitel 3.2.1, TinyTimber-kärnan. Detta skapade en del problem d˚a den senast använts p˚a en MSP430-plattform var av utvecklaren för cirka 4 ˚ar sedan. Vilket medförde att bland annat Watchdog-funktionen, en säkerhetsfunktion som ˚aterställer processorn till dess utg˚angsläge om den inte ˚aterställs med jämna mellanrum, fick stängas av för att inte störa kärnan.

5.3 R ¨ orelsealgoritm

För att testa om rörelseklassificeringsalgoritmen fungerade som det var tänkt implementerades den i MATLAB [16], där även ett skript för att ta emot data över Bluetooth implementerades. Detta underlättade en hel del d˚a accelerometerdata samt alla beräknade storheter lätt kunde ˚ask˚adliggöras i diverse grafer. Utöver detta kunde all data sparas ner för senare tester om det skulle behövas.

För att data lätt skulle kunna skickas till MATLAB skrevs ett program till sensornoden som tar emot data fr˚an accelerometern och sedan omvandlar de hexadecimala talen till en sträng i ASCII formatet. Denna sträng omvandlas i sin tur fr˚an det hexadecimala värdet till en decimal representation av g-krafter i MATLAB efter att detta skript mottagit strängen över Bluetooth.

(47)

5.3.1 Datainsamling

F¨or att kunna testa den implementerade algoritmen gjordes ett antal olika m¨atningar.

Dessa mätningar g˚ar i grund och botten ut p˚a att upptäcka olika rörelsemönster som till exempel att resa sig, kallat ”sitta till st˚a” i figuren 5.2. Vid mätningarnas början har redan testpersonen intagit den korrekta startpositionen. Efter cirka fem sekunder g˚ar personen fr˚an första läget till det andra. Under rörelsen för att byta position förväntas n˚agon slags kortvarig aktivitet att detekteras. I figur 5.2 kan alla olika rörelsetester och hur de detekteras ses, sekundangivelserna är inte alltid s˚a exakta utan ska ses som en riktlinje.

Figur 5.2: Förväntat resultat för de olika rörelsemönstren när ett positionsbyte sker vid tiden 5 sekunder.

För att överhuvudtaget ha n˚agot resultat att analysera utfördes ett antal tester p˚a alla olika ”rörelsemönster”. Dessa test utfördes dock bara p˚a en person, d˚a tiden var väldigt begränsad, men eftersom bland annat ref [11, 15, 13] har gjort tester p˚a samma eller mycket liknande algoritmer s˚a fanns änd˚a en del resultat att jämföra emot. För att däremot testa olika sorters rörelser gjordes de flesta test i olika varianter. Att g˚a fr˚an st˚aende till sittande gjordes genom att försökspersonen satte sig olika varianter av b˚ade stolar och f˚atöljer med varierande höjd och mjukhet. Att falla gjordes fr˚an diverse olika

(48)

positioner, som till exempel vid st˚aende och sittande, ner p˚a olika mjuka material men ocks˚a direkt ner p˚a golvet.

I figur 5.2 visas även hur rörelsemönstret ”g˚a” kan upptäckas men detta är inte rik- tigt sant d˚a det som görs är att upptäcka l˚angvariga användaraktiviteter, det vill säga rörelsemönstret ”g˚a” uppst˚ar d˚a 4 p˚a varandra följande användaraktiviteter har upptäckts.

För att verkligen kunna se om en person g˚ar bör mer analys ske p˚a de olika kroppskom- ponenterna fr˚an accelerometern, detta gjordes dock aldrig i brist p˚a tid men ocks˚a d˚a det inte ans˚ags ha ett viktigt användningsomr˚ade.

Utöver dessa test gjordes en del tester för att försöka utlösa en fall-signal. En rad upp- repade hopp, relativt höga, fick en fallindikation att uppst˚a. Utöver detta var det inga

”vanliga” rörelser som lyckades att f˚a ett s˚adant larm att uppst˚a. Dessa tester utfördes fortfarande bara ut av en person. Fler tester med andra personer i olika ˚aldersgrupper skulle behövas för att kunna dra en tydlig slutsats av detta. Detta gjordes dock aldrig d˚a det inte rymdes i tidsplanen för detta projekt men ocks˚a för att det skulle behövas ett godkännande av etikprövningsnämnden [41] för att f˚a genomföra testerna.

5.3.2 Datasammanst ¨allning

Som nämnts ovan gjordes en rad olika tester och dessutom användes en hel del olika objekt vid de olika testerna. I figur 5.3 kan datainsamling vid ett simulerat fall ses. I figur 5.4 kan datainsamling d˚a ett rörelsemönster fr˚an st˚aende till sittande har utförts. I den senare figuren kan man se att den upprätta aktiveten upptäcks ett tag efter att den skett i verkligheten , g˚ar att se om x-,y- och z-axelns acceleration besk˚adas. Detta beror p˚a sekund till sekund”implementationen som gör att vid nästa helsekund beräknas ett nytt SMA-värde och eventuellt utlöser som en aktiv rörelse.

En sammanställning av alla tester gjorda av försökspersonen kan ses i tabell 5.1.

(49)

R¨orelsem¨onster Antal test Antal korrekta test Noggrannhet (i %)

Sitt till St˚a 23 21 91.3

St˚a till Sitt 24 23 95.8

Sitt till Ligg 20 20 100

Ligg till Sitt 20 20 100

Olika positioner, liggandes 20 20 100

F¨orflytta sig 15 13 86.7

Fall 16 16 100

Totalt 138 133 96.4

Tabell 5.1: Tabell ¨over gjorda m¨atningar och deras utfall.

Figur 5.3: Insamlad data och ber¨aknade variabler d¨ar ett fall har skett efter cirka 5 sekunder.

(50)

Figur 5.4: Insamlad data och beräknade variabler där en person har rört sig fr˚an st˚aende till sittande position.

(51)

Trådlös trygghetslarm för en Androidenhet