mandag den 4. juni 2012

Slutprojekt, del 4


Deltagere: Bjarke, Mikkel, Troels, Jesper
Tid: 6 timer

Mål

Målet er, at få robotterne til at virke, og at bygge videre på hiveminden.


Plan

1. Robotterne skal ombygges, så de fylder mindre og kan dreje skarpere.
2. Vi skal diskutere, hvordan vores tiles skal laves, så det er muligt at lave et korrekt sving til både højre og venstre, samt at fortsætte lige frem.
3. Vi skal også diskutere, hvordan vi bruger vores interne repræsentation af edges og tiles, til at lave stier, som robotterne kan følge. Denne diskussion skal også nå frem til en løsning på, hvordan og i hvilken rækkefølge banen skal udforskes af vores seeker.
4. Udvid softwaren på robotterne, så den passer til det nye design. Derudover skal dens evne til at bevæge sig i banen forbedres. Den skal begynde at anvende bluetooth kommunikation så dette kan testes.
5. Serveren skal udvides, så den kan lave stier rundt i banen baseret på forskellige mål. Disse stier skal kommunikeres med hvert mind og disse skal videre kunne tolke dem og give ordre videre til robotterne. Også på denne side skal bluetooth kommunikation implementeres yderligere.
6. Test kommunikationen mellem robotterne og serverne. 



Resultater

1.
Vi har bygget dem efter anvisningerne i Lego manualen. Derudover har vi en special tilbygning for at holde vores lys og farvesensorer (se billede længere nede på bloggen).

2.
Vi har haft en stor diskussion omkring design af tiles. Vi havde sidste gang nogle problemer med det design af tiles vi havde lavet. Problemene bundede i at vores lysforskellene imellem grøn og sort ikke var store nok til at vi kunne styre om robotten kørte ligeud eller drejede. Dette ledte til en større brainstorm over hvordan de skulle opbygges. Resultatet kan se på nedstående tavle:







Vi er nåede frem til et nyt design, hvor vi har helt lige sorte veje og grønt i midten af kryds. Her er planen så at robotten følger stregen indtil den læser grønt. Så kører den lidt frem og roterer på stedet indtil farvesensoren læser sort igen, hvilket betyder at den har ramt stregen.
Det gav et sensorsetup, hvor vi har en farvesensor i midten foran robotten og en lyssensor der står lidt forskudt til højre, som skal følge stregen. Tiles ser nu således ud:






Efter test fandt vi ud af, at problemet ligger i at farvesensoren mange gange læser grænsen imellem hvid og sort som grøn. Derfor gik vi over til et rødt midterfelt.
Efter et par test havde vi stadig lidt problemer, nu med at farvesensoren overser det røde område. Vi prøvede at få placeret sensorerne bedre i forhold til hinanden.
Efter en del test lykkedes det at få robotten til at køre som vi ønskede. Vi endte med følgende opsætning af sensorer (hvor farvesensoren er forrest og lyssensoren er bagerst, nærmest hjulene):




Det resulterede i følgende video.





 

3. Indledningsvist diskuterede vi igen, hvilke krav vi kunne sætte til start tilstanden for banen. De tre robotter starter i hver deres garage. Her diskuterede vi, om dette krav skulle udvides til også at inkludere hvert tile foran garagen, således at vi med sikkerhed kan forvente et intersection-tile der. Dette vil gøre det muligt for robotterne at køre ud uden at disse tiles først skulle opdages af seekeren. Denne diskussion startede, idet vi endnu ikke havde gennemtænkt systemet for udforskningen af banen. Overvejelserne om dette system vil blive specificeret herefter, men først vil vi præcisere de krav til starttilstanden vi endeligt fastlagde:

De tre garage-tiles skal ligge ved siden af hinanden. Der er kun én vej ud fra en garage og denne skal pege i samme retning for alle tre tiles. Grundet vores interne styring af robotterne skal vi altid vide, på hvilket tile de befinder sig. Derfor er det et krav, at seekeren altid starter på tilet yderst til venstre, således at når den forlader garagen kan den passere de andre robotters garager ved at dreje til højre. Internt giver vi de tre tiles x, y koordinaterne (10, 10) - seekerens garage, (11, 10), (12, 10), da det således giver mulighed for at disse tiles kan placeres et arbitrært sted i banen. Koordinatsystemet for banen defineres dernæst ud fra garagernes placering, således at første tile seekeren kører ud på har koordinat (10, 11). Der stilles ingen krav til de tiles, der ligger umiddelbart udenfor garagerne, men hvis de ikke er intersections bliver det en kedelig bane.


