Week 15 - Session 3

Dato:

31-05-2013

Varighed:

Fælles lab: 5 timer

Blog: 4 timer

Deltagere:

Steffen Høi
Nikolaj Mols Hansen
Martin Vang
Ulrik Sahl Lystbæk

Status

LEGO-robotten kan se bolden på lang afstand. Den er i stand til at affyre et skud i en rimelig konsistent retning. Vi har store problemer med at få kompasset til at virke og koden trænger til en grunding oprydning.

Mål

Målet er at have den endelige konstruktion af robotten færdig, så vi har en robot, der fungerer bedst muligt ud fra de eksperimenter, vi har lavet. Der skal også arbejdes videre med eksperimentet omkring at få robotten til at kunne bestemme hvilken retning, den er positioneret i vha. kompasset, så den ud fra det, kan finde og skyde mod det rigtige mål.
Indtil videre består koden til projektet af brudstykker, som kun virker isoleret til specifikke test. I denne session vil vi opsætte en arkitektur af koden så de forskellige adfærd kan begynde at køre sammen.

Plan

• Videreudvikling af robotten.
• Refaktorering af kode.
• Videre test med kompas.

Proces

Videreudvikling af robotten

Vi arbejde videre med TrikeBase prototypen sideløbende og har løbende arbejdet ud fra at indføre de erfaringer, vi er kommet frem til på vores anden prototype. De primære forbedringer vi har lavet i forhold til TrikeBase basen er følgende:

• Vi har monteret fangekrogen og dribleren foran på robotten i stedet for den bøjle som normalt i på TrikeBase modellen.
• Vi har ombygget baghjulet til at være mere lodret for holde robotten under de 22 cm. For at robotten stadig skulle beholde den rigtige hældning i forhold til baghjulet har vi monteret større forhjul. Vi bar bygget en bar øverst på robotten til at montere IR sensor og som skal bruges til kompas sensor for kompas sensoren væk fra motoren og for at sørge for at IR sensoren ikke bliver dækket af robottens andre dele.
• Vi har indført gearing for at gøre robotten hurtigere og mere kvik hvilket oftest er en stor fordel i fodbold.
• Vi har monteret afstandsensor under robotten til at registrere hvornår bolden er i robottens besiddelse. Vi er dog kommet frem til at der skal bruges tryk sensor da afstandsensoren har svært ved registrere bolden. Denne funktionalitet har vi valgt at flytte fra den anden prototype når den endelige udgave laves.

Den endelige robot prototype vi kom frem til ud fra TrikeBasen ser ud som billedet. Den er meget stabil og holder sig lige præcis inden for de 22 cm i diameter.

Færdig Robot2

Robot2 under hjulskift

Refaktorering af kode

Det kode vi har til robotten på dette tidspunkt er følgende 3 adfærd.

1. Køre tilfældigt rundt.
2. Skyde.
3. Finde bolden og køre hen imod den.

Til håndtering af det adfærdbaserede logik har vi brugt Ole Capranis Arbitrator.java [1] og Behavior.java [2]. Vi har tilføjet en abstrakt klasse AbstractBehavior.java [3] som implementerer Behavior. I den klasse implementeres metoden suppress som sætter en boolean variabel suppressed til true. Metoden action har vi også implementeret i den abstrakte klasse fordi vi som udgangspunkt altid vil sætte suppressed til false i starten af enhver action. Til gengæld kræver den abstrakte behavior at metoden customAction implementeres af klasser som nedarver fra den. AbstraktBehavior.java kalder customAction i dens action metode. En ting vi havde lidt problemer med, med vores adfærd var at de nogle gange tog kontrol hurtigt selv igen. Uden at bruge tid på at undersøge det længe tilføjede vi en boolean variabel executingAction som sættes til sand når action kaldes og til falsk når action er færdig. Den kan bruges i metoden takeControl til at tjekke for at en adfærd ikke skal afbryde sig selv hvis det er det man har lyst til.
Til hver af de tre ovennævnte adfærd lavede vi en klasse som nedarver fra AbstractBehavior.java så de kunne komme ind i adfærdhierarkiet. Det er nu nemt senere at tilføje nye adfærd til hierarkiet.

Udover at refaktorere koden til at være adfærdbaseret tilføjede vi klassen Robot.java [4]. Robot.java er en beskrivelse af robottens fysiske forhold. F.eks. hvor motorerne og sensorerne er forbundet.

Selvom de tre adfærd er lette at få til at virke sammen programmeringsmæssigt, kan de stadig ikke virke sammen i praksis fordi vi endnu ikke har en måde til at afgøre om robotten har bolden på. Dvs. at vi ikke ved hvornår skydeadfærden skal tage kontrollen.

Videre test med kompas

Efter en halv dags test af kompasset af en ny person der ikke havde adgang til første forsøg, var resultatet nogenlunde det samme. Der var en smule fremgang, da vi nu kunne kalibrere kompas ift. motor-støj samt støj fra brikken. Det overordnede resultat var dog det samme - robotten fandt et nyt Nord alt efter hvor på banen den stod.
Kalibrering sker ved at dreje langsomt om robottens akse i 20-40 sekunder, efter et kald til at starte kalibreringen. Ideelt set skal robotten dreje én omgang pr. 20 sekunder, men vi fandt at der ikke var nævneværdig forskel imellem en kalibrering hvor den kørte en smule hurtigere rundt. Ligeledes fandt vi, at kalibreringen sagtens kunne foretages hurtigere (forsøgt med halv tid) med samme effekt. Eftersom kompas-sensoren blot skal kalibreres én gang pr miljø den kører i (gemt permanent efter hver kalibrering, men kan overskrives), besluttede vi os for at lave en lang og præcis kalibrering på vores endelige testbane. Herunder ses en af vores første forsøg med kalibrering (de første havde hurtig omdrejninghastighed).

Brugen af Differentiel Piloten fik omdrejninghastigheden ned på 360 grader / 40 sekunder = 9 grader pr sekund, hvilket styres præcist uafhængigt af batteriniveau, fra denne klasse.

Konklusion

Vi har refaktoreret koden til at være adfærdbaseret jf. vores teori, så det er let at tilføje og fjerne adfærd. Det er samtidig let at teste ved at sætte den adfærd som skal testes til at returnere noget højere end de andre. Vi mangler at få vores ultrasoniske sensor til at registrere når robotten har bolden, hvilket kræver lidt flere test med målingerne.
Vi har på dette tidspunkt besluttet indtil videre kun at gå videre med en markspiller og ikke en til at stå i mål, fordi målene ikke er store i forhold til robotterne og på det niveau vi forventer at vores robot kommer til at kunne sigte og skyde på mål, vil det ikke være realistisk at score, hvis der står en robot i målet (selv hvis den ikke bevæger sig). Hvis vi når at lave en markspiller der kan skyde fornuftigt på mål vil det give mening at fortsætte med en som står i mål.

Referencer

[1], https://www.dropbox.com/sh/py0lfofp42zjydx/_YCH2xZpAO/LEGO%20Soccer/standard/Arbitrator.java
[2], https://www.dropbox.com/sh/py0lfofp42zjydx/eyFWJ2wVck/LEGO%20Soccer/standard/Behavior.java
[3], https://www.dropbox.com/sh/py0lfofp42zjydx/U7MebEgYaa/LEGO%20Soccer/behaviors/AbstractBehavior.java
[4], https://www.dropbox.com/sh/py0lfofp42zjydx/aQDHGHV2oz/LEGO%20Soccer/standard/Robot.java

