Typ Agenta Mˇeˇren´ı v´ykonu Prostˇred´ı Aktu´atory Senzory
Robotick´y fotbalista
Fotbalov´e hˇriˇstˇe (mˇr´ıˇzka)
Vstˇrelen´e g´oly M´ıˇc Nohy k pohybu Kamera
Min inkasovan´ych g´ol˚u Spoluhr´aˇci Nohy k odkopnut´ı m´ıˇce Protihr´aˇci
Pˇr´ıstup˚u k n´avrhu agent˚u existuje cel´a ˇrada. K naˇsim potˇreb´am poslouˇz´ı nejl´epe reflexn´ı agent, kter´y reaguje na aktu´aln´ı podnˇety a neuvaˇzuje jejich historii (coˇz se v re´aln´em fotbalu nehod´ı – hr´aˇci se uˇc´ı z chyb). Specifick´y n´avrh je vidˇet na obr´azku 3.1. Diagram popisuje princip vnitˇrn´ıho fungov´an´ı agenta: Nejdˇr´ıve agent sv´ymi senzory z´ısk´a informace o prostˇred´ı. Tyto informace jsou pak pˇred´any jako vstup rozhodovac´ımu stromu, kter´y byl pˇredem zkonstruov´an z tr´enovac´ıch dat. Strom je vlastnˇe funkce f(x), kter´a vrac´ı rozhodnut´ı – v naˇsem pˇr´ıpadˇe akci.
Tato akce se pˇred´a ke zpracov´an´ı aktu´ator˚um agenta a provede se. Akce m˚uˇze2ovlivnit prostˇred´ı, a to jen svoji aktu´aln´ı pozici nebo pozici m´ıˇce.
2Kdyˇz agent provede akci kopnut´ı m´ıˇce, ale m´ıˇc nem´a, tak neovlivn´ı prostˇred´ı.
20 Kapitola 3. Vlastn´ı n´avrh
Obr´azek 3.1Diagram vnitˇrn´ıho n´avrhu agenta
3.2.1 Akce
Agent m˚uˇze pomoc´ı sv´ych aktu´ator˚u vykon´avat akce a t´ım ovlivˇnovat prostˇred´ı. Vˇsechny jeho akce se daj´ı rozdˇelit na dvˇe kategorie:
Pohyb
Z´akladn´ı akce agenta. Umoˇzˇnuje mu pohybovat se do osmi smˇer˚u. M˚uˇze se pohybovat na urˇcitou pozici nebo do urˇcit´e z´ony. K nalezen´ı cesty je vyuˇz´ıv´an algoritmus A* upraven´y pro hled´an´ı cesty v mˇen´ıc´ım se prostˇred´ı (ostatn´ı agenti).
Pr´ ace s m´ıˇ cem
Agent m˚uˇze m´ıˇc vystˇrelit urˇcitou silou na jemu urˇcenou pozici, jemu urˇcen´e z´ony nebo nˇekter´emu z jeho spoluhr´aˇc˚u. Tak´e m˚uˇze m´ıˇc vz´ıt a pohybovat se s n´ım.
Senzory
Tento agent m´a jedin´y senzor, a to kameru, ze kter´e vypoˇc´ıt´av´a veˇsker´e informace. Dok´aˇze z nich z´ıskat polohu spoluhr´aˇc˚u, protihr´aˇc˚u i m´ıˇce. Senzor byl vybr´an kv˚uli korespondenci s re´aln´ym fotbalem, kde hr´aˇci z´ısk´avaj´ı nejv´ıce informac´ı zrakem. V realitˇe sice hr´aˇci vn´ımaj´ı i pomoc´ı sluchu a hmatu, ale pro tuto simulaci tyto senzory neuvaˇzujeme.
3.3 Simulace spojit´ eho ˇ casu
V diskr´etn´ım modelu ˇcasu robot potˇrebuje jednu jednotku ˇcasu k pohybu na sousedn´ı pole.[2]
Jelikoˇz chceme pracovat s r˚uzn´ymi rychlostmi hr´aˇc˚u a m´ıˇce, mus´ıme vyuˇz´ıt model spojit´eho ˇcasu.
K jeho simulaci vyuˇzijeme modifikovanou datovou strukturu prioritn´ı fronta (d´ale jen fronta).
3.4. Implementace rozhodovac´ıch strom˚u 21
V´ypis k´odu 3.1 Abstraktn´ı tˇr´ıda vrcholu v rozhodovac´ım stromu p u b l i c c l a s s C A c t i o n {
A c t i o n a c t i o n ; f l o a t p r i o r i t y ; }
IDefinice 3.2. Fronta je abstraktn´ı datov´a struktura, kter´a ukl´ad´a prvky. Prvky z n´ı vystupuj´ı v poˇrad´ı, ve kter´em pˇriˇsly (typ FIFO = First-In, First-Out, ˇcesky Prvn´ı dovnitˇr, prvn´ı ven). Z prioritn´ı fronty vystupuj´ı nejdˇr´ıve prvky s nejvyˇsˇs´ı prioritou z´ıskan´e na z´akladˇe prioritn´ı funkce.
[3, pˇreklad vlastn´ı]
Do fronty budeme vkl´adat struktury reprezentuj´ıc´ı akce (k´od 3.1):
Fronta, narozd´ıl od klasick´e definice, bude zpracov´avat nejdˇr´ıve prvky s nejniˇzˇs´ı prioritou, kter´a reprezentuje ˇcas vykon´an´ı akce. Agenti pˇri pokusu proveden´ı nˇejak´e akce, mus´ı ”vzn´est poˇzadavek“ t´eto frontˇe (pomoc´ı struktury CAction, kde priority je doba trv´an´ı akce). Ta si mus´ı udrˇzovat hodnotu pr´avˇe zpracov´avan´eho ˇcasu a tu pˇriˇcte k prioritˇe pˇr´ıchoz´ı struktury. N´aslednˇe tuto strukturu vhodnˇe um´ıst´ı do sv´e pamˇeti (cel´y proces lze vidˇet na obr´azku 3.2).
Obr´azek 3.2 Proces vkl´ad´an´ı nov´e akce do fronty
Fronta tedy postupnˇe zpracov´av´a poˇzadavky a pˇri jejich vyjmut´ı provede definovanou akci.
Agent tedy provede akci a z´aroveˇn vnese nov´y poˇzadavek frontˇe. M´ame tedy zajiˇstˇeno pracov´an´ı s r˚uzn´ymi d´elkami trv´an´ı jednotliv´ych akc´ı a t´ım z´ısk´av´ame simulaci spojit´eho ˇcasu.
Probl´em m˚uˇze nastat, kdyˇz se ve frontˇe budou nach´azet dvˇe akce se stejnou prioritou. V nˇekter´ych sc´enaˇr´ıch by mohlo z´asadnˇe z´aleˇzet na poˇrad´ı proveden´ı tˇechto kolizn´ıch akc´ı, ale v naˇsem pˇr´ıpadˇe provedeme dˇr´ıv akci, kter´a do fronty pˇriˇsla jako prvn´ı.
3.4 Implementace rozhodovac´ıch strom˚ u
Rozhodovac´ıstrom se skl´ad´a z koˇrene, vniˇrn´ıch vrchol˚u a list˚u. Pro vˇsechny tyto uzly si vytvoˇr´ıme abstraktn´ı tˇr´ıdu, ze kter´e budou dˇedit. Spoleˇcn´e atributy tedy jsou (viz. 3.2) hloubka uzlu (jak daleko od koˇrene se nach´az´ı) a rozliˇsovac´ı flag, jestli se jedn´a o vnitˇrn´ı uzel.
22 Kapitola 3. Vlastn´ı n´avrh
V´ypis k´odu 3.2 Abstraktn´ı tˇr´ıda vrcholu v rozhodovac´ım stromu p u b l i c a b s t r a c t c l a s s D e c i s i o n T r e e N o d e {
p r o t e c t e d b o o l i s I n n e r ; p u b l i c int d e p t h ;
}
Vnitˇrn´ı vrchol (viz. 3.3) si mus´ı udrˇzovat informace o sv´ych synech, kter´e jsou typu Decisi-onTreeNode, takˇze se m˚uˇze jednat o vnitˇrn´ı vrchol nebo list. D´ale pak mus´ı m´ıt specifikovanou hodnotu, kter´a se bude porovn´avat se z´ıskan´ymi daty od agenta pˇri pr˚uchodu stromem (3.5).
Vnitˇrn´ı vrcholy mus´ı m´ıt definovan´e oba syny, jinak m˚uˇzeme pˇri pr˚uchodu narazit na chybu (kaˇzd´y pr˚uchod stromem mus´ı vracet akci, ale kdyˇz nen´ı definovan´y jeden syn, m˚uˇze nastat situace, kdy nem´ame moˇznost vr´atit akci).
V´ypis k´odu 3.3 Implementace vniˇrn´ıho vrcholu p u b l i c c l a s s I n n e r N o d e : D e c i s i o n T r e e N o d e {
Listy narozd´ıl od vnitˇrn´ıch vrcho˚u uˇz nemohou m´ıt ˇz´adn´e potomky. Obsahuj´ı pouze urˇcitou akci agenta (struktura CAction), kterou pˇri pr˚uchodu stromem (zde pr˚uchod konˇc´ı, viz. 3.5) pˇred´a frontˇe simuluj´ıc´ı spojit´y ˇcas. Listy maj´ı jeˇstˇe pomocnou metodu k z´ısk´an´ı jm´ena akce, kter´a ale nen´ı pro funkˇcnost d˚uleˇzit´a, pouˇz´ıv´a se jen pˇri vizualizaci rozhodovac´ıho stromu.
V´ypis k´odu 3.4 Implementace listu
p u b l i c c l a s s L e a f N o d e : D e c i s i o n T r e e N o d e { p r i v a t e C A c t i o n _ c A c t i o n ;
p u b l i c v o i d E x e c u t e () = > _ c A c t i o n . C o m m i t ();
}
Pˇri spuˇstˇen´ı programu nebo po vykon´an´ı nˇejak´e akce se opˇet proch´az´ı rozhodovac´ı strom agenta. Nejdˇr´ıve mus´ıme z´ıskat data z jeho senzor˚u. Pot´e zaˇcneme proch´azet strom od koˇrene.
Pokud se jedn´a o vnitˇrn´ı vrchol, porovn´ame urˇcit´y pˇr´ıznak ze z´ıskan´ych dat s hodnotou vrcholu.
Porovn´an´ı prob´ıh´a pouze pomoc´ı oper´atoru >. Pˇri pouˇzit´ı inverzn´ıho oper´atoru se pouze prohod´ı synov´e vˇsech vnitˇrn´ıch uzl˚u, takˇze nen´ı potˇreba implementovat pouˇzit´ı libovoln´eho oper´atoru.
V´ypis k´odu 3.5 Funkce pro pr˚uchod rozhodovac´ım stromem p u b l i c v o i d P r o c e e d (){
R e q u e s t D a t a (); // Get d a t a f r o m a g e n t D e c i s i o n T r e e N o d e n o d e = _ r o o t ;
w h i l e ( t r u e ) {
3.5. Hled´an´ı cest 23
Agenti ke sv´emu pohybu do urˇcit´eho m´ısta potˇrebuj´ı nˇejak´y algoritmus k nalezen´ı cesty. Existuje ˇrada tˇehchto algoritm˚u napˇr.: BFS, DFS, Greedy Search, A*, Dijkstra, atd. Ne vˇsechny algoritmy dok´aˇzou naj´ıt nejkratˇs´ı cestu (DFS, Greedy Search) nebo potˇrebuj´ı v´ıce dostupn´ych prostˇredk˚u neˇz je skuteˇcnˇe potˇreba. Pro n´aˇs pˇr´ıpad jsme zvolili A*, a to hlavnˇe kv˚uli naˇsemu prostˇred´ı, coˇz je m ∗ n mˇr´ıˇzka. Princip fungov´an´ı A* m˚uˇzeme nejl´epe popsat na uk´azan´ı rozd´ıl˚u mezi n´ım a Greedy Searchem. Nejprve ale mus´ıme definovat pojem heuristika a zm´ınit nˇekter´e vlastnosti, protoˇze se v obou algoritmech vyuˇz´ıv´a. Tak´e uvaˇzujme, ˇze cestu hled´ame v prostoru X a prvky x ∈ X jsou nˇejak´e pozice, mezi kter´ymi m˚uˇzeme mˇeˇrit vzd´alenost funkc´ı d(x1, x2).
IDefinice 3.3 (Heuristika). ”Heuristika h(x) je (v kontextu hled´an´ı nejkratˇs´ıch cest) odhado-van´a cena (d´elka) nejlevnˇejˇs´ı (nejkratˇs´ı) cesty z urˇcen´e pozice do c´ıle.“ [3, pˇreklad vlastn´ı]
Pro popis vlastnost´ı si definujeme optim´aln´ı heuristiku h∗(x), kter´a vrac´ı skuteˇcnou cenu (vzd´alenost) od pozice k c´ıli. Tato heuristika sice existuje, ale vypoˇc´ıtat jde pouze hrubou silou, tud´ıˇz se to v´ypoˇcetnˇe nevyplat´ı. Lepˇs´ı heuristiku neˇz h∗(x) nelze sestavit.
I Definice 3.4 (Pˇr´ıpustnost heuristiky). ”Pˇr´ıpustn´a heuristika je takov´a, kter´a nikdy nenad-hodnot´ı cenu (vzd´alenost) do c´ıle.“[3, pˇreklad vlastn´ı] Form´alnˇe:
∀x ∈ X : h(x) ≤ h∗(x)
Pˇr´ıpustn´e heuristiky jsou nˇekdy taky oznaˇcov´any jako optimistick´e.
IDefinice 3.5 (Konzistence (Monot´onnost) heuristiky). ”Heuristika je konzistetn´ı, jestliˇze pro kaˇzdou pozici x a kaˇzd´eho jeho souseda x’ je odhadovan´a cena (vzd´alenost) do c´ıle z x nen´ı vˇetˇs´ı
24 Kapitola 3. Vlastn´ı n´avrh
neˇz re´aln´a cena (vzd´alenost) z x do x’ plus odhadovan´a cena (vzd´alenost) do c´ıle z x’.“[3, pˇreklad vlastn´ı] Form´alnˇe:
∀x, x0∈ X : h(x) − d(x, x0) ≤ h(x0)
IVˇeta 3.6. Algoritmus A* je koneˇcn´y a s monot´onn´ı heuristikou je jeho v´ystupem optim´aln´ı cesta.
D˚ukaz. Algoritmus iteruje pˇres mnoˇzinu open, dokud nen´ı pr´azdn´a. Pˇri kaˇzd´e iteraci odstran´ıme jeden prvek x a do open vloˇz´ıme jeho sousedy, kteˇr´ı nejsou v mnoˇzinˇe closed. Nakonec x vloˇz´ıme do mnoˇziny closed =⇒ ˇz´adn´y prvek nebude v mnoˇzinˇe open v´ıckr´at, neˇz jednou a jelikoˇz je poˇcet prvk˚u koneˇcn´y, algoritmus se zastav´ı. D˚ukaz optimality viz [3, s. 95]
Algoritmus 5:A*
10 temp d ← GetDistance(x,y) + x.gCost
11 if y /∈ open ∨ temp d < y.gCost then
12 y.prev = x
13 y.gCost = temp d
14 y.fCost = y.gCost + GetDistance(start,y)
15 if y /∈ open then
Algoritmus mus´ıme modifikovat kv˚uli hled´an´ı cesty v prostˇred´ı s v´ıce agenty [18]. V podm´ınce v 5 na 11. ˇr´adce staˇc´ı pˇr´ıdat ke konjunkci kontrolu obsazenosti pozice. To znamen´a upravit podm´ınku n´asledovnˇe: if((y /∈ open ∨ temp d < y.gCost) ∧ y.Empty())
3.5.1 Rychlostn´ı optimalizace
Funkce pro hled´an´ı cesty se mus´ı volat pˇred kaˇzd´ym proveden´ym pohybem. Nejv´ıce ˇcasu (O(n)) se pak spotˇrebuje na hled´an´ı minima na ˇr´adku 5. Mus´ıme tedy vybrat novou a vhodnou strukturu pro mnoˇzninu open. Takovouto strukturou je minim´aln´ı bin´arn´ı halda. ˇCasov´a sloˇzitost ˇr´adku 5 se tedy zmˇen´ı na O(log n). Touto optimalizac´ı vˇsak zaplat´ıme zpomalen´ım vkl´ad´an´ım do open na ˇr´adku 16, z O(1) na O(log n).
Kapitola 4
Z´ısk´ an´ı dat a experimenty
V t´eto kapitole se budeme zab´yvat z´ısk´av´an´ım potˇrebn´ych dat (testov´an´ım) k supervi-zovan´emu uˇcen´ı, konkr´etnˇe pro konstrukci rozhodovac´ıch strom˚u. Pop´ıˇseme zde rozdˇelen´ı
´uˇcastn´ık˚u, postup z´ısk´an´ı dat a jejich strukturu. Nakonec, na z´akladˇe tˇechto dat, budeme prov´adˇet experimenty se vznikl´ymi agenty.
Vzhledem ke specifiˇcnosti t´ematu a netrivi´alnosti z´ısk´an´ı dat jsme nezvolili hromadn´e a ano-nymn´ı testov´an´ı. Softwarov´y prototyp nem´a webovou verzi a t´ım se testov´an´ı zt´ıˇzilo. Testov´an´ı tedy bylo uskuteˇcnˇeno kontaktnˇe nebo online s dozorem s menˇs´ım poˇctem lid´ı.
Obr´azek 4.1 Uk´azka situaci ze SW prototypu vyuˇzit´eho k z´ısk´an´ı dat
4.1 Popis testovan´ e skupiny
Cel´eho testov´an´ı se z´uˇcastnilo 12 lid´ı. Vzhledem k t´ematu pr´ace se nab´ızelo prozkoumat rozd´ıl mezi daty aktivn´ıch hr´aˇc˚u fotbalu (d´ale jen fotbalist´e) a lid´ı nehraj´ıc´ıch fotbal (d´ale jen nefot-balist´e). Skupinu tak tvoˇr´ı 6 fotbalist˚u a 6 nefotbalist˚u. Testov´an´ı napˇr´ıˇc skupinami se nijak neliˇsilo, bylo ´uplnˇe totoˇzn´e.
25
26 Kapitola 4. Z´ısk´an´ı dat a experimenty
4.2 Z´ısk´ an´ı dat
K z´ısk´an´ı dat n´am poslouˇzily pˇredem nadefinovan´e a jednoduch´e situace. Na kaˇzdou roli agenta pˇripadaj´ı 2-4 situace. Uˇzivatel ovl´ad´a jednoho agenta podle instrukc´ı, kter´e jsou dopˇredu zn´amy.
Pˇri kaˇzd´em vstupu od uˇzivatele se do souboru uloˇzila data ze senzoru ovl´adan´eho agenta. Kaˇzd´a akce se ale jednoduˇse ned´a pˇrev´est na ˇc´ıslo. Nejdˇr´ıve mus´ıme podle typu vstupu analyzovat danou akci. To znamen´a ˇze napˇr. pˇri zm´aˇcknut´ı ˇsipek v´ıme, ˇze se jedn´a o pohyb, ale mus´ıme ho bl´ıˇze specifikovat (m˚uˇze se jednat o pohyb k m´ıˇci, nebo pohyb do urˇcit´e z´ony hˇriˇstˇe). To sam´e plat´ı o vstupu z myˇsi, kdy se jedn´a o akci s m´ıˇcem.