Androids - TP 2010/2011

Z RoboCupTP wiki

Androids Tím Androids je zoskupenie študentov na predmete Tímový projekt na FIIT STU v školskom roku 2010/2011. V tejto časti analýzy sa sústreďujem na ich prácu, na ktorú by mal náš tým tento rok nadviazať. Analyzoval som ich konečnú dokumentáciu a používateľskú príručku, pomocou ktorej som následne úspešne vyskúšal ich konečný produkt.

Členovia tímu androdis v minulom roku analyzovali dvanásť svetových 3D tímov, server pre robocup a agenta JIM. Ďalej sa budeme stručne venovať iba robotovi NAOvi a agentovi JIMovi, pretože slúžil ako podklad pre vytvorenie agenta tímu androids.

1.1.1 Robot NAO Model robota, s ktorého využili na projekte RoboCup 3D, je Robot NAO. Má výšku je 57 cm a váhu 4,5 kg. Je zložený z 22 kĺbov. Na Obr. 1 sú znázornené kĺby a osi robota NAO.

Obrázok č.1: Kĺby a osi robota NAO – pomôcka pri tvorbe pohybov

1.1.2 Agent JIM Agent JIM je fakultný agent, pôvodne vytvorený z agenta Sirius tímu Critical Error a prenesený do Javy. Tím androids komunikáciou s autormi agenta získali dobrý prehľad o tomto agentovi. Rozhodli sa vylepšovať jeho koncept, pretože je vhodne štruktúrovaný a organizovaný, moderný a dostatočne zdokumentovaný. Z ich analýzy sa dozvedáme, že agent bol vytvorený v prostredí Eclipse v jazyku Java, kde bola vytvorená komunikácia, parser, model sveta a predpovedací modul, a v jazyku Ruby, kde bola vytvorená logika a konfigurácie. Využité boli taktiež aspektovo-orientované techniky pomocou AspectJ, zmenili načítavanie pohybov a správania, a vytvorili pohyby vstávania z brucha, chrbta a prototyp chôdze. Agent sa skladá z piatich komponentov, a to Communication, Parser, Models, Planner a Movement Engine. 1.1.3 Špecifikácia a návrh prototypu V špecifikácii sa venovali dosť širokému záberu požiadaviek. Chceli vylepšiť alebo vytvoriť nové pohyby hráča, ako vstávanie (3 typy), chôdza(2 typy), otáčanie(v rôznych uhloch a vojenské), kop do lopty(nastavenie sa na loptu a rôzne druhy kopov) a bránenie gólom(pád do boku a sadnutie s rozkročenými nohami), chceli vytvoriť vyššiu logiku(chôdza, vstaie, kop do lopty, vedenie lopty, zorientovanie sa, blokovanie strely), ktorá v agentovi JIMovi chýbala, chceli vylepšiť editor pohybov a správania, chceli definovať vyššiu logiku pomocou XABSL(prototyp funkcii a definície parametrov vyššej logiky) a chceli vytvoriť framework pre efektívne testovanie schopností hráča(automatizovanie a zrýchlenie simulácie a jej vyhodnocovania). V návrhu už vynechali niektoré oblasti zo špecifikácie a určili si priority. Navrhli 2 typy vstávania, chôdzu(najvyššia priorita), otáčanie o 90°, 180° a vojenské otáčanie(vysoká priorita, pretože je rýchle, no náročne na stabilitu), kop do lopty(kop dopredu a stranou nohy), bránenie(oba spôsoby). V návrhu vyššej logiky spracovali uviedli diagramy a vstupné parametre: chôdza(cieľ), vstávanie(aktuálny stav), kop do lopty(cieľ a sila), vedenie lopty(cieľ), zorientovanie sa na zistenie svojej polohy a polohy lopty. Navrhli rozšíriť existujúci editor pohybov a to zlepšením funkcionality a implementovaním editora správania(ako plugin). Zlepšenie funkcionality: navrhnuté pridanie nového panelu s možnosťou symetrického a zrkadlového ohýbania kĺbov alebo samostatne, refactoring kódu, doplnenie používateľského rozhrania a umožnenie zložitejších pohybov. V editore správania navrhli algoritmus práce produkčného systému: načítanie súboru s pravidlami, výber pravidlo z bázy poznatkov, pre zvolené pravidlo nájde kombinácie naviazania premenných a podmienkovej časti a na ne naviaž akciu na pravidlo, odfiltruj nesprávne a zaraď medzi akcie na vykonanie, ak neexituje aplikovateľná akcia tak ukonči proces, inak vykonaj prvú akciu a znova vyber pravidlo z bázy poznatkov. Navrhli taktiež vyššie správanie v XABSL, kde je opisované pomocou konečného stavového automatu, ktorý pozostáva z menších celkov, ktoré sú implementované v Jave. Navrhli tak zorientovanie sa a blokovanie strely. Ďalej navrhli novú architektúru testovacieho agenta, ktorý musí dokázať testovať schopnosti nižšej úrovne a taktiež vloženie viacerých schopnosti nižšej úrovne a testovať tak schopnosti vyššej úrovne. Testovací framework je zložený z netriviálnych blokov: parametre modelu(meniteľné parametre agenta/agentov), záznam zo servera(informácie o situácii), požadované konanie(zadáva užívateľ), vyhodnotenie konania(nižšia úroveň – pozície kĺbov, vyššia úroveň pozície agentov). Navrhli implementovať testovací framework v Jave za pomoci knižníc JGAP a JAGA, ktoré obsahujú funkcie na prácu s generickými algoritmami.

