onsdag den 15. december 2010

NXT Programming, lesson 15

Dato: 15/16-12-2010
Varighed: 10 timer
Deltagere: Nick, JC, Allan


Formål:

Vi skal lave koden til mobiltelefonen, så vi kan teste billederne den tager, når robotten bevæger sig. Vi skal arbejde videre med banen, for at sikre at den virker sammen med klodserne og vi skal begynde på koden til den endelig robot, så robotten kan finde vej vha. lyssensorerne. 
Derudover skal ultrasonicsensoren flyttes, da mobiltelefonen er i vejen, når afstanden måles.


Plan:

-Lave et program til mobiltelefonen, der tager billeder
-Teste robotten på banen med en klods
-Arbejde på koden til lyssensorene
-Ultrasonicsensor flyttet og testet


Test af robot med klods


Vi testede vores robot med en klods i kloen på banen.








Som det kan ses på videoen, så kan kloen ikke holde godt nok fast i klodsen på vores bane. Vi har tapet kanterne mellem papirene, men klodsen vælter stadig. Vi besluttede os derfor for at ændre på kloen frem for at ændre på banen. Dette blev gjort ved at tilføje en ekstra klo på hver siden, så den samlede klo nu har et ordenligt greb om klodsen. Videoen kan ses her:






Test af billeder taget fra mobil i bevægelse

Vi lavede et simpelt program til mobiltelefonen, der tog et billede hvert sekund og lavede et program til robotten, der fik den til at snurre om sig selv, hurtigere og hurtigere.
Denne test skulle gerne give os en ide om hvor skarpe billederne er fra robotten i bevægelse og hvilke dele af billedet vi har brug for.
Her under er et par af billederne taget fra mobilen:
Som det kan ses er de meget utydelige og vi kom også frem til at kameraet ikke kunne tage billeder hurtigt nok. Vi skal derfor lave en videostream fremfor enkelte billeder.
Videostream

Video streamen kommer som nævnt fra en Google Nexus One telefon. Det har taget en del timer at få lavet kode til telefonen der kan analysere en livestream hurtigt nok. Planen er at telefonen skal dele billedet ind i en mængde områder og derefter at sende dette til NXT'en. Muligvis vil det kun være nødvendigt at sende en bestemt linje på en pixels brede, som altid vil indeholde klodserne, da kameraet altid er i samme højde. Koden ser ud som følger:

Thread t = new Thread() {
            public void run() {
                while(running) {                
                 if(previewBuffer!=null) { 
                 int[] res = new int[previewBuffer.length];
                 decodeYUV(res, previewBuffer, w, h);
                 Bitmap.createBitmap(w,h,Bitmap.Config.ARGB_8888);
                
                 Bitmap bMap = Bitmap.createBitmap(res, w, h, Config.ARGB_8888);
                 int segments = 12;
                 int width = bMap.getWidth();
             int height = bMap.getHeight();
             for(int i=0; i<width; i++) { //width
             for(int j=0; j<height; j++) { //height
             int color = bMap.getPixel(i, j);
             }
             }
                 }
                }
            }
        };
        t.start();

Den gennemløber indtil videre blot livestreamen og kigger på hver pixels farve.

Næste gang skal vi arbejde videre med dette . 

Ultrasonicsensor:


Vi har flyttet den ultrasoniske sensor fremad på robotten, så den nu kan se henover mobilen. Vi har lavet en simpel adfærd til robotten, når den er ved at støde ind i noget. Koden kan ses her:

package BrickSorter;
import Robot.DistanceSensor;
import Robot.LightSensorNavigator;
import Robot.Movement;
import lejos.nxt.LCD;
import lejos.nxt.Sound;
import lejos.robotics.subsumption.Behavior;
public class DetectWall implements Behavior {
private DistanceSensor ds;
private LightSensorNavigator lsn;
public DetectWall(DistanceSensor distanceSensor, LightSensorNavigator lightSensor)
{
ds = distanceSensor;
lsn = lightSensor;
}
public boolean takeControl()
{
int distance = ds.getDistance();
String sd = "" + distance;
if(distance < 100) sd = "0" + sd;
LCD.drawString("Distance: " + sd, 0, 1);
return distance < 15;
}
public void suppress()
{
//Since  this is highest priority behavior, suppress will never be called.
}
public void action()
{
int left = lsn.getLeft();
int right = lsn.getRight();
if(left > right){
Movement.drive(-40, -40);
Sound.pause(500);
Movement.drive(40, -40);
Sound.pause(500);
}
if(left < right){
Movement.drive(-40, -40);
Sound.pause(500);
Movement.drive(-40, 40);
Sound.pause(500);
}
}
}


