Varighed: 14 - 17
Medvirkende: Morten Rasmussen, Kenneth Sejdenfaden Bøgh, Morten Nikolaj Pløger.
Mål:
http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson8.dir/Lesson.html
Idag skal vi prøve at arbejde med en 9797 Lego bil, der udviser forskellige former for og prioritering af adfærd igennem concurrent tråde.
Til at starte med er det eneste vi skal, er at afprøve og observere et program vi får givet der har tre opførsler:
1: Spil en lyd hvert 10. sekund
2: Undgå objekter
3: Kør tilfældigt omkring
Herefter skal vi forsøge at tilføje en opførsel der gør at vores robot søger mod lys.
Plan:
Der er ikke så forfærdelig meget at sige til dette punkt, udover at vi følger planen i linket, altså:
Vi starter med at bygge standard robotten 9797 fra manualen, og overfører programmet SoundCar.java for at se hvordan den opfører sig.
Når det er klaret implementerer vi vores egen behavior der får robotten til at køre efter lys. Her overvejer vi at låne endnu en NXT lyssensor og følge idéen fra sidste lab, således at to lyssensorer kan bruges til at styre robotten i den rigtige retning.
Forløb:
LEGO car that exhibits several behavior
Vi har nu ombygget robotten så den ser ud som på billedet nedenfor:
Programmet SoundCar.java opfører sig som forventet, idet den som førsteprioritet afspiller en lyd hver 10. sekund, dernæst vil forsøge at undgå objekter, og som det sidste kører tilfældigt rundt.
Vi forsøgte også her at blive ved med at holde noget foran robotten, hvoraf det ses tydeligt, at den afspiller lyden selvom den er midt i at bakke tilbage for at undgå sammenstød.
Class Behaviour:
Hvis ikke trådene var markeret som daemon, ville de have mulighed for at leve videre selvom programmet termineres på NXT'en, hvilket er årsagen til at daemon er sat til true.
SuppressCount, der anvendes i Behaviour.java filen, er implementeret som en tællesemafor. Det vil sige, så længe SuppressCount er lig 0, er den tilhørende Behaviour supprressed og kan ikke tilgå robottens motore. Hver Behaviour kender sin underlæggende Behaviour. Så, når en Behaviour konstatere at den vil tilgå motoren, kalder den suppress(), der tæller alle underlæggende Behaviours' suppressCount én op. Bagefter, nær den er færdig, kaldes release(), der tæller alle underlæggende suppressCounts én ned, hvilket muligvis åbner muligheden for at en ny Behaviour ikke længere er suppressed og nu kan få lov at tage kontrollen.
Fred Martin's version baserer sig på et gennemløb af et array af processer, der har tilkendegivet at de ønsker at blive 'enabled', altså tage kontrol. Ud af dette array udvælges den process der har højest prioritet, som får lov at køre, hvorefter den kan afmelde sig listen af 'enabled' processor, og give plads til en ny opførsel.
Vi mener at de to algoritmer vil give den samme opførsel, men at Fred Martin's version kunne være smartere i det tilfælde hvor man ønsker størrer kontrol på runtime over hvilke mulige opførsler robotten kan have, idet det nemt kan arrangeres således at man kan påtvinge en process aldrig at blive enabled.
Spørgsmål fra forelæsning omkring boolean og Behaviour strategien:
Grunden til at boolean ikke fungerer her, er, at så snart der er mere end to lag med behaviour, så ønsker man at oprette en kø over hvem der skal have lov til at have kontrol over motorene. Hvorimod, hvis der blev brugt en boolean, ville man kunne risikere at flere underlæggende behaviors der venter på at opnå kontrol, vil kunne tilgå kontrollen på samme tid.
Add a behavoiur "Drive towards light":
Til denne opgave har vi anskaffet os 2 NXT lyssensorer og forsøgte at genanvende koden fra sidste uge, hvor vi tager input fra venstre sensor (hvor i det her tilfælde mørke er 0 og skarpt lys 100) og sender direkte til højre motor og vice versa.
Det første problem vi løb ind i, var at selvom vi har anskaffet os NXT sensorer, så var lysstyrken i lokalet vi befinder os i relativt lav, under 35. Så hvis vi placerede robotten i et mørkt lokale og forventede at den ville søge mod lyset i døren der fører ud af lokalet, så ville robotten stå stille og lave en høj hyletone, idet motorene ikke får strøm nok til at skubbe robotten fremad.
Herefter forsøgte vi, for at komme ud over det ovenstående problem, at lave vores egen mapping fra sensorenes målinger til den strøm vi giver motorene således at robotten skulle blive mere lysfølsom, og dermed kunne køre selvom det er mørk. Denne ændring gjorde at robotten stadig bevæger sig langsomt i mørke og hurtigt når det er lyst, hvilket ikke umidelbart er ønskværdigt, men hvad vigtigere er, så kan vi se at den kører imod lys!
Vi diskuterede os frem til at det måtte være muligt at implementere, i vores mapping fra sensorene til motorene, en algoritme der gør robotten hhv. mere eller mindre lysfølsom over tid. Det vil sige, hvis den placeres i et mørkt rum, vil den køre målbevist efter små lysværdier, og omvendt, stilles den i et lyst lokale bør den ikke køre særlig hurtigt, idet de høje værdier over tid skulle have mindre betydning for strømmen der sendes til motorene. Desværre kom vi ikke så vidt at vi fik implementeret denne tankegang, men det var nogle overvejelser vi gjorde os i løbet af eksperimentet.
Ingen kommentarer:
Send en kommentar