Week 7

Dato:

14-03-2013

Varighed:

Fælles lab: 5 timer

Blog: 3 timer

Deltagere:

Steffen Høi
Nikolaj Mols Hansen
Martin Vang
Ulrik Sahl Lystbæk

Status

Vi har forsøgt at få LEGO-robotten til at balancere vha. farvesensoren og gyrosensoren med NXT Intelligent Brick placeret horisontalt, hvilket var det, vi manglede at lave fra sidste uge. Desuden har vi bygget Braintenberg køretøjer med udgangspunkt i "figur 1"¹ og programmeret dem inspireret af det, der stod beskrevet i de to noter af Tom Dean².

Mål

Målet for denne laboratoriesession er at lave de resterende opgaver fra Week 6 ("Self-balancing robot with color sensor" og "Self-balancing robots with gyro sensor")³ samt at lave opgaverne for "Week 7 - Embodied Agents" og derigennem få et indblik i hvordan man kan lave Braintenberg køretøjer vha. NXT. Desuden er målet også at oprette et blogindlæg for denne laboratoriesession.

Plan

• Løse opgaverne "Self-balancing robot with color sensor" og "Self-balancing robots with gyro sensor" fra "Week 6 - Communication and Embedded Systems"³.
• Løse opgaverne for "Week 7 - Embodied Agents"⁴.
• Udarbejdelse af blogindlæg for denne laboratoriesession.

Opgaver

Self-balancing robot with color sensor

Sidste uge udskiftede vi lyssensoren på vores LEGO-robot med en farvesensor og begyndte på at teste, om vi kunne få den til at balancere ved brug af farvesensoren. Efter at have testet videre på dette denne laboratoriesession, har vi erfaret at farvesensoren kan bruges lige så godt som lyssensoren. Den kan stadig balancere nogenlunde, men ikke særlig længe uden hjælp. Det er altså ikke lykkedes os at forbedre robottens evne til at balancere ved skiftet mellem disse to sensorer.

Self-balancing robot with gyro sensor

Før vi forsøgte med at bruge gyrosensoren til at få vores LEGO-robot til at balancere, afprøvede vi hvordan gyrosensoren virker⁵. Vi monterede den på toppen af vores robot så den pegede op ad, og startede med at prøve på at få gyrosensoren til at kalibrere, men vi kunne ikke få den til at kalibrere rigtigt. Problemerne vi fik med kalibreringen var fordi, vi forventede, at den skulle kalibreres til at have et udgangspunkt på 0, og man derefter kunne bruge den til at tage målinger på vinklen i forhold til udgangspunktet. Efter at have brugt en del tid på dette, besluttede vi os for at gå videre til denne uges opgaver. Vi fandt efterfølgende ud af at udgangspunktet ikke behøver at være 0, men at det skal bruges til at regne ændringen ud i forhold til målingen. Derudover kan gyrosensoren ikke give en værdi for, hvilken vinkel den befinder sig i i forhold til startpositionen, men den kan bruges til at finde accelerationen i en given retning.

Vehicle 1

Med udgangspunkt i Tom Deans noter om Braitenbergs køretøjer har vi lavet et program til en robot med 2 motorer og én lydsensor. Styrken, der tilføjes motorerne, er i denne opgave ens, hvilket vil sige at bilen enten kører lige frem eller bakker lige.
Vi startede med at mappe de rå værdier fra lydsensoren til en værdi mellem 0 til 100 og bruge det som styrke til motorerne. Derfor kunne den kun køre frem til at starte med, men efter at have ændret mapningen til at ligge mellem -100 til 100, brugte vi de negative værdier til at angive hastigheden, hvormed bilen skulle bakke.

Da vi startede på opgaven, havde vi placeret lydsensoren tæt på motorerne, men støjen fra motorerne påvirkede dens opførsel meget. Når den først begyndte at køre frem med høj hastighed, gjorde støjen fra motorerne at den fortsatte frem i samme tempo hele tiden. Derfor flyttede vi lydsensoren op på toppen, et godt stykke fra motorerne.
Den rå værdi som hentes fra lydsensoren kan ligge mellem 0 til 1023. Derfor startede vi med at bruge de værdier som min. og maks. til normaliseringen fra målingsværdi, til styrkeværdi til motoren. Med de værdier skulle der meget støj til at få bilen til at køre frem. Dette kunne som beskrevet af Braitenberg skyldes, at min og maks målingsværdierne ikke er realistiske i det miljø, vi tester vores robot. Derfor vil vi mens programmet kører løbende opdatere min. og maks. værdierne i forhold til de målinger der er taget. Dette gør vi ved at tjekke om hver måling er større end maks. eller mindre end min. Hvis den er større end maks. opdateres maks til målingens værdi. Hvis den er mindre end min. opdateres min. til målingens værdi. På den måde normaliseres sensor-målingerne ud fra det miljø robotten befinder sig i.

Den excitatoriske udgave bevægede sig aldrig tilbage med fuld styrke, da der hele tiden var lidt støj, f.eks. fra bilens motorer. Til gengæld kom den let til at bevæge sig hurtigt frem fordi, så snart en lydmåling lå over middel af min. og maks. værdierne, fik motorerne meget styrke frem. Den inhibitoriske udgave bevægede sig modsat af den excitatoriske. Programmet vi har skrevet til vehicle 1 kan ses i Vehicle1.java⁶.

Vehicle 2

Programmet vi har lavet til vehicle 2 ligner meget programmet fra vehicle 1. Den største forskel er at lydsensoren er skiftet ud med 2 lyssensorer, og de to motorer får styrke fra hver sin sensor. Derudover har vi tilføjet et array, som indeholder de seneste N målingsværdier⁷, og maks. og min. værdierne findes ud fra dette array. Vi lavede nogle forsøg med at tage robotten ud i skarpt sollys og bagefter tilbage i et mørkt rum. Der var en tydelig forbedring, når vi brugte arrayet til at begrænse maks og min værdierne. Hvis arrayet ikke blev brugt, havde robotten svært ved at tilpasse sig det nye miljø.

Den excitatoriske udgave kører væk fra lyset, hvilket kan ses i videoen her:

Den inhibitoriske kører mod lyset, hvilket kan ses i videoen her:

Vores program til vehicle 2 kan ses i Vehicle2.java⁸.

Vechicle 3