Opførelsen tjekker om sensoren giver en værdi under 15. Hvis dette sker, overtager DetectWall og sørger for at robotten bakker væk fra væggen. Robotten tjekker hvilken lyssensor, der har den højeste værdi, så den kan bakke i den rigtige retning og vende sig ned mod afleveringszonerne.
Alt koden kan findes her http://daimi.au.dk/~u052912/Lego/end_course_uge50/


Navigering med lyssensore:




package BrickSorter;

import Robot.Claw;
import Robot.LightSensorNavigator;
import lejos.robotics.subsumption.Behavior;

public class NavigateBack implements Behavior{
 
 private LightSensorNavigator lsn;
 private boolean _suppressed = false;

 public NavigateBack(LightSensorNavigator lsn) {
  this.lsn = lsn;
 }

 @Override
 public void action() {
  int right = lsn.getRight();
  int left = lsn.getLeft();
  
  
 }

 @Override
 public void suppress() {
  _suppressed = true;// standard practice for suppress methods
  
 }

 @Override
 public boolean takeControl() {
  return true;
 }

}


Vi er langsomt begyndt på denne opførelse, men som det kan ses i koden, så er det ikke færdigt. Det vil vi se på næste gang.

Adfærdshierarki: 


Vi har nu to adfærd, DetectWall og NavigateBack, som skal sættes ind i et adfærdshierarki (subsumption achitecture [Dean3]).

Vores nederste adfærd i hierarkiet er NavigateBack som skal søge mod målzonerne, og skal altid tage kontrollen hvis den ikke bliver undertrykt af et af niveauerne over den. I dette tilfælde er det DetectWall, der tjekker om afstandsmåleren giver en værdi under 15, og tager kontrollen hvis dette er tilfældet.

Dette hierarki skal udbygges med flere adfærdsmønstre for at fuldende robotten.

Resultat for denne uge

Vi fik ombygget kloen til at bedre kunne holde på klodsen, så den ikke vælter når den bliver ført rundt på banen.
Vi fik taget billeder med mobiltelefonen fra robotten. Vi skal arbejde videre med androidkoden, da vi skal kunne tage billeder med ca. 100 ms mellemrum.
Vi fik i ultrasonicsensoren til at virke med en opførelse, så robotten nu bakker væk fra vægge, og vender sig mod målzonerne.
Afslutnngsvis begyndte vi på koden til navigering vha. lyssensorene og farverne på banen, men denne del skal vi arbejde mere med.

torsdag den 9. december 2010

NXT Programming, lesson 14

Dato: 09-12-2010
Varighed: 5
Deltagere: Nick, JC


Formål:
Vi skal bygge både robotten og banen færdig. Vi skal derefter teste om robotten opfylder vores fysiske krav og om robotten kan bruge farverne på banen til at orienterer sig. Vi skal yderligere teste om mobiltelefonens billeder er skarpe selv når robotten bevæger sig.


Plan:
-Ombygning af robotten.
-Lime den udprintet bane på en solid plade.
-Teste om mobiltelefonen sidder fast.

-Tjekke skarphed af billeder.
-Teste robottens evne til at finde rundt kun via farverne på banen.


Forventet resultat:
Robotten skal bygges helt færdig, banen limes og er klar til test, teste skarpheden af billederne taget fra robotten og teste lyssensorenes evne til at navigere på banen.



Montering af mobiltelefonen:
Vi byggede en meget simpel struktur til at holde mobiltelefonen. Billederne kan ses her under:




På billeder nr. 3 kan det ses at kameraet sidder i bunden og derved tættest på kløerne. Vi skal nu teste hvad kameraet kan se når kløerne er åbnede og lukkede og om skarpheden af billedet er tilstrækkeligt til vores formål. Vi skal også teste om kameraet sidder ordenligt fast, når robotten bevæger sig hurtigt.



Banen


Vi skar kanterne af de udprintede dele af banen, og limede dem fast på en spånplade. Her er det færdige resultat. 



Vi skal teste om klodsen vælter, når den bliver flyttet hen over limningerne mellem papirene. Hvis dette er tilfældet så vil vi prøve at bruge tape på samlingerne og derved gøre dem mere glatte.

Navigering via lyssensorerne

Vi har lavet et meget simpelt testprogram, som beskrevet sidst, prøver at udligne værdierne mellem de to sensorer. Herunder er resultatet af dette program på den nuværende bane:

 


Med dette simple program er det mulig for robotten at finde vej fra den ene ende af banen. Vi skal nu lave flere opførelser der kan tage over når robotten kommer til farvecirklerne og målzonerne.


Kamerastabilitet


Vi testede om robotten stadig er stabil efter kameraet er blevet monteret og om kameraet sidder ordentligt fast. Dette blev gjort ved at robotten drejede om sig selv, først den ene vej og så den anden, og derefter kørte frem og tilbage hurtigere og hurtigere for at se om den tiltede. Mobilen blev ustabil ved omkring 80% af motorernes ydeevne. Vi skal derfor ikke køre for hurtigt og bremse for hårdt i det endelige projekt.
Video af testen kan ses her:










Udvikling af software til mobiltelefonen

Udviklingen af et stykke software til Google Nexus One telefonen er ikke gået så hurtigt som planlagt, og derfor har vi ikke nået at teste hvordan robottens bevægelser påvirker billedernes skarphed -- dette vil dog blive testet næste gang.
Planen er at telefonen skal virke som en sensor og blot sende data videre til robotten, hvorefter denne forholder sig til disse data og hvordan der skal reageres på disse. Softwaren på telefonen vil virke ved at den måler mængden af farve i billedet og dermed kan den sende denne værdi til robotten som en indikator på hvor tæt den er på en klods. Yderligere skal mobiltelefonen kunne bruges til at estimere hvilken retning en klods befinder i ved at se hvilken side af billedet der er mest af en given farve i.

Resultat for i dag

Der er foretaget en ombygning af robotten, så den kan holde en mobiltelefon. Det er blevet testet at mobilen sidder tilstrækkeligt godt fast, ved en simpel test. Yderligere er banen limet fast og der er foretaget nogle små tests.
Mobiltelefonapplikationen er endnu ikke færdigudviklet og er dermed ikke blevet testet.





onsdag den 8. december 2010

NXT Programming, lesson 13

Dato: 08-12-2010
Varighed: 5
Deltagere: Nick, JC
Formål:
Dagen i dag vil gå med at teste hvorvidt robotten kan benytte banen. Yderligere vil de førnævnte ombygninger af robotten vil blive udført.
Plan:
-Ombygning af robotten.
-Printning af banen.
-Robot test.
Forventet resultat:
Robotten skal bygges færdig, banen printes, robotten testes.
Banen
Den valgte bane er blevet udprintet i A0 format, dvs. 4 gange 4 A4 sider:

Til at sprede billedet ud på flere A4 sider er brugt følgende program: http://www.blockposters.com/. Bemærk banen er ikke limet sammen, dette gøres næste gang.
Robotten:
Som nævnt i tidligere labrapporter, så skulle robottens ændres, da den var bygget efter en model fundet på nettet, der ikke opfyldte vore krav til fulde (se forklaringer af ændringer nedenfor).
Billeder af robotten efter ombygningen:





Trykføleren der var i fronten er fjernet, da vi satser på at kunne bruge mobiltelefonens kamera til at se om der er en brik i kløerne. Holderen til mobilen er ikke bygget endnu, da vi ikke har mobilen. Den bliver hentet senere i dag.
Fangarmene er blevet kortere for at gøre robotten mindre, og derved gøre det muligt at vende på et mindre område.
Lige nu er der fastgjort en lyssensor i den venstre front og en magen til skulle gerne monteres så snart vi får fat  i den ene klods vi mangler. Dette skulle gerne ske i morgen.
Så sammenlagt er robotten blevet kortere, fået to lyssensorer og mangler en mobiltelefon til at kunne "se".

