Portable Instrument Panel for Rowers

Bachelor afstudeerscriptie:

Portable Instrument Panel for Rowers Dataverwerking via Android applicatie

Auteurs: K. Dreef M. van der Reek

- 4107861 - 4107624

Begeleider: Prof. Dr. K.A.A. Makinwa

Delft, 4 juli 2014

Samenvatting Op het moment zijn er geen gebruiksvriendelijke en betaalbare producten die de prestaties van een roeier kunnen meten op het water. In dit bachelor afstudeerproject wordt de software besproken die is ontworpen voor Android 4.4. Hier worden de keuzes die zijn gemaakt voor de software toegelicht. Met behulp van de verkregen kracht en hoek van de sensoren wordt het aantal slagen per minuut en het vermogen berekend. Voor de communicatie tussen de sensoren en de smartphone is Bluetooth low energy gekozen wegens het lage energieverbruik en de grote ondersteuning onder high-end smartphones. Dit in tegenstelling tot het handjevol smartphones die Ant+ ondersteunen. Om de locatiebepaling zo accuraat mogelijk te maken wordt er gebruik gemaakt van de netwerk provider in combinatie met WIFI en GPS. De locatie wordt twee keer opgevraagd en daarna worden de locaties met elkaar vergeleken. De locatie met de hoogste accuratie wordt gebruikt als locatie voor de afstandsbepaling. Het prototype van de applicatie werkt naar behoren. Er kan een Bluetooth low energy verbinding worden opgezet zodat de data kan worden ontvangen, verwerkt en opgeslagen in de database. Dezelfde kan vervolgens worden uitgelezen en in een grafiek worden gezet. In de toekomst moeten er nog meer functies worden toegevoegd. Zoals split-time, snelheid van de boot ten opzichte van de aarde en het water, en het vergelijken van data met andere roeiers. Wanneer ook Ant+ breed beschikbaar is zal deze mogelijk de Bluetooth low energy moeten vervangen. Aangezien er dan de mogelijkheid is dat ook de coach tegelijkertijd de data kan ontvangen op een eigen apparaat. De broncode van de Android applicatie is terug te vinden op bitbucket1 .

1

https://bitbucket.org/boeaptutu/rowapp

ii

Voorwoord Graag presenteren wij u hierbij onze scriptie met betrekking tot ons eindproject voor onze bachelor electrical engineering. Het eindproject betreft het ontwikkelen van een meetsysteem voor de roeisport. Wij hebben in het kader van het project de ontwikkeling van de software applicatie voor onze rekening genomen. Deze taak sluit goed aan bij de minor programmeren die wij beiden hebben gevolgd. Het ontwikkelen van de software applicatie in Android bleek een serieuzere uitdaging dan verwacht, hetgeen vooral kwam door onze beperkte programmeerervaring met Android. Desondanks hebben wij door een serieuze aanpak, niet aflatende inzet en goede samenwerking de obstakels die wij op onze weg vonden weten te overwinnen. Wij zijn derhalve buitengewoon content met de resultaten. Zeker in het licht van de korte looptijd van 3 maanden van het project. Graag hadden we meer tijd gehad om zaken verder te ontwikkelen en het product verder te volmaken. Naast de ontwikkeling van de software applicatie zijn wij zeer te spreken over zowel de onderlinge samenwerking als de constructieve samenwerking binnen het team. Als laatste een woord van dank voor onze opdrachtgever Guus van Wechem, onze technisch begeleider Jeroen Bastemeijer en onze hoofdbegeleider Kofi Makinwa. Wij wensen u veel leesplezier.

Delft, 4 juli 2014

- Kaj Dreef en Menno van der Reek

iii

iv

Inhoudsopgave Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Voorwoord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

i iii

1 Introductie 1.1 Achtergrondinformatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Definities en afkortingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 1 1

2 Probleemdefinitie 2.1 Probleemstelling . 2.2 Eisen . . . . . . . . 2.3 Het meetsysteem . 2.4 Specificaties . . . . 2.5 Samenvatting eisen

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . en specificaties

3 Verwant onderzoek 3.1 Verwante onderzoeken 3.2 Bestaande systemen . 3.2.1 RowX . . . . . 3.2.2 Concept 2 . . . 3.2.3 RunKeeper . . 3.3 Conclusie . . . . . . .

. . . . . .

. . . . . .

. . . . . .

4 Hardware interfaces 4.1 Het meetsysteem . . . . . . 4.2 Draadloze communicatie . . 4.2.1 NFC . . . . . . . . . 4.2.2 WIFI . . . . . . . . 4.2.3 Ant+ . . . . . . . . 4.2.4 Bluetooth . . . . . . 4.3 Bluetooth low energy (BLE)

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . . .

. . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

5 5 5 6 6 7

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

9 9 10 10 11 11 11

. . . . . . .

13 13 13 13 14 14 14 15

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

5 Sofware-architectuur 19 5.1 Top-down ontwerp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2 Decompositie beschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.3 Ontwerp afwegingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 v

INHOUDSOPGAVE 6 Data ontwerp 6.1 Opslagmethode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Database ontwerp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Opslagruimte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23 23 23 24

7 Componenten ontwerp 7.1 Bluetooth low energy . . . 7.2 Dataverwerking . . . . . . 7.3 GPS . . . . . . . . . . . . 7.3.1 GPS werking . . . 7.3.2 Afstandsbepaling . 7.3.3 Snelheidsbepaling . 7.3.4 Aanbevelingen . .

27 27 28 32 32 33 34 34

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

8 User Interface Ontwerp 35 8.1 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.2 Ontwerpen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.3 Schermresolutie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9 Foutenanalyses en testen 9.1 Benodigde hardware smartphone . . 9.2 Pakketten verliezen . . . . . . . . . . 9.3 Connectie verliezen . . . . . . . . . . 9.4 Testen . . . . . . . . . . . . . . . . . 9.4.1 JUnit: Dataverwerking . . . . 9.4.2 CPU en RAM verbruik . . . 9.4.3 Data doorvoersnelheid . . . . 9.4.4 Meetresultaten totaalsysteem

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

39 39 39 40 41 41 42 43 43

10 Conclusie

45

11 Aanbevelingen

47

Bibliografie

49

Appendix A Enquête . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C Figuren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51 52 53 54

vi

Hoofdstuk 1

Introductie 1.1

Achtergrondinformatie

Tijdens een roeiwedstrijd wint bijna altijd het team dat het meeste vermogen heeft geleverd op het water. Het geleverde vermogen is derhalve een goede indicatie voor de prestatie van een roeier. Op het water is dit alleen minder makkelijk te bepalen dan tijdens een training op een ergometer. Een ergometer is een roeimachine, die wordt gebruikt voor roei trainingen op het land. Hier moet dus een nauwkeurig, maar ook gebruiksvriendelijk systeem voorkomen. Tegenwoordig bestaan er al systemen die het vermogen kunnen meten die een roeier uitoefent op het water. Deze systemen zijn vaak alleen duur en niet makkelijk te installeren, derhalve niet erg gebruiksvriendelijk. Het doel van dit project is dan ook een meetsysteem te ontwikkelen dat gebruiksvriendelijk is en tegelijkertijd betaalbaar blijft.

1.2

Overzicht

Voordat het ontwerpproces van de software wordt beschreven, worden in het hoofdstuk “Probleem definitie” de eisen die aan de software gesteld zijn beschreven. Daarna volgt het hoofdstuk “Verwant onderzoek”. Hier worden meerdere bestaande systemen onderzocht wat daar de gebreken van zijn. In de volgende hoofdstukken zal het systeem vanuit een top-down aanpak besproken worden. Als eerste wordt er uit gezoomd naar het totale systeem inclusief de microcontroller, sensoren en hoe deze communiceren met de software. Daarna volgt een beschrijving van de software in de vorm van de “Software-architectuur”. In hoofdstuk 6 wordt de opbouw van de database besproken. Hoofdstuk 7 gaat dieper in op de implementatie van enkele belangrijke componenten. Er wordt daarna besproken hoe de gebruikersinterface is ontworpen en waarom er bepaalde afwegingen zijn gemaakt om zo optimaal mogelijke gebruikerservaring te creëren. In het daarop volgende hoofdstuk worden foutenanalyses en testen besproken die gedaan zijn om de software te evalueren. In het hoofdstuk “Conclusie” wordt alles samengevat en een oordeel geveld over de software. Als laatste worden er nog aanbevelingen gedaan hoe de software zou kunnen worden verbeterd.

1.3

Definities en afkortingen

Hieronder bevindt zich een lijst met veel gebruikte termen in dit verslag. 1

1.3. DEFINITIES EN AFKORTINGEN Paal: De paal wordt door de roeier gebruikt om de boot vooruit te stuwen. Het handvat aan het uiteinde van de paal is het punt dat de roeier vast houd. Het blad aan het andere uiteinde van de paal, zorgt dat de kracht van de roeier wordt overgebracht op het water. Zie figuur 1.1 voor een weergave van een paal.

Figuur 1.1: De paal[1] Dol: De dol is de houder waar de paal in ligt. De dol bevindt zich op het draaipunt van de paal. Fase van de roeislag: Figuur 1.2 laat de fases die worden doorlopen tijdens één roeislag zien. In de software is één slag gedefinieerd als het inpikken van het blad (‘catch’), vervolgens de kracht die op de paal wordt gezet om de boot te verplaatsten (‘drive’). Daarna tilt de roeier het blad uit het water (‘finish’) en ten slotte brengt hij de paal terug naar zijn beginpositie (‘recovery’).

Figuur 1.2: De verschillende fases die een roeier doormaakt bij één slag[2] Android activiteit: Een nieuw scherm met eigen ge¨ımplementeerde functies. Op een activiteit draait altijd de user interface. Thread: Een lopend proces naast het hoofdproces. Op een single core processor wisselen deze processen elkaar onmerkbaar snel af, waardoor het lijkt dat de codes concurrent zijn. Swipen: Door middel van een veegbeweging over het scherm met één vinger kan de gebruiker wisselen tussen meerdere schermen. Datapakket: Een pakket met data van een voorgedefineerd aantal bytes dat wordt verzonden. Deze grootte is exclusief de head en tail informatiegegevens van een communicatielink. 2

HOOFDSTUK 1. INTRODUCTIE Zend-/ontvangsnelheid: De snelheid (datapakketten/s) waarmee complete datapakketten worden verzonden/ontvangen. Data doorvoersnelheid: De hoeveelheid data in bits (tenzij anders vermeld) die per seconde over een communicatielink kan worden verzonden, exclusief de head en tail bits van een communicatielink. GPS: ‘General Positioning System’ is een satelliet navigatie systeem wat gebruikt kan worden voor locatie bepaling.

3

1.3. DEFINITIES EN AFKORTINGEN

4

Hoofdstuk 2

Probleemdefinitie 2.1

Probleemstelling

Voor tijdens het roeien is er momenteel geen gebruiksvriendelijk systeem dat het effectief geleverde vermogen door de roeier op het water kan meten en real-time feedback kan geven. De opdrachtgever1 wil een systeem dat dit kan meten en (semi) real-time kan doorsturen naar de smartphone van de gebruiker. De smartphone moet de data dan verwerken en weergeven op het scherm. Voor de software wil de opdrachtgever het volgende zien dat: • De binnengekomen data wordt opgeslagen, zodat deze achteraf geanalyseerd kan worden. • Er gebruik moet worden gemaakt van zuinige draadloze communicatie. • De gebruikersinterface moet net zoveel of meer informatie tonen als de Concept2 [3].

2.2

Eisen

In samenspraak met de opdrachtgever zijn de volgende eisen geformuleerd: • De software moet gebruiksvriendelijk zijn. • Er moet via de applicatie gemakkelijk verbinding kunnen worden gemaakt met de sensoren. • Tijdens het roeien mogen er alleen cijfers getoond worden van de volgende grootheden: – Vermogen – Kracht – Afgelegde afstand – Slagen per minuut – Hartslag • De data moet achteraf geanalyseerd kunnen worden. 1

Guus van Wechem

5

2.3. HET MEETSYSTEEM • Tijdens de analyse moeten er kracht-tijd grafieken getoond worden. • Data van meerdere roeiers moeten met elkaar kunnen worden vergeleken. Met behulp van deze eisen zijn de specificaties voor de software opgesteld.

2.3

Het meetsysteem