Til denne opgave monterede vi en ultrasonicsensor på bilen foruden de sensorer, som vi havde monteret på den i forrige opgave. Dvs. den nu har 2 lyssensorer, 1 ultrasonicsensor og 2 motorer. For at få målingerne fra ultrasonicsensoren med i bilens opførsel, normaliserede vi værdien fra dens målinger særskilt, mens vi stadig normaliserede værdien fra hver lyssensor, der bruges til hver sin motor. Den normaliserede værdi fra ultrasonicsensoren, bruger vi til at påvirke begge motorstyrker ens. Det betyder ikke at begge motorer får samme styrke, fordi de er også påvirket af hver sin lyssensor.
For at udregne en motorstyrke som er påvirket af både lyssensorerne og ultrasonicsensoren, har vi gjort følgende:

1. Lyssensormålingerne og ultrasonicsensormålingerne har vi særskilt normaliseret til at ligge mellem 0 og 100.
2. Den motorstyrke, der tilføjes, udregnes således: En normaliseret lyssensormålig - (100 - en normaliseret ultrasonicsensormåling).

Dette gør at bilen stadig enten følger lyset eller går væk fra lyset alt efter, om vi har brugt en excitatorisk eller inhibitorisk tilslutning mellem motorerne og lyssensorerne, samt at den holder afstand til genstande (så længe den kører lige frem). Resultatet kan ses i videoen nedenunder.

Koden til Vehicle 3 kan ses i Vehicle3.java⁹.

Konklusion

Denne uge har vi eksperimenteret videre med at få LEGO-robotten til at balancere vha. farvesensoren og gyrosensoren. Resultatet af dette var, at vi kunne få robotten til at balancere nogenlunde, men ikke særlig længe uden hjælp vha. farvesensoren, ligesom vi kunne det med lyssensoren fra sidste gang. Vi fik monteret gyrosensoren på robotten, men vi fik den aldrig robotten til at balancere ved at benytte denne. Dette skyldtes, at vi havde nogle problemer med at få den til at kalibrere til 0, som vi forventede, at den skulle, men vi erfarede senere at udgangspunktet ikke behøvede at være 0, og at vi i stedet for skulle have kigget på ændringen af en måling i forhold til udgangspunktet.
Vi har endvidere bygget Braintenberg køretøjer med udgangspunkt i figur 1 og programmeret dem inspireret af det, der stod beskrevet i de to noter af Tom Dean. Dette har vi gjort ved at bruge forskellige sensorer individuelt, men også ved at kombinere dem. Lydsensoren har vi brugt til at lave et køretøj, der bevæger sig enten hurtigere desto højere lyden fra omgivelserne er, eller modsat alt efter om forbindelserne er excitatoriske eller inhibatoriske. Desuden har vi brugt to lyssensorer til at styre, hver sin motor, hvor lyssensoren bestemmer, hvor meget power motoren skal have. Den excitatoriske udgave kørte væk fra lyset og den inhibatoriske kørte mod lyset. Til sidst monterede vi, foruden de to lyssensorer, ultrasonicsensoren på bilen, og implementerede en måde hvorpå, vi kunne kombinere de forskellige power-værdier til motorerne, som kom fra de forskellige sensorer.
____________________________________________________________________________________________________________

1. http://legolab.cs.au.dk/DigitalControl.dir/NXT/pictures.dir/vehicles.gif
2.
http://www.cs.brown.edu/people/tld/courses/cs148/02/introduction.html
http://www.cs.brown.edu/people/tld/courses/cs148/01/vehicles/vehicles.htm
3. https://services.brics.dk/java/courseadmin/DigitalControl/pages/Week+6+-+Communication+and+Embedded+Systems
4. https://services.brics.dk/java/courseadmin/DigitalControl/pages/Week+7+-+Embodied+Agents
5. http://lejos.sourceforge.net/nxt/nxj/api/lejos/nxt/addon/GyroSensor.html
6. https://sites.google.com/site/digikaison/Vehicle1.java
7. https://sites.google.com/site/digikaison/Measurement.java
8. https://sites.google.com/site/digikaison/Vehicle2.java
9. https://sites.google.com/site/digikaison/Vehicle3.java

Week 6

Dato:

07-03-2013

Varighed:

Fælles lab: 5 timer

Blog: 3 timer

Deltagere:

Steffen Høi
Nikolaj Mols Hansen
Martin Vang
Ulrik Sahl Lystbæk

Status

Vi har forsøgt at få LEGO-robotten til at balancere vha. lyssensoren og farvesensoren og sat NXT Intelligent Brick horisontalt på robotten. Desuden har vi fået lavet en brugergrænseflade, så vi kan ændre variablerne for PID kontrollen løbende under runtime. Vi mangler at eksperimentere videre med at få LEGO-robotten til at balancere med farvesensoren, samt at prøve at få LEGO-robotten til at balancere vha. gyro-sensoren.

Mål

Målet for denne øvelsesgang er at lave opgaverne for "Week 6 - Communication and Embedded Systems"¹ og derigennem eksperimentere med, hvordan man laver en selvbalancerende LEGO-robot inspireret af Steve Hassenplug's originale Legway kontrolleret af RCX'en². Desuden er målet også at oprette et blogindlæg for denne laboratoriesession.

Plan

• Løse opgaverne for "Week 6 - Communication and Embedded Systems"¹.
• Udarbejdelse af blogindlæg for "Week 6 - Communication and Embedded Systems"¹.

Opgaver

Self-balancing robot with light sensor

Til denne opgave har vi samlet robotten, så den er som LGO modellen, efter Phillippe Hurbains³ anvisninger. Vi har brugt programmet Segway.java⁴ fra Brian Bagnall for, at få robotten til at stå. Når programmet startes, skal robotten holdes i balancerende tilstand for, at der er et udgangspunkt til at udregne størrelsen af fejl på målinger og derefter rette op efter.
Vi har lavet få justeringer på robotten for at hjulene sidder mere stramt, men ellers er vores første forsøg med  den standard beskrevne LGO model og koden fra Brian Bagnall. Resultatet af dette kan ses i videoen her:

Som det kunne ses på videon, var den ikke god til at stå lige. For at forbedre den, startede vi med at flytte lyssensoren længere op, og bagefter justerede vi de forskellige variabler i programmet. Det blev aldrig helt godt, men det blev bedre end den første udgave. Vores modificerede udgave af Segway programmet af Brian Bagnall kan ses i Segway.java. Da vi har flyttet lyssensoren længere op, har vi bl.a. forsøgt at ændre på konstanten 1.8F, som ganges på error. En video af den samme robot med den modificerede variable kan ses i nedenstående video:

Choice of parameters on-the-fly

