Week 17

Dato:

03-06-2013

Varighed:

Fælles lab: 1 time

Blog: 7 timer

Deltagere:

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

Mål

Målet med denne session er at præsentere vores projekt på en grundig og underholdende måde, hvor vi alle fik en væsentlig del at gennemgå, samt at opsummere projektet og skrive konklusion.

Præsentationen

Vores præsentation forløb med en meget hurtig gennemgang af, hvad der kan forventes af disse blog-indlæg, samt en fodboldkamp imod en anden gruppes fodboldrobotter. Under kampen blev det meget tydeligt for os, at vores beslutning om hastighed var en god plan. Vi havde boldkontrol i en utrolig stor del af tiden. Desværre oplevede vi, at vores robotter blev "forvirrede", når de skulle skyde. Vi tror, at det måske kunne skyldes de mange motorer, der var i nærheden af robotterne, som kompassene ikke var kalibreret til. Det blev i hvert fald ret tydeligt, at vi havde et stort problem, da kampen endte med et selvmål fra en af vores robotter, hvilket ikke var noget vi havde observeret, da vi "kun" havde vores 2 egne robotter på banen. Vores robot skød ikke helt præcist men den skød dog præcist nok i alle vores tidligere forsøg til at skyde bolden ned mod modstanderens mål med højst en 45 graders afvigelse i retningen. Det kunne være interessant at undersøge nærmere, om det var kompasset, der blev forstyrret, eller om det var noget andet, men desværre når vi det ikke i dette projekt.

Produkt

Den samlede kode, som det endelige program består af kan ses her LEGO Soccer [1]. Vi har desværre ikke en færdig byggevejledning til robotten, så hvis man vil lave en lignende, må man forsøge sig ved at se billeder og vejledninger gennem alle blogindlæg. Banen står indtil videre stadig i LEGO lab.

Sammendrag af observationer og eventuelle forslag til udbedringer

Vores konklusion er opbygget således at vi først gennemgår de erfaringer vi har gjort os gennem projektet og herefter præsenterer vi en række ændringsforslag, hvis formål er at skabe et spil, der opfylder KISS-principperne defineret i ”Week 13” [2].
I dette afsnit gennemgår vi nogle observationer, vi har gjort os gennem forløbet som vi synes er relevante i forhold til KISS-principperne defineret i "Week 13" [2]. Til nogle af de observationer der nævnes som forstyrrer KISS-principperne kommer vi med forslag til hvordan vi tror spillet kunne forbedres.

Banen

Underlag

Som underlag havde vi valgt filt af den årsag, at vi ville forsøge at skabe spin i bolden (inspiration fra billardborde). Vi fik dog ikke eksperimenteret nok med at skabe spin i forhold til at kunne konkludere, at filt ikke ville være en fordel i forhold til andet underlag. Det var en skam, da spin i bolden ville have understøttet princippet om et sjovere spil for tilskuerne.

Farver

Ud fra de farver, der er på banen, er det ikke lykkedes os at afgøre, hvor på banen robotten befinder sig. Vi kom dog frem til at farvesensoren med en kappe, kan foretage målinger, der er præcise nok til at vurdere, hvilket farvefelt robotten er på.
Selvom det med en kappe på farvesensoren kan afgøres, hvilket af felterne på banen robotten befinder sig  på, fortæller det ikke meget om robottens præcise lokation på banen fordi de farvede felter er store. De to grønne strækker sig hele vejen fra den ene ende af banen til den anden.
Fordi vi har fået så nøjagtige målinger med farvesensoren som vi har "Week 16 session 2" [3], mener vi at det kunne være til stor hjælp at farve banen ved at lave en graduering fra helt lys til mørk i længden af banen og fra rød til blå på bredden af banen. Således at banen er bygget op af farvede felter rektangler, således at farvesensorens målinger kan bruges til at vurdere ret præcist hvor på banen robotten befinder sig. På figuren nedenunder ses idéen, men hvis det skulle laves rigtigt, kunne det være, der skulle flere felter til, alt efter hvor godt farvesensoren kan skelne disse.

Grov farveinddeling af felterne på banen

Vi tror, at en sådan farvning af banen kan hjælpe til et intelligent spil, da deltagerne ville have betydeligt lettere ved at finde robotternes positioner på banen og dermed kan bruge tiden på at anvende robottens position til forskellige ting, i stedet for at bruge tiden på at finde på måder til at udregne robottens position.

Bander

Vi har erfaret, som gennemgået i dette blogindlægs referat af præsentationen, at banderne er årsag til at der kommer deadlocks i spillet samt klumpspil langs banderne, hvilket krævede menneskelig indblanding for at spillet kunne fortsætte. Dette går imod princippet om et kontinuerligt spil.
Banderne blev netop indført for at understøtte et kontinuerligt spil. Da de ikke hjælper til dette, er de ikke til gavn, men det bliver den originale udgave af banen ikke bedre af.
En af de ting, vi ville have gået videre med, hvis vi skulle fortsætte med spillet var at lave skråninger i kanterne af banen. Det skulle ikke være tilladt for robotterne at køre op af skråningerne. Formålet med skråningerne ville være at bolden triller tilbage på banen af sig selv, uden at den skal flyttes tilbage på banen, hver gang den ryger ud over kanten.

