Dotterkort

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

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¨omf¨ors¨orjning Best˚ar av lite olika delar f¨or att kunna ge en j¨amn str¨om men ocks˚a f¨or 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 kompo-nenterna kan ses i figur 3.4

3.4. Sammanfattning 21

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

F¨or fullst¨andig komponentlista se appendix A, f¨or kopplingsschema och layout C.1 re-spektive D.1.

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¨or att enkelt kunna samla information fr˚an en accelerometer och dessutom kunna skicka meddelande beh¨ovs n˚agon sorts inbyggd ”intelligens”. F¨or att kunna g¨ora detta direkt p˚a ett litet smidigt kort anv¨ands en mikrokontroller. Dessa finns i v¨aldigt m˚anga oli-ka storleoli-kar, snabbhet och funktioner. F¨or ¨andam˚alet som diskuteras i denna rapport anv¨ands en MSP430 mikrokontroller som ¨ar relativt str¨omsn˚al och dessutom har m˚anga olika funktioner tillg¨angliga.

4.1.1 Utvecklingsmilj ¨ o

F¨or att programmera mikroprocessorer anv¨ands f¨or det mesta programmeringsspr˚aket C och s˚a ¨aven i detta fall. F¨or att underl¨atta programmeringsdelen anv¨ands en IDE, ”In-tegrated Development Environment”, eller p˚a svenska integrerad utvecklingsmilj¨o. En ofta anv¨and milj¨o till diverse olika programmeringsspr˚ak ¨ar Eclipse [30] d˚a den ¨ar gratis och relativt enkelt att skriva plugins till. I detta fall anv¨andes Eclipse tillsammans med en verktygskedjan MSPGCC [31], vilket bland annat inneh˚aller kompilator f¨or MSP430

23

serien. Detta tillsammans med MSPdebug [32] g¨or det m¨ojligt att b˚ade programmera processorn men ¨aven att debugga den via JTAG-gr¨anssnittet. F¨or installationsinstruk-tioner av dessa verktyg i Eclipse anv¨andes en f¨ardig guide [33]. Ett annat alternativ till detta som eventuellt kunnat f¨orkorta uppstarten av projektet hade varit att anv¨anda IAR Embedded Workbench, [34]. Detta har dock sina nackdelar i att den finns i antingen en betalversion, som f¨orvisso g˚ar att k¨ora i 30 dagars test version, eller k¨ora en gratis version som begr¨ansar programstorleken.

4.1.2 Reaktiv programmering

F¨or att kunna spara str¨om beh¨over processor g˚a i vilol¨age s˚a ofta som m¨ojligt. Det-ta g¨ors enklast genom att anv¨anda s˚a kallad reaktiv programmering, ocks˚a k¨ant som h¨andelsestyrd programmering. Kortfattat inneb¨ar detta att processorn alltid sover utom vid tillf¨allen d˚a de finns olika h¨andelser som ¨ar inplanerade eller vid externa interrupt.

F¨or att kunna skriva reaktiva program beh¨ovs en k¨arna, ett operativsystem, att bygga sina program runt. I detta fall anv¨andes en ”realtidsk¨arna” utvecklad p˚a Lule˚a tekniska universitet, LTU, vid namn TinyTimber. F¨ordelen med att anv¨anda denna realtidsk¨arna ist¨allet f¨or en av de m˚anga andra som finns var till st¨orsta delen att hj¨alp var l¨attillg¨anglig d˚a utvecklarna fanns tillg¨angliga p˚a universitetet f¨or fr˚agor. Ut¨over detta tar TinyTimber, f¨orkortat tT, relativt liten plats j¨amf¨ort med andra k¨arnor och det har v¨aldigt h¨og nog-grannhet p˚a hur precist de schemalagda h¨adelserna kan utf¨oras enligt en unders¨okning av Lindgren et al [19]. F¨or lite mer information och exempel p˚a hur TinyTimber har anv¨ands finns till exempel i ett licentiat skriver av Johan Eriksson [35].

