Projekt, møde 4

Deltagere: Asbjørn og Jesper
Tidsforbrug: 7 timer (kl 9 - 16)

Denne gang satte vi os for at rette de fejl der var ved vores hardwares håndtering af kuben:

• Vores tilter kunne ikke altid tilte kuben.
• Vores twister kunne ikke holde sig på multipla af 90 grader.

Disse tre problemer angreb vi i rækkefølgen beskrevet her. Det første var at fikse tilteren. Dette problem løste vi ved at ombygge forbindelsen mellem motoren og tilter-armen. Det viste sig at vi ikke behøvede nedgearing her. Resultatet er en mere voldsom tiltning af kuben, men til gengæld virker den hver gang.

Det andet problem var en større hindring. Da rubikskuber ikke er designet med LEGO-kompatibilitet for øje, er der rimelig meget slør mellem kuben og twisterarmen. Løsningen har her primært været i softwaren, der nu kompenserer for slør-effekten. I stedet for at dreje f.eks. 90 grader, drejer den i stedet lidt for langt og lidt tilbage. Ved at prøve forskellige værdier for denne overkompensering, lykkedes det os at finde en løsning der virkede. I hardwaren har vi gjort grebet om kuben lidt tættere.

Efter vi havde opnået en rimelig pålidelig mekanisk manipulation af kuben, fik vi udleveret en NXT Color Sensor. Projektet kræver godt nok to, men det er da en start. Vi lavede nogle indledende tests og konstaterede følgende:

• Farvemålingen er generelt god og følsom overfor små ændringer i farve, men:
• Afstanden man kan måle præcist i er kort og skarpt afgrænset. Det observerede vi tydeligst med kubens blå og grønne felter. Ved ca 1 cm var målingen god, men ved 1.5 cm var der problemer.
• Selv om den indbyggede RGB -> farveindex konvertering virker det meste af tiden, har den meget svært ved at genkende kubens hvide sider (farve index 17). Også selv om RGB værdierne er ca lige store og i den høje ende (dvs i intervallet lysegrå..hvid).

Efter disse indledende målinger var det tid at finde en måde at montere sensoren på, så den pålideligt kunne måle farverne på kubens sider. I vores mockup har vi indtil nu anvendt to andre sensorer med samme ydre dimensioner som farvesensoren. Men vi havde ikke taget højde for sensorens begrænsede rækkevidde. Derfor har vi været nødt til at ændre twister-armen, så sensorerne kan komme tættere på kubens sider.

Vi brugte resten af tiden på at forbedre monteringen af farvesensorerne, samt at påbegynde programmeringen af softwaren. Vi har valgt at adskille logikken fra styringen af motorerne. Derved kan vi udvikle løsningsalgoritmen uden at inddrage den fysiske robot hver gang koden skal testes. Hvis en almindelig PC kan løse en virtuel kube i Java, vil det da være en smal sag at flytte koden over på NXT'en og løse kuben ved mekanisk manipulation.

Desuden optog vi en video af maskinen mens den kørte. Den laver ikke noget "fornuftigt" på denne video. Det er udelukkende en test af de forskellige mekaniske dele.


Billeder
Her ses et nærbillede af styringsmekanismen til rotation af slæden. I vores oprindelige design var slæden monteret direkte på en motor. Dette viste sig dog at være en vakkelvorn og ikke særlig præcis løsning. Dette design er meget bedre med hensyn til stabilitet og præcision.
Her ses en måling af et grønt felt på kuben. På NXT'ens skærm udskriver vi farveindex og RGB værdier.
Det kan være lidt svært at se værdierne på billedet, men der står:









På de næste billeder ses hele konstruktionen oppefra, sidefra og i perspektiv som den ser ud på dette tidspunkt.

Projekt, møde 3

Deltagere: Asbjørn, Christer og Jesper.
Tidsforbrug: 3 timer.

Som beskrevet i sidste blogpost besluttede vi at mødes en ekstra gang inden jul. Heller ikke denne gang er der det store at skrive, men vi kan jo tage flere billeder så.

Sideløbende med videre udbygning af robotten er vi begyndt med udvikling af software til styring af motorene. Derfor går en god del af tiden med at bestemme hvor mange grader de forskellige motorer skal køre for at opnå den ønskede mekaniske effekt. Ligeledes er der aspektet med hvor præcise motorerne er. Når man roterer slæden som kuben ligger på, er det vigtigt at den drejer præcis 90 grader hver gang. Det er ikke godt nok at den f.eks. drejer 90 grader og derefter et par grader mere mens motoren speeder ned.

Billeder
Alle nedenstående billeder er af vores work-in-progress model. Derfor vil selve modellens opbygning variere mellem hvert af billederne. De er sorteret kronologisk med de første øverst og de sidste nederst.

Modellen lige før og midt under en rotation.














Denne konfiguration virker det meste af tiden. Dog er der tilfælde hvor kuben sidder fast når man "tilter" den. Til at imødegå dette problem monterede vi ekstra sider af tandhjul i slæden. De sørger dels for at hindre at kuben sidder fast, og dels for at den ruller ned på plads efter en tiltning. Som det ses på billederne, eksperimenterede vi med flere forskellige tandhjul.














To be continued...

Projekt, uge 2

Deltagere: Asbjørn, Christer og Jesper.
Tidsforbrug: 3 timer

Nu har vi fået tilladelse til at gennemføre rubiks-kube projektet. De specielle lyssensorer er bestilt, men vi har ikke fået dem endnu. Planen for dagens session er, at prøve at få den mekaniske del i retning mod et funktionelt stadie.

Mekanikken består af tre dele:

1. En "slæde" der kan rotere. Den går 1/3 op ad kuben, så den nederste side kan holdes fast mens resten roteres.
2. En "rambuk" der kan vælte kuben om på siden, så vi kan rotere i flere dimensioner.
3. En "hånd" der kan holde kuben fast mens ovennævnte slæde roterer. Denne hånd indeholder også vores farvesensorer (NXT Color Sensor), så vi i den indledende fase af løsningen kan scanne kubens startkonfiguration

Der er ikke så meget at skrive om selve byggeriet. Derfor indeholder denne blog-post flere billeder end normalt.
Her ses første udkast til del 1 og 2 fra et par vinkler:
Her ses gribearmen (del 3) med et par mockup-sensorer. På dette tidspunkt har vi endnu ikke fået de rigtige sensorer. Det kan dog ikke umiddelbart ses på dette billede:

Ved enden af denne øvelsesgang var vi nået frem til følgende stadie.
Oppefra:
Sidefra:
Som det ses på de sidste par billeder, er opstillingen på dette tidspunkt langt fra færdig og er desuden temmelig vakkelvorn. Derfor aftalte vi at mødes igen onsdag d. 19., så vi måske kunne have mekanikken nogenlunde færdig inden jul. Derved vil der være mere tid i januar til at færdiggøre softwaren.

Projektstart

Deltagere: Asbjørn, Christer og Jesper.
Tidsforbrug: 3 timer.

Målet med dagens session er, at:

• Få et projekt godkendt af Ole Caprani.
• Påbegynde arbejdet på dette projekt.

Ved dagens start kunne det ikke lade sig gøre at træffe Ole, så vi besluttede i stedet at gå så småt igang med at skille vores gamle robot ad og påbegynde en eksperimentel opbygning af en rubiks kube løser.

Oplæg til projekt

Tidsforbrug: 3 timer.
Deltagere: Asbjørn og Christer
(Jesper er på Island i denne uge)

Disse er opstillet i prioriteret rækkefølge. Vi vil helst arbejde med den øverste (rubiks kube løseren). Fælles for dem alle er, at de benytter en eller flere farvesensorer (NXT Color Sensor). Den findes ikke i det udleverede NXT sæt og skal derfor først indkøbes hos LEGO.
Som første del vil vi undersøge egenskaberne ved en sådan sensor. Vi kan se i lejOS APIen at den er understøttet og at man kan få en RGB-værdi ud. Indkøb af en eller flere af disse sensorer mener vi kan retfærdiggøres af, at vi undersøger og beskriver egenskaberne set i forhold til den ordinære lyssensor. Først efter en sådan undersøgelse vil vi tage den i anvendelse. Så vil farvesensorerne eventuelt kunne anvendes i senere udgaver af kurset.

1. Robot der med en farvesensorer indscanner siderne på en rubiks kube og ud fra denne måling løser den.
2. Robot der på et gulv med legoklodser søger rundt og "spiser" klodser med en bestemt farve.
3. Robotter der kører rundt mellem hinanden og kan skelne mellem ven og fjende baseret på hinandens farver.

Projekt 1 - Robot der løser en rubiks kube. (Primært valg)
Hardware/software platfom:
Vi skal bruge en NXT, 3 motorer og 2 stk NXT Color Sensor. Motorer, sensorer og software vil blive beskrevet i de følgende afsnit.

Motorer:
Den mekaniske del skal kunne:

1. Rotere terningen (1 motor) ved at terningen hviler i en slæde der går 1/3 op på den
2. Holde terningen fast mens den nederste 1/3 roterer (1 motor), samt at skubbe terningen på plads når den roteres om en anden akse (se næste punkt)
3. Rotere terningen i en dimension mere (1 motor).

Med disse tre funktioner kan vi rotere og manipulere terningen som vi vil, da alle handlinger kan reduceres til en serie af disse.

Sensorer:
Før man kan løse en rubiks kube, skal man kende farverne på alle felterne. Dette kan løses på to måder:

1. Vi kan taste kubens farver ind på forhånd.
2. Robotten kan undersøge det selv med farvesensorer.

Da det mest er i kursets ånd med selvstændighed, vil den anden mulighed være at foretrække. Vi har hos LEGO fundet en farvesensor (NXT Color Sensor), der vil kunne bruges til dette formål.
Angående dette projekt er vi kommet frem til at 2 sensorer vil kunne gøre det uden at vi skal montere flere motorer. Med de eksisterende motorer vil vi kunne skubbe disse hen over siderne på kuben og "scanne" to rækker felter ad gangen. Ved at rotere kuben kan vi således komme hele vejen omkring. Med kun én enkelt sensor skal vi bruge en del ekstra mekanik for at kunne have komplet dækning, da vi ikke umiddelbart kan nå både centrum og hjørnerne på en side på denne måde uden ekstra mobilitet.
Sensorerne er markeret med "S" på billedet.

Software:
Vi skal dels kunne:

• Løse en rubiks kube algoritmisk. Dette er et velkendt problem, som sagtens kan implementeres i lejOS java.
• Styre motorerne, så de manipulerer kuben som ønsket.
• Scanne overfladerne på kuben og omsætte resultatet til et kort over den. Ud fra dette kort og de to ovenstående punkter, kan vi løse kuben.

Største udfordring:
I dette projekt vil den største udfordring være at scanne overfladen på kuben. Her vil vi komme til at arbejde med en ny type sensor og mekanik der er stabilt nok til denne anvendelse. En ekstra udfordring ville være at understøtte kuber med et på forhånd ukendt farveskema. Her vil programmet være nødt til at tage alle målingerne (6 sider á 9 målinger) og forsøge at placere dem i 6 clusters i et tredimensionelt RGB-rum. Hvis dette kan lykkes, kan man udlede hvilke felter der skal ende op på samme side af kuben.

Hvad vi regner med at nå frem til:
En mekanisme der automatisk undersøger siderne på en rubiks kube og derefter mekanisk manipulerer den til en løsning.

Opdeling i delmål:

1. Test af NXT Color Sensor.
2. Manupulation af kuben med motorer
3. Indscanning af kube
4. Selvstændig løsning af rubiks kube i NXT'en.
5. Skelne imellem farver der ikke er fastlagt ved compiletime.

De alternative projekter:

Projekt 2 - Køre på et gulv med legoklodser hvor robotten søger rundt og "spiser" klodser med en bestemt farve.

Hardware/software platform:
En NXT, 3+ motorer (og muligvis en motor multiplexer) og en NXT Color Sensor.

Motorer:
Vi skal dels:

• Kunne navigere rundt på en todimensionel flade (2 motorer).
• Kunne "spise" en klods med en specifik farve op fra gulvet (ukendt antal motorer).

Sensorer:
Der skal bare være en NXT Color Sensor til at måle farven på hver klods.

Software:
Softwaren skal kunne:

• Måle og skelne mellem et antal farver.
• Køre rundt og lede efter klodser på en mere eller mindre udtømmende måde.
• Samle en klods op fra gulvet.

Største udfordring:
Vi har ikke overblik over hvordan man nemmest (dvs med mindste antal motorer) samler en legoklods op fra gulvet. Derfor vil dette være den største udfordring.

