Konklusion

Konklusion for projektet

Hvad blev projektet til

Det endelige projekt er 2 robotter der kan skubbe en puk rundt på en
bane. Som sensor til at give position og rotation af robotterne bruges
AR-toolkit, der via bluetooth sender oplysningerne til robotterne. På
robotterne har vi brugt en subsumption arkitektur, for at have en
mekanisme til at kontrollere deres opførsel.

Camera tracking fungerede rigtig fint som en sensor, der leverede
information til robotterne om deres miljø. Og 2 vejs kommunikation
over bluetooth virkede fint, både til at leverer opdateringer til
robotterne om deres koordinater og til at leverer informationer fra
robotterne til vores GUI'en til brug ved debugging.

Problemer i processen/produktet

Vi nåede ikke alle de ting vi gerne ville have haft med i
projektet. Bl.a. nåede vi kun at implementere 4 af vores i alt 7
behaviors.

Vi oplevede en del problemer med at få robottens navigation til at
agere korrekt. Problemerne opstår fordi vores kode består af en masse
tråde der muterer data på kryds og tværs. Således kan man ikke være
sikker på at virkeligheden afspejler det robotten er igang
med. Problemerne kan løses ved at implementere en navigator der netop
tager højde for opdateringer fra flere kilder, af fysiske
positionsoplysninger.

Vi har haft problemer med at debugge vores kode, fordi vi er på et
embedded system. Det var dog en kæmpe hjælp da vi endeligt havde et
stabilt bluetooth subsystem, hvor vi kunne sende en masse forskellige
beskeder igennem. Når man reflekterer over hele kurset, har debugging
og datalogging været en del af alle ugeopgaverne. Set i det perspektiv
ville det være oplagt, at lave det bluetooth subsystem vi
konstruerede, allerede i første uge af kurset.

Fremtids perspektiv

Hvis vi havde haft mere tid, ville vi have implementeret vores egen
navigator, således vi bedre kan bruge de informationer vi får fra
AR-toolkit.

Navigatoren kunne endvidere med fordel bruge stimulans fra en
kompassensor, da et af de store problemer med vores nuværende design
er at robotten overstyrer når den drejer. Det sker fordi, der er
nævneværdig forsinkelse på oplysningerne der kommer fra
AR-toolkit.

Forsinkelsen af dataen kunne man også kompensere for med et moving
average, sammen med aktiv brug af en slags tachonavigering.

Alternativt kunne man sætte et timestamp på dataen fra
AR-toolkit. Ideen er så at robotten med en slags tachonavigator kender
sin fortid. Den kan så lave et opslag i sin fortid, for at finde ud af
hvor den var på det pågældende timestamp, robotten vil så have
mulighed for at korrigere sin nuværende position i forhold til
oplysningerne om, hvor stor afvigelsen var i fortiden.

De data robotten modtager om position og rotation af de andre objekter
er et halvt til et helt sekund forsinkede. På et sekund kan robotten
næsten dreje 90 grader hvis motorerne kører med en hastighed på
100grader pr. sekund. Hvilket er en relativt lav hastighed.

På subsumption siden kunne man forestille sig at skifte over til at
bruge det subsumption framework der er i lejos. Grunden er at vi er
skiftet til lejos 0.7. Efter vi har læst lejos kildekoden for
subsumption frameworket, viser det sig at lejos 0.7 faktisk har et
ganske brugbart subsumption framework.

lab 6

Hvornår: Torsdag d. 22/1
Hvem: Asger, Michael
Varighed: 6 timer

Mål

• Forbedre Drive Towards Ball opførslen

Arbejdsgang

Autonomous behavior model

Vi forsøgte på forskellige måder at forbedre Drive towards ball
opførslen, så den ikke længere ville bruge tid på at køre forvirret
rundt ved siden af bolden (se lab7). Først prøvede vi at tweake
threshold for hvornår agenten skulle skifte mellem at køre ud på siden
af bolden og bag den. Dette hjalp os intet så vi skiftede
strategi. Drive towards ball havde indtil da været en stateless
behavior. Dette var gjort for at agenten bedre kunne følge efter
bolden, hvis den fik at vide fra kameraet at bolden havde flyttet sig,
og havde den utilsigtede bivirkning at robotten kørte forvirret rundt
på siden af bolden.

