ESEA - Labnotes

NXT Programming - Lektion 11
Varighed: 3.5 timer - kl. 9:00-12:30
Gruppemedlemmer: Aslak, Ruben og Lars

Gruppens mål for dagens lektion:

• lave en beskrivelse af vores projekt
• opbygge en blokopdelt oversigt over komponenter i projektet
• diskutere mulige løsninger på de enkelte blokke
• diskutere mulige krav til hardware (hvilke sensorer, antal osv.)

Idet vi har snakket om hvilket projekt vi gerne ville give os i kast med i forbindelse med afslutningen af dette fag (ESEA - embedded systems, embodied agents) var vi ved lektionens opstart ret afklarede omkring projektets afgrænsning.

Projektet omhandler navigation af en gaffeltruck (eller andet transportkøretøj), eksempleficeret ved en Lego NXT robot, i et afgrænset miljø (lagerbygning/fabrikshal). Robotten skal kunne tage hensyn til andre i området, herunder andre transportkøretøjer (hermed sagt at vi gerne vil have adgang til 2 NXT'er ialt). Der skal laves en undvige-funktionalitet, som ikke forstyrrer den overordnede navigation. En overordnet styrende computer (big-brother) giver ordre til transport-robotten, og herefter udffører robotten opgaven på egen hånd. Hvilke informationer som denne "ordre" skal indeholde er ikke fastlagt endnu.

Den blokopdelte oversigt over projektet ser pt ud som følger (se linket):

http://userportal.iha.dk/~20060651/dokumenter/projektbeskrivelse.pdf

Mulige krav til hardware:

Vi forventer at kunne bruge de medfølgende motore og sensore fra NXT-kittet. Dog håber vi på at have 2 NXT'er at arbejde med, og hermed også ekstra motore og sensore. Det udarbejdede dokument, som kan ses via ovenstående link, beskriver hvilke ting vi forventer at skulle bruge, og hvor mange.

Med hensyn til mulige løsninger på de enkelte blokke på projektoversigten har vi i gruppen diskuteret forskellige tilgange til bl.a. robottens kørselsmønster. Det skal besluttes om robotten skal køre midt på en midterstribe, eller om den skal køre på højre side af en midterstribe. Yderligere skal det besluttes, hvordan robotten tackler sving. Om den skal køre ind på midten, rotere om sig selv, for at have størst mulig viden om sin egen placering, eller om den skal svinge på en mere "normal" måde. Det blev besluttet at vi først vil træffe valg omkring den endelige løsning af de forskellige blokke, når vi går i gang med blokkene. Altså har vi på denne måde mulighed for at afprøve en eller flere mulige løsninger inden vi træffer beslutningen. Også på området omkring kommunikation mellem styrecomputer og robot skal der træffes valg omkring hvilke informationer som skal kommunikeres frem og tilbage. Skal robotten modtage en "kørselsvejledning" eller blot en kendt destination. Disse valg og overvejelser vil blive beskrevet nærmere, når vi påbegynder løsning af selve opgaven.

ESEA - Labnotes

NXT programming - Lesson 10
Varighed: 4.5 timer - kl. 09.00-13.30
Gruppemedlemmer: Aslak, Ruben og Lars

Gruppens mål for dagens lesson:

• At undersøge hvorledes en behaviour-baseret arkitektur er implementeret i subsumption API'en.
• At følge dagens lektion og først implementere og observere "BumperCar" robotten
• At udvide "BumperCar" robotten med en ny behaviour
• At forsøge med en ny "Arbitrator", som er den kode som styrer hvilke behaviours som skal "køres"

Det første der blev gjort, var at montere en tryksensor på køretøjet. Dernæst hentes klassen 'BumperCar.java' og downloades til NXT'en. Programmet startes og køretøjets opførsel observeres. Da vores design af køretøj fra sidste gang ikke svarer helt overens med, det der var tiltænkt i dag, er der "byttet rundt på" forward og backward. Derfor ændrede vi dette i koden, for at rette op på dette. Programmet downloades igen og bilens opførsel observeres. Det ses at bilen kører fremad. Når tryksensoren bliver aktiveret, bakker bilen
lidt og korrigerer herefter en anelse til højre.

Køretøjets tryksensor bliver til tider ikke trykket ordentligt ind, som ønsket,
hvilket resulterede i at køretøjet fortsatte ind i "væggen". For at afhjælpe dette, påmonterede vi endnu en tryksensor og anordninger, der hjælper med bedre at trykke sensorerne ordentligt ind. Denne sensor tilføjes også i "HitWall.java", således at et tryk på en af tryksensorerne returnerer TRUE fra takeControl().
Den omtalte kodeændring kan ses i følgende uddrag:

public class HitWall implements Behavior{
TouchSensor touch1 = new TouchSensor(SensorPort.S2);
TouchSensor touch2 = new TouchSensor(SensorPort.S3);
public boolean takeControl() {
boolean t1 = touch1.isPressed();
boolean t2 = touch2.isPressed();
return (t1 t2);
}
.
.
.
}

Køretøjet kan ses på følgende billede.


Ovenstående billede viser robottens "stødtænder" som opfanger , når robotten kører ind i noget.


Ovenstående billede viser robottens opbygning, set fra siden.


Ovenstående billede viser robotten tæt på en væg, dvs. tæt på at få aktiveret den venstre tryksensor.


Dette billede viser et "close-up" af tryk-sensor systemet. Selve tryksensoren har den indbyggede svaghed, at kontakten skal trykkes ind vinkelret, for at sensoren virker. Derfor skal der bygges tilbygning på, foran tryk-sensoren, for at robotten registrere at den kører ind i ting fra forskellige vinkler.

Det undersøges herefter hvad der sker, hvis en af tryksensorerne trykkes ind og holdes inde.
Når sensoren trykkes ind, bakker køretøjet et stykke tid og korrigerer herefter til højre (pga HitWall.java). Herefter holder køretøjet helt stille. Dette fortsætter indtil sensoren slippes igen. Denne opførsel sker fordi takeControl() holdes til TRUE fra den tidligere behaviour. Dette resulterer i at action() ikke køres igen. En behaviour kan ikke køre flere gange i træk. Der skal ske noget andet inden den samme behaviour kan køre igen. I afsnittet "Coding Solid action() and suppress() Methods" fra " The leJOS Tutorial" under afsnittet "Behaviour" af Brian Bagnall, er netop denne problemstilling beskrevet.
Denne tutorial kan findes via følgende link:

http://lejos.sourceforge.net/p_technologies/rcx/tutorial/behavior/index.html

Der implementeres endnu en behaviour, 'TuneBehave.java', der spiller en meget kort melodi.
Klassen så ud, som følger, ved timens afslutning:
(det skal nævnes at vi har eksperimenteret en del, bl.a. med at bruge tryk-sensorene også, hvilket koden bærer en del præg af)

public class TuneBehave implements Behavior{
private static final short [] note = {
2349,115, 0,5, };
TouchSensor touch1 = new TouchSensor(SensorPort.S2);
TouchSensor touch2 = new TouchSensor(SensorPort.S3);
public boolean takeControl() {
boolean i = true;
while(i) {
i = false;
try{Thread.sleep(3000);}catch(Exception e){}
return false;
}
return true;
}
public void suppress() {
}
public void action() {
for(int i=0;i

Denne tredje behaviour kom aldrig til at virke, som vi gerne ville have den til, så vi kom aldrig til at se at HitWall styrede motorerne, selvom den er undertrykt. Dette gør det meget svært for os at svare på, hvorfor dette er tilfældet. I den ovennævnte tutorial "Behaviour" nævner Brian Bagnall, at der specielt mht. tråde kan opstå problemer med at undertrykke dem med "suppress" funktionaliteten. Om det kan være her at svaret skal findes kan vi ved lektionens afslutning ikke svare på. Vi må spørge en "Teaching Assistant"', eller Ole C. ved nærmeste lejlighed.

Den nye behaviour tilføjes i klassen 'BumperCarAb2.java', med højeste prioritet:

public class BumperCarAb2 {
public static void main(String[] args) {
Behavior b1 = new DriveForwardAb2();
Behavior b2 = new HitWallAb2();
Behavior b3 = new TuneBehave();
Behavior [] bArray = {b1, b2, b3};
Arbitrator2 arby = new Arbitrator2(bArray);
Motor.A.setSpeed(400);
Motor.C.setSpeed(400);
arby.start();
}
}

Det blev forsøgt at køre med den nye Arbitrator (vi kaldte den Arbitrator2). Når denne blev benyttet, kunne det observeres, at en behaviour godt kunne køres flere gange i træk. Bilen kunne bakke og korrigere
flere gange i træk, når sensoren holdes inde.

Her er en lille film, hvor robottens opførsel kan ses:

ESEA - Labnotes

NXT Programmering - Lektion 9
Varighed: 3.5 timer - kl. 09:00-12:30
Gruppemedlemmer: Aslak, Ruben og Lars

Gruppens mål for dagens lesson:

• Undersøge hvordan NXT'en navigerer vha. tachocounterne

Det første der blev gjort var at bygge robotten efter vejledningen på side 292 i Chapter 12 af Brian Bagnall. (Udleveret kopi).Robotten kom dermed til at se således ud (se Billede 1 og Billede 2).

Billede 1

Billede 2

Testprogrammet der er givet på side 298 i Chapter 12 af Brian Bagnall, blev lagt ned på XT'en.Testprogrammet fører køretøjet rundt til forskellige destinationer i et koordinatsystem. Dette blev forsøgt flere gange, og afvigelsen fra startpunktet til slutpunktet, der burde være det samme sted, blev målt. Målingerne blev foretaget ved at lægge en mønt under det højre hjul, ved start og slut og måle afstanden imellem disse mønter.Da køretøjet efter endt kørsel næsten havde den modsatte retning af startretningen, tillader vi os at trække 16 cm fra, der er afstanden imellem hjulene.Dette er dog ikke en helt pålidelig måling, da retningen ikke er 100 % modsat, men der er en vinkelforskel. Der er altså en vis usikkerhed ved metoden. Det giver dog en indikation af afstanden mellem start og slut, og de enkelte målinger i serien er sammenlignelige.

Med hjulet: Måling 1: Måling 2: Måling 3: Måling 4: Måling 5: Måling 6: Måling 7:
Vi blev gjort opmærksomme på at det kunne give lidt problemer med forhjulet, der kunne være med til at bringe køretøjet ud af kurs, både under ligeud-kørsel og i svingene. Derfor blev der også foretaget en udskiftning af forhjulet med et "støtteben" med en "glide-klods" i bunden. Dette ses på Billede 3:

Billede 3

Med støttebenet:

Måling 1:
Måling 2:
Måling 3:
Måling 4:
Måling 5:
Måling 6:
Måling 7:


Ud fra vores målinger var tendensen dog at køretøjet blev mere upræcist med støtte benet, så vi valgte at gå tilbage til hjulet.
Efterfølgende førsøgte vi at montere en sprittusch på køretøjet, så vi kunne følge køretøjets bane på en tavle der var opstillet horisontalt.

Billede 4

Billede 5

Det blev forsøgt at skifte hjulene til forskellige typer (og huske at ændre dette i koden) for at se om der kunne opnås et bedre resultat. Det blev dog ikke på noget tidspunkt bedre end det originale køretøj.

ESEA - Labnotes

NXT Programming - Lektion 8
Varighed: 5.0 timer - kl. 9:00 - 14:00
Gruppemedlemmer: Aslak, Ruben og Lars

Dagen i dag startede lidt rodet op, og der gik et godt stykke tid inden vi påbegyndte dagens dont.
Inden vi påbegyndte arbejdet med dagens lektion gik vi Oles kode for det flertrådede projekt igennem, for at gennemskue det og se, hvordan det adskiller sig fra vores tidligere kode. Vi har i tidligere lektioner oplevet uventede exceptions, når vi har forsøgt at skrive ud på NXT'ens display fra forskellige tråde. Dette lykkes meget smart med Oles kode og vi har nu, med denne kode, et godt udgangspunkt, både for denne lektion, og fremtidige opgaver.

Dagens mål:

• Opnå en bedre forståelse for håndteringen af tråde. Dette punkt er et gennemgående punkt, både for den første og anden halvdel af lektionen.
• Første del af dagens lektion; Prøve 'BehaviourTest1.java' og de tilhørende filer, samt at undersøge robottens opførsel med hhv. den første 'behaviour' tråd, de første 2 'behaviour tråd' og alle 3 tråde.
• Tilføje en "behaviour" fra Lektion 7. Denne opførsel er at køre mod lys. Det skal overvejes hvordan denne tråd skal implemeteres og hvilke andre 'behaviours' den kan undertrykke. Er det vigtigere at spille en melodi, som tråden 'PlaySounds.java' gør, eller at køre imod lyset ?

Det var til denne lesson ikke muligt at benytte den computer vi hidtil havde benyttet i forbindelse med øvelserne. Eftersom vi tidligere ikke havde kunnet få kommunikationen imellem NXT'en og de andre computere til at virke, stod vi over for lidt af et problem. Efter en vis eksperimenteren, viste det sig, at den ene computer alligevel kunne bruges. Det var dog ikke helt problemfrit. Flere gange var det nødvendigt at lukke og genstarte Eclipse for at downloade klasserne til NXT'en.

Det første punkt på dagsordenen, at få større forståelse for tråde, blev både dækket af det indledende arbejde, hvor vi gennemgik Oles kode, samt da vi skulle skrive vores egen tråd 'DriveTowardsLight.java'.

Den første del - 'BehaviourTest1.java'

'BehaviourTest1.java' starter de 3 tråde, kodet i 'RandomDrive.java', 'AvoidFront.java' og 'PlaySounds.java' og lader dem efterfølgende køre indtil 'escape'-knappen trykkes ned.
Som det første downloades programmet 'BehaviourTest1.java', efter at de 3 nye klasser er blevet oprettet i Eclipse, og køretøjets opførsel samt udskriften på LCD displayet observeres. I displayet er de tre behaviours/tråde repræsenteret på hver sin linie. Efter navnet på hver behaviour/tråd står der 0 eller 1, hvor '1' indikerer, at den enkelte behaviour/tråd bliver undertrykt/supressed og '0' indikerer at den ikke bliver undertrykt. Som nævnt i indledningen har vi tidligere haft problemer med at få tråde til at udskrive i displayet, hvilket Oles kode klarer fint. Til forskel fra det vi tidligere har forsøgt, tildeles trådene en linie i displayet, som den pågældende tråd herefter opdaterer, uden at ændre på det som ellers udskrives i displayet.

Ved at starte 'RandomDrive'-tråden alene, ses det tydeligt, hvordan tråden styrer robotten. Koden for tråden ses her:

reportState();
Locomotion.forward((int)(50+50*Math.random()),(int)(50+50*Math.random()));
delay((int)(500+1000*Math.random()));
reportState();
Locomotion.stop();
delay((int)(1500+1000*Math.random()));

Robotten kører fremad på begge hjul, med 'tilfældig' hastighed på hhv. højre og venstre hjul, herefter kører den i perioden (500+1000*Math.random()), udskriver sin tilstand i displayet og venter (laver ingenting) i perioden (1500+1000*Math.random()). Denne opførsel virker meget tilfældig, når robotten observeres. Robotten opleves som 'vægelsindet', altså ubeslutsom og med skiftende forkærlighed for den retning den sidst bevægede sig i.

Ved at starte 'AvoidFront'-tråden sammen med 'RandomDrive'-tråden, ses det, hvordan de styrer robotten. 'AvoidFront' foretager sig intet, sålænge der ikke 'ses' noget med den påmonterede ultralydssensor. Mere præcist fortalt måles konstant den afstand som aflæses med ultralydssensoren, og kun når den målte afstand når ned under en givet tærskel reagerer tråden og griper ind i robottens opførsel. Tråden starter med at undertrykke 'RandomDrive', noget som er gjort muligt vha. Oles kode, hvor alle trådene egentlig er baseret på klassen 'Behaviour'. Efter at undertrykke 'RandomDrive' sørger 'AvoidFront' for at robotten først bakker lige bagud i et sekund (Delay(1000)) for derefter at dreje til venstre, ved at køre fremad på højre hjul i 800 ms. Afslutningsvis holder robotten stille i et halvt sekund. Yderligere udskriver tråden i displayet når den hhv. bakker (skriver 'b'), drejer til venstre (skriver 'l') og holder stille (skriver 's'). Helt til slut frigives tråden 'RandomDrive' igen.

Ved at starte 'PlaySounds'-tråden tilføjes den sidste behaviour. Denne tråd starter med at sove i 10 sekunder, hvor de andre tråde får frit spil. Herefter undertrykker den de to andre tråde, tilføjer et 's' i sin display-linie, samt afspiller en lydsekvens, venter i 200 ms og afspiller en anden lydsekvens. Afslutningsvis frigiver tråden de andre tråde.

Den anden del - 'DriveTowardsLight.java'
Efterfølgende blev klassen 'DriveTowardsLight.java' oprettet, der extender klasssen 'Behaviour.java'. Denne klasse går overordnet set, ud og læser hvilke værdier, der er på begge RCX-lyssensorerne. Såfremt værdierne ligger under en fastsat tærskelværdi, køres en while-løkke, der udelukkende udskriver værdierne for de to sensorer i hver deres linie af displayet.
Komme værdien for en af lyssensorerne over tærsklværdien, springes der ud af while-løkken og 'RandomDrive'-løkken undertrykkes. Vi har valgt at 'DriveTowardsLight' i øjeblikket kun undertrykker 'RandomDrive', således at den stadig kan undgå at køre frontalt ind i noget, og at den stadigvæk kan blive afbrudt og bryde ud i festlige toner. Det kan nemt ændres på et andet tidspunkt. Efter at have undertrykt 'RandomDrive'-tråden forsøger vi at omsætte de to aflæste værdier på lyssensorene til en hastighed/power til hjulene. Denne omregning kan forbedres, men ser i pt. ud som følger:

leftSpeed = 50+ 800-(60-rightlight)*800/(40);
rightSpeed = 50+ 800-(60-leftlight)*800/(40);

Motorene modtager herved 'hastigheder' imellem 50 og 850, når lyssensorene måler hhv. 20 og 60. Tråden udskriver stadigvæk de målte lysintensiteter og udskriver herudover teksten 'li' i den øverste af sine 2 tilgængelige linier. Den kører i en tilfældig tidsperiode, noget vi har taget fra en af de andre tråde. Til slut stopper tråden de to motore og venter i en tilfældig periode. Årsagen til at det blev denne opbygning, med tilfældige periode-længder var fordi vi kopierede en af de andre tråde. I teorien bør dette ændres på baggrund af ekperimentiel data, således at robotten kører mest optimalt hen imod en lyskilde.

Denne nye klasse/tråd, 'DriveTowardsLight.java' ses i sin fulde kode her:
http://userportal.iha.dk/~20060651/JavaFiles_ESEA/Lektion8/DriveTowardsLight.java

Den førnævnte kode for 'DriveTowardsLight'-tråden tilføjes i 'BehaviourTest1.java', således at den ('DriveTowardsLight') kan undertrykke 'RandomDrive' og robotten tilføjes de to RCX-lyssensorer. Det følgende billede viser robottens udseende.

Idet vores nye tråd udelukkende har mulighed for at undertrykke 'RandomDrive'-tråden sker der ofte det, at lysfølger-funktionaliteten afbrydes af de to andre tråde, enten fordi hånden, som holder lyskilden aktiverer 'AvoidFront' eller fordi den fantastiske melodi pludselig afspilles. Reelt set burde vi teste 'DriveTowardsLight'-tråden, enten alene, eller med mulighed for, at den undertrykker de andre tråde, og ingen af de andre tråde undertrykker den. Desværre nåede vi ikke mere i denne lektion.

Af denne lektion, sammenlignet med vores tidligere oplevelser, ses det hvor vigtigt det er at have en ordentlig struktur på sin kode. Vi har i tidligere lektioner brugt meget tid på at få udskrift i display til at fungere med multitråd-projekter, uden at have fundet en langtidsholdbar løsning. Med den, til dagens lektion udleverede kode, under armen kan vi forhåbentlig spare meget tid i fremtidige lektioner, i hvert fald når det drejer sig om udskrift i displayet og flere tråde. Yderligere nævnes, at vi startede med at teste hver enkelt 'behaviour' hver for sig, og sluttede alligevel af med at teste vores 'DriveTowardsLight' sammen med de andre tråde uden at teste den for sig selv. Her kunne vi jo godt have tænkt os lidt mere om. Ja, ja. Vi er her jo for at lære.

ESEA - Labnotes

NXT Programming - Lektion7 - fortsat onsdag d. 7. nov. 2007
Varighed: 4.0 timer - kl. 17:00 - 21:00
Gruppemedlemmer: Aslak, Ruben og Lars

Gruppens mål for dagen:

• At få løst de problemer vi havde i fredags, se Lektion 7. Problemerne bestod i, at robotten stoppede af sig selv efter ganske kort til og udskrev en exception i displayet, samt, at vi ikke kunne udskrive fra vores 2 tråde i displayet. Når vi forsøgte at skrive i displayet fra de 2 tråde, så fik vi en anden exception og koden blev aldrig startet op på NXT'en.
• At, når det første punkt er løst, observere Braitenberg-robottens opførsel i begge konfigurationer (2a og 2b i lektionensbeskrivelsen fra Lektion 7). Disse Braitenberg-robotter, som vi forsøger at implementere vha. NXT'en, kan ses på følgende side: http://www.legolab.daimi.au.dk/DigitalControl.dir/NXT/Lesson7.dir/Lesson.html

Den Første Del
Vi startede eftermiddagen med at addressere det første problem fra sidste gang, nemlig at robotten stopper efter et kort stykke tid med en fejlmeddelse på skærmen. Ved at ændre på måden vi skriver ud på displayet lykkedes det at få robotten til at fortsætte "uendeligt". Denne ændring kan ses af det følgende kode:


String str1 = "Left read: ";
while(true) {
try {
light = ls.readValue(); // 2. step
LCD.clearDisplay(); // 1. step
LCD.drawString(str1, 0, 1); // 1. step
LCD.drawInt(light, 14, 1); // 2. step
LCD.refresh(); // 1. step
}
}

Linierne i den ovenstående kode efterfølges af kommentare, som henviser til i hvilket trin vi skrev linierne. Først brugte vi de linier mærket "1. step" og da det fungerede tilføjede vi linierne mærket "2. step".

Efterfølgende var vi interesserede i, at få de to tråde til at skrive ud på skærmen med en opdateringsfrekvens, som gør det muligt at se hvad der står. Hvis trådene opdaterer hver gang de læser en sensor-værdi, så bliver displayet opdateret så ofte, og hermed også slettet så ofte, at det som effekt blinker alt for hurtigt. Displayet blinker så hurtigt, at det ikke er muligt af aflæse. Dette løser vi ved at lade de 2 tråde sove i et stykke tid (laver en løkke, som laver ingenting:

int i = 10000;
while (i > 0) {
i--;
}

Denne fremgangsmåde gør reaktionstiden for robotten længere, idet der ikke bliver reageret på lysændringer sålænge den ovenstående while-løkke eksekveres. Dog er det nu lykkedes os, at løse de 2 problemer, som var dagens første mål. Nu kan vi observere hvordan robotten opfører sig, når den udsættes for lys.

Koden, som den ser ud under de følgende observationer:
http://userportal.iha.dk/~20060651/JavaFiles_ESEA/Lektion7/fortsat/MotorLightLeft.java

http://userportal.iha.dk/~20060651/JavaFiles_ESEA/Lektion7/fortsat/MotorLightRight.java

http://userportal.iha.dk/~20060651/JavaFiles_ESEA/Lektion7/fortsat/RobotA.java

Den Anden Del

Når robotten er i den ene konfiguration, hvor højre lyssensor styrer højre motor, og venstre sensor styrer venstre motor, opfører robotten sig nogenlunde som forventet. Med det samme skal det siges, at de monterede RCX-lyssensorer har en meget lille 'range' indenfor hvilken de måler lyset. Den laveste måling vi kunne opnå er på omkring 16-20 og den højeste måling er omkring de 40-45. Dette er ikke en 'range' som tydeligt stiger, når vi bringer lyskilden tættere og tættere på sensorene. Derfor opfører robotten sig heller ikke helt som forventet/håbet.

Nok fordi vi, som forklaret ovenfor, har indsat en "tom" while-løkke, at robotten reagerer forsinket på lysintensitetsændringer. Altså reagerer robotten relativt pludseligt på højere lysintensitet og drejer kraftigt imod/væk fra lyskilden, alt efter om robotten er i 2A, eller 2B opsætning (se linket under det andet punkt i målsætningen for denne lektion). Vi har altså, med andre ord, gjort robotten relativt langsomtopfattende, idet den ikke reagerer når koden står i tomgang i de "tomme" while løkker. Udover dette, så har lyssensorene (RCX-generation lyssensorer) ikke så stor 'range', dvs. der er ikke så stor forskel på den laveste måling (16-20) til den højeste måling (40-50). Denne sidste måling er med en lygte direkte ind i sensor, dvs. relativt uopnåeligt i en virkelig situation. Indfaldsvinklen på det lys om sensorene skal måle intensiteten på, skal også være stort set lig 0 grader (direkte frontalt ind i sensoren) for at det bliver opfattet.

Alt i alt gør dette, at robotten reagerer for kraftigt, når den endelig reagerer. Holdes et lys til højre for robotten, når den er sat til at køre mod lys, så drejer den alt for kraftigt imod lyset, og den modsatte sensor når ikke at reagere, fordi robotten er i en tilstand af "køre mod lyset til højre". Der er flere årsager til denne opførsel, bl.a. reagerer robotten for kraftigt, og de tråde, som robotten kører i kan ikke afbryde hinanden.
En løsning på dette ville være hvis en tråd aflyttede begge sensorer, og kunne sige ( i ovenstående tilfælde) at robotten skulle dreje mod højre SÅLÆNGE at lysintensiteten målt ved højre sensor var højere end ved den venstre. Vi forsøgte ikke at indbygge denne funktionalitet, idet opgaven for i dag lagde op til, at der skulle implementeres 2 tråde som hver især styrede en sensor og en motor.

Dette var hvad vi nåede på denne lektion.

ESEA - Labnotes

NXT programming - Lektion 7
Varighed: 4.0 timer - kl. 9:00-13:00
Gruppemedlemmer: Aslak, Ruben og Lars

Gruppens mål for dagens lektion:

• Bygge en robot, som kan benyttes til at undersøge opførslen på Braitenbergs køretøjer 2a og 2b. Disse køretøjer kan ses på lektionsplanen: http://www.legolab.daimi.au.dk/DigitalControl.dir/NXT/Lesson7.dir/Lesson.html
• På baggrund af Tom Deans noter at implementere disse to køretøjer i java-kode. Til forskel for Tom Deans noter, er det meningen, at der skal implementeres 2 tråde, som hver især tager sig af kontrollen mellem samplingen af en lysføler og styringen af en motor. Hvilken databehandling som indgår i denne "kontrol" omtales i detalje, når vi når så langt. Først vil vi blot omregne imellem det tilgængelige lysintensitets-interval og det mulige interval for "power" til motorene.

Fabrikation af Braitenberg-robot

"First things first", som det hedder. Dette indebærer, at bygge en robot, som ligner de skitser på dagens lektion. Et køretøj, som har 2 lysfølere foran, og som drejer udelukkende på baggrund af hvilken af baghjulene, som kører hurtigst. Der er to Braitenberg-variationer. Den første har en kobling mellem den lysføler til højre og den motor, som driver højre baghjul og mellem den lysføler til venstre og den motor, som driver venstre baghjul. Den anden variation bytter om på koblingerne, således at venstre lysføler kobles til højre baghjul og højre lysføler kobles til venstre baghjul.

I dag startede vi med at bruge lidt tid på at modtage kritik af vores labnotes frem til nu. Dette gav os gode tilbagemeldinger, både ros og gode råd til forbedringer. Der var også lidt tid til at diskutere muligheder for emner til det afsluttende arbejde.

Robotten tog lang tid at bygge. Problemet var faktisk at udarbejde en forhjulskonstruktion, som virkede stabil nok, idet robotten skubber bagfra. Tidligere har vi arbejdet med den "default" robot, som kan ses i manualen, som følger med de lånte legoklodser. Denne "default" robot trækker på forhjulene og trækker et baghjul, som blot følger efter og kan rotere frit (dreje frit om en vertikal akse). Vores ønske er at bygge en robot som ligner Braitenbergs skitser så meget som muligt. Problemet med det første udkast til en forhjulskonstruktion var, at rotationspunktet for aksen ned til forhjulet var lavet lige over hjulet. Dette gør det vanskeligt at få hjulet til at dreje, når baghjulene skubber bagfra. Løsningen blev at bygge et simpelt forhjul, som har rotationspunkt forskudt i forhold til centrum af selve hjulet. Dette svarer til princippet for baghjulet på den førnævnte "default" robot. Følgende billeder viser lidt tydligere hvordan den færdige forhjulskonstruktion ser ud. Billederne viser yderligere hvordan vores Braitenberg-robot ser ud.

(indsæt billeder..)

Implementering af koden

Vi påbegyndte arbejdet med koden ved at danne 2 tråde i java. Disse tråde skal hver især aftaste en lysføler (vi bruger de "gamle" fra RCX-tiden) og styre en motor af NXT-typen.
Den første version af koden skrev intet ud på displayet (noget vi bøvlede en del med under arbejdet med "Robot Race" robotten) og gav bare et niveau til begge hjul. Denne kode fik en exception efter at have kørt et ganske kort stykke tid. Forsøgte vi at udskrive noget i displayet fik vi en exception med det samme, og koden kom aldrig i gang. Altså er der 2 ting, som skal rettes: Koden skal ændres, således at den ikke stopper af sig selv, og det skal være muligt at udskrive i displayet. Disse 2 opgaver skal løses inden vi kan komme i gang med den egentlige opgave, nemlig at realisere Braitenberg-robot 2a og/eller 2b. Den ene java-fil 'RobotA.java' starter de to tråde, og de to andre (som er ens i koden) tager sig af at læse hhv. den højre og venstre lyssensor og styre hhv. den højre og venstre motor. Disse to sidstnævnte filer hedder 'MotorLightRight.java' og 'MotorLightLeft.java'.

Vi aftalte at mødes igen inden næste uges forelæsning.

Koden, som den så ud ved afslutningen:

http://userportal.iha.dk/~20060651/JavaFiles_ESEA/Lektion7/RobotA.java

http://userportal.iha.dk/~20060651/JavaFiles_ESEA/Lektion7/MotorLightRight.java

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.

ESEA - Labnotes

NXT programming - Lesson 4
Varighed: 3.5 timer - kl. 09.00-12.30
gruppemedlemmer: Aslak, Ruben og Lars

Målet for i dag er at påbegynde arbejdet med linjefølger-robotten, som skal deltage i næste uges Robot Race. Følgende delmål forventes at blive gennemført i dag.

• implementere følgende 3 filer : BlackWhiteSensor.java, LineFollowerCal.java og Locomotion.java
• arbejde med at optimere på disse, for på denne måde at optimere på robottens opførsel på en sort streg på en hvid baggrund. Arbejdet med at få robotten til at genkende det grønne "målområde" venter vi med til senere

Filen BlackWhiteSensor.java http://userportal.iha.dk/~20060651/JavaFiles_ESEA/BlackWhiteSensor.java omfatter en kalibrering af lyssensoren, hvor bilen placeres over hhv. en sort og en hvid flade, således at lysintensiteterne for disse kan gemmes. På baggrund af lysintensitetsmålingerne for sort og hvid beregnes en tærskelværdi som bruges til at fastslå om robotten skal dreje til højre eller venstre ((intensitet_sort+intensitet_hvid)/2).

Filen Locomotion.java er den samme, som er blevet benyttet ved tidligere lektioner. Til denne lektion har vi ændret lidt i filen, og den ændrede kan findes her: http://userportal.iha.dk/~20060651/JavaFiles_ESEA/Locomotion.java

Filen LineFollowerCal.java er main-filen i dette projekt. Den version af filen, som vi var kommet frem til ved denne lektions afslutning kan findes her: http://userportal.iha.dk/~20060651/JavaFiles_ESEA/LineFollowerCal.java

Den første del af dagens opgave forløb ganske uden overraskelser. BlackWhiteSensor.java bruges af LineFollowerCal.java til at teste om sensoren er på sort eller hvidt underlag.

Anden del af dagens opgave, at ændre i LineFollowerCal-filen og optimere på robottens opførsel blev påbegyndt. Denne opgave slutter først, når selve løbet Robot Race løber af staben på næste fredag (d. 5. oktober 2007). Vores tilgang til robottens opførsel er en videreførsel af tilgangen til WallFollower-problematikken (se Lektion 2). I stedet for den eksisterende kode, drejer robotten, i den ændrede kode, til at begynde med kun en lille smule til hhv. højre og venstre, når lyssensoren måler intensiteter svarende til hhv. sort og hvid. Det bløde sving opnås ved at begge hjul kører på samme tid, det ene hurtigere end det andet. Måles der den samme intensitet 2 gange i træk (eksempelvis hvid) drejer robotten skarpere til venstre. Dette skarpere sving opnås underforstået ved, at det venstre hjul (i dette tilfælde) sættes til en endnu lavere hastighed. Som koden er i øjeblikket, bliver der, når den samme intensitet (farve) er målt 3 gange i træk drejet aller skarpest, som resultat af, at det forventes at robotten er på afveje.

Ved afslutning af denne lektion blev det besluttet at gruppen mødes igen på mandag (d. 1.oktober 2007) kl. 17.00.

ESEA - Labnotes

NXT Programmering - Lektion 3

varighed: 4 timer - kl. 09.00 - 13.00
gruppemedlemmer: Aslak, Ruben og Lars

Målet for i dag var at komme hurtigt igang med arbejdet med lydsensoren (mikrofonen) og dermed hurtigt komme i gang med programmet til den klap-styrede bil. Hjemmefra var der blevet forberedt en test af mikrofonen, baseret på koden fra forrige lektion ('SonicSensorTest.java').

Desværre var der fra starten problemer med Lars' computer og installationen af Java og Eclipse. Computeren kunne ikke kommunikere med NXT'en, noget som også drillede lidt under forrige lektion. Der endte med at gå en hel time tabt, inden vi havde givet op og begyndte at bruge Aslaks computer istedet. Der virkede kommunikationen fint, og vi påbegyndte dagens arbejde.

Først oprettes en ny klasse 'MicrophoneTest.java', baseret på den kode, som var lavet hjemmefra (se forrige afsnit). Denne blev uploadet til NXT'en og vi diskuterede brugen af 'klap' til at teste med. Vi blev enige om, at det er for svært at klappe ensartet gentagne gange, og vi lavede en Matlab funktion, som danner og afspiller en 1000 Hz tone med en varighed på 3 sekunder. Vi udførte en test af mikrofonen med en opstilling, hvor NXT'en, monteret på 'bilen', stod på gulvet i et åbent område, med den pc som afspiller lyden placeret på en kasse, umiddelbart udfor mikrofonen. Testopstillingen vises på følgende billeder.

Resultatet af denne test vises på følgende graf:

Som det fremgår af grafen er målingerne ikke helt enstydige. Dette kan skyldes flere ting. Den første måling, ved en afstand mellem mikrofonen og pc'ens højttaler på 20 cm, forekommer det målte lydniveau for lavt (sammenlignet med lydniveauet ved 40 cm). Dette kan forklares med en antagelse om, at mikrofonen har en meget retningsafhængig response. Ved den første måling står pc'ens højttaler faktisk hævet over mikrofonens fysiske niveau. Derfor vil meget af lyden, efter vores antagelse, udbrede sig "hen over" mikrofonen. De andre ulineariteter kan forklares ved uforudsiglige refleksioner og ved at omgivelserne ikke er fuldstændig konstante, hverken i lydniveau eller i fysisk udseende (vi stod ikke altid på helt samme position). Dog viser figuren en tydelig tendens og viser at det målte lydniveau falder som funktion af afstanden.

Næste punkt var en kørsel af 'SoundCtrCar.java'. Dette program benytter mikrofonen og giver bilen en forudbestemt opførsel afhængigt af de lyde som måtte blive registreret. Koden opererer med en tærskelværdi, som kan ændres efter omstændighederne og benytter klassen 'Locomotion.java', som også blev omtalt under forrige lektion. Ved starten er denne tærskel sat til et lydniveau på 90. Efter opstart begyner bilen at bevæge sig fremad, og fortsætter med dette, indtil en lyd, hvis niveau overstiger tærskelværdien indtræffer. Herefter drejer bilen til venstre, og fortsætter med dette, indtil en lyd, som overstiger tærskelværdien indtræffer. Herefter drejer bilen til højre, og igen indtil en lyd overstiger tærskelværdien. Slutteligt holder bilen stille, og fortsætter med at holde stille indtil den gentager hele bevægelsesmønstret, når en lyd overstiger tærskelværdien endnu engang. Dette kan så fortsætte i det uendelige, eller indtil batteriet løber tørt.

En anden måde at afslutte det omtalte program 'SoundCtrCar.java' er ved at trykke på 'escape'-knappen, men dette fungerer udelukkende, når eksekveringen af koden befinder sig i den yderste while-løkke. Trykkes der på 'escape' imens NXT'en er igang med at eksekvere en af de indre while-løkker, f.eks. at dreje til højre, sker der ingenting. For at kunne stoppe NXT'en på alle tidspunkter af kode-afviklingen, implementerede vi først den "grimme" måde, som vi valgte at kalde den. Den "grimme" måde er, at de indre while-løkker i koden bliver tilføjet en if-sætning, som tester om 'escape' er aktiveret. Er knappen aktiveret, stopper eksekveringen af koden.

Som sidste opgave i dag, arbejdede vi med at implementere en klap-tæller (clap counter), som, på baggrund af vores kendskab til de akustiske aspekter af en lyd af denne type, tæller antallet af disse. Desværre nåede denne kode ikke at blive færdiggjort. Gruppens medlemmer vil forsøge, at arbejde videre på denne kode inden næste lektion.

Afslutningsvis kan det nævnes at den forulykkede pc stadig, ved lab-sessionens afslutning, ikke fungerer mht. kommunikation ml. pc og NXT. Det forventes at det kan være Java, eller Eclipse, som ikke fungerer. Muligvis vil dette også blive rettet op på inden næste lektion.

ESEA - Labnotes

NXT programmering - Lektion 2
Varighed: 4 timer - kl. 9.00 - 13.00
Gruppemedlemmer: Aslak, Ruben, Lars

Efter at have sluttet sidste session uden at have testet linefollower-koden (se bloggen fra Lektion 1) startede vi dagen i dag med at køre en tur på den til formålet udfærdigede bane. Dette gik helt fint og NXT-køretøjet opførte sig ganske pænt.

Målet for i dag er at arbejde med ultralydssensoren (Ultrasonic Sensor). Dette testes først med pre-fabrikerede java-filer, SonicSensorTest.java og Avoider.java, som benytter klassen Locomotion.java og herefter med en videreudvikling, som skal resultere i en væg-følger WallFollower.java. Efter at have uploadet filen SonicSensorTest.java, fik vi udlæsninger på NXT'ens display, som svarede godt overens med de målte afstande.

Vi oprettede klassen Locomotion.java i Eclipse og compilede den. Dernæst oprettede vi klassen Avoider.java, compilede den, og uploadede koden til NXT'en. Dette medførte den forventede opførsel, hvor NXT-køretøjet kørte hurtigt hen imod væggen og jo tættere pa den kom jo langsommere kørte den, for til sidst at stoppe helt.

Til sidst oprettede vi klassen WallFollower.java og fik lidt inspiration fra Philippe Hurbains hjemmeside og hans væg-følger. Vi oprettede en "blød" version af medlemsfunktionerne Locomotion.right og Locomotion.left, kaldet hhv. softright og softleft. Disse to funktioner giver mulighed for at dreje lidt, dvs. begge hjul roterer, det ene hurtigere end det andet. Ved et højresving er det således venstre hjul som roterer hurtigst, om omvendt. Vi brugte koden fra Avoider.java, som skabelon, og benyttede således den definerede tærskel for minimumafstand. Idet ultralydssensoren er monteret foran på bilen, og vinklet ca. 45 grader til venstre, skal bilen dreje til højre, når afstanden er mindre end tærsklen, og til venstre, når afstanden er større end tærsklen.

Vi compilerede og uploadede vores WallFollower og lavede forsøg med både de skarpe og de bløde sving. Fordelen ved bløde sving, hvor ingen af hjulene stopper helt op på noget tidspunkt, er en mere jævn bevægelse af køretøjet, og pæne håndteringer af 90 graders venstresving. Der opstår lidt problemer når bilen skal dreje til højre, hvor den jo bevæger sig fremad samtidig med at den drejer, her kommer bilen for tæt på den væg som er foran den.
Fordelen ved de "hårde" sving, hvor det kun er et hjul ad gangen, som roterer, er en pæn håndtering af 90 graders højresving. Dog har bilen nu en tendens til at dreje alt for kraftigt ved 90 graders venstresving, så kraftigt, at den næsten kører ind i selve hjørnet.

Det var meningen at kombinere disse to mulige måder at dreje på, ved at kigge på ændringen af den målte afstand fra sidste måling og til den nuværende måling (tilvæksten), og på denne baggrund beslutte, om der er brug for et kraftigt, eller blødt sving. Denne funktionalitet nåede vi desværre ikke at implementere, og derfor heller ikke at teste.

ESEA - Labnotes

Forberedelse til Lektion 2
varighed : 2 timer - 18.00 - 20.00
forgik tirsdag d. 11. september ´07

Målet er at få al software'en til at køre på min egen computer. Sidste gang fik vi det hele op at køre på Aslaks computer, men det er nok en god idé at have det installeret på min også. Man ved jo aldrig hvad der kan ske med de computere.

Sidste fredag fik jeg installeret de fleste komponenter, mangler faktisk bare NXT software'en fra Lego og at sætte Eclipse helt op efter vejledningen. Efter at have installeret NXT software'en uden problemer er det bare at checke, at alt er gjort som på listen. Jeg finder hurtigt ud at, at der er noget galt. Jeg får ikke de forventede beskeder, når jeg skriver "javac" eller "nxjc" i kommando-promten. Efter at have dobbeltchecket stort set alt, og efter at have forsøgt både med den nævnte skrivemåde og med de fulde stier i PATH i Enviroment Variables, går det endeligt op for mig, at jeg heller må checke min java-installation igen.

Og nu ser jeg det endeligt. Det jeg har installeret er rigtignok version 1.6.0_02, men ikke development-kittet. Bare den "almindelige" bruger-java-pakke JAVA Runtime Enviroment (JRE) jre1.6.0_02. Jeg lægger først nu mærke til, at der i installations guiden står:

"Ex. JAVA_HOME = C:\Program Files\Java\jdk1.6.0_02"

under punkt 3, hvor den nye 'System Variable' oprettes. De 3 små bogstaver har været årsagen til mine grå hår. Jeg ville nok have foretrukket, at der i punkt 2) på installationsvejledningen stod, at det var Java Development Kit, som skulle installeres, og at der ikke bare stod "install Java 1.5 or later".

Efter at have installeret Java SE Development Kit'et (JDK) og genstartet Eclipse, virkede alt som forventet, og jeg kan nu uploade de oprettede klasser til NXT'en.

Herligt. Og her kan man bare se, hvor lang tid, der kan gå, når man ikke ved så meget om JAVA og om, at JRE-pakken ikke var nok, men at det skulle være JDK-pakken indeholdende udviklings-værktøj. Men nu er også denne laptop klar til at tage hul på næste lektion med NXT-programmering.

ESEA - Labnotes

NXT programming - Lektion 1
Varighed: 3 timer - kl. 09.00-12.00
Gruppemedlemmer: Aslak, Ruben, Lars

Målet for i dag er at opnå kendskab til Lego Mindstorms NXT sættet, samt at få installeret tilhørende software. Yderligere sigter vi efter at compile og downloade et Java program til NXT'en, som får en bil til at følge en sort linie på en hvid overflade (linefollower).

Efter at have hentet kasser, installations-cd'er, oplader og bluetooth-dongle, satte vi straks det medfølgende batteri til opladning. Dette batteri nåede på den afmålte tid ikke at blive ladet op, og vi brugte almindelige 1.5 volts batterier til denne lektion.

Imens en af gruppens medlemmer installerede alt det tilhørende software, byggede de andre selve bilen til dagens lektion. Vejledning til bilen blev fundet i den medfølgende manual "9797".
Under installation af diverse software stødte vi på lidt problemer med mellemrum i sti-navne. Noget som egentlig var tydeliggjort i installationsguiden. Efterfølgende gik alt som det skulle, og eclipse, lejos_NXT og Lego Mindstorm NXT softwaren var klar.

Første kontakt mellem computer og NXT'en gik umiddelbart ikke, hvorefter vi blev gjort opmærksom på at NXT'en skulle reset'es på en lille knap gemt i nærheden af USB-stikket. Første overførsel fra computer til NXT foregik via en command promt. For at overførslen kunne gå godt skulle Bluetooth-donglen isættes, selvom USB kablet var tilkoblet både pc og NXT. Dette fandt vi aldrig en god forklaring på. Programmet "Tune" blev uploadet og NXT'en spillede lystigt, som forventet.

Nu kom tiden til at opsætte Eclipse, således at programmering og upload af programmer herefter kan foregå via dette interface. Første forsøg med at oprette et nyt projekt i Eclipse, og kopiere indholdet af Tune.java over i en ny klasse i dette projekt. Den nye klasse blev compilet uden fejl og uploadet til NXT'en. Nu begyndte Eclipse-programmet at lede efter NXT'en via Bluetooth, og efter lidt ventetid opgav vi denne kommunikationsform. Vi valgte at bruge USB-kablet og nu uploadede Eclipse uden problemer til NXT'en. Som før begyndte NXT'en at spille fin musik..

Slutteligt oprettede vi en ny klasse "linefollower" og kopierede koden fra Legolab-hjemmesiden ind. Efter at have uploadet koden til NXT'en nåede vi dårligt at teste den, idet batterierne løb tør. De 3 timer var nu gået og vi blev nødt til at splitte os op og slutte, idet gruppens medlemmer skulle hver til sit.

I forhold til dagens målsætning nåede vi at alle punkterne. Vi ville gerne have leget mere med "linefollower" koden, og have optimeret på den, men det må blive på et andet tidspunkt.