Week 15 - Session 2

Dato:

28-05-2013

Varighed:

Fælles lab: 7 timer

Blog: 5 timer

Deltagere:

Steffen Høi
Nikolaj Mols Hansen
Martin Vang
Ulrik Sahl Lystbæk

Status

Vi kan aflæse målingsværdier for IR sensoren som er monteret på robotten. Den overordnede konstruktion af robotten er stadig i gang. Adfærdhierarkiet er stadig lidt buggy.

Mål

Målet for denne laboratoriesession er at arbejde videre på konstruktion af robotten, teste IR sensoren samt lave indledende undersøgelser med kompas.

Plan

• Videreudvikling af robot.
• Undersøge interaktion mellem IR-sensor og IR-bold og finde bolden på lang afstand (måle vinklerne med vinkelmåler og sætte værdierne ind i en graf for at se forholdet mellem)
• Få LEGO-robotten til at skyde mod mål (afgøre hvor målet er måske ved brug af kompas)
• Indlede undersøgelser med kompas.
• Rette fejl i adfærdhierarkiet.

Proces

Undersøge interaktion mellem IR-sensor og IR-bold

Først testede vi IR sensorens bredde. I bredden ved vi som vist på figuren Infrared Seeker Sensor fra sidste session, at der er 5 områder værdierne kan aflæses for. Vi ved også at der i alt burde være en bredde på 240 grader[1], som vi startede med at teste. Vinklen på de 240 grader stemte fint overens og det næste interessante var om de var ligeligt fordelt over de 5 områder. Det viste de sig at være dvs. at hvert felt fylder ca. 44 grader.

Test af IR Seekers vinkel

På bredden testede vi også overgangen mellem felterne og rigtigt nok som også kan ses i dokumentet vi fandt sidst Thomas Eng [2] er der et sted mellem de forskellige felter hvor begge felter giver udslag på målingerne. Vi har ikke oplevet på noget tidspunkt at bolden har givet udslag på mere end 2 målingfelter for sensoren. Dvs. at værdien for alle felter som ikke ser bolden er 0 og ikke noget med at de svinger mellem lave værdier. Det er meget stabilt og derfor har vi faktisk 9 felter hvor vi kan se bolden. Felterne er som følgende: (5), (5 og 4), (4), (4 og 3), (3), (3 og 2), (2), (2 og 1), (1).

IR Seeker målefelter og overlap

Derefter fortsatte vi til at teste rækkevidden af sensoren. Formålet med at teste rækkevidden var for det første at finde ud af hvor langt væk IR sensoren ville være i stand til at se bolden, fordi hvis det ikke var langt skulle der arbejdes på en adfærd til at komme godt rundt på banen for at lede efter bolden uden at kunne se den. Fremgangsmåden var at måde den givne afstand ud fra robotten, for så at holde bolden fast i denne position og rotere den. Imens blev den maksimale og minimale værdi gemt. Afstandsmålingerne vi foretog kan ses her:

Måleværdier

200 cm 27-40
180 cm 26-50
160 cm 29-58
140 cm 34-60
120 cm 39-69
100 cm 51-80
80 cm 59-97
60 cm 81-120
40 cm 118-142
20 cm 130-145
10 cm 141-145

IR-Seeker måledata over afstand

Vi har på baggrund af måledataene konkluderet at vi desværre ikke med god nok præcision kan bestemme afstanden fra vores robot til bolden. Problemet er at IR Bolden ikke udsender lige stærkt signal i alle retninger, så afhængig af hvordan bolden's indre dioder vender, får vi forskellige værdier ud fra en given afstand.

Kompas Sensor

Dette forsøg med at få kompasset til at fungere var ganske enkelt ubehageligt. Der er to forskellige måder at få en læsning ud af kompasset. Den ene er getDegrees(), der giver antal grader offset fra Nord jf. normalt kompas. Den anden er getDegreesCartesian(), der istedet giver grader der jf. dokumentationen "Compass readings increase clockwise from 0 to 360, but Cartesian coordinate systems increase counter-clockwise." Denne måletype havde dog den fordel at man kan "nulstille Nord" i den retning man har lyst til. Herefter får man grader ift. det nye "Nord".
I første omgang gik fremgangsmåden ud på at forsøge at få robotten til at dreje konsekvent imod Nord. Dette viste sig hurtigt at være utrolig svært. Under testene var robotten nogenlunde konsistent på en given plads på banen, men dens opfattelse af hvor Nord fra getDegrees() variereden med op til 50 grader. Dette var naturligvis uholdbart og utrolig frustrerende.
Vores teorier om hvad der var galt var på dette tidspunkt, at vi lavede fejlberegninger, at kompasset var i stykker eller at vi påvirkede det med trådløst signal fra telefoner. Vi havde allerede konstateret at kompasset var anderledes men stadigvæk ca. 50 grader usikkert forskellige steder på banen, ved at montere det på en lang ledning væk fra selve robotten og motorene (da vi mistænkte disses magnetfelter for at påvirke vores målinger under rotationen).
Opgaven blev overdraget til et par friske øjne med en ny vinkel på sagen og koden blev gemt, men ikke brugt i dette nye forsøg (helt nyt forsøg).

Differentiel Pilot

En normal begrænsning ved at bruge Lejos frameworket er, at man ikke kan benytte de forskellige pilot-klasser sammen med direkte kontrol over motorerne. Vi har fra et tidligere projekt [3] lavet modifikationer så denne begrænsning ikke længere umiddelbart gør sig gældende. Der er dog stadig indstillinger for afstand imellem hjul (19,0 mm) samt hjulenes diameter (6,3 mm), der spiller ind ift. at kunne benytte differentiel piloten til at lave præcise sving og manøvredygtighed. Da vi har gearing på vores markspiller, bliver dette naturligvis nød til at blive indregnet. Dette burde gøres ved at gange gearings-faktoren (2,5:1) med hjulets diameter.
Efter disse indstillinger testes robotten for at se om den kan dreje præcist på stedet. Vejledningen til differentiel pilot anbefaler at man ser om den kan køre en lige linje, men dette er meget svært at vurdere. Ved drejning på stedet 5 * 360 grader, fandt vi at det er nemmere at se om robotten stopper det samme sted, og dette hjalp os med at eliminere drift.
Efter at disse indstillinger er på plads blev robotten testet, og vi fandt at vi skulle bruge en konstant på 1,51 som dividend, for at robotten var præcis i drejninger. Dette kom noget bag på os, da vi forventede at en gearing på 2,5:1 ville give os en 2,5 gange hurtigere omdrejning, hvilket burde passe med den rapporterede 2,5 gange større diameter.
Vi valgte ikke at undersøge nøjere hvorfor dette var tilfældet, indtil vi fandt noget godt at bruge piloten på, hvor det kunne blive relevant.

Konklusion

IR sensoren er meget præcis i bredden og vi forventer at det vil gøre det ret let at navigere pænt i den rigtige retning mod bolden. De 9 felter gør at den kan rammes forholdsvis præcist selvom den nogle gange vil kunne ramme lidt skævt på bolden. Afstanden bolden kan ses på er meget god i forhold til at banen kun er 217 cm. Det betyder faktisk at bolden næsten vil kunne ses over hele banen. Det største problem bliver hvis robotten vender med ryggen mod bolden. Der er dog følgende problem som vi er opmærksomme på, på nuværende tidspunkt. Netop at robotten ikke helt overholder WRO GEN II Football reglerne for kravet om robottens dimensioner.
Vi udskyder igen adfærdhierarkiet til næste session.