En annan f¨ordel med att anv¨anda tT ¨ar att det redan fanns f¨ordefinierad inst¨allningar specifikt f¨or processorn MSP430f1611 som anv¨andes i projektet. Detta medf¨orde att bland annat UART-inst¨allningar, klockinst¨allningar etcetera var f¨orinst¨allda. Allt detta hade dock redan gjorts i syfte att l¨ara sig om MSP430 arkitekturen innan en k¨arna skulle anv¨andas, dels f¨or att det underl¨attar att kunna systemet om problem skulle uppst˚a men ocks˚a f¨or att veta att allt fungerar utan k¨arnan till en b¨orjan.

4.1.3 Basfunktioner

F¨or att systemet skall vara l¨attare att anv¨anda och samtidigt ge ett b¨attre intryck ¨ar det bland annat bra att ge lite information till anv¨andaren av produkten. H¨ar ing˚ar till exempel att visa att enheten ¨ar uppkopplad mot en annan enhet eller att den v¨antar p˚a att n˚agon ska f¨ors¨oka ansluta. Bluetooth-modulen som anv¨ants, RN-42 [26], i ”proof of

4.1. Sensorkortet 25

concept”-enheten har utg˚angar f¨or att visa b˚ada dessa statusar och dessa anv¨andes till att trigga en interrupt i mikroprocessorn s˚a att denna kan styra indikationen. Information om att enheten inte ¨ar kopplad kan bland annat utnyttjas till att f¨ors¨oka para med en f¨orutbest¨amd enhet etcetera.

Annan information som ocks˚a ¨ar l¨att att visa via lysdioder och framf¨orallt nyttig att ha f¨or anv¨andaren ¨ar batteristatus. Detta l¨ostes genom att anv¨anda mikroprocessorns inbyggda analoga till digitala omvandlare, ADC (Analog to Digital Converter). ADCn i mikropro-cessorn kan dock bara m¨ata upp till samma sp¨anningen som processorn drivs med, i detta fall 3,3V, och d˚a batteriets nominalsp¨anning ligger p˚a 3,7V m˚aste en sp¨anningsdelare anv¨andas. Sp¨anningsdelaren valdes att halvera sp¨anningen s˚a den m¨atta sp¨anningen ¨ar h¨alften s˚a stor som den verkliga, se formel 4.1 f¨or utr¨akning av batterisp¨anningen utifr˚an uppm¨atta sp¨anningen. I formeln ¨ar Vmatning matningen till mikroprocessorn p˚a 3,3V och ADC_v¨arde ¨ar det momentana v¨ardet som m¨atts medans ADC_max ¨ar de maximala v¨ardet.

ADC_max var i det h¨ar fallet 4095 d˚a m¨atningarna gjordes med hj¨alp av en 12-bitars ADC. Denna information visades sedan p˚a en flerf¨argad lysdiod, RGB-LED, genom att lysa i olika f¨argkombinationer, 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¨or detta ¨andam˚al.

Tabell 4.1: Tabell f¨or att avl¨asa batteristatus utifr˚an RGB-LEDens f¨arg.

4.1.4 Kommunikation

F¨or att kunna skicka data ¨over Bluetooth anv¨andes i detta fall det digitala kommuni-kationsprotokollet UART, som diskuterats i kapitel 3.2.3. Eftersom mikroprocessorn har

en inbyggd UART-enhet handlar programmeringen av UART om att st¨alla in kommu-nikationsfrekvenser och sedan skicka data till enheten som representeras av ett register s˚a sk¨oter mikroprocessorn kommunikationen. Detta underl¨attades en hel del av att det dessutom fanns f¨ardiga ”drivrutiner” f¨or detta inbyggt i TinyTimber-k¨arnan vilket kunde anv¨andas som exempel innan k¨arnan anv¨andes fullt ut.

F¨or att avl¨asa informationen fr˚an accelerometern fanns tv˚a protokoll att v¨alja mellan, SPI och I²C. SPI [22] har f¨ordelen att det st¨odjer h¨ogre ¨overf¨oringshastigheter medans I²C [23] har f¨ordelen att f¨arre ledare beh¨ovs. Ut¨over detta st¨odjer I²C adressering med f¨orinst¨allda adresser om flera enheter skulle anv¨andas i samma kedja medan SPI beh¨over en ing˚ang p˚a varje enhet som s¨ager om enheten ska anv¨andas, en s˚a kallad ”chip select ing˚ang”. Med f¨ordelen att I²C kr¨aver f¨arre ledare och att de h¨ogsta hastigheterna inte var av st¨orre vikt b¨orjade implementering av I²C att ske. Efter f¨ors¨ok att implementera I²C hittades en errata till MSP430F1611-processorn , [36]. Med hj¨alp av denna kunde ett tiotal fel p˚a I²C-enheten konstateras och det beslutades d˚a att SPI var ett b¨attre alternativ.