Mål

Målene er statiske objekter, der intet betyder for robotterne "Week 16 session 1" [4]. Dette bryder vores princip om intelligens, kontinuerlighed og simple regler. Alle disse skal nøje vurderes og overvåges af mindst 1 dommer, der både skal holde styr på point, dømme om der er mål og overvåge alle andre aspekter af spillet.

En udbedring kunne være en måltæller, som informerer alle robotterne hver gang der bliver scoret, hvis der bliver givet et penalty-point, samt hvis der gives et bonus-point. Disse beskeder vil kunne bruges af robotterne til at ændre deres strategier, samt ved mål, at køre tilbage på deres start-positioner og afvente nyt kick-off.

Robot

Hastighed

Pga. gearing har vi kunnet få vores robot til at køre hurtigt, hvilket vi synes gjorde spillet sjovere at se på. Desværre gik det ud over princippet om kontinuerlighed, da robotterne ofte kolliderede og konsekvenserne heraf var at vi ofte var nødt til at bryde ind for at spillet kunne fortsætte. Dette var også imod reglerne om at man ikke må sabotere modstanderens robotter.

Kompas

Kompasset opførte sig generelt godt, men under kampen mod det andet hold, oplevede vi, at vores robot havde svært at finde den rigtige retning. Dette mistænker vi skyldes, at kompasset blev forstyrret af de mange robotter på banen. Dette gør det svært at overholde princippet om et intelligent spil, når måleinstrumentet ikke opfører sig konsistent.

Her vil vi henvise til vores tidligere forslag med en farvning af banen i adskillige rektangler, da en sådan ville kunne bruges til hele tiden at holde styr på hvor på banen robotten ca. befinder sig og dermed også have viden om i hvilken retning målene er.

Driblemekanismen

Driblemekanismen opfyldte dens formål. Faktisk fungerede den bedre end hvad spillet kunne holde til. Dette var mindre sjovt at se på, da det kombineret med robottens hastighed, gjorde det svært for konkurrerende robotter at erobre bolden. Dette var med til at ødelægge det kontinuerlige spil fordi robotten holdt så lang tid på bolden, at de ofte stødte sammen. Ydermere medførte det, at spillet blev knap så sjovt at se på.
Af løsningsforslag til dette har vi at der kan indføres en regel om at en robot højst må holde på bolden i en vis tid, f.eks. 2 sekunder. Et andet alternativ kunne være slet ikke at tillade robotten at holde på bolden på nogen måde. Det ville ændre spillets stil en del da alle robotter ville være nødt til kun at støde ind i bolden. På denne måde skal robotterne hele tiden finde den rigtige vinkel at køre ind i bolden fra. Hvis en robot befinder sig på den forkerte side af bolden i forhold til hvor den skal score skal den køre rundt om bolden før den kører ind i den. Det kunne være et spændende eksperiment at udføre, for det er ikke til at forudse om det er en god idé. Det kan skabe store problemer, hvis robotterne i praksis hele tiden kører ind i hinanden, når de kører rundt om bolden for at finde den rigtige position til at køre ind i bolden fra. På den måde ville robotterne måske sjældent ramme bolden, og det ville være et kedeligt spil.

Skud

Vi har observeret at robottens skud ikke var hårdt og præcist nok, samt at det tog for lang tid at forberede et skud. Dette medførte, at der var for mange sammenstød og den lave styrke ved et skud gjorde at robotten kunne nå at opfange dens eget skud, hvilket gjorde spillet mindre sjovt og kontinuerligt.

Dimensioner og vægt

Vi har kunnet overholde kravene fra det officielle regelsæt mht. dimensionerne af robotten. Vi var dog af den opfattelse, at kravet om vægten om vores robot, var overskredet. Ved senere vejning af robotten har vi dog fundet ud af at robotten vejer 944 g, hvilket opfylder 1 kg – kravet.  Vi observerede at robotternes størrelse dog var et problem ift. Banens størrelse. Det viste sig at være særdeles svært at lave mål ved blot at stille en slukket robot i målet. Dette går imod vores princip om et sjovt spil.

Konklusion

