Monday, April 28, 2014

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.

Monday, April 21, 2014

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.




Monday, April 7, 2014

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 architecture1

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.java2 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 opgavesiden1). 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 her3

Opgave 2

Programmet RobotFigure9_9.java4 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-funktionen5 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ængdesensoren6



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 7. 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 Martin8 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
http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson7.dir/Programs/AvoidFigure9_3.java
http://codetidy.com/8726/
http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson7.dir/Programs/RobotFigure9_9.java
http://codetidy.com/8728/
http://codetidy.com/8727/
http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson7.dir/11128_Mobile_Robots_Inspiration_to_Implementation-Flynn_and_Jones.pdf
Fred Martin, [4, page 214-218]