Lab 10

Dato: 18/11 - 2010

Varighed: 14 - 16
Medvirkende: Morten Rasmussen, Kenneth Sejdenfaden Bøgh, Morten Nikolaj Pløger.

Mål:

http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson10.dir/Lesson.html

  I dag skal vi eksperimentere med behaviour robotter, der skifter opførsel baseret på en prioriteringsliste af Behaviour objekter. 

Plan:

  Opgaven i dag er beskrevet i punktform, så derfor tager vi simpelthen et punkt af gangen og skriver en beskrivelse af hvad vi oplevede og fik ud af opgaven. 

Robottens konstruktion:

Standard 9797 Lego robot med tryk- og sonicsensor tilføjet.


Udførsel:


First, make BumperCar run on an NXT:

 BumperCar er et eksempel på et stykke kode der anvender LejOS' Behaviour API [1]. Programmet beskrives til at lade robotten køre fremad som laveste prioritet, og som højeste prioitet undvige, altså bakke og dreje lidt, hvis enten dens tryk- eller sonicsensor 'ser' noget.
  Programmet opfører sig fuldstændig som forventet og det ses tydeligt, hvad enten vi rammer tryksensoren eller sætter hånden foran sonicsensoren, at den behaviour der er ansvarlig for at undvige (DetectWall) overtager kontrollen.

Press the touch sensor and keep it pressed. What happends ?:

 Der sker det, at robotten hele tiden udfører DetectWall, hvilket vil sige at robotten først bakker en smule og stopper. Den anden behaviour, DriveForward, får aldrig lov til at tage kontrollen, idet den har laveste prioritet, og inden den når at få en chance for at styre, så har DetectWall allerede kaldt takeControl().

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:

  For at være helt sikre, lavede vi her noget udskrift til skærmen på vores NXT, med en tæller der incrementes for hver gang takeControl() kaldes for de to Behaviours. Med disse udskrift var det tydeligt at DriveForward ikke kalder takeControl(), end ikke hvis DetectWall bliver færdig med sin action og Arbitrator skal finde den næste Behaviour. Dette skyldes nødvendigvis at Arbitratorens liste af Behaviour's gennemløbes bagfra (højeste prioritet først), hvilket giver god mening, idet den første der tilkendegiver at den ønsker kontrollen nødvendigvis også vil have den højeste prioritet, også er der ingen grund til at spørge dem med lavere prioritet.

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.  

Den endeligfe kode: http://daimi.au.dk/~u071354/BumperCar.java

Denne Behavior indsættes som den sidste i listen og vil dermed have den højeste prioritet.

Is the Exit behavior activated immediately ? 


  Vi forventer at der vil være en mindre forsinkelse idet den tidligere acition skal være færdig før Exit kan få lov at overtage kontrollen.

  Nej, den kan ikke aktiveres før den nuværende behaviour er færdig med at udføre sin action.

  Den måde at gennemløbe Behaviours og lade dem kalde deres action, udelukker muligheden for at lade en højere prioritet overtage kontrollen midt i en anden Behaviours action. 

What if the parameter to Sound.pause(20) is changed to 2000 ?

  Så vil det tage 1980ms længere inden programmet terminerer. 

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:

   Vi lavede en tråd der som beskrevet ovenfor med en enkel variabel der husker den sidste måling.
  Denne ændring fjernede fuldstændig den lille pause der var for takeControl metoden tilhørende DetectWall.

Try to implement the behavior DetectWall so the actions taken also involve to move backwards for 1 sec before turning. 

  Denne opgave klarede vi ved at tilføje 3 linier i starten af is(suppressed) blokken.

  Motor.A.backward();
  Motor.C.backward();
  Sound.pause(1000);

  Hermed sættes motorene til at køre baglæns og programmets udførsel sættes på pause et enkelt sekund. Efter pausen er gået, vil robotten dreje, og DetectWall's action er slut.

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.

  For at gøre det muligt at afbryde en action, er vores første idé at lægge alt koden fra DetectWall's action ud i sin egen tråd, som så bliver interrupted når tryksensoren rammes.
  Vi havde ikke held med denne løsning, idet vi fik java exception på  NXT'en hver gang vi brugte tryksensoren. Desværre fandt vi ikke ud af hvad vi gjorde forkert, og tiden er ved at løbe fra os så vi stopper her.

 

Referencer:


[1],  behavior-based architecture: http://lejos.sourceforge.net/nxt/nxj/tutorial/Behaviors/BehaviorProgramming.htm