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