Vi startede med at bygge lego robotten om, så lydsensoren blev monteret, derefter gik vi i gang med at teste programmerne på planen.
Det første program var et simpelt program til at udskrive værdien der blev aflæst fra sensoren på displayet. Underligt nok kunne vi ikke få dette program til at virke, men efter lidt flytten rundt både på polling intervallet og sensor portene fik vi det til at virke. Tilsyneladende virkede sensoren ikke i port 4, så da den var flyttet til port 1 var problemet løst.
Robotten forsøger at komme hen på en bestemt afstand af et objekt. Den afstand er sat til distanceThreshold i programmet. Robotten skal se et objekt før den begynder at bevæge sig hen imod det, dvs. hvis der ikke er nogen objekter inden for sensorens rækkevidde så holder robotten stille. Vi kunne ikke lige umiddelbart gennemskue forholdet mellem robottens afstand til objektet, og dens fart, så vi besluttede at lave et plot af funktionen.
Som det ses er det en lineær funktion, som vi umiddelbart ikke kunne få helt til at hænge sammen med robottens opførsel. Ved nærmere eftertanke kunne vi se at det skyldes at robotten først begynder at bevæge sig når der er et objekt foran sensoren, og dette objekt kommer tættere på når robotten kører. Desuden startede vi robotten ved at holde et objekt ind foran sensoren, og dette objekt holdt vi relativt tæt på sensoren, så opstarts hastigheden var også lav. Vi lavede en simpel test ved at holde robotten op foran en mur, og ændre afstanden. Der kunne vi se at sensoren kunne måle op til omkring 150, hvorefter værdien blev aflæst som 255 hvis robotten blev flyttet lidt længere væk. Vi prøvede at ændre på polling intervallet i den tro at lydsignalet måske ikke kunne nå at blive aflæst inden næste lydbølge blev sendt, men det gav samme resultat.
Hastigheden af robotten er den kontrollerede variable, og afstanden er den målte variable. Denne form for kontrol kaldes simple feedback control, og da vi kan se fra plottet at funktionen er linær kaldes det proportional kontrol.
Da vi kom til WallFollower delen fik vi implementeret WallFollower.java udfra Philippe Hurbain's (PH) NQC kode. Han brugte en anden sensor, så vi definerede andre thresholds værdier. Under testningen af programmet, kørte bilen konstant ind i væggen. Vi lod den bippe hver gang den læste 255 og det gjorde den mistænkeligt mange gange, hvor den ikke burde gøre det. Fx når sensoren pegede direkte ind i væggen. Vi prøvede forskellige threshold værdier for at få det til at virke, men forgæves. Endeligt spurgte vi en anden gruppe om vi måtte låne deres program, der virkede, og bilen kørte stadig ind i væggen. Vi prøvede deres sensor og så virkede vores program. Altså må sensoren være defekt. Fordi vi havde så meget bøvl med sensoren fik vi ikke programmet fin tunet, men det virkede.
Fred G. Martins (FGM)'s version af algoritmen er 3 state algoritmer, men PH's algoritme bruger flere værdier og altså flere tilstande. Selvom PH definerer 6 thresholds er der kun 5 der bliver brugt og det giver 6 forskellige states. 3 forskellige hastigheder for at dreje væk fra muren og to for at dreje ind imod muren og en til at køre ligeud.
Fordi vi havde problemer med vores sensor fik vi ikke afprøvet de forskellige grader af turns, men umiddelbart vil vi mene flere threshold værdier giver en mere jævn kørsel.
PH's algoritme har to hastigheder, en langsom til når den er tæt ved væggen og en hurtig til når den er langt væk fra væggen. Her vil det muligvis være en fordel at implementere en propertionel kontrol ligesom vi så i avoider koden.
Ingen kommentarer:
Send en kommentar