Technisch verslag
Project Cursus Docent(en) Datum Versie
: Lasertag : TCTI-V2THO8-12 : M. Wensink, J. Zuurbier : 24 juni 2014 : 0.5
Team 9 Dennis Haverhals, 1589419 Wouter Veen, 1584747 Matthijs Veldhuizen, 1627265 Jonathan Smit, 1604482
1
Versiebeheer Versie 0.1 0.2 0.3 0.4 0.5
Beschrijving Initiële document Controle document Opmaak en samenvoeging Controle eerste opmaak Controle document
Auteur Iedereen Dennis, Wouter Wouter Jonathan Iedereen
2
Abstract In opdracht van de firma TAG’M heeft de Hogeschool Utrecht dit projectteam opdracht gegeven om software voor een speldetector-prototype te realiseren. Met het oog op de automatiseringen in deze tijd ziet de directie van de firma TAG’M kans om het bekende paintball-spel in een moderne jas te steken. De faseringen van project Lasertag (van ontwerp tot en met realisatie) alsmede de uitwerking(en) van de oplossing(en) zijn in dit document beschreven. Aan het begin van het project is met de klant overeenstemming bereikt wat de speldetector moet doen. De overeenstemming heeft geresulteerd in een kader voor dit project. Het kader is met enkele punten uitgebreid om aan extra wensen van de klant te voldoen. Twee architectuurmodellen laten de gemodelleerde oplossing op een functionele en technische wijze zien. Aan de hand van de architectuurmodellen is de software ontwikkeld. In de laatste fase van het project is het prototype getest op niet-functionele eisen gesteld aan de software (constraints). De software is goed door het testen heen gekomen; alle constraints zijn behaald. Wat niet zou worden opgenomen in dit project maar waar niet aan kon worden ontkomen, is het testen van een infraroodsignaal met enkele infraroodzenders. Zonder infraroodzender zou het alleen bij de simulatie van een infraroodsignaal zijn gebleven. Mede door het succes van het ontvangen van infraroodsignalen, het behalen van de constraints en de oplevering van het software die voldoet aan de gestelde eisen van de klant, kan geconcludeerd worden dat een werkend prototype is opgeleverd.
3
Inhoudsopgave 1 Inleiding ..................................................................................................................................................... 6 2 Functionele specificatie ............................................................................................................................. 7 2.1 De speldetector moet voldoen aan (Must have): ................................................................................. 7 2.2 De speldetector zal waarschijnlijk voldoen aan (Should have): ......................................................... 7 2.3 De speldetector zou kunnen voldoen aan (Could have): ..................................................................... 8 2.4 De speldetector gaat nu niet voldoen aan (Won’t have): .................................................................... 8 3 Requirements architecture ......................................................................................................................... 9 4 Solution architecture ................................................................................................................................ 11 4.1 Class model ....................................................................................................................................... 11 4.1.1 Objecten voor de speldetector .................................................................................................... 11 4.1.2 De associaties ............................................................................................................................. 12 4.1.3 Het objectendiagram .................................................................................................................. 14 4.2 Concurrency model ........................................................................................................................... 15 4.2.1 Taakstructurering ....................................................................................................................... 15 4.2.2 Taaksamenvoegingscriteria ........................................................................................................ 16 4.2.3 Het initiële task structure diagram ............................................................................................. 20 4.2.4 Het initiële klassendiagram ........................................................................................................ 21 4.2.5 Het concurrency diagram ........................................................................................................... 22 4.3 Dynamic model ................................................................................................................................. 26 4.3.1 STD’s voor de speldetector ........................................................................................................ 26 4.3.2 Het definitieve klassendiagram .................................................................................................. 31 5 Ontwikkelomgeving ................................................................................................................................. 32 6 Algoritmen en structuren ......................................................................................................................... 33 6.1 Het ontvangen en decoderen van het infrarood signaal .................................................................... 33 6.2 Het listener pattern ............................................................................................................................ 34 6.3 Schrijven naar het LCD .................................................................................................................... 36 7 Testresultaten ........................................................................................................................................... 38 7.1 Bevindingen ...................................................................................................................................... 38 7.2 Constraints ........................................................................................................................................ 40 7.2.1 Contraints voor accuracy ........................................................................................................... 40 7.2.2 Constraints voor performance .................................................................................................... 42
4
8 Mogelijk onopgeloste problemen............................................................................................................. 47 9 Conclusie en aanbevelingen ..................................................................................................................... 47 10 Literatuurlijst.......................................................................................................................................... 48 BIJLAGE 1 Requirements architecture BIJLAGE 2 Testcode BIJLAGE 3 Lasertag handleiding BIJLAGE 4 De wapens BIJLAGE 5 Het definitieve klassendiagram
5
1 Inleiding Na een bedrijfsuitje van de firma TAG’M in een paintball-centrum kwamen computertechnici van de firma op het idee een soortgelijk spelsysteem te ontwikkelen. De wapens die verfkogels afvuren maken plaats voor wapens die infraroodsignalen afvuren. De treffer die een verfvlek bij de speler achterlaat, maakt plaats voor een lampje dat brandt wanneer de draagbare detector op een treffer reageert. De directie van de firma TAG’M is zo onder de indruk van de ideeën, dat een kans op de markt wordt gezien als het prototype van het concept aanslaat. De Hogeschool Utrecht is benaderd om programmatuur voor het prototype van de detector te ontwikkelen. Aan de hand van twee architectuurmodellen is de programmatuur voor de speldetector ontwikkeld. De requirements architectuur (RA) beschrijft wat de software van het systeem moet doen. De solution architecture (SA) beschrijft hoe de software van het systeem in elkaar moet zitten. De nadruk in dit document ligt op de SA en de oplossingen - zoals algoritmen - die tot een werkend prototype hebben geleid. Om een globaal beeld van het systeem te krijgen wordt op basis van de functionele specificatie een samenvatting van het RA gegeven. Er wordt ingegaan op de tests die het prototype heeft ondergaan. Een infraroodsignaal is gedurende de ontwikkeling gesimuleerd om losse onderdelen te testen. Om het systeem met (echte) infraroodsignalen in de praktijk te laten werken is programmatuur voor een infraroodzender ontwikkeld. De ontwikkeling van een IR-wapen was geen onderdeel van de casus, hier is echter wel aan gewerkt. Aan het DB038 bordje is de timing gecorrigeerd om het succesvol te laten werken. Naast de DB038 is ook de DB103 gebruikt. In hoofdstuk 2 wordt de functionele specificatie besproken. In hoofdstuk 3 wordt een samenvatting van de RA gegeven. In hoofdstuk 4 wordt de SA beschreven. In hoofdstuk 5 wordt de ontwikkelomgeving besproken. In hoofdstuk 6 komen de belangrijkste algoritmen aan bod. In hoofdstuk 7 worden de testresultaten besproken. In hoofdstuk 8 worden onopgeloste problemen besproken.
6
2 Functionele specificatie De eisen aan het op te leveren product zijn samen met de klant opgesteld om de functionaliteiten te valideren naar aanleiding van de aangeleverde beschrijving van de casus.
2.1 De speldetector moet voldoen aan (Must have): 1) Tonen van de levenspunten op LCD. 2) De speler begint met 20 levens. 3) Tonen van de resterende speeltijd op LCD. 4) Speeltijd begint op 10 minuten en wordt het spel gespeeld. 5) Bij een treffer wordt een LED aangezet voor korte tijd. 6) Bij een hit van een standaard wapen (pistool) verliest de speler een levenspunt. 7) Bij een hit van een standaard wapen wordt 1 scorepunt voor de schutter opgeslagen in een variabele. 8) 10 sec wordt er op het LCD afgeteld tot het spel begint. 9) 10 sec timeout tussen verschillende keren geraakt kunnen worden. 10) De detector registreert ieder geraakt shot. Er is geen teamverband. 11) Speler nummer van het shot van de tegenstander wordt niet getoond maar wel onthouden. 12) Activeren van het spel door een infraroodsignaal van de spelleider. 13) Het spel eindigt als de speler geen levens meer heeft of de tijd van het spel voorbij is. 14) Automatisch loggen van treffers via de seriële verbinding na afloop van een spel zodra de detector verbonden is met een computer.
2.2 De speldetector zal waarschijnlijk voldoen aan (Should have): 1) Bij een hit wordt een geluidje afgespeeld. 2) Bij opstarten wordt een geluidje afgespeeld. 3) Variabele speeltijd a.d.h.v. speciaal signaal van de spelleider (5, 10, 30 en oneindig)1. 4) Variabele levens a.d.h.v. speciaal signaal van de spelleider (5, 10, 20 of oneindig). 5) De tijd waar op het spel begint wordt verstuurd tijdens het activeren door het signaal van de spelleider. 6) Bij een hit van een zwaarder wapen en dus niet het standaard wapen verliest de speler twee levenspunten. 7) Bij een hit van een zwaarder wapen worden altijd twee scorepunten voor de schutter opgeslagen ook als de geraakte speler maar een levenspunt heeft. 8) Na het aansluiten van de speldetector aan de PC, als het spel nog niet afgelopen is, wordt het spel eerst gestopt voor het verzenden van de treffers kan beginnen. 9) Trefferlog na speeltijd in opdracht van een serieel signaal afkomstig van een PC versturen.
1
Een combinatie van oneindige levens met oneindige speeltijd is niet mogelijk wegens te weinig geheugen op de microcontroller.
7
2.3 De speldetector zou kunnen voldoen aan (Could have): 1) Verschillende spelmodi. 1.1) Team deathmatch. 1.2) Last man standing. 2) Friendly fire bij spelmodi waar spelers in teams worden ingedeeld. 3) Trefferlog verzenden in opdracht van het IR-logsignaal door de spelleider na speeltijd.
2.4 De speldetector gaat nu niet voldoen aan (Won’t have): 1) Batterijspanningscontrole.
8
3 Requirements architecture De requirements architecture bevat het usage model en het constraints model. In het usage model staat wat het systeem moet doen. Het usage model bestaat uit een use case diagram aangevuld met een uitwerking van elke use case. Deze uitwerkingen zijn vastgelegd in activity diagrams (AD’s). In het constraints model staan de voorwaarden (de niet-functionele eisen) waaraan het systeem moet voldoen. Beide modellen zijn gebaseerd op de must have-categorie uit de functionele specificatie (H2). Dit hoofdstuk dient als samenvatting van de requirements architecture. Om alsnog een goed beeld te krijgen van het systeem zijn alleen de hoofdzakelijke punten uit dit document opgenomen. Zie bijlage 1 voor het volledige document. Het use case diagram voor de speldetector Het systeem moet de spelvoortgangswaarden tonen voor de actor gebruiker (de drager van de speldetector). Het tonen van de spelvoortgangswaarden slaat op de speeltijd en de (resterende) levenspunten van de user. Om de resterende levenspunten te kunnen tonen moeten altijd infraroodsignalen worden gedecodeerd, want door middel van de actor ‘Wapen van deelnemer’ kunnen bij de actor gebruiker de levenspunten worden verminderd. Het decoderen van infraroodsignalen moet ook gebeuren voor de spelleider die door middel van een afstandsbediening het spel activeert. Tot slot moeten de treffers naar de PC worden gelogd.
Figuur 1.1 Het use case diagram van de speldetector
9
Use cases De uitwerking van een use case wordt weergegeven in een activity diagram. Zie bijlage 1 voor alle uitwerkingen en beschrijvingen van use cases voor de speldetector. Constraints In het constraints model staan de voorwaarden (de niet-functionele eisen) waaraan het systeem moet voldoen. Zo moet binnen 3 IR-berichten duidelijk zijn wie de schutter is van de hit en mag de speeltijd niet meer dan 2 seconden afwijken van de werkelijke tijd. Verder moet binnen 150 ms een treffer gedetecteerd en verwerkt zijn en binnen 150 ms moet een serie karakters op het LCD te zien zijn. Tot slot moeten de acties in overgangen, bijvoorbeeld na het aftellen aan het begin van het spel naar het activeren en starten van het spel, in minder dan 400 ms gebeuren. Zie bijlage 1 voor meer details van de constraints. De constraints zijn geverifieerd, de testresultaten kunnen worden teruggelezen in H7.
10
4 Solution architecture Als helder is wat de software van het systeem moet gaan doen en hoe goed het systeem een bepaalde functie moet uitvoeren, kan gekeken worden hoe de software in elkaar moet zitten, zodat aan de eisen, geformuleerd in de requirements architecture, kan worden voldaan. De solution architecture bevat drie software-modellen om dit realiseren. De statische structuur van objecten die verantwoordelijk zijn voor de werking van het systeem wordt beschreven in het class model. Hoe objecten (samenwerkende taken) communiceren en welke mechanismen worden gebruikt wordt besproken in het concurrency model. Tot slot beschrijft het laatste model, het dynamic model, wat de interne werking van objecten is. In hoofdstuk 4.1 wordt het class model beschreven. In hoofdstuk 4.2 wordt het concurrency model beschreven. In hoofdstuk 4.3 wordt het dynamic model beschreven.
4.1 Class model De statische structuur van objecten die verantwoordelijk zijn voor de werking van het systeem wordt beschreven in het class model.
4.1.1 Objecten voor de speldetector Om objecten voor de speldetector boven water te krijgen, is een CRC-sessie gehouden. De CRC-sessie (Class-Resposibilities-Collaborators) is een brainstormsessie om de verantwoordelijkheden en de objecten waarmee een object moet samenwerken vast te leggen. Door het nalopen van de actitvity diagrams van de use cases (zie requirements architecture in bijlage 1) kunnen de boundary objecten, controllers en entities worden ontdekt. Boundary objecten Boundary objecten schermen details van de hardware af. Mocht in de toekomst hardware worden vervangen, dan hoeft alleen een nieuw boundary object worden gemaakt en kan de rest van het systeem ongewijzigd blijven. Object
Beschrijving
theLCD
een object om gegevens op het LCD te printen
theSerialSendI nterface
een object om (d.m.v. een ARM board pin) seriële gegevens te verzenden
theIRReceiveIn terface
een object om IR-signalen te ontvangen van deelnemer of spelleider en dit doorgeeft aan andere objecten
theLEDs
een object om (d.m.v. ARM board pin) de LED-lampjes aan of uit te zetten Tabel 4.1 Boundary objecten
11
Controller objecten Controller objecten (non-I/O objecten) zijn verantwoordelijk voor de coördinatie van een use case. Als regel geldt: Iedere use case van enige omvang heeft een eigen controller object. De verantwoordelijkheden van alle use cases kunnen niet aan een object worden toegewezen, daarom zijn verschillende controller objecten gevonden. Object
Beschrijving
theShowGameStatusValuesCtrl een object dat speeltijd en de (resterende) levenspunten van de User toont en een indicatie geeft bij een hit theShowGameTimeCtrl
een object dat de speeltijd bijhoudt en toont op het LCD
theIRDecodeSignalCtrl
een object dat de IR-signalen decodeert en doorgeeft aan ander objecten
theActivateGameCtrl
een object dat zorgt voor activatie van het spel en dit doorgeeft aan een ander object.
theLogHitsCtrl
een object dat hits logt naar een PC. Tabel 4.2 Controller objecten
Entity objecten Voor het onthouden van data is een object gevonden. De gegevens van de speler (levenspunten) en de gegevens van deelnemers (score en deelnemernummer) moeten worden onthouden. Voor het onthouden van de tijd van het spel hoeft geen apart object te worden gemaakt. De tijd wordt als int-attribuut van een controller ondergebracht. Object
Beschrijving
PlayerData
een object voor het bijhouden van gegevens van de deelnemer. Tabel 4.3 Entity objecten
4.1.2 De associaties Tijdens de CRC-sessie is duidelijk geworden naar welk object een bericht moet sturen en van welke objecten het object een bericht moet kunnen ontvangen, dus welke objecten het object moeten ‘kennen’. Voor het vastleggen van de associaties is gebruik gemaakt van de activity diagrams uit het use case model (zie requirements architecture).
12
theShowGameStatusValuesCtrl
stuurt berichten naar theLCD, theShowGameTimeCtrl (game over, start), theLogHitsCtrl (start), theIRDecodeSignalCtrl ( game over ), theLEDs (aan/uit) * ontvangt berichten van theIRDecodeSignalCtrl (deelnemer signaal, spelleider signaal), theShowGameTimeCtrl (speeltijd voorbij), theLogHitsCtrl (start)
theShowGameTimeCtrl
stuurt berichten naar theLCD, theShowGameStatusValuesCtrl (speeltijd voorbij) ontvangt berichten van theShowGameStatusValuesCtrl (game over, start)
theActivateGameCtrl
stuurt berichten naar theShowGameStatusValuesCtrl (startspel), theLCD om tijd op LCD te tonen ontvangt berichten van theIRDecodeSignalCtrl (spelleider),
theLogHitsCtrl
ontvangt berichten van theShowGameStatusValuesCtrl verstuur bericht naar theSerialSendInterface (startSending)
theIRDecodeSignalCtrl
stuurt berichten naar theShowGameStatusValuesCtrl (spelleider, deelnemer, deelnemergegevens), ontvangt berichten van theIRReceiver (ir-signaal), theShowGameStatusValuesCtrl (game over)
* De LED-lampen op het ARM board kunnen via een pin aan of uit worden gezet. Deze pin wordt aangeroepen in theShowGameStatusValuesCtrl. Ter verduidelijking dat de controller gebruikt maakt van deze hardware-mogelijkheid is het boundary object in het initiële klassendiagram opgenomen.
13
4.1.3 Het objectendiagram Het objectdiagram geeft de eerder besproken communicatie tussen de objecten weer. Om duidelijkheid te creëren zijn voor de objecten verschillende kleuren gebruikt.
Figuur 4.1 Initiële objectdiagram
14
4.2 Concurrency model Nu de objecten zijn vastgesteld moet eerst gekeken worden bij wat voor taak deze horen. De taken die hieruit voortkomen worden gerangschikt op deadlines en prioriteiten.
4.2.1 Taakstructurering Een realtime systeem met meerdere objecten moet goed kunnen functioneren. Het systeem opsplitsen in taken zodat het goed kan functioneren wordt gedaan aan de hand van taak structurering. I/O criteria Bepalen hoe Boundary-objecten worden toegewezen en wanneer een I/O taak wordt geactiveerd. boundary object theLCD theIRReceiveInterface theSerialSendInterface theLEDs
Taak nodig Asynchrone I/O taak Periodieke I/O taak, clock freq.: 400 μs Periodieke I/O taak *, clock freq.: 400 μs Asynchrone I/O taak Tabel 4.4 I/O criteria
15
Interne taakstructurering Hoe non-I/O objecten worden toegewezen aan taken en wanneer een interne taak wordt geactiveerd. Non-I/O object theShowGameStatusValuesCtrl theLogHitsCtrl theIRDecodeSignalCtrl theActivateGameCtrl theShowGameTimeCtrl
Taak nodig Asynchrone interne taak Asynchrone interne taak Asynchrone interne taak Asynchrone interne taak Periodieke interne taak, timer freq.: 1000 ms Tabel 4.5 Interne taakstructurering
Takenprioriteitencriteria Bepalen welke taken een hogere prioriteit moeten hebben dan een andere taken. Object theIRReceiveInterface theIRDecodeSignalCtrl theShowGameStatusValuesCtrl theActivateGameCtrl theLogHitsCtrl theLCD theSerialSendInterface theLEDs theShowGameTimeCtrl
Taak nodig Periode Periodieke I/O 400 μs Asynchrone intern Asynchrone intern Asynchrone intern Asynchrone intern Asynchrone I/O Periodiek I/O 400 μs Asynchrone I/O Periodieke intern 1000 ms Tabel 4.6 Takenprioriteitencriteria
Deadline 395 μs 10 ms
Prioriteit 1 3
400 ms
7
400 ms
7
50 ms
4
200 ms 400 μs 1 ms 300 ms
5 1 2 6
4.2.2 Taaksamenvoegingscriteria Objecten kunnen samengevoegd worden tot taken aan de hand van samenvoegingscriteria. Onder deze criteria vallen temporele, sequentiële en control cohesie. Hierbij wordt gekeken hoe objecten ten opzichte van elkaar zich gedragen op basis van tijd, aanroep volgorde en verhouding tot elkaar.
16
Temporele cohesie Wanneer kandidaat-taken actief worden door hetzelfde event, komen ze in aanmerking om te worden samengevoegd. Als de periodes te veel verschillen moeten ze niet worden samengevoegd. Object - theIRReceiveInterface - theSerialSendInterface - theIRDecodeSignalCtrl
Taak nodig Periodieke I/O
Periode 400 μs
Asynchrone intern - theShowGameStatusValuesCtrl Asynchrone intern - theActivateGameCtrl Asynchrone intern - theLogHitsCtrl Asynchrone intern - theLCD Asynchrone I/O - theLEDs Asynchrone I/O - theShowGametimeCtrl Periodieke 1000 ms intern Tabel 4.7 Temporele cohesie
Deadline 395 μs
Prioriteit
10 ms 400 ms 400 ms 50 ms 200 ms 1 ms 300 ms
De IRReceiveInterface, en de theSerialSendInterface worden samengevoegd. De reden hiervoor is dat de drie interfaces op dezelfde frequentie de bits kunnen ontvangen of verzenden.
17
Sequentiële cohesie Wanneer de eerste kandidaat-taak in een rij van twee of meer taken, waarvan nooit twee of meer tegelijkertijd actief hoeven te zijn, de tweede activeert, die vervolgens de derde activeert, etc., dan is er sprake van sequentiële cohesie en kunnen deze taken worden gecombineerd tot een taak. Wanneer een kandidaat-taak ook door een andere dan zijn voorganger in de rij kan worden geactiveerd of wanneer een kandidaat-taak een andere prioriteit moet hebben dan zijn voorganger, worden deze niet samengevoegd. Object - theIRReceiver - theSerialSendInterface - theIRDecodeSignalCtrl - theShowGameStatusValuesCtrl - theActivateGameCtrl - theLogHitsCtrl - theLCD - theLEDs - theShowGametimeCtrl
Taak nodig
Periode
Deadline
Prioriteit
Periodieke I/O Asynchrone intern Asynchrone intern
400 μs
395 μs
0
-
10 ms
2
-
400 ms
5
200 ms
3
1 ms
1
300 ms
4
Asynchrone I/O Asynchrone I/O Periodieke 1000 ms intern Tabel 4.8 Sequentiële cohesie
Op basis van sequentiële cohesie worden theActivateGameCtrl en theShowGameStatusValueCtrl en theLoghitsCtrl samengevoegd.
18
Control cohesie Als een controller het enige object is dat berichten naar een bepaald object stuurt en beide objecten op dat moment geen andere acties moeten ondernemen, is control cohesie van toepassing. Object - theIRReceiveInterface - theSerialSendInterface
Taak nodig Periodieke I/O
Periode 400 μs
Deadline 395 μs
Prioriteit 0
- theIRDecodeSignalCtrl - theLCD - theShowGameTimeCtrl - theShowGameStatusValuesCtrl - theActivateGameCtrl - theLogHitsCtrl - theLEDs
Asynchrone intern Asynchrone I/O Periodieke intern Asynchrone intern
1000 ms -
10 ms 200 ms 300 ms 400 ms
1 2 3 4
Tabel 4.9 Control cohesie De theShowGameStatusValueCtrl is de enige die de LED-lampjes aan zet, deze kunnen dus worden samengevoegd op basis van control cohesie. Samenvoegen van taken Alle taken op een rij geprioriteerd. Asynchrone interne / I/O taken hebben geen periode. Object IOHandlerTask - theIRReceiverInterface - theSerialSendInterface IRDecodeTask
Taak nodig Periodieke I/O
Periode 400 μs
Deadline 395 μs
Prioriteit 0
Asynchrone intern Asynchrone I/O
-
10 ms
1
200 ms
2
300 ms
3
400 ms
4
LCDTask - theLCD GameTimeTask Periodieke intern 1000 ms - theShowGameTimeCtrl GameHandlerTask Asynchrone (theShowGameStatusValuesCtrl) intern - theActivateGameCtrl - theLogHitsCtrl - theLEDs Tabel 4.10 Samenvoegen van taken
* De GameHandlerTask heeft zelf de functionaliteit van de theShowGameStatusValuesCtrl.
19
4.2.3 Het initiële task structure diagram Het initiële task structure diagram laat zien welke objecten zijn toegewezen aan de gedefinieerde taken. De objecten die zijn opgenomen worden ook welk parts genoemd. In het onderstaande diagram heeft elke taak een of meerdere parts met een doorgetrokken lijn eromheen. Dit betekent dat een part eigendom is van een taak en door middel van compositie aan een taak is gekoppeld. Met andere woorden de taak heeft een aantal objecten die ophouden te bestaan wanneer de desbetreffende eigenaar stopt met de uitvoering.
Figuur 4.2 Initieel task structure diagram
20
4.2.4 Het initiële klassendiagram Na het samenvoegen van taken kan het objectendiagram uitgewerkt worden tot het initiële klassendiagram. Een aantal taken hebben een stereotype isActive. Dit betekent dat de klasse een RTOStask is. Verder zijn de namen van de controller- en boundary objecten omgezet naar de namen van de bijbehorende klassen.
Figuur 4.3 Initieel klassendiagram
21
4.2.5 Het concurrency diagram Het concurrency model laat door middel van een concurrency diagram zien hoe informatie door verschillende taken moet worden uitgewisseld en of dit periodiek of asynchroon moet gebeuren. Om de concurrency mechanismen boven water te krijgen, moet per taak gekeken worden welke informatie deze moet ontvangen.
GameHandlerTask De GameHandlerTask is asynchroon. Vooraf aan het spel moet de taak wachten op een gamemaster event zodat het spel gestart kan worden. Tijdens het spel moet de taak wachten op een player event wanneer er een treffer is. Om de score te berekenen moet de GameHandlerTask informatie van de deelnemer hebben, zoals spelernummer en wapen. Deze informatie zal bij het ontvangen van een player-signaal in de signalDataPool staan. Wanneer de speeltijd voorbij is wordt de taak op de hoogte gesteld door het timeOver event. Na het spel moeten de treffergegevens gelogd worden naar de PC. Eerst moet worden gewacht op het serialConnection event. Wanneer er een seriële verbinding is geconstateerd, dan wordt de sendChannel van de IOHandlertask met treffergegevens gevuld. Wanneer de treffers naar de pc zijn gelogd, dan wordt de eventflag doneSendingFlag ge-set, om weer terug te gaan naar zijn initiële staat (activategame staat).
IOHandlerTask De IOTask (IOT) is periodiek. De IOT controleert elke 400 µs op het ontvangen van een bit. De IOT krijgt wanner er een verbinding is het startSending event van de GameHandlerTask en verandert hierdoor in de SerialSending staat. Vervolgens leest de IOT de sendChannel uit en verzendt de trefferdata met het STD::cout commando via de seriële poort. Als het receiveNext event optreedt zal nieuwe data in de receivePool kunnen worden geschreven.
22
LCDTask De LCDTask (LT) is asynchroon. De LT wacht totdat data in de channel staat. Wanneer dit zo is wordt de data naar het LCD geschreven en die plek in de channel geleegd. Om datacorruptie te voorkomen wordt bij deze channel gebruik gemaakt van een mutex. (De GameHandlerTask en GameTimeTask schrijven naar de channel van het LCD, door een context-switch kan datacorruptie optreden.)
GameTimeTask De GameTimeTask (GTT) is asynchroon. Nadat de GTT is geïnitialiseerd zal deze wachten op een StartGameTime event. Wanneer deze is opgetreden begint de tijd af te tellen. Tijdens het runnen kan het gameOver event optreden. Wanneer deze is ge-set zal worden gestopt met tellen. De GTT wil zijn tijd weergeven op het LCD. Om dit te doen zal de GTT zijn data naar de lcdChannel schrijven.
IRDecodeTask De IRDecodeTask is asynchroon. Als een nieuw IR-signaal is aangekomen (vanuit de IOHandlerTask), treedt het receiveDataFlag event op. De gegevens van het infraroodsignaal worden dan uit de receiveDataPool gelezen. Als de IRDecodeTask data heeft doorgegeven aan de GameHandlerTask, wordt pas weer nieuwe data doorgegeven als de receiveNextFlag ge-set is.
23
Het concurrency diagram De hiervoor besproken concurrency mechanismen zijn hieronder grafisch weergegeven in het concurrency diagram.
Figuur 4.4 Concurrency diagram
24
Definitieve task structure diagram Nu de concurrency mechanismen bekend zijn kan de initiële task structure diagram worden aangepast door de mechanismen aan de taken toe te voegen. Hierdoor ontstaat het definitieve task structure diagram.
Figuur 4.5 Definitieve task structure diagram
25
4.3 Dynamic model In het dynamic model wordt vastgelegd hoe objecten intern functioneren en hoe ze reageren op bepaalde events.
4.3.1 STD’s voor de speldetector Aan de hand van een state transition diagram (STD) wordt getoond hoe objecten in een bepaalde toestand reageren op events en welke operaties dan moeten worden uitgevoerd. STD voor de GameHandlerTask
Figuur 4.6 STD voor de GameHandlerTask
De GameHandlerTask heeft als hoofddoelen: 1. de activatie van het spel te verzorgen (activation), 2. zorgen dat de levenswaarden van de speler op het scherm worden getoond. De taak heeft 5 ingaande events. Het gameMaster event treedt op als de spelleider (gamemaster) het spel wilt activeren. Het player event treedt op als tijdens het spel een andere speler een treffer maakt. Wanneer de speeltijd voorbij is treedt het timeOver event op, hierdoor wordt het spel afgesloten (gameOver). Het serialConnection event treedt op als aanduiding van een seriële verbinding wanneer het spel voorbij is en de treffers naar de PC gelogd kunnen worden. Wanneer de seriële gegevens zijn verzonden treedt het sendingDone event op. Hierna wacht de taak weer op activatie van de spelleider.
26
STD voor de IRDecodeTask
Figuur 4.7 STD IRDecodeTask
De IRDecodeTask reageert op twee ingaande events en genereert ook twee uitgaande events. Ingaande events: ● Bij nieuwe gegevens in de pool (dataReceivePool) wordt de dataReceivedFlag ge-set. ● Als een ontvanger van een uitgaand event gegevens heeft gelezen, wordt de receiveNextFlag geset. Pas na deze flag wordt weer een IR-signaal gedecodeerd. Uitgaande events: ● Bij een IR-signaal van de spelleider (gamemaster) of speler (player) wordt het player- of gamemaster event gegenereerd. Als argument van het event wordt SignalData meegegeven. SignalData bevat een ID en het commando van de spelleider of speler. ● Bij een serieel signaal wordt alleen het serialConnection event gegenereerd.
27
STD voor de IOHandlerTask
Figuur 4.8 STD IOHandlerTask
De IOHandlerTask is de taak die de infraroodsignalen ontvangt en de trefferdata via de seriële poort verzendt. Voor het wisselen van deze onderdelen zijn het startSending event gedefinieerd. Daarnaast kunnen te versturen berichten worden toegevoegd met de write() methode. Het receiveNext event zorgt ervoor dat data in de receivePool niet overschreven kan worden. De taak die de berichten uit deze pool leest, zal na het lezen dit event aan moeten roepen zodat de IOHandlerTask weet dat het nieuwe bericht in de pool gezet kan worden. De taak begint in de Waiting for IR signal staat. In deze staat kijkt de taak elke 400 µs of een IR-bericht binnenkomt. Als dat zo is zal dit bericht na driemaal ontvangen te zijn geweest doorgestuurd worden naar de IRDecodeTask. Tussen het ontvangen van de IR-berichten zal altijd gewacht worden om de achtereenvolgende berichten goed op te kunnen vangen. Wanneer het startSending event ontvangen is, zal de taak naar de laatste staat gaan: het versturen van de trefferdata over de seriële poort. In deze staat worden één voor één de berichten uit de sendChannel gelezen en zullen de gegevens weggeschreven worden. Zodra alle trefferdata verstuurd is, gaat de taak weer naar de waiting for IR signal staat.
28
STD voor de GameTimeTask
Figuur 4.9 STD GameTimeTask
Het doel van de taak is de speeltijd (gametime) bijhouden en tonen op het LCD. Deze taak reageert op twee ingaande events en heeft een uitgaand event. De taak wacht totdat de gametime mag worden getoond. Dit wordt duidelijk doordat het event startGameTime wordt ontvangen. Als gevolg wordt de gametime ingesteld op 10 minuten en wordt de tijd op het LCD gezet. Hierna komt de taak in de toestand ShowGameTime.Elke seconde wordt afgeteld en op het LCD gezet. Als de speler door zijn levenspunten heen is wordt het signaal gameOver ontvangen. De staat showGameTime eindigt en wacht weer totdat de gametime mag worden getoond. Als de gametime voorbij is, wordt de GameHandlerTask op de hoogte gebracht door de operatie timerOver van dit object aan te roepen. Als gevolg van dit event keert de taak weer terug in de toestand waiting.
29
STD voor de LCDTask
Figuur 4.10 STD LCDTask
De LCDTask heeft als doel karakters op het LCD te zetten. Het enige event waar deze taak op wacht is de channel die wordt gevuld met gegevens van de taken die deze taak kennen. De taak wacht tot iets in de channel wordt gezet. Vervolgens wordt dit ingelezen en weggeschreven. Afhankelijk met het meegeven regelnummer wordt het bericht op het bovenste of onderste regel van het LCD gezet.
30
4.3.2 Het definitieve klassendiagram Het dynamic model heeft inzicht gegeven in de interne werking van de verschillende klassen. Nu dit duidelijk is kan deze informatie (in de vorm van variabelen en methoden) toegevoegd worden aan het klassendiagram.
Figuur 4.11 Het definitieve klassendiagram
31
5 Ontwikkelomgeving Voor het ontwikkelen van het prototype met behulp van een infrarood detector is bepaalde hardware aangeleverd en is gekozen om met bepaalde software dit te realiseren. Hardware Voor het implementeren van de besturing van de speldetector word gebruik gemaakt van LPC2148 ARM7 RISC processor op een ontwikkelbord. Dit ontwikkelbord is uitgerust met: ● Een 60MHz klok ● 16 Registers van 32-bits ● 32KB RAM en 512KB ROM geheugen ● Een USB-bus voor de voeding en het laden en debuggen van een programma. ● Een 2x16 segments LCD met eigen microcontroller. ● Een array met 8 LEDs. ● Een 16-knops toetsenbord, waarvan elk van de toetsen een hoog signaal afgeeft zolang deze is ingedrukt. ● Een reset knop om de ARM-processor te resetten. ● Een luidsprekertje Software Voor het ontwikkelen en beheren van code moet ook gebruik gemaakt worden van een aantal middelen die dit in goede banen leid. Voor het ontwikkelen van code wordt gebruik gemaakt van het programma PSPad (versie 4.5). Dit programma is freeware en biedt een brede set aan van mogelijkheden, ook worden veel soorten programmeertalen ondersteund. De software van de speldetector is in C++ geschreven.
Figuur 5.1 Logo PSPad
RTOS bibliotheek Deze bibliotheek bestaat uit een set van RTOS mechanismen die gebruikt kunnen worden om een realtime embedded systeem te programmeren. Deze bibliotheek is geprogrammeerd door Wouter van Ooijen en is door hem aangeboden om voor dit project te gebruiken. Code-distributie en versiebeheer Om de code goed te kunnen distribueren tussen de verschillende contributeurs aan het project wordt gebruik gemaakt van een eigen server. Op deze server draait Git, dit biedt versiebeheer aan, is gratis en open source. Om te zorgen voor een goede distributie van de code, wordt gebruik gemaakt van het programma SmartGitHg (versie 5).
Figuur 5.2 Logo GIT
Figuur 5.3 Logo SmartGit
32
6 Algoritmen en structuren Naast hardware werkt het prototype niet zonder software. Deze software is opgezet aan de hand van de solution architectuur en hierop is de implementatie ontwikkeld. In dit hoofdstuk worden verschillende algoritmen en structuren besproken.
6.1 Het ontvangen en decoderen van het infrarood signaal De zenders (DB103 en DB038) van het infraroodsignaal sturen de bitjes gemoduleerd op een draaggolf van 36KHz. Wanneer dit signaal wordt ontvangen door de sensor, wordt het gedemoduleerd. Vervolgens leest de microcontroller het output-signaal in. Om de 400 microseconden wordt nagegaan of het signaal hoog of laag is. Wanneer het signaal laag is, wordt er 1000 microseconden gewacht. Wanneer het signaal nu nog steeds laag is, is een nul gedetecteerd. Wanneer deze hoog is, wordt deze gedetecteerd als een één. Nadat deze bit verwerkt is door de code zal er 800 microseconden gewacht worden, zodat er weer een nieuwe bit gedetecteerd kan worden. Figuur 6.1 Output van bits van een infraroodsignaal
Uitwerking in code rawData[j] = 0x0000 Alles start op 0 RTOS::event ev = wait(iotPeriod); if(ev == iotPeriod){ currState = IRpin.get(); if(!currState) { Als de pin laag is sleep( 1000); Wacht 1000 ms currState = IRpin.get(); Kijk of de pin nog steeds laag is if(!currState) { Als dat zo is, is het een 1, anders blijft het een 0 rawData.signal[j] += (1 << (14 - i)); } } } Om een IR-signaal te kunnen decoderen, moeten de velden van speler, wapen en XOR-bitjes gefilterd worden uit drie patronen van vijf bits. De XOR-bitjes uit het patroon moeten matchen met een XOR van het zender- en commando veld. Alleen dán is een IR-signaal in orde.
33
Uitwerking in code //check data int countCorrectRawSignals = 0; short rdXOR = 0; short rdCMD = 0; short rdSENDER = 0; short rdXOR_CMD_SENDER = 0; for(int i = 0; i < DecodeHandlerTask::maxReceiveDataRawSignals; i++){ //first, get the fields from a raw signal rdXOR = ( ( rawData.signal[0] >> 10) & MASK_5_BIT ); rdCMD = ( ( (rawData.signal[0]) >> 5 ) & MASK_5_BIT); rdSENDER = ( ( (rawData.signal[0]) ) & MASK_5_BIT); //second, make XOR from SENDER and CMD rdXOR_CMD_SENDER = rdCMD ^ rdSENDER; //third, compare above XOR with raw signal XOR if(rdXOR == rdXOR_CMD_SENDER){ countCorrectRawSignals++; } }
6.2 Het listener pattern Een ander interessant onderdeel van de code heeft betrekking tot het zogenaamde listener pattern. Het listener pattern is een systeem waardoor klassen elkaar data en signalen kunnen sturen zonder elkaar echt te hoeven kennen. Hierdoor wordt het probleem van het kip en het ei voorkomen. Voorbeeld De IOHandlerTask heeft een lijst van listeners waarvan de methode dataReceived wordt aangeroepen. De IRDecodeTask implementeert de ReceiveDataListener.
Figuur 6.2 Een ingezoomd deel van het klassendiagram om het listener pattern zichtbaar te maken.
Hierdoor kan de IOHandlerTask data naar de IRDecodeTasksturen zonder dat de een de ander hoeft te kennen.
34
Uitwerking in code Een listener klasse class ReceiveDataListener { public: virtual void dataReceived(ReceiveData data); }; Een implementatie van de listener in een andere klasse void DecodeHandlerTask::dataReceived(ReceiveData aReceiveData){ receiveDataMutex.wait(); receiveDataPool.write(aReceiveData); receiveDataMutex.signal(); receiveDataFlag.set(); } De aanroep van de listener methode vanuit een derde klasse for(int i = 0; i < countReceiveDataListeners; i++){ _theReceiveDataListener[i]->dataReceived(rawData); } Om de listeners te implementeren is de volgende main-code vereist: #configure board hu_arm_v4 #configure clcd_lines 2 #configure memory rom #configure baudrate 38400 #configure port com4 #include "pRTOS.h" #include "armboard.h" #include "IOHandlerTask.h" #include "IRDecodeTask.h" #include "LCDTask.h" #include "GameHandlerTask.h" #include "SignalData.h"
35
int main( void ){ LCDTask * lcd = new LCDTask(); IOHandlerTask * iot = new IOHandlerTask(); IRDecodeTask * dht = new IRDecodeTask(); GameTimeTask * gtt = new GameTimeTask(*lcd); GameHandlerTask * ght = new GameHandlerTask(*lcd, *gtt, *iot); //iot listeners iot->addDoneSendingListener(ght); iot->addReceiveDataListener(dht); //dht listeners dht->addReceiveNextListener(iot); dht->addSignalDataListener(ght); //gtt listeners gtt->addTimeOverListener(ght); //ght listeners ght->addGameOverListener(gtt); ght->setReceiveNextListener(dht); RTOS::run(); return 0; }
6.3 Schrijven naar het LCD Om een variabele als tekst op het LCD te plaatsen moest extra functionaliteit aan de LCDTask toegevoegd worden. Uitwerking in code Eerst wordt het karakter omgezet in een string en toegevoegd aan tempStr variabele, vervolgens wordt de string op het LCD geschreven. void LCDTask::write(const char * p, int num, short int digits, short int row, short int pos) { intToTempStr(p, num, digits); write(tempStr, row, pos); }
36
Omzetten van het karakter naar een string en toevoegen aan de tempStr void LCDTask::intToTempStr(const char* p, int num, short int digits){ char str[digits]; for(int i = digits - 1; i >= 0; i--){ str[i] = '0' + (num % 10); num /= 10; } tempStr[0] = '\0'; strncat(tempStr, p, 16); strncat(tempStr, str, 16); } Het samenvoegen van 2 strings char * LCDTask::strncat(char *dest, const char *src, size_t n){ size_t dest_len = 0; size_t i; for(unsigned int i = 0; i < n; i++){ if(dest[i] == '\0') { break; } dest_len++; } for (i = 0 ; i < n && src[i] != '\0' ; i++){ dest[dest_len + i] = src[i]; } dest[dest_len + i] = '\0'; return dest; } Het schrijven van de string naar het LCD void LCDTask::write(const char * p, short int row, short int pos){ lcddata kd; int i = 0; for(i = 0; p[i] != '\0'; i++) { kd.buf[i] = p[i]; } kd.len = i; kd.row = row; kd.pos = pos; lcdMutex.wait(); buffer.write(kd); lcdMutex.signal(); }
37
7 Testresultaten In dit hoofdstuk worden de testresultaten en bevindingen besproken. In paragraaf 7.1 worden bevindingen besproken. In paragraaf 7.2 worden de testresultaten van de constraints besproken. De constraints die zijn opgesteld staan in bijlage 1 (RA, H3 Constraints model).
7.1 Bevindingen In deze paragraaf worden de bevindingen besproken. Per projectbord is een indeling gemaakt. IR-ontvanger (LPC1248) Wanneer de speldetector geactiveerd moest worden door een gamemaster-signaal terwijl een playersignaal ontvangen werd, ontstond er een deadlock in het systeem. De reden was dat de GameHandlerTask na ontvangst van een player-signaal in de ActivationCtrl niet aan de IR-decodeTask liet weten dat het signaal gelezen was; de ActivationCtrl gebruikte alleen een gamemaster-signaal en liet alleen dan weten dat het signaal gelezen was. De oplossing voor dit probleem is dat in de GameHandlerTask wordt geprogrammeerd dat na elk signaal de IRDecodeTask op de hoogte wordt gesteld wanneer een signaal ontvangen is en niet alleen bij het verwachte signaal. IR-zender (DB038) De clock-instelling (in DB038.h) van het bordje stond eerst op 4 MHz maar dit moet 20 MHz zijn. Dit had te maken met de kristalsnelheid, want de kristalsnelheid is één vijfde van de ingestelde snelheid. Dat resulteerde in een te trage verzending van het infraroodsignaal. Met de 20 MHz kon het infraroodsignaal, overeenkomstig de casusbeschrijving van het infraroodsignaal, verzonden worden op een snelheid van 4 MHz. Met andere woorden, er moest dus korter gewacht worden om een bit te verzenden. Voor details over de werking, zie de code voor de DB038. IR-zender (DB103) Wanneer de code om een infraroodsignaal te verzenden is gewijzigd op de PC kan het voorkomen dat de object-files niet allemaal goed gebuild worden. Het resultaat hiervan is dat oude object-files op het bordje kunnen komen en hierdoor niet de aangebrachte wijzigingen meeneemt. Bij ons kwam het voor dat we problemen hadden met het verzenden van een IR-signaal, doordat er oude object-files geupload werden. Aangeraden word om een ‘clean’-commando uit te voeren wanneer er soms onverklaarbare problemen na het repareren en aanpassen van code zijn. Dit commando zorgt ervoor dat de object-filed opnieuw gebuild zullen moeten worde De aangeleverde code om een infraroodsignaal te verzenden met de DB103 werkte direct. Omdat we de ontvanger niet direct werkend kregen, vroegen we ons af of dit niet aan de zender lag. Om hier achter te komen hebben we de ontvanger aangesloten op een digitale oscilloscoop (PicoScope). De resultaten hiervan staan hieronder:
38
Figuur 7.1 Weergaven van een reeks bits die verstuurd word door de infrarood op het wapen.
Hierboven staat een capture van een bitreeks, ontvangen door de IR ontvanger. In het plaatje is te zien dat er te maken is met drie bit reeksen, gescheiden door een brede pilaar. De twee brede pilaren in het midden van het plaatje duren vijf microseconden en scheiden de bit reeksen van elkaar. De veel minder brede pilaren tussen de brede pilaren zijn de bits. De breedste pilaar representeert de 1600 μs lage flank van een 0-bit. De minst brede pilaar representeert de 800 μs lage flank van een 1-bit. Uit het plaatje is de volgende reeks te lezen: ….. 00100 00101 00001 <pauze> 00100 00101 00001 <pauze> 00100 00101 00001 ….. Conclusie Deadlock Door het bordje te testen is een deadlock uit het systeem gehaald die veroorzaakt werd doordat een player-signaal verstuurd werd vóór de activatie. Dit is een scenario dat vaak had kunnen voorkomen. Het is niet zeldzaam dat spelers al op elkaar schieten voordat het spel geactiveerd is. Zend timing Er konden niet correct bitjes verzonden worden naar de IR ontvanger doordat de timing niet klopte. Door de juiste timing in te stellen is dit opgelost. Ontvangst Het gemoduleerde signaal dat verzonden wordt door de IR- LED werkt correct. Het ontvangen signaal wordt gedemoduleerd waardoor we de, in het bovenstaande plaatje staande, bit reeks verkrijgen. We hoeven ons dus niet zorgen te maken om de hardware, maar juist om de software.
39
7.2 Constraints In deze paragraaf wordt het resultaat getoond van het testen van de constraints. Bij iedere constraint wordt ook een conclusie gegeven. De constraints zijn onderverdeeld in accuracy en performance. Per constraint wordt de naam (identificatie), de beschrijving, de gestelde eis en de verificatie van de constraint in een tabel weergegeven.
7.2.1 Contraints voor accuracy Accuracy geeft aan hoe nauwkeurig iets moet werken, dit is weer opgedeeld in de snelheid, tijd en klok. Bij snelheid wordt bedoeld hoe snel iets wordt gedaan in het programma. In de tabel wordt bij snelheid gesproken over hoe snel een binnenkomende signaal verwerkt moet worden. Onder tijd valt hoeveel de speeltijd maximaal mag afwijken van de tijd die echt gespeeld is. Contraint voor de treffer-detectie Identificatie treffer-detectie
Beschrijving Binnen een maximum aantal ontvangen IRsignalen moet duidelijk zijn wie de deelnemer is.
Eis Binnen 3 IR-signalen
Verificatie Drie keer de bitjes opslaan in een variabele en tonen in de command prompt.
Tabel 7.1 deel van het constraints tabel die de treffer-detectie bespreek. Resultaat Door een goede IR-ontvangst kan uit de drie bit reeksen al een deelnemer afgeleid worden. Deze bit reeksen staan opgeslagen in een struct met een short array voor drie reeksen. De volgorde van de bits zijn van links naar rechts: XOR, wapen en speler.
Figuur 7.1 Resultaat van de output van het IR-Signaal
Conclusie De verificatie van deze constraint is gelukt en heeft voldaan aan de gestelde eis.
40
Constraint voor het bijhouden van de speeltijd. Identificatie Speeltijd bijhouden
Beschrijving De maximale afwijking die de totale speeltijd mag hebben van de werkelijke tijd.
Eis Maximaal 2 seconden.
Verificatie Nagaan of de gespeelde tijd overeenkomt met de tijd van een lopende klok en gemeten met een stopwatch. Tabel 7. 2 Deel van het constrains tabel voor de contrain speeltijd bijhouden
Resultaat Met de stopwatch op de mobiele telefoon is getest of de tijd overeenkomt met de tijd op het projectbordje. Zowel van de eerst van de vijfde minuut is de tijd vastgelegd.
Figuur 7.2a: De tijd na één minuut
Figuur 7.2b: De tijd na vijf minuten.
Figuur 7.2c: De tijd na 10 minuten.
Conclusie De eis was maximaal 2 seconden afwijking en hieraan is voldaan want als rekening gehouden moet worden met de reactiesnelheid waarmee de stopwatch is gestart is er geen afwijking
41
7.2.2 Constraints voor performance Performance beschrijf hoe snel een functie moet worden uitgevoerd. Wanneer het over realtime systemen gaat is de timing erg belangrijk. Een goed voorbeeld hiervan is bijvoorbeeld de tijd die het kost om een treffer te detecteren. Dit moet snel gebeuren zodat het spel in een goede flow blijft. Wanneer een treffer niet op tijd gedetecteerd word, zouden meerdere spelers op een detector kunnen blijven vuren voordat het systeem echt reageert. Dit is natuurlijk niet de bedoeling. Ook de verwerking van de treffer komt hierbij kijken, de treffer moet vanzelfsprekend ook gelijk verwerkt worden. De snelheid van het schrijven van karakters naar een LCD komt hier ook bij kijken, maar heeft een minder hoge prioriteit dan het verwerken van een treffer. Constraint voor de treffer-detectie Identificatie Treffer-detectie
Beschrijving Tijd waarbinnen een inkomend infrarood signaal uitgelezen wordt.
Eis Binnen 150 ms
Verificatie Armboard-tijd in een variabele zetten en na laatste instructie in command-prompt tonen.
Tabel 7.3 constraint voor de treffer detectie Resultaat Het resultaat van deze meting geeft aan dat een inkomend IR-signaal 40 ms nodig heeft om uitgelezen te worden. Het is wel dat het hier gaat over 1 één bit reeks van 15 bits. Voor het totaal heeft hij dus de som nodig van alle drie de bits reeksen. Wat in de testen niet hoger kwam dan 121 milliseconden.
Figuur 7.3 Output van een meting van een IR-signaal
Conclusie De ontvanger voor het infraroodsignaal snel genoeg is naar de genoemde constraint.
42
Constraint voor het verwerken van een treffer Identificatie Treffer verwerken
Beschrijving Eis Tijd waarbinnen het Binnen 50 ms gedetecteerde IR-signaal verwerkt wordt. Tabel 7.4 constraint voor het verwerken van een treffer
Verificatie Armboard-tijd in een variabele zetten en na laatste instructie in command-prompt tonen.
Resultaat In de meting van de tijd waarin een IR-signaal verwerkt wordt is te zien dat dit binnen ongeveer 10 of 11 ms gebeurd. De meting is gedaan aan de hand van de run_time van RTOS die de totale verstreken tijd weergeeft. Hiermee wordt de tijd berekend die nodig is om te ontvangen en te verwerken.
Figuur 7.4 Meting voor het verwerken van het IR-Signaal
Conclusie De eis was om binnen 50 ms een IR-signaal te verwerken: dat is dus behaald.
43
Constraint voor het LCD Identificatie LCD
Beschrijving Hoe snel een serie karakters op het LCD wordt gezet
Eis Binnen 150 ms
Verificatie Armboard-tijd in een variabele zetten en na laatste instructie in command-prompt tonen.
Tabel 7.5 Constraint voor het LCD Resultaat Met deze test is gekeken naar de snelheid over hoe snel een reeks karakters wordt geschreven naar het beeldscherm. Dit is getest op de regel: “Starting in.. 10”. Deze regel beslaat één volledige regel van het display. Uit de test is gebleken dat het schrijven van een volledige regel met 16 karakters naar het display ongeveer 40 ms in beslag neemt.
Figuur 7.5 Output van de meting van het schrijven naar het LCD.
Conclusie De eis was binnen 150 ms, de constraint is dus behaald.
44
Constraint voor het spel starten en na het speleinde Identificatie Spel start en spel einde
Beschrijving Eis Wanneer de actie na een Binnen maximaal 400 ms. gebeurtenis, zoals na de countdown vóór het spel/ na het einde van het spel, behandeld moet worden. Tabel 7.6 Constraint voor het spel starten en na het speleinde
Verificatie Armboard-tijd in een variabele zetten en na laatste instructie in command-prompt tonen.
Resultaat
Figuur 7.6 Output van diverse acties
Conclusie De eis was binnen 400 ms een actie te hebben uitgevoerd, dit is dus behaald.
45
Constraint voor de tijd tussen IR-signalen Identificatie Tijd tussen IR Signalen
Beschrijving Eis Wanneer een IR signaal maximaal 5ms ontvangen is, zal er een tijd gewacht moeten worden voordat het nieuwe IR signaal binnenkomt Tabel 7.7 Constraint voor de tijd tussen IR-signalen
Verificatie
Resultaat
Figuur 7.7 Output van de snelheid van het verweren van een binnenkomend IR-signaal
Conclusie De pauze tussen de IR signalen is precies 5 MS. In de code is geen 5 MS wachten ingebouwd, er wordt enkel gewacht tot het nieuwe signaal binnen komt. Hierdoor zal deze detector ook bruikbaar zijn als de wachttijd tussen de signalen van andere wapens anders is. Zie paragraaf 6.1 voor de uitwerking.
46
8 Mogelijk onopgeloste problemen Het project bevat geen bekende onopgeloste problemen.
9 Conclusie en aanbevelingen Vooraf aan het project is middels een gesprek met de klant de functionele specificatie opgesteld. De musthaves in de functionele specificatie zijn het kader waarbinnen de requirements achitecture en solution architecture is ontwikkeld. Echter is tijdens de ontwikkeling rekening gehouden met uitbreidingsmogelijkheden van het systeem. Daarom is gekozen de should-have variabele IR-wapens in te bouwen. De reden dat het IR-signaal een diversiteit aan commando’s (wapen-nummers) van spelers kan bevatten heeft ook meegewogen. De score van speler is op dit moment afgestemd op het soort wapen. Dus commando ‘1’ betekent wapen ‘1’ en zal één punt van de (resterende) levenspunten van de speler afhalen, wapen ‘2’ twee punten etcetera. De vier spelers die voor deze speldetector zijn gedefinieerd kunnen dus verschillende wapens gebruiken, wat het spel dus een stuk uitdagender maakt. In de requirements architecture (zie H3 constraints) zijn niet-functionele eisen gesteld aan de software van het systeem. In hoofdstuk 7 zijn de constraints getest. Aan de hand van de testresultaten kan worden geconcludeerd dat de constraints voldoen aan de gestelde eisen. Dit betekent dat de software ten opzichte van het systeem en idem dito goed op elkaar zijn afgestemd. Tijdens het project zijn onverwachte problemen opgetreden met aangeleverde software van de IR-zender (DB038). Aan de software zijn aanpassingen toegebracht om de zender toch correct te kunnen laten functioneren. Ook is het DB103 bordje gereed gemaakt voor gebruik als IR-zender. Aan de hand van het soort hardware dat gebruikt is kan worden geconcludeerd dat het een kleine investering is om een standaard wapen en speldetector te kunnen ontwikkelen. Zo wordt aangeraden om het IR-protocol uit te breiden, zodat ook speler namen in het spel kunnen worden opgenomen. Voor het wapen wordt aangeraden om een tijdsynchronisatie in te bouwen zodat elke speler op hetzelfde moment in het spel begint.
47
10 Literatuurlijst [1] Wensink, M (2012), Reader Realtime System Programming (RTSP) versie 1114.
48
BIJLAGE 1 Requirements architecture Inleiding Voor project Lasertag is het de bedoeling dat een software-architectuur ontworpen wordt voor een realtime systeem en deze architectuur gerealiseerd wordt in programmacode voor het op te leveren product. Het op te leveren product is de programmacode in de vorm van sofware voor een detectorprototype van het lasertag-systeem van de firma TAG’M. Voordat software voor een systeem kan worden geschreven, moet eerst helder zijn wat de software voor het systeem moet gaan doen. Ten tweede moet helder worden hoe goed het systeem een bepaalde functie moet uitvoeren. Voor beide uitwerkingen is een software-model beschikbaar. Wat het systeem moet gaan doen wordt weergegeven in een usage model. De niet-functionele eis (een voorwaarde, oftewel constraint) aan een bepaalde functie wordt vastgelegd in een constraints model. Samen vormen deze modellen de requirements architecture. In hoofdstuk 1 wordt het usage model beschreven. In hoofdstuk 2 wordt het constraints model beschreven.
49
1. Het usage model Het eerste deel van de requirements architecture is het usage model. Hierin wordt vastgelegd wat het systeem voor de verschillende actoren doet. Eerst worden de actoren vastgesteld, vervolgens de doelen van de actoren die het systeem waar moet zien te maken (het use case diagram) en tot slot een uitwerking van de stappen die daarvoor genomen moeten worden (de activity diagrammen).
1.1 Beschrijving van de actoren voor de speldetector De actoren zijn de rollen die een gebruiker (mens of object) kan hebben wanneer het gebruik maakt van of invloed heeft op een systeem. In de onderstaande tabel zijn de actoren voor de speldetector vastgelegd. Actor
Beschrijving
Primair: PC
PC voor het loggen van treffers
Primair: Gebruiker
Drager van de speldetector
Primair: Afstandsbediening van spelleider
Afstandsbediening van spelleider
Secundair: Wapen van deelnemer
Wapen van de deelnemer
De actor PC is primair omdat het systeem de trefferdata naar de PC moet loggen. De actor gebruiker is primair omdat deze de drager is van de detector. Het systeem moet aan de gebruiker de speeltijd en de voortgang (overgebleven levenspunten) laten zien en een indicatie geven bij een hit. De actor afstandsbediening van spelleider is primair omdat deze het signaal aan de detector geeft om het spel te kunnen starten. De actor wapen van deelnemer is secundair omdat deze een van de voortgangswaarden van het spel beïnvloedt (levenspunten) door op de gebruiker te ‘schieten’. Hierdoor wordt het aantal levenspunten van de gebruiker verminderd.
50
1.2 Het use case diagram van de speldetector In het onderstaande use case diagram staan de drie hoofddoelen en twee sub-doelen van het systeem verwerkt. Deze (sub)doelen zijn: Het systeem moet voor de gebruiker de spel-voortgangswaarden tonen: o Hiervoor moet het systeem altijd de speeltijd tonen o Het systeem moet altijd infraroodsignalen kunnen decoderen om op IR-signalen van wapens van de deelnemers (treffers) te reageren, zodat de levenspunten van de gebruiker getoond kunnen worden (deze worden door een treffer verminderd).
Het spel moet door een (gedecodeerd) infraroodsignaal van de afstandsbediening van spelleider gestart kunnen worden.
Het systeem moet voor de PC de gegevens van de treffers kunnen loggen naar de pc zodat de winnaar uitgerekend kan worden.
Figuur 1.1 Het use case diagram van de speldetector
51
1.3 Beschrijving van de use cases voor de speldetector In deze paragraaf zijn de use cases uitgewerkt. De doelen, pre- en post-conditities en uitzonderingen zijn voor elke use case in onderstaande tabellen beschreven. Het doel geeft specificeert wat de use case moet doen. De pre-condities geven aan wat er gebeurd moet zijn voordat de use case uitgevoerd kan / mag worden. De post-condities geven aan waaraan het systeem moet voldoen wanneer de use case afgelopen is. Eventuele uitzonderingen geven aan als iets soms wel zou kunnen gebeuren, maar in de meeste gevallen niet zo is. Use case naam
Spelvoortgangswaarden tonen
Doel
De voortgang van het spel tonen (d.m.v. het aantal levenspunten en speeltijd).
Pre-condities
Het spel is geactiveerd.
Post-condities
De speler heeft geen levenspunten meer, de speeltijd wordt niet meer bijgewerkt en het LCD is leeg gemaakt.
Uitzonderingen
-
Use case naam
Speeltijd tonen
Doel
Tonen van resterende speeltijd aan de gebruiker.
Pre-condities
Het spel is geactiveerd.
Post-condities
de speeltijd is verstreken en de spel-voortgang wordt niet meer bijgewerkt
Uitzonderingen
-
Use case naam
Spel activeren
Doel
Het activeren van de taken die zorgen dat het spel gespeeld kan worden.
Pre-condities
De speldetector is niet geactiveerd.
Post-condities
De speldetector is geactiveerd.
Uitzonderingen
-
52
Use case naam
Infrarood-signalen decoderen
Doel
De binnengekomen signalen terugvertalen naar bits waaruit de gegevens van een bericht gelezen kunnen worden
Pre-condities
-
Post-condities
-
Uitzonderingen
-
Use case naam
Hits loggen
Doel
Alle treffers naar de PC loggen.
Pre-condities
De speldetector is in stand-by mode (en is aan de PC gekoppeld).
Post-condities
De speldetector is uit stand-by mode (en is niet meer aan de PC gekoppeld).
Uitzonderingen
-
53
1.4 Activity diagrams voor de speldetector Om een beter beeld te geven van de use cases is voor elke use case een activity diagram uitgewerkt. Deze diagrammen tonen de stappen die de speldetector moet uitvoeren om aan het doel van de actoren te voldoen. De uitwerkingen zijn gebaseerd op de ‘Must Haves’ van de functionele specificaties. De functionele specificaties zijn als bijlage 1 van dit document opgenomen.
1.4.1 Activity diagram voor use case ‘Spel activeren’ De spelleider moet het spel activeren door met zijn afstandsbediening een IR-signaal af te vuren op de speldetector. Om het ‘spelleider’ signaal te kunnen afhandelen moeten IR-signalen altijd worden gedecodeerd. Na ontvangst van het ‘spelleider’ signaal wordt 10 seconden afgeteld - dit wordt op het LCD getoond - en daarna wordt het signaal gegeven om het spel te starten. Ingaande events: Signaal ‘spelleider’ om het spel te kunnen aftellen en het spel te starten. Uitgaande events: Signaal ‘spel starten’ om het spel te starten.
Figuur 1.4.1 AD spel activeren
54
1.4.2 Activity diagram voor use case ‘Spelvoortgangswaarden tonen’ De voortgangswaarden van het spel zijn de speeltijd en de (resterende) levenspunten. Er moeten altijd IR-signalen worden gedecodeerd om een indicatie van een hit van een deelnemer af te handelen zodat de (resterende) levenspunten getoond kunnen worden. Het tonen van de voortgangswaarden van het spel stopt als de speeltijd van 10 minuten voorbij is of als de 20 levenspunten op zijn. Ingaande events: Dat het spel gestart mag worden d.m.v. signaal ‘spel starten’. Een indicatie bij een hit d.m.v. signaal ‘deelnemer’ om de levenspunten te verminderen en een LEDlampje kort aan te zetten. Een indicatie van de verstreken speeltijd d.m.v. signaal ‘speeltijd voorbij’. Uitgaande events: Een indicatie dat de levenspunten op zijn d.m.v. signaal ‘game over’ om de speeltijd te stoppen. Een indicatie dat het loggen van treffers gestart mag worden d.m.v. signaal ‘start loggen’ als de levenspunten 0 zijn of als de speeltijd voorbij is. Wanneer de speler door de levenspunten heen is, wordt het bericht ‘Dead’ op het scherm getoond. Als de uitvoering onderbroken is, wordt het LCD geleegd en wordt het laatste uitgaande event gegeven (start loggen).
Figuur 1.4.2 AD Spel-voortgangswaarden tonen
55
1.4.3 Activity diagram voor use case ‘Speeltijd tonen’ Naast het tonen van de spelvoortgangswaarden moet de speldetector ook de speeltijd tonen, in figuur 1.4.3 is hier de werking van vastgelegd. Zodra het spel gestart is wordt de speeltijd, die start op de standaard tijd van 10 minuten, elke seconde verminderd met 1 seconde totdat de speeltijd voorbij is of de speler game over is gegaan. Ingaande events: ‘game over’ om de speeltijd niet meer te tonen. Uitgaande events: ‘speeltijd voorbij’ als de speeltijd verstreken is.
Figuur 1.4.3 AD Speeltijd tonen
56
1.4.4 Activity diagram voor use case ‘Infrarood-signalen decoderen’ Om de treffers van deelnemers te kunnen verwerken en om het spel te kunnen activeren door de spelleider moet de speldetector ten eerste deze signalen binnenkrijgen. Om zeker te zijn van de gegevens van een bericht wordt het bericht zoals beschreven in de casus drie keer ingelezen met een interval van 5ms. Vervolgens zullen deze berichten vergeleken worden om te kijken of de gegevens van de berichten kloppen en compleet zijn. Als een bericht goed ontvangen is zal de decoder kijken naar de gegevens van het bericht en op basis van de afkomst van het bericht zal de decoder een signaal geven. Hier wordt onderscheid gemaakt tussen twee soorten berichten: afkomstig van een deelnemer of afkomstig van de spelleider. Bij een bericht van een deelnemer zal de decoder bericht sturen naar spelvoortgangswaarden tonen om de levenspunten bij te werken. Als het bericht afkomstig is van de spelleider zal het signaal gestuurd worden naar spel activeren. Uiteindelijk zal de decoder weer wachten op nieuwe inkomende IR berichten.
Figuur 1.4.4 AD Infrarood-signalen decoderen
57
1.4.5 Activity diagram voor use case ‘treffers loggen’ Tot slot moet het systeem aan het einde van het spel de informatie over de treffers versturen naar een PC. Om de gegevens te kunnen versturen moet de speldetector weten dat de PC de informatie kan ontvangen. Hier is gekozen om te wachten op een log-signaal die op het moment van het aansluiten direct verstuurd wordt vanaf de computer. We hebben hiervoor gekozen omdat na de bespreking met de klant het gemakkelijker bleek om niet te hoeven richten met het wapen op de speldetectoren.
Figuur 1.5 AD treffers loggen
2 Constraints model Het constraints model heeft als doel het duidelijk maken van de voorwaarden waaraan het systeem moet voldoen. Dit wordt gedaan aan de hand van verschillende eisen. Deze zijn op te delen in onder andere accuracy en performance. De constraints model is opgesteld op basis van nauwkeurigheids- en tijdsvoorwaarden van het systeem. In paragraaf 2.1 wordt het constraints model getoond. In paragraaf 2.2 wordt er een uitleg gegeven over de verschillende data die in het model worden gepresenteerd.
2.1 Constraints model voor casus lasertag In het volgende model worden alle constraints uitgebeeld voor het product. Deze constraints zijn opgedeeld in accuracy en performance. Constrainttype Accuracy
Identificatie treffer-detectie
Beschrijving Eis Binnen een Binnen 3 IRaantal maximum signalen ontvangen IRsignalen moet duidelijk zijn wie de deelnemer is.
Verificatie 3x de bitjes opslaan in een variabele en tonen in de commandprompt.
Speeltijd bijhouden
De maximale afwijking die de
Nagaan of de gespeelde tijd
Maximaal 2 seconden
58
totale speeltijd mag hebben van de werkelijke tijd. Performance
Treffer-detectie
Tijd waarbinnen een inkomend infrarood signaal uitgelezen wordt. Tijd waarbinnen het gedetecteerde IR-signaal verwerkt wordt.
Binnen 150 ms
LCD
Hoe snel een serie karakters op het LCD wordt gezet
Binnen 150 ms
Spel start en spel einde
Wanneer de actie na een gebeurtenis, zoals na de countdown vóór het spel/ na het einde van het spel, behandeld moet worden. Wanneer een IR signaal ontvangen is, zal er een tijd gewacht moeten worden voordat het nieuwe IR signaal binnenkomt
Binnen maximaal 400 ms.
Treffer verwerken
Tijd tussen IR Signalen
Binnen 50 ms
overeenkomt met de tijd van een lopende klok en gemeten met een stopwatch. Armboard-tijd in een variabele zetten en na laatste instructie in commandprompt tonen. Armboard-tijd in een variabele zetten en na laatste instructie in commandprompt tonen. Armboard-tijd in een variabele zetten en na laatste instructie in commandprompt tonen. Armboard-tijd in een variabele zetten en na laatste instructie in commandprompt tonen.
maximaal 5ms
59
2.2 Uitleg constraints-tabel In het constraints model zijn een aantal termen genoemd. Deze termen hebben te maken met de eisen die gesteld zijn aan het product. In de volgende sub-paragraven zal het opvolgend gaan over accuracy en performance.
2.2.1 Accuracy Accuracy heeft aan hoe nauwkeurig iets moet werken. Accuracy is weer opgedeeld in snelheid, tijd en de klok. Bij snelheid wordt bedoeld hoe snel iets wordt gedaan in het programma. In de tabel wordt bij snelheid gesproken over hoe snel een binnenkomende signaal verwerkt moet worden. Onder tijd valt hoeveel de speeltijd maximaal mag afwijken van de tijd die werkelijk gespeeld is.
2.2.2 Performance Performance beschrijf hoe snel een functie moet worden uitgevoerd. Wanneer het over realtime systemen gaat is de timing erg belangrijk. Een goed voorbeeld hiervan is bijvoorbeeld de tijd die het kost om een treffer te detecteren. Dit moet snel gebeuren zodat het spel in een goede flow blijft. Wanneer een treffer niet op tijd gedetecteerd word, zouden meerdere spelers op een detector kunnen blijven vuren voordat het systeem echt reageert. Dit is natuurlijk niet de bedoeling. Ook de verwerking van de treffer komt hierbij kijken, de treffer moet vanzelfsprekend ook gelijk verwerkt worden. De snelheid van het schrijven van karakters naar een LCD komt hier ook bij kijken, maar heeft een minder hoge prioriteit dan het verwerken van een treffer.
60
BIJLAGE 2 Testcode De code die ontwikkeld is om een onderdelen van de speldetector te testen zijn hieronder beschreven. Testprogrammatuur voor de het bitshiften in de DecodeHandlerTask Om de patronen uit een IR-signaal te filteren, zoals de xor-bits, commando-bits en speler(sender)-bits is vooraf getest met bitshift-operaties. Een willekeurig getal simuleert de bitjes in een patroon. Na een (logische) operatie op het getal blijft het juiste patroon over. //getting XOR short getal = 44; short uitkomst = getal & 0x1F; std::cout << uitkomst; // 12 // getting CMD short getal = 32; short uitkomst = (getal >> 5) & 0x1F; //5 plaatsen naar rechts ( en niet 4 i.v.m. 0..4 ), dan AND uitvoeren voor 5 bitjes std::cout << uitkomst; // 1 // getting Sender short getal = 1024; short uitkomst = (getal >> 10) & 0x1F; //10 plaatsen naar rechts ( en niet 4 i.v.m. 0..4 ), dan AND uitvoeren voor 5 bitjes std::cout << uitkomst; // 1
61
Testprogrammatuur voor het aansturen van RTOS Tasks Om te voorkomen dat later grote problemen op komen zetten, door het hele programma heen, zijn tussendoor kleine RTOS tasks gemaakt die een bepaald deel van het systeem testen. TestTask voor de GameHandlerTask De GameHandlerTask was een van de eerst compilerende onderdelen. Om te kijken of de functionaliteit ook echt goed werkte, is hiervoor een kleine RTOS test task gemaakt. Deze test task geeft met een interval van 1 seconde bepaalde commando’s door zoals deze later door de IRDecodeTaskgegeven zullen worden. class TestGHT : public RTOS::task { public: TestGHT(GameHandlerTask & aght) : task(5,"test"), _ght(aght), t(this, 1000000, "testClock"){}//, _ght(ght){} private: GameHandlerTask & _ght; RTOS::clock t; void main( void ){ int i = 0; for(;;){ wait(t); if(i++ == 0) { SignalData sd; sd.senderID = 0; sd.commandID = 0; _ght.gameMaster(sd); }
Het GameMastersignaal - 1x
if(i%15 == 1) { SignalData sd; sd.senderID = i %4; sd.commandID = 1; _ght.player(sd); Het Speler} signaal - elke 15 s } } };
62
TestTask voor de DecodeHandlerTask Na het testen van de GameHandlerTask was het de beurt aan de IRDecodeTask om getest te worden. Deze taak werkt hetzelfde als de TestTask voor de GameHandlerTask maar stuurt in plaats van de GameHandlerTask de IRDecodeTask aan. class TestDHT : public RTOS::task { public: TestDHT(IRDecodeTask& adht) : task(6,"testDHT"), _dht(adht), t(this, 1000000, "testClock"){}//, _ght(ght){} private: IRDecodeTask& _dht; RTOS::clock t; void main( void ){ ReceiveData rd; short data = 1; int i = 0; for(;;){ wait(t); switch(i++) { case 1:Gamemaster signaal 00000-00000-00000 rd.signal[0] = rd.signal[1] = rd.signal[2] = 0x0000; _dht.dataReceived(rd); break; case 15: case 26: Speler signaal data = 1 << 10; 00001-00001-00000 data = data + (1 << 5); rd.signal[0] = rd.signal[1] = rd.signal[2] = data; _dht.dataReceived(rd); break; case 68: data = 1 << 10; //test serial input break; } } } };
63
Testen van de inkomende IR-signalen: std::cout << "\nReceived Bits\n"; std::cout << "-------------\n"; for(int k = 0; k< 3;k++) { for(int j = 0; j < 15; j++) { std::cout << ((rawData.signal[k] & (1 << 14 - j)) >> (14 -j)); } std::cout << "\n"; } std::cout << "-------------\n";
64
BIJLAGE 3 Lasertag handleiding In deze handleiding gaan we in op het gebruik van de detector voor het spel, zodat we u in goede banen kunnen leiden voordat u deze in gebruik neemt, of wanneer u deze al in gebruik heeft genomen. De focus word gelegd op wat de detector van u verwacht en wat de detector van de spelers verwacht. Activatie van het spel Wanneer de lasergame start wacht de detector op het activatie signaal van de spelleider. Op het beeldscherm word nu “waiting for activation” getoond. Wanneer de spelleider het spelactivatie signaal heeft verstuurd word er vanaf 10 afgeteld. Nadat er is afgeteld word het spel gestart en kan er met de wapens op de detectoren geschoten worden.
Figuur 1 Wachten voor spelactivatie
Figuur 2: Het aftellen is begonnen
Speler spelverloop Tijdens het spel word er continu door de spelers op elkaar geschoten. Wanneer een speler een andere speler raakt worden van de geraakte speler levenspunten afgetrokken. Dit aftrekken van levenspunten gaat zo lang door als dat de speler levenspunten heeft, hierna is de speler dood en word er op het beeldscherm een “u bent verslagen” tekst getoond.
Figuur 3 Spel informatie
Figuur 4 Alle levens zijn op
65
Het kan natuurlijk ook voorkomen dat de tijd is afgelopen voordat de levenspunten van de speler op zijn. Wanneer dit gebeurt word er op het LCD een “tijd voorbij” tekst geplaatst zodat de speler weet dat de tijd is afgelopen. Ook zal er worden overgegaan naar het loggen van de speldata.
Figuur 5: Speeltijd afgelopen
Spelerdata loggen Als het spel voorbij is zal de speler gevraagd worden om de speldetector aan de computer te koppelen zodat over de seriële verbinding de speldata verzonden kan worden. Om de speldata te versturen wanneer de detector aan de computer gekoppeld is, moet de spelleider het ‘log signaal’ versturen. Het loggen zal nu starten
Figuur 6: Het log verzoek
Figuur 7: Het loggen is voltooid
Reactivatie Nadat het loggen van de speldata voltooid is wordt het spel opnieuw gestart, er word dan weer gewoon bij de eerder besproken ‘Activatie van het spel’ gestart.
66
BIJLAGE 4 De wapens
Wapen DB038
Wapen DB103
67
De wapens die gebruikt zijn voor het project zijn de DB038 en de DB103. Deze wapens worden gebruikt om een infrarood signaal te versturen naar de ontvanger. In de casus wordt het wapen buiten scope beschouwd maar uiteindelijk is hier ook aan geprogrammeerd. De DB038 draait op een PIC 16F887 processor die volgens de Harvard architectuur is gebouwd. Deze processor wordt geprogrammeerd via de IDE MPLAB X. De DB038 heeft een 20 MHz kristal waar één vijfde van gebruikt wordt. Dit was in het begin ook meteen het probleem. Het wapen werkte niet goed met de ontvanger en uiteindelijk bleek de frequentie voor de processor verkeerd ingesteld te zijn. In plaats van 20 stond 4 MHz ingesteld, dit is 5 keer trager dan eigenlijk zou moeten. In de eerste instantie zou dit wapen niet ondersteund worden in het project, maar op het einde is het toch gelukt om de DB038 aan de praat te krijgen. Voordat verzonden wordt, moet eerst de speler en het wapen geselecteerd zijn. Het wapen onthoudt deze keuze niet in tegenstelling tot de DB103. De DB103 is een ARM gebaseerde microcontroller. De processor is een LPC1114FN28/102. Deze microcontroller wordt gewoon in PSPad geprogrammeerd net zoals de ontvanger. Het probleem van de DB103 was dat eerst de configuratie van de PC goed gezet moest worden om naar het bordje toe te kunnen schrijven. Hiernaast moest ook eerst de C-lib voor de keyboard volledig naar C++ omgeschreven worden.
68
BIJLAGE 5 Het definitieve klassendiagram
Figuur 4.11 Het definitieve klassendiagram
69