In figuur 2.1 is het overzicht van het complete systeem te zien. De krachtsensor meet de doorbuiging van de paal en de hoeksensor meet de hoek van de paal ten opzichte van de boot. Deze metingen worden door de microcontroller samengevoegd en verzonden naar de smartphone. De smartphone zal de data verwerken en presenteren aan de gebruiker. In deze scriptie zal er gefocust worden op het ontvangen, verwerken en daarna presenteren van de data aan de gebruiker op een Android smartphone. Informatie over de krachtsensor is te vinden in de scriptie van R.L. Leijsen en T. Beintema[4] en informatie over de hoeksensor en de microcontroller met de Bluetooth module in de scriptie van K.P. schaper en B.F. Oosterhuis[5]. Voor een uitgebreidere werking van het gehele systeem, zie sectie 4.1.

Figuur 2.1: Overzicht van alle onderdelen van het roei meetsysteem

2.4

Specificaties

De specificaties zijn bepaald naar aanleiding van de eisen van de opdrachtgever en wat haalbaar is binnen de gestelde tijd van drie maanden. Deze worden hieronder besproken. Platform Er is gekozen om alleen maar Android te ondersteunen gericht op versie 4.4. Android heeft op het moment een marktaandeel van bijna 80% [6]. Mede gezien het feit van de beperkte ontwikkelingstijd van maar drie maanden is er derhalve gekozen om geen andere platformen te ondersteunen zoals iOS of Windows Phone. Communicatie De communicatie tussen de sensoren en de software op de smartphone zal verlopen via Bluetooth low energy (BLE). De BLE ‘service’ en ‘characteristic’ hebben een eigen UUID, 6

HOOFDSTUK 2. PROBLEEMDEFINITIE zie tabel 2.1. Er worden pakketten van 20 bytes ontvangen met een ontvangsnelheid van 20 pakketten/s. Dit resulteert in een data doorvoersnelheid van 3,2 kb/s. In een pakket zitten 5 samples en één identiek pakketnummer. De samples zijn ieder 26 bits en het pakketnummer is 30 bits groot. De eerste 14 bits van een sample geven de hoek en de laatste 12 bits van een sample geven de kracht weer. De waarden van deze hoek en kracht zijn het gesamplede getal uit de ADC. Er moet dus nog een conversie plaatsvinden naar de juiste grootheid. Pakketnummers worden verstuurd in oplopende volgorde beginnend bij 0. Figuur 2.2 geeft een illustratieve weergave van een ontvangen pakket van 20 bytes.

Figuur 2.2: Datastructuur van een ontvangen pakket

Snelheid en afstand In de software zal gebruik gemaakt moeten worden van plaatsbepaling. Zodat de plaats van de boot bepaald kan worden. Uit deze informatie kan de afgelegde afstand en snelheid van de boot worden bepaald. De afstand moet een nauwkeurigheid van tenminste 50 meter hebben over een afstand van 2 kilometer, dit is dan 2,5 %. Voor de snelheid dient een nauwkeurigheid van ten minste 5 % te gelden. Analyse Tijdens het analyseren moet de vergaarde data opnieuw bekeken kunnen worden. Deze keer op een uitgebreidere manier dan tijdens het roeien zelf. Hier moet algemene informatie kunnen worden bekeken, split-time (informatie per 500 meter) en een kracht-tijd grafiek. Data vergelijken De data van meerdere roeiers zal met deze versie niet vergeleken kunnen worden. De tijdslimiet van drie maanden laat het niet toe om dit te implementeren, maar zal wel meegenomen worden in het ontwerp zodat dit later toegevoegd kan worden.

2.5

Samenvatting eisen en specificaties

In tabel 2.1 worden alle specificaties uit de vorige paragrafen herhaald waar het product aan moet voldoen.

7

2.5. SAMENVATTING EISEN EN SPECIFICATIES

Tabel 2.1: Technische specificaties

Platform Communicatie Bluetooth data doorvoersnelheid Format Bluetooth BLE service UUID BLE characteristic UUID Benodigde informatie

Optionele informatie

Opslag

Technische specificaties Android 4.4 Bluetooth low energy 3,2 kb/s Zie figuur 2.2 00003b01-0000-1000-8000-00805f9b34fb 00003b02-0000-1000-8000-00805f9b34fb - Afstand (GPS) 50 m nauwkeurigheid over 2 km (nauwkeurigheid van 2,5 %) - Snelheid ten opzichte van aarde (GPS) (nauwkeurigheid van 5 %) - Geleverde vermogen roeier (nauwkeurigheid van 5 %) - Geleverde kracht roeier - Slagen per minuut (SPM) - Iedere 10 seconden updaten van de data (tijdens het roeien) - Hartslag - Snelheid ten opzichte van water (nauwkeurigheid van 5 %) Lokale database

Tabel 2.2: User Interface specificaties

Tijdens het roeien Analyse

User Interface specificaties - Geen grafieken - Alleen cijfers - Overzicht van de roeiprestatie - Grafiek voor krachtverloop - Split-time

8

Hoofdstuk 3

Verwant onderzoek 3.1

Verwante onderzoeken

Om duidelijkheid te verkrijgen over wat de roeiers willen zien tijdens en na het roeien is er een enquête afgenomen. Deze enquête, terug te vinden in appendix A, is afgenomen bij een roeivereniging in Delft. Aan de hand van de uitkomsten van deze enquête is in overleg met de opdrachtgever besloten waar de nadruk op ligt tijdens het ontwerpproces in dit bachelor afstudeerproject. De bevindingen van de enquête zullen hieronder worden besproken. Tijdens het roeien De roeier wil tijdens het roeien graag het volgende op het beeldscherm zien (gesorteerd van belangrijk naar onbelangrijk): 1. Het aantal slagen per minuut. 2. De tijd per 500 meter. 3. Vermogen van een slag. 4. Kracht van een slag. Deze informatie moet worden getoond in getallen en niet in grafieken, omdat grafieken te veel afleiden tijdens het roeien. Verder denkt een roeier niet vaak naar het scherm te kijken, ongeveer één keer per minuut. Het vermogen ziet de roeier het liefst in de eenheid watt. Na het roeien De data die de roeier terug wil zien in de analyse (gesorteerd van belangrijk naar onbelangrijk): 1. Krachtcurve over de gehele tocht. 2. Vermogenscurve over de gehele tocht. 3. Snelheid ten opzichte van het water. 4. Hoekbereik per slag. 9

3.2. BESTAANDE SYSTEMEN 5. Totale vermogensverbruik van de tocht. De roeier wil punten 1 en 2 zien in een grafiek. De roeiers zelf gaven aan geen behoefte te hebben om deze gegevens met elkaar te vergelijken. De coaches vinden het vergelijken van gegevens wel een interessante optie. Verder werd de snelheid ten opzichte van het water vaak negatief gezien, omdat dit de-motiverend zou kunnen werken wanneer er forse tegenwind is. Overige bevindingen Wanneer de software opensource zou worden gemaakt, waren de roeiers zeer enthousiast om zelf modificaties aan te brengen aan de applicatie. Wel dient te worden opgemerkt dat dit zou kunnen komen doordat de ondervraagden allemaal aan een technische universiteit studeren. Ook is aan bod gekomen of de roeier de gegevens zou willen bekijken op de computer. Indien de smartphone applicatie goed functioneert ziet de roeier er geen meerwaarde in dit op de computer te bekijken. Ten slotte gaf de roeier aan het goed te vinden als de coach ook mee kan kijken met de data tijdens het roeien.

3.2

Bestaande systemen

Roeiers willen graag weten wat hun prestaties zijn. Er zijn al systemen die dit weergeven, maar deze hebben nog gebreken. Dit bachelor afstudeerproject gaat om de software behorend bij het product, dus zal er vooral gekeken worden naar wat de concurrenten doen met de software.

3.2.1

RowX

De RowX heeft een applicatie waar de data niet alleen tijdens het roeien uitgelezen kan worden, maar ook achteraf. Zoals te zien is in figuur 3.1 is de interface voor achteraf analysen niet erg gebruiksvriendelijk. Er wordt een hoop data getoond, maar er wordt verwacht dat de gebruiker er zelf conclusies uit gaat trekken: De software helpt bovendien niet om de data te analyseren.

Figuur 3.1: Interface van de RowX [7]

10

HOOFDSTUK 3. VERWANT ONDERZOEK

Figuur 3.2: Het display van de Concept2 [8]

3.2.2

Concept 2

De concept2 is een ergometer, maar het display daarvan (zie figuur 3.2) geeft op een hele simpele en doeltreffende manier de informatie weer. Tijdens het roeien is dit een goede manier om de informatie te tonen, het geeft snel de belangrijkste informatie weer. Er wordt per slag informatie weergegeven, maar ook over de langere termijn wordt er informatie weergegeven op een overzichtelijke manier.

3.2.3

RunKeeper

Naast het kijken naar bestaande systemen binnen de roeisport is er ook gekeken naar andere systemen die de prestaties van de sporter bijhouden. Er is daarom gekeken naar de ren applicatie RunKeeper [9]. Het idee achter de interface is snel kunnen starten van het rennen en daarna als de gebruiker dat wil, de data vergelijken met vorige trainingen of vergelijken met andere gebruikers. Daarnaast worden er statistieken bijgehouden over de persoonlijke resultaten van de gebruiker en kunnen er trainingen gevolgd worden via de applicatie.

3.3

Conclusie

Enquˆ ete Omdat de roeiers duidelijk kenbaar hadden gemaakt tijdens het roeien geen grafieken maar getallen te willen zien, is dit besproken met de opdrachtgever. De eisen zijn daarom bijgesteld en er worden geen grafieken getoond tijdens het roeien. Aan de hand van de eisen van de opdrachtgever en de bevindingen van de roeier is het volgende plan van aanpak opgesteld: 11

3.3. CONCLUSIE 1. Er worden twee layouts ontworpen. Voor tijdens het roeien een overzichtelijke layout waar getallen worden getoond en voor bij de analyse een layout waarbij grafieken worden getoond. 2. De dataverwerking van de kracht- en hoeksensor zal zich richten op het berekenen van het aantal slagen per minuut, het vermogen van een slag en de kracht in een slag. 3. GPS zal worden ge¨ımplementeerd om 500 meter tijd te kunnen laten zien. 4. De software zal open source worden gemaakt. Bestaande systemen Het analyse menu moet simpel en gebruiksvriendelijk zijn. Dit gaat dan mogelijk ten koste van wat de gebruiker allemaal zelf zou kunnen doen met de data, maar voor de grootste groep van gebruikers zal dit zorgen voor een betere gebruikerservaring. Tijdens het roeien zal het streven zijn om een interface als de Concept 2 te creëren. Door alleen getallen te laten zien zal de gebruiker snel kunnen zien wat de prestaties zijn. De applicatie moet een simpele interface hebben, zodat de gebruiker snel zijn weg kan vinden door de applicatie. Het vergelijken van data zou een goede toevoeging zijn aan de applicatie, maar heeft geen prioriteit en zal derhalve in het kader van het bachelor afstudeerproject niet toegevoegd worden aan de applicatie.

12

Hoofdstuk 4

Hardware interfaces 4.1

Het meetsysteem

Het volledige meetsysteem bestaat uit verschillende onderdelen, afzonderlijk ontworpen binnen de bachelor afstudeerproject groep. Zo is het systeem verdeeld in een krachtsensor, een hoeksensor, de microcontroller en de Android software voor een smartphone. Figuur 2.1 toont een weergave van hoe deze componenten met elkaar in verbinding staan. De microcontroller leest de hoeksensor en krachtsensor uit met een sample rate van 100 samples/s. De uitgelezen waarden zijn getallen rechtstreeks van de ADC’s. In de microcontroller worden deze waarden samengevoegd in pakketten van 5 samples per pakket en vervolgens via Bluetooth low energy technologie verzonden naar de smartphone. De effectieve zendsnelheid bedraagt dan 20 pakketten/s. De smartphone zal deze data verwerken door de samples uit de pakketten om te rekenen naar de kracht in newton en hoek in radialen om vervolgens deze waarden op te slaan in een database. Tevens wordt iedere 10 seconden op het scherm van de smartphone de afgelegde afstand, het aantal slagen per minuut, en vermogens- en krachtverbruik van de roeier getoond.

4.2

Draadloze communicatie

