tag:blogger.com,1999:blog-53982010127548428622024-02-19T06:12:44.598+01:00Embedded Systems - Embodied AgentsKristan Andersen, Simon Lykke, Jacob Styrup BangSKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.comBlogger21125tag:blogger.com,1999:blog-5398201012754842862.post-58078959640082417912008-01-16T13:24:00.000+01:002008-01-21T11:27:21.566+01:00Lab Notebook 11<hr/><span style="FONT-WEIGHT: bold">Date: </span>16.1.08<br /><b>Duration of activity: </b>13.30-14.00<br /><b>Group members participating:</b> Simon, Jacob og Kristian<br /><hr /><span style="FONT-WEIGHT: bold;font-size:130%;" >Fremtidigt arbejde</span><br /><span style="FONT-WEIGHT: bold">Bruge Navigation</span><br />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 <a href="http://esea-legolab.blogspot.com/2007/11/lesson-9.html">Lesson 9</a>. 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.<br />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. <span style="FONT-WEIGHT: bold"><br />Forbedre infrarød sender</span><br />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.<br /><span style="FONT-WEIGHT: bold">Udregne afstand via IR seeker og udnytte dette</span><br />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.<br /><span style="FONT-WEIGHT: bold">Kunne fjernstyre en robot.</span><br />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.<br /><span style="FONT-WEIGHT: bold">Lave baner med forhindringer (ultrasonic)</span><br />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.<br /><span style="FONT-WEIGHT: bold">Flere robotter - måske med hold</span><br />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.<br /><span style="FONT-WEIGHT: bold;font-size:130%;" >Konklusion</span><br />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.SKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0tag:blogger.com,1999:blog-5398201012754842862.post-3193975481151852842008-01-16T12:42:00.000+01:002008-01-21T11:31:17.594+01:00Lab Notebook 10<hr/><span style="FONT-WEIGHT: bold">Date: </span>16.1.08<br /><b>Duration of activity: </b>9:15-13.30<br /><b>Group members participating:</b> Simon, Jacob og Kristian<br /><hr/><span style="FONT-WEIGHT: bold">Dagens mål:</span><br /><ul><li>Få fast monteret de infrarøde lyskilder på robotterne.</li><li>Programmere IRSeekerSensor klassen så der tages højde for defekt sensor.</li><li>Teste spillet, og rette evt. fejl eller mangler der viser sig.</li></ul><br /><span style="FONT-WEIGHT: bold">Lyskilder</span><br />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.<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9mABq9hRgouaGD2tyVLt-kVWhOQS2bEhVbrJG3SDX2MlleWA2rpeO9MvlDCHt-gv5Fg7uhgbAEAC36iniS_wsH7xhEJ-FOPz2iGZh4rkA_F5AG2hV73PgitYSw9ruHv_uBFOA18J8cwg/s1600-h/00005.jpg"><br /><br /><img id="BLOGGER_PHOTO_ID_5156041539069320178" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: pointer; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg9mABq9hRgouaGD2tyVLt-kVWhOQS2bEhVbrJG3SDX2MlleWA2rpeO9MvlDCHt-gv5Fg7uhgbAEAC36iniS_wsH7xhEJ-FOPz2iGZh4rkA_F5AG2hV73PgitYSw9ruHv_uBFOA18J8cwg/s320/00005.jpg" border="0" /></a><br /><span style="FONT-WEIGHT: bold">Defekt sensor</span><br />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 <a href="http://esea-legolab.blogspot.com/2008/01/lab-notebook-6.html">Lesson 5</a> 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.<br /><span style="FONT-WEIGHT: bold">Test</span><br />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.<br />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:<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgaUTAXWqFz-TKftnwuIZ6OrkrVkIhlEsPTO3jD_6im6CLpDLteY9JDfpGX49O_yB0lgI5ugROLxZxesjDtx3cDJ2vvc8K9vK88LiHjK0yy3rTAvSw5yoTTWasLqwHXEjjWsc9yWnXypmI/s1600-h/00004.jpg"><img id="BLOGGER_PHOTO_ID_5156047195541249026" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: pointer; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgaUTAXWqFz-TKftnwuIZ6OrkrVkIhlEsPTO3jD_6im6CLpDLteY9JDfpGX49O_yB0lgI5ugROLxZxesjDtx3cDJ2vvc8K9vK88LiHjK0yy3rTAvSw5yoTTWasLqwHXEjjWsc9yWnXypmI/s320/00004.jpg" border="0" /></a><br /><span style="FONT-WEIGHT: bold">Softwareakitektur</span><br />Det endelig program kom til at bestå af 9 klasser som kan hentes <a href="http://www.daimi.au.dk/~styrup/esea/java/">her</a>, opbygningen af programmet ligger tæt på planen fra <a href="http://esea-legolab.blogspot.com/2007/12/lab-notebook-3.html">Lab Notebook 3</a> og kan ses herunder:<br /><img id="BLOGGER_PHOTO_ID_5157873806477532322" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: hand; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiqie1Jb70uSL4IlR5JMaLpkAN3-OcZ3Rfk12HwSHCp4DvcfHAHhfzF8OPfnJCtwrqZZJVSsCCD1ZYTN9fOyIiFtkInzowAx_hudPMWH5IROCaPeFybpPFtjIEDQp_dZOSfCyh4qKADVUQ/s400/final.jpeg" border="0" /><br /><span style="FONT-WEIGHT: bold">Konklusion</span><br />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.SKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0tag:blogger.com,1999:blog-5398201012754842862.post-51293407760778094302008-01-15T12:33:00.001+01:002008-01-21T11:07:07.723+01:00Lab Notebook 9<hr/><span style="FONT-WEIGHT: bold">Date: </span>15.1.08<br /><b>Duration of activity: </b>9:15-13:45<br /><b>Group members participating:</b> Simon, Jacob og Kristian<br /><hr /><span style="FONT-WEIGHT: bold">Dagens mål:</span> <ul><li>Konstruere infrarøde kilder</li><li>Fortsætte med at ordne stay on track opførslen fra sidst</li></ul><span style="FONT-WEIGHT: bold">Konstruere infrarøde kilder.</span><br />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.<br />I og med at vi har spænding til 5 dioder, valgte vi at blande de to typer for at få maksimeret spredningsgraden.<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwzGOjFU5IwxwJxR_WpQ1_JT9dtV_HT9hhbJlfAhTpVDyyKpNPod9vY72R4BZnxlzqbQ0_4uHJ5AghfiFSqhGI4xdUlj1PL9JySm6lZo_Mvs6TA6SJ12NCRhvjo-dNjZNi2i8RAh0mZsY/s1600-h/00002.jpg"><img id="BLOGGER_PHOTO_ID_5156049020902349842" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: pointer; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwzGOjFU5IwxwJxR_WpQ1_JT9dtV_HT9hhbJlfAhTpVDyyKpNPod9vY72R4BZnxlzqbQ0_4uHJ5AghfiFSqhGI4xdUlj1PL9JySm6lZo_Mvs6TA6SJ12NCRhvjo-dNjZNi2i8RAh0mZsY/s320/00002.jpg" border="0" /></a><br />Vi brugte en med spredningsgrad på 40 og fire med spredningsgrad på 80 grader, hvilket gav os 360 grader.<br />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.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWDhBd2HeowMXdLJipEcn1cEZVdZjEUoRuKAucPOuXDF3HczzjHGr7OLML0ebLbDZkkcPl3vrDvWfY4DQ50na4AKhmAXCmvOVoishyTWpKmL3GDrVLCfd1Y1tAw-FLDAv8zuNfVnXajss/s1600-h/DSC00117.JPG"><img id="BLOGGER_PHOTO_ID_5157851176294849618" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: pointer; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWDhBd2HeowMXdLJipEcn1cEZVdZjEUoRuKAucPOuXDF3HczzjHGr7OLML0ebLbDZkkcPl3vrDvWfY4DQ50na4AKhmAXCmvOVoishyTWpKmL3GDrVLCfd1Y1tAw-FLDAv8zuNfVnXajss/s200/DSC00117.JPG" border="0" /></a><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1wtEHiHqtBrjL97OAUdbTO7W3PxYKuxXf-Esa3z24q-xHhLRZq3LlLGOSKj348tCkEA_aaGA4TaWLqiggBHHevm0FrDZp1VrOf7T4MhsvHUQAfJOA-rAf5DNAUHlgxN5MxVjN3RGYb8w/s1600-h/DSC00118.JPG"><img id="BLOGGER_PHOTO_ID_5157851287963999330" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: pointer; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1wtEHiHqtBrjL97OAUdbTO7W3PxYKuxXf-Esa3z24q-xHhLRZq3LlLGOSKj348tCkEA_aaGA4TaWLqiggBHHevm0FrDZp1VrOf7T4MhsvHUQAfJOA-rAf5DNAUHlgxN5MxVjN3RGYb8w/s200/DSC00118.JPG" border="0" /></a>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.<br />For at få strøm til til senderen valgte vi som nænvt i <a href="http://esea-legolab.blogspot.com/2008/01/lab-notebook-8.html">Lab Notebook 8</a> 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.<br />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.<br /><span style="FONT-WEIGHT: bold">Stay on track opførslen.</span><br />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.<br /><span style="FONT-WEIGHT: bold">Konklusion<br /><span style="FONT-WEIGHT: bold"></span></span>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).. <span style="FONT-WEIGHT: bold"><span style="FONT-WEIGHT: bold"></span><br /></span>SKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0tag:blogger.com,1999:blog-5398201012754842862.post-54363976675025702432008-01-14T10:31:00.000+01:002008-01-21T11:07:29.393+01:00Lab Notebook 8<hr/><span style="FONT-WEIGHT: bold">Date: </span>14.1.08<br /><b>Duration of activity: </b>9:15-14:00<br /><b>Group members participating:</b> Simon, Jacob og Kristian<br /><hr /><span style="FONT-WEIGHT: bold">Dagens mål:<br /></span><ul><li>Løse memory leak problem </li><li>Få ordnet de infrarøde kilder</li><li>Teste videre på den kode vi har lavet</li></ul><p><span style="FONT-WEIGHT: bold">Løse memory leak problemet fra sidst</span><br />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 <a href="http://lejos.sourceforge.net/">leJOS</a>, 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.<br /><span style="FONT-WEIGHT: bold">Infrarøde kilder</span><br />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. <a href="http://mindstorms.lego.com/Overview/NXTreme.aspx">Hardware Developer Kit</a>, page 5, kan en outputport kontinuert give en strøm på 700mA, hvilket vi fik at vide var tilstrækkeligt.</p><p><span style="FONT-WEIGHT: bold">Teste videre på den kode vi har lavet<br /></span>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.<br /><span style="font-size:100%;">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.<br />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.<br />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.<br /><span style="font-size:100%;"><span style="FONT-WEIGHT: bold">Konklusion<br /></span>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...</span><span style="FONT-WEIGHT: bold"> </span></span></p>SKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0tag:blogger.com,1999:blog-5398201012754842862.post-21284704380647031952008-01-11T09:29:00.001+01:002008-01-21T11:31:40.386+01:00Lab Notebook 7<hr/><span style="FONT-WEIGHT: bold">Date: </span>11.1.08<br /><b>Duration of activity: </b>9:15-14:00<br /><b>Group members participating:</b> Simon, Jacob og Kristian<br /><hr /><span style="FONT-WEIGHT: bold">Dagens mål:<br /></span><ul><li>Få Bluetooth kommunikation til at virke mellem enhederne</li><li>Få "undvige" / "fange" mekanismer til at virke</li><li>Hvis IR dioderne kommer hjem skal vi have dem sat sammen til infrarøde sendere</li></ul><p><span style="FONT-WEIGHT: bold">Bluetooth kommunikation </span><span style="FONT-WEIGHT: bold"><br /><span style="FONT-WEIGHT: bold"><span style="FONT-WEIGHT: bold"><span style="FONT-WEIGHT: bold"></span></span></span></span>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.<br />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".<br />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.<br />"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".<br /><br />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.<br /><span style="FONT-WEIGHT: bold">Infrarøde kilder<br /><span style="FONT-WEIGHT: bold"></span></span>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. <span style="FONT-WEIGHT: bold"><span style="FONT-WEIGHT: bold"></span><br /></span><span style="FONT-WEIGHT: bold">Konklusion<br /></span>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".<br />Vi nåede ikke at løse memory leak problemet og vi nåede heller ikke at få styr på de infrarøde kilder.<br /><strong>Referencer</strong><br />(1) NXT Bluetooth, <a href="http://mindstorms.lego.com/Overview/NXTreme.aspx">Hardware Developer Kit</a>, side 12.<br /><span style="FONT-WEIGHT: bold"></span><span style="FONT-WEIGHT: bold"></p></span>SKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0tag:blogger.com,1999:blog-5398201012754842862.post-86928131274361146242008-01-09T09:49:00.000+01:002008-01-21T11:32:09.406+01:00Lab Notebook 6<hr/><span style="FONT-WEIGHT: bold">Date: </span>9.1.08<br /><b>Duration of activity: </b>9:15-15:15<br /><b>Group members participating:</b> Simon, Jacob og Kristian<br /><hr/><span style="FONT-WEIGHT: bold">Dagens mål:</span><br /><ul><li>Reklamere over den defekte sensor</li><li>Finde en løsning på problemet vi har med infrarøde kilder</li><li>Begynde at lave software strukturen.</li></ul><p><span style="FONT-WEIGHT: bold">Reklamation over defekt sensor<br /></span>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.<br /><span style="FONT-WEIGHT: bold">Infrarøde kilder</span><br />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.<br /><span style="FONT-WEIGHT: bold">Arkitektur</span><br />Vi besluttede at bruge den indbyggede behaviour struktur i leJOS, da vi havde nogle problemer med den alternative arbitrator fra <a href="http://esea-legolab.blogspot.com/2007/11/lesson-10.html">Lesson 10</a>. 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: </p><ul><li>Random drive</li><li>Catch</li><li>Avoid</li><li>Stay On Track</li></ul><p>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.<br />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.<br />Stay On Track opførslen har højest prioritet. Begge robotter skal holde sig inden for banen, for at overholde spillet regler.<br /><span style="FONT-WEIGHT: bold">Implementation</span><br />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.<br />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. </p><p>Vi har undervejs udelukkende brugt simple feedback control, som beskrevet i <a href="http://vig.prenhall.com/catalog/academic/product/1,4096,0130895687,00.html" target="_top">Robotic Explorations: A Hands-on Introduction to Engineering</a>,. 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...<br /><span style="FONT-WEIGHT: bold">Konklusion</span><br />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.<br />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.<br />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.<br /><span style="FONT-WEIGHT: bold">Referencer</span><br />(1) - Electronics - A Systems Approach, Neil Storey. s 602.</p>SKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0tag:blogger.com,1999:blog-5398201012754842862.post-63607517124825818542008-01-08T09:35:00.000+01:002008-01-21T11:07:48.176+01:00Lab Notebook 5<hr/><span style="FONT-WEIGHT: bold">Date: </span>8.1.08<br /><b>Duration of activity: </b>9:15-13.30<br /><b>Group members participating:</b> Simon, Jacob og Kristian<br /><hr /><span style="FONT-WEIGHT: bold">Dagens mål:</span><br />I dag vil vi koncentere os om at få bygget vores anden NXT og få kommunikationen mellem robotterne til at fungere:<br /><ul><li>Konstruktion af NXT nr. 2</li><li>Få Bluetooth kommunikationen mellem de to robotter til at virke</li></ul><p><span style="FONT-WEIGHT: bold">Konstruktion af NXT nr. 2</span><br />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. <a href="http://www.legolab.daimi.au.dk/DigitalControl.dir/Lejos_NXJ.dir/lejos_nxj_install_guide.html">installationsguiden</a>.<br />Næste skridt er at kopiere prototypen vi lavede i <a href="http://esea-legolab.blogspot.com/2007/12/lab-notebook-2.html">Lab Notebook 2</a> & <a href="http://esea-legolab.blogspot.com/2007/12/lab-notebook-3.html">Lab Notebook 3</a>, 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.<br /></p><p><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhr01wOHk3KGFvgdZNb2lGHT8So2vuPyJ2L51ZmBt71jJ_gEoN4wzQm8yHwTABplbcZKaepYz24Q7Gd7iWMLF_aLDuifuRPDsOvkqovFnN0q2PcIn-AI_KyO9oJqecrYSQtu7dzpBPwXHM/s1600-h/00002-1.jpg"><img id="BLOGGER_PHOTO_ID_5153058722936953810" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: pointer; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhr01wOHk3KGFvgdZNb2lGHT8So2vuPyJ2L51ZmBt71jJ_gEoN4wzQm8yHwTABplbcZKaepYz24Q7Gd7iWMLF_aLDuifuRPDsOvkqovFnN0q2PcIn-AI_KyO9oJqecrYSQtu7dzpBPwXHM/s320/00002-1.jpg" border="0" /></a><br /><br /><span style="FONT-WEIGHT: bold">Bluetooth kommunikation<br /><span style="FONT-WEIGHT: bold"></span></span>Bluetooth kommunikationen skal bruges til at robotterne skal kunne kommunikere med hinanden. Altså at "fangeren" skal kunne sige til "undvigeren" at den er fanget.<br />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.<br /><span style="FONT-WEIGHT: bold">Infrarød lyskilde.</span><br />Da vi havde fået kommunikationen op at køre, begyndte vi at eksperimentere med infrarøde lyskilder. Inspireret af <a href="http://www.cs.brown.edu/people/tld/courses/cs148/01/vehicles/vehicles.htm" target="_top">Notes on construction of Braitenberg's Vehicles, Chapter 1-5 of Braitenbergs book</a>, 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. <br />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.<br /><span style="FONT-WEIGHT: bold">Konklusion</span><br />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.<br /><br /><span style="FONT-WEIGHT: bold"></span></p>SKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0tag:blogger.com,1999:blog-5398201012754842862.post-31368331716654268172008-01-07T09:33:00.000+01:002008-01-08T12:25:08.773+01:00Lab Notebook 4<hr /><span style="font-weight: bold;">Date: </span>7.1.08<br /><b>Duration of activity: </b>9:15- 13:30<br /><b>Group members participating:</b> Simon og Kristian<br /><hr /><span style="font-weight: bold;">Dagens mål:<br /></span><ul><li>Eksperimentere med de infrarøde søgere vi har bestilt hjem</li><li>Få dem til at virke i leJOS.</li></ul><span style="font-weight: bold;">Eksperimenter med infrarød søger<br /></span>Vi har på nuværende tidspunkt ikke nogen infrarød lyskilde til vores NXT, så vi fandt en fjernbetjening som erstatning. Iflg. brugervejledningen til den infrarøde søger kan man bruge en NXT til at teste enheden med. Vi havde en ny NXT der ikke var blevet flashet, så vi koblede sensoren til, valgte "View" -> "Ultrasonic - cm". Her kunne vi bevæge den infrarøde kilde og teste sensorens zoner (efter en firmware opdatering til 1.05!).<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEidPbyWlKNldUuZrX08peK0v1uQg9wjoeES8LDMYtzFbLg2Ee5guuKe-avnGdhKp3ykGRTINH1Xz_4sdsssgej6UdU1xvh8rSH0jPDVsp0_sq_2ZLePCl3SGp68BK9kAJpIPVwWWuiXQi8/s1600-h/DSC00113.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEidPbyWlKNldUuZrX08peK0v1uQg9wjoeES8LDMYtzFbLg2Ee5guuKe-avnGdhKp3ykGRTINH1Xz_4sdsssgej6UdU1xvh8rSH0jPDVsp0_sq_2ZLePCl3SGp68BK9kAJpIPVwWWuiXQi8/s400/DSC00113.JPG" alt="" id="BLOGGER_PHOTO_ID_5152664118521666482" border="0" /></a>Vi fandt ud af at fjernbetjeningen ikke var nødvendig og en almindelig lysdiode kunne bruges istedet - dog var signalet ikke særligt kraftigt.<br />Ved at holde dioden overfor sensoren i forskellige positioner kunne vi teste om zonerne var som specifieret. Overordnet fandt vi ud af at zonerne 2 og 8 er en del smallere end opgivet, mens zone 5 er bredere.<br />Derudover lagde vi mærke til at andre lyskilder i omgivelserne spiller kraftigt ind på målingerne. Vi er ret sikre på det ikke vil kunne virke ude i sollys og det vil være bedst med et helt mørklagt lokale. Vi venter med at lave mere præcise opmålinger af zoner og afstande, da dette sikkert vil afhænge af hvilket lys vi får sat på robotten, omgivelserne og hvordan vi aflæser og beregner værdierne i leJOS.<br /><span style="font-weight: bold;">Infrarød søger i leJOS<br /></span>I leJOS er der ingen klasse, der repræsenterer vore infrarøde søger. Derfor tilføjede vi vores egen klasse "IRSeekerSensor" til "lejos.nxt" pakken. Opbygningen af klassen ligner meget "UltrasonicSensor.java", men vi skal læse fra flere registre, da der i manualen er specificeret 6 forskellige adresser: 1 til retningen (returnerer 0-9) og 5 til signal styrken på hver af de 5 indbyggede sensorer.<br /><span style="font-weight: bold;">Test af infrarød søger i leJOS<br /></span>Efter at have implementeret "IRSeekerSensor" klassen og kompileret den kunne vi bruge den i et test program. Vores testprogram aflæser retningen og udskriver det på skærmen. Vi prøvede igen at aflæse retningen fra sensoren ved at tape sensoren fast, hvorefter vi førte en lyskilde rundt om sensoren. Vi markerede når retningen skiftede værdi.<br />De lange streger på tegningen repræsenter de opgivne skillepunkter fra brugervejledningen, mens de små streger angiver de målte skillepunkter.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhMsxB6VD8J_ZFrVL22eQQXexvsNdsFx_VQixY_aQua3shVxlqiDnJfBPtuAwM4TgeSBkT4J_px4PriuCZVM-zEe_0mRubHTM0SLkamDamWq9sPC5wj9lWQGgHzc2v3vRZ0qoemBI1R4Mw/s1600-h/00001-1.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhMsxB6VD8J_ZFrVL22eQQXexvsNdsFx_VQixY_aQua3shVxlqiDnJfBPtuAwM4TgeSBkT4J_px4PriuCZVM-zEe_0mRubHTM0SLkamDamWq9sPC5wj9lWQGgHzc2v3vRZ0qoemBI1R4Mw/s320/00001-1.jpg" alt="" id="BLOGGER_PHOTO_ID_5153064774545873890" border="0" /></a>Vi udførte testen både i dagslys, og i et mørkelagt rum, og konkluderede at lys fra omgivelserne ikke har så stor indvirkning som vi frygtede, man skal dog være opmærksom på at sensoren kan finde på at aflæse en værdi, under påvirkning af indirekte dagslys.<br /><span style="font-weight: bold;">Konklusion<br /><span style="font-weight: bold;"></span></span>Vi ved at de infrarøde søgere virker og vi har fået en ide om hvilken præcision vi kan forvente fra dem. Derudover virker vores hjemmelavede "IRSeekerSensor" leJOS klasse efter hensigten.<span style="font-weight: bold;"><span style="font-weight: bold;"></span><br /></span>SKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0tag:blogger.com,1999:blog-5398201012754842862.post-3450073449732221982007-12-13T09:32:00.000+01:002008-01-21T11:08:20.102+01:00Lab Notebook 3<hr/><span style="FONT-WEIGHT: bold">Date: </span>13.12.07<br /><b>Duration of activity: </b>9:15- 13:00<br /><b>Group members participating:</b> Simon, Jacob og Kristian<br /><hr /><span style="FONT-WEIGHT: bold">Dagens mål:<br /></span>Fortsætte med at udvikle robot prototypen fra sidst.<br /><ul><li>Design af bane </li><li>Montere sensorer</li><li>Designe og implementere simple test programmer til test af sensorer </li></ul><p><span style="FONT-WEIGHT: bold">Design af bane<br /></span>Vi har haft en del overvejelser til hvordan banen, hvorpå spillet skal foregå, skal designes. Først og fremmest skal banen være ensfarvet, så vi kan aflæse med lyssensorer, når vi kommer udenfor banen. Om banen skal være rund, firkantet, med eller uden forhindringer vil vi overveje nærmere i løbet af projektet, men umiddelbart vil vi starte med en firkantet enefarvet bane uden forhindringer. </p><br /><p><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjehwPse-BrQuvZ7QvKZCeCCG5NnbyGUej5CTpoEE_dbh8a6JVS-Nw5thedD8d01p8CFR9YxxHuYmvHQSaYzckkxywMS0gTzzW66l52CunLgzoyeV0NO8Pn9MWICqGo-Z-AyudupTySsJE/s1600-h/bane.JPG"><img id="BLOGGER_PHOTO_ID_5143378463993483058" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: pointer; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjehwPse-BrQuvZ7QvKZCeCCG5NnbyGUej5CTpoEE_dbh8a6JVS-Nw5thedD8d01p8CFR9YxxHuYmvHQSaYzckkxywMS0gTzzW66l52CunLgzoyeV0NO8Pn9MWICqGo-Z-AyudupTySsJE/s400/bane.JPG" border="0" /></a>Når spillet virker, kan vi overveje om vi vil tilføje forhindringer, samt om vi vil lave andre baner...<br /><span style="FONT-WEIGHT: bold"><br />Opbygning af prototype</span><br />Sidste gang monterede vi 2 tryk sensorer, men der er kun 4 input porte. Robotten skal kunne navigere rundt indenfor en bane og vores erfaringer fra <a href="http://esea-legolab.blogspot.com/2007/10/lesson-5-robot-race.html">Robot løbet</a> siger os, at vi skal bruge 2 lyssensorer for at kunne bestemme hvordan vi skal komme ind på banen igen, når vi først er kørt ud over. Dvs. at vi kun har en enkelt port tilbage til en tryksensor, da vi også skal have monteret en infrarød sensor.<br /><img id="BLOGGER_PHOTO_ID_5143388565756563314" style="DISPLAY: block; MARGIN: 0px auto 10px; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhsWSaBMaY0M793Z0k38klG7KpmPyOaqxOY62eUjShQbL05LRu-VYRANWGn9q0SrYSSKvOfQtU2ODiWhVRJa7vMkXdv5e7olrac_soKnhLWwcGVknmfHuAn3IsdoxU-Olmz0BqxSQKQOzM/s320/sensor-porte.JPG" border="0" />Vi vil stadig gerne have en stor kontaktfalde til den ene sensor vi har. Det gjorde vi ved montere et stativ som vist på tegningen nedenunder:<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBXoSwhPdWKOJj0pOkBYzvNkuohaDfMAEAsB86gYOXt0ycfDTSfu7of1uw59Yle1AlVTGhHby5bz_xdYqqtYbPTXJUeORu4Qm31lyNGBfVia7oW0VtXtQswF8jiLDVRkHTptArbVw-uAg/s1600-h/touch.JPG"><img id="BLOGGER_PHOTO_ID_5143377282877476642" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: pointer; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBXoSwhPdWKOJj0pOkBYzvNkuohaDfMAEAsB86gYOXt0ycfDTSfu7of1uw59Yle1AlVTGhHby5bz_xdYqqtYbPTXJUeORu4Qm31lyNGBfVia7oW0VtXtQswF8jiLDVRkHTptArbVw-uAg/s400/touch.JPG" border="0" /></a></p><br />Meningen er at 'stativet' skal rette kraften ved kontakt ind mod tryksensoren og gør at den nemmere aktiveres. Lys sensorerne blev monteret på hver side af tryksensoren og vi byggede en anden robot, der kunne være den anden del af spillet indtil prototypen er færdig.<br /><img id="BLOGGER_PHOTO_ID_5143383742508289890" style="DISPLAY: block; MARGIN: 0px auto 10px; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEidpCZeGAxUW5lvwthbtrIsSHDQi-B1tx2czzLnMofvdjMw73BkK85o8OnhOnrGKJAt465sqtUzE5MDLRvRppgU5fflyIHSZN-Fd70tOC2qMnu52_QaVuknt4d8G4BtYtSF-5xG2HO9Tt4/s320/DSC00109.JPG" border="0" /><br /><p><strong>Testprogrammer<br />Tryksensor</strong><strong><br /></strong>I første omgang lavede vi et simpelt program, der ved aktivering af tryksensoren bipper. Det kørte vi for at teste konstruktionen omkring vores tryksensor. Umiddelbart ser det ud som om at vi har den følsomhed vi ønsker.<br />Vi lavede endnu et program, hvor vi tester 'sammenstød' med den anden robot. Når tryksensoren aktiveres kører prototypen tilbage, hvilket kan ses i nedenstående video:<br /><br /><iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.blogger.com/video.g?token=AD6v5dyM0L8h5lyrxR3i9sKf-gOjrbYZ6zwaBVmbzcGYzjVJb_tR9S9s_E79AdnMOC6JPnB0cqJjOBwAmZXJ4ZfecQ' class='b-hbp-video b-uploaded' frameborder='0'></iframe></p><p><strong>Lyssensorer</strong><br />For at teste vores lyssensorer implementerede vi et program, der aflæser værdier fra sensorerne og skriver dem ud på skærmen. Testen viste at der på samme overflade var en forskel på de aflæste værdier fra de to sensorer. Normalt varierede værdierne 5-10. Forskellen mellem hvid overfalde og gulv, målte den ene sensor 35-54 og den anden fra 44-60. Dvs. at en fornuftig Threshold er 49, - altså middelværdien mellem den højeste lave måling (44) og den laveste høje måling (54). Eventuelt kan man kalibrere værdierne før spillet startes.</p><p>Vi satte en threshold på 49 og lavede et program, der ud fra denne threshold kunne blive indenfor banen. Implementationen blev afprøvet på banen fra Robot racet og det ser ud som om det virker efter hensigten.<br /><strong><iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.blogger.com/video.g?token=AD6v5dy6wpWRQ-R1AZCObQZsM7TwugCrcCV8wO0WJ7K4d4aAJ0E49HHnWxIupY5uAcAUV8ahCD_ozInEzQSCWOCJ' class='b-hbp-video b-uploaded' frameborder='0'></iframe><br />Softwarearkitektur<br /></strong>Vi har valgt en Behavior baseret arkitektur. I <a href="http://esea-legolab.blogspot.com/2007/11/lesson-10.html">Lesson 10</a> og <a href="http://esea-legolab.blogspot.com/2007/11/lesson-8.html">Lesson 8</a> eksperimenterede vi med forskellige implementationer af Behaviors. Den vi fandt der virkede bedst er <a href="http://lejos.sourceforge.net/p_technologies/nxt/nxj/api/lejos/subsumption/Arbitrator.html">leJOS NXJ Arbitrator</a>, men der stilles nogle krav til hvordan den skal bruges for at sikre at Behaviors bliver udført korrekt.<br /></p><p><img id="BLOGGER_PHOTO_ID_5143396434136649602" style="DISPLAY: block; MARGIN: 0px auto 10px; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEivSvAEn1ODaReu8UvdynAdMHvQ9SpUyvA2Yx7UCcEEbxgdkCiR-Dpw6aCmkIn49QW_5z-Br6D44Z5eAnCVDGaSDjAY0WVgkdojl-U-Q8ThoqMkXscl2I-vIJcluVodNCZ9q4-djqcn744/s320/Klasser.jpeg" border="0" />Foreløbigt har vi tænkt os at vi vil lave følgende Behaviors: StayOnTrack, RandomDrive og Action. StayOnTrack skal sørge for robotten bliver indenfor banen og skal derfor have den højeste prioritet. RandomDrive skal have den laveste prioritet, da den kun skal køre tilfældigt rundt, hvis den er inden for banen og ikke ved hvor modstanderne er. Action skal enten sørge for robotten 'undviger' eller 'fanger' - afhængigt af tilstand. </p><p><strong>Konklusion<br /></strong>Vi har nået alle målene for i dag, derudover har vi også har fået bestilt de infrarøde sensorer. På prototypen er monteret trykføler og lyssensorer. Vores små testprogrammer viser at vi kan registrere når robotten rammer en genstand og at robotten kan holde sig indenfor en bane. Software arkitekturen bliver Behavior baseret, med indtilvidere 3 forskellige behaviors: StayOnTrack, RandomDrive og Action.</p>SKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0tag:blogger.com,1999:blog-5398201012754842862.post-22641787188070954472007-12-06T09:51:00.000+01:002008-01-21T11:08:44.229+01:00Lab Notebook 2<hr/><span style="FONT-WEIGHT: bold">Date: </span>6.12.07<br /><b>Duration of activity: </b>9:15-11:00<br /><b>Group members participating:</b> Simon, Jacob og Kristian<br /><hr /><span style="FONT-WEIGHT: bold">Dagens mål:<br /></span>Bygge en prototype af en robot vi kan anvende i vores "Tag fat spil". Vi har opsat følgende krav til prototypen: <ul><li>Skal kunne bruges i begge roller - som "fanger" og "undviger"</li><li>Skal være let at bygge videre på</li></ul><p><span style="FONT-WEIGHT: bold">Prototypens form<br /></span>Det skal være muligt for "fangeren" v.h.a en tryksensor at kunne registrere når der er kontakt med en "undviger".:<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjudVtbGEAjMNkODrZ0_myfhFltfd5WNGd8Vzv2Xi08L0phYtePfkCZe3X-cgOVuCahPYdORw0zFCGfhdxbn43luiAJnnTF6HiRNBvClPeWf8yv0zlbsHoYl3LvFK_OT3xXLQTiEIYz4ek/s1600-h/undviger-tryk.JPG"><img id="BLOGGER_PHOTO_ID_5140783180999629666" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: pointer; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjudVtbGEAjMNkODrZ0_myfhFltfd5WNGd8Vzv2Xi08L0phYtePfkCZe3X-cgOVuCahPYdORw0zFCGfhdxbn43luiAJnnTF6HiRNBvClPeWf8yv0zlbsHoYl3LvFK_OT3xXLQTiEIYz4ek/s400/undviger-tryk.JPG" border="0" /></a>Idéen er at robotten skal have en oval form, så der er en større kontaktflade der kan aktivere tryksensoren. Hvis robotten var firkantet ville det i højere grad gælde om at "fangeren" skal ramme "undvigeren" i den rigtige position:<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEivjJV2jnLZWsgTn3YQgUq1vhStOVWtNsSsccuqF_OxdkbY7aJHlpDu7_7_6U3fJBHQdkzQ1UB-0KG8nlSk_Oy4ci2fdwLy9W3mXp1TmZLx4vIiQJynDIEyzSZGRM3jIMYnwVv-nSVor2E/s1600-h/undviger-tryk2.JPG"><img id="BLOGGER_PHOTO_ID_5140787128074574706" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: pointer; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEivjJV2jnLZWsgTn3YQgUq1vhStOVWtNsSsccuqF_OxdkbY7aJHlpDu7_7_6U3fJBHQdkzQ1UB-0KG8nlSk_Oy4ci2fdwLy9W3mXp1TmZLx4vIiQJynDIEyzSZGRM3jIMYnwVv-nSVor2E/s400/undviger-tryk2.JPG" border="0" /></a><span style="FONT-WEIGHT: bold">Placering af NXT enhed<br /></span>I kursets øvelser har vi haft store problemer, når det var nødvendigt at ombygge robotten vi byggede iflg. Lego Mindstorms Education manualen s. 8-22.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVxEvPpKsCJf4-xwsDQy6hRZAWpy-Em-gBEgKMnbUhXsaDYMH-Yp07qOG5B_zDWt-pJXblM8Oz1r5k7_O7uWy5KaL52CVg05ggiYn1GSQXNcTpqehB6hZlrN6KQcZ8HYU1DjoBemV801k/s1600-h/DSC00103.JPG"><img id="BLOGGER_PHOTO_ID_5140789692170050450" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: pointer; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVxEvPpKsCJf4-xwsDQy6hRZAWpy-Em-gBEgKMnbUhXsaDYMH-Yp07qOG5B_zDWt-pJXblM8Oz1r5k7_O7uWy5KaL52CVg05ggiYn1GSQXNcTpqehB6hZlrN6KQcZ8HYU1DjoBemV801k/s200/DSC00103.JPG" border="0" /></a>I denne konstruktion, se overstående billede, sidder NXT enheden skrå og det har ofte været et problem at bygge videre på robotten - især hvis der skulle monteres en sensor eller lignende, der skulle sidde horisontalt.<br />Vi besluttede os derfor at lave vores eget design, hvor NXT enheden sidder vandret med et lavt tyngdepunkt, så robotten forbliver stabil både under kørsel og påkørsel - se <a href="http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?z=y&endeca=1&isbn=0973864915&itm=5">Maximum Lego NXTBuilding Robots with Java Brains</a>. Det er vigtigt med statisk balance, og det har vist sig under kurset at en 3 hjuls opbygning både giver gode manøvre egenskaber, men også giver god statisk balance.<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjAls4096dW0fXAM_1AaWR9npux1D6Tr_q4dzyDd5GnJzOIllqOdpyKYcPqGJTl3zGIWoGq8hpd7DtlsblnguoD0WefMdfJPQKuixrQ7mPsNE74NJple7aWcr2uL8YeBTj6rQ4PV7hPIM4/s1600-h/DSC00106.JPG"><img id="BLOGGER_PHOTO_ID_5140791861128534946" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: pointer; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjAls4096dW0fXAM_1AaWR9npux1D6Tr_q4dzyDd5GnJzOIllqOdpyKYcPqGJTl3zGIWoGq8hpd7DtlsblnguoD0WefMdfJPQKuixrQ7mPsNE74NJple7aWcr2uL8YeBTj6rQ4PV7hPIM4/s200/DSC00106.JPG" border="0" /></a><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiJUceHtv6dZlJLtIBYuBLXw1QEU8Ky2EqTitk0uvEJYjEptJ6_PhC2BrRijDZmnesQO0OVjs_PZnl9Z70UkP17hvzHtkuLhM7o-6vB1kSiE1svfvVaOx9bN0-k4owPD0eiz7py-tXzjUY/s1600-h/DSC00107.JPG"><img id="BLOGGER_PHOTO_ID_5140791972797684658" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: pointer; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiJUceHtv6dZlJLtIBYuBLXw1QEU8Ky2EqTitk0uvEJYjEptJ6_PhC2BrRijDZmnesQO0OVjs_PZnl9Z70UkP17hvzHtkuLhM7o-6vB1kSiE1svfvVaOx9bN0-k4owPD0eiz7py-tXzjUY/s200/DSC00107.JPG" border="0" /></a><span style="FONT-WEIGHT: bold">Montering af actuators og sensors<br /></span>Vi har brug for motorer til at drive vores robot fremad. På vores prototype monterede vi to motorer ved siden af NXT enheden, som vist på overstående billeder. Derudover monterede vi to tryksensorer, som vist på nedenstående billede.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9CcOWaTLoMcvixsfTp4wORc7gx04ehO239u68TiA0Grdt6bzeZR1BLRAuIXdLS-xpmqeFHKC_tf_6JFyA6R0d8BjMmuZseD1_ISjKzvPlw7AFC8qzab6MK5cIfpu6okKy2r3boUkwGoY/s1600-h/DSC00108.JPG"><img id="BLOGGER_PHOTO_ID_5140796551232822210" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: pointer; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9CcOWaTLoMcvixsfTp4wORc7gx04ehO239u68TiA0Grdt6bzeZR1BLRAuIXdLS-xpmqeFHKC_tf_6JFyA6R0d8BjMmuZseD1_ISjKzvPlw7AFC8qzab6MK5cIfpu6okKy2r3boUkwGoY/s200/DSC00108.JPG" border="0" /></a>Tryksensorene er koblet sammen med en aflang Lego brik. Intuitionen er at de giver en bedre "følelse" af om der er kontakt i forhold til hvis det bare var en enkelt sensor med en mindre kontaktflade. Vi bliver nød til at eksperimentere med tryksensorerne, - finde vinklerne de bliver aktiveret i, for at bestemme om denne placering af sensorene er brugbar. </p><p><strong>Konklusion</strong></p><p>Vi har fået lavet en prototype, der indtilvidere er stabil har lavt tyngdepunkt og gode muligheder for udbygning.</p>SKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0tag:blogger.com,1999:blog-5398201012754842862.post-87821192884604010242007-11-30T09:25:00.000+01:002007-11-30T11:00:49.399+01:00Lab Notebook 1<hr /> <span style="font-weight: bold;">Date: </span>30.11.07<br /><b>Duration of activity: </b>9:15-12:00<br /><b>Group members participating:</b> Simon, Jacob og Kristian<br /><hr /><span style="font-weight: bold;">Dagens mål:</span><br /><ul><li>Diskutere hvert projekt på <a href="http://www.blogger.com/Projects.html" target="_top">list of projects.</a></li><li>Finde og diskutere nye forslag til projekter.</li><li>Vælg endeligt projekt.</li></ul><span style="font-weight: bold;">Diskutere hvert projekt på </span><a style="font-weight: bold;" href="http://www.blogger.com/Projects.html" target="_top">list of projects</a>:<br />Under hvert projekt vil vi:<br /><ol><li>Give en kort beskrivelse af projektet<br /></li><li>Overveje hardware/software platform (antal af NXT's, sensors, actuators etc)</li><li>Beskrive den overordnede software arkitektur og software arkitekturen på hver komponent.</li><li>Udpege det mest vanskelige problem, der skal løses, i hvert projekt.</li><li>Beskrive hvad vi forventer vi kan præsentere som færdigt produkt.</li></ol><span style="font-style: italic;">Navigation through LEGO road elements<br /></span><ol><li>Lego robotten skal navigere gennem vej-elementer og skal kunne finde den korteste vej mellem to punkter. Projektet er inspireret af artiklen <a href="http://www-robotics.usc.edu/%7Emaja/publications/ieeetra92.pdf" target="_top"><i>Integration of Representation Into Goal-Driven Behavior-Based Robots.</i></a></li><li>Navigationen foregår internt i NXT'en, så en NXT vil være nok. En farve sensor er nødvendig for at kunne genkende vejen. Robotten skal bruge to motorer som actuators til at bevæge den.</li><li>Vi vil implementere ved brug af behaviors; En til at holde NXT'en på vejen og en der kører at finde hen mod et mål. Derudover skal der implemteres en mekanisme til at mappe banen og finde korteste vej.<br /></li><li>Det mest vanskelige problem bliver at lave den interne repræsentation af hvordan vejsystemet er og bygge et internt kort.</li><li>Vi forventer vi kan lave en robot der har en fornuftig representation af et kort, og der med en vis usikkerhed kan navigere igennem banen.</li></ol><span style="font-style: italic;">Sex Bots</span><br /><ol><li>Projektet går ud på at lave en flok af robotter der kan reproducere ved at udveksle kode eller gener som beskrevet i <a href="http://www.demo.cs.brandeis.edu/pr/ee/" target="_top">Embodied Evolution</a>. Det skal være observerbart at flokken ændrer deres opførsel som følge af reproduktion.</li><li>Der skal bruges et antal NXT'er, min 2, men helst flere, da der skal være en flok. Der skal være en måde, hvorpå de kan finde hinanden fx ved hjælp af infrarøde sensorer, der også kan bruges til at udveksle kode.<br /></li><li>Fx kan projektet implementeres v.h.a. forskellige behaviors der kan udveksles mellem robotterne.</li><li>Få lavet softwaren, hvor behaviors kan udveksles under kørselen.</li><li>2 til 3 NXT'er der kan finde hinanden og overføre simple behaviors.</li></ol><span style="font-style: italic;">Interactive Robot Games<br /></span><ol><li>Formålet er at implementere et interaktivt robot spil, eventuelt inspireret af computerspil eller spil i det virkelige liv. Tidligere er der blevet lavet et Pacman spil. Vi overvejede en del spil, men det der fangede os var "Robot Tag-Fat". I "Robot Tag-Fat" gælder det om for 2 eller flere robotter at prøve på at fange hinanden, alt efter hvem der er fangeren. Det er et rimeligt simpelt spil, men der er stadig masser af udfordringer at arbejde med.</li><li>Der skal bruges min. 2 NXT'er, så der kan være en "fanger" og en der skal undvige. Alle NXT'er skal udstyres med infrarøde sendere/modtagere, tryksensorer til at mærke om to robotter har kontakt og en farvesensor til at bestemme om robotten kommer ud over banen. Eventuelt en PC, hvor en bruger interaktivt kan kontrollere en af robotterne via Bluetooth. Vi har overvejet hvorvidt vi skal bruge infrarøde sensorer, så robotterne kan se hinanden, eller bruge Bluetooth til at kommunikere koordinater mellem robotterne. Valget faldt på infrarød, da det vil minde mere om hvordan TagFat normalt leges og da koordinater over tid bliver ret upræcise.<br /></li><li>Vi vil lave en behavior-baseret arkitektur til NXT'erne. Grundlæggende skal der være følgende opførseler: "Bliv indenfor banen", "Lokaliser andre robotter", "Undvig"/"Fang". Eventuelt skal en PC kunne være en klient til en NXT og altså fjernkontrollere den.</li><li>Det største problem med dette projekt bliver at få robotterne til at kunne finde hinanden.</li><li>Vi forventer at kunne præsentere to robotter der leger "Tag Fat", altså hvor en robot har rollen som "fanger" og den anden som "undviger". Når "fangeren" fanger "undvigeren" vil de bytte rolle.<br /></li></ol><span style="font-weight: bold;">Konklusion<br /></span>Vi har valgt at lave projektet "<span style="font-style: italic;">Interactive Robot Games - Tag Fat"</span>, fordi det er et simpelt projekt, men et projekt der alligevel indeholder mange spændende aspekter vi kan arbejde med. Bl.a. er der udfordringer i arkitekturen hvorved robotterne kan finde hinanden, i behavior-arkitekturen og hvis vi får tid, fjernstyring af NXT robotter.<br /><br /><span style="font-weight: bold;">Delmål<br /></span><span>Dette er vores forløbige plan over projektets formål: </span><span style="font-weight: bold;"><br /></span><ul><li>Bygge en prototype robot</li><li>Implementere:</li><ul><li>At robotten holder sig indenfor banen</li><li>At robotten kan lokalisere en anden robot</li><li>At robotten kan navigere hen mod / væk fra en anden robot</li><li>At en robot kan "fanges".</li></ul><li>Opbyg bane og opstil spil.<br /></li><li>Lav fjernstyring af en robot via Bluetooth.</li></ul><span style="font-weight: bold; font-style: italic;">Ønskeliste<br /></span><ul><li>En ekstra NXT</li><li>2 infrarøde sensorer (1 på hver robot) af typen <a href="http://shop.lego.com/ByCategory/Product.aspx?p=MS1042&cn=389&d=292">MS1042 </a> eller <a href="http://hitechnic.com/contents/en-us/d23.html"><span class="ProductNumber" id="ProductNumber-P24" object="ProductNumber">NSK1042</span></a></li><li>8 infrarøde lyskilder (4 på hver robot) </li></ul>Vi kigger på hvad vi kan gøre med de infrarøde lyskilder. Muligvis kan skaffe dem selv. Eller eventuelt har I en god idé?<br /><span style="font-weight: bold;"></span>SKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0tag:blogger.com,1999:blog-5398201012754842862.post-29170204090758484842007-11-23T09:24:00.000+01:002007-11-29T13:54:17.268+01:00Lesson 10<span style="font-size:130%;"><strong>Dagens mål</strong></span><br /><ul><li>Undersøge hvordan en opførsels-baseret arkitektur er implementeret i subsumption API'en af leJOS NXJ. Herunder undersøge ved hjælp af BumperCar: </li><li>interfacet lejos.subsumption.Behavior</li><li>klassen lejos.subsumption.Arbitrator</li><li>udvide med en PlaySound behavior</li><li>Eksperimentere med en alternativ implementation af en Arbitrator, hvor suppress ikke bliver brugt</li><li>Overveje brug af Motivations funktioner.</li></ul><p><span style="font-size:130%;"><strong>Ombygning af robotten</strong></span></p><p>Vi benyttede standard robotten, monterede en kontakt sensor i port S2 og tilsluttede motorerne til port A og C.</p><p><img id="BLOGGER_PHOTO_ID_5135958965570618994" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: hand; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiI1gEI2BRhzED6k3qE25Sae0ana58aybZF7GfLpTjwW214zyuT56ZZ7G4nK5Jw5BWsxdLcUZa3ld9aGgAp61jPIox_xNKLdf5sGbw-SZcqJdOB9VG8aigLlfgCSxEicEQ0MG0y577kdD0/s200/DSC00091.JPG" border="0" /><img id="BLOGGER_PHOTO_ID_5135958819541730914" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: hand; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiRiEM6U2Hv7oq5hXCdz7qfBp13GbwyNQEQJeLx2dQJpXUEM8blWkv70_yec65rD-dDKTvZY_cHUNgar553swfbwJO9k8qlXvbibaJdyT6CvrdZPQgreEAXELFOMVZTZ03Uo-D1tcBaMpw/s200/DSC00092.JPG" border="0" /> <strong><span style="font-size:130%;">BumperCar</span><br /></strong>Vi fik BumperCar til at køre på vores ombyggede NXT. Vi observerede at bilen kørte fremad, men når touch sensoren blev aktiveret, bakkede bilen og roterede. Det svarer til de to Behaviors DriveForward og HitWall, hvor HitWall ser ud til at have en højere prioritet end DriveForward. Ved at holde touch sensoren inde observede vi at motorene stopper efter et kort stykke tid og bilen vender tilbage til sin normale opførsel, når knappen slippes.<br />Dette skyldes at så længe touch sensoren er trykket ind, så vil HitWall behavior'en være den aktive behavior. Så længe HitWall er den aktuelle behavior vil den kun udføre sin 'action' metode en gang.<br />Vi undersøgte om takeControl i DriveForward bliver kaldt, når HitWall er aktiv, ved at lade takeControl metoden afspille en lyd hver gang den bliver kaldt. Som forventet bliver takeControl i DriveForward aldrig kaldt, når touch sensoren holdes inde.<br /><br /><iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.blogger.com/video.g?token=AD6v5dzVm45C5b6hcO_hAKJwhorlbai49JbpKLja-Vf0ztEqz35wYrk3vjrCB-x9_O2PGPE3MrQZiExTOgothQZs_g' class='b-hbp-video b-uploaded' frameborder='0'></iframe><br /><span style="font-size:130%;"><strong>Implementation af en tredje Behavior "PlaySound".</strong></span><br />Den tredje Behavior skal være lignende "PlaySound" fra <a href="http://www.legolab.daimi.au.dk/DigitalControl.dir/NXT/Lesson8.dir/Lesson.html" target="_top">NXT Programming, Lesson 8</a>. Denne opførsel skal have den højeste prioritet.<br />Vi implementerede opførslen ved at lave en ny klasse "PlaySound" der implementerer "Behavior". I metoden Action afspilles en lyd, mens der i takeControl tjekkes om tiden summeret med afspilningsintervallet er større end den nuværende tid - er dette sandt returneres false for at give kontrollen videre til en anden opførsel.<br />I BumperCar.java laves en ny instans af klassen og tilføjes til Behavior array'et som den opførsel med det højeste index, der giver den højeste prioritet. </p><p>Der kan opstå et problem under afviklingen af programmet, da supress metoden i HitWall kun stopper motorene, men i Action metoden kaldes sleep på tråden. Hvis supress kaldes, kan tråden fortsætte mens sleep afvikles i Action metoden. Vi har lavet et eksempel, der kan ses i nedenstående video:<br /><iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.blogger.com/video.g?token=AD6v5dwKNQ28gaZIr7BZX9mp1-FFa9wiYMXjw-nqgpK6o_HuvJXv9EM9CLJnrIpWtG4UyYE2sXY_LdZbGmjla0HVqQ' class='b-hbp-video b-uploaded' frameborder='0'></iframe></p><p>Robotten har en Behavior "PlaySound", som afspiller en lyd hvert andet sekund. Når HitWall aktiveres sættes robotten til at køre baglæns og sove i 11 sek. Det resulterer i at HitWall behavior'en kontrollerer motorene selvom "PlaySound" har højere prioritet. For at undgå dette skulle supress metoden sørge for at afbryde 'sleep' på tråden - altså sørge for at Action metoden er helt afsluttet.</p><p><span style="font-size:130%;"><strong>Eksperimentere med en alternativ implementation af en Arbitrator</strong></span></p><p>Vi downloadede <a href="http://www.legolab.daimi.au.dk/DigitalControl.dir/NXT/Lesson10.dir/Arbitrator.java">Arbitrator</a> og tilpassede koden i DriveForward og HitWall jævnfør <a href="http://www.legolab.daimi.au.dk/DigitalControl.dir/NXT/Lesson10.dir/Lesson.html" target="_top">NXT Programming, Lesson 10</a>. Vi tjekkede at takeControl i begge metoder blev kaldt hver gang i loopet, ved at sætte programmet til at afspille en lyd, når metoden kaldes. Robottens opførsel er den samme som med leJOS NXJ Arbitrator implementation, bortset fra at ved at holde touch sensoren inde bliver den ved med at køre baglæns, hvilket vi også forventede. </p><p>For at gentage eksperimenterne med leJOS Arbitratoren ændrede vi Behavior'en "PlaySound" til at virke med den nye Arbitrator. I første omgang så det ud som om det kun har DriveForward der virkede. Efter at have prøvet nogle gange fandt vi ud at HitWall Behavior'en kun kunne aktiveres 3 gange. Derefter virkede det som om kun DriveForward var aktiv... Det samme var tilfældet når kun DriveForward og HitWall var Behaviors i systemet. Vi fandt aldrig fejlen, men "PlaySound" kom til at virke.</p><p><iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.blogger.com/video.g?token=AD6v5dze4ECzaCLg-iKSdMBfhlo_GXXMmOp_h9LERrFmP8zeZ_o2NA2H_i1_az8nAPwVnA3h-3M-Hy95TeFcNGCY2Q' class='b-hbp-video b-uploaded' frameborder='0'></iframe></p><p>Det ser ud som Arbitrator'en kun virker godt med 2 behaviors, når vi tilføjer den tredje opførsel (højest prioritet), tager den ofte over, men ikke altid! Endvidere sker der det, at når DriveForward er aktiv og PlaySound tager over, så kører det ene hjul samtidigt med lyden afspiller.</p><p></p><p><span style="font-size:130%;"><strong>Motivation Functions</strong></span></p><p><a href="http://legolab.daimi.au.dk/DigitalControl.dir/Krink.pdf" target="_top">Motivation Networks - A Biological Model for Autonomous Agent Control</a> beskriver hvordan en motivations funktion kan bruges som et alternativ til prioriteter, i stedet for en fast prioritet har man en variabel motivation mellem 0 og 1. Ud fra en række motivations variable bestemmes en opførsel, f.eks. kunne en aktiveret tryk sensor give høj motivation for at udføre behavior'en HitWall. Motivations funktionen giver mulighed for at en behavior kan reaktiveres mens den udføres. F.eks. kan HitWall behavior'en afbrydes, mens den drejer, af en "ny" HitWall behavior med højere prioritet. Dette kan gøres ved at tryk sensoren giver en lav motivations værdi et stykke tid efter den sidst har været aktiveret. Hvis sensoren igen trykkes ind efter det stykke tid vil motivations variablen stige, og handlingen udføres forfra (Dette ville kræve en del ændringer i koden, da motivations variablen skal være knyttet til en bestemt udførelse af action).</p><p><span style="font-size:130%;"><strong>Konklusion</strong></span></p><p>Den indbyggede opførsels baserede arkitektur i leJOS er end den vi undersøgte sidst, men der kan stadig opstå problemer som beskrevet ovenfor, men det er problemer man kan programmere sig ud af. Derfor skal man være påpasselig når supress metoden bliver brugt. Det er simpelt at udvide med flere behaviors i forhold til det behavior system vi brugte i sidste uge. Den alternative arbitrator har vi haft mange problemer med. Det ser ud som om den ikke virker helt stabilt med flere end 2 tråde. Da vi kørte med 3 tråde virkede det som om opførselen var mere eller mindre tilfældig. Vi fandt aldrig problemet.</p>SKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0tag:blogger.com,1999:blog-5398201012754842862.post-83403944878820161682007-11-16T09:20:00.000+01:002007-11-16T11:50:12.806+01:00Lesson 9<span style="font-size:130%;">Dagens Mål</span><br /><ul><li>Undersøge leJOS TachoNavigator.</li><ul><li>Teste TachoNavigatoren i praksis.</li><li>Teste præcisionen af TachoNavigatoren.</li></ul><li>Overveje undvigelse af objekter mens der navigeres med TachoNavigatoren.</li></ul><span style="font-size:130%;"><br />Opbygning af robotten</span><br />Vi benyttede standart robotten dog uden sensorer. Det lille baghjul på robotten kan give uregelmæssigheder når robotten startes.<br /><br />Eksperimenter med TachoNavigatoren.<br />Programmet fra side 298 i " Brian Bagnall, Maximum Lego NXTBuilding Robots with Java Brains" blev indlæst.<br />Vi valgte dog at implemntere det i en Behaviour tråd som i Lesson 8, det er dog kunne denne ene tråd der states i selve hovedprogrammet da alle andre Behaviours er slået fra.<br />I følge teksten var det nødvendig at måle hjulafstanden da dette skal bruges til TachoNavigatoren.<br />Første gang målte vi hjulafstanden fra ydresiden af hjulene, da robotten kørte observerede vi at robotten ikke drejede som beskrevet i teksten men næsten 90 grader i stedet for de forventede 45 grader.<br />Vi målte da hjul afstanden som angivet i teksten fra midten af hjulene og dette betød at robotten nu var tæt på at komme tilbage til udgangspunktet.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkkQ8YSWRjk8xlzxXJCr1SbTj2luVdAUcMGSzVVv6Jwx_MIhQ8oI08woeSGjb4h5EkSKLQh8nKCJwipSZjY-MwdrGTTbNP9zVdRdGjGF-O2I9nvldJx_HNSlTfqLH1fG6Uu9_VZ5xW4aU/s1600-h/DSC00084.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkkQ8YSWRjk8xlzxXJCr1SbTj2luVdAUcMGSzVVv6Jwx_MIhQ8oI08woeSGjb4h5EkSKLQh8nKCJwipSZjY-MwdrGTTbNP9zVdRdGjGF-O2I9nvldJx_HNSlTfqLH1fG6Uu9_VZ5xW4aU/s320/DSC00084.JPG" alt="" id="BLOGGER_PHOTO_ID_5133355837432120898" border="0" /></a>Herover ses hvor tæt robotten sluttede på udgangspunktet på 4 kørsler. Hver mønt er placeret midt under hjulaksen på det sted hvor robotten stoppede efter hver kørsel.<br />Robotten udgangspunkt var samlingen mellem de 3 plader i gulvet.<br />Som det ses ud fra robottens størrelse ses det at robotten stoppede mellem 5 og 10 cm fra udgangspunktet og med ca. 5 cm afvigelse mellem hver kørsel.<br /><br />Vi lavede også et eksperiment, hvor vi satte robotten til at dreje 90 grader 4 gange. Først med det lille hjul der følger med når der drejes rundt og derefter hvor hjulet er erstattet af en pind. Som det kan ses på videoerne i bunden af indlægget øger brug af pind i stedet for hjul præcisionen med ca. 10 grader i vores lille forsøg.<br /><span style="font-size:130%;"><br />Undvigelse af objekter mens der navigeres med TachoNavigatoren</span><br />Da vi har implementeret vores BlighBot som en behaviour, ville det være nemt at udvide robottens opførsel med en ny behaviour "Avoid object". Denne nye behaviour skal have højere prioritet end BlighBot behaviouren, og skal som "Avoid object" behaviour'en fra Lesson 7 få robotten til at bakke væk fra objektet, men i modsætning til denne, skal den nye ikke bakke direkte tilbage. Hvis robotten bakkede direkte tilbage, og drejede rundt, for derefter at forsøge igen at køre mod dens mål, ville den fortsætte af præcis den samme sti, og køre direkte hen til forhindringen. For at undgå denne "Dead lock" skal robotten i stedet for at køre direkte tilbage, køre i en vinkel tilbage, for at ændre den rute robotten tager mod målet. Tegningen her illustrerer forskellen.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiScff11thQutmXf5Vv1esvx9sP6oy5gZ1R46o8Dl5PTS5RqGcEfc4gTZiwqUxDjDf0oNkzmPjQ0vTlAvOqeG_rre6kAlFIOf6Ocb6w8S2vPWlIG4as6wSbW2STRGEIHDN41DBx06ozQn8/s1600-h/avoidnavigator.GIF"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiScff11thQutmXf5Vv1esvx9sP6oy5gZ1R46o8Dl5PTS5RqGcEfc4gTZiwqUxDjDf0oNkzmPjQ0vTlAvOqeG_rre6kAlFIOf6Ocb6w8S2vPWlIG4as6wSbW2STRGEIHDN41DBx06ozQn8/s320/avoidnavigator.GIF" alt="" id="BLOGGER_PHOTO_ID_5133363177531229778" border="0" /></a>a. viser hvordan robotten med avoideren fra Lesson 7 hele tiden ville køre ind i forhindringen, mens b. viser at objektet kan undgås hvis robotten bakker et stykke skråt tilbage.<br /><br /><br /><span style="font-size:130%;">Konklusion</span><br />I vores undersøgelser af TachoNavigatoren blev vi overraskede over præcisionen. Under robot race'ed eksperimenterede vi selv med TachoCounteren, hvor indtrykket var at den ikke var specielt præcis. Vi fandt ud af at præcisionen af hjulafstanden var meget vigtig for at opnå en korrekt drejevinkel. Vi målte afstanden til 11.3cm, og selvom vi havde 0.1cm præcision stoppede robotten inden for en radius af 10-15cm fra udgangspunktet. Andre faktorer, som kan have haft indflydelse på denne afvigelse er at startvinklen for robotten kan have afviget en smule fra gang til gang, og robottens baghjul kan have en indvirkning på robottens retning efter der blevet drejet. En mulighed for at øge præcisionen ville være at bruge en pind i stedet for baghjulet. Evt. kunne man udføre eksperimenter med en tusch som baghjul, for bedre at kunne observere den præcise rute robotten kører. Problemet med TachoNavigatoren er at alle disse små usikkerheder lagt sammen over længere tid giver en stor afvigelse.<br /><br /><iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.blogger.com/video.g?token=AD6v5dzayVZ_uOXslNcN_InOxssUqiJ8aPgO8YbDBeZTajlFM5Yu7PghmUMbDtNPt-S27vmpRnZ3TWkC3tDoINvLJg' class='b-hbp-video b-uploaded' frameborder='0'></iframe><br /><iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.blogger.com/video.g?token=AD6v5dx5z0b4F5VkrbIZ6pyvLxfNRWyGuu_xP0ycx9q2sBqKdukJgSMDEieMZgZDRtq4ALlJwFzdbjgYTXz1Jp8Vlg' class='b-hbp-video b-uploaded' frameborder='0'></iframe>SKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0tag:blogger.com,1999:blog-5398201012754842862.post-5602407719646693852007-11-09T09:47:00.000+01:002007-11-15T12:23:16.402+01:00Lesson 8<span style="font-size:130%;">Dagens mål:</span><br /><br /><ul><li>Undersøge opførslen af en robot med flere behaviours.</li><li>Undersøge hvordan flere behaviours kan implementeres.</li><li>Implementere en behaviour og observere robottens opførsel.</li></ul><br /><span style="font-size:130%;">Opbygning af robotten</span><br />For at kunne udføre eksperimenterne monterede vi ultrasonic sensoren, som vist s. 28-30 i LEGO-byggeinstruktionsbogen.<br /><br /><span style="font-size:130%;">Eksperimenter med BehaviourTest1.java</span><br /><a href="http://legolab.daimi.au.dk/DigitalControl.dir/NXT/Lesson8.dir/BehaviourTest1.java">BehaviourTest1.java</a> og <a href="http://legolab.daimi.au.dk/DigitalControl.dir/NXT/Lesson8.dir/">tilhørende klasser</a> blev installeret på NXT'en, og programmet blev afviklet. Vi gjorde os følgende observationer:<br /><ul><li>Robotten kørte tilsyneladende tilfældigt rundt. Robotten valgte en retning, kørte et stykke, hvorefter den stoppede op, og startede forfra.</li><li>Robotten afspillede en lille melodi periodisk.</li><li>Hvis robotten møder en forhindring bakker den, og drejer rundt.</li><li>Undvige manøvren har højere prioritet end den tilfældige kørsel.</li><li>Melodien har højeste prioritet.</li></ul>På LCD displayet kan man se følgende:<br /><ul><li>Klassenavnet "BehaviourTest1.java"<br /></li><li>Navne på de tre behavior tråde "Drive", "Avoid" og "Play" efterfulgt af 0 eller 1. Tallet angiver om tråden er suspended.</li><li>Ud for "Avoid" angiver et tal fra 0 til 255 målingen fra ultrasonic sensoren. Til højre for tallet angiver et bogstav om robotten 'b' bakker, 'l' kører til venstre eller 's' i alle andre tilfælde (Vi går ud fra at 's' skal betyde stop, men displayet cleares ikke, så værdien bliver stående).</li><li>Til højre for "Play" står der altid et 's'. Vi går ud fra at det angiver, at når der afspilles en lyd skal robotten stoppes, men displayet cleares ikke, så bogstavet bliver stående.</li></ul>Vi prøvede at deaktivere nogle af trådene, for at observere opførslen af de enkelte behaviours enkeltvis, men vi opdagede ikke noget nyt.<br /><span style="text-decoration: underline;"></span><a href="http://legolab.daimi.au.dk/DigitalControl.dir/NXT/Lesson8.dir/"><br /></a><span style="font-size:130%;">Behaviour Klassen og Locomotion Klassen</span><br />Formålet med at lave Behaviours daemon threads er at de kører i baggrunden og yder en service, og de kører kun så længe det service krævende program. kører.<br />Den private boolske værdi i trådene angiver om tråden er suppressed. I Locomotion klassen testes på om den aktive tråd er suppresed, hvis det er tilfældet gør den ingenting.<br />Når der kaldes delay på en Behaviour, fortager tråden busy waiting så længe tråden ikke er suppressed og tiden for delay'et ikke er gået.<br />Suppression mekanismen i Behaviour.java benytter en boolsk værdi til at afgøre om en behaviour har adgang til motorene. Der kan opstå problemer i forbindelse med at scheduleren skifter den aktive tråd. Da der ikke er synkroniseret adgang til metoderne i Locomotion kan følgende scenarie opstå.<br /><ol><li>"AvoidFront" tråden kalder en metode i Locomotion.java.</li><li>Checket på om den aktive tråd er suppressed bliver gennemført. Lige efter skifter scheduleren til "PlaySounds" tråden.</li><li>"PlaySounds" tråden suppresser "AvoidFront" tråden.</li><li>Scheduleren skifter tilbage til "AvoidFront" tråden, som fortsætter med at udføre metodekaldet i Locomotion, selvom tråden er suppressed.</li></ol><span style="font-size:130%;">Tilføj Behaviour</span><br />Fra sidste uges lektioner havde vi en implementation af braitenbergs køretøj, som har opførslen "kør mod lys". Implementationen er beskrevet i blogindlæget "Lesson 7". Implementationen kørte to tråde, et for hvert motor/sensor par. For at implementere opførslen "kør mod lys" i en behaviour tråd, lavede vi en behaviourtråd, som vi pakkede hele implementationen fra Lesson 7 ind i. Her sørgede vi for at suspend kald til behaviour tråden blev sendt videre til de to tråde, som styrede motor/sensor parene. Vi erstattede "Random Drive" opførslen i robotten med denne nye opførsel.<br /><br /><span style="font-size:130%;">Eksperiment med "kør mod lys" behaviour</span><br />Da vi startede robotten med den nye "kør mod lys" opførsel, kunne vi observere at robotten kørte mod lys på samme måde som beskrevet i Lesson 7, og med samme opførsels hieraki, som beskrevet under eksperimenter med BehaviourTest1.java.<br /><br /><span style="font-size:130%;">Konklusion</span><br />I vores forsøg har vi oplevet at det er nemt at implementere behaviours vha. tråde, og tilføje eller fjerne forskellige behaviours, dog skal man overveje designet grundigt, da der kan opstå race conditions, som beskrevet nederst i afstnittet Behaviour Klassen og Locomotion Klassen. En mulig forbedring ville være at implementere subsumption mekanismen, så race conditions ikke kan forekomme, f.eks ved at lave synkroniseret adgang til metoder og variable der bruges i flere tråde. Implementationen af "kør mod lys" opførslen gik uden de store problemer, og så snart opførslen var lavet om en til Behaviour(.java) kunne den uden problemer "samarbejde" med de eksisterende behaviours.SKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0tag:blogger.com,1999:blog-5398201012754842862.post-12912505938682198022007-11-02T09:33:00.000+01:002007-11-09T09:34:31.264+01:00Lesson 7Dagens mål er at:<br /><ul><li>Bygge et NXT Braitenberg køretøj</li><li>Implementere køretøj 2a og 2b i <a href="http://www.cs.brown.edu/people/tld/courses/cs148/02/introduction.html" target="_top"> Introduction to Machina Speculatrix and Braitenberg Vehicles</a></li></ul>Vi starter med at bygge vores NXT om, jævnfør lego manualen s. 22, til en standard bil. Herpå monteres 2 lamper på toppen af bilen og der påsættes to lyssensorer. I første omgang bygges bil 2a med venstre lyssensor i port S1 og venstre motor i port B, mens højre lyssensor tilsluttes port S2 og højre motor i port C.<br /><br />Næste skridt er at bruge Tom Deans ideer til at implementere sammenhængen mellem sensor og motor. Vi bruger to tråde til at implentere kontrollen - en for hver forbindelse.<br />Vi havde problemer med brug af tråde på NXT'en. Det var kun den ene motor der ville køre. Vi fandt ud af at koden efter vi havde kaldt Thread.start() ikke blev udført. Det skyldtes at vi havde poblemer med kald af tråd metoder og at vi havde erklæret sensor og motor som statiske variable i kontrol trådene. Da det blev rettet virkede programmet efter hensigten.<br /><br />Vi havde implementeret hastighedskontrollen som i <a href="http://www.cs.brown.edu/people/tld/courses/cs148/01/vehicles/vehicles.htm" target="_top"> Notes on construction of Braitenberg's Vehicles, Chapter 1-5 of Braitenbergs book</a>, med samme normalize metode. Dog så det ud som om at lys påvirkning ikke havde stor effekt. Vi satte NXT'en til at udskrive sensorværdierne, der ifølge API'en skulle gå fra 0-1023, men vi målte værdierne til mellem 400 ved normalt rumlys op til 900 ved at en lampe var sat op lige foran sensoren.<br /><br />Vi blev nød til at gøre grænserne for MIN_LIGHT og MAX_LIGHT (threshold værdierne for lyst og mørkt) tilpassende. Når programmet startes skal der tages en måling, som MIN_LIGHT og MAX_LIGHT bliver sat til. Derefter skal grænserne tilpasse sig situationen. Vi besluttede at robotten skulle kunne huske målte værdier for et bestemt stykke tid. Ud fra de målinger skulle MIN_LIGHT og MAX_LIGHT værdierne så udregnes, som hhv. den mindste målte værdi og den største målte værdi inden for tidsintervallet. Dette blev implementeret ved at gemme værdier i to arrays med hhv. de største og mindste værdier for hver motor/sensor par. Hver indgang i de to arrays er hhv. den største og mindste måling foretaget inden for et samplings interval. Dette gjorde at robotten kunne "huske" de sidste<br /><br />(Sampling rate * array størrelse) sekunder<br /><br />Når arrayet er fuldt fyldes værdier ind fra starten igen. MIN_LIGHT og MAX_LIGHT værdierne er så bestemt ved hhv. den mindste og største værdi i de to arrays.<br /><br />Først havde hver sensor / motor par sine egne thresholds værdier, men vi observerede at begge motorer altid kørte og robotten reagerede ikke særligt kraftigt på udsving i lysmålingerne. Vi konstanterede at det skyldtes at hver tråd havde sin egen opfattelse af hvordan lyssituationen var. Ved at lave MIN_LIGHT og MAX_LIGHT værdierne fælles for trådene vil kraftigt lys på den ene sensor betyde at den anden sensor registrede lav belysning.<br /><br />Da dette blev implementeret med motor/sensor par som vist i figur 1 Vehicle 2a i opgave beskrivelsen, kunne vi observere at robotten søger væk fra lyset. Vi testede ved at holde en diode cykel lygte foran sensorerne. Hvis vi byttede om på motorerne, som Vehicle 2b kørte robotten istedet mod lyset.<br /><br />I vores tests observerede vi at hvis robotten blev udsat for skarpt lys, og dette lys blev fjernet, så stod robotten nærmest stille i en periode, for derefter pludselig at begynde at køre. Dette skyldes at robotten husker den højeste lysværdi i en periode som tidligere beskrevet. Når denne periode er gået falder MAX_LIGHT værdien hurtigt, og robotten skifter hurtigt hastighed. Vi observerede at den tid robotten stod stille svarede til den tid robotten skulle kunne "huske". Hvis man skulle forhindre denne bratte ændring i robottens opfattelse af lyst og mørkt kunne man implementere en vægtning af de målte værdier, så gamle værdier får mindre indflydelse.SKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0tag:blogger.com,1999:blog-5398201012754842862.post-58871957303403030982007-10-11T13:44:00.000+02:002007-11-15T13:56:26.598+01:00Lesson 6Målet er at:<br /><ul><li>Ombygge vores NXT til en balancerede robot.</li><li>Lave et program der justerer hjulene hastigheden passende.</li></ul>Vi startede med at bygge robotten efter vejledning s. 276-279 i <a href="http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?z=y&endeca=1&isbn=0973864915&itm=5"> "Maximum Lego NXTBuilding Robots with Java Brains</a>". Dog havde vi det problem at vores NXT bruger en større batteri pakning, så tyngdepunktet blev ikke det samme som i papirene. Fra start skulle robotten hælde ret meget til den ene side for at være i balance. Vi downloadede og kørte Sejway.java, men resultatet var ikke godt. Den kørte lidt frem og tilbage, og så ellers bare i en retning.<br /><br />Efter aflæsning af værdier fra lyssensoren fandt vi ud at værdien ændrede sig ret jævnt trinvist, så længe hældningen ikke var for stor. Hvis hældningen var meget stor var den aflæste værdi ca. var den samme som når lyssensoren var meget tæt på bordet.<br /><br />Vi bestemte os for at lave om på robotten og lave tyngdepunktet højere i håb om den den var nemmere at balancere og for at få sat lyssensoren i en bedre position mod bordet - altså med mindre hældning, når robotten var i balance. Vi prøvede igen Sejway.java og robotten kørte bedre. Efter at have justeret lidt på de variable i koden, ved sætte scale og KP op kørte robotten bedre, men stadig ikke godt.<br />Den kørte frem og tilbage i lidt tid, men så begyndte den at tippe og selv med fuld kraft på motorene kunne den ikke rette op. Vi fandt ud af at værdien af startkalibreringen havde stor betydning på hvor godt robotten kunne balancere. Det er svært at trykke "enter" ind uden at skubbe til robotten, så vi lavede en ændring, der gjorde at vi kunne aflæse lyssensorens værdi, hvorefter vi manuelt kunne sætte den med "højre, venstre" knapperne.<br /><object id="BLOG_video-UPLOADING" class="BLOG_video_class" contentid="UPLOADING" height="266" width="320"></object><br />Vi fik ikke robotten til at balancere meget kort tid af gangen, men vi går ud fra en mulig forbedring kunne være at fjerne muligheden for at hastigheden på motorene bliver 0. Når hastigheden er 0, står robotten stille og falder bagud. Hvis vi laver det så hastigheden bliver lav i den samme retning som den falder vil den muligvis køre bedre.hSKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0tag:blogger.com,1999:blog-5398201012754842862.post-86718872586928827342007-10-06T17:17:00.000+02:002007-10-06T21:04:40.073+02:00Lesson 5 - The Robot RaceDagens mål er at få lavet en robot, der kan gennemføre banen så hurtigt som muligt. Det har vi tænkt os at gøre i 3 del skridt. <div><div><ul><li>Diskutere og vælge design af robot</li><li>Implementere programmet, der skal styre robotten</li><li>Optimere program og design</li></ul><div>Ved sidste øvelsesgang fik vi lavet en robot der kunne følge en sort linie og stoppe på et grønt felt. Vi så det dog som en ret stor ulempe at robotten kun havde en sensor. Ved at tilføje flere sensorere kunne robotten vide mere om omgivelserne - fx til hvilken side af den sorte linie den kørte ud over. Vi legede lidt med ideen om at lade robotten køre på den sorte linie istedet for altid at køre lige ved siden af den, så den ikke behøvede at justere retningen så ofte, men med kun en sensor riskerede vi at komme i problemer. Ihvertfald med en simpel implementation, hvor vi starter robotten til venstre for linien og hvis den møder sort kører den bare lige ud, møder den hvidt igen må den være kørt ud over justerer tilbage mod startpositionen- dette kan gå galt i dette tilfælde:</div><div><img id="BLOGGER_PHOTO_ID_5118276511742550402" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: hand; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjNzaQ4jngmW1DXJ1L_mP_FAKh29fE3gFUDlQjlU594nVskR_lGI3bIJ9YqKDL-rKhpFuc5-NoTbsSpVKeuNQYTbqMtRXH3PRKTLcQjIEmOWTMVpDDsQwRLthlBzWU7Rp3V3BoEp4_55VQ/s320/nxt_paa_afveje.jpg" border="0" /></div><div>Her starter NXT'en til venstre for stregen, møder sort og kører lige ud langs den hvide linie, men umiddelbart skulle den justere til venstre for at komme tilbage til udgangspositionen, men det vil gå galt fordi linien drejer.</div><br /><div>Ved brug af flere sensorer, lad os bare sige 3 fordi NXT'en har 3 indgange, ville vi have mulighed for at kunne følge linien bedre. Ved en montering af sensorerne foran ligesom på nedenstående billede, ville det være let at aflæse hvilken retning banen går i.</div><p><img id="BLOGGER_PHOTO_ID_5118279062953124242" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: hand; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh6I5YLyYbPbelsurnrvqnKjnB76J_cymrRvB2dOd0VuABhhDoEPTfqNoYViuktkO2Gn1y1HVUmFNOZ-fVhgAg7hKDACd1akuLm46cTpmR-bwBFzfzHP2E4z3w4LcjMEcit96Z1kOkyWeA/s320/nxt+3+sensorer.jpg" border="0" />Hvis den sorte linie drejer til højre vil den højre blå sensor begynde at aflæse sort og retningen skal justeres mod højre indtil den orange sensor aflæser sort og den højre blå aflæser hvid. På samme måde hvis linien skifter retning mod venstre.</p><p>Desværre var der ikke flere sensorer vi kunne låne, så denne løsning blev vi nød til at droppe.<br /></p><p>Stadigvæk ville vi gerne have muligheden for at "se" mere af banen. Derfor kom vi på at vi kunne bruge en motor til at rotere sensoren, så den kunne lave et sweep af området foran banen:</p><p><img id="BLOGGER_PHOTO_ID_5118283787417149858" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: hand; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgFcHokuQtueYPzR7IqIC_MOeVkigRQViVEekWlnEyPrmmM-GMUrag_EH2i__IG5WweMnGVhEYIeoNpAS_tL6cHGOMJfBkWJoIWIqJ_UzrTfZyzyNDG2rhEZ0VgSAHkesNCwN4I-7tAb0c/s320/sweepingnxt.jpg" border="0" />I første omgang havde vi et hjul monteret på samme motor der roterede sensoren, så NXT'en bevægede sig i samme retning som sensoren. I princippet gjorde det bare at robotten blev led delt, men der var ikke rigtigt nogen fordel i forhold til den simple linefollower vi implementerede i sidste lektion. </p><p>Derfor besluttede vi at fjerne hjulet på den roterende sensor, så farvesensoren kunne rotere uden at påvirke retningen direkte. Håbet var at sweepet kunne laves hurtigt, så vi kunne få information om venstre og højre siden af den sorte linie og derudfra beregne hvordan NXT'en skulle køre. </p><br /><img id="BLOGGER_PHOTO_ID_5118292798258536882" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: hand; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiF_xhwtSYsLSpiIYLFHbBuqp2p9zKTi9m_OVXX5Wd1JD-VRwAO79G1R2er9Gu5vedlUawnMMSUGpfqlYpAxf1s-RawvA17_ZcAU3Q4sKicPHti-HJ4XOEHd8CWYzwjp5GvE2wXnWXmVB0/s320/DSC00068.JPG" border="0" /> Programmet blev implementeret således at sweepet prøver at følge linien. Dvs. at når sensoren har set sort og derefter hvid stopper den og roterer tilbage. Værdien hvor linien slutter til højre (hvis den slutter ellers den max_taco) og værdien til venstre, hvor linien slutter bruges til at beregne middelværdien x, der bruges til beregning af hastighederne på motorene der driver hjulene. Vores første forsøg kan ses i grafen nedenuden.<br /><br /><img id="BLOGGER_PHOTO_ID_5118296075318583762" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: hand; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEijfW3BDKqVay77cvgGw5R5sDr1xuSmxieydrObAVsOgusUQSAIoP-FZyp7rG7Eob0GzfLsmNZebnVc0nAg-2MHXGn-5iIP7N68YcnfohyphenhyphenlJNKdtVKeLjI2Bn7aF8evZ0vfQEqHtb3ZNj0/s320/hast1.jpg" border="0" /> Ideen er at hvis x er positiv skal robotten dreje mod højre. Dvs. at venstre hjul får fuld hastighed, mens hastigheden på det højre hjul varieres. Desværre fandt vi ud af overstående gav en for kraftig styring og værdien blev justeret til den nedenstående graf, der så ud til at virke meget bedre.<br /><img id="BLOGGER_PHOTO_ID_5118297690226287074" style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: hand; TEXT-ALIGN: center" alt="" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhLtc01p15hyphenhyphenCoWPTT1ScwKoj7N7MLg_FXewhRqnIMOEgXpfEhmOzzbxigDOEIJ_qYl-5s1isfGzF2lPG3_340mckAEtE7xUvSlqwF94RfZdSQL5xCK2WwJsGVEIixWbeiaKp-GaFNaQHk/s320/hast2.jpg" border="0" />Bortset fra det tilfælde hvor x er meget stor. Derfor indsatte vi to thresholds, et til at lade det ene hjul floate og et andet til at bakke på det ene hjul for at få skarpere sving ved store x-værdier.<br /><p></p></div><div>Vi lavede en del justeringer, da det så ud som om at værdier ikke blev læst ordentligt ved høj hastighed på sweepet - se fx denne video hvor det går galt:</div><div><br /><br /><iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.blogger.com/video.g?token=AD6v5dxTNPFBAJPC897JA6mM0i3RYwlKeg2sJJ4pLJA0vbu5qixwsEnsLN0p7vnO3NdS7aF7EQnLl-kWTZgu4guqhg' class='b-hbp-video b-uploaded' frameborder='0'></iframe></div><div> </div><div>Endvidere fandt vi ud af at hvis den sorte linie drejer meget skarp kan vi risikere at et sweep kun læser hvidt og ingen sort. Dermed ville robotten ikke vide hvad skal gøre og vi blev nød til at implementere en løsning der sagde at hvis den kun så hvidt skulle den bare dreje til venstre for finde banen igen.</div><div> </div><div>Endelig kom vi frem til et optimeret robot der rent faktisk ville kunne gennemføre banen, ved at ændre på motorhastigheder og thresholds. Langsomt men sikkert kørte den, uheldigvis fik vi en fejl læsning, da vi satte den til at stoppe på grønt. Derfor blev vi nød til at lave en counter på grønt, så der skulle gentagne målinger til før robotten konkluderer der er grønt og stopper.<br /><iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.blogger.com/video.g?token=AD6v5dw6NJO0OSwtCLjjWxIK00I4Rq0N14tvJfuzCOLsjObWxSl508YAumHrLue_ON5wIZYOgO2MqMG32fskoN_w2Q' class='b-hbp-video b-uploaded' frameborder='0'></iframe></div></div>SKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0tag:blogger.com,1999:blog-5398201012754842862.post-67986403922126911472007-09-28T09:29:00.000+02:002007-09-28T12:25:05.840+02:00Lesson 4Dagens mål:<br /><ul><li>Eksperimenter med lys sensoren.</li><li>Få sensoren til skelne mellem 3 farver.</li><li>Få robotten til at følge en sort streg og stoppe i et grønt målfelt.<br /></li></ul>Vi startede med at montere lys sensoren på robotten i følge manualen.<br />Dernæst blev alle programmer hentet, kompilet og kørt. Vi kikkede på kildekoden for BlackWhiteSensor og sammenligede den med første uges LineFollower klasse.<br />De 2 forskelle var; i LineFollower udføres der ingen kalibering da blackWhiteThreshold er sat i programmet og LineFollower bruger ikke Locomotion klassen.<br /><br />Vi valgte ikke at teste klassen BlackWhiteSensor med vores egen test klasse, da den bliver testet i LineFollowerCal.<br />Vi tilføjede grøn i BlackWhiteSensor (nu omdøbt til ColorSensor) på samme måde som sort og hvid. I stedet for en thresholdværdi udregner vi nu 2 værdier, baseret på sort/grøn og grøn/hvid.<br />Vi regnede værdien ud på samme måde som før med sort/hvid ved at tage gennemsnittet af de 2 målinger.<br />Herunder er angivet vores målinger:<br /><ul><li>Hvid: 52-53</li><li>Grøn: 45</li><li>Sort: 25</li></ul>Dette gav så følgende thresholdværdier:<br /><ul><li>blackGreenThreshold: 35</li><li>greenWhiteThreshold: 47,5<br /></li></ul>Desuden blev LineFollowerCal ændret så hvis colorsensoren "så" grøn stoppede robotten.<br />Vi testede robotten på banen og opdagede at robotten stoppede i det hvide. Dette skyldes at den hvide bane nogle gange giver en værdi som tolkes som værdien ligger i det grønne område.<br />På banen blev følgende værdier målt:<br /><ul><li>Hvid: 48</li><li>Sort: 27</li><li>Grøn: 47<br /></li></ul>Det ses at disse målinger er markant anderledes end de første målinger som blev foretaget på A4 ark.<br />Man kan se at værdien for hvid og grøn er ligger meget tæt på hinanden.<br />Vi indførte nu at der kun er en thresholdværdi, dvs. der sammenlignes i forhold til den grønne værdi hele tiden.<br />Desuden indførte vi også at robotten skulle måle "grøn" 5 gange i træk før robotten stoppede, dette gjorde vi for at undgå at en enkelt fejllæsning på grænsen mellem det hvide og sorte førte til robotten stoppede.<br />Alle disse forbedringer gjorde at robotten nu kunne følge en sort linje og stoppe på et grønt felt.<br /><br /><span style="font-size:130%;">Tuning af robot.<br /><span style="font-size:85%;">Da vores mål for dagen var opfyldt blev fokus nu at tune robotten til det forestående løb.<br />Vi valgte først ikke at tilføje flere sensorer for at se hvad vi kunne få ud af "standart" robotten.<br />Vores strategi først var at sætte hastigheden op for de 2 motorer, dette medførte naturligvis at robotten bevægede sig hurtigere frem men desvære og hurtigere uden for banen.<br />Vi fjernede også "Thred.sleep" fra robotten for at få så mange målinger så muligt, for at kunne korrigere hurtigt.<br />Vi indførte desuden også at så længe robotten var over det sorte skulle robotten kører med fuld kraft på begge hjul.<br />Dette viste sig dog at have nogle problemer da robotten havde svært ved at korrigere når den kom uden for det sorte.<br />Vi arbejder også med at lave en lys sensor som bevæger sig over overfladen som så skulle være guide for robotten.<br /><br /></span></span>SKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0tag:blogger.com,1999:blog-5398201012754842862.post-14895417744285307422007-09-20T10:14:00.000+02:002007-09-20T12:36:56.341+02:00Lesson 3Dagens mål er at undersøge lydsensoren og lave en lyd kontrolleret lego bil.<br /><br />Vi startede med at eksperimentere med et program, der aflæser værdien fra lydsensoren. Vi fandt ud af den læste værdi er lavere jo længere væk lyden er og lyden kan aflæses hele vejen rundt. Dvs. at et klap bagfra også registeres, dog aflæses en lavere værdi end ved klap forfra, ved den samme afstand.<br /><br />Ved kørsel af <a href="http://legolab/DigitalControl.dir/NXT/Lesson3.dir/SoundCtrCar.java">SoundCtrCar.java</a> skulle man klappe rimeligt højt for at få bilen til at skifte tilstand. Der er 4 tilstande, kør fremad, venstre, højre og stop. Et klap registreres som en lyd, der giver en readValue() > 90. Dvs. at sensoren ikke kan genkende om det er et klap, et råb eller eller en anden høj lyd. Programmet kan kun stoppes med Escape knappen, når den holdes inde imellem tilstand 3 og 4.<br /><br />Vi brugte ButtonListener mekanismen til at få programmet til at reagere på Escape knappen ligeså snart den blev holdt inde. Det eneste vi behøvede var at tilføje:<br /><br />Button.ESCAPE.addButtonListener(new lejos.nxt.ButtonListener() {<br /> public void buttonPressed(Button b){<br /> running = false;<br /> }<br /> <br /> public void buttonReleased(Button b){ <br /> }<br />}<br /><br />og ellers bare lave et tjek på den boolske værdi running, hvis falsk break ud af den ydre løkke. I de indre løkker har vi et tjek på om running == true, hvis falsk springes de over.<br /><br />Vi implementerede Sivan Toledo's (ST) metode til at detecte klap. Metoden virker, men nogle gange opfatter den ikke et klap. Dog kan vi se at fløjt og andre længerevarende høje lyde ikke har nogen effekt. Den anden implementation SoundCtrCar.java, reagerer på alle høje lyde (over 90), mens vores bedre adskiller lyde. Vi har implementeret det på følgende måde:<br />while (running){<br /> display(sound.readValue());<br /> if (sound.readValue() < lowSoundThreshold && running){<br /> time = (int)System.currentTimeMillis();<br /> while(time + 25 > (int)System.currentTimeMillis() && running){<br /> if(sound.readValue()>highSoundThreshold){<br /> time = (int)System.currentTimeMillis();<br /> while(time + 250 > (int)System.currentTimeMillis() && running){<br /> if(sound.readValue()<lowSoundThreshold){<br /> mode++;<br /> if(mode==5){<br /> mode=1;<br /> }<br /> setMode(mode);<br /> break;<br /> }<br /> }<br /> break;<br /> }<br /><br /> }<br /> }<br /> }<br /> }<br /><br />hvor running stadig er vores boolske sat til sand så længe escape ikke trykket ned. lowsoundthreshold="50" og highsoundthreshold="85". Sådan som klap beskrives af ST skal der være stilhed, derefter en høj lyd og så stilhed. Dvs. at har et tjek på om der er stilhed, hvis det er tilfældet tjekker vi om der indenfor 25 ms kommer en lydmåling > highSoundThreshold. Er det tilfældet tjekker vi om der er stilhed indenfor 250 ms efter den høje lyd og vi har et klap.<br /><br />Bilen detekterer kortvarige høje lyde, fx en hård plastik bold der rammer et bord, et tramp i gulvet eller lignende. En mulig forbedring kunne at analysere et klap bedre. Altså få robotten til at gemme samplings data og lave en graf over et klap. Derved kunne vi bedre finjustere thresholds (tid og lydstyrke) samt tilføje flere thresholds.SKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0tag:blogger.com,1999:blog-5398201012754842862.post-53941888411759958592007-09-14T09:24:00.001+02:002007-09-14T12:39:32.285+02:00Lesson 2Dagens mål er at undersøge NXT ultrasonic sensoren, og bygge og programmere en wall follower.<br />Vi startede med at bygge lego robotten om, så lydsensoren blev monteret, derefter gik vi i gang med at teste programmerne på planen.<br /><br />Det første program var et simpelt program til at udskrive værdien der blev aflæst fra sensoren på displayet. Underligt nok kunne vi ikke få dette program til at virke, men efter lidt flytten rundt både på polling intervallet og sensor portene fik vi det til at virke. Tilsyneladende virkede sensoren ikke i port 4, så da den var flyttet til port 1 var problemet løst.<br /><br />Robotten forsøger at komme hen på en bestemt afstand af et objekt. Den afstand er sat til distanceThreshold i programmet. Robotten skal se et objekt før den begynder at bevæge sig hen imod det, dvs. hvis der ikke er nogen objekter inden for sensorens rækkevidde så holder robotten stille. Vi kunne ikke lige umiddelbart gennemskue forholdet mellem robottens afstand til objektet, og dens fart, så vi besluttede at lave et plot af funktionen.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj8v1sK4PegoJgja2-1YEBcvb3aJJ5CAJLIXMOZHmaTdpHKkupoFF9hkdTZQcXT5ZDkV3u7ftJ4WigKOcTR-vQqQ4APH6gxZEP62gBuEGSmooniH6Bjpncppg0uQ5RCGKFDKaNOojHPMds/s1600-h/plot.JPG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj8v1sK4PegoJgja2-1YEBcvb3aJJ5CAJLIXMOZHmaTdpHKkupoFF9hkdTZQcXT5ZDkV3u7ftJ4WigKOcTR-vQqQ4APH6gxZEP62gBuEGSmooniH6Bjpncppg0uQ5RCGKFDKaNOojHPMds/s400/plot.JPG" alt="" id="BLOGGER_PHOTO_ID_5109978415836567442" border="0" /></a><br /><br />Som det ses er det en lineær funktion, som vi umiddelbart ikke kunne få helt til at hænge sammen med robottens opførsel. Ved nærmere eftertanke kunne vi se at det skyldes at robotten først begynder at bevæge sig når der er et objekt foran sensoren, og dette objekt kommer tættere på når robotten kører. Desuden startede vi robotten ved at holde et objekt ind foran sensoren, og dette objekt holdt vi relativt tæt på sensoren, så opstarts hastigheden var også lav. Vi lavede en simpel test ved at holde robotten op foran en mur, og ændre afstanden. Der kunne vi se at sensoren kunne måle op til omkring 150, hvorefter værdien blev aflæst som 255 hvis robotten blev flyttet lidt længere væk. Vi prøvede at ændre på polling intervallet i den tro at lydsignalet måske ikke kunne nå at blive aflæst inden næste lydbølge blev sendt, men det gav samme resultat.<br /><br />Hastigheden af robotten er den kontrollerede variable, og afstanden er den målte variable. Denne form for kontrol kaldes simple feedback control, og da vi kan se fra plottet at funktionen er linær kaldes det proportional kontrol.<br /><br />Da vi kom til WallFollower delen fik vi implementeret WallFollower.java udfra Philippe Hurbain's (PH) NQC kode. Han brugte en anden sensor, så vi definerede andre thresholds værdier. Under testningen af programmet, kørte bilen konstant ind i væggen. Vi lod den bippe hver gang den læste 255 og det gjorde den mistænkeligt mange gange, hvor den ikke burde gøre det. Fx når sensoren pegede direkte ind i væggen. Vi prøvede forskellige threshold værdier for at få det til at virke, men forgæves. Endeligt spurgte vi en anden gruppe om vi måtte låne deres program, der virkede, og bilen kørte stadig ind i væggen. Vi prøvede deres sensor og så virkede vores program. Altså må sensoren være defekt. Fordi vi havde så meget bøvl med sensoren fik vi ikke programmet fin tunet, men det virkede.<br /><br />Fred G. Martins (FGM)'s version af algoritmen er 3 state algoritmer, men PH's algoritme bruger flere værdier og altså flere tilstande. Selvom PH definerer 6 thresholds er der kun 5 der bliver brugt og det giver 6 forskellige states. 3 forskellige hastigheder for at dreje væk fra muren og to for at dreje ind imod muren og en til at køre ligeud.<br /><br />Fordi vi havde problemer med vores sensor fik vi ikke afprøvet de forskellige grader af turns, men umiddelbart vil vi mene flere threshold værdier giver en mere jævn kørsel.<br /><br />PH's algoritme har to hastigheder, en langsom til når den er tæt ved væggen og en hurtig til når den er langt væk fra væggen. Her vil det muligvis være en fordel at implementere en propertionel kontrol ligesom vi så i avoider koden.SKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0tag:blogger.com,1999:blog-5398201012754842862.post-55007484977704115042007-09-07T10:13:00.000+02:002007-09-07T11:41:23.222+02:00Lesson 1Dagens mål er at installere leJOS NXJ systemet. Samle lego bilen iflg. lego manualen og køre LineFollower programmet.<br /><br /><br />Vi startede med at pakke Lego Mindstorm kassen op, tage delene ud af plastikken, og spredte delene ud over skrivebordet. Vi fandt NXT enheden og tilkoblede den til computeren. Vi delte os op, så en samlede lego bilen og de to andre installerede softwaren jævnfør "leJOS NXJ installation guide".<br /><br />Vi testede systemet ved at overføre og køre "Tune.java".<br /><br />Da lego bilen var færdig samlet, overførte vi og kørte "LineFollower.java".<br /><br />Ved at køre programmet "LineFollower.java" på bilen med lyssensor, kunne vi få bilen til at følge en sort linie. Ved eksperimenter fandt vi ud af at bilen kunne følge alle linier, hvor der var tilstrækkelig stor forskel mellem farverne. Vi foretog målinger på sort og hvid:<br /><br />Sort: 35<br />Hvid: 57<br />Lysblå: 40<br />Mørkblå: 40<br />Rød: 51<br />Gul 52<br /><br />blackWhiteThreshold er sat til 45, hvilket er en passende værdi til at skelne mellem hvid og sort. Ud fra overstående værdier, kan det ses at det er svært at få programmet til at skelne mellem rød og gul. Hvis bilen skulle køre langs fx en rød linie ved gul baggrund, skulle der nok bruges en anden sensor.<br /><br />Vi prøvede med forskellige værdier af sample intervallet. Ved 10 msek syntes vi den reagerede hurtigere og justerede kursen hurtigere ind. Hvorimod den ved 500 msek og 1000 msek reagerede meget langsomt. Faktisk så langsomt at den ikke kunne følge stregen og kørte tilsyneladende mere eller mindre tilfældigt rundt alt efter hvor den var i samplings øjeblikket.<br />Det virker som om Ole har tænkt over parametrenes værdi da han lavede programmet. 100 msek virker til at være en god værdi. Hvis samplings værdien var for lille ville den ikke køre særligt hurtigt, da den hele tiden ville korrigere. Hvorimod den vil have sværere ved at følge linien ved en højere værdi.<br /><br />Ved at initialisere nye streng objekter, istedet for at bruge "left" og "right", i LCD.drawString kunne vi observere at hukommelsen blev brugt ret hurtigt op og NXT'en kastede en exception. Hver gang man initialiserer et objekt bruger man hukommelse og siden der ikke er nogen garbage collection kan man ende op med at allokere alt tilgængelig hukommelse. Derfor skal man altid huske at lave objekter uden for kontrol loops.SKJhttp://www.blogger.com/profile/01484004134389794829noreply@blogger.com0