End Course Project Bonanza

Vi har i løbet af vores projekt valgt at samle alle vores End Course Project sessions i et enkelt Google Docs som kan findes her.

Alternativt kan de samlede sessions hentes soms PDF her.
Ydermere kan koden til vores balancerende robot findes her

Billedserie mht. konstruktionen kan findes her (comming asap)

Ønsker man ikke at følge fodnoterne til de to youtube film i vores Google Doc kan de også ses nedenfor: 

End Course Project Planning

Date: 8/5 2014
Duration of Exercise: 3 timer
Group Members Participating:
Henrik Jørgensen
Michael Schiønning
William Thorsen

Mål

Målet med denne øvelsesgang er, i enighed, at nå frem til had vores End Course Project skal være.

Plan

Planen for denne uge er:

• Finde en række potentielle projekter
• Udvælge hvilket projekt vi vil arbejde videre med 
• Påbegynde blogindlæg

Fremgangsmåde

Efter en indledende diskussion nåede vi frem til tre kandidater til vores End Course Project

Robot Balancing On A Ball

Den første idé er en robot der kan balancere på en bold, samt holde balancen selvom der puffes let til enten bolden eller robotten. 

Hardware

• 1 NXT unit 
• 3 motorer til hjulene
• 2 Hitechnic Gyro Sensors til at stabilisere robotten 
• 1 bold til at balancere robotten på 
• 3 omnidirektionelle hjul 

Software

• Behaviour alt efter hvilken tilstand robotten er i (Altså, hvilke motorer der skal aktiveres for at robotten ikke falder ned fra bolden) 
• PID til at kunne finjustere motorerne 

Den sværeste del af opgaven ville være at kunne kalibrere PID'erne til de tre motorer og derved sørge for at de reagerer korrekt når robottens balance forstyrres og derved korrigerer sin placering på bolden. 

Det endelige resultat vil derfor være en robot der kan balancere, uden assistance, på en bold og vil opretholde balancen selvom man skubber let til enten robotten eller bolden. 

WRO 2014

En robot der kan finde og scanne de ni solpaneler på banen. Såfremt robotten registrerer ogle defekte paneler skal de udskiftes med nye paneler fra et lager på banen. 

Hardware

• 1 NXT unit
• 3 Lyssensorer. To til at kunne følge banen (á la LineFollower) og en tredje til at registrere om de solpaneler robotten kører henover er defekte eller ej. 
• 2 motorer til hjulene
• 1 motor til en løftemekanisme, der skal bruges til at fragte de defekte paneler væk og erstattes med de nye fra et lager 

Software

• Softwarearkitekturen til denne opgave er behaviour-based. Robotten checker alle solpanelerne og i det øjeblik den finder en defekt skifter vi opførsel og skal udskifte det givne panel. Efterfølgende fortsættes den oprindelige behaviour og vi checker de resterende solpaneler.

Det absolut sværeste ved denne opgave er at kunne designe en robot, der kan navigere banen uden at støde ind i solpanelerne, samt at designe selve navigeringen. Problemet ligger i, at vi ikke har en fritliggende linje, som vi let kan følge og at robotten skal være i stand til at kunne vende tilbage til det defekte panels plads med erstatningen. 

Til slutpræsentationen skal vi have en robot der som minimum kan scanne de ni paneler og bringe et defekt panel med sig tilbage til basen/lageret.    

Navigating LEGO Road Elements

Til denne opgave skal NXT'en først navigere en opsat bane og efterfølgende danne sig et "roadmap" så den kan find den korteste rute fra et punkt A til B på banen. 

Hardware

• 1 NXT unit
• Mindst 3 lyssensorer. Den første placeres centralt og kan via en LineFollower navigere banen. De resterende to sensorer placeres på hver sin side af robotten så vi kan registrere mulige fodgængerovergange. Gør vi dette skal det noteres at der er muligheder for dele af kortet vi ikke har besøgt og vi skal vende tilbage til det.

Software

• Sekventiel softwarearkitektur med dynamisk tilgang
• Første sekvens indebærer at robotten kører en rute á la LineFollower
• Når robotten er vendt tilbage til sit udgangspunkt, checker vi om vi har passeret nogle fodgængerovergange, hvilket er lig med potentielle sving. NXT'en returnerer til det punkt og mapper den sidste del af banen
• Til sidst er det "blot" et spørgsmål om at kunne udregne den korteste rute fra A til B og omsætte den udregning til en kørselsvejledning. 

