Projekt - 2

Dato:
11-12-2009

Antal timer brugt:
7 timer

Deltagende personer:
Kim Munk Petersen, Andreas Koefoed-Hansen og Tim Rasmussen

Målet:

• Få robotten til at balancere vha. vores gyroskop-sensor-klasse. 

Planen:

På baggrund af sidste blogindlæg, hvor vi havde store problemer med at gyroskopets værdier drifter, vil vi forsøge at finde frem til en løsning på dette. Vi ved at problemet blev løst af en gruppe fra tidligere år, så derfor vil vi forsøge at finde inspiration herfra. Når vi har løst drift-problemet, vil vi prøve at få robotten til at balancere vha. vores gyroskop klasse.

Processen:

For at kunne komme videre med projektet, blev vi nødt til at finde en løsning på gyroskopets drift-problem. En af grupperne fra forrige år havde prøvet at  løse problemet ved at løbende ændre offset'et ud fra de målte værdier fra gyroskopet. Offset'et beregnes således som et eksponentielt løbende gennemsnit [1] af det aktuelle offset og målte gyroskop-værdier. Formlen hertil er følgende, hvor alpha bestemmer vægten af de forskellige værdier.

offset = alpha * offset + (1-alpha) * sensorValue

Hvis værdien af alpha er omkring 1, vægtes de tidligere offsets højere end den målte værdi. Hvis den omvendt tæt på 0, vægtes den målte værdi højere end de tidligere offsets. Den målte værdi ændrer sig fra -533 til 391 ifølge vores tests fra tidligere [2]. Det betyder at en meget stor alpha-værdi gør at offset'et ikke ændres for meget, men alligevel at det langsomt flytter sig langsomt svarende til gyroskopets drift. For at dette virker, er antagelsen at der kommer lige meget udsving til begge sider. Denne antagelse burde holde idet at robotten netop skal holde sig oprejst og dermed skal en tiltning til den ene side ophæves af en ligeså stor tiltning til den anden side. Dette virkede udmærket i starten, men efter noget tid resulterede fejl-værdier i at den beregnede vinkel blev ukorrekt. Vi kunne ikke korrigere for denne fejl idet vinklen nogle gange driftede til den ene side og andre gange til den anden side.

På baggrund af ovenstående ledte vi efter en løsning på nettet. Vi fandt frem til en side hvor en kandidatstuderende, Steven Witzand, fra Australien havde bygget en "GELway" som hans speciale[5]. Navnet GELway kommer fra LEGO i omvendt orden uden O'et konkateneret med "way", inspireret af Segway. Koden til robotten er skrevet i leJOS, men er til version 0.80 så derfor var vi nødt til at ændre lidt på koden for at få den til at virke på vores NXT brick der bruger firmware version 0.85. Resultatet af dette var dog ikke særligt godt, da robotten satte begge motorer til at køre med fuld kraft fremad. Vi prøvede at skrive forskellige værdier ud for at se hvad problemet kunne være, men uden held. Først troede vi at det kunne være på grund af at forskellig firmware. Så vi hentede leJOS v. 0.80 og uploadede firmwaren til NXT´en. Dette havde heller ikke nogen indflydelse på opførslen af robotten.

Ved at prøve os frem med forskellige ting fandt vi frem til at gyro-sensoren skulle monteres omvendt, hvilket resulterede i at robotten i de første 3 sekunder prøvede at balancere, men herefter skiftede til at sætte fuld kraft på motorerne.
Vi overvejede hvad grunden til denne opførsel kunne være overvejede at det kunne være forskelle i design af robotten. Vi fandt en byggevejledning[3] til hans robot og så at han brugte 81,6 x 15 mm hjul hvor vi brugte 56 x 26 mm hjul. Vi udskiftede hjulene, men uden resultat. På billedet herunder til venstre er et billede af vores robot som vi byggede ved første projekt-gang. Vi besluttede os for at prøve at bygge vores robot om således at den blev magen til GELway'en. Den resulterende konstruktion ses på billedet herunder til højre.