Lyssensor navigation
Lyssensortesten foretages ved hjælp af den ovenfornævnte bane. Først foretages nogle stikprøver for at se om værdierne falder jo tættere robotten er på den grønne eller den røde zone. Det observeres at de to lys sensorer i tilfælde hvor værdierne burde være næsten ens, altid er cirka 5 fra hinanden (normaliseret værdi i procent), hvilket konstateres til at være en sensorunøjagtighed. Denne unøjagtighed løses ved at ligge en konstant på 5 til en af sensorernes værdier, hvilket resulterer i at lyssensorværdierne er ens, eller stort set ens, når robotten er på vej mod den grønne eller røde zone. Det bør bemærkes at værdierne også næsten er ens når man bevæger sig væk fra zonerne, her stiger værdierne dog, men da robotten givere mere kraft til den side der har den højeste målte værdi, vil robotten vende sig mod målzonerne af sig selv.
En endelig test for i dag var hvorvidt det var muligt at lave en simpel algoritme som kan finde frem til zonerne:

if(lightNav.getLeft() < lightNav.getRight()) {
   Car.forward(0, 40);
} else {
   Car.forward(40, 0);
}
Thread.sleep(100);

Denne algoritme kigger blot på hvorvidt venstre lyssensor har en mindre værdi end den højre lys sensor, og giver derefter højre motor 40% kraft mens venstre får 0% kraft, eller omvendt.
Denne simple algoritme løste faktisk opgaven og bevægede sig langsomt mod målzonerne.
Eksperiment med gribeklo:
Vi ville teste om gribekloen kunne gribe fat i de klodser vi forestiller os, der skal bruges i det endelige setup. Vi udvidede klassen Car til at indeholde to nye methoder, openClaw() og closeClaw():

public static void openClaw(){
   if(!clawIsOpen){
      claw.setPower(openingAndClosingPower*c);
      claw.rotate(angle);
      clawIsOpen = true;
   }
}
public static void closeClaw(){
   if(clawIsOpen){
      claw.setPower(openingAndClosingPower*c);
      claw.rotate(-angle);
      clawIsOpen = false;
   }
}

Metoderne sætter hastighed på klo-motoren til 50% og henholdsvis åbner eller lukker, ved at rotere 85 grader den ene eller anden vej.
Der bliver tjekket for om kloen er åben eller lukket i forvejen, for ikke at risikere at vi åbner to gange efter hinanden og derved kan ødelægge robotten.
Video af testen:
Kloen får fat i klodsen og åbner fuldt op igen. 
Vi ville også teste at at kloen kan holde godt nok fast til at robotten kan køre med den og dreje med den uden at klodsen vælter.
Videoer af testen:
På forskellige underlag kan vi risikere at klodsen vælter, og vi bliver derfor nødt til at teste med den endelige bane næste gang, for at være sikker på at selve designet af kloen ikke skal laves om. Vi har dog idéer til ændringer, hvor vi har to "fingre" på den ene siden og kloen kan derfor måske holde bedre på klodsen.
Vi har altså en virkende klo, der dog kan have problemer ved visse underlag, så der skal flere eksperimenter til for at være sikre på at klodsen ikke vælter når robotten drejer.

Resultat for i dag:

Vi fik printet banen ud, modificeret robotten til at bedre kunne opfylde vores krav, lavet test med den nye klo og testet lyssensorene på banen. Vi skal i morgen se på at få monteret mobiltelefonen og testet yderligere på banen med lyssensorerne og lave flere tests med kloen.

torsdag den 2. december 2010

NXT Programming, lesson 12

Dato: 2-12-2010
Varighed: 6
Deltagere: Nick, JC

Formål:
Vi vil i dag lave et design til banen, med gradierende farver, som kan hjælpe robot 1 med at finde vej til afleveringspunkterne. Vi vil også finde et design til robotten, der kan opfylde vores krav til robot 1.