For at have lettere ved hurtigt at ændre på konstanterne, hovedsageligt til PID kontrollen, til vores balancerende robot, modificerede vi GUI'en og kommunikationen fra PCcarController.java⁵ og BTcontrolledCar.java⁶. Først afprøvede vi dog programmerne PCcarController.java og BTcontrolledCar.java. Til BTcontrolledCar.java lavede vi et LeJOS NXT Project i Eclipse, som også indeholdt Car.java⁷. Til PCcarController.java lavede vi et LeJOS PC Project i Eclipse. Dette virkede fint, og vi fortsatte ved at tilpasse det til Sejway.java⁸, så vi under runtime af programmet har mulighed for at justere de ønskede konstanter. På samme tidspunkt byggede vi også robotten lidt om, så NXT Intelligent Brick blev placeret horisontalt i stedet for vertikalt. Denne udgave af robot ses på nedenstående billede:

Til vores kombination af Sejway.java og kommunikationen fra PCcarController.java og BTcontrolledCar.java lavede vi to projekter. Et LeJOS PC Project med klassen SejwayController.java⁹ til at have en GUI, som kan bruges til at uploade nye værdier til det program, der kører på robotten. GUI'en er en kopi af den fra PCcarController.java, men lidt modificeret. Resultatet ses på nedenstående billede:

Det andet, et LeJOS NXT Project som indeholder Sejway.java, der er programmet fra den ovenstående opgave, men nu med kommunikation, SejwayCommunicationImpl.java¹⁰, som står for at læse værdier der sendes fra PC-applikationen samt SejwayValues.java¹¹, som indkapsler de variabler, der modtages fra PC-applikationen.

Der er ikke meget opfindsomhed i det kode, vi har lavet i forhold til de eksempler, vi har fået udleveret. Den største forskel er, at BTcontrolledCar.java venter på noget fra PC-applikationen og reagerer så på det, hvorimod vores Sejway.java hele tiden skal forsøge at balancere, mens den tjekker, om der er sendt data fra PC applikationen. Hvis der ikke er sendt noget, skal den vende tilbage til at balancere, og hvis der er sendt noget, skal den hente det og opdatere konstanterne til PID kontrollen og fortsætte med at balancere igen.

Vi bruger metoden available fra DataInputStream¹² til at tjekke om PC-applikationen har sendt noget data, der venter på at blive læst.

Når vi sender data fra PC-applikationen til NXT-applikationen, sender vi hver gang alle de variable, vi har valgt, som skal være mulige at justere fra PC-applikationen. Alternativt kunne vi have nøjedes med at sende dem, der var blevet opdateret, men så skulle vi til at sende data med, som angiver hvilke variable, der er sendt og tjekke på det. Derfor vurderede vi, at det både var lettere og hurtigere at sende dem alle med hver gang.
PC-applikationen gjorde det lettere med at prøve at få robotten til at balancere, men vi fik den aldrig helt til at balancere helt perfekt. Vi håber på, at vi på et tidspunkt får tid til at gå tilbage til en udgave af LineFollower.java med PID kontrol, så vi kan lave en PC-applikation til den.

Self-balancing robot with color sensor

Vi har udskiftet lyssensoren på den balancerende robot med en farvesensor og prøvet på programmet fra ovenstående opgave. Det virker umiddelbart på samme niveau som med lyssensoren, vi har brugt indtil nu. Dvs. robotten stadig kan balancere nogenlunde, men ikke særligt længe uden hjælp. Vi har ikke nået at teste meget med farvesensoren, så vi fortsætter herfra i næste uge.

Self-balancing robots with gyro sensor

Denne opgave mangler vi at lave, hvilket vi vil gøre i næste uge.

Konklusion

Denne uge har vi eksperimenteret med hvordan, man kan få LEGO-robotten til at balancere vha. NXT lyssensoren samt farvesensoren ved at have arbejdet med opgaverne omhandlende disse. Vi har  desuden prøvet med forskellige opstillinger, hvor vi bl.a. har ændret på afstanden mellem sensorerne og den flade, vi har forsøgt at få LEGO-robotten til at balancere på, samt placeret NXT Intelligent Brick både horisontalt og vertikalt. Desuden har vi også forsøgt at slukke lyset for at gøre lokalet så mørkt som muligt, hvilket vi så havde en lille effekt på robottens evne til at balancere vha. lyssensoren og farvesensoren. Vi har endvidere etableret en trådløs baseret forbindelse mellem PC og NXT, så vi via en grafisk brugergrænseflade, som vi også har udviklet i denne uge, kan ændre på konstanterne i PID kontrollen løbende under runtime. Dette vil uden tvivl blive en stor hjælp for os senere hen, da det gør processen med at prøve sig frem med at justere på værdierne en del nemmere. Gennem vores arbejde med denne uges opgaver, har vi fået robotten til at balancere nogenlunde, men ikke særlig længe uden hjælp. Dette vil vi arbejde videre med i næste uge, hvor vi vil lave videre på opgaven med at få robotten til at balancere via farvesensoren, samt lave opgaven omhandlende balance vha. gyro-sensoren.

______________________________________________________________________________________________________

1. http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/Lesson.html
2. http://www.teamhassenplug.org/robots/legway/
3. http://www.philohome.com/nxtway/nxtway.htm
4. http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/Sejway.java
5. http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/PCcarController.java
6. http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/BTcontrolledCar.java
7. http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/Car.java
8. http://dl.dropbox.com/u/995376/Sejway.java
9. http://dl.dropbox.com/u/995376/SejwayController.java
10. http://dl.dropbox.com/u/995376/CommunicationImpl.java
11. http://dl.dropbox.com/u/995376/SejwayValues.java
12. http://lejos.sourceforge.net/nxt/nxj/api/java/io/DataInputStream.html

Week 5

Dato:

28-02-2013

Varighed:

Fælles lab: 5 timer

Blog: 4 timer

Deltagere:

Steffen Høi
Nikolaj Mols Hansen
Martin Vang
Ulrik Sahl Lystbæk

Status

Vi har monteret NXT lyssensoren, som beskrevet i LEGO Mindstorm Education NXT Base Set 9797.

Mål

Målet for denne øvelsesgang er at lave opgaverne for "Week 5 - Sequential and reactive control strategies"¹ og derigennem lære hvordan NXT lyssensoren kan bruges til at få LEGO 9797 bilen til at følge en sort linje og stoppe for enden af linjen, når billen kører ind i "målzonen", der i dette tilfælde er et stykke grønt rektangulært papir for enden af linjen. Ideen er at vi skal bruge lyssensoren til at opfange tre forskellige farver. Desuden er målet også at oprette et blogindlæg for denne laboratoriesession.