Da vi testede den nye konstruktion, var den i stand til at balancere langt bedre end før. Det fysiske design af robotten viste sig altså at være meget betydningsfuldt. Vi konverterede igen alt koden i projektet til at passe til leJOS 0.85, men var denne gang mere påpasselige med at gøre det korrekt. Der var en del ting der skulle ændres, blandt andet at der som default ikke bliver givet strøm til en port hvis der ikke bliver oprettet en motor eller et sensor objekt der benytter porten. En anden ting der skulle ændres var at der på motorerne ikke findes en getActualSpeed()-metode i den nye firmware. Vi fandt ud af at metoden getRotationSpeed() virkede som en god erstatning. Efter disse ændringer blev foretaget og koden uploadet til NXT´en viste det sig stadig at virke. Vi tog tid på hvor længe robotten kunne balancere og det var op til 4 minutter før den kom for meget ud af balance og væltede.

Koden der er tilpasset version 0.85 kan ses på Google SVN vi har oprettet i forbindelse med kurset:
http://code.google.com/p/legolab/source/detail?r=19

- Ændring af mål:
På baggrund af det kode vi fandt på nettet og de resultater dette gav, ændrede vi vores mål til følgende. 

• Forstå principperne i koden fundet på nettet, og på baggrund af dette konstrurere vores egen gyroskopklasse. 
• Kontrollere at vores egen gyroskopklasse leverer fornuftige tal.

Vi prøvede at teste gyroskopklassen fra GELway for sig selv for at sammenligne resultaterne med den klasse vi selv havde lavet og det viste sig at den vinkel vi hentede ud, når vi gjorde brug af vores egen gyroskopklasse var noget mere nøjagtig end den vinkel vi fik når vi gjorde brug af den anden.
Desværre virker vores gyroskopklasse ikke særligt godt sammen med PID kontrolleren. Selv om værdierne er mere korrekte, så vælter robotten hurtigt.

- Fysiske overvejelser:
Som beskrevet fulgte vi samlevejledningen til GELwayen [3] da vi ombyggede vores robot. Selvom vi ikke fulgte den til punkt og prikke, var der kun tale om mindre forskelle. Bl.a. skulle der ifølge samlevejledningen bruges en EOPD-sensor (Electro Optical Proximity Decetion), men denne har vi ingen intentioner om at bruge, så det gjorde vi ikke. Efter at have samlet robotten, vurderede vi at dens design var utroligt solidt, i modsætning til vores initielle robot, hvilket er en god egenskab, både pga. at det giver robotten mere kontante bevægelser hvilket gør det nemmere at analysere og tune dens PID controller, men også at den kan holde til at vælte uden at falde fra hinanden. Desuden resonerede vi over følgende elementer i konstruktionen: den største forskel på vores initielle konstruktion og den nye er at robotten er blevet noget højere. Dette giver et større inerti-moment hvilket medfører en langsommere vinkelacceleration når robotten vælter. Det giver også en forøgelse af luftmodstanden idet vinkelfarten er højere jo længere væk fra omdrejningspunktet man kommer, men dette har dog ikke den store betydning i denne sammenhæng. Alt i alt har robotten altså længere tid til at korrigere hvilket selvsagt gør det lettere for den at holde balancen. Den nye konstruktion er også langt mere solid end den gamle. Den primære grund hertil, er de mange klodser der er brugt til at afstive den. Klart nok medfører det en øget vægt, men i forhold til NXT-brick'en og motorerne er dette negligibelt. Gyro'ens placering er for så vidt ubetydelig så længe den blot vender rigtigt. Dette skyldes at dens output ikke påvirkes af bevægelse, hvilket kunne mindskes ved at placere den tæt på robottens tyngdepunkt, men udelukkende af robottens hældning. Robottens hjul er placeret på ydersiden af robotten. Vi kunne også have placeret dem på indersiden, men det vil gøre robotten mere sidevejrs ustabil og besværliggøre eller umuliggøre placering af lyssensorer som vi måske får brug for til implementering af line-following. De store LEGO-hjul vi bruger gør at robotten kan bevæge sig hurtigt og dermed også korrigere for fejl hurtigere end med mindre hjul. Idet motorerne har intern gearing med en udveksling der giver meget trækkraft, er de på trods af de store hjul i stand til at give robotten en god accelerationsevne. Ultralydssensoren, som vi får brug for til implementering af en opførsel der får robotten til at undvige objekter foran den, er placeret over NXT-brick'en. Den er nødt til at være placeret højt eller pege opad for at undgå at pege ned i jorden når robotten læner sig forover eller kører op af en skråning. Idet vi regner med at placere lyssensorer under NXT-brick'en, er der ikke også plads til ultralydssensoren, og det er derfor plausibelt at placere den oven på robotten. NXT-brick'en er klart den dyreste komponent på robotten og den er derfor beskyttet af klodser både for og bag således at det ikke er den der rammes når robotten vælter. Ligeledes er gyro-sensoren beskyttet af en klods der absorberer noget af slaget når robotten vælter bagud.

