Robot Race - Øvelsesgang 6

Denne uges opgave går ud på at få robotten til at køre så hurtigt som muligt, samtidig med at den følger Alishan train track. Regelsættet vi bruger under denne øvelse er en smule mindre end det oprindelige sæt, men giver stadig god udfordring. Vores regelsæt er som følgende:

• Robotten skal starte fra startområdet. Ingen dele af robotten må stikke ud af start arealet.
• Et tryk på ENTER starter robotten og robotten skal så følge sporet til at vende området, den øverste platform. Fra vende området skal robotten køre tilbage, indtil robotten kører ind i start området igen. Robotten skal derefter stoppe og tid der er gået siden starten skal vises på LCD. Bilen skal være inde i start området, før den stopper.
• Når robotten er på toppen, bør robotten være inde i vende området før den kører tilbage.

Begge gruppe medlemmer har deltaget aktivt i at forsøge at løse denne opgave.

Hvordan greb vi det an?

Vi starter hvor vi slap sidste gang med vores robot og gik i gang med at få den til at følge linjen. Dette var dog ikke så let som vi troede, så vi besluttede os for at dele banen op i flere steps. Disse steps kan ses på billedet. På denne måde vidste vi hele tiden hvor på banen vi var og kunne på den måde udføre den rigtige handling ud fra dette. Vi brugte de 2 lyssensorer fra sidste gang, som hele tiden sørgede for at holde os opdateret på hvor vi var på banen. Dette betød at når vi f.eks. så sort på begge lyssensorer første gang, så vidste vi at vi var kørt ud af start området. Det var ideen, at vi ville blive ved sådan indtil ruten var gennemført. Dette lykkes dog ikke for os. Vi nåede rundt i det første sving, men kom så heller ikke videre.

Hvorfor kom vi ikke videre?

Grunden til at vi ikke nåede til toppen og ned igen var hovedsageligt manglende tid. Da klokken blev over 11 og vi begge var nødt til at gå kl. 12, måtte vi erkende at der ikke var tid nok til at kode robotten helt færdig. Så i ren panik for at se om vi kunne nå toppen, gik vi over til at anvende en sekventiel tilgangsvinkel. Dette betød at vi satte robotten til at køre ligeud et stykke tid (tiden det skulle tage at komme op til første sving) og når den tid så var gået skulle robotten dreje til højre og derefter fortsætte lige ud. Det lykkedes os også at få robotten forbi første sving, men herefter gav robotten op og begik selvmord.

Vi nåede derfor ikke til toppen, hvilket vi begge er en smule irriteret over, men man kan jo ikke vinde hver gang. Vi vidste godt at vi umuligt kunne vinde, da vi så hvor hurtigt nogle af de andres robotter kom til toppen og ned igen. Målet blev derfor for os blot at komme på toppen og ned igen.

Forberedelse til robot race - Øvelsesgang 5

Denne uges opgave går ud på at få robotten til at følge en linie og stoppe når den når til målområdet. Opgaven er en god forberedelse til næste uges race, hvor det gælder om at få robotten hurtigst til toppen og tilbage igen. Under denne uges øvelser, har begge gruppemedlemmer deltaget aktivt.

Black White Detection
For at kunne udføre denne og senere opgaver, var vi nødt til endnu engang at bygge vores robot.

Opgaven går ud på at anvende klassen BlackWhiteSensor som vi har fået udleveret. Klassen indeholder en række metoder, hvor 2 bruges til at kalibrere farverne og to bruges til at bestemme om lyssensoren befinder sig over en hvid eller sort farve. Måde denne afgøre dette på er ved at lave et blackWhiteThreshold, som er summen af de to farvers værdi diveret med 2.

For at teste brugen af BlackWhiteSensor klassen, oprettede vi vores eget test program. BlackWhiteTest.
Programmet opretter en ny BlackWhiteSensor som vi herefter kalder calibrate metoden på. Denne metode sørger for at værdierne for hvid og sort bliver gemt og beregner blackWhiteThreshold.
Resten af test programmet udskriver blot den målte værdi og undersøger om der er tale om en sort eller hvid farve.

Programmet brugt i denne opgave kan findes:
http://www.cs.au.dk/~tiras/filer/LEGO/BlackWhiteSensor.java
http://www.cs.au.dk/~tiras/filer/LEGO/BlackWhiteTest.java

