Øvelsesgang 9

Dato:
19-11-2009

Antal timer brugt:
6 timer

Deltagende personer:
Kim Munk Petersen, Andreas Koefoed-Hansen og Tim Rasmussen

Denne uges opgaver:

Denne uges opgave går ud på at se hvordan man kan få robotten til at køre til forskellige positioner, enten via en TachoPilot eller via CompassPilot. Den første opgave gik ud på at observere hvordan man kunne bruge TachoPilot sammen med SimpleNavigator til at finde frem til forskellige koordinater og til slut vende tilbage til udgangspunktet. Robotten er derfor nødt til at vide hvor den er hele tiden. Anden opgave går ud på at få robotten til finde frem til nogle koordinater som i opgave 1, men her skal robotten også kunne undgå evt. forhindringer på vejen. Den sidste opgave går ud på at anvende et kompas til at finde frem til de forskellige koordinater og se om robotten kører mere præcis vha. et kompas frem for ved brugen af en TachoPilot.

Vi har løst opgaverne i følgende rækkefølge:

1. Navigation
2. Kompas navigation
3. Navigation, hvor objekter undgås
   

Fysiske overvejelser

Robotten anvendt til denne uges opgaver er bygget ud fra beskrivelsen i Brian Bagnall's kapitel 12. Placeringen af kompasset har været til nøje overvejelser, eftersom den skal væres placeret minimum 10 - 15 cm fra NXT'en og motorrene. Vi har derfor først placeret kompasset i et tårn over selve NXT'en, men da dette tårn blev ustabilt, valgte vi at placere kompasset med den nødvendige afstand foran robotten.

Vi har målt følgende afstande:

• Afstand mellem hjulene er 17.8 cm
• Diameteren på hjulene er 56 mm
• Afstand fra kompas til NXT midt = 11.5 cm
• Afstand fra kompas til motor er 13 cm

Navigation

Vi brugte Brian Bagnalls kode og ændrede argumenterne der blev givet til TachoPilot constructoren til at passe med vores robot. Vi udførte først små tests hvor vi fik robotten til at køre 20 cm og prøvede at justere argumenterne efter dette. Da vi havde justeret disse, udførte vi tests på hele ruten og fik efter 3 forsøg en ret præsis gennemkørsel af ruten.

Vi brugte Lego klodser til at markere den tilbagelagte rute. Ruten blev mere kørt og mere korrekt i takt med at vi ændrede afstanden mellem hjulene. Den målte værdi var 17.8, men vi fik først en rigtig rute da vi ændrede til 18.4. Grunden til dette, kan skyldes at afstanden øges når der kommer belastning på hjulene, men dette giver ikke 6 mm, de sidste mm kan findes i unøjagtigheden i motor hastigheder.

Med en hjul diameter på 56mm kørte robotten meget præcist. Dvs. at når vi bad den om at køre 200mm så kørte den også næsten de 200mm. I vores tilfælde bad vi den køre 200cm, og den kørte godt 197cm. Da vi ændrede hjulstørrelsen til 55mm kørte den godt 199.7cm.

Kørelse 1: ca. 50 fra udgangspunkt (afstand mellem hjul 17.5)
Kørelse 2: ca. 30 fra udgangspunkt (afstand mellem hjul 17.8, her fandt vi ud af at vores måling var forkert)
Kørelse 3: ca. 7 fra udgangspunkt (afstand mellem hjul 18.4, her prøvede vi os frem med afstanden for at få den til at køre tilbage til udgangspunktet)





Navigation while avoiding objects

I forsøg på at løse denne opgave brugte vi to opførsler: en til at styre robotten hen til bestemte koordinater og en til at undvige objekter på robottens vej. Som tidligere i lignende opgaver, har den undvigende opførsel højest prioritet. Vores program bygger på Ole Capranis arkitektur til behavior based systems hvor hver opførsel er en tråd der nedarver fra en klasse Behavior og implementerer sin funktionalitet i run-metoden. Behavior-klassen stiller nogle metoder der styrer robottens motorer til rådighed og sørger for at det kun er ikke-suppressed opførsler der har adgang hertil. Vi tilføjede nogle metoder til Behavior-klassen, bl.a. goTo(x,y), travel(distance) og rotate(angle) der så kalder videre på en underliggende SimpleNavigator der styrer robotten. Alle definerede opførsler deler således en navigator hvilket gør at robotten i teorien bør opdatere sin position og retning, uanset hvilken opførsel der styrer den. Opførslen AvoidFront træder i kraft når robotten er 20cm eller mindre fra et objekt foran den. Den får herefter robotten til at rotere 90 grader og køre 20cm ligeud for at komme uden om objektet. Den anden opførsel WaypointDrive er aktiv når AvoidFront ikke er aktiv. Den har et array af koordinater og holder hele tiden styr på hvilket koordinat-sæt den er på vej hen til. Hver gang opførslen aktiveres kalder den goTo til dette koordinat-sæt, og når den når derhen skifter den til næste koordinat-sæt og fortsætter således indtil den når enden af koordinat-array'et. 