Hvad vi ville regne med at nå frem til:
Såfremt det kan lykkes at samle en klods op fra gulvet, ser vi ikke andre hindringer mod at opnå en komplet løsning.

Projekt 3 - Robotter der kører rundt mellem hinanden og kan skelne mellem ven og fjende baseret på hinandens farver.

Hardware/software platform:
Pr robot vil vi have brug for: en NXT, to motorer og en NXT Color Sensor.

Motorer:
Motorerne skal køre robotten rundt på samme måde som vi har eksperimenteret med til de almindelige øvelsesgange.

Sensorer:
I hver robot skal vi have en farvesensor, så vi kan skelne mellem ven og fjende.

Software:
Softwaren skal kunne ændre robottens adfærd baseret på hvad den ser.

Største udfordring:
Robotterne skal formentlig meget tæt på hinanden før man kan lave en præcis farvemåling. Den præcise adfærd omkring denne måling vil være den største udfordring i et projekt som dette.

Hvad vi ville regne med at nå frem til:
Såfremt vi kunne få robotterne til at skelne mellem hinanden på en pålidelig måde, ser vi ingen grund til ikke at kunne opnå komplet funktionalitet.

NXT programmering, lesson 10

Tidsforbrug: 3 timer. Deltagere: Asbjørn, Christer og Jesper.
I dag vil vi undersøge hvordan en adfærdsbaseret arkitektur er implementeret i leJOS NXJs subsumption API.

Vi vil gennemgå disse skridt et for et:

• BumperCar
• Ombygge bilen ved at tilføje touch sensor.
• Hvad sker der hvis man holder touch sensoren inde?
• Tilføj 3. adfærd.
• En ny arbitrator.
• Motivation functions.
• Resten af tiden.
• Da Jesper er bortrejst i næste uge, påbegynder vi projekt-brainstorm nu.
  

BumperCar.
Tidsforbrug: 1 time.

Vi hentede BumperCar koden, tilføjede en touch sensor på bilen og kørte koden. I første omgang kørte bilen baglæns, da vores nuværende konstruktion har motorerne vendt modsat.

Hvis man holder touch sensoren inde, stopper bilen helt. HitWall udføres én gang og bilen venter da på at sensoren slippes igen. På grund af arbitratoren kan den ikke komme videre før sensoren slippes. Hvis takeControl i DriveForward kaldes mens HitWall er aktiv, busy-waiter den indtil sidstnævnte bliver inaktiv.

Sidste delopgave her var, at implementere en tredje adfærd med højeste prioritet. Vi valgte en musikafspiller som foreslået i opgaven. Hver gang den spiller, trumfer den alle de andre adfærdsmønstre. Det vil sige, at når vi holder touch sensoren inde, vil musikadfærden før eller siden komme og undertrykke HitWall, hvorefter robotten ikke behøver vente på at sensoren slippes.
Det er ikke altid at arbitratoren virker som den bør. Det kan godt ske at HitWall fortsætter med at kontrollere motorerne. Det vil sige, at en lav-prioritets adfærd godt kan undgå at blive undertrykt af en høj-prioritetsadfærd.

En ny arbitrator.
Tidsforbrug: 1/2 time.

Vi hentede og compilede den nye arbitrator. Denne gang ser vi en ny adfærd ved HitWall. Nu gentager den undvigemanøvren indtil touch sensoren slippes. Til gengæld virkede vores musikafspiller ikke mere. Den kom aldrig "til fadet" her på trods af sin høje prioritet.

Motivation functions.
Tidsforbrug: 1/2 time.

Man kunne ændre takeControl til at returnere en motivationsværdi. I tilfældet med touch sensoren og HitWall kunne den returnere en værdi når den trykkes og eksempelvis 0 når den ikke trykkes. Jo højere, jo mere motivation. Arbitratoren kunne da bestemme adfærd ud fra disse værdier. Med andre ord kunne man udskifte de statiske prioriteter med dynamiske prioriteter bestemt ud fra sensor input.
Dette svarer cirka til idéen i Thiemo Krinks motivation functions. Touch sensorens input mappes af en funktion til en motivationsvariabel for berøring, som decision-makeren aktiverer et behavior-pattern ud fra. Den adfærd der er mest motivation for, HitWall, udføres og robotten undviger ved at ændre retningen på motorerne.

Resten af tiden.
Tidsforbrug: 1 time.

Da Jesper er på Island i næste uge, besluttede vi at påbegynde projekt-brainstorm nu.

NXT programmering, lesson 9

Tidsforbrug: 3 timer.
Deltagere: Asbjørn og Christer.
(Jesper er til programmeringskonkurrence i Holland.)

Målet med dagens session er, at eksperimentere med navigation ud fra motorernes tacho tællere med og uden forhindringer på banen.

Vi vil gennemgå disse skridt et for et:

• Bygge bilen i noten og få den udleverede kode til at virke.
• Vores egen bil havde et uheldigt tyngdepunkt og notens bil virkede enklere.
• Teste præcision af Blightbot koden.
• Testen udføres et antal gange.
• Vi ændrer ruten i koden for at teste præcision i sving.
  
• Navigation uden om forhindringer.

Bygge bilen i noten og få den udleverede kode til at virke.
Tidsforbrug: 30 min.

Som sagt var vores gamle design uegnet. Det var for stort og klodset og havde et dårligt tyngdepunkt (højt og forskudt). Byggeinstruktionerne i noten var rimeligt lette at følge i kraft af bilens simple opbygning. Der var kun enkelte problemer hvor kvaliteten af fotokopieringen gjorde det svært at se præcis hvor tingene skulle monteres. En mere kompliceret konstruktion ville have været vanskelig at bygge på denne måde.

Den udleverede kode virkede med det samme uden problemer.







Teste præcision af Blightbot koden.
Tidsforbrug: 30 min.

Af pladshensyn var vi nødt til at ændre afstandsangivelser i den initielle rute i koden. Vi havde simpelthen ikke gulvareal nok til at køre programmet som det var. Derfor halverede vi alle afstande før vi startede. Vi kørte robotten med Blightbot koden flere gange med enslydende resultat hver gang. Afvigelsen mellem startpositionen og slutpositionen var ca ½ cm ved alle vores tests.

