Projekt - 6

Dato:
18-01-2010

Antal timer brugt:
8 timer

Deltagende personer:
Kim Munk Petersen, Andreas Koefoed-Hansen og Tim Rasmussen

Målet:

1. Ryde op i koden
2. Udbedre ujævn kørsel
   
1. Vil fjerne sinus kode.
2. Modificere PID værdierne
3. Regulere speed til motorerne bedre

Planen:
Vi vil starte med at få ryddet op i koden, således alt det kode vi ikke gør brug af bliver fjernet. Samtidig vil vi gennemgå koden for at se om der er ting der kan laves smartere. En af de ting der har irriteret os en smule når vi har kørt rundt med Legwayen er at dens hastighed svinger op og ned. Vi har en idé om at det er setPower() i MotorController der er skyld i at hastigheden svinger, eftersom den lægger en sinus værdi til hastigheden. Vi vil derfor for at fjerne den ujævne kørsel, prøve at fjerne koden der modificerer motorPower med en sinus værdi. Vi kunne forstille os at fjernelsen af sinus værdierne, kan medvirke at robotten bliver mere ustabil og vi derfor er nødt til at se på værdierne anvendt i PID Controllren. Derfor vil vi gennemføre endnu en test af disse og ændre på PID controllerens værdier så de kommer til at passe.

Processen:
Efter at have ændret rigtigt meget i koden, var der efterhånden opstået en hel del kode som vi ikke længere gjorde brug af. Et eksempel på noget kode der skulle fjerens, er måden hvornår bluetooth forbindelsen oprettes. Dette blev før gjort ved at der blev lavet en

BTConnection conn = Bluetooth.waitForConnection();

direkte i main metoden, hvorefter conn blev sendt videre til BTCommandReader. Det objekt af BTCommandReader blev herefter send videre til BTDriver sammen med ctrlParam. Efter at vi har ændret vores BTDriver til at håndtere hele opsætningen af Bluetooth i forbindelse med BTCommandReaderen, var der en helt del kode i main metoden der skulle fjernes. Dette kode fik vi fjernet sammen med alt andet død kode.

Legwayens kørsel er meget ujævn når den kører frem eller tilbage. Den starter med accelerere op til en vis hastighed hvorefter den decelererer indtil robotten kommer nær tilstand hvorefter den igen accelerer. Eftersom hastigheden svinger meget lignende en sinus kurve, var vores ide at grunden til den svingende hastighed skyldes den sinus værdi der lægges til motorhastigheden i setPower metoden.

Næste mål med at fjerne sinus-koden var ligetil. Vi udkommenterede koden der er placeret i MotorController klassen og compilede og uploade ændringerne. Resultatet af dette var at når Legwayen skulle stå stille og balancere, overshootede den mere en før og bevægede sig derved mere frem og tilbage. Ligeledes medførte ændringer ikke nogen forbedringer på den ujævne hastighed når vi kørte Legwayen frem og tilbage.
Vi prøvede også at ændre på nogle af de kontanter der bliver brugt i forbindelse med sinus-reguleringen:

private final double sin_speed = 0.1;
private final double sin_amp = 20.0; 

Dette gav ikke noget bedre resultat og vi besluttede os for at gå tilbage til den originale kode.

For at komme med et nyt bud på årsagen til den ujævne kørsel så vi på hvordan Legwayen håndterer frem og tilbage kommandoer. Når Legwayen bevæger sig frem eller tilbage sker det er det ved at give BalanceController klassen en tiltAngle der lægges til den angle der bliver hentet fra GyroscopeSensor klassen hvorved Legwayen "tror" den er ude af balance og derved vil prøve at korrigere for dette. Dette bliver gjort ved at ændre på den CtrlParam der bliver giver med til BalanceControllerens contructor.

CtrlParam har metoder til at sætte forskellige variabler som damp og driveState. Damp variablen bestemmer hvor hurtigt robotten skal accelerer mens driveState kan enten være stationary, forward eller backward. TiltAngle bliver beregnet ud fra de to variabler ved følgende formel

tiltAngle = maxForwardSpeed - maxForwardSpeed * Math.exp(-damp));

tiltAngle bliver beregnet hver gang runDriveState() metoden bliver kaldt og efter den er beregnet bliver damp talt lidt op.

