Thursday, December 2, 2010
Legolab 25/11 - Projekt start
Vi ligger vores blog posts på google docs fremover:
Thursday, November 18, 2010
Lab 18/11 - 2010
Dato: 18/11 - 2010
Varighed: 3 timer
Deltagere: Lasse, Esben og Toke
Dagens mål
I dag fokuserer vi lab sessionen på at undersøge leJOS NXJ behaviour-based kontrol program. Måden vi vil gøre det på er ved at kigge på den inkluderede testklasse BumberCar der ligger i samlples/BumberCar.
Til at gøre dette bruger vi vores NXJ robot hugo der til dagens session er bygget sådan her.
Dagens plan
- Testkørsel af BumberCar.java klassen samt analyse af Arbitrator.java klassen
- Udvidelse af BumberCar klassen med en ny behaviour Exit
- BESKRIV SIDSTE PUNKTER
Testkørsel af BumberCar.java klassen samt analyse af Arbitrator.java klassen
For at kunne arbejde med BumberCar klassen startede vi med at køre klassen i standard form på vores NXJ robot. Ud fra dette kunne vi observere at vores robot altid forsøger at køre ligefrem, indtil der skulle komme noget ind foran vores robot. Hvis robotten registrerer noget foran sig vil den forsøge at undgå dette ved at dreje væk fra den.
Ved at kigge på BumberCar koden kan vi udlede at den har en behaviour DetectWall, som er en subklasse af Behaviour, der står for denne undvigelse.
Uden at genfortælle hele strukturen som de bruger i deres behaviour kontrol så fungerer den ved at have implementeret en funktion takeControl() der returnerer true hvis har opdaget noget og gerne vil have kontrollen.
[CODESNIPPET]{
public boolean takeControl() {
return touch.isPressed() || sonar.getDistance();
}
Her vises implementation af takeControl(). touch og sonar er henholdsvis en TouchSensor og en UltrasonicSensor fra det leJOS NXJ API.
Ved at holde touch knappen nede vil takeControl returnere true hver gang Arbitrator.java tjekker for hvilken behaviour der skal være aktiv.
Mens vi kigger på Arbitrator.java så kan vi med det samme udlede at man starter fra den behaviour med højest prioritet og derfra arbejder sig nedad indtil man har fundet en behaviour der gerne vil have kontrol over robotten. Dette betyder altså at behvaiourer ikke vil få kaldt deres takeControl() funktion hvis der er en behaviour med højerer prioritet der returnerer true i takeControl().
[CODESNIPPET]{
_highestPriority = NONE;
for (int i = maxPriority; i >= 0; i--) {
if (_behavior[i].takeControl()) {
_highestPriority = i;
break;
}
}
int active = _active;// local copy: avoid out of bounds error in 134
if (active != NONE && _highestPriority > active) {
_behavior[active].suppress();
}
Ovenstående er et uddrag fra Arbitrator.java i metoden run(). Det viser hvordan man går igennem alle behaviours (behaviour er et array med alle behaviours) og spørger hver af dem om de gerne vil tage kontrol. Hvis metoden finder en behaviour der vil så breaker den og suppresser den behaviour der er aktiv.
Udvidelse af BumberCar klassen med en ny behaviour Escape
For at lære yderligere omkring Behaviours og hvordan de fungerer, prøvede vi som næste skridt at lave vores egen simple Behaviour og tilføje den til BumberCar.java. Vi kaldte denne behaviour for Escape
[CODESNIPPET]
class Escape implements Behavior{
public boolean takeControl() { return Button.ESCAPE.isPressed(); }
public void action() { System.exit(0); }
public void suppress() {}
}
Her ses vores simple behaviour der implementerer Behaviour og de metoder der følger med.
Denne behaviour blev tilføjet til vores behaviour liste som den sidste behaviour og dermed den behaviour med højest prioritet (Se inkluderede BumberCar.java fil for at se inkluderingen).
Ved testkørslen af dette opdagede vi noget uventet. Robotten slukkede ikke ned med det samme hvis man trykkede på NXJ robottens escape knap samtidig med at robotten var i gang med at udføre action funktionen i DetectWall behaviouren så blev man nødt til at holde knappen inde til dens action var færdig.
Hvis man kigger inde i DetectWall.action() så finder man følgende kode:
public void action() {
_suppress = false;
Motor.A.rotate(-180);// start Motor.A rotating backward
Motor.C.rotate(-360); // rotate C farther to make the turn
} Denne kode kører to metode kald til motorerne med rotate. Ved at kigge leJOS NXJ API så kan man ved denne metode se de er blokkerende metoder hvilket forklarer hvorfor vi skal holde knappen inde.
Litteraturliste
BumberCar.java : STI TIL KLASSE
Arbitrator.java STI TIL KLASSE
Behaviour.java STI TIL KLASSE
Thursday, November 11, 2010
Lab 11/11-2010
Dato: 11/11
Varighed: 3 timer
Deltagere: Philip, Lasse, Toke og Esben
Dagens mål
At arbejde med navigation for lego NXT robotten. Først vil vi teste lejos.robotics.navigation.TachoPilot og måle hvor præcis denne er. Herefter vil vi implementere to-lags opførsel på robotten så den undgår kollisioner.
TachoPilot
En vigtig ting når det kommer til navigering via tacho counters, er at minimere friktionen samt at maksimere grebet med underlaget. Robotten blev programmeret til at køre i en geometrisk figur 10 gange (et kvadrat med sidelængde 30 cm).
TachoPilot tachoPilot = new TachoPilot(8.16f, 11.2f, Motor.C, Motor.B);
tachoPilot.setSpeed(100);
tachoPilot.forward();
for (int i = 0; i <>
for (int j = 0; j <>
tachoPilot.travel(30);
tachoPilot.rotate(90);
}
}
Vi satte vores rotationshastighed til 100 grader i sekundet på et hjul med en diameter på 81,6mm. Dette fik vores robots hjul til at skride ud, hvilket fik robotten til at tabe sin kurs og ikke følge den ønskede figur. Ved at reducere hastigheden fik vi maksimeret vejgrebet, hvilket er med til at minimere robottens drift[1].
Med en rotationshastighed på 30 grader i sekundet, noterede vi en afvigelse fra nulpunktet på ca. 1,5 cm pr kørt figur.
Robotten blev efterfølgende sat til at rotere 360 grader på stedet, og herefter rotere tilbage til udgangspunktet. Med den korrekte rotations hastighed (vi benyttede 10 grader i sekundet) roterede robotten kun lige over 300 grader, men roterede dog tilbage til næsten samme udgangspunkt, her med en afvigelse på et par grader. Dette virker mere som et problem med konfigurationen af robottens forskellige størrelser, end et problem med tacho counterne, da robotten netop roterer tilbage til det originale udgangspunkt korrekt. Ved at sætte afstanden mellem vores hjul op med yderligere 0,1cm kørte robotten næsten en fuld cirkel og roterede tilbage til sit udgangspunkt. Da der ikke var påsat en tusch til at tegne stien. må vi estimere på afvigelsen - vores estimat er 355 grader.
For at kunne stole på tacho counterne er det altså vigtigt at robottens konfiguration af diverse fysiske afstande er så korrekt som muligt samt at grebet mellem hjulene og overfladen maksimeres.
Navigation mens der undgås kollision
Målet for vores robot er at køre til et givent punkt og køre rundt om eventuelle forhindringer. Til dette definerede vi to behaviours, navigation behaviour og evasion behaviour, der blev hvor evasion opførslen undertrykker navigationen vha. supress mekanismen fra [2]
Navigation behaviour benytter SimpleNavigator og kører til et givent koordinat via funktionen goTo(x,y). Et problem vi opdagede da vi testede opførslen for sig selv, er at et kald til GetX() eller GetY() på en anden tråd, får det synkrone kald til goTo(x,y) til at afbryde og de indre værdier for x og y bliver forkerte. Et kald til goTo(100,0), som får robotten til at køre 1 meter ligeud, fik robotten til at køre i en halvcirkel da vi samtidig på hovedtråden pollede efter dens position og udskrev dette.
Evasion laget søger efter en forhindring, og hvis der findes en, undertrykkes navigationen, der drejes 90 grader og køres 20 cm, hvorefter navigationen igen overtager. Der gemmes ingen state og reagerer direkte på input.
while (true) {
while (sonicSensor.getDistance() > tooCloseThreshold) { //threshhold is 20cm
}
suppress();
rotate(90);
travel(20);
release();
}
Vi har observeret at robotten kan finde på at dreje med kun et hjul, hvor (ifølge dokumentationen) at SimpleNavigator blot drejer på stedet (robotten benytter differential drive). Den observerede opførsel kan være et resultat af udefineret opførsel hvis den synkrone metode goTo(x,y) bliver afbrudt. En mulighed her er at benytte den asynkrone version af goTo eller programmere vores egen navigation.
Der er enkelte fejl som nævnt ovenfor, der kunne forbedres, men generelt virker robotten fint, og kører korrekt hen til sit mål. Den lider af samme problemer som TachoPilot robotten, nemlig at den skyder lidt ved siden af, hvilket forværres drastisk hvis grebet med overfladen ikke er god nok.
[1] Brian Bagnall, MAXIMUM: LEGO NXT, Building Robots with Java Brains
[2] Rodney Brooks, MIT AI Memo 864, September 1985
Thursday, November 4, 2010
Lab 4/11-10
Vi har idag været:
Toke, Esben og Philip (Lasses søn var syg)
Vi har arbejdet fra 11 til 14
Opsætning
Vi starter med at hente SoundCar.java og overføre det til nxt'en. I programet er der 3 behavoiurs som kører simultant men supressor hinanden.
Test
Vi tester programmet med forskellige antal behaviours og de opfører sig som forventet, de supressor hinanden. Når der f.eks bliver spillet lyd stopper robotten altid med at køre, også selv om den er ved at avoide.
Daemon Tråde
Behaviour tråedene bliver sat som daemon threads, for at den virtuelle maskine skal lukke ned når SoundCar.java (som har kører i main tråden) lukker ned. Vi skal altså ikke vente på behaviourne når vi vil sukke programmet.
Counters vs Booleans til supression
Behaviour klassen bruger counters til at styre supression. Grunden til at bruge counters i stedet for en simpel boolean er at hvis man bruger booleans, så vil en behaviour når den releaser sin underbehaviour også release sit "barnebar". Det kan være det barnebarnets far med vilje allerede har supressed sit barn. Den supression vil så blive brudt. Med counters sker det ikke.
Det er vigtigt at forstå at behaviours altid kører og udregner, også selv om de er supressed.
Prioritet vs Heirarky
Forskellen på den kode vi kører med behaviours og den kode som Fred Martin kører er at Martin's kode bruger en central styrings algoritme til at bestemme hvilke tråd der skal køre. Vores tråde kører altid, selv om de ikke får lov til at give udput. For os er det trådenes heraki der bestemmer udput og ikke prioritet.
Lys behaviour
Vi laver en TowardLight behaviour, som skal styre robotten imod lys når det er meget stærkt.
For at få triggered vores behaviour laver vi en treshold for hvornår lys er for lyst til at ignorere.
Vi har sat TowardLight til at supresse de andre behavious, når den ser lyset går den efter det.
Thursday, October 28, 2010
Lektion 7
Lektion 7
Dato: 28/10 - 2010
Tid arbejdet: kl 11 til 14
Deltagere: Lasse Staal, Esben Andersen og Toke Brødsted
Bil 1
Ved starten af denne lektion begyndte vi at implementere den første type bil som skal køre hurtigere jo højere lyde den registrere. Dette løste vi ved at lave en 1 til 1 mapping fra lyd registreret til motor power da begge har en skala fra 0 til 100.
Bil 2 - lys
Den anden bil koder vi ved at bruge samme klasse som bil 1 da vi ved løsningen hertil havde sat to motorer til bare at køre som var det en motor. Måden vi gør det på er at lave en specifik run metode til hver type bil. Dette gør at vi hurtigt kan teste de forskellige biler i forhold til hinanden.
Første implementation af bil 2 laves ved at des mere lys registreret på højre lyssensor før højre hjul til at køre hurtigere rundt.
Den anden implementation bytter om på dette så des mere lys registreret ved højre lyssensor des hurtigere kører højre hjul.
Ved begge vores implementationer med lyssensorer har vi valgt at implementere en normalize funktion som ændrer den registrerede lys værdi om til en værdi som vi kan få vores motorer til at køre. Denne metode er taget direkte fra [3], Tom Dean, Notes on construction of Braitenberg's Vehicles, Chapter 1-5 of Braitenbergs book.
Videoen viser at bilen følger lyset da den side hvor lyset er kraftigst kører langsomt. Man kan se at robotten drejer primært til den ene side. Dette skyldes at den sides lyssensor registrerer højere værdier end den anden side.
For at få robotten til at køre lige har vi hardcodet noget kalibrering i koden så robotten nu kører lige:
Herefter byttede vi om på sensor portene så robotten nu flygtede fra lyset frem for at køre mod det
Bil 2 - lyd
Vi havde kun en lydsensor til rådighed da vi kom til denne opgave så vi har valgt at løse denne opgave teoretisk.
Man burde sagtens få en robot til at bevæge sig efter lyden alt afhængigt af hvor godt lydsensorerne kan måle lyden, hvor langt de er fra hinanden. Man kan eventuelt lave en lille væg mellem de to lydsensorer for at bryde lyden i mellem dem og få en større afstand.
Bil 2 - lyd og lys
Ved næste opgave hvor vi skulle indføre en inhibitor valgte vi at lave en lydsensor hvis værdi vi trækker fra motorernes kraft. Udover den nye lydsensor så kører den præcist som i bil 2 med lyd.
Bil 2 - Dynamisk
Dette løste vi ved at flytte lyssensorerne ud i en thread som selv registrede maks og min værdier som der så blev gemt. Registrere hele tiden nye værdier.
I den sidste video her kan man se resultatet fra i dag. Det viser at robotten gemmer nye lys værdier og den kan konfigurere sig selv til at køre lige ud.
Saturday, October 16, 2010
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.
Thursday, September 23, 2010
Lego labøvelse 4
Balancerende robot
Denne uge står laboratorie-udfordringen på en selv-balancerende robot. Ved brug af en lyssensor skal vi bedømme om vores robot står oprejst eller er ved at falde til en side - og derpå ved hjælp af motorerne hjælpe robotten tilbage i balance.
Idag er Toke, Phillip og Esben tilstede, Lasse er syg.
Forsøg 1:
Bygge-fasen var simpel og kort, det tog omkring 2 min at samle den nye robot.
I mellemtiden var balance programmet blevet downloadet og gjort klar til overførsel. Den første kørsel fejlede øjeblikkeligt; Robotten startede og væltede inden for 1 sekund.
Forsøg 2:
Vi forsøgte at finde den value der passede med ligevægt, og forsøgte at hard-code denne ind i programmet. Dette gav umiddelbart en fordel; Det var muligt for os at finpudse denne værdi og dermed ikke være afhængig af at hole robotten helt ens under start længere.
Forsøg 3:
Efter noget finpudsning af lys-sensor threshold. begyndte vi at rode med de forskellige gains. Det var dog stadig ikke muligt for os at finde en indstilling som kunne få robotten til at balancere mere end 1-3 sekunder.
På dette tidspunkt er den første time gået.
Datalog:
Da vi ikke helt var klar over hvorfor vores program fejlede, besluttede vi at indføre en datalogger, så vi kunne få en graf over udviklingen; Og måske klarlægge årsagen til vores fejlende program.
Fra den graf vi fik ud, kunne vi konkludere at vores robot overskød mere og mere og derfor uundgåeligt væltede.
Forsøg 4:
Efter tilføjelse af datalogger kørte vi flere forsøg hvor vi igen prøvede forskellige gain-indstillinger. Da vi havde behov for at skifte omåde og underlag måtte vi sætte initial indstilling af threshold tilbage i robottens program.
Sidste udkald:
Efter nogle timers frustrationer over vores robot og da tiden var ved at være udløbet, gik det op for os at vi havde arbejdet på et dårligt underlag. underlaget havde været et bord som havde en skinnene overflade. Da vi skiftede til at køre på et stykke farvet papir gik det bedre - men robotten ville stadig ikke balancere helt.
Vores sidste udkast til programmet (som stadig ikke virker):
Thursday, September 16, 2010
Lego labøvelse 3
SoundSensorTest
I starten af øvelsen monterede vi lydsensoren på fronten af vores robot så vi kunne teste vores første testprogram SoundSensorTest.java. Dette program er meget lige UltraSonicTest.java hvor vi ændrede Sensor porten til SoundSensor og læste dB i stedet for distance.
Ved at stille robotten på et punkt hvorfra vi ændrede vores afstand til robotten kunne vi aflæse at dB værdien ændrede sig alt efter hvor langt eller tæt på vi var fra robotten.
SoundSensorTest.java
Datalogger
Tilføjelsen af dataloggeren til vores robot gik smertefrit. Det samme kan også siges om testen af selve loggeren. Til selve graf repræsentationen af vores indsamlede data krævede det dog at vi ændrede en smule i datalogger klassen så den skrev ud i et format vi kunne bruge sammen med GnuPlot.
DataLogger.java
Vi har lavet et plot hvor vi laver lidt forskellige lyde:
Sound controlled car
Ved testen af SoundCtrCar.java fandt vi ud af at robotten står og venter på at registrere en høj lyd, i koden er det speciferet til at være 90 dB (LeJOS defination af dB). Efter at have registreret en høj lyd cykler robotten igennem en prædefineret sekvens af bevægelser: frem, højre, venstre, stop.
For at løse problemet med at escape er i det yderste loop laver vi en button listener hvis funktion er at lytte efter tryk på bestemte knapper og på den måde bryde vores loop.
SoundCtrCar.java
Clap controlled car
Ved implementationen af vores klap kontrollerede bil fandt vi ud af at det er noget vanskeligere at definere et klap i forhold til bare at registrere en høj lyd. Nogen af de problemer vi løb ind i var at timingen skulle være rigtig for at definationen var korrekt. Desuden så var der også den faktor at vi sad i et stort lokale med masser af andre grupper der larmede, hvilket vores robot selvfølgelig også registrede.
ClapCar.java
Thursday, September 9, 2010
Lego Lab 2
Vi fik bygget vores robot om så den nu også inkluderer en sonar sensor. Vi installerede test programmet og begyndte at teste vores sonar. Ud fra en plan væg hvor sensoren står vinkelret ind på, kan vi måle op til ca. 230 cm fra væggen, herefter vises "no object". Hvis overfladen er skrå (en kasse lænet op ad en væg for eksempel) eller hvis sensoren måler lidt skråt ind på overfladen, reduceres den maksimale afstand vi kunne måle en del. Materialet af overfladen betyder også noget, og ved "støjabsorberende" materiale alla en trøje, har den svært ved at måle korrekt.
I programmet er måleintervallet 300 ms, hvilket vi prøvede at ændre. Vi har sat den til 20 ms uden problemer, da vi beregnede at ved den maksimale afstand (255 cm) vil lyden være ca 14 ms om at nå ud til overfladen og reflektere tilbage. Ved at sætte måleintervallet til 5 ms måler den nogle lidt sære afstande længere ude.
Tracker programmet vi fik udleveret benytter en P-D controller, med et gain på 0.5. Dens standard instillinger får den til at opnå en tilstand hvor den oscillerer frem og tilbage omkring 35 cm. Vi prøvede ikke at tweake på de forskellige parametre men et lavere gain burde få den til at stoppe med at oscillere (men kan risikere at stoppe uden at ramme dens desired state, hvilket kunne fikses med et integral led).
I sidste del af opgaven implementerede vi en wallfollower baseret på vores tidligere linefollower. Den benytter en P-D controller. Efter vi fik tilpasset gainet korrekt, kører den næsten ude oscilationer hen langs en væg. Kommer der en forhindring kører vores robot rundt om, dog med en begrænsning. Da sonar sensoren er monteret i en 45* vinkel betyder dette at hvis vi kommer ind i et hjørne hvor væggene har en vinkel mindre end dette, vil vi ikke kunne se den indkommende væg og robotten kører ind i hjørnet.
Sammenlignet med three_state algoritmen opnår robotten aldrig en tilstand hvor den skal korrigere voldsomt for at komme tilbage imod vores desired state da vi altid laver små korrigeringer når vi er tæt på vores desired state. Sammenlignet med gentle turn og hard turn algoritmerne, fandt vi at vores P-D controller baserede robot oscilerede væsenligt mindre, hvilket skyldes at vi benytter en gain funktion.
Thursday, September 2, 2010
Lab øvelser 1
Vi startede med at få bygget standart robotten, mens vi lagde drivere ind på computeren.
Vi havde ingen problemer med at få lagt lejos ind, og robotten kørte fint efter den sorte streg.
Der var nogle problemer med vores ene motoer men vi fik bare en ny.
Ved at sætte sample tiden op oplevede vi at robotten havde svært ved at følge efter stregen da den tit nåede at dreje for langt til den ene siden inden den opdagede stregen, og kørte derfor i ring.
Ved 500ms kunne den følge stregen nogenlunde. Men ved 1000ms kørte den bare "tilfældigt" rundt.
Vi målte lys censorens værdier for forskellige matrialer, med og uden flodlight tændt.
Målinger - Med lys
Ahorn 52
Gråtbord 50
Blåt gulv 35
Whiteboard 54
Sort streg 33
Grå væg 47
Rød Stol 41
Blankt Metal 43
Målinger - Uden lys
Ahorn 43
Gråtbord 35
Blåt gulv 27
Whiteboard 43
Sort streg 27
Grå væg 35
Rød stol 37
Blankt metal 27
Generelt er værdierne væsentligt lavere uden lyset.
Ved at indtaste strenge direkte i metoderne, benyttede vi hurtigt al heapspacen og der måtte ofte køres garbage collection. Derfra kan vi aflede at generelt skal strenge gemmes i variable så de ikke fylder for meget.
Vi havde ingen problemer med at få lagt lejos ind, og robotten kørte fint efter den sorte streg.
Der var nogle problemer med vores ene motoer men vi fik bare en ny.
Ved at sætte sample tiden op oplevede vi at robotten havde svært ved at følge efter stregen da den tit nåede at dreje for langt til den ene siden inden den opdagede stregen, og kørte derfor i ring.
Ved 500ms kunne den følge stregen nogenlunde. Men ved 1000ms kørte den bare "tilfældigt" rundt.
Vi målte lys censorens værdier for forskellige matrialer, med og uden flodlight tændt.
Målinger - Med lys
Ahorn 52
Gråtbord 50
Blåt gulv 35
Whiteboard 54
Sort streg 33
Grå væg 47
Rød Stol 41
Blankt Metal 43
Målinger - Uden lys
Ahorn 43
Gråtbord 35
Blåt gulv 27
Whiteboard 43
Sort streg 27
Grå væg 35
Rød stol 37
Blankt metal 27
Generelt er værdierne væsentligt lavere uden lyset.
Ved at indtaste strenge direkte i metoderne, benyttede vi hurtigt al heapspacen og der måtte ofte køres garbage collection. Derfra kan vi aflede at generelt skal strenge gemmes i variable så de ikke fylder for meget.
Subscribe to:
Posts (Atom)