Torsdag d. 30/9
Vi har i dag arbejdet med at få robotten til at følge en linie hurtigst muligt. Vi har benyttet 2 lyssensorer fra RCX robotten til at måle fra og disse virker lidt anderledes end de normale sensorer, hvorved vi fik nogle andre thresholds. Vi fik ikke arbejdet med at detektere tre farver, da vi i den sidste halvdel af lektionen brugte et stykke tid på at få vores PC GUI op og køre.
http://www.youtube.com/watch?v=6ZHVAhnLxDw
Vores GUI, lavet i Java/Beans, benytter lejos.pc.comm pakken til at kommunikere med vores NXT robot. Der kan søges efter NXT klodser med et bestemt navn og for at minimere tiden det tager for os at benytte programmet har en ekstra knap der forbinder til vores robot, hugo, ved at forbinde direkte til dens Bluetooth addresse, der er hardcoded ind i programmet. Vores forskellige variable i tabellen bliver hentet fra en data fil gemt ved siden af vores jar fil, så vores indstillinger forbliver der fra gang til gang.
Protokollen for overførsel af variable er; et variabelnavn, en havelåge og vores data efterfulgt af en ny linie, altså:
variabelnavn#variabeldata\n
På NXT klodsen lytter en tråd, BluetoothParameterReciever, efter indkommende forbindelser og modtager og gemmer data’en ned i de korrekte variable. Et problem med lejos API’et opstod her, da vi på afsendersiden sendte vores data med en PrintWriter, men det var lejos ikke glad for, da det gjorde den overførte data korrupt af en eller anden grund, og vi modtog kun den sidste byte afsendt. Vi skiftede til en DataOutputStream og herefter virkede alt som det skulle.
Næste gang vil vi optimere vores robots hastighed ved at prøve at implementere en PID-controller, samt få lavet så den kan detektere når den når de forskellige platforme på rampen så den kan komme helt til tops og ned igen.
Torsdag d. 7/10
Vi startede dagen med at modificere koden til at kunne skelne imellem 3 farver, sort, hvid og grøn. Dette gav os et problem i forhold til at følge en sort linie, da den til tider målte en værdi indenfor vores grønne threshold, når den er på vej fra hvid til sort eller omvendt. Dette løser vi ved at kræve at robotten er inden for den grønne threshold et stykke tid inden vi registrerer at farven er grøn.
Vi forsøgte at få lavet en tråd til hver hjul og lys sensor par, som opererede uafhængigt af hinanden. Vores robot startede med at opføre sig mærkeligt efter vi forsøgte at indføre en proportional styring af vores power. Vi havde meget svært ved at finde ud af hvad der var galt og antog at det var fordi NXT’en ikke havde nok kraft til at håndtere 2 gange PID-controller, en i hver sin tråd. Vi brugte lang tid på at prøve at gøre koden hurtigere, inline flere metoder osv. Til sidst prøvede vi bare at sætte power på begge motorer til 0, selv da vi gjorde det bevægede robotten sig. Vi forstod ikke hvorfor dette skete og spurgte instruktor Lasse. Han sagde at han selv havde haft samme problem. Det skyldes at default indstillingen til styring af de to motorer, er ved at benytte setSpeed, og ikke setPower som vi prøvede på. Løsningen er at kalde regulateSpeed(false); på begge motorer. Standard er værdien true, hvilket resulterer i at setPower ikke virker.
Da vi endelig fik fikset den ovenstående fejl, havde vi under en time tilbage af øvelsesgangen, så vores robot blev derfor ikke meget bedre end en simpel on/off controller. Da vi havde fundet fejlen virkede vores dobbelt tråede PID-controller baserede styring, men på det tidspunkt var det blevet så sent at vi ikke fik justeret vores PID værdier, eller lavet så vores robot kunne registrere et kryds på banen på de forskellige platforme.
Vi indså da at vi måske skulle have fokuseret mere på opgaven som ikke var at følge en linje, men at komme op på toppen af banen og tilbage igen, vores fokus område var altså forkert.
Vi kunne have brugt tid at bygge vores robot så den kørte stabilt og lige, og så timet hvor lang tid det tog den at køre på de forskellige dele af banen, derved effektivt hardcode banen ind i robotten. Vi så senere at netop denne klasse af robotter klarede det rigtigt godt. Der er ikke noget der ændrer sig i miliøet så hvis robotten er stabil kan det være en gyldig strategi.
Vi har generelt lært lejos API’et bedre at kende, samt erfaret at det er vigtigt at fokusere på det rigtige, ellers kan ens tidsplan falde helt fra hinanden. Derudover har vi fået vores PC GUI op og køre, hvilket vil spare os for meget tid i vores eget projekt.
Vi har i dag arbejdet med at få robotten til at følge en linie hurtigst muligt. Vi har benyttet 2 lyssensorer fra RCX robotten til at måle fra og disse virker lidt anderledes end de normale sensorer, hvorved vi fik nogle andre thresholds. Vi fik ikke arbejdet med at detektere tre farver, da vi i den sidste halvdel af lektionen brugte et stykke tid på at få vores PC GUI op og køre.
http://www.youtube.com/watch?v=6ZHVAhnLxDw
Vores GUI, lavet i Java/Beans, benytter lejos.pc.comm pakken til at kommunikere med vores NXT robot. Der kan søges efter NXT klodser med et bestemt navn og for at minimere tiden det tager for os at benytte programmet har en ekstra knap der forbinder til vores robot, hugo, ved at forbinde direkte til dens Bluetooth addresse, der er hardcoded ind i programmet. Vores forskellige variable i tabellen bliver hentet fra en data fil gemt ved siden af vores jar fil, så vores indstillinger forbliver der fra gang til gang.
Protokollen for overførsel af variable er; et variabelnavn, en havelåge og vores data efterfulgt af en ny linie, altså:
variabelnavn#variabeldata\n
På NXT klodsen lytter en tråd, BluetoothParameterReciever, efter indkommende forbindelser og modtager og gemmer data’en ned i de korrekte variable. Et problem med lejos API’et opstod her, da vi på afsendersiden sendte vores data med en PrintWriter, men det var lejos ikke glad for, da det gjorde den overførte data korrupt af en eller anden grund, og vi modtog kun den sidste byte afsendt. Vi skiftede til en DataOutputStream og herefter virkede alt som det skulle.
Næste gang vil vi optimere vores robots hastighed ved at prøve at implementere en PID-controller, samt få lavet så den kan detektere når den når de forskellige platforme på rampen så den kan komme helt til tops og ned igen.
Torsdag d. 7/10
Vi startede dagen med at modificere koden til at kunne skelne imellem 3 farver, sort, hvid og grøn. Dette gav os et problem i forhold til at følge en sort linie, da den til tider målte en værdi indenfor vores grønne threshold, når den er på vej fra hvid til sort eller omvendt. Dette løser vi ved at kræve at robotten er inden for den grønne threshold et stykke tid inden vi registrerer at farven er grøn.
Vi forsøgte at få lavet en tråd til hver hjul og lys sensor par, som opererede uafhængigt af hinanden. Vores robot startede med at opføre sig mærkeligt efter vi forsøgte at indføre en proportional styring af vores power. Vi havde meget svært ved at finde ud af hvad der var galt og antog at det var fordi NXT’en ikke havde nok kraft til at håndtere 2 gange PID-controller, en i hver sin tråd. Vi brugte lang tid på at prøve at gøre koden hurtigere, inline flere metoder osv. Til sidst prøvede vi bare at sætte power på begge motorer til 0, selv da vi gjorde det bevægede robotten sig. Vi forstod ikke hvorfor dette skete og spurgte instruktor Lasse. Han sagde at han selv havde haft samme problem. Det skyldes at default indstillingen til styring af de to motorer, er ved at benytte setSpeed, og ikke setPower som vi prøvede på. Løsningen er at kalde regulateSpeed(false); på begge motorer. Standard er værdien true, hvilket resulterer i at setPower ikke virker.
Da vi endelig fik fikset den ovenstående fejl, havde vi under en time tilbage af øvelsesgangen, så vores robot blev derfor ikke meget bedre end en simpel on/off controller. Da vi havde fundet fejlen virkede vores dobbelt tråede PID-controller baserede styring, men på det tidspunkt var det blevet så sent at vi ikke fik justeret vores PID værdier, eller lavet så vores robot kunne registrere et kryds på banen på de forskellige platforme.
Vi indså da at vi måske skulle have fokuseret mere på opgaven som ikke var at følge en linje, men at komme op på toppen af banen og tilbage igen, vores fokus område var altså forkert.
Vi kunne have brugt tid at bygge vores robot så den kørte stabilt og lige, og så timet hvor lang tid det tog den at køre på de forskellige dele af banen, derved effektivt hardcode banen ind i robotten. Vi så senere at netop denne klasse af robotter klarede det rigtigt godt. Der er ikke noget der ændrer sig i miliøet så hvis robotten er stabil kan det være en gyldig strategi.
Vi har generelt lært lejos API’et bedre at kende, samt erfaret at det er vigtigt at fokusere på det rigtige, ellers kan ens tidsplan falde helt fra hinanden. Derudover har vi fået vores PC GUI op og køre, hvilket vil spare os for meget tid i vores eget projekt.
No comments:
Post a Comment