ESEA - Labnotes

NXT programming - Lesson 4
Varighed: 3.5 timer - kl. 09.00-12.30
gruppemedlemmer: Aslak, Ruben og Lars

Målet for i dag er at påbegynde arbejdet med linjefølger-robotten, som skal deltage i næste uges Robot Race. Følgende delmål forventes at blive gennemført i dag.

• implementere følgende 3 filer : BlackWhiteSensor.java, LineFollowerCal.java og Locomotion.java
• arbejde med at optimere på disse, for på denne måde at optimere på robottens opførsel på en sort streg på en hvid baggrund. Arbejdet med at få robotten til at genkende det grønne "målområde" venter vi med til senere

Filen BlackWhiteSensor.java http://userportal.iha.dk/~20060651/JavaFiles_ESEA/BlackWhiteSensor.java omfatter en kalibrering af lyssensoren, hvor bilen placeres over hhv. en sort og en hvid flade, således at lysintensiteterne for disse kan gemmes. På baggrund af lysintensitetsmålingerne for sort og hvid beregnes en tærskelværdi som bruges til at fastslå om robotten skal dreje til højre eller venstre ((intensitet_sort+intensitet_hvid)/2).

Filen Locomotion.java er den samme, som er blevet benyttet ved tidligere lektioner. Til denne lektion har vi ændret lidt i filen, og den ændrede kan findes her: http://userportal.iha.dk/~20060651/JavaFiles_ESEA/Locomotion.java

Filen LineFollowerCal.java er main-filen i dette projekt. Den version af filen, som vi var kommet frem til ved denne lektions afslutning kan findes her: http://userportal.iha.dk/~20060651/JavaFiles_ESEA/LineFollowerCal.java

Den første del af dagens opgave forløb ganske uden overraskelser. BlackWhiteSensor.java bruges af LineFollowerCal.java til at teste om sensoren er på sort eller hvidt underlag.

Anden del af dagens opgave, at ændre i LineFollowerCal-filen og optimere på robottens opførsel blev påbegyndt. Denne opgave slutter først, når selve løbet Robot Race løber af staben på næste fredag (d. 5. oktober 2007). Vores tilgang til robottens opførsel er en videreførsel af tilgangen til WallFollower-problematikken (se Lektion 2). I stedet for den eksisterende kode, drejer robotten, i den ændrede kode, til at begynde med kun en lille smule til hhv. højre og venstre, når lyssensoren måler intensiteter svarende til hhv. sort og hvid. Det bløde sving opnås ved at begge hjul kører på samme tid, det ene hurtigere end det andet. Måles der den samme intensitet 2 gange i træk (eksempelvis hvid) drejer robotten skarpere til venstre. Dette skarpere sving opnås underforstået ved, at det venstre hjul (i dette tilfælde) sættes til en endnu lavere hastighed. Som koden er i øjeblikket, bliver der, når den samme intensitet (farve) er målt 3 gange i træk drejet aller skarpest, som resultat af, at det forventes at robotten er på afveje.

Ved afslutning af denne lektion blev det besluttet at gruppen mødes igen på mandag (d. 1.oktober 2007) kl. 17.00.

ESEA - Labnotes

NXT Programmering - Lektion 3

varighed: 4 timer - kl. 09.00 - 13.00
gruppemedlemmer: Aslak, Ruben og Lars

Målet for i dag var at komme hurtigt igang med arbejdet med lydsensoren (mikrofonen) og dermed hurtigt komme i gang med programmet til den klap-styrede bil. Hjemmefra var der blevet forberedt en test af mikrofonen, baseret på koden fra forrige lektion ('SonicSensorTest.java').

Desværre var der fra starten problemer med Lars' computer og installationen af Java og Eclipse. Computeren kunne ikke kommunikere med NXT'en, noget som også drillede lidt under forrige lektion. Der endte med at gå en hel time tabt, inden vi havde givet op og begyndte at bruge Aslaks computer istedet. Der virkede kommunikationen fint, og vi påbegyndte dagens arbejde.

