Dato:
02-05-2013
Varighed:
Fælles lab: 5 timer
Blog: 3 timer
Deltagere:
Steffen Høi
Nikolaj Mols Hansen
Martin Vang
Ulrik Sahl Lystbæk
Nikolaj Mols Hansen
Martin Vang
Ulrik Sahl Lystbæk
Status
Vi har bygget vores LEGO-robot om til en BumperCar, og undersøgt, hvordan en adfærdsbaseret arkitektur er blevet implementeret i subsumption APIet af leJOS NXJ.
Mål
Målet med denne laboratoriesession er at lave opgaverne for "Week 11 - Motivation based behaviour selection in agents"1 og derigennem undersøge hvordan en adfærdsbaseret arkitektur er blevet implementeret i subsumption APIet af leJOS NXJ, særligt interfacet lejos.subsumption.Behavior og klassen lejos.subsumption.Arbitrator. Det er desuden også et mål at se på, hvordan man laver en alternativ implementering af Arbitratoren, samt at udarbejde et blogindlæg for denne laboratoriesession.
Plan
- Løse opgaverne for "Week 11 - Motivation based behaviour selection in agents"1.
- Udarbejdelse af blogindlæg for "Week 11 - Motivation based behaviour selection in agents"1.
Opgaver
BumperCar
I denne opgave skal vi bruge leJOS APIet's Arbitrator og Behavior klasser til at afprøve prioritetsbaserede adfærd. Opgaverne tager udgangspunkt i BumperCar eksemplet fra leJOS's NXT sample-applikationer, og de klasser vi har ændret i er BumperCar.java2 og Arbitrator.java3. Nedenstående billede viser, hvordan vores LEGO-robot ser ud, i forbindelse med, at vi har monteret en touch sensor.- Det der sker, når touch sensoren rammer noget, er at adfærden DetectWall bliver aktiveret, hvilket får robotten til at bakke og dreje en lille smule. Hvis touch sensoren holdes nede, fortsætter denne adfærd, hvilken kan ses på videoen nedenunder:
- Vi har implementeret adfærden Exit, der reagerer på ESCAPE-knappen og kalder System.Exit(0) efter samme princip som DriveForward og DetectWall er lavet. For at give Exit adfærden højeste prioritet, er den sat sidst ind i listen over adfærd, som sendes med til Arbitrator. Desuden har vi tilføjet til DetectWall, at den ikke skal tage kontrol, når den er undertrykt.
- Arbitrator bliver ved med at give DetectWall kontrollen, så længe touch sensoren er trykket ned, eller sonaren er inden for 25 cm. Dette betyder, at DriveForward ikke bliver udført, hvilket medfører at takeControl i DriveForward ikke kaldes.
- I DetectWall har vi tilføjet en tråd, som startes i når DetectWall instantieres. Det eneste tråden gør er at opdatere et globalt felt til sonar distancen ved at foretage en ny måling. Tråden venter 20 ms. mellem målinger. I takeControl bruges det globale felt med sonar distancen.
- For at tilføje handlingen at køre bagud 1 sekund i DetectWall før der drejes, har vi tilføjet et loop inden, som fortsætter, indtil den bliver suppressed, eller der er gået 1 sekund.
- Den måde vi har fået vores robot til at reagere på, under udførslen af DetectWall er ved, at tjekke på om touch sensoren rammer noget, mens handlingen udføres, i DetectWall's action metode. Hvis den rammer noget stopper vi handlingen. Nedenstående video viser hvordan LEGO-robotten opfører sig efter dette.
Motivation Functions
Denne opgave omhandler at implementere en modificeret udgave af vores BumperCar, der er istand til at afbryde handlingen DetectWall med endnu en DetectWall, når robotten er kommet til et bestemt punkt i sin undvigelse af væggen. Med udgangspunkt i Thiemo Krink's motivation functions4, er der i Behavior.java5 ændret på interfacet Behavior, så takeControl returnerer en motivation value. Arbitrator.java6 er implementeret således, at den adfærd med den højeste motivation value bliver aktiveret hver gang ved loopet. I BumperCar.java7 er der ændret på de forskellige adfærd; DriveForward, DirectWall og Exit, så takeControl returnerer motivation values.
Som takeControl er implementeret, er bilen er istand til at afbryde sin egen DetectWall vha. en lavere motivation value, når den er i gang med at udføre undvigelsen. Den værdi, der returneres, afhænger af om DetectWall er aktiv eller ej. Disse detaljer er implementeret i koden, hvor DetectWalls prioritet normal er 100, men kun 50, hvis den allerede er aktiv.
Som takeControl er implementeret, er bilen er istand til at afbryde sin egen DetectWall vha. en lavere motivation value, når den er i gang med at udføre undvigelsen. Den værdi, der returneres, afhænger af om DetectWall er aktiv eller ej. Disse detaljer er implementeret i koden, hvor DetectWalls prioritet normal er 100, men kun 50, hvis den allerede er aktiv.
Konklusion
Denne uge har vi eksperimenteret med den adfærdsbaseret arkitektur, der er blevet implementeret i
subsumption APIet af leJOS NXJ, særligt interfacet
lejos.subsumption.Behavior og klassen lejos.subsumption.Arbitrator. Som et eksempel på et adfærdsbaseret kontrolprogram, har vi arbejdet med BumperCar programmet, der er en del af leJOS NXJ og i forbindelse med dette, har vi bygget vores LEGO-robot om, så den nu har en touch sensor monteret. I den forbindelse har vi kigget på hvordan de to adfærd DriveForward og DetectWall er implementeret og eksperimenteret med funktionerne i Arbitratoren til at kontrollere de forskellige typer adfærd. Vi har desuden kigget på, hvordan man kan reaktivere en sekvens af handlinger med udgangspunkt i motivation functions, som beskrevet af Thiemo Krink.
____________________________________________________________________________________________________________
1. http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson10.dir/Lesson.html
2. https://www.dropbox.com/s/yyxphpzp57tifbn/BumperCar.java
3. https://www.dropbox.com/s/v52to8dudhib7po/Arbitrator.java
4. Thiemo Krink(in prep.). Motivation Networks - A Biological Model for Autonomous Agent Control.
5. http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson10.dir/Behavior.java
6. http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson10.dir/Arbitrator.java
7. http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson10.dir/BumperCar.java

No comments:
Post a Comment