Lektion 7

Lektion 7

Dato: 28/10 - 2010

Tid arbejdet: kl 11 til 14

Deltagere: Lasse Staal, Esben Andersen og Toke Brødsted

Bil 1

Ved starten af denne lektion begyndte vi at implementere den første type bil som skal køre hurtigere jo højere lyde den registrere. Dette løste vi ved at lave en 1 til 1 mapping fra lyd registreret til motor power da begge har en skala fra 0 til 100.

Bil 2 - lys

Den anden bil koder vi ved at bruge samme klasse som bil 1 da vi ved løsningen hertil havde sat to motorer til bare at køre som var det en motor. Måden vi gør det på er at lave en specifik run metode til hver type bil. Dette gør at vi hurtigt kan teste de forskellige biler i forhold til hinanden.

Første implementation af bil 2 laves ved at des mere lys registreret på højre lyssensor før højre hjul til at køre hurtigere rundt.

Den anden implementation bytter om på dette så des mere lys registreret ved højre lyssensor des hurtigere kører højre hjul.

Ved begge vores implementationer med lyssensorer har vi valgt at implementere en normalize funktion som ændrer den registrerede lys værdi om til en værdi som vi kan få vores motorer til at køre. Denne metode er taget direkte fra [3], Tom Dean, Notes on construction of Braitenberg's Vehicles, Chapter 1-5 of Braitenbergs book.

http://www.youtube.com/watch?v=DCuF9XJsPNQ

Videoen viser at bilen følger lyset da den side hvor lyset er kraftigst kører langsomt. Man kan se at robotten drejer primært til den ene side. Dette skyldes at den sides lyssensor registrerer højere værdier end den anden side.

For at få robotten til at køre lige har vi hardcodet noget kalibrering i koden så robotten nu kører lige:

http://www.youtube.com/watch?v=gAjsBWmgaiE

Herefter byttede vi om på sensor portene så robotten nu flygtede fra lyset frem for at køre mod det

http://www.youtube.com/watch?v=X99_PJ7NkIA

Bil 2 - lyd

Vi havde kun en lydsensor til rådighed da vi kom til denne opgave så vi har valgt at løse denne opgave teoretisk.

Man burde sagtens få en robot til at bevæge sig efter lyden alt afhængigt af hvor godt lydsensorerne kan måle lyden, hvor langt de er fra hinanden. Man kan eventuelt lave en lille væg mellem de to lydsensorer for at bryde lyden i mellem dem og få en større afstand.

Bil 2 - lyd og lys

Ved næste opgave hvor vi skulle indføre en inhibitor valgte vi at lave en lydsensor hvis værdi vi trækker fra motorernes kraft. Udover den nye lydsensor så kører den præcist som i bil 2 med lyd.

http://www.youtube.com/watch?v=TwyZ9L4lLxY

Bil 2 - Dynamisk

Dette løste vi ved at flytte lyssensorerne ud i en thread som selv registrede maks og min værdier som der så blev gemt. Registrere hele tiden nye værdier.

http://www.youtube.com/watch?v=Y9hIjbA-maA

I den sidste video her kan man se resultatet fra i dag. Det viser at robotten gemmer nye lys værdier og den kan konfigurere sig selv til at køre lige ud.

Torsdag d. 30/9

Vi har i dag arbejdet med at få robotten til at følge en linie hurtigst muligt. Vi har benyttet 2 lyssensorer fra RCX robotten til at måle fra og disse virker lidt anderledes end de normale sensorer, hvorved vi fik nogle andre thresholds. Vi fik ikke arbejdet med at detektere tre farver, da vi i den sidste halvdel af lektionen brugte et stykke tid på at få vores PC GUI op og køre.

http://www.youtube.com/watch?v=6ZHVAhnLxDw

