NXT programmering, lesson 4

Tidsforbrug: 3 timer
Deltagere: Asbjørn, Christer og Jesper

Målet for dagens session er, at:

• Black White Detection
• Montering og test af lyssensor
  
• Line Follower with Calibration
• Brug af lyssensor til at følge en sort streg
  
• ColorSensor with Calibration
• Udvidelse af kode til at genkende grøn
• Line Follower that stops in a Goal Zone
• Forberedelse til næste uges løb

Programmerne vi lavede under denne session kan findes på adressen:
http://www.daimi.au.dk/~jn/lego/uge5/

Disse punkter gennemgår vi et for et nedenfor.

Black White Detection
Tidsforbrug: 15 minutter.

Dagens første opgave var at montere lyssensoren på LEGO™ bilen. Det var hurtigt gjort ud fra LEGO™ Mindstorms Education NXT Base Set 9797 byggeinstruktionshæftet. Derefter hentede vi BlackWhiteSensor.java og skrev et program omkring den. Igennem eksperimenter kunne vi se, at den var meget god til at skelne mellem mørke og lyse farver. Mørke farver gav høje værdier og lyse farver gav lave værdier.


Line Follower with Calibration
Tidsforbrug: 45 minutter

Vi hentede LineFollowerCal.java fra nettet og forsøgte at overføre det til NXT'en. Det lykkedes dog ikke først. Hver gang vi prøvede, skrev den "Data abort", dumpede registre til skærmen og frøs. Vi lånte da en NXT af en anden gruppe og forsøgte at overføre programmet til den i stedet. Det virkede fint, hvorfor vi konstaterede, at det var vores NXT den var gal med. Herefter hentede vores instruktor en ny NXT til os, hvilket løste problemet. Vi kunne nu køre programmet og følge en sort streg på gulvet.

ColorSensor with Calibration
Tidsforbrug: 30 minutter

Nu skulle vi udvide BlackWhiteSensor til ColorSensor, så den kunne skelne mellem sort, hvid og grøn. Så i stedet for at opdele intervallet af mulige målinger i to klasser, skal den nu opdeles i tre, da grøn måles som en gråtone et sted mellem de to andre. Det viste sig eksperimentelt at den anvendte nuance af grøn gav en måling ca midt mellem målingerne for sort og hvid.

Line Follower that stops in a Goal Zone
Tidsforbrug: 90 minutter (resten af tiden)

Nu var det tid til at arbejde på bilens egenskaber for at følge linjen på jorden hurtigst muligt. For at forbedre bilens evne for at holde sig på stregen, udvidede vi den med to RCX lyssensorer som vist på billedet til højre.
Vi opdagede at de tilgængelige RCX sensorer ikke havde samme følsomhed som NXT sensoren. Der var simpelthen ikke så stor forskel på en hvid-måling og en sort-måling. Farvemåling viste sig at være upraktisk, hvis ikke umulig. Dette er dog ikke at være et problem, da vi kun har brug for at genkende farve til aller sidst, og der er NXT sensoren nok. For at kunne bruge både RCX og NXT sensorer med vores BlackWhiteSensor og ColorSensor lavede vi et software interface fælles for de to og wrapper klasser til at pakke LightSensor og RCXLightSensor klasserne ind.

Efter gentagne eksperimenter med den viste robot besluttede vi os for at ændre den igen. Sensorerne sad for tæt på hinanden og for tæt på robotten. Dette bevirkede, at den reagerede for sent når underlaget ændrede sig. Desuden har vi udviddet softwaren så den ikke bare reagerer i forhold til hvad den ser lige nu, men husker til hvilken side den sidst har set stregen, så hvis den kører helt uden for stregen kan den finde den igen. Denne opdatering gjorde en meget stor forbedring. Det lykkedes altså at finde en konfiguration der virkede ret godt, men vi aftalte at mødes igen den følgende uge til en gang tweaking inden konkurrencen.

NXT programmering, lesson 3

Tidsforbrug: 3 timer og 10 minutter
Deltagere: Asbjørn, Christer og Jesper

Målet for dagens session er, at:

• Test of Sound Sensor
• Sound Controlled Car
  
• Clap Controlled Car
  

Programmerne vi lavede under denne session kan findes på adressen:
http://www.daimi.au.dk/~jn/lego/uge4/