Først oprettes en ny klasse 'MicrophoneTest.java', baseret på den kode, som var lavet hjemmefra (se forrige afsnit). Denne blev uploadet til NXT'en og vi diskuterede brugen af 'klap' til at teste med. Vi blev enige om, at det er for svært at klappe ensartet gentagne gange, og vi lavede en Matlab funktion, som danner og afspiller en 1000 Hz tone med en varighed på 3 sekunder. Vi udførte en test af mikrofonen med en opstilling, hvor NXT'en, monteret på 'bilen', stod på gulvet i et åbent område, med den pc som afspiller lyden placeret på en kasse, umiddelbart udfor mikrofonen. Testopstillingen vises på følgende billeder.

Resultatet af denne test vises på følgende graf:

Som det fremgår af grafen er målingerne ikke helt enstydige. Dette kan skyldes flere ting. Den første måling, ved en afstand mellem mikrofonen og pc'ens højttaler på 20 cm, forekommer det målte lydniveau for lavt (sammenlignet med lydniveauet ved 40 cm). Dette kan forklares med en antagelse om, at mikrofonen har en meget retningsafhængig response. Ved den første måling står pc'ens højttaler faktisk hævet over mikrofonens fysiske niveau. Derfor vil meget af lyden, efter vores antagelse, udbrede sig "hen over" mikrofonen. De andre ulineariteter kan forklares ved uforudsiglige refleksioner og ved at omgivelserne ikke er fuldstændig konstante, hverken i lydniveau eller i fysisk udseende (vi stod ikke altid på helt samme position). Dog viser figuren en tydelig tendens og viser at det målte lydniveau falder som funktion af afstanden.

Næste punkt var en kørsel af 'SoundCtrCar.java'. Dette program benytter mikrofonen og giver bilen en forudbestemt opførsel afhængigt af de lyde som måtte blive registreret. Koden opererer med en tærskelværdi, som kan ændres efter omstændighederne og benytter klassen 'Locomotion.java', som også blev omtalt under forrige lektion. Ved starten er denne tærskel sat til et lydniveau på 90. Efter opstart begyner bilen at bevæge sig fremad, og fortsætter med dette, indtil en lyd, hvis niveau overstiger tærskelværdien indtræffer. Herefter drejer bilen til venstre, og fortsætter med dette, indtil en lyd, som overstiger tærskelværdien indtræffer. Herefter drejer bilen til højre, og igen indtil en lyd overstiger tærskelværdien. Slutteligt holder bilen stille, og fortsætter med at holde stille indtil den gentager hele bevægelsesmønstret, når en lyd overstiger tærskelværdien endnu engang. Dette kan så fortsætte i det uendelige, eller indtil batteriet løber tørt.

En anden måde at afslutte det omtalte program 'SoundCtrCar.java' er ved at trykke på 'escape'-knappen, men dette fungerer udelukkende, når eksekveringen af koden befinder sig i den yderste while-løkke. Trykkes der på 'escape' imens NXT'en er igang med at eksekvere en af de indre while-løkker, f.eks. at dreje til højre, sker der ingenting. For at kunne stoppe NXT'en på alle tidspunkter af kode-afviklingen, implementerede vi først den "grimme" måde, som vi valgte at kalde den. Den "grimme" måde er, at de indre while-løkker i koden bliver tilføjet en if-sætning, som tester om 'escape' er aktiveret. Er knappen aktiveret, stopper eksekveringen af koden.

Som sidste opgave i dag, arbejdede vi med at implementere en klap-tæller (clap counter), som, på baggrund af vores kendskab til de akustiske aspekter af en lyd af denne type, tæller antallet af disse. Desværre nåede denne kode ikke at blive færdiggjort. Gruppens medlemmer vil forsøge, at arbejde videre på denne kode inden næste lektion.

Afslutningsvis kan det nævnes at den forulykkede pc stadig, ved lab-sessionens afslutning, ikke fungerer mht. kommunikation ml. pc og NXT. Det forventes at det kan være Java, eller Eclipse, som ikke fungerer. Muligvis vil dette også blive rettet op på inden næste lektion.

ESEA - Labnotes

NXT programmering - Lektion 2
Varighed: 4 timer - kl. 9.00 - 13.00
Gruppemedlemmer: Aslak, Ruben, Lars