Vi prøvede nu i stedet at give agenten state. Dette vil sige at når
drive towards ball opførslen startede skulle robotten planlægge hele
sin rute hen til bolden, og følge den indtil den nåede frem eller en
anden opførsel spillede ind. Dette ville betyde at vores robot ikke
ville være nær så fleksibel i forhold til at jagte bolden, men
forhåbentlig blive bedre til at komme hen hvor den mente bolden var og
derfra fortsætte jagten, forhåbentlig tættere på bolden end den startede.

Konklusion

Autonomous behavior model

Vi fik desværre ikke vores state implementation til at virke før
fremlæggelsen, så vi måtte vende tilbage til vores tidligere
implementation.

Vi kan konkluderer at det ikke altid er ligetil at få en agent til at
bevæge sig rundt i et miljø. Vores tilgang til det mht kamera
tracking gør ganske vidst vores robotter alvidende, men alvidende med
en smule forsinkelse, hvilket vi endnu ikke succesfuldt har fået taget
højde for.

---

Den endelige behavior model

De konkrete behaviors nedarver fra en abstract behavior klasse, som så
implementerede de funktioner som var fælles for alle behaviors. Som
eksempler kan nævnes ikke at udfører deres handling når de var
undertrykt eller fortælle andre behaviors at de ikke længere måtte
køre.

Behavior klassen kan ses her:
http://www.daimi.au.dk/~mkm/LEGO/project/src/legodart/nxt/Behavior.java

Som det ses er hver enkelt opførsel en seperat tråd. Dette er gjort
for at opførsler hurtigt kan undertrykke hinanden, uden at skulle
vente på at hinanden.

Behavior klassens run metode er hvor det hele sker. Så længe opførslen
ikke bliver afbrudt, kører opførslens løkke. Løkken tester først om
opførslen skal udføres ved at kigge på om opførslen ikke er undertrykt
af en anden opførsel og dernæst om opførslens aktion giver mening i
robottens miljø. Hvis detter gælder, så fortæller behavioren at den
starter og går i gang med at udføre opførslen.

Vi opdagede senere at det ikke var nok for en opførsel at vide om den
blev undertrykt. Den skulle også kunne se om den var blevet undertrykt
mens den var ved at udfører sin action, eller at den havde mistet
kontrollen så at sige. Dette var nødvendigt da en opførsel kan
undertrykke de lavere opførsler og frigive dem igen, uden at de lavere
opførsler når at teste for dette. Med den boolske variabel
lostControl, ville en tråd få at vide når den mistede kontrollen
midtvejs i sin action og kunne returnerer.

Vi valgte at putte funktioner til at bevæge agenten i behavior, da
disse sørger for at checke om behavioren har mistet kontrollen inden
de flytter agenten. Det gøres så vi ikke behøver skrive testen hver
gang vi vil flytte agenten.

Vi har implementeret følgende behaviors:

Drive towards ball behavior
http://www.daimi.au.dk/~mkm/LEGO/project/src/legodart/nxt/DriveTowardsBall.java

Drive towards ball behavior er agentens øverste behavior. Dens
condition er true, så den altid kan køres og forsøger at manøvrere
agenten bag bolden i forhold til målet. Er agenten foran bolden vil
behavioren forsøge at få agenten ud på siden af bolden, hvorfra den
frit kan køre om bagved bolden.

Face ball behavior
http://www.daimi.au.dk/~mkm/LEGO/project/src/legodart/nxt/FaceBallBehavior.java

Hvis agenten først står placeret således at bolden er mellem den og
målet, sørger denne opførsel for at den vender sig rundt mod bolden og målet.

Dribble behavior
http://www.daimi.au.dk/~mkm/LEGO/project/src/legodart/nxt/Dribble.java

Er bolden mellem agenten og målet og agenten har front mod bolden,
skal agenten bare køre fremad, for at "drible" bolden tættere på mål.

