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