Lab Notebook 11

---

Date: 16.1.08
Duration of activity: 13.30-14.00
Group members participating: Simon, Jacob og Kristian

---

Fremtidigt arbejde
Bruge Navigation
Igennem projektet har vi haft problemer med at holde robotterne indenfor banen. Hvis vi indførte en form for koordinater og navigation kunne vi forbedre "RandomDrive", så den ikke længere ville være helt tilfældig, men forsøge at holde sig i koordinatsystemet. Et problem vil være præcisionen, hvilket vi opdagede i Lesson 9. Præcisionen vil kunne forbedres v.h.a. en kompas-sensor, som beskrevet i "Maximum Lego NXTBuilding Robots with Java Brains, Chapter 12, Localization", men fordi det bare er et område vi skal holde os indenfor at præcision ikke af afgørende vigtighed. Vi kan justere når robotten kommer ud i kanterne og robotterne kan udveksle viden om banen gennem Bluetooth.
Vi overvejede at sende koordinater mellem robotterne, så de altid vidste hvor modstanderen var henne, men det ville være "snyd". Det ville være alt for let at finde og fange den den undvigende robot.
Forbedre infrarød sender
Vi lavede et forsøg med at holde den ene robot stille og lave målinger mens vi drejede en af vore infrarøde kilder ca. 20 cm foran den. Det viste sig at der var store "blinde vinkler". Selvom vi iflg. specifikationen på dioderne skulle dække alle 360 gader, var det ikke tilfældet. En løsning kunne være at forbedre den infrarøde sender ved at bruge kraftigere dioder og sætte dem tættere sammen. Det vil give et problem med at få spænding nok. Der skal ligge 1,5-1,8 V over hver diode. Dvs. at det ikke længere vil være nok med en enkelt motorport og vi skulle have en ekstern spændingskilde. Hvis vi parallelkoblede dioderne ville vi have et problem med strømforbruget.
Udregne afstand via IR seeker og udnytte dette
Det er muligt at implementere en afstandsmåling v.h.a. den infrarøde søger. Problemet er bare at de læste signaler ikke er særligt gode, vi modtager ikke signaler særligt ofte, sollys giver udsving, det afsendte signals styrke varierer og skal kalibreres (pga. afladning af strømkilde) - hvis vi er heldige kan "se" hinanden indenfor en afstand af 50 cm. Hvis vi kunne omsætte signal styrken på de interne sensorer til en afstand på en pålidelig måde, vil det kunne give mere glidende bevægelser når der skal fanges og undviges - i og med at robotterne bedre ved hvor den anden er.
Kunne fjernstyre en robot.
Det er muligt at benytte Bluetooth til at fjernstyre en robot evt. med en mobil telefon. Dette er forholdsvis nemt at implementere men vi skal dog undersøge om NXT'en kan håndtere 2 forskellige Blutetooth forbindelser.
Lave baner med forhindringer (ultrasonic)
En åbenlys forbedring til banen er at benytte forhindringer som skal unviges samtidig med at robotterne fanger og unviger. Dette kunne implementere ved hjælp af ultrasonic sensoren, dog ville det kræve en sensor multiplextor at vi med den nuværende robot bruger alle sensor porte.
Flere robotter - måske med hold
Man kunne også udvide spillet med flere robotter som kunne være på 2 hold, og så når en robot fra et hold blev ramt skal hele holdet skifte roller.
Konklusion
Det er lykkedes at lave et par robotter, som kan spille tag-fat spillet som ønsket, og holde sig til reglerne. Dog er vi skuffede over funktionaliteten af IRSeekerSensor'ene og vores infrarøde lyskilde. Om fejlen ligger i lyskilderne eller sensorerne har vi ikke kunne finde svar på, men robotterne har svært ved at finde hinanden, selv på kort afstand. Det giver et indtryk af at det nogle gange er mere tilfældighed end noget andet når robotterne fanger hinanden i spillet. I opbygningen af softwaren har vi brugt en behaviour baseret arkitektur, nærmere betegnet LeJOS' subsumption mekanisme. Vi har opbygget en struktur, som fungerer fint efter hensigten, og man kan tydeligt observere på robotterne at de forskellige behaviours tager over på de ønskede tidspunkter. I forløbet har vi fået en bedre indsigt arbejdet med et embedded system, hvor man ikke har samme muligheder, som man har på en normal computer. Samtidig har vi set hvilke problemer der kan opstå med upræcise hardware enheder, arbejdet med at tilpasse softwaren, så vi kommer ud over disse problemer, og løser opgaven.