Projektet har mange løse ender, der kunne fyldes ud samt helt nye idéer, vi slet ikke har afprøvet. Det var, hvad vi forventede, fordi der ikke er nogen afgrænsning af hvor regelsættet til fodboldspillet kan tages hen. Vi har afprøvet mange ting deriblandt kompas, IR-sensor, kørt robotter på filt underlag og spillet på en fodboldbane med bander. Derfor synes vi at projektet er kommet derhen, hvor vi ønskede.
Vores eksperimenter med reglerne har ledt os frem mod, at det vil være fornuftigt at have en fast bygge-vejledning som alle mere eller mindre skal overholde, jf. vores sumo-robot uge [5]. Dette vil have en lang række fordele, der fint indsamler mange af punkterne ovenfor, samt vil gøre regelsættet betydeligt nemmere at arbejde med. Byggevejledningen kunne evt. være fra forrige års vindere, så alle eventuelle modifikationer der gav dette hold en fordel, vil blive udlignet fremover. Ideen bag dette er, at et regelsæt ellers naturligt vil eksplodere i kraft af alle de kreative ideer, der bliver afsagt dom om fra år til år. Ved at have en standard robottype som alle skal følge kan reglerne skrives simplere. F.eks. kan alt med dimensioner af robotten slettes. Den næste væsentlige ændring er, at banen skal kunne aflæses med sensorer så det er lettere at finde robotternes position, således at deltagerne kan koncentrere sig om at få robotterne til at opføre sig intelligent. Der er rigeligt udfordring ved at lave smarte måder for robotterne at udmanøvrere hinanden på, uden at tilføje besværet ved at give dem usikkerhed på hvor de er på banen. Uden præcise målinger for hvor robotten er, er det umuligt at lave tilstrækkeligt intelligente beslutninger for robotten, til at det virker som andet end tilfælde hvem der vinder. Dette bekræftes af at det virker langt mere tilfældigt hvad markspilleren laver sammenlignet med målmændene, når vi ser på en mesterskabskonkurrence. Dette er fordi målmændene har gode muligheder for at udlede deres egen position, sammenlignet med markspillerne. Markspillernes typiske strategi er at køre i en lige linje for så at skyde så hårdt som muligt på mål. En kombination af mål-tæller der informerer om mål, samt graduering af banen vil give robotterne et meget bedre billede af hvilket miljø de bevæger sig i, og måltælleren vil endda give dem mulighed for at lære af deres fejltagelser, og deres mål fortælle dem hvor god deres nuværende strategi er.

Hvis andre vil lave et lignende projekt om WRO GEN II Football [6] er vores forslag i betragtning af ovenstående, at koncentrere sig om at ændre banen, så den er lettere at aflæse frem for at bruge tid på at aflæse på den, som den er bygget nu. Vi vil også foreslå at bruge en standard robottype frem for at formulere et regelsæt, der tager højde for alle udgaver folk kan finde på, hvilket også ville sætte selve programmeringen mere i fokus.

Referencer

[1], https://www.dropbox.com/sh/py0lfofp42zjydx/ncrrnxFMth/LEGO%20Soccer
[2], http://digikaison.blogspot.dk/2013/05/week-13.html
[3], http://digikaison.blogspot.dk/2013/06/week-16-session-2.html
[4], http://digikaison.blogspot.dk/2013/06/week-16-session-1.html
[5], http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson8.dir/Lesson.html
[6], http://wro2013.org/challenges/challenges-football

Week 16 - Session 2

Dato:

04-06-2013

Varighed:

Fælles lab: 8 timer

Blog: 5 timer

Deltagere:

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

Status

Farvesensor og angrebstrategier er ikke færdige, og robotten er endnu ikke klar til at blive præsenteret.

Mål

Målet med denne laboratoriesession er at lave robotterne færdige, så de er klar til vores præsentation.

Plan

• Oprydning i adfærdshierarki.
• Forbedringer af adfærd
• Aim
• Shoot
• Angrebsstrategier
• Montering af isolering på farvesensoren og test med denne

Proces

Adfærdshierarki

Efter at have kigget på på vores tidsplan i forhold til de udfordringer, vi havde med farvesensoren, har vi ændret vores adfærdshierarki til nedenstående. Vi har valgt at droppe de forskellige angrebsstrategier, der skulle bruge farvesensoren, for i første omgang bare at fokusere på det at sigte og skyde mod mål lige når robotten har fået bolden.

Illustration af adfærdshierarki

Vi har en delvis færdig implementering af strategi-arbitrator, men valgte i første omgang at droppe den, indtil vi har mere end Aim-Shoot strategien, hvilket forudsætter bedre information om positionering. Tanken er at lade denne arbitrator håndtere. hvilke strategier der skal vælges til eksekvering, for så at lade de individuelle strategier kunne skifte prioritet indbyrdes ift. hvad robotten erfarer.

Aim

Ved denne adfærd har vi forsøgt at benytte en PID-controller for at mindske oscillering, i forbindelse med, at robotten prøver, at finde den rigtige vinkel. Tilpasningerne var dog større end, hvad vi havde tid til, så vi valgte i stedet en simpel løsning, hvor Aim har en skalering på hastigheden, således at denne bliver sat ned, jo tættere robotten kommer på den rigtige vinkel.

Diskussion af rotation af robot, til venstre, samt skitse af strategier til højre

Herover ses en af vores overvejelser ift. vores Aim, der går ud på altid at rotere den korteste vej imod vores "falske Nord". Denne ide blev implementeret, hvilket potentielt set, halverer vores rotationtid for Aim, der dog stadig er noget langsom.

Shoot

Vores problem med skydemekanismen var, at vi nogle gange fik udført to skud i træk. Dette problem blev løst ved at lave en buffer af læste værdier, og så kun påstå, at vi har bolden, hvis touch-sensoren har været berørt de sidste par målinger.

Touch-sensor samt berøringsflade for bolden

Som det måske kan ses herover, har der været en del trial-and-error ift. at få sat den lille grå brik sådan at boldens runde flade falder korrekt ind og trykker på den, uden at den lille brik pga. touch-sensoren's fjeder yder for stor modstand. I sidste ende havde vi en særdeles stabil, omend noget skrøbelig løsning, der præcist kunne fortælle, om bolden var i robottens greb.

Angrebsstrategier