Da vi testede robotten prøvede vi i første omgang at lade den køre banen fra før uden at lade noget komme i vejen for den, og den kørte til alle punkterne som i første opgave. Derefter testede vi robottens AvoidFront opførsel og konstaterede at den blev aktiveret på de rigtige tidspunkter, dvs. når robotten nærmede sig et objekt, og den forsøgte at dreje omkring objektet som den burde. De to opførsler opfyldte derfor hver især deres mål. Når vi kombinerede de to opførsler gik det dog galt. Robotten mistede sin stedfornemmelse så snart AvoidFront-opførslen blev aktiveret. Vi fik den til at udskrive på LCD-skærmen hvor den var på vej hen, og det viste sig at den kørte til det korrekte koordinat-sæt, men at dens retning og position altså var forkert. Det lykkedes os ikke at løse problemet, men antager at problemet skyldes SimpleNavigator, som antageligt også gav problemer i forrige opgave.

Vi har hørt at andre grupper har samme problem, og heller ikke har været i stand til at løse det. I begyndelsen troede vi at problemet skyldtes at det kun var metoden goTo der opdaterede robottens interne koordinatsystem, men efter at have lavet en test med metoderne goTo, travel og rotate i SimpleNavigator, viste denne antagelse sig at være forkert. Robotten er tilsyneladende i stand til at opdatere sin position ligegyldigt hvilken af SimpleNavigators metoder man kalder.

Får vi senere brug for at have flere samtidige opførsler der skal navigere robotten rundt, vil vi løbende skrive robottens koordinater til en fil som vi så kan plotte, evt. så vi kan skelne koordinater skrevet af den ene henholdsvis den anden opførsel. Herved burde vi kunne se hvor og hvornår problemet opstår.

Compas Navigation

Til at løse denne opgave, monteres et kompas et sted på robotten. Første gange vi kørte vores program, kørte robotten rundt som om den havde været på Roskilde festival i en uge uden søvn og alt for store mængder alkohol. For at få den til at køre mere præcist vha. kompasset, valgt vi at kalibrere kompasset. Dette ændrede dog ikke meget på dens måde at køre på. Da vi placerede den på samme udgangspunkt som da vi gjorde brug af TachoPilot, kørte den meget forvildet rundt. For at finde ud af hvad grunden var til denne meget unøjagtige kørsel, lavede vi et simpelt program der blot skulle starte med at rotere robotten mod nord, hvorefter den skulle dreje 90 grader og vente 1 sekund inden den igen skulle dreje 90 grader. Heller ikke dette kunne den finde ud af. I stedet for at dreje samme vej rundt hele tiden, begyndte den pludselig at dreje den anden vej som om den var kommet forbi den ønskede position. Vi forsøgte derfor at teste om de værdier vi kunne hente ud fra CompassSensoren vha. getDegrees() var korrekte. Det viste sig at de var så korrekte som man kunne forvente.

Vi prøvede derfor forskellige ting, der kunne hjælpe os med at få robotten til at opfører sig efter hensigterne. Disse ting var følgende:

• Ændrer placeringen af kompasset, så i stedet for at være placeret i toppen af et meget ustabilt tårn, blev den nu placeret foran robotten. Dette gjorde at den sad mere fast på robotten og derfor ikke havde de sammen udsving.
  
  
• Ændre hastigheden af mortorerne, så vi var sikre på at grunden til den mærkelige opførelse ikke skyldtes at vi bevægede os forbi den ønskede position. Grunden til denne test, var at vi ikke vidste om SimpleNavigator på nogen måde håndtere fejltolerencer. Men selv ved meget lave motorhastigheder kørte robotten som tidligere.
  

På trods af de ændringer og målinger vi har lavet, er det ikke lykkes os at få robotten til at køre på en fornuftig måde når der bruges et kompas. Det er dog flere ændringer vi kunne have udført i håb om at disse kunne hjælpe med at få robotten til at opføre sig nogenlunde fornuftigt. Disse ændringer er:

• Vi kunne undgå at bruge SimpleNavigato og i stedet blot kalde rotate metode direkte på CompassPilot. Dette vil fjerne evt. fejl der kan opstå ved at bruge SimpleNavigator på en CompassPilot.
  
  
• Vi kunne også vælge at læse indputtet direkte fra CompassSensor og ud fra disse værdier selv styre motorerne. Herved vil vi fjerne 2 evt. fejlkilder.
  

Grunden til at vi kunne forestille os at disse ændringer vil have en god effekt skyldes at det virker som om SimpleNavigator ikke er så glad for at arbejde sammen med CompassPilot. Da vi gjorde brug af en TachoPilot, havde vi ingen problemer, så vi bygger ideen om at SimpleNavigatoren og CompassPiloten ikke arbejder godt sammen på baggrund af dette.