Diskussionen om, hvordan banen skulle udforskes af seekeren, blev lang og endte med at inkludere mange omskrivninger af og tilføjelser til koden. Problematikken består i den måde vi håndterer tiles og edges på internt. Som tidligere beskrevet her på bloggen, har hvert tile sin egen repræsentation bestående af et x, y koordinat og en type. En edge beskrives af en hash værdi mellem de to tiles den forbinder. Internt har vi hashmaps der forbinder de forskellige hashværdier sammen med en status for hver edge (undiscovered, free, locked, wall, map-end) og et andet map, der binder hashet sammen med de to tiles edgen ligger imellem. Dette er nødvendigt, da vi ikke kan gå fra en hashværdi til de oprindelige x, y koordinater den er lavet af.
Seekerens job er at besøge alle uudforskede tiles og edges. Dvs. vi skal konstant opretholde en oversigt over de edges og tiles, der endnu ikke er blevet undersøgt. Hver gang seekeren finder en ny intersection ved den, at der går fire edges ud fra denne, hvoraf én er den, den er kommet ind ad. Den skal derfor oprette tre nye kanter, hvilket let kan gøres da vi kender x, y koordinatet for tilet. Det er dog muligt, at et nabo-tile allerede er blevet opdaget tidligere, hvorfor edgen muligvis findes i systemet. Hvis dette er tilfældet, kan vi derfor ændre status for den edge til free i stedet for undiscovered. Der er en mængde af lignende tilfælde, der skal håndteres, men disse vil ikke blive specificeret her. 
Hver gang en edge oprettes opretter vi også de nye tiles denne edge leder over til. Dette gør vi uanset om den tile eksisterer i banen eller ej (også hvis edgen leder ud af banen). Når seekeren så forsøger, at bevæge sig ud af en edge, der ikke leder over til et nabo tile (som der sker i kanten af banen) vil den opdage, at edgen ender blindt og returnere dette. Således vil vi ende med tiles i vores system, der ikke findes rent fysisk, men som er nødvendige for systemet.
Årsagen til at de er nødvendige er, at vores robotter altid bevæger sig mellem tiles. En robot kan ikke sendes til en edge. Dette er et resultat af banens fysiske opbygning. Vi kan ikke opdage, hvor langt inde på en edge vi er, og derfor risikerer vi at blokere for andre robotter, hvis vi kører for langt eller for kort ud af edgen. For at en edge kan blive opdaget, skal vi derfor sende robotten fra det ene tile til det andet.
Da vores implementation kan indeholde ikke-eksisterende tiles, der er uopdagede, blev vi nød til at ændre vores krav til seeker robotten. Det eneste den skal undersøge, er uopdagede kanter. Derved ved vi, at hvis der ikke er nogen uopdagede kanter tilbage, findes der heller ingen uopdagede tiles, der er inden for rækkevidden af robotterne.
Alle disse overvejelser, beslutninger og tilhørende kode-ændring og skrivning betød, at vi ikke fik lavet funktionen, der genererer en sti. Målet for næste gang er derfor, at få implementeret denne.


4. Det var rimelig simpelt at få sat robottens funktioner sammen med Sender og Receiver klasserne, så den var klar til bluetooth kommunikation, da stort set al koden var på plads allerede. Som det kan ses på videoen under punkt 2, fik vi robotten til at køre og reagere på de røde midterfelter i krydsene.


5. Dette nåede vi desværre ikke, idet punkt 3 tog længere tid end beregnet.

6. Dette punkt nåede vi heller ikke.

Konklusion

Vi er kommet i mål med at få robotten til at følge et grid. Dette gør, at vi nu kan komme videre med de andre dele af projektet, da vi nu har de basale funktioner på plads, så vi kan bruge det til at teste de andre funktioner med. Af de grundlæggende robot funktioner mangler der kode til at rotere 180 grader, hvis robotten skal vende om. Derudover mangler vi at håndtere hulerne (som nu skal have en anden farve end rød).

Yderligere fik vi gennemarbejdet vores måde at udforske banen på og dette betød også, at vi fik tilføjet nye funktioner og fjernet bugs i koden. Generelt har vi nu et bedre system, omend det tog lang tid at nå dertil.
Næste gang vil vi forsøge at nå punkt 5. og 6. fra planen.

Ingen kommentarer:

Send en kommentar