Projektaktivitet 7 Konklusion

Projektaktivitet 7 Konklusion

Dato: 15. januar 2010
Varighed: 7 timer
Deltagere: Annette, Rasmus og Samuel


Mål
Da der ikke er mere tid til at lave yderligere afprøvninger vil vi bruge i dag på at samle op på hele projektet.


Oprindeligt mål for projektet

Det oprindelige mål var at få robotten til at finde vej op ad Alishan Train Track balancerende på to hjul. Det gav nogle delopgaver der var som følgende:

- Få robotten til at balancere.

- Få robotten til at balancere på en skrå overflade.

- Navigation på banen.


At få robotten til at balancere krævede undersøgelser af gyrosensoren. Her oplevede vi første gang hvordan der var store problemer med at sensoren drifter. Det var et problem der forfulgte os gennem hele projektet og har gjort at vi ikke har fået opfyldt målet. Når vi troede vi havde fået driften så langt ned at vi kunne PID regulere robotten viste det sig at det ikke var tilfældet.

Vi har også haft nogle mystiske oplevelser med at vi er gået hjem nogle dage, hvor problemet har været stort set væk og når vi har fortsat arbejdet næste dag har der været meget voldsom drift. Det må dog nok tilskrives tilfældigheder, at det indimellem har set ud til at vi er kommet driften til livs, for vi er efterhånden ret sikre på at de følgende nævnte forsøg på at løse problemet ganske enkelt ikke er gode nok.



Forsøg på løsning af driftproblemet

Vi har været igennem mange undersøgelser for at finde en løsning på problemet. Overordnet har der været følgende forsøg:

- Glatte integralet ud (og fjerne det igen).

- Optimere kalibrering af offset.

- Indføre grænse på -1 og +1 i vinkelberegningen.

- A/D converteren.

- Tiden mellem læsninger justeret.

Det har været tidskrævende at lave ændringerne og efterfølgende afprøvningerne for at se om det havde positiv effekt på problemet. Det har drillet os meget at nogle af justeringerne har set ud til at virke, men efterfølgende har det vist sig ikke at virke alligevel, det har været meget frusterende. Overordnet har nogle af ændringerne ført til en bedring af driften, fx delayet på 15 sekunder inden der kalibreres, men generelt har effekten været for lille.

Vi vendte til sidst tilbage til at kigge på karakteristikken af driften over længere tid. Det bedste forslag vi har vil være at se på om man kan finde en forskrift for offset ud fra tiden og dermed opnå et dynamisk offset. Det kræver dog at offset har samme karakteristik hver gang hvilket vi ikke kan garantere ud fra de få målinger vi har på nuværende tidspuntk.


Prioritering
Set tilbage, kan det diskuteres om vi prioriterede rigtigt da vi valgte at holde fokus på drift problemet, i stedet for at bruge samme tilgang som de brugte i Marvin projektet sidste år. Vi valgte som bekendt at fortsætte med driften, og det har været nogle spændende undersøgelser så vi havde nok gjort det samme igen. Det har været et vanskeligt projekt, men vi har arbejdet seriøst med de udfordringer det har givet og vi er ikke nået frem til en robot der balancerer, men vi har været igennem en interessant og lærerig proces.

Da vi valgte at fokusere på driften havde vi heller ikke regnet med at det ville være helt så problematisk som det vidste sig at blive, at komme driften til livs. En ting vi kunne have gjort anderledes, er at vi kunne have kontaktet HiTechnic for at bede om diagrammer over hardwaren i sensoren. Det kunne måske have givet et konkret hint til hvad det skyldes og hvordan det kan løses.


Hvis vi havde 14 dage mere...
Det er først nu vi begynder at have overblik over hvor stort et problem driften er og hvor svært det er at slippe af med den. Hvis vi havde haft længere tid til projektet, er der umiddelbart to ting vi ville se nærmere på. Vi har fået lavet nogle gode målinger af driften i løbet af en halv time og det er disse målinger vi ville koncentrere os om.
Der skulle laves flere nye målinger for at se hvor ens karakteristikken for offset er ved forskellige målinger. Desuden er der meget støj på de målte værdier og det er ikke optimalt. Hvis målingerne belv filtreret så man fik tendensen frem ville det måske være muligt at finde en forskrift for værdierne så der kan kompenseres for det varierende offset alt efter hvor lang tid der er gået.


Noget andet der skal kigges på er Marvins (gruppen fra sidste år) løbende gennemsnit. Vi har forstået det som om de også er nødt til at bruge taco counteren for at undgå drift, men hvis det er nok at bruge running average er det værd at undersøge nærmere.


Vi har på baggrund af det vi er nået frem til på nuværende tidspunkt ikke nok viden til at kunne sige hvad løsningen på driftproblemet er. Der er dog forslag til noget at arbejde videre med og hvis det viser sig at det ikke kan løse problemet må man bruge taco counteren eller en anden ekstra sensor der kan give den nødvendige kompensation for driften.


Vi er dog helt sikre på at vi med nogle pålidelige værdier, nemt ville være i stand til at lave PID regulering af robotten. Det er baseret på den øvelse vi havde med at få robotten til at balancere med lyssensoren. Der havde vi nogle stabile værdier at regulere på og i dette projekt er det hvad vi har manglet.


Hvordan det vil påvirke robottens balance at køre på en skrå overflade kan vi heller ikke garantere, men da robottens set point stadigvæk skal være det samme tror vi ikke det vil skabe de store problemer. Den sidste del er at få robotten til at navigere på banen og det har vi også tidligere lavet en øvelse med så det mener vi også vi har baggrund for at få til at lykkes.


For andre der skal bruge sensoren er det værd at vide

- Hvordan karakteristikken af drift ser ud over længere tid.

- At den klipper asymmetrisk.