Ifølge opgaven har denne robot en præcisionsmæssig svaghed når den drejer. Derfor ændrede vi ruten i koden så den fik flere sving. På tegningen ses den nye rute der køres i rækkefølgen 1-6. Nu var afvigelsen mellem start og stop ca 3.5 cm hver gang. Altså er sving tilsyneladende designets svaghed.



Navigation uden om forhindringer.
Tidsforbrug:2 timer.

Vi besluttede at genbruge sidste uges AvoidFront behavior kode. Desuden modificerede vi RandomDrive til TachoDrive. Tanken er da at vi så vil have en robot med disse to behaviors. I denne forbindelse monterede vi ultralydssensoren igen.

Hvad skal der ske når den ser en forhindring?
En mulighed er at bakke lidt tilbage, dreje og prøve igen. Ved gentagne gange at foretage denne handling burde man før eller siden kunne komme forbi forhindringen.

I praksis fik vi desværre ikke denne løsning til at virke inden for tidsrammen. Efter den ser forhindringen første gang går det galt og den fortsætter aldrig mod målet igen.

NXT programmering, lesson 8

Tidsforbrug: 3 timer. Deltagere: Asbjørn, Christer og Jesper.
Målet med dagens er, at eksperimentere med flere forskellige simultane adfærdsmønstre.

Vi vil gennemgå disse skridt et for et:

• Ombygning af bilen.
• Der skal monteres en ultrasonisk sensor.
• Eksperimenter med den udleverede kode.
• Først med et enkelt adfærdsmønster, derefter flere.
• Diskussion af klasserne Behavior og Locomotion
• Besvarelse af konkrete spørgsmål i opgaveformuleringen.
• Tilføjelse af nyt adfærdsmønster: "kør mod lyset"

Ombygning af bilen.
Tidsforbrug: 15 minutter.

Vi har valgt at genbruge LEGO-modellen, vi brugte som sidste uges Braitenberg vehicle. Herpå har vi så monteret den ultrasoniske sensor ovenpå.

Eksperimenter med den udleverede kode.
Tidsforbrug: 45 minutter.

Først kørte vi kun med RandomDrive. Denne ændrede vi hurtigere og uden pauser. Dette gjorde vi fordi den kørte så langsomt, at den kun meget sjældent kørte ind i ting.
Herefter aktiverede vi AvoidFront klassen. Denne virkede dog ikke umiddelbart og gav en konstant måling på 255. Løsningen var at flytte sensoren fra port 4 til port 3. Nu virkede den, men den kørte stadig ind i ting. Problemet løste vi ved at sætte threshold op fra 20 cm til 40 cm. Dette bevirkede at den herefter stoppede i god tid før kollision. Til sidst aktiverede vi PlaySounds og observerede at alle tre adfærdsmønstre kørte.

Under vores gennemgang af koden opdagede vi et par småfejl. Et par steder (AvoidFront og PlaySounds) fandt vi en række drawString() inde i en løkke. Dette er ikke noget problem i sig selv, men når den opretter et nyt String-objekt hver gang og VM'en ikke har en garbage collector, bliver det et problem med memory leaks. Vi løste problemet ved at ændre disse til drawChar(), da det alligevel kun var et enkelt bogstav den udskrev hver gang.

Diskussion af klasserne Behavior og Locomotion.
Tidsforbrug: 30 minutter.

Hvad er formålet med daemon threads?
En daemon thread kan ikke holde Java VM'en kørende hvis programmet afsluttes.

Hvordan bruges undertrykkelses booleanvariablen i LocoMotion.java?
Hvis en klasse har sin undertrykkelsesboolean sat, vil LocoMotion ikke adlyde den. Dens adfærd bliver da undertrykt.

Hvordan vil vi beskrive delay metoden i Behavior?
Det er en metode der busywaiter til en af to ting sker:

• Den når sin timeout værdi.
• Den er undertrykt.

Formålet er at være en slags adfærds-reset.

Hvordan bruges undertrykkelsesmekanismen i Behavior til kontrolleret adgang til motorerne?
Som udgangspunkt skiftes adfærdsmønstrene til at tilgå motorerne. Hvis en adfærd er undertrykt, vil delay-metoden afslutte med det samme og adfærden vil ikke kunne komme til udtryk.

Er der situationer hvor denne model fejler?
Når den bliver undertrykt, vil en adfærden løkke bare stå og loope. I det øjeblik den ikke er undertrykt mere, vil den stoppe et sted i løkken. Vi kan ikke være sikre på hvor dette sker, men kun håbe på at det er et "godt" sted.

Tilføjelse af nyt adfærdsmønster: "kør mod lyset"
Tidsforbrug: 1 time og 30 minutter.

Det første vi gjorde var en mindre refaktorering af den udleverede kode. I den udleverede kode skal en behaviour eksplicit kende alle behaviours den vil undertrykke. Dette gør det besværligt at tilføje nye behaviours eller ændre rækkefølgen af eksisterende behaviours. Vi udvidede Behaviour super-klassen med to feltvariable: child og childSuppressed, hvor child er en Behaviour og childSuppressed er en boolean. Desuden udvidede vi koden i Behaviour med:

private void updateChildSuppressed()
{
if(child != null)
child.setSuppressed(suppressed || childSuppressed);
}

Et child er altså suppressed hvis enten dens ane er suppressed eller dens ane eksplicit har bedt om at barnet er suppressed. På denne måde får vi en kæde af behaviours hvor den enkelte behaviour kun behøves at kende til den umiddelbart foregående.

Til denne delopgave udvidede vi bilen med en lyssensor. For at kunne observere den nye adfærd i detalje, måtte vi ændre et par af de andre adfærdsmønstre:

• RandomDrive blev ændret til at køre mere i cirkler og mindre lige ud. Hermed ville det være nemmere for den at "få øje på" lyskilden.
• Threshold for AvoidFront blev sat ned til 30 cm. Igen pga det lille testrum.
  

Vi havde sidste gang eksperimenteret med en robot der kan søge lyset ved at kigge på forskellen mellem to lyssensorer. Vi var dog kun i stand til at anskaffe to RCX lyssensorer, disse var dog ikke gode nok til at skelne små forskelle i lys så det kom aldrig til at virke særligt god. Denne gang valgte vi derfor en simplere metode der kun kræver en enkelt lyssensor og derfor kunne vi bruge NXT sensoren. Algoritmen var simpel: Vi beregner et vægtet løbende gennemsnit (som beskrevet i teksten her) af de lysværdier vi har set og hvis den værdi vi måler nu er større end gennemsnittet antager vi at robotten peger mod lys, suppreser barnet til vores Behaviour og sætter bilen til at køre fremad:

avg.addValue(val);
if(val > avg.get())
{
setChildSuppressed(true);
Locomotion.forward(300, 300);
delay(300);
}

Denne behaviour blev indsat mellem DriveRandom og AvoidFront:

RandomDrive rd = new RandomDrive("Drive", 1);
GoTowardsTheLight gl = new GoTowardsTheLight("Light", 2, SensorPort.S4, rd);
AvoidFront af = new AvoidFront("Avoid", 3, SensorPort.S3, gl);
PlaySounds ps = new PlaySounds("Play", 4, af);

Ideen er at hvis vi ikke ser lys kører vi tilfældigt rundt. Når vi så (tilfældigvis) peger i retningen af lys kører vi fremad. På den måde burde vi i længden nærme os eventuelle lyskilder.

Nedenstående billede er taget med lang lukketid i et møkelagt rum. Kameraet var indstillet til først at tage et billede med blitz og derefter holde sig åbent i 15 sekunder. Da det er håndholdt, er der en vist mængde af rysten, hvilket kan ses på, at lyskilden øverst til venstre i billedet har flyttet sig undervejs. Det ændrer dog ikke på billedets centrale budskab.
Til at begynde med stod bilen hvor den ses på billedet. Efter lyset blev slukket ses det, at den først drejer rundt om sig selv. Da får den øje på lyskilden og kører hen mod denne. Lige før den når frem, træder AvoidFront adfærden i kraft og den bakker tilbage. Til sidst kører den tilfældigt og taber lyset af syne, hvorefter de 15 sekunder er gået.

NXT programmering, lesson 7

Tidsforbrug: 3 timer.
Deltagere: Asbjørn, Christer og Jesper.

Målet for dagen session er, at bygge og programmere Braitenberg vehicles 2a & 2b.

Bygning og programmering skal foregå i disse skridt jfr opgaven:

• Bygge en bil og teste stabilitet.
  
• Implementere et styreprogram ud fra Tom Deans noter.
• Eksperiment med en flertrådet version.
• Automatisk løbende tilpasning af MAX_LIGHT og MIN_LIGHT

Programmerne vi lavede under denne session kan findes på adressen:
http://www.daimi.au.dk/~jn/lego/uge8/

Disse punkter vil blive gennemgået ét for ét.

Bygge en bil og teste stabilitet.
Tidsforbrug: 1½ time.

Vores første bud på en bil viste sig at være for høj. Det gav den et højt tyngdepunkt og dermed en tendens til at vælte forover ved hurtige retningsskift. Dette har vi forsøgt at løse ved at sænke NXT'en, hvorved det samlede tyngdepunkt blev sænket.
Det har vist sig at virke. Robotten væltede ikke mere efter dette.





Implementere et styreprogram ud fra Tom Deans noter.
Tidsforbrug: 30 minutter.

Første delopgave her var, at få nogen fornuftige målinger ud af lyssensorerne. Til denne opgave anvender vi to RCX sensorer. Som beskrevet i et af de tidligere indlæg, er disse sensorer ikke specielt gode til at skelne mellem lysstyrker. Vi vil gerne have, at en lille forskel i en lav lysstyrke giver en tydelig måling fra sensoren. Desuden ønsker vi ensartede reaktioner på input fra begge sensorer. De giver målinger i forskellige intervaller på samme lyspåvirkning. Dette kan vi kompensere for ved at have en MIN_LIGHT og MAX_LIGHT per sensor. Så kan vi normalisere input.



Efter vi havde implementeret styreprogrammet, forsøgte vi at lade bilen køre i et mørkt rum. Samme program kan uændret anvendes til både vehicle 2a og 2b ved at man bytter rundt på forbindelserne til motorerne. Her viste RCX sensorerne deres svaghed. Ved forsøg med at følge lyset fra en LED cykellygte, opnåede vi kun at kunne "se" ca 20 cm frem. Var lyset længere væk, var det for svagt til at robotten kunne reagere på det. Men ud over den manglende lysfølsomhed virkede programmet efter hensigten. Vehicle 2a flygtede fra lyset og vehicle 2b kørte mod det.

Eksperiment med en flertrådet version.
Tidsforbrug: 30 minutter.

En flertrådet version af styreprogrammet blev implementeret. Vi kunne ikke observere nogen forskel på denne version og den enkelttrådede.

Automatisk løbende tilpasning af MAX_LIGHT og MIN_LIGHT.
Tidsforbrug: 30 minutter.

Vi begyndte at implementere det, men så gik tiden. Når sensorerne ikke er bedre end de er, besluttede vi at droppe denne del. Det ville ikke have betydet noget særligt alligevel.

NXT programmering, lesson 6

Tidsforbrug: 3 timer.
Deltagere: Asbjørn, Christer og Jesper.

Målet for dagens session at bygge en robot der kan balancere på to hjul ligesom en Segway.

Vi startede med at dræbe den gamle robot (R.I.P.) og bygge en ny. I softwaren forsøgte vi først med en P-controller, men den viste sig at være helt utilstrækkelig.

Den direkte mapping mellem målinger og motor-output resulterede i vild overshoot. Denne ville vi da udvide til en PD-controller for at kompensere for dette. I denne process flyttede vi sensoren tættere på jorden for at opnå bedre målinger. I sin oprindelige position mistede den hurtigt jorden af syne når den vippede.

Vi opdagede desuden at den indbyggede Math.pow(double a, double b) er defekt.
Derfor måtte vi ændre styringen, så vi ikke skulle bruge denne funktion. Vi modificerede PD-styringen til at benytte en ulineær funktion.

Nu prøvede vi at ændre robottens fysiske egenskaber ved at hæve tyngdepunktet. Dette gjorde vi ved at hæve NXT'en nogle centimeter. Hjulene skiftede vi også til en større model for at opnå en hurtigere respons når ubalance måles.

Det lykkedes desværre ikke i dag at få den til at holde balancen mere end et sekund ad gangen.

NXT Robot Race (lesson 5)

Tidsforbrug: 3 timer.
Deltagere: Asbjørn, Christer og Jesper

Målet med dagens lektion er, at få vores robot til at følge en sort
streg på en bane på kortest mulig tid. Til slut skal vores tid
indsendes til Legolab.

