2011/01/11 - Daniel

11 Januar

Tilstedeværende: Daniel
Varighed: 2 timer
Mål: Implementation af lysSensor NXT'en der skal styre reglerne
Plan: Analysere behovene for lysSensor NXT'en og implementere kode til at opfylde de behov.

Det er en prioritet at sensorene reagerer hurtigt på bolde og ikke venter på en bold ved den anden sensor, dvs. de to sensorer kører uafhængigt af hinanden. Derfor virker det åbenlyst at gøre hele systemet multi threaded og lade hver manager styre sin egen sensor. Det gør systemet mere komplekst, men det giver større sikkerhed for at systemet registrerer alle bolde.

For at kunne genbruge koden til hver sensor bliver der også lavet en main tråd der styre reglerne som så skal modtage signaler fra de to managers, derved kan koden for hver sensors tråd være ens hvilket letter implementationen og reducerer debugging. Det betyder godt nok at opstarten af de to manager tråde bliver mere avanceret og at man bliver nødt til at tage hensyn til concurrency problemer i main tråden, som begge managere skal kalde ved hver ændring.

Besluttede også at LCD’en skulle bruges til at repræsentere scoren for hver sensor samt forskellen i scoren. Dermed kan kampens stilling hele tiden følges.

For at kunne lave den samme kode for begge managers skal der ved initiering bruges et “LightSensor”-objekt, en linje hvor scoren skal skrives ud på LCDen, et “LysNxtMain”-object som denne sensor er koblet på og den lysværdi hvorved boldsensoren skal registrere bolde.

Derudover er implementationen af Managerene meget lige til og kan ses her:

Main tråden har en “changeScore”-metode som de to managers kalder hver gang scoren er ændret og med hvor meget den er ændret. Main tråden ændrer scoren og tjekker så om de gældende regler er overholdt (reglerne forklare jeg senere). Da denne metode er en delt ressource mellem to eller flere tråde er man nødt til at overveje de concurrency problemer det medfører.
Der kan opstå race conditions (http://en.wikipedia.org/wiki/Race_condition#Computing) hvis “changeScore” ikke bliver synchoniseret.
Da der ikke findes nogen cyklisk afhængighed eller “hold and wait” kan der ikke opstå en deadlock (http://en.wikipedia.org/wiki/Deadlock#Necessary_conditions).
Når det er implementeret er systemet concurrency sikret.

Til sidst ville vi også gerne implementere et ur til spillet, så man kunne se hvor lang tid der var gået. Men vi kunne ikke finde nogen timer implementation der kunne det (senere fandt vi ud af at der var en “stopwatch” i Lejos) så vi implementerede en timer der skulle tælle en int op hver sekund. Det betød at en 4. tråd blev startet op til det formål, men da ingen af trådende har nogen tunge udregninger var der ingen problemer med schedulering.

Der var ikke tid til at implementere kommunikationen over bluetooth til PC i dag, men hvis der bliver tid til det fremover skal det implementeres.

Her er et diagram over det færdige system:

Reglerne
Vi har implementeret spillet sådan at den ene sensor tæller scoren op, mens den anden tæller scoren ned. Så hvis en bold kommer igennem hele banen så vil der ikke være nogen ændring i “balancen”, men hvis bolden ikke når frem (eksempelvis fordi midter robotten blokere bolden) så vil der være en ubalance. Hvis ubalancen overskrider 10 eller -10 så er spillet ovre.

Derfor gælder det om for midterobotten at få så mange bolde igennem hele banen som muligt, om det så betyder at den skal skubbe nogen igennem fordi de ramte kanterne. Når spillet er ovre kan man se hvor længe man overlevede og konkurrere med sine venner.

Konklusion
Det lykkedes at lave LysNXTen færdig i dag med sensorer, regler alt imens der tages hensyn til concurrency. Da jeg ikke havde en nøgle kunne jeg ikke teste at det fungerede, men jeg testede at det kunne compile, og vil teste at det virker i morgen.