Week 10

Dato:

25-04-2013

Varighed:

Fælles lab: 3 timer

Blog: 3 timer

Deltagere:

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

Status

Vi har monteret en marker på vores LEGO-robot og eksperimenteret med NXT motorernes tacho-counter og navigationssystemet i leJOS.

Mål

Målet for denne laboratoriesession er at bruge NXT motorernes tacho-counter til at holde rede på positionen og retningen af LEGO-bilen med såkaldt differential drive, hvor to motorer bliver brugt uafhængigt af hinanden til at flytte og styre bilen, som vist på figur 1¹.

Plan

• Konstruere en LEGO-robot med en marker monteret, så den kan markere LEGO-bilens bevægelse.
• Udarbejdelse af opgaverne for "Week 10 - Navigation and Map Building".
• Udarbejdelse af blogindlæg for denne laboratoriesession².

Opgaver

Navigation

For at holde det simpelt valgte vi at udbygge vores LEGO-robot med muligheden for at holde en marker, som Maja Mataric³ beskriver. Til at holde markeren har vi fjernet sensoren forrest på LEGO-robotten og monteret to hjul, der kan holde fast om markeren.

For at kunne benytte koden sammen med vores SDK var vi nødsaget til at skifte klassen TachoNavigator til Navigator. Vi instantierede vores DifferentialPilot til Navigator med værdierne 5.5 cm for dæk-diameter og 17 cm for bredden af dækket.

Vores første kørsel resulterede i, at robotten kørte ud over kanten på tavlen, som vi havde robotten til at køre på. Derfor forkortede vi alle distancer i koden til en fjerdedel. Nedenstående video viser robotten på dens anden kørsel fra samme startpunkt.

Nedenunder ses slutresultatet af kørslen fra videoen.

Som det fremgår tydeligt, ligger de to streger ikke helt oven i hinanden. Dette kan skyldes unøjagtighed i, hvordan vi har placeret robotten imellem de to test kørsler. På billedet fremgår det, at forskellen imellem de to streger vokser, specielt når robotten roterer, som Brian Bagnall⁴ også pointerer mht. til hans Blightbot . For at teste denne påstand har vi opbygget en ny teststub i koden, hvor vi forsøger at rotere mest muligt og derefter sammenligne robottens endelige position.

               navigator.goTo(0, -1);

               navigator.goTo(0, 0);

               navigator.goTo(0, -1);

               navigator.goTo(0, 0);

               navigator.goTo(0, -1);

               navigator.goTo(0, 0);

               navigator.goTo(25f, 25f);

               Thread.sleep(12000);

Billedet viser to testkørsler med den nye teststub.

Den grønne marker er brugt til at lave referencepunkter for at placere robotten ens under hver testkørsel. Den blå og den røde marker ligger meget tæt på hinanden og afviger kun lidt. Afvigelsen vil dog være noget større på en større skala, men de forskellige tests viste at afvigelsen var meget ens, og derfor mener vi, at vores robot kunne klare opgaven ret præcist.

Navigation while avoiding objects

For at få LEGO-bilen til at undgå objekter foran den, kunne man montere en ultrasonic-sensor. Når man skal undgå objekter samtidig med at bruge Navigationen, kan man tjekke for objekter i en særskilt tråd. Det er ikke nødvendigt at starte en tråd til Navigationen, da den automatisk kører i en særskilt tråd. Tråden der bruges til at opdage objekter med kan stoppe Navigationen, når den ser et objekt og beregne en ny rute, som der skal navigeres efter.

Improved navigation

For at navigere korrekt beregnes der i Java Robotics Tutorials⁵ en fejl ud fra, hvor meget et hjul burde have kørt i forhold til, hvad det rent faktisk har kørt. Fejlen bruges til at udligne retningen ved at give mere styrke til motoren, der er bagud og mindre styrke til motoren som er foran. På denne måde vil robotten komme til at oscillere. Det er en proportional kontrol uden integral og derivate, så det vil være svært at mindske oscilleringen.

