Finally showing off the robot

The day finally came, where we had to show off the robot we have worked on for 6 months off to the world. It is of course based on Lego Mindstorms as you know if you have followed this blog ;). Otherwise you can read up on the progress from start to finish in the menu to the right.

As you can see in the video above, we settled for a transportation mechanism inspired by movement of insects. This makes the robot far more stable at the cost of speed. I hope you liked the robot apologies for the short post, i'll be back with more shortly!.

P.S. As you noticed we are switching from danish, to English to make the blog useful for more people.

Slut Projekt Session 7

Slut Projekt Session 7

Tid: 5 timer, Deltagere: Kenneth, Rawad.

Siden sidst:
Vi har fremvist vores projekt til End Course Project fremvisningen og alt gik godt.

Formål:
Formålet med denne session er at afprøve samt evaluere ideer til forbedring af IR seeker mekanismen.

Plan

1. Konstruer en mekanisme der kan vise i hvilken retning den foreslåede metode udregner bolden til at befinde sig i.
2. Implementering samt evaluering af metoder.
3. Diskusion.
4. Konklusion

1. Konstruer en mekanisme der kan vise i hvilken retning den foreslåede metode tror bolden befinder sig i:
Mens vi bevæger bolden rundt foran IRSeekeren vil det være nyttigt at have en måde at se hvor robotten udregner bolden til at være. Dette har vi i første omgang løst ved at logge målingerne, der er dog en stor ulempe ved denne metode da det er svært at sammenligne målingerne bagefter med hvad der skete realtid. Derfor har vi valgt at lave en anden konstruktion hvor IRSeekeren plus motoren den er monteret på sidder sammen med en anden motor. Denne motor skal så være styret af robotten og pege i den retning som robotten udregner bolden til at være i. Dermed vil det være tydeligt at se hvor præcis og hvor hurtig den enkelte metode er. Konstruktionen kan ses her:


2. Implementering samt evaluering af metoder.

2a. Svingnings metode
Denne metode til bestemmelse af boldens retning er beskrevet i “Slut Projekt Session 5”[4] i den beskrivelse bruger vi eksponentielt løbende gennemsnit til at udregne den nye vinkel. Her har vi i stedet valgt at tage gennemsnittet over målingerne for den sidste svingning således at forsinkelsen forkortes. Koden kan findes her[1].

Test:
 

Evaluering:
På videoen ses at svingnings metoden bestemmer boldens retning overraskende dårligt taget i betragtning hvor godt den så ud til at klare sig i testen i “Slut Projekt Session 5”[4]. Vi har prøvet at forbedre metoden ved at tælle antal målinger pr. svingning og tage højde for det i udregningerne. Dette har dog ikke ændret på metodens præstation. Koden brug i denne forbedring kan findes her[2]  

2b. Seeker metode
Denne metode til bestemmelse af boldens retning er beskrevet i diskussionsafsnittet i “Slut Projekt Session 5”. Vi vil i første omgang prøve at få IRSeekeren til at følge bolden ved at dreje så bolden hele tiden befinder sig i direction 6. Denne direction er meget smal i modsætning til f.eks. direction 5, som det kan ses i undersøgelsen af IRSeekeren i “Slut Projekt Session 4”[5].
Koden brug til testen kan findes her[3]

Test:

I denne test bevæger indikator armen til venstre sig ikke da IRSeeker selv indikere hvor bolden udregnes til at være. IRSeekeren peger ca. 30 grader til højre for bolden. 

Efter studering af karakteristikken for IRSeekeren kunne vi se at direction 4 er smallere end direction 6 hvilket betyder at vi kan øge præcisionen med den deterministiske regulering vi gør brug af. Resultatet af skiftet til direction 4 kan ses her:

 

Det kan ses at direction 4 rigtigt nok forøger præcisionen, dog svinger seekeren meget da det er svært at regulerer motoren til at stå stille indenfor sådan et smalt område.


4. Konklusion
I denne session evaluerede vi den tidligere brugte svingnings metode på en ny måde, som viste at metoden ikke var så præcis som vi først havde målt. Vi afprøvede også en tidligere foreslået metode, Seeker metoden, som viste sig at være meget præcis. Vi vil ikke arbejde videre med optimering af IR seeker mekanismen da dette er vores sidste session. Havde vi dog haft mere tid ville vi prøve at kombinere de 2 metoder så IRSeekerens svingninger ville være meget smallere og placeret omkring direction 4.   

