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
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:
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:
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.
 |
| 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.
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.
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].
 |
| Hver sektion er 44 grader og det totale målespektrum er 240 grader |
Reglerne kan kort beskrives, meget forsimplet, ved disse 3 skridt:
- Ved opdagelse af bold i 5, drej hurtigt imod venstre.
- Ved opdagelse af bold i 1, drej hurtigt imod højre.
- Ellers brug PID: error i PID-controller er sat til 4 minus 2.
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.
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
[2], https://www.dropbox.com/sh/py0lfofp42zjydx/YofhGiLP8f/LEGO%20Soccer/behaviors/SeizeBallBehavior.java
No comments:
Post a Comment