Efter at have sluttet sidste session uden at have testet linefollower-koden (se bloggen fra Lektion 1) startede vi dagen i dag med at køre en tur på den til formålet udfærdigede bane. Dette gik helt fint og NXT-køretøjet opførte sig ganske pænt.

Målet for i dag er at arbejde med ultralydssensoren (Ultrasonic Sensor). Dette testes først med pre-fabrikerede java-filer, SonicSensorTest.java og Avoider.java, som benytter klassen Locomotion.java og herefter med en videreudvikling, som skal resultere i en væg-følger WallFollower.java. Efter at have uploadet filen SonicSensorTest.java, fik vi udlæsninger på NXT'ens display, som svarede godt overens med de målte afstande.

Vi oprettede klassen Locomotion.java i Eclipse og compilede den. Dernæst oprettede vi klassen Avoider.java, compilede den, og uploadede koden til NXT'en. Dette medførte den forventede opførsel, hvor NXT-køretøjet kørte hurtigt hen imod væggen og jo tættere pa den kom jo langsommere kørte den, for til sidst at stoppe helt.

Til sidst oprettede vi klassen WallFollower.java og fik lidt inspiration fra Philippe Hurbains hjemmeside og hans væg-følger. Vi oprettede en "blød" version af medlemsfunktionerne Locomotion.right og Locomotion.left, kaldet hhv. softright og softleft. Disse to funktioner giver mulighed for at dreje lidt, dvs. begge hjul roterer, det ene hurtigere end det andet. Ved et højresving er det således venstre hjul som roterer hurtigst, om omvendt. Vi brugte koden fra Avoider.java, som skabelon, og benyttede således den definerede tærskel for minimumafstand. Idet ultralydssensoren er monteret foran på bilen, og vinklet ca. 45 grader til venstre, skal bilen dreje til højre, når afstanden er mindre end tærsklen, og til venstre, når afstanden er større end tærsklen.

Vi compilerede og uploadede vores WallFollower og lavede forsøg med både de skarpe og de bløde sving. Fordelen ved bløde sving, hvor ingen af hjulene stopper helt op på noget tidspunkt, er en mere jævn bevægelse af køretøjet, og pæne håndteringer af 90 graders venstresving. Der opstår lidt problemer når bilen skal dreje til højre, hvor den jo bevæger sig fremad samtidig med at den drejer, her kommer bilen for tæt på den væg som er foran den.
Fordelen ved de "hårde" sving, hvor det kun er et hjul ad gangen, som roterer, er en pæn håndtering af 90 graders højresving. Dog har bilen nu en tendens til at dreje alt for kraftigt ved 90 graders venstresving, så kraftigt, at den næsten kører ind i selve hjørnet.

Det var meningen at kombinere disse to mulige måder at dreje på, ved at kigge på ændringen af den målte afstand fra sidste måling og til den nuværende måling (tilvæksten), og på denne baggrund beslutte, om der er brug for et kraftigt, eller blødt sving. Denne funktionalitet nåede vi desværre ikke at implementere, og derfor heller ikke at teste.

ESEA - Labnotes

Forberedelse til Lektion 2
varighed : 2 timer - 18.00 - 20.00
forgik tirsdag d. 11. september ´07

Målet er at få al software'en til at køre på min egen computer. Sidste gang fik vi det hele op at køre på Aslaks computer, men det er nok en god idé at have det installeret på min også. Man ved jo aldrig hvad der kan ske med de computere.

Sidste fredag fik jeg installeret de fleste komponenter, mangler faktisk bare NXT software'en fra Lego og at sætte Eclipse helt op efter vejledningen. Efter at have installeret NXT software'en uden problemer er det bare at checke, at alt er gjort som på listen. Jeg finder hurtigt ud at, at der er noget galt. Jeg får ikke de forventede beskeder, når jeg skriver "javac" eller "nxjc" i kommando-promten. Efter at have dobbeltchecket stort set alt, og efter at have forsøgt både med den nævnte skrivemåde og med de fulde stier i PATH i Enviroment Variables, går det endeligt op for mig, at jeg heller må checke min java-installation igen.

