robotszimulációs leírók automatizált létrehozása és...
TRANSCRIPT
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 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
2 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 Acceleo ....................................................................................................... 21
3 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
4 Implementáció ....................................................................................................... 31
4.1 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 Az alkalmazás felépítése ................................................................................. 45
4.7.1 RdsModel .................................................................................................... 45
4.7.2 RdsSimulationHelper .................................................................................. 45
4.7.3 RdsSplGenerator ......................................................................................... 47
5 Az alkalmazás használata .................................................................................... 48
5.1 Egyszerű felhasználó ...................................................................................... 48
5.2 Alkalmazás fejlesztő ....................................................................................... 50
6 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
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
7 Ö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.
7
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.
8
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.
9
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.
10
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
11
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á.
12
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]
13
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]
14
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
15
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
16
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.
17
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 .NET-
bő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 Leírás
EntityState Entitás állapot ServiceContract Kapcsolódó entitások InitError Inicializálási hibák Flags Renderelő feltételek Parent/Joint Több komponens összetétele Position X,Y,Z [m] Rotation Euler szög [deg] Meshes Az entitáshoz rendelt Mesh MeshRotation A Mesh elforgatása
18
MeshTranslation A Mesh eltolása MeshScale Mesh skálázása Shapes 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.
19
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.
20
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.
21
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.
EDataType Egy attribútum típusát reprezentálja, pl float, int.
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.
22
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.
23
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
24
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
25
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
26
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.
27
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.
28
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.
29
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).
30
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.
31
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.
32
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.
33
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).
34
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.
35
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
36
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</EntityType> <CreateString>AddNewEntity</CreateString> <Renderable>True</Renderable> <BehaviourFileName>Segment.txt</BehaviourFileName> <Attribute> <UmlName>IsKinematic</UmlName> <RdsName>IsKinematic</RdsName> <IsRdsEntityAttribute>True</IsRdsEntityAttribute> </Attribute> <Attribute> <UmlName>Color</UmlName> <RdsName>Color</RdsName>
37
<IsRdsEntityAttribute>False</IsRdsEntityAttribute> </Attribute> <Attribute> <UmlName></UmlName> <RdsName>Length</RdsName> <IsRdsEntityAttribute>False</IsRdsEntityAttribute> </Attribute> </Entity>
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
38
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
<Attribútum> 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 <Length> 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);
39
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 Acceleo-
t 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:
40
AddNewEntity seg1 /IsKinematic: true /Color: 0 0 0 1 /Position: 0.0 0.009999999776482582 5.0 /Orientation: 0 -180.0 0 AddBoxShape /Dimensions: 10.0 0.001 0.2 /Mass:0.1 /DiffuseColor: 0 0 0 1
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 <Length> 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
41
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()); } }
42
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() + ": " + line + Environment.NewLine); }
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 17:32:00: Simulation Started 12/05/2013 17:32:20: Forklift: Found a pallet 12/05/2013 17:32:20: Forklift: Stopped 12/05/2013 17:32:20: Forklift: Lifting up to full 12/05/2013 17:33:11: Forklift: Found a corner 12/05/2013 17:33:11: 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.
43
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 5.0 /Orientation: 0 -180.0 0 AddBoxShape /Dimensions: 10.0 0.001 0.2 /Mass:0.1
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
44
d1 = value.DistanceMeasurements[0] d2 = value.DistanceMeasurements[90] d3 = value.DistanceMeasurements[180] d4 = value.DistanceMeasurements[270] if (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
45
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 <Name> 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).
46
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.
47
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 package-
ekbő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.
48
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 álló elemkészletből szeretnénk
szimulációs teszteseteket felépíteni.
49
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"
50
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:<Radius> /Mass:20
Felépítéséhez egy egyszerű gömb formát használtam, melynek sugarához a
<Radius> 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).
51
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</EntityType> <CreateString>AddNewEntity</CreateString> <Renderable>True</Renderable> <BehaviourFileName>Ball.txt</BehaviourFileName> <Attribute> <UmlName>Radius</UmlName> <RdsName>Radius</RdsName> <IsRdsEntityAttribute>False</IsRdsEntityAttribute> </Attribute> <Attribute> <UmlName>Texture</UmlName> <RdsName>DefaultTexture</RdsName> <IsRdsEntityAttribute>True</IsRdsEntityAttribute> </Attribute> </Entity>
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).
52
18. ábra: A szimulációban megjelenő új labda entitás
53
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.
54
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 mesh-
eket é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 20:45:00: Simulation Started 14/05/2013 20:45:20: Forklift: Found a pallet 14/05/2013 20:45:20: Forklift: Stopped 14/05/2013 20:45:20: 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: Simulation Started 14/05/2013 21:15:31: Forklift: Found a corner 14/05/2013 21:15:31: Forklift: Turning left in the corner
55
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 21:37:17: Simulation Started 14/05/2013 21:37:26: Forklift: Found a corner 14/05/2013 21:37:26: Forklift: Turning right in the corner 14/05/2013 21:37:36: Forklift: Found a corner 14/05/2013 21:37:36: Forklift: Going ahead in the corner 14/05/2013 21:37:45: Forklift: Found a pallet 14/05/2013 21:37:45: Forklift: Stopped 14/05/2013 21:37:45: 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.
56
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.
57
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.
58
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-amsta-
2012.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
59
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.
60
/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.