Grafen herunder viser hvordan tiltAngle bliver sat efterhånden som damp bliver talt op.

Som det ses fra grafen giver dette en blød ændring i tiltAngle over tid. Dette gøres for at Legwayen skal kunne holde balancen under accelerationen. Hvad er så grundet til at Legwayen stopper op efter den har kørt et stykke tid? Ud fra grafen ses det at tiltAngle forbliver den samme efter accelerationen, så ret intuitivt skulle robotten blive ved med at køre frem med samme hastighed. Grunden til at dette ikke er tilfældet, er at integral ledet i PID controlleren[1]. Efter noget tid vil error-værdien bliver normaliseret da integral ledet gør at robotten "vænner" sig til den nye tilt.

Vi prøvede at ændre den måde hvorpå tiltAngle beregnes, således tiltAnglen nu kun afhang af damp værdien. Dette betød at tiltAnglen blev talt så hurtigt op at Legwayen accelererede eller decelererede så hurtigt at at den væltede. Grunden til at den vælter skyldes at integral ledet i PID controlleren ikke kan følge med til at kompensere for den store tiltAngle og derved vælter robotten når tiltAngle bliver for stor.Vi kunne have lavet et loft for hvor meget tiltAngle må tælles op, men ved at gøre dette vil vi blot være tilbage til udgangspunktet hvor hastigheden svinger op og ned. 

Vi ændrede derfor på hvor meget damp blev talt op hver gang og med den måde at bregne tiltAngle på nåede vi frem til en optimale værdi på 0.07. Efter at have fundet frem til denne værdi, står robotten stadig og overshooter mere end den gjorde ved den oprindelige måde at beregne tiltAngle på. Grunden til dette skal findes i at den accelerere hurtigt op og derved kommer over balancepunktet hvorfor den skal til at køre modsat vej for at kompensere for dette. Vi forsøgte at løse problemet med at den overshooter ved at skrue ned for ki variablen, så integralet ikke betød så meget i error-beregningen, men uden held.

Selv om vi nu have løst problemet med hastigheden, så valgte vi alligevel at vende tilbage til den anden måde at beregne tiltAngle på. Grunden til dette skyldes at Legwayens balanceringsevne. Den overshooter simpelthen for meget og det lykkes os ikke at finde nye værdier til PID controlleren der kunne kompensere for den overshoot der sker.

Vi ændrede PID controllerens parametre tilbage til de originale da det gav den bedste balance evne.

En ting vi gjorde der hjalp på kørslen var at udskifte den ene motor på Legwayen. Førhen kørte Legwayen skævt fordi den ene motor ikke var så kraftig som den anden. Efter denne ændring fik vi en bedre balance og den blev lettere at styre. Vi kunne også have kompenceret for den svage motor i koden, men jo kraftigere motorerne er, jo mere kraft har Legwayen til rådighed hvilket giver mulighed for bedre balanceevne.

Konklusion:
Vi fandt ud af at vores første tanke om at det var setPower() metoden der tilføjede en sinus værdi til hastigheden ikke var skyld i Legwayens svingende hastighed. Vi fandt frem til at svingningerne i stedet skyldes måden hvorpå tiltAngle blev beregnet i runDriveState samt den måde hvorpå PID controller prøver at kompensere for tiltAnglen. Vi prøve at ændre på den måde hvorpå runDriveState beregner tiltAnglen, således den nu kun afhænger af damp. Dette hjalp på problemet med den svingende hastighed, men gav i stedet nye problemer i form af for hurtig acceleration eller for høj hastighed. Begge tilfælde gjorde at Legwayen væltede. Vi prøve derfor at ændre på ki, for at se om vægtning af int_error (integralet af error) have en betydning for svingningerne. Det viste sig at dette gjorde Legwayen så ustabil at vi ikke rigtig kunne konkludere noget på dette.

Vi vil måske senere få tid til at arbejde videre på dette problem, men vores næste mål vil være at få udvidet funktionaliteten ved at tilføje en ny behavior i form af en LineFollower.


Referencer:

1. PID Control.Chapter 5, pp. 179-190 of Fred G. Martin, Robotic Explorations: A Hands-on Introduction to Engineering, Prentice Hall, 2001.