Uge 12; Initial description of end course project

Deltagere: Lars, Thomas og Morten

Goal:
At tage en begrundet beslutning med hensyn til udformningen af vores slutprojekt, herunder at vurdere flere forskellige alternativer udfra de kriterier der står beskrevet i opgaveformuleringen.

Plan:
Analysearbejdet tager udgangspunkt i Capranis liste med forslag, samt gruppens egne ønsker og interesser for indholdet af slutprojektet.

1. I første omgang skal der udføres en brainstorm. Dette gøres for at få listet egne ideer og ønsker.
   
2. For hvert muligt emne skal der:
• Udformes en kort beskrivelse.
  
• Diskuteres hw / sw; antallet a NXT'er, kommunikation, hvilke sensorer og aktuatorer, sw arkitektur med argumentation.
  
• Diskuteres muligheder for at konstruere et 'kunstigt miljø', bedre passende for den givne NXT.
  
• Påpeges det sværreste at løse i projektet, med argumentation.
  
• Listes hvad vi forventer at kunne fremvise til slut.
  
3. Efter listen er gennemgået, skal der argumenteres for gruppens valg af slutprojekt.
4. Herunder skal der laves en dyberegående beskrivelse af projektet, evt. i samarbejde med Caprani.
5. Sidste punkt er, at udforme en realistisk tidsplan for projekt-processen

Activities:

Liste med projektforslag:

• Legovej navigation.
• Evolution.
• Legway.
• Interactive Robot Games.

• Autonom robot med kortopbygning, inspireret af bl.a. Maja J Mataric.
• Robot som interaktiv legetøj.

Analyser:
Legovej navigation og/eller autonom robot med kortopbygning, inspireret af bl.a. Maja J Mataric.

• Her kan man i første omgang starte med een NXT, som om nødvendigt kan kommunikere med en stationær PC via bluetooth.
• Omkring miljø, har gruppens erfaringer vist, at et almindeligt kontormiljø med stole- og bordben er meget besværligt for robotten at manøvrere i. En mulighed for at afhjælpe dette problem vil være at konstruere et kunstigt miljø, f.eks. Legovej elementer, eller et rum kun med klare og tydelige flader, f.eks. større kasser hvor der er mulighed for tydelige ekkoer for UltrasonicSensoren.
• Der skal bruges flere slags atenuatorer og aktuatorer;
• CompassSensor - vil kunne gøre navigationen mere præcis, idet kørselsretningen kan korigeres.
• UltrasonicSensor - kan have flere formål, det primære vil være at måle afstande til større objecter. De målte afstande koblet med vinkler fra kompasset, kan måske vise sig at hjælpe til at korigere navigationen, sammen med en form for virtuel mapbuilding, ie. korektion af cartesisk position.
• LightSensor - kan bruges til at genkende kunstige pejlemærker eller referencepunkter, f.eks. et grønt farvet stykke karton på gulvet.
• TouchSensor - en failsafe, hvis der køres ind i stoleben eller andet der kan være for småt til at reflektere ekko tilbage til UltrasonicSensor.
• 2 eller 3 motorer - minimum 2 motorer med tachomålere til fremdrift, og evt. en motorer for at dreje UltrasonicSensor i flere retninger og tage målinger.
• Det største problem vil blive at udvikle en abstraktion på og mulig vedligeholdelse af et kort over NXT'ens miljø. En abstraktion der er tilstrækkelig og ikke samtidig bliver uanvendelig, fordi det bliver i et menneskeligt symbolsprog som robotten ikke kan forholde sig til fysisk.
• Omkring hvad der er muligt at fremvise til slut;
• 1) En mulighed der har været på tale er en slags 'sentry' eller vagtrobot, der kunne have til opgave at køre rundt og holde øje med om forskellige tilstande i miljøet ændrer sig, f.eks. gennemsnitlig støj- / lys-niveau for forskellige kendte positioner, evt med en form for bevægelses sensor.
• 2) Der har også været snak om en robot der skal kunne finde en optimal rute gennem en labyrint, via en form for kortopbygning og planlægning.