Referencer

[1], http://www.usfirst.org/sites/default/files/uploadedFiles/_Programs/FTC/FTC_Documents/Using_the_IR_Seeker.pdf,  Using IR Beacons and IR Seeker - Thomas Eng 2011.
[2], http://www.robotshop.com/lego-mindstorms-nxt-irseeker-v2-infrared-sensor.html, Robotshop IR sensor.
[3], http://digikaison.blogspot.dk/2013/04/week-8.html, Alishan Train Track.

Week 15 - Session 1

Dato:

28-05-2013

Varighed:

Fælles lab: 7 timer

Blog: 5 timer

Deltagere:

Steffen Høi
Nikolaj Mols Hansen
Martin Vang
Ulrik Sahl Lystbæk

Status

Selvom den er langt fra færdig har vi en prototype, som vi kan begynde at teste med. Adfærdhierarki mangler at blive implementeret.

Mål

Målet for denne laboratoriesession er at bygge videre på robotten, undersøge hvordan IR sensoren kan anvendes til at finde bolden samt at teste det hvis der bliver tid.

Plan

• Bygge videre på robotten.
• Undersøge IR sensor og bold.
• Udvide vores adfærdhierarki.

Proces

Undersøge IR sensor og bold

Før vi begyndte at teste med IR sensoren søgte vi på nettet for, at se om vi kunne finde ud af hvad andre har gjort. Et dokument der gav også noget forståelse af sensoren er Thomas Eng [1]. Vi brugte det mest til at få en generel forståelse af hvordan sensoren virker. F.eks. at man kan aflæse målinger på 5 forskellige steder. De steder kan ses på billedet Infrared Seeker Sensor herunder. På andre sider (særligt dem der sælger LEGO Mindstorms NXT IRSeeker V2 Infrared Sensor se f.eks. Robotshop [2]) har vi også fundet lidt information om sensoren. F.eks. at den kan foretage målinger i en bredde af 240 grader. Herunder forsøger vi at måle efter for at se om vores sensor passer nogenlunde overens med det påståede 240 grader målefelt, inddelt i 5 måleområder. Vores måledata understøttede det sælgerne påstod.

Måling af gradtal for de forskellige måle-områder

Da vi havde fået dannet os et overblik over sensoren, ledte vi efter noget i LEJOS' API, som vi kunne bruge. Vi fandt LEJOS klasserne IRSeeker og IRSeekerV2. Da vi havde version 2 af IR sensoren valgte vi at starte med at prøve klassen IRSeekerV2. Med den klasse var det let at få målinger i de 5 forskellige områder som der er vist på herunder.

Infrared Seeker Sensor måleområder

Vi har også kørt en hurtig test hvor vi laver små korrektioner på at robotten ellers skal køre ligeud. Grunden til at den hopper af sted er, at vi samtidig testede for, hvornår vores adfærd frigav kontrollen, hvilket vi markerede med en lille pause.

Testen var lige så meget for at få en føling for hvordan vi kunne inkorporere IR-Seeker i vores spæde adfærdhierarki.

Konklusion

Først har vi dannet os en forståelse af IR sensoren og dernæst fået hul igennem til at aflæse målingerne med et program. Næste gang skal undersøgelserne fortsættes med at aflæse konkrete målinger for at teste præcision af sensoren i forhold til bolden på afstand både i bredde og længde. Angående viderebygning af robotten har vi ikke noget konkret resultat denne session. Opgaven fortsætter næste session.
Adfærdhierarkiet har nogle bugs vi lige skal glattes lidt ud, hvilket ikke er på plads denne uge. Vi vælger at udskyde denne sammenfletning indtil vi er tættere på at have adfærdstumper der fungere fuldt ud som de skal.

Referencer

[1], http://www.usfirst.org/sites/default/files/uploadedFiles/_Programs/FTC/FTC_Documents/Using_the_IR_Seeker.pdf,  Using IR Beacons and IR Seeker - Thomas Eng 2011.
[2], http://www.robotshop.com/lego-mindstorms-nxt-irseeker-v2-infrared-sensor.html, Robotshop IR sensor.

Week 14 - Session 2

Dato:

23-05-2013

Varighed:

Fælles lab: 5 timer

Blog: 4 timer

Deltagere:

Steffen Høi
Nikolaj Mols Hansen
Martin Vang
Ulrik Sahl Lystbæk

Status

Banen er bygget og vi har påbegyndt konstruktionen af robotten samt eksperimenteret med at få robotten til at skyde mod mål.

Mål

Målet for denne laboratoriesession er at lave forskellige prototyper af LEGO-robotten samt lave nogle tests for at undersøge, hvor godt LEGO-robotterne kan udføre den basale funktionalitet, som at drible med bolden og foretage et skud mod mål.

Plan

• Udvikling af prototyper af LEGO-robotten.
• Teste de basale funktionaliteter af LEGO-robotten.

Proces

Udvikling af prototyper af LEGO-robotten

Vi var i "Week 14 - Session 1", allerede gået i gang med at konstruere en robot, med det formål at teste nogle af de basale funktionaliteter i fodboldspillet, som en robot skulle kunne. Den første robot vi konstruerede, blev løbende tilpasset efterhånden, som vi gjorde os nogle erfaringer, og nye behov opstod. Ideen med denne robot, var at vi gerne hurtigt ville i gang med at teste de forskellige idéer og strategier, og fokus var ikke på at robotten nødvendigvis skulle overholde alle reglerne til spillet.
Vi påbegyndte konstruktionen af en ny prototype sideløbende med, at vi lavede eksperimenter med den første prototype.
I forbindelse med konstruktionen af prototype nummer to, blev der lagt vægt på at bruge erfaringerne fra den første prototype til at lave en mere solid og gennemtænkt robot. Fokus denne gang var, at den også skulle overholde reglerne defineret i forrige session. For at opnå en stabil base ledte vi efter forskellige robotkonstruktioner, som kunne overholde regelkravet med en diameter på 22 cm. Vi var også bevidste om, at vi ønskede at genbruge ideen med fangarmene og driblefunktionen, som vi var kommet frem til efter arbejdet med den første prototype.

Fangarme med støttestave

For at få plads til fangarme inden for de 22 cm., var vi ret bevidste omkring at NXTen ikke måtte ligge vandret, da det ville give en for stor overflade sammen med fangarmene. Vi fandt frem til TrikeBase, hvilket er basen for en motorcykel, hvor NXTen ligger på skrå. Motorcyklen virkede meget robust i sin opbygning, og der var desuden en byggevejledning [1].

TrikeBase Robot

Resten af denne session gik med at opbygge TrikeBasen.

Test af basale funktionaliteter af prototype 2

Fra start af konstruktionen af prototype 2, begyndte vi at teste isolerede dele af robotten. Vi testede f.eks. om den drejede som den skulle, om den kunne køre hurtigt nok og især om driblehjulet kunne holde tilstrækkeligt på bolden, til at robotten var i stand til at dreje og kunne bakke uden at miste bolden. Nedenstående video viser, hvordan denne prototype kører ligeud for en af de allerførste gange:

Vi testede desuden driblemekanismen, da vi forventede, at den var svær at få til at virke. Desuden ville det kræve en større ombygning af hele robotten, at lave om på driblemekanismen. Det er ikke nødvendigvis sådan, men da vi ikke med sikkerhed kunne vurdere, hvor der ville opstå problemer, måtte vi prøve at lave en vurdering.
På videoen herunder ses, hvor vi testede på en tidlig prototype, om den var i stand til at holde på bolden når den drejede:

Arbejdet med første prototype

Vi har i dag arbejdet med at få samlet vores resultater fra forrige session i noget der virker jf. vores ønske om at benytte et adfærdshierarki. Samtidig har vi testet om vores småstumper af adfærd vil være i stand til at fungere sammen, og det viste sig at der skal et par ændringer til, før vi er klar med en fodboldspiller.

Konklusion

Konstruktionen af robotten går ok, men vi kan se nu at det bliver en udfordring at overholde regelsættets dimensioner for robotten. Da vi hele tiden afprøvede robotten, særligt driblemekanismen, under udvikling af robotten fandt vi hurtigt ud af når vi havde lavet en konstruktion som ikke virkede som den skulle. Det tog selvfølgelig tid at teste prototypen meget, men i forhold til den tid det tager at bygge den om når der er noget galt mener vi at det ofte vil kunne betale sig at sætte tid af til at teste tidligt for at opdage fejlene, så hurtigt som muligt.
Vores første prototype er ved at udforme sig, men koden mangler at blive samlet i en helhed med en prioritering af adfærd. Den grundlæggende struktur for, hvordan vi vil implementere vores adfærd er på plads, taget fra uge 11[2]. Vi har den dog ikke implementeret i koden endnu.

Referencer

[1],http://www.hitechnic.com/upload/TrikeBase_Instructions.pdf, TrikeBase Instructions, 2010
[2],http://digikaison.blogspot.dk/2013/05/week-11.html, BumperCar

Week 14 - Session 1

Dato:

21-05-2013

Varighed:

Fælles lab: 8 timer

Blog: 5 timer

Deltagere:

Steffen Høi
Nikolaj Mols Hansen
Martin Vang
Ulrik Sahl Lystbæk

Status

Vi har indkøbt materiale til konstruktion af banen, og vi har en idé om, hvordan vi skal konstruere LEGO-robotten.

Mål

Målet for denne laboratoriesession er at bygge fodboldboldbanen ud fra det indkøbte materiale samt starte konstruktionen af LEGO-robotten.

Plan

• Konstruktion af banen med det indkøbte materiale
• Begynde på konstruktionen af robotten

Proces

Konstruktion af banen med det indkøbte materiale

Ud fra de overvejelser, vi gjorde i sidste uge, har vi indkøbt filt, tape, hobbyknive og andre redskaber, der skal bruges til at lave underlaget på banen. Filt har vi indkøbt i fire forskellige farver (grøn, lysegrøn, hvid og sort). Vi har først forsøgt at bruge dobbeltklæbende tape til at fastgøre filten, men det viste sig hurtigt at være svært at kontrollere. De steder, hvor tapen ikke var monteret, kunne filtet skride, og vi var derfor bange for, at når filtet gav sig i forhold til den hårde overflade, så ville robotterne kunne rykke filtet i stykker, hvis den kom til at sidde fast på et af de løse områder, og hjulene spandt rundt. Vi blev derfor enige om at filten skulle ligge mere jævnt, hvilket ledte til ideen om at bruge tapetklister. Vi brugte først sandpapir på den glatte overflade på pladen, så der kom nogle ujævnheder, som tapetklistret kunne fange, hvorefter vi monterede filtet med tapetklister til overfladen. Selve processen var forholdsvis nem, da tapetklistret ikke størknede med det samme, hvilket gav os spillerum til at få det hele til at passe godt sammen. Et billede af det færdige resultat kan ses nedenunder.

Nyklistret bane

Senere på dagen testede vi filtoverfladerne, og enkelte steder var der nogle kanter, der ikke sad ordentlig fast. Dette lappede vi med tapetklister, i trit med at vi fandt fejl, indtil filtet var helt fastgjort til bordet.

Konstruktion af Robot 1 - prototypen

I forbindelse med konstruktionen af vores robot, var det klart fra starten at vores ønske om at benytte tre motorer blev udfordret ift. størrelseskravet til robotten. 22 cm diameter lyder af meget, men med tre motorer og en stor NXT-boks, samt et ønske om stabilitet, blev det besværligt at lave en robot, der var nem at skille ad i forbindelse med at videreudvikle prototypen.
Vores første udfordring var at få en drible-mekanisme på plads. Tanken var at benytte en motor til udelukkende at skabe back-spin i bolden foran vores robot. Kombineret med en "klo", der kan holde bolden på plads, jf. reglerne om i hvor høj en grad robotten må kontrollere bolden, burde dette være en særdeles effektiv løsning. Back-spin har vist sig at være lige så godt som forventet, men konstruktionen af robotten så "drible-hjulet" ikke går for langt ind over bolden er besværlig, dog ikke umulig. Her har vi besluttet vi at tillade, at reglerne ikke skal overholdes 100 procent for denne prototype, da den blot skal bruges til at vise "proof-of-concept" for alle vores ideer. Vores forsøg med at lave fangarme, der kan skyde bolden ved at skubbe den en smule ud (reverse drible-hjul), for så at slå til den med fangarmene, virker konsistent. Styrken på skuddet er høj og præcisionen sikres, da vi blot skyder vha. en sekventiel udførsel af drejninger. Vores eksperiment kan ses nedenunder:

Skyde på mål

Da vi valgte at have en driblemekanisme til at holde fast på bolden, kunne vi ikke skyde ved at køre direkte ind i bolden. Vi forsøgte i stedet to andre metoder. Den første var at slynge bolden af sted ved at dreje robotten rundt og øge farten langsomt, uden at driblemekanismen mistede kontrollen af bolden. Da robotten var ved at være oppe på den maksimale hastighed, hvor den stadig kunne dreje rundt om sig selv, uden at driblemekanismen mistede taget på bolden, satte vi farten helt op, samtidig med at driblemekanismen blev sat til at skubbe bolden fra sig. Det resulterede i at bolden blev slynget af sted, pga. centrifugalkraften, hvilket kan ses på videoen nedenunder:

Den anden metode, vi prøvede, var at skubbe bolden væk med driblemekanismen, og herefter give den et slag med robottens ene fangearm. For at skyde bolden i den retning, som robotten vendte mod, da skuddet blev påbegyndt, lavede vi nedenstående skudsekvens:

1. Drej kontrolleret ca. 90 grader til venstre.
2. Stop og skub bolden ud med driblemekanismen.
3. Drej med fuld styrke mod højre.

Denne type skud kan ses på videoen herunder:

Den endelige udgave af skud adfærden kan ses her ShootBehavior.java [1].

Konklusion