Stop behavior
http://www.daimi.au.dk/~mkm/LEGO/project/src/legodart/nxt/Stopped.java

Stop opførslen er agentens vigtigste "refleks". Hvis nogen fortæller
spilleren at den skal stoppe, undertrykker denne refleks alle andre
opførsler og agenten står stille.



Vi lavede så
følgende arbitrator,
eller behavior manager.

De vigtige metoder er her int attachBehavior(Behavor
b), synchronized void reportStart(int index) og
synchronized void reportFinished(int index)

attachBehavior er den metode hvor en behavior bliver forbundet med
arbitratoren, metoden returnerer behaviorens index. Dette bliver brugt
så behavioren kan undertrykke alle behaviors med et lavere index.

reportStart bliver kaldt af en opførsel hver gang denne kan
køre. Hvis opførslen har et højere index end den eksekverende
opførsel, fortæller arbitratoren den eksekverene at den har mistet
kontrollen og alle underliggende opførsler bliver undertrykt.

reportFinished låser op for alle underliggende opførsler hvis den
kaldes fra den eksekverende opførsel.

Resultater:

Vi vurderer om vores implementation kan kaldes et autonomous system ud
fra om vi lever op til de 6 characteristica opsat i
Modeling
Adaptive Autonomous Agents



1. Task-oriented modules

Vi har i vores implementation opgave baserede moduler. Disse er hvad
vi kalder opførsler eller behaviors, og hver enkelt sørger for at
udføre én opgave når det giver mening indenfor miljøet.

2. Task-Specific Solutions

Vores implementation har opgave specifike løsninger i form af vores
opførsler, der alle selv sørger for at teste om det giver mening at
kører dem i forhold til miljøet.

3. Role of Representations is De-emphasized

Representationen af verdenen omkring vores agent er fremhævet, modset
hvad characteristicaen gerne så. Dette bliver den gjort i vores
SoccerField klasse, hvor alle behaviors kan hente data om hvor andre
spillere og bolden er. Vi valgte denne løsning for at gøre det nemmere
at holde styr på disse oplysninger og at sikre os at alle tråde kunne
få de nyeste oplysninger uden selv at skulle bruge tid på at hente
dem.

Dette skyldes dog så også at vores robotter ikke befinder sig i en så
generel verden som P. Maes agenter, men i stedet indenfor et
spillefelt vi selv opsætter.

4. Decentralized Control Structure

Dette characteristica er opfyldt da alle vores opførsler arbejder
parallelt ved siden af hinaden. Naturligvis har vi en arbitrator til
at holde styr på hvilken opførsel der må køre, men dette er tilladt
under characteristicaen.

5. Goal-directed Activity is an Emergent Property

Vores agents målrettet aktivitet ændres konstant i takt med at nye
opførsler overtager agenten.

6. Role for Learning and Development

Dette characteristica henvender sig til adaptive autonomous
systemer og ikke bare autonomous systemer.
Det var oprindeligt meningen at vi ville have implementeret et
adaptivt system, så vi kunne se vores spillere udvikle sig og blive
bedre. Dette nåede vi dog ikke til, så vi opfylder ikke denne
characteristica.

Konklusion

Vores implementation lever ikke helt op til Maes 6 characteristica men
vi anser stadig implementationen for et autonomous system. Grunden er
at characteristica 6 kun henvender sig til adaptive systems, hvilket
vores ikke er endnu, og characteristica 3 gælder i forhold til
agentens sensor, noget vi ikke har, men i stedet har vi en beskrivelse
af vores model af verden.

lab 5

Hvornår: Onsdag d. 21/1
Hvem: Asger, Peter, Michael
Varighed: 15 timer

Mål

• Lave testopstillingen


• Konstruere behaviors til robotten


• Udvide bluetooth forbindelsen til at kunne sende flere beskedtyper


• Lave 2 vejs bluetooth kommunikation

Arbejdsgang

Testopstilling

I dag konstruerede vi testopstillingen. Til dette brugte vi følgende ting:

• Webcam + lang ledning


• Træpinde


• Tape

Det tag der sidder i hjørnet af banen repræsentere vores nulpunkt,
således at kameraets placering er underordnet.

