Önálló laboratórium összefoglaló Készítette: Kisfaludi Péter A feladat címe: Autonóm robotok kooperatív stratégiája stratégiai célok megvalósításához A feladat konzulense: Dr. Harmati István
A dokumentum részei: A feladat háttere Célo k K ö rny e zet
A megoldás lépései K ö rny e zet mo de lle zé se St ra t ég iá k kut a t á sa M a t e ma t i ka i mo del l K eret re nd sz er St ra t ég ia f e j le szt é s Te szt e k, er ed mé ny e k Tá v la t i c élo k
A feladat háttere A megoldás célja: A megoldás fı célja kooperatív stratégiák fejlesztése és összehasonlítása volt, amel yben a stratégiák összehasonlítása szimuláció útján történt. A cél ol yan magas és alacson yszintő stratégiák kifejlesztése volt, amel yek felhasználják a játékelmélet és a gépi tanulás eredmén yeit (különös tekintettel a multiágens körn yezetekre). A feladat további célja volt egy ol yan keretrendszer kifejlesztése, amel yben a stratégiákat tesztelni lehetett, valamit további stratégiák implementálását megkönn yítette. A feladat második része a stratégiák összehasonlítás és szimulációja volt. Ebben a szakaszban arra kerestünk választ, hogy két stratégia mil yen szempontok alapján lesz összehasonlítható, illetve, hogy egy adott kezdeti feltétel esetén mel yik mil yen kimenetet ad. Erre azért van szükség, mert az összehasonlításhoz szükséges lenne ol yan objektív mérıszám megadása eg y stratégia minıségére, amel y lehetıség szerint nem azt veszi figyelembe, hog y egy konkrét lefutásra hogyan reagált a stratégia, hanem valami általánosabb, belsı jellemzıt számol ki. A félév során végül a feladat elsı részével tudtunk több idıt, tölteni, de alapszintő stratégiák implementálására is sor került.
A feladat környezete A feladatot valós fizikai körn yezetben, terepasztalokkal és tankokkal kellett megoldani. A valós körn yezetrıl a rendszernek egy képfeldolgozó modulon keresztül volt visszacsatolása, a rendszer pedig n yilvántartott egy ol yan belsı modellt is, amel y a fizikailag kin yerhetı információkon további, virtuálisan létezı paramétereket tartott n yilván (il yen volt például a tankok töltén ymenn yisége, amel y a hardver szintjén nem jelent meg)
A megoldás lépései Környezet modellezése A modellezés során külön kellett választani a valós fizikai körn yezetbıl származó modell-elemeket, valamint az olyan modellezı elemeket, amel yeket a fejlesztendı stratégia miatt kellett bevezetni. A modellalkotás során ezért figyelni kellett arra is, hogy a stratégiák mil yen lehetséges információkat, paramétereket igényelnek a körn yezetbıl (illetve az azt reprezentáló modellbıl), hiszen ezeket is a modellbe be kellett venni.
A konkrét fizikai körn yezet a terepasztal volt, rajta önállóan mozgatható tankokkal. A tankokhoz az alapvetı fizikai tulajdonságokon túl (mint a pozíció, orientáció) felvettük paraméterként az életerıt, az üzeman yagszintet, a látótávolságot, a hatótávolságot, stb. A terep egy sima felület volt, amel yen csak a virtuális modell szintjén jelentek meg akadál yok. A terepnek viszont a virtuális modellben tereptulajdonságok vannak definiálva, így egy jó stratégiának azt is figyelembe kell vennie, hogy a különbözı terepeken a jármővek haladási sebessége igen eltérı lehet.
Stratégiák kutatása A stratégiák kutatásához elolvastam Cruz, Marwan és Yong Liu cikkét az általuk javasolt dinamikus feladathozzárendelési módszerrıl. Ez a cikk definiálja a játékban részt vevı objektumokat és a rajtuk végezhetı mőveleteket (megadja a játék modelljét, amel y modellt az általunk fejlesztett modell részhalmazként tartalmazza). A cikk a játék során Nash-egyensúl yt tételez fel, ami azt jelenti, hogy minden csapat ol yan stratégiát választ, hogy adott konfigurációban (csapat és stratégia összerendelés) annál jobb stratégia nincsen (egyik csapatnak sem éri meg eltérni a választott stratégiánál, mert ezt csak a saját célfüggvén yének csökkenésével érhetné el). A problémafelvetés lén yege, hogy ha meg van engedve, hogy bizon yos egységek egy feladat elvégzése után egy másik feladatot is elvégezzenek, akkor az optimális stratégia (feladathozzárendelés) megtalálása exponenciálisan hosszúvá válik, mivel a hozzárendelési lehetıségek száma az idıben exponenciálisan növekszik, ahogy egyre több egység fejezi be a hozzárendelt feladatot és egyre kevesebb a még senkihez nem rendelt feladat. A problémára szuboptimális megoldást adó, számításigén yben szerén yebb megoldása egy 1 vagy 2 idılépésn yi elıretekintı csúszóablak alkalmazása, ami azt jelenti, hogy a feladathozzárendelések kombinációit csak ezen a csúszóablakon belül számítjuk ki, és ezek közül választjuk ki az optimális feladathozzárendeléseket, és ezt minden idılépésben dinamikusan újra elvégezzük. A szimulációk alapján a 2 mérető idıablak használata jobb megoldást adott, mint 1 idıablak használata. Elolvastam Arslan és Shamma cikkét, amel y játékelméleti megközelítésben tárgyalja az autonóm célpontválasztás lehetıségét. Ebben a cikkben a szerzık bebizon yítják, hogy megfelelı hasznosságfüggvén y és döntési mechanizmus esetén a résztvevık autonóm, individuális mőködésének eredmén yeként összességében optimális globális hasznosságra vezetı stratégia alakítható ki. Az egyes hasznosságfüggvén yeknek ehhez összhangban kell lenni a globális hasznosságfüggvénnyel, „tanulhatónak kell lennie” (az egyes cselekvések visszahatásának szignifikánsnak kell lennie) és lokalizált információn
alapulónak kell lennie, amel y kritériumokat például a WLU (Wonderful Life Utilit y) hasznosságfüggvén y teljesíti. A döntési mechanizmusnak szintén lokalizált információkon kell alapulnia, valamint feltétel, hogy gyorsan konvergáljon, a véges rendelkezésre álló idı miatt. Il yen döntési mechanizmus például a FP (Fictitious Play), amel y és a SAP (Spatial Adaptive Play), mel yek közül a szimulációk során a SAP bizon yult hatékon yabbnak. (A SAP a megerısítéses tanuláshoz hasonló, a korábbi lehetséges hasznosságok alapján dönt, míg az FP a jövıbeni lehetséges hasznosságok alapján). Elolvastam Yan Jin, Yan Liao, Minai és Pol ycarpou cikkét a felderítési feladatok és célponttal kapcsolatos feladatok egyensúl yban tartásáról. A cikk arra a problémára vázol fel egy megoldást, amikor a stratégiai feladat kezdetén még nem minden célpont és tereptulajdonság ismert elıre, hanem az egyes egységeknek a feladataik végrehajtása során egyrészt a már ismert célpontokkal kapcsolatos feladatokat kell végrehajtani, másrészt fel kell deríteni ismeretlen célpontokat és el kell dönteni, hogy az új célpontokkal mi a teendı. A cikk bemutat két eltérı feladathozzárendelési modellt: az egyik az aktuális állapot alapján dönt (jó eredmén yt ad, ha sok kezdetben ismeretlen célpont van), a másik egy megjósolt állapot alapján (jó eredmén yt ad, ha már sok ismert célpont van). Ebbıl következik, hogy ha az elsı modell szerinti feladathozzárendelés során már viszonylag sok célpontot felderítettünk, érdemes áttérni a második modell szerinti feladathozzárendelésre. Átnéztem a behatolók-üldözık problémájáról szóló cikket, amiben az tőnt fontosnak, hogy hierarchikus dekompozícióval (csapatok alakításával) oldották meg a feladatot, ami a szimulációk során jó eredményt adott. Az irodalomkutatás eredmén yei alapján a stratégiákat mindenképpen játékelméleti megközelítésben gondoltuk kifejleszteni, mivel ezekkel nagyon komplex, több ágenst tartalmazó rendszerre is adható optimális stratégia. A kezdetleges stratégiák fejlesztése során nem használtunk elıretekintı ablakot, hanem csak az ellenséges egységek konkrét elhel yezkedése alapján született meg a haditerv, illetve az egyes egységek ol yan módon döntöttek a cselekvéseikrıl, hogy nem vették figyelembe, hogy a többi (nem ellenséges) egység mil yen hadmőveletbe kezdett bele.
Matematikai modellezés A matematikai modellezés során a fizikai és a virtuális körn yzetet négy fı szempont szerint vizsgáltuk meg: • Statikus tulajdonságok (paraméterek) • Beavatkozójelek • Dinamikus tulajdonságok (változás a beavatkozás hatására) • Korlátozások (Mind a statikus, mind a dinamikus paraméterekre)
A modellezés során három fı dolognak alkottuk matematikai modelljét: • Tank • Fegyver (a tankhoz csatlakoztatva) • Mezı (térképrészlet tereptulajdonságokkal) Tank A tank statikus tulajdonságai:
A tank beavatkozójelei:
meg
a
részletesebb
A tank dinamikus tulajdonságai (állapotegyenlet)
A tankra vonatkozó korlátozások
A korlátozások egyenlete:
A tank dinamikus modellje:
Pozícióváltás:
Elhasználódás (életerıvesztés, üzeman yagfogyás)
Az egyes betők, jelölések szemantikája: x: A tank pozíciójának x tengel y irán yú komponense y: A tank pozíciójának y tengel y irán yú komponense θ: A tank orientációja HP: A tank életereje f: A tank üzeman yagszintje D: A tank energiabefektetése (a gázkar állása) r: A tank látótávolsága w: A tankhoz csatolt fegyverek listája aos: A tank látószöge sh: Az egyes fegyverekbıl egy idıpillanatban kilıtt lövedékek száma t: A tank által aktuálisan elfoglalt mezık listája
Fegyver A fegyver statikus tulajdonságai:
A fegyver beavatkozójelei:
A fegyver dinamikus tulajdonságai (állapotegyenlet)
A fegyverre vonatkozó korlátozások
A korlátozások egyenlete:
A fegyver dinamikus modellje:
Az egyes betők, jelölések szemantikája: r: A fegyver hatótávolsága aos: A fegyver látószöge H: A sebzési táblázat, megadja, hogy egy adott fegyver egy adott fajta egység ellen menn yire hatékon y a: A fegyver töltén ymen yisége FR: A fegyver tüzelési sebessége Mezı A mezı statikus tulajdonságai:
A mezı beavatkozójelei: Nincsenek beavatkozójelek
A mezı dinamikus tulajdonságai (állapotegyenlet) A mezı tulajdonságai az idıben nem változnak.
A mezıre vonatkozó korlátozások Nincsenek korlátozások Az egyes betők, jelölések szemantikája: µ c : A mezı sebességmódosító tén yezıje µ s : A mezı lövéspontosságot befol yásoló tén yezıje β: A mezı idıjárási tén yezıje (látótávolságot befol yásolja) OC: A mezıt elfoglaló entitások listája
Az így elıállt matematikai modell alapján el lehetett kezdeni a keretrendszer fejlesztését, amel y a matematikai modellt nem teljes mértékben követte, de a
rendszer modelljének megalkotásában nagyban támaszkodott rá. A fejlesztés során az derült ki, hogy a matematikai modellben leírt állapotegyenletek kiszámítása túl nagy számítási kapacitást köt le, és tekintve, hogy a rendszernek valós idıben kellett mőködnie, valamint azt, hogy a képfeldolgozó modul is viszon ylag erıforrásigén yes volt, úgy döntöttünk, hogy inkább a modellben teszünk ol yan egyszerősítéseket, amel yek mellett a stratégiák még összehasonlíthatóak maradnak (megmarad bizon yos fokú komplexitás)
Keretrendszer fejlesztés A keretrendszer megvalósításához felhasznált szoftver elemek: Microsoft Visual Studio 2008 Matlab A keretrendszert C# n yelven fejlesztettük, a stratégiákat pedig vegyesen C#ban (kevésbé bon yolult stratégiák) és Matlab körn yezetben (számításigén yes, bon yolult stratégiák). A két körn yezet között egy közös változóval lehetett a kapcsolatot megteremteni, amel y közös változót a két rendszer két irán yú FIFO-ként érte el, így lehetıség volt az adatszerkezetek, parancsok (szérializálás utáni) átvitelére. A keretrendszer fıbb moduljai: •
• •
•
•
GUI o Csapatok inicializálásához o Szimuláció n yomonkövetéséhez o Egységek csapatokhoz rendeléséhez o Kezdeti intelligenciakomponensek becsatolásához Képfeldolgozás o Vizuális visszacsatolás Modell o Fizikai, mérhetı paraméterek n yilvántartása o Virtuális paraméterek n yilvántartása o Virtuális korlátozások betartatása o Processzoridı biztosítása az intelligenciakomponenseknek Intelligencia o Matlab vagy C# o Futásidıben cserélhetı o Dinaikusan becsatolható különbözı szintekre Motion Planner o Mozgástervezés
•
Kommunikáció o Hardverfüggı n yelvre utasítások lefordítása o Esetlegesen hardver felıl érkezı információk (visszacsatolás)
fogadása
A keretrendszerben lévı modulok kapcsolata:
Képfeldolgozás A keretrendszerhez tartozó képfeldolgozó modul feladata a valós fizikai modellrıl szolgáltatott vizuális visszacsatolást biztosítani valós idıben. A keretrendszer feladata volt a képfeldolgozó modul által szolgáltatott kimeneti információk alapján a belsı (virtuális) modell naprakésszé tétele és elérhetıvé tétele a különbözı (akár Matlabos, akár C#-ben megvalósított) intelligencia komponensek számára. Modell A modellezés során diszkrét idıt feltételeztünk, mivel a képfeldolgozó modul is il yen módon tudta az információkat szolgáltatni. A modellezés során a
fizikailag létezı objektumokat kibıvítettük virtuális objektumokkal, amel yeket a terepasztalon úgy jelenítettünk meg, hogy színes filctollal különbözı módon sávozott téglalapokat vettünk fel. Ezek a téglalapok egyegy virtuális objektumot jelöltek. A keretrendszerben jelenleg modellezett elemek: • • • • • •
Tank Radarállomás Töltıállomás Bázisok Épületek Tereptulajdonságok
A belsı modell frissítése úgy történt, hogy a képfeldolgozás információi alapján az egységek hel yzetét és orientációját a keretrendszer módosította, a virtuális paramétereket pedig a matematikai modell egyszerősített változata alapján újraszámolta. Különbözı szőrıkkel meg lehetett azt oldani, hogy a fizikailag nem létezı korlátozásokat az egységek betartsák. Ehhez arra volt szükség, hogy minden kiadott parancs keresztülment a keretrendszer eg y ol yan modulján, amel y a bírónak felelt meg. Ez a modul valós idıben ellenırizte, hogy az egyes egységek által kiadni kívánt parancsok a virtuális modellel összhangban vannak-e, és a parancs esetleges cseréjével vagy teljes eldobásával biztosította a korlátozásokkal a konzisztenciát. Például ha egy tank az ideálistól eltérı terepen haladt, akkor mivel errıl fizikailag nem volt visszacsatolása, a modell felügyelı része oldotta azt meg, hogy a tanknak kiadott parancs hel yett egy ol yan parancsot adott ki, amel y az adott mezı tereptulajdonságaiból következı sebességgel történı haladás parancsát tartalmazta, mindeközben a tank fogyasztását ennek megfelelıen módosította. Ha viszont például egy életerejét vesztett tanknak adott ki a stratégia mozgatási vagy bármil yen parancsot, azt a keretrendszer felügyelı modulja egyszerően eldobta, az a parancs a kommunikációs modulhoz nem is jutott el. Intelligencia Az intelligencia modul feladata a stratégiák kezelése volt, ennek a modulnak a felelıssége volt, hogy az esetlegesen Matlabban futó számítások eredmén yét értelmezze és a keretrendszer számára a kívánt parancsokat elérhetıvé tegye. Az intelligencia modul több, azonos idıben betöltött stratégiát tartalmaz, amel yeket a csapatok (vagy eg ységek) dinamikusan, a program futása közben betölthetnek (erre akkor lehet szükség, amikor egy csapat úgy érzi, hogy az aktuális taktikája nem a megfelelı sebességgel vagy egyál talán nem viszi közelebb a célfüggvénn yel megfogalmazott céljához). Az egyes stratégiák implementációja is futásidıben cserélhetı (legalábbis azok, amel yek Matlab alatt kerültek implementálásra)
Az intelligencia futtatása úgy történik, hogy az egyes csapatoknak elıre definiált mérető idıszeletet oszt ki a keretrendszer, és az idıszelet alatt kell a stratégiának megterveznie minden kiadni kívánt parancsát. Az idıszelet befejeztével az intelligencia modul az egyes stratégiák által kért parancsokat végrehajtja és az ıket futtató szálat megszőntetni, majd a következı csapatnak biztosít megint egy idıszeletn yi futásidıt. Il yen módon elképzelhetı, hogy egy stratégia nem képes az idıszelet alatt a megfelelı parancsok kiszámítására, ekkor két dolog történhet: a stratégia vagy elmenti a kiszámolt értékeket és a következı idıszeletben visszatér a számításukhoz, vagy pedig a futási jog elvételekor elveszíti minden adatát és a következı idıszeletben már egy kevésbé komplex algoritmust futtat le. Az idıszeletek kezelésére azért van szükség az intelligencia modulban, hog y ne fordulhasson elı ol yan, hogy egy végtelen ciklusba került stratégia az egész program futását blokkolja. Az intelligencia és a modell közti adatáramlás szőrése ol yan szempontból meg van oldva, hogy az intelligencia modul tudással rendelkezik arról, hogy az egyes stratégiák melyik csapathoz vannak becsatolva, és amikor a modellben szereplı információkat az egyes stratégiák számára elérhetıvé teszi, figyel arra, hogy minden stratégia csak ol yan információkat kaphasson meg, amel y az aktuális modellbıl következik. Tehát például az egyes stratégiák a térképnek csak azon mezıihez férhetnek hozzá, amel yeket az adott csapat egységei a látómezejükkel lefednek. Természetesen lehetıség van arra, hogy az egyes stratégiák egy úgynevezett kognitív térképet tartsanak n yilván, tehát az egyszer már felfedezett térképrészletekbıl a teljes térképet össze tudják rakni. Motion Planner A motion planner feladata az volt, hogy egy bármil yen (de rögzített) formában kapott útvonaltervet lebontson ol yan elemi utasításokra, amel yeknek a hardverfüggı megfelelıjét a kommunikációs modul már ismeri. A hardver kialakítása miatt jelenleg három alapvetı mőveletre kell lebontani az utasításokat: fordulás adott szöggel adott irán yba, haladás elırefelé adott ideig valamint lövés. A parancsok közül konkrét fizikai megfelelıle csak az elsı két utasításnak (fordulás és haladás) van, a lövést a tank hátraugrásával modelleztük. Elképzelhetı például, hogy egy fol ytonos görbét kap meg a motion planner, ekkor azt úgy tudja elemi utasításokká alakítani, hogy egy adott (például megfelelıen kicsi, de fix) idıközönként mintavételezi, és a diszkrét útvonalpontokat adja ki a parancsokban.
Kommunikáció A kommunikációs modul feladata a parancsok lefordítása volt a hardvernek értelmezhetı formátumba, és ennek a modulnak a feladata volt az is, hogy ezeket a parancsokat az egyes egységeknek kiadja. A modul használható szinkron és aszinkron módban is, a valós idejő szimulációkhoz érdemes az aszinkron módot használni, mivel ekkor az egyes parancsok kiadása nem blokkolja a rendszert.
Stratégia fejlesztés A felsı szintő utasítások lebontása A stratégia fontos szempontja, hogy a stratégiai szinten (például a csapatok szintjén) csak azt akarjuk megmondani, hogy egy csoport hova menjen, mit csináljon, de magas szintő formalizmussal (deklaratívan, magas absztrakciós szinten). Például tipikus parancs egy védd meg a bázist, vagy egy foglald el az ellenséges bázist utasítás. Ezek a parancsok viszont deklaratívak abban az értelemben, hogy nem adnak pontos végrehajtásra vonatkozó információkat, az egységeknek alacson yabb szinten kell eldönteni, hogy az adott célt mil yen módon fogják elérni. Ahhoz, hogy ezeket a magas szinten kiadott parancsokat le tudjuk bontani az alacson yabb hierarchiaszintek számára értelmezhetıbb formában, szükség van valamil yen fajta tervkészítı alkalmazására, amel y le tudja bontani a stratégiai utasításokat elemi(bb) utasítások sorozatára. Másik lehetıség a parancsok lebontására, hogy a különbözı stratégiai modulok rendelkeznek azzal a tudással, hogy hogyan kell egy magas szintő utasítást lebontani alacson yabb szintővé. Ekkor viszont ezt a tudást explicit bele kell kódolni a stratégiába, ami kevesebb rugalmasságot enged meg, mit ha tervkészítıket alkalmaznánk. A tervkészítık alkalmazásának hátrán ya viszont az adatok átvitele miatt jelentkezı overhead, viszont tesztekkel, szimulációkkal meg kell vizsgálni, hogy összességében a számítási idıben történik-e n yereség. A konkrét tervkészítı kiválasztásánál továbbá figyelni kell majd a valósidejőség követelmén yére, valamint arra, hogy az általunk használt modellre jól alkalmazható legyen (hasonló elemekkel, utasításszervezéssel dolgozzon). Léteznek ol yan tervkészítık, amel yek csak elemi akciók sorozatát adják vissza, de léteznek olyanok is, amel yek képesek úgynevezett hierarchikus terv elkészítésére, ami azt jelenti, hogy a tervet úgy készíti el a tervkészítı, hogy benne megjelenhetnek összetett(összevont, aggregált, kompozit) utasítások is, aminek következtében a hierarchiaszinteken az éppen (nekünk) szükséges mél ységig kell csak lemenni a megfelelı akciók kiválasztásához. (Tehát ha megelégszünk egy m enj északn yugatra paranccsal, akkor nem kell megnézni, hogy ez tulajdonképpen „fordulj 36 fokot balra és menj elıre 10 métert” akciókra tovább bontható, ahol a „fordulj balra 36 fokot” tovább bontható „fordulj balra 1 fokot” parancsok 36-szori egymásutánjára). A konkrét
feladathoz alkalmasabb egy hierarchikus tervkészítı használata, hiszen ekkor a modellben megjelenı hierarchiaszinteket meg lehet feleltetni a tervkészítıben megjelenı hierarchiaszinteknek, és ezeket a parancsokat mindig a megfelelı szinten kiadva az alkalmazás mőködıképes lesz, továbbá nem kell a tervkészítés (valószínőleg hosszadalmas) folyamatát minden hierarchiaszinten kezdemén yezni. Néhány, a tapasztalatok, illetve nemzetközi versenyek alapján jól telesítı tervkészítı: Egy ágensre (a tervkészítı csak egy ágenssel foglalkozik, nem veszi figyelembe az abból adódó optimalizációs lehetıségeket, hogy egy terv megvalósításában több ágens fog részt venni) STRIPS: Hagyomán yos tervkészítı, elképzelhetı, hogy megfelelı lesz nekünk a mőködése. Dinamikus mőködésre nem képes, futásidıben érkezı információkat nem értékel ki. CASPER: Lehetıvé teszi, hogy megadjuk egy elérendı célhalmazt, a jelenlegi és a kívánt modell-állapotot, és ez alapján készít tervet. Elın ye, hogy a bemeneteket fol yamatosan változtatva újratervezi az akciókat, lehetıség van arra, hogy az aktuális modell frissítése után a tervkészítı egy újratervezést hajtson végre, ezáltal a gyakorlatban jobban használható terveket fogunk kapni. SHOP-2: Hierarchikus tervkészítı, nagy biztonsággal old meg tervkészítési feladatokat. A 2002-es tervkészítı versenyen 99%-os teljesítmén yt produkált. (open source, ingyen es) Több ágensre (a tervkészítı körn yezetben használjuk):
fel
van
arra
készítve,
hogy
multiágens
SIPE-2 Interaktív információbevitellel fol yamatos terv-újrakészítést tesz lehetıvé, ki tudja használni az újonnan bejövı információkat és ez alapján a tervet módosítani tudja. Hierarchikus terv készítésére alkalmas. Sikeresen használták légihadjárat-tervezéshez, katonai hadmőveletek tervezéséhez. MPA-ra épülı (MPA= Multiagent Planning Architecture by David Wilkins) architektúrát használ. Ezen tervkészítı közül alkalmasnak tőnik a S IPE-2 használata. Parancsok lebontásának megvalósítása A különbözı hierarchiaszinten kiadott parancsok lebontásának fol yamata a jelenlegi modellezéssel:
Az ábra azt mutatja be, hogy a modellben definiált hierarchiaszintek között hogyan történik a parancsok lebontása. A modellben három fı hierarchiaszintet különböztetünk meg: Stratégiai szint(Csapatoknak) Taktikai szint(Egységeknek) Fizikai szint (mozgástervezés, hardverfüggı részek) Topológia Az intelligencia moduloknak lehetıségük van a csapatok topológiájának n yilvántartására is. A csapatok topológiája irán yított körmentes gráf (fa), ahol a csomópont jelenthet konkrét, vagy virtuális egységet. A konkrét egység a valóságban is a terepasztalon lévı egys éget jelent, a virtuális egység pedig ol yan csomópont a gráfban, amel yik egy hierarchiaszint miatt jelenik meg (tehát a csapat parancsnoka például nem egy konkrét fizikai egység). Minden csomópont ismeri a közvetlen leszármazóit és a felmenıjét. A kommunikáció a felmenık irán yába csak visszacsatolás jellegő lehet, a gyermekcsomópontok irán yába mind információk, mind utasítások áramolhatnak. Az intelligenciák mivel általában Matlab körn yezetben vannak megvalósítva, tartalmaznak minden élhez egy kommunikációs változót, amelyen keresztül a kommunikáció történik. Ez a változó teljesen hasonló a Matlab és a Visual Studio között használt változóhoz, tehát ez is egy FIFO jelleggel használható kommunikációs csatorna.
Szimuláció, teszt A keretrendszer teszteléséhez elıször minden osztál ynak létrehoztuk egy úgymond Dumm y példán yát, amel y arra volt képes, hogy nem okozott kivételt a rendszer futásában és a legszükségesebb inicializáló, illetve kommunikáló rutinok meg voltak benne valósítva. Íg y meg lehetett azt oldani, hogy a keretrendszer leforduljon. Ezután a hel yes mőködés ellenırzéséhez egy logger alkalmazást használtunk, amel y képes volt a felépülés és futás során végrehajtott belsı akciókat naplózni, így ellenırizni lehetett, hogy az egyes példán yok konkrétan hogyan kapcsolódnak egymáshoz. A modell felépítése során különösen azt kellett vizsgálni, hogy az egyes hierarchiaszinteken elhel yezkedı stratégiaobjektumok egymással mil yen viszon yba kerülnek (az elvárt mőködés az volt, hogy kialakul a hierarchia és létrejönnek az egyes ágak mentén a kommunikációhoz tartozó, Matlab kommunikációt lehetıvé tevı változók A szimulációt úgy valósítottuk meg, hogy a mozgatás parancsot fizikai szintre fordító utasítás is implementálva volt, az egyes intelligenciák által kiadott mozgatás parancsok eredmén yei tehát láthatóak voltak a terepasztalon is. Az intelligenciák tehát csak mozgatás parancsokkal dolgoztak, és úgy teszteltük ıket, hogy minden elızetes információ nélkül az intelligenciák csak elküldték a tankokat valamilyen pozícióba. Ez, bár nem egy komplex stratégia megvalósítása, mégis bizon yítja, hogy a keretrendszer mőködıképes, hiszen a parancsok hierarchiaszintek közötti áramlása, illetve a Matlab kapcsolat mindenképpen mőködıképes kellett, hogy legyen, hiszen a parancsnak el kellett érnie a legalsó (Kommunikátor) hierarchiaszinte is.
A szimuláció során készített képek:
A szimuláció és a tesztelés eredmén ye alapján elmondható, hogy a projekt eddig megvalósított fázisai sikeresen lezárultak, a következı félévekben a megvalósított keretrendszerre lehet hatékon yan fejleszteni
További célok • • • • • •
Komplex, játékelméleten alapuló stratégiák kifejlesztése Adaptív algoritmusok bevezetése Valószínőségi modellezés További modellezı elemek felvétele a modellben Stratégiákhoz minıségi mérıszám rendelése Stratégiák összehasonlítása