Plan

• Montere NXT lyssensoren på LEGO 9797 bilen.
• Løse opgaverne for "Week 5 - Sequential and reactive control strategies"¹.
• Udarbejdelse af blogindlæg for "Week 5 - Sequential and reactive control strategies"¹.

Opgaver

Black White Detection

Vi har monteret NXT lyssensoren som beskrevet i LEGO Mindstorms Education NXT Base Set 9797 manualen s. 32 til 34.
Til at afprøve den udleverede klasse BlackWhiteSensor.java², brugte vi det udleverede program LineFollowerCal.java³. LineFollowerCal.java³ bruger calibrate metoden fra BlackWhiteSensor.java² til, at indstille standardværdier for hvid og sort. Metoden light fra BlackWhiteSensor.java² bruges til at få en måling fra sensoren, som BlackWhiteSensor.java² er konstrueret med. Når lyssensoren er kalibreret, fortsætter LineFollowerCal.java³ til et loop, hvor der udover at blive tilført kraft til motorerne bliver taget prøver med lyssensoren, og de prøver bliver udskrevet på LCD'et. Derfor kunne vi bruge programmet til også at teste forholdene mellem målinger for sort og hvid.
Selvom værdierne fra lyssensoren teoretisk ligger mellem 0 til 100, ligger de målinger, vi har registreret mellem 39-60. Den laveste værdi er for sort, og den højeste er for hvid.

Line Follower with Calibration

Programmet LineFollowerCal.java³ har vi brugt og beskrevet lidt i afsnittet "Black White Detection" ovenover. Derfor beskriver vi ikke hele programmet igen, men kun den del der ikke er beskrevet endnu. Den essentielle del som programmet gør, der ikke er beskrevet, er når motorerne tilføres kraft i loopet. Motorerne tilføres kraft på baggrund af om sensoren har taget en måling, som vurderes at være sort, fordi værdien er tættere på den kalibrerede sorte værdi end den hvide. Hvis den er sort føres der kraft til den venstre motor, således at bilen drejer til højre. Hvis ikke må målingen antages at være hvid, og programmet handler symmetrisk til den anden retning. Dvs. at den højre motor tilføres den samme kraft, som den venstre hvis det havde været en sort måling.
Resultatet er at bilen kan følge en linje mellem sort og hvid ved konstant at oscillere fra side til side.

ColorSensor with Calibration

I denne opgave har vi lavet en klasse, som vi har kaldt BWOURSENSOR.java⁴ i stedet for "ColorSensor.java", fordi vi synes, det var mere oplagt, da det er en lyssensor, vi anvender, og vi på den måde ikke kommer til at forveksle den med farvesensoren.

Som tidligere nævnt fik vi farveværdierne 39 og 60 for henholdsvis sort og hvid. Vi målte farveværdien fra det grønne kvadrat som der senere skal standses på til at være 47. I stedet for at kalibrere hver gang, vi skulle afprøve programmet, har vi hardcoded de tre værdier for farverne i BWOURSENSOR.java⁴.

I stedet for at have en grænseværdi mellem sort og hvid, har vi ændret det til, at der nu er to grænseværdier. Én mellem sort og grøn og én mellem grøn og hvid. Idéen bag udregningen er fuldstændig den samme, men udvidet til at grøn er et interval mellem sort og hvid, som vist nedenfor.

greenWhiteThreshold = (greenLightValue + whiteLightValue)/2; greenBlackThreshold = (greenLightValue + blackLightValue)/2 + 5;

For at vurdere om farven er sort, skal værdien af en måling være mindre end greenBlackThreshold og for at vurdere om den er hvid, skal den være større end greenWhiteThreshold. Til at finde ud af om farven er grøn, har vi tilføjet metoden green, som ses her:

int temp = ls.readValue(); return (temp >= greenBlackThreshold && temp <= greenWhiteThreshold);

Det eneste der sker er, at der afgøres, om værdien af målingen ligger indenfor det interval, som angiver, at den er grøn.

Line Follower that stops in a Goal Zone

Fra det ovenstående emne "ColorSensor with Calibration", har vi muligheden for at se om farven på en måling er grøn. Nu forsøger vi at stoppe på et grønt felt efter at have fulgt en sort-hvid linje. LineFollow2.java⁵ er vores modificerede udgave af den udleverede LineFollowerCal.java³. I LineFollow2.java⁵ anvender vi BWOURSENSOR.java⁴ til, at se når farven grøn aflæses.
Vores første idé var at stoppe, når én måling blev registreret til at være grøn, men når den kører mellem den sorte og hvide linje, vil den vurdere farven til at være grøn, når målingen ligger tilstrækkeligt meget på både sort og hvid. Til gengæld er det ikke lang tid det sker, fordi den oscillerer meget, og som følge deraf, vil der hurtigt komme enten en sort eller en hvid måling hurtigt efter. Derfor satte vi bilen til først at stoppe, hvis der havde været fem grønne målinger i træk. På den måde kørte bilen fint rundt, og stoppede på det grønne felt, hvilket man også kan se i nedenstående video.

PID Line Follower

PID controllers handler om at lave en blødere/mindre oscillation for vores linje-følgende robot. Vores tilgang var at implementere selve algoritmen for så at prøve os lidt frem. Efter lidt usystematisk forsøgen, mest for at se om vores algoritme gjorde som den burde, viste det sig dog, at vi havde forbedret hastigheden af gennemløbet med godt 7% power (vi har valgt udelukkende at se på, hvor stort power-output vi var i stand til at sætte på motorerne i gennemsnit, som måling for hvor "hurtigt" vi kom igennem banen).

Altså kan vi allerede, uden korrekt at "tune" vores algoritme komme frem til, at vi kan opnå en ganske betragtelig forbedring vha. PID. Hvor vi har valgt at lade vores kode være som den er, synes vi dog, at det er interessant at se på, hvordan vi kunne gribe opgaven an, hvis vi havde brug for at opnå en endnu større forbedring.

