af Patrick L. Larsen, Rasmus Lindholm, Morten Lyk, Patricia B. Lyk og Tommy Otzen
Lærings- og Oplevelsesteknologi 8. semester, Programmering af Robotter og andre Fysiske Enheder – 2015
YuniBomber er et opensource projekt og kan downloades fra github – Download sourcecode

The Yuni Family

INTRODUKTION

Multi Agent Systemer (MAS) forstås ved et netværk af interaktive intelligente agenter. Agenterne er delvist autonome og kan samarbejde om løsning af en fælles opgave, konkurrerer individuelt eller i hold [1]. MAS kan bruges til spil med fysiske agenter, eksempelvis robotkonkurrencer, logistiksystemer på et større lager eller i selvkørende biler.
I denne artikel beskrives tilblivelsen af et MAS ud fra generelle teoretiske principper omkring MASer, design af robotter og netværksteori. Artiklen er praktisk orienteret, hvilket kommer til udtryk i præsentation af processen fra idefase til slut resultat, samt forskellige test og designbeslutninger undervejs i projektet. Som afrunding på artiklen diskuteres og analyseres resultatet i forhold til den indledende teori og beskrevne målsætninger.

PROJEKTFORMULERING

PROJEKTETS RAMMER

Projektet tager udgangspunkt i de faglige mål til faget Programmering af Robotter og andre Fysiske Enheder[2] på 8. semester i Lærings og Oplevelsesteknologi ved Syddansk Universitet. Den beskriver at den studerende skal have:

  • kendskab til forskellige robotteknologiske begreber og platforme
  • kendskab til teori om sensor- og aktuator teknologier
  • kendskab til multi agent systemer

Skal kunne:

  • analysere en konkret, fagrelevant problemstilling og anvise teknologiske løsningsmuligheder
  • designe og bygge prototype robotsystemer på et videregående niveau
  • programmere og debugge robot controllere
  • håndtere analyse, design og programmering af en fysisk teknologi

PROBLEMFORMULERING

Ud fra almene principper og teori omkring MAS vil vi opstille en case og analysere os frem til en løsning af denne. Efterfølgende vil vi udforme denne løsning gennem en robot.

METODER & MATERIALER

I dette afsnit vil vi redegøre for de teorier, der har været grundlag for vores løsning og beskrive de komponenter, vi bruger i løsningen.

TEORI

Agent

Ifølge Jacques Ferber er en agent en ”… physical or virtual entity…”[3], der:

  • Kan agerer i et miljø
  • Kommunikerer direkte med andre agenter
  • Er drevet af et regelsæt
  • Besidder egne ressourcer
  • Opfatter sine omgivelser
  • Har delvis eller ingen repræsentation af dens miljø
  • Besidder nogle evner og kan tilbyde services
  • Har adfærd, der leder mod at opfylde sine mål ved hensyntagen til ressourcer og kompetencer, den har til rådighed, og tager hensyn til dens opfattelse, dens repræsentation og den kommunikation, den modtager [4].
Multi Agent System

Yves Demazeau definerer et MAS som “…adskillige agenter, et miljø, samt et sæt af mulige interaktioner og muligt mindst én organisation”[1], hvilket han yderligere uddyber i følgende tre sætninger:
Den deklarative ligning:
MAS = Agent+Miljø+Interaktion+Organisation
Den funktionelle ligning:
Funktion(MAS) = ∑ Funktion(Agenter) + Kollektiv Funktion
Det rekursive princip:
Et MAS må forstås som en agent i sig selv, på et højere niveau.

Et MAS med to agenter, der tilsammen har to funktioner, en for hver agent, kan altså forstås som havende en overordnet funktion, der kun kommer til udtryk i kraft af samarbejde mellem de to agenter. Den overordnede funktion kan altså tælles som en tredje funktion. På baggrund heraf kan et MAS i sig selv forstås som en agent.

Kommunikation er også en integreret del af et MAS. Overordnet set kan kommunikationen foregå på to måder: via interaktions protokoller eller gennem manipulation af det fysiske miljø.

Et MAS kan kommunikere via forskellige interaktionsprotokoller alt efter hvilke egenskaber systemet har. De forskellige agenter kan have forskellige roller, hvilket også påvirker udformningen af interaktionsprotokollen. Eksempelvis kan en agent fungere som manager. En manager ser en problemstilling, hvorefter den indgår en kontrakt med en eller flere agenter, der er i stand til at løse den givne problemstilling. En sådan protokol kaldes en Contract Net Protocol[1]. En mere autonom tilgang taget de individuelle agenter i betragtning er MOSCA Learning Protocol[1] hvor den enkelte agent har større selvbestemmelse.
Interaktions protokoller kan defineres ud fra forskellige sproglige primitiver (Se figur X)

Protocol

De forskellige primitiver har betydning for interaktionen i det samlede system. fortæller eksempelvis hvor agenterne befinder sig i miljøet, kan fortælle hvilken agent der har størst gennemslagskraft i situationer, hvor der opstår en konflikt. Disse primitiver bruges så til at opbygge en interaktionsprotokol.

Da Silva taler om, at når man kreerer et MAS bliver man nødt til at tage stilling til forskellige problemstillinger omkring hvordan systemet skal kunne koordinere[4]. Her introducerer han 4 forskellige aspekter, der kan koordinere; agent(A), interaction (I), environment (E) og organisation (O). Et MAS er altså, ifølge da Silva en kombination af Agent+Environment+Interaction+Organisation.
Agent aspektet er centreret på agentens rolle og egenskaber til at koordinere, miljø aspektet på hvordan man kan bruge miljøet til at koordinere agenterne via miljøet, interaktionen på det dynamiske forhold mellem robotterne afhængigt af opgaver, mål og evner og organisationsaspektet beskriver hvordan koordinationen sker på baggrund af sociale strukturer, opgave- og rollefordelinger.

Design principper til autonome agenter