Evolution manipulation og distribuering af robotgener:

• Man kan starte med at eksperimentere med 2 NXT-blokke, siden kan man låne sig frem, når/hvis der skal eksperimenteres med større flokke.
• Omkring miljø, vil det optimale, som nævnt før, være at lave et kunstigt miljø der ikke er besværligt for robotter at manøvrere i. I artiklen fra Embodied Evolutions bruges der jo f.eks. et lys, der hjælper som dommer for hvilke gener der skal overleve og hvilke der ikke skal. I artiklen af striegel er der også en dommer, ie. robotterne selv, hvis de ikke kan komme i kontakt med hinanden uddør de.
• Der skal bruges flere slags atenuatorer og aktuatorer. I første omgang kan der til hver NXT-blok anvendes to RCX lyssensorer, til at lave fysikken tilsvarende en Braidenberg vehicle, dvs. der også skal bruges 2 uafhængige motorer til at manøvrerer rundt med. Hvis Braidenbergs-behaviour kan komme til at fungere relativ hurtigt kan man udvide antallet af sensorer og ligeledes opførslen.
• Muligheden forligger at man bare anvender talværdier til at repræsentere gener, ligesom i eksperimenterne fra Embodied Evolution, men det kunne måske være mere interessant at anvende noget lignende reflection, ie. istedet at overføre metoder som gener. Det vil i alle fald forøge spektret af mulige genkonstruktioner. - Er det så et problem at vi bruger Java? - Det ser ikke umiddelbart ud som om, at pakken java.lang.reflect er en del af lejos-API'en.Hvis vi vil bruge noget lignende reflection, vil det så placere projektets indhold udenfor kurset?
• Produktet kunne ende op i en flok "dumme" NXT'er der starter med køre ind i vægge, men efter et stykke tid, lærer at manøvrere og opfylde nogle mål, gennem distribution af "god" viden, NXT'erne imellem.

Legway / Segway

• Segway projektet ville hardware-mæssigt komme til at minde meget om det projekt vi lavede under øvelserne, en nxt med to motorer, samt en lyssensor.
  
• Selve segway-ideen lægger ikke op til noget specifikt miljø, idet der først og fremmest skal arbejdes på at få en stabil robot. Hvis dette opnåes, kan man dog eksperimentere med at lade robottoen bevæge sig rundt i forskellige miljøer, evt. kunne man kombinere segway-robotten med legovej-findingsprojektet.
• Den største hurdle i forbindelse med et segwayprojekt ville, som under øvelserne, være at få bygget en robot der ved hjælp af en pid-controller og de tilgængelige sensorer, ville være så stabil, at den faktisk kunne anvendes til andet end at stå og rokke frem og tilbage.

Atari's 'Pong' fra 1972 som interaktiv robot legetøj (Interactive Robot Games):

• Der skal bruges 3 NXT'er: En NXT til at repræsentere bolden, og to til ketcherne, henholdsvis den til den menneskelige spiller og til 'ai'-spilleren.
• Miljøet skal være et afgrænset område, omkranset af en barriere til at holde bolden inde. Barrieren kan repræsenteres af fysiske vægge eller kanter, evt. kan de repræsenters ved striber af farve-/nuance-skift på gulvet. Til at hjælpe de to ketcherer i at 'holde kursen', kan der anvendes en skinneanordning, men dette kan give et problem for bolden, hvis den ikke bliver fanget af en ketcheren på vej ud, da bolden ikke nødvendigvis er terrænkørende kan den have svært ved at køre over skinner.
• Til ketcheren, der skal styres menneskeligt, skal der være mulighed for kommunikation, f.eks. via bluetooth til en laptop eller mobiltelefon.
• Om det er tilstrækkeligt med to lyssensorer til ai-ketcheren og en tilsvarende lysafgiver på bolden, for at ai-ketcheren kan placere sig korrekt i forhold til bolden, kræver lidt eksperimentation. En anden mulighed kan evt. være et kamera (NXTCam) på ai-ketcheren.
• Hvis der anvendes fysiske barriere til at holde bolden inde, kræver det et antal (evt. parallelt forbundne) touchsensorer. En anden mulighed er, hvis der bruges et andet farvet underlag til at afgrænse banen, kan der bruges lyssensore på bolden, men så opstår der måske problemer med at mærke om en bold bliver fanget af ketcheren.
• I teorien er det nok med én motor per ketcher, idet Ketcherne kun skal køre på en akse. Bolden er nødt til at have to motorer, da den skal køre i flere forskellige vinkler. Til at korrigere NXT-boldens kørende vinkel kan der bruges en CompassSensor.
• Det sværeste vil formentlig være at finde en god måde hvorpå 'ai'-ketcheren skal genkende positionen af 'bold'-robotten. Enten via lyssensor eller kamera.
• Fremvisningen af dette projekt er ligefrem, et interaktivt Pong-spil, med tre robotter, hvoraf den ener - en ketcher - kan styres af en menneskelig spiller, via piletaster på en laptop, mobiltelefon eller en remote.