- Det er ikke kun forskellige gyroskoper der har forskellige driftkarakteristikker. Det spiller også ind hvilken NXT der bliver brugt. Om det skyldes batteriniveau eller A/D converter ved vi ikke.

Projektaktivitet 6

Projektaktivitet 6

Dato: 14. januar 2010
Varighed: 7 timer
Deltagere: Annette, Rasmus og Samuel

Mål
Tilbage i projektaktivitet 4 observerede vi at der blev reguleret meget kraftigt selvom robotten var tæt på set point. Det er et hængeparti som vi vil nå at undersøge inden vi afslutter projektet, fordi det ligesom driften er en forhindring for at PID tuningen kan udføres.

Fremgangsmåde / Resultater

Motornormalisering
NXT'ens motorer kan modtage en kraft mellem 0 og 100. Hvis denne kraft er for lav, er motorerne ikke stærke nok til at overvinde den indre modstand og gnidning så robotten kan bevæge sig. Derfor er der i det projekt vi har taget udgangspunkt i, lavet normalisering af motorkraften. Motorkraften kommer med denne normalisering til at ligge mellem 55 og 100. Motornormalisering giver en mere glat overgang når robotten forsøger at balancere.

Når vi forsøger med PID regulering, kan vi se at robotten reagerer meget kraftigt, selvom den er tæt på sit balancepunkt. Dette kan måske skyldes motornormaliseringen, som gør at den tilførte kraft aldrig bliver mindre end 55, selvom robotten er i balancepunktet, og motorene burde stå stille.

Motornormaliseringen fjernes derfor, så det er muligt for robotten at stå stille, når den er i balancepunktet. Det ser mere rigtigt ud nu, når robotten kommer op til balancepunktet. At der ikke er normalisering gør dog at motorerne nogle gange "staller" (går i stå), hvilket er et problem der er set ved tidligere øvelser, når motorene skifter retning hurtigt efter hinanden, med fuld kraft.

Ændring af tid mellem regulering ( løsning af stall-problemet)
For at modvirke problemet med at motorerne går i stå uden motornormalisering, sættes ventetiden i programmets control-loop op. Det bevirker at der går længere tid mellem instruktioner til motorerne så skiftene ikke sker så ofte.

Vi prøver at sætte ventetiden gradvist op (spring på ca. 50 ms. ad gangen), helt op til en ventetid på 250 ms. En ventetid der til at starte med var 50. Dette gør at motorerne ikke længere staller, men robotten er meget langsom til at reagere, hvilket vi også havde forudset.

At sætte ventetiden så langt op, mener vi derfor ikke er en løsning på motorernes pludselige stop. En ventetid på omkring 50-60 ms er det der bruges i de andre projekter, vi har set på, og også det der har fungeret bedst for os generelt.

Tråd der håndterer læsninger
Læsning fra sensoren sker kun en gang per gennemløb af control-loopet og det kan måske være for sjældent, så det resulterer i dårlige beregninger af vinklen. Derfor forsøger vi at overlade læsning fra sensoren, til en separat tråd, der kan læse meget oftere end programmets control-loop. Det betyder at der nu er tre tråde; en tråd med selve PID reguleringen, en med aflæsning fra gyrosensoren samt beregning af vinklen og en med bluetooth kommunikationen.

Tråden sættes til at læse fra sensoren (som hovedprogrammet gjorde før), og gemme det i en lokal variabel. Hovedprogrammet kan derefter læse fra denne variabel, når den har brug for det. Derved sikrer vi at læsningerne fra sensoren er up-to-date, når programmet skal bruge dem.

Afprøvning

Drift vil naturligvis stadigvæk spille ind så vi har meget kort tid til at vurdere om fjernelse af normaliseringen har fungeret. Ved afprøvning, går der et eller andet galt. Driften er allerede fra starten helt enorm. Når programmet starter efter kalibrering, står vinklen et sted mellem 30 og 45 grader, hvor den ellers brude stå på 0 grader.

Vi brugte noget tid på at finde fejlen, som viste sig at være opstået pga. problemer med versionsstyring. Der var desværre blevet brugt en version af koden hvor en if sætning i readAngle() metoden var udkommenteret i forbindelse med forsøg på at lokalisere årsagen til driften. Da den blev indført igen var problemet væk.

Der er stadigvæk problemer med at motorerne staller, men vi vil holde fast i indførslen af en tråd mere til at læse vinklen. På den måde kommer vi ikke senere i problemer hvis vi ændrer i intervallet der skal reguleres i, intervallet mellem læsninger af vinkler vil stadigvæk ske i et passende lille interval.

Man kunne godt arbejde videre med at løse stall problemet, men vi ved fra et tidligere projekt at det burde blive afhjulpet når P konstanten er indstillet ordentligt, da der ikke vil komme så store skift i kraften til motoren [6.2]. Spørgsmålet vil så være om P konstanten kan indstilles ordentligt når den staller, men det har vi ikke tid til at se nærmere på.

Konklusion
Problemet med at der reguleres for voldsomt selvom robotten er omkring sit set point er løst ved at fjerne normaliseringen. Det førte til et nyt problem med at motorerne staller ved de hurtige skift. Forsøg på at komme det nye problem til livs gik på at ændre intervallet som der reguleres i og det førte igen til et problem med at readAngle kaldene skete for sjældent så vi lagde den del ind i en ny tråd.

Det løste ikke problemet, men vi holder fast ved den nye tråd fordi det giver frihed til at justere i control delen. Løsningen på stall problemet skal ifølge en anden gruppe i stedet komme fra tuningen af P konstanten.



Kilder
[6.1] Koden med tråd der håndtere læsning: KodeMedTraad
[6.2] Balance med lyssensorer , se løsning 2

Projektaktivitet 5

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.

