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