Deltagere: Bjarke, Mikkel, Jesper, Troels
Varighed: 4 timer

Mål

Vi skal arbejde videre med Mind arkitekturen og få bygget de tre robotter. Derudover vil vi gerne have lavet nogle baneelementer (tiles).

Plan

1. Byg tre ens robotter.

2. Få arkitekturen på plads.

3. Tegn og print nogle baneelementer.

4. Begynd på at kode.

Resultater

1. Vi konstruerede tre ‘five minute bots’ [1]. Disse blev udbygget med farvesensorer der kigger ned i jorden. Sensorerne skal bruges til at finde vej i banen. Derudover tilføjede vi ultralyds-sensorer, da de alle skal kunne håndtere blokeringer af den edge de bevæger sig ad. Vi er ikke overbevist om, at én farvesensor er tilstrækkeligt. Det er nok til at bevæge sig ned ad en sort edge, men vores robotter skal kunne identificere om edgen pludselig stopper og dette vil muligvis være lettere med to sensorer.

Derudover har vi udbygget “DemolisherBot” med en “fejearm”, der kan fjerne mure fra banen, ved at feje dem til side:

2. Sidste gang diskuterede vi hvorledes kommunikationen mellem robotterne og serveren skulle fungerer [2].
Denne gang er målet at få fastsat en arkitektur på server siden. Som vi bestemte sidst, skal vi bruge en bot-klasse der kan styrer robotterne rundt. Den er ansvarlig for al kommunikation mellem server-arkitekturen og robotterne. Denne bot klasse nedarves af mere specialiserede robot-klasser, der hver især også kan varetage specifikke opgaver.
Indledningsvist lagde vi meget arbejde i, at planlægge hvordan stier skulle kommunikeres mellem vores Hivemind (Den der er ansvarlig for, at det overordnede mål bliver mødt) og bot-klassen. Vi planlagde en simpel form, hvor robottens handlinger og ikke selve stien bliver kommunikeret. Bot-klassen ville da blot modtage en liste over kommandoer, såsom: “LEFT, FORWARD, FORWARD, LEFT...”

Dette gav dog problemer da computeren derved skulle bevare information om robotternes umiddelbare kørselsretning, for at beslutte om der skulle bruges f.eks. FORWARD eller LEFT. Derudover ønskede vi et system, hvor Hivemind'en reserverede stier som robotterne skal bevæge sig ad og i dette system vil det være fordelagtigt at hver del af stien kan ‘unlockes’ løbende, som robotten bevæger sig ad stien. Hvis vi brugte denne kommando-baserede kommunikation, ville computeren selv skulle opretholde en oversigt over de stier robotterne bevæger sig ad, så den kan åbnes løbende. Dette talte samlet set imod et design, hvor hele stier blev sendt til robotten på samme tid.

Vi besluttede at anvende et system der lægger ansvaret for retning hos robot-superklassen (NB. tidligere 'Bot', nu kaldet 'Overmind' (indsat d.25/6)). Fordi vores bane har en grid-baseret opbygning, kan Overmind-klassen også holde styr på robottens placering i banen ud fra et x,y koordinatsystem. Vores Hivemind skal derfor blot sende en liste med tiles, der udgør den vej robotten skal køre til sit mål, til robot-klasserne, hvorefter disse selv opdeler dem i enkelte trin og sørger for at robotten udfører disse ét af gangen. Hiveminden reserverer alle tiles involveret i ruten, således at andre robotter ikke kan bevæge sig over disse før de åbnes igen. Når en robot har bevæget sig fra et tile til et andet, kan det forrige tile åbnes op igen, hvorfor dette skal rapporteres til Hivemind'en.

Banen består, som beskrevet i første blogpost, af kvadratiske tiles. Disse repræsenteres internt af en Tile-klasse. Der kan potentielt være en forbindelse mellem to nabo tiles, men dette er ikke sikkert, derfor skal veje også kunne identificeres. Som beskrevet i forrige blogpost overvejede vi at gøre dette ved hjælp af en matrice, med tiles på hver akse, hvorfor hver indgang i matricen derfor skulle beskrive en potentiel forbindelse. Dette design har vi opgivet af forskellige årsager. En af dem er, at der ville være meget spildplads idet der maksimalt kan være fire forbindelser fra en tile til andre tiles. Yderligere ønskede vi at kunne beskrive om der var en vej fra til A til B og måske ikke fra B til A, idet en blind vej stadig kunne benyttes som midlertidig holdeplads for en robot. Dette blev dog opgivet, efter vi lavede prototyper af de fysiske tiles robotterne skulle færdes på. Det viste sig at de blinde veje ikke var tilstrækkeligt store til formålet, hvorfor dette 2-vejs system er overflødigt.
Vi besluttede at anvende et hashmap i java. De værdier vi mapper sammen er en unik hashværdi for to nabo tiles og en enum der beskriver stiens tilstand (er den der, er den reserveret, er den blokeret etc). Hashing algoritmen ser pt således ud: ( (tile1.x + tile2.x) ^ 37) * (tile1.y + tile2.y) baseret på [5] (NB. Ændret - beskrives i blogpost 7 (25/6)).

Følgende billede viser et uml-diagram over vores server-arkitektur samt en to-do liste.

Vi har besluttet at tage udgangspunkt i kun at have to slags tiles: et kryds og en hule med en indgang. Derudover overvejer vi at have garager for robotter.

Kryds:

Problemet med denne repræsentation er, hvordan robotterne skal finde over til de nye streger... Her har vi udtænkt følgende tile. Tanken er her, at vi kan bruge en farvesensor [3] til at opdage hvornår vi er i det grønne område og en lyssensor [4] til at følge den sorte streg:

Hule:

Tanken er her at hvis robotten vil ud af hulen, skal den finde grænsen imellem rød og hvid og derefter køre rundt indtil den finder den sorte streg.

4. Løbende med arkitektur diskussionen er der blevet implementeret enkelte interfaces og klasser der hører til på serveren.

Efter dagens diskussioner har vi fastsat de essentielle variable på hoved-serveren, der skal håndtere verden og robotterne:

Map paths = new HashMap<String, Integer>(); //kanter mellem Tiles

Tile tiles[][] = {}; //Tiles, indgangen i array svarer til position i kartesisk koordinatsyst.

MinerMind miner;

SeekerMind seeker;

DemolisherMind demolisher;

Hver af de tre *Mind klasser repræsenterer en robot. Som tidligere nævnt nedarver de fra en OverMind-klasse. Denne har følgende constructor:

public Overmind(HiveMind mind, String bluetoothAddress, String bluetoothName, Tile startTile)

Som det ses af denne, tager hver implementation en forbindelse til Hivemind'en, hvilket gør dem i stand til at kommunikere med denne. Derudover tager den informationer der gør den i stand til at oprette en bluetooth forbindelse til den robot den repræsenterer. Det sidste argument den tager er et Tile, det repræsenterer det felt hvor robotten starter. Dette gør det muligt for robotten at opretholde et billede af hvor i banen den befinder sig.

Slutteligt implementerede vi Tile klassen. Denne er blot en simpel klasse der holder et x,y koordinat og en type.