De tags der sidder på robotterne er placeret så de sidder lige over
hjulaksen, så deres koordinater ændre sig så lidt som muligt når de
rotere om sig selv.

Player abstraktionen

Vi lavede vores abstraktion af en spiller i player klassen.

En spiller skal kende til et SoccerField, så spilleren har mulighed
for at få sin egen position, modstanderens position og boldens
position.

Ud over det bruger vi til spilleren en tachonavigator, som senere blev
udskiftet med vores egen CamTachoNavigator. Dette har vi gjort for at
spilleren løbende kan opdatere sin position mellem opdateringer fra kameraet.

Spilleren skal så initialiserer sine behaviors og disse overtager herfra.

code
http://www.daimi.au.dk/~mkm/LEGO/project/src/legodart/nxt/Player.java
http://www.daimi.au.dk/~mkm/LEGO/project/src/legodart/nxt/SoccerField.java
http://www.daimi.au.dk/~mkm/LEGO/project/src/legodart/nxt/CamTachoNavigator.java

Autonomous behavior model

De første 3 behaviors blev lavet til spillerne. En behavior som får
dem til at løbe om bag ved bolden, en der vender dem mod bolden og en
som får dem til at løbe med bolden mod målet.
Uddybende forklaring på de forskellige behaviors kan findes i lab
reporten for d. 22/1

code

http://www.daimi.au.dk/~mkm/LEGO/project/src/legodart/nxt/DriveTowardsBall.java


http://www.daimi.au.dk/~mkm/LEGO/project/src/legodart/nxt/FaceBallBehavior.java


http://www.daimi.au.dk/~mkm/LEGO/project/src/legodart/nxt/Dribble.java


http://www.daimi.au.dk/~mkm/LEGO/project/src/legodart/nxt/Stopped.java

Problemer

Testopstilling

Vores bold er en del lavere end robotterne, og det er derfor muligt
for dem at skygge for dens tag, når det sker vil positionen af bolden
ikke blive opdateret, og robotterne vil navigere efter forældet
information indtil bolden igen er synlig.

Bluetooth er mildt sagt lidt problematisk på NXT'erne, og det er
begrænset hvor hurtigt vi kan sende ny information til vores
robotter. Derfor arbejder de efter lidt forældet information, hvilket
giver problemer ved bl.a. rotation. I nogle tilfælde, hvor vores robot
skal rotere 180 grader om sig selv, får den forældede informationer,
som siger at den stadig mangler at rotere 180 grader. Dette resultere
i at den konstant drejer rundt om sig selv. Vi har yderligere
undersøgt problemet og fundet ud af at når man bruger goTo metoden i
lejos TachoNagigator, så laver den først et blocking kald til rotate
metoden for dernæst at lave et nonblocking kald til travel metoden,
hvis man velogmærke har bedt den om at lave imediately return. Altså
ligger en del af problematikken også her at man ikke løbende opdateres
med den nyeste rotation.

Sende forskellige typer beskeder via bluetooth

Indtil videre har vi kun kunne sende en slags beskeder til robotten,
nemlig beskeder hvori der står informationer om position og rotation
på robotterne. Målet er så at udvide dette således vi kan sende
flere slags beskeder til robotten, med information om at de skal
starte, stoppe eller måske lukke programmet ned.

For at kunne sende forskellige slags beskeder har vi lavet en
konvention for hvordan de nye beskeder er konstrueret. Det blev
følgende format:

-----------------
| Type | Besked |
-----------------

Type er en byte der siger hvilken type den sendte besked er, hvor
Besked er en serie af bytes der er indholdet af beskeden. Det er
således optil den enkelte beskedtype at vide hvorlang beskeden er.

Vi har lavet et switch statement der så tjekker på byten Type. Udfra
denne information konstrueres et objekt med supertypen Message, denne
nye besked bliver så sendt til alle objekter der har bedt om at få
besked når der kommer nye beskeder.

Det er let at understøtte nye beskedtyper, fordi det eneste det
kræver, for at lave en ny type besked er at lave en klasse der
nedarver fra Message http://www.daimi.au.dk/~mkm/LEGO/project/src/legodart/util/Message.java