Konklusion:
Vi fik endelig noget til at virke ved at benytte noget kode fundet op nettet fik vi en robot der kan balancere i et godt stykke tid. Planen er i første omgang at benytte Stevens kode og forstå hvordan den virker, og senere bygge vores egne udvidelser på. Senere kan vi lave vores egen gyroskopklasse og BalanceControl der virker sammen med de nye moduler.

Den første Legway vi byggede, var ud fra den samme samlevejledning som vi anvendte under den 4. øvelsesgang. Det viste sig at denne robot vi utrolig ustabil og vi byggede derfor en ny og mere solid en. Selv om samlevejledningen beskrev hvordan gyroskop- og ultralydsensoren kunne placeres på robotten, overvejede vi nøje hvor de var placeret mest optimalt. Efter nøje overvejelser besluttede vi at følge anvisningen til hvordan sensorerne kunne placeres. Samlevejledningen beskrev ikke noget om hvordan lyssensorerne til en senere line-following behavior kunne placeret. Det vigtige her, er at sensorerne skal sidde forholdsvis tæt på jorden for at kunne registrere lysændringer. Vi vender tilbage til dette senere hvis vi når at implementere behavioren.

Alt i alt kom vi frem til en solid robot hvor vi mener at de forskellige sensorer og hjul er placeret på den mest optimale måde.

Referencer:

1. Exponential moving average, http://en.wikipedia.org/wiki/Moving_average#Exponential_moving_average
2. Projekt - 1, http://legolab09.blogspot.com/2009/12/projekt-uge-1.html
   
3. GELway building instructions, http://gelway.googlecode.com/files/Building%20Instructions.rar
4. NXT building instructions, http://www.philohome.com/nxtway/bi_nxtway.htm
5. The Java source code for the GELway, http://gelway.googlecode.com/files/GELway%20Java%20Code.rar

Projekt - 1

Dato:

04-12-2009

Antal timer brugt:
7 timer

Deltagende personer:
Kim Munk Petersen, Andreas Koefoed-Hansen og Tim Rasmussen

Introduktion til projektet:
Ved øvelsesgang 4 [1] forsøgte vi at lave en Legway vha. en lyssensor. Som beskrevet i vores projektbeskrivelse vil vi i dette projekt lave en Legway, men denne gang med et gyroskop i stedet for en lyssensor. Den virkelige Segway® Personal Transporter [2] benytter også et gyroskop, eller rettere sagt 5 hvoraf de 2 er sikkerheds-redundans [3][4]. Idet vores Legway ikke styres ved direkte manipulation af tyngdepunktet som en Segway, har vores robot ikke brug for at detektere "roll". I modsætning til Segway der bruger to gyroskoper til forlæns/baglæns rotation, bruger vi kun et enkelt. Alt i alt kan vi altså nøjes med et enkelt gyroskop. Fordelen ved at bruge et gyroskop i stedet for en lyssensor er at lyssensoren naturligvis afhænger af lysforholdende og farven af underlaget. Derudover vil den hele tiden prøve at holde afstanden til overfladen konstant, hvilket vil resultere i at den vælter når den kommer til en skrå overflade som illustreret på figuren herunder.

Der er to typer af gyroskoper: det mekaniske og det optiske [5]. Gyroskopet vi bruger til Legway'en er et optisk gyroskop fra HiTechnic. Udover at der er stor forskel i konstruktionen er der også forskel på den værdi de returnerer. Hvor et mekanisk gyroskop er i stand til at returnere dets rotation ift. alle tre akser, er det optiske kun i stand til at returnere en ændring i rotation, dvs. vinkelfart, omkring én akse. Ved at lave numerisk integration over vinkelfarten fås vinklen i forhold til omverdenen ud fra et bestemt nul-punkt. Det er vores plan at vi bruger en bestemt vinkel som goal-værdi [6] og så vinkelfarten til at afgøre hvor hurtigt robotten skal flytte sig for at kompensere for afvigelsen fra goal-værdien.