Zoals vermeld in sectie 4.1 is er een draadloze communicatie nodig om de gemeten hoek en kracht te ontvangen van de microcontroller. Hier zijn verschillende technieken voor, omdat de ontvangende kant een smartphone is worden de keuzen tot het draadloos verzenden van deze data beperkt. De connectiemogelijkheden in een smartphone zijn: NFC, WIFI, Ant+ en Bluetooth. In tabel 2.1 staan de eisen die aan de communicatie worden gesteld. Aan de hand van deze eisen zal in onderstaande alinea’s uiteen worden gezet waarom een techniek wel of niet geschikt is voor de data overdracht van dit systeem. Hieruit zal duidelijk worden waarom er voor Bluetooth Low Energy is gekozen. In tabel 4.1 is een overzicht te vinden van de verschillende communicatie specificaties.

4.2.1

NFC

NFC (Near Field Communication) wordt gebruikt om relatief grote bestanden te versturen in een korte tijd met laag energie verbruik en haalt een data doorvoersnelheid van 424 kb/s[10]. Deze technologie werkt echter zoals de naam al aangeeft op een korte afstand. De 13

4.2. DRAADLOZE COMMUNICATIE theoretische afstand bedraagt 10 cm[10] en de afstand in de praktijk bedraagt meestal 4 cm of minder[11]. De data doorvoersnelheid is snel genoeg, echter is de overdrachtafstand te kort om te communiceren met de microcontroller op 1,5 meter afstand. Vanwege het korte bereik van deze technologie is daarom niet voor NFC gekozen.

4.2.2

WIFI

WIFI is gestandaardiseerd als de IEEE 802.11. Tegenwoordig wordt in bijna elke smartphone de IEEE 802.11n variant ondersteund[12]. Deze WIFI variant haalt een data doorvoersnelheid van 54 Mb/s tot een maximale data doorvoersnelheid van 600 Mb/s[13]. Echter is het gebruik van WIFI niet energie efficiënt wanneer er gebruik wordt gemaakt van het verzenden van datapakketten kleiner dan 100 bytes[14]. De microcontroller zal data pakketten versturen van 20 bytes waardoor de WIFI dus niet energiezuinig zal zijn. Om deze reden is niet voor WIFI gekozen.

4.2.3

Ant+

Ant+ is een nieuw opkomende technologie en werkt op dezelfde zendfrequentie als Bluetooth en WIFI, namelijk 2,4 GHz. Ant+ heeft een data doorvoersnelheid van 20 kb/s[15] en wordt omschreven als energie efficiënt. Hiernaast zijn bij Ant+ complexe netwerktopologieën mogelijk[16], dit betekent dat bijvoorbeeld niet alleen de roeier de sensor uit kan lezen maar ook tegelijk de coach. De coach kan zelfs alle data van alle roeiers tegelijkertijd ontvangen op zijn smartphone of tablet. Helaas is vanwege het gebrek aan ondersteunende smartphones en het nog niet op grote schaal beschikbaarheid van Ant+ besloten niet voor deze technologie te kiezen tijdens het bachelor afstudeerproject. Echter in een verbeterde versie van het product zal wel gekozen moeten worden voor deze optie, vanwege de uitbreiding mogelijkheden met de coach.

4.2.4

Bluetooth

Bluetooth is er in verschillende versies. Er zal worden gekeken naar versie 2 t/m versie 4. Bluetooth versie 1 zal buiten beschouwing worden gelaten, omdat versie 2 een verbetering is van versie 1. Naast verschillende Bluetooth versies heeft iedere versie ook een klasse. Een klasse staat voor het bereik van de Bluetooth verbinding[17]. De volgende klassen worden onderscheiden: • Klasse 1: bereik van 100 meter. • Klasse 2: bereik van 10 meter. • Klasse 3: bereik tot 1 meter. Er moet dus gekozen worden voor een klasse 2 Bluetooth verbinding om te verzekeren dat de microcontroller verbinding houdt met de smartphone. Dit is tevens ook de meest voorkomende klasse. 14

HOOFDSTUK 4. HARDWARE INTERFACES Versie 2 Bluetooth versie 2 is in iedere smartphone aanwezig en hiermee is dus iedere smartphone direct compatibel met het roeisysteem. Versie 2 haalt een data doorvoersnelheid van 3 Mb/s[18]. Toch is niet voor deze versie gekozen, omdat er minder energieverbruikende versies van Bluetooth beschikbaar zijn. Versie 3 Bluetooth versie 3, ook wel ‘High speed’ genoemd, is speciaal ontworpen voor het snel verzenden van grote hoeveelheden data. Denk hierbij aan video’s of muziek. Deze versie maakt gebruik van de WIFI technologie en is hiermee meteen de minst zuinige variant. Bluetooth 3 is dan ook alleen ontworpen om zonder regelmaat grote bestanden te versturen. Deze versie van Bluetooth is voor het roeisysteem dus niet geschikt, aangezien er continu data moet worden ontvangen en verzonden. Versie 4 Versie 4 is de nieuwste versie van Bluetooth en wordt ook wel Bluetooth smart of Bluetooth low energy (BLE) genoemd. Zoals de naam al aangeeft is dit de meest zuinige variant van de Bluetooth versies. Bij het zenden verbruikt de module zo 10 mA en in rust verbruikt de module 1 µA[19]. Het gaat hier dan ook om een sterk geoptimaliseerde versie van Bluetooth 2. BLE heeft een theoretische data doorvoersnelheid van 1 Mb/s[20]. In de praktijk kunnen waarden van 125 kb/s behaald worden[21]. BLE is terug te vinden in bijna iedere high end smartphone en wordt steeds meer terug gevonden in goedkopere smartphones. Wanneer het roeisysteem op de markt wordt gebracht (over 2 jaar), wordt er verwacht dat bijna iedere middensegment telefoon ook BLE zal ondersteunen. Met het oog op de nabije toekomst is dus gekozen voor deze versie en omdat deze voldoet aan alle eisen. Tabel 4.1: specificaties van de verschillende communicatie mogelijkheden Specification Data doorvoersnelheid Zend/ontvang afstand Verbruik tijdens zenden Verbruik tijdens slapen

4.3

Ant+ 20 kb/s 30 m 86,4 mW 0, 5 ∼ 0, 1 µA

BLE 1 Mb/s 100 m 15 mW 0,78 µA

NFC 424 kb/s 10 cm 100 mW 120 µA

WIFI n 600Mb/s 92 m 500 mW ?

Bluetooth 3Mb/s 100 m 15mW 7,8 µA

Bluetooth low energy (BLE)

Bluetooth low energy werkt geheel anders dan zijn voorgangers. In deze sectie zal daarom kort worden uitgelegd hoe BLE werkt. BLE maakt het onderscheid tussen een ‘master’ en een ‘slave’. De slave is het apparaat dat zich aanbiedt en gevonden kan worden door zoekende apparaten. De zoekende apparaten die verbinding maken met de aanbiedende apparaten zijn de masters[22]. In de android API is het alleen mogelijk de BLE module in de telefoon te gebruiken als master. Een master 15

4.3. BLUETOOTH LOW ENERGY (BLE) heeft de mogelijkheid zich met 7 verschillende slaves tegelijkertijd te verbinden, terwijl een slave alleen de mogelijkheid heeft zich met één master tegelijkertijd te verbinden[19]. Hiernaast onderscheidt BLE zich ook nog in een ‘client’ of ‘server’. De server is het apparaat dat data beschikbaar heeft voor de client. De client kan dan met lees of schrijf commando’s deze data opvragen van de server[22]. De smartphone zal de client worden en de microcontroller zal de server zijn. Verder is BLE opgebouwd uit het GATT (generic attribute) profiel. In een GATT profiel zijn verschillende ‘services’ aanwezig waarvan sommige zijn gestandaardiseerd aan de hand van een ‘Universally Unique Identifier’(UUID). Een UUID is gekoppeld aan iedere service en is 128 bits groot indien niet gestandaardiseerd en 16 bits groot indien wel. Services worden gestandaardiseerd, zodat data door verschillende applicaties op een zelfde wijze kan worden uitgelezen. Een voorbeeld hiervan is een service voor het verzenden van de hartslag. Het is ook mogelijk zelf een service aan te maken met een eigen UUID. Dit 128 bits UUID kan gegenereerd worden op een UUID generator website. In een service kunnen zich verschillende ‘characteristics‘ bevinden. Een characteristic heeft ook een eigen UUID en bevat een beschrijving, zijn eigenschappen en een waarde. De waarde in de characteristic is de data die met bijvoorbeeld een smartphone kan worden uitgelezen of veranderd. Een grafische representatie van een GATT profiel is te zien in figuur 4.1. De commando’s die de client kan schrijven naar de server zijn: • Read, leest de waarde van de characteristic uit. • Write, schrijft een waarde naar de characteristic. • Notify, zet een flag in de characteristic op true waardoor deze met een ingestelde periode data zal sturen zonder ontvangstbevestiging. • Indicate, hetzelfde als notify, maar nu met ontvangstbevestiging. Samenvattend voor de smartphone geldt het volgende: • De smartphone staat ingesteld als master. • De smartphone is de client. • Er is een eigen service en characteristic gemaakt waar de UUID’s te vinden zijn in tabel 2.1. • Er wordt gebruik gemaakt van notify’s.

16

HOOFDSTUK 4. HARDWARE INTERFACES

Figuur 4.1: Structuur van een Bluetooth low energy profiel[23]

17

4.3. BLUETOOTH LOW ENERGY (BLE)

18

Hoofdstuk 5

Sofware-architectuur 5.1

Top-down ontwerp

De applicatie is ontworpen vanuit twee ideeën. Namelijk het real-time feedback geven tijdens het roeien en het kunnen analyseren van deze data achteraf. Hier is tijdens het ontwerp vooral op gelet. Om dit te realiseren moet er gebruik gemaakt worden van Android’s activiteiten. Deze maken gebruik van verschillende andere klassen voor extra functionaliteiten zoals de database of de dataverwerking. De applicatie heeft vier functies die gebruikt kunnen worden in de activiteiten namelijk: • Bluetooth • Database • GPS • Dataverwerking In figuur C.2, te vinden in de appendix, kan de UML diagram gevonden worden voor de applicatie. Hierin kan duidelijk worden gezien welke activiteiten gebruik maken van welke klassen (functies).

Roeien Om data te ontvangen, verwerken en op te slaan tijdens het roeien zijn extra functies nodig. Er moet een Bluetooth verbinding worden opgezet tussen de microcontroller en de smartphone. Daarnaast moet er een klasse gemaakt worden die de data kan verwerken en terug kan geven, zodat deze real-time aan de gebruiker getoond kan worden. Om de snelheid en afstand te berekenen dient er ook nog gebruik gemaakt te worden van de GPS mogelijkheden van de smartphone. Ten slotte moet er nog een database zijn waar de data in opgeslagen kan worden voor latere analyse van de data. 19

5.2. DECOMPOSITIE BESCHRIJVING

Analyseren Na het roeien moet de data geanalyseerd kunnen worden. Hiervoor kunnen meerdere klassen hergebruikt worden die hiervoor genoemd zijn, zoals dataverwerking en de database. De data zal namelijk opnieuw uitgelezen en verwerkt worden. Tijdens het roeien zal de data worden getoond aan de gebruiker in de vorm van getallen. Bij de analyse zal ook gebruik worden gemaakt van grafieken. Dit wordt bereikt door gebruik te maken van de opensource GraphView API [24].

5.2

Decompositie beschrijving

In figuur C.1 is te zien hoe er geschakeld wordt tussen verschillende activiteiten. Hieronder worden verschillende onderdelen uit het diagram verder toegelicht.

Opstartscherm Het opstartscherm is gemaakt om kort de naam van de applicatie te tonen. Dit scherm sluit zich automatisch na 2 seconden af om dan direct over te gaan naar het hoofdmenu.

Hoofdmenu In het hoofdmenu kan de gebruiker kiezen tussen twee opties. De gebruiker kan kiezen om data te verzamelen en real-time feedback te krijgen tijdens het roeien door op de knop ‘Rowing’ te klikken. De andere optie is om te kiezen om de vergaarde data te analyseren door op de knop ‘Analysis’ te klikken.

Roeien Tijdens het roeien kan de gebruiker dus data verzamelen. Deze data wordt dan verwerkt en door de applicatie op het scherm getoond. Hier kan de gebruiker dan zien hoeveel vermogen overgebracht wordt op het water, de SPM en de totaalafstand die de roeier heeft afgelegd.