Grundlæggende var vi enige om at vores robot havde den korrekte
grundlæggende funktionalitet og dagen skulle bruges til at kalibrere
diverse konstanter i robotten for at opnå optimal hastighed.

Vi havde to forskellige "håndtag" vi kunne dreje på, begge relateret
til hastigheden i sving. Som det kan ses på billeder har vores robot
tre sensorer. Vores program kører robotten fremad hvis den midterste
sensor ser sort. Hvis den midterste sensor ikke ser sort, men er af de
andre to gør drejer den ind imod banen igen. Det gør den ved at det
ene hjul kører ved fuld hastighed og det andet kører ved en anden
hastighed. Denne anden hastighed kaldes herefter halfSpeed. Hvis ingen
af sensorne ser sort drejer den skarpt imod den side hvor den sidst
har set sort. Igen gøres det ved at det ene hjul kører ved fuld
hastighed mens det andet kører ved mindre hastighed. Denne mindre
hastighed kalder vi stopSpeed. De to variabler vi har leget med er
altså halfSpeed og stopSpeed.

Det første vi gjorde var at skifte batterierne til almindelige AA
batterier og sætte det store specielle batteri til opladning. Vi satte
da stopSpeed til 0 og eksperimenterede med forskellige værdier af
halfSpeed. For hver værdi lavede vi tre tests på banen:

halfSpeed	stopSpeed	tid / s
600	0	21,8
-	0	21,9
-	0	22,8
700	0	22,5
-	0	22,9
-	0	22,9
800	0	Fejl
-	0	23,8
600	0	22,8
-	0	23,1
-	0	23,2
500	0	23,1
-	0	23,3
-	0	23,4

På dette tidspunkt valgte vi at stoppe. Vi nøjedes med kun to målinger
ved værdien 800 fordi den værdi gav meget dårlige resultater. Kigger
du på ovenstående bruges værdien 600 to gange og giver forskellige
resultater. Vores konklusion var at det var vigtigere at der er meget
strøm på batterierne end hvad værdien af halfSpeed er.

Vi ændrede nu softwaren til at kunne skifte halfSpeed of stopSpeed
variablerne på runtime med et menu-system og skiftede batteriet
tilbage til det medfølgende specielle batteri og lavede nye
tests. Denne gang testede vi kun en gang for hver parameter. Først
koncentrede vi os om at skyde os ind på nogle gode værdier til
halfSpeed med de nye batterier:

halfSpeed	stopSpeed	tid / s
600	0	22,3
550	0	22,5
650	0	22,0
700	0	22,9

Dernæst eksperimenterede vi med stopSpeed:

halfSpeed	stopSpeed	tid / s
650	100	22,0
650	200	22,0
650	400	22,6
800	500	23,3

Hvor den sidste test var et halv-desperat forsøg på at få meget fart
ud af robotten ved hele tiden at køre hurtigt. Det mislykkedes
naturligvis fordi den nu ikke længere var i stand til at følge banen
godt.

På dette tidspunkt koknkluderede vi at den eneste måde at få mere fart
på var bedre batterier, som vi ikke umiddelbart kunne finde. Vi gav
derfor umiddelbart op.

Nu var der ca. en time tilbage og for sjov ville vi få robotten til at
spille et stykke musik mens den kørte. Som musik valgte vi naturligvis
fjerde del af ouverturen fra William Tell. (Det eneste muligt korrekte
valg.) Vi fik bilen til at stå stille under introen hvilket så meget
imponerende ud. Det sjove er at med musik satte vi dagens bedste tid
(for vores bil):

halfSpeed	stopSpeed	tid / s
600	50	21,317

Vores bedste gennemkørsel:

En AVI kan hentes her.
Den spiller føromtalte melodi, men desværre bliver den overdøvet af motorerne.

NXT programmering, lesson 4½

Tidsforbrug: 3 timer, onsdag d. 3. oktober
Deltagere: Asbjørn, Christer og Jesper

Målet med dagens ekstraordinære session er, at arbejde videre på forberedelsen til løbet. Vores robot kørte ikke hurtig nok og desuden var der flere mangler hist og pist. Så den blev sendt på operationsbordet for at blive udstyret med ekstra gearing.

Planen er i store træk:

• Montere gearing så robotten kører hurtigere
• Udvide programmet til at stoppe ved grønt
• Udvide programmet til at tage tid
• Optimeringer (vi har f.eks. lidt overshoot når robotten drejer)
• Diverse... :)
  

I det følgende vil vi ikke nødvendigvis gennemgå disse punkter i denne rækkefølge. Vi vil snarere beskrive vores arbejdsgang i kronologisk orden.
Kl 17:30
Første udkast til den nye gearing er så småt på plads.

kl 17:55
Den nye gearing er færdigmonteret, men bilen kører nu baglæns. Fejlen rettes i software. Desuden er tyngdepunktet blevet rykket så langt frem, at vi midlertidigt monterede ekstra kontravægt.



kl 18:15
Første rigtige testkørsel med den nye gearing. Motorerne er for stærke. Med den nye gearing hopper sensorerne op og ned, og robotten får ikke ordentlige målinger. Det bevirker at den "stikker af" og slet ikke kan følge sporet. Vi diskuterer forskellige løsningsmodeller:

• Mere vægt foran.
• Dette viste sig at være utilstrækkeligt.
  
• Mindre aggressiv gearing.
• Softwaren skal ikke kompensere så kraftigt.

Desuden opdaterer vi softwaren med default måleværdier, så vi ikke behøver at kalibrere sensorerne ved hver eneste kørsel.

Kl 18:30 - 19:00
Pizzamanden ankommer og arbejdet indstilles. :)

kl 19:00
Vi indser at gearingen får robotten til at køre for hurtigt. Den kan simpelthen ikke nå at ændre retning før det er for sent. Vi beslutter at fjerne gearingen helt, men beholde de store hjul. Dette viste sig at være en god ide. Vi retter nu opmærksomheden mod overkompenseringen i svingene.

kl 20:00
Vi begynder så småt at pakke sammen. På nuværende tidspunkt er vi rimeligt tilfredse med robotten og det er kun småting der mangler. Disse regner vi med at kunne nå at udbedre fredag inden det endelige løb.

Dagens bedste tid for en gennemkørsel af banen:
22,3 sekunder