Referencer:
[1]:https://dl.dropbox.com/u/4447110/IRSeekerFollowB2.txt
[2]:https://dl.dropbox.com/u/4447110/IRSeekerFollowB5.txt
[3]:https://dl.dropbox.com/u/4447110/IRSeekerFollowB3.txt
[4]:http://legolabsblog.blogspot.dk/2012/06/slut-projekt-session-5.html
[5]:http://legolabsblog.blogspot.dk/2012/06/slut-projekt-session-4.html

Slut Projekt Session 6

Slut Projekt Session 6

Tid: 5 timer, Deltagere: Kenneth, Rawad.

Siden sidst:
Intet at bemærke.

Formål:
Formålet med denne session er at færdiggøre subsumption arkitekturen for opponent robotten samt færdiggøre konstruktionen af den fjernstyrede segway (montere IR kugle). Dette vil være sidste session inden fremvisning, der vil derfor være fokus på små justeringer[1]

Plan

1. Kig på Subsumption Arkitektur i opponent robot.
2. Monter IR bold på segway robot.
3. Undersøg og forbedre spille værdi.
4. Konklusion

1. Subsumption Arkitektur i opponent robot
Efter vi oplevede problemer med subsumption arkitekturen i sidste session der er baseret på en arbitrator, har vi valgt at implementere en hieraki baseret subsumption arkitektur. Forskellen på de to arkitektur er at behaviors suppresser hinanden som det kan ses i diagrammet herunder, hvor der istedet ville have været en arbitrator til at beslutte hvem der er suppressed.
En vigtig forskel mellem vores implementering af hieraki baseret arkitektur og arkitektur med arbitrator er at alle behaviors er selvstændige tråde der forløber kontinuerligt, og det der suppresses er kun adgang til motorene.



Vi introducerede fire behaviors i den nye arkitektur:
MonitorTouch:
Har ansvaret for monitorering af touchsensoren og registrering af tab for opponent robot[6].

MonitorInfrared:
Har ansvaret for monitorering af IRSeekeren og rapporterer directions til KillSegway behavior[5].

DiscoverSegway:
Har ansvaret for at undersøge terrænet for at finde den fjernstyrede segway, i realitet køres der rundt random indtil behavior bliver suppressed[7].

KillSegway:
Har ansvaret for at fange den fjernstyrede robot. Vi har valgt at implementere to udgave af denne behavior for at kunne justere sværhedsgraden i spillet.

Den første killSegway behavior er baseret på switch styring som det ses i forrige session. I.e. killSegway modtager en direction fra MonitorInfrared og vurdere ud fra nogle IF-statements hvilken vej den skal tage. Derudover er der inkluderet nogle kunstige delays for at gøre det lettere at undgå at blive fanget[8].

Den anden KillSegway behavior er baseret på en PID Controller. Dog anvendes kun den propertionelle del af PID controlleren. Når denne behavior aktiveres har den fjernstyrede segway reelt ingen chance for at undgå opponent robotten[9].

Behaviors initialiseres i main, hvordan dette udføres kan ses her[4].

2. Monter IR bold på segway robot.
For at IR bolden er i samme højde som IR seekeren har vi måtte placere den oven på segway robotten. På grund af boldens glatte overflade har vi valgt at lave en slags holder hvori bolden er spændt fast med elastik. Den orginale segway robot blev beskyttet ved fald af gummi dutter for og bag. Desværre betød boldens placering på toppen af robotten at det nu var den der skulle tage slaget når robotten væltede. Dette var ikke hensigtsmæssigt da bolden ikke ser ud til at være designet til at kunne modstå sådanne slag. Derfor valgte vi at konstruere en støttehjuls anordning til hver side af segway’en sådan at den ikke bliver udsat for samme høje acceleration når den vælter.

Effekt:
Desværre havde monteringen af IR bolden samt støttehjulene den effekt at vægten af robotten blev forøget væsenligt samt tyngdepunktet blev højere. Dette resulterede i at robotten ikke hold balancen så fint som den havde gjort tidligere. Dog var den stadig i stand til at stå uden at svinge for meget og køre efter kommandoerne fra telefonen dog med nedsat reaktionshastighed.


Resultatet ses her:



3. Undersøg og forbedre spille værdi
Efter skiftet fra arbitrator baseret arkitektur til hieraki forsøgte vi at optimere KillSegway behavioren ved at anvende en PID-Controller. PID-Controlleren viste sig dog at gøre spillet for svært, da den fjernstyrede segway kun er blevet langsommere efter tilføjelsen af IR-kuglen. For at gøre spillet sjovere tilføjelse en mulighed i start menuen for at skifte sværhedsgrad. Måden dette er gjort på er ved at have to implementeringer af KillSegway behavior og skifte hvilken af disse bliver initieret på baggrund af valget i menuen.

Den nemmere udgave af KillSegway er baseret på en switch struktur som det kan ses i forrige session. Grunden til at vi vælger en switch struktur er at det i kombination med et delay, for robotten til at køre i nogenlunde rigtig retning men ikke helt præcist. Dette giver mulighed for at den fjernstyrede segway kan komme om bagved opponent robotten og ramme touchsensoren der får den til at vinde spillet.

Introduktion af touchsensoren skyldes at det føltes lidt håbløst at spille, uden at have nogen mulig måde at vinde på. Uden touchsensoren ville det bare være et spørgsmål om tid før man tabte.

4. Konklusion
Det lykkedes os at få begge robotter klar i stand så de kan fremvises. Subsumption arkitekturen virkede tilfredsstillende, dog var vi mindre glade for IR-bolden på den fjernstyrede robot, da den gjorde robotten langsommere og mere klodset end vi havde håbet på.

Referencer:
[1]:http://legolab.cs.au.dk/DigitalControl.dir/index.html
[2]: Behavior.java
https://dl.dropbox.com/u/2779683/OpponentRobot/Behavior.java
[3]: Car.java
https://dl.dropbox.com/u/2779683/OpponentRobot/Car.java
[4]: Main.java
https://dl.dropbox.com/u/2779683/OpponentRobot/Main.java
[5]: InfraredMonitor.java
https://dl.dropbox.com/u/2779683/OpponentRobot/InfraredMonitor.java
[6]: TouchMonitor.java
https://dl.dropbox.com/u/2779683/OpponentRobot/TouchMonitor.java
[7]: DiscoverSegway.java
https://dl.dropbox.com/u/2779683/OpponentRobot/DiscoverSegway.java
[8]: KillSegwayEasy
https://dl.dropbox.com/u/2779683/OpponentRobot/KillSegwayEasy.java
[9]: KillSegwayHard
https://dl.dropbox.com/u/2779683/OpponentRobot/KillSegwayHard.java

Slut Projekt Session 5

Slut Projekt Session 5

Tid: 8 timer, Deltagere: Kenneth, Rawad.

Siden sidst:
Intet at bemærke.

Formål:
Formålet med denne session er at anvende vores viden fra session 3 omkring IRseekeren, til at designe og udvikle en opponent robot der er istand til at fange den fjernstyrede segway robot.

Plan

1. Undersøg svingnings metode med IRSeeker
2. Konstruktion af opponent robot
3. Software arkitektur
4. Evaluering af opponent robot
5. Diskussion
6. Konklusion

1. Undersøg svingnings metode med IRSeeker
Vi har fået den ide at vi måske kan forøge præcisionen af IRSeekeren ved at bevæge den fra side til side og så lave en løbende gennemsnit. Dermed vil flere af sensorerne i IRSeekeren være i brug når vinkelen skal bestemmes. Derudover vil lys intensiteten fra emitteren blive udjævnet og dette vil måske gøre det muligt at bestemme afstanden mere præcist.

Test
Testen er konstrueret på samme måde som vores tidligere test af IRSeekeren. En enkelt IRSeeker er fastgjort til en motor med en IR bold[1] placeret ca. 30 cm væk. Så drejes sensoren, ved hjælp af motoren, en omgang én grad af gangen mens målinger foretages. Til de initierende test vil vi aflæse målingerne vha. getDirection metoden beskrevet i denne blog[2] og logge dem ved at skrive dem i en fil vha. denne klasse[3]. Test koden bevæger sensoren et vist antal grader til hver side for den ønskede vinkel mens den tilføjer den aflæste værdier til et eksponentielt løbende gennemsnit. Følgende kode blev brugt i testen[4]. Her ses en optagelse af hvordan testen blev udført:

Første Test
Ved den første test valgte vi at give nye målinger en 5% indflydelse på den nye udregning af vinklen. IRSeekerens bevægelse blev sat til 10 grader i hver retning for midtpunktet.

Resultat:

Det ses at sensoren måler direction meget deterministisk hvilket får os til at tro at IRSeekeren bevæger sig for lidt. Samtidig er der ved skift fra en direction til den næste volsom oscillering som kan betyde at nye sensorværdier har for stor indflydelse på den “nye” direction.

I den anden test satte vi bevægelsen af IRSeekeren op til 20 grader i hver retning og indflydelsen fra nye sensorværdier ned til 1%.

Resultat:


Karakteristikken for sensormålingerne ser meget bedre ud efter ændringerne. Dog ved vi ikke om bidraget fra hver måling er for lille og hele målings sættet derfor er forsinket. Med den metode vi bruger vil direction altid være mindst en svingning forsinket da vi ikke tager højde for i hvilken vinkel IRSeekeren er når målingen bliver taget.

2. Konstruktion af opponent robot
Formålet med opponent robotten er at vælte den fjernstyrede segway. På baggrund af vores overvejelser i session 2. Har vi valgt at bygge opponent robotten med 3 hjul. Konstruktionen af opponent robotten er baseret på mindstorm education bogen side 8-23 Selve sensor placeringen er baseret på side 28-30 i samme bog.

Dog har vi modificeret designet lidt. Vi har valgt at sætte sensoren fast til en motor på toppen af robotten, som det kan ses på billedet herunder.


Dette giver os mulighed for at bevæge sensoren rundt vandret, og anvende svingings metoden beskrevet i afsnit 1.

3. Software arkitektur
Til software arkitekturen på opponent robotten anvendes en behavior based subsumption arkitektur. Der er grundlæggende defineret to behaviors til opponent robotten, hhv. DiscoverSegway og KillSegway. Arbitratoren og behavior klassen er skrevet af Ole Caprani [6][7]. Selve opponent robottens kode kan findes her [5].

DiscoverSegway er lavest i behavior hierakiet, og består af simpel rotation.

KillSegway overtager styring når der detekeres et signal på direction 4-6.

 public int takeControl()
 {
if (intensity >= 100 && direction > 3 && direction < 7)
      return 100;
return 0;
 }

Herefter sætter killsegway behavior fuld fart fremad og forsøger at ramme segwayen. Hvis direction ikke er 5, justeres retningen en smule ved hjælp af motorene.

 public void action()
 {
  int motorPowerA = 0;
  int motorPowerC = 0;
  Sound.beep();

LCD.drawString("Attacking",0,3);

   while (!_suppressed)
   {
   if(direction > 5.5)
   {
    motorPowerA = 65;
    motorPowerC = 100;
   }
   if(direction < 4.5)
   {
    motorPowerA = 100;
    motorPowerC = 65;
   }
   if(direction >= 4.5 && direction <= 5.5)
   {
    motorPowerA = 100;
    motorPowerC = 100;
   }
   
   MotorPort.C.controlMotor(motorPowerC, 1);
MotorPort.A.controlMotor(motorPowerA, 1);
     Thread.yield(); //don't exit till suppressed
     
   }
   MotorPort.A.controlMotor(0,3);
MotorPort.C.controlMotor(0,3);
Motor.A.suspendRegulation();
Motor.C.suspendRegulation();

 }


Til selve motorstyrringen anvendte vi klassen Motor, og brugte forward(), backward() funktionerne. Efter vi testede at subsumption arkitekturen virkede, havde vi brug for mere præcis motor styring og skiftede til Motorport klassen. Da vi begyndte at anvende MotorPort klassens controlmotor funktioner, oplevede vi store problemer med subsumption arkitekturen. Når Killsegway behavior blev aktiveret, kunne andre behaviors ikke overtage når deres konditioner blev opfyldt.