Målet:
Målet for denne projekt-gang er først og fremmest at få bygget en robot og få fundet en fornuftig placering til gyroskopet. Vores initielle robot laves ud fra NXTway building instructions [7]. Ud over at få lavet en robot at arbejde på, er målet også enten at finde en god leJOS klasse til gyroskopet på nettet eller kode en selv. På de klasser vi finder eller koder selv, vil vi lave nogle test for at se hvordan værdierne fra gyroskopet passer med det forventede. Dette kunne f.eks. være at test hvor meget værdierne fra gyroskopet drifter når gyroskopet holdes i ro.

Planen:
Planen stemmer meget overens med det beskrevet i målet. Robotten med en gyroskop-sensor når vi helt sikkert at få bygget, men om vi når at få fundet eller lavet en fornuftig klasse til håndtere gyroskobet er mere uvis.

Processen:
I leJOS er der en klasse til HiTechnic-gyroskopet, men det fremgår fra dokumentationen er den ikke er testet. HiTechnic-gyroskopet returnerer ifølge den medfølgende folder ændring i grader pr. sekund, med et offset på 620. Vi prøvede klassen og satte offset'et til 620, men fandt ud af at alle HiTechnic's gyroskoper er forskellige og at vi målte et offset på ca. 600 på vores. Grunden til at vi ikke kan give det nøjagtige tal er at det bl.a. afhænger af temperaturen. En sådan ændring af offset kaldes "drift" og er et kendt problem ved gyroskoper. Selv et meget lille drift kan få stor betydning når man bruger et optisk gyroskop idet man som beskrevet integrerer over målingerne for at finde vinklen. Herved summeres afvigelsen hvilket betyder at den beregnede vinkel forøges eller formindskes selvom gyroskopet er i ro.

Før vi begyndte at kode på vores egen gyroskop-klasse, søgte vi på nettet for at se hvad andre havde udviklet i lignende projekter. Vi fandt frem til en gruppe [8] der havde dette kursus for et år siden og læste at de også havde problemer med at gyrosensoren ”driftede” og derfor var nødsaget til at bruge en EOPD-sensor (Electro Optical Proximity Detector) for at få robotten til at balancere. Vi fandt mange andre der havde bygget deres robot med kun en gyrosensor og fået den til at balancere og køre rundt, men i de fleste tilfælde var der ikke en særlig god beskrivelse af processen og koden var ikke frigivet. De steder hvor vi fandt noget kode [9] var det oftest C-kode eller skrevet til en anden firmware.

Vi besluttede derfor at vi ville lave vores egen gyroskop-klasse til leJOS. Klassen vi lavede er ret simpel. De to vigtigste metoder er getAngularSpeed() der returnerer den rå værdi aflæst fra gyro-sensoren, fratrukket et offset, og metoden getAngle() der returnerer resultatet af den numeriske integration af vinkelfarten (angular speed). Denne numeriske integration laves vha. en Riemann-sum med en intervalstørrelse på ca. 4 ms, hvilket er den højst mulige sample rate for gyroskopet ifølge den medfølgende folder. For at teste vores klasse og ikke mindst gyroskopet, fastgjorde vi gyroskopet til en motor således at vi nøjagtigt kunne styre rotationen via et test-program. Konstruktionen er vist herunder:

Vi lavede først en test af gyroskopets stabilitet, dvs. de rå værdier vi fik når det var i fuldstændig ro. Herunder er et plot der viser at gyroskopet står og svinger mellem værdien 600 og 601. Testen er foretaget over 1 sekund hvor der blev opsamlet 121 samples. Gyroskopets output er som grafen viser altså ikke helt stabilt.

Som nævnt er gyroskop-drift et kendt problem. Herunder er et plot der viser hvor meget gyroskopet drifter i løbet af 2 timer (120 minutter).

Det ses at gyroskopet drifter meget i starten. Efter ca. en halv time er det stabilt på 598-599. Udover at målingerne drifter, ses det også at det er ustabilt pga. de sporadiske udsving på trods af at gyroskopet lå helt stille under testen.