NXT programmering, lesson 4

Tidsforbrug: 3 timer
Deltagere: Asbjørn, Christer og Jesper

Målet for dagens session er, at:

• Black White Detection
• Montering og test af lyssensor
  
• Line Follower with Calibration
• Brug af lyssensor til at følge en sort streg
  
• ColorSensor with Calibration
• Udvidelse af kode til at genkende grøn
• Line Follower that stops in a Goal Zone
• Forberedelse til næste uges løb

Programmerne vi lavede under denne session kan findes på adressen:
http://www.daimi.au.dk/~jn/lego/uge5/

Disse punkter gennemgår vi et for et nedenfor.

Black White Detection
Tidsforbrug: 15 minutter.

Dagens første opgave var at montere lyssensoren på LEGO™ bilen. Det var hurtigt gjort ud fra LEGO™ Mindstorms Education NXT Base Set 9797 byggeinstruktionshæftet. Derefter hentede vi BlackWhiteSensor.java og skrev et program omkring den. Igennem eksperimenter kunne vi se, at den var meget god til at skelne mellem mørke og lyse farver. Mørke farver gav høje værdier og lyse farver gav lave værdier.


Line Follower with Calibration
Tidsforbrug: 45 minutter

Vi hentede LineFollowerCal.java fra nettet og forsøgte at overføre det til NXT'en. Det lykkedes dog ikke først. Hver gang vi prøvede, skrev den "Data abort", dumpede registre til skærmen og frøs. Vi lånte da en NXT af en anden gruppe og forsøgte at overføre programmet til den i stedet. Det virkede fint, hvorfor vi konstaterede, at det var vores NXT den var gal med. Herefter hentede vores instruktor en ny NXT til os, hvilket løste problemet. Vi kunne nu køre programmet og følge en sort streg på gulvet.

ColorSensor with Calibration
Tidsforbrug: 30 minutter

Nu skulle vi udvide BlackWhiteSensor til ColorSensor, så den kunne skelne mellem sort, hvid og grøn. Så i stedet for at opdele intervallet af mulige målinger i to klasser, skal den nu opdeles i tre, da grøn måles som en gråtone et sted mellem de to andre. Det viste sig eksperimentelt at den anvendte nuance af grøn gav en måling ca midt mellem målingerne for sort og hvid.

Line Follower that stops in a Goal Zone
Tidsforbrug: 90 minutter (resten af tiden)

Nu var det tid til at arbejde på bilens egenskaber for at følge linjen på jorden hurtigst muligt. For at forbedre bilens evne for at holde sig på stregen, udvidede vi den med to RCX lyssensorer som vist på billedet til højre.
Vi opdagede at de tilgængelige RCX sensorer ikke havde samme følsomhed som NXT sensoren. Der var simpelthen ikke så stor forskel på en hvid-måling og en sort-måling. Farvemåling viste sig at være upraktisk, hvis ikke umulig. Dette er dog ikke at være et problem, da vi kun har brug for at genkende farve til aller sidst, og der er NXT sensoren nok. For at kunne bruge både RCX og NXT sensorer med vores BlackWhiteSensor og ColorSensor lavede vi et software interface fælles for de to og wrapper klasser til at pakke LightSensor og RCXLightSensor klasserne ind.

Efter gentagne eksperimenter med den viste robot besluttede vi os for at ændre den igen. Sensorerne sad for tæt på hinanden og for tæt på robotten. Dette bevirkede, at den reagerede for sent når underlaget ændrede sig. Desuden har vi udviddet softwaren så den ikke bare reagerer i forhold til hvad den ser lige nu, men husker til hvilken side den sidst har set stregen, så hvis den kører helt uden for stregen kan den finde den igen. Denne opdatering gjorde en meget stor forbedring. Det lykkedes altså at finde en konfiguration der virkede ret godt, men vi aftalte at mødes igen den følgende uge til en gang tweaking inden konkurrencen.

NXT programmering, lesson 3

Tidsforbrug: 3 timer og 10 minutter
Deltagere: Asbjørn, Christer og Jesper

Målet for dagens session er, at:

• Test of Sound Sensor
• Sound Controlled Car
  
• Clap Controlled Car
  

Programmerne vi lavede under denne session kan findes på adressen:
http://www.daimi.au.dk/~jn/lego/uge4/

Disse punkter gennemgår vi et for et nedenfor.

Test of Sound Sensor
Tidsforbrug: 45 minutter.

Vi monterede sensoren som beskrevet i materialet. Herefter overførte vi det udleverede testprogram og konstaterede at det virkede. Til målingerne af lyd som funktion af afstanden mellem kilden og bilen ændrede vi i programmet, så det ud over de aktuelle lydniveau også printede det maximalt målte. Vi anvendte enter-knappen til reset af maximum-målingen.
Generelt så vi, at jo højere lyd, jo højere måling. Vi kørte to måleserier. En med høj lyd og en med let dæmpet lyd. Lyden var i begge tilfælde Windows™ lyden ding.wav. Et sammendrag af målingerne ses i tabellen.

Afstand i cm	Lav lyd	Høj lyd
10	10	49
20	8	37
30	7	30
40	0	31

Sound Controlled Car
Tidsforbrug: 15 minutter.

Programmet har fire tilstande: fremad, venstre, højre, stop. Hver gang man laver en tilstrækkelig høj lyd, som trigger en tilstrækkelig stor måleværdi, skifter den til næste tilstand. Som beskrevet i opgaven pollede den kun efter escape-knappen i yderste loop. Vi tilføjede da en boolean variabel, stop, som en ButtonListener hele tiden opdaterer ud fra escape-knappen. Denne opdatering overførte vi til bilen, hvor vi konstaterede at den virkede.

Clap Controlled Car
Tidsforbrug: 30 minutter.

Vi implementerede Sivan Toledos algoritme for genkendelse af klap. Den virkede ikke til genkendelse af klap, men reagerede i stedet på små "skarpe" ord. Det opdagede vi da Christer udtalte, at han troede den var gået kold. Så vi konkluderede, at metoden i SoundCtrCar.java var væsentlig bedre.

Resten af tiden
Tidsforbrug: 90 minutter

Da vi nu var igennem dagens program, kunne vi eksperimentere med yderligere forbedringer. En af disse var at udvide SonicSensorTest.java, så den plotter lydstyrken på NXT'ens skærm.

NXT programmering, lesson 2