Den sværeste del af opgaven ville først og fremmest være at kunne mappe banen og skelne imellem den grå og hvide farve på vejen når vi skal bearbejde fodgængerovergangene. 

Til slut skal robotten kunne mappe en hel bane og efterfølgende kunne finde frem til den korteste vej imellem to specifikke punkter på banen. 

Konklusion

Vi har valgt at arbejde med balancerobotten. Dette er fordi at det først og fremmest er en anderledes opgave i forhold til de to andre opgaver der omhandler pathfinding. Selve robotten er ikke det mest udspekulerede design og derved kan fokus hurtigt flyttes over til softwarearbejdet med kalibreringen. En anden god ting ved dette projekt er, at det hverken er bøvlet at teste eller sætte op til den endelige præsentation. Det eneste der er brug for er robotten samt en bold. 

Embedded Systems Lesson 10

Date: 1/5 2014
Duration of Exercise: 3½ time
Group Members Participating: 
Henrik Jørgensen
Michael Schiønning
William Thorsen

Mål

Målet med denne øvelsesgang er at gennemføre øvelserne til denne uges ugeseddel Motivation-Based Behavior Selection in Agents

Plan

Planen for denne uge er:

• Bygge en robot til øvelserne
• Udføre opgaverne på ugesedlen  
• Påbegynde blogindlæg 

Fremgangsmåde

Til  BumperCar-opgaven skulle vi igen arbejde med leJOSs Arbitrator- og Behaviorklasser. Vi havde allerede fra sidste uge påbegyndt basen af robotten og kunne nu nøjes med at påmontere den ultrasoniske sensor og bumperen vha en touch-sensor. Nedenstående ses et billede af vores BumperCar.

Til øvelserne tog vi udgangspunkt i den udleverede BumperCar.java fil og skulle gøre os en række observationer omkring klassen og derved robottens opførsel. Til at starte med kørte vi et "dry" testrun og kunne konstatere at robotten kørte fremad indtil enten den ultrasoniske sensor registrerede en forhindring. Det samme gjaldt touch-sensoren. Al brugt kode kan findes til sidst i rapporten. 

Så snart en af de to sensorer blev aktiveret ville robotten aktivere behavior'en "DetectWall" og  stoppe, bakke og dreje en smule til den ene side før den fortsætter med at køre fremad igen. Vi satte et elastik rundt omkring vores bumper og derved blev DetectWall hele tiden aktiveret og robotten blev altså ved med at bakke og efterfølgende dreje ad nauseum. 

Adfærden Exit, som reagerer på Escape-knappen og kalder System.Exit(0), er implementeret som en klasse efter samme princip som DriveForward og DetectWall. Exit-adfærden er sat til sidst i adfærdslisten og derved får den den højeste prioritet. 

Efterfølgende prøvede vi at teste vores Escape-knap når robotten bevægede sig rundt. Så snart knappen trykkes stoppede programmet øjblikkeligt såfremt DriveForward havde prioritet. Var det tilfældet at DetectWall var under opsejling ville den først færdiggøre sin bakken og korrigering af ruten før robotten stoppede. 

I både DetectWall og DriveForward har vi metoden takeControl der kaldes i Arbitrator. Vi skulle finde ud af om, at DriveForward's takeControl metode også kaldes når vores triggering condition for DetectWall opfyldes. Som det fremgår ud fra kodestykket neden under fra Arbitrator klassen. Her kan vi set at den starter fra den højestre prioritet og checker hvorvidt takeControl() returnerer true. Er det ikke tilfældet checker vi den næsthøjeste prioritet osv. Dvs i vores tilfælde bliver takeControl() i DriveForward ikke kaldet, hvis DetectWalls takeControl() returnerer true. 

             maxPriority = -1; highest = -1;
          for (int i = 0; i < behavior.length; i++)
          {
           int priority = behavior[i].takeControl();
                 if (priority > maxPriority ) 
                 {
                    highest = i;
                    maxPriority = priority;
                 }
          }

Ydermere skulle DetectWall sættes til at bakke i 1 sec før den begyndte at dreje og efterfølgende bevæge sig fremad. Dette kan ses ud fra følgende kodestump 

    Motor.A.backward();
    Motor.C.backward();
    int now = (int)System.currentTimeMillis();
    while (!_suppressed && ((int)System.currentTimeMillis()< now + 1000))

Sumo-robot

Til sumorobotten gik vi ud fra den opgivene kode, hvor vi implementerede flere behaviors for at gøre robotten til en bedre sumorobot. Da vi kom ldit sent i gang med sumo-delen af opgaven (og derved ikke nåede at være med til selve konkurrencen) sad vi til sidst og biksede lidt med en rimelig simpel tilgang til sumorobotten. Derved har vi ikke en video eller et billede af robotten. Den er i bund og grund det samme skelet som vores BumperCar fra første del, tilsat en lyssenor foran og bagved samt et lidt større hjul på vores touch-sensor. 

Først ændrede vi en DetectWall klassen til i stedet for at bakke væk, når bumperen er trykket, så kører vi lige frem i små korte ryk. Denne behavior fik den højeste prioritet da tanken bag var at når bumperen var trykket så ville vi være lige foran en modstander og kunne forhåbentligt brute force modstanderen ud af ringen. 

Denærst monterede vi 2 lyssensorer, henholdsvis foran og bagved. Sensorerne  skulle bruges til at sørge for at vi ikke kørte eller bakker ud af banen . Her løb vi ind i et problem, hvor vi ikke kunne få bilen til at skifte prioritet mellem de klasser som håndterer lyssensoren. Vi tænkte at med samme prioritet 

(return 75;) ville de skifte imellem dem. Fx hvis en lyssensoren bagpå robotten registrerede et skift fra sort til hvid ville den køre frem for ikke at falde ned fra banen og derved tabe. Når den forreste sensor så registrerede et skift kunne den ikke tage prioritet, og visa versa.

Tanken var at vi videre hen måske ville bruge den ultrasoniske sensor  til at scanne efter en modstander. Anden ide var sætten endnu en bumper bagpå og så have bilen kører frem og tilbage, med små turns, indtil den fik et input på en bumper og så kører fuld kraft i den givne retning.

Den brugte kode kan findes her 

Konklusion

I denne uge har vi arbejdet videre med adfærdsbaseret arkitektur, som er implementeret i subsumption API'en af leJOS NXJ. Vi har lært at "motivation values" giver os en hurtigere reaktiong og derved et bedre resultat hvad vores behaviors angår. Dette kan f.eks. ses i forbindelse med, at når vores EXIT behavior aktiveres får vi en øjeblikkelig reaktion. 

Embedded Systems Lesson 9

Date: 29/4 2014
Duration of Exercise: 3 timer
Group Members Participating:
Henrik Jørgensen
Michael Schiønning
William Thorsen

Mål

Målet med denne øvelsesgang er at gennemføre øvelserne til denne uges ugeseddel Navigation and Map Building

Plan

Planen for denne uge er:

• Bygge en robot til øvelserne
• Udføre opgaverne på ugesedlen 
• Påbegynde blogindlæg

Fremgangsmåde

Vi lagde ud med at bygge basen til en robot ved at genbruge vores design fra forrige uges opgave. Derefter testede vi, hvilke hjul der ville være bedst til eksperimentet.

Vi startede med at prøve de store flade hjul med mål 81.6 x 15, fordi vi gerne ville hæve robotten så vi kunne få et roterende hjul ind under. Dette gjorde dog at udførselen af TachoNavigator blev meget "stor" med hensyn til arealet robotten kørte.

Efter et par test for at sikre os at koden virkede skiftede vi til de mindre 56 x 26 hjul og gjorde selve ruten for robotten 5 gange mindre, hvilket gav et fint lille areal hvor robotten kørte. De mindre hjul gjorde også at robotten bevægede sig mere roligt og forekom at have mindre slip imellem dækkene og overfladen. Desuden var svingene ikke så voldsomme og kastede ikke robotten ud af kurs. Aligevel kunne vi ikke konsistent få den tilbage til udgangspositionen.
Vi fik dog robotten til at give det samme resultat som Blightbot og derved finde frem til den distance den skal køre.

Koden kan findes her

Dernæst skulle vi som Maja Mataric placerer en marker for enden af robotten så vi kunne tegne den rute som vi havde kørt. Her opstod et problem med designet;

Vi havde spændt boardmarkeren foran med elastikker og da vi kørte robotten begyndte den at ryste så vi fik lange rækker af prikker eller bare ingenting.

For at løse dette forsøgte vi at sætte et par extra elastikker på som kunne presse boardmarkeren ned på whiteboardet.
Dette gav flere problemer da boardmarkeren da løftede robotten en smule og dermed havde hjulene ikke god kontakt med underlaget og den drejede da helt ud af kurs. I stedet for at bruge tid på et justere designet valgte vi at gå videre og bygge en ny robot fra bunden af med byggeguiden fra uge 7, da samme robot skal bruges til næste uges opgave, Sumobryderen.

 

Ovenstående kørsel er et resultat af

LegacyNavigator robot = 
new LegacyNavigator(wheelDiameter, trackDiameter, Motor.B, Motor.C, true);
for(int i = 0; i < 10; i++) {
robot.goTo(40F, 0F);
robot.goTo(20F, 20F);
robot.goTo(20F, -10F);
robot.goTo(0F,  0F);
}

Improved navigation.

En måde til at undgå objekter foran robotten er ved at bruge den  ultrasoniske sensor. Sensoren skal køre i en tråd hele tiden ved siden af selve vores rutenavigation. Registrerer den ultrasoniske sensor et objekt som er i vejen skal en ny rute beregnes.

Posering

Fremgangsmåden i [2] kaldes dead reckoning og deres implementation beregnes en fejlmargin set udfra hvor meget et givent hjul har kørt i forhold til hvad det burde have kørt. Denne korrektion for fejl kan ses som en P kontrol.

Fremgangsmåden i [5] er at beregne motorkraften udfra en model og så undervejs korrigere for eventuelle afvigelser. Da [5] ikke akkumulerer fejl bør den være mere præcis.

Beregningerne foretages i [5] ved tidsinterval kontra [2] der beregner efter en given kørt distance. Så her burde [5] også være mere præcis, dog kun så længe at tidsintervallet er mindre end distance intervallet i [2].

Lejos egen algoritme er implementeret i OdometryPoseProvider.updatePose()

Her ses det at Lejos skelner imellem det at dreje og det at køre lige ud. Denne skarpe opdeling virker til at give plads til akkumulering af fejlmargin da det hele afhænger af den drejede vinkel, som er upræcis.

Konklusion

I denne uge har vi arbejdet med tacho counteren og erfaret, at selvom der kan forekomme afvigelser, specielt når vores robot svingede, er det rimeligt simpelt at kunne præcisere robottens bevægelser vha. manipulering af tacho counteren. Der vil dog over tid nærmest uundgåeligt akkumulere fejl den antagede og reelle placering ved brug af dead-reckoning. Upræcise tachocounters, slip i dækkene o.l. gør at selv den perfekte algoritme vil afvige over tid.

Embedded Systems Lesson 8

Date: 22/4 2014
Duration of Exercise: 9 timer
Group members participating:
Henrik Jørgensen
Michael Schiønning
William Thorsen

Mål

Målet med denne øvelsesgang er at gennemføre øvelsen til denne uges ugeseddel Robot Race, altså at bygge en robot der kan gennemføre Alishan banen.

Plan

Planen for denne uge er:

• Bygge en robot der kan gennemføre banen
• Programmere robotten så den kan gennemføre banen
• Påbegynde blogindlæg

Fremgangsmetode
Design af robotten:

Vi så med det samme at udfordringen lå i svingene og at det nok største problem lå i at vide hvornår vi skulle dreje. Efter en del trial-and-error fandt vi et design der ved brug af to touch-sensorer kunne registrere når en bom monteret foran på robotten var enten oppe, midt eller nede. Med denne var planen at føle hvornår robotten skulle dreje et forud defineret sving og dermed helt undgå at følge linjen på plateauerne. Bommen kunne desuden bruges til at afskærme de to lysesensorer fra indtrængende sollys.

Dette bom-design var mere problematisk end forventet at føre ud i livet og krævede en del timers arbejde.
En del af problemet lå naturligvis i sammensætningen af klodser for at opnå en tilstrækkelig rigid robot.
Vi havde brugt Lego Digital Designer til det første design og her er det let at blive snydt da tingene bare sidder fast hvor de skal. Da vi så samlede den designede bil så vi at det hængte sammen, bogstavligt talt.

Et andet problem var at touch sensors ikke har samme (de)aktiveringspunkter, denne forskellighed i følsomhed havde vi ikke umiddelbart tænkt på og det kostede igen tid at finde "sweet spot" så bommen virkede efter hensigten.



Kommunikation med robotten:
Vores tidligere implementering af Bluetooth var meget begrænset og slet ikke gearet til at sende information både til og fra robotten. Vi måtte da bruge en del tid på at udvide vores BT framework, dette kompliceredes desværre af en HashMap implementation i Lejos som ikke virker korrekt og smed tilsyneladende uvedkommende NullPointer exceptions til højre og venstre.

Design af programmet:
Vi besluttede at bruge en subsumption arkitektur. Dog så vi en problematik i forhold til antallet af behaviors der unødigt havde prioritet i forskellige stages af gennemkørselen. En idé var derfor at ændre i listen af behaviors alt efter hvilken stage af Alishan vi var nået til.

Simpel inddeling af stages og tilhørende behaviors.

Med to lys-sensorer brugte vi to PIDControllers fra lejos.robotics pakken. Her brugte vi manipulated value (mv) fra højre(venstre) lyssensor til at sænke farten på venstre (højre) hjul.

 Grov skitse over brug af to lyssensorer ift. styring
af tildelt kraft til det enkelte hjul.

Denne fremgangsmåde til dobbelt PID styring synes at virke godt når vi alene skal følge en lige linje. Et problem vi dog mødte var at vi havde gearet hjulene i et forsøg på at sænke robottens tyngdepunkt. Denne gearing havde en del slør og lagt sammen med motorens egen slør oplevede vi problemer med justering at P,I og D værdier. For at fjerne gearingen måtte vi også bruge mindre hjul for at undgå at skulle lave ændringer på bommen og placering af lysesensorer. Begge dele hjalp meget på robottens evne til at følge linjen.



Koden kan findes her

Konklusion
Vi syntes selv at idéen i robotten grundlæggende er god; Bommen virkede umiddelbart efter hensigten og de to lys-sensorer var nok til at kunne følge linjen tilfredsstillende. Med mere tid på programmeringsdelen ville det bestemt være muligt at opnå en tilfredsstillende gennemkørsel.
Dette projekt har nok mest af alt lært os noget omkring KISS ift. LEGO technic og NXT sensorere. Jo færre bevægelige dele jo bedre.

Embedded Systems Lesson 7

Date: 3/4 2014
Duration of activity: 3 timer
Group members participating:
Henrik Jørgensen
Michael Schiønning
William Thorsen

Mål

Målet med denne øvelsesgang er at gennemføre øvelserne til denne uges ugeseddel Agents & behaviour selection in agents, subsumption architecture¹

Plan

Planen for denne uge er:

• Ombygge robotten til øvelserne
• Udarbejde ugens øvelser 
• Påbegynde blogindlæg

Resultat af øvelser

Opgave 1

Efter at have bygget den nye robot med en ultrasonisk sensor, en lyssensor samt en bumper, via to touch sensorer, startede vi den udleverede AvoidFigure9_3.java² klasse. Måden den virker på er, at robotten hele tiden måler afstanden fra sensoren til et objekt, samtidigt med at den fortsat kører fremad.

Når sensoren opfanger en afstand, der er mindre end et givent threshold stopper robotten og den checker hvilken en af sine 2 målinger der er den største. Vi er ikke helt 100% sikker på hvad der menes her, men vi regner med at den højre afstandsværdi måles ud fra sensorens højre øje og vice versa for venstre.

Når de to værdier sammenlignes drejer robotten i den retning hvis "øje" har den største værdi og derved drejer vi uden om den givne forhindring. Vi rendte dog ind i et tilfælde, hvor vores robot ikke kunne finde ud af at rette op når den bevægede sig imod en mur. Hvis vinklen mellem muren og robotten er tilpas spids vil de målinger sensoren foretage sig ikke nå under klassens threshold og vi ender med nærmest at glide langs væggen uden at rette op.

Enten kunne man pille lidt ved klassens threshold og hæve det for at undgå situationer som dette. Det der nok er mest sandsynligt, men som vi ikke lige fik dobbeltchecket, er at da vi byggede robotten satte vi alle sensorene på. Altså betyder det at den ultrasoniske sensor ikke er placeret lige midt for robotten, men nærmere 1/4 af robottens bredde (jvf evt billedet fra opgavesiden¹). Derved kan det muligvis gøre at hvis vi har en spids vinkel mellem robot og en væg på højre side af robotten kan målingerne på det højre øje være over vores threshold som en centreret sensor måske ville have reageret på.