1.1.4 Prototyp Do prototypu sa rozhodli implementovať tri časti: testovací framework, pohyby pre agenta JIM, a vylepšenie v editore pohybov tímu Agenty 007.

Testovací framework je aplikácia na posielanie príkazov agentom, ich plnenie a vyhodnocovanie na základe údajov získaných zo servera. Musí umožňovať testovanie nižších aj vyšších schopností hráča, konfiguráciu udalosti na ihrisku, testovanie viacerých hráčov a ich kooperácie, umožniť optimalizáciu hľadaním lepších parametrov. V aplikácii je nutná komunikácia agenta so serverom. V implementácii upravili agenta tak, aby prijímal príkazy z vonku. Bolo nutné definovať, čo má agent robiť a ako to vyhodnotiť. Na tu vybrali jazyk Ruby, kde budú uložené skripty v stanovenom tvare, ktoré potom bude agent spúšťať. Ďalej zistili, že je nutné prenášať súbory medzi frameworkom a agentom. Zvolili komunikáciu klient – server, keďže komunikácia má prebiehať aj medzi hráčmi spustenými na viacerých počítačoch. Implementovali open-source TFTP server na agenta a TFTP klient na strane frameworku. Server nastavili aby pri priatí súboru s menom “ruby.exec” bol tento súbor automaticky vykonaný ako Ruby skript. Používateľ frameworku zadáva Ruby skript, v ktorom je definované čo sa má vykonať, časovo závislý test, ktorý určuje, či výsledný test môže byť pozitívny(časová efektivita, napr. nahrávka so zlým smerom nebude nikdy úspešná ), test vypovedajúci, či výsledok akcie bol úspešný. Vyhodnotenie konania spracuje vstupy od používateľa a servera a následne odosiela agentom súbory (XML alebo Ruby skripty so zmenenými parametrami) a skript v Ruby, ktorý sa okamžite vykoná na strane agenta. Zmena súborov má potenciál zaviesť do frameworku princípy umelej inteligencie. Server je schopný logovať priebeh simulácie pomocou S-výrazov(obyčajné reťazce alebo ďalšie s výrazy). Najskôr sa zapíšu informácie o prostredí, potom informácie o stave hry a potom prebieha periodické zapisovanie čiastočných informácii o stave hry. Informácia o prostredí má nasledujúcu štruktúru: ((<EnvironmentInformation>)(<SceneGraphHeader>)(<SceneGraph>)), Informácia o stave hry má podobnú štruktúru ako tá o prostredí a vyzerá nasledovne: ((<GameState>)(<SceneGraphHeader>)(<SceneGraph>)). Hlavička grafu scény obsahuje informácie o kompletnosti grafu scény a jej verzie. Jej štruktúra vyzerá nasledovne: (Name Version Subversion) Príklady a vysvetlenia: (EnvironmentInformation) : ((FieldLength 18)(FieldWidth 12)(FieldHeight 40) (GoalWidth 2.1)(GoalDepth 0.6)(GoalHeight 0.8) (FreeKickDistance 1.3)(WaitBeforeKickOff 2) (AgentRadius 0.4)(BallRadius 0.042)(BallMass 0.026) (RuleGoalPauseTime 3)(RuleKickInPauseTime 1)(RuleHalfTime 300) (play_modes BeforeKickOff KickOff_Left KickOff_Right PlayOn KickIn_Left KickIn_Right corner_kick_left corner_kick_right goal_kick_left goal_kick_right offside_left offside_right GameOver Goal_Left Goal_Right free_kick_left free_kick_right) ) (<GameState>) : ((time 0)(half 1)(score_left 0)(score_right 0)(play_mode 0))