Denne laboratoriesession har resulteret i, at vi har fået banen konstrueret færdig, så vi nu kan eksperimentere med de forskellige elementer af fodboldspillet. Filten sidder dog ikke lige godt fast alle steder, så den skal have en ekstra gang tapetklister enkelte steder i forbindelse med næste session.
På baggrund af vores beslutning om at bruge robot1 som proof-of-concept robot, planlægger vi efter at der skal bygges en ny robot sideløbende. Indtil videre har vi alle 3 motorer i brug; to til at styre hver sin motor samt en til at styre driblemekanismen. Det tager ca. 1-2 sekunder at udføre skudsekvensen, og det er når robotten står i den retning, som den skal skyde imod. Hvis vi lægger tiden, det tager for robotten at finde retningen, den skal skyde, vil det sandsynligvis tage for lang tid for den at få afsluttet før en anden robot er kørt ind i den. Vi har endnu ikke en god løsning på dette problem.

Referencer

[1], https://www.dropbox.com/sh/py0lfofp42zjydx/QAX0wFXuCe/LEGO%20Soccer/behaviors/ShootBehavior.java

Week 13

Dato:

16-05-2013

Varighed:

Fælles lab: 7 timer

Blog: 12 timer

Deltagere:

Steffen Høi
Nikolaj Mols Hansen
Martin Vang
Ulrik Sahl Lystbæk

Status

Vi har valgt projektet at lave en udgave af WRO GEN II Football[1], hvor vi afprøver og analyserer reglerne.

Mål

Målet for denne laboratoriesession er at gennemgå de officielle regler for WRO GEN II Football og se videoer igennem af kampe fra turneringerne for at se, hvad man kan udlede af kampene med henblik på at forbedre spillet. Ud fra dette skal en udarbejdelse af de regler, vi ønsker at implementere i vores udgave af spillet være påbegyndt. Det er desuden også et mål at planlægge opbygningen af banen, efter vi har defineret krav og regler til spillet, samt indlede overvejelser omkring konstruktionen af LEGO-robotten.

Plan

• Analyse af WRO GEN II Football spil.
• Finde anden gruppe ift. regler.
• Diskutere konstruktion af LEGO-robot.
• Opsætning af SVN.

Introduktion

WRO (World Robot Olympics)  er en international konkurrence for unge mennesker. I konkurrencen anvendes LEGO Mindstorms af holdene som konkurrerer. Der er tre forskellige kategorier "Regular", "Open" og "Football". 
I dette projekt afprøves spillet og reglerne fra WRO GEN II Football med det formål at vurdere om regelsættet med fordel kan ændres eller, om vi kan få skabt et succesfuldt fodboldspil med LEGO-robotter ved at følge de regler og krav WRO, sætter til spillet. Vores definition af et succesfuldt spil vil vi give efter, at vi har analyseret kampene fra WRO turneringerne, samt gennemgået reglerne for spillet.

Proces

Analyse af WRO GEN II Football spillet

Efter at have gennemgået de officielle regler fra WRO GEN II Football, har vi udvalgt de regler, som vi vil implementere i vores udgave af fodboldspillet samt de regler fra WRO GEN II Football, som vi vil lave eksperimenter ud fra. Begrundelsen for dette er, at de officielle regler virker meget omstændige. Efter at have set nogle videoer på Youtube[2] af kampene fra WRO turneringerne, har vi lagt mærke til, at der er utrolig mange afbrydelser i løbet af en kamp, hvilket for det meste skyldes, at bolden triller uden for banen, men også situationer hvor robotterne låser hinanden. Disse afbrydelser, der kræver menneskelig indblanding, kunne vi godt tænke os at minimere.

En anden gruppe arbejder også med fodboldspillet, og for at kunne spille på lige vilkår mod hinanden i slutningen af projektperioden, har vi aftalt at følge de samme regler mht. dimensionerne for konstruktionen af LEGO-robotten. Desuden blev vi også enige om udgangspunktet for banen. Vi har fundet ud af, at det på nuværende tidspunkt ikke given megen mening, at lave et fast og endeligt regelsæt, da det vil sætte en del begrænsninger for kreativiteten og evt. forbedringer af spillet. Desuden går dette projekt også ud på, via eksperimenter med LEGO NXT, at give et bud på hvilke muligheder, der er for at skabe det bedst mulige LEGO NXT fodboldspil.
De regler, som vi har valgt at følge, er beskrevet i nedenstående afsnit:

Materialer

De controllere, motorer og sensorer, der bruges til at samle robotterne skal være fra LEGO® MINDSTORMS sæt og HiTechnic (HiTechnic NXT IRSeeker V2 sensor og HiTechnic NXT Compass sensor).

Bane

Vi har fået stillet en plade fra et tidligere projekt til rådighed. Pladen har målene 115 cm x 217 cm og er udstyret med sidestykker, hvilket vi har tænkt os at udnytte som bander. Intentionen med dette er at forhindre de afbrydelser, der ødelægger flowet i spillet, hver gang bolden ryger ud. I følge beskrivelsen givet fra WRO, har vi fundet ud af, at det officielle underlag til banen, lavet af vinyl, kan tilkøbes[4]. Da vores fysiske rammer, som førnævnt er anderledes, har vi dog valgt, at vi vil lave vores eget underlag, hvilket også giver os mulighed for at eksperimentere med et alternativt underlag. Vi har bestemt at de farver, der skal være på banen, er grøn på de to sider (lysegrøn og mørkegrøn), sort i de to målfelter samt hvid på midtstykket af banen. Vi har overvejet enten at male disse farver på eller at lægge filt i de dertilhørende farver på som underlag. En skitse af banen kan ses nedenfor:

Illustration af vores bane

Ideen med de forskellige farver i siderne er, at man ved hjælp af en farvesensor kan afgøre, hvilken side man befinder sig i og kan bevæge sig imod midten i stedet for at køre ind i banden. Vi har også overvejet forskellige typer mål. Vi overvejer enten at male målene på endebanden eller at bygge en konstruktion i træ med to sidestolper og en overlægger, der kan placeres i hver sin ende af banen. Det er vigtigt at målene bliver meget brede, for at det ikke skal være umuligt at score. En konstruktion i LEGO virker ustabilt og overlæggeren komme til at hænge. Vi vil til næste gang få indkøbt filt, tape og andre materialer nødvendige for at konstruere banen. Selve konstruktionen vil vi påbegynde næste session.

Robot