Efter at robotten er begyndt at kunne leve op til de forskellige sensorer vi havde stillet for øje, er vi begyndt at analysere, hvordan vi kan udnytte dette fremadrettet. De vigtigste teknikker vores robot nu besidder er følgende:

• Opnå kontrol over bolden.
• Drible med bolden.
• Afslut med bolden imens den er i besiddelse.

Det er primært de samme egenskaber en menneskelig fodboldspiller har, og vi vil kigge på hvordan sammenspillet af disse teknikker kan sikre den bedst mulige succesrate. Herunder vil vi fokusere på, hvilke muligheder vi har, ud fra kompas og farvesensor, til at bestemme vores position. Ud fra denne position kan vi begynde at diskutere strategier. Hvis vi befinder os i en af de sorte målfelter og har bolden, vil vi have svært ved at fastslå, hvilken af de to målfelter vi befinder os i. Vi har muligheden for at køre mod modstanderens mål og undersøge, om vi rammer den hvide region. Hvis dette er tilfældet ved vi, at vi befinder os i vores eget felt, men hvis vi befinder os i modstanderens felt, vil vi køre ind i målet i stedet. Derfor vil vi altid skyde mod mål, hvis vi har bolden i en sort region. Enten vil vi stå i modstanderens målfelt og afslutte, ellers vil vi stå i vores eget felt og skyde bolden væk. Hvis vi står i en af sideregionerne, vil vi bevæge os imod midten. Midten kan beregnes ud fra, hvilken vi læser og kompas sensoren (i eksemplet nedenfor, vil mørkegrøn altid være vores højre bane, og lysegrøn altid venstre). Hvis den næste region vi rammer ind i er en sort region, så vil vi ligesom før (vist med røde pile) skyde mod mål, da vi stadig ikke ved, hvilken ende vi befinder os i.

Skitsering af overvejede strategier

Hvis den region vi bevæger os ind i, når vi bevæger os imod midten, er den hvide region, eller hvis vi allerede befinder os i den hvide region når bolden findes, så vil vi bruge enten den blå eller gule strategi vist på billedet. Den blå strategi går ud på at bevæge sig over i den ene side og udnytte vores robots hurtighed til at køre tilbage i den modsatte region og afslutte i retning mod mål. Den blå strategi går primært ud på at få modstanderens robot til at bevæge sig imod den ene side, og så bruge vores hurtighed til at udmanøvrere modstandernes robot. Vi forventer at modstanderens robot primært vil rette sig efter bolden, og har næppe mulighed for at tage forbehold for at vi vender. Vores ide er, at modstandernes robot ikke er hurtig nok til at komme på plads efter vores finte, så vi kan skyde bagom den. Den gule strategi går ud på hurtigt at køre over i den ene side og afslutte, og derved gribe modstanderens robot ude af position, specielt hvis man kommer fra den modsatte side. Alle strategier kan udnyttes fra begge sider, hvor strategierne spejlvendes i forhold til illustrationen.
Den overordnede ide bagved disse to (gul og blå) strategier er, at vi hvis vi fik tilbagemelding om succes/fiasko fra vores miljø, nemt ville kunne oparbejde en præference. Vi forventer ikke at vores modstanders robot, der jf. reglerne kun må køre direkte imod bolden, og derfor ikke parere med siden, vil være i stand til at blokere begge strategier lige godt.

Monter isolering på farvesensoren og test med denne

For at mindske påvirkningen af lys fra miljøet lavede vi isolering til, at have rundt om farvesensoren. Vi lavede den i første omgang i pap, da det gik noget hurtigere end at bygge et mørkekammer i LEGO. Formålet var, at se om vi kunne få gode nok målinger til, at det kunne betale sig at bygge en i LEGO, da regelsættet dikterer, at alt på robotten skal være af LEGO komponenter.

Kappe til isolering set nedefra

Efter isoleringen, med en kappe af pap, var sat på foretog vi nye målinger i banens fire forskelligt farvede felter. Målingerne var denne gang følgende:

• Mørkegrøn: 145 +- 5
• Lysegrøn: 288 +- 5
• Sort: 83 +- 5
• Hvid: 432 +- 5

Måledata med isolerende kappe

Konklusion

Med isolering mod lys fra miljøet monteret på farvesensoren, gav det meget stabile målinger. Den maksimale forskel, vi fik i målinger på ét felt var 10 , hvorimod den var 164 før vi havde lavet isoleringen. Udover at målingerne var stabile, så var der også stor forskel på de fire forskellige felter. Derfor kunne farvesensoren på denne måde godt bruges til at kende forskel på felterne. Desværre kom dette på plads så sent, at vi ikke kunne nå at implementere angrebsstrategier baseret på denne nye information.
Robotterne er nu klar til at blive præsenteret, og projektet mangler kun præsentationen samt redigering af blogindlæg.

Week 16 - Session 1

Dato:

03-06-2013

Varighed:

Fælles lab: 7 timer

Blog: 7 timer

Deltagere:

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

Status

Vi har ikke brugbare målinger med farvesensoren. Den endelige robottype er besluttet, så der fra nu af kun er plads til finjusteringer af denne.

Mål

