Embedded Systems Lesson 3

Date: 20/2 2014
Duration of activity: 3 timer 
Group members participating: 
Henrik Jørgensen
Michael Schiønning 
William Thorsen 

Mål 

Målet med denne øvelsesgang er at gennemføre øvelserne til denne uges ugeseddel "Acting and Actuators^[1]

Plan

Planen for denne uge er: 

• Påmontere robottens lydsensor 
• Udarbejde ugens øvelser. 
• Påbegynd blogindlægget for denne uge med den forrige uges kritik i mente.

Resultat af øvelser 

Opgave 1 

Til den første øvelse skulle vi have monteret lydsensoren samt downloadet, compilet og kørt SonicSensorTest.java^[2] til at teste vores sensor

Den nedenstående tabel viser de resultater vi har fået fra vores målinger. Til målingerne har vi gjort brug af et normalt klap samt en kontinuert tone^[3] fra en af vores telefoner. Ideen med de to valg er, at klappets mønster indeholder et spring fra lav-amplitude til høj-amplitude (som vi senere ser i opgave 5). Tonen derimod bibeholder den samme amplitude (alle 10 timer...), hvilket giver os så konsistente målinger som muligt. 

cm	0	50	100
klap	49	32	11
beeeep	92	54	20

Som det fremgår af tabellen kan vi se at beep-tonen opfanges langt lettere ved de forskellige afstande. Dette kan være grundet at tonen, som førnævnt, er kontinuert, men samtidigt at klappets ampitude ikke er lige så stor som tonen og falder relativt hurtigt af i styrke. 

Alle målingerne er foretaget vinkelret på lydsensoren og afstanden er afmålt fra spidsen af sensorens "hovede".


Opgave 2

Til den anden opgave skulle vi igen gøre brug af DataLogger.java^[4] fra sidste uge til at indsamle lyddata via det udleverede SoundSamling.java^[5]. Grafen neden under er over beep-lyden da den som sagt var lettere at holde styr på grundet den konstante lyd. 

Opgave 3

I denne opgave skulle vi gøre brug af SoundCtrCar.java^[6]. Programmet får robotten til gentagne gange at vente på en høj lyd. Ved første registrering bevæger den sig fremad, ved den anden registreting drejer den til højre. Den tredje gang vil den dreje til venstre og fjerde gang den registrerer en høj lyd stopper robotten.

Måden hvorpå programmet aflæser høje lyder er, at i metoden waitForLoudSound bliver der konstant taget prøver med lydsensoren indtil den modtager en prøve der ikke er mindre end det threshold (her sat til 90). Når en af de returnerede prøver er >= 90 returnerer funktionen, hvilket i dette tilfælde betyder at den har opfanget en høj lyd.  

Opgave 4

Programmet SoundCtrCar2.java^[7] looper og vi skal få den til at stoppe efter et tryk på ene af vores tilgængelige knapper. Dette kan gøres ved at implemtere en buttonlistener som lytter på en input på en knap, I vores tilfælde escape og så når breaker ud af den igangværende løkke. 

Samt også lettest ved at hardcode escape til altid at breake ud af loops og terminere programmet.

Opgave 5

I denne opgave skulle vi forsøge at bruge Sivan Toledo^[8] metode til at registrere klap på.

Vores endelige implementation afviger fra Toledo ved at være mindre rigid i kravene til et klap.

Vi benytter to sample-rækker, en til kort- og en til lang-tidshorisont. Størrelsesforholdet mellem medianen i de to rækker afgør da om vi tolker et klap. Opførelsen kan da reguleres ved at skrue på samplerate, samplesize og grænseværdien for tolkning af et klap.

En naiv implementation der fulgte Toledo vil være mere usikker.

...

if(soundLevel < 50) {

Thread.sleep(25);

soundLevel = sound.readValue();

if(soundLevel>85) {

Thread.sleep(250);

soundLevel = sound.readValue();

if(soundLevel<50) {

Sound.beep();

break;

}

}

}

...

I stedet for en flydende evaluering af den indkommende lyd låses tråden i mindst 275ms ved kraftige lyde længere end 25ms.

Implementationen i ClapBeep.java^[9] var mere reagerende, dog kunne den få problemer ved længerevarende støj der øgede middel db for den længerevarende sample række.

