Friday, May 31, 2013

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


Thursday, May 30, 2013

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

Tuesday, May 28, 2013

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

Thursday, May 23, 2013

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

Tuesday, May 21, 2013

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