Friday, May 31, 2013

Week 15 - Session 3

Dato:

31-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

LEGO-robotten kan se bolden på lang afstand. Den er i stand til at affyre et skud i en rimelig konsistent retning. Vi har store problemer med at få kompasset til at virke og koden trænger til en grunding oprydning.

Mål

Målet er at have den endelige konstruktion af robotten færdig, så vi har en robot, der fungerer bedst muligt ud fra de eksperimenter, vi har lavet. Der skal også arbejdes videre med eksperimentet omkring at få robotten til at kunne bestemme hvilken retning, den er positioneret i vha. kompasset, så den ud fra det, kan finde og skyde mod det rigtige mål.
Indtil videre består koden til projektet af brudstykker, som kun virker isoleret til specifikke test. I denne session vil vi opsætte en arkitektur af koden så de forskellige adfærd kan begynde at køre sammen.

Plan

  • Videreudvikling af robotten.
  • Refaktorering af kode.
  • Videre test med kompas.

Proces


Videreudvikling af robotten

Vi arbejde videre med TrikeBase prototypen sideløbende og har løbende arbejdet ud fra at indføre de erfaringer, vi er kommet frem til på vores anden prototype. De primære forbedringer vi har lavet i forhold til TrikeBase basen er følgende:
  • Vi har monteret fangekrogen og dribleren foran på robotten i stedet for den bøjle som normalt i på TrikeBase modellen.
  • Vi har ombygget baghjulet til at være mere lodret for holde robotten under de 22 cm. For at robotten stadig skulle beholde den rigtige hældning i forhold til baghjulet har vi monteret større forhjul. Vi bar bygget en bar øverst på robotten til at montere IR sensor og som skal bruges til kompas sensor for kompas sensoren væk fra motoren og for at sørge for at IR sensoren ikke bliver dækket af robottens andre dele.
  • Vi har indført gearing for at gøre robotten hurtigere og mere kvik hvilket oftest er en stor fordel i fodbold.
  • Vi har monteret afstandsensor under robotten til at registrere hvornår bolden er i robottens besiddelse. Vi er dog kommet frem til at der skal bruges tryk sensor da afstandsensoren har svært ved registrere bolden. Denne funktionalitet har vi valgt at flytte fra den anden prototype når den endelige udgave laves.
Den endelige robot prototype vi kom frem til ud fra TrikeBasen ser ud som billedet. Den er meget stabil og holder sig lige præcis inden for de 22 cm i diameter.

Færdig Robot2

Robot2 under hjulskift

Refaktorering af kode

Det kode vi har til robotten på dette tidspunkt er følgende 3 adfærd.
  1. Køre tilfældigt rundt.
  2. Skyde.
  3. Finde bolden og køre hen imod den.
Til håndtering af det adfærdbaserede logik har vi brugt Ole Capranis Arbitrator.java [1] og Behavior.java [2]. Vi har tilføjet en abstrakt klasse AbstractBehavior.java [3] som implementerer Behavior. I den klasse implementeres metoden suppress som sætter en boolean variabel suppressed til true. Metoden action har vi også implementeret i den abstrakte klasse fordi vi som udgangspunkt altid vil sætte suppressed til false i starten af enhver action. Til gengæld kræver den abstrakte behavior at metoden customAction implementeres af klasser som nedarver fra den. AbstraktBehavior.java kalder customAction i dens action metode. En ting vi havde lidt problemer med, med vores adfærd var at de nogle gange tog kontrol hurtigt selv igen. Uden at bruge tid på at undersøge det længe tilføjede vi en boolean variabel executingAction som sættes til sand når action kaldes og til falsk når action er færdig. Den kan bruges i metoden takeControl til at tjekke for at en adfærd ikke skal afbryde sig selv hvis det er det man har lyst til.
Til hver af de tre ovennævnte adfærd lavede vi en klasse som nedarver fra AbstractBehavior.java så de kunne komme ind i adfærdhierarkiet. Det er nu nemt senere at tilføje nye adfærd til hierarkiet.
Udover at refaktorere koden til at være adfærdbaseret tilføjede vi klassen Robot.java [4]. Robot.java er en beskrivelse af robottens fysiske forhold. F.eks. hvor motorerne og sensorerne er forbundet.
Selvom de tre adfærd er lette at få til at virke sammen programmeringsmæssigt, kan de stadig ikke virke sammen i praksis fordi vi endnu ikke har en måde til at afgøre om robotten har bolden på. Dvs. at vi ikke ved hvornår skydeadfærden skal tage kontrollen.

Videre test med kompas

Efter en halv dags test af kompasset af en ny person der ikke havde adgang til første forsøg, var resultatet nogenlunde det samme. Der var en smule fremgang, da vi nu kunne kalibrere kompas ift. motor-støj samt støj fra brikken. Det overordnede resultat var dog det samme - robotten fandt et nyt Nord alt efter hvor på banen den stod.
Kalibrering sker ved at dreje langsomt om robottens akse i 20-40 sekunder, efter et kald til at starte kalibreringen. Ideelt set skal robotten dreje én omgang pr. 20 sekunder, men vi fandt at der ikke var nævneværdig forskel imellem en kalibrering hvor den kørte en smule hurtigere rundt. Ligeledes fandt vi, at kalibreringen sagtens kunne foretages hurtigere (forsøgt med halv tid) med samme effekt. Eftersom kompas-sensoren blot skal kalibreres én gang pr miljø den kører i (gemt permanent efter hver kalibrering, men kan overskrives), besluttede vi os for at lave en lang og præcis kalibrering på vores endelige testbane. Herunder ses en af vores første forsøg med kalibrering (de første havde hurtig omdrejninghastighed).


Brugen af Differentiel Piloten fik omdrejninghastigheden ned på 360 grader / 40 sekunder = 9 grader pr sekund, hvilket styres præcist uafhængigt af batteriniveau, fra denne klasse.

Konklusion

Vi har refaktoreret koden til at være adfærdbaseret jf. vores teori, så det er let at tilføje og fjerne adfærd. Det er samtidig let at teste ved at sætte den adfærd som skal testes til at returnere noget højere end de andre. Vi mangler at få vores ultrasoniske sensor til at registrere når robotten har bolden, hvilket kræver lidt flere test med målingerne.
Vi har på dette tidspunkt besluttet indtil videre kun at gå videre med en markspiller og ikke en til at stå i mål, fordi målene ikke er store i forhold til robotterne og på det niveau vi forventer at vores robot kommer til at kunne sigte og skyde på mål, vil det ikke være realistisk at score, hvis der står en robot i målet (selv hvis den ikke bevæger sig). Hvis vi når at lave en markspiller der kan skyde fornuftigt på mål vil det give mening at fortsætte med en som står i mål.

Referencer


Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)