Figur 5.1

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.

Figur 5.2

Sidste måling er fortaget hvor kald til LCD Objektet og Thread.wait(6) er udkommenteret.
Her er gennemsnitet 5-6 ms.

Figur 5.3

Med maks 15ms går der ikke for lang tid imellem målingerne så intervallet mellem kaldene til readAngle() er ikke for stort og vi mener derfor ikke det kan være skyld i problemet.


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.4

Figur 5.5

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

Projektaktivitet 4

Projektaktivitet 4

Dato: 18. december 2009
Varighed: 7 timer
Deltagere: Annette, Rasmus og Samuel

Mål

Vi påbegynder PID reguleringen ud fra den manuelle fremgangsmåde der er beskrevet flere steder under emnet PID regulering.

Baggrundsinfo

Tuningmetoder

Kilder til baggrundsinfo er [4.1] og [4.2]. Justering af P, I og D værdierne for et system kaldes tuning. Når der ikke er en matematisk model af systemet til rådighed må parametrene bestemmes eksperimentelt.

To af metoderne vi har overvejet at bruge i vores projekt til at finde de rigtige konstanter for P, I og D leddene er manuelle online metoder. I den moderne industri bruges de manuelle tuningmetoder ikke så ofte længere. I stedet bruger man software værktøjer til tuningen. Disse værktøjer sørger for at indsamle data for systemet og udvikle modeller og på denne måde opnå de passende værdier for systemet.

Ziegler-Nichols
Blandt de manuelle tuningmetoder er Ziegler-Nichols, hvor Ki og Kd sættes til at være 0. P leddets forstærkning øges indtil kritisk forstærkning nås, med Kc, her starter oscilleringen. Efterfølgende bruges Kc og oscilleringsperioden Pc til at sætte værdierne for Kp, Ki og Kd. For PID regulering er det som i Figur 4.1.

Figur 4.1

Rent praktisk er det dog vanskeligt for os at bruge denne tuningmetode, da vi har svært ved at bestemme oscilleringsperioden.

Inden beskrivelse af den anden manuelle tuningmetode skal nogle begreber klarlægges:

- Rise time: Tiden det tager for outputtet at stige over 90% af det ønskede niveau for første gang.

- Overshoot: Hvor meget er peak niveauet højere end steady state niveauet.

- Settling time: Tiden det tager for systemet at konvergere til steady state niveauet.

- Steady state error: Forskellen mellem steady state niveauet og det ønskede output.

Manuel tuningmetode

Den anden manuelle tuningmetode er en trial and error metode med følgende fremgangsmåde:

- Kp øges indtil der opnås oscillering.

- Kp halveres.

- Efterfølgende øges Ki indtil der er et passende forhold mellem tiden og stabiliteten.

- Til sidst øges Kd, hvis det er nødvendigt så det går tilstrækkeligt hurtigt at regulere ind igen efter en forstyrrelse (skub til robotten i vores tilfælde).

For reguleringssystemer må man gå på kompromis når det gælder stabilitet og responstid. Hurtig responstid giver dårlig stabilitet og god stabilitet giver langsom responstid.

Figur 4.2 er en oversigt over hvad der sker når de tre konstanter øges.

Figur 4.2

Tabellen kan bruges til at designe en PID controller, men hver gang man laver ændringer for at opnå en ønsket karakteristik kan det påvirke andre karakteristikker på en uhensigtsmæssig måde, som det ses i tabellen.

- Kp bruges til at mindske rise time.
- Ki bruges til at fjerne steady state fejl.
- Kd bruges til at reducere overshoot og settling time.

Det er som nævnt en trial and error metode, hvilket vil sig at det kan komme til at tage lang tid at finde de rigtige konstanter. Det er dog en metode der virker som om den er mere til at gå til, end Ziegler-Nichols fordi vi her kun skal observere når robotten begynder at oscillere. Beregningerne bygger i Ziegler-Nichols metode, på nogle specifikke værdier for oscilleringen, der er udgangspunkt for beregning af de andre konstanter, hvilket gør hele processen med at finde konstanterne mere usikker.

Fremgangsmåde / resultater

Manuel indstilling af P, I og D konstanterne
Under kalibrering er det meget vigtigt at robotten står helt stille. Derfor har vi lavet en holder, som sørger for at den både står stille og er i sit balancepunkt, for det har vi brug for når den skal have sit udgangspunkt for reguleringen (set point). Se Figur 4.3. Den er lavet så forenden kan vippes ned, så robotten kan komme fri af holderen uden at den skal løftes, da det påvirker gyrosensoren.

Figur 4.3

Som udgangspunkt er P, I og D sat til 0 i programmet der downloades til robotten. Når den er kalibreret og har registreret set point sendes en ny P-værdi og først herefter begynder robotten at bevæge sig.

Koden der bruges er resultatet af projektaktivitet 3. Se [3.3] Samlet kode.

Vi forsøgte at få robotten til at balancere med værdier fundet vha. den manuelle tuningmetode. Én holdt robotten mens en anden justerede P-værdien fra en computer via Bluetooth. Der er flere udfordringer forbundet med den manuelle metode, dels er det svært at afgøre hvornår robotten oscillerer og dels vil robotten vælte i de fleste tilfælde. Derfor støttede vi robotten ved at en person greb den når den var ved at vælte.

Vi er stødt ind i et problem fordi vi oplever at set point ændrer sig når robotten bevæger sig. Det er dog ikke set point der ændrer sig, da det kun sættes én gang, under initialiseringen. Det er et symptom på det egentlige problem, som er, at funktionen readAngle() ikke fungerer helt som den skal. Det skyldes drift eller beregningen af vinklen. Pga. dette problem valgte vi at undersøge GyroSensor klassen yderligere. Vi har tidligere observeret at der har været udsving i den målte vinkel, med den samme kode.