Tidsforbrug: 3 timer og 10 minutter
Deltagere: Asbjørn, Christer og Jesper

Målet for dagens session er, at:

• Test of Ultrasonic Sensor
• Obstacle Avoider
• Wall Follower

Disse punkter gennemgår vi et for et nedenfor.

Test of Ultrasonic Sensor.
Tidsforbrug: 20 minutter.

Den første opgave var at montere den ultrasoniske sensor på LEGO™ bilen. Det var hurtigt gjort ud fra LEGO™ Mindstorms Education NXT Base Set 9797 byggeinstruktionshæftet. Herefter var det tid til at hente SonicSensorTest.java. Desværre var serveren nede, hvorfor vi var nødt til at finde en udprintning og indtaste programmet selv. Som beskrevet til forelæsningen kunne vi konstatere en stor forskel i evnen til at måle afstande i alt efter vinklen mellem ultralydens udbredelsesretning og normalen på den overflade den rammer.

Ved at sammenholde måleresultater med et målebånd vi havde udspændt på gulvet, har vi konstrueret en omregningstabel mellem udlæsning og afstand i centimeter.

Afstand i cm	Måling
10	15
20	23
30	31
40	41
50	51
60	61
70	72
80	86
90	92
100	-

Som det ses, er der en ret god direkte sammenhæng mellem disse to tal.

Obstacle Avoider
Tidsforbrug: 1 time.

Her var vi igen nødt til at indtaste de to klasser Avoider.java og Locomotion.java der udgjorde programmet. Efter en del debugging virkede de endelig og vi kunne teste. Som udgangspunkt var det udleverede program temmelig forsigtigt. Det satte farten ned i god tid før bilen ramte væggen. Efter at have justeret distanceThreshold ned til 20 fik vi den til at køre væsentlig tættere på væggen. Ligeledes eksperimenterede vi også med at variere maxDistance. Ved at sætte denne ned til 50 (og bibeholde den ændrede distanceThreshold) kunne vi få den til at køre hurtigere og tættere til væggen, hvor den stoppede helt ca. en centimeter fra.
Bilens hastighed (the controlled variable) er beregnet direkte ud fra afstandsmålingen (the measured variable) og konstanterne. Derfor er der tale om en simpel feedback kontrol.

Wall Follower
Tidsforbrug: 1 time og 50 minutter.

Vi udvidede vores robot med ultralydssensoren. Herefter forsøgte vi uden held en direkte oversættelse af NQC-programmet. Det mislykkedes fordi programmet var lavet til et andet system (RCX) og dets kontrollogik var uoverskuelig pga dårlige variabelnavne. Efter et par mindre refaktoreringer fik vi programmet til at virke fornuftigt.

Så tweakede vi konstanter for at optimere ydelsen. Blandt andet skulle kørselshastigheden sættes ned og samplingfrekvensen op. Derved kunne robotten nemmere nå at reagere på sine omgivelser i tide. Et gennemgående problem er, at robotten, specielt omkring hjørner, taber væggen af "syne" og begynder at køre rundt om sig selv (med en konstant afstandsmåling på 255). Dette kan skyldes den effekt vi observerede i ugens første delopgave, hvor vi så at vinklen til objektet vi målte på betød en del.

Til sidst droppede vi vores første bud på at montere sensoren og monterede den nede forrest på robotten i stedet (se billede). Dette gav meget bedre resultater. Nu kunne den finde rundt om hjørner, da sensoren ser hjørnet før den kører forbi.

NXT programmering, lesson 1

Tidsforbrug: 3 timer
Deltagere: Asbjørn, Christer og Jesper

Målet for dagens session er, at:

• Pakke vores LEGO™ ud.
  
• Bygge en LEGO™ bil efter medfølgende instruktioner.
• Installere leJOS.
• Compile et Java-program og køre det på NXT'en.

Vi startede med at pakke vores LEGO™ ud og fordele det i de medfølgende plastikbakker. Herefter byggede vi bilen efter de medfølgende instruktioner på ca 45 minutter. Efter dette forsøgte vi at køre bilen med den forudinstallerede software. Det lykkedes ikke at få den til at følge en sort streg på denne måde, men det generede os ikke umiddelbart, da det trods alt ikke er det vi skal bruge.

Herefter påbegyndte vi installationen af leJOS. Dette kompliceredes af, at ingen af os besidder laptops med optiske drev. Installationen drillede. For det første tog det lang tid at hente alle de nødvendige programmer og bagefter tog det et par forsøg at få sat diverse miljøvariable korrekt op. Det viste sig også at libusb skal ligge i et bibliotek med et DOS 8.3 filnavn. I alt brugte vi ca. 80 min på at få sat softwaren op.

Da først vi fik flashed NXT'en til lejOS gik alt dog let. Vi gik nu i gang med at teste LineFollower.java programmet. Det første vi gjorde var at teste de rapporterede lysværdier for henholdsvis lyst og mørkt papir. vi fik ca. 45 og ca. 60 og satte derfor variablen blackWhiteThreshold til 54. Nu kunne vi teste bilen og konstanterede at den fint fulgte enbred sort streg.

Næste forsøg var at lege med sample intervallet. Det startede på 100ms, hvor den virkede ude mærket. Næste forsøg var på 500ms. Det resulterede i at den ikke kunne reagere hurtigt nok på at den fandt den sorte streg og at bilen derfor var generelt ude af stand til at følge stregen. Sidste forsøg var med 10ms, og her var bilen fint i stand til at følge stregen. Om muligt kørte den her endnu bedre, da bilen meget hurtigt kunne reagere på ændringen i lyset og derfor ikke nåede langt væk fra stregen før den drejede tilbage ind på den.

Til sidst lavede vi forsøg med hukommelsesforbruget. Vi brugte inline streng literals i stedet for variablerne left og right og fik den til at udskrive Runtime.getRuntime().freeMemory(). Det der skete var at vi kunne se den ledige hukommelse forsvinde hurtigt. Da der ikke var mere hukommelse tilbage smed bilen en exception og vi kunne kun stoppe den ved at resette den ved at trykke enter og escape på samme tid. Grunden til at hukommelsen forsvandt var naturligvis at den ikke har nogen garbage collector og når vi bruger string literals bliver VM'en ved med at oprette nye string objekter der ikke forsvinder igen.

I alt tog de to eksperimenter ca. 30 min.