Opgave 6

Til den sidste opgave skulle montere to sensorer på robotten og via de lyde den modtog skulle den altid bevæge sig imod høje lyde. For at få party robotten til at følge hvilken side lyden kom fra lavede vi et simpelt differensudtryk. Er differens 0 kør ligeud, er differens under eller over 0 så kør til den respektive side. Til dette har vi implementeret PartyBot.java^[10].

Nedenfor ses en optagelse af vores PartyBot.java i funktion. Vi havde nogle enkelte problemer med at robotten kørte lige frem selvom lydkilden var placeret foran den ene sensor. Altså burde robotten ahve drejet enten til venstre eller højre. Vi regner stærkt med at dette er fordi den anden sensor formår at opfange lyden selvom den peger i en anden retning. Derfor sætter robotten sin differens til at være 0 og den kører lige frem. 

Ydermere oplevede vi at vores robot faktisk kunne opfange nogle af de lyde de andre grupper i lokalet gjorde brug af, hvilket resulterede i at robotten rørte på sig, inden vi havdde tændt for vores lydkilde. 

Konklusion

I denne uge har vi fået monteret robottens lydsensor og fået et indblik i, hvordan sensoren virker via denne uges opgaver. Dette indebærer bl.a. vores afstandsmålinger af klappe- og beep-lyden.Ydermere har vi lært at det er muligt at få robotten til at bevæge sig i bestemte retninger når den opfanger høje lyde via sin sensor. Dog har vi også erfaret at der kan være visse problemer med brugen af lyd. 

Nogle gange kan det være svært for sensoren at opfange lyde konsistent over længere afstande, som da vi forsøgte at bruge dataloggeren til at måle vores klap. Endvidere rendte vi ind i det førnævnte problem, at den ene sensor kunne opfange en lyd der var ment til anden sensor og derved skabe en hvis form for ravage 

---

1 http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson3.dir/Lesson.html^↩
2 https://docs.google.com/file/d/0B22Duz_kNMvWWkxuVEx3cVhtN2c/edit^↩
3 http://www.youtube.com/watch?v=GhhcpQI3iAs^↩
4 http://legolab.cs.au.dk/DigitalControl.dir/NXT/src/DataLogger.java^↩
5 http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson3.dir/SoundSampling.java^↩
6 http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson3.dir/SoundCtrCar.java^↩
7 https://docs.google.com/file/d/0B22Duz_kNMvWYnM3Mks1Uk1tZHM/edit^↩
8 http://www.tau.ac.il/~stoledo/lego/ClapCounter/^↩
9 https://docs.google.com/file/d/0B22Duz_kNMvWaFlISi02RUZWelU/edit^↩
10 https://docs.google.com/file/d/0B2MYdpHIaaatRWhCYmNodVNjUVE/edit^↩

Embedded Systems Lesson 2

Date: 13/2 2014
Duration of activity: 3 timer 
Group members participating: 
Henrik Jørgensen
Michael Schiønning 
William Thorsen 

Mål 

Målet med første øvelsesgang er at samle LEGO-robotten, få basal kendskab til leJOS og gennemføre denne uges opgaver. 

Plan

Planen for denne uge er: 

• Påmontere robottens ultrasoniske sensor
• Udarbejde ugens øvelser. 
• Påbegynd blogindlægget for denne uge

Resultat af øvelser 

Til de første to opgaver skulle vi placere vores robot foran en række objekter ved forskellige afstande og til sidst sammenligne afstanden med de læsningen sensoren gav. På billedet nedenfor ses de objekter vi har brugt til at udføre målingerne med: 

Opgave 1

Denne tabel viser de målede resultater som er kommet frem ved hjælp af det udleverede SonicSensorTest.java program. Det har en måleinterval på 300 ms 

	30cm	50cm	100cm	150cm	200cm
Ting	30	50	100	150	200
Væg	30	49	100	146	193
Bog	30	48	101	145	255
Plastic	30	51	102	160	255

Sensoren kan måle en stor afstand afhængigt af hvad genstand der bliver brugt og sandsynligt også komme på de max 255 cm, dette kan skyldes at genstandene har forskelling størrelse. En anden mulighed er  at visse objekter måske absorbere noget af lyden inden den kastes tilbage ulig hårde overflader som f.eks. en mur.