Integralet

Vi har en mulig fejlkilde i readAngle() som returnerer vinklen ud fra en beregning af vinkelhastigheden og tiden siden sidste readAngle() kald. Vinklen beregnes på nuværende tidspunkt som en firkantet blok som vist i Figur 4.4. d_t er tiden siden sidste kald til readAngle() og den ganges med en aflæsning af den nuværende vinkelhastighed fra gyrosensoren. Det betyder at værdien er beregnet ud fra, at vinkelhastigheden med det samme stiger til det nye niveau og holdes konstant indtil den næste aflæsning. Derfor vil vi forsøge at glatte integralet ud og vi håber det kan være med til at mindske driften.

Figur 4.4

For at lave beregningen af vinklen, hvor vinkelhastigheden ikke er konstant, fjernes den del af blokken, der er over den stiplede linje vist i Figur 4.4. Der laves stadigvæk en beregning som ovenfor beskrevet, men 0,5 * (d_t * d_omega) trækkes fra. d_omega er den gamle vinkelhastighed trukket fra den nye vinkelhastighed.

Med udglatningen af vinklen implementeret i readAngle(), ser det ud til at driften mindskes en meget lille smule, så vi har besluttet at lade det blive. Den første måde at lave beregningen på, antager at vinkelhastigheden stiger, lige efter den gamle vinkelhastighed er beregnet og holder sig konstant indtil næste beregning, så det virker mest rigtigt at trække det fra.

Undersøgelse af kalibrering / optimering

Opvarmning af gyrosensoren
Vi har en teori om, at driftproblemet også kan skyldes en upræcis kalibrering. På nuværende tidspunkt bruger vi 50 samples, til at beregne et gennemsnit for offset. Ud fra dette har vi besluttet at foretage undersøgelser, om hvordan kalibreringen kan gøres mere præcis.

Vi fandt en tutorial til en balancerende robot, men i et andet programmeringssprog. Forfatteren har her erfaret at sensoren skal bruge omkring 10 sekunder til at "varme op" før læsningerne bliver stabile [4.3].

Målinger af vinkelhastigheden fra sensoren når den fikseres på holderen i en halv time, viser ikke noget specielt problem de første sekunder [4.4]. Det betyder dog ikke at det ikke kan have betydning for kalibreringen, så derfor har vi valgt at indsætte en ventetid på 15 sekunder i GyroSensor klassen inden kalibreringen startes. Dette har en god indflydelse på aflæsningerne, driften er blevet lidt mindre, den er ikke helt væk, men det var heller ikke forventet med denne justering.

[4.4] viser forløbet for driften over længere tid. Der er ingen tvivl om at jo længere tid robotten skal holde sig oprejst desto, mere vil den komme til at drifte, fordi kalibreringen foretages i starten af forløbet og vil ikke blive ændret undervejs. For at kunne tune PID værdierne og komme op ad rampen, mener vi det er nok med fire minutter uden drift og det håber vi er muligt at opnå med en god kalibrering til at starte med.

Fast offset
Vi arbejder videre med kalibreringsdelen, da driften endnu er for voldsom til at kunne regulere. Driften ser ud til at være i samme retning (negativ), og vi forsøger derfor at lægge en lille konstant til, for at opveje for denne unøjagtighed i det kalibrerede offset. Vores teori er at offsettet bliver kalibreret lidt for lavt hver gang. 0.001 lægges til offsettet der kalibreres, og driften ser ud til at være blevet betydeligt mindre.

Efter flere afprøvninger blev der på et tidspunkt kalibreret et offset som gav minimalt drift. Offsettet der blev beregnet her, sammen med konstanten, hardcodes direkte ind i programmet, for at se om det vil hjælpe at bruge et fast offset i stedet for at kalibrere hver gang, og dette afprøves ad flere omgange.

Af tre forsøg, ser driften ud til at blive bedre, dog er det varierende hvor lidt drift der er tilbage. Dette kan være fordi offsettet er forskelligt fra gang til gang, og derfor ikke kan hardcodes. Men når offsettet er "rigtigt" er driften stort set væk.

Forbedring af kalibrering

For at finde et mere præcist offset, vil vi forsøge at have flere målinger med i beregningen af gennemsnittet, der udgør offsettet. Tidligere har vi prøvet forskellige værdier mellem 50 og 750, men vil nu forsøge med nogle langt højere værdier. Under følgende målinger lægges konstanten 0.001 ikke til.

Målinger – 2000: Her viser der sig stadig samme drift.
Målinger – 4000: Drift virker reduceret.
Målinger – 8000: Drift er samme som ved 4000, og i nogle tilfælde bedre (mindre drift).
Vi forsøger også at bevæge enheden, op til 90 grader, og tilbage til udgangspunktet. Her ses kun lidt drift, og den viser 0 grader når den bevæges tilbage til udgangspunktet sm det er ønsket.
Målinger – 10.000: Drift er lav, men varierer lidt.
Målinger – 20.000: Efter 4 minuter er drift kun oppe på 1.5 grader.
Målinger – 20.000: Efter 2 minutter er drift kun på 1.6 grader.
Målinger – 25.000: Efter hhv. 2 og 3 minuter, kommer drift op på 2 grader.
Målinger – 50.000: Efter flere tests mellem 1 og 4 minuter, kom drift max op på 2.5. Holdt sig generelt omkring 1. Efter at være bevæget 180 grader og efterfølgende tilbage til udgangspunktet er udlæsningen 0 grader som ønsket.
Målinger – 100.000: Efter få minutter, kom drift op over 6 grader, og der var generel forværring i alle tests.
Målinger – 50.000: Denne gang stiger drift hurtigere, end sidst der blev testet ved samme antal målinger.

