Konklusion

Projekt konklusion
Kompromisser

• Banens væg (der ligger mellem bakken og EndeRobotterne) højde er et kompromis. Da den skulle være højere for at kunne stoppe alle bolde, men så kunne vi ikke sparke til boldende eller se boldende da lyssensorene ville blive blokeret.

Problemer
Vi har undervejs i projekter brugt meget tid og energi på nogle ting der af forskellige årsager ikke er med i det endelige projekt. Dette drejer sig om:

• Wiimote

• Vi ville oprindeligt bruge en Wiimote til at styre midterrobotten, men fandt først sent ud af at dette var meget besværligt da wiimote og NXT bruger to forskellige bluetooth stacks.
• Det lykkedes os aldrig at få kommunikation i mellem wiimote og PC til at køre samtidig med at NXT og PC kommunikerede.

• Bluetooth

Vi ville oprindeligt gerne have reglerne implementeret i PC, der fik signal fra de forskellige NXT’er, f.eks. om at der var skudt til bolden mv. Vi havde desværre nogle (unødvendigt) store problemer med at bruge bluetooth da vi havde fået opsat forbindelsen forkert, og var længe om at finde denne fejl. Da vi fik bluetooth mellem PC og flere NXT’er til at virke, var tiden så fremskreden at vi opgav denne del af projektet og implementerede reglerne direkte i lysNXT’en der fik et større ansvar end det var meningen fra starten.

Andre problemer der til sidst blev løst

• Enderobotter

Undervejs har vi haft en del besvær med vores enderobotter og det at de ikke altid stoppede inden de skød til bolden. Dette problem har vi brugt lang tid på at debugge, uden rigtig at få det løst. Til vores store glæde lykkedes det kort før deadline at få løst dette problem.

Godt
Vi har nogle elementer i vores projekt vi er stolte af, flere af delene har vi brugt en del tid og energi på at få til at virke tilfredsstillende.

• Midterrobot

• Midterrobotten sørgede for at vi fik genopfrisket vores vektorregning. Vi er rigtig glade for at vi har fået den til at køre så godt og stabilt. Vi er også glade for at vi har fået brugt omnihjulene i projektet, da de har været en sjov motivationsfaktor i gruppen.

• Enderobot

• Slåarmen bruger motoren til at trække elastikken op, der så virker som fjeder. Når armen kommer ud over rampen sparker den til bolden, og kræften som der sparkes med kan nemt justeres ved at flytte på elastikket.
• Arkitekturen med behavior-based design virker rigtig godt, og har gjort det nemmere at debugge koden, da det har været med til at holde koden simpel. Desuden gør det at lave flere behaviors for at udvide funktionaliteten i enderobotten, eller redigere nuværende funktionalitet er væsentlig nemmere.

• LysNXT

• Det lykkedes at lave LysNXTen færdig i projektet med sensorere, regler og concurrency sikkerhed.

Fremtiden
Hvis vi havde haft 14 dage til ville vi havde implementeret disse dele.

• Alle enheder skal via bluetooth kobles til en PC der håndterer spillet. Det betyder at sensorene sender data til PC’en som kender reglerne, styringen af midterrobotten og eventuelt kunne man styre endeRobotterne manuelt (hvis man var flere spillere) alt fra den samme PC.
• Når reglerne lå på PC’en og PC’en havde alle informationer om spillets tilstand så kunne man lave mere avancerede regler (da man kunne tælle antal spark og lignende) samt have flere forskellige spiltyper man kunne vælge imellem.
• For at midterrobotten ikke kan bryde lyset ved lysSensorene, skulle der være en markering på banen som robotten skulle kunne registrere (eksempelvis mørk tape kombineret med en lyssensor monteret på robotten) og en behavior i robotten der gjorde at markeringen ikke kunne krydses.
• Ud over det ville vi også implementere et handicap system på midterrobotten. Handicapsystemet skulle sørge for at ændre på sværhedsgraden af robotten ved f.eks. at styre hvor hurtigt robotten kan køre. Andre handicaps kunne være at sætte begrænsninger på hvor meget man kan køre i hver retning så man skal bevæge sig så lidt som muligt for at undgå boldene.
• Hvis vi havde mere tid i slutningen af de 14 dage kunne vi gøre midterobotten automatstyret. Men da hele systemet allerede er koblet op med bluetooth, mangler vi bare en måde at holde styr på positionen af midterrobotten. Her springer kameratracking op som det åbenlyse valg da denne også gør computeren i stand til at se hvor boldene befinder sig så den kan undgå dem.

