1. Assignment, byg robotten om til en sejway.
Vi fulgte vejledningen her: http://www.philohome.com/nxtway/binxtway.htm, og byggede en balancerobot.
Vi fulgte vejledningen her: http://www.philohome.com/nxtway/binxtway.htm, og byggede en balancerobot.
2. Assigment, lav et program der kan få robotten til at balancere.
Vi blev inspireret Bagnals "gode" programeksempel fra bogen. Vi prøvede først bare at køre programmet og afbalancere robotten, vi havde ikke lyst til at afbalancere robotten hver gang, og hardcodede derfor en værdi, velvidende at den så skal stå på det samme underlag hver gang (i vores tilfælde et bord).
Vi blev inspireret Bagnals "gode" programeksempel fra bogen. Vi prøvede først bare at køre programmet og afbalancere robotten, vi havde ikke lyst til at afbalancere robotten hver gang, og hardcodede derfor en værdi, velvidende at den så skal stå på det samme underlag hver gang (i vores tilfælde et bord).
Dette virkede OK, uden flere ændringer i programmet, men robotten var ikke særlig stabil, og skulle have hjælp til at holde balancen indimellem. Da den bevægede sig med store ryk. Vi iagtog også at den havde en tendens til at vælte bagover og ændrede derfor offsetværdien, for at få det til at passe.
Vi ændrede KP til 1 for at se hvilken effekt dette havde på robottens balance. Vi synes den reagerede langsommer, for at bekræfte vores teori, forsøgte vi os med at sætte den på 50. Her synes vi robotten reagerede meget hurtigere. Med det mener vi at den hurtigere reagerer når den for overbalance med at køre.
Vi ændrede KI til 8 for at se hvilken forskel dette gjorde. Mens vi forsøgte os med det lagde vi mærke til hvor stor forskel det gjorde når vi skyggede for lyset omkring os. Herefter besluttede vi altid at skygge for sensoren.
Efter dette "nulstillede" vi programmet for at måle offset igen hvor vi var beviste om at skygge for sensoren. Dette gav os ikke noget nyt, og vi forsøgte med at skrive værdierne for KI*int_error, KP*error og KD*deriv_error på displayet for at se hvordan de skifter. For at få en ide om hvordan vi skal regulere dem for at få det til at passe.
Vi kunne se at værdierne for error og int_error sprang fra 2000 til -1000, og prøvede derfor at halvere KI og KP. Dette resulterede i mindre errors, samt at motorerne kørte langsommere.
Vi kunne se at nulpunktet for error er meget forskudt, dvs. den går med værdier fra -500 til ca 2000. Derfor prøvede vi at trække 500 fra alle errors, for at se om vi kunne få midtpunktet for udregningerne flyttet. Dette hjalp ikke, nu kunne vi kun køre baglæns.
Vi prøvede at sætte robotten til en anden motor, så vi kunne se hvordan den reagerde. Her observerede vi meget store spring i error. Derfor ændrede vi værdien man ganger error med når den er negativ, til 18.
Dette resulterede i at hjulene kørte ca. lige hurtigt. og værdierne sprang fra -20000 til 40000. Da vi satte værdien op til 180 ramte vi et overflow og fik derfor ikke længere negative error værdier. Derfor valgte vi at prøve at dividere den positive værdi med 10 i håb om at få værdierne ligeligt fordelt.
Dette resulterede i at hjulene kørte ca. lige hurtigt. og værdierne sprang fra -20000 til 40000. Da vi satte værdien op til 180 ramte vi et overflow og fik derfor ikke længere negative error værdier. Derfor valgte vi at prøve at dividere den positive værdi med 10 i håb om at få værdierne ligeligt fordelt.
Vi prøvede at tjekke freMemory, for at være sikker på at den ikke gav os problemer. Der så vi at vores memory blev brugt op i løbet af 2 sekunder, så rød garbage collectoren op og memory forsvandt igen efter 2 sek. Vi huskede derefter at hvis vi oprettede nye strings i vores write() metoder vil det hurtigt fylde vores memory (især i et loop uden pause). Så vi fik ændret alle vores write() til writeInt() da vi jo kun var interesseret i værdierne og det løste vores memory problem.
Et andet problem vi rendte ind i var at vi glemte at clear skærmen, så grunden til at vi fik absurd høje tal engang imellem var fordi der var nogle "gamle" cifre fra tidligere tal for "enden" af tallet. Da vi ordenede det fik vi meget finere tal end før, men balanceringen af konstanter var stadig meget bøvlet, primært pga. lysforholdene.
Vores endelige kode kan findes her:
http://code.google.com/p/lego2010/source/browse/trunk/Lego%20Lab4/src/Sejway.java
Ingen kommentarer:
Send en kommentar