2. fejezet - Robot keretrendszerek

Az RT-middleware (Robot Technology Middleware) egy olyan technológia, amely implementálja a komplex robot rendszerek készítéséhez szükséges elemeket. Segítségével egyszerűen készíthetünk, majd később üzemeltethetünk térben elosztott rendszereket. Mindezeket újrahasznosítható, szabványosított komponensekkel, kommunikációs csatornákkal, programozói API-kal, automatizmusokkal és eszközökkel teszi lehetővé.

A robotika területén a robot rendszerek feladata gyakran változhat. Ha ez a cél vagy maga a környezet gyakran változik, akkor újrahasznosítható, újra konfigurálható komponensek szükségesek, valamint egy azokat üzemeltető keretrendszer, amely tudja ezen változásokat kezelni. Az ilyen komponensek és a keretrendszer fejlesztése speciális programozói ismereteket, tapasztalatot igényel. Ezen implementáció során használhatunk már meglévő általános célú keretrendszereket (pl. CORBA), továbbá számos programozói nyelvet használhatunk, melyek döntően befolyásolják ezen munka nehézségét, idejét. Egy teljesen új robot keretrendszer implementálása az alapoktól bonyolult feladat, és több verzió szükséges a megfelelő eléréséhez. Egy létező keretrendszer alkalmazása, és annak a testre szabása jelentősen lerövidíti a fejlesztés idejét, bonyolultságát.

A keretrendszerek (framework) és a köztes rétegek (middleware) népszerűsége egyre nő, ez gazdag funkció készletüknek köszönhető, azaz a gazdag funkció készletének, így használatukkal könnyedén és gyorsan tudunk komplex rendszereket létrehozni. Robot meghajtókat használva robot keretrendszerből egy komplex és hatékony robot rendszert tudunk létrehozni viszonylag kevés munkával. Legtöbb esetben a robot rendszerek létrehozása valójában csak egy általános robot keretrendszer paramétereinek beállítása az adott célra.

Amennyiben egy létező kertrendszerhez csupán néhány funkció szükséges egyszerűen kiterjeszthetjük azt. Ezen kiegészítése a létező rendszernek sokkal könnyebb feladat, mint egy új implementálása a kezdetektől, mert az ilyen jellegű rendszerek tervezése, és implementálása speciális ismereteket és tapasztalatot igényel. Legtöbb esetben a hiányzó funkciók könnyen beágyazhatóak, ha a létező keretrendszert erre felkészítették, készítésénél gondoltak erre.

A robotika területén számos olyan elem van, amely hasonló tulajdonságú, azonos csoportba sorolható. Ezért a robot keretrendszer koncepció - mint egy általános keretrendszer, mely testre szabható, vagy kiterjeszthető – helyénvaló, sőt célszerű. Valószínűleg nem létezik és nem is lehet olyan robot keretrendszer készíteni, amely mindet igény maradéktalanul kielégít

Ebben az alfejezetben először felderítjük a robot rendszerekkel szemben támasztott követelményeket, majd megvizsgáljuk a jelenleg elérhetőeket (YARP, OpenRDK, OpenRTM-aist és ROS), hogy mennyire elégítik ki a támasztott követelményeinket. Végül ezen fejezet végén egy táblázatban foglaljuk össze a ROS és Openrtm-aist tulajdonságait.

Robot middleware egy olyan szoftver köztes réteg, egy olyan keretrendszer, amely kiterjesztik az általános célú kommunikáció middleware-eket, mint a CORBA vagy ICE. Számos eszközt, könyvtárat, API-t, és leírást biztosítanak a robot komponensek és robot rendszerek létrehozásához és üzemeltetéséhez. A robot köztes rétegek, mint a ragasztó fogják össze a robot részeket, megteremtik a kapcsolatot közöttük transzparens módon.

Definiáljuk először a követelményeket a robot rendszerekkel szemben, és azok aktorait. Általában a robot rendszerek felhasználói két nagy csoportba oszthatóak: a vég-felhasználók, és a komponensek fejlesztői. Minden robot keretrendszernek ezen két csoport munkáját kell támogatniuk eszközökkel és mechanizmusokkal.

