NXT, Programmering, Lesson 7

NXT Programmering, Lesson 7

Tid: 2 timer, Deltagere: Kenneth, Rawad.

Siden sidst:
Intet at bemærke.

Formål:
I session 6 observede vi Braitenberg bilerne 2a og 2b, de havde kun en synlig behavior der kunne ses af en observatør: Enten køre den mod lyset eller væk fra lyset. I denne session er formålet at se hvordan flere synlige behaviors kan implementeres i en enkelt NXT lego bil, med ultralyds sensor monteret.


Plan

1. Konstruktion af robot
2. Observer SoundCar
3. Undersøg SoundCar.java implementationen
4. Undersøg Behavior.java implementationen
5. Tilføj behavior til SoundCar

1. Konstruktion af robot
Vi har brugt NXT base set 9797 manualens side 32-34 som basis for vores robot, og så efterfølgende monteret lys og lyd sensorer cirka som vist på billedet.


2. Observer SoundCar
I denne sektion tester vi SoundCar programmet som leveret af Ole Caprani, den kan findes i zip format her [x]. Vi har ikke undersøgt program koden, før denne undersøgelse blev lavet.

Testen er foretaget på gulvet i legolab.

Ved observation af programmet SoundCar, ser vi at robottens opførsel består af tre forskellige handlinger. Vi har identificeret tre hoved handlinger udfra robottens handlinger og LCD displayet hhv. “Drive”, “avoid” samt ”play”.
Drive tror vi består af tilfældig fremad kørsel i tilfældig længder, hastigheder og retning.
Avoid ser ud til at bestå af detektion af objekter via ultralydssensoren, hvis et objekt detekters kører robotten tilbage indtil denne ikke detekters og drejer 90 grader.
Play afspiller en melodi der varer cirka 1-4 sekunder, og ser ud til at blive afspillet med et fast interval.

3. Undersøg SoundCar.java implementationen
I denne sektion undersøger vi de tre klasser i programmet fra sektion to, der definere robottens behavior.

RandomDrive, består af en tråd, der implementere tilfældig kørsel ved brug af Math.random().

      suppress();
      
      drawString("f");
      forward((int)(50+50*Math.random()),(int)(50+50*Math.random()));
      delay((int)(100+300*Math.random()));
      
      drawString("s");
      stop();
      delay((int)(1500+1000*Math.random()));
      
      release();

Som det ses udfra koden ovenover beregner motor styrken for begge hjul tilfældigt samt hvor længe de skal køre. Til sidst en tilfældig udregning af hvor lang tid der skal gå før den kører igen.

AvoidFront har ansvaret for at undgå kollision. Tråden starter med at vente på detektering af et objekt før den begynder at suppress andre behaviors. Herefter kører den baglæns og drejer, hvor efter den releaser kontrol igen.
Måden AvoidFront trigger på ses her:
           while ( distance > tooCloseThreshold )
           {
               distance = us.getDistance();
               drawInt(distance);
           }
Når distance bliver større end en given threshold som i dette tilfælde er 20 cm, går avoidFront igang.

PlaySounds har ingen trigger kondition og forsøger at suppress hver 10. sekund. Når denne behavior er aktiv afspilles en sekvens af toner et tilfældigt antal gange. herefter releaser playSounds kontrol.

4. Undersøg Behavior.java implementationen

I Denne sektion af lab session undersøger vi indeholdet af Behavior klassen. De tre ovenstående klasser vi har undersøgt extender alle denne klasse. Behavior klassen er den der håndterer den suppress mekanisme der diskuteres i forrige sektion. Suppression mekanisme håndtere arbitrering af adgang til motorstyring. Suppression udføre dette ved at etablere et prioritets hieraki mellem de tre behavior klasser.

   public synchronized void suppress()
   {
       if ( subsumedBehavior != null )
       {
           subsumedBehavior.suppressCountIncrement();
           subsumedBehavior.suppress();
       }
   }

Kode sekvensen ovenover, udføres hver gang en behavior klasse, suppresser behaviors med lavere prioritet. SubsumedBehavior repræsentere den behavior der ligger lige under suppresseren i prioritet. Dette foregår rekursivt, indtil lavest prioritet behavior er suppressed.

   public void forward(int leftPower, int rightPower)
   {
    if ( ! isSuppressed() ) Car.forward(leftPower, rightPower);
   }

Selve suppression er implementeret ved en if sætning i hver af motorstyrings funktionerne.


   public boolean isSuppressed()
   {
       return suppressCount != 0;
   }

Når suppress counteren er forskellig fra 0, kan den behavior der efterspørger motorstyringen ikke få adgang. Dette er implementeret ved en counter da en behavior kan af flere overliggende behaviors på samme tid. En situation hvor flere behaviors suppresser en underliggende, kan ske i dette program, i situationen hvor robotten forsøger at undgå et objekt og samtidig afspiller lyde.

Grunden til at daemon flaget er sat til true i behavior, skyldes at vi ønsker alle tråde lukker sammen med hoved tråden, når programmet lukkes.

5. Tilføj behavior til SoundCar
I denne sektion vil vi udforske subsumption arkitekturen yderligere ved at implementere vores egen asynchrone behavior modul. Modulet hedder DriveTowardsLight, og forsøger at bevæge robotten mod en lyskilde ved at køre fremad når lyssensor detektere lys over en vis værdi.

Vi har valgt at placere DTL modulet mellem RandomDrive og AvoidFront. Grunden til dette er at vi prioritere at køre mod lyskilde højere end random kørsel, da random kørsel er til udforskning. AvoidFront placeres højere da vi ikke kan nå frem til en lyskilde ved at kollidere med objekter. Vi har valgt at trigger DriveTowardsLight når lyssensoren finder en lyskilde under en vis værdi.

           int lightValue = SensorPort.S2.readRawValue();
           while ( lightValue > tooCloseThreshold )
           {
               lightValue = SensorPort.S2.readRawValue();
               drawInt(lightValue);
           }

Triggeren til DTL ses ovenover og er baseret på samme koncept som AvoidFront.


Status
Vi har nået at være igennem alle 5 punkter i vores plan og har gennem øvelsen opnået forståelse af og erfaring med subsumption arkitektur. Specielt DriveTowardsLight virkede bedre end vores forventninger med subsumption, da integrationen med de andre behaviors ved styring af prioritet var let og tillader mange concurrent behaviors.

Vi har der udover brugt tid på at tænke over hvordan vi vil løse robot konkurrencens udfordringer. Vi har overvejet at anvende et gyroskop til detektion af hældinger og flade platforme til at bestemme hastighed for kørsel..

Referencer
[1], SoundCar: http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson7.dir/SoundCar.java
[2], Ekstra klasser: http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson7.dir/
[3], Behavior klassen, Ole Caprani, http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson7.dir/Behavior.java
[4], DriveTowardsLight: http://dl.dropbox.com/u/2779683/Session7.rar