Målet for denne laboratoriesession er, at begge robotter skal være færdigbygget, og at det nu kun er finjusteringer af designet, der mangler. Endvidere skal der laves eksperimenter med tryksensoren for at finde ud af, om denne medfører at robotten bedre kan registrere, at den er i besiddelse af bolden end den kunne med den ultrasoniske sensor. Desuden skal de forskellige adfærd sættes sammen, så de to robotter kan spille mod hinanden.

Plan

• Færdigbyg og finjuster robotter.
• Byg måltællere som NXT'er.
• Diskuter om der mangler noget for robotternes konstruktion.
• Implementering af strategier for at skyde på mål.
• Gennemgang af adfærdhierarki.
• Gennemgang af SeizeBall adfærd.
• Afprøv en kamp.

Proces

Færdigbygning og finjustering af robot

Dagen startede med, at vi blev enige om at lade Robot3 forblive som den er, så vi har en fungerende robot til vores præsentation. Vi vil herefter kun bruge tid på at programmere adfærd for robotterne.
Herunder er vores endelige prototyper:

Endelige design, bagfra og forfra

Endelige design, fra begge sider

Endelige design, fra top og bund

Robotterne er nu ens designet, og vi har nu monteret tryksensor og farvesensor. Vi har testet robotten med tryksensoren og resultatet er, at det nu er blevet nemmere for robotten at bestemme, hvornår den har bolden. Med ultrasonisk sensor, var der problemer, når robotten kom for tæt på væggen eller andre robotter. Tryksensoren kan ses markeret nedenfor:

Touch sensor. Den lysegrå brik er området der har kontakt med bolden.

Vi regner med at støde på ting, vi gerne vil bygge om, men vores erfaring siger, os at vi bør have et fastlåst design til det resterende af vores programmering. Med faste fysiske parametre kan vi sikre os at hver testet adfærd vil fungere, når vi kommer til vores præsentation.

NXT måltællere

Vi har løbende talt om en række forskellige strategier, som kunne gøre robotten effektiv i dens angrebfaser. Det er i princippet det samme som i rigtig fodbold hvor hold ofte har indøvede angrebmønstre til at udnytte modstanderholdets svage punkter. Vi har diskuteret, at det kunne være sjovt, at lade robotten ændre adfærd løbende i spillet, og benytte de strategier mere hyppigt, som viser sig at  betale sig bedst. Idéen er taget fra rigtig fodbold, hvor man finder den svageste forsvarspiller, for så at angribe fra den side, i.e. danne sig ny erfaring undervejs i en kamp, og tilpasse strategien derefter.

For at robotterne løbende kan lære af deres strategier, vil vi forsøge at udarbejde et intelligent mål, der kan registrere scoringer og videresende disse informationer til robotterne.

Vi kom frem til at målene kunne konstrueres af LEGO. Her fandt vi ud af, at det vil være nok med at bygge to stolper, der kan fastgøres til banden. Ved at bygge pladen og stolperne, der ses herunder, opnåede vi, at det er nemmere at registrere, når bolden er inde i målet. Grunden til at der ikke er en overlægger er, at bolden ikke forlader baneoverfladen. Bagpladen vil så presse på en tryksensor bagved, der aktiverer optælling af points.

Massiv målplade

Bagpladen var desværre for tung til at kunne registrere små tryk, når bolden ikke havde meget fart på. Derfor forsøgte vi at bygge en lettere konstruktion af snor, der blev ført igennem stolperne. Hvis snoren blev ramt, ville de trække i en tryksensor. 

Mål med tråd

Det viste sig at snoren var for elastisk i forhold til de små ændringer. Ud fra de første erfaringer, kom vi  frem til at bygge en bjælke tværs imellem begge stolper, hvorved vi havde en forholdsvis stabil konstruktion, der nu kun krævede en brøkdel af trykket af vores pladeversion. For at få tværstangen til at glide bedst muligt, er hullerne lavet så stangen kan glide på en glat overflade.   

Mål med tynd plade

En NXT blev monteret til tryksensoren, og vi installerede software til at tælle op når tryksensoren blev aktiveret. På videoen nedenunder ses målet i aktion.

Vores fremtidige planer er at spillerne kan abonnere på målenes enhed, således at de bliver informeret, når der laves et mål, samt hvilken side der fik et point. Derved kan de forskellige robotter tilpasse deres strategier, udfra hvilke der oftest fører til mål.

Strategier for at skyde på mål

Vi har indtil videre udtænkt følgende teorier mht. at skyde på mål. Hvis robotten har bolden, og farvesensoren læser sort skal den være i retning mod mål og skyde. Ellers skal den rotere i retning mod mål og skyde. Grunden til at den altid skal skyde ved sort er, at vi, som banen og robotten er designet, på nuværende tidspunkt ikke har nogen måde hvorpå, vi kan finde ud af, hvilket af de to sorte felter, den står på.
Hvis robotten har bolden, og farvesensoren læser en af de grønne farver (lys eller mørk), skal robotten forsøge at rotere i den rigtige retning og drible mod det hvide felt, hvorfra den enten skal skyde direkte mod mål eller først drible længere frem på banen og dernæst skyde mod mål.
Andre strategier for at skyde, som vi har diskuteret er f.eks. at lade robotten skyde bolden mod banden, i en sådan vinkel, at bolden ryger mod mål.