Tovejs kommunikation mellem computer og NXT'er

Vi vil gerne kunne sende beskeder fra NXT'en til computeren, for
bl.a. at få en ide om hvordan dens opfattelse af virkeligheden er.

Dette er en simpel udvidelse af koden som vi ellers har brugt til
Bluetooth kommunikationen, NXT'ens kode skal udvides med en tråd der
sender beskeder via bluetooth og computer versionen af koden skal
udvides med en tråd der lytter efter bluetooth data og parser
beskederne der kommer.

Dette er tilmed også det sidste vi har lavet på bluetooth koden. De
følgende 4 filer er dem der er ansvarlige for bluetooth
kommunikationen.

Sender beskeder, http://www.daimi.au.dk/~mkm/LEGO/project/src/legodart/util/BTSender.java

Konstruerer beskeder, http://www.daimi.au.dk/~mkm/LEGO/project/src/legodart/util/MessageFactory.java

Computer specifik kode for afsending og modtagelse af beskeder, http://www.daimi.au.dk/~mkm/LEGO/project/src/legodart/pc/Sender.java

NXT specifik kode for afsending og modtagelse af beskeder, http://www.daimi.au.dk/~mkm/LEGO/project/src/legodart/nxt/BTConnection.java

Derudover er er der i pakken legodart.util implementationen af de
forskellige beskedtyper og interfaces som man skal implementere hvis
man vil notificeres om modtagene bluetooth beskeder.

Konklusion

Testopstilling

Om end vi opdagede nogle nye problemstillinger fungerede banen fint,
givet at det var første test med hele systemet.

Autonomous behavior model

Der var et par problemer med opførslerne.

Drive towards ball ville ikke altid køre om bag bolden, men kunne køre
lidt forvirret rundt ved siden af bolden. Vi mener at dette skyldes
det delay vi har når billeder fra kameraet skak processeres og
derefter sendes til robotten, så robotten bliver opdateret med en lidt
forældet position. Vi vil prøve at fikse dette senere i
CamTachoNavigator.

Dribble opførslen stopper ofte for tidligt med at drible og går
tilbage til drive towards ball. Dette mener vi kan rettes ved at
tweake parametre.

lab 4

Hvornår: Søndag d. 18/1
Hvem: Peter, Michael
Varighed: 8 timer

Mål

• Sende positioner til lego robotten


• Grafisk fremstilling af hvor på banen de forskellige enheder er

Arbejdsgang

Gennem de sidste par dage har vi bygget et system, der finder
positionen af forskellige tags på vores bane. Nu vil vi sende disse
informationer til legorobotten, så vi kan begynde at bruge det til at
navigere efter.

Vi kombinerer de forskellige dele af systemet som vi har arbejdet med
de sidste par dage og bygger et sammenhængende forsøg:

• ARToolKit læser et billede fra webcam, og identificere alle tags


• Transformationerne for hvert tag sendes til vores styringsprogram


• Position og rotation af hvert tag i forhold til vores bane beregnes


• Informationerne sendes til NXT robotten


• Robotten forsøger at køre i retningen af bolden

For at få et bedre overblik byggede vi et lille gui, hvor det er
muligt at se den position vi ser med kameraet, samt den seneste
position robotten kender til.



De to firkanter repræsentere robotterne, den runde er bolden. Alle de
sorte objekter er hvad vi ser med kameraet. Derudover er der en blå og
en rød kopi af hver information, som er hhv. det den ene og den anden
robot ved om banen. De to streger viser hvor bolden skal være for at
der er mål.

Input til ARToolKit lavede vi vha. et webcam der filmede nogle små
stykker papir med tags på et bord. Vi flyttede hvert tag manuelt for
at se ændringen i vores GUI.

Vha. vores bluetooth kode sendte vi koordinaterne til et meget simpelt
NXT program, der brugte TachoNavigator til at køre mod bolden.

Da vi manuelt skulle flytte tagsne var det naturligvis ikke
realistiske positioner der blev send til robotten, men det var
brugtbart til at teste om de forskellige komponenter virkede.