Ved at sætte antallet af målinger op til 50.000 som netop beskrevet ser vi at der er mindre drift. Det er dog lidt forskelligt hvor godt der kompenseres fra gang til gang så der er stadigvæk problemer og det kigger vi på i det følgende.

Kompensation for drift ved stilstand

Når robotten står stille, burde vinkelhastigheden være 0. Da vi har drift, kan vi se at dette ikke er tilfældet. For at undgå at der er drift mens robotten står stille, vil vi lave et interval for vinkelhastigheden, som ikke skal regnes med. Når den står og vipper omkring 0 (Altså den fejl sensoren laver når den står stille), skal dette i stedet tolkes som 0.

For at gøre dette, tilføjes en beregning til readAngle(). Hvis rawvalue minus offset er mellem 1 og -1, skal 0 returneres.

Der foretages målinger hvor dette er implementeret:

Målinger – 50.000: Efter 4 minutter, stillestående, er drift kun på 0.52 grader.
Målinger – 50.000: (-1 og 1 skiftes ud med -0.75 og 0.75) Efter kort tid er drift oppe på 3 igen.
Målinger – 650: (-1 og 1 bruges igen) Stillestående i 4 minuter er drift på 0.03. Ved bevægelse stiger drift.
Målinger – 50.000: (-1 og 1) Stillestående næsten ingen drift, men efter at have bevæget robotten frem og tilbage er drift kun på 1.5 grader.
Målinger – 650: (-1 og 1) Stillestående næsten ingen drift, men efter nogenlunde samme bevægelser, er drift oppe på 6 grader.

Vi holder fast i en kalibrering med 50.000 samples og -1 og 1. Det ser ud til at give det bedste resultat. Målingerne er udført med et GyroTest program, og sættes nu ind i det samlede program med PID regulering og bluetooth.

Her udføres stillestående tests, hvor drift holdt sig under 0.03. Ved bevægelse er drift dog betydeligt større, så der er stadigvæk problemer.

Tiden

Vi undersøgte kort om det har noget med tiden imellem målingerne at gøre, altså den tid programmet venter i slutningen af control-lykken. Den er betydeligt længere, end i GyroTest programmet. Vi afprøver både højere ventetid, og lavere ventetid, end i GyroTest programmet. Drift lader ikke til at være påvirket af om der er længere tid mellem målingerne eller kortere tid mellem målingerne, i forhold til den tid der var brugt i GyroTest programmet, men det vil vi undersøge nærmere i næste projektaktivitet.

Integralberegningen

Som et sidste forsøg fjernede vi udglatningen af integralberegningen, og dette så ud til at fjerne en del af driftet. Det har altså ikke haft den ønskede hensigt selvom det allerførst så ud til at virke. Men det er heller ikke første gang at noget vi har troet virkede ikke har virket alligevel.

Note

I denne projektaktivitet har vi observeret hvordan robotten regulerer kraftigt selvom den er tæt på set point. Det skyldes muligvis motornormaliseringen, så det skal vi have undersøgt i en kommende projektaktivitet.

Konklusion

Det viste sig at udgangspunktet for at kunne begynde at bestemme PID konstanterne var for dårligt. Vi oplevede igen at driften var for voldsom, selvom vi i sidste projektaktivitet troede det var så lidt at det ikke ville blive et problem. Vi er derfor ikke kommet nogen vegne med selve PID controller tuningen, og projektaktivitet 5 kommer også til at omhandle drift. Her vil vi allerførst vende tilbage til at se på tiden mellem læsningerne af vinkelhastigheden fra sensorerne.

I forhold til vores egentlige mål, som er at få robotten til at balancere op ad Alishan Train Track, er der stadigvæk lang vej endnu. Vi har i gruppen diskuteret om vi skal bruge koden fra Marvin projektet sidste år, og fokusere på de problemstillinger der er ved banen i stedet for, eller om vi skal fortsætte vores undersøgelser af selve sensoren. I projektet fra sidste år har de omgået problemet ved bl.a. at bruge taco counteren, men vi er opsatte på at se om vi kan få noget ud af gyrosensoren alene. Prioriteringen er altså at undersøge driften.

Referencer
[4.1] Kilde: http://techteach.no/publications/books/dynamics_and_control/tuning_pid_controller.pdf
[4.2] Kilde: http://saba.kntu.ac.ir/eecd/pcl/download/PIDtutorial.pdf
[4.3] Kilde: http://www.hempeldesigngroup.com/lego/pbLua/tutorial/pbLuaGyro.html
[4.4] Offset: 4.4 Offset

Projektaktivitet 3

Projektaktivitet 3

Dato: 17. december 2009
Varighed: 7 timer
Deltagere: Annette, Rasmus og Samuel

Mål

GyroSensorkoden er klar til at blive brugt i forbindelse med at robotten skal holdes oprejst, så der skal laves et projekt hvor der kan reguleres ud fra værdier fra GyroSensorkoden. Dette skal efterfølgende kombinereres med bluetoothkoden, hvor regulering og bluetooth hver bliver en selvstændig tråd. Arbejdet med at få robotten til at balancere påbegyndes muligvis.

Baggrundsinfo
PID er et lukket sløjfe reguleringssystem. PID controlleren beregner en fejlværdi mellem den målte værdi (procesvariablen) og en ønsket værdi (set point) og ud fra det prøver den at regulere. Se yderligere om PID regulering her: PID regulering.

Fremgangsmåde

Segway med gyrosensorkoden

Udgangspunktet for at få robotten til at balancere bliver klassen Segway fra øvelse 4 [3.1]. Segway er den klasse som håndterer selve PID reguleringen. Den blev brugt i forsøg på at få robotten til at balancere vha. lyssensorer, så den skrives om til at bruge GyroSensor klassen i stedet for.