Vi har også diskuteret at gøre sådan at robotten kan registrere, når den har scoret et mål, og huske hvilken angrebstrategi, den har brugt. Hvis modstanderen har lavet deres målrobot sekventielt så dens opførelse ikke ændrer sig, når der bliver skudt imod den, ville det så være en fordel at bruge den strategi, der har givet mål hyppigst.  Det samme har vi overvejet om kunne være muligt at gøre med vores målrobot, således at den husker, hvilken forsvarstrategi den har brugt, da modstanderen scorede, og så bruge denne mindre hyppigt.
For at kunne gøre dette ville det kræve, at det er muligt for robotterne at få at vide, hvornår der er scoret et mål.

Oprydning i Adfærdhierarki

Vi er påbegyndt arbejdet med at rydde op i vores fragmenterede arbejde på adfærdhierarkiet. Vores plan er at ende med noget der minder om følgende:

Exit  > Avoid > SeizeBall  > "Attack (find pos, attack strategy, aim, shoot)" > Drive randomly.

Attack er tænkt som en samlet betegnelse for angrebstrategier. Vi er gået igang med at selve oprydningen, samtidig med en udbygning af vores måde at håndtere strategierne på. Vi vil nemlig gerne have en isoleret måde at håndtere vores strategier på, hvor de kan skifte prioritet indbyrdes. Vi skal ligeledes have udbygget vores arbitrator så den er mere tilfældig i sit valg af adfærd når to eller flere har samme prioritet (lige nu vælger den altid den samme).
Attack er ovenfor sat i situations-tegn, da gerne vil kunne tale om denne gruppering af adfærd, som en samlet adfærd bestående af delelementer.

SeizeBall adfærd

Indtil nu har vi blot drejet en smule ind imod bolden, afhængig af hvilket læsefelt af vores IR Seeker der gav højest værdi. Vi vil dog gerne have en blødere indfaldsvinkel til at fange bolden. Vi har fra tidligere i projektet netop brugt en metode til at lave en dæmpe oscillering ved kørsel langs en linje: PID. Denne fremgangsmåde valgte vi at bruge, da den skaber en selv-justerende tilgang til en "optimal bane". Sensorens 5 målefelter udgjorde dog en udfordring ift. den tidligere 1 måling vi var bekendte med. Vores løsning var at slå flere målinger sammen til én, samt at lave meget skarpe sving ved de 2 mest ekstreme målefelter (1 og 5). Her så vi ingen grund til at benytte PID-princippet, da vi blot ville dreje hurtigt på stedet, for at få en blødere bue på vores jagt efter bolden.

Hver sektion er 44 grader og det totale målespektrum er 240 grader

Reglerne kan kort beskrives, meget forsimplet, ved disse 3 skridt:

1. Ved opdagelse af bold i 5, drej hurtigt imod venstre.
2. Ved opdagelse af bold i 1, drej hurtigt imod højre.
3. Ellers brug PID: error i PID-controller er sat til 4 minus 2.

Vi har derudover brugt vores viden om, at bolden er ligeud, hvis kun måleposition 3 har en værdi der er større end 0. I dette tilfælde nulstiller vi integral. Denne del af koden kan tilpasses en del mere, men vores nuværende resultat er rigelig godt til at fungere til vores formål.

Vi testede også med at inkoopere sensormåling 5 og 1 i vores PID-controller, men fik vi aldrig en helt så pæn eller hensigtsmæssig opførsel ved denne fremgangmåde - enten reagerede robotten for langsomt på at bolden trillede tæt forbi den, ellers overskød den markant, hvis den kom ind fra en vinkel, hvor en af de ydre vinkler havde fået tid til at lave målinger.
Vi konkluderede at det ikke gav mening at benytte disse målestationer til vores PID, da vi faktisk ikke vil have robotten til at køre fremad imens den ser bolden bag sig selv - ligeud ift. noget yderst på 1 eller 5, får robotten længere væk fra det den har set. Vi vil derfor dreje på stedet, indtil enten position 4, 2 eller 3 har en måling.
Udover disse observationer er vores PID for vores SeizeBall adfærd præcis ligesom vores tidligere PID fra linefollower [1]. Den endelige udgave af vores adfærd til at få fat i bolden kan ses i SeizeBall.java [2].

Prøvekamp

Endelig var vi kommet til en prøvekamp imellem de 2 robotter. Vi havde indstillet den ene robot til at være mærkbart hurtigere (dobbelt power) ift. den anden, for at se hvad hastighed betød. Denne kan ses herunder:

Den hurtige robot var den, der korrekt havde 1 sekunds pause, før den startede (venstre). Vi fandt primært frem til at vores drible-mekanisme er fantastisk god til at afmontere vores egen models hjul, hvilket er det, der kort kan ses til sidst i videoen. Det er dog også tydeligt, at der er meget kort tid til at foretage et skud, hvilket bekræftede vores mistanke om, at det ville blive meget svært for et hold at vinde med en målmand på hvert sorte felt, da vores markspiller meget hurtigt vil kollidere med modstanderholdets markspiller.

Konklusion