Line Follower with Calibration
Denne opgave går ud på at stifte bekendtskab med hvordan man kan anvende BlackWhiteSensor klassen til at få robotten til at følge en linie. Vi får udleveret programmet LineFollowerCal, som netop gør bruge af funktionerne til at bestemmer om den følger linjen.

Programmet brugt i denne opgave kan findes:
http://www.cs.au.dk/~tiras/filer/LEGO/LineFollowerCal.java

Vi vil ikke gør mere ud af denne beskrivelse da næste opgave omhandler samme enme, blot den tilføjelser og ændringer af BlackWhiteSensor klassen.

ColorSensor with Calibration
Denne opgave går ud på at lave et nyt program ColorSensor, som kan kende forskel på sort, hvid og grøn. Programmet er en udvidelse af BlackWhiteSensoren klassen. Tilføjelserne består i at vi har lavet en ekstra variabel greenLightValue, indeholder den kalibrerede værdig for grøn. Ligeledes er et nyt greenWhiteThreshold lavet, som indeholer summer af den grønne og hvide værdi divideret med 2.
Vi har nu to thresholds der indeholder gennemsnittsværdien af henholdsvis sort - grøn og grøn - hvid.

Vi har tilføjet en ny metode green(), som returnere true hvis den aflæste værdi ligger imellem de to thresholdes.

Denne løsning virker for det meste, men kan have problemer med at skelne mellem sort og grøn, da de to værdi ligger meget tæt op af hinanden. En lille forskel i lysmængden kan derfor kan derfor være med til at påvirke resultatet.

ColorSensor programmet kan findes på:
http://www.cs.au.dk/~tiras/filer/LEGO/ColorSensor.java

Line Follower that stops in a Goal Zone
Denne opgave går ud på at få robotten til at følge en linje og stopper når den når til målområdet. For at løse denne opgave har vi gjort bruge af ColorSensor klasse og LineFollowerCal. Klassen LineFollowerCal er blevet modificeret således at den nu også gør brug af metoden green() til at bestemmer om den er nået til målområdet.

Til at starte med gjorde vi kun bruge at en lyssensor, men det viste sig hurtigt at det var svært for den at følge linjen. Grunden til dette er som beskrevet i forrig opgave at den har svært ved at se forskel på sort og grøn.

Dette problem løste vi, ved at tilføje en ekstra lyssensor til robotten. Dette har gjort at den nu er meget mere præcis og nu følger linjen til punkt og prikke. :D
Grunden til at den nu følger linjen bedre, er at den nu kigger ved siden af linjen i stedet for på linjen.

Det nuværende program ser du som følgende:
http://www.cs.au.dk/~tiras/filer/LEGO/LineFollowerCalColor.java

Selv-balancerende robot - Øvelsesgang 4

Opgaven i denne uge går ud på at bygge en robot der selv kan balancere. Det vil sige at den står og vipper frem og tilbage uden at vælte. Under arbejdet med denne øvelse har begge gruppemedlemmer deltaget aktivt.

Som beskrevet tidligere, så går opgaven ud på at bygge og programmere en robot til selv at kunne balancere. Det er meningen at vi skal tage udgangspunkt i Steve Hassenplug, Philippe Hurbain og Brian Bagnall ideer i konstruktionen af sådanne robotter. Vi kigge på designet, hvorefter vi så selv gik i gang med at bygge en robot. Da vi var færdige og havde fået monteret lyssensoren gik det op for os at der var en vejledning på hjemmesiden til hvordan robotten kunne samles.. Vi valgte dog at holde fast i vores eget design.

Hvordan arbejde vi os frem
Vi startede med at finde ud af hvilken værdier vores lyssensoren sendte retur. Vi var dog ikke helt sikkert på hvilken metode vi skulle bruge. Lyssensoren har følgende (og flere) valg muligheder:

readValue(); getLightValue(); getNormalizedLightValue();

Vi valgte til at starte med at anvende getLightValue(). Ved at anvende denne metode fandt vi ud af at vi skulle have robotten til at balancere omkring værdien 50. Vi mente at brugen af en proportional controller var vejen frem, da den tog hensyn til error mellem vores ønsket værdi på 50 og den målte værdi. Denne error mente vi at vi kunne bruge til at bestemme om robotten skulle køre frem eller tilbage. Efter at have kodet på dette et par timer og vores robot stadig opførte sig en syg høne der gik og hakkede i jorden, måtte vi indse at proportional controller nok ikke var vejen frem.