Analyse In het Analyse menu kan de gebruiker meer informatie krijgen over de training. Er zijn hier drie schermen waar tussen gewisseld kan worden. Het eerste scherm laat algemene informatie over de training zien. Hier kan de SPM, gemiddeld vermogen per slag, totale tijd en afstand gevonden worden. Het tweede scherm zou een split-time moeten tonen. Dit houdt in dat er per afgelegde 500 meter komt te staan hoe lang de gebruiker over deze afstand heeft gedaan. Deze functie zal in verband met de korte looptijd van het project niet worden ge¨ımplementeerd. Het derde en laatste scherm laat de gebruiker door middel van een grafiek de kracht-tijd verloop van de training analyseren. Hierdoor kan een gebruiker zien of deze wel constant evenveel kracht blijft leveren, of dat er in de loop van de tijd veranderingen zijn zodat de gebruiker bij een volgende training daar op kan letten. 20

HOOFDSTUK 5. SOFWARE-ARCHITECTUUR

5.3

Ontwerp afwegingen

Tijdens het maken van de applicatie is er vooral gelet op de functies in de applicatie. De applicatie heeft daardoor een eenvoudige interface. Hier is voor gekozen zodat er meer tijd was om de functies te implementeren en te optimaliseren. Bij het analyse scherm is er gekozen om te kunnen swipen tussen de verschillende schermen. De gebruiker kan hierdoor makkelijk op een intu¨ıtieve manier wisselen tussen verschillende schermen, dit bevorderd de gebruikerservaring. Het probleem dat hierdoor ontstaat is dat bij het navigeren van de ‘kracht-tijd grafiek’ scherm naar het split-time scherm de touchscreen input overeen komt met het navigeren in de grafiek. Hier zouden nog verbeteringen in doorgevoerd moeten worden om het gebruiksgemak te verbeteren.

21

5.3. ONTWERP AFWEGINGEN

22

Hoofdstuk 6

Data ontwerp 6.1

Opslagmethode

De data die verstuurd wordt vanaf de microcontroller dient ergens te worden opgeslagen. Er zijn verschillende manieren om data op te slaan in een Android applicatie. Voor de applicatie is het belangrijk dat de data gestructureerd wordt opgeslagen, want elk ontvangen pakket bevat data die bij elkaar hoort. Daarom moet er derhalve gebruik worden gemaakt van een ‘SQLite Database’. Data kan hier relatief simpel gestructureerd in worden opgeslagen, waardoor het later gemakkelijk weer opgevraagd kan worden. Er is ook nagedacht of de data niet online opgeslagen zou moeten worden. Dit zou bij een verdere uitbreiding een interessante optie kunnen zijn voor de mogelijkheden die het biedt om data op te vragen van collega roeiers om te vergelijken, maar omdat er nu gefocust is op een systeem voor één roeier biedt dit weinig meerwaarde.

6.2

Database ontwerp

In figuur 6.1 is het ontwerp van de database te zien. De database bestaat uit twee entities. Als een nieuwe rij in ‘Row-training’ wordt aangemaakt aan het begin van elke training. Dan geeft deze elke training een unieke identificatie nummer (ID). Dit zorgt ervoor dat de data goed geordend blijft. Er wordt een datum en naam van de roeier bij opgeslagen, zodat er altijd terug gekeken kan worden wanneer er werd geroeid en wie er roeide. Op het moment heeft de naam van de roeier nog geen functie in de applicatie, maar dit kan nodig zijn als later data van roeiers vergeleken word. In de ‘Row-package’ entity wordt alle data opgeslagen. Om de data op te vragen, die hoort bij de juiste training, wordt er gebruik gemaakt van de primary key van de bijbehorende Row-training. Elke keer als er een nieuw pakket binnenkomt zal de data daar uitgehaald worden. Deze zal in combinatie met de andere data (zoals de lengte- en breedtegraden van de GPS) gezamenlijk opgeslagen worden in de database. Hierdoor kan later per tijdsmoment gekeken worden wat de locatie, kracht, hoek en optioneel hartslag waren. Hier wordt dan een sample nummer en de bijbehorende ID toegevoegd zodat het later weer op te vragen is. Er is voor latere uitbreiding van de applicatie een ‘RealTime’ en een ‘HeartRate’ toegevoegd aan de database. RealTime is toegevoegd voor als er data vergeleken moet gaan 23

6.3. OPSLAGRUIMTE worden met andere roeiers uit de boot. De ‘HeartRate’ zal worden gebruikt om de hartslag van de roeier in op te slaan. Deze zou bij uitbreiding van het systeem dan opgevraagd worden van een extra sensor die nog niet in het ontwerp zit. De database van deze applicatie moet voldoen aan de derde normaal vorm bij het normaliseren van een database. Dit houdt in dat er geen redundantie dient te zijn. Ook moet er een afzonderlijke entity voor gerelateerde gegevens zijn en dienen entities via een referentie sleutel gekoppeld te worden. In de database voor deze applicatie is er geen redundantie. Dit houdt in dat er geen onnodige attributen zijn toegevoegd. Ook zijn de tabellen met waarden met betrekking tot andere trainingen in verschillende entities gestopt. Door gebruik te maken van de ID als primary key zijn de verschillende entities aan elkaar gekoppeld. Derhalve kan er geconstateerd worden dat de database voldoet aan de derde normaal vorm. Als de data opgevraagd moet worden kan dat op verschillende manieren gedaan worden. Als eerste is er de functie fetchAllTrainings(). Deze functie wordt gebruikt om alle trainingen uit de database te halen. Dit gaat dan alleen om de training ID en de datum dat deze is uitgevoerd. Deze functie wordt gebruikt om een lijst te kunnen maken van alle uitgevoerde trainingen tot nu toe. Ten tweede is er de functie fetchTrainingData(long TrainingId). Met deze functie wordt alle data uit de database gehaald die hoort bij de gegeven training ID. Voor het analyseren van de data wordt deze functie gebruikt. Ten derde is er de functie fetchTrainingData(long trainingId, long packetNum). Deze functie wordt gebruikt tijdens het verwerken van de data. Hier kan vanaf een bepaald pakket data worden opgevraagd om te worden verwerkt. Dit is nodig, omdat data niet per definitie chronologisch binnen hoeft te komen. Door deze manier toe te passen wordt de data gesorteerd en teruggegeven om verder te verwerken.

6.3

Opslagruimte

Een database neemt ruimte in beslag op de telefoon. Het is dus belangrijk ook te kijken hoeveel ruimte dit zou kunnen zijn. Op het moment worden niet alle kolommen gebruikt, waardoor de grootte nog wat beperkt wordt. Als er een nieuwe training wordt toegevoegd aan de database, dan worden één integer en 17 characters (7 voor naam en 10 voor de datum) opgeslagen. Dit staat gelijk aan 4 bytes + 17 × 2 bytes = 38 bytes. Voor elk meetpunt dat er bij wordt opgeslagen zullen er nog eens twee integers en vier ‘floating point’ getallen bij worden opgeslagen, dit zijn dus 2 × 4 bytes + 4 × 4 bytes = 24 bytes. Omdat er per seconde 100 samples worden genomen die moeten worden opgeslagen, zal de database dus per seconde 24 bytes×100 samples = 2400 bytes groter worden. Per uur zal dit ongeveer 8,7 MB aan data zijn. Als een gebruiker veel trainingen doet loopt deze hoeveelheid aan data dus snel op. Een oplossing zou zijn alleen de Row-training entity lokaal en Row-package entity online op te slaan. Hierdoor zal lokaal weinig data opgeslagen hoeven te worden, maar kan de data van een specifieke training nog steeds worden opgevraagd als de gebruiker dat zou willen.

24

HOOFDSTUK 6. DATA ONTWERP

Figuur 6.1: Entity-relationship model van de database

25

6.3. OPSLAGRUIMTE

26

Hoofdstuk 7

Componenten ontwerp 7.1

Bluetooth low energy

Voor het ontwerp van de Bluetooth low energy (BLE) communicatie klasse is gebruik gemaakt van een voorbeeld code van de Android website[25]. Deze code is gebruikt als basis voor de BLE communicatie klassen. De communicatie met de BLE is opgesplitst in drie aparte onderdelen, namelijk: 1. Het zoeken naar een apparaat dat zich aanbiedt. 2. Het opvragen van de verschillende ‘services’ van de server tijdens de connectie en het laten zien van de data aan de gebruiker. 3. Een service klasse waarin opgevraagde data wordt ontvangen. Onderdeel 1 is ge¨ımplementeerd in de klasse ‘DeviceScanActivity’. Deze klasse wordt aangeroepen wanneer er in het hoofdscherm op ‘Rowing’ wordt gedrukt. Eerst zal bij het aanmaken van de activiteit worden gekeken of er een BLE module aanwezig is in de smartphone. Indien er geen BLE module aanwezig is zal de activiteit dit melden en zich afsluiten zodat de gebruiker terugkeert naar het hoofdmenu. Wanneer de BLE module wel aanwezig is zal er worden gekeken of de BLE module aanstaat. Als deze uitstaat zal een pop-up worden getoond waarin de gebruiker wordt gevraagd toestemming te geven de BLE module aan te zetten. Vervolgens zal er voor een scan periode van 10 seconden worden gezocht naar BLE apparaten. De gevonden apparaten zullen aan de hand van hun naam en identieke hardware adres in een lijst worden getoond. De lijst waar de apparaten in komen te staan is een standaard functie in de Android API en zal scrolbaar worden wanneer er meer apparaten worden gedetecteerd dan op het scherm passen. Als er geen apparaten worden gedetecteerd binnen de 10 seconden zal de gebruiker opnieuw moeten scannen. Het scannen naar apparaten gebeurd met behulp van de Android API. Wanneer een apparaat is gevonden zal automatisch de callback functie onLeScan worden aangeroepen waarin het apparaat zich kenbaar maakt en de sterkte van het signaal meestuurt. Momenteel wordt met de sterkte van het signaal niets gedaan. Tijdens het scannen zou het mogelijk kunnen zijn alleen apparaten te zoeken die een bepaald ‘system service UUID’ hebben. Dit betekent dat er dan alleen roei meetsystemen kunnen worden getoond. Dit is wegens beperkte tijd helaas nog niet ge¨ımplementeerd. Wanneer op een gevonden apparaat wordt gedrukt wordt een 27

7.2. DATAVERWERKING nieuwe activiteit gestart. Deze zal de functies vervullen zoals genoemd in onderdeel 2. Aan deze activiteit zullen de naam en het hardware adres van het gevonden apparaat worden meegegeven. De activiteit uit onderdeel 2 is de ‘DeviceControlActivity’. Deze activiteit koppelt de service klasse, ‘BluetoothLeService’, van onderdeel 3 aan de activiteit. Wanneer er gegevens tussen de activiteit en de service moeten worden verstuurd gebeurt dit via een broadcast. Een broadcast is een asynchroon proces waarbij data wordt verstuurd naar andere klassen en activiteiten die filteren op een bepaalde broadcast naam. Wanneer deze activiteiten of klassen een broadcast ontvangen zullen zij in een thread hun functie uitvoeren. Bij het aanroepen van de activiteit ‘DeviceControlActivity’ zal er aan de hand van het meegegeven hardware adres een verzoek tot verbinding met het apparaat worden ingediend via de Android API. De uitkomst van het tot stand brengen van de verbinding zal worden beantwoord in de asynchrone callback functie onConnectionStateChange in het service onderdeel. Dit service onderdeel zal vervolgens met een broadcast de resultaten terugsturen naar de ‘DeviceControlActivity’ zodat deze een pop-up melding kan geven over de status van de verbinding. Wanneer de status aangeeft verbonden te zijn wordt er automatisch gezocht naar alle services van het apparaat. Wanneer het apparaat het service UUID heeft van een roei meetsysteem, zal in deze service worden gezocht naar de juiste characteristic voor het opvragen van de data uit de sensor. Zie tabel 2.1 voor het UUID van de service en de characteristic. Als ook de juiste characteristic is gevonden wordt voor de zekerheid gecontroleerd of deze de optie notify heeft en zal deze indien aanwezig worden geactiveerd op de microcontroller. De microcontroller zal nu beginnen met het verzenden van datapakketten. Een datapakket bevat de hoek en de kracht van 5 samples en één pakketnummer, zoals beschreven in de eisen en figuur 2.2. Het pakketnummer wordt gebruikt om te detecteren of er pakketten zijn verloren. Hoe dit gedetecteerd wordt, wordt uitgelegd in sectie 7.2. Wanneer een datapakket wordt ontvangen, wordt door de Android API de callback onCharacteristicChanged in het service onderdeel aangeroepen. Deze functie controleert van welke characteristic het de data heeft ontvangen. Wanneer de data afkomstig is van de characteristic aangegeven in tabel 2.1 zal het datapakket door middel van een bit mask worden ontleed. De kracht en hoek zullen vervolgens per sample in de database worden opgeslagen samen met een sample nummer. Een sample nummer wordt verkregen uit een pakketnummer met de volgende formule: sample nummer = pakketnummer · 5 + sample index