Valg af end-course-project, og argumentation herfor:
Den autonome navigations robot vil helt sikkert være et spændende projekt, både interesant og lærerigt, men vi ville gerne finde et projekt der også kunne være interaktivt, i form af f.eks. spil.
Vi er en smule tilbageholdende overfor projektet med robotgener, grundene herfor er nævnt i afsnittet der beskriver dette ovenfor.
Valget af slutprojektet er således faldet på computer spillet fra Atari, Pong, som vi vil forsøge at lave i robotform.

A more detailed description
Dette afsnit skal udfyldes efter samtale med Caprani.

A plan for your work with the end course project
Dette afsnit skal udfyldes efter samtale med Caprani.

Uge 11; 'Behavior and Arbitrator'

Deltagere:
Morten, Lars og Thomas.

Goal:
At undersøge opførsel-baseret arkitektur, implementeret ved hjælp af klasserne lejos.subsumption.Behavior og lejos.subsumption.Arbitrator.
Samt at lave en alternativ implementation af Arbitrator-klassen.

Plan:
(1) Uploade samples/BumberCar/BumberCar.java til NXT-robotten.
(2) Indse at hvis en Behavior's takeControl metode returnerer sand, efter denne lige har kørt, får den ikke lov igen før en anden behavior har kørt.
(3) Undersøge om takeControl i klassen DriveForward kaldes, hvis den overliggende HitWall er aktiv.
(4) Implementere en tredie Behavior Exit, der reagerer ved tryk på ESCAPE-knappen ved kald af System.exit(0). Exit skal have højeste prioritet.
(5) Undersøg hvad der sker ved tryk på ESCAPE samme tid med at HitWall er aktiveret.
(6) Undersøge om det er muligt, for HitWall-behavioren fortsat at kontrollere motorerne efter suppress metoden er kaldt fra Arbitrator.
(7) Implementere en fjerde Behavior PlaySound, der reagerer ved tryk på ENTER knappen og afspiller en lyd. PlaySound skal indsættes i prioritetsarrayet mellem DriveForward og HitWall.
(8) Forklare hvad der sker når robotten kører og Hitwall aktiveres, hvorefter PlaySound aktiveres mens Hitwall stadig er aktiv (og dernæst escape-behavioren).
(9) Implementere en alternativ Arbitrator, hvor takeControl kaldes for alle Behaviors hver gang løkken gennemløbes. Undersøg betydningen af at metoder kan lave busy-wait og dets indflydelse på action metoden.

Activities:

(1)
Overførslen af BumperCar.java til NXT'en gik uden problemer som forventet.

(2)
Ved udførsel af programmet observeres den forventede opførsel, således at robotten stopper helt når tryksensoren holdes inde. Efter at have studeret kildekoden til Arbitrator, er det klart at en behavior maksimalt må udføres en gang i træk(det står endda kommenteret i koden), derudover er koden struktureret således at en behavior med højere prioritet stadig suppresser andre behaviors selvom den ikke selv er i stand til at køre.