Vi fandt derefter frem til at man kunne anvende en PID controler i stedet. En PID controller forsøger at rette den error der er imellem den målte værdi og den ønskede værdi ved beregninger og derefter sørger for at de rigtige handlinger bliver udført. Formlen for PID controler er som følgende:

MV(t) = POUT + IOUT + DOUT

Når disse værdier er beregnet ud af en mænge målte data, vil det være muligt at få robotten til at balancere..

Hvor langt nåede vi?

Eftersom vi havde brugt alt vores tid på at kode en proportional controler, var der ikke mere tid tilbage fredag. Vi ville derfor gerne have implementeret PID controller, men pga. presset fra et andet kursus har vi desværre været nødt til at opgive håbet om at få robotten til at balancere.
Den kode vi nåede at få lavet, kan findes på
http://www.cs.au.dk/~tiras/filer/LEGO/Balance.java

Vi vil dog i den kommende evaluerings periode, hvis der bliver tid, forsøge at implementere PID controlleren.

Lydsensor - Øvelsesgang 3

Opgaven i denne uge er at udvidde vores NXT-robotten med en lydsensor. Vi startede med at lave en "arm" som sensoren kunne sidde på og monterede den på robotten. Under denne øvelse har begge gruppemedlemmer deltaget aktivt.

Test af lydsensor:
Den første opgave bestod i at omskrive et program der var beregnet til en ultrasonicsensor så den kunne bruges i forbindelse lydsensoren. Efter et par små ændringer fik vi NXT'en til at vise lydniveauet angivet i procent.

Vi testede sensoren ved at lave lyde i forskellig styrke og afstand:

Lyd:	Afstand:	Procent aflæst på NXT:
Normal tale	45 cm	10-12
Klap	30 cm	20
Baggrundsstøj	?	2-3
pc 440 hz, 30% vol	10	18
pc 440 hz, 50% vol	10	45
pc 440 hz, 70% vol	10	91

Man kan se i tabellen at lydsensoren er meget følsom, hvilket betyder at der er er udslag på selv den mindste baggrundstøj. Vi placerede sensoren i et lukket rum og alligevel fik vi målinger på 2-3. Dette er en faktor der er meget lille, men stadig skal tages i betragtning.

Programmet kan findes på:
http://www.cs.au.dk/~tiras/filer/LEGO/SoundSensorTest.java

Data logger:

Data logger opgaven går ud på at anvende NXT'en til at gemme alle målte resultater i en txt fil, og derefter plotte dataerne i en graf. Grafen giver derefter et godt overblik over hvordan sensoren måler og hvordan det
stemmer overens med den lyd der blev mål på.

Til at løse opgaven anvendte vi følgende kode:
http://www.cs.au.dk/~tiras/filer/LEGO/DataLogger.java
http://www.cs.au.dk/~tiras/filer/LEGO/SoundSampling.java

Vi modificerede koden en smule for at få den til kun at indsætte en måling pr. linie, således det derefter var let at overføre alle målinger over i excel for at lave en graf. Eftersom det gav anledning til 3132 måling vælger vi ikke at inkludere dem her, men blot inkludere grafen. Vi udførte to sæt målinger, men da de ligner hinanden meget vælger vi kun at inkludere den ene.

Den lyd vi målte på gav anledning til at kurven skulle bevæge sig i retning af en sinuskurve, hvilket man må sige ikke helt er tilfældet med vores graf. Man kan dog alligevel godt se hvornår lydstyrken bevæger sig op og ned, men der er stadig store udsving på grafen som antyder at sensoren sender forkerte værdier tilbage til NXT'en som vi godt kendte det fra UltralydsSensoren.



Sound Controlled Car

Denne opgave går ud på at anvende noget udleveret kode og betragte hvordan robotten opfører sig på høje lyde. De udleverede kode indholder den fejl at programmet ikke er til at stoppe pga. at den måde det ene loop ligger inden i det andet loop, derfor modificeres koden så det nu bliver muligt at få programmet til at terminere.

Det udleverede program kan findes på:
http://www.cs.au.dk/~tiras/filer/LEGO/SoundCtrCar.java