Disse punkter gennemgår vi et for et nedenfor.

Test of Sound Sensor
Tidsforbrug: 45 minutter.

Vi monterede sensoren som beskrevet i materialet. Herefter overførte vi det udleverede testprogram og konstaterede at det virkede. Til målingerne af lyd som funktion af afstanden mellem kilden og bilen ændrede vi i programmet, så det ud over de aktuelle lydniveau også printede det maximalt målte. Vi anvendte enter-knappen til reset af maximum-målingen.
Generelt så vi, at jo højere lyd, jo højere måling. Vi kørte to måleserier. En med høj lyd og en med let dæmpet lyd. Lyden var i begge tilfælde Windows™ lyden ding.wav. Et sammendrag af målingerne ses i tabellen.

Afstand i cm	Lav lyd	Høj lyd
10	10	49
20	8	37
30	7	30
40	0	31

Sound Controlled Car
Tidsforbrug: 15 minutter.

Programmet har fire tilstande: fremad, venstre, højre, stop. Hver gang man laver en tilstrækkelig høj lyd, som trigger en tilstrækkelig stor måleværdi, skifter den til næste tilstand. Som beskrevet i opgaven pollede den kun efter escape-knappen i yderste loop. Vi tilføjede da en boolean variabel, stop, som en ButtonListener hele tiden opdaterer ud fra escape-knappen. Denne opdatering overførte vi til bilen, hvor vi konstaterede at den virkede.

Clap Controlled Car
Tidsforbrug: 30 minutter.

Vi implementerede Sivan Toledos algoritme for genkendelse af klap. Den virkede ikke til genkendelse af klap, men reagerede i stedet på små "skarpe" ord. Det opdagede vi da Christer udtalte, at han troede den var gået kold. Så vi konkluderede, at metoden i SoundCtrCar.java var væsentlig bedre.

Resten af tiden
Tidsforbrug: 90 minutter

Da vi nu var igennem dagens program, kunne vi eksperimentere med yderligere forbedringer. En af disse var at udvide SonicSensorTest.java, så den plotter lydstyrken på NXT'ens skærm.

NXT programmering, lesson 2

Tidsforbrug: 3 timer og 10 minutter
Deltagere: Asbjørn, Christer og Jesper

Målet for dagens session er, at:

• Test of Ultrasonic Sensor
• Obstacle Avoider
• Wall Follower

Disse punkter gennemgår vi et for et nedenfor.

Test of Ultrasonic Sensor.
Tidsforbrug: 20 minutter.

Den første opgave var at montere den ultrasoniske sensor på LEGO™ bilen. Det var hurtigt gjort ud fra LEGO™ Mindstorms Education NXT Base Set 9797 byggeinstruktionshæftet. Herefter var det tid til at hente SonicSensorTest.java. Desværre var serveren nede, hvorfor vi var nødt til at finde en udprintning og indtaste programmet selv. Som beskrevet til forelæsningen kunne vi konstatere en stor forskel i evnen til at måle afstande i alt efter vinklen mellem ultralydens udbredelsesretning og normalen på den overflade den rammer.

Ved at sammenholde måleresultater med et målebånd vi havde udspændt på gulvet, har vi konstrueret en omregningstabel mellem udlæsning og afstand i centimeter.

Afstand i cm	Måling
10	15
20	23
30	31
40	41
50	51
60	61
70	72
80	86
90	92
100	-

Som det ses, er der en ret god direkte sammenhæng mellem disse to tal.

Obstacle Avoider
Tidsforbrug: 1 time.

Her var vi igen nødt til at indtaste de to klasser Avoider.java og Locomotion.java der udgjorde programmet. Efter en del debugging virkede de endelig og vi kunne teste. Som udgangspunkt var det udleverede program temmelig forsigtigt. Det satte farten ned i god tid før bilen ramte væggen. Efter at have justeret distanceThreshold ned til 20 fik vi den til at køre væsentlig tættere på væggen. Ligeledes eksperimenterede vi også med at variere maxDistance. Ved at sætte denne ned til 50 (og bibeholde den ændrede distanceThreshold) kunne vi få den til at køre hurtigere og tættere til væggen, hvor den stoppede helt ca. en centimeter fra.
Bilens hastighed (the controlled variable) er beregnet direkte ud fra afstandsmålingen (the measured variable) og konstanterne. Derfor er der tale om en simpel feedback kontrol.