Når det kommer til dimensionerne af robotterne, har vi besluttet stortset at følge kravene fra det officielle regelsæt. Dette indebærer, at en robot, der deltager i vores udgave af fodboldspillet, skal kunne være inden for en diameter af 22 cm, samt at højden af robotten er begrænset til 22 cm. Når en robot måles, skal den være i opretstående position og alle påmonterede dele skal være fuldt udfoldede. Desuden sigter vi efter, at vægten på robotten ikke må overskride 1 kg. Om vi rent faktisk kan holde os inden for disse dimensioner er noget, der vil vise sig, når vi påbegynder selve konstruktionen af robotten.
Selve styringen af robotten skal foregå autonomt, hvilket indebærer, at robotten skal startes manuelt, samt at det ikke er tilladt at fjernstyre robotten. Kommunikation mellem robotter på samme hold via Bluetooth er dog tilladt, sålænge at det ikke forstyrrer modstanderens robotter i en sådan grad, at det går ud over robotternes performance. Dette finder vi umiddelbart særlig interessant, da det gør det muligt for to robotter at spille sammen.
Robotterne må udelukkende bestå af det udstyr, der er nævnt under afsnittet materialer samt almindelige LEGO-klodser, som ikke må modificeres. Dette udelukker brugen af lim, tape samt skruer. Dog er tape tilladt i forhold til at holde styr på ledningerne, der bruges, i forbindelse med de førnævnte sensorer.
Når det kommer til de programmer, der må uploades på robotten, skal disse være programmeret i LeJOS, LEGO Robolab eller LEGO Mindstorms NXT-G. Omni-orienteret hjul er ikke tilladt, da det ville give den robot, der agerer som målmand, en alt for stor fordel, og dermed gøre det meget svær for modstanderen at score. Hvis man bruger en målmand, skal den derfor kunne bevæge sig i alle retninger. En målmand må godt godt bevæge sig ud af straffesparksfeltet, når den ser bolden i forbindelse for at opsnappe den.
Det er tilladt for en robot at "erobre" bolden, men den må ikke "holde" på bolden. Som det er defineret i de officielle regler fra WRO Soccer GEN II,  erobrer en robot bolden ved maksimalt at have kontrol over 3 cm af bolden, i.e. en robot må ikke have halvdelen af boldens diameter under sig. Det er et krav at bolden skal bevæge sig, når en robot er i besiddelse af den. En robot holder på bolden ved at tage fuld kontrol af over bolden, så den fjerner alle boldens grader af frihed, hvilket gør det umulig for andre andre robotter at få fat i bolden. Dog må man gerne bruge en driblemekanisme, der kan gøre det muligt at give bolden backspin, og hvor robotten slipper bolden i forbindelse med, at den skyder mod mål. Denne driblemekanisme, er vi særligt interesseret i at eksperimentere med for at se, hvor godt den kan bruges, både i forbindelse med at erobre bolden, samt at skyde mod mål. Vi forestiller os, at det bliver en udfordring, i forhold til disse regler, helt præcist at definere, hvornår en robot, bryder reglerne ved at holde på bolden.

Game Play

Vi forestiller os, at robotterne måles og vejes inden en kamp, og at de to hold, bliver enige om at alle robotter overholder de fysiske krav, der er til robotten. Der gives desuden tid til, at holdende kan kalibrere deres robotter, således de er tilpasset til at operere under de givne forhold. En kamp varer to halvlege, men vi har på nuværende tidspunkt ikke lagt os fast på, hvor lang tid en halvleg skal vare, da vi først vil se, hvordan en typisk kamp forløber sig på den bane, vi har lagt os fast på for at afgøre, hvor lang tid det giver mening at spille. Der byttes banehalvdel efter hver halvleg, og spillet bliver sat i gang, ved at hvert hold tænder deres robotter, samt at en uvildig person tænder for bolden og lægger denne ind på banen. Deadlocks, i.e. når en robot er låst i en position, den ikke kan komme ud af, efter at have prøvet på dette i omkring 5-10 sekunder, løses ved menneskelig indblanding, hvor hvert hold kun må løfte på deres egne robotter. Hvert scoret mål skal registreres og tælles op, når kampen er slut, hvor det hold med flest antal mål har vundet kampen.

Succesfuldt spil

Efter de forudgående undersøgelser, vil vi definere et succesfuldt spil ud fra nedenstående 4 principper:

1. Kontinuerligt spil: Spillet skal køre flydende, og der skal være så få afbrydelser som muligt. Dvs. et spil hvor der så sjældent som muligt, skal menneskelig interaktion til for at løse konflikter. Dette krav er dog ikke nok til et kontinuerligt spil. Robotterne skal ikke kun selv løse konflikten, men den skal også kunne gøre det indenfor en overskuelig tid. En overskuelig tid bør ses i sammenhæng med at en kamp typisk vil vare 10-20 min. og derfor vil 10-20 sekunders deadlock være i nærheden af et loft, for hvad vi ønsker.
2. Intelligent spil: For at øge deltagernes tid til at skabe robotter, der opfører sig intelligent, skal tidsforbruget på at fortolke sensormålinger minimeres. Dvs. at miljøet skal være så behjælpeligt, som muligt for robotterne, i forhold til at navigere rundt på banen, finde hinanden og finde målene, så muligheden for at udvikle en intelligent robot er til stede.
3. Simpelt spil: Det skal være hurtigt og overskueligt at læse og forstå reglerne.
4. Sjovt spil: Det skal være underholdende både for de konkurrerende hold samt tilskuere at se på spillet.

Tilsammen vil vi henvise til disse principper forkortet som KISS, eller blot ved at henvise til et succesfuldt spil.

Diskutere konstruktion af LEGO-robot

Vi har diskuteret hvilke fysiske krav, der skal stilles til robotten. Udover at regelsættet stiller en række krav, som vores robot skal overholde, har vi besluttet at forsøge at bygge en robot, der ligesom en levende fodboldspiller, kan bevare boldkontrol imens den "løber" hen over banen. Udfordringen bliver her at skabe en driblemekanisme, der ikke fikserer bolden (jf. regelsættet), men stadig sikrer, at vi ved, hvor bolden er i forhold til robotten.
Tanken bagved vores ønske om boldkontrol, er at det vil være meget svært at udføre avancerede strategier, hvis vi ikke er 100 procent sikre på, hvor bolden er. Dette bliver en stor udfordring, da vi gerne vil være i stand til at stoppe op uden at bolden triller fra os.
En anden overvejelse er, hvor vigtigt det er at kunne skyde hårdt med robotten. Vores umiddelbare plan er at negligere dette aspekt en smule. Vi vil forsøge at bygge en robot, der i stedet for at skyde en hård bold, kan skyde en præcis bold, og uddrible modstanderen. Tanken her er, at uanset hvor hårdt vi får skudt, så vil målmanden stadig stå i vejen, hvis vi ikke har udmanøvreret ham, hvilket gør styrke irrelevant.
Det sidste punkt er derfor hastighed. Vi vil have en hurtig sprinter, da hastighed i virkelig fodbold er en af de primære faktorer for hvilket hold, der vinder. Dette betyder en gearing, der er stor nok til at tillade sprint, men samtidig er præcis nok til, at vi kan udføre vores strategier.

Konklusion

Vi har analyseret WRO GEN II Football spillet og derudaf udledt, hvilket materiale, vi skal bruge til at konstruere banen samt gjort os nogle indledende overvejelser omkring de eksperimenter, vi vil udføre. Ud fra dette ved vi, hvad der skal købes ind, så vi kan have det klart til næste lab-session. Dette har vi fremlagt for den anden gruppe, der også arbejder med fodboldspillet.
Endvidere har vi haft en indledende diskussion af konstruktionen af robotten, så vi kan påbegynde denne næste gang. Planen er dog, at diskussionen fortsætter sideløbende med konstruktionen af robotten de kommende sessioner.
Til udviklingen af software til robotten, har vi sat et SVN projekt op, så vi nemt kan dele koden.

Referencer

[1], http://wro2013.org/challenges/challenges-football
[2], WRO2010 GENII
[3], http://www.teaching.com.au/product?KEY_ITEM=ROB010&KEY_ALIAS=ROB010&gcsct=0ChMIuJbcy-L-twIVsgu0Ch26aAAAEAQ

Week 12

Dato:

16-05-2013

Varighed:

Fælles lab: 4 timer

Blog: 3 timer

Deltagere:

Steffen Høi
Nikolaj Mols Hansen
Martin Vang
Ulrik Sahl Lystbæk

Status

Vi har lavet en beskrivelse af tre mulige eksamensprojekter (Shooting LEGO Tower, LEGO Mindstorms meets Kinect samt WRO Soccer Gen II), samt nogle af de umiddelbare udfordringer ved hvert projekt.