Vi opdagede at dette skyldes motorregulering og løste problemet med at suspendere reguleringen når en behavior bliver afsluttet, som det kan ses i kode segmentet ovenover.

Svingingsmetoden er ikke anvendt i denne iteration af opponent robotten, da de er blevet arbejdet på parallelt vi vil forsøge at integrere disse i næste iteration.

4. Evaluering af opponent robot
Vi nåede desværre ikke at evaluere opponent robotten.

5. Diskussion
Seeker metode
Vi regner med at vi kan få nogle rimelig præcise målinger fra svingnings metoden og at den holder præcisionen selv når bolden befinder sig et stykke fra sensorens midte. Det er dog blevet overvejet om en høj præcision på direction også kan opnåes ved at bevæge IRSensoren så lyskilden(bolden) altid befinder sig imellem to sensorer. Som vi beskrev i Slut Projekt Session 4 overlapper nogle af sensorerne i IRSeekeren. Disse overlap er forholdsvis smalle og mens bolden befinder sig imellem to sensorer kan forskellen i lysintensiteten bruges til at bestemme boldens direction meget præcist. Hvis det er muligt at bevæge IRSeekeren så bolden hele tiden befinder sig i dette overlap kan præcisionen på direction måske øges og forsinkelsen måske mindskes.

Forbedret Svingnings metode
En anden metode som kunne forbedre svingnings metoden kunne være at aflæse vinkelen målingen bliver foretaget i. For dermed at gøre det muligt at udregne direction udfra et lavere antal samples og derefter tage højde for i hvilken vinkel de blev målt. Et lavere antal samples vil derfor også betyde et lavere delay.


6. Konklusion
Vi har testet IRSeekerens præcision i et svingnings scenarie og har fået resultater der tyder på at direction på IR bolden kan fastslås med højere nøjagtighed end tidligere. Disse målinger er ikke afsluttet og vi vil fortsætte med at udvikle og teste denne metode.

Referencer:
[1]:http://www.hitechnic.com/cgi-bin/commerce.cgi?preadd=action&key=WFB1015
[2]:http://legolabsblog.blogspot.dk/2012/06/slut-projekt-session-4.html
[3]:https://dl.dropbox.com/u/4447110/FileLogger.java
[4]:https://dl.dropbox.com/u/4447110/IRSeekerTest2.java
[5]:https://dl.dropbox.com/u/2779683/Opponent.java
[6]:https://dl.dropbox.com/u/2779683/Arbitrator.java
[7]:https://dl.dropbox.com/u/2779683/Behavior.java

Slut Projekt Session 4

Slut Projekt Session 4

Tid: 12 timer, Deltagere: Kenneth, Rawad.

Siden sidst:
Intet at bemærke.

Formål:
Formålet med denne session er at udforske hvordan hitechnics infrarød sensor fungerer, og så ud fra den viden designe en detektions mekanisme baseret på IR dioder. Den fjernstyrede segway robot vil være udstyret med IR dioder, der udstråler infrarødt lys. Opponent robotten (den autonome) vil have en IR seeker der er istand til at opfange dette lys og måle retning og afstand.

Plan

1. Undersøgelse af Hitechnic IR seeker (DC) med IR LED’er
2. Undersøgelse af Hitechnic IR seeker (AC mode) med IR bold
3. Analyse af IR Emitter design til fjernstyret robot
4. Konstruktion af IR Emitter
5. konklusion

1. Undersøgelse af Hitechnic IR seeker i DC mode (med IR LED’er)
Vi har i samtale med Ole Caprani omkring detekterings mekanismer, besluttet at bestille Hitechnic NXT IRSeeker V2 sensor for LEGO Mindstorms [2]. De blev bestilt som en del af et “Lego soccer set” der består af to af disse IRSeekers samt en IR bold.

IRSeekeren kan fungere i to modes, hhv. moduleret (AC) mode og ikke-moduleret (DC) mode. I AC mode kan sensoren detektere moduleret signaler som f.eks. fra IR bolden og fjernbetjeninger. AC mode filtrer ikke modulerede lyskilder som f.eks. sollys.
DC mode kan detektere konstant lys, som sollys etc.

