NXT Programming, Lesson 10

Varighed: 3 timer, Deltagere: Mads, Rolf og Janus

Vi vil undersøge hvordan Behaviour og Subsumption API'en i lejos fungerer.

• Først vil vi teste Bumpercar klassen som den findes i lejos samples biblioteket.
• Vi vil også kigge på en alternativ implementation af Arbitrator.
• Til sidst vil vi kigge på Motivation functions.

BumperCar

Bumpercar kører langsomt frem, når bumperen aktiveres bakker bilen lidt tilbage og drejer en anelse til venstre. Herefter kører bilen igen fremad.

Hvis bumperen holdes inde stopper bilen efter den har lavet sin "undvige" manøvre.

For at teste om takeControl metoden i DriveForward bliver kørt, blev metoden udbygget med en counter som tæller op hver gange metoden bliver kørt, og herefter skrevet til LCD'et

public boolean takeControl() {
    count ++;
    
    LCD.clear();
    LCD.drawInt(count, 0, 1);
    LCD.refresh();
    
    return true;
}

Vi implementerede PlaySounds i det nye Behavior framework, og indsatte den i BumperCar som højeste prioritet behavior. Når der som foreskrevet i lesson 8 er gået 10 sekunder stopper bilen, spiller sin musik, og fortsætter så igen.

HitWall metoden kan godt kontrollere motorerne selvom den bliver supressed, netop ved at lave noget kontrol kode i supress().

Efter et par testkørsler har vi fundet ud af at det hele kører i en thread, altså Arbitratoren får ikke kontrollen tilbage før en Behavior har afsluttet sin action() metode. Derfor kan HitWall også blive ved med at kontrollere motorerne selvom den bliver supressed, fx med en while(true) i sin action().

Another Arbitrator

Efter at have rettet i programmet som foreskrevet i opgaven testede vi igen BumperCar. Nu bliver takeControl som forventet kaldt selvom en højere prioritets behavior har "kontrollen".

Den nye interrupt mekanisme virker efter hensigten, fx. hvis bilen er igang med at bakke væk fra muren og det er blevet musik tid, stopper bilen med at bakke og spiller musik istedet!

Motivation Functions

Implementationen af motivations funktionen kunne ske ved at ændre så takeControl returnerer int istedet for boolean. Så kunne 0 indikere at en metode ikke vil tage kontrollen.

public int takeControl() {
    //Drive forward has low priority so return 1
    return 1;
}

Motivations funktionen gør det muligt for en takeControl metode at returnere en højere motivation ved et senere kald. Fx hvis bilen rammer en væg, men er inde i en behavior som ligenu har en højere prioritet, så kan takeControl ved andet kald i HitWall returnere en højere motivation fordi den nu har været "inde" i vægen i længere tid, og derfor på et tidspunkt overstige motivationen af alle andre funktioner. Det er så vigtigt at motivations faktorer igen falder.

Vi har valgt at springe over: How could takeControl be programmed to give high values when touch is pressed and lower values when it is ok to reactivate the action method ? da vi umiddelbart ikke synes at spørgsmålet giver mening. (Hvilket vores instruktor var enig i)

Konklusion

Ummidelbart må konklusionen være at motivations funktioner er det der virker bedst når man arbejder med behaviors, fordi en behavior så kan stige i "prioritet". Altså er man ikke så fastlåst i et prioritets hieraki som man er ved prioritets arrayet. Den Arbritrator som følger med LejOS har klart mangler omkring supression, og afgivelse af kontrollen til behaviors med højre prioritet.