Rolf Pfeifer præsenterer i ”Building ‘Fungus Eaters’: Design Principles of Autonomous Agents”[5] en designtilgang til at designe autonome agenter. Han bruger de fiktive agenter, fungus eaters, til at beskrive hvilke egenskaber en real-world autonom agent bør have. Fungus eaters er sendt til en fremmed planet for at opsamle prøve. De skal selv tænke på energi (fungus) og fjender, imens deres opgave udføres. De er komplette og har alt, hvad der skal til for at overleve i verden. Ud fra dette kommer han frem til tre perspektiver, som fungus eaters/autonome agenter, ifølge Pfeifer, altid skal evalueres ud fra. Første perspektiv er Functional, der fokuserer på agentens nuværende internal og sensoriske state. Andet perspektiv er learning and development (forskellen mellem læring og udvikling er, at udvikling kræver en ændring i organismen, hvor læring ikke gør), hvor tidligere begivenheder også medtages og det tredje evolutionary, hvor agenten sættes i konteksten af en evolutionær proces.
Herfra kommer han frem til 10 designprincipper. De er også delt i 3 klasser: ”Types of agents of interest, ecological niche and tasks”, ”Morphology, architecture, mechanism” og ”Strategies, heuristics, stances, metaphors”[5]. Her vil vi fokusere på de to første klasser, der dækker princip 1-7.

  1. Komplet agent: De er autonome (fungerer uden hjælp), selv-bevarende, embodied (fysisk system, der agerer i den virkelige verden) og situerede (agenten styrer selv interaktionen med omverdenen)
  2. Økologisk niche: Altid designet til en bestemt niche og alle tasks en agent skal opfylde er defineret
  3. Parallelle og løst koblede processer: intelligensen udspringer fra et stort antal parallelle, løst koblede processer. De er asynkrone og kræver lidt eller ingen centraliserede ressourcer, men resulterer alligevel i sammenhængende adfærd.
  4. Værdi-princippet: robotten ved hvad der er godt og skidt for den.
  5. Sensor-motor koordination: agenten interagerer med verden gennem sensor-motor koordination. Der ses på samspillet frem for de enkelte sensorer.
  6. Ecological balance: samspillet mellem krop og hjerne. Kompleksiteten af sensorer, aktuatorer skal passe til opgaven.
  7. Cheap design: godt design er billigt design og der skal ikke bruges penge på noget, der ikke er nødvendigt.
How the body shapes the way we think

Ifølge Rolf Pfeifer & Josh Bongard [6] er der en parallel mellem robotters udvikling og naturlig evolution. En robots udviklingsstadier kan forstås på samme måde, som den udvikling vi fra naturens side kender som naturlig selektion. Pfeifer og Bongard har udarbejdet en kunstig evolution’s algoritme der viser hvordan en robot kan udvikle sig på samme vis, som biologiske skabninger. Algoritmen består af en cyklus på fem trin:

  1. Generér indledende befolkning
  2. Udvikling af den indledende befolkning
  3. Udvælgelse af den indledende befolkning
  4. Reproduktion af den indledende befolkning
  5. Gentagelse af processen, startende ved trin 2.

Ved generering af befolkning i trin 1, forstås udvælgelse af en række komponenter og principper, der tilsammen skal kunne løse en specifik problemstilling. Eksempler på komponenter kan være kompas, motor og sonar. Principper kan være, at to agenter ikke må støde sammen. Tilsammen udgør komponenter og principper hvad Pfeifer og Bongard kalder genotypes. Ud fra disse genotypes kan man i trin 2 sammensætte (udvikle) sine genotypes til phenotypes. Phenotyper skal forstås som egentlige robotter der bliver skabt på baggrund af de komponenter og principper der blev genereret i trin 1. I trin 3 testes forskellige sammensætninger af ens robotter, hvoraf dem der løser det overordnet mål bedst bliver udvalgt og resten kasseres. I trin 4 reproduceres de “overlevende” af den udvalgte oprindelige befolkning. Disse udvikles så yderligere med forskellige modifikationer af komponenter og principper fra trin 1 (genotyper). Den nye gruppe af robotter vil så igen blive testet mod det oprindelige mål. I trin 5 starter cyklussen forfra.

IDEFASE

I idéfasen var første mål, at opstille nogle betingelser for design og udvikling af et MAS. Som inspiration til betingelser er rammerne for forskellige robot-konkurrencer blevet undersøgt nærmere. En liste over nogle af de robot konkurrencer, der er blevet kigget på kan ses her: www.wikipedia.org/wiki/Robot_competition. De forskellige konkurrencer indebære løsninger af fælles problemstillinger, indbyrdes konkurrence mellem individuelle robotter eller hold etc.
Inspireret heraf blev det bestemt at projektet skulle indeholde følgende:

  • et regelsæt som grundlag for kommunikation mellem enheder (spilleregler)
  • kendt og begrænset miljø (bane)
  • 3 autonome agenter (robotter)

Ud fra ovenstående rammer blev følgende muligheder diskuteret: skulle agenterne konkurrere indbyrdes eller løse en fælles problemstilling?
Overvejelserne omkring løsning af fælles problemstilling gik på følgende: Skulle robotterne have forskellige egenskaber? Og eventuelt en overordnet fælles funktion som Yves Demazeau beskriver som “The recursion principle”?[1]
Hvilken interaktionsprotokol kunne systemet bygges op omkring? Nogle af de interaktions protokoller der blev overvejet, var blandt andet “The Smiths Contract Net Protocol”(CNP)[1], der har en manager der styrer alle beslutningerne.
En CNP som kommunikation mellem agenterne ville indebære, at en af agenterne skulle fungere som master eller beslutningstager, hvilket der ikke var et ønske om i gruppen. I stedet var der fælles opbakning for, at lave et system, der gav lige vilkår til alle agenter, altså mere autonome agenter. For ikke at lave et system der bestod af master/slave relationer, besluttede vi at gå i retning af et system, hvor agenterne havde indbyrdes konkurrence. Ud fra det, begyndte vi at formulere nogle spilleregler.

Vi tog udgangspunkt i tanken om en klassisk bombeleg, hvor en tidsindstillet bombe (med vand) kastes rundt mellem deltagerne, indtil den springer i hænderne på en af deltagerne. Hvor lang tid der går, før bomben springer, er for deltagerne ukendt. I takt med at tiden løber og bomben skifter hænder, stiger spændingen mellem deltagerne.

Ud fra denne tanke begyndte vi at sætte nogle konkrete regler for et bombe spil:

  • Ved spillets start vælges en agent til at have virtuel bomben med en random funktion.
  • Når en agent modtager bomben, kan denne ikke skifte position i 5 sek.
  • Sammenstød med andre agenter medføre diskvalifikation.
  • Kører en robot ud af banen, bliver den ligeledes diskvalificeret.
  • Bomben udløses efter en random funktion 3-5 min. efter spillets start.

Efterfølgende begyndte vi at bestemme nogle rammer, for den verden agenterne skulle bevæge sig rundt i. En af de ting vi diskuterede, var hvorvidt elementer i agenternes miljø skulle være mulige at manipulere, således at de kunne bruges som kommunikation mellem agenterne. Skulle der eksempelvis være en klods i banen, der kunne flyttes af en agent, således at spillets udfald blev ændret. Denne form for inddragelse af banens betydning, valgte vi dog at gå væk fra. Vi blev i stedet enige om at banen skulle udformes på en sådan måde, at den ville være mulig at aflæse for robotterne. Dette ville være muligt, hvis robotten havde en farvesensor, således vil den kunne forstå sin egen position via et farveinddelt grid.

På nuværende tidspunkt var vi blevet enige om, at lave et MAS bestående af tre agenter, der indbyrdes skulle kæmpe om ikke at blive “sprunget i stykker” af en tidsindstillet bombe. Agenterne skal befinde sig i et miljø, hvori de kan forstå deres egen position i et kendt miljø, ved at aflæse hvilken farve, de befinder sig på. De skal ligeledes undgå at kollidere med hinanden, samt blive inden for banens rammer for ikke at blive diskvalificeret.