Den første del af opgaven gik som sagt ud på at se hvordan robotten opfører sig når den hører høje lyde og hvordan programmet bestemmer om der er tale om høje lyde eller ej.
Da det giver mest meningen at starte med at beskrive hvordan robotten bestemmer om den har med høje lyde eller ej, er det det vi gør. Der er i starten af programmet defineret en variabel soundThreshold som er grænsen for hvornår lyden er høj. Programmet står og kører i en while løkken indtil den målte lyd overskrider værdien i soundThreshold. Når det så et tilfældet, så hopper den ud af while løkken og får robotten til at køre frem. Herefter started en ny while løkken hvor den igen står og venter på en høj lyd. Dette er måden den bestemmer om lyden er høj og får robotten til at køre. Rækkefølgenden for hvordan den kører er: Frem -> Højre -> Venstre -> Baglæns.

For at få programmet til at terminere når der trykkes på ESCAPE knappen, kan man vælge mellem to metoder. Vi valgte at gøre det ved at bruge en ButtonListener som hele tiden holder øje med om knappen ESCAPE er blevet trykket ned. Hvis det er tilfældet sættet en boolean stop = true. Denne boolean anvendes så i while løkken som en betingelse, således at når stop = true, så stopper loopet og programmet terminere.

Koden til denne opgave findes sammen med koden til clap controlled car opgaven.

Clap Controlled Car

Denne opgave går ud på at anvende Sivan Toledo's teori om at man kan bestemme et klap ved at måle på lydmønstret. Han mente at hvis en lav lyd (f.eks. under 50) blev efterfulgt af høj lyd (f.eks. over 85) inden for 25 millisekunder og derefter returnerede tilbage til en lav lyd (f.eks. under 50) inden for yderlig 250 millisekunder så var der tale om et klap.

Den måde vi løse opgaven på var at anvende et array af længe 5 til at gemme tidligere værdier i. Ligeledes oprette vi en ny metode isClapped() til at bestemmer om de forskellige betingelse er opfyldt. Hvis det er tilfældet så returneres der true elles false. Denne metode placerede vi så som betingelse i while løkken, således den først hoppede ud af løkken når der blev klappet.

Koden kan findes her:
http://www.cs.au.dk/~tiras/filer/LEGO/SoundCtrCar_Clap.java

Brugen af ultralydssensor - Øvelsesgang 2

Målet med denne uges opgaver at udvide kendskabet i brugen af NTX'en. Denne uge omhandlede opgaver hvori vi skulle anvende en ultralydsensor til at måle afstand til forskellige elementer. For at få placeret ultralydsensoren på robotten, var vi nødt til at lave nogle små ændringer som vil blive beskrevet senere.

Under øvelserne var begge medlemmer af gruppen til stede.

Denne uges opgaver bestod af følgende:

1. Tilføje ultralydsensoren til robotten
2. Lave målinger med ultralydsensoren og sammenligne de målte afstande med den rigtige afstand.
3. Tracker Beam: Et udleveret program som sørger for at robotten ikke kører ind i ting.
4. Wall Follower: Et program vi selv koder for at få robotten til at følge en væg.

Tilføjelse af ultralydssensor
Denne første opgave gik ud på at tilføje en ultralydssensor til robotten. Dette blev gjort ved at følge vejledningen side 28 - 30. Denne opgvage indeholdte ikke nogle svære elementer, så derfor havde vi heller ikke nogle problemer med denne fase.

Målinger med ultralydssensor
De første målinger omfattede forskellen imellem den reelle afstand og den afstand der bliver vist på displayet. Diagrammet viser forholdet imellem disse og det ses at det er en næsten lineær afbildning.

Hvis man ser på forskellen imellem det der bliver vist på displayet og den målte afstand, ses afvigelserne tydeligere. Vores målinger viste at der var ret stor afvigelse fra 0-5 cm da det mindste vi kunne få vist på displayet var 5 cm. Fra 5-250 cm var afvigelserne mere uniforme og lå på ca 1-2 cm. Fra 250 cm og op viste displayet 255.













Den sidste del af delopgaven gik ud på at beregne responcetiden for sensoren. Lydens hastighed er 340 m/sek = 20400 cm/sek. Vha. denne oplysning kan vi finde reponsetiden ved at bruge følgende formel: responcetid i sekunder = (afstand * 2) / 20400. Diagrammet nedenunder viser responcetiderne for forskellige afstande. Responcetiden for den afstand der maksimalt kan måles er omkring 25 ms. Denne tid er ikke noget der påvirker resultaterne.