(3)
Ved at studere Arbitratorkoden ser vi, at det kun er muligt for en behavior der ligger over den nuværende, at preempte en allerede kørende behavior. Derfor vil den lavere liggende behavior aldrig blive udført, dette betyder dog ikke at den lavere rangerende behaviors takeControl() metode ikke bliver kaldt, behavioren bliver blot sat til at vente, indtil den overliggende er færdig med at køre.

(4)
Implementationen af escape-behavioren, kan findes her. I al sin simpelhed fungerer den ved at returnere sandt i takeControl, såfremt escape-knappen er trykket ned, hvor efter action-metoden afslutter hele programmet. Exiteren fungerer som ventet, når den indsættes sidst i behavior-arrayet.

(5)
Som ventet ser vi, at programmet terminerer ved tryk på escape-knappen, dette skyldes naturligvis, at den højere liggende behavior bliver injectet i actionthreaden uden at vente på, at denne afslutter den igangværende opgave.

(6)
Det viser sig, at det er muligt for Hitwall-behavioren at bevare kontrollen over motorerne i et forventet kort tidsrum efter suppress metoden er kaldt. Dette kan lade sig gøre, hvis der sker et trådskift lige efter suppress-metoden er kaldt, så vil actionthreaden nå at udføre action metoden, før der igen skiftes så suppress-metoden bliver fuldført.

(7)
Sound-behavioren er implementeret således, den minder meget om exit-behavioren, blot aktiveres den ved en anden knap og i stedet for at lukke programmet spiller den en lille melodi. Efter indsættelsen af sounder-behavioren, ser vores behaviorhieraki således ud:

DriveForward > PlaySound > HitWall > Exit

(8)
Dette eksperiment udførtes ved at starte robotten, aktivere tryk-sensoren og derefter, mens hitwall-behavioren er aktiv, aktivere sounder-behavioren. Vi havde forventet at sounder-behavioren ville overtage når den overliggende hitwall var færdig med at køre, dette var dog ikke tilfældet, istedet begyndte robotten blot at køre lige ud igen. Efter at have gransket koden igen, viser det sig at sounder-behavioren aldrig kommer i kø, da den lavest prioriterede behavior(DriveForward), som altid ønsker at køre, nærmest ikke kan undgå at komme først i køen(med mindre man er endog meget hurtig på knappen) og når der allerede er en behavior i kø ignoreres alle de andres ønske om at køre.

(9)
Her findes implementationen af vores egen abitrator, OurArbitrator.java. Til forskel fra den oprindelige klasse, sikrer vi os at hver behavior får tid til at køre i hvert gennemløb af arbitratorens løkke. Hver behavior startes i en ny tråd, som nedlægges når behaviorens har udført sin handling eller den interruptes af en højere prioriteret behavior, dette står i kontrast til den oprindelige arbitrator hvor den valgte behavior injectes i den allerede kørende tråd. I vores implementation er det hver behaviors ansvar holde øje med hvor vidt den er blevet interrupted. Vores arbitrator giver mulighed for at gentage en behavior lige så mange gange det skulle være nødvendigt og hvis der er tale om en gentagelse hvor den sidste udførelse ikke er færdig, så vil den gamle tråd fortsætte sin udførsel, således opnår vi, at en behavior ikke resettes unødigt.

Conclusion:
Meningen med denne uges labøvelser, var bl.a. at undersøge Arbitrator klassen i lejos.subsumption pakken.
Igennem arbejdet med de opsatte punkter for labøvelsen, fik vi et indtryk af en ikke helt gennemtænkt / veldesignet 'Behaviour-based-architecture'.
Umiddelbart er det ikke oplagt hvorledes pakken skal bruges, dvs. hvis man ikke har lavet ovenstående øvelser eller selv skrevet koden, kan man nemt misse den initielle idé med hvordan koden skal anvendes, dvs. komme til at misforstå intentionen og derved misbruge koden.
Gennem de noget ledende spørgsmål, her ovenfor, viser lejos.subsuption.Arbitrator sig at blive mindre og mindre smuk.