A Robot keretrendszerek főbb használati eseteit a 21. ábra szemlélteti. Ezeket a használati eseteket megvizsgálva azonosíthatunk néhány funkcionális követelményt. A komponens fejlesztő megtervezi a robot komponens szerkezetét, kapcsolódásait más komponensekhez, majd implementálja azokat. A megvalósításhoz különböző operációs rendszer, és programozói nyelv támogatása célravezető. Olyan eszközök szükségesek továbbá, melyekkel a komponensek váza vagy akár félkész komponensek generálhatóak a gyorsabb fejlesztés érdekében. A fejlesztők fő tevékenysége az osztály vázak generálása, üzleti logika implementálása, fordítás, majd végül a tesztesetek futtatása. Természetesen a fejlesztők, mint végfelhasználó tesztelik is az általuk készített komponenseket, de ekkor a másik szerepkörben tevékenykednek. Összefoglalva a fejlesztő szemszögéből a következő lényeges igények azonosíthatóak:

A fejlesztő aktorral ellentétben a végfelhasználónak nincs (és nem is kell, hogy legyen) semmilyen programozói ismerete. Ez a felhasználó csoport csak használni akarja a komponenseket a munkájához. A lehető legkevesebb komponens és rendszer paramétert kell, hogy ismerje. A robot rendszerével szép grafikus felületen és vizuális segédekkel keresztül kapcsolódik. Két fő célja van: saját, komplex robot rendszerek kialakítása az elérhető komponensek felhasználásával (azok mentése) és az előzőleg létrehozott saját robot rendszerének üzemeltetése. A saját robot rendszer létrehozása gyakran magában foglalja az elérhető robot komponensek felkutatását is, amely során információkat szerez arról (hozzáférés, név, leírás, verzió, ...). Ezek a hozzáférési információk erősen függenek a robot keretrendszertől. Általában szimbolikus nevekkel hivatkozhatnak a felhasználók az elemekre, de valójában a hoszt IP címe és TCP/UDP portja azonosítja azokat. Sajnos a legtöbb keretrendszer csak az online komponenseket támogatja, így azoknak futniuk kell, és regisztráltnak kell lennie a saját rendszer szerkesztésének időpontjában.

A végfelhasználó regisztrálja (elérhetővé teszi) a komponensét, így elérhetővé teszi azt saját maga és más végfelhasználók számára. Regisztráció után az már elérhető lesz a saját robot rendszer kialakítása során. A robot rendszer futtatása közben szeretné ezt vezérelni, paramétereit változtatni.

Összegezve a végfelhasználó a következő követelmények támasztja a robot keretrendszerekkel szemben:

Összefoglalva egy robot keretrendszernek egy hatékony API-n keresztül kell a szolgáltatásait nyújtania, lehető legtöbb automatizmust kell elvégezni lehetőleg transzparens módon, minél több operációs rendszert, és programozó nyelvet kell támogatnia. Egyszerűnek kell lennie továbbá, hogy elterjedjen, népszerűvé váljon.

Az egyik osztott rendszer a robot rendszerek fejlesztésére az OpenRDK (információ, és a robot rendszer elérhető a [1] helyen található, a koncepciót Calisi et al vezette be [2] ). Ágensekből építhetjük fel a komplex rendszerünket, ami valójában egy egyszerű processz. Ezen ágenseken belül modulok futhatnak, melyek egy fonálban futnak. Minden modul rendelkezik egy tárolóval (repository), melyben a belső tulajdonságait menedzselheti. Ágensek közötti ( inter-agent = inter-process) kommunikációnak két fajtáját támogatja: a tulajdonságok megosztását, és az üzenet küldést.

Rendelkezik egy RConsole nevű grafikus eszközzel, amely a távoli modulok felderítését és vezérlését segíti. Ez az eszköz segítségére lehet mind a fejlesztőnek hibakeresésnél, mind a végfelhasználónak az üzemeltetés során. Valójában ez egy speciális ágens, melynek grafikus felülete van.

