Deltagere: Bjarke, Mikkel, Troels, Jesper
Tid: 5 timerMål
Målet med i dag er at få noget kommunikation op at køre imellem robot og computer. En robot skal kunne køre lige frem og stoppe, når den rammer grønt. Hvis der er tid til det skal vi igang med at få robotten til at dreje.Plan
1. Få kommunikationen imellem robot og computer til at virke.2. Implementer kommunikation imellem Hivemind og de enkelte minds på Computeren.
3. Lave en simpel implementation af, hvordan Seekermind opdager edges og tiles.
4. Få seeker-robotten til at køre frem indtil farvesensoren læser grøn.
5. Få seeker-robotten til at dreje i et kryds.
Resultater
Ordforklaring: Indledningsvist vil vi beskrive de termer vi bruger internt i gruppen til at beskrive dele af projektet. Vi finder dette vigtigt, da disse termer let kan blive anvendt her på bloggen, enten bevidst eller ved et uheld og vi vil derfor sikre os at læseren forstår meningen med disse.Banen består som tidligere beskrevet af tiles. Mellem disse tiles kan der være en forbindelse. En forbindelse imellem tiles kaldes en "Edge”. Hvis en robot skal køre igennem flere tiles over flere edges, er det en “Path”.
Vores software arkitektur lægger op til, at meget af robotternes adfærd bliver styret fra serveren og at selve robotterne kun har den simpleste kode der gør den i stand til at bevæge sig ud af forudbestemte tiles og rapportere når opgaven er fuldfør, samt hvilken type til den står på. Derfor har vi på serveren klasser der repræsenterer robotterne. En fælles betegnelse for disse klasser er minds. De nedarver hver fra klassen overmind og kaldes hhv. minermind, seekermind og demolishermind. Derudover har vi på serveren en klasse, der er ansvarlig for at nå målet. Den holder styr på banen og giver opgaver til robotterne etc. Denne klasse kalder vi hivemind.
Robotterne vil enten blive betegnet som robotter eller bare bots.
1. Sender og Receiver klasserne for både robotterne og serveren er blevet implementeret i en grov version. Serverens Sender kan give robotten besked om at bevæge sig. Frem, højre, venstre og et u-turn. Samtidig kan den give robotten besked om, at udføre sin specielle opgave, der er implementationsspecifik for hver enkelt robot.
Robottens Sender kan give besked om, hvilken tile den har fundet, om den har fundet en mur eller om den har udført den opgave, serveren har givet den.
Al kommunikation imellem server og robotterne foregår ved udveksling af integers. Disse er defineret i klassen ControlSignals:
public final class ControlSignals {
public static final int PERFORMTASK = 0;
public static final int FORWARD = 1;
public static final int UTURN = 2;
public static final int TURNLEFT = 3;
public static final int TURNRIGHT = 4;
public static final int TASKPERFORMED = 5;
public static final int FOUNDWALL = 6;
public static final int FOUNDCAVE = 7;
public static final int FOUNDENDOFMAP= 8;
public static final int FOUNDINTERSECTION = 9;
public static final int FOUNDGARAGE = 10;
public static final int SHUTDOWN = 11;
public static final int BACKWARD = 12;
}
2. Der er indført en række metoder til kommunikation imellem Hivemind og de enkelte minds (SeekerMind, DemolisherMind & MinerMind) og vi er blevet enige om, hvilke datastrukturer vi benytter til at holde styr over tiles og edges (kanterne) imellem tiles. For at holde styr de forskellige tiles er der i Hivemind'en oprettet et to-dimensionelt array der indeholder tiles, hvor indgangene svarer til x og y-koordinaterne i et 2-dimensionelt kartesisk koordinatsystem. Enten er en indgang Null eller også er der et tile. Typerne af tiles er defineret som en enum:
public enum TileType {
CAVE, INTERSECTION, GARAGE, UNDISCOVERED, MINED
}
To hashmaps benyttes til at holde styr over status for edges imellem de forskellige tiles. Disse opdateres løbende. Det ene er et opdateret map fra et hash af to tiles til de to tiles (en instans af TwoTiles klassen). Det andet fungerer som map fra to tiles til status for kanten mellem de to tiles (en EdgeStatus). EdgeStatus er en enum:
public enum EdgeStatus {
LOCKED, WALL, FREE, MAPEND, UNDISCOVERED
}To metoder i Hivemind'en holder styr over EdgeStatus for kanter imellem to tiles. De kaldes enten når en ny kant opdages eller når der er stillet en mur på en eksisterende kant og dette opdages af en robot. Samtidig er der lavet en metode (taskPerformed()), der kaldes når en robot har udført en serie af instruktioner og er klar til at modtage nye instruktioner fra Hivemind'en.
3. Der er oprettet en række metoder i SeekerMind, der via sin Receiver kan se og opdage edges og tiles. foundIntersection() og foundCave() metoderne kaldes af Receiveren når de forskellige typer af tiles findes. Metoden foundWall() kaldes når en robot finder en mur. SeekerMind har to metoder der er unikke for denne underklasse af Overmind (superklassen der er fælles for alle minds). Det drejer sig om metoderne discoverEdge() og discoverTile(). Disse metoder opretter nye edges og nye tiles gennem Hivemind'et. Dette foregår via Hivemind metoderne maintainHashToTilesMap() og createNewTile().
4. Vi har fundet noget gammel code frem fra uge 4, dette drejer sig om BlackWhiteSensor.java [1] og LineFollowerCal.java [2]. Vi har modificeret disse to så de passer med vores SeekerRobot. Det har været nødvendigt at tilpasse motorkraft og lige få gjort så motorene var på de rigtige porte. Vi har lagt koden i Miner.main() og robotten følger nu en streg. Vi skal have udvidet robotten så den stopper, når den tilsluttede farvesensor ser grønt. Seeker robotten ser nu sådan ud:
Vi har udvidet mineren så den nu stopper på grønt, her er en video:
Vi har valgt den meget simple løsning fordi vores hovedfokus ikke ligger på at få robotten til at køre pænt, men på at den skal kunne løse sin opgave. Hvis vi senere får tid til det vil vi arbejde på at få robotten til at køre pænere.
Koden der er fælles for robotterne er lagt ind i en fælles abstract klasse (AbstractMiner). Den har funktioner som f.eks. moveLeft(). Ideen er så at hvis der er noget opførsel der er forskellig, kan der nedarves fra denne klasse (f.eks. som i SeekerMiner).
5. Vi har prøvet os med at dreje mod højre ved et sving. Men vi rendte hurtigt ind i nogle problemer. Vi fandt ud af at vores 5 minutes robots [3] var for bredde og derfor havde svært ved at foretage “skarpe” sving ordentligt. Derudover er der nogle problemer med at lyssensoren bliver i tvivl om den kører på sort eller grønt, da farverne ligger tættere sammen end hvid/sort. Vi bliver derfor nød til at overveje nyt design af robotterne og tiles.
Konklusion
Vi har nået det vi planlagde. Vi har fundet ud af, at det er nødvendigt at ombygge robotterne så der er kortere imellem hjulene, da de ikke drejer skarpt nok nu. Ombygning af robotterne skal klares næste gang. Vi regner med at følge vejledningen i Lego Mindstorm byggevejledningen (9797). Vi skal også genoverveje, hvordan vores tiles skal se ud.Derudover skal vi implementere vores interne repræsentation af banen og de underliggende systemer, der skal gøre det muligt, at lave paths som robotterne skal bevæge sig ad. Vigtigst er det system, der skal gøre det muligt for seekeren at bevæge sig til uudforskede tiles. Vi står her med et problem, da vi både repræsenterer tiles og edges i vores system og begge dele skal udforskes, før seekeren er færdig med sit arbejde.
Slutteligt skal vi forbedre software arkitekturen af vores robotter, således at de kan kommunikere med Sender og Receiver klasserne. Derved håber vi også, at vi kan teste hele kommunikationen fra hivemindet til robotterne og tilbage igen.
Referencer
[1]: http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson4.dir/BlackWhiteSensor.java[2]: http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson4.dir/LineFollowerCal.java
[3]: http://www.nxtprograms.com/five_minute_bot/index.html
Ingen kommentarer:
Send en kommentar