Varighed: 11-14
Deltagere: Daniel, Leni, Martin A og Martin N
1. Formål
Formålet med denne øvelse var at opnå erfaring med installation og opsætning af leJOS.
Herudover at give deltagerne et indblik i hvorledes et simpelt reguleringssystem fungerer, ved at uploade og afvikle Java applikationen LineFollower.java på den opbyggede Lego NXT model.
2. Øvelsesgennemgang
Del 1 - leJOS installation og opsætning
Først blev driveren fra LEGO’s hjemmeside downloadet og installeret for at kunne kommunikere med NXT bricken.
Herefter foregik installationen af leJOS version 0.85 samt JDK version 1.6 update 20-21 foregik uden der opstod nogle problemer. Følgende tutorial blev fulgt:
http://lejos.sourceforge.net/nxt/nxj/tutorial/Preliminaries/GettingStartedWindows.htm
Efter fuldendt installation blev NXT bricken flashed med leJOS firmwaren. Her opstod et problem, da driveren til Lego Mindstorm Firmware Update Mode ikke var indeholdt i den driver fil som var blevet hentet fra LEGO’s hjemmeside. I stedet blev NXT bricken detekteret som et GPS Tracker Cam.
For at løse dette problem blev LEGO Mindstorms NXT 2.0 suiten installeret, hvorefter leJOS firmware flash af NXT bricken foregik uden yderligere problemer.
Til at teste om leJOS firmwaren var blevet installeret korrekt på NXT bricken, blev sample programmet "View" kompileret og uploadet til bricken. Dette foregik via en command promt med følgende kommandoer:
nxjc View.java
nxj –r View
Sample programmet blev både kompileret og afviklet som forventet på NXT bricken.
Del 2 - Upload og afvikling af LineFollower program
Efter at have opbygget LEGO modellen til 9797 LEGO car ud fra samlevejledningen, var det muligt at afprøve funktionaliteten i NetBeans plugin’et.
NetBeans installationen foregik uden problemer, og det samme gjorde installationen af NetBeans plugin’et vha. følgende vejledning:
http://lejos.sourceforge.net/nxt/nxj/tutorial/Preliminaries/UsingNetbeans.htm
Et projekt blev oprettet i NetBeans, hvorefter LineFollower.java koden blev hentet ind. Da vi forsøgte at kompilere projektet via NetBeans opstod der dog det problem, at kompileren ikke kunne finde leJOS.nxt pakken. Dette blev løst ved at åbne projekt options og under ”Java Source Classpath” fjerne den relative URL til leJOS classes.jar og erstatte den med en URL til en kopi af classes.jar, som blev overført til projektmappen.
Herefter forsøgte vi igen at kompilere projektet vha. build.xml filen med kommandoen ”uploadandrun”. Igen opstod der et problem af samme type som ovenstående.
Det viste sig at build.properties filen som lå i roden af projektmappen indeholdt en forkert reference til NXJ_HOME mappen:
nxj.home=..snapshot
I stedet for at hente den environmental variable som var sat, var der i stedet indsat stien: ”../snapshot”. Dette blev rette til:
nxj.home=${env.NXJ_HOME}
Herefter kunne NetBeans kompilere programmet korrekt og uploade det til NXT bricken.
Herunder findes et billede af den opbyggede LEGO 9797 car:
Del 3 – Test af LineFollower program
Efter afvikling af LineFollower programmet blev lysniveauet målt for følgende tilfælde:
- På bordet: 53
- I fri luft (1m over bordet): 42
- Sort banedel: 32
- Hvid banedel: 55
Ud fra de målte værdier kunne vi konkluderer at programmet burde fungere med den allerede fastsatte blackWhiteThreshold på 43, der er midt mellem sensorens værdi for den sorte og hvide farve.
Banetesten var en succes, LEGO bilen kørte hele banen igennem, kørte rundt omkring den blå overflade for enden og kørte tilbage af banestrækning igen.
En video af, hvordan banetestene så ud, kan ses ved at trykke her:
Del 4 – Måling af lysniveau for andre farver
Lysniveauet blev målt for følgende farver:
- Hvid:55
- Gul: 47
- Lyserød: 45
- Rød: 44
- Grå: 44
- Blå: 43
- Lilla: 41
- Mørkeblå: 38
- Sort: 32
En overflade med en anden farve vil give en sensor udlæsning, der afhænger af hvor meget af den røde farve der reflekteres fra overfladen.
Del 5 – Måling af lysniveauer uden rød lys
Alle de tidligere målte farver blev målt igen, men uden at tænde for det røde lys. Dette resulterer i en måling af, hvor godt det naturlige lys' refleksion kan måles af sensoren.
Målingerne blev som følger:
- Hvid:42
- Gul: 48
- Lyserød: 41
- Rød: 44
- Grå: 43
- Blå: 44
- Lilla: 40
- Mørkeblå: 37
- Sort: 24
Ud fra dette kan vi konkludere at sensorens responsivitet må være afstemt efter lysdioden, således at den er mest følsom overfor den samme røde farve som lysdioden udsender.
Da lysniveauet for hvid er faldet til 42, vil det være nødvendigt at justere variablen blackWhiteThreshold til en lavere værdi, for at få LEGO bilen til at gennemføre banetesten korrekt uden at have lysdioden tændt.
Denne nye værdi som valgt til 33, da den værdi ligger lige mellem de målte værdier for sort og hvid.
Ændringen af variablen blackWhiteThreshold fungerede efter hensigten.
Del 6 – Ændring af samplerate
Her skulle det undersøges, hvilken indflydelse en evt. ændring af sampleraten ville have på LEGO bilen evne til at fuldføre en banetest.
Sampleraten var oprindeligt sat til 10ms, og det skulle efterfølgende forsøges med en ændring til henholdsvis: 50ms, 100ms, og 1000ms.
Først blev gennemløbet med en samplerate på 10ms observeret, hvorfra det kunne konkluderes at banetesten blev gennemført som forventet med små udsving til højre/venstre ved overgangen mellem banens sorte og hvide dele. Det blev også observeret at motorerne ikke virkede til at kunne følge med til en ændring med 10ms, hvilket resulterede i et større udsving end man kunne have forventet med den lave samplerate.
Dette skyldes at motorerne ikke reagerer øjeblikkeligt på en ændring i spænding, da inertimomentet i hjul og motoranker er med til at opretholde rotationen.
Konsekvensen af at ændre samplerate til en lavere værdi end motorernes responstid er, at jo længere tid der går imellem hver sample, jo større sving fra side til side vil bilen tage, da der går længere tid inden den "opdager" at den skal ændre retning.
Ved meget lave samplerates når bilen slet ikke at sample lyset når den er over den sorte linie, og ender derfor med at dreje rundt om sig selv, indtil det tilfældigvis passer med at er samples på det tidspunkt hvor den er over den sorte streg, hvorefter bilen vil begynde at dreje den anden vej rundt om sig selv.
Ved en test med sample rate på 500 ms drejede LEGO bilen så meget væk fra stregen at den ikke kunne finde tilbage igen. Endvidere kunne den heller ikke finde stregen igen efter at være drejet en hel omgang rundt, grundet det tidligere nævnte dilemma med at sample på det korrekte tidspunkt.
Banetestene for den ændrede sample tid kan ses her:
100ms
500ms
Del 7 – LCD.drawString test
I denne del opgave skulle vi forsøge at anvende string direkte i kaldet LCD.DrawString() for at se på hukommelses forbruget i NXT’en.
Ved at kalde Runtime.getRuntime().freeMemory() og udskrive resultatet fra denne funktion på NXT'ens display vil vi kunne se hukommelsesforbruget i NXT’en.
Kodestumpen der kører systemets kontrol loop og udskrivning på LCD displayet ser således ud:
final String left = "Turn left ";
final String right= "Turn right";
while (! Button.ESCAPE.isPressed()) {
if (light.readValue() > blackWhiteThreshold) {
// On white, turn right
LCD.drawString(right, 0, 1);
MotorPort.B.controlMotor(0,stop);
MotorPort.C.controlMotor(power, forward);
} else {
// On black, turn left
LCD.drawString(left, 0, 1);
MotorPort.B.controlMotor(power, forward);
MotorPort.C.controlMotor(0,stop);
}
LCD.drawString(String.valueOf(Runtime.getRuntime().freeMemory()) , 0, 4);
LCD.drawInt(light.readValue(), 3, 9, 0);
Thread.sleep(10);
}
Når vi bruger string right og left variablerne forventer vi, at NXT enheden bruger mindre hukommelse end ved at kalde direkte med strenge.
Grundlaget for dette er, at vi i variablerne bruger final string prefix som gør, at strengen kun bliver allokeret en gang og derefter sendes der en reference med til denne hukommelse når disse strenge skal sendes til en funktion.
Altså ville vi forvente at den frie hukommelsen ikke ville falde efter første gennemløb af kontrol loopet.
I testen viste det sig dog at den frie hukommelse stadig falder, dog ikke med konstant hastighed. Dette kunne skyldes, at vi kalder runtime.getRuntime().freememory() funktionen som allokerer plads til resultatet fra kaldet og dermed står for det fald vi ser på displayet.
3. Konklusion
Generelt set lykkedes alle de opstillede test, og de fejl vi stødte på undervejs blev rettet.
Herudover lavede vi nogle observationer under testene, hvor vi kunne konstatere, at LEGO bilen bremsede engang imellem i omkring et sekund, hvor det ikke rigtig virkede som om den lavede noget.
Efter at have udført del 8, kunne vi se en sammenhæng mellem at antallet af fri hukommelse næsten altid var lav mens dette skete. Vores første tanke var derfor at dette kunne skyldes at Garbage Collectoren var i gang, og af en eller anden grund fik den ene af motorerne til at stoppe under sin afvikling.
For at komme nærmere en løsning, valgte vi at forsøge og udskifte den ene motor. Det resulterede i at fejlen forsvandt hvorved det kan konkluderes at den ene motor havde en defekt. Vi kunne samtidig observerer at den nye motor havde et væsentlig højere omdrejningstal. Altså er det muligt at den defekte motor kan have været overbelastet og derfor midlertidig slukkede når den blev hårdt belastet.
4. Referencer
http://lejos.sourceforge.net/index.php
http://lejos.sourceforge.net/nxt/nxj/tutorial/index.htm
http://lejos.sourceforge.net/nxt/nxj/tutorial/Preliminaries/GettingStartedWindows.htm
http://lejos.sourceforge.net/nxt/nxj/tutorial/Preliminaries/CompileAndRun.htm
http://lejos.sourceforge.net/nxt/nxj/tutorial/Preliminaries/UsingNetbeans.htm
No comments:
Post a Comment