Másik robot platform a YARP (Yet Another Robot Platform, hivatalos információ oldala [3]). Itt a kommunikáció Observer tervezési mintán alapszik. Minden kapcsolatnak típusa van, melyek a következők lehetnek: TCP, UDP, MCAST, osztott memória. A portokon forgalmazott adatok SHA256 alapú titkosítással védettek lehetnek. Ebben a rendszerben a portokat kell egy központi név szerverbe regisztrálni egyedi névvel. A YARP név szerver, ami maga is egy speciális YARP port, nyilvántartja az összes többi YARP port kulcs mezőit string formátumban.

A harmadik fontos robot keretrendszer az OpenRTM-aist (információs oldala [4]). Koncepcióját a [5], [6], [7] vezették be Ando et al. Itt is a komponenseket használhatjuk osztott módon, melyeket regisztrálni kell egy közös név szolgáltatóba (CORBA eszköze). A komponensek modulokból állhatnak, melyeket bármikor betölthetünk. A keretrendszer egy tervezési mintákat használó, robosztus rendszer, mely tudása kiemelkedik a többiekhez viszonyítva. A rendszerünk komponensei azonos jogokkal rendelkeznek, nincs központi logika (CORBA név szolgáltatás van csak). A komponensek egymással a portokon keresztül kommunikálhatnak, melynek két fajtája van.

Az adatportok aszinkron kommunikációt biztosítanak, míg a szerviz portok segítségével a másik port szolgáltatásait érhetjük el. a szerviz portok használatát nehezíti, hogy az elavult Corba technológia ismerete szükséges hozzá. A komponensek összekapcsolását a végfelhasználónak kell elvégeznie a grafikus felület segítségével. A fejlesztőknek ez egy kényelmes állapot, mely gépi modellt kínál, csupán felül kell definiálni a megfelelő metódust. Számos operációs rendszert és programozó nyelvet támogat. Véleményem szerint a világon a második legnépszerűbb robot keretrendszer (Japánban az első).

Az utolsó robot keretrendszer a ROS (Robot Operating System), amelyet a készítői operációs rendszernek neveznek, de hasonló szolgáltatásokat biztosít, mint az eddig vizsgáltak (fórum, dokumentáció a [8] oldalon található, felépítését, és működését Quigley et al vezették be [9]). Itt is a robot rendszerünk elemeit kell egy központi szerverre regisztrálni, de itt ROS node-nak nevezik. Maga a rendszer nem engedi tovább osztani a node-okat, de a mások által fejlesztett nodelet csomag lehetővé teszi "csomópontocskák" létrehozását, azaz algoritmusok, melyek egy processzen belül futnak. Saját központi processze van (roscore file, amely a ros master, és a rosout node-okat hozza létre), amely biztosítja a központi loggolást, és egy osztott, közös paraméter készletet. Ennek a központi logikának folyamatosan futni kell, a rendszerünk üzeme alatt. A csomópontok egymással kommunikálni aszinkron módon üzenet küldéssel, vagy szinkron módon szerviz hívással tudnak. A csomópontok kapcsolódása automatikus, azaz ha elérhető az a folyamat, amely meghirdette a topic-ot, és amelyik érdeklődik az iránt, úgy azok összekapcsolónak a roscore API-ját használva. A fejlesztők munkáját maximálisan támogatják, a végfelhasználókét kevésbé. A legnépszerűbb mind a robotgyártók, mind a robot komponenseket fejlesztők körében.

Mind a négy keretrendszer esetében valamilyen fogalmat használnak osztottan, ami vagy ágens, vagy port, vagy komponens, vagy node. Bár a YARP a kommunikációra több lehetőséget biztosít, addig az eszköz készlete sajnos csekély. Míg az OpenRDK és YARP fejlesztése leállt, addig az OpenRTM-aist és ROS rendszerek hódítanak szerte a világban. A továbbiakban ezen két robot keretrendszert állítjuk egymás mellé, és hasonlítjuk össze részletesebben.