Lab Notebook 10

---

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

---

Dagens mål:

• Få fast monteret de infrarøde lyskilder på robotterne.
• Programmere IRSeekerSensor klassen så der tages højde for defekt sensor.
• Teste spillet, og rette evt. fejl eller mangler der viser sig.

Lyskilder
Vi startede dagen med at montere de infrarøde lyskilder. Da IRSeeker'en også skal bruges når robotten er "Avoider" skal placeringen af lyskilden være således at den bedst muligt kan opdages af den anden robot, samtidig med at robotten selv ikke opfanger lyset. Vi testede forskellige placeringer, og målte sensor værdierne på begge robotter, og fandt at den bedste placering var ca. 2 cm bag IRSeeker'en på robotten, i højde så den lige kunne lyse hen over sensoren. Billedet her viser placeringen af sensoren på robotten.


Defekt sensor
Trods reklamationen over vores defekte sensor har vi ikke modtaget en ny fra lego endnu. Vi valgte at implementere vores IRSeekerSensor klasse, så den tager højde for at den ene sensor er defekt. Som beskrevet Lesson 5 var den ene af de 5 interne sensorer på den ene af vores IRSeekerSensor gået istykker. Vi implementerede vores IRSeekerSensor klasse så direction() metoden, der angiver retning, tager en boolsk parameter, som angiver om det er den defekte sensor, eller den fejlfrie. I det tilfælde at vi måler på den defekte sensor giver vi bare retningen som den højeste målte værdi på de fire interne sensorer, som virker. Dette giver ikke helt samme præcision som på den anden sensor, men det gør det alligevel muligt for begge robotter at se hinanden i de fleste situationer.
Test
Da vi havde monteret både sensor og lyskilde på begge robotter gik vi igang med at teste. Vi observerede en fejl når en robot blev fanget mens den var ifærd med "StayOnTrack" behavior'en. Robotten var ved at køre tilbage mod banen, men når rollen skifter fra catcher til avoider, skifter robotten køre retning, hvilket resulterede i at robotten kørte væk fra banen. Dette blev klaret ved at behavior'en blev afsluttet i den retning, den var startet, i stedet for at retningen blev aflæst løbende igennem handlingen.
Vi valgte derefter at implementere en ny behavior, som stopper spillet. Når spillet starter gemmes systemtiden, og når der er gået et fastsat stykke tid stopper begge robotter. Vinderen af spillet er den robot som er "avoider" i afslutnings tidspunktet. Vinderen af spillet laver en dans, og spiller en melodi, mens taberen står stille. Her ses et billede af de to robotter ifærd med et spil:

Softwareakitektur
Det endelig program kom til at bestå af 9 klasser som kan hentes her, opbygningen af programmet ligger tæt på planen fra Lab Notebook 3 og kan ses herunder:

Konklusion
Det lykkedes at finde en fornuftig placering af lyskilderne på robotterne, samt at finde en løsning på problemet med den defekte sensor. Vores testkørsler har vist at robotterne kan have problemer med at finde hinanden, men til tider lykkes det. Det skyldes nok det relativt svage signal fra vores lyskilder.

Lab Notebook 9

---

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

---

Dagens mål:

• Konstruere infrarøde kilder
• Fortsætte med at ordne stay on track opførslen fra sidst