Plan:
Nick vil prøve at tegne banen i tegneprogrammet Gimp. Grundidé for banen kan ses i lesson 11.
JC vil se om han kan finde et design på nettet til en robot, der kan modificeres til vores formål og krav.

Forventet resultat:
Vi forventer at have en tegning af banen klar der kan printes ud og limes på evt et stort stykke pap, så vi har en permanent bane.

Vi forventer også at have en færdig robot, med alle sensorerne vi skal bruge og en mobil som skal virke som "øjne" for robotten.

Robotten:
Vi søgte efter en robot med gribearme og fandt denne.




Den har både lyssensor til at aflæse underlagets farve, ultralydssensor til at undgå objekter, gribearm der burde kunne gribe fat i de klodser vi har forestillet os og tryksensor.


Dog skal denne robot modificeres en del. Vi skal lave plads til en mobiltelefon, så denne kan bruges til at finde klodserne og hvis muligt, bruges til at indikere at vi har en klods tæt nok på til at vi kan lukke armene og derved gøre tryksensoren overflødig. Vi skal have sat en lyssensor mere på så vi kan se forskelle i farve på de to og bruge det til at navigere på banen med. Til sidst vil vi også prøve at gøre gribearmene kortere, så robotten bliver kortere og derved mere mobil.

Billeder af den umodificeret robot:








Banen:
Banen skal konstrueres på en sådan måde at robotten er i stand til ved hjælp af farve sensoren at bestemme om den kører den korrekte retning, når den har fundet en klods. Første forslag til en bane så ud som følger:


Idéen med denne bane er at robotten hele tiden vil bevæge sig mod en lysere eller mørkere farve alt afhængigt af om robotten vil aflevere en grøn eller en rød klods. Banen blev dog droppet grundet tvivl om hvorvidt lyssensoren er god nok til skelne mellem de mange forskellige nuancer.

Den endelige bane bliver den følgende:

Her er der kun en nuance i baggrunden som bliver mørkere og mørkere jo nærmere man er på målzonerne. Yderligere vil robotten kunne benytte to lyssensorer til at kunne køre mere lige ned mod målzonen, da den cirka skal se samme nuance på hver sensor.
Når robotten nærmer sig målzonen vil den møde nogle røde eller grønne cirkler som betyder den begynder at nærme sig målzonen.



Resultat:


Robotten skal modificeres til vores formål og krav. Den er en god basis at arbejde ud fra, men den mangler en del. Dette vil der blive set på i næste labsession.


Banen skal udprintes i de forskellige versioner, og forsøg skal laves på dem, for at finde den der bedst kan opfylde de krav vi har til banen. Banen skal også udprintes i fulde og sættes på noget pap, så vi kan få en permanent bane. Vægge skal måske også indføres så ultrasonicsensoren kan hjælpe med at holde robotten fra kanten af banen.

torsdag den 25. november 2010

NXT Programming, lesson 11

Dato: 25-11-2010
Varighed: 3
Deltagere: Nick, JC

Formål med øvelsen


Formålet med øvelsen er at finde på tre mulige end-course projects og evaluere dem.

Planen for øvelsen


Beskrive hvert muligt projekt på følgende måde:

-Kort beskrivelse
-Hardware-/softwareplatform
-Mulige udfordringer
-Hvad vi vil kunne præsentere til eksamen

Vi vil ud fra disse beskrivelser vælge én af projekterne og uddybe denne med en handlingsplan.

Forventede resultater


Vi vil have en beskrivelse af et end-course project, som vi vil kunne begynde at arbejde ud fra i næste uge.

Parkeringsrobotterne:

Kort beskrivelse:
To robotter skal kunne finde parkering i et simpelt miljø bestående af én vej, med to retninger. De skal kunne parallelparkere også selvom de bliver nødt til at lave tre-punktsvending og kunne indikere til hinanden at de har tænkt sig at tage en bestemt parkeringsplads.

Hardware-/softwareplatform:
To nxt'er udstyret med den samme software. Vi forestiller os at de skal bruge følgende sensorer:

1. Ultralydssensor til at vurdere afstand til andre biler
2. Lyssensor til at kunne følge vejen
3. Lydsensor til at kunne kommunikere med hinanden gennem "dyt"

Mulige udfordringer:

1. At parkere mellem to andre biler, uden at ramme dem og vurdere om robotten har foretaget en ordenlig parkering.
2. At kunne kommunikere gennem "dyt", og vurdere om robotten er i vejen for den anden, eller om det er den anden der tager fejl.

Hvad vi vil kunne præsentere til eksamen:

En bane med mulighed for selv at placere de statisk parkeret biler, og derefter sætte to to nxt-biler ind på banen. De skulle derefter gerne finde en parkeringsplads hver og benytte dem hvis muligt.

Sorteringsrobotterne:

Kort beskrivelse:


Én robot indsamler klodser på et givent areal, og sortere dem i henhold til deres farve, i nogen bestemte områder. En anden robot kan derefter tage klodserne fra disse områder og sortere dem i henhold til deres størrelse. Så fra at have en mængde usorterede klodser spredt på et areal, får vi x antal bunker med brikker sorteret efter farve og størrelse.

Hardware-/softwareplatform:

To nxt'er udstyret med forskelligt software, og en PC med webcam til at hjælpe robotterne med at finde rundt på banen.

Følgende sensore forestiller vi os at bruge:

1. Lyssensor til at finde farven på brikken
2. Tryksensor til at vide om den har fat i en brik
3. Tryksensor for at analysere en briks størrelse
4. Webcam til at overvåge og hjælpe med position
5. Lydsensor til at kunne kommunikere mellem robotterne om der er en klods klar til sortering
6. Ultralydsensor for at undgå kollision med omgivelserne

Mulige udfordringer:

1. At samle en brik op og finde farven på denne
2. Analysere billedet som webcammet giver af banen (brug af tredieparts software)
3. Kommunikere med lyd mellem de to robotter. Alternativt kunne vi bruge bluetooth

Hvad vi vil kunne præsentere til eksamen:

En bane med to halvdele. Den ene halvdel vil tilskuerne kunne sprede en mængde klodser, hvorefter den ene robot vil kunne sorterer dem efter farve, og den anden robot vil derefter kunne sortere dem efter størrelse.

Labyrintrobotterne:

Kort beskrivelse:

En labyrint skal løses af en robot uden global viden omkring dens miljø. En anden robot har til opgave at forsøge at fange robotten som forsøger at løse labyrinten. Robotten som skal fange har global viden via webcam, men bevæger sig dog væsentligt langsommere end robotten som skal løse labyrinten.

Hardware-/softwareplatform:

To nxt'er udstyret med forskelligt software, og en pc med webcam til at hjælpe den ene robot med at fange den anden.

Følgende sensore forestiller vi os at bruge:

1. Ultralydsensor til at navigere i labyrinten
2. Tryksensor til at indikere om robotten er fanget
3. Webcam til at give global viden til den ene robot
4. Lyssensor til at se at man er i mål

Mulige udfordringer:

1. At finde vej i labyrinten og løse den
2. At skabe en intelligent fjende, der forudser løserens næste træk og agere der efter

Hvad vi vil kunne præsentere til eksamen:

En labyrint med der tilhørende to robotter, hvor den ene kan finde i mål, mens den anden måske kan fange den. Variable labyrint eller hanstighed på den to robotter kunne være muligt for tilskueren at ændre på.

End-course projekt:


Sorteringsrobotterne:


Efter samtale med Ole Caprani, blev vi enige om at gå videre med sorteringsrobotterne, da det ikke er indskræntet af for faste rammer. Vi vil kunne udvide med nye ideer, som ikke er bundet af et bestemt scenarie.
Vi ønsker at undgå brug af global viden, dvs. et webcam placeret over banen. Dette skyldes at det er mere interessant at benytte robotternes lokale viden, da dette tillader indførsel af flere robotter.

Til at starte med vil fokus ligge på banen og farvelægning af denne. Banen vil indtil videre være som følger:




