SPI-kommunikationen var l¨att att f˚a ing˚ang n¨ar v¨al protokollet f¨orstods. Ett problem som orsakades av detta var d˚a avl¨asning av data skulle ske. Detta kr¨aver p˚a MSP430-enheten att, efter registerv¨ardet som skall avl¨asas skickats, denna skickar n˚agot ut˚at f¨or att starta klocksignalen som tillhandah˚alls av mikroprocessorn. Klocksignalen beh¨ovs f¨or att accelerometern skall kunna skicka tillbaka data och n¨ar inte detta gjordes korrekt returnerade accelerometern aldrig n˚agon data.

4.2 Programmering av smartphone

I denna sektion kommer programmeringen av en enkel s¨akerhetsapplikation att disku-teras. Id´en med denna applikation ¨ar att n¨ar ett speciellt meddelande tas emot ¨over Bluetooth fr˚an sensorenheten skall ett SMS, Short Message Service, med platsangivel-se skickas till ett n¨odnummer som anges i applikationens inst¨allningar. Denna position h¨amtas i b¨asta 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¨ands en uppskattad position utifr˚an mobiln¨atet. Den information som erh˚alls sl˚as sedan upp emot en karta vilket ger en adress som ¨ar l¨attare att f¨orst˚a f¨or en m¨ansklig mottagare.

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

¨ar i skrivande stund iOS, Android och Symbian d¨ar de tv˚a f¨orstn¨amnda ¨ar de betydligt vanligaste [37, 38]. Symbian ¨ar ett operativsystem som mer eller mindre har ¨overgivits av de stora mobiltelefontillverkarna idag och ¨ar d¨arf¨or inte en av de b¨attre plattformarna att satsa p˚a.

F¨or att utveckla applikationer till en iPhone, som k¨or iOS, beh¨ovs tillg˚ang till en Mac-dator, som egentligen ¨ar en PC specialanpassad f¨or Apples egna operativsystem MAC OS X. En licens f¨or att f˚a tillg˚ang till Apples utvecklingsprogram f¨or iOS-enheter m˚aste k¨opas, kostar$99, och dessutom m˚aste en iPhone,Ipad eller iPod touch finnas tillg¨anglig.

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

Detta g¨or det sv˚art att p˚a prototypniv˚a testa Bluetooth-kommunikation med en IOS enhet eller s˚a s¨atts restriktiva krav p˚a vilka f¨ardiga Bluetooth-enheter som g˚ar anv¨anda.

Android som ¨ar en av de mest anv¨anda operativsystemet har f¨ordelen att all kod ¨ar

¨oppen och att komma ig˚ang med programmeringen g˚ar fort, inte ens en enhet beh¨ovs d˚a emulator g˚ar anv¨anda till att testa de flesta applikationer. Nackdelen med Android ¨ar d¨aremot att enheterna ¨ar ganska segmenterade, det vill s¨aga att det finns m˚anga olika enheter med mycket skillnader i h˚ardvara vilket kan medf¨ora strul om bak˚atkompatibilitet till ¨aldre versioner av Android skall st¨odjas. F¨or applikationen som ¨ar t¨ankt anv¨andas mot sensor-noden ¨ar detta inte ett problem d˚a varken h¨oga krav p˚a prestandan eller h¨oga krav p˚a utseendet av appen beh¨ovs. Ut¨over detta ¨ar m˚alet med detta exjobb att ut¨oka Neavas s¨akerhtsapplikationer som i dag ¨ar gjorda till Android-enheter. Allt detta tillsammans med att en enhet redan ¨agdes av rapportskrivaren gjorde valet f¨oll p˚a Android som plattform.

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

4.2.2 Utvecklingsmilj ¨ o