Et delmål for ugens labøvese var også at konstruere en alternativ Arbitrator. Vi mener vi er kommet frem til noget der i det mindste er lidt bedre end den oprindelige. Metoden takeControl kaldes nu for all Behaviour i hvert gennemløb af Arbitrator løkken.
Et trick-spørgsmål var, om der er situationer hvor en lavere prioriteret Behavior ikke bliver suppressed af interrupt mekanismen. Svaret hertil er ja, idet det nu er Behaviour'erne selv der får ansvaret for at tjekke om de er interrupted.
Metoden takeControl i HitWall klassen er nu sat til at returnere den boolske værdi fra touchsensoren OR'et med en boolsk variabel 'working'. 'working' sættes til true som første statement i action metoden, og sættes til false igen som sidste statement i action metoden. I tilfælde af HitWall-Behaviour'en interruptes catches denne og 'working' sættes til false.

Angående returnering af motivationsværdier:
Så nåede vi ikke at eksperimentere med dette. Ideen er dog at i stedet for en absolut boolsk værdi. På f.eks. HitWalls action kunne man subtract'e en factor fra motivationsvariablen, indtil denne bliver nul, og sætte variablen til en maksimal værdi hver gang touch aktiveres.
En Behaviour som DriveForward kan sættes til altid at returnere en "næsten" maks værdi. Den må ikke være den maksimale værdi for en motivation fordi den ligger nederst i hierakiet, og der skal være plads til at højereprioritets behaviour, der meget gerne vil til, for lov at køre istedet.

Uge 10; 'Navigation'

Deltagere:
Morten, Lars og Thomas.


Goal:
Teste præcision af TachoNavigator alene, senere sammenligne med CompassNavigator.


Plan:
(1) Måle og estimere hjul-diameteren.
(2) Måle og estimere afstanden mellem hjulene.
(3) Teste præcisionen af robotten når TachoNavigator klassen anvendes.
(4) Gøre det muligt at nå et mål (tænkt som et punkt i et kartesisk koordinatsystem) selvom der korrigeres ved at at køre udenom evt. fundne forhindringer.


Activities:
Vi gennemførte i første omgang alle test ved brug af lego konstruktionen fra sidste uge, ie. den med bælter (a). Herefter lavede vi de samme test ved brug af en robot med hjul. Her brugte vi kontruktionen, beskrevet i Brian Bagnall's 'Maximum Lego NXTBuilding Robots with Java Brains' kapitel 12 (b).

(1a) Fordi vi havde brugt udveksling med forskellig størrelse tandhjul, til overførsel af kraft fra motor til bælter, var vi nødt til at eksperimentere med forskellige konstanter for 'hjul-diameteren'.
Vi indsatte en værdi for konstanten i konstruktøren til TachoNavigator, og udførte så et program, der fik robotten til, først at køre 60 enheder frem, derefter 60 enheder baglæns dette blev udført to gange. Hvorefter den aktuelle afstand til startstedet blev opmålt.
Det viste sig, at det ikke var muligt at finde en konstant således at robotten aldrig kørte længere end 60 cm og stadig endte ved nulpunktet efter 2 gange frem og tilbage.

Herefter udførte vi testen således at robotten kørte fremad en gang og stoppede. Dette gentog vi, indtil der blev fundet en aktuel konstant, der svarede til 60 cm bevægelse.

Eksperimenterne kan ses i skemaet herunder hjul-diameter-konstanst (hdk) vs. aktuel-kørsels-afstand-i-cm (cm) :

hjk	6.3F	5.6F	5.1F	4.8F
cm	44	53	57	60

Konstanten for 'hjuldiameteren' blev, som det kan aflæses, sat til 4.8F for bælter (Aktivitetstid ca. 35 min).

