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