Tid: 25 timer, Deltagere: Kenneth, Rawad.
Siden sidst:
Intet at bemærke.
Formål:
Gennemføre lesson 8, Robot Race[1]. Der går ud på at konstruere en robot der kan starte i det grønne felt på Alishan banen i legolab, køre op til den øverste platform og returnere til det grønne felt hurtigst muligt.
Plan
- Planlægge design & koncept
- Foretag målinger på Alishan
- Konstruktion af robot
- Test af robot på Alishan
- Analyse af koden
- Konklusion
1. Konstruktion af robot
Billedet ovenover viser robotten. Vi har valgt at anvende større hjul end de der standard medfølger NXT, for at køre en større afstand pr. omdrejning. Vi har under konstrukstionen valgt at gøre plads til mulighed for tilføjelse af en kæde til en mindre aksel, der fungere som gear, for at opnå flere omdrejninger. Et billede af kæden og akslerne kan ses herunder.
Vi har valgt ikke at anvende kæden i vores design, da hastighederne der opnåes er for høje til at vi mener vi kan køre stabilt på alishan. Da vi testede denne konstruktion med hjulene fastgjort på akserne med de små tandhjul syntes vi ikke bilen opnåede en højere hastighed på et flat stykke end da hjulene var fastgjort direkte til motor aksen. Dette skyndes formindelig at motorene ikke har den fornødne torgue til at fastholde samme høje omdrejninger i begge tilfælde. Da vi testede gearingen på Alishan banen hoppede kæden over tandhjulene når reguleringen var for voldsom. Derfor valgte vi at skrotte gearingen, fordelene var tvivlsomme og det introducerede begrænsninger.
Robotten er baseret på LEGO Mindstorms Education NXT base set 9797 bygnings instruktion side 8 til 22. De eneste modifikationer er beskrevet ovenover, en konsekvens af dette har været at selve NXT blokken ikke er direkte bygget sammen med resten af robotten. Den holdes fast ved hjælp af en lego elastik.
2. Design & koncept
Vores koncept er baseret på to standard NXT lyssensorer der er opstillet ved siden af hinanden som det kan ses på billedet herunder.
Med to lyssensorer kan vi dektektere hvilken side af den sorte linie vi er på, og vi anvender også disse til at detektere at vi er ankommet til en platform.
Billedet ovenover viser starten på en platform på Alishan, de røde cirkler viser hvor sensorerne måler. Vi kan med vores dual sensor setup, pålideligt detektere disse ved at højre sensor måler helt sort, hvor venstre sensor måler helt hvidt. Denne metode til at dedektere platformen ville dog kun virke hvis bilen var forholdsvis god til at følge linien uden for meget slinger.
I starten af vores design af en robot der kan komme igennem Alishan banen, havde vi planer om at anvende et gyroskop, til at detektere de flade platformer der findes på banen. Vi gik væk fra dette koncept efter vi fandt ud af at det er relativt let at detektere platformene med to lyssensorer.
Selve robottens logik er bygget op som en statemachine, dvs. vi har specifik programmel for hver sektion af banen. Det gør at vi kan tage højde for evt. forskelle mellem sektionerne som f.eks. lys værdier eller hældning.
3. Foretag målinger på Alishan
For at få en forståelse af hvordan robottens lyssensorer opfatter alishan banen, har vi udvidet dataloggeren brugt i tidligere lessons. Dataloggeren måler input fra to lyssensorere, og logger dette i en text fil. Vi vil bruge målinger fra dataloggeren til at optimere robottens logik.
Begge sensorere på hvid overflade: left 45 right 45-46
Begge sensorere på sort overflade: left 35 right 37
Start af platform: left 40+ right 33-35
Disse målinger blev foretaget cirka kl 9-10. Vi erfarede at disse målinger ændrede sig voldsomt senere på dagen efter der kommer mere lys ind i bygningen, og nogle sektioner af banen dækkes af skygger.
Vi foretog målinger igen kl 12.
Begge sensorere på hvid overflade: left 51 right 51
Begge sensorere på sort overflade: left 41 right 41
Start af platform: left 33-35 right 40+
Effektiv opløsning på cirka 10 mellem hvid og sort med normaliserede værdier.
Vi har senere skiftet over til at bruge raw-values, da dette giver en højere opløsning. Vi har også valgt at kalibrere værdierne før start. Målingerne ovenover har dog stadig været en stor hjælp til forståelse af hvordan sensorerne aflæser banen.
råværdier sort 457 hvid 525
Effektiv opløsning på cirka 60 mellem hvid og sort med rå værdier.
På baggrund af tip fra Ole Caprani om sænkning af højde forskellen sensor og overflade, har vi opnået endu større opløsning. Alle målinger ovenover er foretaget med sensor højde på cirka 2.3cm,
Efterfølgende målinger er foretaget med sensor højde på cirka 1.5cm
råværdier sort 410 hvid 550
Effektiv opløsning på cirka 140 mellem hvid og sort med rå værdier og ny sensor højde.
Hver gang vi har effektiviseret sensormålingerne og opnået højere opløsning har det været nødvendigt at lave massive ændringer på koden for at få det til at virke med den ny opløsning.
4. Test af robot på Alishan
Robotten er løbende gennem arbejdsprocessen blevet testet mange gange på alishan banen. Videoen herunder viser sidste kørsel udført 18-04-2012 kl: 14:30, kørslen varede 27.753 sekunder fra grøn zone og tilbage igen.
5. Analyse af koden[2]
Follow line
Denne funktion var forholdvis let at lave da vi fra tidligere lab øvelser[] havde erfaring med at få biler til at følge en linie. I dette tilfælde var der dog to lys sensorer hvilket vi valgte at udnytte ved at udregne error på denne måde:
error = (sensor.whiteLightValue - lightRight) - (sensor.whiteLightValue - lightLeft);
Error brugte vi herefter i en pd-regulering (Vi undlader at bruge integralet da dette kun gavner reguleringen hvis linien drejer) som holdte bilen på linien så den konsekvent og med høj sikkerhed kunne dedektere platformen.
Den første halvdel af banen bevægede bilen sig opaf og pd-reguleringen var istand til at holde bilen på linien ved top hastighed ( begge motorer ydede maksimum). På den sidste halvdel af banen skulle bilen bevæge sig nedaf og dette betød at top hastigheden var noget højere og at den samme regulering ikke var tilstrækkelig. Derfor lavede vi en anden udgave at pd-reguleringen som kunne holde bilen på linien når den kørte nedaf. På dette tidspunkt var vi dog lidt i tidsnød og valgte at skrue ned for hastigheden. Da vi havde den forventning at bilen ved den lavere hastighed ville have lettere ved at følge linien. Dette var dog ikke det vi observerede, men vi havde ikke tid til at optimere hastigheden og da funktionen virkede acceptabelt ved en power på 80, gik vi videre.
Hardcoded sving
Vi har håndteret sving på alishan banen på flere måder. I starten gjorde vi det ved at sætte motor værdier til at dreje i.e. Car.forward(70,100), og så vente et tidsrum med sleep funktionen. Dette giver dog store afvigelser for hver kørslen og afhænger voldsomt af batteri-niveau.
Anden metode vi brugte anvendte tachocounteren til at bestemme hvor lange vores sving skulle være samt en pd-regulering til at bestemme power til de to motor. Dette viste sig at være meget mere stabilt end ved brug af tid. Herunder se udregningen af error under foretagelse af svinget, konstanten 2.5 resulterer i at motor C drejer 2,5 gange længere end motor B.
error = ((MotorPort.B.getTachoCount() - iniTachoB)*2.5 - (MotorPort.C.getTachoCount() - iniTachoC));
Catch line
Efter vi komme ud af at sving, skal vi finde linien igen. Catch line funktionen forsøger at gøre dette ved at måle hastigheden som bilen har imod linien og herefter reagere ved at foretage et sving så bilen lander med linien imellem sensorene og i en ikke alt for spids vinkel på linien.
Denne funktion var den mest tidskrævende af alle. Vi havde den til at virke i starten hvor vi ikke brugte rå værdier fra sensorerne og hvor sensorene var placeret højt. Her var den meget alsidig og virkede både ved meget høje indfaldsvinkler og ved meget lave. Funktionen virkede ved først at prøve at detektere noget mindre end helt hvid, når dette skete ventede den 40 milisekunder hvorefter den foretog en ny måling. Differencen imellem den første måling og den foretaget efter de 40 milisekunder var så error ( rightSensorVal - tempRightLight ). Denne error havde så indflydelse på hvor hurtigt vi skulle dreje og hvor længe.
Thread.sleep(40);
int tempRightLight = sensorRight.light();
if(rightSensorVal - tempRightLight > 3)
Car.forward(power - Math.abs((rightSensorVal - tempRightLight))*5, power);
Thread.sleep(Math.abs((rightSensorVal - tempRightLight))*50);
while(sensorLeft.light() > sensorLeft.whiteLightValue-2)
{}
Efter vi ændrede højden på sensorerne og gik over til rå værdier kunne vi ikke få funktionen til at virke igen, lige meget hvor meget vi stillede på variablerne.
Derfor valgte vi på den sidste dag at foretage nogle målinger der skulle vise hvad sensorerne faktisk målte når bilen ramte linien. Ved en høj indfalds vinkel fik vi følgende resultater:
r:532 l:499time:26284
r:534 l:494time:26288
r:532 l:462time:26300
r:533 l:439time:26304
r:532 l:427time:26308
r:533 l:397time:26313
r:532 l:384time:26317
r:532 l:361time:26321
r:534 l:353time:26325
r:532 l:349time:26330
r:532 l:347time:26334
r:532 l:348time:26338
Vi antog at vi først kunne dedektere linien pålideligt efter værdien var under ca. 480 da samlingen imellem platform og pladen fik sensoren til at måle ned til 485. Disse resultater betød at vi ændre vente tiden i funktionen fra 40 milisekunder til 30 da dette var tiden det tog at komme fra kanten af linien til en minimum værdi på sensoren. Resultaterne bekræftede også vores antagelse om at vi ikke kunne udregne hastigheden imod linien udfra to på hinanden følgende målinger. Selvom tiden imellem dem blev taget i betragtning er svingningerne for store, herunder vises en oversigt over ændringen i tid og måleværdi fra måling til måling.
Herefter delte vi funktionen op i fire dele, en seperat kodesekvens for hver situation, op og ned, højre og vestre sving. Systematisk gik vi igennem dem alle og indstillede konstanterne så de var optimale for netop det sving. Men det tog simpelthen for lang tid og det var svært at få funktionen til at være så alsidig at den kunne fange linien i alle vinkler.
Derfor valgte vi at lave svinget tacho og pd styret hvilket resulterede i at funktionen nu ikke skulle være så alsidig fordi bilen altid ramte linien i nogenlunde den samme vinkel. Dette gjorde at vi hurtigt kunne få bilen til fange linien i de fleste tilfælde, og dette var godt nok for nu da der var omkring halvanden time til deadline.
Turn
Opgaven der lød på at dreje 180 grader om sig selv på den øverste og køre ud igen prøvede vi først løse ved at køre en vis afstand fremad ind på platformen. Derefter dreje først ca. 90 grader mod højre og så fortsætter drejet indtil den højre sensor så linien. Starte pdLineFollower og køre ned fra platformen og ned til det næste sving. Denne metode var dog udsikker da det med at køre lige ud ind på platformen var meget usikkert. Nogle gange landede bilen til venstre for linien og andre gange til højre, hvilket betød at vi måtte køre meget langsomt ud igen for at være sikker på at ramme linien på den anden side af det sorte bælte. Vi valgte istedet en både sikker og hurtig løsning, bruge pdLineFollower til at køre til det sidste sorte bælte, på den måde var vi sikre på at når vi begyndte at vende stod vi lige på linien. Dermed landede vi også lige på linien efter drejet og kunne køre hurtig ud igen vha. pdLineFollower. Det hurtigt bak som kan ses i videoen er for at baghjulet ikke kører ud over kanten.
6. Konklusion
Det lykkedes os at lave en robot der er istand til at navigere fra den grønne zone på alishan banen op til toppen, og tilbage til den grønne zone på under 28 sekunder. Vi havde mange problemmer der skulle løses undervejs. De mest nævneværdige problemer var hvor følsom lyssensorerne var for små ændringer i banen, dette gjorde det nærmest umuligt at køre rundt på banen med normaliserede lys sensorværdier og med lys sensorene placeret højt over banen. Ændringerne til råværdier samt at justere på sensorhøjden, hjalp dog meget på dette problem. Det ser ud til at konkurrence elementet i denne lab øvelse har haft meget indflydelse på vores arrangement, som aldrig før har været i nærheden af 25 timer.
Referencer
[1], http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson8.dir/Lesson.html
[2], http://dl.dropbox.com/u/4447110/Code.rar
No comments:
Post a Comment