Denne uge har vi arbejdet med en balancerede LEGO robot, lignende Philippe Hurbain's NXTway-robot. Idéen er at den skal fungere ligesom den velkendte selvbalancerende segway.
Målet med denne lab session var først at prøve SejwayBad.java af, hvor vi gerne skulle se robotten kører meget ustabilt og drejer voldsomt frem og tilbage. Herefter skulle vi afprøve Sejwat.java, som er en forbedring af SejwayBad.java. Vi skulle gerne kunne obsevere at Sejway.java virker bedre end SejwayBad.java (bedre balance).
Vi fik downloaded de 2 kode filer, men støte derefter på et problem. Vi kunne ikke forbinde til vores NXJ, da de libraries vi bruder til kommunikere med NXJen i OS X ikke virkede. Det viste sig at en af sidste uges opdateringer til OS X satte Java til at kører 64-bit som standard, hvorfor USB og Bluetooth (hhv. usblib og bluecore) ikke længere virkede. Løsningen var at tvinge Java til at starte NXJ applikationerne (f.eks. nxjbrowse) i 32-bit. Dette tog desværre noget tid at finde ud af.
Det gøres ved at indsætte -d32 i den sidste linie i det script man ønsker at køre. Her er et eksempel fra nxjbrowse:
java -d32 -Dnxj.home="$NXJ_HOME" -DCOMMAND_NAME="$NXJ_COMMAND" -Djava.library.path="$NXJ_BIN" -classpath "$NXJ_CP_TOOL" lejos.pc.tools.NXJBrowser "$@"
SejwayBad.java forsøg:
Problemet med denne kode er at programmet kører for langt hver vej før den skifter retning. Det 'overreagerer' hver gang, og lærer ikke af sine fejl. Efter at have overreageret burde den korrigere nogle variable så den ikke korrigerer lige så meget næste gang.
SejwayBad.java har en variable int NEUTRAL = 37. Denne variable angiver lysstyrken læst af lyssensoren når robotten står i balance (nautral). I vores tilfælde var det for lavt. Da vi kørte programmet, kunne vi aflæse på displayet en værdi ca 400. Dette resulterede i at robotten straks væltede. Så for at få SejwayBad til at virke var vi nødt til at korrigere denne værdi.
Men pga. de problemer vi havde tidligere med USB-driveren og java, valgte vi at stoppe med SejwayBad og gå videre med den bedre kode (Sejway.java) som vi fået udleveret.
Sejway.java forsøg:
Sejway.java koden er bedre af to grunde. Den første er at programmet starter med at sætte den værdi der læses fra lyssensoren, som balance punkt (i modsætning til SejwayBad.java der havde en pre defineret værdi i koden). Den anden grund er at Sejway.java forsøger at tage højde for overkorrigering ved at huske hvormeget der sidst blev korrigeret med og ændre ud fra dette, hvormeget der korrigeres.
Vi lavede et forsøg med koden uden at have ændret i det, for at se hvor længe robotten kunne holde sig oprejst. Det var muligt for den at holde sig oprejst i et par sekunder, inden den væltede.
Herefter kiggede vi på koden for at se om vi kunne forbedre dette. Vi forsøgte os med at sætte PID variablen KP ned til 10. Det gjorde vi ud fra den obsevation at robotten i første korrigerede sin balance for kraftigt i de første par iterationer og endte med at "stille" sig på lyssensoren. Vi ville derfor nedsætte styrken med hvilken robotten startede med at korrigere, så den kunne nå selv at ændre på sin korrigtions styrke.
// PID constants
final int KP = 17;
Efter nogle forsøg endte vi på 17, hvilket viste sig at være den værdi der fik robotten til at klare sig bedst. Det var det ikke en forbedring på mere end et par sekunder, robotten kunne holde sig oprejst. Herefter nåede vi ikke længere.
Reflektion:
Vi skulle måske have kigget mere på hvordan algoritmen virkede og forsøgt at arbejde med den, såvel som PID værdierne. Vi skulle også have kigget på de andre konstakter, ud over KP.
En anden ting der viste sig vigtig var hvor godt man fik placeret robotten i sit balance punkt. Ulempen her er at der i et givet forsøg ikke er nogen garenti for at vi kan placere robotten på præcis samme måde, som i forgående forsøg og dette kan påvirke vores fortolkning af den effekt, som vores ændringer i koden har givet. F.eks. er det muligt at vores ændringer i KP konstanten ikke var grunden til at vores robot klarede det (en smugle) bedre, men grunden var at vi var bedre til at placere robotten i sit balance punkt ved starten af testen. Vi havde dog ikke tid til at udforske dette, grundte den "spildte" tid på USB/Bluetooth driverne.
Ingen kommentarer:
Send en kommentar