Mål

Målet med denne laboratoriesession er at lave den forberedelse af eksamensprojektet og derigennem udarbejde en beskrivelse af de mulige projekter, som vores gruppe vil arbejde med. Som en del af dette skal vi udarbejde en beskrivelse af nødvendig hardware og software platformen for hvert projekt samt en analyse af de problemer, vi på nuværende tidspunkt kan se, som værende de største udfordringer ved hvert projekt. Målet er desuden at udvælge hvilket projekt, vi skal arbejde med og lave en mere detaljeret beskrivelse af dette, samt udfærdige en plan for arbejdet med eksamensprojektet.

Plan

• Undersøge forskellige muligheder for projektet
• Beskrivelse af de forskellige projekter
• Valg af projekt
• Udarbejdelse af plan for eksamensprojektet
• Udarbejdelse af blog for denne laboratoriesession

Proces

Shooting LEGO Tower

Dette projekt går ud på at lave LEGO-robotten om til et tårn (evt. på hjul så det kan køre rundt). Det er meningen, at robotten skal danne sig et overblik over dens omgivelser, identificere mål og skyde dem.
Der skal bygges en skydemekanisme samt udvælges objekter, der skal skydes afsted. Disse objekter kunne være bolde eller alternativt små stykker LEGO, alt efter hvilke der giver den mest konsistente affyring. Dette ville kræve noget eksperimentering. I det hele taget må der planlægges en del bygge- og testtid ift. fysiske aspekter af dette projekt.
En simpel måde at finde mål på er at søge efter genstande vha. en ultrasonisk sensor. Denne metode kunne evt. udvides med en laser-pind og et kamera, som tilsammen kunne bruges til at udregne afstanden til f.eks. røde mål (trigonometri; afstand imellem kamera-linse og lys-pind er kendt). Herunder er en illustration af hvordan centrum af et billede kunne se ud ift. den røde prik fra laseren.

Billede med laser-prik

En fordel ved at bruge et kamera er, at mål lettere vil kunne identificeres og adskilles fra omgivelser vha. billedbehandling. Dette er dog også en ulempe, da denne del hurtigt kan komme til at tage meget tid.

LEGO Mindstorms meets Kinect

En anden idé vi fik til et projekt var at inddrage Kinect. Kinect er en bevægelsessensor fra Microsoft, der fungerer både til Xbox 360 og PC. Sensoren har et kamera og infrarød kamera og en speciel mikrochip bygget til at følge objekter i et 3D rum. Det betyder, at den er yderst effektiv til at genkende og følge objekter i et 3D miljø. Vores idé var benytte Kinect som en high-end sensor, der skulle kobles til en computer. Computeren med sensoren ville kommunikere med Mindstorm over en bluetooth forbindelse. Kinect og computer kunne enten monteres sammen med LEGO Mindstorm robotten eller et eksternt sted og fungere som et All-Seeing Eye". Ideen var så at kombinere Mindstorms lav-niveau sensorer med Kinecten. Vi har overvejet ideer, som at montere Kinecten på robotten og lade den køre rundt og mappe et rum i 3D. Næste gang vil den så kunne undersøge om nogle af genstandene i rummet er flyttet rundt på. Det kan være, at robotten kortlægger et rum, der er ryddet op, og så kan den løbende køre rundt og undersøge, om rummet er blevet efterladt i opryddet tilstand. Vi har også overvejet at bruge mennesket som en human controller for robotten, hvor Kinecten fungerer som et All-Seeing Eye, der tracker en person. Personens bevægelser sendes så videre til robotten, som mapper disse bevægelser til handlinger.

WRO GEN II Football

WRO GEN II Football er en konkurrence inden for World Robotic Olympics. Dette projekt går ud på at spille fodbold med selvstyrende LEGO Mindstorms robotter, hvor en kamp varer 10 minutter og består af 2 hold, der hver skal have 2 spillere. Den officielle bold, der bruges, er IR Ball fra HiTechnic.
Der eksisterer en række regler, som skal overholdes primært ift. fairplay. Derudover er der en bane som ligeledes skal være statisk, hvilket vi ved potentielt kan være en god forudsætning for at lave en delvis sekventiel løsninger, som vi gjorde det i "Week 8"[w8 link.]
Da et hold må have to LEGO-robotter på banen er vores umiddelbare tanke, at den ene skal agere målmand og den anden markspiller, og i den forbindelse lade LEGO-robotterne have en mængde af adfærd, de skal skifte imellem alt efter, hvordan forholdene ændrer sig. Grunden til at en ren sekventiel adfærd ikke kommer til at fungere er, at der er andre spillere, som vi ikke kender adfærden af samt en bold, der kan være et hvilket som helst sted på banen. Disse skaber et meget dynamisk miljø, som robotterne skal kunne reagere i. Derfor går vi ud fra at en adfærdsbaseret robot vil fungere bedre, hvilket skal undersøges nærmere i løbet af projektet.

Valg af projekt

Efter at være blevet gjort opmærksom på muligheden for at lave WRO GEN II Football projektet af forelæser og set den officielle beskrivelse af spillet[WRO-side], valgte vi gå videre med dette som eksamensprojekt. Eftersom vi er 4 medlemmer i gruppen, er det en stor fordel, at dette projekt kan deles op i to dele, hvor den ene del indebærer at konstruere og programmere den LEGO-robot, der skal agere markspiller og den anden del indebærer programmering og implementeringen af målmanden. De officielle regler fra WRO er ret kompliceret og nogle af dem virker overflødige, så en del af opgaven ved dette projekt er også at udvikle vores eget regelsæt baseret på de officielle regler fra WRO13. Alt dette blev afgørende for valget af WRO GEN II Football, som det endelige eksamensprojekt.

End Project - detaljer

I vores slut-projekt skal vi bruge følgende ting:
- 2 NXT LEGO-sæt
- 1 IR Ball fra HiTechnic
- 1 bane der overholder reglerne. Evt. filtbelagt for at mindske boldens evne til at trille væk.
- 1 regelsæt baseret på de officielle regler fra WRO13.

Her er et billede af den originale beskrivelse af hvordan banen ser ud:

Vi antager, at det kommer til at være en udfordring at få robotterne til at kunne "holde på bolden", så de kan drible samtidig med, at de ikke må kontrollere bolden 100%. En anden udfordring er at finde på strategier, som robotterne kan benytte for at lave mål i den korrekte ende af banen. Vi forventer at kunne lave en kamp imod enten os selv med forskellige strategier/adfærd for de 2 hold, eller spille en kamp imod en anden gruppe med samme projekt.

Plan for arbejdet med projektet

Vi har ud fra beskrivelsen af projektet og de tanker, vi har gjort os i den sammenhæng lavet nedenstående foreløbige plan. Vi regner med, at den bliver udviddet efterhånden, som arbejdet med projektet skrider frem, og vi får mere indsigt i de reelle problemstillinger.

• Week 13
•  Analyse af WRO GEN II Football.
• Udarbejdelse af regelsæt for WRO GEN II Football.
• Planlægning af opbygningen af fodboldbanen.
• Diskutere konstruktionen af LEGO-robotterne.
• Week 14
• Opbygning af fodboldbanen.
• Påbegyndelse af konstruktion af LEGO-robotterne.
• Det udarbejdede regelsættet skal være komplet. 
• Week 15
• Påbegyndelse af programmering af software til robotter.
• Test LEGO-robotterne i en kamp.
• Forberedelse af fremlæggelse.
• Week 16
• Produkt til præsentation skal afsluttes.
• Opsamling.
• Week 17
• Præsentation forberedes og afholdes.

Det har været svært for os at planlægge specifikke dage, hvor vi har tænkt os at arbejde med projektet, men vi har forsøgt at skrive de opgaver ned, vi regner med at nå de forskellige uger inden projektets deadline. I planen er der taget højde for, at alle medlemmerne af gruppen har eksamener i den sidste uge op til deadline, og arbejdet med projektet skal derfor være afsluttet inden da.

Konklusion

Denne uge har vi lavet de forberedende opgaver til arbejdet med eksamensprojektet. Vi har diskuteret og beskrevet tre mulige ideer til projektet og kigget på de forskellige hardware- og software teknologier, der skal bruges til hver enkelt projekter. Desuden har vi kigget på hvilke udfordringer, der vil komme i forbindelse med de forskellige projekter. Ud fra dette har vi valgt at arbejde med WRO GEN II Football, som vores eksamensprojektet. Et par væsentlige udfordringer ved dette projekt bliver at sortere i det officielle regelsæt fra WRO13, samt at få lavet en driblemekanisme til robotten. Vi forudser desuden også, at det bliver en udfordring at implementere robotternes adfærdsbaserede strategier. Særligt bliver det en udfordring at beslutte hvordan disse strategier skal skifte. Afslutningsvis har vi lavet en plan for det kommende arbejde med projektet.

Week 11

Dato:

02-05-2013

Varighed:

Fælles lab: 5 timer

Blog: 3 timer

Deltagere:

Steffen Høi
Nikolaj Mols Hansen
Martin Vang
Ulrik Sahl Lystbæk

Status

Vi har bygget vores LEGO-robot om til en BumperCar, og undersøgt, hvordan en adfærdsbaseret arkitektur er blevet implementeret i subsumption APIet af leJOS NXJ.

Mål

Målet med denne laboratoriesession er at lave opgaverne for "Week 11 - Motivation based behaviour selection in agents"¹ og derigennem undersøge hvordan en adfærdsbaseret arkitektur er blevet implementeret i subsumption APIet af leJOS NXJ, særligt interfacet lejos.subsumption.Behavior og klassen lejos.subsumption.Arbitrator. Det er desuden også et mål at se på, hvordan man laver en alternativ implementering af Arbitratoren, samt at udarbejde et blogindlæg for denne laboratoriesession.

Plan

• Løse opgaverne for "Week 11 - Motivation based behaviour selection in agents"¹.
• Udarbejdelse af blogindlæg for "Week 11 - Motivation based behaviour selection in agents"¹.

Opgaver

BumperCar

I denne opgave skal vi bruge leJOS APIet's Arbitrator og Behavior klasser til at afprøve prioritetsbaserede adfærd. Opgaverne tager udgangspunkt i BumperCar eksemplet fra leJOS's NXT sample-applikationer, og de klasser vi har ændret i er BumperCar.java² og Arbitrator.java³. Nedenstående billede viser, hvordan vores LEGO-robot ser ud, i forbindelse med, at vi har monteret en touch sensor.

• Det der sker, når touch sensoren rammer noget, er at adfærden DetectWall bliver aktiveret, hvilket får robotten til at bakke og dreje en lille smule. Hvis touch sensoren holdes nede, fortsætter denne adfærd, hvilken kan ses på videoen nedenunder:

• Vi har implementeret adfærden Exit, der reagerer på ESCAPE-knappen og kalder System.Exit(0) efter samme princip som DriveForward og DetectWall er lavet. For at give Exit adfærden højeste prioritet, er den sat sidst ind i listen over adfærd, som sendes med til Arbitrator. Desuden har vi tilføjet til DetectWall, at den ikke skal tage kontrol, når den er undertrykt.
• Arbitrator bliver ved med at give DetectWall kontrollen, så længe touch sensoren er trykket ned, eller sonaren er inden for 25 cm. Dette betyder, at DriveForward ikke bliver udført, hvilket medfører at takeControl i DriveForward ikke kaldes.
• I DetectWall har vi tilføjet en tråd, som startes i når DetectWall instantieres. Det eneste tråden gør er at opdatere et globalt felt til sonar distancen ved at foretage en ny måling. Tråden venter 20 ms. mellem målinger. I takeControl bruges det globale felt med sonar distancen.
• For at tilføje handlingen at køre bagud 1 sekund i DetectWall før der drejes, har vi tilføjet et loop inden, som fortsætter, indtil den bliver suppressed, eller der er gået 1 sekund.
• Den måde vi har fået vores robot til at reagere på, under udførslen af DetectWall er ved, at tjekke på om touch sensoren rammer noget, mens handlingen udføres, i DetectWall's action metode. Hvis den rammer noget stopper vi handlingen. Nedenstående video viser hvordan LEGO-robotten opfører sig efter dette.

Motivation Functions

Denne opgave omhandler at implementere en modificeret udgave af vores BumperCar, der er istand til at afbryde handlingen DetectWall med endnu en DetectWall, når robotten er kommet til et bestemt punkt i sin undvigelse af væggen. Med udgangspunkt i Thiemo Krink's motivation functions⁴, er der i Behavior.java⁵ ændret på interfacet Behavior, så takeControl returnerer en motivation value. Arbitrator.java⁶ er implementeret således, at den adfærd med den højeste motivation value bliver aktiveret hver gang ved loopet. I BumperCar.java⁷ er der ændret på de forskellige adfærd; DriveForward, DirectWall og Exit, så takeControl returnerer motivation values.
Som takeControl er implementeret, er bilen er istand til at afbryde sin egen DetectWall vha. en lavere motivation value, når den er i gang med at udføre undvigelsen. Den værdi, der returneres, afhænger af om DetectWall er aktiv eller ej. Disse detaljer er implementeret i koden, hvor DetectWalls prioritet normal er 100, men kun 50, hvis den allerede er aktiv.

Konklusion

Denne uge har vi eksperimenteret med den adfærdsbaseret arkitektur, der er blevet implementeret i subsumption APIet af leJOS NXJ, særligt interfacet lejos.subsumption.Behavior og klassen lejos.subsumption.Arbitrator. Som et eksempel på et adfærdsbaseret kontrolprogram, har vi arbejdet med BumperCar programmet, der er en del af leJOS NXJ og i forbindelse med dette, har vi bygget vores LEGO-robot om, så den nu har en touch sensor monteret. I den forbindelse har vi kigget på hvordan de to adfærd DriveForward og DetectWall er implementeret og eksperimenteret med funktionerne i Arbitratoren til at kontrollere de forskellige typer adfærd. Vi har desuden kigget på, hvordan man kan reaktivere en sekvens af handlinger med udgangspunkt i motivation functions, som beskrevet af Thiemo Krink.

____________________________________________________________________________________________________________

1. http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson10.dir/Lesson.html
2. https://www.dropbox.com/s/yyxphpzp57tifbn/BumperCar.java
3. https://www.dropbox.com/s/v52to8dudhib7po/Arbitrator.java
4. Thiemo Krink(in prep.). Motivation Networks - A Biological Model for Autonomous Agent Control.
5. http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson10.dir/Behavior.java
6. http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson10.dir/Arbitrator.java
7. http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson10.dir/BumperCar.java