Segway klassen arver fra Thread Klassen og i constructoren til Segway oprettes en instans af GyroSensor klassen. En anden metode i Segway er getBalancePos() som sørger for at kalibrere offset ved at kalde calibrateOffset() metoden på GyroSensor. Efterfølgende aflæses setPoint vinklen som er udgangspunkt for reguleringen af robotten. run() metoden indeholder koden til reguleringen, som vil være på baggrund af værdier fra GyroSensor klassens getAngle() metode.

Reguleringen vil blive beskrevet senere. Derudover består projektet af DataLogger klassen så vi har mulighed for at analysere opsamlet data under arbejdet med PID kontrollen. Testen udføres fra BalanceTest klassen.

Bluetoothdelen

SegWayPCGUI klassen, viser et grafisk interface på PC'en, hvor der kan skrives værdier ind for P, I og D, som kan sendes individuelt. Den opretter forbindelse til NXT enhedens BluetoothThread klasse (som skal være startet først). Værdierne der bliver sendt fra PC'en er 4 cifrede, så der laves en omregning i BluetoothThread klassen, der kan indstilles individuelt for P, I eller D, alt efter hvor store eller små tal der skal bruges.

Når der modtages en værdi i BluetoothThread, kalder den den passende set-metode i SegWay klassen, så værdierne kan bruges. Værdierne starter alle på 0, når enheden startes. Kraften til motoren i SegWay, er normaliseret mellem 55 og 100, hvilket vil sige at den bevæger sig selvom P, I og D er 0. Derfor sættes en if sætning ind, der sætter motor power til 0, hvis P er 0. Så begynder robotten først at køre, når den får en P værdi tilsendt.

Resultater

Segway med gyrosensorkoden

Det har ikke voldt problemer at implementere PID reguleringskoden fra øvelse 4 i en test med vores egen GyroSensor klasse og DataLogger klassen.

Bluetooth delen

Arbejdet med undersøgelserne af gyroskopet er foregået vha. USB kablet på en anden NXTenhed end den der er brugt til arbejdet med Bluetooth kommunikationen. Det viser sig nu at der er problemer med Bluetooth kommunikationen på NXT’en hvor gyroskopet er blevet undersøgt, så vi har besluttet at bruge den, hvor vi ved Bluetooth virker.

Her viser det sig dog at der sker noget interessant med driften, for den er her langt mindre selvom vi kun skifter NXT og ikke selve sensoren. En anden ting der også undrer os er at offset er ændret fra før 596 til nu ca. 591. Så vidt vi har kunnet forstå skyldes drift hardwaren i selve sensoren, men denne opdagelse tyder på at også hardwaren i NXT'en har indflydelse.

Vi har ikke tid til at undersøge dette nærmere, men vi har en formodning om at det kan være A/D konverteren eller måske batteriniveauet der spiller ind.

Den samlede kode med GyroSensor, regulering og Bluetooth kan ses i [3.2] Samlet kode.

Konklusion

Samlingen af koden er gået fint, så vi er nu klar til at finde værdier for PID reguleringen. Bluetooth kommunikationen er implementeret så vi kan sende værdier til robotten. Det gør det nemmere fordi vi så ikke skal ændre i koden, compile og downloade til robotten, hver gang vi ændrer en af P, I, D værdierne.

Vores oplevelse med at det har betydning hvilken NXT der bruges og ikke kun hvilken sensor der bruges undrer os stadigvæk, men vi har valgt at lade det ligge.

I næste projektaktivitet skal interfacet på PC'en bruges til at tune PID konstanterne.

Referencer
[3.1] Øvelse 4: Øvelse 4.
[3.2] Samlet kode: Endelig-Kode

PID regulering

PID Algoritmen og Lukket-sløjfe-styring

Lukket-sløjfe-styring og feedback

Lukket-sløjfe-styring eller automatisk styring, er en kontrol teknik som er baseret på såkaldt negativ tilbagekobling ( feedback).

Et velkendt eksempel på ukontrolleret, positiv feedback findes hos elektronisk udstyr, der kan begynde at hyle. Det sker i højttalersystemet, hvis lyden fra højttaleren når mikrofonen, hvor den bliver forstærket af systemet og returnerer dertil med endnu større styrke. Ved et enkelt gennemløb af sløjfen er denne virkning ikke til at høre, men den bliver alvorlig, når signalet passerer gennem systemet igen og igen.

Lukket-sløjfe-styring består grundlæggende af 3 elementer, Controller, system (plant) og Sensor, som konstant prøver at give et ønsket system output ud fra en givet reference.

Figur 1

Sensoren måler system output (også kaldet procesvariablen) og fejlen (Measured error) beregnes ved at trække den målte værdi fra referencen (negativ feedback). Controlleren beregner så et nyt system output som sendes til systemet, som så reagerer på det og loopet begynder forfra.


PID regulering
I vores projekt bruger vi en PID (proportional–integral–derivative) regulerings algoritme til at styre vores lukkede sløjfe, dvs. som controller (se figur 1). PID regulering er en form for kontrolalgoritme der er meget udbredt inden for industrien og som benyttes lukket-sløjfe-styringer. PID-algoritmen er baseret på 3 parametre, proportional (Kp), integral (Ki) og differential (Kd).

Figur 2

PID algoritmen ser ud som vist på figur 2. I forhold til figur 1 svarer "input" til "system input" og "error" til "measured error".

Projektaktivitet 2

Projektaktivitet 2

Dato: 11. december 2009
Varighed: 7 timer
Deltagere: Annette, Rasmus og Samuel

Mål

Færdiggøre undersøgelser af gyroskopet og lave et grafisk program til PC'en, der kan sende parametre til NXT enheden løbende over Bluetooth.