(Name Version Subversion): (RSG 0 1) Name : RSG(plný popis prostredia) alebo RDS(iba inf. o zmenách) Version: hlavná verzia grafu scény, vždy 0 Subversion: vedľajšia verzia grafu scény, vždy 1

(SceneGraph) - predstavuje logickú a priestorovú reprezentáciu scény. Je štruktúrovaný do stromu s koreňom na pozícií <0,0,0> bez rotácie. Každý vrchol v strome obsahuje jedného alebo viac nasledovníkov. Pozícia a rotácia každého nasledovníka je násobkom všetkých transformačných matíc z koreňa až k nasledovníkovi. Každý uzol, ktorý nie je zároveň aj listom je označený skratkou nd. Existuje viacero typov uzlov: základný(napr. (nd BN <contents>)), transformačný(4x4matica napr. (nd TRF (SLT nx ny nz 0 ox oy oz 0 ax ay az 0 Px Py Pz 1 ))), geometrický, ktorý opisuje tvar objektu( zložité, viacero typov).

Parsovanie správ sa skladá z monitorovania a samotného parsovania. Monitorovanie sa stará o príjem informácii počas behu simulácie na porte 3200 vo forme S-výrazov. Parosvacia časť spracuje informácie a vytvorí z nich objektový model, ktorý bude spracovaný časťou zodpovednou za reprezentáciu simulácie.

Skladá sa zo 4 balíčkov: 1. sk.fiit.testframework.parsing – obsahuje triedy zodpovedné za samotné parsovanie informácií, najdôležitejšie, 2. sk.fiit.testframework.parsing.models – obsahuje triedy, ktoré tvoria objektový model Informácií, 3. sk.fiit.testframework.parsing.models.messages – obsahuje triedy, ktoré reprezentujú prijaté správy zo servera, 4. sk.fiit.testframework.parsing.models.nodes – obsahuje triedy, ktoré reprezentujú uzly v grafe scény.

1.1.5 Vytvorené pohyby Vstávanie z brucha - najskôr hráč uvedie všetky kĺby do neutrálnej polohy, okrem ramenných, ktoré pripažíí, následne rozkročí a úplne skrčí nohy, v ďalšej fáze postupne prinožuje a vystiera nohy, čím zároveň vstáva,v koncovej fáze vystierania hráč predpaží ruky, ktoré až do tejto fázy boli pripažené. Vstávanie z chrbta - vystretie tela a pripaženie rúk, rýchle predpaženie a čiastočné rozkročenie, vďaka čomu sa hráč čiastočne posadí, dokončenie rozkročovania a pokrčenia nôh, a zároveň opätovné pripaženie, čím sa hráč, prevráti na brucho a skončí v polohe, ktorú opisuje druhá odrážka v opise vstávania z brucha, následne pohyb prebieha ako vstávanie z brucha. Pád vpred a vzad – pomocné pohyby, hlavne na testovanie, jednoduchá a rýchla zmena uhla kĺbu členku, ktorý je zodpovedný za napnutie a pritiahnutie nártu. Drobná pomalá chôdza dopredu – jeden krok je zložený z dvoch fáz, najskôr hráč prenesie váhu na opornú nohu a druhú nohu zdvihne a mierne vystrie v kolene, čím ju predsunie pred opornú nohu, zároveň rukou na strane opornej nohy pohne v ramene dopredu, nakoniec dostúpi na predsunutú nohu a prenesie na ňu váhu kvôli ďalšiemu kroku. Dĺžka kroku je približne pätina dĺžky hráčovho chodidla. Táto chôdza je veľmi pomalá a jej účelom je predovšetkým presné priblíženie k lopte bez jej odkopnutia. Drobná pomalá chôdza dozadu - mierne odrazenie sa z päty pri predkopnutí nohy, lebo päta sa jemne zachytí o zem, nasleduje mierne zanoženie pri vrátení predkopnutej nohy späť na zem. Dĺžka kroku je približne tretina chodidla. Hráč výrazne predkopáva nohy a mierne poskakuje. Drobčivá rýchla chôdza dopredu - podobá sa drobnej chôdzi dozadu, hráč pri nej mierne nadskakuje. Táto chôdza má rovnaké fázy ako predošlé dve chôdze, odlišuje sa len v hodnotách otočení jednotlivých kĺbov a je pri nej výraznejšie prenášanie váhy na opornú nohu pri kroku. Je určená hlavne na prekonávanie väčších vzdialeností.