Andre overvejelser
Efter fremlæggelsen af projektet har vi overvejet at det ikke nødvendigvis er et single-player spil, da det er nødvendigt at der står en spiller mere i hver ende for at samle bolde op der enten kommer for langt eller kort. Man kan være op til fire spillere, en i hver ende, en til at styre midterrobotten og en til at samle de bolde op der rammer midterobotten og det er stadig sjovt for alle.

Konklusion
Alt i alt har vi fået lavet et projekt der kan næsten det vi havde som vision fra starten. Det eneste der ikke er blevet til noget er kommunikationen mellem PC og bluetooth, som også er det vi ville arbejde på hvis vi havde haft mere tid.
Herudover var vores første ide at der skulle spilles med en bold og at smørklatten skulle forsøge at fange den, dette blev gennem projektet lavet om, da det virkede sjovere at spille med flere bolde og forsøge at undgå disse.


Til sidst har vi samlet alt kode, billeder og videoer her:

• Billeder taget i løbet af projektet kan ses her
• Alle youtube videor der er taget i løbet af kurset har vi uploadet her
• Kode fra projektet:
• NXT kode
• PC Applikationer
• Android Applikation

2011/01/13

13. januar 2011
Tilstedeværende: Lars Christian, Daniel og Line
Varighed: 4 timer
Mål: Fremlæggelse
Plan: Sætte op, teste, ændre kode hvis nødvendig, fremlægge.

Vi startede med at konstatere at der var for mørkt i lokalet til at vi kunne registrere de blå bolde fra enderobotterne, derfor ændrede vi koden så vi i searchBehavior ledte efter noget der var lysere end omgivelserne i stedet for mørkere.
Før:
…

// Så længe værdien er større end lysværdien for bolden gør vi ikke noget

while ( value >= lightvalue ){...}
..
Efter:
…
// Så længe værdien er mindre end lysværdien for bolden gør vi ikke noget
while ( value <= lightvalue ){...}



Vi forsøgte at afhjælpe problemet med at robotten ikke altid stoppede for at skyde ved at undersøge hvad der var der gik galt så stop ikke kom igennem til motorene. Vi prøvede at indsætte et beep i searchBehavior så det blev kaldt efter vi havde kaldt stop. Herefter kørte vi programmet så vi kunne høre hvad der skete. Når robotten så en bold beepede den og slog med armen, uden at stoppe.
Vi overvejede den måde implementation i Wheels brugte motoren på, men ændrede ikke noget. Da vi ikke kunne løse dette problem gik vi videre til at forsøge at lave en driveCloserfunktionalitet.

//Vi har set bolden en gang, og nu skal vi så finde den igen.
suppress();
stop();
delay(500);
//driveCloserToBall();

boolean orgDir = getDirection();
int i = 0;
while(value <= weightedValue){
value = light.readValue();
if(orgDir) { //getdirection == true => robotten kører forward
backward(60);
}
else{
forward(60);
}

if(getDirection() != orgDir || i > 100){
stop();
break;
}
delay(10);
i++;
}
if(getDirection() == orgDir) {
stop();
kick();
}

Her går vi ind og kører med motoren, fremfor bare at kalde stop(), og dette tror vi har resulteret i at robotten altid stopper, og altid kører tættere på bolden hvis der ikke er den ønskede lysværdi.
Her er også implementeret at vi venter et sekund, og hvis vi ikke har fundet bolden der, skyder vi og kører videre, dette er for at undgå at robotten sidder fast et sted hvor den ikke kan finde bolden, eller hvis bolden blot er en skygge.
Koden kan ses her.
Og en video af projektet i funktion kan ses her:

2011/01/12 - Sidste journal

Til stede: Line, Lars Christian og Daniel
Varighed: 8 timer
Mål: At få alle delene til at køre sammen og gøre klar til fremlæggelse.
Plan: Daniel og Line kalibrerer og tester lysNXT, Lars Christian bygger slåarmen om (igen), herefter prøver vi at få enderobotten til at stoppe hver gang, samt evt. at køre tættere på bolden.

Test af LysNXT
Vi startede dagen med at opdage at vi ikke helt havde overvejet hvor lange ledningerne til NXT’en er. Derfor måtte vi indse vi ikke kunne bruge de nye lyssensorer til at måle hvorvidt en bold havde passeret lyset eller ej. I stedet brugte vi de gamle lyssensorer, der heldigvis kunne registrere den nødvendige ændring i lyset.
Vi startede med at teste lysNXT der har reglerne til spillet (efter at have ændret sensorene til RCXLightSensor). Dette gjorde vi ved at montere lamper og sensorer på banen, hvorefter vi undersøgte værdierne for lysintesiteten og hardcodede dem i programmet. Da vi havde testet at NXT’en kunne registrere hver gang en bold kom forbi, implementerede vi en kalibrerings funktionalitet der bruges når programmet startes.
Herefter testede vi med enderobotten at lysNXT’en registrerede når der blev skudt.
Det hele virkede herefter som forventet.

Konfigurering af enderobot
Vores mål for i dag var at få enderobotten til at stoppe hver gang den skyder, og herefter lave driveCloserToBall der sørger for at vi kommer tættere på bolden.
Vi forsøgte os med en masse ændringer for at forhindre robotten i at køre imens den sparkede efter bolden, bl.a. prøvede vi at ændre måden hjulene blev kontrolleret ved at skifte fra MotorPort til Motor.
Dette resulterede i at robotten aldrig stoppede for at skyde. Vi forsøgte os med flere forskellige ændringer uden held.

Her er koden til det der ikke virkede: rev. 140 - virker ikke

Vi sluttede med at gå tilbage til en gammel revision, hvor den grundlæggende funktionalitet med at skifte retning, og (for det meste) stoppe før den skød til bolden. Koden ses her.

Når vi ser på det i bakspejlet burde vi have logget mere præcis hvad der skete, endten ved brug af dataloggeren, eller ved brug af bluetooth kommunikation. Havde vi gjort det havde vi været i stand til at se mere præcist hvad der skete, om stop aldrig blev kaldt, af wheels eller af Behavior og på den måde kunne vi måske have fundet fejlen.

Planlægning af fremlæg
Vi brugte noget tid på at lave en struktur og udbygge denne, som vi finpudsede og godkendte. Hvorefter vi lige øvede den igennem en enkelt gang. Vi lavede to poster - “Hall of fame” og “Hall of shame”, der indeholdte de ting vi var stolte af og de ting der ikke var lykkedes men der var brugt meget tid på.

Konklusion
Vi har testet lysNXT og tilføjet kalibrering, den kan nu styre spillets regler.
Vi har i dag ikke nået vores mål, vi har prøvet at undersøge grunden til at vores enderobotter ikke altid stopper for at slå til bolden, uden held til at finde årsagen. Vi forsøgte også at ændre måden vi brugte motorene på, men dette forværrede blot problemet. For at få det grundlæggende til at virke måtte vi gå tilbage til en gammel revision.
Vi har planlagt oplægget til i morgen, og snakket om hvad der har været godt og skidt.

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.

2011/01/11 - Line

11. januar

Tilstedeværende: Line
Varighed: 4 timer
Mål: Få robotten til at vende i enderne selvom den har ramt en bold, evt. at få robotten til at køre tættere på bolden inden den skyder. Bygge den anden robots skydearm om.
Plan: Starte med at få robotten til at køre rigtigt, herefter finjustere skydningen