Opgave 2

I denne opgave har vi så vidt som muligt genskabt forholdene fra opgave 1, så vi kan få den bedste sammenligning. Vi satte vores målingsinterval ned på 10 ms istedet for 300 ms for at se en forskel

10 msec
ting
Væg	30	49	100	149	191
Bog	30	48	100	148	195
Plastic	30	53	255	255	255

Plastik beholderen gav langt dårligere resultater end i første målling, men derimod så blev resultatet med bogen langt bedre. Altså må nedsættelsen af måleintervallet gøre det lettere for sensoren at kunne registrere objekter langt væk.

Opgave 3

Vi prøvede for så vidt muligt at få den længst mulige målling ved at stå foran en væg. Det bedste vi kunne få var 227cm ud af de 255 potentielt mulige. 255 er måske muligt ved at holde sensoren på en bestemt måde eller måle  på et specifikt objekt.

Vi har en maximal måleafstand på 255cm hvilket betyder sensoren skal sende et ekko 255cm frem og så skal ekkoet 255 cm tilbage, med lysets hastighed på 340.29 m/sek så giver det (2.55*2)/340.29 = 14.987 ms. 

Opgave 4

Den strøm der leveres til motorne bestemmes af en proportional relation til en målt afvigelse (error). Afvigelsen er givet ved forskellen imellem den målte og den ønskede afstand til et objekt.

error = distance - desiredDistance;

Altså vil en større afvigelse resultere i større kraft leveret til motorne, dette er altså en proportional control. Kraften kan som udgangspunkt variere i et interval [60; 100] hvilket resulterede i oscillerende adfærd når error nærmede sig nul. Reduktion af denne adfærd opnåede vi igennem en mindre aggresiv tildeling af kraft til motorne. Ved at sænke gain eller minPower bevæger robotten sig langsommere og dennes forsøg på at reducere en afvigelse har da mindre mulighed for faktisk at overskyde error = 0 og dermed resultere i en øget afvigelse.

Opgave 5

Efter at have kørt det udgivne Tracker.java og set  den occilere skulle vi se om
vi kunne få den til at stå stille, ved at bruge den udgivne pseudokode for en PID controller

previous_error = 0
integral = 0 
start:
  error = setpoint - measured_value
  integral = integral + error*dt
  derivative = (error - previous_error)/dt
  output = Kp*error + Ki*integral + Kd*derivative
  previous_error = error
  wait(dt)

  goto start

Ved at sætte kp = 0.5f; ki = 0.0f; kd = 0.1f vil robotten stadig occilere lidt, dog ved at sætte power til 50 stod robotten helt stille.

Opgave 6

For at løse opgaven skulle vi oversætte Philippe Hurbains wallfollower program til Java. Linket til et klip af robotten i aktion samt selve koden til wallfollower programmet kan findes nederst på siden. Vi nåede dog ikke at sammenligne NQC-algoritmen med de alternativer i Fred G. Martins tekst. 

Konklusion

Vi har efter i dag lært, hvordan den ultrasoniske sensor fungerer ved at udsende en kort høj-frekvens lyd og opfange ekkoet. Ud fra dette kan sensoren måle afstanden til diverse objekter. Ydermere har vi lært at den fysiske verden, her de målte objekter og hvilket materiale de består af, kan have stor indflydelse på sensorens måling. I visse tilfælde kan det endda give os forkerte resultater. 

Referencer
Fred G. Martin, Robotic Explorations: A Hands-on Introduction to Engineering, Prentice Hall, 2001
Øvelserne, SonicSensorTest.java og Tracker.java er hentet fra kursussiden:
http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson1.dir/Lesson.html
Link til google drive med vores WallFollower.java fil: 
https://docs.google.com/file/d/0B22Duz_kNMvWa0lwaDM3clV2Zk0/edit
Link til youtube klip med WallFollower.java i aktion: 
http://www.youtube.com/watch?v=d6b3xoQLZXU
Link til bloggen:
http://eswihemi.blogspot.dk/

Embedded Systems Lesson 1

Date: 6/2 2014
Duration of activity: 3 timer
Group members participating: 
Henrik Jørgensen
Michael Schiønning 
William Thorsen 

Mål 