sample index ∈ Z[0, 4]

(7.1)

Wanneer ook de hartslag van de roeier moet worden opgeslagen, kan dit in een aparte characteristic met tevens een andere zendsnelheid gebeuren. De callback functie onCharacteristicChanged zal dan, wanneer er data wordt ontvangen, worden aangeroepen en deze data in een losse thread kunnen verwerken. Op deze wijze is de code makkelijk uitbreidbaar voor nieuwe sensor inputs.

7.2

Dataverwerking

Dataverwerking zal op twee plaatsen in de software gebeuren: In het analyse scherm om de data achteraf te bekijken en in het roei scherm, wanneer de roeier real time data wil zien. In de volgende secties zullen de belangrijkste klassen voor het verwerken van de data worden uitgelegd. 28

HOOFDSTUK 7. COMPONENTEN ONTWERP

Klasse AngleCalc De klasse ‘AngleCalc’ heeft 2 belangrijke functies, namelijk het berekenen van de hoeksnelheid en het opvragen van de fase van de roeier: drive of recovery fase zoals besproken in sectie 1.3. Van de sensor is alleen de huidige hoek bekend. Om de hoeksnelheid te bepalen is het nodig de hoek te differentiëren. Uit onderzoek van K.P. Schaper en B.F. Oosterhuis[5] blijkt dat de kleinste foutmarge wordt behaald wanneer centrale differentiatie wordt toegepast. De centrale differentiatie is als formule 7.2 ge¨ımplementeerd. ω(x) =

Θ(x − 1) − Θ(x + 1) 2∆x

(7.2)

In deze formule is Θ(x + 1) twee samples verder dan Θ(x − 1) en ∆x is het tijdverschil tussen twee samples. De functie die formule 7.2 heeft ge¨ımplementeerd heet getAngularVelocity. Deze functie zorgt dus voor het opvragen van de hoeksnelheid. Telkens als er een nieuwe hoeksnelheid ω(x) opgevraagd wordt zal Θ(x + 1) moeten worden meegegeven aan deze functie. In de klasse AngeCalc wordt een array van 3 plekken groot bijgehouden waarin telkens de oudste hoeksnelheid wordt verwijderd en de nieuwste hoeksnelheid wordt toegevoegd wanneer getAngularVelocity wordt aangeroepen. Op deze wijze wordt er een geschiedenis van hoeken bijgehouden en is Θ(x − 1) bekend wanneer de hoeksnelheid wordt berekend. Bij de eerste 2 keer aanroepen van getAngularVelocity zal de functie nog niet weten wat Θ(x − 1) en Θ(x) zijn en wordt de hoeksnelheid gelijk gesteld aan 0. Om de fase van de roeier te bepalen wordt bij iedere aanroep voor het berekenen van de hoeksnelheid de hoeksnelheid opgeslagen in een array. Deze array bevat een geschiedenis van de afgelopen 3 hoeksnelheden, waarbij als de nieuwe hoeksnelheid wordt toegevoegd de oudste hoeksnelheid wordt verwijderd. De opgeslagen hoeksnelheden worden gebruikt om te bepalen of de roeier in een drive of recovery fase is. De functie driveDirection zal ‘false’ terug geven wanneer alle 3 de hoeksnelheden negatief zijn. Dit is gedaan zodat een onverwachte meetfout in de hoek dat resulteert in het omklappen van het teken van de hoeksnelheid, gefilterd kan worden.

Klasse PowerCalc De klasse ‘PowerCalc’ berekent aan de hand van de functie calculatePower het totale vermogen en de totale kracht in één slag. Als parameters heeft deze functie de kracht, de hoeksnelheid en de fase van de roeier. Alleen wanneer de fase van de roeier de drive fase is, zal het vermogen worden opgeteld bij het totaal vermogen. Wanneer in een andere klasse is gedetecteerd dat de slag opnieuw begint (hier wordt bij de klasse ‘ProcessData’ op terug gekomen) moet de functie reset worden aangeroepen die er voor zorgt dat het totale vermogen weer op 0 wordt gezet. Het vermogen wordt bepaald aan de hand van formule 7.3 van Hofmijster, Landman, Smith e.a.[26]. In deze vergelijking zijn twee assenstelsels gedefinieerd waarin x de richting is waarin de boot vaart en de x0 -y 0 is georiënteerd in de richting van de paal waar y 0 in de richting van de dol naar het handvat wijst. 0

x 0 0 Proeier = Fhandvat · (yhandvat − ypin ) · ωpaal + mroeier · x ¨roeier · x˙ boot

• Proeier : het geleverde vermogen van de roeier [W]. 0

x • Fhandvat : de kracht van de roeier op de paal [N].

29

(7.3)