Vi lavede en test af den maksimale værdi gyroskopet kan returnere, dvs. den maksimalt målelige vinkelfart. Ifølge folderen der fulgte med gyroskopet er den 360 grader pr. sekund, men vores målinger viser at vi rent faktisk kan måle større værdier end dette. Målingerne er lavet ved hurtigt at rotere gyroskopet den ene vej og derefter tilbage igen. Til den ene side kan vi måle 391 og til den anden side 533, hvilket fremgår af nedenstående diagram:

At der er så stor forskel på de to yderpunkter kan få betydning hvis robotten er ved at vælte og forsøger at rette sig selv op igen. Idet målingerne muligvis bliver meget større til den ene side end til den anden, bliver den beregnede vinkel forkert. Vi vil derfor muligvis indsætte en begrænsning på 391 grader/sekund til hver side i vores program i håb om at udligne forskellen, hvis dette viser sig at blive et problem.

Ifølge gyroskopets specifikationer returnerer det som beskrevet tidligere en værdi der angiver vinkelfarten målt i grader/sekund. For at teste om dette passer, brugte vi tacho-counteren i motoren til at give den reelle rotation. Målingerne er vist herunder:

Ved at sætte motoren til at rotere med 391 grader pr. sekund, altså den maksimalt målelige vinkelfart fås ovenstående graf. Det ses at gyroskopet tilnærmelsesvis måler den rigtige rotation. Tacho counteren er dog ret upræcis hvilket kan ses ved at dens graf er meget "kantet".

På nedenstående graf ses vinkelfarten returneret fra gyroskopet samt den beregnede vinkel fra vores gyroskop-klasse. Målingen blev lavet ved at starte robotten i lodret position og derefter læne den til den ene side og derefter til den anden. Som det ses er der en lille afvigelse i vinklen hvilket vi tilskriver gyroskopets drift.

Konklusion:
Efter at have arbejdet med gyroskopsensoren en uges tid, er vores indtryk af den ikke særligt godt. Vi har været igennem en lang og til tider meget frustrerende proces med at få håndteret gyroskopets drifting problem. Vi har forsøgt flere metoder for at få gjort tallene stabile, men lige lidt hjalp det. Vi var derfor på et tidspunkt overbevist om at der nok var en fejl i gyroskopet, men efter at have snakket med den anden gruppe der også laver en Legway, ændrede vi denne overbevisning. De sad også fast i det samme problem som vi, så med mindre at begge gyroskoper er defekte er dette ikke problemet. Lige nu er vi meget usikre på hvordan vi skal løse dette problem med gyroskopet, da vi føler at vi har prøvet alt.

Vi har været ude at undersøge andre muligheder for hvordan man kan få en robot til at balancere og i den forbindelse er vi kommet frem til at der eksisterer en tilt sensor. Det kunne være interessant at se hvile data denne sensor sender retur. Eftersom der ikke er andre der anvender denne sensor i forbindelse med en selvbalancerende robot, har vi vores betænkeligheder ved den. Vores bekymring ved tilt sensoren går på at den måske ikke kan opdatere hurtigt nok til at dens data kan bruges i forbindelse med en robot af denne type. I hvert fald må det være muligt at få en robot til at balancere vha. et gyroskop idet vi på Internettet har fundet flere videoer der viser  legway-lignende robotter gøre dette [10]. Af den grund giver vi ikke op med gyroskop-sensoren og arbejdet fortsætter derfor i morgen.

Referencer:

1. NXT Programming, Lesson 4, http://www.legolab.daimi.au.dk/DigitalControl.dir/NXT/Lesson4.dir/Lesson.html
2. Segway® Personal Transporter, http://www.segway.dk/personal-transporter/
3. Segway® Personal Transporter, how it works, http://www.segway.dk/personal-transporter/how_it_works.php
4. How Segways work, http://www.howstuffworks.com/ginger.htm
5. Wikipedia: Gyroscope, http://en.wikipedia.org/wiki/Gyroscope
6. "Goal" value. Chapter 5, pp. 175+179 of Fred G. Martin, Robotic Explorations: A Hands-on Introduction to Engineering, Prentice Hall, 2001. 
7. NXTway building instruction, http://www.philohome.com/nxtway/bi_nxtway.htm
8. Legolab2008 (SecretMan), http://lego.secretman.dk/wiki/Forside
9. NXTway gs, http://lejos-osek.sourceforge.net/nxtway_gs.htm
   