Mystisk problem hvor robotten ikke skiftede retning i enderne selvom dette var den behavior der havde 1.prioritet. Efter lang tids debug + hjælp fra Ole og en anden gruppe fik vi løst problemet, jeg havde været så tumpet at tænke suppress og release lidt som låse som vi kender dem fra concurrency og derfor gladeligt ændret på globale variable - der overhovedet ikke var supressed. Problemet blev løst og robotterne kører nu pænt.
Koden så således ud før problemet blev løst:

public class searchBehavior() extends Behavior{
...

supress();

dir = getDirection();

stop();

delay(500);

driveCloserToBall();

kick();

//TODO: send signal

setDirection(dir);

release();

…
}
           

Dette problem resulterede i at robotten ikke altid skiftede retning når den nåede enden. Dette skete kun når robotten også skulle slå til bolden. Dette skete når vi så en bold og derfor satte dir = getDirection(), herefter så vi sort og derfor i stopBehavior kaldte setDirection(!getDirection) hvorefter vi i searchBehavior fortsatte og kaldte setDirection(dir) og dermed satte den tilbage til det den var før robotten så sort.

Da setDirection ikke længere var i koden (og driveCloserToBall også var udkommenteret) for searchBehavior kørte robotten igen som forventet, bortset fra at den ikke altid stoppede når den skulle skyde til en bold.

Konklusion
Jeg har fået robotten til at køre mere stabilt, og som forventet, da jeg indså jeg ikke skulle ændre på globale variable i mere end en behavior.
Det næste der skal laves er funktionaliteten med at køre tættere på bolden inden der skal skydes, og at robotten stopper hver gang den ser en bold.

2011/01/08

8. Januar

Dato: Lørdag d. 8/1 2011
Tilstedeværende: Daniel, Line og Lars Christian
Varighed: 5 timer
Mål: Enderobotten skal være bedre til at ramme bolden, bluetooth skal virke mellem flere robotter og pc, enderobotten skydearm skal bygges om så den ikke falder af.
Plan:Line justerer enderobotten så den rammer bedre (programmering), LC bygger enderobottens skydearm om så den ikke falder af samt arbejder på midterrobotten og hjælper, Daniel arbejder på bluetooth kommunikation imellem flere devices.

Finjustering af skyder:
Line forsøgte at justere præcisionen hvormed armen ramte bolden. Dette gjorde hun ved at sende endu en lysværdi med til vores behavior fra kalibreringsdelen. Denne værdi bruges i metoden "moveCloserToBall" i searchBehavior. Her bruges den så vi tjekker værdien af lyssensoren og hvis den ikke er boldværdien + 1 eller derunder forsøger vi at køre tættere på.
For at køre en lille smule i en retning forsøgte vi at lave en metode i Behavior klassen "aLittleForward" og "aLittleBackward" der kørte i 10 ms og stoppede igen. Det viste sig at motorene på 10 ms ikke kunne nå at flytte bilen, og dermed stod og knitrede lidt uden at der skete mere.

Udover dette problem har vi også hele tiden haft et problem med at robotten ikke stopper når den skal skyde, selvom dens behavior er programmeret til netop dette. Vi har snakket om at dette muligvis kan begrundes med at der er for mange tråde robotten skal holde styr på på en gang (der er 3 - drive, stop og search behavior). Da det ikke er dybt nødvendigt både at have en drive og en stop behavior har vi prøvet at slå disse sammen til en behavior for at mindske mængden af tråde.
Dette er muligt selvom hierakiet hedder

1. Stop
2. Search
3. Drive

Da funktionaliteten af drive og stop godt ville kunne implementeres i en enkelt behaviour der kørte den ene vej indtil den mødte sort. Dog ville det give problemer da vi så er nødt til at tage hensyn i vores search behaviour til at vi kan køre ud over banen, i stedet for nu hvor Stop sørger for at det aldrig sker.