Tracker Beam
Denne opgave at se hvordan robotten reagere på ændringer af variablerne. Robotten arbejder i programmet med 6 vigtige variabler:

• distance: den aktuelle afstand til objektet.
• desiredDistance: den afstand hvor man ønske robotten skal begynde at tage action.
• power: bestemmer hvor meget power der skal på motoren.
• minPower: minimums farten man ønsker robotten bevæger sig med.
• error: forskellen mellem den målte afstand of den ønskede afstand. Sålænge error er større en 0 kører robotten frem af, med det sammen error bliver mindre eller lig 0 kører robotten baglæns.
• gain: sørger for at farten falder proportionalt med at vi kommer tætterre og tætter på objekter.

Det programmet gør, er at den sålænge error (distance - desiredDistance) > 0 får robotten til at kører frem. I takt med at robotten kommer tættere på et objekt bliver error mindre og mindre, hvilktet får robotten til at sætte farten ned. Robotten har dog en minPower variablen, som sørger for at robotten aldrig får en far under 60.
Når robotten er så tæt på objekter at error falder til mindre eller lig med 0, så begynder robotten at kører baglæns væk var objektet. Når afstanden til objekter så igen øges vil error også kommer over 0, hvilket får robotten til igen at kører frem. Pga. den måde gain er med til at bestemme farten, vil robotten kommer til at står og kører frem og tilbage i små stræk, da error vil komme til at stå og svinge omkring 0.
Ved at ændre variablen gain til f.eks. 5, vil robottens udsving omkring 0 blive større. Dvs. at robotten bevæger sig længere væk fra den ønskede afstand (desiredDistance). Denne form for kontrol kaldes proportional control, eftersom den gør brug af en måle variable og en control variabel.

Hvis vi ændre desiredDistance, vil robottens afstand til objektet ændre sig til den ny afstand.

Filerne til denne opgave findes:
http://www.cs.au.dk/~tiras/filer/LEGO/Tracker.java
http://www.cs.au.dk/~tiras/filer/LEGO/Car.java

Wall Follower
Til at starte med ændrede vi robotten således ultralydssensoren kom til at sidde med 45 graders vilkel i forhold til robotten, således den hele tiden kigger skrå frem.
Under implementeringen af wall follower opgaven gik vi ud fra progarmmet Tracker.java, som vi gik i gang med at kode om.

De omkodede filer kan findes på:
http://www.cs.au.dk/~tiras/filer/LEGO/WallFollower.java
http://www.cs.au.dk/~tiras/filer/LEGO/FollowCar.java

Til at starte med ændre robotten så den skifter med at kører til venstre og højre alt efter afstanden til væggen. Dette virkede også meget fornuftigt hvis robotten blot skulle kører langs en lige mur, men da den også skulle kunne klare f.eks. 90 graders sving fik den problemer. Derfor lavede vi det sådan at hvis den kom rigtigt tæt på muren så drejede den til venstre for at undgår det stor sving. Dette virkede også til en hvis grad når vi satte den ønskede afstand til muren til en højere værdi. Dette var selvfølgeligt ikke noget super løsning men den virkede.

Et af de problemer der voldte os store problemer var at ultralydssensoren kunne finde på at sende værdien 255 tilbage til robotten, selvom den faktiske afstand kun var 30 cm, dette fik robotten til at dreje længer ind mod væggen hvorved kan pludselig kom for tæt på og robotten tog en 90 graders sving væk fra muren igen. Dette betød at robotte var nødt til at køre en godt stykke tid for den igen fandt muren og kunne vende tilbage til sin normale kørebane. Dette var dog blot til det næste voldsomme udsving fra sensoren.

Hvis vi skulle have løst dette problem, var vi nødt til at have lavet et filter, således at hvis robotten f.eks. modtog 1, 2 eller 3 signaler på 255 mens alle ander var på omkring 30, så skulle de bare ignoreres. Dette vil have fået robotte til at holde sin bane uden alle de store sving. Ligeledes kunne man have udnyttet det at når sensoren endelig sendte 255 tilbage i store mængde så skulle robotten dreje 90 grader til højre, fordi så betød det at robotten var nået til et sted hvor der var et hul i vægge og derfor skulle uden om den.
Et filter ville ligeledes have været med til at løse et muligt problem med at vores sensor opfangede signaler fra andres sensor. Et filter ville altså have været en stor hjælp på vores problemer med robotten.

Lær at kende din robot - Øvelsesgang 1