Ud fra dette grundlag gik vi igang med beslutte hvilke komponenter vores agenter skulle bruge, for at overholde kravene:

  • Til at aflæse sin egen position valgte vi at bruge en TCS3472[8] farvesensor.
  • For at undgå kollisioner valgte vi to forskellige sonare en Ultrasonic Ranging Module HC – SR04[12] og PING))) Ultrasonic Distance Sensor (#28015) [13]
  • Til at blive inden for banens rammer og bestemme orienteringen, valgte vi et kompas – HMC5883L [10]
  • Til at gøre agenterne mobile valgte vi en LEGO motor – Electric Technic Mini-Motor 9v LEGO 43362
  • Til at forbinde alle komponenterne og skabe kommunikation mellem agenterne valgte vi at bruge Arduino Yun.

Elektroniske komponenter

Arduino Yun

Arduino Yun er en open-source mikro-kontroller, der kombinerer det klassiske arduino miljø i form af en Atmega32U4 processor med kraften fra linux styresystemet i en Atheros AR9331 processor[7]. Kombinationen af de to processer betyder, man kan programmere i det velkendte arduino/processing miljø, men samtidig kører et linux miljø, der eksempelvis kan fungere som client eller server. Linux miljøet udvider de sprog, man kan bruge til at skrive programmer til Yun. Eksempelvis kan man skrive php, python eller javascript. Dette gør Yun robust til at udvikle systemer, der indebærer brugen af wifi. Yun kan dog ikke køre php, python eller javascript direkte på Atmega32U4 processoren. Det er dog muligt at kommunikere mellem de to processorer via Bridge interfacet.

Farvesensor

En farvesensor kan bruges til at registrere farven af et objekt ved brug af fotodioder. RGB-sensoren TCS3472[8]  fra TAOS Inc. kan angive RGB-værdierne af et objekt, og således bruges til at identificere en specifik farve.
Den benyttede RGB farvesensor består blandt andet af en LED-diode og fotosensitive dioder. Fotodioderne er belagt med henholdsvis rødt, grønt og blåt farvefilter, således at de kun registrerer dét spektrum af lyset. Ved at måle strømmen gennem dioden, som er resultat af mængden af lys på fotodioden, kan man angive hvor meget af det pågældende spektrum der findes i farven. Desuden er der en ufiltreret fotodiode, som måler den samlede mængde lys på sensoren. En analog-til-digital konverter konverterer strømmen til et digitalt tal, som kan læses af fx mikroprocessorer. Den nævnte farvesensor benytter I2C protokollen og behøver derfor kun 2 data pin’s til at kommunikere med en Arduino[8].
Ved brug af farvesensor er det muligt at genkende objekter ud fra den målte farve, og kan således bruges som led i at kunne identificere og ’se’ robottens omgivelser.

Sonar

For at være i stand til at bedømme afstanden til et objekt, benyttes sonaren. Dette bidrager til mængden af informationer om robottens omgivelser.
Sonar fungerer ved at registrere en lyd, og måle hvor lang tid den er undervejs, hvilket med en simpel udregning, inkluderende lydens hastighed, kan omsættes til en afstand. En sonar kan enten være aktiv, dvs. at den selv udsender en lyd, eller passiv, dvs. at den er afhængig af at en ekstern lydkilde [9].
Sonaren kan benyttes på forskellige måder afhængig af behovene. En simpel applikation vil være blot at måle den umiddelbare afstand til et objekt placeret foran sonaren. Et mere avanceret eksempel ville dog være at benytte sonaren til at danne et mere komplet kort over robottens nuværende omgivelser, ved at registrere og gemme alle afstande rundt omkring robotten. Dette kan så kan benyttes til at træffe mere velbegrundede beslutninger. For at kunne benytte sådan en løsning, vil det samtidig være vigtigt at kunne koble information om en form for placering sammen med de enkelte afstande. For eksempel kan afstandene knyttes til robottens orientering på ved den pågældende afstand. Dette kan for eksempel måles med et kompas, eller estimeres ved brug af stepper motor.

Kompas

Ved benyttelse af et digitalt kompas er det muligt at bestemme hvorfra den stærkeste magnetiske kilde stammer fra, og da dette ofte er nord, kan en global orientering således bestemmes. Det digitale kompas-komponent HMC5883L, er bygget til at registrere små magnetfelter, og er derfor meget sensitiv over for diverse magnetiske kilder [10]. Dette gør sensoren i stand til at registrere jordens naturlige magnetfelt, men betyder samtidig at den er meget påvirkelig af utilsigtede forstyrrelser i magnetfeltet. Den nævnte sensor bør ifølge databladet være i stand til at opnå en præcision på 1°-2°.

Motorer

Motoren styres igennem arduino med; et signal der angiver retning, et signal som angiver hvorvidt der bremses, og et PWM signal som styrer den effektive spændingen over motoren, og dermed hastigheden heraf.

DESIGN

ROBOTTERNES MILJØ

For at kunne opnå en præcis bestemmelse af robottens position ønskes der som udgangspunkt en bane med mange felter. Der blev derfor udarbejdet et designforslag, som skulle danne grundlag for det egentlige banedesign, og samtidig undersøge muligheder og forhindringer i banedesignet. Dette forslag søgte at øge antallet af felter i banen. Eftersom at farverne måles med en RGB sensor, haves der tre parametre som der kan reguleres på i banedesignet. For at udnytte 2 parametre, tilknyttes disse blot hver sin akse i et plan. For at udnytte det sidste parametre må der tilføjes endnu en dimension. Det kan gøres med ”bokse” som stilles på siden af hinanden. Hver boks vil indeholde de samme inddelinger (og værdier) på det to første parametre, men være forskellige fra hinanden på det sidste. Dette princip er illustreret på nedenstående figur.
første banedesign Som udgangspunkt undersøges muligheden for at skelne 512 farver fra hinanden, da dette på baggrund af tidligere erfaringer blev estimeret til at være et realistisk antal. Med fuld udnyttelse af de tre parametre giver dette 512=8 inddelinger på hvert parametre. Altså 8 bokse, med hver 8 inddelinger langs x- og y-aksen.
Ud fra dette blev der udarbejdet et designforslag som set på ovenstående figur, hvor der langs den vandrette akse i hver boks varieres på R-værdien, ved den lodrette akse varieres der på G-værdien, imens der boksene imellem varieres på B-værdien. Dette design medfører en grå zone i midten, som enten kan implementeres som en udfordring, eller elimineres med redesign på baggrund af test.
Dette design gør det teoretisk muligt at bestemme robottens position, da robotten med banens systematiske opbygning kan regne sig frem til placeringen på baggrund af de læste RGB-værdier, uden at være nødt til at indtaste værdierne for hver enkelte farve i koden.
Da dette design skulle testes blev der printet store kopier af udsnit af banen for at teste om de enkelte farver kunne detekteres og skelnes fra hinanden. Det viste sig hurtigt at en printer ikke benytter sig af RGB, men af CMYK farvemodellen. Derfor kan det ikke lade sig gøre at printe farver der stemmer tilpas overens med de planlagte, da afvigelserne er for store. Derudover har papirets kvalitet, tykkelse og det som ligger bag papiret stor betydning for hvilke RGB-værdier der læses af sensoren. Målingerne var så usikre at det valgte design forslag ikke var muligt at gennemføre. I stedet blev det besluttet at mindske antallet af felter, og i stedet måle og indskrive de enkelte felters RGB-værdi. For at mindske betydningen af kvaliteten af print, blev banens felter konstrueret af farvet pap. Samtidig sikrer det tykkere felter, således målingerne ikke påvirkes af den bagvedliggende plade. Udvalget medførte en bane på 5×7=35 felter, som det ses på nedenstående figur.
Endelige bane design Det endelige design betyder ud over en mindsket opløsning, at når der på nuværende tidspunkt måles en RGB-værdi, skal denne ”matches” med alle de indtastede farver, men med kun 35 forskellige farver har dette ingen betydning for performance af systemet.

Positionsbestemmelse

Eftersom at banens farver skal skrives ind i robottens kode, er der oprettet en farveklasse med parametrene R,G,B og C. (Red, Green, Blue og Clear). Således kan den fysiske bane afspejles i programmet af et todimensionalt array, hvor farvens position i array’et svarer til den på banen. For at bestemme robottens position er der lavet en funktion som matcher en målt farve med dem gemt i det todimensionelle array. Befinder den målte farve sig inden for en margin af en af dem i array’et, returneres robottens formodede position.
Der kan til tider kan opstå fejl ved detektering af position, fordi nogle af felternes farveværdier ligger tæt på hinanden. Derfor er der lavet en funktion, som tjekker om to positioner er hosliggende, således at der kan tjekkes om robottens to seneste positioner ligger ved siden af hinanden. Derfor vides det om robottens nyeste position giver logisk mening, og om den skal godkendes, eller om der skal ventes på at der detekteres en gyldig position. På denne måde kan man løse problemet med felter, som har stor lighed i farveværdier, ved at placere dem tilstrækkeligt langt fra hinanden.
Det har ved senere test vist sig at robotten i perioder ikke er i stand til at bestemme dens position, og således springer et felt over uden at registrere dens position. Den tidligere nævnte funktion til sikring af hosliggende positioner betyder da, at de efterfølgende positioner ikke godkendes, og robotten ikke længere kan bestemme sin position. Dette skyldes formentligt at der til tider køres på kanten mellem to felter, hvorved ingen gyldig farve detekteres.
Skærmbillede 2015-05-19 19.42.22 Situationen illustreres på ovenstående billede hvor robotten (hvid cirkel), ikke formår at registrere nogen position imellem felt 9 og 2. Da den når til felt 2 kan denne ikke godkendes da den ikke er nabo til felt 9, og robotten vil fortsat tro at den befinder sig på felt 9, og navigere derefter. Dette kan i værste fald betyde at robotten kører uden for banen.
På baggrund af dette bliver den førnævnte funktion ikke længere benyttet, hvilket til tider kan medføre uregelmæssig opførelse, men da problemet kun eksisterer indtil den korrekte position bestemmes, vurderes det til at være at foretrække frem for det permanente problem som kan opstå ved brug af funktionen.

ROBOT

Igennem forløbet har robottens fysiske design gennemgået forskellige ændringer. I det oprindelige design var det var meningen robotten skulle laves i akrylplader, der skulle limes sammen, for at gøre robotten så lille som mulig. Et udkast til designet kan ses på billedet herunder.
Skærmbillede 2015-05-19 20.44.04 Vi besluttede dog efterfølgende, at den endelige robot skulle laves i LEGO, da den fysiske størrelse ikke ville blive væsentlig større af det. Fordelen ved at lave robotten i LEGO, i forhold til at lave dem i akrylplader, er at det hele tiden er muligt hurtigt at lave ændringer på den fysiske udformning af robotten, hvis dette skulle blive nødvendigt. Desuden ville tiden, der skulle bruges på at designe og fabrikere emnerne i akryl, kunne spares væk, da vi allerede havde LEGO til rådighed.
Robotten er opbygget ud fra arduino Yún med et tilhørende motorshield. Drivkraften er 2 LEGO dc motorer, som er gearet ned 1:5. Ved at bruge LEGO motorerne, var det nemt at skabe et holdbart chassis for robotten, da de let blev bygget ind i LEGO konstruktionen. Det blev også diskuteret om der skulle bruges stepper motor i stedet, da kompasset derved muligvis kunne spares væk på grund af den større præcision denne type motor giver. Det blev dog valgt at fortsætte med LEGO dc motorerne, netop på grund af deres kompatibilitet med LEGO.
Der blev lagt fokus på, at robotten stadig skulle dreje rundt om sin egen akse for at mindske det areal, der skulle til for at vende. Desuden blev farvesensoren sat i omdrejningspunktet. På denne måde mindskes risikoen for at robotten, ved et uheld, drejede ind på et andet felt, imens den vendte/drejede.
Kompasset er hævet højt over robotten for at mindske elektromagnetisk støj fra resten af robotten.
Det blev besluttet, at der kun skulle være en fast monteret sonar foran på robotten. I stedet kunne man have monteret sonar på en servomotor oven på robotten, der således kunne rotere og måle afstanden til alle objekter omkring robotten. Denne løsning blev dog vurderet til at ville tage for lang tid at implementere. Samtidig ville det blive økonomisk dyrere eftersom det ville kræve et andet motorskjold, der kunne klare at styre så tre motorer. Det blev vurderet, at hvis robotten bare tog hensyn til at dens ”syn” var begrænset, så kunne den godt nøjes med én fastmonteret sonar.
Det endelige resultat kan ses på billederne herunder.
Skærmbillede 2015-05-19 20.41.30

Erfaringer med anvendte sensorer

Alle sensorer brugt i dette projekt er først implementeret og testet separat, for at sikre at de virker som tiltænkt, og for at lette fejlsøgning. Test er udført ved at have en “original” robot som alle komponenter løbende blev implementeret på, for at teste samspillet mellem komponenterne. Denne robot er brugt til at bygge to kopier, således at der haves tre agenter. I løbet af projektet er der desuden gjort erfaringer med sensorerne, som det har været nødvendigt at tage højde for.

Farversensor

Som beskrevet i afsnittet om design af banen, har der været problemer med at opnå overensstemmelse mellem de forventede farver, og de eksakte farverværdier sensoren læser. Derfor blev antallet af farver mindsket, hvilket samtidig gav mulighed for større margin imellem hver enkelt farve. Samtidig er der vist tegn på, at det kan være svært at opnå tilstrækkelig præcision med farvesensoren til at skelne farver hvis værdier ligger tæt på hinanden, da der er forholdsvis store udsving i de læste værdier for et enkelt felt (én farve) på den endelige bane. Dette skyldes formentlig variation i pappets kvalitet og spor efter den lim som felterne er limmet fast med.
Farvesensoren blev testet ved at holde den op imod forskellige farve-værdier, og tjekke om de givne værdier gav mening i forhold til farven. Eksempelvis har en rød farve højt udslag på R-parameteren, imens en sort har lave værdier for alle parametre. Ved montering af farvesensor på en robot, bemærkes det at selv små ændringer i afstanden mellem farvesensor og den farve der læses, har betydning for den læste værdi. Derfor blev hver robots farvesensor (monteret på robotten) testet mod hver enkelt felt på banen (Resultateterne af testen kan downloades fra nedenstående link). De to kopierede robotter testes for deres evne til at detektere farven som den blev opfattet af den “originale” robot. De felter hvor en robot havde problemer med at detektere en farve, blev der noteret dens egen opfattelse af feltets RGB-værdi.
Desuden kan det være svært at udnytte farvesensorens fulde spektrum, på 0-512, for hvert parameter (pt. har de kraftigste farver opnået værdier på cirka 380 på enkelte parametre, hvilket også ses i resultaterne fra nedenstående link).
Se resultater fra farvesensor test

Sonar

Qua antallet af komponenter, som har været til rådighed under projektet, har det været nødvendigt at benytte to forskellige sonar-komponenter: Ultrasonic Ranging Module HC – SR04[12] og PING))) Ultrasonic Distance Sensor (#28015) [13]. De to komponenter virker fint i separate test, og kan sensorere afstande ned til henholdsvis to og tre centimeter, og helt op til henholdsvis fire og tre meter. [12] Har en måle-vidde på 15°, imens den anden ikke er nærmere specificeret.
Til tider udsender de brugte sonar et fejlsignal i form af en målt afstand på ´0´, hvilket dog nemt filtreres fra i programmet på Arduinoen. Sonaren er testet og verificeret ved at sammenligne sensorens værdi hen til et objekt, og afstanden målt med en lineal.

Kompas

Der er i løbet af projektet blevet brugt meget tid på at få kompasset, Ultrasonic Ranging Module HC [12], til at fungere efter hensigten, og der er flere gange forekommet uregelmæssige målinger. For eksempel ses der flere gange en ikke-lineær ændring i gradtallet når robotten roteres 90°. En sådan komplet rotation i 90° skridt kunne give målinger der ligner; 0°, 140°, 240°, 310°, 0°.
Kompasset er i flere omgange blevet flyttet til et punkt højere over robotten, og således længere væk fra motoren og batteriernes magnetiske felt, hvilket har forbedret målingerne. Ydermere har det vist sig at den valgte spilleplade skabte store forstyrrelser i målingerne, da den består en af en stor metalplade. Pladens påvirkning har været påvist/erfaret under praktiske test på en græsplæne udendørs, for at eliminere eventuelle kilder i projekt lokalet. Dette har medført en udskiftning af spillepladen, som afslutningsvis er lavet af træ.
Disse ændringer for at mindske magnetisk støj har øget præcisionen af bestemmelse af robottens orientering, om end der stadig er udsving afhængig hvor på pladen robotten er placeret. Målinger for dette er angivet på nedenstående figur:
Skærmbillede 2015-05-19 20.57.36

Motor

Undervejs i projektet blev der oplevet en manglende evne til at styre hastigheden af robottens ene motor, og kilden dertil var længe ukendt. Det viser sig at den pin som bruges til at styre PWM (pin 3), også er forbundet til SCL signalet, som er en del af I2C protokollen på Arduino Yún [17].

NETVÆRKSKOMMUNIKATION

Robotterne kommunikerer ved hjælp af wifi. Alle robotterne er koblet på samme trådløse netværk, sammen med en computer, der kører en NodeJS server[11]. Serveren opdateres med data om hvor de forskellige robotter befinder sig, hvem der har bomben, samt andre informationer om selve spillet. Robotterne fungerer som klienter til serveren. De har mulighed for at sende data til serveren, for eksempel om deres position, samt mulighed for at efterspørge data fra serveren om de andre klienter og selve spillet. Der er lavet en simpel protokol, der håndterer de forskellige kommandoer og data, der sendes mellem klienterne og serveren.
Skærmbillede 2015-05-19 20.59.18

Yun Client

Klienterne kommunikerer med serveren ved brug af et HTTPClient bibliotek, der gør det muligt at tilgå serveren ved hjælp af netværket. Til dette bruger arduinoen også en såkaldt Bridge, der står for forbindelsen mellem arduinoen og det linux-system, der styrer wifi-modulet.
Klienten tilgår serveren ved brug af IP-adressen på den computer, som serveren kører på, samt den port, som serveren kører på. Efter dette følger ”/[COMMAND][DATA]”. Et eksempel på en klient, der sender sin position til serveren hvert femte sekund vil derfor være:

#include <Bridge.h>   
#include <HttpClient.h>

HttpClient client;
int myId;
int myXPosition;
int myYPosition;

void setup() {
  myId = 0; //Change accordingly
  Bridge.begin();
}

void loop() {
  myXPosition = 3; //Get data from color sensor    
  myYPosition = 5; //Get data from color sensor 
  SendData(); //Send data to the server
  delay(5000);
}

void SendData(){
  String dataString = String("/") + myId + 1 + myXPosition + myYPosition; // "/0135"
  client.get("192.168.43.201:8080" + dataString); //Access server
}

Hvis klienten vil have data om de andre klienter skal den selv initialisere en efterspørgsel til serveren, der så kan sende et svar.

void GetData(){
  String cmdString = String("/") + myId + 0;  
  Console.println("Get: " + cmdString);
  client.get("192.168.43.201:8080" + cmdString);
  
  String dataString = String("");
  while (client.available()) {         // Read message from server
    char val = client.read();          // Val is a char and 1 is = 49
    dataString += val;  
  }
  
  Console.println(dataString);
  
    xPosition0 = dataString.charAt(1) - '0';
    Console.print("X0: ");
    Console.println(dataString.charAt(1));
    yPosition0 = dataString.charAt(2) - '0';
    xPosition1 = dataString.charAt(3) - '0';
    yPosition1 = dataString.charAt(4) - '0';
    xPosition2 = dataString.charAt(5) - '0';
    yPosition2 = dataString.charAt(6) - '0';
    bombKeeper = dataString.charAt(7) - '0';
    
    Console.print("Bomb keeper: ");
    Console.println(bombKeeper);
    
}
Nodejs Server

Serveren fungerer ved at den hele tiden står og venter på at blive tilgået af klienterne. Når serveren bliver tilgået af en klient responderer den i forhold til protokollen. Serveren vedligeholder hele tiden et sæt variabler, der fortæller hvor de enkelte klienter befinder sig, samt hvem der har bomben. Derudover holder serveren også styr på om spillet er startet eller ej.
Når serveren modtager ”SET_ROBOT_DATA” fra Figur 1 opdaterer den disse variabler for den pågældende klient. X- og Y-positionen vil ligge i henholdsvis charAt(2) og charAt(3) i henhold til protokollen.

switch(path.charAt(1)){
		case SET_ROBOT_DATA:
			switch(path.charAt(0)){
				case "0":
					robot0.xCoord = path.charAt(2);
					robot0.yCoord = path.charAt(3);
					sys.puts("Robot 0 position set to: (" + robot0.xCoord + "," + robot0.yCoord + ")");
					break;
				case "1":
					robot1.xCoord = path.charAt(2);
					robot1.yCoord = path.charAt(3);
					sys.puts("Robot 1 position set to: (" + robot1.xCoord + "," + robot1.yCoord + ")");
					break;
				case "2":	
					robot2.xCoord = path.charAt(2);
					robot2.yCoord = path.charAt(3);
					sys.puts("Robot 2 position set to: (" + robot2.xCoord + "," + robot2.yCoord + ")");
					break;
			}

På samme måde kan serveren også sende data tilbage til klienterne, når den modtager en ”GET_ROBOT_DATA” kommando.

case GET_ROBOT_DATA:
			sys.puts("Sending Robot data to robot: " + path.charAt(0));
			response.write("0" + 
						   robot0.xCoord + robot0.yCoord +
						   robot1.xCoord + robot1.yCoord +
						   robot2.xCoord + robot2.yCoord +
						   bombKeeper);
			break;

Serveren vil selv sørge for at svare den klient, der har anmodet om data.
Når serveren starter vil den tilfældigt tildele en af klienterne bomben. Derefter vil den vente indtil alle tre klienter har spurgt om spillet er startet (og dermed meldt sig klar). Når dette sker, vil serveren sende et startsignal ud.

Se den komplette kode på vores github side.

Alternativ Netværksløsning

Før den beskrevne kommunikationsløsning blev valgt, blev der arbejdet i en alternativ metode. Denne gik ud på at arduinoerne skulle hente og sende data til et Google spreadsheet. Denne løsning virkede oplagt, da der allerede fandtes færdige metoder til dette. Samtidig ville det også være nemt for kontrollørerne af spillet at følge med. Ulemperne ved denne metode er, at det er nødvendigt at have forbindelse til internettet og at det derfor kan være svært at forudsige den hastighed, man kan sende og hente med. Derudover er det kun en begrænset udgave af servicen til dette, der kan fås gratis. Derfor blev denne løsning fravalgt.
Når der bruges Arduino Yún er der også mulighed for direkte at sætte en Yún op som server eller klient. På denne måde kunne NodeJS serveren undværes. Grunden til at denne metode blev fravalgt er at vi ønskede at alle agenterne skulle være ligebyrdige, hvilket ikke ville være tilfældet, hvis den ene fungerede som server.

ADFÆRD

Robotternes adfærd styres ud fra et sæt forholdsvis simple tilstandsmaskiner. Den første tilstand robotterne befinder sig i vil være at afvente at spillet er startet. Det eneste robotterne gør her er hele tiden at spørge serveren om alle de andre robotter er klar.
Når robotten modtager et startsignal vil den enten gå i chase mode, hvis den har bomben, eller i evade mode, hvis den ikke har. I evade mode vil robotten ganske simpelt forsøge at køre i den direkte modsatte retning af den robot, der har bomben. Hvis den kommer til en kant, vil den forsøge at dreje til den side, der får den længst væk fra bomben. Med denne metode vil robotten uundgåeligt på et tidspunkt blive trængt op i en krog, hvis den bliver forfulgt. Dette vurderes dog at være okay, da robotten med bomben gerne skulle have en lille fordel.
Hvis robotten derimod er i chase mode vil den yderligere tjekke på, om den har et target. Dette bliver bestemt ud fra om robotten kan se en anden robot med sonaren. Hvis ikke robotten med bomben har et target, vil den forsøge at køre mod den tætteste robot, baseret på positionsdata fra serveren. Mens den kører mod dette mål, vil den løbende skanne omkring sig for at finde et eventuelt target. Hvis den finder et, vil den køre mod dette så længe den kan ”se” det og derefter gentage denne proces. Hvis robotten kan se en anden robot og står på et felt ved siden af denne kan den give bomben videre ved at sende en besked til serveren. Den vil derefter gå i evade mode, og den nye robot med bomben vil begynde at chase.
Skærmbillede 2015-05-19 21.18.54 Skærmbillede 2015-05-19 21.19.08 Udover disse tilstandsmaskiner vil robotter altid forholde sig til to ting. Dette er for det første at undgå kollisioner med andre robotter og for det andet at undgå at køre ud over kanten. Hvis en robot tror at den er ved at køre ind i en anden robot vil den stoppe og dreje indtil den er fri af den anden robots bane. Dog vil den hvis den er i ”Chase” mode aflevere bomben først. Hvis en robot tror, den er ved at køre ud over kanten vil den ligeledes altid forsøge at undgå dette. Dette gør den ved at tjekke om det felt den står på er et af de yderste, samt om den dens nuværende orientering leder ud over kanten.
Derudover vil alle robotterne også så ofte som muligt sende og modtage data fra serveren for at holde informationerne på denne opdateret.

TEST

Som afslutning på projektet blev der udført en komplet spiltest af hele systemet. Vi startede med at teste, hvor vidt robotterne var i stand til at navigere rundt i sit miljø ved at læse banens farver. Efterfølgende testede vi forskellige funktioner for spillet, hvilket ses nedenfor.

Beskrivelse:
I ovenstående video kan det ses hvordan robotten, ved at benytte farvesensor og kompas navigerer robotten imellem de fire forudbestemte positioner, og demonstrerer derved dens evne til at navigere i det kendte miljø.

Beskrivelse:
I test nummer to, fra ovenstående video, blev udført med både to og tre robotter. I testen blev robotterne placeret på banen med stor afstand til hinanden. Herefter blev serveren og robotterne startet. Videoer af testene kan ses her:

Beskrivelse:
I ovenstående video benyttes to robotter, hvor robot ID0 starter med bomben, imens ID1 flygter. de to robotter skiftes af flere omgange til at have bomben, og forløbet sker uden store problemer, omend robot ID0 er tæt på at køre ud over kanten omkring ID1 minut inde i videoen.

Beskrivelse:
I ovenstående video er alle tre robotter på banen, hvor robot ID2 starter med bomben. Der ses et par kollisioner og der er situationer hvor robotterne er på vej ud over kanten. 40 sekunder inde i videoen ses at robot ID2, som forventet, skifter target eftersom robot ID1 er tætter på end robot ID0. Senere skifter den target tilbage til robot ID0. I den sidste tredjedel af videoen bruger robot ID0 meget lang til på at scanne efter sit target, hvilket ikke er tilsigtet, men formegentlig kan løses ved justering af koden.

Testene viser at systemet i store træk virker som forventet. Både chase og evade adfærden virker tilstrækkeligt til at spillet kan ”spilles”. Dog ses det nogle gange, når robotten chaser, at den drejer rundt om sige selv flere gange end nødvendigt. Dette skyldes enten at sonaren nogle gange ikke når at opfange en anden robot foran den, hvilket betyder at man bliver ved med at skanne indtil næste gang man ser den. Den kan også skyldes at robotten begynder at scanne efter modspillere selv om at der ikke er nogen, der er tæt nok på til at blive registreret.
Det ses desuden af testen at robotterne nogle gange fejler i deres kant detektering og risikerer at køre ud over. Dette skyldes flere ting. Enten er der en fejl i farve detekteringen, eller at den begynder at undvige kanten for sent på grund forholdet mellem hastighed og detekterings hastighed. Det kan også skyldes at robotten, når den evader og kommer ud til kanten, ender i en mellemting mellem at forsøge at flygte og forsøge at undgå kanten.
Når en robot modtager bomben ses det desuden nogle gange at den fortsætter med at køre i stedet for at stoppe op og vente til må fortsætte.
Sidst, men slet ikke uvæsentligt, ses der også et forholdsvist højt antal kollisioner. Dette skyldes dels at den afstand hvor en robot forsøger at undgå en kollision er for lille, men også dels at robotterne kan se relativt lidt, når de kommer helt tæt på hinanden og begynder at dreje rundt. Det ses også enkelte gange at robotterne aldrig opdager en kollision og bare fortsætter med at køre.

DISKUSSION

I dette afsnit vil der blive fokuseret på hvad der er lykkedes at lave og hvilke kompromisser, der er blevet gjort.
Det var planen, at robotterne skulle have hver deres unikke kode og dermed forskellig adfærd. Dette har desværre ikke været muligt at få dette implementeret, da der var en del flere udfordringer end forudset. Dette har gjort at vi, desværre har måtte skære ned i ambitionerne, og er endt med én kode til styring af alle robotter.
På sensorsiden er det måden hvorpå sonaren bliver styret, hvor der er blevet lavet et kompromis. Det var meningen, at sonaren skulle være monteret på en servo-motor på toppen af robotten, så den kunne swipe et område for forhindringer. Dette blev så ændret til at sonaren er monteret fast foran på robotten. Dette kompromis blev gjort, da det motorskjold, der blev valgt i begyndelsen, som kunne styre både motorerne og servo-motoren til sonaren, ikke var til at skaffe indenfor den tidsramme, der var til rådighed.
En anden sensor, hvor der blev gjort et kompromis er kompasset. Efter meget arbejde var resultatet at sensoren var meget unøjagtig, men det blev vurderet at koden kunne skrives, så den tog højde for dette. Alternativet havde været at bestille en dyrere sensor, hvor leveringsiden var ukendt. Det sidste blev anset som at være den dårligste løsning.
Det sidste kompromis, der blev gjort, var at robotterne skulle være lavet af akrylplader for at de var mere kompakte, men da det ville være mere tidskrævende, og motorerne allerede var valgt til at være LEGO motorer, så blev det besluttet, at gøre et forsøg med et LEGO design. Resultatet var et chassis, der fysisk ikke var meget større end det var forventet at akrylplade designet havde været.
Der har undervejs været en del tests, der har været med til at forme robotterne til det de er nu. De første mange tests, der blev lavet var på sensorbasis. Arduinoerne blev programmeret til at kunne bruge én sensor af gangen. Dette blev gjort for at have noget programkode til de enkelte elementer af robotterne, som der var testet til at virke, så når de blev sat sammen til den endelige kode, vidste man at de enkelte sensorer og deres tilhørende kode virkede.

Som beskrevet tidligere anvendes en relativ simpel chasing/evading algoritme. Begge disse kunne optimeres. En metode til at forbedre disse kunne være at prøve at forudsige de andre robotters bane og ud fra dette selv udregne den mest optimale rute.
I forhold til de beskrevne resultater af testen, er der blevet lavet en kort analyse af problemernes omfang, og hvor meget det umiddelbart vil kræve at løse dem. I forhold til at en robot med bomben kan finde på at scanne, dvs. rotere i lang tid på samme sted, så kræver dette debugging af koden, således problemet kan lokaliseres, da koden burde tage højde for hvorvidt target er inden for sonarens synsvidde.
Problemet med konflikten imellem at prøve at evade og undgå kanten på samme tid, kan løses på flere måder. Basalt set består problemet i at robotten under evasion ikke navigerer til en bestemt position, men blot kører i en bestemt retning (modsatrettet bombeholderen), hvilket kan lede den ud over banen. Problemet kan altså løses ved i stedet at udvælge en bestemt position. Ellers skal det sikres at robotten ikke kan evade når den samtidig prøver at undgå at køre ud over kanten.
I forhold til undgå sammenstød mellem robotterne kan man øge grænsen for den afstand som opfattes som kollisionskurs, som pt. er 5 cm. Det er dog samtidig vigtigt at denne afstand ikke kommer for tæt på den afstand som angiver hvor tæt en bombemand skal være på sit target for at give bomben videre. Det skyldes at hvis bombemanden registrerer kollisionskurs før den afleverer bomben, vil funktionen til at undgå kollisioner forhindre en videregivning af bomben.

Vi er altså endt ud med 3 robotter, der kan agere i deres miljø (banen), kommunikere med hinanden, er drevet af et regelsæt, opfatter omgivelserne og besidder egne ressourcer. De har også en adfærd, der leder mod at opfylde deres mål (ikke at have bomben, når den springer) ved hensyntagen til de ressourcer og kompetencer, som de har til rådighed, og de tager hensyn til deres opfattelse, repræsentation og den kommunikation, de modtager. De er altså det, som Ferber vil betegne som agenter.
Tilsammen udgør de et MAS, som både Demazeau og da Silva definerer det; der er flere agenter, de er i et miljø, de interagere og har en indbyrdes organisation.

Evalueres agenterne ud fra Pfeifer designprincipper, er det tydeligt, der er punkter, hvor agenterne kan forbedres.
Særligt er det princip 1, hvor robotterne halter. Agenterne er tiltænkt at skulle være helt autonome og dermed fungere uden hjælp og være selvbevarende. Det lykkedes næsten, men af og til når robotterne (som nævnt) forsøger at undslippe robotten med bomben, ryger de ud over banen, fordi de kører væk fra robotten med bomben og ikke mod en bestemt position. Robotterne er designet til et bestemt miljø og alle opgaver, som robotterne skal udfylde er definerede og dermed opfyldes princip 2.
Ifølge princip 3 skal den enkelte agent kunne køre processer parallelt. Dette er ikke nemt med arduino, da den kun har én kerne. Der køres dog nogle processer i loops, som bliver kørt så hurtigt, at de virker til at køre parallelt. Dette kaldes pseudoparallelle processer[18] . Til Gengæld opfylder systemet som helhed princippet, da det kører parallelle processer i form af agenterne.
Robotterne ved, de ikke skal køre ind i noget, men som nævnt kører de stadig af og til af banen. Princip 4, værdi-princippet, der går på at robotten skal vide, hvad der er godt og skidt for dem, er derfor kun delvist opfyldt. Som i princip 5 interagerer robotterne med verdenen igennem sensor-motor koordination, hvor der også er samspil mellem sensorerne. Robotterne bruger kompasset til at navigere på banen, fx når de har bomben. Når robotten med bomben når indenfor en vis afstand af sit offer, overtager sonaren. De sidste to principper, 6 og 7, der omhandler samspillet mellem krop og hjerne samt cheap design, er også blevet diskuteret. Designet af robotten blev ændret, så den ikke havde behov for et dyrere motorshield, der kunne styre en servomotor, så sonaren kunne afsøge et område. Dette blev i stedet kompenseret for i koden/behaviour. Dermed bruges der ikke penge på noget, der ikke er nødvendigt.

KONKLUSION

Det er lykkedes at få konstrueret et bombespil, der “spilles” ved brug af et MAS, hvor tre robotter er i stand til at navigere på en bane, hvor de kan undvige hinanden og (for det meste) ikke køre ud over banen. Desuden kan robotten, der har bomben, finde ud af hvilken anden robot, der er tættest på, køre over til den og give den bomben. Endvidere er de robotter, der ikke har bomben, i stand til at finde ud af, hvem der har bomben og køre i den modsatte retning af denne. Desuden er robotterne relativt robuste, hvilket også gælder for koden/algoritmen, som i høj grad er god til at sørge for at robotterne ikke ender i deadends eller deadlocks som gør at systemet bryder sammen. Kommunikationen robotterne imellem fungerer upåklageligt, omend der er en smule ventetid på svar fra serveren. Det er lykkedes at mindske og kompensere for fejl på kompasset tilstrækkeligt til at anvende det som tiltænkt.

PERSPEKTIVERING

Hvis vi skulle arbejde videre med robotten, ville en af de første ting, der skulle kigges på være robotternes adfærd. Til start var det meningen, vi skulle have arbejdet i 3 grupper og programmere hver vores robot. Pt. har robotterne samme kode og dermed er konkurrenceelementet, mellem os studerende, væk. Der kunne fx. arbejdes med mere avancerede former for chasing og evading som interception, hvor robotten med bomben forsøger at fange “sit bytte” på dens bane. Den skal derfor kende byttets aktuelle position, fart og retning. Med denne tilgang kommer man ud over problemet med at robotterne kan ende lige i hælene på hinanden, fordi de kører med samme fart. En anden tilgang kunne være A* pathfinding [15, 16]. A* algoritmen garanterer, ifølge David M. Bourg og Glenn Seemann, den bedste rute mellem et hvilket som helst startpunkt og slutpunkt. Metoden er desuden god til at håndtere forhindringer og på sigt kunne det være med til at gøre bombespillet mere spændende og mindre forudsigeligt (man ville kunne gemme sig bagved forhindringer).
For at gøre spillet mere interessant at kigge på, er der flere ting, der kan tilføjes. Det kunne gøres mere tydeligt, hvilken robot, der har bomben ved gøre bomben fysisk eller give hver robot en diode, der fx. kunne blinke rødt, når den “bærer” bomben. Der kunne også laves et interface med en highscore liste, hvor der trækkes oplysninger ud af serveren og laves statistikker. Her kunne også laves en nedtælling, så man hele tiden kan holde øje med hvor lang tid der er tilbage af runden.
Robottens udseende kunne også forbedres. Vi har bl.a. snakket om at 3D-printe et skjold til dem, hvilket også ville gøre dem mere robuste.

Hele systemet kunne på sigt tilpasses, så folk uden kendskab til robotter kan manipulere nogle variabler og på den måde påvirke robotternes adfærd. Dette kan virke som en introduktion til robotter og adfærd og kunstig intelligens.

For at sikre mere konsistente resultater kunne der være implementeret et running-average filter til at midle værdier fra sonar, farvesensor og især kompas. Dette ville gøre systemet mindre sårbart over for støj, men til gengæld øge dets responstid.


 

REFERENCER

  1. Demazeau, Yves: From interactions to collective behaviour in agent-based systems. I: Proceedings of the 1st. European Conference on Cognitive Science. Saint-Malo., 1995, (Artikel)
  2. The Faculty of Engineering. Udgivet af SDU. Internetadresse:http://fagbesk.sam.sdu.dk/study/fagbasen/fagprint.shtml?fag_id=27301&print=1 – Besøgt d. 19.05.2015 (Internet)
  3. Nielsen, Jacob: UserConfigurable Modular Robotics: Design and Use. 2008. (Bog)
  4. da Silva, Joao Luis: Vowels Co-ordination Model. 2002 (Artikel)
  5. Pfeifer, Rolf: Building “Fungus Eaters”: Design Principles of Autonomous Agents. 1996 (Artikel)
  6. Pfeifer, Rolf, and Josh Bongard. How the body shapes the way we think: a new view of intelligence. MIT press, 2006.
  7. Arduino Yun. Udgivet af Arduino.cc. Internetadresse: http://www.arduino.cc/en/Main/ArduinoBoardYun?from=Main.ArduinoYUN – Besøgt d. 19.05.2015 (Internet)
  8. TCS3472 COLOR LIGHT-TO-DIGITAL CONVERTER with IR FILTER. Udgivet af TAOS. Internetadresse:http://www.adafruit.com/datasheets/TCS34725.pdf – Besøgt d. 19.05.2015 (Internet)
  9. Sonar. Udgivet af Dosits. Internetadresse: http://www.dosits.org/science/soundsinthesea/peopleanimalsuse/sonar/- Besøgt d. 19.05.2015 (Internet)
  10. 3-Axis Digital Compass IC HMC5883L. Udgivet af Adafruit . Internetadresse:http://www.adafruit.com/datasheets/HMC5883L_3-Axis_Digital_Compass_IC.pdf – Besøgt d. 19.05.2015 (Internet)
  11. NODE.JS ON THE ROAD. Udgivet af nodejs. Internetadresse: https://nodejs.org/ – Besøgt d. 19.05.2015 (Internet)
  12. Ultrasonic Ranging Module HC – SR04 . Udgivet af micropik. Internetadresse:http://www.micropik.com/PDF/HCSR04.pdf – Besøgt d. 19.05.2015 (Internet)
  13. PING))) Ultrasonic Distance Sensor (#28015) . Udgivet af Parallax. Internetadresse:http://che126.che.caltech.edu/28015-PING-Sensor-Product-Guide-v2.0.pdf – Besøgt d. 19.05.2015 (Internet)
  14. Data til kompas
  15. Bourg, D. og Seemann, G. : AI for Game Developers. 2. udg. O’Reilly, 2004. (Bog)
  16. A*Pathfinding Toturial . Udgivet af CodeCompile. Internetadresse:
    https://www.youtube.com/watch?v=KNXfSOx4eEE – Besøgt d. 22.12.2014 (Internet)]
  17. Arduino Yún schematic http://www.arduino.cc/en/uploads/Main/arduino-Yun-schematic.pdf

Leave a Reply