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.