7.2. DATAVERWERKING 0 0 ) de afstand tussen het handvat en het middelpunt van de dol [m]. • (yhandvat − ypin

• ωpaal de hoeksnelheid van de paal [rad/s]. • mroeier de massa van de roeier [kg]. • x ¨roeier de versnelling van de roeier [m/s2 ]. • x˙ boot de snelheid van de boot [m/s]. Deze vergelijking is op te delen in 2 termen: 0

x 0 0 )·ω 1. Fhandvat · (yhandvat − ypin paal

2. mroeier · x ¨roeier · x˙ boot De tweede term is uit onderzoek van G. van Wechem een factor 7 kleiner dan de eerste term. Het vermogen zal aan de hand van de eerste term met een factor 1,143 worden gecorrigeerd. Uit deel 1 van vergelijking 7.3 is te zien dat ook de afstand tussen het handvat en de dol bekend moet zijn, de overige variabelen worden namelijk al meegegeven in de parameters van de functie. Momenteel is deze afstand als een constante gedefinieerd, namelijk 0,8 meter. De bedoeling is echter dat er een settings scherm komt waarin de roeier deze afstand eenmalig in kan vullen en deze wordt opgeslagen op de smartphone. Doet de roeier dit niet dan zal de standaard waarde van 0,8 meter worden gebruikt.

Klasse ProcessData De klasse ‘ProcessData’ zorgt dat de klasse ‘PowerCalc’ en ‘AngleCalc’ samen komen. De belangrijkste functie is calculateData met de parameters voor de hoek, de kracht en de locatie. Hieronder wordt in stappen uiteengezet wat de functie doet: 1. Het aantal keer dat deze functie is aangeroepen wordt bijgehouden. Dit staat gelijk aan het aantal samples. 2. De hoeksnelheid wordt opgevraagd. 3. De fase van de roeier wordt opgevraagd. 4. Als de roeier van recovery fase naar drive fase gaat zie dan stap 5, anders ga naar stap 10. 5. Vraag het totale vermogen van een slag op en deel deze door het aantal keer dat de functie is aangeroepen. 6. Hetzelfde als stap 5 maar dan voor de kracht. 7. Bereken de tijd van één slag door het aantal keer dat de functie is aangeroepen maal de sample tijd. 8. Zet het aantal keer dat de functie is aangeroepen op 0. 9. Reset functie van de klasse ‘PowerCalc’ wordt aangeroepen. 30

HOOFDSTUK 7. COMPONENTEN ONTWERP 10. Bereken het vermogen met de kracht variabelen van de vorige keer dat de functie was aangeroepen en de bij stap 2 verkregen hoeksnelheid en bij stap 3 verkregen fase. Het berekende vermogen en kracht van één slag bij stap 5 en 6 worden beide opgeslagen in een array van 3 groot. De oudste variabelen wordt weer verwijderd en de nieuwste wordt toegevoegd. Zoals te zien in stap 4 wordt er alleen een nieuwe waarde in de array gezet wanneer de slag is afgelopen. Op deze wijze zal in de array altijd een volledige slagwaarden staan. Wanneer de kracht of het vermogen wordt opgevraagd wordt het gemiddelde van deze 3 waarden genomen. Bij stap 7 wordt de slagsnelheid bepaald om hiermee het aantal slagen per minuut te kunnen bepalen. De slagsnelheid wordt opgeslagen in een array van 3 groot net als de kracht en het vermogen. Hier wordt vervolgens het gemiddelde over genomen. De slagsnelheid is in milliseconden. Om het aantal slagen per minuut te bepalen wordt de berekening 60.000 uitgevoerd. Wanneer bij de initialisatie de slagsnelheid nog 0 bedraagt zal het slagsnelheid aantal slagen per minuut 0 terug geven en wordt de berekening overgeslagen om delen door nul te voorkomen. Ten slotte is er nog de totale roeitijd die wordt bijgehouden. In de smartphone wordt een timer gestart wanneer de roeier verbinding heeft gemaakt met het roei meetsysteem. Iedere seconde zal de nieuwe tijd van de starttijd worden afgetrokken om zo de tijd te bepalen die de roeier op het water is. Voor het bijhouden van tijd zijn verschillende mogelijkheden: 1. Er is een speciale klasse aanwezig voor het opvragen van de datum en tijd. 2. De functie System.currentTimeMillis() geeft de tijd in milliseconden. 3. De functie System.nanoTime() geeft de tijd in nanoseconden. Optie 1 is de langzaamste van de drie en te uitgebreid, aangezien ook de datum wordt opgevraagd. De datum moet dan met een filter worden verwijderd wat onnodig veel rekenkracht kost. Optie 2 en 3 lijken erg veel op elkaar. Echter wanneer bij optie 2 de tijd van de smartphone wordt aangepast, zal ook de tijd die opgevraagd wordt door de functie veranderen. Als een roeier in de boot zijn tijd van de smartphone aanpast klopt de roeitijd die wordt getoond derhalve niet meer. Daarom is gekozen voor optie 3, omdat deze functie in de processor een stamp bijhoudt en niet kan worden gewijzigd [27]. Tevens kan deze teller tot 292 jaar doortellen voordat deze een overflow veroorzaakt. Hetgeen meer dan voldoende is voor een roeisessie.

Verwerking in een thread Wanneer het systeem zich in het roei scherm bevindt, zie sectie 5.2, zal er een thread worden gestart die iedere 10 seconden zorgt dat het scherm van de gebruiker wordt ververst met nieuwe roei informatie. Deze thread zal uit de database met oplopende volgorde van sample nummers de data opvragen. Het startende sample nummer voor het opvragen van de data is het sample nummer waar de thread voor de laatste keer is gebleven met uitlezen. Het laatste sample nummer is het nummer wat tot dan toe als laatst is ontvangen. Vanaf het eerst opgevraagde nummer tot het laatste zal nu de functie calculateData uit de klasse ‘ProcessData’ worden aangeroepen met de verkregen hoek en kracht uit een sample nummer. Wanneer een volgend sample nummer minus het vorige sample nummer niet gelijk is aan 31

7.3. GPS één dan zijn er samples niet ontvangen. Vervolgens zal er voor de missende meetpunten een waarde worden bepaald. Dit wordt gedaan aan de hand van linearisering tussen de twee punten van de vermiste samples die wel bekend zijn. Zie figuur 7.1 voor een visuele weergave van het algoritme. De blauwe lijn geeft de kracht aan die is gemeten. Tussen de twee gestreepte lijnen zijn de samples die zijn verloren. De rode lijn stelt de gelineariseerde waarde voor die is bepaald tussen de twee bekende samples.

Figuur 7.1: Linearisering waneer pakketten zijn verloren. Let op: het assenstelsel is niet op echte meetgegevens gebaseerd Wanneer er samples als “verloren” worden aangegeven tussen een sample en het laatst ontvangen opgevraagde sample, kan het zijn dat deze tussengelegen pakketten nog binnen kunnen komen. Deze waarden in de samples worden dan ook niet gelineariseerd. De thread zal het start sample voor de volgende keer nu niet op het laatste sample nummer zetten maar het een-na-laatste bekende sample nummer. Bij een volgende aanroep gebeurt het algoritme opnieuw en als er dan nog geen tussen samples zijn ontvangen worden de missende waarden alsnog gelineariseerd.

7.3

GPS

De GPS wordt gebruikt om de locatie van de gebruiker te bepalen. Dit wordt gedaan in een thread in de ‘DeviceControlActivity’ klasse. Er wordt om de 8 seconden een update gevraagd van de locatie. Door de opgevraagde punten steeds met elkaar te vergelijken kan de afgelegde afstand en uiteindelijk ook de snelheid bepaald worden.

7.3.1

GPS werking

GPS kan worden gebruikt om accuraat de locatie te bepalen. Om de locatie te bepalen moet de locatie worden opgevraagd. Dit wordt gedaan door om de zoveel tijd een locatie update op te vragen via GPS of de netwerk provider in combinatie met WIFI. GPS is accurater, maar werkt niet binnen gebouwen en kan hinder ondervinden van hoge gebouwen in de 32

HOOFDSTUK 7. COMPONENTEN ONTWERP omgeving[28]. De netwerk provider is over het algemeen sneller en werkt binnen, maar is ook minder accuraat dan GPS. Volgens [29] heeft de locatie via de netwerk provider een accuratie tussen 25-200 meter en GPS tussen 1-50 meter. Daar zit een groot verschil in. Er moet hier dus een afweging worden gemaakt tussen snel en accuraat. In dit geval wordt er gebruik gemaakt van beide. Bij beide providers worden de locaties opgevraagd. Nadat ze zijn opgevraagd wordt de accuratie van de opgevraagde locaties met elkaar vergeleken. De locatie met de beste accuratie zal worden gebruikt voor de afstandsbepaling. Hierdoor zal er altijd de best mogelijke accuratie gebruikt worden om de locatie te bepalen. Als de applicatie wordt gebruikt kan het zijn dat de GPS nog uitstaat. Om er voor te zorgen dat de gebruiker hierop geattendeerd wordt zal er een scherm verschijnen in de ‘DeviceScanActivity’. Er zal een scherm komen die vraagt of de gebruiker GPS alsnog wil aanzetten. Als de GPS dan wordt aangezet kan de GPS last hebben van een zogenaamde ‘cold start’. Dit houdt in dat de GPS een bepaalde tijd nodig heeft om de eerste locatie te vinden, dit wordt ook wel de ‘Time to first fix’ genoemd of ook wel de TTFF. De TTFF kan bij GPS liggen tussen 5-60 seconden [29]. Bij de netwerk provider is dit maar tussen de 1-3 seconden. In de huidige versie is het niet gelukt om de TTFF omlaag te brengen naar de gewenste 1-3 seconden. Deze schommelt nu tussen de 15 en 60 seconden. Om de TTFF te verlagen kan ook de laatst opgeslagen locatie gebruikt worden, maar deze kan van de huidige locatie af liggen wat met de afstandsbepaling een grote afwijking tot gevolg kan hebben.

7.3.2

Afstandsbepaling

De afstand wordt bepaald door steeds de afstand tussen twee punten te bepalen om vervolgens deze afstand op te tellen bij de totale afstand. In principe zou dit goed kunnen werken. Zelfs bij afwijkingen van de opgevraagde locatie kan deze fout geminimaliseerd worden door de tijd tussen elk sample te vergroten. Hier komt ook direct een van de problemen. GPS heeft, zoals eerder gezegd een foutmarge van tussen de 1-50 meter. Dit hangt af van de gebruikte provider en van hoeveel satellieten de GPS op weet te pikken. Het gevolg is dat bij elke meting een fout wordt ge¨ıntroduceerd. Deze fout zal bij elke volgende meting dus groter worden. Dit kan op verschillende manieren aangepakt worden. Een van deze mogelijkheden is de sample tijd vergroten. Omdat de roeiers meestal grote afstanden alleen rechtdoor varen zou dit een optie kunnen zijn. Het probleem is: om de foutmarge binnen de 5 % (zie specificaties 2.1) moet de sample tijd erg groot worden. Als er wordt uitgegaan van een snelheid van 20 km/h (5,6 m/s) mag de maximale foutmarge maar 1,4 meter zijn bij een sample tijd van 5 seconden. Dit kan niet behaald worden zelf op het moment dat de afwijking per meting 1 meter is. De sample tijd moet derhalve groter worden. Er is uiteindelijk gekozen voor een sample tijd van 8 seconden. Deze is bepaald door middel van vergelijking 7.4. min af wijking

2

af gelegde af stand max f out 0,05 = = ≈ 8 seconden gemiddelde snelheid gemiddelde snelheid 5, 6

(7.4)

Het probleem is hier alleen nog niet helemaal opgelost. Als de afwijking groter is dan 1 meter per meetpunt zal de fout nog steeds oplopen. Alleen er moet een afweging gemaakt worden tussen het nog steeds real-time kunnen tonen van de data en hoe accuraat de afgelegde afstand is, waardoor verder verhogen van de tijd geen oplossing is. 33

7.3. GPS Er is daarom ook voor gezorgd als de roeiboot langzaam beweegt, deze niet alle kleine plaatsveranderingen meeneemt. Als de plaatsverandering sinds het laatst opgeslagen punt kleiner is dan 3 meter, dan zal deze niet worden toegevoegd aan de afgelegde afstand. Er worden dan nieuwe metingen gedaan totdat er een grotere plaatsverandering is dan 3 meter.

7.3.3

Snelheidsbepaling

Voor de applicatie is gespecificeerd dat de snelheid bepaald moet worden. GPS heeft alleen een afwijking waardoor in eerste instantie het niet mogelijk leek in dit stadium om snelheid er in te verwerken binnen de gestelde specificaties. Door de combinatie van de netwerk provider en GPS is de fout alleen van de locatie bepaling drastisch verminderd. Hierdoor zou het mogelijk zijn om als nog snelheid te implementeren. Alleen deze nauwkeurigheid werd te laat in het ontwerpproces bereikt om snelheid nog toe te voegen aan de applicatie.

7.3.4

Aanbevelingen

Om ervoor te zorgen dat de GPS betere locatiebepalingen kan doen en ook de snelheid kan bepalen zou er gekeken kunnen worden naar de combinatie van een accelerometer, GPS en een Kalman filter [30]. Ook zou er misschien door middel van de ‘kleinste kwadraten’ methode een betere methode voor de afstand te berekenen gemaakt kunnen worden. Hierdoor kan door meerdere meetpunten van de GPS de ‘echte’ locatie worden bepaald. Als laatste zou snelheid alsnog ge¨ımplementeerd moeten worden. Met de huidige GPS zou het halen van de eis van 5 % accuratie nog lastig kunnen worden, maar in combinatie met een accelerometer zou dit een stuk nauwkeuriger kunnen.

34

Hoofdstuk 8

User Interface Ontwerp 8.1

Overzicht

Er is gekozen om de applicatie zo simpel mogelijk te houden. Als de applicatie geopend wordt zijn daarom op het hoofdmenu maar twee knoppen te vinden. Deze corresponderen met twee functies van de applicatie, namelijk het meten van de roei prestaties en het analyseren van de gemeten data achteraf.

8.2

Ontwerpen

Voor het project was beperkte tijd beschikbaar en dus lagen de prioriteiten bij de functionaliteit van de applicatie in plaats van het ontwerp, maar er is natuurlijk rekening mee gehouden. Er is vooral gekeken naar hoe de data het best gepresenteerd kon worden en daarbij een zo goed mogelijke interface te ontwerpen, zodat de gegevens logisch gepresenteerd worden. Als eerste is er het analyse gedeelte van de applicatie. Op het moment dat vanaf het hoofdmenu (zie figuur 8.2a) naar het analyse gedeelte wordt gegaan, zal eerst een lijst van trainingen getoond worden. De gebruiker kan dan door op de training te klikken de training verder kunnen analyseren. Er is hier gekozen om ook de datum te tonen van de training. Hierdoor kan de gebruiker makkelijker terugvinden welke training geanalyseerd moet worden. Als de gebruiker de training heeft geanalyseerd, zal een nieuwe activiteit gestart worden. Hier zijn drie schermen te vinden waar men tussen kan swipen, zie figuur 8.1. Er is voor deze manier van navigeren gekozen, zodat de gebruiker snel kan switchen tussen deze schermen zonder steeds op knoppen te moeten drukken. Het nadeel hiervan is dat deze beweging ook wordt gebruikt in het derde scherm ‘Force-time Graph’. De bewegingen zitten elkaar daardoor in de weg. Dit zou in een volgende versie verholpen kunnen worden door een duidelijke knop te maken die naar het vorige scherm navigeert. Het voordeel van het sneller door de gegevens heen kunnen gaan heeft in weegt in onze overweging zwaarder mee, waardoor dit een goede oplossing is. Ten tweede is er het roeigedeelte van de applicatie, zie figuur 8.2b. Als er vanaf het hoofdmenu geklikt wordt op de knop ‘Rowing’ dan zal er als eerste gescand worden voor de sensoren. Het kan soms zijn dat de gebruiker nog geen Bluetooth heeft geactiveerd. Als dit 35

8.3. SCHERMRESOLUTIE

Figuur 8.1: Analyse interface en de schermen waar tussen gewisseld kan worden het geval is zal er een pop-up scherm komen om te vragen of de gebruiker zijn bluetooth alsnog wil activeren. Hetzelfde geldt ook voor GPS. Als Bluetooth niet is geactiveerd dan wordt de gebruiker teruggestuurd naar het hoofdmenu. Als er een Bluetooth low energy apparaat gevonden wordt zal er een blauwe balk verschijnen met informatie over dit apparaat. Hier kan vervolgens op geklikt worden. Indien dit apparaat de roei sensor is, wordt hier de verbinding mee opgezet, zodat de data ontvangen kan worden. Na het klikken op de blauwe balk kan er begonnen worden met roeien. In het scherm waar de gebruiker zich dan bevindt zal alle data getoond worden zoals vermogen, tijd, afstand en dergelijke. Deze data zal regelmatig ververst worden, zodat de gebruiker een duidelijk beeld kan krijgen van de geleverde prestaties. Hoe er tussen alle schermen gewisseld kan worden wordt duidelijk gemaakt in figuur C.1 in Appendix C.

8.3

Schermresolutie

Tijdens het ontwikkelen van de applicatie is er geen rekening gehouden met ondersteuning voor verschillende schermresoluties. Hierdoor zal voor schermen kleiner dan 4 inch de grafiek in verticale oriëntatie moeilijk leesbaar worden, doordat het scherm niet goed meeschaalt. Er is maar met één schermresolutie rekening gehouden. Voor grotere schermen zal dus veel van de ruimte leeg vallen. De layout schaalt namelijk wel mee, maar de tekst of knoppen niet. Hierdoor kan de tekst wat klein overkomen. Voor kleine schermen is precies het omgekeerde het geval. Doordat de layout mee schaalt, maar de tekst niet, zal alles zeer dicht op elkaar komen. Dit kan opgelost kunnen worden door meerdere layouts te maken voor verschillende grootten van schermen of de tekst op een bepaalde manier mee te laten schalen met het scherm.

36

HOOFDSTUK 8. USER INTERFACE ONTWERP

(a) Hoofdmenu interface

(b) Roei interface waar alle data getoond worden

Figuur 8.2: (a) Het hoofdmenu; en (b) Interface tijdens het roeien

37

8.3. SCHERMRESOLUTIE

38

Hoofdstuk 9

Foutenanalyses en testen 9.1

Benodigde hardware smartphone

Om de applicatie te kunnen gebruiken moet de smartphone beschikken over het Android besturingssysteem versie 4.4 (KitKat). Wanneer de smartphone niet beschikt over deze versie, kan de applicatie niet worden ge¨ınstalleerd. De smartphone moet tevens beschikken over GPS en Bluetooth low energy. Als deze functies niet aanwezig zijn zal de applicatie niet werken zoals bedoeld. Indien een smartphone wel beschikt over GPS en Bluetooth low energy, maar deze staan uit tijdens het opstarten van de applicatie, zal de applicatie uit zichzelf verzoeken deze alsnog aan te zetten. Als de Bluetooth niet aangezet wordt, zal de gebruiker terug worden verwezen naar het hoofdmenu en niet kunnen beginnen met roeien totdat deze alsnog aangezet zal worden. Gebruikers die de applicatie hebben ge¨ınstalleerd zonder GPS of Bluetooth low energy module maar wel met Android versie 4.4 zullen na het openen van het roei scherm een melding krijgen waarin te lezen is dat hun apparaat niet geschikt is.

9.2

Pakketten verliezen

Tijdens het verzenden is er altijd een mogelijkheid dat er pakketten verloren gaan. Dit kan leiden tot meerdere problemen. Ten eerste tijdens het verwerken van de data zal er een pakket ontbreken. Hierdoor wordt de berekening minder nauwkeurig. Het tweede probleem is dat in de analyse een deel van de data mist om de grafiek te maken. In de volgende alinea’s wordt besproken hoe deze problemen worden aangepakt. Om de berekening van het vermogen zo dicht mogelijk bij het werkelijke slagvermogen te houden, indien er pakketten zijn verloren, worden de samples binnen een verloren pakket geschat. Aan de hand van het eerstvolgende pakket dat goed binnenkomt en het daarvoor goed binnengekomen pakket wordt met behulp van een linearisering de tussengelegen vermiste samples geschat. Dit wordt gedaan zoals uitgelegd in sectie 7.2. Wanneer er echter meer dan 2 pakketten(10 samples) ontbreken, kan de linearisering niet meer worden toegepast, omdat dit mogelijk niet in de buurt van de werkelijkheid zal liggen. Dit is beredeneerd op het maximale slag tempo van 50 slagen per minuut. Hier zullen 60 samples de drive fase van de roeier presenteren. Indien hier 3 pakketten zullen ontbreken, mist 25 % van de drive data. De slag moet dan niet worden meegenomen in de berekening van het vermogen per 39

9.3. CONNECTIE VERLIEZEN

Figuur 9.1: De blauwe lijn presenteert hoe de grafiek had moeten lopen, maar de rode lijn laat zien hoe de grafiek er uit zal zien als de data verloren gaat tussen 2 en 7 seconden, en derhalve geen betere grafiek oplevert slag over 10 seconden. Dit is echter nog niet ge¨ımplementeerd in de code. Of de aanname van 2 ontbrekende pakketten geldig is moet blijken uit testen op het water. Om een goede grafiek te maken zijn zoveel mogelijk data punten nodig. Deze zullen dan met een lijn verbonden worden en zo ontstaat er via de graphview API een grafiek. Bij het missen van data zal de grafiek de punten gewoon overslaan en omdat er een sample nummer gekoppeld is aan de samples zal de data wel op de goede plek komen, alleen met ontbrekende data daar tussen. De GraphView API werkt zo dat deze punten als nog dan verbonden zullen worden met een rechte lijn, ook al missen er data punten tussen. Bij één of twee data-punten is dit geen groot probleem, maar als er ongeveer een slag aan samples ontbreekt kunnen er vreemde grafieken gaan vormen, zie figuur 9.1. In het figuur is te zien dat de rode lijn direct twee punten verbindt, maar dit geeft niet goed aan wat er echt gebeurt. Ook zal de grafiek geen melding geven dat er iets fout gaat. Om dit probleem te voorkomen worden alle ontbrekende samples in de grafiek nu op nul gezet. Hierdoor blijft de vorm zo goed als bewaard. In de toekomst zou aan ontbrekende samples nog een andere kleur in de grafiek moeten worden toegevoegd, zodat de gebruiker direct kan zien dat er iets fout is. Alleen dit vergt grote veranderingen in de graphview API, waardoor dit nu niet te realiseren is.

9.3

Connectie verliezen

Als de connectie verloren gaat tijdens het roeien, zal er een pop-up verschijnen die de gebruiker vertelt dat de connectie verloren is. Als eerste zal de applicatie dan zelf proberen opnieuw verbinding te maken. Hier geeft de applicatie dan ook melding van. Als de applicatie weer verbinding maakt zal er weer een pop-up verschijnen die vertelt dat de verbinding weer hersteld is. Het kan echter ook voor komen dat de applicatie de verbinding niet zal kunnen 40

HOOFDSTUK 9. FOUTENANALYSES EN TESTEN herstellen. In dat geval moet de gebruiker zelf terug naar het menu waar naar de Bluetooth apparaten gezocht kan worden om opnieuw verbinding te maken met de microcontroller.

9.4

Testen

In deze sectie worden onderdelen van de applicatie getest. Deze testen zijn uitgevoerd met een sample rate van 40 samples/s, dus een ontvangsnelheid van 8 pakketten/s, tenzij anders vermeld.

9.4.1

JUnit: Dataverwerking

Een JUnit test is een stuk code dat speciaal is gemaakt om een functie te controleren in het hoofdprogramma. Gekozen is de data verwerking te testen en dan de in sectie 7.2 besproken klasse: ‘PowerCalc’, ‘AngleCalc’ en ‘ProcessData’. De hoeksnelheid is getest door verschillende hoeken in de functie getAngularVelocity als parameter mee te geven en de hoeksnelheid te controleren. Als onderdeel van de test zijn de volgende hoeken meegegeven: 5,10 , 5,13 en 5,15 Verwacht werd dat de eerste 2 aanroepen 0 terug gaven en de derde aanroep 1. De derde uitkomst zal wanneer met de hand berekend 1 moeten terug geven, zie vergelijking 9.1. 5, 15 − 5.10 =1 (9.1) 50 ms Echter geeft de functie 1,0000038 terug. Dit is te verklaren doordat er floats worden gebruikt. Deze kunnen namelijk niet ieder getal exact presenteren door het eindig aantal bits. Deze fout is echter verwaarloosbaar klein en de test kan worden gezien als geslaagd. De ‘PowerCalc’ klasse met de functie calculatePower is op dezelfde wijze getest als de ‘AngleCalc’ klasse. Ook deze functie voldeed aan het verwachte antwoord. De klasse ‘ProcessData’ is getest door een gesimuleerde slag te creëren van 101 samples en deze mee te geven aan de parameters van de functie calculateData. De gesimuleerde slag is te zien in figuur 9.2. Merk op dat dit geen zeer reële waarden zijn, maar voor het testen van de functie voldoen. De totaal geleverde kracht van alle samples bij elkaar bedraagt volgens formule 9.2, 2500 N. 25 X

n·4+

n=0

50 X

(100 − 4(n − 25)) +

n=26

100 X

0 = 2500

(9.2)

n=51

2500 De gemiddelde kracht over de gehele slag bedraagt dan = 24, 7525. In de JUnit 101 test wordt deze waarde goedgekeurd wanneer er een afwijking van 0,0001 naar boven of beneden is toegestaan. Hieruit kan worden geconcludeerd dat de functie werkt. Ook het vermogen van de gehele slag is berekend om te controleren of deze ook naar behoren werkt. In formule 9.3 wordt het totaal geleverde vermogen van alle samples berekend. Hierin is 80 de hoeksnelheid in rad/s van figuur 9.2 en 0,8 is de afstand in meters van het handvat tot de dol van de paal. 25 X n=0

n·4·0, 8·80·1, 143+

50 X

(100−4(n−25))·0, 8·80·1, 143+

n=26

100 X

0·0, 8·80·1, 143 = 182880

n=51

(9.3) 41

9.4. TESTEN

Figuur 9.2: Dummy data van de kracht en de hoek die is gebruikt in de JUnit tests 182880 = 1810, 7 bedraagt. Met een afwijking van Hieruit volgt dat het vermogen per slag 101 0,0068 blijkt dit ook te kloppen in de code. Deze afwijking kan komen doordat er is afgerond in zowel de code als het met het narekenen. Ten slotte is de berekening van het aantal slagen per minuut gecontroleerd. Iedere slag duurt 101 samples en de tijd tussen 2 samples bedraagt 25 ms. Het aantal slagen per minuut 60 = 23, 7624. Afgerond naar beneden is 23. Dit zelfde blijkt uit de JUnit is dan 101 · 0.025 test te komen. Uit de test blijkt dat de dataverwerking naar behoren functioneerd. Voor een overzicht van alle geteste functies zie appendix B.

9.4.2

CPU en RAM verbruik

Iedere smartphone waar Android 4.4 op draait heeft minstens 512 MB RAM [31]. Als de applicatie gedraaid wordt, zonder andere applicaties op de achtergrond, gebruikt deze ongeveer tussen de 60 en 75 MB aan RAM zie figuur C.3, C.4 en C.5. In deze overzichten dient er gekeken te worden naar de “private dirty” om het verbruikte RAM te vinden van de applicatie. De 75 MB aan geheugen wordt alleen gehaald als er een grote hoeveelheid aan data in één keer moet worden ingeladen vanuit de database. Dit gebeurt in het analyse menu. Dit kost relatief veel tijd, omdat er veel data moet worden opgevraagd en verwerkt. Uit de private dirty blijkt dat de applicatie ruim binnen de 512 MB aan geheugen blijft waardoor er genoeg geheugen is bij elke Android 4.4 toestel waar deze applicatie voor is ontwikkeld. De toestellen waar op getest zijn (Google Nexus 5 en Nexus 7 (2013 model)) konden beide de applicatie draaien. Beide toestellen hadden bij het openen van een lange training in het analyse menu last van dat de applicatie traag reageert. Dit komt doordat de applicatie in één keer alle data van de training op vraagt uit de database. De CPU moet dan een 42

HOOFDSTUK 9. FOUTENANALYSES EN TESTEN grote hoeveelheid data laden en verwerken om dit in de grafiek te kunnen plotten. Het gevolg hiervan is dat de CPU het zwaar krijgt en het dus meer tijd kost. Hier zou nog voor geoptimaliseerd kunnen worden door alleen een deel van de data te laden, waardoor een deel van de grafiek maar geplot wordt. Tijdens het scrollen door de grafiek zou overige data nog kunnen worden geladen en verwerkt indien de grafiek dat nodig heeft

9.4.3

Data doorvoersnelheid

Om de data doorvoersnelheid van 3,2 kb/s te testen moet er worden gesampled met een sample rate van 100 samples/s. Dit betekent dat er 20 pakketten/s worden ontvangen. Bij deze snelheid werd echter geconstateerd dat de applicatie na iedere aanroep om het scherm te verversen hier enkele seconden langer over deed. Na 6 minuten kreeg de bluetooth buffer een overflow en liep de applicatie vervolgens vast. De oorzaak van dit probleem ligt in het feit dat de dataverwerkings thread beschreven in 7.2 boven op de user interface draait (runOnUiThread) samen met de GPS thread en de tijd thread, zie figuur C.6. De runOnUiThread is bedoeld om binnen Android middelmatige berekeningen uit te voeren en om vervolgens direct de user interface te bewerken. Wanneer een runOnUiThread eenmaal zijn main heeft gestart zullen alle functies binnen de main eerst worden uitgevoerd alvorens er gewisseld wordt naar een andere runOnUiThread. Omdat de dataverwerkings thread iedere 10 seconden wordt aangeroepen zal deze 1000 samples moeten verwerken, dit kost 492 ms. Een betere implementatie zou daarom zijn dat de runOnUiThread’s worden ge¨ımplementeerd als losse threads wat te zien is in figuur C.7. Wanneer de berekeningen in de dataverwerkings thread klaar zijn kan vervolgens een callback functie worden aangeroepen die de user interface update.

9.4.4

Meetresultaten totaalsysteem

In figuur 9.3 en 9.4 zijn de resultaten te zien van de metingen met het totaalsysteem. In figuur 9.3 is de hoek in graden (y-as) te zien ten opzichte van de tijd in seconde (x-as). Vanaf 36 seconden werd er versneld. Dit is terug te zien in de meetresultaten, want het hoek bereik wordt in een kortere tijd afgelegd. Ook bij de kracht meting is dit terug te zien. Daar wordt vanaf 36 seconden een hogere kracht waargenomen, doordat de roeier sneller moet roeien en derhalve ook meer kracht levert. Uit deze meting kan worden geconstateerd dat de verschillende onderdelen samen kunnen werken.

43

9.4. TESTEN

Figuur 9.3: Meetresultaten van totaalsysteem: Hoek

Figuur 9.4: Meetresultaten van totaalsysteem: Kracht

44

Hoofdstuk 10

Conclusie Het doel van dit project was om een Android applicatie te ontwerpen die real-time de data aan de gebruiker kan presenteren, maar ook achteraf kan analyseren. Dit doel is behaald. Echter niet alle doelen binnen de specificaties zijn behaald. Tabel 10.1: Resultaat vs de specificaties Wat Platform Communicatie Bluetooth data doorvoersnelheid Format bluetooth BLE service UUID BLE characteristic UUID Benodigde informatie

Optionele informatie

Opslag

Specificaties Android 4.4 Bluetooth low energy 3,2 kb/s Zie figuur 2.2 00003b01-0000-1000-8000-00805f9b34fb 00003b02-0000-1000-8000-00805f9b34fb - Afstand (GPS) 50 m nauwkeurigheid over 2 km (nauwkeurigheid van 2,5 %) - Snelheid ten opzichte van aarde (GPS) (5 % nauwkeurigheid) - Geleverde vermogen roeier (maximale afwijking van 5 %) - Geleverde kracht roeier - Geleverde SPM roeier - Iedere 10 sec updaten van data (tijdens het roeien) - Hartslag - Snelheid ten opzichte van water (5 % nauwkeurigheid) Lokale database

Resultaat X X 7 X X X ? 7 X X X X 7 7 X

Zoals te zien in tabel 10.1 is aan bijna alle eisen voldaan. Hierdoor is er een goede basis voor de applicatie. De data kan real-time worden ontvangen en verwerkt. De database zorgt dat alle binnengekregen data kan worden opgeslagen en is zo ontworpen dat in de toekomst de applicatie makkelijk uitgebreid kan worden zonder dat de database dient te 45

worden aangepast. De data doorvoersnelheid van 3,2 kb/s kan de applicatie nog niet aan. Dit ligt aan hoe de applicatie is opgebouwd omtrent de UI threads. Bij het testen bleek dat bij een data doorvoersnelheid van 1,28 kb/s de applicatie wel goed functioneerde. Verder is de communicatie zo ontworpen dat in de toekomst het geen probleem is meerdere sensoren toe te voegen aan het systeem. Dit kan worden gerealiseerd met extra BLE services en bijbehorende characteristics. De sensoren zijn ontworpen om binnen de 5 % nauwkeurigheid te blijven van het vermogen en de JUnit tests uitwezen dat de afwijking van een berekening verwaarloosbaar klein is, daarom is de nauwkeurigheid van 5 % voor het vermogen behaald. Bij de afstandsbepaling staat in de tabel een vraagteken. De reden hiervoor is dat de GPS is ge¨ımplementeerd, maar dat de nauwkeurigheid moeilijk is vast te stellen. Per meting kan er namelijk een afwijking zijn van tussen de 1-50 meter. Over het algemeen worden er alleen metingen gedaan met accuratie van tussen de 4-20 meter. Het moet nog in de praktijk getest worden wat de afwijking over bijvoorbeeld 2 kilometer is. Als deze binnen de 5 % valt dan wordt voldaan aan de eisen en kan de snelheid ten opzichte van de aarde worden ge¨ımplementeerd. Tot slot is wegens de grote tijdinvestering in de GPS en Bluetooth low energy het helaas niet meer mogelijk geweest om te kijken naar de optionele informatie (hartslag en snelheid ten opzichte van het water).

46

Hoofdstuk 11

Aanbevelingen Zoals aangegeven in de conclusie zijn er nog punten waar het product uitgebreid of geoptimaliseerd kan worden. Sommige essentiële informatie is nog niet aanwezig in de applicatie of heeft nog een te grote afwijking. Voor het huidige product zou als eerste opnieuw gekeken moeten worden naar de GPS. Per meting kan er een fout zijn. Deze fout kan zich accumuleren, waardoor over grotere afstanden deze fout behoorlijk kan oplopen. Deze fout is geprobeerd minimaal te houden door een sampletijd van 8 seconden. Hierdoor zou de fout geminimaliseerd worden, maar bij grotere afwijkingen zal dit alsnog een probleem kunnen zijn. Door gebruik van meerdere meetpunten en daarmee een ‘gemiddeld’ punt te bepalen zou de fout nog verder verminderd kunnen worden. Dit zou gedaan kunnen worden door de kleinste kwadraatmethode. Als de fouten eenmaal geminimaliseerd zijn (lager dan 5 %), dan zou uit deze data ook de snelheid ten opzichte van de aarde kunnen worden bepaald. Wanneer er te veel pakketten worden verloren moet de slag niet worden meegenomen in de gemiddelde vermogensberekening, omdat er dan een verkeerde waarde voor het vermogen wordt berekent. Bij het zoeken naar Bluetooth low energy apparaten moeten alleen de apparaten getoond worden die een roei sensor zijn. Dit kan aan de hand van een filter, die filtert op een afgesproken systeem UUID. Om de database te verbeteren moet er in de row-package van de ID een foreign key worden gemaakt en van de sampleNum een primary key. Hierdoor kan er worden voorkomen dat er een dubbele invoer kan komen van een sample in de database. Wanneer hogere data doorvoersnelheden moeten worden behaald, zullen de runOnUiThread’s moeten worden vervangen door losse threads zoals in figuur C.7. Om het product uit te breiden zou de data vergeleken moeten kunnen worden tussen de roeiers uit dezelfde boot. De microcontroller moet dan in het bezit zijn van een ‘realtime clock’ (RTC). Deze RTC moet wanneer er wordt gestart met roeien gesynchroniseerd worden met de tijd van de telefoon. De telefoon synchroniseert zijn tijd met het telecom netwerk, waardoor alle telefoons dezelfde tijd hebben. Data pakketten zullen in plaats van een pakketnummer een tijd mee krijgen waardoor het vergelijken van de data mogelijk wordt. Het synchroniseren met de microcontroller wanneer de roeier start is nodig, zodat de mogelijke afwijking van de RTC na een run periode van bijvoorbeeld een maand weer wordt gereset. Als extra uitbreiding zou de coach ook real-time mee kunnen kijken met de roeier. Met 47

de bestaande netwerk topologieën van BLE is dit niet mogelijk. Ant+ kan wel een topologie creëren waarbij meerdere apparaten gegevens kunnen ontvangen van de sensoren. Tevens is Ant+ ook energie zuinig en heeft een data doorvoersnelheid die voldoet aan de eisen. Als deze functies zijn ge¨ımplementeerd zou de applicatie getest moeten worden door gebruikers die niet mee hebben gewerkt aan dit project. Door hun feedback zou de applicatie en vooral de gebruikersinterface verbeterd moeten worden. Er zou gelet moeten worden of het navigeren door de applicatie natuurlijk aanvoelt voor de gebruiker. Dit vooral met het oog op het swipen in het analyse scherm en het navigeren in de grafiek.

48

Bibliografie [1] J. Brinkman, De modulaire methode - Theorieboek roeien, Naarden, December 2009. [2] “Care of the young athlete patient education handouts,” american Academy of Pediatrics. [Online]. Available: http://patiented.aap.org/content2.aspx?aid=7326& refURL= [3] “Concept 2 performance monitors.” [Online]. Available: http://www.concept2.com/ indoor-rowers/performance-monitors [4] R. L. Leijsen and T. Beintema, “Portable instrument panel for rowers krachtsensor,” Technical University of Delft, 2014. [5] K. P. Schaper and B. F. Oosterhuis, “Portable instrument panel for rowers hoekmeting en hardware integratie,” Technical University of Delft, 2014. [6] J. Fingas, “Android climbed to 79 percent of smartphone market share in 2013, but its growth has slowed,” januari 2014. [Online]. Available: http: //www.engadget.com/2014/01/29/strategy-analytics-2013-smartphone-share/ [7] “Rowx,” rowX. [Online]. Available: http://www.webasport.at/index.php?option= com content&view=article&id=5&Itemid=6 [8] “Concept 2 display,” concept 2 display. [Online]. Available: indoorsportservices.co.uk/assets/images/guide/pm3 displaysplit.jpg

http://www.

[9] “Runkeeper.” [Online]. Available: http://runkeeper.com/ [10] K. Grassie, “Easy handling and security make nfc a success,” Card Technology Today, vol. 19, pp. 12 – 13, oktober 2007. [11] “Near field communication.” [Online]. Available: http://developer.android.com/guide/ topics/connectivity/nfc/index.html [12] L. Snol, “802.11n in 87% of wi-fi smartphones by 2014.” [Online]. Available: http: //www.pcworld.idg.com.au/article/332225/802 11n 87 wi-fi smartphones by 2014 [13] “Wireless lan medium acces control (mac) and physical layer (phy) specifications,” oktober 2009. [14] N. Warty, R. K. Sheshadri, W. Zheng, and D. Koutsonikolas, “A first look at 802.11n power consumption in smartphones,” University at Buffalo, SUNY, 2012. 49

[15] Burst Transfers, ANT, 2009, revision 2.1. [Online]. Available: http://www.thisisant. com [16] ANT Message Protocol and Usage, ANT, juli 2007, revision 2.9. [17] “Bluetooth basics.” [Online]. Available: http://www.bluetooth.com/Pages/Basics.aspx [18] “Bluetooth specification version 2.1 + edr,” 2007. [19] J. Decuir, “Bluetooth 4.0: Low energy,” 2010, standards Architect, CSR plc; IEEE Region 6 NW Area chair. [20] “Bluetooth specification version 4.0,” 2010. [21] K. Townsend, C. Cuf´ı, Akiba, and R. Davidson, Getting Started with Bluetooth Low Energy: Tools and Techniques for Low-Power Networking. O’Reilly Media, Inc., 2014. [22] J. Rowberg, “Ble master/slave, gatt client/server, and data rx/tx basics,” 2013. [Online]. Available: https://bluegiga.zendesk.com/entries/25053373--REFERENCEBLE-master-slave-GATT-client-server-and-data-RX-TX-basics [23] D. Smith, “Bluetooth smart for android.” [Online]. Available: doubleencore.com/2013/12/bluetooth-smart-for-android/

http://www.

[24] “Graphview api.” [Online]. Available: http://android-graphview.org/ [25] A. API, “Bluetoothlegatt,” bluetooth low energy Generic Attribute Profile example code. [26] M. J. Hofmijster, E. H. J. Landman, R. M. Smith, and A. J. K. van Soest, “Effect of stroke rate on the distribution of net mechanical power in rowing,” Journal of Sports Sciences, vol. 4, no. 25, pp. 403–411, 2007. [27] “Class system,” java 2 Platform Standard Ed. 5.0. [Online]. Available: //docs.oracle.com/javase/1.5.0/docs/api/java/lang/System.html

http:

[28] “Gps accuracy and limitations.” [Online]. Available: http://earthmeasurement.com/ GPS accuracy.html [29] N. Vallina-Rodriguez, J. Crowcroft, A. Finamore, Y. Grunenberger, and K. Papagiannaki, “When assistance becomes dependence: Characterizing the costs and inefficiencies of a-gps,” Dec. 2013. [30] H. Hermsen, “Using gps and accelerometer data for rowing race tracking.” [Online]. Available: http://www.ai.rug.nl/∼mwiering/Thesis Harm Hermsen.pdf [31] “Android kitkat.” [Online]. Available: https://developer.android.com/about/versions/ kitkat.html

50

Appendix

51

ˆ A. ENQUETE

A

Enquˆ ete

Tijdens het roeien 1. Wat voor data zou je willen terug zien tijdens het roeien? 2. In welke vorm zou je deze data willen zien? Grafieken of cijfers? 3. Zou jij live grafieken willen zien op de telefoon? Ook al zou dat betekenen dat je tussen pagina’s zou moeten swipen tijdens het roeien? 4. Hoe vaak denk je naar het scherm te gaan kijken? En hou je het scherm voor je?

Na het roeien 1. Wat voor data zou je willen terug zien na het roeien? 2. In welke vorm zou je deze data willlen terug zien? Grafieken of cijfers? 3. Hoe zou je het scherm willen hebben tijdens analyseren van de data?

Computer 1. Zou je de data willen kunnen analyseren op de computer of online?

Etc 1. Heb je programmeerervaring en zou je er dan zelf aan de app willen kunnen sleutelen? 2. Hoe belangrijk is het dat de coach aan de kant real time met jullie data kan meekijken?

52

BIJLAGE . APPENDIX

B

JUnit

Figuur B.1: JUnit test overzicht

53

C. FIGUREN

C

Figuren

Figuur C.1: Activiteiten diagram van de applicatie

54

BIJLAGE . APPENDIX

Figuur C.2: UML diagram van de applicatie

55

C. FIGUREN

Figuur C.3: Hoeveelheid RAM in gebruik in het hoofdmenu

56

BIJLAGE . APPENDIX

Figuur C.4: Hoeveelheid RAM in gebruik tijdens het roeien

57

C. FIGUREN

Figuur C.5: Hoeveelheid RAM in gebruik in het analyse scherm

58

BIJLAGE . APPENDIX

Figuur C.6: Interne structuur van de applicatie

59

C. FIGUREN

Figuur C.7: Structuur van de applicatie met losse threads

60

Portable Instrument Panel for Rowers

Recommend Documents