Konstruere infrarøde kilder.
Vi havede valget mellem to typer dioder, en type som sendte lyset ud med en spredning på 40 grader og en med en spredning på 80 grader. Men dioden med 80 graders spredning var ikke så kraftig som den på 40.
I og med at vi har spænding til 5 dioder, valgte vi at blande de to typer for at få maksimeret spredningsgraden.
Vi brugte en med spredningsgrad på 40 og fire med spredningsgrad på 80 grader, hvilket gav os 360 grader.
Vi placerede den kraftigeste diode så den peger fremad, dette blev valgt for både ikke at forestyrre den infrarøde modtager og for at give den anden robot gode muligheder for at "se" den.
Selve udformningen af den infrarøde sender bygger på en rund papplade hvorpå de fem dioder er sat i serie, her er det vigtig at tjekke at dioderne virker før de loddes på da en defekt diode får alle til at fejle.
For at få strøm til til senderen valgte vi som nænvt i Lab Notebook 8 at bruge en motorudgang. Vi lodede den infrarøde sender på en strømførende Legoklods, og kobede denne til en mortorport ved hjælp af et NXT til RXT kabel.
Derefter testede vi senderen med et lille testprogram som satte strøm på motorporten og samtidig målte ved hjælp af den infrarøde søger.
Stay on track opførslen.
Vi havde et problem når robotten var "avoider" og var i "StayOnTrack" behavioren. Sidste gang tilføjede vi tilstande, så robotten kunne huske hvordan den skulle komme ind på banen igen, men i visse tilfælde gik der noget galt og den kørte rundt i en cirkel. Løsningen var at nulstille de boolske tilstandsvariable, når robotten var færdig med en handling. Dette var nødvendigt for at robotten kunne afslutte behaviouren.
Konklusion
De infrarøde kilder er færdige og klar til brug. Det samme er "StayOnTrack" opførslen, der nu virker både når NXT'en er "Catcher" (kører forlæns) og når den er "Avoider" (når den bakker)..

Lab Notebook 8

---

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

---

Dagens mål:

• Løse memory leak problem
• Få ordnet de infrarøde kilder
• Teste videre på den kode vi har lavet

Løse memory leak problemet fra sidst
Oprindeligt havde vi tænkt os at tage en behavior af gangen. Altså lade en Behavior' køre, mens vi aflæser hukommelsesforbruget for at finde den eller de Behaviors, hvor der er memory leaks. Istedet valgte vi at flashe med den nye version af leJOS, da den indeholder garbage collection. Det gik over alt forventning. Programmet compilede og virkede med det samme! Udover vi ikke behøver at tænke over memory leaks kan koden nu også laves mere overskuelig, når man ikke skal erklære værdier uden for fx loops.
Infrarøde kilder
Vi nåede ikke at få målt spændingen over en motorport sidst, så vi tog NXT'en over på elektronik værkstedet og fik det gjort. Spændingen er 8,3 V, ved fuld opladning (samme værdi som kan måles i leJOS). Over hver diode skal der være en spænding på 1.7V. Dvs. at vi kan kan sætte 4-5 dioder i serie og tilslutte dem en motorport. Iflg. Hardware Developer Kit, page 5, kan en outputport kontinuert give en strøm på 700mA, hvilket vi fik at vide var tilstrækkeligt.

Teste videre på den kode vi har lavet
NXT'en opførte sig ikke helt som vi forventet. Vi har sat den til at skrive ud, hvilken Behavior der er aktiv, men den skifter ikke korrekt og engang imellem kørte robotten ud over banen. Derfor kiggede vi koden igennem for at få rettet de bugs der var.
Et af problemerne var at robotten hakkede meget i kørslen. Vi fandt ud af det skete når fx forward blev kaldt på en motor, mens den allerede kørte forward. Fejlen opstod efter vi havde opdateret leJOS til 0.5.0. Løsningen var at lave et tjek på hvilken mode motoren kørte i og kun kaldte forward, hvis det var nødvendigt.
Et andet problem var at vi brugte Thread.sleep i "RandomDrive". Det medførte at robotten undertiden stod stille i op til 1 sek, når den skiftede Behaviors. Istedet brugte vi busy waiting, hvilket løste problemet.
Vi var kommet godt igennem "RandomDrive" og "StayOnTrack", dog manglede der en anden opførsel når NXT'en skulle avoide. Når robotten skal avoide vil vi gerne have den stadig skal kunne se den anden robot med den infrarøde modtager. Dvs. at den skal køre baglæns, når den skal avoide. Vi lavede ændringer i "Locomotion", så den tager en boolsk værdi som parameter til metoderne, som angiver hvilken retning den kører i. Problemet er når robotten bakker ud af banen, så når den forsøger at rette op sker der det at begge sensorer kommer udenfor banen - pga. robottens opbygning. Vi prøvede at rette problemet ved at tilføje forskellige tilstande, der kunne huske hvilken retning robotten skal holde for at komme ind på banen igen.
Konklusion
Vi fik løst memory leak problemet, fandt ud af hvor mange infrarøde sensorer vi kan sætte på og fik rettet en del bugs. Dog skal vi arbejde videre på dette næste gang...

Lab Notebook 7

---

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

---

Dagens mål:

• Få Bluetooth kommunikation til at virke mellem enhederne
• Få "undvige" / "fange" mekanismer til at virke
• Hvis IR dioderne kommer hjem skal vi have dem sat sammen til infrarøde sendere

Bluetooth kommunikation
Vi valgte at benytte Bluetooth til kommunikation mellem enhederne og da Bluetoothsenderen i NXT har en rækkevidde på 10 m (1) er dette nok til vores behov. I første omgang brugte vi enhedernes navne, der var parrede i forvejen, men vi stødte på problemer med at når den ene enhed sendte til den anden modtog den også samme data. Det skyldes at robotterne har fået det samme navn. Istedet valgte vi at lave et lille testprogram, der aflæste hardware MAC adresserne på NXT'erne og bruge disse lokale adresser til kommunikationen, dette betyder at MAC adresserne ligger i selve programmet men dette ser vi ikke som noget problem. I programmet laver vi et tjek på de to adresser, hvis adressen tilhører denne NXT bruges den anden adresse til kommunikation, dermed slipper vi for at have to versioner af programmet.
Bluetooth kommunikationen virker ved at den ene part skal stå og vente på en forbindelse, og den anden skal oprette forbindelsen. Her blev vi nød til at implementere rollerne "Avoider" og "Catcher", så det skal vælges ved opstart hvilken rolle den enkelte NXT skal have. Vi valgte at "Avoider'en" skal stå og vente på en forbindelse fra "Catcher'en".
NXT'erne skal igennem spillet kunne skifte roller. Oprindeligt havde vi forestillet os at "Avoider" og "Catcher" behaviors kunne stå for skiftet, men da begge behaviors har en lavere prioritet end "StayOnTrack" vil det være umuligt at den ene kan fange den anden når "StayOnTrack" er aktiv. Vi lavede derfor en ny Behavior "Touch" med højest prioritet.
"Touch" vil tage kontrollen, hvis touch sensoren er trykket ind og den pågældende NXT er "Catcher" (At være "Catcher/Avoider" er implementeret ved hjælp af en statisk boolsk værdi i vores hovedklasse "TikCar"). Får "Touch" kontrollen vil den sende beskeden "42" til den anden NXT og ændre sin boolske værdi fra "Catcher" til "Avoider". En "TikCar" har en "BTRecieve" tråd kørende, hvis den er "Avoider" prøver den konstant at modtage beskeden "42". Når beskeden modtages ændrer "Avoideren" rolle til "Catcher".

Efter alt dette var implementeret oplevede vi et problem med memory leaks. Efter NXT'erne havde kørt et kort stykke tid fik vi en "Exception : 5". Vi debuggede koden og fandt nogle memory leaks, men det eneste vi fik ud af det var af forsinke fejlen.
Infrarøde kilder
Fyren fra daimi's elektronik værksted havde bestilt 20 infrarøde dioder: 10 med en spredningsgrad på 40 og 10 med en spredningsgrad på 80 grader. Vi forventer hovedsageligt at benytte dioderne med en spredningsgrad på 40, da lyset skulle være kraftigere. Dioderne skal sættes sammen i en lille kæde, men for at finde ud af hvor mange de kan sættes på skal vi kende spændingen over en motorudgang.
Konklusion
Vi fik Bluetooth kommunikationen til at virke v.h.a. lokale MAC adresser. For at få dette til at virke blev vi nød til at kunne vælge rolle på robotten ved opstart, men det er ikke noget problem da rollen alligevel skal bruges under spillet. Kommunikationen er implementeret i "BTRecieve" og "TikCar". Vi fik lavet en ny "Touch" behavior med højest prioritet til at håndtere skiftet når robotten er "catcher" og fanger "avoideren".
Vi nåede ikke at løse memory leak problemet og vi nåede heller ikke at få styr på de infrarøde kilder.
Referencer
(1) NXT Bluetooth, Hardware Developer Kit, side 12.

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.

