Projektaktivitet 5
Dato: 13. Januar 2010
Varighed: 7 Timer.
Deltagere: Annette, Rasmus og Samuel
Mål
Da vi i forbindelse med projektaktivitet 4 konstaterede at vores readAngle-metode endnu ikke virker tilfredsstillende, har vi valgt at undersøge drift yderligere.
Baggrundsinfo
Vi har haft nogle overvejelser om hvor lang tid der går mellem hvert gennemløb af vores while-loop i Segway.java. Vi er interesserede i hvor lang tid der går mellem hvert kald til readAngle(). Hvis denne tid er konstant kan vi måske optimere vores vinkelberegning, ved ikke at skulle læse System.currentTimeMillis() hver gang metoden kaldes, men istedet gange vinkelhastigheden med en konstant for at beregne vinklen. System.currentTimeMillis() returnerer tiden i millisekunder siden NXT'en startede.
Vi er også interesserede i at undersøge gyrosensorens drift igen. Da vi ikke har fået fjernet driften helt endnu. Det skal gøres ved at opsamle rå værdier (vinkelhastigheder) fra sensoren ved hjælp af dataloggeren, se beskrivelse her: Øvelse 3.
Fremgangsmåde
Tiden
I denne projektaktivitet vil vi bruge dataloggeren til at få en fornemmelse af hvad der sker med sensoren under forskellige forhold. Først vil vi undersøge programmets gennemløbstid, for at se hvor ofte readAngle-metoden bliver kaldt. Dette gøres ved at kalde System.currentTimeMillis() i funktionen readAngle() og bruge dataloggeren til at gemme værdierne.
Vi har lavet flere målinger, hvor forskellige elementer i koden har været udkommenteret, bl.a. kald til LCD objektet og Thread.wait().
Offset
Derudover har vi logget gyroSensorens offset over en periode på en halv time, både med fuldt opladet batteri og med brugt batteri. Målingerne er lavet ved at robotten står helt stille og gyrosensorens raw value læses og gemmes med dataloggeren. Der er lavet tre målinger, én hvor alle kald til LCD objektet er udkommenteret, én hvor alle kald til LCD objektet ikke er udkommenteret og en hvor alle kald til LCD objektet er udkommenteret og Thread.wait(6) også er udkommenteret. Den brugte kode kan ses i [5.1]. Alle målingerne er udført på den samme sensor, og resultaterne kan muligvis variere fra sensor til sensor.
Den sidste måling foregår ved at logge både vinkelhastighed og den beregnede vinkel, mens robotten bevæger sig. For at dette kan lade sig gøre, er vi nødt til at ændre lidt i Dataloggeren. Det er vi fordi vi tidligere har forsøgt at logge flere værdier i forskellige filer, hvilket får NXT'en til at gå ned. Derfor ændrer vi nu dataloggeren så den skriver to værdier i samme fil, adskilt af mellemrum og efterfulgt af linieskift, for at få to kolonner.
Til at analysere de data som dataloggeren giver, har vi brugt GNU Octave, som er en opensource pendant til Matlab. Nogle kommandoer er kompatible med matlab, men vi har ikke testet dette. Alle data og vores m-filer (scripts) kan downloades (se [5.3]).
Resultater
Alle måledata kan ses i [5.3].
Tiden
Målingerne viser den værdi som returneres af metoden System.currentTimeMillis().
Ved første måling er der ikke udkommenteret noget.
Målingen ser lidt sjov ud pga. det knæk den laver efter noget tid, men før og efter er gennemløbstiden konstant. Det er ikke helt klart hvorfor denne ændring opstår, og da vi ikke har været opmærksomme på det, da vi udførte målingen, har vi svært ved at give en forklaring på dette. Derfor kunne dette undersøges nærmere hvis der var tid.
Under den næste måling er alle kald til LCD objektet blevet udkommenteret.
Her er gennemløbstiden konstant igen og den gennemsnitlige gennemløbstid (hældningen) ligger på ca. 15 ms.
Sidste måling er fortaget hvor kald til LCD Objektet og Thread.wait(6) er udkommenteret.
Her er gennemsnitet 5-6 ms.
Offset
Vi har lavet flere målinger hvor vi har aflæst gyrosensorens "rå" værdi fra A/D konverteren (vinkelhastigheden). Det er en 10 bit konverter som derfor kan levere værdier fra 0-1023, som repræsenterer vinkelhastigheden i grader/sekund. Som tidligere nævnt har gyrosensoren et offset som vi har prøvet at finde. For at kende udviklingen af offsettet, har vi målt værdierne over en periode på ca. 30 min.
I Figur 5.4 og Figur 5.5 er to af målingerne vist samt til sidst en graf (Figur 5.6) hvor alle målingerne er plottet ind.
Figur 5.6
Det ses på grafen at sensoren i nogle tilfælde har et indsvingnings forløb som er på ca. 5-8 min.
Under udførslen af disse målinger har vi ikke været opmærksomme på om NXT'en var tændt før målingen gik igang. Den grønne kunne godt tyde på at den muligvis var foretaget i forlængelse af en anden måling, dvs. NXT'en ikke har været slukket i mellem de to målinger.
Målingerne er foretaget over 30 min og vores offset bliver normalt beregnet i en periode over 30 sekunder i starten af forløbet. I indsvingningsperioden falder offset værdien kraftigt og dette kan være årsagen til vores drift.
Ud fra dette må vi nok konkludere at selv den bedste kalibrering af offsettet hurtigt vil blive uaktuel, så det ikke vil være muligt at holde robotten oprejst i de fire minutter vi havde håbet på. Her er vi nok i stedet nødt til, hvis det er muligt, at bruge grafen som udgangspunkt for et dynamisk offset.
Man kunne lave yderligere målinger og undersøge hvor tæt de ligger op ad hinanden. Det er et krav at driften altid har samme forløb for at kunne korrigere på denne måde. Hvis den grønne kurve i Figur 5.5 mangler et indsvingningsforløb selvom den har været slukket inden målingen er foretaget er det et problem. Hvis målingerne altid er ens når robotten har været slukket mellem målingerne vil det være muligt at finde en forskrift eller der kan samles data så er kan korrigeres vha. tabelopslag. På denne måde ville man opnå et dynamisk offset.
Vinkelhastighed og vinkel
Disse målinger er foretaget ved at logge vinkelhastighed (grøn) og vinkel (rød) samtidig, mens robotten bevæges frem og tilbage.
Figur 5.7
Figur 5.8
Figur 5.9
Vores målinger viser at vinklen drifter meget når robotten bevæges hurtigt frem og tilbage.
Når vinkelhastigheden (den rå værdi som A/D konverteren returnerer) er over ca. 400 grader/sekund eller under -440 grader/sekund sker det at A/D konverteren "klipper" værdien. Dvs. de returnerede værdierne er 400 eller -440, fordi A/D konverteren ikke kan repræsentere en værdi der er højere eller lavere.
I den tid hvor robotten bevæger sig hurtigere end dette, vil den beregnede vinkel ikke vokse hurtigt nok og omvendt når hastigheden er negativ. Producenten af gyrosensoren garanterer dog heller ikke at Sensoren kan registrere en hastighed der er hurtigere end +/- 360 grader/sekund.
Værdierne i figur 5.7 og 5.8 viser vores målinger før der blev kompenceret og figur 5.9 viser målinger efter vi i vores software har kompenceret for problemet.
Det ses dog at driften forekommer på alle tre målinger, dvs. også efter kompenceringen, men det skyldes den måde robotten bevæges på. Bevægelserne skete ved at vi manuelt bevægede robotten frem og tilbage. På denne måde er det svært at kontrollere ordentligt, og driften på figur 5.9 opstår hovedsageligt fordi robotten bevæges hurtigt til den ene side og langsomt til den anden. Dvs. vores kompencering virker kun hvis fejlen er den samme både positiv og negativt.
Kompenceringen sker ved at vi i vores readValue metode sørger for, at hvis den angularVelocity (port.readRawValue() - offset) er større end 395 bliver angularVelocity sat lig med 395 og hvis angularVelocity er mindre end -395 bliver den sat til -395. Herved undgår vi problemet med at A/D konverteren "klipper" assymetrisk og så får vi udelukket det asymmetriske klip som årsag til at det vandrende set point.
Konklusion
Vores målinger har vist at gennemløbstiden i vores program ligger et sted mellem 5 - 15 ms.
Vi syntes denne måling var interessant fordi den giver os en ide om hvor lang tid der gik mellem kaldene til readAngle. Desuden samples der kun hver 3. ms så det giver ikke mening at kalde den hurtigere end dette.
Målingerne viser at offsettet kan være meget ustabilt i de første 5-8 min. Umiddelbart betyder det at det er nødvendigt med et dynamisk offset der måske kan beregnes ud fra målinger som dem der er udført i denne projektaktivitet. Der skal dog mange flere målinger til for at finde en klar tendens. Ud fra denne tendens kan der måske findes en forskrift eller data til en tabel som kan bruges til at kompensere for det skiftende offset.
De sidste målinger hvor vi loggede sammenhængen mellem vinkel og vinkelhastighed gav et godt overblik og viste tydeligt at der er et problem når hastigheden er høj. Denne kilde til problemer er dog fjernet nu, ved at softwaren klipper symmetrisk.
I projektaktivitet 4 fandt vi ud af at der muligvis er problemer med normaliseringen. Det skal undersøges i projektaktivitet 6.
Kilder
[5.1] Koden som er brugt under målingerne
[5.2] GNU Octave
[5.3] Måledata
Ingen kommentarer:
Send en kommentar