Wall Follower
Tidsforbrug: 1 time og 50 minutter.

Vi udvidede vores robot med ultralydssensoren. Herefter forsøgte vi uden held en direkte oversættelse af NQC-programmet. Det mislykkedes fordi programmet var lavet til et andet system (RCX) og dets kontrollogik var uoverskuelig pga dårlige variabelnavne. Efter et par mindre refaktoreringer fik vi programmet til at virke fornuftigt.

Så tweakede vi konstanter for at optimere ydelsen. Blandt andet skulle kørselshastigheden sættes ned og samplingfrekvensen op. Derved kunne robotten nemmere nå at reagere på sine omgivelser i tide. Et gennemgående problem er, at robotten, specielt omkring hjørner, taber væggen af "syne" og begynder at køre rundt om sig selv (med en konstant afstandsmåling på 255). Dette kan skyldes den effekt vi observerede i ugens første delopgave, hvor vi så at vinklen til objektet vi målte på betød en del.

Til sidst droppede vi vores første bud på at montere sensoren og monterede den nede forrest på robotten i stedet (se billede). Dette gav meget bedre resultater. Nu kunne den finde rundt om hjørner, da sensoren ser hjørnet før den kører forbi.

NXT programmering, lesson 1

Tidsforbrug: 3 timer
Deltagere: Asbjørn, Christer og Jesper

Målet for dagens session er, at:

• Pakke vores LEGO™ ud.
  
• Bygge en LEGO™ bil efter medfølgende instruktioner.
• Installere leJOS.
• Compile et Java-program og køre det på NXT'en.

Vi startede med at pakke vores LEGO™ ud og fordele det i de medfølgende plastikbakker. Herefter byggede vi bilen efter de medfølgende instruktioner på ca 45 minutter. Efter dette forsøgte vi at køre bilen med den forudinstallerede software. Det lykkedes ikke at få den til at følge en sort streg på denne måde, men det generede os ikke umiddelbart, da det trods alt ikke er det vi skal bruge.

Herefter påbegyndte vi installationen af leJOS. Dette kompliceredes af, at ingen af os besidder laptops med optiske drev. Installationen drillede. For det første tog det lang tid at hente alle de nødvendige programmer og bagefter tog det et par forsøg at få sat diverse miljøvariable korrekt op. Det viste sig også at libusb skal ligge i et bibliotek med et DOS 8.3 filnavn. I alt brugte vi ca. 80 min på at få sat softwaren op.

Da først vi fik flashed NXT'en til lejOS gik alt dog let. Vi gik nu i gang med at teste LineFollower.java programmet. Det første vi gjorde var at teste de rapporterede lysværdier for henholdsvis lyst og mørkt papir. vi fik ca. 45 og ca. 60 og satte derfor variablen blackWhiteThreshold til 54. Nu kunne vi teste bilen og konstanterede at den fint fulgte enbred sort streg.

Næste forsøg var at lege med sample intervallet. Det startede på 100ms, hvor den virkede ude mærket. Næste forsøg var på 500ms. Det resulterede i at den ikke kunne reagere hurtigt nok på at den fandt den sorte streg og at bilen derfor var generelt ude af stand til at følge stregen. Sidste forsøg var med 10ms, og her var bilen fint i stand til at følge stregen. Om muligt kørte den her endnu bedre, da bilen meget hurtigt kunne reagere på ændringen i lyset og derfor ikke nåede langt væk fra stregen før den drejede tilbage ind på den.

Til sidst lavede vi forsøg med hukommelsesforbruget. Vi brugte inline streng literals i stedet for variablerne left og right og fik den til at udskrive Runtime.getRuntime().freeMemory(). Det der skete var at vi kunne se den ledige hukommelse forsvinde hurtigt. Da der ikke var mere hukommelse tilbage smed bilen en exception og vi kunne kun stoppe den ved at resette den ved at trykke enter og escape på samme tid. Grunden til at hukommelsen forsvandt var naturligvis at den ikke har nogen garbage collector og når vi bruger string literals bliver VM'en ved med at oprette nye string objekter der ikke forsvinder igen.

I alt tog de to eksperimenter ca. 30 min.