Aven h¨¨ ar, som vid MSP430 programmeringen, anv¨andes Eclipse som utvecklingsmilj¨o men ist¨allet f¨or spr˚aket C s˚a anv¨andes Java. Tillsammans med Androids egna SDK, Software Development Kit, finns alla tillg¨angliga API:er, Application Programming In-terface, f¨or Android-enheter tillg¨angliga. Denna SDK ger ¨aven tillg˚ang till en emulator

f¨or att simulera en enhet direkt p˚a datorn f¨or att l¨attare kunna fels¨oka eller n¨ar ing-en telefon finns att tillg˚a. Denna funktion ¨ar dock inte optimal vid programmering och tester av mobiltelefonernas Bluetooth-modul d˚a emulatorn inte kan simulera Bluetooth-kommunikation och d¨armed alltid skapar en applikationskrasch. Detta l¨ostes mycket l¨att genom att alla tester och debuggningar enkelt kan k¨oras fr˚an utvecklingsmilj¨on direkt p˚a en fysisk enhet.

4.2.3 Anv ¨andargr ¨anssnitt

Eftersom den t¨ankta trygghetsapplikationen skall ligga och v¨anta p˚a ett Bluetooth-meddelande och i detta fall utl¨osa ett alarm s˚a ¨ar behovet av ett anv¨andargr¨anssnitt ganska litet. Det som beh¨ovs ¨ar en inst¨allningsmeny, n˚agonstans att st¨alla in uppkopp-lingen mot Bluetooth-enheter och en vanlig knapp som startar applikationen.

Fr˚an den enkla huvudsk¨armen g˚ar det med hj¨alp av menyknappen, h˚ardvaruknappar p˚a alla Android-enheter som kom innan Android version 4.0 och d¨arefter 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¨ora inst¨allningar. Anv¨ands knappen f¨or att ansluta en Bluetooth-enhet listas tillg¨angliga enheter som g˚ar att ansluta till, se figur 4.1b. Inst¨allningsknappen leder vidare till en inst¨allningssk¨arm, se figur 4.1c, d¨ar bland annat mottagarens telefonnummer g˚ar knappa in. H¨ar g˚ar ¨aven att v¨alja om den inbyggda GPS:en ska anv¨andas eller inte.

4.2.4 Bluetooth-kommunikation

F¨or att snabbt och enkelt komma ig˚ang med Bluetooth-kommunikationen i Android anv¨andes ett kodexempel vid namn Bluetoothchat [39]. Detta exempel beh¨ovde dock modifierades en aning f¨or att kunna st¨odja bland annat SPP.

I grund och botten skapas en egen tr˚ad f¨or Bluetooth-kommunikationen s˚a att framf¨orallt inte anv¨andargr¨anssnittet tappar kapacitet och blir okontaktbart. Skulle anv¨ andar-gr¨anssnittet vara okontaktbart en l¨angre stund, en l¨angre stund ¨ar f¨or Androidsystemet cirka 5 sekunder, kommer operativsystemet automatiskt st¨anga ner applikationen d˚a det anser att programmet har h¨angt sig. Denna tr˚ad bevakas sedan av huvudtr˚aden f¨or att kunna uppdatera olika statusf¨alt som till exempel om n˚agon enhet h˚aller p˚a att kopplas upp, ¨ar uppkopplad eller om den ¨ar fr˚ankopplad. Bevakningen av Bluetooth-tr˚aden tar

¨aven emot meddelandena, som i sin tur kommer fr˚an en annan Bluetooth-enhet, och utifr˚an detta best¨ams vad som skall g¨oras (till exempel sl˚a p˚a larmet).

4.2. Programmering av smartphone 29

(a) Huvudsk¨armen med me-nyf¨altet ¨oppnat.

(b) Sk¨arm ¨over m¨ojliga en-heter att ansluta till.

(c) Inst¨allningsmenyn.

Figur 4.1: Sk¨armdumpar fr˚an anv¨andargr¨anssnittet av den utvecklade applikationen

4.2.5 Alarm

N¨ar ett f¨orutbest¨amt meddelande tas emot av Bluetooth-tr˚aden, se kapitel 4.2.4 f¨or mer information, skall ett larm utl¨osas. Detta larm har i uppgift att b˚ade meddela personer i omgivningen om att n˚agot har h¨ant och att kontakta n¨arst˚aende via SMS, Short Message Service, med platsbeskrivning med mera.