I den anden del af opgaven var det blot et spørgsmål om at indsætte et ekstra check for at se om alle tre afstande (leftDistance, frontDistance og  rightDistance) er mindre end vores stopThreshold. Når det er tilfældet giver vi først lidt power til begge hjul så den bakker og derefter kun power til det ene af hjulene så vi kan vende.

Koden kan findes her³

Opgave 2

Programmet RobotFigure9_9.java⁴ implementerer nu yderligere to behaviours: nemlig Follow og Cruise samt en arbritarian mechanism. Efter at have downloadet programmet og overførte det, startede vi robotten. Fordi vi i første forsøg var ude i det lyse fællesrum var der ikke rigtigt en lyskilde for Follow behaviouren at skulle specifikt følge. I stedet for får Avoid prioritet og checker hvorvidt vi er ved at støde ind i noget. Er det ikke tilfældet får Follow nu prioriteten og checker om der er en lyskilde at følge. Ellers bevæger vi os blot fremad.

Slår vi både Follow og Avoid fra har vi blot en robot der kan kører fremad og intet andet. Aktiverer vi nu  Follow vil robotten aktivt søge imod en stærkere lyskilde, men skulle vi kolliderer med en mur har vi ingen mulighed for at rette op, da det er Avoids ansvar.

Opgave 3

Escape-funktionen⁵ bliver opbygget på samme måde som det udgivne eksempel i  Mobile Robots, Inspiration to Implementation,  samt de allerede opgivne Follow.java og Avoid.java
Efter et par justeringer virkede robotten efter hensigten og bumperen fungere nu og får prioritet når den bliver trykket uanset hvad der kommer ind af lys- eller længdesensoren⁶



Opgave 4

Vi nåede ikke at påmontere den tredje motor til lyssensoren.

Opgave 5

Arbiter og SharedCar virker grundlæggende på samme måde som foreslået i Mobile Robots, Inspiration to Implementation s. 306 ⁷. I stedet for en hardcoded liste indsættes processer i et array, udfaldet af konflikter afgøres ved en prioritet ud fra indexeringen af dette array; Jo hørere indeks jo højere prioritet.

I Martin⁸ håndteres prioritetskonflikter mellem processer (flere med samme prioritet) ved først at finde højeste prioritet og så vælge den først fundne process med denne prioritet.

Konklusion

Denne gang har vi lært omkring brugen af forskellige behaviours og måden man kan væve dem sammen på via en arbritarian mechanism. Nemlig at man vægter hvilken opførsel der er vigtigst og derved ændrer robotten sin strategi Samtidig skal man dog, igen, være opmærksom på at specilt den soniske- og lyssensor kan være lidt tunge at danse med og måske ikke altid giver en de allerskarpeste målinger.

---