Otočenie o 90° - jediné implementované otočenie, aj to úspešné len na 50%, pracuje len s kĺbmi nôh, funguje do oboch strán, fázy: mierne pokrčenie nôh a rúk v inicializačnej fáze pre zvýšenie stability priblížením ťažiska k zemi, prenesenie váhy na opornú nohu a otočenie druhej nohy v bedrovom kĺbe úplne na stranu, prenesenie váhy na otočenú nohu a prinoženie pôvodnej opornej nohy, uvedenie pohybovaných kĺbov do pozície, v ktorej boli na konci inicializačnej fázy pred ďalším pokračovaní. Priamy kop - je jeden z viacerých druhov pohybov, ktoré sme sa rozhodli pre hráča JIM vytvoriť. Ide o kop špicou chodidla pri zapojení bedrového, kolenného kĺbu a členku. Ide o kop, ktorý poslúži na ďaleké prihrávky a kopy na bránu. Viď dokumentáciu androids. Kop do lopty hranou chodidla - v tomto prípade ide o kop do lopty hranou chodidla agenta. Nejde však o kop dopredu, ale do boku, tento kop umožní agentovi nahrávku do strany bez nutnosti zdĺhavo sa nastavovať k lopte, vzhľadom na možnosti a anatómiu agenta nejde o silný kop – na kop možno využiť iba jediný kĺb. Viď dokumentáciu androids. Pád brankára na bok - je jeden z možných spôsobov zabránenia gólu, ktorý je vhodné použiť, ak brankár nestojí v ceste strele na bránu, ale je v bode, z ktorého pri páde na bok pretne svojím telom trajektóriu strely. Pohyb je implementovaný pre ľavú aj pravú stranu. Viď dokumentáciu androids. Prevrátenie na chrbát - Je to pomocný pohyb pre uvedenie brankára do polohy, z ktorej dokáže vstať po tom, čo použil pohyb pád na bok, je implementovaný pre použitie z ľavého aj pravého boku. Pohyb pozostáva z dvoch fáz: v prvej hráč presunie nezaťaženú ruku a nohu za telo a zaťaženú ruku smerom pred telo, čo spôsobí, že sa prevráti na chrbát v druhej fáze pripaží a vráti bedrové kĺby do neutrálneho uhla.

1.1.6 Úpravy v editore pohybov Vytvorili dve úpravy a to úpravu XML exportu pohybov a symetriu pohybov. Prvá menovaná úprava bola nutná, pretože export bol určený pre hráča Sirius, a teda museli vytvoriť export pre hráča JIM. Upravili pôvodnú triedu Xml exportu – XMLExporter. Editor pohybov je napísaný v jazyku C# a na generovanie XML je použitá knižnica System.Xml. Na dosiahnutie nového formátu boli použité metódy WriteStartElement(),WriteEndElement() a WriteAttributeString() triedy XmlTextWriter. Kompletný formát je zachytený pomocou XSD schémy, ktorá sa nachádza v adresári moves hráča JIM(Hlavička, Constants, Low_skills, Phases). V editore pohybov vytvorili políčko, v ktorom volíme, či chceme, aby sa symetrické kĺby pohybovali spoločne (nezávisle, symetrické, zrkadlové). Všetky úpravy ohľadom symetrie kĺbov boli robené v triedach balíka MotionEditor. Ďalej sa pokúsili o implementáciu previazania kĺbov. Nešlo o previazanie symetrických kĺbov, ale napríklad synchronizáciu bedrového kĺbu s kolenným. Narazili však na problémy: editor to nepodporuje, treba implementovať a odladiť zložité výpočty, vizualizácia sa správala neprirodzene pri prehraní pohybu.