Seekeren kan detektere retning og afstand, som det ses på billedet herunder indikere 5 at lyskilden er i fronten osv. 

IRSeekers skal bruges til at detektere infrarødt lys. Til udstråling af IR lys har vi bestilt 25 stks. IR-LED Black 20grader 5mm 20mA [1].

For at teste IRSeekeren har vi lavet en lille opstilling med et fumlebræt og en strømforsyning, hvor vi power en 20mA IR-led[1]. Opstillingen kan ses på billedet herunder. Testen er foretaget i elektronik lab i edison (IHA).

I første omgang har vi forsøgt at power dioden beskrevet ovenover og peget sensoren imod den for at se om den kan detektere dioden i DC mode. Resultatet af testen var at der blev detekteret en lyskilde, dog var vi meget i tvivl om det rent faktisk var LED’en der var lyskilden pga. meget svage målinger omkring lysdioden. Vi slukkede herefter lysdioden og målte omkring den, og fik samme resultat hvilket førte os til den konklusion at det må have været støj i lokalet som vi har målt. Derfor prøvede vi at måle indflydelsen fra solen ved at holde IRSeekeren på den anden siden af gardinerne. Her blev intensiteten målt til omkring 200 hvilket var meget højere end vi havde målt ved dioden.Vi anvendte et digitalt kamera for at se om dioden overhovedet udsendte IR lys, som det kan ses på billedet herunder kan man intet lys se i dioden.

Efter mislykket forsøg med at få lys ud af de første dioder, lånte vi en IR-diode med en meget større sprednings vinkel fra elektronik værkstedet i Edison (værdi på spredningsvinkel ukendt). Her kunne vi detekere dioden med sensoren, og rent faktisk også se lyset i kameraet. Dog var forskellen mellem støj og infrarødt lys fra dioden meget lille, som det kan ses på målinger herunder. getAverage funktionen i IRseeker klassen anvendes  til at opsamle data.

I lommen på cowboybukser
Direction 0
Intensitet 0

Max baggrundsstøj omkring test opstillingen
Intensitet 26 (i retning af vinduet)

Tændt diode afstand 0 cm 0grader (IRseekers hældning til diode)
Direction: 5
Intensitet: 205

Tændt diode 10 cm, i retning af diode
Direction: 5
Intensitet: 170

Tændt diode 20 cm, i retning af diode
Direction: 5
Intensitet: 87

Tændt diode 30 cm, i retning af diode
Direction: 5
Intenistet: 69

Tændt diode 30 cm, 90 grader fra diode
Direction: 7
Intensitet: 60

Tændt diode 30 cm, 45 grader fra diode
Direction: 7
Intensitet: 65Vi kan udfra ovenstående målinger konkludere at man i DC mode godt kan måle afstanden og vinklen til en IR-diode. Dog målte vi en voldsom baggrundsstøj som vi fjernede ved at afskærme solen fra test opstillingen. Da robotten i sidste ende skal fremvises i et rum med lys vil der være stor risiko for at solen vil have en indflydelse på bestemmelsen af IR-seekers direction.
2. Undersøgelse af Hitechnic IR seeker i AC mode (med IR Bold)

I denne test sættes IRSeekeren til at operere i AC mode. Denne test er foretaget i Zuse bygningen.
Først tester vi hvor modtagelig sensoren er overfor baggrundsstøj i AC mode, ved at pege sensoren mod forskellige lyskilder i lokalet og op mod solen.

Resultat ved alle lyskilder:
Direction 0
Intensitet 0

Seekeren blev ikke ligesom i DC mode forstyrret af lyskilderne.

Når IR bolden kommer indenfor rækkevidde af IR Seekeren, begynder den at opføre sig mærkeligt. IR Seekeren kan se i hvilken retning bolden er, men intensitet vises om -1, i alle retninger. Dog skal det bemærkes at den er super god til at finde ud af hvilken retning IR bolden er i. Til at hente retningen fra sensoren anvendes klassen IRSeekerV2. Funktionen der anvendes er .getDirection().

Vi mistænker at getAverage ikke kan bruges i AC, og vil derfor finde en anden måde at hente data fra sensoren på. Vi vil nu afprøve opsamling af sensorværdierne med getSensorValues(). Ved skift til getSensorValues funktionen opdagede vi at der returneres 5 tal i arrayet. Dette afspejler at der er 5 sensorere.