Eksperimenterne med farvesensoren trak noget ud, uden at ende i et resultat, der faktisk kunne bruges til en prøvekamp. Derfor er kampen udskudt til næste lab. SeizeBall adfærden er dog på et stadie, hvor vi vælger, at sige den er så god, at vi skal bruge tid på andre aspekter af vores adfærd i stedet.
Strategierne for at skyde på mål tog ligeledes en del tid at få diskuteret på plads, og ligeledes en del tid at omstrukturere koden, så den understøtter brug af forskellige strategier. Vi er dog ikke helt færdige med selve implementeringen af adfærdshierarkiet, så det kan understøtte vores strategier.

Referencer

[1], http://digikaison.blogspot.dk/2013/02/week-5.html
[2], https://www.dropbox.com/sh/py0lfofp42zjydx/YofhGiLP8f/LEGO%20Soccer/behaviors/SeizeBallBehavior.java

Week 15 - Session 5

Dato:

02-06-2013

Varighed:

Fælles lab: 5 timer

Blog: 5 timer

Deltagere:

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

Status

Vi mangler et kompas til den anden robot (spørg Ole). Koden er rodet, men virker efter hensigten.

Mål

Målet for denne laboratoriesession er at få LEGO-robotten til at skyde mod mål i en bestemt retning efter at vi nu kan bestemme denne vha. kompasset. Desuden skal de eksisterende adfærd refaktoreres, så vi i stedet benytter klassen DifferentialPilot til styringen af robotten. Desuden vil vi montere en farvesensor og påbegynde test med denne.

Plan

• Montering af farvesensor og tag målinger med formål at vurdere om der kan skelnes mellem banens fire farver (hvid, sort, lys grøn og mørk grøn).
• DifferentialPilot.
• Diskutere regel om, at man ikke må komme ind i det sorte felt.

Proces

Ombygning af nummer to robot

Efter overvejelser omkring brugen af farvesensor til at bestemme robottens position på banen, besluttede vi os for at bygge robotten om igen. Vi byggede Kaison om, så den kom til at ligne designet fra NXT, men nu med en touch-sensor i stedet for en ultrasonisk sensor samt en farvesensor. Grunden til at vi skiftede robottens ultrasoniske sensor ud med en touch-sensoren var, at den krævede mindre plads, og at dette gjorde det muligt for os at montere farvesensoren i midten i forhold til hjulene samt tættere på fladen af banen.

Montering af farvesensor og test af målinger

En hurtig test hvor vi sammenlignede farvesensorens RGB farvemålinger med de rå lysmålinger viste, at de rå lysmålinger gav en betydeligt større forskel på de fire forskelligfarvede felter vi skulle være i stand til at skelne mellem. Derfor fortsatte vi testene med den rå lysværdi og det er den der vil fremgå i de resultater som præsenteres for farvesensormålingerne i resten af dette projekt.

Målingerne blev lavet på banen og da de første målinger blev taget stod banen i det store åbne rum med loftsvinduer. Programmet som blev brugt gjorde ikke andet end at tage målingerne og udskrive dem til LCD'et. Vi kørte selv robotten lidt rundt på et felt ad gangen fordi den skal kunne kende felterne når den senere selv bevæger sig rundt. Fra vores første test er målingerne som følgende:

• Sort: 245-300
• Mørk grøn: 227-336
• Lys grøn: 316-480
• Hvid: 440-582

Color-Sensor måledata fra forskellige farver

Vi vurderede overlappet i måleværdierne for de forskellige felter til at være for stort til, at vi kunne bruge målingerne i spillet. Det virkede på dette tidspunkt usandsynligt, at vi ville få taget nogle gode målinger, og vi prøvede at optimere omstændighederne for gode resultater fordi vores tanke var, at vi dermed ville kunne udelukke at bruge farvesensoren til at skelne mellem felterne, hvis det også gav et dårligt resultat. Den måde vi ville forbedre omstændighederne var ved:

1. Ikke at bevæge robotten rundt. Dvs. kun tage målinger på ét sted på et givet felt på banen.
2. Samle værdierne fra de sidste 20 målinger og tage gennemsnittet for at reducere effekten af enkelte afvigende målinger. 

Vi afprøvede det først på det sorte felt, hvor den stabiliserede sig omkring 300. Før vi nåede at flytte robotten, gik der en sky for solen, og den faldt straks til at ligge stabilt omkring 200.

Registrering af det sorte felt

Efter at have nærlæst reglerne, opdagede vi, at der ikke var noget krav til, at man ikke måtte køre ind i modstanderens sorte målfelt. Gennemgang af videoerne fra WRO konkurrencerne bekræftede desuden også dette.

Konklusion

De første målinger som vi tog viste at der var for stort overlap i lysværdierne til, at vi synes vi kunne bruge farvesensoren til at skelne mellem de forskellige felter på banen. Da vi ikke kunne se anden mulighed for at skelne mellem felterne fortsatte vi med at lave målinger på lysværdierne. I et forsøg med en stillestående robot viste det sig at værdien på det sorte felt faldt med 1/3 fordi der gik en sky for solen. Lyset fra miljøet påvirkede målingerne for meget og vi flyttede straks banen ind i et andet rum hvor vi havde mulighed for bedre at sikre at banen blev ramt af en konsistent lyskilde. Vi har også fået ombygget vores robot, men test af touch-sensoren venter til næste lab. Derudover udskyder vi refaktoreringen af koden til næste session.

Week 15 - Session 4

Dato:

01-06-2013

Varighed:

Fælles lab: 5 timer