Lab Notebook 5

---

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

---

Dagens mål:
I dag vil vi koncentere os om at få bygget vores anden NXT og få kommunikationen mellem robotterne til at fungere:

• Konstruktion af NXT nr. 2
• Få Bluetooth kommunikationen mellem de to robotter til at virke

Konstruktion af NXT nr. 2
Sidste gang sikrede vi os at de infrarøde søgere virkede på en NXT med standard software og vi fik dem også til at virke i leJOS. Dermed kunne vi flashe den anden robot og få lagt leJOS over på denne iflg. installationsguiden.
Næste skridt er at kopiere prototypen vi lavede i Lab Notebook 2 & Lab Notebook 3, og yderligere få monteret de IR sensorer, som vi har modtaget siden vi byggede prototypen. Her ses et billede af de to færdige robotter.

Bluetooth kommunikation
Bluetooth kommunikationen skal bruges til at robotterne skal kunne kommunikere med hinanden. Altså at "fangeren" skal kunne sige til "undvigeren" at den er fanget.
Vi startede med at kigge på Bluetooth eksemplerne i "lejos_nxj\samples" og at få dem til at virke med vores robotter. Først fandt vi ud af hvordan robotternes "Friendly name" kunne ændres, så vi kunne skelne vores robotter fra andre NXT'er i lokalet. Dernæst fik vi parret de to robotter vha. deres friendly name, og dernæst kunne test programmerne køres. Test programmerne er simple programmer, hvor det ene sender noget data, mens den anden modtager. Programmet virkede fint på vores to NXT'er, og dermed havde vi fået kommunikationen op at køre.
Infrarød lyskilde.
Da vi havde fået kommunikationen op at køre, begyndte vi at eksperimentere med infrarøde lyskilder. Inspireret af Notes on construction of Braitenberg's Vehicles, Chapter 1-5 of Braitenbergs book, ville vi konstruere et køretøj, der reagerer direkte på input fra den infrarøde søger. Altså opførsler nøjagtigt som "MoveTowardsLight", når den er fanger og "MoveAwayFromIR", når den er undviger.
De små lamper der følger med til NXT'en udgiver infrarødt lys, så derfor besluttede vi at montere nogle lamper på den ene robot, og implementere en tilfældig kørsel på denne, mens vi implementerede en simpel følg det infrarøde lys opførsel på den anden robot. Forsøget viste robotten havde svært ved at opfange lyset fra lamperne, og skulle tæt på før den opfangede noget signal. Vi forsøgte dernæst med en anden lyskilde, som havde lånt på daimi's elektronik værksted. Denne lyskilde havde et kraftigere lys, men dette var meget retningsbestemt, hvilket kan blive et problem. Indtil videre har vi ikke fundet nogen holdbar løsning til den infrarøde lyskilde.
Konklusion
Vi har nået dagens mål, og haft tid til lidt ekstra eksperimenter med en infrarød lyskilde. Vi har fået samlet de to robotter, som nu er klar til tests. Samtidig har vi fået oprettet kommunikation mellem de to NXT'er via bluetooth, som er nødvendig for at den ene robot kan meddele den anden om at den er blevet fanget. Indtil videre har vi lavet opdagelsen af den anden robot manuelt, så programmet kan ikke selv søger efter den anden NXT. Dette burde måske laves automatisk til den endelige robot. De sidste eksperimenter vi lavede med den ifrarøde lyskilde, som skal monteres på begge robotter, førte os desværre ikke frem til en endelig løsning på problemet. Ideelt skulle begge robotter have en kraftig lyskilde monteret, hvor lyset bliver jævnt fordelt til alle sider. Sidstnævnte er meget vigtigt, da robotten skal være synlig for den anden robot, når de er i nærheden af hinanden. Kraften er ikke helt så vigtig, da robotterne ikke nødvendigvis skal kunne se hinanden på meget lang afstand. I løbet af vores eksperimenter oplevede vi problemer med den ene IR-sensor. Denne læste en meget høj værdi på den ene af de interne sensorer, som gjorde at robotten altid kørte i den samme retning. Det tyder desværre på en defekt sensor, da problemet ikke var tilstæde når den anden sensor blev monteret. Vi kontakter lego i morgen, og håber at kunne få en ny sensor leveret.