Fremgangsmåde
GUI program til Bluetooth kommunikation.
Da problemerne med kommunikation mellem PC og NXT blev løst i sidste projektaktivitet, er det nu kun nødvendigt at bestemme formatet af kommunikationen og lave den grafiske brugergrænseflade.

Undersøgelse af gyroskop
Gyrosensor
Til undersøgelserne af gyroskopet laves et LeJOS NXJ projekt som indeholder tre klasser, en testklasse, en GyroSensor klasse og en DataLogger klasse. Testklassen varierer afhængigt af om vi ønsker at læse fx vinkelhastighed eller vinkel, DataLogger klassen er skrevet af Ole Caprani, og opretter en .txt fil, hvortil man kan skrive integers.

GyroSensor klassen
Lejos har en GyroSensor klasse under lejos.nxt.addon som i constructoren tilknytter en medsendt port til sensoren, og i hvilken mode den skal fungere. Når sensoren holdes fast i en stilling returnerer den værdier der i vores tilfælde ligger på omkring 596, det er sensorens offset og kan sættes i GyroSensor klassen.
readValue() metoden i GyroSensor klassen læser den rå værdi fra porten (A/D converteren) med ADSensorport.readRawValue() metoden og som tidligere beskrevet returneres en værdi fra sensoren der svarer til grader/sekund. I readValue() metoden fratrækkes offset værdien så vinklen har nul som udgangspunkt.

getAngle metoden
Det er dog ikke vinkelhastigheden vi har brug for til vores projekt hvor robotten selv skal kunne balancere. Her har vi brug for en angivelse af position i stedet for. Derfor må vi tilføje en metode getAngle() der returnerer vinklen beregnet ud fra vinkelhastigheden. Beregningen udføres som vist i Figur 2.1.

Figur 2.1

Implementationen er som vist i Figur 2.2. Det er nødvendigt at kende tiden, så derfor kaldes metoden System.currentTimeMillis() som returnerer tiden i millisekunder siden NXT'en blev startet. Derefter beregnes dt som er den nye tid minus den gamle og efterfølgende beregnes den nuværende vinkel ud fra den gamle vinkel, sensorværdien og dt.

Figur 2.2

Nu er vi klar til at lave nogle forskellige undersøgelser, som først vil dreje sig om at finde ud af hvordan sensoren måler vinklen, og efterfølgende vil det dreje sig om drift, som vi ved er et problem med sensoren.

Undersøgelse 1: Vinkel
Den første undersøgelse skal vise om sensoren fungerer, som beskrevet af HiTechnic og om den tilføjede metode getAngle() returnerer vinklen som den skal. Det gælder altså her om at få en fornemmelse af hvordan sensoren fungerer. Offset angives i koden til at være 596.

Undersøgelse 2: Vinkelhastighed
Vinkelhastigheden undersøges, ved at bruge GyroSensor klassen med offset sat til 0. Sensoren fastgøres i en opstilling som vist på Figur 2.3 så den ikke bevæger sig. Værdierne fra sensoren burde så være stabile, men vil sandsynligvis stå at skifte lidt (drift).

Figur 2.3

Værdierne fra sensoren opsamles i en datafil der efterfølgende overføres til en PC og undersøges i Mathcad.


Undersøgelse 3: Vinkel
For at undersøge vinklen sættes offset til 596 da det er ca. der NXT’ens offset ligger. Det er den samme opstilling der bruges for at holde sensoren stille. Her bruges vores egen getAngle() metode til at returnere vinklen og igen burde værdierne være stabile fordi sensoren ikke bevæger sig. Værdierne opsamles også her i en datafil der undersøges i Mathcad.


Undersøgelse 4: Kompensation for drift
Da det ikke er et dyrt gyroskop må vi forvente at der kan forekomme drift. Det kommer til udtryk ved at der returneres en vinkelhastighed fra A/D konverteren selvom sensoren ikke bevæger sig. Offset ændrer sig altså en smule, som vi også så i undersøgelse 2. For at finde et nøjagtigt offset har vi derfor lavet en kalibreringsmetode, i klassen gyroSensor, som kaldes for at kalibrere offset. Metoden kalder readRawValue() metoden et antal gange og tager et gennemsnit af det antal samples den tager. For at få et mere nøjagtigt resultat bruger vi double-præcision.

Beregningen af offsettet sker ved at vi tager 50000 samples og tager gennemsnittet af disse samples. Dette gøres reelt to gange i træk.

Til at finde ud af om kompensationen har den ønskede virkning bruges den samme opstilling som i de to foregående undersøgelser. Ved hjælp af getAngle() metoden hentes værdier for vinklen som skrives til en datafil. Forventningen er så at driften vil være stærkt reduceret i forhold til de tidligere målinger.

Resultater

GUI program til Bluetooth kommunikation.
Overførsel af data:
Kommunikationen mellem PC og bluetooth enhed, foregår ved at der bliver sendt en stream af data. Der kan sendes bytes, Integers, Chars og andre typer, men der kan kun læses én ad gangen hos modtageren. Samtidig kan der kun sendes via én stream ad gangen, så alt data skal overføres via denne ene stream.
Da der skal sendes 3 forskellige parametre på vilkårlige tidspunkter, skal det besluttes hvordan disse data skal sendes og opfattes. Værdierne der skal modtages, skal i sidste ende være doubles, altså kommatal, som NXT'en bruger som parametre i sin PID kontrol. Der kan ikke sendes doubles over streamen, da der kun kan læses "enkelte tegn" i den anden ende.

For at kunne kende forskel på de forskellige parametre der sendes, sendes data som chars. Hvis der skal sendes en P parameter, sendes der et lille p, efterfulgt af de tal der er parametren: "p001". Dette betyder at der sendes 4 chars, for at få et tal på 3 tegn.