F¨or att meddela omgivningen att n˚agot har h¨ant anv¨ands en alarmsignal. Denna startas i en egen tr˚ad f¨or att inte belasta anv¨andargr¨anssnittet d˚a ljud spelas upp.

P˚a samma s¨att som ljudtr˚aden skapas en tr˚ad f¨or att skicka SMS. Denna tr˚ad b¨orjar med att kolla om GPS:en ¨ar tillg¨anglig och om den ¨ar detta b¨orjar den s¨oka efter satelliter.

Finns inte GPS:en tillg¨anglig eller om det tar f¨or l˚ang tid att hitta en GPS-signal, satt till 30 sekunder vid test, s˚a anv¨ands ist¨allet telefonn¨atet f¨or att uppskatta en position.

Oavsett vart ifr˚an positionsdatat kommer ifr˚an s˚a anv¨ands det f¨or att sl˚a upp en plats-beskrivning som ¨ar l¨attare f¨or en m¨anniska att f¨orst˚a. I detta fall anv¨andes Androids inbyggda API f¨or ”Geocoding” [40]. Denna fungerar s˚a att med hj¨alp av en adress g˚ar det att h¨amta ut latitud och longitud eller som i denna applikation h¨amta ut en adress

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.

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¨astan uteslutande hade testats p˚a en labbkort innan designen f¨or m¨onsterkortet gjordes fungerade de mesta sm¨artfritt direkt efter att allt hade blivit monterat p˚a det designade kortet. En sak som inte fungerade som det var t¨ankt var den MOSFET som skulle kunna st¨anga 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¨anda men hade beh¨ovt 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

(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¨or r¨orelseigenk¨anning aldrig gjordes i C s˚a utf¨ordes tester som ist¨allet f¨or att larma vid specifika r¨orelser larmade vid ett klick p˚a accelerometern. Detta utl¨oste en alarmsignal som skickades till Androidapplikationen via Bluetooth och som i sin tur startade SMS-tj¨ansten. SMS-tj¨ansten i sin tur h¨amtade GPS-data, om GPS var vald, och slog upp adressen som motsvarar positionen. Om en GPS-signal inte fanns tillg¨anglig eller enheten inte var vald h¨amtades en approximerad position utifr˚an telefonn¨atet 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.

5.3. R¨orelsealgoritm 33

5.2.2 MSP430

Att skicka data ¨over Bluetooth-enheten gick snabbt att komma ig˚ang med d˚a det enda som kr¨avdes var en fungerande UART-kommunikation. Efter att l¨ange ha f¨ors¨okt h¨amta data fr˚an accelerometern ¨over I²C-protokollet uppt¨acktes 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¨anda en vanlig port och simulera I²C-protokollet via detta eller ¨overg˚a till SPI. Det senare valdes d˚a detta medf¨or att betydligt h¨ogre ¨overf¨oringsfrekvenser kan uppn˚as och att den inbyggda SPI-enheten kunde ta hand om det inkommande paketet. Efter detta problem var l¨ost 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¨or att spara energi n¨ar inget k¨ors, det vill s¨aga g˚a ner i vila, och f¨or att kunna schemal¨agga h¨andelser s˚a de utf¨ors regelbundet. F¨or att g¨ora detta valdes, som n¨amnts i tidigare kapitel 3.2.1, TinyTimber-k¨arnan. Detta skapade en del problem d˚a den senast anv¨ants p˚a en MSP430-plattform var av utvecklaren f¨or cirka 4 ˚ar sedan. Vilket medf¨orde att bland annat Watchdog-funktionen, en s¨akerhetsfunktion som ˚aterst¨aller processorn till dess utg˚angsl¨age om den inte ˚aterst¨alls med j¨amna mellanrum, fick st¨angas av f¨or att inte st¨ora k¨arnan.

5.3 R ¨ orelsealgoritm

F¨or att testa om r¨orelseklassificeringsalgoritmen fungerade som det var t¨ankt

F¨or att testa om r¨orelseklassificeringsalgoritmen fungerade som det var t¨ankt