Morten, Lars og Thomas.
Goal:
Teste præcision af TachoNavigator alene, senere sammenligne med CompassNavigator.
Plan:
(1) Måle og estimere hjul-diameteren.
(2) Måle og estimere afstanden mellem hjulene.
(3) Teste præcisionen af robotten når TachoNavigator klassen anvendes.
(4) Gøre det muligt at nå et mål (tænkt som et punkt i et kartesisk koordinatsystem) selvom der korrigeres ved at at køre udenom evt. fundne forhindringer.
Activities:
Vi gennemførte i første omgang alle test ved brug af lego konstruktionen fra sidste uge, ie. den med bælter (a). Herefter lavede vi de samme test ved brug af en robot med hjul. Her brugte vi kontruktionen, beskrevet i Brian Bagnall's 'Maximum Lego NXTBuilding Robots with Java Brains' kapitel 12 (b).
(1a) Fordi vi havde brugt udveksling med forskellig størrelse tandhjul, til overførsel af kraft fra motor til bælter, var vi nødt til at eksperimentere med forskellige konstanter for 'hjul-diameteren'.
Vi indsatte en værdi for konstanten i konstruktøren til TachoNavigator, og udførte så et program, der fik robotten til, først at køre 60 enheder frem, derefter 60 enheder baglæns dette blev udført to gange. Hvorefter den aktuelle afstand til startstedet blev opmålt.
Det viste sig, at det ikke var muligt at finde en konstant således at robotten aldrig kørte længere end 60 cm og stadig endte ved nulpunktet efter 2 gange frem og tilbage.
Herefter udførte vi testen således at robotten kørte fremad en gang og stoppede. Dette gentog vi, indtil der blev fundet en aktuel konstant, der svarede til 60 cm bevægelse.
Eksperimenterne kan ses i skemaet herunder hjul-diameter-konstanst (hdk) vs. aktuel-kørsels-afstand-i-cm (cm) :
hjk | 6.3F | 5.6F | 5.1F | 4.8F |
cm | 44 | 53 | 57 | 60 |
(2a, 3a) Om pivot-konstanten, ie. afstanden mellem bælterne.
Vi målte afstanden mellem bælterne til 10 cm., indsatte værdien 10.0F som konstant og lod robotten køre i en timeglas-form.
Det viste sig dog at robotten ved denne værdi underkompenserede, den virtuelle afstand var for lille i forhold til den reelle afstand. Det resulterede i at robotten ikke drejede nok rundt når den roterede.
Konstanten eksperimenterede vi os frem til, ved at indsætte forskellige værdier for 'hjul-afstanden' i konstruktøren til TachoNavigator klassen og lade robotten køre ruten, beskrevet i Brian Bagnall's 'Maximum Lego NXTBuilding Robots with Java Brains' kapitel 12.
En skitse for kørslen kan ses herunder :
Den endelige værdi for hjulafstand konstanten blev sat til 12.35F (Aktivitetstid ca. 70 min).
(1b) I første omgang brugte vi det mål der står på siden af hjulet som konstant for hjul-diameteren.
Vi eksperimenterede igen med fremad / baglæns kørsel alene flere gange - Og forsøgte at ende op det samme sted. Vi oplevede igen den samme mangel på præcision ved gentagen kørsel frem og tilbage, og resignerede derfor igen til kun at køre frem en enkelt gang og så aflæse værdien. Konstanten blev til sidst bestemt til 5.6F enheder (Aktivitetstid ca. 35 min).
(2b, 3b) Igen eksperimenterede vi med rotation på stedet ( som beskrevet i 2a og 3a), og at køre en rute med samme slutpunkt som startpunkt, for at kunne approksimere konstanten.
Igennem observationer af flere udførsler på denne test, så det ud som om robotten havde en tendens til at dreje en smule mod venstre, altså når meningen var at den skulle køre ligeud. En værdi på 16.0F enheder for hjulafstanden gav en fornuftig opførsel (Aktivitetstid ca. 45 min).
(4) 4. punkt var at kode en opførsel der muliggør at komme fra punkt A til punkt B og samtidig køre uden om evt. forhindringer.
Vi lavede en wrapper klasse Avoider, der tager en TachoNavigator som argument i konstruktøren. Wrapperen har en public metode goTo der tager to argumenter, - et X og Y koordinat. Koordinaterne bruges argumenter i et kald til TachoNavigator objectets goTo metode der samtidig sættes til at returnere umiddelbart. Herefter spørges TachoNavigator (TN) om vi kører ved vedvarende kald til isMoving, under disse vedvarende kald, bruges en UltrasonicSensor til at måle afstanden foran robotten, - hvis afstanden bliver målt til at være under 20 cm, kalder vi stop på TN og udfører en undvigelses manøvre ved at bakke 20 og dreje 90 grader. Hvis der ikke er forhindringer foran nu, kører vi max 40 cm frem og genoptager søgning mod de oprindelige koordinater. Hvis der efter det forrige drej på 90 grader stadig er forhindringer ( måske lige foran, afstand nul ) bakker vi max 20 cm. Hvis der ikke er forhindringer foran nu, genoptager vi søgning mod de oprindelige koordinater (Aktivitetstid ca. 125 min).
Conclusion:
Tendensen for venstre søgning under ligeud kørsel kan stamme flere steder fra; lille strøm-niveau, en minimal men alligevel forskellig størrelse på de to hjul, fysisk fejl/forskel i de to motorer eller måske timings/syncroniserings fejl/problemer i selve softwaren. Spørgsmål som flere eksperimenter måske vil kunne give et svar på.
Der skal muligvis fastsættes nye konstanter for hjul-afstanden, idet vi måske er kommet til at indlemme den evt. error for venstre søgning i denne konstant, fordi vi testede med Bagnalls rute, der kun laver venstre rotationer og ikke både højre og venstre rotation. En test hvor vi anvender en spejling af den brugte rute, kunne svare på dette spørgsmål.
Vi mangler at eksperimentere med CompassNavigator klassen. Intuitionen siger at det må være en smule mere præcis idet det må være muligt at korigere for tendensen til venstre søgning, ved at sammenligne den målte retning med den beregnede.
Ingen kommentarer:
Send en kommentar