Robot 1 skal samle rød/grønne brikker sammen i de rød/grønne zoner. Bølgerne ud for hver zone repræsentere to farver, hvormed robotten kan navigere hen til zonen.
Robot 2 begynder først at sortere klodserne efter størrelse når robot 1 angiver at der er en klods klar, enten via bluetooth eller lyd.

Plan:


Uger:
48: Banen og robotkonstruktion
49: Robot 1's software del og mobiltlf. som webcam
50: Robot 1's software del og mobiltlf. som webcam
51: Robot 2's software del
52: Robot 2's software del
1: Test
2: Presentation
3: Aflevering af lab rapporter

torsdag den 18. november 2010

NXT Programming, lesson 10

Dato: 18-11-2010
Varighed: 3
Deltagere: Nick, JC og Allan

Formål med øvelsen
Dagens øvelse går ud på at undersøge behavior-based architectures i Lejos API'en i form af den implementerede subsumption arkitektur i lejos.subsumption.

Planen for øvelsen
Planen for i dag er følgende:
  • BumperCar projektet i "samples/BumperCar" skal kunne køres på en NXT robot.
  • Eksperimenter med BumperCar, som beskrevet i øvelsesbeskrivelsen:
  1. Press the touch sensor and keep it pressed. What happends ? Explain.
  2. 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.
  3. 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. Is the Exit behavior activated immediately ? What if the parameter to Sound.pause(20) is changed to 2000 ? Explain.
  4. 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.
  5. Try to implement the behavior DetectWall so the actions taken also involve to move backwards for 1 sec before turning.
  6. 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.
  • Når BumperCar har fundet en væg, hvad sker der hvis man trykker på sensoren mens den er ved at dreje? Hvordan kan Thiemo Krink's motivations funktioner bruges til at gøre reaktivering muligt?
Forventede resultater
At opnå viden omkring Lejos implementation af en subsumption arkitektur, som i det hele taget minder mere om Fred Martins reaktive arkitektur end en decideret subsumption arkitektur, da Lejos implementationen kun kører en opførsel ad gangen.