Bluetooth forbindelse

Delmålet er at sende data via bluetooth til en NXT fra en computer.

Måden vi gør det på er at bruge pakken lejos.pc.comm på computeren og
lejos.nxt.comm på NXT'en. Fordelen ved at bruge lejos.pc.comm på
computeren er at det giver næsten samme bluetooth grænseflade på
NXT'en som på computeren.

Under overfladen bruger lejos.pc.comm Bluecove, der er et opensource
bluetooh bibliotek. Det virker på Linux, Mac og Windows hvilket gør at
vi kan nøjes med en kodebase til de forskellige platforme vi bruger.

Det tog noget tid at få computeren til at finde en driver til det
underliggende bluetooth system. Grunden til dette var problemer med
javas CLASSPATH, den fandt således ikke Bluecove jar-filerne og kunne
derved ikke gøre brug af bluecove. Dette blev løst ved at tilføje
bluecove.jar og bluecove-gpl.jar fra mappen 3rdparty/lib/ i lejos, til
CLASSPATH'en. Derefter kunne vi connecte til NXT'en ved at bruge 2 små
testprogrammer.

Det næste mål er så at sende positioner og rotationer til
NXT'en. Målet blev opnået, ved bruge den DataOutputStream og
DataInputStream som lejos.nxt.comm.NXTConnection og
lejos.pc.comm.NXTComm stiller til rådighed.

For at have styr på de data vi sender over bluetooth så vi entydigt
kan encode og decode dem, lavede vi følgende dataformat:

int::RobotID | float::X-position | float::Y-position | float::Rotation

Hvor RobotID enten er 1,2,3 for hhv. robot 1, robot 2 og bolden.

Kode for at sende en position, hvor ``dos'' er en DataOutputStream for
bluetooth forbindelsen:

  dos.writeInt(id);
  dos.writeFloat(x);
  dos.writeFloat(y);
  dos.writeFloat(rotation);

Kode for at modtage en position, hvor ``dis'' er en DataInputStream
for bluetooth forbindelsen:

  id = dis.readInt();
  x = dis.readFloat();
  y = dis.readFloat();
  rotation = dis.readFloat();

På den måde kan vi altså udtrykke binær data der skal sendes over
bluetooth og forstå denne data hos modtageren uden, at tænke på
hvordan dataen præcist er udtrykt binært.

En ting der er værd at bemærke er at man skal kalde flush() på sin
DataOutputStream for at få denne til at sende dataen over
bluetoothforbindelsen.

Hastighed på bluetooth

Vi oplevede en hastighedsforskel på bluetooth mellem forskellige
platforme. Det lykkedes, at vinde lidt hastighed ved at ændre
opførslen på vores kode, der før kaldte flush efter hver besked, til
kun at kalde flush når den havde sendt alle de beskeder, der kunne
sendes på en gang.

Vi havde god succes med at sende koodinaterne til vores NXT, men for
at se hvor godt det virker skal vi have bygget en testopstilling.

Det næste der skal laves ved bluetooth forbindelsen er muligheden for
tovejs kommunikation mellem en computer og NXT'erne således de kan
sende flere forskellige slags beskeder til hinanden.

lab 3

Hvornår: Lørdag d. 17/1
Hvem: Peter, Asger
Varighed: 7 timer

Mål

• Find position af tag på banen

Arbejdsgang

ARToolKit

Fra ARToolKit har vi transformationsmatricen af vores tag. Faktisk har
vi transformationen af vores kamera i forhold til vores tag. Det vi
gerne vil have er koordinater i forhold til vores bane. Derfor har vi
placeret et tag i hjørnet af banen, således at positionen af kameraret
er ligegyldigt.

Gennem utallige forsøg og konsultation af bøger om 3d grafik fandt vi
den korrekte formel.

Vi tager transformationen for vores nulpunkt og ganger med den inverse
transformation for den robot vi har set. Det giver os transformationen
af robotten i forhold til vores nulpunkt. Denne kan vi konvertere til
translation og rotation.

Autonomous behavior model