1 http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson7.dir/Lesson.html^↩
2 ^{http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson7.dir/Programs/AvoidFigure9_3.java↩}
3 ^{http://codetidy.com/8726/↩}
4 ^{http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson7.dir/Programs/RobotFigure9_9.java↩}
5 ^{http://codetidy.com/8728/↩}
6 ^{http://codetidy.com/8727/↩}
7 ^{http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson7.dir/11128_Mobile_Robots_Inspiration_to_Implementation-Flynn_and_Jones.pdf↩}
8 Fred Martin, [4, page 214-218]^↩

Embedded Systems Lesson 6

Date: 13/3 2014
Duration of activity: 3 timer
Group members participating:
Henrik Jørgensen
Michael Schiønning
William Thorsen

Mål

Målet med denne øvelsesgang er at gennemføre øvelserne til denne uges ugeseddel Embodied Agents¹

Plan

Planen for denne uge er:

• Bygge den NXT Braitenberg robotten udfra beskrivelsen i ugeseddelen.
• Gennemgå ugens øvelser.

Resultat af øvelser 

Vi lagde ud med at bygge basis køretøjet udfra beskrivelsen og de to .lxf filer.

Vehicle 1

Ved brug af en lyssensor skulle vi implementere opførslen af det mest simple Braitenberg køretøj (Vehicle 1). Her forbindes en sensor "direkte" til motoren og genererer et signal proportionelt med sensorens input. Dvs. at jo stærkere lys sensoren opfanger, jo hurtigere kører motoren. For at opnå bedst mulig opløsning valgte vi at normalisere lydsensorens rå værdier til et motor interval. Da SoundSensor klassen ikke direkte understøtter rå værdier måtte vi tilgå disse direkte på SensorPort klassen.

SensorPort.S1.readRawValue();

Før dette virkede som forventet måtte porten dog klargøres for rå værdier:

// Manually setup sensorport for raw sound readings.
SensorPort.S1.setTypeAndMode(SensorConstants.TYPE_LIGHT_ACTIVE, SensorConstants.MODE_RAW);

Først normaliserede vi til intervallet [0; 100] hvor vi som forventet for exitatory forbindelsen imellem sensor og motor observerede at køretøjet, når det så lys, bevægede sig fremad i en hastighed proportionel med lysstyrken. Omvendt gik det da vi ændrede forbindelsen til inhibitory, hvor hastigheden var omvendt proportionel med lysstyrken. Da kørte bilen med fuld styrke i mørke indtil den så lys.

Den dansende robot forsøgte vi at fremmane ved at normalisere fra det større rå interval [0; 1023] og ned til Car.forward() metodens interval [-100; 100] således

public int normalizeToRange(int light) {
    int output = 200 -((light - MAX_LIGHT) * 200) / (MIN_LIGHT - MAX_LIGHT);
 
    if(output > 100) output = 100;
    else if(output < -100) output = -100;
    return output;
}

MIN_LIGHT og MAX_LIGHT representerer minimum og maximum værdierne for de lysværdier vi forventer at få fra lyssensoren. Disse afhænger af sensoren og de lysforhold der er tilstede hvor denne arbejder.

At sætte musik til bilen vil få den til at danse, muligvis pga af de forskellige temposkift I sangen (NB: video er gået tabt I produktion )

Kode her²

Vehicle 2a og 2b

Vi monterede endnu en lyssensor foran, vinklet til hver sin side med 45 grader og forsøgte os med begge konfigurationer (2a og 2b). Styringen implementerede vi udfra Vehicle 1 og

I konfiguration 2a i exitatory tilstand observerede vi at robotten drejede væk fra lyset. I inhibitory tilstand søgte robotten imod lyset.

I konfiguration 2b observerede vi det omvendte af 2a; I exitatory tilstand drejede robotten imod lyset, jo kraftigere jo hurtigere. I inhibitory ville den ikke "se ind i lyset", den drejede væk.




main loop ( aner ikke om dette skal med? )

while (true) {
    int s4 = SensorPort.S1.readRawValue();
    int s1 = SensorPort.S4.readRawValue();

    // Update min/max light values
    if(s1 < MAX_LIGHT) MAX_LIGHT = s1;
    if(s4 < MAX_LIGHT) MAX_LIGHT = s4;
    if(s1 > MIN_LIGHT) MIN_LIGHT = s1;
    if(s4 > MIN_LIGHT) MIN_LIGHT = s4;

    average_s1 = alpha * s1 +(1-alpha) * average_s1;
    average_s4 = alpha * s4 +(1-alpha) * average_s4;

    LCD.drawString("Raw: " + s1 + ":" + s4, 0, 0);

    int s4n = s4 > average_s4 ? normalizeToRange(s4) : 0;
    int s1n = s1 > average_s1 ? normalizeToRange(s1) : 0;

    LCD.drawString("Norm: " + s1n +":" + s4n, 0, 1);

    Car.forward(s4n, s1n);
}

Opdatering af MIN_LIGHT og MAX_LIGHT over tid udførte vi i main loop
Vi observerede ingen udtalt ændring i robottens opførsel ved automatisk at opdatere værdierne af set MIN_LIGHT og MAX_LIGHT. 

Koden kan findes i fodnote 2. 

Vehicle 3

Denne nåede vi ikke at eksperimentere med.

Konklusion

I dennne uge har vi, med udgangspunkt i Braintenberg bygget to robotter med dertilhørende program på baggrund af Tom Deans noter. Lydsensoren blev brugt til vehicle 1, som havde en extiatory og en inhibitory metode. Dette samme var tilfælde for lyssensoren. Altså har vi en robot, der bevæger sig hurtigere desto højere en lyd den kan opfange fra omgivelserne.

---

1 http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson6.dir/Lesson.html^↩
2 https://docs.google.com/folderview?id=0B22Duz_kNMvWUk9ZS2NzYzRmZ2M&usp=docslist_api# ^↩