Embedded Systems Lesson 10

Date: 1/5 2014
Duration of Exercise: 3½ time
Group Members Participating: 
Henrik Jørgensen
Michael Schiønning
William Thorsen

Mål

Målet med denne øvelsesgang er at gennemføre øvelserne til denne uges ugeseddel Motivation-Based Behavior Selection in Agents

Plan

Planen for denne uge er:

• Bygge en robot til øvelserne
• Udføre opgaverne på ugesedlen  
• Påbegynde blogindlæg 

Fremgangsmåde

Til  BumperCar-opgaven skulle vi igen arbejde med leJOSs Arbitrator- og Behaviorklasser. Vi havde allerede fra sidste uge påbegyndt basen af robotten og kunne nu nøjes med at påmontere den ultrasoniske sensor og bumperen vha en touch-sensor. Nedenstående ses et billede af vores BumperCar.

Til øvelserne tog vi udgangspunkt i den udleverede BumperCar.java fil og skulle gøre os en række observationer omkring klassen og derved robottens opførsel. Til at starte med kørte vi et "dry" testrun og kunne konstatere at robotten kørte fremad indtil enten den ultrasoniske sensor registrerede en forhindring. Det samme gjaldt touch-sensoren. Al brugt kode kan findes til sidst i rapporten. 

Så snart en af de to sensorer blev aktiveret ville robotten aktivere behavior'en "DetectWall" og  stoppe, bakke og dreje en smule til den ene side før den fortsætter med at køre fremad igen. Vi satte et elastik rundt omkring vores bumper og derved blev DetectWall hele tiden aktiveret og robotten blev altså ved med at bakke og efterfølgende dreje ad nauseum. 

Adfærden Exit, som reagerer på Escape-knappen og kalder System.Exit(0), er implementeret som en klasse efter samme princip som DriveForward og DetectWall. Exit-adfærden er sat til sidst i adfærdslisten og derved får den den højeste prioritet. 

Efterfølgende prøvede vi at teste vores Escape-knap når robotten bevægede sig rundt. Så snart knappen trykkes stoppede programmet øjblikkeligt såfremt DriveForward havde prioritet. Var det tilfældet at DetectWall var under opsejling ville den først færdiggøre sin bakken og korrigering af ruten før robotten stoppede. 

I både DetectWall og DriveForward har vi metoden takeControl der kaldes i Arbitrator. Vi skulle finde ud af om, at DriveForward's takeControl metode også kaldes når vores triggering condition for DetectWall opfyldes. Som det fremgår ud fra kodestykket neden under fra Arbitrator klassen. Her kan vi set at den starter fra den højestre prioritet og checker hvorvidt takeControl() returnerer true. Er det ikke tilfældet checker vi den næsthøjeste prioritet osv. Dvs i vores tilfælde bliver takeControl() i DriveForward ikke kaldet, hvis DetectWalls takeControl() returnerer true. 

             maxPriority = -1; highest = -1;
          for (int i = 0; i < behavior.length; i++)
          {
           int priority = behavior[i].takeControl();
                 if (priority > maxPriority ) 
                 {
                    highest = i;
                    maxPriority = priority;
                 }
          }

Ydermere skulle DetectWall sættes til at bakke i 1 sec før den begyndte at dreje og efterfølgende bevæge sig fremad. Dette kan ses ud fra følgende kodestump 

    Motor.A.backward();
    Motor.C.backward();
    int now = (int)System.currentTimeMillis();
    while (!_suppressed && ((int)System.currentTimeMillis()< now + 1000))

Sumo-robot

Til sumorobotten gik vi ud fra den opgivene kode, hvor vi implementerede flere behaviors for at gøre robotten til en bedre sumorobot. Da vi kom ldit sent i gang med sumo-delen af opgaven (og derved ikke nåede at være med til selve konkurrencen) sad vi til sidst og biksede lidt med en rimelig simpel tilgang til sumorobotten. Derved har vi ikke en video eller et billede af robotten. Den er i bund og grund det samme skelet som vores BumperCar fra første del, tilsat en lyssenor foran og bagved samt et lidt større hjul på vores touch-sensor. 

Først ændrede vi en DetectWall klassen til i stedet for at bakke væk, når bumperen er trykket, så kører vi lige frem i små korte ryk. Denne behavior fik den højeste prioritet da tanken bag var at når bumperen var trykket så ville vi være lige foran en modstander og kunne forhåbentligt brute force modstanderen ud af ringen. 

Denærst monterede vi 2 lyssensorer, henholdsvis foran og bagved. Sensorerne  skulle bruges til at sørge for at vi ikke kørte eller bakker ud af banen . Her løb vi ind i et problem, hvor vi ikke kunne få bilen til at skifte prioritet mellem de klasser som håndterer lyssensoren. Vi tænkte at med samme prioritet 

(return 75;) ville de skifte imellem dem. Fx hvis en lyssensoren bagpå robotten registrerede et skift fra sort til hvid ville den køre frem for ikke at falde ned fra banen og derved tabe. Når den forreste sensor så registrerede et skift kunne den ikke tage prioritet, og visa versa.

Tanken var at vi videre hen måske ville bruge den ultrasoniske sensor  til at scanne efter en modstander. Anden ide var sætten endnu en bumper bagpå og så have bilen kører frem og tilbage, med små turns, indtil den fik et input på en bumper og så kører fuld kraft i den givne retning.

Den brugte kode kan findes her 

Konklusion

I denne uge har vi arbejdet videre med adfærdsbaseret arkitektur, som er implementeret i subsumption API'en af leJOS NXJ. Vi har lært at "motivation values" giver os en hurtigere reaktiong og derved et bedre resultat hvad vores behaviors angår. Dette kan f.eks. ses i forbindelse med, at når vores EXIT behavior aktiveres får vi en øjeblikkelig reaktion.