Blog: 5 timer

Deltagere:

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

Status

Vi har adfærdbaseret kode, så det er nemt at tilføje adfærd til vores program. Robotterne er endnu ikke færdige. Vi har endnu problemer med at finde retningen for målene. Adfærdhierarkiet er stadig buggy.

Mål

Målet for denne laboratoriesession er at færdigbygge konstruktionen af den nye robot. Desuden er målet også at indlede eksperimenter med, hvordan vi bestemmer, hvilken retning robotten vender, så vi sikrer, at robotten skyder mod det rigtige mål.

Plan

• Færdigbygge og teste ny robot.
• Retningbestemmelse af robotten.
• Rette adfærdhierarkiet.

Proces

Færdigbygning af ny robot

På dette tidspunkt fandt vi frem til at vores Robot2 desværre var utroligt uheldigt sammensat ift. at få på-monteret en farvesensor, samt at den pga. vinkle på den klo, ikke var så god til at slynge bolden af sted som Robot1. Vi besluttede os derfor for noget radikalt - endnu et redesign. Dette redesign gik ud på at rette Robot2 op så den var i en vertikal stilling med brikken.
Der var nu plads til farvesensor imellem hjul og klods, selvom den ultrasoniske sensor stadig sad noget dårligt.

Robot 3 til venstre, Robot2 til højre

Efter dette redesign blev en kopi af Robot3 bygget, så vi kunne påbegynde intensiv test af vores programmer på 2 robotter samtidig. Denne kopi var færdig i slutningen af dagen.

Retningsbestemmelse af robotten

Eksperiment med kompas

Vi startede dagen med at revidere planen om at orientere os med kompas. Efter nogen debat, kom vi frem til at vi blev nød til at finde en løsning. Hele gruppen gik nu ind i at "debugge" hardwaren. Ligesom ved alle andre bugs gik vi i gang med at eliminere alle faktorer, én ad gangen.
Vi havde følgende ideer til hvad der kunne være galt:

1. Trådløse signaler
2. Strømledende kabler under gulvet
3. Motorerne (selvom vi regnede med at vores kalibrering var korrekt)

Vi startede med at flytte bordet, for at se om det gjorde en forskel. Dette var minimalt, eller ikke eksisterende. Vi besluttede at det kunne være, at der var kabler alle steder i det lokale vi fysisk var i (Suze's store åbne område), så vi flyttede robotten rundt i alle omliggende rum. I Lego-rummet var robotten pludselig stabil. Herefter besluttede vi at forsøge at "isolere" robotten fra evt. stråling fra jorden (ledninger) ved at lade den køre på stanniol. Dette havde minimal effekt.

Til sidst besluttede vi os for at teste ved at løfte banen rundt i lokalet for at finde et "godt" sted. Umiddelbart efter at vi flyttede banen væk fra bordet, begyndte robotten at opføre sig som forventet. Ved at holde banen tilbage over bordet, opstod problemet præcis som før. Vi havde nu fundet problemet: Der løber store jern-bjælker under alle bordene i bygningen, og hver gang vi testede robotten stod den på et sådan bord. En side-effekt er dog, at påvirkningen af bordene kan ses som en bueformet afbrydelse af jordens magnetfelt - sjovt nok nu vi ved hvad der går galt, men meget frustrerende og tidskrævende at finde frem til.
Herunder er en sjov video af os der glade, og slæbende på en tung bane, finder frem til problemet.

Koden der får den til at stoppe op, i videoen ovenfor, er meget upræcis og kun til testformål. Robotten viser dog en meget klar tendens til, at uanset hvor vi bærer den hen i lokalet (bla. over en samlings-boks af ledninger), kan den finde frem til vores ønskede retning.
Koden vi har brugt til at kalibrere robotten kan ses her:

public static void calibrate() {

    LCD.drawString("Calibrating compass", 0, 2);

  

    Robot.COMPASS.startCalibration();

    PILOT.setRotateSpeed(18);

    Robot.rotate(360 * 2);

    PILOT.stop();

    PILOT.setRotateSpeed(120);

  

    Robot.COMPASS.stopCalibration();

    Robot.stop();

}

  

Metoden calibrate kan findes i klassen Robot.java [1]. Kompasset gemmer heldigvis kalibrering, så det er ikke et stort problem, at det tager lidt tid at kalibrere det.

Rette adfærdhierarkiet

Vi fik pillet lidt ved vores variabler for hvornår vores ultrasoniske sensor-målinger er godtaget som at have boldkontrol. Vi har nu en robot der fungerer efter et simpelt adfærdhierarki:
Exit > CatchBall > Shoot > Drive Random.

Konklusion

Vi havde fået kompasset til at virke og havde 2 næsten ens robotter, der begge kunne programmeres sideløbende. Vores nyeste medlem af holdet, kopien af vores robot3, manglede dog et kompas.
Vi var nu i stand til at vurdere hvilken generelle retning vores modstanderes mål lå i, men havde stadig ikke nogen brugbar strategi for at sigte på målet.
Vores adfærdhierarki virker nu efter hensigten, men er blevet noget rodet.

Referencer

[1],https://www.dropbox.com/sh/py0lfofp42zjydx/aQDHGHV2oz/LEGO%20Soccer/standard/Robot.java