Billedet ovenfor beskriver en basal PID. Med den udleverede kode svinger power på motor A og B med +/- alt efter den samlede error. Dette betyder, at vi er nødt til at se på, hvor meget vores samlede error kan blive - en total error på over 100+% er uønsket, hvis vi gerne vil igennem banen.
I vores tilfælde gik vi efter at lade error kontrollere omkring 25% af vores totale power, og lade vores basis fremdrift være 75%. Til at starte med, fandt vi en skaleringsfaktor, der gjorde at vi kunne oscillere os nogenlunde igennem banen. Derefter satte vi den en smule ned, og introducerede i og d. Da det var den forholdsmæssige forskel på værdierne i artiklen, vi arbejdede ud fra, valgte vi at sætte i=1/100*p og d=1/10*p. Dette gav os den ønskede forbedring, dog med den bemærkning at vi nulstiller i hver gang, vi ser en sort streg. En systematisk fremgangsmåde, der sikkert giver et godt resultat, vil være at halvere p. Derefter sættes i lidt op (oprindeligt sat til 0) og d tilpasses for at lave en dæmpende effekt.

Vores kode kan ses i LineFollow3.java⁶. Nedenstående video viser, hvordan bilen fulgte den sorte linje efter at programmet blev uploadet til den.

Color Sensor

I denne opgave har vi lavet programmet LineFollow4.java⁷, som er en modificeret udgave af den udleverede LineFollowerCal.java³. Som den første strategi for at løse opgaven, valgte vi at trække alle tre farver. Vi beregnede gennemsnittet af de tre farver og delte den med 2.55, som er en hundrededel af maksimumsskalaen for en RGB farve. Vores intention med den beregning var, at vi nu havde et gennemsnit af nuancen inden for alle tre farveskalaer, og vi ville give en mere præcis værdi til den samme algoritme, som vi brugte i forrige opgave i forbindelsen med sort/hvid-sensoren. De første test viste sig hurtigt, at det ikke var tilfældet, og efter en række test opdagede vi, at det skyldtes hastigheden på farvesensoren. Tiden det tog for farvesensoren at tage alle tre målinger betød, at robotten havde bevæget sig en betydelig del imellem hver måling, og derfor blev det meget upræcist.

Ud fra de første resultater kom vi til den konklusion, at vi enten skulle ændre måden robotten bevægede sig på, og derved få den til at bevæge sig langsommere og mere forsigtigt fremad, eller også skulle vi forbedre timingen på sensoren. Vi fandt ud af, at sensoren var meget hurtig til at foretage målinger inden for en farveskala, hvilket betød at vi ligesom ved sort/hvid-sensoren kunne foretage målinger inden for kun en af skalaerne og navigere på samme måde.

Vi diskuterede evt. fremtidige forbedringer, og den mest åbenlyse var at undersøge, hvilken af de tre farver, der giver det bedste resultat. En mere kompleks forbedring kunne være at benytte den bedste farve til at navigere med og lokalisere hvilke områder, der er problematiske for denne farve. Ved målinger der ligger inden for det problematiske område, vil man så stoppe robotten og undersøge området nærmere med de to andre farver for at danne en mere præcis måling.

Konklusion

Denne uge har vi monteret lyssensoren på LEGO 9797 bilen og fået indblik i hvordan denne fungerer ved at lave ugens opgaver. Dette har vi blandt andet gjort ved at foretage målinger med BlackWhiteSensor og teste forholdene mellem sort og hvid. Ved at bruge programmet BlackWhiteSensor.java² har vi set, hvordan vi kan kalibrere lyssensoren og derved indstille standardværdier for sort og hvid og via programmet registrere lysværdierne med lyssensoren. Ud fra de registrerede målinger har vi, via programmet, kunnet påvirke de to motorer alt efter, om det var sort eller hvid, der blev registreret. På den måde har vi kunnet få vores robot til at følge den sorte linje ved konstant at oscilere fra side til side. Endvidere har vi fået lyssensoren til at kunne registrere tre farver; sort, hvid og grøn ved at lave grænseværdier i programmet BWOURSENSOR.java⁴ ud fra de lysværdier, vi registrerede for de forskellige farver. Dette har vi kunne bruge til få robotten til at stoppe ved et mål i form af et grønt rektangulært område. Vi har derigennem set, hvilke udfordringer, der kan kan være med at registrere en farve, hvis lysværdi ligger mellem sort og hvid samt kommet frem til en løsning på dette. Derudover har vi erfaret, hvordan vi med en PID controller kan få robotten til at oscilere mindre, samt at det kan være en udfordring, at finde ud af præcist, hvilke variabler man skal ændre på, og hvor meget man skal ændre på disse for at få det bedste resultat. Til slut har vi stiftet bekendtskab med NXT farvesensoren, hvor vi har erfaret at det er nødvendigt at tage højde for hastigheden på farvesensoren, når man skal tage målinger med denne. Det kunne enten være ved at få robotten til at bevæge sig langsommere, forbedre timingen på sensoren eller foretage målinger inden for kun én farveskala.
____________________________________________________________________________________________________________

1. https://services.brics.dk/java/courseadmin/DigitalControl/pages/Week+5+-+Sequential+and+reactive+control+strategies
2. http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson4.dir/BlackWhiteSensor.java
3. http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson4.dir/LineFollowerCal.java
4. https://sites.google.com/site/digikaison/BWOURSENSOR.java
5. https://sites.google.com/site/digikaison/LineFollow2.java
6. https://sites.google.com/site/digikaison/LineFollow3.java
7. https://sites.google.com/site/digikaison/LineFollow4.java

Week 4

Dato:

21-02-2013

Varighed:

Fælles lab: 5 timer

Blog: 3 timer

Deltagere:

Steffen Høi
Nikolaj Mols Hansen
Martin Vang
Ulrik Sahl Lystbæk

Status

Vi har monteret lydsensoren, som beskrevet i LEGO Mindstorm Education NXT Base Set 9797.

Mål

Målet for denne øvelsesgang er at lave opgaverne for "Week 4 - Acting and actuators"¹ og derigennem forstå hvordan NXT lydsensoren kan bruges til at lave LEGO 9797 bilen om til en lydkontrolleret bil. Desuden er målet også at oprette et blogindlæg for denne laboratoriesession.

Plan

• Montere sensoren på LEGO 9797 bilen.
• Løse opgaverne for "Week 4 - Acting and actuators"¹.
• Udarbejdelse af blogindlæg for "Week 4 - Acting and actuators"¹.

Opgaver

Opgave 1

I denne opgave skulle vi montere sensoren på LEGO 9797 bilen som beskrevet i LEGO Mindstorms Education NXT Base Set 9797 manualen s. 24-26. Vi har programmeret, kompileret og downloadet et simpelt Java-program¹ til at teste lydsensoren. Nedenstående tabel viser de resultater, vi har fået ved at placere robotten på nogle faste positioner og prøve med lyden af et klap² samt en fløjtelyd³ i forskellige afstande. Vi har afspillet de to lydklip fra en computer i stedet for selv at klappe og fløjte for, at få en så konsistent lyd som muligt. Resultaterne er vist i følgende tabel:

Lyd	30 cm	60 cm	90 cm	120 cm	150 cm
Klap	21	16	13	9	8
Fløjten	54	30	21	26	13

Ud fra målingerne vi har lavet er lydsensoren nogenlunde stabil idet lydniveauet falder stødt.

Vores opstilling så ud som følgende:

Opgave 2

I denne opgave har vi brugt dataloggeren DataLogger.java⁴ til at indsamle lyddata, hvilket vi har gjort via SoundSampling.java⁵. Vi har brugt den målte data fra forsøget med fløjtelyden til at lave nedenstående graf.

Opgave 3

I denne opgave skal vi bruge programmet SoundCtrCar.java⁶, der benytter sig af klassen Car.java⁷ til at bevæge bilen i forskellige retninger. Programmet med lydstyring får robotten til gentagne gange at vente på en høj lyd. Første gang den hører en høj lyd, kører den ligeud, anden gang drejer den til højre ved kun at give den venstre motor fart, tredje gang drejer den til venstre og sidste gang stopper den. Hvis der er trykket på escape-knappen når den er færdig med de fire skridt, stoppes programmet. Hvis der ikke er trykket på escape udføres det hele igen.
I metoden waitForLoudSound tages der konstant prøver med lydsensoren indtil en prøve ikke er mindre end treshold, som er sat til 90. Når en prøve er 90 eller større returnerer funktionen, hvilket i dette program semantisk betyder, at der har været en høj lyd.

Opgave 4

I denne opgave skal vi ændre i programmet SoundCtrCar.java⁸  og få det til at terminere som en effekt af at escape-knappen trykkes. Den eksisterende termineringsfunktion poller på knappen for at tjekke, om den er trykket. Hvis escape-knappen er nede, vil programmet forlade main-loopet og derved terminere. Denne måde at behandle termineringen på åbner for en række problemer. Første problem er at eksekveringen kan gå ind i et indre loop så punktet, hvor escape-knappen polle ikke nåes. Det andet problem er at hvis punktet først nåes efter at knappen er sluppet igen, så vil den returnere falsk, når der polles, om den er trykket ned.

For at få programmet til at terminere når escape-knappen trykkes, laver vi en instans af ButtonListener, der har metoderne buttonPressed og buttonReleased, som skal implementeres. Instansen af ButtonListener kan tilføjes til escape knappens opførsel events. Til dette bruges den statiske wrapper metode Button.ESCAPE.addButtonListener. Vi har valgt at ligge termineringslogikken i buttonReleased, hvilket betyder, at det udføres, når knappen slippes. For at få programmet til at terminere rydder vi først skærmen, stopper evt. bevægelse af bilen, hvorefter vi kalder System.exit(0) som får programmet til at terminere med exit code 0.

Opgave 5

I denne opgave skal vi få robotten til at opfange, hvis der klappes. For at  opfange et klap bruger vi igen lydsensoren til at analysere lyden den kan opfange. Kravene for et klap lyder på følgende:

          - En lyd der er under 50.

          - Indenfor de næste 25 milisekunder kommer der en lyd over 85.

          - Indenfor de næste 250 milisekunder kommer der igen en lyd under 50.

Den første måde vi løste problemet på var at benytte et indre loop for hver fase, så når første fase er opfyldt går den ind i et indre loop og venter det tilladte tid på, at denne fase bliver opfyldt og det samme gælder den sidste fase. Problemet med denne løsning er, at hvis programmet befinder sig i det f.eks. tredje indre loop pga. lyde, der næsten er et klap, så vil et evt. klap på det tidspunkt muligvis ikke registreres. For at løse det problem har vi valgt at sample lyden ind i en buffer for hvert 5. milisekund. Ved hver sampling går vi så baglæns i bufferen fra den sidste sampling og undersøger om kriterierne for et klap er opfyldt. Hvis et klap er opfyldt, tæller vi en tæller op på skærmen og clearer bufferen for at undgå, at samme klap registreres flere gange. SoundSampling.java⁹ viser, hvordan vi sampler lyden i en buffer, og hvordan vi løbende i funktionen isAClap analyserer bufferen for om et klap er hændt. Vi har brugt dataloggeren til at optage klapmønstret¹⁰

Opgave 6

I denne opgave har vi monteret to lydsensorer og prøvet at bruge læsningerne fra disse sensorer til altid at køre mod retningen med den højeste lyd. Til dette har vi implementeret programmet FunBot.java¹¹. Resultatet af en kørsel af dette program kan ses i nedenstående video.

Vi havde nogle udfordringer med at adskille lyden fra de to sensorer, hvilket vi prøvede på at løse med papir mellem og rundt omkring begge sensorer for at isolere lyden, men det kom aldrig til at virke helt efter hensigten. Desuden kan baggrundslyd og den måde hvorpå lydbølgerne blev udsendt i rummet også have spillet en rolle.

Konklusion

Denne uge har vi fået monteret lydsensoren på LEGO 9797 bilen og fået et indblik i, hvordan denne fungerer ved at lave ugens opgaver. Dette har vi bl.a. gjort ved at lave afstandsmålinger af en fløjte- og klappelyd og set, at lydsensoren fungerer nogenlunde stabilt. Endvidere har vi igen brugt dataloggeren til at indsamle og gemme lyddata, som vi har kunnet lave en graf over for at illustrere sammenhængen mellem afstanden og lyd. Vi har også erfaret hvordan robotten kan bevæge sig bestemte retninger i forbindelse med, at den hører en høj lyd. Desuden har vi stiftet bekendtskab med Java Threads, Listeners og Events og set hvordan disse virker specifikt for leJOS herunder ButtonListeneren. Dertil har vi også lært hvilke udfordringer, der er med at genkende lyde, og at man bliver nødt til at være opmærksomme på lyde, der næsten overlapper hinanden, samt hvad man kan gøre for at løse dette. Til sidst har vi erfaret, at der kan være nogle udfordringer med at bruge to lydsensorer til at styre bilen i retningen af en høj lyd.

____________________________________________________________________________________________________________

