Lesson 10

Dagens mål

• Undersøge hvordan en opførsels-baseret arkitektur er implementeret i subsumption API'en af leJOS NXJ. Herunder undersøge ved hjælp af BumperCar:
• interfacet lejos.subsumption.Behavior
• klassen lejos.subsumption.Arbitrator
• udvide med en PlaySound behavior
• Eksperimentere med en alternativ implementation af en Arbitrator, hvor suppress ikke bliver brugt
• Overveje brug af Motivations funktioner.

Ombygning af robotten

Vi benyttede standard robotten, monterede en kontakt sensor i port S2 og tilsluttede motorerne til port A og C.

BumperCar
Vi fik BumperCar til at køre på vores ombyggede NXT. Vi observerede at bilen kørte fremad, men når touch sensoren blev aktiveret, bakkede bilen og roterede. Det svarer til de to Behaviors DriveForward og HitWall, hvor HitWall ser ud til at have en højere prioritet end DriveForward. Ved at holde touch sensoren inde observede vi at motorene stopper efter et kort stykke tid og bilen vender tilbage til sin normale opførsel, når knappen slippes.
Dette skyldes at så længe touch sensoren er trykket ind, så vil HitWall behavior'en være den aktive behavior. Så længe HitWall er den aktuelle behavior vil den kun udføre sin 'action' metode en gang.
Vi undersøgte om takeControl i DriveForward bliver kaldt, når HitWall er aktiv, ved at lade takeControl metoden afspille en lyd hver gang den bliver kaldt. Som forventet bliver takeControl i DriveForward aldrig kaldt, når touch sensoren holdes inde.


Implementation af en tredje Behavior "PlaySound".
Den tredje Behavior skal være lignende "PlaySound" fra NXT Programming, Lesson 8. Denne opførsel skal have den højeste prioritet.
Vi implementerede opførslen ved at lave en ny klasse "PlaySound" der implementerer "Behavior". I metoden Action afspilles en lyd, mens der i takeControl tjekkes om tiden summeret med afspilningsintervallet er større end den nuværende tid - er dette sandt returneres false for at give kontrollen videre til en anden opførsel.
I BumperCar.java laves en ny instans af klassen og tilføjes til Behavior array'et som den opførsel med det højeste index, der giver den højeste prioritet.

Der kan opstå et problem under afviklingen af programmet, da supress metoden i HitWall kun stopper motorene, men i Action metoden kaldes sleep på tråden. Hvis supress kaldes, kan tråden fortsætte mens sleep afvikles i Action metoden. Vi har lavet et eksempel, der kan ses i nedenstående video:

Robotten har en Behavior "PlaySound", som afspiller en lyd hvert andet sekund. Når HitWall aktiveres sættes robotten til at køre baglæns og sove i 11 sek. Det resulterer i at HitWall behavior'en kontrollerer motorene selvom "PlaySound" har højere prioritet. For at undgå dette skulle supress metoden sørge for at afbryde 'sleep' på tråden - altså sørge for at Action metoden er helt afsluttet.

Eksperimentere med en alternativ implementation af en Arbitrator

Vi downloadede Arbitrator og tilpassede koden i DriveForward og HitWall jævnfør NXT Programming, Lesson 10. Vi tjekkede at takeControl i begge metoder blev kaldt hver gang i loopet, ved at sætte programmet til at afspille en lyd, når metoden kaldes. Robottens opførsel er den samme som med leJOS NXJ Arbitrator implementation, bortset fra at ved at holde touch sensoren inde bliver den ved med at køre baglæns, hvilket vi også forventede.

For at gentage eksperimenterne med leJOS Arbitratoren ændrede vi Behavior'en "PlaySound" til at virke med den nye Arbitrator. I første omgang så det ud som om det kun har DriveForward der virkede. Efter at have prøvet nogle gange fandt vi ud at HitWall Behavior'en kun kunne aktiveres 3 gange. Derefter virkede det som om kun DriveForward var aktiv... Det samme var tilfældet når kun DriveForward og HitWall var Behaviors i systemet. Vi fandt aldrig fejlen, men "PlaySound" kom til at virke.

Det ser ud som Arbitrator'en kun virker godt med 2 behaviors, når vi tilføjer den tredje opførsel (højest prioritet), tager den ofte over, men ikke altid! Endvidere sker der det, at når DriveForward er aktiv og PlaySound tager over, så kører det ene hjul samtidigt med lyden afspiller.

Motivation Functions

Motivation Networks - A Biological Model for Autonomous Agent Control beskriver hvordan en motivations funktion kan bruges som et alternativ til prioriteter, i stedet for en fast prioritet har man en variabel motivation mellem 0 og 1. Ud fra en række motivations variable bestemmes en opførsel, f.eks. kunne en aktiveret tryk sensor give høj motivation for at udføre behavior'en HitWall. Motivations funktionen giver mulighed for at en behavior kan reaktiveres mens den udføres. F.eks. kan HitWall behavior'en afbrydes, mens den drejer, af en "ny" HitWall behavior med højere prioritet. Dette kan gøres ved at tryk sensoren giver en lav motivations værdi et stykke tid efter den sidst har været aktiveret. Hvis sensoren igen trykkes ind efter det stykke tid vil motivations variablen stige, og handlingen udføres forfra (Dette ville kræve en del ændringer i koden, da motivations variablen skal være knyttet til en bestemt udførelse af action).

Konklusion

Den indbyggede opførsels baserede arkitektur i leJOS er end den vi undersøgte sidst, men der kan stadig opstå problemer som beskrevet ovenfor, men det er problemer man kan programmere sig ud af. Derfor skal man være påpasselig når supress metoden bliver brugt. Det er simpelt at udvide med flere behaviors i forhold til det behavior system vi brugte i sidste uge. Den alternative arbitrator har vi haft mange problemer med. Det ser ud som om den ikke virker helt stabilt med flere end 2 tråde. Da vi kørte med 3 tråde virkede det som om opførselen var mere eller mindre tilfældig. Vi fandt aldrig problemet.