Og nu ser jeg det endeligt. Det jeg har installeret er rigtignok version 1.6.0_02, men ikke development-kittet. Bare den "almindelige" bruger-java-pakke JAVA Runtime Enviroment (JRE) jre1.6.0_02. Jeg lægger først nu mærke til, at der i installations guiden står:

"Ex. JAVA_HOME = C:\Program Files\Java\jdk1.6.0_02"

under punkt 3, hvor den nye 'System Variable' oprettes. De 3 små bogstaver har været årsagen til mine grå hår. Jeg ville nok have foretrukket, at der i punkt 2) på installationsvejledningen stod, at det var Java Development Kit, som skulle installeres, og at der ikke bare stod "install Java 1.5 or later".

Efter at have installeret Java SE Development Kit'et (JDK) og genstartet Eclipse, virkede alt som forventet, og jeg kan nu uploade de oprettede klasser til NXT'en.

Herligt. Og her kan man bare se, hvor lang tid, der kan gå, når man ikke ved så meget om JAVA og om, at JRE-pakken ikke var nok, men at det skulle være JDK-pakken indeholdende udviklings-værktøj. Men nu er også denne laptop klar til at tage hul på næste lektion med NXT-programmering.

ESEA - Labnotes

NXT programming - Lektion 1
Varighed: 3 timer - kl. 09.00-12.00
Gruppemedlemmer: Aslak, Ruben, Lars

Målet for i dag er at opnå kendskab til Lego Mindstorms NXT sættet, samt at få installeret tilhørende software. Yderligere sigter vi efter at compile og downloade et Java program til NXT'en, som får en bil til at følge en sort linie på en hvid overflade (linefollower).

Efter at have hentet kasser, installations-cd'er, oplader og bluetooth-dongle, satte vi straks det medfølgende batteri til opladning. Dette batteri nåede på den afmålte tid ikke at blive ladet op, og vi brugte almindelige 1.5 volts batterier til denne lektion.

Imens en af gruppens medlemmer installerede alt det tilhørende software, byggede de andre selve bilen til dagens lektion. Vejledning til bilen blev fundet i den medfølgende manual "9797".
Under installation af diverse software stødte vi på lidt problemer med mellemrum i sti-navne. Noget som egentlig var tydeliggjort i installationsguiden. Efterfølgende gik alt som det skulle, og eclipse, lejos_NXT og Lego Mindstorm NXT softwaren var klar.

Første kontakt mellem computer og NXT'en gik umiddelbart ikke, hvorefter vi blev gjort opmærksom på at NXT'en skulle reset'es på en lille knap gemt i nærheden af USB-stikket. Første overførsel fra computer til NXT foregik via en command promt. For at overførslen kunne gå godt skulle Bluetooth-donglen isættes, selvom USB kablet var tilkoblet både pc og NXT. Dette fandt vi aldrig en god forklaring på. Programmet "Tune" blev uploadet og NXT'en spillede lystigt, som forventet.

Nu kom tiden til at opsætte Eclipse, således at programmering og upload af programmer herefter kan foregå via dette interface. Første forsøg med at oprette et nyt projekt i Eclipse, og kopiere indholdet af Tune.java over i en ny klasse i dette projekt. Den nye klasse blev compilet uden fejl og uploadet til NXT'en. Nu begyndte Eclipse-programmet at lede efter NXT'en via Bluetooth, og efter lidt ventetid opgav vi denne kommunikationsform. Vi valgte at bruge USB-kablet og nu uploadede Eclipse uden problemer til NXT'en. Som før begyndte NXT'en at spille fin musik..

Slutteligt oprettede vi en ny klasse "linefollower" og kopierede koden fra Legolab-hjemmesiden ind. Efter at have uploadet koden til NXT'en nåede vi dårligt at teste den, idet batterierne løb tør. De 3 timer var nu gået og vi blev nødt til at splitte os op og slutte, idet gruppens medlemmer skulle hver til sit.

I forhold til dagens målsætning nåede vi at alle punkterne. Vi ville gerne have leget mere med "linefollower" koden, og have optimeret på den, men det må blive på et andet tidspunkt.