ESEA - Labnotes

NXT programming - Lektion 6 - fortsat (igen)
Varighed: mange timer
Gruppemedlemmer: Aslak, (Ruben og Lars)

Fejlen med motoren (se blog fra lektion 6 - lørdag) blev rettet relativt hurtigt da dette var pga. at vores initialisering af motoren ikke var rigtig. Herefter kørte begge motorer lige hurtigt.

Herefter begyndte vi at skrue på parametrene for KP, KI og KD.Vi lavede kopier af programmet, hvor vi ændrede KP i positiv og negativ retning med 2 for hver test altså KP = (20, 22, 24, 26, 28 (standard), 30, 32, 34, 34). Vi kunne ikke konstatere nogen umiddelbar forbedring, men jo lavere KP blev desto svagere blev selvreguleringen. Og det modsatte skete hvis KP blev højere, men dette hjalp ikke på balancen.

KI ændringen kunne ikke mærkes på robotten.Det samme oplevede vi for KD. Derudover opdagede vi en klassisk fejl, som også omtales i den læste litteratur; Batteriniveauet har stor betydning for, hvordan robotten reagerer. Vores bedste resultat, som vi desværre ikke fik filmet, hvor vi var oppe på et minuts ballance, var med et batteri niveau på 7.0 (så vidt der huskes). Men da Aslak, som arbejdede individuelt i ferien, dagen efter havde kameraet klar og havde opladet batteriet, gik robotten fuldstændig amok med sin regulering. Dette skal man nok tage højde for en anden gang og skrive en regulerings algoritme i forhold til batteriet.

Efter en snak med Ole, prøvede vi at fjerne KI konstanten fra algoritmen. Og dette hjalp faktiskt på balancen.Dette skyldes, at Integral fejlen stiger og stiger. Denne stigende Integral fejl resulterer i, at robotten fint holder balancen i starten. Herefter bliver reguleringen kraftigere og kraftigere, hvilket resulterer i, at robotten kommer i ossilationer og får besvær med balancen.

den endelige kode (som den ser ud nu) kan ses her:
http://userportal.iha.dk/~20060651/JavaFiles_ESEA/Lektion6/Balancer.java

ESEA - Labnotes

NXT programming - Lektion 6 - fortsat (lørdag)

Varighed: 2,5 timer - kl. 11.00-13.30

Gruppemedlemmer: Aslak,Ruben (og Lars)

Gruppens mål for dagens lektion:

• Modificere robottens design til bedre at kunne balancere
• Programmere robotten til at balancere

Vi blev enige om at robottens konstruktion var lidt for ustabil. Hjulene var monteret nede under NXT'en og motorerne sad ikke ret godt fast.Vi besluttede at bygge robotten om, så den fulgte udseendet fra KAP 11 i stedet. Da vi nu havde ændret på robottens design, var det nu nødvendigt at bytte rundt på forward og backward igen i koden. For at øge afstanden fra lyssensoren til underlaget og øge stabiliteten for robotten,satte vi to store hjul på i hver side i stedet for de små hjul, hvilket kan ses af de følgende billeder:

Desuden byggede vi lidt i højden og tilføjede lidt vægt foran på robotten for at den skulle være i bedre balance, hvilket kan ses af billedet ovenfor. Vi lavede et støtteben til robotten for at lave en ensartet kalibrering hver gang. Vi ville prøve at se, hvad der skete ved en ændring i SCALE-værdien i koden.Vi ændrede scale faktoren fra 18 til 19, 25, 40. Det virkede, som om at øgningen af SCALE gjorde at robotten ikke regulerede så kraftigt, så robotten hurtigere kom i ubalance. Vi ændrede herefter scale faktoren ned til 10. Dette bevirkede at den regulerede bedre igen - dog lige i overkanten da den overshootede en del. Vi skiftede den venstre motor, fordi den ikke reagerede så kraftigt som den højre.Dette gav samme resultat.Herefter prøvede vi at skifte den Højre motor, fordi den reagerede kraftigere end den venstre.Det blev en smule bedre, der var dog stadig lidt forskel på de to motorer. På følgende videoklip kan det bedst opnåede balanceringsforsøg ses. Den havde dog stået og balanceret i cirka 10 sekunder inden der blev filmet,så den balancerede altså i nærheden af 20 sekunder.

