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.