Thomas Hellstrom⁶ beskriver, hvorledes det er muligt at lave præcise svingninger. Dog kan formlen også bruges ift. at køre ligeud, da man så blot betragter afvigelsen fra ikke at have svinget. Eftersom denne model ikke bruger akkumulering af afvigelse til at korrigere for fejl, er den mere præcis. Når afvigelsen opstår, bliver der med det samme reguleret på hastigheden af hjulene. Dette betyder, at modellen faktisk forsøger at lave et estimat af hvilken kraft, der skal på motorerne for at lave et givet sving, og undervejs i svinget korrigerer hastigheden af hjulene, så svinget bliver korrekt. Altså, modellen benytter viden om, hvor man skal hen til at lave en vurdering af, hvordan der skal tilpasses, i stedet for at se på hvor vi er henne lige nu, ift. hvor vi burde være henne lige nu.

Vi har også taget et kig på hvordan Navigator og særligt TachoNavigator er implementeret i leJOS. Efter at have undersøgt det lidt nærmere kom vi frem til, at ArcAlgorithms⁷ bliver brugt til selve beregningen af en Path frem til en destination. Præcis hvad der sker i denne klasse er dog noget kaotisk, ikke mindst fordi der er talrige kode-kommentarer om ting, der enten ikke fungerer helt efter hensigten, ting der lige er blevet rettet, eller forslag til hvordan koden kan skrives om, så den kan læses af andre. Herunder er vores bud på hvad klassen gør:

Dette betyder, at når man vil fra punkt A til B, og vil forsøge at undgå en slingretur jf. den grønne linje, så benyttes en cirkel til at svinge ind på linjen ved punkt A. Derefter kørers der ligeud vha. en anden beregning, hvorefter en cirkel om punkt B forsøger at sikre retningen af bilen, når den rammer punkt B. Ift. hvordan disse paths rent faktisk laves, så ser det ud til, at der er eksperimenteret med kørsler indtil man har fundet 16 ”gode standard”-paths, som alle kan tilpasses bilens dimensioner og afstanden imellem A og B. Her kan det f.eks. nævnes at algoritmen specifikt ignorerer, om man gerne vil dreje til venstre eller højre, når den vælger en ”best path”, så vi må håbe, at de har valgt de 16 standard-paths på en meget snu måde. Da vi ikke kan få et ordentligt overblik over, hvad der rent faktisk sker i ArcAlgorithms, har vi haft svært ved at finde frem til, om vi kan forbedre navigatoren i leJOS vha. Java Robotics Tutorial eller Thomas Hellstroms noter.

Konklusion

Denne uge har vi eksperimenteret med at bruge NXT motorernes tacho-counter til at holde rede på positionen og retningen af LEGO-bilen med såkaldt differential drive. Vi har bygget vores LEGO-robot om, så den nu har en marker monteret, så vi kan følge bilens bevægelse. Vi har fået bilen til at flytte sig mellem forskellige positioner og set, at den er god til at måle distancer, men at den ikke roterer helt ens hver gang. Vi har desuden overvejet, hvordan man kan få LEGO-robotten til at undgå objekter samtidig med at bruge leJOS navigationssystemet. Desuden har vi kigget på de to artikler; Java Robotics Tutorial og Thomas Hellstrom, og vurderet at den model Thomas Hellstrom beskriver, er den mest præcise. Vi har også kigget på, hvordan leJOS i ArcAlgorithms opdaterer positionen og retningen, men vi har haft svært ved helt præcist at se, hvordan leJOS i ArcAlgorithms, har implementeret dette, så det har været vanskeligt for os at finde frem til, om vi kan bruge Thomas Hellstroms noter til at forbedre dette.

____________________________________________________________________________________________________________

1. http://legolab.cs.au.dk/DigitalControl.dir/NXT/pictures.dir/DiffCar.jpg
2. http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson9.dir/Lesson.html
3. Brian Bagnall, Maximum Lego NXTBuilding Robots with Java Brains, Chapter 12, Localization, p.297 - p.298.
4. Maja J Mataric, Integration of Representation Into Goal-Driven Behavior-Based Robots, in IEEE Transactions on Robotics and Automation, 8(3), Jun 1992, 304-312.
5. Java Robotics Tutorials, Enabling Your Robot to Keep Track of its Position.
6. Thomas Hellstrom, Foreward Kinematics for the Khepera Robot
7. https://sites.google.com/site/digikaison/ArcAlgorithms.java