Dette har vi gjort ved at samle det hele i en "DriveStopB" (=DriveStopBehavior), der har ansvaret for både at køre og skifte retning i begge ender. For at vi stadig kan kan overtage magten med search hvor som helst i DriveStopB, undtagen når denne har låsen, er det nødvendigt at vi kan holde styr på om DriveStopB har været afbrudt - f.eks. mens den stod og kiggede efter hvidt underlag (while-løkke). Dette er nødvendigt fordi at vi er nødt til at bryde ud af disse løkker og starte forfra i metoden med at sætte robotten igang med at køre, da den ellers bare står stille efter den har skudt med armen (fordi den søger efter hvid uden at køre). Dette er gjort ved at implementere to metoder i Behavior-klassen "setBeenSupressed" og "beenSupressed" der hhv. sætter og beder og en boolsk værdi der repræsenterer om der har været kaldt supress eller ej.
Når motorene er sat i gang sætter vi denne værdi til falsk og tjekker den så i while-løkkerne.

Vi er er i gruppen klar over (nu) at vi har misforstået noget. Ovenståene afsnit er ikke blevet skrevet om for at tydeliggøre denne misforståelse, nemlig at vi troede at vi havde en lås over den anden tråd. Det vi egentlig havde var ikke en generel lås, men en lås på den ene motor som vi bruger til styre om robotten. Denne misforståelse var grunden til denne omstrukturering af kode, til en blanding mellem behavior-based og sekventielt (se næste blog for uddybning).

Denne omstrukturering virker dog ikke helt efter hensigten og derfor gik vi tilbage til den originale struktur, og forsøgte at finde løsningen på problemet med at stoppe.

Bluetooth til flere devices:
For den videre implementation af projektet var det en prioritet at vide om vi kunne koble op til flere devices og om der vil være nogen nævneværdig forsinkelse af beskeder hvis man koblede flere device til en PC.

Så Daniel lavede et program der kunne koble op til 3 andre bluetooth devices, så skulle den sende en besked til alle de devices der var koblet op til PC’en i øjeblikket. Disse devices skulle alle sende besked til  PC’en hvor mange beskeder de havde modtaget indtil videre på denne opkobling. Hver gang man genstartede koblingen til et device skulle den nulstille antallet beskeder den havde modtaget.

Samtidig eksperimenterede vi med at sende tekst. Da det ikke direkte er understøttet af Lejos besluttede vi os for først at sende en int (som beskrev længden af en besked) og så en række chars der repræsenterede hele beskeden.

Alt gik efter planen, da der er gode ressourcer at hente eksempler fra på nettet. Samtidig erfarede vi at grunden til at Daniel havde haft så mange problemer med forbindelsen før jul (og i går) var fordi han havde oprettet en RAW bluetooth forbindelse der gør al formatering væsentlig mere bøvlet.

Vi har koblet en standard genereret GUI til, så koden virker stor, men den relevante kode er i bunden. Koden til PC kan findes her, og koden til NXT’en her.

Ombygning af skydearm:
Armen er for svag og har brug for en ombygning for at kunne holde til det stress der opstår under et spark. Vi har bygget robotten om så skydearmen er mere stabil og har en større skydeflade i håb om at vi så rammer bolden bedre, hver gang.

Konklusion
Vi har prøvet at omstrukturere opbygningen af programmet til enderobotten, men måtte gå tilbage til den gamle opbygning da dette fungerede dårligere og gav flere problemer med den grundlæggende funktionalitet
Skydearmen blev bygget om så den ramte bedre, og ikke faldt fra hinanden undervejs.
Registrering af flere devices resulterede ikke i forsinkelse af data. Opkoblingen tog ikke mere end 2 sek (efter den første opkobling hvor bluecove skulle startes), og herefter blev alle beskeder modtaget straks efter forsendelse. Dvs. vi nu har kommunikation mellem PC og flere devices.
Herefter skal vi have enderobotten til at køre tættere på bolden inden den skyder, og være sikre på at den stopper inden den skyder hver gang, samt PC-applikation implementeret.

2011/01/07

7. Januar