ESEA - Labnotes

NXT programming - Lektion 6 - fredag

Varighed: 3.5 timer - kl. 09.00-12.30

Gruppemedlemmer: Aslak,Ruben (og Lars)

Gruppens mål for dagens lektion:

• Bygge en ny type robot til at balancere
• Programmere robotten til at balancere

Først byggede vi robotten. Der blev taget udgangspunkt i NXTway modellen,hvis byggevejledning kan findes på følgende link:
http://www.philohome.com/nxtway/bi_nxtway.htm
Det færdige resultat af den byggede robot kan ses på de følgende billeder:

Efterfølgende læste vi lidt omkring PID-regulering for at opnå en lidt bedre forståelse herfor.
Vi begyndte at programmere robotten med klassen 'Balancer.java', der fra startentager udgangspunkt i klassen 'Sejway' fra kapitel 11 i Brian BagnallsMaximum Lego NXTBuilding Robots with Java Brains (s. 282-284), herefter KAP 11.
Robotten reagerede alt for voldsomt, så vi forsøgte at justere motorpoweren ned (til 1/10).Dette var dog alt for meget, hvilket resulterede i at den blev alt for sløv. Så motorpoweren blev justeret tilbage igen.
Afstanden fra lyssensoren til underlaget var meget stor, så vi besluttede at justere den lidt ned.
Det var lidt problematiskt med opstarten af robotten, for den startede med det samme man gik ind i programmet på NXT'en. Derfor blev LEFT-knappen assignet til at starte i stedet for enter, så robotten blev ordentligt kalibreret inden den startede op.

Efter at vi justerede lyssensoren ned, blev afstanden til underlaget for lille, hvilketresulterede i at robotten ikke kunne regulere den ene vej, fordi sensoren rørte gulvet.
Vi bemærkede at robotten regulerede forkert i forhold til forventningen.Vi opdagede at NXTway-byggevejledningen og koden vi benyttede fra KAP 11 ikke stemte overens.Lyssensoren sad i disse to tilfælde på hver sin side af køretøjet.
Vi korrigerde i koden, for at regulere rigtigt. (Byttede om på forward og backward)
Vi besluttede at bygge lidt til i højden af robotten for at ændre tyngdepunktet for robotten,så det skulle blive lettere at balancere.
Ved dagens afslutning, var det ikke lykkedes at få robotten til at balancere ordentligt.Gruppen aftalte at mødes igen den følgende dag (lørdag d. 13/10-2007).

ESEA - Labnotes

NXT Programmering - Lektion 5 - fredag
Varighed: 4 timer - 9.00 - 13.00
Gruppemedlemmer: Aslak, Ruben og Lars

Målet for i dag er at gennemføre Robot Race hurtigst muligt. Vi er blevt forslået at gå væk fra brugen af Locomotion.java, idet den er baseret på en ikke-direkte adgang til motorene. Vi beslutter ved starten af dagen at bibeholde brugen af Locomotion.java, idet en så gennemgribende ændring vil tage for lang tid.

Dagen i går sluttede i en nedadgående retning, idet vi ved de sidste ændringer opnåede større kontrol med robottens opførsel, men med dårlige tider som resultat. Se bloggen fra i går for nærmere beskrivelse. Dette medfører at humøret ikke er i top, som fredagen starter kl. 09.00. Men vi tror på at det nok skal lade sig gøre at forbedre opførslen mærkbart. Det største problem vi har oplevet er, at vi ikke helt ved hvor mange målinger robotten når at udføre, når den er hhv. ude på det hvide uderlag og inde på den sorte tape. Vi ved altså ikke helt hvor aggresiv robotten skal dreje til højre, når den er på den sorte tape. Når robotten er for "slap" kører den ofte over tapen og kommer på den forkerte side (dette resulterede i en bakke-sensor placeret bag højre hjul). Når robotten er for aggresiv opnår vi utrolig god linje-følger tendenser, men også lave hastigheder. Altså er løsningen et kompromis, som skal findes eksperimentalt.