For at forstå de tegn der sendes over streamen, skal modtageren laves rigtigt. Da der i et tidligere SegWay projekt blev brugt PID regulering, med double værdier, bruges denne type også her. I det tidligere projekt, havde parametrene 2 decimaler, hvilket er grunden til at der i dette program sendes 3 chars.
Når Nxt programmet modtager de 4 chars fra PC programmet, tjekker den det første tegn og ser om det er et p, i eller d. Hvis ikke det er en af de tre, prøver den det næste tegn.
Hvis det er et af de tre tegn, sætter den de næste 3 chars i streamen, sammen til en string. Denne string bliver omfortolket til en integer. Denne integer bliver så lavet om til en double, og kommaet rykkes 2 pladser til venstre. For eksempel bliver strengen 001 til tallet 1 og strengen 101 til tallet 101. Derefter ganges dette tal med 0.01, så det i stedet bliver til et kommatal som følgende eksempler: (String - Int - Double)
(001 - 1 - 0.01), (101 - 101 - 1.01) og (021 - 21- 0.21).
Fordi der tjekkes på om det første tegn er p, i eller d, gemmes dette tal i den respektive variabel, som programmet så bruger til PID regulering.

Den grafiske brugergrænseflade:
Interfacet der skal bruges til at sende PID parametrene til NXT'en er ikke særligt kompleks. Der er 3 knapper, med tilsværende tekstfelter hvori tallene der skal sendes, skrives ind. Der laves også et større tekstområde, hvor der udskrives feedback på, om der sker fejl og om parametrene faktisk bliver sendt.


Den grafiske del er lavet ud fra et simpelt eksempel om JButtons i java, som er tilpasset til ovenstående formål. Derefter bliver der oprettet en instans af det program der står for kommunikationen med bluetooth enheden, "BTconnector" (som er indeholdt i samme fil). Hver gang der trykkes på en knap, tager programmet strengen i det tilhørende tekstfelt (og sætter hhv. p, i eller d foran) og sender videre til BTconnectoren. Derefter sendes strengen over den oprettede bluetooth forbindelse, som BTconnector sørger for at oprette.

Undersøgelse af gyroskop
Undersøgelse 1: Vinkel
Når sensoren holdes i en fast lodret position returneres en vinkel på 0 grader og når den vippes med uret returneres en positiv værdi for vinklen og mod uret en negativ værdi for vinklen. Selve udlæsningerne af vinklen ser også ud til at passe godt med det forventede, hvis udgangspunktet er at sensoren er i lodret position og den bliver roteret med uret til vandret position (efter øjemål) udlæses en værdi på 45 grader. Hvis man roterer videre med uret til lodret på hovedet udlæses 90 grader. Tilsvarende ser udlæsningerne ud til at passe hvis den roteres mod uret


Undersøgelse 2: Vinkelhastighed
Der er opsamlet værdier for vinkelhastigheden for sensoren når den er stationær og værdierne er plottet ind i grafer der kan ses i [2.1]. Der er lavet målinger over tre gange og de viser alle at vinkelhastigheden varierer mellem 694 og 696 og ved enkelte målinger helt ned til 593 og op til 598. Målingerne viser altså at der returneres en vinkelhastighed selvom sensoren er fikseret og derfor ikke bevæger sig. Testkoden kan ses under [2.2] VelocityDriftTest projektet.


Undersøgelse 3: Vinkel
Der er opsamlet værdier for vinklen af sensoren når sensoren er stationær og værdierne er plottet ind i grafer i [2.1]. Også her er der lavet målinger tre gange og de viser at ved et offset på 296, sker driften i negativ retning. Det er varierende hvor hurtigt det går, men det er en ret voldsom drift. Testkoden kan ses under [2.3] AngleDriftTest projektet.

Undersøgelse 4: Kompensation for drift
Der er lavet tre målinger på vinklen når der kompenseres for drift, en grafisk fremstilling kan ses i Mathcad dokumentet i [2.1]. Med offset kalibreret til 596.032426458401 fås en negativ drift, på to grader i løbet af lidt mere end 20000 samples hvilket er en stor forbedring hvis man sammenligner med målingerne hvor der ikke kompenseres.
Med offset kalibreret til 595.99829648078 fås en positiv drift på to grader i løbet af lidt mindre end 20000 samples. Den sidste kalibrering er på 595.976274831896 og giver en positiv drift på seks grader i løbet af lidt mindre end 20000 samples, men det er også en noget lavere offset værdi så det er forventet. Det rigtige offset må ligge mellem 596.032426458401 og 595.99829648078, da det ene giver negativ drift og det andet giver positiv drift. Testkoden kan ses under [2.4] DriftCompensation projektet.

Konklusion

Undersøgelserne af gyroskopet er afsluttet. Der er ret voldsom drift, men der kan kompenseres for det i en sådan grad, at vi håber at det ikke bliver et problem i det videre arbejde.

Vi synes vi har et godt udgangspunkt til at få robotten til at balancere nu hvor vi kan beregne en vinkel ud fra den målte vinkelhastighed fra sensoren og vi kan sende værdier vha. Bluetooth mellem en PC og NXT'en.

I projektaktivitet 3 skal GyroSensor klassen og bluetooth klassen kombineres i et program og vi begynder muligvis at kigge på PID reguleringen.

Referencer
Java eksempel GUI er bygget over: ButtonDemo.java
BTconnector uden GUI: BTconnector.java
Samlet GUI program: SegWayPcGUI.java (Indeholder også BTconnector)
BT klient program på Nxt: BluetoothUnit.java
[2.1] Drift Test: Drift.pdf
[2.2] VelocityDrift projektet: VelocityDrift.rar
[2.3] AngleDrift projektet: AngleDrift.rar
[2.4] DriftCompensation projektet: DriftCompensation.rar