Kristan Andersen, Simon Lykke, Jacob Styrup Bang

onsdag den 9. januar 2008

Lab Notebook 6


Date: 9.1.08
Duration of activity: 9:15-15:15
Group members participating: Simon, Jacob og Kristian

Dagens mål:
  • Reklamere over den defekte sensor
  • Finde en løsning på problemet vi har med infrarøde kilder
  • Begynde at lave software strukturen.

Reklamation over defekt sensor
Vi testede igen den infrarøde sensor vi havde problemer med i går. Den er helt klart defekt. Den måler altid et kraftigt signal på den ene interne sensor. Iflg. Lego's hjemmeside skulle vi udfylde en "Customer Service Replacement Parts Form", hvilket vi gjorde. Nu håber vi at vi får en ny inden for en rimelig tid.
Infrarøde kilder
Vi havde fået fat i en infrarød diode fra en fjernbetjening, som vi seriekoblede med et 1,5V batteri. Vi havde håbet på en bedre spredning, men det viste sig at spredningen var nogenlunde den samme som med de dioder vi testede sidst. Vi vil undersøge om vi kan få fat i nogle flere, så vi kan lave en kæde af dioder til at sætte på robotten.
Arkitektur
Vi besluttede at bruge den indbyggede behaviour struktur i leJOS, da vi havde nogle problemer med den alternative arbitrator fra Lesson 10. Dette medfører at vi skal være påpasselige med vores implementationer af action og suppress metoderne i Behaviour. De behaviours som skal implementeres er:

  • Random drive
  • Catch
  • Avoid
  • Stay On Track

Random drive behaviour'en skal have lavest prioritet. Opførslen skal bare sørge for at robotterne ikke står stille, hvis de ikke kan se hinanden.
Catch/Avoid opførslerne er dem som "styrer" legen. Hver robot er enten catcher eller avoider, men kun en af tingene ad gangen. Disse behaviours tager kun over når robotten kan se den anden robot på sin IR sensor. Hvis ikke kører robotten bare tilfældigt rundt pga. random drive opførslen.
Stay On Track opførslen har højest prioritet. Begge robotter skal holde sig inden for banen, for at overholde spillet regler.
Implementation
Vi gik igang med at implementere de simple behaviours først. Random drive er en simpel behaviour, som sørger for at robotten kører tilfældigt rundt. Denne er implementeret ved at robotten sætter en ny hastighed på hver af de to motorer hvert andet sekund. Dernæst gik vi igang med at implementere StayOnTrack behaviour'en. Denne er lidt mere kompleks end først nævnte. Robotten skal bruge sine to lys sensorer til at holde sig inden for banen, som foreløbig er en stor hvid rektangel på gulvet. Lyssensorerne kan nemt skelne mellem det det hvide plastik, og det mørke gulv. Vi implementerede opførslen ud fra tre forskellige tilfælde, hvis en af de to lys sensorer måler en værdi der er under terskel værdien skal motoren i den modsatte side stoppe, mens den anden motor kører frem. I sidste tilfælde læser begge sensorer værdier, som er under terskel værdien, og der skal begge motorer sættes til at bakke. I starten havde vi problemer med at robotten i nogle tilfælde, specielt omkring hjørnerne af banen kom uden for banen, og låste sig fast i en undvige manøvre. Vi undersøgte arbitratoren fra leJOS og fandt ud af at en Behaviour ikke må køre flere gange i træk, derfor ville robotten låse, da StayOnTrack opførslen hele tiden ønsker kontrol, men denne er færdig afviklet. Vi ændrede opførslen så action metoden først afsluttede når robotten var tilbage på banen.
Næste skridt var at få robotten til at bevæge sig hen mod det infrarøde lys. Her startede vi med at køre robotten med en enkelt behaviour. Vi oplevede problemer med at robotten var langsom til at reagere på at vores lyskilde blev flyttet. Efter nogen eksperimentering med koden fandt vi ud af at fejlen opstår når man forsøger at læse direction værdien fra sensoren for ofte. Da denne fejl var rettet havde vi en simpel program version, som kan holde sig indenfor banen, køre tilfældigt rundt, og følge en lyskilde hvis denne er tilstede. En mulighed var at følge Nyquist's sampling theorem(1), men først og fremmest var det svært at lave målinger på frekvensen, og samtidig var vi nødt til at sætte sampling frekvensen lavt for at sensoren kunne følge med.

Vi har undervejs udelukkende brugt simple feedback control, som beskrevet i Robotic Explorations: A Hands-on Introduction to Engineering,. Et alternativ kunne være en form for proportional kontrol i tilfældet af IRSeekeren. så jo længere væk jo kraftigere skulle der reageres, men vi startede med den simple feedback kontrol. Senere kan man eventuelt erstatte den med proportional kontrol...
Konklusion
Vi fik bestilt nogle infrarøde dioder, som gerne skulle løse vores problem med lyskilder. Vi fik også reklameret over den defekte lego sensor, og håber på at modtage en ny inden præsentationen d. 17 januar.
Vi fik lavet en del af den behaviour baserede arkitektur, og har nu en simpel robot, som understøtter en stor del af den krævede opførsel. Dog mangler vi stadig avoider behaviour'en, samt den endelige kommunikation over bluetooth.
Under tests med robotterne opdagede vi at lyssensorer ikke fungerer på sensorport 4, mens tryk sensorer virker fint. Vi har ikke kunne finde årsagen til dette, men det kan evt. at port 4 hardware mæssigt adskiller sig fra de andre.
Referencer
(1) - Electronics - A Systems Approach, Neil Storey. s 602.

Ingen kommentarer: