Varighed: 3
Deltagere: Nick, JC og Allan
Formål med øvelsen
Dagens øvelse går ud på at undersøge behavior-based architectures i Lejos API'en i form af den implementerede subsumption arkitektur i lejos.subsumption.
Planen for øvelsen
Planen for i dag er følgende:
- BumperCar projektet i "samples/BumperCar" skal kunne køres på en NXT robot.
- Eksperimenter med BumperCar, som beskrevet i øvelsesbeskrivelsen:
- Press the touch sensor and keep it pressed. What happends ? Explain.
- Both DriveForward and DetectWall have a method takeControl that are called in the Arbitrator. Investigate the source code for the Arbitrator and figure out if takeControl of DriveForward is called when the triggering condition of DetectWall is true.
- Implement a third behavior, Exit. This behavior should react to the ESCAPE button and call System.Exit(0) if ESCAPE is pressed. Exit should be the highest priority behavior. Try to press ESCAPE both when DriveForward is active and when DetectWall is active. Is the Exit behavior activated immediately ? What if the parameter to Sound.pause(20) is changed to 2000 ? Explain.
- To avoid the pause in the takeControl method of DetectWall a local thread in DetectWall could be implemented that sample the ultrasonic sensor every 20 msec and stores the result in a variable distance accessible to takeControl. Try that. For some behaviors the triggering condition depends on sensors sampled with a constant sample interval. E.g. a behavior that remembers sensor readings e.g. to sum a running average. Therefore, it might be a good idea to have a local thread to do the continous sampling.
- Try to implement the behavior DetectWall so the actions taken also involve to move backwards for 1 sec before turning.
- Try to implement the behavior DetectWall so it can be interrupted and started again e.g. if the touch sensor is pressed again while turning.
- Når BumperCar har fundet en væg, hvad sker der hvis man trykker på sensoren mens den er ved at dreje? Hvordan kan Thiemo Krink's motivations funktioner bruges til at gøre reaktivering muligt?
At opnå viden omkring Lejos implementation af en subsumption arkitektur, som i det hele taget minder mere om Fred Martins reaktive arkitektur end en decideret subsumption arkitektur, da Lejos implementationen kun kører en opførsel ad gangen.
Eksperiementer med BumpCar:
- Touch sensor
Når man trykker på touch sensoren, begynder bilen at bakke i ca. et sekund og derefter kører den fremad igen. Hvis knappen holdes inde bakker den, efterfulgt af en kort pause og bakker derefter igen. Dette skyldes at Arbitratoren kører listen af behaviors igennem, før den vælger at bakke ligesom reactive control arkitektur[Martin] og den laver en lille pause for at lave en lydprøve som ultrasonic sensoren kan tjekke for. Dette giver den lille pause mellem de to gange den bakker. - takeControl i DriveForward
takeControl() bliver aldrig kaldt i DriveForward, da der bliver kaldt break på for-loopen, når den finder den behavior med højst prioritet der skal udføres. - Exit on escape button implementeres som et nyt behaviour på følgende måde:
class Kill implements Behavior{public Kill(){}public boolean takeControl(){return Button.ESCAPE.isPressed();}public void suppress(){//Since this is highest priority behavior, suppress will never be called.}public void action(){System.exit(0);}}Yderligere tilføjes behaviouren til Arbitratoren:Behavior b3 = new Kill();Behavior[] behaviorList = {b1, b2, b3}; //b3 has the highest priority - For at undgå noget af pausen i takeControl i DetectWall opførslen har vi implementeret en lokal tråd som opdatere en felt variabel hvert 20 millisekund som naturligvis bruges i takeControl metoden:
private int distance = Integer.MAX_VALUE;public DetectWall(){touch = new TouchSensor(SensorPort.S1);sonar = new UltrasonicSensor(SensorPort.S3);new Thread(new Runnable() {public void run() {while (true) {sonar.ping();Sound.pause(20);distance = sonar.getDistance();LCD.drawString(""+distance, 0, 2);}}}).start();} - DetectWall klassens action() metode modificeres ved at indsætte følgende øverst:
Motor.A.setPower(100);Motor.A.backward();Motor.C.setPower(100);Motor.C.backward();Sound.pause(1000);
- Håndtering af interrupt mens DetectWall kører
Hvis det skal være muligt at genstarte DetectWall's action, foreslår vi at lave en while-loop, der udfører selve handlingen i små skridt, mens den tjekker for en boolean felt variable, som berøringssensoren kan ændre. Hvis denne variable ændres, starter while-loopen forfra.
Som beskrevet i, [Krink], anvendes motivationsfunktioner til at bestemme hvor højt en autonomt styret enhed ønsker at udføre en given handling. Autonomt styrede enheder skal her ses som et bredt begreb, som fx. omfatter spurve, rotter, visse former for robotter mm.
Forskellen mellem LejOSs adfærdsbaserede tilgang til autonome systemer og Krinks motivationsfunktioner, er at LejOSs adfærdsmønstre (Behaviors) er inddelt i en hakkeorden hvor hvert mønster har sin plads i prioritetsrækkefølgen, mens Krinks motivationsfunktioner giver hvert adfærdsmønster mulighed for at differentiere i hvor høj grad det ønsker at blive udført. Det betyder altså at ved motivationsfunktioner beregnes en motivationsgrad som er angivende for hvilket adfærdsmønster enheden udfører – højeste motivationsgrad bliver udført.
LejOSs hakkeorden er styret ud fra en prioriteret liste af adfærdsmønstre som løbende løbes igennem for at se om et højereprioriteret mønster skal udføres i stedet for det aktuelle. Rent praktisk foregår dette ved at spørge hvert mønster i faldende prioritetsorden om det ønsker at blive udført. Når et mønsters takeControl-metode returnerer “true”, at det gerne vil udføres, tjekker skeduleringsmekanismen – Arbitrator, som også er mekanisme der hele tiden tjekker om der skal ændres adfærdsmønster – om mønsteret har højere prioritet end det alleredevalgte mønster. Hvis det har, ændres adfærd og ellers fortsættes som før.
Det er vigtigt at notere sig, at LejOSs skeduleringsmekanisme starter forfra når et mønster gerne vil udføres. Det er måden at sikre at det højest prioriteret mønster bliver opdaget når det gerne vil udføres. Ved motivationsfunktioner findes der ikke en hakkeorden, så derfor skal skeduleringsmekanismen ændres således at alle adfærdsmønstre tjekkes inden der kan skiftes mønster eller fortsættes som før. Det kan gøres ved at tilføje en heltalsfeltvariabel, hvor maximumværdien af et gennemløb af adfærdsmønstrernes takeControl-metode gemmes.
Fra ovenstående er det indlysende at det ikke er nok blot at returnere en boolean som svar på takeControl, men at mønstrernes vekslende motivationsgrad kræver at der kan gives et differentieret svar, fx. en heltalsværdi. Det giver skeduleringsmekanismen mulighed for at identificere adfærdsmønstret med højeste motivationsgrad, og efterfølgende aktiverer dette. Her skal man passe på ikke at efterligne LejOS-modellen – hvor der tjekkes op mod det aktive adfærdsmønsters prioritet for at afgøre om dette skal overtrumfes – for det kan resultere i at et bestemt adfærdsmønster konstant udføres selvom det ikke er nødvendigt (her tænkes på “nød-adfærdsmønstre” hvor der fx. undviges vægge eller flygtes fra rovdyr). Dette begrundes med at nød-adfærdsmønstrene skal udføres hvis enheden kommer i farlige situationer, og som følge deraf bliver motivationsgrader meget høj – dog kun i kort tid.
Derfor bør der, for hvert gennemløb, findes en maximumværdi som diktatorisk vælges til udføre sin handling. Her følger en liste over de ændringer vi mener er passende for at implementere motivationsfunktioner:
tilføj en heltalsfeltvariabel til opbevaring af maximum motivationsgrad
fjern tjekket hvor det aktive adfærdsmønster bliver vurderet ift. det mønster som ønsker at blive udført
for hvert adfærdsmønster opstilles en matematisk formel som beregner motivationsgraden. Denne værdi returnes.
lad hvert gennemløb i Arbitrator finde maximum motivationsgrad, og efterfølgende aktivere denne
Ingen kommentarer:
Send en kommentar