Deltagere: Mikkel, Jesper, Troels & Bjarke
Status på Bluetooth forbindelse
Bluetooth forbindelse mellem PC og NXT brick inspireret fra koden fra PCCarController [1] og BTControlledCar [2] fungerer fint. Vi kan sende parametre frem og tilbage mellem PC og NXT. Der er et problem i forhold til at at afbryde bilen, som diskuteret til forelæsningen. Vi har tænkt os at ændre i programmet på bilen så vi i stedet benytter available metoden til at tjekke om streamen indeholder noget inden vi kalder readInt().
public int available() throws IOExceptionPt. har vi fået bluetooth forbindelse til at fungere på to computere. Én ubuntu 32-bit maskine samt én windows 7 maskine med 32-bit java og 32-bit eclipse.
Returns the number of bytes that can be read (or skipped over) from this input stream without blocking by the next caller of a method for this input stream. The next caller might be the same thread or or another thread.
Formål
Lesson 6: http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson6.dir/Lesson.html
I denne lektion vil vi bygge og programmere Braitenberg robotter. Dvs. robotter med reactive control hvor der er en direkte forbindelse fra lys -eller lydsensorerne til motorerne på robotten.
Plan
2. Vi ændrer i programmet så vi i stedet benytter en inhibitory connection imellem lyd og kraft. Dvs. robotten kører med fuld kraft, men når der registreres lyd trækkes den registrerede lyd fra kraften.
3. Vi ombygger robotten til en “five-minute bot” efter byggeinstruktioner fra nxtprograms.com [3].
4. Vi tilføjer to lyssensorer til robotten så vi kan lave Braitenberg robotterne 2a og 2b, som vist nedenfor. De registrerede værdier for lyssensorerne normaliseres, som tidligere og gives som input til hjulene. Robotten kan så køre mod lyset eller væk fra lyset alt efter hvordan lyssensorerne kobles til NXT brikken.
5. Vi vil placere en lyskilde på bilen og sætte den sammen med en eller flere andre robottor for at se hvordan de reagerer.
6. Omskriv vores program der styrer robotten, således at den opsamler N samples og anvender gennemsnittet til at bestemme hastigheden på motorerne.
7. Byg en Braitenberg robot 3
Resultater
1. Først lavede vi en minimal implementation, hvor vi på displayed vi fik vist den registrerede værdi fra lyssensoren. Vi fik de forventede værdier mellem 0 og 100 fra readValue() metoden. Vi lavede en minimums hastighed for motoren på 50 baseret på vores tidligere erfaringer med hvor meget kraft der skulle til for at drive hjulene.
Vores normalisering af den indlæste værdi fra lydsensoren gik i første omgang ud på at dividere den indlæste værdi med 2. Ved at lægge dette resultat sammen med minimum speed fik vi en værdi mellem 50 og 100 for motoren. Bilen kørte som forventet bortset fra at vi var kommet til at sætte motoren omvendt på. Altså kørte bilen baglæns..
Som foreslået i opgaven [4] lavede vi også en version hvor normaliseringen i stedet lavede en mapping til kraft mellem -100 og 100. Vi tolkede negative tal som ‘bakgear’ [5]. Resultatet blev at bilen bakkede medmindre den registrerede høje lyde. I så fald kørte den fremad som før.
2. Det virkede som forventet. Implementationen trækker den registrerede lydværdi/2 fra default power på 100. Robotten havde således en default power og når den registrerede lyd kørte den langsommere eller stoppede helt [6].
4. Robotten kørte som forventet. Robot 2b styrede mod lyset som vist på videoen. Hvis vi byttede om på hvilke porte lyssensorerne var tilsluttet styrede den væk fra lyset, som 2a [7].
5. Vi har derefter tilsluttet dioder foran på, så vi kan se hvordan to robotter reagerer overfor hinanden. Vi har tilsluttet dioden til MotorPort.C og tænder den ved at kalde controlMotor(100, MotorPort.FORWARD).
Vi kunne konstatere at vores robot kunne finde ud af det mørklagte køkken ved at køre efter lyset.
6. I stedet for at opsamle N værdier har vi valgt at følge Estimate-formlen fra bunden af noten om Braitenbergs “Vehicles” [9]:
Dette gør at vi slipper for at tage gennemsnittet over en masse læste værdier og i stedet lader den nye værdi afhænge af den tidligere værdi. Her er beta et tal imellem 0 og 1, som fortæller hvor meget vægt den nye værdi skal have i forhold til den tidligere værdi.
For at kunne observere at robotten ændrer hastigheden over flere værdier, har vi valgt at tilføje et Thread.sleep(100) [10]. Med dette delay var det tydeligt at det tog lidt tid for robotten at accellerere op til den nye hastighed.
Vi fandt efter punkt 5 i dagsordenen ud af, at vi kunne hente raw value via metoden readNormalizedValue() fra sensoren.
Det ville have givet en større spændvidde af værdier i stedet for getValue der blot giver en procentværdi mellem 0 og 100. Der er også den forskel at getValue på en SoundSensor giver en procent værdi på DB værdierne af målingerne. Dette gør at koden formentlig opfører sig anderledes end hvis vi havde brugt raw-værdierne.public int readNormalizedValue()
- Get the normalized light reading
- Returns:
- the raw light level
Tiden løb fra os og vi nåede ikke at prøve os frem med punkt 7 i planen.
Referencer
[1] http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/PCcarController.java
[2] http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/BTcontrolledCar.java
[3] http://www.nxtprograms.com/five_minute_bot/steps.html
[4] http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson6.dir/Lesson.html
[5] http://dl.dropbox.com/u/609402/V1.0/PPControl.java
[6] http://dl.dropbox.com/u/609402/V1.1/PPControl.java
[7] http://dl.dropbox.com/u/357278/Lego/ExpandedPPControl/V1.0/EPPControl.java
[8] http://dl.dropbox.com/u/357278/Lego/ExpandedPPControl/V1.1/EPPControl.java
[9] http://www.cs.brown.edu/people/tld/courses/cs148/01/vehicles/vehicles.htm
[10] http://dl.dropbox.com/u/357278/Lego/CollectPPControl/V1.0/CPPControl.java
Ingen kommentarer:
Send en kommentar