1. https://services.brics.dk/java/courseadmin/DigitalControl/pages/Week+4+-+Acting+and+Actuators
2. http://soundjax.com/clapping-1.html
3. http://soundjax.com/whistle-1.html
4. http://legolab.cs.au.dk/DigitalControl.dir/NXT/src/DataLogger.java
5. http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson3.dir/SoundSampling.java
6. http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson3.dir/SoundCtrCar.java
7. http://legolab.cs.au.dk/DigitalControl.dir/NXT/src/Car.java
8. https://sites.google.com/site/digikaison/SoundCtrCar.java
9. https://sites.google.com/site/digikaison/SoundSampling.java
10. https://sites.google.com/site/digikaison/Claps.txt
11. https://sites.google.com/site/digikaison/FunBot.java

Week 3

Week 3

Dato:

14-02-2013

Varighed:

Fælles lab: 5 timer
Blog: 4 timer

Deltagere:

Martin

Nikolaj

Steffen

Status

Vi har samlet LEGO 9797 og monteret UltraSonic sensoren, som beskrevet i LEGO Mindstorm Education NXT Base Set 9797. Desuden har vi fået leJOS til at virke på alle computerne i gruppen. Computeren med OS X virker dog ikke med tilslutning via Bluetooth.

Mål

Målet for denne øvelsesgang er at lave opgaverne for "Week 3 - Sensing and Sensors - Analog|Digital conversion"¹ og derigennem forstå hvordan sensorerne i Lego Mindstorms virker. Endvidere er det et mål at få leJOS installeret på de resterende maskiner, så alle gruppens computere kan kommunikere med robotten. Desuden skal der oprettes et blogindlæg med henblik på denne laboratoriesession, hvor vi skal huske på den feedback, vi fik fra forrige uge (Week 2).

Plan

• Afslutning af installation af leJOS.
• Løse opgaverne for "Week 3 - Sensing and Sensors - Analog|Digital conversion"¹ .
• Udarbejdelse af blogindlæg for "Week 3 - Sensing and Sensors - Analog|Digital conversion"¹ .

Afslutning af installation af leJOS

OS X

Efter at have fulgt tutorialen "Getting Started on OS X"² uden succes blev tutorialen, der beskriver, hvordan man installerer og kører leJOS via et plugin i Eclipse³ , fulgt. Installationen af pluginet var simpel, men da der skulle kompileres et Java-program for at teste, at der kunne uploades til robotten, opstod fejlen "This Java instance does not support a 32-bit JVM.". Efter at have søgt på internettet var det første bud på en løsning af dette problem at tjekke om alle filerne i bin mappen af leJOS havde fået tilføjet switchen -d32, der sikrer at Java-filerne bliver kompileret med 32-bit versionen af Java på OS X. Dette var dog implementeret som standard i den nyeste version af leJOS. Løsningen på problemet var derimod at hente 32-bit versionen af Eclipse i stedet for 64-bit versionen, der allerede var installeret på computeren i forbindelse nogle tidligere projekter. Java-programmet kunne derefter kompileres og uploades til robotten via USB. LeJOS kører derfor nu også fint på OS X. 

Da leJOS var kommet op at køre i Eclipse, og man kunne overføre programmerne til robotten via USB, blev det forsøgt at få det til at virke med den indbyggede Bluetooth i MacBooken. Det lykkedes at finde og forbinde til robotten via "Bluetooth" i systemindstillinger, men da det blev afprøvet i Eclispe kunne den her ikke finde robotten. Status er derfor at overførsel af programmer til robotten fungerer med USB, men ikke med Bluetooth på computeren, der kører OS X. 

Windows 8

Skiftet fra Ubuntu til Windows skete, da understøttelsen af leJOS til Linux er dårlig. Dette kombineret med at installationen ikke ligefrem var "mint" bidrog til, at det ikke længere kunne betale sig at bruge flere timer på de problemer, der var med at få leJOS til at virke i Linux. Følgende trin blev derfor foretaget:

1. Hent Windows 8 Pro N fra Dreamspark (bemærk at man kun kan hente fra Windows-maskiner).
2. Installer Windows 8. (ca. 30 min)
3. Installer Java.
4. Installer leJOS via guiden⁴. (ingen problemer/advarsler undervejs)
5. Installer leJOS igen - første gang virkede kommunikationen imellem robotten og Eclipse ikke.

Efter disse 5 trin virkede alt på nær det indbyggede bluetooth-kort. Dette kort tog længere tid at få til at virke end resten af installationen. Windows kunne nemlig ikke finde ud af at tænde for kortet uden driveren, som ikke kunne installeres uden at kortet var tændt. Dette blev dog løst på følgende måde:

1. Installer Window 7 driveren i kompatibilitet mode.
2. Aktiver kortet.
3. Installer Windows 8 driveren.

Status for denne maskine er nu, at leJOS er installeret, samt at det fungerer med overførsel via Bluetooth.

Opgaver

Til opgave 1 og 2  skulle vi placere robotten foran forskellige objekter i forskellige afstande og sammenligne afstanden med læsningerne fra sensoren. Vi har lavet afstandsmålinger på en skraldespand, affaldsposen i skraldespanden og en mur.

1. På billedet nedenunder ses skraldespanden og affaldsposen, som vi har foretaget afstandsmålinger på. Da vi lavede målingerne på skraldespanden, havde vi trukket posen helt væk, og da vi lavede målingerne på affaldsposen, havde vi trukket den ned, så den dækkede hele siden.

2. Muren vi har lavet afstandsmålinger på.

Opgave 1

Nedenstående skema viser målingerne med det udleverede program SonicSensorTest.java⁵ i version alfa_03. Dvs. med prøveinterval på 300 msek.

Genstand	45 cm.	75 cm.	105 cm.	135 cm.	165 cm.	195 cm.	225 cm.	Max
Skraldespand	45	75	106	138	255	255	255	150
Mur	45	76	107	138	168	199	232	255
Affaldspose	40	72	255	255	255	255	255	78

Ud fra de målinger vi har foretaget, er vores konklusion, at den maksimale afstand det er muligt at registrere en genstand fra med UltraSonic sensor er afhængig af den genstand, der skal registreres. Vi ved ikke helt præcist, hvorfor der er forskel på genstandene, men vi har overvejet, at det f.eks. kunne være at nogle genstande absorberer mere lyd end andre.

Opgave 2

I denne opgave har vi forsøgt at gøre miljøet så ens som muligt i forhold til, hvordan det var, da målingerne til opgave 1 blev foretaget, men denne gang med et prøveinterval på 10 msek. Nedenstående skema viser resultatet af målingerne.

