Tilstede:
Mikkel Nielsen
Søren Bramer Schmidt
Peter Jessen
Tid brugt:
6 timer
Mål
Målet med dagens øvelse er at lave de 3 køretøjer beskrevet i ugeopgave 6 samt udføre de beskrevne forsøg.
Plan
Planen er skrevet således, at vi følger opgaveformuleringen for uge 6. [1]
0. Bluetooth status.
1. Vi vil starte med at bygge en basis robot der kan bruges til alle eksperimenter, som beskrevet i [2]
2. Robotten konfigureres med en lydsensor og vi udfører eksperimenterne for køretøj 1 på tegningen, Herunder regulation og normalisering.
3. Køretøj 2 bygges med lys-sensor og og 2a og 2b konfigurationerne afprøves.
4. Køretøj 1 tilføjes estimering af gennemsnitlig lys-værdi som beskrevet ved forelæsning d. 08/03.
Resultater
0. Bluetooth status
Status på bluetooth er at vi har 3 computere som kan kommunikere med NXT'en via bluetooth og de medfølgende .jar filer, så som nxtbrowse, m.m. For at få dette til at virke har vi skulle tilføje miljøvariablen "LEJOS_NXT_JAVA_HOME", som peger på java runtime.
Herudover har vi forbindelse til NXT'en fra en mobiltelefon vha. af bluetooth og en app fra Android Market der hedder "NXT Remote Control". Vi har 1 computer med 32-bit java, 32-bit eclipse og lejos NXT-plugin'et til eclipse. Denne computer bruger vi til at overføre kode til NXT'en via bluetooth. Maskinen kører 64-bit Windows 7, med indbygget bluetooth.
Vi har på intet tidspunkt fået 64-bit Java eller 64-bit eclipse til at virke med lejos.
1.Bygning af robot
Vi byggede en simpel liggende robot med to motorer og et støttehjul efter instruktioner fra nxtprograms.com [2]. Denne robot har et lavt tyngdepunkt og har et godt udgangspunkt at tilføje sensorer på. Robotten er vist på billedet her.
2. Eksperimenter for køretøj 1
I disse eksperimenter bruges en enkelt lydsensor. I første eksperiment laver vi en direkte mapping mellem lydsensorens input og motorenes værdier. Dette resulterer i en robot der kører hurtigere fremad jo mere larm der er omkring den. Da lydsensoren kan aflæses som en værdi mellem 0-100 er denne mapping liniær. Vi placerede en musikafspiller på robotten og kunne observere den køre i takt til musikken.
Vi ændrede mappingen til at gå mellem -100 og 100. Dette svarer til at dække intervallet fra fuld bak til fuld frem på motorerne. Resultatet var en robot der bakker indtil en lydkilde kommer tæt nok på til at fange dens interesse. Denne video illustrerer sådan et møde mellem robot og mobiltelefon:
Koden for denne mapping er her:
public int negativeNormalization() {
int power = (power() - 50) * 2; return power; }
Som altså gør, at vi nu i stedet for et interval på [0, 100] får et interval på [-100, 100]
3. Eksperimenter for køretøj 2
Til det næste eksperiment monterede vi 2 lyssensorer på robotten. Robotten kan så nemt konfigureres til 2a eller 2b. Forskellen på 2a og 2b er at vi bytter om på ledningerne til lyssensorerne. Dette resulterer i at vi kan få robotten til at køre imod lyset eller køre væk fra det. Vi forsøgte først med lyssensorer placeret som vist på billedet her, med lang afstand imellem dem. Vi observerede at lys-sensorene er meget retningsbestemte, og det derfor ikke var så vigtigt at sensorene sad så langt fra hinanden. Vi valgte derfor at gå videre med et design hvor sensorene sidder tættere sammen, som vist på de følgende videoer.
Her er en video af 2a. Her kører robotten 'væk fra lyset'. Det vil sige at den drejer imod den side hvor der er mindst lys.
Her er 2b, hvor robotten følger lyset ved at konstant dreje i retningen af det skarpere lys.
4. Køretøj 1 med estimeringsfunktion
Vi har tilføjet en estimeringsfunktion til vores lyssensorer, som vi efterfølgende testede på en køretøj 1. Måden vi har gjort det på er ved at tilføje følgende funktion til vores LightMapping klasse, som i forvejen håndterer mappingen og normaliseringen af vores RAW value input fra en lyssensor.
public double estimate(double prevEstimate) {
double alpha = 0.001;
return alpha * readLight() + (1 - alpha) * prevEstimate;
}
Værdien af alpha på 0.001 fandt vi ved empirisk at undersøge hvor frekvent vi ønsker at opdatere vores estimat af gennemsnttet for lysværdierne.
Ved at have denne funktion kan vi så på vores NXT tilføje følgende stump kode:
LightMapping lightMapping = new LightMapping(new LightSensor(SensorPort.S1));
double average = lightMapping.estimate(420);
while(true) {
average = lightMapping.estimate(average);
if (lightMapping.readLight() > average) {
Car.backward(100, 100);
}
else {
Car.stop();
}
}
Som man kan se, har vi valgt at initialisere estimatet til at være 420, da det passer meget godt med det almindelige lysniveau i rummet. Denne værdi har dog ikke så stor betydning, da den meget hurtig bliver ligegyldig i forhold til, at vi meget hurtig indsamler nye værdier til gennnemsnittet. Denne stump kode gør, at vi nu kun kører hvis vi opdager en ændring i det gennemsnitlige lysniveau målt fra vores estimeringsfunktion.
Dette kan ses i følgende video:
Som man kan se på videoen står vores robot stille fordi den har tilpasset sig lysværdien, og derfor ikke bevæger sig. Efter vi så påvirker lysværdien begynder robotten at køre, da den målte værdi nu er over gennemsnittet. Herefter bliver den ved med at kører indtil den målte lysværdi nu igen passer med det estimeret gennemsnit.
Status
Vi blev færdige med dagens planlagte program. Udover det nævnte i denne rapport medvirkede vi også til forsøg i "køkkenet", hvor lyset blev slukket og robotterne kørte efter eller forbi de andre robotter, som havde lys monteret på dem.
Referencer