Vores GUI, lavet i Java/Beans, benytter lejos.pc.comm pakken til at kommunikere med vores NXT robot. Der kan søges efter NXT klodser med et bestemt navn og for at minimere tiden det tager for os at benytte programmet har en ekstra knap der forbinder til vores robot, hugo, ved at forbinde direkte til dens Bluetooth addresse, der er hardcoded ind i programmet. Vores forskellige variable i tabellen bliver hentet fra en data fil gemt ved siden af vores jar fil, så vores indstillinger forbliver der fra gang til gang.  


Protokollen for overførsel af variable er; et variabelnavn, en havelåge og vores data efterfulgt af en ny linie, altså:
variabelnavn#variabeldata\n

På NXT klodsen lytter en tråd, BluetoothParameterReciever, efter indkommende forbindelser og modtager og gemmer data’en ned i de korrekte variable. Et problem med lejos API’et opstod her, da vi på afsendersiden sendte vores data med en PrintWriter, men det var lejos ikke glad for, da det gjorde den overførte data korrupt af en eller anden grund, og vi modtog kun den sidste byte afsendt. Vi skiftede til en DataOutputStream og herefter virkede alt som det skulle.

Næste gang vil vi optimere vores robots hastighed ved at prøve at implementere en PID-controller, samt få lavet så den kan detektere når den når de forskellige platforme på rampen så den kan komme helt til tops og ned igen.

Torsdag d. 7/10

Vi startede dagen med at modificere koden til at kunne skelne imellem 3 farver, sort, hvid og grøn. Dette gav os et problem i forhold til at følge en sort linie, da den til tider målte en værdi indenfor vores grønne threshold, når den er på vej fra hvid til sort eller omvendt. Dette løser vi ved at kræve at robotten er inden for den grønne threshold et stykke tid inden vi registrerer at farven er grøn.

Vi forsøgte at få lavet en tråd til hver hjul og lys sensor par, som opererede uafhængigt af hinanden. Vores robot startede med at opføre sig mærkeligt efter vi forsøgte at indføre en proportional styring af vores power. Vi havde meget svært ved at finde ud af hvad der var galt og antog at det var fordi NXT’en ikke havde nok kraft til at håndtere 2 gange PID-controller, en i hver sin tråd. Vi brugte lang tid på at prøve at gøre koden hurtigere, inline flere metoder osv. Til sidst prøvede vi bare at sætte power på begge motorer til 0, selv da vi gjorde det bevægede robotten sig. Vi forstod ikke hvorfor dette skete og spurgte instruktor Lasse. Han sagde at han selv havde haft samme problem. Det skyldes at default indstillingen til styring af de to motorer, er ved at benytte setSpeed, og ikke setPower som vi prøvede på. Løsningen er at kalde regulateSpeed(false); på begge motorer. Standard er værdien true, hvilket resulterer i at setPower ikke virker.

Da vi endelig fik fikset den ovenstående fejl, havde vi under en time tilbage af øvelsesgangen, så vores robot blev derfor ikke meget bedre end en simpel on/off controller. Da vi havde fundet fejlen virkede vores dobbelt tråede PID-controller baserede styring, men på det tidspunkt var det blevet så sent at vi ikke fik justeret vores PID værdier, eller lavet så vores robot kunne registrere et kryds på banen på de forskellige platforme.

Vi indså da at vi måske skulle have fokuseret mere på opgaven som ikke var at følge en linje, men at komme op på toppen af banen og tilbage igen, vores fokus område var altså forkert.
Vi kunne have brugt tid at bygge vores robot så den kørte stabilt og lige, og så timet hvor lang tid det tog den at køre på de forskellige dele af banen, derved effektivt hardcode banen ind i robotten. Vi så senere at netop denne klasse af robotter klarede det rigtigt godt. Der er ikke noget der ændrer sig i miliøet så hvis robotten er stabil kan det være en gyldig strategi.

Vi har generelt lært lejos API’et bedre at kende, samt erfaret at det er vigtigt at fokusere på det rigtige, ellers kan ens tidsplan falde helt fra hinanden. Derudover har vi fået vores PC GUI op og køre, hvilket vil spare os for meget tid i vores eget projekt.