Vi udførte test af behavior modellen på lokal computer for at se om
den kunne undertrykke behavior.

Testen blev lavet ved at køre en top level behavior som altid ville
køre hvis ingen andre var aktiveret og en behavior som ville køre
efter 3.000.000 condition checks og undertrykke den første i 2 sekunder.

code
Koden kan findes i
http://www.daimi.au.dk/~mkm/LEGO/project/src/PrintSound.java
http://www.daimi.au.dk/~mkm/LEGO/project/src/PrintDrive.java
*Bemærk* koden er forældet mht. den nuværende behavior klasse, som
kræver en player i konstruktoren og en metode til at returnere et
navn.

Modellen blev testet på en computer, i stedet for på vores agent,
pga. debugging. Vi mente det var nemmere at debugge output i en
terminal end robottens opførsel.

Konklusion

ARToolKit

Efter en del forskellige forsøg lykkedes det at finde den korrekte
måde at konvertere informationerne, og få positionen på vores bane
frem.

Autonomous behavior model

Vi så at vores multitrådede behavior model virkede ved testning.

lab 2

Hvornår: Fredag d. 16/1
Hvem: Asger
Varighed: 5 timer

Mål

• Konstruere modellen for eget behavior system

Egen autonomous behavior model

Plan:

På grund af tidligere eksperimentering med lejos behavior model, se
week 10 bloggen, valgte vi ikke at bruge lejos, men i stedet forsøge
at implementere vores eget behavior system.

I Modeling
Adaptive Autonomous Agents beskriver Maes de underliggende
problemer med at vælge den rigtige behavior for en agent.

• En agent skal kunne bestemme hvilken behavior der vil bidrage
  bedst til at opfylde dens mål.


• Den skal kunne behandle muligheder der pludselig opstår,
  dvs. mens agenten er igang med en opførsel, skal den kunne tilpasse
  sig og skifte til en ny opførsel, som får højere prioritet.


• Den skal kunne vælge mellem modstridende mål.


• Den skal reagerer indenfor en overkommelig tidsramme på nye
  miljøer.

Vores model er opbygget som
en subsumtion
arkitektur. Vi putter vores opførsler ind i en liste og lader en
opførsel kunne undertrykke alle de underliggende behaviors. F.eks vil
vores robot som vigtigste "refleks" stoppe når den får et stop signal,
hvilket undertrykker alt andet.


Vi havde tænkt os følgende behaviors til agenten.

1. Stop - stop når kampen er ovre


2. Undgå modstandere - undgå at køre ind i modstandere, så
   tacho navigatoren ikke bliver forvirret og agenter ikke hægner fast
   i hindanden


3. Få bold fra modstandere - Enten skubbe til bolden fra
   siden eller placerer sig mellem modstanderen og målet


4. Skyd på mål - i et kort øjeblik sætte hastigheden op og
   "skyde" til bolden


5. Drible mod mål - Løbe med bolden mod målet


6. Drej så agenten vender mod bolden - vende spilleren mod
   bolden


7. Løb efter bolden - placerer spilleren så bolden er
   mellem spilleren og målet

Arbejdsgang

Autonomous behavior model

