Embedded Systems Lesson 7

Date: 3/4 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 Agents & behaviour selection in agents, subsumption architecture¹

Plan

Planen for denne uge er:

• Ombygge robotten til øvelserne
• Udarbejde ugens øvelser 
• Påbegynde blogindlæg

Resultat af øvelser

Opgave 1

Efter at have bygget den nye robot med en ultrasonisk sensor, en lyssensor samt en bumper, via to touch sensorer, startede vi den udleverede AvoidFigure9_3.java² klasse. Måden den virker på er, at robotten hele tiden måler afstanden fra sensoren til et objekt, samtidigt med at den fortsat kører fremad.

Når sensoren opfanger en afstand, der er mindre end et givent threshold stopper robotten og den checker hvilken en af sine 2 målinger der er den største. Vi er ikke helt 100% sikker på hvad der menes her, men vi regner med at den højre afstandsværdi måles ud fra sensorens højre øje og vice versa for venstre.

Når de to værdier sammenlignes drejer robotten i den retning hvis "øje" har den største værdi og derved drejer vi uden om den givne forhindring. Vi rendte dog ind i et tilfælde, hvor vores robot ikke kunne finde ud af at rette op når den bevægede sig imod en mur. Hvis vinklen mellem muren og robotten er tilpas spids vil de målinger sensoren foretage sig ikke nå under klassens threshold og vi ender med nærmest at glide langs væggen uden at rette op.

Enten kunne man pille lidt ved klassens threshold og hæve det for at undgå situationer som dette. Det der nok er mest sandsynligt, men som vi ikke lige fik dobbeltchecket, er at da vi byggede robotten satte vi alle sensorene på. Altså betyder det at den ultrasoniske sensor ikke er placeret lige midt for robotten, men nærmere 1/4 af robottens bredde (jvf evt billedet fra opgavesiden¹). Derved kan det muligvis gøre at hvis vi har en spids vinkel mellem robot og en væg på højre side af robotten kan målingerne på det højre øje være over vores threshold som en centreret sensor måske ville have reageret på.


I den anden del af opgaven var det blot et spørgsmål om at indsætte et ekstra check for at se om alle tre afstande (leftDistance, frontDistance og  rightDistance) er mindre end vores stopThreshold. Når det er tilfældet giver vi først lidt power til begge hjul så den bakker og derefter kun power til det ene af hjulene så vi kan vende.

Koden kan findes her³

Opgave 2

Programmet RobotFigure9_9.java⁴ implementerer nu yderligere to behaviours: nemlig Follow og Cruise samt en arbritarian mechanism. Efter at have downloadet programmet og overførte det, startede vi robotten. Fordi vi i første forsøg var ude i det lyse fællesrum var der ikke rigtigt en lyskilde for Follow behaviouren at skulle specifikt følge. I stedet for får Avoid prioritet og checker hvorvidt vi er ved at støde ind i noget. Er det ikke tilfældet får Follow nu prioriteten og checker om der er en lyskilde at følge. Ellers bevæger vi os blot fremad.

Slår vi både Follow og Avoid fra har vi blot en robot der kan kører fremad og intet andet. Aktiverer vi nu  Follow vil robotten aktivt søge imod en stærkere lyskilde, men skulle vi kolliderer med en mur har vi ingen mulighed for at rette op, da det er Avoids ansvar.

Opgave 3

Escape-funktionen⁵ bliver opbygget på samme måde som det udgivne eksempel i  Mobile Robots, Inspiration to Implementation,  samt de allerede opgivne Follow.java og Avoid.java
Efter et par justeringer virkede robotten efter hensigten og bumperen fungere nu og får prioritet når den bliver trykket uanset hvad der kommer ind af lys- eller længdesensoren⁶



Opgave 4

Vi nåede ikke at påmontere den tredje motor til lyssensoren.

Opgave 5

Arbiter og SharedCar virker grundlæggende på samme måde som foreslået i Mobile Robots, Inspiration to Implementation s. 306 ⁷. I stedet for en hardcoded liste indsættes processer i et array, udfaldet af konflikter afgøres ved en prioritet ud fra indexeringen af dette array; Jo hørere indeks jo højere prioritet.

I Martin⁸ håndteres prioritetskonflikter mellem processer (flere med samme prioritet) ved først at finde højeste prioritet og så vælge den først fundne process med denne prioritet.

Konklusion

Denne gang har vi lært omkring brugen af forskellige behaviours og måden man kan væve dem sammen på via en arbritarian mechanism. Nemlig at man vægter hvilken opførsel der er vigtigst og derved ændrer robotten sin strategi Samtidig skal man dog, igen, være opmærksom på at specilt den soniske- og lyssensor kan være lidt tunge at danse med og måske ikke altid giver en de allerskarpeste målinger.

---

1 http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson7.dir/Lesson.html^↩
2 ^{http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson7.dir/Programs/AvoidFigure9_3.java↩}
3 ^{http://codetidy.com/8726/↩}
4 ^{http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson7.dir/Programs/RobotFigure9_9.java↩}
5 ^{http://codetidy.com/8728/↩}
6 ^{http://codetidy.com/8727/↩}
7 ^{http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson7.dir/11128_Mobile_Robots_Inspiration_to_Implementation-Flynn_and_Jones.pdf↩}
8 Fred Martin, [4, page 214-218]^↩