10. Balancing robot, http://www.youtube.com/watch?v=hpCwdu0e3i0

Valg af projekt

Dato:
27-11-2009

Antal timer brugt:
5 timer

Deltagende personer:
Kim Munk Petersen, Andreas Koefoed-Hansen og Tim Rasmussen

Denne uges opgave:
Denne uges opgave går ud på at bestemme hvilket projekt der ønskes at arbejde med. Vi skal overveje alle projekter fra listen og dertil gerne tilføje nye selv. Der skal udvælges 3 projekter, hvor det ene er projektet med højeste prioritet og de sidste to er alternative projekter. Til hvert projekt skal der laves et beskrivelse, overvejelser omkring software og hardware, beskrivelse af problemer der skal løses og hvad vi forventer at præsentere når projektforløbet er slut. Efter denne korte beskrivelse, skal der laves en mere detaljeret beskrivelse af det projekt vi har valgt at arbejde med samt en plan for projektets forløb.

Overvejelser omkring projekterne:
Vi har snakket de 6 projekter igennem og har på baggrund af dette udvalgt 2 af projekterne vi kunne have lyst til at arbejde videre med. Ud over de 2 projekter, er vi også selv kommet frem til et projekt der kunne være spændende at arbejde med. De udvalgte projekter, i prioriteret rækkefølge, er:

1. LegWay
2. Farve-scanner (der bygger billedet i lego)
3. Pacman

Vi vil kun koncentrere os om disse projekter fra nu af.

Legway:
Dette projekt går ud på at bygge en Legway robot der kan balancere ved at benytte en gyroskop-sensor fremfor en lyssensor som ved øvelse 4. Ifølge vores overbevisning lykkedes det ikke for nogen gruppe at få den SegWay-lignende robot til at balancere ved øvelse 4. Idet vi af den grund ikke har nogen anelse om hvor lang tid det tager os at få robotten til at balancere, tillader vi os at definere projektet en smule løst. Hermed menes at vi i første omgang koncenterer os om at få robotten til at balancere hvorefter vi implementerer en række features hvis der er tid tilovers.

1x NXT

Sensors:
1x Gyroskop
1x Ultralydssensor
1x Lyssensor
1x Kompassensor

Actuators:
2x Motorer

Achitecture:
I første omgang vil vi benytte en simpel klasse, der implementerer en PID kontroller[1] som sender input til motorerne ved at fortolke inputtet fra gyroskopsensoren. For at udvide funktionaliteten til at kunne køre frem og tilbage vil vi bruge en car klasse der som default sørger for at robotten hele tiden balancerer. Klassen skal også have metoder til at få robotten til at bevæge sig. Senere hen kan der anvendes en behavior-baseret achitecture[2], hvor opførsler fx får robotten til at følge en linje på gulvet, gør det muligt at styre robotten fra en computer eller får den til at undgå forhindringer.

Difficulties:
Det sværeste vil i dette projekt være at implementere en PID kontroller og justere den ved at ændre på parameterne, således at robotten kan balancere. En anden ting der muligvis bliver svært er at få robotten til at dreje samtidigt med at den holder balancen.

Presentation:
Til præsentationen forventer vi at kunne præsentere en kørende robot der balancerer på egen hånd og er i stand til at køre op og ned af ramper samt få små skub uden at vælte. Derudover vil vi demonstrere nogle af de valgfrie features, forklaret længere nede, hvis vi når at implementere disse.

Pacman:
Projektet går ud på at simulerer et pac-man spil med Lego-robotter. Der er en pac-man og tre spøgelser der skal bevæge sig rundt på en fastlagt bane. Målet for pac-man er at "overleve" i et stykke tid, og hvor spøgelserne bliver aktiveret med faste intervaller. For at gøre spillet sværere kan hastigheden af spøgelserne øges efterhånden som spillet skrider frem.

4x NXT

Sensors:
8x Lyssensorer

Actuators:
8x Motorer

Achitecture:
Til pac-man kunne der godt bruges en behavior styret achitecture, hvor en tråd finder ud af om man er i live eller om man er blevet fanget af spøgelserne, og andre tråde der bruges til at holde sig inden for banen og modtage indput via Bluetooth.

Spøgelserne kan bruge noget af den samme ide, hvor der også skal holdes styr på om de er inden for banen og hvor der er en tråd afvikler noget AI der bruges til at forfølge pac-man.