Målet med denne uges opgaver har været at stifte bekendtskab med LEGO mindstorms og måden den programmeres på igennem LeJOS.

Denne uge har gået med at få udleveret det Lego vi skal arbejde med igennem de næste mange uger. Ud af det Lego vi har fået udleveret skulle der bygges en LEGO bil, udstyret med en lyssensor som kan følge en linie. Programmet til denne bil er skrevet i Java og for at uploade programmer til NXT modulet er man nødt til at have LeJOS installeret på både computer og NXT modul.

Opsumering af opgaver:

1. Bygge LEGO bil med lyssensor og få etableret forbindelse mellem computer og NXT.
2. Få bilen til at følge en linie
3. Find forskellige farveværdier vha. lyssensoren med og uden LED tændt.
4. Ændre delayet lyssensoreren og se påvirkningen af dette.
5. Brug Runtime.getRuntime().freememory() til at se forskellen på fri hukommelse ved brugen af henholdsvis variabler og strenge direkte indsat i metodekald.

1. Konstruktion af robot.
Vi fik udleveret de to kasser med lego der indeholdt de dele der skulle bruges til konstruktion af robotten, men der manglede en vejledning til hvordan denne skulle bygges. Vi fandt dog en på nettet der mindede om, og byggede lidt om på den så den passede med specifikationen. Vi havde lidt problemer med at få forbindelse imellem computeren og NXT modulet, men efter vi havde fået installeret de korrekte drivere og Eclipse plug-in kørte det som det skulle.

2. Follow the line...
Programmet i øvelsesvejledningen blev uploadet til robotten og blev testet på en bane der var lagt ud i øvelseslokalet. Robotten brugte lyssensoren til at finde ud af om den var over en sort streg og korrigerede hvis den kom uden for, og kom derved til at køre i en zik-zak bane over stregen.

Filen kan findes på: www.cs.au.dk/~tiras/filer/LEGO/FollowTheLine.java

3. Forskellige farveværdier.
Vi brugte NXT modulet med lyscensoren tilkoblet til at aflæse forskellige farveværdier. Eftersom programmet allerede skrev farveværdierne på skærmen, ændrede vi ikke noget i programmet.

NXT'en gav os følgende farveværdier:

Farve:	LED on:	LED off:
Blå:	43	30
Grøn:	49	39
Rød:	56	34
Gul	60	43
Sort:	35	25
Hvid:	60	39

Det ses at der er flere farver der samme eller næsten samme værdi og kan derved konkludere at sensoren ikke kan skelne imellem farver, men kun gråtoner.

4. Ændring af delay:
Her var vi nødt til at ændre en smule i koden. Det oprindelige program indholdte følgende kode

Thread.sleep(100);

hvor i vi ændrede værdien til henholdsvis 10, 500 og  1000, for at sammenligne robottens opførelse omkring stregen.
Da vi prøvede at ændre delayet til en højere værdi, resulterede det i at der kom et større udsving i zik-zak banen eftersom der var længere tid imellem aflæsningerne. Når delayet blev sat til en lavere værdi blev banen mere lige og robotten kunne gennemføre banen en del hurtigere.

5. Memory:
Denne opgave går ud på at se hvordan NXT'en reagere på brugen af henholds vis variabler og strenge i funktions kald. Det oprindelige program var som følgende:

String left = "Turn left ";
String right= "Turn right";
 
LCD.drawString(right, 0, 1);
LCD.drawString(left, 0, 1);

Dette program ændrede vi således at i stedet for at bruge variablerne left og right i drawString() metodekaldet, placerede strengene direkte i metodekaldet. Ligeledes tilføjede vi noget ekstra kode for at få NXT'en til at udskrive hvor meget fri hukommelse den havde. Ændringerne var som følgende:

LCD.drawString("Turn right", 0, 1);

LCD.drawString("Turn left", 0, 1);

Tilføjede følgende kode:
LCD.drawInt((int) Runtime.getRuntime().freeMemory(), 2, 5);

Når drawString metoden bliver kaldt med en string-variabel bliver der ikke allokeret ekstra memory, men når metoden bliver kaldt med en streng direkte skrevet i metodekaldet bliver der allokeret ektra plads til stregen hver gang koden bliver eksekveret. Man kan se at NXT'ens virtualle maskine har en garbage collector da der bliver frigjort memory inden hukommelsen er fyldt.