Tilstede:
Mikkel Nielsen
Peter Jessen
Søren Bramer Schmidt
Tid brugt:
5 timer
Mål
Målet med dagens øvelse er at afprøve implementeringen af behavior-based arkitektur i leJOS's subsumption API og prøve de forskellige esperimenter beskrevet på ugeseddel 10.[1]
Plan
Planen er skrevet således, at vi følger opgaveformuleringen for uge 10. [1]
Vi vil:
1. Ombygge robotten til at have relevante sensorer og uploade BumperCar til robotten
2. Gå igennem listen af eksperimenter og rapportere resultaterne.
3. Rette subsumption mekanismen som beskrevet i Motivation Functions afsnittet på ugesedlen.
Resultater
Når touchsensoren bliver trykket ind, bliver DetectWall aktiveret af touch sensoren. Arbitratoren er implementeret således at søgning efter den højest prioriterede behavior starter forfra når der findes en behavior med en aktiv trigger condition. Det betyder at når touch sensoren forbliver aktiveret bliver behaviors med lavere prioritet aldrig kørt.
Implementation af exit-behaviour
Vi tilførte en exit behaviour, på linje med de andre behaviours. Exit behaviouren er givet højeste prioritet i arbitratoren. Vi kan observere, at Exit behavioren bliver aktiveret meget hurtigt. Det kræves dog at escape knappen holdes inde, da det kræver mere end en enkelt observation af tryk, før action delen udføres. Dette blev implementeret således:
class Exit implements Behavior {
public boolean takeControl() {
return Button.ESCAPE.isPressed();
}
public void suppress() {
// højeste lag -> skal aldrig kaldes
}
public void action() {
System.exit(0); // exit program
}
}
Subsumption mekanismen er implementeret i run metoden i Arbitrator klassen. Den fungerer ved at løbe igennem alle behaviors startende med den højst prioriterede. Når den finder en med en triggering condition som er true stoppes gennemløbet.
Da DetectWall har højere prioritet end DriveForward bliver takeControl i DriveForward ikke kaldt når DetectWall trigger.
Ændring af sampling af distance
Vi ændrede indsamlingen af afstandsværdier som beskrevet på ugesedlen[1]. Den nye thread indsamler distancen med et interval på 20 millisekunder. Denne thread er så uafhængig af resten af programmet.Vi testede dette, men kunne ikke se nogen forskel på de to implementationer. De 20 millisekunder er ikke nok til at registrere en forskel.
Vi ændrede DetectWall behavioren således at robotten kører et sekund baglæns før den drejer. Dette gjorde vi ved at indsætte et delay med Thread.sleep.
Vores implementation med thread.sleep() gør det umuligt at interrupte DetectWall behavioren. Vi kan derfor ikke med denne implementation både køre baglæns i et sekund og samtidig er interruptable. De enkelte rotate kommandoer kan gøres interruptable ved at give dem parameteren "True". En bedre implementation er at bruge systemtiden til at måle et sekund ud, og så lade en whileløkke køre i sekundet imens det yielder og ikke er interrupted. Dette er f.eks. tilfældet i koden som er givet til os på ugesedlen[1].
Motivation focus
Vi afprøvede først koden, og kunne observere robotten kører fremad indtil den målte en forhindring foran den, eller til der trykkes på tryksensoren. Når dette skete, blev detectWall behaviouren aktiveret. Dette gjorde at robotten afspillede en lyd, kørte baglæns i et sekund, ventede et sekund, drejede og afspillede en lyd inden den kørte videre fremad.
Vi kunne observere at vi med denne implementation kunne interrupte detectWall, således at action() koden fra behaviouren blev genstartet. Dette ses f.eks. i denne video, hvor man kan høre at detectWall lyden bliver genafspillet igen og igen.
Status
Vi blev færdige med dagens program. Vi nåede det vi havde planlagt at lave. Vi valgte ikke selv at give os i kast med at skrive om på bumperCar koden. Vi havde dog brugt tid på at overveje hvordan det skulle gøres, og vores konklusioner mindede meget om koden fra ugesedlen. Koden fra ugesedlen fixer også et andet problem med arbitratoren som vi havde observeret. Den oprindelige arbitrator reagerede langsomt og derfor kunne f.eks. hurtige tryk på sensoren ikke registreres rigtigt.
Referencer