Difficulties:
Det sværeste i dette projekt vil være at progammere en AI der får spøgelserne til at forfølge pac-man og samtidigt holde sig inden for banens grænser.

Presentation:

Ved præsentationen vil vi demonstrere hvordan spillet virker ved at starte et kortvarigt spil. Her vil vi både vise et scenarie hvor man vinder spillet, dvs. ikke bliver fanget af spøgelserne, samt hvad der sker når man bliver fanget og dermed taber. Hvis der er stemning for det, vil vi evt. lade en frivillig teste spillet.

Farve skanner:
Dette går ud på at bytte en scanner der kan aflæse et billede og enten sende informationerne til en pc eller replicerer billedet ved at placere legoklodser på en plade.

Hvis billedet skal kunne repliceres i lego skal der bruges:

2x NXT: En der bruges til at scanne billedet og en der bruges til at bygge replikationen.

Sensors:
1x Lys / Farve sensor

Actuators:
5x Motorer
2x til at scanne, 3x til at bygge.

Achitecture:
Ideen er at fordele ansvaret på de to NXT´er så en sørger for at scanne billedet samt sende informationerne via Bluetooth, og en anden bruges til at finde de korrekte klodser og placere dem. Der er ingen grund til bruge tråde da der ikke er flere behaviors der spiller ind, derfor vil en sekventiel struktur være oplagt.

Difficulties:
Den sværeste del vil være at få lavet den del der bygger billedet i Lego, da der skal kunne placeres forskelligt farvede klodser alt efter hvilke informationer der modtages. Der kunne også være problemer med at få vendt klodserne rigtigt så de kan placeres på pladen.

Presentation:
Vi regner med at kunne demonstrere en scanning og "printning" af et billede. For at det ikke kommer til at tage for lang tid, kunne man starte midtvejs i en scanning og printning. Desuden vil vi forklare hvordan vi har løst de sværeste problemer og evt. præsentere kvantitative målinger udført.

Beskrivelse af valgte projekt:
Vil har valgt at arbejde med projektet LegWay. Grunden til dette, skyldes at vi her føler at vi her bedre kan dele problemet med at få robotten til at balancere og køre op i flere problemer. F.eks. vil det først problem der skal løses blot være at få robotten til at balancere. Herefter kan robotten udvides til at kunne kører og derefter også til at kunne dreje. Samtidig giver projektet os også mulighed for at kommer mere i dybden med PID controlleren, som ikke rigtig lykkes for os under øvelsesgangen.

Vi håber på at kunne udvide funktionaliteten så den kan køre frem og tilbage og muligvis også dreje. Hvis vi får den til at køre rundt kan vi også tilføje ekstra features som fx. følge en linje og/eller undgå forhindringer. Tilføjelsen af ekstra sensorer, kunne give mulighed for at tilføje ekstra opførsler til robotten. Som basis for at få robotten til at balancere, køre og dreje, kunne man forestille sig at man har en opførsel der får robotten til at balancere, en til at få robotten til at køre/dreje. Hvis robotten udvides med ekstra sensorer, vil der også kunne tilføjes en opførsel der sørger for at robotten undgår at køre ind i objekter.

Prioiriteter:

1. Balacere vha. PID kontroller.
2. Køre frem og tilbage evt. styret via Bluetooth.
3. Dreje
4. Follow the line
5. Undgå objekter.
6. Navigation vha. kompas.
   

Plan for projektforløbet:
Først vil i bygge robotten og udføre eksperimenter på gyroskop-sensoren, hvorefter vi vil arbejde på at udvide funktionaliteten.

Vi tager udgangspunkt i de ovenstående prioriteter. Planen vil være at opdele projektet i faser, hvor vi arbejder på at implementere og dokumentere en feature af gangen og først begynder på den næste fase når arbejdet på den forrige er færdig. Der kan opstå situationer hvor vi er nødt til at opgive at implementere en feature, hvis vi kommet til at sted hvor vi ikke kan komme videre. I denne situation vil vi i stedet vælge at gå videre til en anden fase.

Referencer:

1. PID controller, http://en.wikipedia.org/wiki/PID_controller
2. leJOS behavior programming tutorial, http://lejos.sourceforge.net/nxt/nxj/tutorial/Behaviors/BehaviorProgramming.htm