Lab 08 - Subsumption architecture

Dato: 07/10 2010
Varighed: 11-14
Deltagere: Daniel, Leni, Martin A og Martin N

1. Formål
Formålet med denne øvelse er at implementere forskellige observerbare opførseler på baggrund af subsumption arkitekturen.

2. Øvelsesgennemgang
Del 1:
Første del af øvelsen bestod i at afprøve et i forvejen implementeret subsumption program på LEGO bilen og se om de forskellige opførseler kunne identificeres.

Vi iagttog 3 forskellige scenarier, hvor følgende output ses på LCD displayet:

#1 Bilen kører fremad:
Sound Car
Drive 0 f
Avoid 0 45
Play 0

#2 Bilen er tæt på en væg, bilen bakker:
Sound Car
Drive 1 s
Avoid 0 9 b
Play 0

#3 Der afspilles en lyd fra bilen:
Sound Car
Drive 1 s
Avoid 1 41
Play 0 s

Ud fra disse resultater kan vi konkludere, at når der ikke foregår andet, kører bilen fremad.
Når der detekteres et objekt foran bilen, stopper den fremadkørende opførsel, og bilen bakker væk fra objektet og drejer mod venstre.
Hver 10. sekund stopper bilen uanset, hvordan den omgivelser er, og afspiller en lyd.

På LCD displayet ses om de 3 opførsler vil have bilen til hhv. at køre fremad (f), bagud (b) eller stoppe (s). Hvis der er et 1-tal ud for en opførsel, bliver dens output ignoreret.
Derudover vises afstanden målt med ultralydssensoren.

Del 2:
Ved at kigge i kildekoden, kan vi se at RandomDrive opførslen afvikles hele tiden, og konstant forsøger at opnå adgang til motorerne.

AvoidFront klassen har en betingelse der skal være opfyldt (distance > tooCloseThreshold), før den forsøger at få adgang til motorne. Når dette sker, blokeres RandomDrive klassen adgang til motorerne med et kald til funktionen suppress().

PlaySounds klassen aktiveres hvert 10. sekund, hvorefter først AvoidFront og RandomDrive klassens adgang til motorerne blokeres ved kald til supress(). Derefter afspilles en lyd, og endelig får de to undertrykkede klasser givet adgang til motorerne igen.

Del 3.1:
Alle klasserne der implementerer en opførsel, opretter en tråd til at afvikle denne opførsel parallelt med de andre. Disse tråde er oprettet som "daemon" tråde, hvilket sikrer at de stopper når hovedprogrammet lukkes.

Del 3.2:
Hver klasse, der implementerer en opførsel, indeholder metoder, der gør det muligt for højere prioriterede klasser at blokere dens adgang til motorerne.
Dette opnås ved, at den højere prioriterede klasse kan inkrementere variablen "suppressCount", hvorved den blokerede klasses adgang til motorerne forhindres. Når en klasse blokeres er det dens ansvar at blokere alle lavere prioriterede klasser som den selv har mulighed for at blokere; herved sikres det at kun den højest prioriterede tråd har adgang til de delte ressourcer.

Ved at bruge en integer i forbindelse med implementeringen af denne blokering, er det muligt for forskellige høj-prioritets tråde, at blokkere den samme lavere prioritets tråd, og sikre at den først frigives, når alle høj-prioritets opførsler er færdige.

I modsætning til arbiter metoden beskrevet af Fred Martin [1], er det ved suppression mekanismen de enkelte trådes opgave at blokere deres adgang til den delte ressource, hvorimod arbiteren håndtere al adgang til den delte ressource fra ét sted.

Ulempen ved at have denne adgangskontrol fordelt over flere klasser, er at der kan opstår problemer, hvis en klasse glemmer at blokere de lavere prioriterede tråde inden den selv skriver til den delte ressource.

Del 4:

3. Konklusion

4. Referencer
1: Fred Martin, [4, page 214-218]