Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Méréstechnika és Információs Rendszerek Tanszék
Kóródi Balázs
ROBOTSZIMULÁCIÓS LEÍRÓK AUTOMATIZÁLT LÉTREHOZÁSA ÉS VÉGREHAJTÁSA
KONZULENS
Micskei Zoltán Imre BUDAPEST, 2013
Tartalomjegyzék Budapesti Műszaki és Gazdaságtudományi Egyetem ................................................. 1 Kóródi Balázs .................................................................................................................. 1 Tartalomjegyzék ............................................................................................................. 2 Hallgatói nyilatkozat....................................................................................................... 5 Kóródi Balázs .................................................................................................................. 5 Összefoglaló ..................................................................................................................... 6 Abstract............................................................................................................................ 7 1
2
Bevezetés .................................................................................................................. 8 1.1
A feladat specifikációja .................................................................................... 8
1.2
Motiváció a szimulációs megoldásra ................................................................ 9
1.3
A feladat pontosítása ....................................................................................... 10
Irodalomkutatás .................................................................................................... 12 2.1
Microsoft Robotics Developer Studio ............................................................ 12
2.1.1
A Robotics Developer Studio felépítése ..................................................... 12
2.1.2
Concurrency and Coordination Runtime (CCR) ........................................ 13
2.1.3
Visual Programming Language (VPL) ....................................................... 14
2.1.4
Visual Simulation Environment (VSE) ...................................................... 15
2.1.5
Simulation Programming Language (SPL)................................................. 15
2.2
Visual Simulation Environment...................................................................... 17
2.2.1
Szimulációs környezet komponensei .......................................................... 17
2.2.2
Entitások ..................................................................................................... 17
2.2.3
Szolgáltatások ............................................................................................. 18
2.2.4
A szimulátor indítása .................................................................................. 18
2.2.5
Szimulációs környezet készítése................................................................. 19
2.2.6
A szimulátor használata .............................................................................. 19
2.2.7
Naplózás...................................................................................................... 19
2.3
Modellező eszközök, szabványok ................................................................... 20
2.3.1
Papyrus........................................................................................................ 20
2.3.2
XMI............................................................................................................. 20
2.3.3
EMF ............................................................................................................ 20
2.3.4
UML2.......................................................................................................... 21
2.3.5 3
4
Tervezés ................................................................................................................. 23 3.1
A bejövő modell beolvasása és feldolgozása .................................................. 24
3.2
A modell igények szerinti átalakítása ............................................................. 25
3.3
A modell exportálása a szimulációt leíró nyelven .......................................... 26
3.4
A szimuláció futtatása ..................................................................................... 27
3.5
A szimulációs napló elkészítése ..................................................................... 28
3.6
A példa szimulációkhoz szükséges entitások elkészítése ............................... 29
3.7
Tervezés összefoglalása .................................................................................. 29
Implementáció ....................................................................................................... 31 4.1
6
A bejövő modell beolvasása és feldolgozása .................................................. 31
4.1.1
A szimulációs UML modell elkészítése ..................................................... 31
4.1.2
Az UML modell beolvasása ....................................................................... 32
4.1.3
UML modell feldolgozása .......................................................................... 33
4.1.4
UML és RDS leképzés ................................................................................ 34
4.2
A modell igények szerinti átalakítása ............................................................. 37
4.3
A modell exportálása a szimulációt leíró nyelven .......................................... 38
4.4
A szimuláció futtatása ..................................................................................... 40
4.5
A szimulációs napló elkészítése ..................................................................... 42
4.6
A példa szimulációkhoz szükséges entitások elkészítése ............................... 42
4.6.1
Szegmens .................................................................................................... 42
4.6.2
Raklap ......................................................................................................... 43
4.6.3
Targonca ..................................................................................................... 43
4.7
5
Acceleo ....................................................................................................... 21
Az alkalmazás felépítése ................................................................................. 45
4.7.1
RdsModel .................................................................................................... 45
4.7.2
RdsSimulationHelper .................................................................................. 45
4.7.3
RdsSplGenerator ......................................................................................... 47
Az alkalmazás használata .................................................................................... 48 5.1
Egyszerű felhasználó ...................................................................................... 48
5.2
Alkalmazás fejlesztő ....................................................................................... 50
Tesztelés ................................................................................................................. 53 6.1
T1: Új környezet ............................................................................................. 53
6.2
T2: Hiányzó paraméterek ................................................................................ 53
6.3
T3: Hibás konfiguráció ................................................................................... 53
7
6.4
T4: Hiányzó textúrák és mesh-ek ................................................................... 54
6.5
T5: Naplózás hiánya ....................................................................................... 54
6.6
T6: Egyszerű szimuláció ................................................................................. 54
6.7
T7: Kereszteződések kezelése ........................................................................ 54
6.8
T8: Összetett szimuláció ................................................................................. 55
6.9
Tesztek értékelése ........................................................................................... 55
Összefoglalás.......................................................................................................... 56
Irodalomjegyzék............................................................................................................ 58 Függelék ......................................................................................................................... 59 A melléklet tartalma és leírása .................................................................................... 59
HALLGATÓI NYILATKOZAT Alulírott Kóródi Balázs, szigorló hallgató kijelentem, hogy ezt a szakdolgozatot meg nem engedett segítség nélkül, saját magam készítettem, csak a megadott forrásokat (szakirodalom, eszközök stb.) használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen, a forrás megadásával megjelöltem. Hozzájárulok, hogy a jelen munkám alapadatait (szerző(k), cím, angol és magyar nyelvű tartalmi kivonat, készítés éve, konzulens(ek) neve) a BME VIK nyilvánosan hozzáférhető elektronikus formában, a munka teljes szövegét pedig az egyetem belső hálózatán keresztül (vagy hitelesített felhasználók számára) közzétegye. Kijelentem, hogy a benyújtott munka és annak elektronikus verziója megegyezik. Dékáni engedéllyel titkosított diplomatervek esetén a dolgozat szövege csak 3 év eltelte után válik hozzáférhetővé. Kelt: Budapest, 2013. 05. 24.
...……………………………………………. Kóródi Balázs
Összefoglaló A szakdolgozat feladatommal az R3COP nemzetközi projekt egy részfeladatára kellett megoldást készítenem. A projektben a tanszék tesztelési keretrendszert készít, amely autonóm robotokhoz a környezet és a követelmények modellje alapján automatikusan teszteket generál, majd ezeket szimulációs környezetben futtatja és kiértékeli az eredményeket. A feladatom egy demonstrációs platform elkészítése volt szimulációs példák felépítésére, végrehajtására és naplózására egy potenciális szimulátor platformon a Microsoft Robotics Developer Studion (RDS). Dolgozatomban először bemutatom a szimulátor eszközt, egyszerűbb és összetettebb szimulációk segítségével, majd a megismert komponensek felhasználásával a kidolgozott automatizálásra alkalmas algoritmust a szimulációs leírók generálására és a szimulációk végrehajtására. A kidolgozott módszerre egy konkrét implementációt készítettem, szem előtt tartva az általános és könnyen bővíthető megoldásokat. A felmerült problémákhoz kapcsolódó
szabványos
és
alkalmas
eszközök
előnyeinek
és
hátrányainak
megvizsgálásával az általam legmegfelelőbbnek gondoltakat használtam fel, így a választás az Eclipse környezetre és a hozzá kapcsolódó modellező rendszerekre esett. A feladatot
hat nagyobb egységre bontottam kezdve a bejövő modell
beolvasásával és feldolgozásával amely egy általános UML modell, így azt az RDS specifikus igények szerint át kellett alakítani. A feldolgozás után a szimuláció felépítésére alkalmas nyelvű leírókat exportáltam automatizált mechanizmussal, majd ezeket futtattam a szimulációs környezetben. A szimulációs eredményeket egy elemző alkalmazásnak szeretnénk továbbítani ezért szükség volt a naplózó környezet elkészítésére. A példák futtatásához létrehoztam szükséges entitásokat, ezzel együtt a szimulációkban megjelenő robot mesterséges intelligenciáját. Az általános feldolgozásra törekvés miatt a szimulációs kontextus egyszerűen bővíthető és teszteléseim során az elkészített megoldás az elvártak szerint működött.
Abstract I took part in the R3COP international project with my thesis. Our department creates a testing framework in this project, which focuses on generating tests for autonomous robots taking into account their environment and requirement models. It will additionally execute the simulations in the simulation environment and evaluate the results. My task was to create a demonstration platform for building simulation examples, execute them and log the necessary information with a potential simulation environment, the Microsoft Robotics Developer Studio (RDS). During this semester I learnt to use this robot simulation tool and created simple and relatively complex simulation examples. With the capable tools I elaborated an algorithm capable of automatization to generate and execute simulations. With this knowledge I developed an application with the principles of generalization and easy context extending. Examining the advantages and disadvantages of the capable tools the choice fell on the Eclipse environment and the related modeling tools. After the study and preparation of these tools I built these tools into my solution. A szimulációs eredményeket egy elemző alkalmazásnak szeretnénk továbbítani ezért szükség volt a naplózó környezet elkészítésére. A példák futtatásához létrehoztam szükséges entitásokat, ezzel együtt a szimulációkban megjelenő robot
mesterséges
intelligenciáját. The task is divided into six major parts starts with the parsing and processing of the incoming model which is a simple UML model so modification was required to satisfy the RDS specific needs. After the processing method I exported the model into the simulation descriptors with an automatized mechanic and executed it in the simulation environment. We want to transmit the simulation result to an analyzer application, therefore it was necessary to create a logging enviroment. To run the examples I have created the necessary entites together with the robot artificial intelligence. Due to the generalized processing method the simulation context can be easily extended and during testing, the created solution worked as expected.
7
1 Bevezetés Ebben a fejezetben kontextusba helyezem a feladatot annak specifikációjával és a szimulációs leírók automatizált generálásának motivációjával, majd részletesen bemutatom annak értelmezését felkészülve a megoldás kidolgozásának megértésére.
1.1 A feladat specifikációja A szakdolgozat feladatommal az R3-COP nemzetközi projekt egy részfeladatára kellett kidolgoznom egy megoldást. Az R3-COP projektben a tanszék tesztelési keretrendszert készít, amely autonóm rendszerekhez (autonóm robotok) a környezet és a követelmények modellje alapján automatikus teszteket generál, majd ezeket egy szimulátor környezetben végrehajtja, az eredményeket naplózza, végül kiértékeli. Az R3-COP folyamatábrája az alábbi ábrán látható (1. ábra).
1. ábra: Tesztelési keretrendszer áttekintése [1]
A feladatom egy demonstrációs platform készítése, szimulációs példák felépítése, végrehajtása és naplózása egy potenciális szimulátor platformon amely a Microsoft Robotics Developer Studio (MS RDS/RDS). Egy ilyen szimulációra példa, ha egy robotot elhelyezünk egy olyan környezetben amiben más objektumok (asztal, székek, falak) vannak és a robotnak autonóm módon el kell jutnia A-ból B pontba úgy, hogy a többi objektumot kikerülje. A naplózás során feljegyzi, hogy sikerült-e eljutnia B pontba és eközben ütközött-e más objektumokkal. Az ilyen szimulációs példákra a későbbiekben szituációként hivatkozom.
8
Kidolgoztam egy módszert, amely képes ilyen szituációk létrehozására, majd erre a módszerre megvalósítottam egy automatizált megoldást, azaz valamilyen előre rögzített típusú, és formátumú bemenetre automatizált módon létre kell hoznom a szituáció leírását a Robotics Developer Studio nyelvén, valamint a megoldásnak futtatnia és naplóznia kell a szimulációt. A folyamatábráról a Test execution részt kellett megvalósítanom. Ahogy az ábrán is látszik, teszt adatokat, modelleket kapok valamilyen előre rögzített formában, amely a szimulációs világot írja le, és az objektumok valamilyen hierarchia szerint el vannak helyezve ebben a szimulációs világban. A feladat ezt a szimulációs világ leírást automatikusan az RDS nyelvére lefordítani és ezzel felépíteni az adott szimulációt. A szimuláció futása során a robot egyes érzékelőiből vagy a környezetből nyerhetünk naplózható információkat, amely az alkalmazás kimenete lesz, ezt az ábrán a Test trace jelöli.
1.2 Motiváció a szimulációs megoldásra A valós életben számos kihívással kell megbirkózni robot rendszerek fejlesztésekor, ilyenek például a drága és nehezen beszerezhető hardver, amelynek hibaelhárítása igen nehéz és nagy szaktudást igényel, valamint a konkurens rendszerek használata szintén problémákat vet fel. A szimuláció előnyei még az alacsony belépési korlát, ami nemcsak az anyagi oldalon mutatkozik meg, hanem a szaktudást tekintve is, így a szimulációs megoldások jól használhatóak tanulási és tanítási célokra. Szimulációs rendszerekkel gazdaságosan lehet prototípusokat létrehozni, valamint tanuló robotok előkonfigurálását is végezhetjük szimulációs környezetben. A szimulációs megoldások hátrányai között meg kell említeni, hogy a valós környezet kiszámíthatatlan, komplex és zajos amit nehezen lehet szimulálni. A hiányos és pontatlan modelleket nehéz pontosan modellezni, és ezek hangolása elég időigényes. Az előnyöket és a hátrányokat figyelembe véve a tervező felelőssége az adott feladathoz eldönteni, hogy melyik a jobb megoldás. A robotok és egyéb autonóm rendszerek egyre nagyobb elterjedésével a hozzájuk készített vezérlő programok fejlesztése és tesztelése egyre kritikusabb feladat. Szerencsére egyre valósághűbb, és egyre pontosabb szimulátorok állnak a fejlesztők rendelkezésére.
9
A fejlesztés és tesztelés során az adott szimulátor szintaxisával fel kell építeni a szimulációs leíró fájlokat, valamint futtatni, és elemezni kell őket, ami idő- és erőforrásigényes feladat, és a szimulátor mély ismeretét igényli. Ha a szimulálandó környezetek jól definiáljuk, majd ezeket a leírásokat leképezzük a szimulációs környezetre, és ott automatikusan futtatjuk és naplózzuk a fontos adatokat, akkor a feladatot lerövidítjük a szimulálandó környezet definiálásának és az automatizált mechanizmus futtatásának idejére.
1.3 A feladat pontosítása Az előzőekben leírt feladat a felhasználandó környezetek megismerése után öt részből tevődik össze. A feladat bemeneteként egy szabványos módon leírt modellel megadott szimulációs leírást kap, amelyet be kell olvasni és feldolgozni, ezt a modellt a RDS környezet által előírt formába át kell alakítani, majd a RDS által feldolgozandó szimulációs leíró nyelvbe exportálni. Az utolsó lépések a már előállt szimulációs leíró futtatása, és a futás során keletkező fontos adatok fájlba naplózása. Ez a naplófájl lesz a feladatom kimenete, amit tovább lehet küldeni egy elemzőnek, aki értékeli a szimuláció eredményeit. A szimulációban tipikusan egy vagy több robot interakcióját akarjuk vizsgálni egymással és a környezettel. A szimulációk tehát úgy épülnek fel, hogy egy vagy több robotot elhelyezünk a környezetben (pl. raktárhelyiségben), majd a robotoknak adunk egy feladatot, amelyet megpróbálnak elvégezni (pl. menjen A pontból B pontba úgy, hogy ne ütközzön semmivel). A robotjainknak vannak érzékelőik, ezeknek az állapotát szeretnénk naplózni (pl. sikerült-e a robotnak eljutnia B pontba, és eközben ütközött-e más objektumokkal). A feladat nem tér ki a robot mesterséges intelligenciájának aprólékos kidolgozására, és a szimulációs objektumok leírására, hanem a fő feladat az automatizált futtatási keretrendszer megvalósítása. A feladathoz kapcsolódó tesztesetek létrehozásához és a megoldás használhatóságának ellenőrzéséhez természetesen létre kell hoznom különböző szimulációs objektumokat és robot példányokat, amelyeket alap szintű intelligenciával el kell látni. A feladat megoldása során igyekszem az R3-COP projekt egy alkalmazási mintapéldájában rögzített metamodelleket és elemkészletet használni. A szituációkban
10
megjelenő objektumok és viselkedések a mintapélda által definiált metamodelljének főbb részletei az alábbi ábrán látható (2. ábra).
2. ábra: R3COP UML metamodel
Ahogy az ábrán is látható, a különböző szituációkban mozgó és nem mozgó elemek jelennek meg. A mintapéldában autonóm targonca robotokhoz szeretnénk tesztelő keretrendszert létrehozni. Ehhez kapcsolódóan mozgó objektum például a targonca, és stacionárius objektum a raklap. A targonca úgynevezett szegmenseken mozog, amelyek a padlón egy hálózatot hoznak létre, a targonca érzékeli és követi a szegmensek által kialakított pályát. A targoncának a feladata a raklapok felvétele, pakolása ás szállítása a szegmenseken. Ha valamilyen zavaró tényező ér a mozgó targonca közelébe, például egy másik targonca, vagy ember akkor azt a robot érzékeli és reagál rá.
11
2 Irodalomkutatás A feladat megoldásának kulcskérdése a megfelelő eszközök megtalálása és megismerése, ehhez a irodalomkutatásom során megpróbáltam a legalkalmasabbakat kiválasztani
a
hasonló
célt
szolgáló
eszközök
előnyeinek
és
hátrányainak
megvizsgálásával.
2.1 Microsoft Robotics Developer Studio Az RDS [2] indítvány a Microsoft-tól egy olyan eszköztár kialakítására, amivel beléphet a robot rendszerek fejlesztésébe. Az RDS felületet nyújt mind a robot rendszerek tervezéséhez, fejlesztéséhez és teszteléséhez egyaránt egy virtuális szimulációs környezetben.
2.1.1 A Robotics Developer Studio felépítése Az RDS [3] alapvetően a Microsoft .NET eszközkészletére épült. Programozási támogatást nyújt a C#, VB és VPL (Visual Programming Language) nyelvekhez. A rendszer használható mind szimulációs környezetben, mind valós robot hardveren. Felépítésének fő komponensei az alábbi ábrán láthatók (3. ábra).
3. ábra: Az RDS felépítése, fő komponensei [4]
12
A DSS (Decentralized Software Services) szerkezetet biztosít a szolgáltatások (service) létrehozására, ezekből a szolgáltatásokból épül fel az alkalmazás. Célja összekapcsolni az egyszerűséget és a robosztusságot. A szolgáltatások DSS protokollt használnak a kommunikációhoz. Ez a kommunikáció állapot orientált módon működik, a SOAP (Simple Object Acces Protocol) modellhez hasonló. A szolgáltatásokat az alkalmazáshoz tartozó jegyzéken (manifest) keresztül konfigurálhatjuk. A manifest mondja meg, hogy milyen szolgáltatásokat kell indítanunk. A manifesteket a DssHost program dolgozza fel az alkalmazás indításakor.
2.1.2 Concurrency and Coordination Runtime (CCR) A CCR biztosítja az alapvető konkurencia igényeket és a kommunikációt, szeparálja a komponenseket egymástól, így azok csak üzeneteken keresztül tudnak egymással kommunikálni. Ez a komponens felelős az üzenetek közti koordinációért, a komplex hibakezelésért és az aszinkron programozásért. Kliens-szerver architektúra szerű a működése. Az üzenetek (messages) portokhoz kerülnek, majd a Receiverek kezelik a portokra érkezett üzeneteket. Az Arbiterek felelősek az üzenetek koordinációjáért és a szinkronizációjáért. A Dispatcher indítja el magát a feladatot. A működése az alábbi ábrán látható (4. ábra).
4. ábra: A CCR működése [4]
13
2.1.3 Visual Programming Language (VPL) A VPL [5] egy alkalmazás fejlesztő környezet és nyelv, ami grafikus adatfolyam alapú programozási modellt használ. Jól használható változatos konkurens és megosztott folyamatok fejlesztésére. A VPL elemei a cselekvések és a közöttük lévő kapcsolatok. A cselekvés valamilyen műveletet valósít meg a bemenete és a kimenete között. Ez lehet valamilyen adatfolyam vagy feldolgozó funkció, de sokféle saját cselekvés is definiálható. A cselekvések egymással üzenetekkel kommunikálnak és egy cselekvés lehet akár más cselekvés konstrukciója is, így hierarchikus felépítést biztosít. VPL használatával lehetőségünk van robotok intelligencia fejlesztésére. A VPL fejlesztői környezet az RDS-sel együtt települ a számítógépre. Az alábbi ábrán látható a VPL fejlesztői környezet felhasználói felülete (5. ábra).
5. ábra: VPL fejlesztői környezet felhasználói felülete
VPL-ben az adatok típusosak, a típusok más programozási nyelvben megismert analógiát követik, pl. int, string, bool. Az adatokat a cselekvésekkel manipulálhatjuk és a cselekvések között az összekötő nyilak felé utaznak az adatok, ezek a kapcsolatok a két cselekvés között lévő üzeneteket reprezentálja. A cselekvések lehetnek egyszerű if, switch, while típusú szerkezetek vagy szolgáltatások. Az elemeket a bal oldali 14
eszköztárból érhetjük el és ezeket drag-and-drop módszerrel helyezhetjük fel. Lehetőségünk van saját cselekvés definiálására is, amelyhez meg kell adnunk a bemeneti és kimeneti adatokat, és a rajtuk végzendő műveleteket. A kimenet lehet eredményt vagy figyelmeztetést küldő kimenet. A figyelmeztetés olyan speciális kimenet, amely bizonyos esemény bekövetkezésekor küldi tovább az adatot, ilyenek például a robot szenzorok. VPL-t használva könnyen el tudjuk érni a robot szenzorainak adatait, csak a szükséges cselekvést kell felhelyeznünk és az adatok rendelkezésre állnak további módosításra. Az adatok vizsgálatára feltételeket szabhatunk vagy akár naplózhatjuk fájlba vagy konzolra a megfelelő cselekvés használatával.
2.1.4 Visual Simulation Environment (VSE) A VSE [6] a szimulációs környezet, aminek a célja a virtuális környezet létrehozása realisztikus fizikával és a legkorszerűbb renderelési technológiákkal. A szimulációs környezetben megjelenő modellek és mesh-ek a legtöbb modellező programból importálhatók. A feladatom a szimulációhoz kapcsolódik, így a szimulációs környezetet a következő fejezetben részletesen ismertetem. Az alábbi ábrán a VSE környezet felhasználói felülete látható (6. ábra).
6. ábra: VSE felhasználói felülete
2.1.5 Simulation Programming Language (SPL) Az SPL [7] már nem RDS komponens, viszont felhasználtam a megoldásomban. Az SPL egy a RDS-hez kapcsolódó szkript környezet, ami a virtuális világ felépítéséért 15
felelős. Ebben a szkriptben entitásokat és szolgáltatásokat egyszerűen és átláthatóan definiálhatunk, így nem kell bonyolult XML állományokat szerkeszteni. Az SPL létrehozásának motivációja az volt, hogy létrehozzanak egy nyelvet, amely képes a VPL grafikus programozásával létrehozott utasítások végrehajtására, de ezt grafikus programozással ellentétben szöveges állományok szerkesztésével. Az SPL szkript készítéséhez és futtatásához letölthető fejlesztői környezet, amely az alábbi ábrán látható (7. ábra).
7. ábra: SPL fejlesztő és futtató környezet
Az SPL fejlesztő környezet használata könnyen elsajátítható. Az SPL szkriptben entitásokat definiálhatunk és azok leíróit és állapotait állíthatjuk be, valamint ezeket módosíthatjuk. A felület bal alsó részén látható az összes használható entitás és azok paraméterei. Ezekre kattintva az eszköz beilleszti a kód blokkba az adott entitás és azok paramétereinek definícióját. Az entitások állapotának módosítására más programozási nyelvekből megismert szerkezetek használhatók, pl. if, while, switch. A szkript mentése létrehozza a megfelelő állományokat, amelyre az RDS-nek szüksége van, és ezután futtathatjuk a szkriptet, ami elindítja a szimulációs környezetet.
16
2.2 Visual Simulation Environment Mivel a feladatban főként a szimulációs környezettel foglalkozom így ebben a fejezetben a többi komponensnél részletesebben bemutatom annak elemeit és használatát.
2.2.1 Szimulációs környezet komponensei A szimulációs környezetet a következő négy komponensre bontható:
Simulation engine service: Az objektumok rendereléséért és a szimulációs idő menedzseléséért felelős a fizikai motor számára. A szimulációs világ állapotait kezeli, és szolgáltatás orientált front-endet nyújt a szimulációhoz. Managed physics engine wrapper: Elválasztja a felhasználót az alsó API rétegtől és tömörebb, menedzselt interfészt nyújt. A fizikai API közvetlen is hozzáférhető, de a szimulációs motor szolgáltatásai leegyszerűsítik a hibakeresést, ellenőrzést stb. Nvidia Physx technology: Hardveres gyorsítást biztosít Nvidia Physx technológiát támogató videókártyáknak. Entities: Hardver és fizikai objektumok a szimulációs világban.
2.2.2 Entitások Az RDS-ben (Kyle Johns, Trevor Taylor: Professional Microsoft Robotics Developer Studio, ISBN: 978-0-470-14107-6, 2008) entitások a szimulációs világban található objektumokat reprezentálják. Entitás lehet bármi, aminek vannak fizikai tulajdonságai (pl. bútor, ég és föld vagy robot komponensek). Az entitásoknak leíróik és állapotaik vannak, ezeket lehet módosítani a szimulátorból, XML-ből vagy akár .NETből is. Az entitások sokszor valamilyen hardvert reprezentálnak, pl. motor vagy szenzorok. A szolgáltatások kezelhetnek szimulációs entitásokat vagy akár igazi hardver eszközöket, ehhez pusztán csak minimális átalakítás szükséges a futtatásért felelős állományban. Az entitás leírók és állapotok az alábbi táblázatban láthatók (1. táblázat). Név EntityState ServiceContract InitError Flags Parent/Joint Position Rotation Meshes MeshRotation
Leírás Entitás állapot Kapcsolódó entitások Inicializálási hibák Renderelő feltételek Több komponens összetétele X,Y,Z [m] Euler szög [deg] Az entitáshoz rendelt Mesh A Mesh elforgatása 17
MeshTranslation MeshScale Shapes
A Mesh eltolása Mesh skálázása Egyszerű formák 1. táblázat Entitások leírók és állapotok
A joint egy speciális entitás, amely olyan összetett objektum, amiben az entitások joint-okon keresztül kapcsolódnak egymáshoz. A joint-oknak 6 szabadsági fokuk van, 3 lineáris és 3 forgási. Minden szabadsági fok zárolható. A joint-ok szolgáltatásokon keresztül irányíthatók. Az RDS-ben lehetőségünk van új entitások definiálására is, ehhez új entity osztályt kell implementálnunk.
2.2.3 Szolgáltatások A szolgáltatások az entitásokhoz társulnak és a világ módosítását végzik. Felelősségük a robot komponensek, pl. motorok, irányítása és a szenzorok adatgyűjtése. A szolgáltatások adatmanipulációjával tehát a robothoz intelligencia rendelhető. A szolgáltatások működhetnek automatikusan vagy a felhasználótól származó külső parancsok használatával. Külső parancsokat egy DashBoard nevű alkalmazással adhatunk a szolgáltatásoknak. Az eszközzel először csatlakoznunk kell egy szolgáltatáshoz, a szolgáltatások az 50000 feletti portokon érhetők el. Ha csatlakoztunk a szolgáltatáshoz, akkor adatokat küldhetünk, vagy fogadhatunk a szolgáltatásunktól. A szolgáltatásainkat, mint ahogy az összes RDS komponenst böngészőből is el tudjuk érni, ahol XML formátumban visszajelzést kapunk a szolgáltatások aktuális állapotáról.
2.2.4 A szimulátor indítása Az RDS [9] szimulátor indítására több lehetőségünk van, ezt figyelembe kell vennünk, ha automatizált architektúrát akarunk készíteni szituációk szimulálására. A szimulátor indításának alapvető módjai a Start menüből és a Control panelből való hozzáférés, ezen kívül a szimulátor indítható manifest fájlból vagy szolgáltatásból is. A manifest egy konfigurációs XML állomány, ami a szimuláció és a szolgáltatások indításáért felelős.
18
2.2.5 Szimulációs környezet készítése Egy szimuláció két állományból épül fel: a manifestből és egy állapotot definiáló fájlból. A manifest a szolgáltatások és a szimulátor indításáért felelős XML állomány, az állapot fájl pedig a szimulátor állapotát és az egyes entitások állapotát nyilvántartó XML állomány. Egy szimulációs környezet felépítését végezhetjük magából a szimulátorból is, itt copy-paste és drag-and-drop módszerekkel emelhetünk be entitásokat, vagy másolhatunk át egy másik kész szimulációból. Szimulációt felépíthetünk a fentebb említett XML fájlok szerkesztésével is, vagy akár készíthetünk sémát egy másik szolgáltatásból is. A feladat megoldásához mindenképpen egy automatizálható megoldást célszerű választani, így bár a szerkesztő felhasználói felülete letisztult és könnyen használható, mégis az utóbbi két eljárást vizsgáltam mélyebben.
2.2.6 A szimulátor használata A szimulációs környezetben a WSAD gombokkal mozoghatunk előre, hátra, jobbra és balra, valamint a QE gombokkal felfelé és lefelé. Az egérrel mozgathatjuk a kamerát. A szimulátor többféle módon képes renderelni (pl. teljes vizuális renderelés, csak az objektum meshek vagy csak a befoglaló objektumok renderelése, vagy bármilyen kombinált technika). A szimulátorban gombnyomásra lehetőség van a kamerák váltására és a fizika ki-be kapcsolására. Az F5 billentyű megnyomásával érhetjük el a szerkesztő módot, itt módosíthatjuk a szimulációs környezetet és az entitások állapotait.
2.2.7 Naplózás Az RDS-ben a naplózásra két lehetőségünk van. Az egyik esetben saját naplózót készítünk, ezzel lehetőségünk van bármely entitás bármely paraméterének kiíratására, viszont ezt csak akkor használhatjuk, ha hozzáférünk az adott eszköz, robotkomponens forrásához. A másik lehetőség a beépített naplózás használata. Az egyes szolgáltatások pillanatnyi állapotát elérhetjük egy böngésző segítségével az 50000-es portoktól, de megkérhetjük a rendszert, hogy az egész szimulációról készítsen egy naplófájlt. Ez a funkció a szolgáltatás manipulációs panelról érhető el és nem konfigurálható. Kimenetként egy tagolatlan XML fájlt kapunk a robotkomponens adatairól adott időközönként időbélyeggel ellátva. 19
2.3 Modellező eszközök, szabványok A Robotics Developer Studio környezetet megismerve a szimulációs leírók automatizált generálásához kiválasztott eszközök ebben a fejezetben kerülnek bemutatásra.
2.3.1 Papyrus A Papyrus [10] az Eclipse [11] környezetbe épülő nyílt forrású UML 2 modellező eszköz. A Papyrus segítségével az UML szabvány széles palettájú elemkészletét felhasználva diagramokat készíthetünk, valamint fejlett támogatást nyújt az UML profilokhoz. Az elkészített UML diagramok elemei a szabványos, exportált modell segítségével más eszközökben is felhasználhatók. Az Papyrus használható önálló eszközként, vagy Eclipse pluginként. Én az utóbbit választottam más Eclipse eszközökkel való könnyebb integrálhatóság miatt. A Papyrus segítségével UML diagramokat készítek egy szimuláció felépítéséhez, amelyeket a XMI formában fájlba lehet exportálni.
2.3.2 XMI Az XMI [12] hivatalos OMG specifikációs XML szabvány a modellező eszközök közötti kommunikációhoz. XML szabványként könnyen olvasható és bármely böngészőben megjeleníthető, más eszközök által olvasható és XML-ként menthető bármilyen speciális eszköz, vagy fordító nélkül. Az XMI verziószáma nincs kapcsolatban az UML verziószámmal.
2.3.3 EMF Az Eclipse EMF [13] adatmodellek készítéséért és használatért felelős, A modell leírására az EMF is XMI-t használ. Készíthetünk vele metamodelleket és ezeknek konkrét modell példányait. Az Eclipse-be épülő EMF plugin-nal modelleket szerkeszthetünk, majd abból java osztályokat generálhatunk. Az EMF metamodell részei az Ecore modell és a Genmodel. Előbbi tartalmazza a szükséges információkat a létrehozott modell osztályokról, utóbbi pedig a kódgeneráláshoz használható. Az Ecore metamodell elemei az alábbi táblázatban (2. táblázat) láthatók amelyben észrevehető, hogy az elemek hierachikusan épülnek fel.
20
Név
Leírás
EClass
Egy osztályt reprezentál, nulla vagy több attribútummal és referenciával.
EAttribute
Attribútumot reprezentál, amelynek neve és típusa van.
EReference
Kapcsolatot reprezentál két osztály között, ez lehet tartalmazás vagy referencia. Egy attribútum típusát reprezentálja, pl float, int.
EDataType
2. táblázat Ecore metamodell elemei [13]
Az EMF modell használatának sok előnye van, többek között megannyi eszköz által
használt
szabvány
szerinti
generált
kódot
kapunk,
amelyet
bármikor
újragenerálhatunk a modell változása miatt. A modellt könnyen elszeparálhatjuk az alkalmazás logikától és felhasználhatjuk a generált Factory osztályokkal.
2.3.4 UML2 Az Eclipse UML2 [14] eszközök UML modellek és diagramok készítését, megnyitását és módosítását támogatják. Használatával olyan interfész kapunk, amely segítségével
egyszerűen
beolvashatunk
UML
diagramokat
és
az
elemein
szisztematikusan hajthatunk végre funkciókat azok tulajdonságait figyelembe véve. Az UML2 plugin telepítéséhez szükséges az Eclipse és az EMF. Az eszközt a Papyrus-ban készített UML modellek beolvasásához és feldolgozásához használom, amelyet a Papyrus XMI formában exportál.
2.3.5 Acceleo Az Acceleo [15] az Eclipse-be épülő szöveggeneráló eszköz amellyel az adott modell példányokból szöveget, kódot generálhatunk a metamodell elemeinek és tulajdonságainak megfelelő használatával. Tag-eket adhatunk meg a dinamikus szöveg beillesztésére például a programozási nyelvekben is használt if vagy for tag-ekkel a számunkra megfelelő elemek paramétereit válogathatjuk ki.
21
Az eszköz használatával az elkészített modellekről könnyen szöveges reprezentációt készíthetünk például XML vagy webszolgátlatás leírót. Az Acceleo-t a belső modellemből exportált RDS szimulációs kód generálásához használtam fel.
22
3 Tervezés A feladat megoldásának kulcskérdése a megfelelő eszközök megkeresése és megismerése. A megoldást hat nagyobb egységre bontottam:
A bejövő modell beolvasása és feldolgozása.
A modell igények szerinti átalakítása.
A modell exportálása a szimulációt leíró nyelven.
A szimuláció futtatása.
A szimulációs napló elkészítése.
A példa szimulációkhoz szükséges entitások elkészítése.
Az alkalmazás főbb tervezési megfontolásait a következő részekben fejtem ki. Az elkészítendő szoftver magas szintű aktivitás diagramja az alábbi ábrán látható (8. ábra).
8. ábra: Az alkalmazás magas szintű aktivitás diagramja
23
3.1 A bejövő modell beolvasása és feldolgozása A bejövő modell a szimulációnak egy állapotát, a szimulációs színteret kell hogy leírja. Elvárjuk, hogy a szimulációs színtér leírása és az RDS [16] szimulációs leírói nagyrészt összhangban legyenek, egyébként nem lenne értelme az RDS bevezetésének és használatának. A modellben tehát valamilyen módon egyértelműen el kell legyenek helyezve az objektumok, és meg kell legyen adva az objektumok között lévő kapcsolat. Például a szegmensek konkrét megadással (pozícióval) el vannak helyezve a térben, a robotok pedig a szegmenseken mozognak. A bejövő modell megállapodás szerint egy UML modell, amelyben az objektumokat példányok
reprezentálják, a köztük lévő kapcsolatokat linkek és az
objektumok leírására az osztály attribútumait használjuk. Az UML modell felépítését UML modellező segítéségével szeretnénk végezni, a felhasználóbarát és gyors munka céljából. A megoldást törekszem a szabványok szerint elkészíteni, így a cél az, hogy az alkalmazás bemeneti szimulációs modell leíróját a legtöbb modellezővel el lehessen készíteni. Szerencsére a legtöbb UML modellező alkalmazás tud szabványos XMI formába exportálni. Az XMI beolvasásának és feldolgozásának megírása nehéz és időigényes feladat, de mivel ez szabványos UML leíró ezért az XMI feldolgozó API-k kutatásával foglalkoztam. .NET-es vonalon indultam el amely az RDS .NET-es interfészei miatt tűnt jó választásnak, viszont végül az Eclipse UML2 plugint [17] választottam. A döntés okai a következők:
Az XMI verziók sémája között elég nagy különbség van, és a talált .NET-es feldolgozók viszonylag régi XMI verziókat támogatnak. A régebbi XMI specifikációk a kutatásom szerint még nem támogatták a példánydiagramok létrehozását, csak osztálydiagramokét. Az egyes XMI feldolgozók általában valamely modellező eszközhöz készültek, és csak annak az egy eszköznek az exportált XMI-ját tudják beolvasni. A többi eszköz által exportált fájlokat nem találják érvényes leírásnak. Az UML2 plugin-nal lehetőség van UML példány diagramokat is készíteni. A MOF szabványnak megfelelve más modellekhez kapcsolódó eszközökkel kompatibilis, amely például a szimulációs kód generálásánál segítséget jelenthet. Az UML2 plugin választásával eszközök tekintetében az Eclipse [18] környezet
eszközeit részesítettem előnyben a további feladatok megoldására. Az Eclipse UML
24
modellezéshez a Papyrus-t nyújtja, így az alkalmazás bemenő modellje Papyrus UML modellezővel készített .uml kiterjesztésű XMI-ban leírt UML modell. A Papyrus UML modellek alapja a diagram. Létrehozhatunk több, az UML által definiált diagram típust, melyekre a palettáról az elvárt UML metamodell elemek közül válogathatunk az osztály metaszint létrehozásához. Ilyenek például az osztály, attribútum, asszociáció. Az objektum metaszinthez a Papyrus az InstanceSpecificationöket nyújtja. Egy adott osztálydiagramon ezeket elhelyezhetjük, és specifikálhatjuk a már létező osztályokból. Az exportált modellt az UML2 plugin funkcióival beolvasom, majd feldolgozom. A feldolgozás az UML objektumokként megadott modellből egy saját belső modell előállítását jelenti, amelyet a későbbi lépésekben könnyen lehet használni, és módosítani. Ezt a belső modellt az RDS specifikus igényeknek megfelelően hoztam létre. A más eszközökkel való könnyű integrálhatóság miatt ez egy szabványos Ecore modell lett.
3.2 A modell igények szerinti átalakítása Az alkalmazás bemeneti UML modelljét a felhasználó állítja össze a Papyrus modellező segítségével. A modell létrehozásánál figyelembe veszi az előre rögzített szabályokat, és a rendelkezésre álló elemkészletet. Az R3-COP mintapéldában definiálva van, hogy a tesztesetekben milyen objektumok lehetnek és azok milyen kapcsolatban vannak egymással. Például, hogy a robotok a szegmenseken mozognak, vagy ha a mozgó robothoz túl közel kerül valami, akkor megáll, vagy kikerüli. Ezeknek egy része a robot belső működéséhez kapcsolódik, például hogy hogyan reagál más objektumok közeledésére, de egy másik része a virtuális világ, vagy szimuláció felépítésénél is érdekes lehet. Ilyen például az, hogy egyik objektum a másik objektumon van, például a targoncák és a raklapok szegmenseken vannak, amelyet a kényelmes felhasználás miatt egy egyszerű UML asszociációval szeretnénk megadni. Ilyenkor az egyik objektum pozícióját megkapja a másik objektum. Ez olyan tudás, amely feldolgozásához az alkalmazásnak ismernie kell az adott asszociáció jelentését. Egy másik ok amiért szükség van a modell átalakítására, az a modell RDS specifikus jellemzői. Előfordulhatnak olyan igények, amelyekre szükség van a RDS
25
környezet használata miatt, de nem szeretnénk azt, hogy erre a felhasználónak oda kelljen figyelni a szimuláció felépítése során, mert ugyanazt egy másik környezetben esetleg máshogy kellene használni. Emiatt a RDS specifikus igényeket az alkalmazásnak ismernie kell, és aszerint átalakítani a bejövő modellt, így a bejövő UML modell általánosan használható maradhat több környezethez is. Ilyen specifikus jellemző lehet például a RDS által használt bal sodrású koordinátarendszer, amely problémát jelenthet abból a szempontból, hogy a gyakorlatban leginkább jobb sodrású rendszert használnak. Az alkalmazásnak tehát kezelnie kell ezt az objektumok elhelyezésénél és a szükséges eltolásoknál és forgatásoknál. Az alkalmazást célszerűen úgy kell tervezni, hogy könnyen bővíthető legyen új objektumokkal az alkalmazás módosítása nélkül, például ha egy új típusú robotot szeretnénk felvenni. Az alkalmazás így két főbb részre bomlik, egy általános és könnyen bővíthető részre, ilyen például egy új objektum felvétele, és egy kevésbé könnyen módosítható belső tudásra, amely fel van készítve a RDS specifikus jellemzőkre.
3.3 A modell exportálása a szimulációt leíró nyelven A modellt a szimulációs környezet által feldolgozható nyelven kell exportálni. Az RDS többféle lehetőséget nyújt egy szimulációs világ leírására:
Használhatunk natív .NET-es megadást, ami a Robotics Developer Studio-nak egy mély ismeretét és sok tapasztalatot igényel. Egy másik forma a szimulációt leíró viszonylag nehezen átlátható XML felépítése és módosítása. Harmadik a VPL grafikus programozás, amelyben a .NET-es objektumokat és metódusokat használhatjuk egy a .NET-es megadáshoz képest egyszerűbb, és a konkurrens működést átláthatóbb módon. Másik lehetőség az SPL szkript környezet, amely a VPL-el ellentétben a szimulációt nem grafikusan, hanem szöveges formában definiálhatjuk. A szimuláció leírójának generálásához az SPL a legkézenfekvőbb választás az
egyszerű és tömör formája, és a könnyű automatikus generálhatósága miatt. Egy SPL leírás formáját tekintve két részre bomlik. Az első az objektumok, vagy entitások definíciója, vagyis a virtuális világban elhelyezéséért, a második pedig az objektumok viselkedésének leírásáért felelős.
26
A viselkedés leírásában az első részben megadott entitásokhoz kapcsolódó logikát, például mozgását adhatjuk meg. Itt már használhatunk változókat, és a programozási nyelveknél megszokott alap adatszerkezeteket, ciklusokat és feltételeket. A szöveges szkript generálása viszonylag bonyolult feladat. Statikus és dinamikusan generálódott szövegeket kell az elvárt szintaktika szerint a megfelelő helyekre beszúrni, emiatt egy szabványos szöveg generáló eszközt használtam fel. Az Acceleo-t [19] amely egy Eclipse plugin amely a MOF szabványt követő szöveggeneráló eszköz. Használatával az előző lépésekben előállított Ecore modellből az Acceleo szintaktikájával az elvárt formájú kimenetet lehet generálni a modell bejárásával. Az így előállt SPL kód létrehozásával ez volt az utolsó lépés a RDS által feldolgozható szimulációs leíró generálásához. A következő két lépés az így előállt szimuláció futtatása és naplózása.
3.4 A szimuláció futtatása A szimuláció futtatását a RDS végzi, amihez két dologra van szüksége:
A szolgáltatások és a szimulátor indításáért felelős manifest. A szimulációs világ állapotának definíciója. Ha ez a két leíró a rendelkezésre áll, akkor a szimulátor program megfelelő
paraméterezésével elindítható a szimulációs környezet, amely a megadott szimulációt futtatja. A manifestet előre létrehoztam, amely a szimulációs környezet beállítását végzi, és meghívja egy SPL fájl beolvasását végző funkciót. Ez az SPL fájl felelős a szimulációs világ állapotának, és a szükséges szolgáltatásoknak a létrehozásáért. A futtatáshoz kapcsolódik néhány nehézség amit meg kell oldania a szimulációt automatizáló alkalmazásnak. Az egyik ilyen, hogy a szimulációs leírókat nem lehet akárhonnan futtatni, csak a RDS telepítési helyén lévő megfelelő mappákból, vagyis először az alkalmazásnak ide kell másolnia a szükséges fájlokat, és csak ezután futtathatja a szimulációt. Ehhez tudni kell, hogy hova telepítettük a RDS-t, és hogy mely fájlokat szeretnénk a megfelelő helyre másolni. Ezeket a beállításokat célszerű konfigurációs fájlban elhelyezni, így bármely gépen futtatható a szükséges programok telepítése, és a konfiguráció beállítása után.
27
3.5 A szimulációs napló elkészítése A szimuláció naplózása során előáll a szimulációs feladat kimenetele. A szenzorok állapotából a szimuláció futása során folyamatosan mintavételezünk, és ezeket elmentjük. Magasabb szintű napló készítéséhez ezeket a mintákat szűrjük és bizonyos következtetéseket vonhatunk le. Alacsony szintű napló például egy távolságmérő másodpercenként előállított adatai, míg egy magas szintű napló, amelyben csak azt jelenítjük meg, ha egy megadott kritikus távolságon belül kerültünk valamilyen objektumhoz. A naplózás elkészítéséhez kétféle irányvonalat követhetünk, az egyik a szenzorok általi naplózás, a másik pedig az entitások állapotának elkérése a szimulációs környezettől. A második esetben az entitások pozíciójának lekérdezéséhez szolgáltatást kell készítenünk, amelyben valahogy meg kell találnunk a számunkra érdekes entitásokat a szimulációban megjelenő összes entitás közül, és annak lekérdezni a megfelelő állapotait. A szenzorok állapotának lekérdezése valamivel bonyolultabb, mivel ehhez olyan szolgáltatást kell készíteni, amely a már meglévő, felhasznált szolgáltatásokkal kommunikál, és annak típusától függően a megfelelő paramétereket lekérdezi, például egy lézeres távolságmérő szolgáltatás távolságadatait. Ezzel a megoldással az a probléma, hogy egy újabb naplózó funkció felvételéhez az eddigi naplózó szolgáltatásokat kell bővíteni, vagy a funkciótól függően újat létrehozni. A szenzorok általi naplózás a szenzorok SPL definíciójánál a szükséges naplózó logika hozzáadásával egyszerűen kivitelezhető, viszont ebben az esetben a szenzor működését bővítjük. A feladat megoldásához ezt a megoldást választottam annak könnyű bővíthetősége és módosíthatósága miatt. Újabb naplózó igények felvételéhez csak a robot SPL definícióját kell módosítani. A már említett magas szintű napló előállítására két megoldás van, a real-time szűrés és az utólagos szűrés. A real-time szűrésnél azonnal egy magas szintű naplót generálunk, vagyis a szenzor csak a szűrt adatokat naplózza. Ez tipikusan azt jelenti, hogy a szenzor maga szűri meg az adatokat, amely egy plusz terhelést jelent neki, és emiatt szélsőséges esetben változtathat annak viselkedésén is.
28
Az utólagos szűrésnél a szenzorok először egy alacsony szintű naplót készítenek, majd ezt utólag valamilyen programmal feldolgozzuk, és szűrjük aszerint, hogy milyen adatokra vagyunk kíváncsiak. A feladat megoldásánál az egyszerű tesztesetek miatt a real-time szűrést választottam. Bonyolultabb szimulációs kontextussal a naplózó funkciókhoz kapcsolódó igények is nőhetnek, így egy bővítési lehetőség az utólagos napló szűrő keretrendszer létrehozása lehet.
3.6 A példa szimulációkhoz szükséges entitások elkészítése Az szimulációs modell felépítését két részre bontottam, egy általános könnyen bővíthető részre amelyet a modell beolvasása részben, és egy RDS specifikus, a bővítéshez az alkalmazást módosítandó részre amelyet a modell átalakítása részben tárgyaltunk. A szimulációhoz szükséges entitások definíciója az általános részbe kerül, így könnyen bővíthető új entitásokkal. Az entitások definícióját külső SPL fájlokként adhatjuk meg. Az entitások létrehozását egy olyan felhasználó végzi, aki ismeri a szimulációs környezetet és az SPL szkriptet. Az UML modellben egy entitásnak csupán az entitásra vonatkozó definíciói jelennek meg, de nincs benne az entitás részletes felépítése és működése. Ezt külső SPL fájlokban adjuk meg. Például a targoncát az UML modellben annak súlya, pozíciója írja le, de ezen kívül szükség van a targonca kinézetének és szenzorainak a definíciójára, valamint azok működésének megadására. Így tehát minden entitás típushoz tartozik egy külső SPL szkript, amely az entitás belső működését írja le az UML modellben megadott paraméterek alapján. Az UML modellben a megfelelő osztály és attribútum nevek és a RDS entitás attribútumai nem biztos, hogy megegyeznek. Ennek a feloldására egy leképezést definiáltam, amely szintén módosítható, és bővíthető például új entitás felvételekor. Ez a leképezés az UML objektumok és a RDS szimulációs entitások attribútumainak összerendeléséért felelős, valamint a feldolgozáshoz szükséges további információkat helyezhetünk el benne.
3.7 Tervezés összefoglalása A utolsó részfeladat megtervezése után az alkalmazás készen áll az implementációs fázisra, melynek komponensei az alábbi ábrán láthatók (9. ábra). 29
9. ábra: Alkalmazás komponens terv
Az ábrán látszik, hogy az alkalmazás három fő részre bomlik. Az RdsModel az RDS specifikus környezet igényeihez alkalmazkodó belső modell. Ezen a modellen könnyen elvégezhetők a szükséges átalakítások és a szabványos Ecore modell segítségével könnyen lehet kódot generálni az Acceleo eszköz segítségével. Az RdsSimulationHelper komponens az általános bejövő UML modell beolvasásáért és az igények szerint átalakításáért felelős. Az RdsSplGenerator a létrehozott modellből szimulációs szkriptet generál és az futtatja a szimulációs környezetben. A naplózó funkció a szimulációhoz és az entitások szimulációs állapotához kapcsolódik. Az alkalmazás kimenete az így generálódott naplófájl.
30
4 Implementáció Az R3-COP projekt részfeladata, a Test Execution rész a feladatban egy köztes lépés, amely a modell generálása, és a értékelése között helyezkedik el, nevezetesen a szimuláció futtatása az RDS segítségével. A feladatot a Tervezés részben hat részfeladatra bontottam, a részfeladatokban igyekeztem szabványos, a megfelelő részhez legjobban illeszkedő eszközöket felhasználni. Az tervezés során előállt az elkészítendő alkalmazás architektúrája, melynek részleteit ebben a fejezetben mutatom be.
4.1 A bejövő modell beolvasása és feldolgozása 4.1.1 A szimulációs UML modell elkészítése A Test Execution feladatrész egy köztes lépés a folyamatban. Az adatfolyamban a bejövő modell egy, a modell generálás lépésnél előállt modell, amely megegyezés szerint egy XMI formátumban megadott UML modell. A tapasztalatok szerint, bár az XMI az UML leíráshoz használt szabványos leíró, a különböző modellező eszközök által generált XMI leírások között különbségek vannak, amelyet az XMI parser eszközök nem tudnak kezelni. A feladatban ezért egy adott modellező eszközt, a Papyrus-t támogatom. A Papyrusban egy Osztálydiagram segítségével definiáltam a kontextus modellt, a felhasználható entitásokkal, azok attribútumaival és a közöttük lévő kapcsolatokkal. Bár a félév során nem volt idő az R3COP által definiált teljes metamodell megvalósítására, de a megoldott részekben igyekeztem alkalmazkodni hozzá. A kidolgozott kontextus modell az alábbi ábrán látható (10. ábra). A kontextus modell bővítésével az UML modell általános feldolgozása miatt könnyen bővíthető a felhasználható elemek halmaza.
31
10. ábra: Kidolgozott UML kontextus modell
Az
adott
szimulációs
modelleket
a
kontextus
modell
elemeinek
példányosításával lehet elkészíteni. A példánymodelleket külön csomagokban kell definiálni, mert a feldolgozásnál az adott csomagokat külön szimulációs modellként kezelem. Új szituáció felvételéhez létre kell hozni egy új csomagot, abban egy osztálydiagramot, amiben a kontextus modell elemeit lehet példányosítani. Az osztályok példányosításához az InstanceSpecification használható, amely paramétereinél a Classifier beállításával megadható, hogy mely kontextus modell osztályból szeretnénk példányosítani. A példányok közötti kapcsolatot hasonlóan az InstanceSpecification link segítségével adhatjuk meg. A példány attribútumait Slot-ok hozzáadásával állíthatjuk be, ahol a Defining feature paraméterrel megadható mely attribútumból példányosítunk, és a Value paraméter segítségével annak értéke. Mivel az alkalmazásban egy szöveges leírót, kódot generálunk így minden attribútumot LiteralString típusúnak definiálandó, amely egy szöveges attribútumot jelent.
4.1.2 Az UML modell beolvasása Az UML modellt a Papyrus XMI formátumban exportálja. Az XMI beolvasásához és feldolgozásához az UML2 Eclipse plugint használtam, mivel az Eclipse UML2 és a Papyrus is a közös szabvány miatt garantáltan együtt tudnak működni.
32
Az XMI beolvasásához a bemeneti fájl elérési útvonalát az alkalmazás indításánál bekért paraméterből dolgozom fel a szükséges paraméter ellenőrzések után. A modell beolvasását az UML2 parser-re bízom. Mivel ez általános modell kezelő eszköz, így meg kell adni hogy UML modellel dolgozom, ahogy az alábbi kódrészletben is látszik. A metódus a megadott elérési útvonalon lévő XMI leírásból visszaadja a Javaban feldolgozható modellt. public Model getModel(String pathToModel) { typesUri = URI.createFileURI(pathToModel); ResourceSet set = new ResourceSetImpl(); set.getPackageRegistry().put(UMLPackage.eNS_URI, UMLPackage.eINSTANCE); set.getResourceFactoryRegistry().getExtensionToFactoryMap() .put(UMLResource.FILE_EXTENSION, UMLResource.Factory.INSTANCE); set.createResource(typesUri); Resource r = set.getResource(typesUri, true); return (Model) EcoreUtil.getObjectByType(r.getContents(), UMLPackage.Literals.MODEL); }
A könnyebb kezelhetőség érdekében ezt a modellt csomagokra bontom, és elkülönítem egymástól az osztályokat és asszociációkat, így azokon szisztematikusan el lehet végezni a szükséges további műveleteket.
4.1.3 UML modell feldolgozása Az UML modell osztályokat és azok asszociációit tartalmazza. Ezek az asszociációk két objektum közötti kapcsolatot írnak le, például az egyik a másikon van. A RDS szimulációs leírásában pontos koordinátákkaló és orientációkkal lehet dolgozni, így az asszociáció által megadott viselkedéseket fel kell dolgozni, és a modellt ennek megfelelően átalakítani. A könnyebb kezelhetőség érdekében egy saját Ecore modellt hoztam létre, amely jól leírja az RDS elemeit, és könnyen lehet kódot generálni belőle a szimulációs leíró szintaktikájával. Ebben a modellben RDS entitásokat, attribútumokat vettem fel, és definiáltam a közöttük lévő hierarchiát. Az Ecore metamodell felépítése az alábbi ábrán látható (11. ábra).
33
11. ábra: Ecore metamodell
A
SimulationModelEcore
egy
szimulációhoz
szükséges
attribútumokat
tartalmazza és gyökér elemként szolgál a többi entitásnak. Ennek gyermekei az RdsEntityEcore-ok, amelyek az UML modellben megjelenő objektum példányok, amelynek gyermekei az RdsAttributeEcore-ok, amelyek az UML modellben megjelenő objektum példányok attribútumai. Az UML modell feldolgozásakor végigmegyek az UML package-ből kigyűjtőtt osztálypéldányokon, és ezekhez a Classifier és Slot definíciókon keresztül hozzá tudom kapcsolni az UML kontextus modell megfelelő elemeit. Így megvannak a felvett objektumok példányleírói, és azok metadefiníciója amiből felépítem a belső Ecore modell példányt.
4.1.4 UML és RDS leképzés A bejövő UML modell az R3-COP által meghatározott metamodell szerint épül fel. A megoldásnak általánosnak kell lennie, és kezelnie kell az RDS specifikus viselkedéseket. Az UML modellben megadott nevek és paraméterek nem feltételen egyeznek meg a RDS által előírtaknak, így valamilyen megfeleltetésre van szükség közöttük. Ezen felül vannak olyan paraméterek, amelyek az UML modellben nem jelennek meg, viszont a RDS szimulációhoz feltétlen szükségesek. A megoldás általánossága és könnyű bővíthetőségi igénye miatt ezeket a három program egy külső fájlból dolgozza fel, amely egy leképzés, vagy mapping az UML és RDS modell között.
34
A mapping fájl alapértelmezetten az alkalmazás főkönyvtárába került, de igény szerint áthelyezhető, helyét a konfigurációs fájlból olvassa fel. A konfigurációs fájlban a szükséges fájlok elérési útvonalai találhatók, amelyek különböző gépeken máshol helyezkedhetnek el. Tartalmazza például a feltelepített RDS könyvtár elérését, és olyan szükséges könyvtárakat/fájlokat amelyek nem gyakran változnak. A gyakran változó paramétereket, például a bemeneti modell elérési útját az alkalmazás indításánál paraméterként kell megadni. A konfigurációs fájlban a sorok kulcs=érték szintaktikával vannak megadva. A mapping a könnyű és szabványos kezelhetőség miatt egy XML dokumentum, melyben az UML kontextus modellben megjelenő entitások és a szükséges attribútumok találhatók. Az entitásokhoz tartozó attribútumok jelentése a következő:
EntityType: Az entitás típusát adja meg, például targonca, vagy szegmens. Ez a típus a kontextus modellben definiált osztály neve.
CreateString: Az entitás létrehozásához szükséges SPL entitás definíciós művelet neve. Például AddNewEntity - amely egy új egyszerű entitást definiál, vagy AddDifferentialDriveEntity - amely egy új mozgó entitást definiál amelyet robotok létrehozásához használhatunk.
Renderable: Megadja, hogy adott entitást renderelni akarjuk a szimulációban vagy sem. Vannak olyan entitások, amelyek csak segéd objektumok. Ilyen például a Station, amely fontos szerepet játszik a megoldásban. A mintaalkalmazás metamodellben az entitások egymáshoz képesti pozíció megadására a LocatedOn asszociáció van definiálva, viszont egy szegmensnél például nem lehet eldönteni, hogy egy entitás a szegmens mely pontjára kerüljön. Ezért vezettem be a Station entitást, amely egy pont. Ez a pont egyértelműen meghatároz bizonyos pozíciót, például a szegmens két végét. Az entitásokat Station-re helyezve viszont egyértelműen megadott pozíciókra lehet elhelyezni a többi objektumot. A Station értelem szerűen nem jelenik meg a szimulációban mint entitás, mert csak a többi objektum elhelyezésében nyújt segítséget. A Renderable attribútum a True és False értékeket veheti fel.
BehaviourFileName: Az entitások belső tulajdonságait és viselkedését az UML modell nem írja le. Például nem írja le, hogy nézzen ki a targonca, milyen nehéz legyen, vagy milyen érzékelők legyen rajta, de a szimuláció végrehajtásához 35
természetesen ezekre is szükség van. Az egyes entitások belső tulajdonságait a könnyű bővíthetőség miatt külső fájlokban lehet megadni SPL kódként. Új entitásokat tehát olyan valaki tud létrehozni, aki jártas az SPL szkriptek írásában. A BehaviourFileName ennek a viselkedést leíró SPL fájlnak a neve, például Segment.txt. Ezt a fájlt az alkalmazás a konfigurációban megadott viselkedés leírókat tartalmazó mappában keresi.
Attribute: Az UML modellben definiált entitások attribútumait meg kell adni a mappingben, amelynek saját attribútumaik vannak, amelyek a következők: o UmlName: Az UML modellben megadott adott attribútum neve. o RdsName: A RDS által definiált entitás attribútumának neve, amely a RDS által adott, és nem változtatható. o IsRDSEntityAttribute: Az UML leírásban megjelennek valós entitás attribútumok és segédattribútumok. A segédattribútumok olyan attribútumok amelyek közvetlen nem jelennek meg a szimulációban RDS entitás attribútumként, hanem a viselkedést leíró fájlban vannak felhasználva. Ilyen például a szegmens hossza. A szegmens hossza a szegmens két végéből számolt érték, amely a szegmens viselkedés leírójában definiált hossz változóba kerül behelyettesítésre. A viselkedés leíróba behelyettesített változókról
a
következő
fejezetben
részletesebben
lesz
szó.
Az
IsRDSEntityAttribute attribútum a True és False értékeket veheti fel. Ezek az attribútumok az attribútumtól függően a következő lépések, vagy részfeladatok valamelyikében felhasználásra kerülnek. Az EntityType például a modell felépítésénél, vagy a Renderable attribútum a szimulációt leíró kód generálásánál. Egy példa entitás mapping definíció: <Entity> <EntityType>Segment
AddNewEntity True Segment.txt IsKinematic IsKinematic True Color Color
36
False Length False
4.2 A modell igények szerinti átalakítása Ahogy már előbb is volt róla szó, az UML metamodell egy, a mintaalkalmazásban definiált metamodell, amely nem alkalmazkodik a RDS sajátosságaihoz. Mivel a megoldásnak általánosnak kell lenni, így a bemenetben megadott modellt a RDS igényeknek megfelelően át kell alakítani. Az előző lépésben a modell feldolgozásánál egy általános eljárást használtam, amely könnyen bővíthető, viszont bizonyos dolgokat nem vettem figyelembe, például az asszociációkat. Az asszociációnak az UML leírásban csak egy neve és multiplicitása van, például LocatedOn. A névből tudjuk, hogy ez az asszociáció azt takarja, hogy az egyik entitás a másik entitáson helyezkedik el, például egy raklap a szegmensen. Ez azonban egy háttértudás, és az UML modellből nem derül ki. Ezen felül az sem derül ki, hogy a szegmensen pontosan hová kerül a raklap. Erre a problémára sajnos nem lehet általános és könnyen bővíthető megoldást adni, így az ilyen háttértudásokat az alkalmazás belsejébe kell vinni. A
metamodellben
háromféle
asszociációt
definiáltam,
amelyből
kettő
összetartozik. Ezek a Start, End és LocatedOn nevű asszociációk. A LocatedOn-ról már volt szó. A mintaalkalmazásban definiált metamodellben nincsenek meghatározva a pozíciók, viszont az RDS azokkal dolgozik. Emiatt bevezettem a Station entitást, amelynél meg kell adni annak konkrét pozícióját. A többi entitás pozícióját az asszociációk felhasználásával számolom ki a szükséges háttértudás leprogramozásával. A LocatedOn asszociációnál egyik entitás megörökli a másik entitás pozíció attribútumát. Mivel a Station-ön kívül más entitásnak nem kell definiálni az pozícióját így neki nincs is ilyen attribútuma, tehát először hozzá kell rendelni azt. A Start és Stop asszociációk a szegmensekhez kapcsolódnak. A szegmenst egyértelműen annak két végpontja definiálja, ezért a két végpontjához egy-egy Station entitást rendelnek. A szegmens pozíciója tehát a két Station által meghatározott szakasz középpontja lesz. Ezen kívül a szakasz hosszát, és a viselkedésben definiálthoz képesti 37
elforgatást is ki kell számolni. A szakasz hosszát a két végpont koordinátáiból könnyen meg lehet határozni a felezőponttal, az elforgatás szögét pedig skaláris szorzással. A szegmens hossza egy olyan belső attribútum amely a szegmens definíciójában jelenik meg. Mivel egy szegmens hossza attól függ, hogy a szimulációban hogyan vettük fel a szegmenspályát így a viselkedés leíróba ezt az értéket be kell juttatni. A viselkedés leíró definíciós részében nem lehet változókat létrehozni, ezért a megfelelő helyre egy helyfoglalót tettem. Az alkalmazás a megfelelő attribútumokat a fájl beolvasásakor kicseréli a megfelelő helyfoglalóval. A helyfoglaló megadása a
szintaktikával történik, ahol az Attribútum a mapping-ben megjelenő attribútum neve. Az alkalmazás az entitások attribútumait az SPL fájlban kicseréli a megfelelő helyfoglalókkal. Például a mappingben a szegmensnél a Length attribútumhoz a viselkedés leíróban a megadásával helyezhetünk el helyfoglalót.
4.3 A modell exportálása a szimulációt leíró nyelven Az előző részfeladatban elkészült az Ecore modell példány, amely már megfelel az RDS sajátosságainak, és készen áll az SPL kód generálására. A kódgeneráláshoz az Acceleo Eclipse plugint használtam. Ahogy volt róla szó a feladatot két különálló részre, két projektre bontottam. Az első projekt az UML modell feldolgozásáért felelős, a második a kód generálásért, és a szimuláció futtatásáért. A két különálló részt így igény szerint egymástól függetlenül is lehet használni. Tesztelésnél tipikusan több különböző teszt szituációt is létrehozunk, ezekből az első rész segítségével legenerálhatjuk a szükséges RDS modelleket, a második segítségével pedig egymás után futtathatjuk ezeket. Az elkészült metamodellt fájlba mentem, amely modellből fog generálódni az SPL kód. Az Ecore modell fájlba mentést az alábbi kód végzi: ResourceSet resourceSet = new ResourceSetImpl(); resourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap().put("* ", new XMLResourceFactoryImpl()); Resource resource = resourceSet.createResource( URI.createFileURI(this._outSplPath + this._outSplFileName +".xml")); resource.getContents().add(this._modelEcore); Map options = new HashMap(); options.put(XMLResource.OPTION_SCHEMA_LOCATION, Boolean.TRUE);
38
try{ resource.save(options); }catch (IOException e) { e.printStackTrace(); }
A modell beolvasásához, generálásához és a szimuláció futtatásához az Acceleot használtam fel. Az Acceleo típusú projekt általános Ecore modellekkel tud dolgozni. Ahhoz, hogy tudja kezelni az általam generált Ecore modell példányt először meg kell ismertetni az eszközzel annak metamodelljét. Ezt a RegisterPackages metódus felüldefiniálásával lehet megtenni. Az RDS metamodell regisztrációját az alábbi kód szemlélteti: @Override public void registerPackages(ResourceSet resourceSet) { super.registerPackages(resourceSet); if (!isInWorkspace(RdsModelPackage.class)) { resourceSet.getPackageRegistry() .put(RdsModelPackage.eINSTANCE.getNsUR I(), RdsModelPackage.eINSTANCE); } }
A metamodell regisztrációjával az Acceleo már ismeri az általam definiált Ecore modellt, így fel tudja azt dolgozni. A megfelelő szintaktikát használva így már könnyen definiálható egy olyan Acceleo generáló modul, amely érvényes SPL kódot generál. A statikus szövegek mellé a tag-ek felhasználásával dinamikusan beilleszthetők a modell egyes attribútumai. A modellt bejárhatjuk a [for] tag használatával, valamint az [if] tag-gel elágazásokat definiálhatunk. Az alábbi kódrészlet a RDS entitások létrehozását végzi melyhez beállítja a megfelelő attribútumokat: [for (entity : RdsEntityEcore | model.OwnedEntities) separator('\n')] [if (entity.Renderable.toUpperCase() = 'TRUE')] [entity.CreateString/] [entity.Name/] [for (attribute : RdsAttributeEcore | entity.OwnedAttributes) separator('\n')] [if (attribute.IsRdsEntityAttribute.toUpperCase() = 'TRUE')] /[attribute.RdsName/]: [attribute.Value/] [/if] [/for] [entity.BehaviourDefinitions/] [/if] [/for]
A fent lévő Acceleo generáló modul részlet az alábbi SPL kódrészletet generálta egy példafutás során egy szegmens entitásra: 39
AddNewEntity seg1 /IsKinematic: true /Color: 0 0 0 1 /Position: 0.0 0.009999999776482582 /Orientation: 0 -180.0 0 AddBoxShape /Dimensions: 10.0 0.001 0.2 /Mass:0.1 /DiffuseColor: 0 0 0 1
5.0
A fenti SPL kód egy érvényes entitás definíció. Az első AddNewEntity része az entitás létrehozásáért felelős a megfelelő paraméterekkel. A második AddBoxShape része a viselkedés leírásért felelős fájl tartalma, amelyben a helyfoglaló az alkalmazás által 10.0-ra lett lecserélve. A generáló modul a [model.InitializedSPL/] tag-gel kezdődik, amely a szimulációs környezet beállításaiért felelős SPL kódot tartalmazza. Ezt a kódot az alkalmazásban fájlból olvasom be a viselkedést leíró SPL kódokhoz hasonlóan, és helye a konfigurációs fájlban állítható. Ilyen beállítások például a kamera helye és iránya.
4.4 A szimuláció futtatása A szimuláció kézi futtatására több megoldás is létezik. Ami a megoldásokban közös, hogy a szimuláció elindításához szükség van az alábbiakra, amelyeket együtt szimulációs leírónak hívok:
A szolgáltatások és a szimulátor indításáért felelős manifest-re. A szimulációs világ állapotának definíciójára. A szimulációs környezet elindítása után lehetőségünk van kézzel megnyitni egy
szimulációs leírót. Egy másik megoldás a VPL-ben készített szimulációs leíró indítása, vagy egy RDS-en kívül álló eszköz, az SPL szkript szerkesztő segítéségével történő futtatás. Ezek közül a VPL-es megoldást választottam, mert a többinél nem találtam lehetőséget az automatizálásra. A VPL jól illeszkedik az RDS környezethez, használatával könnyen és átlátható módon lehet robot rendszereket fejleszteni. Problémát jelent, hogy nem szöveges programozás, ezért a programkód automatikus generálására nehézkes. Mint már korábban is volt róla szó ezen segít az SPL, amely a VPL funkcióit használó szkript nyelv. Mivel az SPL szerkesztő környezetből indított szimuláció automatizálására nem találtam lehetőséget így VPL-ben készítettem egy egyszerű manifest-et, amely az SPL szkript beolvasását, és annak szimulációs környezetben való futtatását végzi. Az 40
elkészített szimulációs leíró a RDS főkönyvtárának \samples mappájából futtatható, ezért a generált szkriptek futtatásához először oda kell helyezni. A szkript futtatásáért felelős egyszerű VLP program az alábbi ábrán látható (12. ábra).
12. ábra: A generált SPL szkript futtatásáért felelős VLP program
Ezzel minden rendelkezésre áll a szimuláció futtatásához. Ezután a szimulációt a RDS \bin könyvtárában található DssHost alkalmazás megfelelő paraméterezésével lehet programozottan elindítani. A program indításának parancsa a megfelelő paraméterezéssel: dsshost /p:50000 /t:50001 /m:"samples\servicename.manifest.xml"
A parancsban a kapcsolók jelentése a következő:
/p: TCP port amelyen a HTTP kéréseket fogadja
/t: TCP port amelyen a SOAP kéréseket fogadja
/m: manifest
Az alkalmazás feladata a szimuláció futtatásához mindössze annyi, hogy az SPL szkript generálása után futtatja a fenti alkalmazást a megfelelő paraméterekkel. A megfelelően paraméterezett futtatásért felelős kódrészlet a következő: public void executeScript(String rdsFolder) { try { String replacedRdsFolder = rdsFolder.replace("/", "\\"); String[] params = new String [4]; params[0] = replacedRdsFolder + "bin\\dsshost.exe"; params[1] = "/p:50000"; params[2] = "/t:50001"; params[3] = "/m:\"" + replacedRdsFolder + "samples\\MySamples\\SPLExecutor\\SPLExecutor.manifest.xml\""; Process process = Runtime.getRuntime ().exec (params); }catch (Exception e){ System.err.println("Error: " + e.getMessage()); } }
41
4.5 A szimulációs napló elkészítése A szimulációs napló létrehozásához a szenzorok általi real-time naplózást választottam a naplózási funkciók könnyű bővíthetősége és módosíthatósága miatt. Irodalomkutatásom során nem találtam megoldást az SPL-ből történi fájlba írásra, viszont az SPL környezet lehetőséget nyújt .NET szerelvények használatához, ezért a naplózó keretrendszert .NET assemlby-ként használom fel az entitások SPL definíciójában. Ehhez létrehoztam egy RdsLogger nevű osztályt, amely a log fájlok létrehozásáért, és feltöltéséért felelős. Ebben az alábbi Write metódus meghívásával egy-egy sort fűzhetünk a naplófájlhoz. public void Write(string line) { File.AppendAllText(filePath, DateTime.Now.ToString() + ": Environment.NewLine); }
" + line +
Az ebből készített Assembly-t az RDS főkönyvtárának \UserData mappájába kell másolni. A naplózásért felelős funkció az RDS főkönyvtárában létrehoz egy \log mappát és ide minden szimulációhoz egyedi naplófájlt készít. Ezt az osztályt az SPL definícióban az alábbi módon példányosítható és használható: a = Assembly.LoadFrom("UserData/RdsLogger.dll") loggerType = a.GetType("RdsLogger.RdsLogger") logger = Activator.CreateInstance(loggerType) logger.Write("Simulation Started")
Egy példa szimuláció futásának eredménye: 12/05/2013 12/05/2013 12/05/2013 12/05/2013 12/05/2013 12/05/2013
17:32:00: 17:32:20: 17:32:20: 17:32:20: 17:33:11: 17:33:11:
Simulation Started Forklift: Found a pallet Forklift: Stopped Forklift: Lifting up to full Forklift: Found a corner Forklift: Turning right in the corner
4.6 A példa szimulációkhoz szükséges entitások elkészítése A szimuláció futtatásához létre kellett hozni a példákban felhasznált entitásokat. Az elkészített entitások a szegmens (Segment), Raklap (Pallet) és a targonca (Forklift).
4.6.1 Szegmens Egy entitás megadása SPL-ben az entitás létrehozásból az entitás egészére vonatkozó paraméterek megadásával, valamint az entitást felépítő belső építőelemek definiálásával történik. 42
Az SPL entitás definíció szintaxisát az alábbi egyszerű szegmenst leíró példán keresztül szemléltetem. AddNewEntity seg1 /IsKinematic: true /Color: 0 0 0 1 /Position: 0.0 0.009999999776482582 /Orientation: 0 -180.0 0 AddBoxShape /Dimensions: 10.0 0.001 0.2 /Mass:0.1
5.0
A példa első sorában az entitást létrehozó parancs és az entitás neve látható, ezt követik az entitás egészére vonatkozó paraméterek, mint pozíció, orientáció. Ezt a részt az alkalmazás az UML modellből állítja össze. A második AddBoxShape rész az entitás belső felépítését leíró egyetlen téglatestből, és annak paramétereiből áll, ami az entitás viselkedését leíró fájlokból a helyfoglalók behelyettesítésével generálódik. Látható, hogy a szegmens valójában egy nagyon vékony téglatest.
4.6.2 Raklap A raklap szintén egy egyszerű, nem mozgó entitás, amelyet néhány téglatestből raktam össze. A raklapnak egy új fontosabb paramétere van, a textúra. A textúrákat és 3D modelleket a szimulációs környezet alapértelmezetten a RDS főkönyvtárának \store\media könyvtárában keresi, így új entitás felvételénél a megfelelő fájlokat ide kell másolni.
4.6.3 Targonca A szegmens egy egyszerű entitás volt, amely nem tud mozogni, és nincs semmilyen érzékelője, a targonca ezzel ellentétben egy mozgó objektum, amely valamilyen mesterséges intelligencia szerint működik. A működéséért felelős szkriptet a statikus állapot leírása után a FlushScript hívást követően tehetjük meg. Ebben a részben procedurák segítségével defininálhatjuk az entitás viselkedését. A következő procedurát a targoncán található bal oldali lézeres távolságmérő hívja meg adott időközönként. A működése szerint, ha a mért értékek azt mutatják, hogy valami túl közel van (2 méteren belül), akkor meghívja a stop procedurát, amely megállítja a targoncát. Procedure
rangeNotifyRight
43
d1 d2 d3 d4 if {
= value.DistanceMeasurements[0] = value.DistanceMeasurements[90] = value.DistanceMeasurements[180] = value.DistanceMeasurements[270] (d1 < 2000 || d2 < 2000 || d3 < 2000 || d4 < 2000 ) call stop
} End
Az egyszerűség kedvéért a targoncát egy három kerekű mozogni képes alapra helyeztem, így helyben is tud forogni, ami jóval egyszerűbb algoritmust igényel, mint a négy kerekű mozgás. A test modelljének egy ingyenes targonca 3D mesh-t töltöttem le, amelyet utólag 3D Studio Max modellező eszközzel szerkesztettem. A szerkesztésre azért volt szükség, mert leválasztottam a targonca csőrét a testről, így azok egymástól függetlenül tudnak mozogni. A targonca csőrét gyermek entitásként definiáltam, és joint entitásokkal kapcsoltam össze. A joint entitásoknál magunk definiálhatjuk annak szabadsági fokait, így forogni képes csuklókat hozhatunk létre. A targoncán ezen felül különböző érzékelőket helyeztem el, a két oldalán egy-egy lefelé néző színérzékelővel, egy-egy lézeres távolságmérővel és a csőrén nyomásérzékelőkkel. A targonca intelligenciájának tervezésénél és megírásánál törekedtem az egyszerű
megoldásokra,
amelyek
szükségesek
lehetnek
a
példa
szituációk
kialakításához. A lefelé néző színérzékelők segítségével képes követni az adott színű földön futó szegmenseket. A kereszteződéseket egy előre feltöltött útvonallal kezeli, amelyben definiálva van, hogy az adott kereszteződéseknél melyik irányba haladjon tovább. Értékei a LEFT, RIGHT és AHEAD, amellyel nem csak a 90 fokos kereszteződések kezelésére képes. Működését tekintve a kereszteződés áthaladásáig kikapcsolja a megfelelő oldali színérzékelőt, így csak az egyik irányba korrigálja a mozgást. Az R3COP projektben a robotok kifinomultabb intelligenciával működnek, és a feladatokat egy központi számítógéptől kapják, amely követi a mozgásukat. A feladatomnak nem volt része ennek a működésnek a megvalósítása, ezért a robotok egyszerű algoritmus szerint működnek amely lehetőséget biztosít a tesztelési példák futtatásához. A targonca így a szegmenseken képes haladni, és eljutni egyik pontból a másikba a betáplált úton. Egy másik igény, hogy észlelje, ha valami túl közel van, és reagáljon rá. Ehhez a targonca két oldalára lézeres távolságmérőket helyeztem el, amelyek érzékelik ha valami túl közel van, és a targonca ennek hatására megáll. A
44
lézeres távolságmérőket úgy állítottam be, hogy a működését ne zavarja a targonca csőrének fel-leengedése. A csőrön négy nyomásérzékelőt helyeztem el, kettőt a csőr elején, amelyek érzékelik ha a targonca valaminek nekiütközne, és kettőt a csőr hátán, amelyek a raklap felemeléséhez szükségesek. Ha a targonca a szegmensen talál egy raklapot, akkor azt felemeli és az útja további részében hordozza. A targonca entitás megírásánál nem vettem figyelembe azt az esetet, ha egyszerre több targonca is megjelenik a szimulációban. A több targoncával való funkció bővítéshez a leírásban megjelenő gyermek entitások neveinek egyediségét kell biztosítani, amelyet például a helyfoglalóval könnyen meg lehet tenni, mivel az UML példányok nevei egyediek. Ezekkel az alap entitásokkal már összetettebb szituációkat, teszteseteket lehet létrehozni az alkalmazás segítségével.
4.7 Az alkalmazás felépítése Az alkalmazás három különálló projektből tevődik össze. Az első, az RdsModel, amely a saját RDS specifikus Ecore metamodell definícióját tartalmazza. A második az RdsSimulationHelper, amely a bejövő modell beolvasásáért és feldolgozásáért, valamint a modell RDS specifikus igények szerinti átalakításáért felelős. A harmadik projekt, az RdsSplGenerator feladata az Ecore modellpéldányból történő SPL szkript generálás, és a szimuláció futtatása.
4.7.1 RdsModel Az RdsModel alkalmazás a saját RDS specifikus Ecore metamodelt, az Ecore szerkesztővel létrehozott modellből generált definíció kódját, és a létrehozáshoz szükséges factory osztályokat tartalmazza. Mivel az RdsSimulationHelper és az RdsSplGenerator is ezzel a modellel dolgozik, így projekt szintű referenciát használtam erre a package-re.
4.7.2 RdsSimulationHelper Az RdsSimulationHelper feladata főként az R3COP által definiált UML modell beolvasása, feldolgozása és előkészítése az RDS környezethez. Az alábbi ábrán látható a projekt főbb osztályai és metódusai (13. ábra). 45
13. ábra: A projekt főbb osztályai és metódusai
RdsSimulationHelper: Ez az osztály tartalmazza az UML modell beolvasását és feldolgozását, valamint a model RDS igényei szerinti átalakítását.
UMLPackage:
Egy
adott
szimulációhos
kapcsolódó
UML
modell
információkat tartalmazza.
RdsModel: Az UML modellből képzett Rds specifikus modellt tartalmazza. Felhasználja az RdsModel projekt Ecore modelljének osztályait, és metódusait.
XMLHelper: A kapcsolódó XML fájlok, például mapping beolvasásáért, és feldolgozásáért felelős.
FileHelper: A szöveges fájlok beolvasásáért felelős. Ilyenek például az entitáshoz kapcsolódó viselkedésleíró SPL fájlok.
A projekthez kapcsolódó fájlok, és külső állományok:
Configuration: A projekt beállításokat, és fájl, mappa útvonalakat tartalmazza.
UML-RDS Mapping: Az UML kontextus és az RDS specifikus paraméterek összerendelését végző XML fájl.
Szimulátor
inicializáló:
A
szimulációs
környezethez
kapcsolódó
beállításokat elvégző SPL fájl, melynek feladata például a kamera beállítások elvégzése.
Entitás viselkedés leírók: Az entitások belső tulajdonságait leíró SPL fájlok.
46
UML modell: Az alkalmazás bemeneti UML modellje, amely egy Papyrus által generált XMI fájl.
RDS Ecore modell: Az alkalmazás kimeneti fájljai a bemenő UML packageekből előállt RDS specifikus modellek.
4.7.3 RdsSplGenerator Az RdsSplGenerator egy Acceleo projekt, melynek feladata az RDS specifikus modellek beolvasása, és az abból felépített SPL szkriptek generálása, és a szimuláció futtatása. Fő egységét képezi a Generate modulja, amelyben az Ecore modell felhasználásával előáll a kimeneti SPL kód. A projekthez kapcsolódó fájlok, és külső állományok:
Configuration: A projekt beállításokat, és fájl, mappa útvonalakat tartalmazza.
Bemenő Ecore modellpéldány: Az RdsSimulationHelper által előállított RDS modellpéldányok.
SPL szkript: A projekt által előállított kimeneti futtatható SPL szkript.
47
5 Az alkalmazás használata Az alkalmazás főként a programozói csoportot célozza meg, akiket kétféle felhasználói rétegre bontottam. Az egyszerű felhasználóra, akik az alkalmazást szituációk készítésére használják, és az alkalmazás fejlesztőkre, akik képesek az elemkészlet módosítására és bővítésére, melyet a SPL szkript ismerete tesz lehetővé. A alkalmazás felhasználásának Use Case diagramja az alábbi ábrán látható (14. ábra).
14. ábra: Az alkalmazás felhasználásának Use Case diagramja
Az alkalmazás használatához a következő eszközök szükségek:
Eclipse SDK: 4.2 verzió
Eclipse - Papyrus: 0.9.1 verzió
Eclipse - Acceleo: 3.3 verzió
Eclipse - UML2: 4.0.2 verzió
Eclipse - EMF: 1.6 verzió
Microsoft Robotics Developer Studio: 4 verzió
5.1 Egyszerű felhasználó Az alkalmazás használatát egy-egy példa bemutatásával szemléltetem. Egyszerű felhasználóként
tipikusan
a
rendelkezésünkre
szimulációs teszteseteket felépíteni.
48
álló
elemkészletből
szeretnénk
Első lépésként el kell készítenünk a szimuláció UML példánymodelljét az UML kontextus modellből. A példában a szegmensekből egy négyzet alakú utat raktam össze, melyre elhelyeztem egy targoncát és egy raklapot. A targonca feladata a raklap felvétele és körbeszállítása. A kapcsolódó UML modell az alábbi ábrán látható (15. ábra).
15. ábra: Példa szimuláció UML modell
Ha az UML modellel készen vagyunk, a mentett .uml kiterjesztésű XMI-t azonnal használhatjuk az RdsSimulationHelper alkalmazás bemeneteként. A projektek Eclipse pluginként lettek elkészítve, így azokat Eclipse környezetben lehet futtatni. Az RdsSimulationHelper projektnek bemeneti argumentumként a Papyrus által generált UML modellt elérési útját kell megadni, például: "d:/eclipse/Workspace/RdsSimulation1/robot-examples.uml"
Az alkalmazás futtatása után a kimeneti fájlok a konfigurációban megadott helyre kerültek az UML modellben megadott package-ek szerint elnevezve. Hiba esetén az alkalmazás a konzol felületre írja a hiba részleteit. Következő lépésként a már RDS specifikus modellekből a szimuláció futtatása következik. Ehhez az RdsSplGenerator alkalmazást futtatom az előbb legenerált példa modell segítségével. Argumentumként a modell fájl elérési útját kell megadni, amely esetemben a következő: "D:/eclipse/Workspace/RdsSimulationHelper/Resources/OutFiles/Example1.xml"
49
Az alkalmazás futása után a konfigurációban megadott helyre másolja a generált SPL szkriptet, és ezzel futtatja a szimulációs környezetet. Hiba esetén a hibaüzenetet a konzol felületre írja. Az alkalmazás futása az alábbi ábrán látható (16. ábra).
16. ábra: A példa szimuláció futása
5.2 Alkalmazás fejlesztő Alkalmazás fejlesztőként például olyan igény merülhet fel a tesztelési kontextus bővítésére, hogy labdákat szeretnénk elhelyezni a tesztelési környezetben és figyelni, hogy a targonca megáll-e minden labdánál, vagy esetleg a szoftver nem működik és beleütközik. A tesztelési környezet kialakításához egy új labda entitást kell felvennünk. ezzel bővítve a felhasználható elemkészletet. A labda felvételéhez annak SPL leírását írom meg, A labda felvételéhez annak SPL leírását kell megadni, ezzel egyúttal átgondolva a szükséges attribútumait. A labda SPL szkriptje a következő: AddSphereShape /Radius:
/Mass:20
Felépítéséhez egy egyszerű gömb formát használtam, melynek sugarához a helyfoglalót adtam meg, tömegének pedig 20kg-ot, amellyel egy fa golyót szeretnék szimulálni. A labda definíciója után azt fel kell venni az UML kontextusba is a Papyrus segítségével. Attribútumaiként a labda sugarát és a textúráját adtam meg. Mivel textúraként a raklaphoz használt fa képet használom így azt nem kell külön felvenni a RDS mappájába. A alábbi képen látható a labdával bővített UML kontextus modell (17. ábra).
50
17. ábra: Labda felvétele az UML kontextusba
Az utolsó lépés a labda entitás felvétele az UML-RDS mapping-be. A kapcsolódó entitás definíciós rész a következő: <Entity> <EntityType>Ball AddNewEntity True Ball.txt Radius Radius False Texture DefaultTexture True
A Renderable attribútum True-ra állításával megadtam, hogy a szimulációban látni szeretnénk a labda entitást. Egy példa szimuláció UML-jének készítésekor már fel lehet venni új példányt a labda osztályból. Egy konkrét szimuláció az alábbi ábrán látható (18. ábra).
51
18. ábra: A szimulációban megjelenő új labda entitás
52
6 Tesztelés Tesztelésként egy alapszintű kézzel végrehajtott tesztelést végeztem, melynek célja az alkalmazás kipróbálása egy a fejlesztéskor nem használt számítógépen az alkalmazás kipróbálása, és válaszainak vizsgálata, valamint bonyolultabb szimulációk létrehozásának felhasználói szintű tesztelése. A teszteléshez Windows 7 környezetet használtam.
6.1 T1: Új környezet Az alkalmazást egy, a fejlesztésben nem felhasznált számítógépre másoltam, ott próbáltam futtatni az alkalmazást. A projekteket importáltam az Eclipse környezetbe, viszont az alkalmazás futtatásakor az Eclipse hibával válaszolt, miszerint nem találta a felhasznált eszközök definícióját. A használathoz szükséges eszközöket telepítettem, így már tudtam futtatni az alkalmazást.
6.2 T2: Hiányzó paraméterek A szükséges eszközök telepítése után már tudtam futtatni az alkalmazásokat, azonban az alkalmazás az "Arguments not valid" hibaüzenetet dobta. Eclipse-ben a futtatási beállításoknál megadtam argumentumként a bemeneti UML modell útvonalát amit így meg is talált az alkalmazás.
6.3 T3: Hibás konfiguráció Miután a bemeneti fájlokat argumentumként beállítottam az alkalmazás futtatásra az "Error: file not exist" hibaüzeneteket dobta a file helyén a hiányzó fájl útvonalával. A projektek főkönyvtárában lévő konfigurációs fájlokban beállítottam a megfelelő fájlelérési útvonalakat így az alkalmazás már hiba nélkül lefutott. Az RdsSimulationHelper alkalmazás a konfigurációban megadott helyre exportálta az RDS specifikus modell leírókat, külön-külön a bemeneti UML modellben megadott szimulációk szerint.
53
6.4 T4: Hiányzó textúrák és mesh-ek Az előállt RDS specifikus modelleket futtatni szerettem volna a szimulációs környezetben. A szimuláció rendben elindult, azonban nem láttam textúrák és mesheket és naplófájl sem generálódott. A megoldáshoz bemásoltam a mellékletben szereplő fájlokat az RDS megfelelő könyvtárába így már megfelelően futott a szimuláció.
6.5 T5: Naplózás hiánya Az első már jól működő szimulációs tesztben egy szabályos hatszög alakú szegmens pályát hoztam létre a bemeneti UML modellben és egy raklapot is raktam a négyzet alakú pálya egyik sarkába. A szimuláció rendben elindult, viszont log nem generálódott, mivel nem helyeztem fel olyan entitást amely működéséhez napló funkciókat kapcsoltam.
6.6 T6: Egyszerű szimuláció Az előző tesztben létrehozott hatszög alakú pályára egy targoncát is elhelyeztem. A szimulációt végigkövetve a targonca rendben haladt a szegmens pályán, a raklapot is felvette amikor odaért és azt az útján végig hordozta. A szimulációhoz az alábbi napló generálódott, amiben látszik, hogy a szimuláció sikeresen elindult és a targonca megtalálta a raklapot. 14/05/2013 14/05/2013 14/05/2013 14/05/2013
20:45:00: 20:45:20: 20:45:20: 20:45:20:
Simulation Started Forklift: Found a pallet Forklift: Stopped Forklift: Lifting up to full
6.7 T7: Kereszteződések kezelése Ebben tesztesetben egy bonyolultabb szegmens pályát vettem fel több kereszteződéssel és erre raktam rá a targoncát és a raklapot. A szimulációt végigkövetve a targonca az első kereszteződésnél balra fordult és ott a szegmens pálya végén egyenesen továbbhaladt a szegmenspályán kívülre. A teszthez generálódott napló a következő, amelyben látszik, hogy a targonca talált egy kereszteződést és abban balra haladt tovább. Ezután nincs több log bejegyzés, a targonca nem találta meg a raklapot. 14/05/2013 21:15:05: 14/05/2013 21:15:31: 14/05/2013 21:15:31:
Simulation Started Forklift: Found a corner Forklift: Turning left in the corner
54
A targonca egyszerű működési algoritmusában a kereszteződésekben a továbbhaladási választást előre meg kell adni, amelyben az első kereszteződésnél balra fordulás volt megadva.
6.8 T8: Összetett szimuláció Ebben a tesztben a robot működésbe meghatároztam a kereszteződéseknél a megfelelő irányt, hogy megtalálja a raklapot. A szimuláció sikeresen lefutott és a logból kiderült, hogy a targonca megtalálta a raklapot. 14/05/2013 14/05/2013 14/05/2013 14/05/2013 14/05/2013 14/05/2013 14/05/2013 14/05/2013
21:37:17: 21:37:26: 21:37:26: 21:37:36: 21:37:36: 21:37:45: 21:37:45: 21:37:45:
Simulation Started Forklift: Found a corner Forklift: Turning right in the corner Forklift: Found a corner Forklift: Going ahead in the corner Forklift: Found a pallet Forklift: Stopped Forklift: Lifting up to full
19. ábra: Teszteset kereszteződések kezelésével
6.9 Tesztek értékelése Az alkalmazást viszonylag egyszerűen működésbe tudtam hozni egy új környezetben az alkalmazás által dobott hibák követésével és a megfelelő programok telepítésével.
55
7 Összefoglalás A szakdolgozat feladatommal az R3COP nemzetközi projekt egy részfeladatára kellett megoldást készítenem. A projektben a tanszék autonóm robotokhoz készít tesztelési keretrendszert és ennek egy részfeladatára, a Test execution részre kellett megoldást kidolgoznom. A Test execution egy bemenő modell segítségével felépít és futtat szimulációs teszteket és a szükséges részeket naplózza amely egy elemző alkalmazásnak továbbküldhető. A feladatot hat nagyobb egységre bontottam:
A bejövő modell beolvasása és feldolgozása.
A modell átalakítása az RDS igények szerint.
A modell exportálása a szimulációt leíró nyelven.
A szimuláció futtatása.
A szimulációs napló elkészítése.
A példa szimulációkhoz szükséges entitások elkészítése.
A bejövő modellt szabványos UML modellként határoztam meg és az elkészítéséhez a Papyrus UML modellezőt használtam fel. A modell feldolgozását egy erre alkalmas eszközzel végeztem el, a kialakításánál törekedtem a kontextus könnyű bővíthetőségére. A teljesen általános megvalósítás sajnos nem kivitelezhető az UML modell absztrakt leírása és az RDS sajátosságai miatt. Ezeknek a kiküszöbölésére egy saját belső RDS specifikus Ecore modellt készítettem, amelyen könnyű elvégezni a szükséges módosításokat és a megfelelő eszközzel (Acceleo) könnyen végezhető modell-szöveg transzformáció a szimulációt leíró kód generálására. A naplózó keretrendszer létrehozásánál szintén a bővíthetőséget és az igények szerinti módosíthatóságot tartottam elsődleges célnak. Az R3-COP-ban megadott egyik mintaalkalmazáshoz illesztettem az alkalmazás kontextusát, amely autonóm targoncák mozgását és raklapok pakolását szimulálja. Ehhez létrehoztam a példa szimulációkban megjelenő entitásokat a szegmenseket és raklapokat valamint egy robot amelynek a példához szükséges Mesterséges Intelligenciát adtam. 56
Az alkalmazás felhasználásával egyszerűbb és viszonylag összetettebb szimulációkat állítottam össze, futtattam és elemeztem. Tesztelés során a különböző felhasználói rétegek összes funkciójára létrehoztam példamegoldásokat. Az alkalmazás bővítési lehetőségei között sorolnám fel az R3COP által definiált példa alkalmazás teljes kontextusának felépítését, beleértve a robot mesterséges intelligenciájának a példa igényei szerinti létrehozását. A bemenő UML modell feldolgozásánál feltételeztem az egy Classifier alkalmazását, amely egy osztály példányosítását jelenti. A Papyrus környezetben több Classifiert is definiálhatunk ezzel például egy öröklési lánc elemeiből létrehozott példányt is tudunk kezelni. Az öröklési lehetőséggel a kontextus modellben létrehozhatunk olyan ősosztályokat amelyek tartalmazzák a fontosabb attribútumokat amit az összes entitás használ, például pozíció. Egy másik kényelmi funkció az alapértelmezett értékek bevezetése lehet az UML kontextusba. A mostani állapot szerint nem kezelem az alapértelmezett értékeket így a felhasználónak minden attribútumot fel kell vennie. Ha az UML-RDS leképzésbe belekerülne egy alapértelmezett érték mező minden attribútumhoz akkor ha az alkalmazás nem talál definíciót az adott attribútumhoz magától felvehetné azt így időt spórolna meg a felhasználónak. A naplózás tervezésénél szó esett többféle naplózási megoldásról, amelyből a példákat és a felhasználói igényeket figyelembe véve az egyik megoldást valósítottam meg. Egy bővítési lehetőség olyan naplózási keretrendszer készítése, amely a felhasználó által megadott igények szerint és módon naplózná az adatokat, így az adott példához mindig a felhasználó szerinti legjobb naplózó funkciókat lehetne használni.
57
Irodalomjegyzék Az irodalomjegyzék pontjaiban megjelenő linkek utolsó megtekintésének időpontja 2013.05.10. [1]
Zoltán Micskei, Zoltán Szatmári, János Oláh, István Majzik: A Concept for Testing Robustness and Safety of the Context-Aware Behaviour of Autonomous Systems, http://home.mit.bme.hu/~micskeiz/papers/micskei-trumas-kes-amsta2012.pdf
[2]
Microsoft Robotics Developer Studio, http://www.microsoft.com/robotics/
[3]
MSDN: Microsoft Robotics, http://msdn.microsoft.com/en-us/library/bb881626
[4]
Software Engineering for Robotics, http://swrobotics.codeplex.com/
[5]
MSDN: VPL tutorials, http://msdn.microsoft.com/en-us/library/dd772007
[6]
MSDN: VSE tutorials, http://msdn.microsoft.com/en-us/library/dd772012
[7]
HelloApps: SPL, http://www.helloapps.com/
[8]
Kyle Johns, Trevor Taylor: Professional Microsoft Robotics Developer Studio, ISBN: 978-0-470-14107-6, 2008
[9]
Microsoft Robotics Developer Studio Tutorials, http://www.microsoft.com/robotics/#Learn
[10] Papyrus, http://www.papyrusuml.org [11] Eclipse: Papyrus, http://www.eclipse.org/papyrus/ [12] OMG: XMI: http://www.omg.org/spec/XMI/ [13] Eclipse Modeling Framework Tutorial, http://www.vogella.com/articles/EclipseEMF/article.html [14] Eclipse: UML2, http://www.eclipse.org/modeling/mdt/?project=uml2 [15] Eclipse: Acceleo, http://www.eclipse.org/acceleo/ [16] ProMRDS, http://www.promrds.com/ [17] Eclipse: UML2 Getting Started Tutorial, http://www.eclipse.org/modeling/mdt/uml2/docs/articles/Getting_Started_with_U ML2/article.html [18] Eclipse: documentation, http://help.eclipse.org/juno/index.jsp [19] Acceleo: Getting Started Tutorial, http://wiki.eclipse.org/Acceleo/Getting_Started 58
Függelék A melléklet tartalma és leírása Az alábbi listában a mellékletben lévő főbb mappák és fájlok találhatók meg azok rövid leírásával.
/PapyrusUmlModel: Az Eclipse Papyrus projekt fájlokat tartalmazó mappa.
/PapyrusUmlModel/robot-examples.uml: A Papyrusban létrehozott UML modell.
/RdsLogger: A naplózáshoz szükséges .NET-es class library projekt.
/RdsLogger/RdsLogger/bin/Debug/RdsLogger.dll:
A
naplózás
projektből
létrehozott assembly. Használatához az RDS főkönyvtárának UserData mappájába kell másolni.
/RdsModel: Az Ecore modell projekt fájlokat tartalmazó mappa.
/RdsSimulationHelper: Az UML modellből RDS specifikus modellt létrehozó projekt.
/RdsSimulationHelper/RdsSimulationHelper.config:
RdsSimulationHelper
konfigurációs fájl.
/RdsSimulationHelper/Resources: A modell generálásához szükséges fájlok, többek között az Entitás definíciós SPL fájlok is ebben találhatók, melynek helye a konfigurációs fájlban átállítható.
/RdsSimulationHelper/Resources/InitializedSpl:
A
szimulációs
környezet
inicializálásához szükséges SPL fájl. Helye a konfigurációs fájlban átállítható.
/RdsSimulationHelper/Resources/UmlToRdsMapping: UML-RDS mapping fájl, melynek helye a konfigurációs fájlban átállítható.
/RdsSimulationHelper/Resources/OutFiles: A kimeneti modell XMI fájlok helye, konfigurációs fájlban átállítható.
/RdsSplGenerator: A szimulációs leíró generálását, és a szimuláció futtatását végző projekt fájlokat tartalmazó mappa.
59
/RdsSplGenerator/RdsSplGenerator.config:
RdsSplGenerator
projekt
konfigurációs fájl.
/SPLExecutor: A szimuláció indításáért és az SPL szkript betöltéséért felelős VPL projekt.
/Textures_Meshes: A létrehozott entitásokhoz felhasznált textúrák és mesh-ek. Használatukhoz ezeket az RDS főkönyvtárának /strore/media mappájába kell másolni.
60