Vores første tilgang er at starte med bare én opførsel for målinger på hhv. hvid og sort. Ved at analysere hvordan robotten klarer banen med denne indstilling tilføjer vi langsomt flere og flere trin i opførslen. Når robotten f.eks. måler sort for 3. gang i træk er det på tide at dreje meget skarpt, osv. Denne tilgang er den samme som fra dag 1, men den virker ikke som vi håbede. Faktisk må vi indse, at vi ikke kan nå at få robotten til at gennemføre banen lige så godt som dagen i forvejen, inden vores tid løber fra os.

Realiteten er, at det oprindelige udgangspunkt, at holde antallet af sensorer på et minimum, at forsøge at optimere på udgangspunktet, frem for at lave en helt nytænkt løsning, at fokusere på at udvikle koden, frem for køretøjet, er slået helt fejl. Vi kan ikke tackle banen med samme hurtigt kørsel som nogle af de konkurrerende køretøjer.

Som dagen slutter vælger vi at indsende den bedste tid fra dagen i går, og en dokumentation af et gennemløb af banen som vores deltagelse i Robot Race. Koden, som den ser ud da denne lektion er slut er som følger:
slutkode

ESEA - Labnotes

NXT Programmering - Lektion 5 - torsdag
Varighed 7.5 timer - kl. 8.00 - 15.30
Gruppemedlemmer: Aslak, Ruben og Lars

Målet for i dag er opdelt i de følgende delmål:

• at få robotten til at genkende grøn, og stoppe når den er sikker på at den har fundet det grønne område
• at udskrive tiden på displayet (tiden fra robotten blev startet, til den stopper på det grønne område).
• at optimere på robottens opførsel, således at den kan gennemføre banen i bedst mulig tid.

På sidste blog, fra den "xtra" lektion vi havde i tirsdags, viste vi et billede af den bane som skal gennemføres. Det grønne målområde skal genkendes. Dette gøres ved at kalibrere de 2 sensorer (se billede fra samme lektion ang. sensor-placering) så vi kender sensorværdier for hhv. hvid, sort og grøn. Når så begge sensorer læser en værdi som svarer til grønt, er robotten i mål. Denne kode fik vi let til at fungere. Den anden sensor blev placeret hvor den sidder nu (bag ved højre hjul) pga. problemer med at robotten kørte "igennem" den sorte tape. Dette blev omtalt sidste lektion, og denne placering viser sig at være god til at vurdere hvornår robotten er inde i målområdet.

Det næste delmål er tidstagningen, noget som viste sig at være lidt problematisk. Efter mange forsøg, hvor vi fik ulæst fejlmeldinger i displayet, frem for tiden, endte vi med at bruge System.currentTimeMillis() funktionaliteten. Vi fandt at problemet med at skrive ud på display ikke havde noget med de andre forsøge metoder at gøre (Timer, Ticker osv.) men skyldes at vi forsøgte at udskrive (draw) en string, og ikke en int.

Nu er vi så langt, at robotten gennemfører banen hver gang, finder det grønne målområde, samt udskriver tiden på displayet. Dette har vi optaget på en video, og selve arbejdet med at få optimeret på robottens fremfærd kan begynde.

Den ovenfor viste video kan også hentes ned her: http://userportal.iha.dk/~20060651/Movies/Race_2_001.mpg

På denne video gennemfører robottten banen på ca. 47 sekunder. Det lykkedes os at få tiden ned på 35 sekunder, dog uden at få dette dokumenteret på video. Vi gik ud fra at vi kunne få robotten til at køre hurtigere og fik derfor ikke dokumenteret denne præstation.

Som arbejdet skred frem gik det langsomt op for os, at der var ikke-optimale løsninger i koden. Faktisk måtte vi indrømme, at det robotten udførte ikke helt var det vi troede vi havde bedt den om. Dette skyldtes forkerte argumenter i if-sætninger og andet godt. Faktum var, at vi, hvis vi ønskede total kontrol over hvad robotten udførte, måtte vi starte forfra med at kode robottens handlinger. Forfra forstået på den måde, at den kode som bestemmer hvilke værdier, som sendes til de to motorer i forbindelse med forskellige antal målinger af hhv. hvid og sort, skulle tænkes anderledes.