Eksperiementer med BumpCar:



  1. Touch sensor
    Når man trykker på touch sensoren, begynder bilen at bakke i ca. et sekund og derefter kører den fremad igen. Hvis knappen holdes inde bakker den, efterfulgt af en kort pause og bakker derefter igen. Dette skyldes at Arbitratoren kører listen af behaviors igennem, før den vælger at bakke ligesom reactive control arkitektur[Martin] og den laver en lille pause for at lave en lydprøve som ultrasonic sensoren kan tjekke for. Dette giver den lille pause mellem de to gange den bakker.
  2. takeControl i DriveForward
    takeControl() bliver aldrig kaldt i DriveForward, da der bliver kaldt break på for-loopen, når den finder den behavior med højst prioritet der skal udføres.
  3. Exit on escape button implementeres som et nyt behaviour på følgende måde:
    class Kill implements Behavior{public Kill(){}public boolean takeControl(){return Button.ESCAPE.isPressed();}public void suppress(){//Since  this is highest priority behavior, suppress will never be called.}public void action(){System.exit(0);}}
    Yderligere tilføjes behaviouren til Arbitratoren:
    Behavior b3 = new Kill();Behavior[] behaviorList = {b1, b2, b3}; //b3 has the highest priority
  4. For at undgå noget af pausen i takeControl i DetectWall opførslen har vi implementeret en lokal tråd som opdatere en felt variabel hvert 20 millisekund som naturligvis bruges i takeControl metoden:
    private int distance = Integer.MAX_VALUE;public DetectWall(){touch = new TouchSensor(SensorPort.S1);sonar = new UltrasonicSensor(SensorPort.S3);new Thread(new Runnable() {public void run() {while (true) {sonar.ping();Sound.pause(20);distance = sonar.getDistance();LCD.drawString(""+distance, 0, 2);}}}).start();}

  5. DetectWall klassens action() metode modificeres ved at indsætte følgende øverst:
    Motor.A.setPower(100);Motor.A.backward();Motor.C.setPower(100);Motor.C.backward();Sound.pause(1000);


  6. Håndtering af interrupt mens DetectWall kører
    Hvis det skal være muligt at genstarte DetectWall's action, foreslår vi at lave en while-loop, der udfører selve handlingen i små skridt, mens den tjekker for en boolean felt variable, som berøringssensoren kan ændre. Hvis denne variable ændres, starter while-loopen forfra.
Motivational Functions

Som beskrevet i, [Krink], anvendes motivationsfunktioner til at bestemme hvor højt en autonomt styret enhed ønsker at udføre en given handling. Autonomt styrede enheder skal her ses som et bredt begreb, som fx. omfatter spurve, rotter, visse former for robotter mm.

Forskellen mellem LejOSs adfærdsbaserede tilgang til autonome systemer og Krinks motivationsfunktioner, er at LejOSs adfærdsmønstre (Behaviors) er inddelt i en hakkeorden hvor hvert mønster har sin plads i prioritetsrækkefølgen, mens Krinks motivationsfunktioner giver hvert adfærdsmønster mulighed for at differentiere i hvor høj grad det ønsker at blive udført. Det betyder altså at ved motivationsfunktioner beregnes en motivationsgrad som er angivende for hvilket adfærdsmønster enheden udfører – højeste motivationsgrad bliver udført.

LejOSs hakkeorden er styret ud fra en prioriteret liste af adfærdsmønstre som løbende løbes igennem for at se om et højereprioriteret mønster skal udføres i stedet for det aktuelle. Rent praktisk foregår dette ved at spørge hvert mønster i faldende prioritetsorden om det ønsker at blive udført. Når et mønsters takeControl-metode returnerer “true”, at det gerne vil udføres, tjekker skeduleringsmekanismen – Arbitrator, som også er mekanisme der hele tiden tjekker om der skal ændres adfærdsmønster – om mønsteret har højere prioritet end det alleredevalgte mønster. Hvis det har, ændres adfærd og ellers fortsættes som før.

Det er vigtigt at notere sig, at LejOSs skeduleringsmekanisme starter forfra når et mønster gerne vil udføres. Det er måden at sikre at det højest prioriteret mønster bliver opdaget når det gerne vil udføres. Ved motivationsfunktioner findes der ikke en hakkeorden, så derfor skal skeduleringsmekanismen ændres således at alle adfærdsmønstre tjekkes inden der kan skiftes mønster eller fortsættes som før. Det kan gøres ved at tilføje en heltalsfeltvariabel, hvor maximumværdien af et gennemløb af adfærdsmønstrernes takeControl-metode gemmes.

Fra ovenstående er det indlysende at det ikke er nok blot at returnere en boolean som svar på takeControl, men at mønstrernes vekslende motivationsgrad kræver at der kan gives et differentieret svar, fx. en heltalsværdi. Det giver skeduleringsmekanismen mulighed for at identificere adfærdsmønstret med højeste motivationsgrad, og efterfølgende aktiverer dette. Her skal man passe på ikke at efterligne LejOS-modellen – hvor der tjekkes op mod det aktive adfærdsmønsters prioritet for at afgøre om dette skal overtrumfes – for det kan resultere i at et bestemt adfærdsmønster konstant udføres selvom det ikke er nødvendigt (her tænkes på “nød-adfærdsmønstre” hvor der fx. undviges vægge eller flygtes fra rovdyr). Dette begrundes med at nød-adfærdsmønstrene skal udføres hvis enheden kommer i farlige situationer, og som følge deraf bliver motivationsgrader meget høj – dog kun i kort tid.

Derfor bør der, for hvert gennemløb, findes en maximumværdi som diktatorisk vælges til udføre sin handling. Her følger en liste over de ændringer vi mener er passende for at implementere motivationsfunktioner:

  • tilføj en heltalsfeltvariabel til opbevaring af maximum motivationsgrad

  • fjern tjekket hvor det aktive adfærdsmønster bliver vurderet ift. det mønster som ønsker at blive udført

  • for hvert adfærdsmønster opstilles en matematisk formel som beregner motivationsgraden. Denne værdi returnes.

  • lad hvert gennemløb i Arbitrator finde maximum motivationsgrad, og efterfølgende aktivere denne