Figuren herover viser hvordan fem sensorere kan detektere 9 directions. Vi har opdaget at direction udregnes ved at se hvilke sensorere der aktivt måler et signal. I frontal retning i.e. direction 5, er der kun sensor 3 der er aktiv. I direction 4, kan det tydeligt ses at både sensor 2 og 3 er aktive. Når begge sensorere er aktive resultere det i en direction der er imellem begge sensorere. I.e. Alle lige tal repræsentere “virtuelle sensorere”.

Vi har forsøgt at se om IR lyset bliver reflekteret og kan forstyrre retningen målt, vi har gjort dette med glas og blanke overflade og kan ingen reflektion måle.

Afstand:
Funktionen getSensorValues returnere alle sensorværdierne (1-5) i et array.

Afstandsmåling med direction 5, hvilket vil sige sensor 3.
0cm intensitet 145
30cm 125
60cm 76
90cm 58
120cm 42
150cm 32

Under målingen opdagede vi at ændring i rotation af IR bolden havde indflydelse på intensiteten målt af IRseekeren. Dette er fordi IR bolden ikke udsender infrarødt med lige høj intensitet i alle retninger. Derfor har vi taget måling med en optimal vinkel på IR bolden for at få konsistente målinger.

Efter afstandsmålingen forsøgte vi at se hvor stor vinklen rundt om sensoren hvor bolden kan detekteres er. Her opdagede vi at mellem direction 9 og 1 (på den anden side af sensoren) giver sensoren nogle mærkelige værdier. Når den er ude af rækkevidde for den yderste sensor 1, kan sensor 2 pludselig måle den. Befinder bolden sig lige bagved sensoren aktiveres alle sensorer med en lav værdi. Er bolden slukket eller udenfor rækkevidde returneres 1 fra alle sensorer.

Retning:
Bestemmelse af sensorens vinkel til bolden kan gøres ved at måle intensiteten af lys på de enkelte sensorer. Hvis to sensorer er aktive på samme tid kan forskellen mellem disse bruges til bestemmelse af boldens placering. Er kun en sensor aktiv er en højere præcision på boldens placering sværere at opnå. Sensor værdien falder hvis bolden flytter sig fra den optimale vinkel, men dette er desværre også tilfældet hvis afstanden til bolden bliver længere. Derfor er det ikke lige til at bruge lysstyrken til vinkelbestemmelse så vel som afstandsbestemmelse.

IRSeeker:
For at vise IRSeekerens karakteristik ved detektionen af IR bolden, har vi foretaget en test med den. IRSeekeren sættes fast til en motor og roteres rundt 360grader, hvor IR bolden er 30cm foran seekeren. Denne test viser os præcis i hvilke vinkler sensorene overlapper og hvor kun en sensor detekterer lys. Følgende kode er brugt til testen[3] og værdierne logges vha. denne klasse[4].

Udførsel:
 

Resultat:






 

Figuren herover viser sensor input intensitet for hver enkelt grads rotation sensoren foretager. ved 0grader er IR bolden på modsat side af retning 5 (modsat fronten). De områder hvor sensorene overlapper svarer til “lige” directions (2,4,6,8) og de steder hvor der kun er en enkelt sensor er “ulige” directions.

Dual sensor setup
Ved at tilføje en ekstra IRseeker der er placeret på samme sted som den originale IRseeker men vinklet, kan vi fordoble vinkel præcisionen. Hvis bare vi kan få de to sensorer til at skrifte direction med samme interval men forskudt 50%. Dette er dog desværre ikke muligt da intervallet for de forskellige directions ikke er lige så stor. Det kan ses herunder at intervallet for sensor 5 (direction 5) er 59 grader hvor intervallet for nabo sensorene er 44 grader.

Sensor 2
interval 219,263: værdi: 44

Sensor 3
interval 154,213: værdi: 59

Sensor 4
interval 101,145: værdi: 44