Denne dag endte med, at robotten endnu ikke havde gentaget sin "fantomtid" på ca. 35 sekunder, efter vi selv havde overtaget kontrollen med hvad robotten gjorde og hvornår.

Koden, som den så ud ved dagens afslutning er at finde for enden af de følgende links:

http://userportal.iha.dk/~20060651/JavaFiles_ESEA/Improved_2_04102007/SensorReaderTest.java

(mangler pt. koden for Locomotion, som er blevet udbygget med en rotatevenstre)

ESEA - Labnotes

NXT Programmering - "Xtra" Lektion
Varighed: 5.5 timer - kl. 12.30 - 18.00
Gruppemedlemmer: Aslak, Ruben og Lars

Målet for i dag er at fortsætte med at arbejde med linjefølger-robotten, som skal deltage ugens Robot Race. Følgende delmål forventes at blive gennemført i dag.

• Optimere på NXT'ens programmer, så den bliver hurtigere samt bedre til at følge linien.

Her er et billede af den bane, som robotten skal gennemføre:

Som programmerne fra sidst var lavet, kører bilen efter overgangen imellem sort/hvid (kanten af tapen). Såfremt der forekommer flere aflæsninger i træk af samme "farve", drejes der skarpere for at komme tilbage til kanten af tapen.
Bilen kørte fra starten ret langsomt, så vi ændrede på parametrene for hastigheden, hvilket jo fik den til at køre hurtigere, men dette gav problemer i forbindelse med at udføre svingene ordentligt.
Nogle gange fik den drejet så meget at den kørte over tapen og ikke kunnne find tilbage på ret kurs.Det blev diskuteret hvad der skulle gøres for at forhindre at køretøjet kørte over tapen.

Det blev forsøgt at lave et program, der talte, hvor mange gange den læste den sorte farve, når køretøjet kørte lige over tapen. Dette kom dog ikke til at virke ordentligt og ideen blev droppet, da vi igen fik diskuteret om vi kunne bruge denne oplysning til noget fornuftigt.

Det blev herefter besluttet at vi skulle bruge en ekstra lyssensor.Vi skulle altså benytte en af de gamle RCX-lyssensorer.For at disse kunne benyttes, skulle der oprettes en ny sensor-klasse til RCX-lyssensorerne.
RCX-lyssensoren blev påmonteret på NXT-køretøjet bagved højre hjul. Der detekteres om tapen er paseret af den forreste sensor. Den skrevne kode kan ses her: http://userportal.iha.dk/~20060651/JavaFiles_ESEA/Improved_1/RCXBWSensor.java

Placeringen af de to lyssensorer kan ses på de følgende billeder:

Der blev tilføjet en rutine i Locomotion.java, der kunne få køretøjet til at bakke samt en rutine, der kunne få køretøjet til at rotere (det ene hjul kører frem, imens det andet kører tilbage). Den redigerede Locomotion.java kan ses her: http://userportal.iha.dk/~20060651/JavaFiles_ESEA/Improved_1/Locomotion.java

Når RCX-sensoren herefter detekterer sort, er køretøjet kørt over tapen, og de nye rutiner tages i brug.Først bakker køretøjet til NXT-lyssensoren kommer tilbage til tapen (sort). Herefter roterer køretøjet til sensoren er tilbage ved tapens kant (hvid) og køretøjet igen er tilbage på rette kurs. Her sættes et flag, således at koden ved at robotten lige har udført en bakke-rutine. Dette flag medfører, at robotten starter med at køre lidt mod højre (som om den har læst værdien sort). Dette er lavet baseret på analyse af de situationer robotten har været i, når den krydser tapen. Koden BlackWhiteSensor.java er ikke ændret siden sidste lektion. Koden til robottens opførsel kan ses her: http://userportal.iha.dk/~20060651/JavaFiles_ESEA/Improved_1/SensorReaderTest.java

Afslutningsvis blev det besluttet, at gruppen torsdag morgen først og fremmest vil fokusere på at få køretøjet til at detektere den grønne farve i målområdet og udskrive tiden på displayet. Herefter vil vi optimere videre på den resterende kode.