(2a, 3a) Om pivot-konstanten, ie. afstanden mellem bælterne.
Vi målte afstanden mellem bælterne til 10 cm., indsatte værdien 10.0F som konstant og lod robotten køre i en timeglas-form.
Det viste sig dog at robotten ved denne værdi underkompenserede, den virtuelle afstand var for lille i forhold til den reelle afstand. Det resulterede i at robotten ikke drejede nok rundt når den roterede.
Konstanten eksperimenterede vi os frem til, ved at indsætte forskellige værdier for 'hjul-afstanden' i konstruktøren til TachoNavigator klassen og lade robotten køre ruten, beskrevet i Brian Bagnall's 'Maximum Lego NXTBuilding Robots with Java Brains' kapitel 12.
En skitse for kørslen kan ses herunder :

Den endelige værdi for hjulafstand konstanten blev sat til 12.35F (Aktivitetstid ca. 70 min).


(1b) I første omgang brugte vi det mål der står på siden af hjulet som konstant for hjul-diameteren.
Vi eksperimenterede igen med fremad / baglæns kørsel alene flere gange - Og forsøgte at ende op det samme sted. Vi oplevede igen den samme mangel på præcision ved gentagen kørsel frem og tilbage, og resignerede derfor igen til kun at køre frem en enkelt gang og så aflæse værdien. Konstanten blev til sidst bestemt til 5.6F enheder (Aktivitetstid ca. 35 min).

(2b, 3b) Igen eksperimenterede vi med rotation på stedet ( som beskrevet i 2a og 3a), og at køre en rute med samme slutpunkt som startpunkt, for at kunne approksimere konstanten.
Igennem observationer af flere udførsler på denne test, så det ud som om robotten havde en tendens til at dreje en smule mod venstre, altså når meningen var at den skulle køre ligeud. En værdi på 16.0F enheder for hjulafstanden gav en fornuftig opførsel (Aktivitetstid ca. 45 min).

(4) 4. punkt var at kode en opførsel der muliggør at komme fra punkt A til punkt B og samtidig køre uden om evt. forhindringer.
Vi lavede en wrapper klasse Avoider, der tager en TachoNavigator som argument i konstruktøren. Wrapperen har en public metode goTo der tager to argumenter, - et X og Y koordinat. Koordinaterne bruges argumenter i et kald til TachoNavigator objectets goTo metode der samtidig sættes til at returnere umiddelbart. Herefter spørges TachoNavigator (TN) om vi kører ved vedvarende kald til isMoving, under disse vedvarende kald, bruges en UltrasonicSensor til at måle afstanden foran robotten, - hvis afstanden bliver målt til at være under 20 cm, kalder vi stop på TN og udfører en undvigelses manøvre ved at bakke 20 og dreje 90 grader. Hvis der ikke er forhindringer foran nu, kører vi max 40 cm frem og genoptager søgning mod de oprindelige koordinater. Hvis der efter det forrige drej på 90 grader stadig er forhindringer ( måske lige foran, afstand nul ) bakker vi max 20 cm. Hvis der ikke er forhindringer foran nu, genoptager vi søgning mod de oprindelige koordinater (Aktivitetstid ca. 125 min).

Conclusion:
Tendensen for venstre søgning under ligeud kørsel kan stamme flere steder fra; lille strøm-niveau, en minimal men alligevel forskellig størrelse på de to hjul, fysisk fejl/forskel i de to motorer eller måske timings/syncroniserings fejl/problemer i selve softwaren. Spørgsmål som flere eksperimenter måske vil kunne give et svar på.
Der skal muligvis fastsættes nye konstanter for hjul-afstanden, idet vi måske er kommet til at indlemme den evt. error for venstre søgning i denne konstant, fordi vi testede med Bagnalls rute, der kun laver venstre rotationer og ikke både højre og venstre rotation. En test hvor vi anvender en spejling af den brugte rute, kunne svare på dette spørgsmål.
Vi mangler at eksperimentere med CompassNavigator klassen. Intuitionen siger at det må være en smule mere præcis idet det må være muligt at korigere for tendensen til venstre søgning, ved at sammenligne den målte retning med den beregnede.

Uge 9; 'Niveauopdelt styring'

Deltagere:
Morten, Lars og Thomas.