Målet med første øvelsesgang er at samle LEGO-robotten, få basal kendskab til leJOS og gennemføre denne uges opgaver. 

Plan

Planen for denne uge er: 

• Installere leJOS 
• Samle LEGO-robotten med lyssensoren 
• Udarbejde ugens øvelser.
• Opsæt gruppens blog. 

Resultat af øvelser 

Den første øvelse gik ud på at bruge robottens lyssensor til at måle lysværdien på en forskellige række legoklodser af forskellige farver, som kan ses i tabellen nedenfor.

Red	60
Black	40
Orange	60
Blue	53
Light Grey	53
Light Green	57
Yellow	64
"Dark" Grey	53
"Dark" Green	40
White	66

Måden hvorpå sensoren opfanger lys er via en skala fra 0 til 100. 100 svarer til meget lyst og 0 svarer til mørkt. Ud fra vores data kan vi her vælge en grænseværdi imellem hhv. den sorte og den hvide lysværdi ~40-61. Alle målingerne er foretaget med en afstand fra klodsen til sensoren svarende til den afstand sensoren har til jorden når den er monteret på robotten.  

Grænseværdien betyder at robottens program antager, at sensoren er over et sort område når den afmålte værdi befinder sig under den givne grænseværdi. Ellers er sensoren over et hvidt område.    

Øvelse 2 

I den anden øvelse skal vi, igen måle de samme legoklodser, men denne gang uden at sensorens LED lys er tændt. Nu måler sensoren ikke længere reflektionen af det røde LED lys, men derimod bliver omgivelsernes lys målt. Den nedenstående tabel viser de samme legoklodsers målning efter dioden er slukket. Igen er samme afstand brugt til alle målingerne. 

Red	25
Black	17
Orange	29
Blue	23
Light Grey	21
Light Green	27
Yellow	31
"Dark" Grey	20
"Dark" Green	27
White	33

Øvelse 3

Fra starten af er det en forsinkelse på lyssensorens læsning på 10 millisekunder. Øvelsen krævede at vi satte dette op til henholdsvis 100, 500 og 1000 millisekunder. Fordi intervallet mellem robottens læsning sættes ned er den længere og længere om at registrere at den skal rette op. Når den kom uden for den sorte streg kunne robotten have problemer med at finde tilbage. Især ved 1000 millisekunder var tiden mellem afmålingerne så stor, at den kørte i cirkler. Dette var fordi at robotten når at passere den sorte linje i løbet af sin rotation, om de ene hjul, før den foretager målingen.

Øvelse 4

Til øvelse 4 skulle vi tage brug af Datalogger.java til at indsamle data fra robottens lyssensor når intervallet er hhv. sat til 10, 100, 500 og 1000 millisekunder. 

Målingerne er sat ind i graferne nedenfor. Som det fremgår af grafen, oscillerer den kraftigere jo kortere intervallet er imellem afmålingerne. 






Øvelse 5

Vi observerede et jævnt fald i ledig hukommelse, dette kan forbindes med at vi nu skrev strenge direkte i LCD.drawString(). En streng er en reference til et objekt, en in-line streng udgør da  en instantiering af et objekt. Når vi ikke benytter en refereret streng (som tidligere) vil der altså konstant oprettes nye objekter. Garbage collectoren vil da rydde op i disse objekter med jævne mellemrum, hvilket sås ved en kraftig stigning af fri hukommelse .

Konklusion

Vi har i denne uge fået styr på det helt basale hvad leJOS angår, bygget Mindstorms robotten og opsat vores gruppes blog til at kunne føre vores lab-notesbog. Overall har denne uges opgaver ikke været de mest krævende da de har stået for at introducere os til, hvordan den fysiske virkelighed påvirker vores robot. Robotten reagerer kun på den virkelighed den selv har "læst" og har en række begrænsninger, deriblandt dens reaktionstid.

Ved næste øvelsesgang skal vi have taget hul på Eclipse plug-in'et til leJOS og nok også kigget på Bluetooth muligheden, da den med allerhøjeste sandsynlighed bliver nyttige i løbet af de senere uger.

Referencer
Øvelserne, LineFollower.java samt SLineFollower.java er hentet fra kursussiden:
http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson1.dir/Lesson.html
Link til bloggen:
http://eswihemi.blogspot.dk/