For at optimere vinkel bestemmelsen har vi beregnet at den anden IRseeker skal være vinklet 24.5 grader ift. den anden. Dette er udregnet ved at tage halvdelen af gennemsnitet af interval værdierne for de midterste sensorer. Vi har valgt ikke at tage de yderste sensorer 1 og 5 med i beregningen da en høj præcision i yderpunkterne ikke er ønsket på kompromi at en høj præcision frontalt.

Vi har konstrueret en anordning der vinkler den ene IRSeeker med 22.5 grader ift. den anden:

Ved at teste konstruktionen på samme måde som med en enkel IRSeeker: 


Fik vi følgende resultater:

Første test:

Anden test:


For at skabe overblik når begge IRseekernes sensorværdier er plotter i samme diagram har vi markeret hvor sensorene i de enkelte IRSeekers overlapper. De hvide områder imellem de markerede er dem vi vil minimere, da disse hver identifisere en enkel direction. Resultatet viser at der stadig er store områder hvor der ikke er et overlap. Vi mistænker at vi ved at vende den anden sensor har spejlvendt karakteristikken. Istedet prøver vi med en vinkel på 45 grader imellem de 2 IRSeekers:
 

Resultater:
Første test:


Anden test:


Resultaterne med en 45 graders vinkling imellem IRSeekerne viser at de hvide områder omkring midten er gået fra en bredde på 47 grader i test 1 til en bredde på 24 i test 3. Dermed opnåes en meget højere præcision i bestemmelsen af vinklen til lyskilden når den befinder sig foran robotten. Mens det stadig er muligt at bestemme vinkelen når lyskilden befinder sig ved siden af robotten.


3. Analyse af IR design til fjernstyret robot

På baggrund af undersøgelsen i ovenstående afsnit, har vi kunne konkludere at detektering af IR lys med seekeren i DC mode, er næsten ubrugeligt, da afstanden hvor lyskilden kan skelnes fra IR støj er for kort.
Der er derfor nogle muligheder vi skal tage stilling til:

Systemet kan testes i mørkt rum for at undgå støj.
Vi kan forsøge at lave et circuit der kan sende moduleret IR lys med dioderne.
Anvende IR bolden, der allerede udsender moduleret IR lys.

Vi føler at begrænse brugen af robotterne til område hvor der ikke er andre lyskilder end IR vil være ærgeligt og gøre projektet svært at demonstrere. Vi vil derfor ikke vælge at anvende seekeren i DC mode til at detektere IR lyskilder.

At konstruere et circuit der kan modulere IR lys med dioderne og sætte seekeren i AC mode, ville være det optimale valg. Dog er det også en smule ude af scope og omfattende.

Den nemmeste løsning vil være at anvende IR bolden, som IR emitter og anvende seekeren i AC mode. Det vil gøre os i stand til at demonstrere projektet, samt fjerne behovet for hjemmelavet circuit.


4. Konstruktion af IR Emitter

Vi har valgt ikke at konstruere vores egen IR emitter, da det har vist sig at være for komplekst og uden for vores tidsgrænse. Vi vil derfor anvende IR bolden der i testen har vist sig at være detekterbar i en god afstand (over 150cm).


5. Konklusion
Det lykkedes os at evaluere IRseekeren i DC mode med IR LED’er, dog var resultatet ikke optimalt men forventet. Den bedste afstand vi kunne detektere IR LED’erne i DC mode var omkring 30-50cm, men alligevel ineffektivt da baggrundslys nemt var målt til op omkring 200. Vi har også evalueret IRseekeren i AC mode, og var positivt overrasket over hvor nemt IRseekeren havde det med at detektere både afstand og retning. Dog havde vi problemer med getAverage funktionen i AC mode, dette var ikke en stor forhindring da vi nemt kunne opnå nogenlunde samme resultater med getSensorValues(). På baggrund af ovenstående resultater vælger vi at anvende IRbolden istedet for at konstruere vores egen IRemitter pga. det gode resultater samt kompleksiteten i at konstruere en IRemitter i AC mode.


Referencer:
[1]:http://elektronik-lavpris.dk/files/sup2/tsff5210.pdf
[2]:http://www.hitechnic.com/cgi-bin/commerce.cgi?preadd=action&key=NSK1042
[3]:https://dl.dropbox.com/u/4447110/IRSeekerTest.java
[4]:https://dl.dropbox.com/u/4447110/FileLogger.java