A fejlesztő szemszögéből a komponens programozását segítő eszközök meglétét és a szükséges ismereteket vizsgáljuk meg. Megnézzük, hogy a két rendszer esetében mi jellemzi egy új projekt, majd a projektben egy új komponens létrehozását.

Az OpenRTM-aist a végfelhasználónak mindenképpen több lehetőséget ad, mint más robot rendszerek. Biztosítja a komponensek cseréjét a robot rendszer struktúrájának kialakítására, az egyes komponensek paramétereinek beállítását és annak vezérlését. A rendszerhez mellékelnek parancssori eszközöket rtc_shell csomagban, amelyek Phyton scriptek, valamint egy Eclipse plugint egy rendszer szerkesztőt. A 24. ábra szemlélteti a képernyő képét.

Az ábrán bal oldalt az elérhető komponenseket, mellette középen a robot rendszerünk topológiáját, jobb szélen pedig a komponens fontosabb tulajdonságát láthatjuk ez - bár mérete elég nagy, és grafika képességei limitáltak - mindenképpen egy hatékony rendszer felügyeleti eszköz. A végfelhasználó bármikor el tudja indítani vagy leállítani a robot rendszerét, vagy annak bármelyik komponensét. Ha ez a felület nem volna elegendő, akkor lehet újat fejleszteni, de rendszer ilyen mélyen nincs dokumentálva, így a forrás kódokat kell elemezni.

ROS esetében kevés eszköz áll a végfelhasználó rendelkezésére, sőt valójában a fejlesztő eszközöket használhatjuk csak. Van ugyan néhány grafikus felületű eszköz, amelyek qt-ben implementáltak, de ezzel csak a log üzeneteket tudjuk megjeleníteni, a rendszer felépítését tudjuk megjeleníteni. Létezik egy külső komponens család a Robot Web Tools, amely egy Java script gyűjtemény és egy Python szerver alkalmazás, mellyel egy böngészőből lehet a robotokat megfigyelni, de ehhez még saját fejlesztés szükséges.

Az OpenRTM-aist a végfelhasználónak több lehetőséget biztosít grafikus felületeken keresztül, de a fejlesztéséhez több ismeret szükséges. Olyan esetekben, amikor a kutató személy több lehetőséget, megoldást szeretne használni, optimálisabb megoldás a ROS-nál. A több programozói nyelv, és operációs rendszer miatt szélesebb körben alkalmazható. Sajnos a dokumentáció hiánya, és a meglévő komponensek részleges japán nyelvű dokumentációja miatt nem tud igazán elterjedni. A több operációs rendszer támogatását előnyként említettük, azonban hátrányt is jelent, hiszen ha olyan rendszert szeretnénk építeni, amely komponenseit megtaláltuk, de azok nem képesek azonos rendszeren futni, akkor csak ezért kell több számítógépet üzemben tartani. A fejlesztők számára több lehetőséget biztosít, azonban sokkal több ismeret és tapasztalat szükséges a kihasználásához. Az OpenRTM-aist példa projektjeiben sok hasznos dolgot találhatunk, de mivel nincs leírva, nekünk kell megkeresni. A rendszernek aktív japán közössége van, de a kérdések és a válaszok sok esetben csak japánul érhetőek el.

A ROS használata javasolt autonóm rendszerek esetén, amikor a komponensek automatikus kapcsolódása törvényszerű. Ilyenkor nem kell grafikus felület. A meglévő komponensek között megtaláljuk a szükségeset, mivel általában kis méretűek, ezért megismerésük, kiterjesztésük nem okoz nagyobb problémát. Kezdő fejlesztőként a ROS komponens létrehozása lényegesen egyszerűbb, hiszen nem is szükséges osztályt létrehoznunk, elég csak használni a meglévőket. Itt is igaz a kevesebb, sokszor több elv. Folyamatosan fejleszti egy aktív közösség, melynek köszönhetően a hetedik verziót számlálja. Aktív fórum oldala van, ahol kérdéseinkre gyorsan kapunk válaszokat.