Genstand	45 cm.	75 cm.	105 cm.	135 cm.	165 cm.	195 cm.	225 cm.	Max
Skraldespand 10 m/sek	45	76	107	140	169	198	228	255
Mur 10 m/sek	45	76	106	138	168	199	255	208
Affaldspose 10/msek	45	76	103	137	255	255	255	154

Det kortere prøveinterval i opgave 2 i forhold til opgave 1 gør, at det er muligt for UltraSonic sensoren, at registrere genstande, som den på større afstande har haft problemer med .

Opgave 3

Den måde hvorpå vi har fået de bedste resultater med UltraSonic sensoren er ved at sætte prøveintervallet til 0 og måle med en mur som genstand. Betingelsen for et godt resultat er i dette tilfælde at have størst mulig afstand fra UltraSonic sensor og genstanden, vi måler på.
Vi har lavet en måling på 253 cm, og det er muligvis et spørgsmål om, at placere sensoren præcist nok for at få en måling på 254 cm.

Angående spørgsmålet om hvorvidt lydens hastighed har betydning for vores sensors brugbarhed:
Da den maksimale måleafstand er 2,55m hen til og tilbage fra et objekt, får vi at tiden fra vores sensor påbegynder at måle på virkeligheden, til vi har et resultat, har en nedre grænse på:
(2,55 m * 2) / 340,29 m pr sek = 14.987 msek

Denne nedre begrænsning er dog ikke speciel. Vi vil altid være nødt til at se på hvor hurtigt en given sensor er i stand til at give os et måleresultat ift. hvor hurtigt, vi forventer at få et billede af virkeligheden i vores programmer.
Derudover vil en mere typisk brug af sensoren (50 cm) give et mærkbart bedre resultat:

(0,5m * 2) / 340,29 m pr sek = 2.9387 msek

Dette delay er mærkbart bedre og langt mere typisk i de programmer, vi har arbejdet med hidtil.

Opgave 4

For at lave denne opgave skulle vi først hente programmet Tracker.java⁶ og uploade det til robotten. Bilen som styres af programmet Tracker.java kører ind mod den nærmeste mur og står derefter på en distance af ca. 35 cm. fra muren og oscillerer frem og tilbage.

Fordi programmet foretager beregninger på målinger det har aflæst fra miljøet og derefter justerer sin adfærd i forhold til målingerne, er det en closed loop control.

Opgave 5

I denne opgave  skal vi prøve at få robotten til at oscilere ved at justere på konstanterne i controlleren.  Hvis vi indstiller trackeren med nedenstående værdier oscilerer robotten.

velocity = 50, pGain = 1.5, dGain = 0.5

Vi er dog ikke sikker på, hvilken konklusion vi skal drage ud fra dette.

Vi har taget udgangspunkt i pseudokoden fra ugesedlen, der beskriver en generisk PID Controller og brugt denne til at lave ændringer i Java-filen Tracker.java⁷. Resultatet blev at robotten kørte hen til væggen, oscilerede kort og derefter stoppede. Vi har ikke eksperimenteret med så mange variabler, da det er tidskrævende at gætte på hvilke konstanter, der skal ændres på for vores robot, men vi ved at en PID-controller kan bruges til at få en blød opbremsning i stedet for oscilering.

Opgave 6

For at lave denne opgave startede vi med at oversætte dette wallfollower-program⁸, til Java. Det lykkedes os dog ikke at oversætte programmet helt rigtigt, da det var nødvendigt for os at bytte om på højre og venstre motor for at den fulgte muren i stedet for at følge de steder, hvor der ikke er noget. Desuden har vi justeret konstanterne⁹. Den kom til sidst til at følge en mur, men det blev aldrig særlig godt. En video af dette kan ses herunder:

 

Vi har ikke nået at sammenligne NQC algoritmen med de forskellige forslag fra den udleverede tekst¹⁰. Det skyldes, at vi brugte lang tid på at få programmet oversat til Java. For at analysere programmet printede vi værdien af value variablen, hver gang der blev taget taget en ny prøve med UltraSonic sensoren, på LCD displayet. Værdien burde ligge mellem 0-255 da variablen blot bliver sat til distancen som sensoren returnerer, men i stedet fik den værdier mellem 0-2000. Når man skriver distancen fra sensoren direkte på displayet virker det fint. Vi brugte lang tid på at prøve at finde ud af hvorfor værdien fra value ikke var den samme, når vi skrev den på LCD displayet, som når værdien fra sensoren blev skrevet direkte til displayet i stedet for at blive gemt i en variabel. Vi fandt aldrig ud af hvorfor, og gik til sidst videre med at få programmet oversat i stedet for at analysere problemet.

Konklusion

Alle computerne kom til at fungere med leJOS, og vi fik udarbejdet en løsning til de fleste af ugens opgaver. Vi har lært hvordan Ultrasonic sensoren opdager objekter ved at udsende en kort høj-frekvens lyd og lytte for genlyde, samt hvordan vi kan bruge den til at måle afstand til objekter med vores robot. Undervejs i løsningen af opgaverne opdagede vi hvordan den fysiske virkelighed nogle gange registreres ukorrekt af en robots sensorer, hvilket kan have store konsekvenser, når man bruger close loop control - netop at man forsøger at korrigere for noget der ikke kræver korrektion. Typisk ved at køre ind i en væg.
Endvidere har vi forsøgt at tage feedbacken af vores blogindlæg fra sidste uge til os, idet vi har lagt ekstra vægt på at overveje adskillelsen af plan og mål samt tilføjet de punkter, som vi manglede (status, dato, varighed og deltagere). Vi har også prøvet på at være mere specifikke i henvisningerne til de guides og applikationer, som vi har brugt.

____________________________________________________________________________________________________________

1. https://services.brics.dk/java/courseadmin/DigitalControl/pages/Week+3+-+Sensing+and+Sensors+-+Analog|Digital+conversion
2. http://lejos.sourceforge.net/nxt/nxj/tutorial/Preliminaries/GettingStartedMac.htm
3. http://lejos.sourceforge.net/nxt/nxj/tutorial/Preliminaries/UsingEclipse.htm
4. http://lejos.sourceforge.net/nxt/nxj/tutorial/Preliminaries/GettingStartedWindows.htm
5. http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson2.dir/SonicSensorTest.java
6. http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson2.dir/Tracker.java
7. https://sites.google.com/site/digikaison/Tracker.java
8. http://www.philohome.com/wallfollower/wallfollower.nqc
9. https://sites.google.com/site/digikaison/WallFollower.java
10. Fred G. Martin, Robotic Explorations: A Hands-on Introduction to Engineering, Prentice Hall, 2001.