Af behavior nåede vi at sætte de generelle abstrakte klasser op som
skulle bruges. Dette vil sige at vi implementerer Behavior.java
(http://www.daimi.au.dk/~mkm/LEGO/projec/src/legodart/nxt/Behavior.java)
og vores arbitrator
(http://www.daimi.au.dk/~mkm/LEGO/projec/src/legodart/nxt/BehaviorManagerMulti.java).
En komplet gennemgang af vores endelige behavior model følger i lab
reporten for d. 22/1, indtil da vil vi bare redegøre for hvad der blev
udviklet på i modellen.

lab 1

Hvornår: Torsdag d. 15/1
Hvem: Peter, Michael, Asger
Varighed: 8 Timer

Mål

• Få ARToolKit til at compile og snakke med Java


• Undersøg bluetooth mellem java på en pc og NXT'en


• Bygge en robot, som kan køre med bolden og bære fastsiddende tags

ARTooKit

ARToolKit er
et open source projekt der kan finde "tags" i et billede fra webcams,
og udregne deres transformationsmatrix. Vi vil bruge dette til at
finde placeringen af vores NXT'er og bold på vores bane.

ARToolKit er skrevet i C, så for at få det til at kommunikere med
java, har vi lavet et C program der sender informationerne fra
ARToolKit over en UDP socket til et java program, der behandler
informationerne og kommunikere med NXT'erne.


Her ses ARToolKit, der har fundet 4 tags.

Når ARToolKit ser et tag, rapportere den tilbage med et id og en
matrix, der repræsenter transformationen fra tagget hen til
kameraet. Vi pakker informationerne til en streng, hvor hver komponent
i matrixen er efterfulgt af et ";".

Fx.

d;3;0.992832;-0.057238;-0.104917;0.000000;
-0.095224;-0.909338;-0.405015;0.000000;
-0.072223;0.412102;-0.908271;0.000000;
36.001337;-493.343131;1330.260070;1.000000

d'et bruges til at skelne mellem om vi sender data eller andre
informationer (vi har dog ikke andre typer beskeder endnu). Derefter
kommer taggets id (3 i dette tilfælde) efterfulgt af
transformationsmatricen.

På java siden af systemet arbejder vi videre med matricerne vh.a. java
biblioteket Jama
- et java bibliotek til at arbejde med matricer.

BlueTooth

Vi ønsker at sende oplysninger om position og rotation fra en computer
til NXT'er. En oplagt måde at gøre dette på er ved at bruge
bluetooth. Da vi antager at vi allerede har positioner og rotationer
fra AR-toolkit er det oplagt at betragte Bluetooth som en abstrakt
kommunikationskanal, hvor vi kan sende og modtage data over.

Det viser sig at lejos både har Bluetooth support til NXT og
computere, endvidere viser det sig at de bruger bluecove til computer
delen. Bluecove er et opensource og crossplatform bibliotek, så vi kan
derfor nøjes med at bruge et bibliotek selvom vi bruger forskellige
platforme.

Bluetooth kan agere master og slave, hvis NXT'erne er slave enheder og
computeren er master, så er der ingen problemer i at lave forbindelser
fra computeren til flere NXT'er.

Til næste labsessions er målet at skrive noget kode der kan sende
positioner fra computeren til NXT'erne.

Bygge robotten

Et godt udgangspunkt at tage inden vi kodede til en lego robot, var at
bygge den først. Vi satte os derfor ned og kiggede på hvad der skulle
til for at få en robot, som kunne spille fodbold.

Vi kom frem til at roboten kun krævede 2 actuators, nemlig motorer
til styring. Begrundelsen er at vi ville have robotterne til at køre
med lav hastighed, og et spark til bolden ville så foregå ved at
robotten accelererede op til en høj hastighed med bolden, og slap den
ved at vende tilbage til normal "løbe" hastighed.

Robotten skulle ikke have nogle påmonterede sensore, da den fik alt
sit data omkring miljøet via bluetooth.

Baseret på dette valgte vi at bygge standard robotten og foran på
denne placerede vi en "arm" eller boldholder til at holde bolden
nogenlunde på plads når robotten kørte fremad. Ovenpå placerede vi en
holder til kamera-tagget og og puttede noget hæftemasse
(a.k.a. elefantsnot) på, så tagget blev siddende.

Nedenstående billeder skulle vise designet ganske godt.






Endvidere
kan Legodart.lxf
åbnes i Lego Digital Designer, der
bl.a. kan genere en byggevejledning.

Konklusion

ARTooKit

Det lykkedes at sende matricerne fra ARToolKit til java, og oprette en
tilsvarende matrice i Jama format. Næste gang skal vi forsøge at få
noget nyttigt ud af disse.

Bygge robotten

Lego robotten kan fint køre med vores bold, en omvendt dyb plastik
tallerken, pga armen foran. Og tagget ovenpå robotten sidder fast,
også når robotterne kører ind i hinanden, og kan trackes at
kameraet. Vi ser derfor vores robot design som en succes indenfor de
kriterier vi stillede under mål