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