Tid: 9 timer, Deltagere: Kenneth, Rawad.
Siden sidst:
Intet at bemærke.
Formål:
Formålet med denne lab session er at få robotten til at balancere. Dette vil vi opnå ved at analysere koden så vi kan få en forståelse af hvordan segwayen kan gøres bedre.
Plan
- Analyse af HTWay
- Forbedring af HTWay kode
- Bluetooth remote control
- Opponent robot design
- Konklusion
1. Analyse af HTWay
HTWay programmet består af to parallele funktioner, den ene holder robotten stående på to hjul mens den prøver at holder sig tæt på det oprindelige nulpunkt for motorenes tacho værdier. Den anden funktion modtager instruktioner fra infrarød modtageren som fjernstyres og ændre på nulpunktet for de enkelte motorer så robotten bevæger sig.
Funktionen der holder robotten stående hedder taskBalance og virker ved 4 inputs gyroSpeed, gyroAngle, motorPos og motorSpeed. Robottens nuværende hældning og hældnings ændring repræsenteres af henholdsvis gyroAngle og gyroSpeed som beregnes udfra sensor input fra gyroskopet.
Vinkel ændring pr. sekund, som er inputtet fra gyroskopet er den samme information som ligger i gyroSpeed og det er derfor nærliggende at tro at disse skulle være de samme. Dog fandt vi ud af i sidste lab session[2] at gyroskopets nulpunkt drifter og derfor er det nødvendigt at tage højde for dette når gyroSpeed skal beregnes. Dette drift tager robotten højde for ved at lave et “Exponential Moving Average” som gør at alle værdier målt på gyroskopet bidrager til et gennemsnit der bestemmer hvad nulpunktet for gyroskopet er.
Robottens hældning, gyroAngle, bliver herefter beregnet udfra den faktiske vinkelhastighed, gyroSpeed og tidsintervallet siden sidste måling.
Motorenes position beregnes som en sum af de to motores tacho værdier mens robottens hastighed, motorSpeed beregnes som et gennemsnit af de sidste 4 ændringer i motorposition.
taskBalance holder robotten balancerende ved at kobinere disse input i følgende udregning af motor outputtet:
power = (KGYROSPEED * gyroSpeed +
KGYROANGLE * gyroAngle) / ratioWheel +
KPOS * motorPos +
KDRIVE * motorControlDrive +
KSPEED * motorSpeed;
KGYROANGLE * gyroAngle) / ratioWheel +
KPOS * motorPos +
KDRIVE * motorControlDrive +
KSPEED * motorSpeed;
Gyrospeed, gyroAngle, motorSpeed og motorPos bliver ganget med deres respektive konstanter. Input fra gyroskoppet bliver derudover også korrigeret ift. den hjulstørrelse der sidder på robotten. Grunden til at dette er nødvendigt er at de store hjul bevæger sig længere på den samme power. MotorPos og motorSpeed er selv korrigerende overfor dette da en afvigelse i afstand på f.eks. 5 cm resulterer i en mindre afvigelse i tacho ved brug af de store hjul end ved brug af de små.
Parameteren motorControlDrive er den ændring der bliver påført motorPos af den parallelt eksekverende funktion taskControl. Denne værdi indgår i funktionen fordi den forbedre robottens start og stop sekvenser. Når roboten sætter igang får denne variabel robotten til at køre kortvarigt den modsatte vej så den hurtigere kan få fart på. Samtidig får den robotten til kortvarigt at køre hurtigere når robotten skal stoppe.
2. Forbedring af HTWay kode
Det havde vist sig i sidste lab session at robotten ikke kunne balancere særlig længe med de store hjul[2]. Derfor prøvede vi at montere de små hjul for at se om det uændrede HTWay kode kunne balancere bedre med disse. Som det fremgår af videoen herunder balancerede robotten bedre med de små hjul.
Dog oscillerede robotten omkring nulpunktet for hurtigt til at vi fandt det acceptabelt. For få at indsigt i hvordan de forskellige værdier ændrede sig når robotten prøvede vi at logge dem i en fil i balance loopet[4]. Dette resulterede dog i at loopets cycle tid blev forlænget så robotten ikke længere kunne stå. Ved at forkorte mængden af tekst der blev logget kunne tiden bringes ned til ca. 5 ms pr. logging hvilket var indenfor de 8 ms som loopet var beregnet til at tage. Dog svingede tiden det tog at logge så meget, at det nogen gange tog 12-14 ms at logge[5]. Hvilket fik os til at droppe at logge værdierne i programmet og istedet prøve at forbedre robotten udfra dens visuelt synlige opførsel.
Ved at sænke konstanten for hjul størrelsen gjorde vi gyroAngle og gyroSpeed mere signifikante i power beregningen vist i afsnit 1. Dette resulterede i at robotten reagerede mere skarpt hvilket betød at den balancerede bedre. I videoen herunder har vi fundet et kritisk punkt for hjulstørrelses konstanten, robotten reagere for hurtigt hvilket resultere i at NXT’en slukker for motorportene. Dette karakteristika blev beskevet af Ole Caprani i lektion 3 d. 16-02-12 [3].
Det er lidt svært at se på videoen men når robotten skifter retning vibrerer den kraftigt.
Efter vi havde fundet en passende hjul konstant, der fjernede den kraftige vibration ved retningsskift, bevægede robotten sig omkring 30 cm før den skiftede retning.
Dette forbedrede vi ved at gøre motorkonstanterne KPOS og KSPEED højere hvilket gjorde robotten mere aggressiv ift. hvor langt den var fra den ønskede tacho værdi på motorene. Herunder ses robotten først før ændringerne og nedenunder resultatet af at vi firdoblede KPOS samt næsten fordoblede KSPEED:
Robotten svinger maksimum 8cm når den står stille og den tager ca. 2 sekunder om at skifte siden. Hvilket er en stor forbedring fra den orginale HTWay kode.
3. Bluetooth remote control
For at kunne fjernstyre robotten har vi valgt at anvende en bluetooth forbindelse, da dette er understøttet i NXT og oplagt da vi har en android telefon. Selve styre mekanismen fungerer ved brug af accelerometer, så man styre robotten ved at “hælde” telefonen i den retning man vil køre.
Vi har anvendt eclipse som udviklingsplatform til android telefonen og taget udgangspunkt i et lejos android bluetooth tutorial [1]. Applikationen sender hvert sekund en hastighed og turn værdi der er baseret på aflæsning af accelerometeret i telefonen.
Disse værdier har en range mellem -6 til 6.
Robotten håndtere bluetooth kommunikationen i en selvstændig tråd/task, der hedder TaskControl.
while(true)
{
// Set control Drive and Steer. These are in motor degree/second
readData();
motorControlDrive = (float) ((-speed * 60) * CONTROL_SPEED / 200.0);
motorControlSteer = (float) ((-turn * 40) * CONTROL_SPEED / 200.0);
try {
Thread.sleep(CONTROL_WAIT);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
Som det kan ses af den ovenstående kode, modtager tråden en speed og turn værdi over bluetooth der svinger mellem -6 og 6 alt efter hvordan brugeren hælder telefonen. Disse værdier anvendes som factor i udregningen af de globale værdier motorControlDrive & motorControlSteer. De to globale værdier anvendes af tråden TaskBalance til udførelse af de ønskede ændringer i hastighed og rotation. Den fulde TaskControl kan ses nederst i denne fil [2].
4. Opponent robot design
Vi har brugt den sidste del af session 3 på at diskutere hvordan en evt. opponent robot til den fjernstyrede segway skal fungere. Vi overvejer pt. følgende ting:
Skal opponent robotten være en segway eller tre hjulet robot ?
Hvilken detektion mekanisme skal opponent robotten anvende ?
Hvordan giver vi opponent robotten en fordel over den fjernstyrede robot ?
Det første spørgsmål hænger meget sammen med hvordan vi sørger for at opponent robotten ikke vælter mens den forsøger at vælte den fjernstyrede, hvis de begge er segways. Samtidig kan vi øge hastigheden på en tre hjulet robotten mere end vi kan på en segway.
Detektions mekanismen har vi indtil videre besluttet vil være baseret på infrarød til detektering af vinkel og ultralyd til detektering af afstand. Dette kommer også til at have en indflydelse på om vi kan lave opponent robotten til en segway da der så skal monteres yderligere på sensorer end der er på den fjernstyrede.
Den fjernstyrede robotten vil af natur have en fordel over opponent robotten da den er menneske styret. Hvor den autonome robot skal først måle på sine omgivelser og derefter reagere. Der er dog tiltag vi kan tage i brug for at mindske denne fordel og gøre spillet mere udfordrende. Det mest oplagte vil være at anvende større hjul da disse give højere hastighed og hurtigere rotation. Et andet tiltag vil være at ændre designet på den autonome robot og gøre den tre hjulet, dette vil give den et markant større fordel end bare at ændre hjul størrelsen.
5. Konklusion
Vi har analyseret HTWay koden og forstået i store træk hvordan de har implementeret den balancerende robot. Vi har anvendt denne forståelse til at lave nogle små forbedringer i koden så robotten balancere væsentligt bedre som dokumenteret. Yderligere har vi implementeret bluetooth styring på baggrund af lejos demo sample. Vi testet alle disse ændringer på HTWay med forskellige hjul størrelse, og vi er ret glade for resultatet.
Vi har diskuteret hvordan vi vil komme videre i projektet ved at begynde at overveje hvordan en evt. opponent robot skal konstrueres. Vi har en række overvejelser som vi vil prøve at udforske i næste session. Vi har forsøgt at få HTWay til at virke i samme omfang som vi har set i demoen, med eksakt samme kode setup etc. dette kunne dog ikke lade sig gøre. Vi mistænker at dette skyldes en forskel i batteri spænding. De batterier vi anvender har en spænding på 7.2v hvor dem der er anvendt i HTWay måske har været 8.3v:
Her en kommentar til blog indlægget om HTWay på hitechnics hjemmeside:
“Fernando says:
Hi,
Reading trough all comments, it turned out that I was using also my rechargeable battery, at too low level. 7,4V despite the bar indicator was still above half way.
After fully charging (now 8,3V) it works perfectly!
Great model!
Thanks
”[6]Referencer:
[1]:http://dl.dropbox.com/u/2779683/RCNavigationControl.java
[2]:http://dl.dropbox.com/u/2779683/HTWay%2024-05.txt
[3]:http://legolab.cs.au.dk/DigitalControl.dir/index.html
[4]:http://legolabsblog.blogspot.com/2012/02/tid-5-timer-deltagere-kenneth-mikkel.html
[5]:http://dl.dropbox.com/u/4447110/Logging%20skrive%20mindre.txt
[6]:http://www.hitechnic.com/blog/gyro-sensor/htway/
No comments:
Post a Comment