Dato: Fredag d. 7/1 2011
Tilstedeværende: Lars Christian, Daniel og Line
Varighed: 6 timer
Mål: Implementere en måde at kalibrere robottens sensorer, få enderobotten til at køre stabilt, få bluetooth kommunikation til at virke, få midterrobot med omnihjul til at virke (opfriskning af vektorregning)
Plan: Line arbejder på enderobot, LC på midterrobot og Daniel arbejder på bluetooth kommunikation

Implementering af kalibrerings funktionalitet:
Line implementerede en kalibreringsfunktionalitet i KickerCar klassen, til det formål blev Behavior constructoren udvidet til at tage en parameter mere med (en int), som fortæller hvad gennemsnitsværdien af lys/bold eller hvid/sort er alt efter om der er tale om bold sensor eller bane sensor.

Vi havde længe haft problemer med at robotten ikke skiftede retning når den nåede de sorte underlag. Der blev brugt meget tid på at gøre koden så simpel som mulig for at overskue hvad der gjorde dette. Til sidst fandt vi ud af at ledningerne sad i spænd på robotten og ødelagde en masse målinger fra lyssensoren. Dette fandt vi ud af ved brug at dataloggeren (og implementere dens metoder i Behavior klassen).

Tilbage står vi nu med en robot der ikke altid stopper for at skyde, men ellers fungerer glimrende, bortset fra at skydearmen ikke er robust nok da den falder fra hinanden ved længere kørsler.

Kommunikation med flere devices over bluetooth:
Formålet er at teste hvor effektivt flere devices koblet op til en PC kan kommunikere med hinanden.

Der blev lavet et standard GUI og begyndte at implementere funktionalitet for at kunne koble op til tre devices og så sende den samme besked til dem alle. Nåede ikke meget længere end at lave GUI'en færdig og så begynde at etablere kommunikation (men det blev ved med at bøvle lige så meget som før jul).

Styring af midterobot med omnijul

Efter flere overvejelser blev det besluttet at den nemmeste måde at styre de 3 motorer der er placeret med 120 graders forskydning var ved vektorregning. LC gik derfor igang med at genopfriske sin vektorregning.

Resultatet blev at hver motor bliver repræsenteret som en vektor der peger i samme retning som den positive omløbsretning på motoren er:

Hvilket gør os i stand til at projektere “stick” vektoren på hver motor vektor og få kræften som den enkelte motor skal køre med da dette kan udtrykkes således:

Til at starte med uviklede vi en simpel API i java til at fange input fra mus, og en simpel bluetooth protokol imellem API og NXT til at kommunikere motorhastigheder. Resultatet kan ses her:





Vi gik dog igang med at videreudvikle kontrollen af midterrobotten da vi gerne ville kontrollere den via en Wiimote.
Efter en del bøvlen med at få adgang til Wiimoten igennem Java lykkedes det, men kun så længe vi enten koblede op til Wiimoten eller NXT’en. Efter lang tids debugging fandt vi ud af at det havde at gøre med hvilken bluetooth stack som blev brugt til at kommunikere med. NXT’en kommunikerer via winsock, mens wiimoten kommunikerer via en anden. Og det er endnu ikke lykkedes os at få begge to til at snakke sammen via den samme stack eller få java til at bruge to forskellige stacks.
Vi opgiver derfor at bruge wiimotes til kontrol af midterrobotten.

Konklusion
Vi har implementeret kalibrering af lyssensor-værdier i KickerCar klassen, vi har også fået testet at robotten skifter retningen hver gang den når enden, og lært at ledninger ikke skal sidde for stramt.
Vi har fået midterobotten til at køre på omnihjul ud fra input fra en mus på PC’en. Vi har ikke fået wiimote kontrol til at virke.
Vi har fået programmeret GUI’en til det program der skal teste bluetooth kommunikationen imellem flere NXT’er, men brugte meget tid på at få selve kommunikationen til at virke.
Det næste vi skal til er at finjustere skydearmen så den rammer bolden bedre, samt bygge den mere stabil så den ikke falder fra hinanden.
Vi skal have bluetooth til at fungere så vi kan implementere reglerne i en PC samt sikre os at midterobotten kører stabilt og gøre PC-interfacet bedre.