Goal:
I løbet af dagens labsession skal der bygges en LEGO car, der udviser forskellig opførsel i forskellige situationer, ved brug af en lagdelt styring.


Plan:
Sideløbende med de aktiviteter der er foreslået til dagens labsession, testes forskellige LEGO-konstruktioner til slutprojektet, med hensyn til præcision. Vi valgte at beholde den nuværende bæltekonstruktion under denne lab-øvelse, istedet for LEGO konstruktionen på side 28-30 i instruktionsbogen.


For hurtigt at komme igang med at teste, er det valgt at anvende Capranis subsumption implementation SoundCar.java. Denne aggregerer 3 klasser der nedarver fra Behaviour.java, som igen nedarver fra java.lang.Thread. Meningen er at de 3 opførsler kører samtidig, men at opførsler på et højere niveau kan undertrykke eller forhindre lavere liggende opførsel, ie. suppresse dem.

Planen for dagen er som følger:
(1a) I første skridt observeres bilen med kun RandomDrive.java aktiveret.
(1b) I Andet skridt indkommenteres også AvoidFront.java.
(1c) Tredje skridt er at observere bilens opførsel med alle Behaviours aktiveret.

(2) Beskrive hvad det vil sige at en tråds Daemon-flag sættes til true.

(3) Undersøge og forklare hvorledes 'suppressed' bruges til at opnå kontrolleret adgang til motorerne.

(4) Der skal implementeres en yderligere 'Drive towards light'-behaviour i subsumptionmekanismen i SoundCar.java.


Aktivities:
Udover ovenstående punkter, blev der også brugt lidt tid på at lave justeringer af bælterne på NXT'en. og på at montere Sonar-sensoren. (aktivitetstid: ca. 25 min)

(1a)(1b)(1c) forløb som forventet.
I første skridt blev der alene observeret en kørsel i vilkårlig retning, uden at der blev taget højde for forhindringer, Det var således ikke muligt at undgå forhindringer.
I andet skridt tog AvoidFront.java over for RandomDrive.java, såfremt en forhindring blev detekteret. I de fleste tilfælde bemærkede AvoidFront.java de forhindringer robotten mødte,, og overtog styringen, dvs. satte 'suppressed' på den underliggende opførsel 'RandomDrive.java'.
I tredje skridt tog 'PlaySounds.java' over og kaldte stop() på motorene - udførte sin handling og lod de andre tage over igen. (aktivitetstid: ca. 40 min)

(2) At daemon-flaget sættes, betyder at main-metoden ikke skal vente på at tråden afsluttes, at vi ikke skal vente på et "join" eller interrupt'e, men at vi bare kan stoppe uden videre.

(3) 'suppressed' er en boolsk attribut hos en Behaviour, værdien kan sættes af en 'overliggende' Behaviour. Hvis en Behaviour har fået sin suppressvariabel sat til true, er meningen at den ikke må kunne sende kommandoer til Motoren. Dette er implementeret ved at tilføje en if-sætning inden kaldet til moteren. Hvis suppress er sand ignoreres kaldet til motoren.

(4) ToLight.java blev tilføjet i SoundCar.java, den blev indsat i mellem RandomDrive.java og AvoidFront.java. Vi brugte meget af koden fra forrige og tilføjede en lys-grænse på en værdi af 30. Hvis lysmålingen oversteg grænsen på 30, ville ToLight-opførslen tage over og undertrykke RandomDrive. (aktivitetstid: ca. 110 min)


Conclusion:
I gennem dagens labøvelser blev der opnået en indsigt i princippet for fler-laget kontrolsystem.

Det kunne være spændende, at teste skalerbarheden af Brooks koncept sammen med hardwaren i NXT'en.

Brooks' er tænkt til et meget lavere abstraktions niveau end Javas programmerings paradigme. Dette betyder at der enten bliver en meget tæt kobling, hvilket går imod principper for Java, eller også må man implementere en form for scheduleringsklasse - hvorved simpliciteten mistes, hvilket var det Brooks netop ville undgå.