Teleoperáció Robot vezérlése IP-hálózaton Simon Csaba Z56IGL Konzulens: dr. Kiss Bálint Önálló laboratórium 1. Beszámoló 2009. MÁJUS. 17.
1. Bevezetés Önálló laboratóriumi feladatom alapgondolata az volt, hogy az IIT IL406-os laborjában lévő GT6A típusú robotot a helyi IP hálózaton keresztül lehessen vezérelni. Így az oktatóknak nem kell a hallgatókat elvinniük a laborba, illetve a labort lefoglalni, ha prezentálni szeretnék robotok irányítását, vezérlését élő példán keresztül is. Feladatom első sorban, ehhez egy keretrendszer kiépítése volt. A keretrendszer két főbb részből áll: a szerverprogramból (Master.vi), valamint a kliensprogramból (Client.vi). A rendszer a fentebb már említett roboton kívül tartalmazza egy Web-kamerát, ami majd a képi információt szolgáltatja, egy számítógépet, ami központilag vezérli a robotot, a kamerát, és fogadja a távolról bejelentkező klienst. A számítógép alapkövetelménye hogy a belső hálózatra legyen kötve, és fix IP-címe legyen (könnyen megtalálható és elérhető legyen a helyi címtartományból). A robot vezérlését már egy meglévő LabVIEW-ban készült interpreter programmal oldottam meg (bővebb információk [3] forrásban). A vezérlő számítógépre szükséges a National Instruments LabVIEW 6.1-es programja, hogy tudjuk futtatni az Interpreter programot, valamit a rendszerem szerver komponensre is ebben készült. A képfeldolgozáshoz és a kamera kezeléséhez szükséges az IVision 1.5-ös verziója LabVIEW alá. Az IVision képfeldolgozó függvények gyűjteménye, melyhez készítettek LabVIEW alá egy eszköztárat is (a HYTEK Automation, Inc. gondozásában jelent meg). Az rendszer készítése közben a LabVIEW számos távoli elérési módját kipróbáltam, míg a kialakított megvalósítás mellett döntöttem. A rendszer szűk erőforrásának az ethernet hálózat rendelkezésre álló sávszélessége bizonyult. A képek átküldése a hálózaton nagyon leterhelték a rendszerünket, ezért tömörítésre volt szükség, ami viszont a hostként szolgáló Pentium hármas számítógép CPU-ját terhelte meg, mivel valós időben, közel 15 FPS sebességgel, kellett biztosítania a képek tömörítését. A vezérlést megvalósító szabályozási kőrben jelentős késleltetés lép fel, melynek kezeléséről gondoskodnunk kell. Mivel a visszacsatolást a web-kamera képe jelenti, az ember is részt vesz a vezérlésben, hiszen az ő szeme az, ami megítéli, hogy szükség van-e még további irányításra, vagy a robot a kívánt helyen van. Ily módon az ember is részese a szabályozási körnek, ami szintén plusz késleltetést jelenthet (emberi reakció idő), valamint igen kritikus annak eldöntése, hogy a felhasználó által kiadott alapjel, esetlegesen nem a nagy késleltetés miatt kialakult téves megítélés eredménye.
2. Teleoperáció A teleoperációs rendszerek ma is aktív kutatási területet képeznek, számos eredménnyel. Teleoperációról, akkor beszélünk, amikor az irányított (mechatronikai) rendszer relatíve nagyobb távolságra helyezkedik el az irányító személytől, géptől. Tipikus példák a különböző űrszondák, marsjárók, olyan ember nélküli járművek, amiket távolról vezérelnek, de az orvosi robotikában is léteznek, olyan teleoperációs rendszerek, melyben az orvos messziről irányítja a műtőrobotot (pl.: a steril műtőszobán kívülről). A [1] irodalomban olyan modellt állítottak fel, mely erő és gyorsulás jeleket továbbít a beavatkozó felület, és a környezet között, így a rendszer erő-visszacsatoláson alapul. Nézzük az [1] irodalomban is említett egyik egyszerű szabályozási elvet: A modellben három részt különítünk el: - master (G m ): a felhasználó (emberi) oldali rész, ő avatkozik be. A beavatkozó szervek ezen esetben un. haptic interface -k, melyek erő-visszacsatolásra alkalmasak (olyan rendszerek melyek segítségével az kontaktus átvihető az emberi kézre, érezzük a visszacsatolt nyomatékot, erőt) - slave (G s ): a távoli, vezérelt rendszert reprezentáló rész, mely közvetlen kapcsolatban áll a környezettel (enviroment), amit manipulálni szeretnénk. - csatorna (K): a jeleket továbbító közeg. Mind a két irányba külön külön csatornát használunk, különböző késleltetéssel és különböző skálázási tényezőkkel. A rendszer és a csatorna modellezésére: 1. ábra: teleoperációs rendszer modellje
A fenti ábrán az alábbi jelöléseket használjuk: - P m (s): az interface az ember és a rendszer között. Ez kezeli az felhasználók által megadott alapjeleket, utasításokat. - f h : jel a felhasználó által kiadott erőt jelöli. - P s : a távoli rendszerünket írja le. - f e : erő, mellyel be tudunk avatkozni a távoli oldalon. - x m, x e : master és a slave pozíciói - n p és e -stp : mestertől induló csatorna skálázási tényezője, és késleltetése - n e és E -ste : slave-től induló csatorna skálázási tényezője, és késleltetése A master és a slave erő/pozíció átviteli függvényei a következők: ahol az: - m m és m s a master és a slave tömege - k m és k s csillapítási tényezők A master és a slave rendszer is passzívnak tekinthető. Így a K csatorna passzivitásának biztosítása elegendő a rendszer stabilitásához. A passzivitáshoz figyelembe kell venni a késleltetés és skálázási tényezőket. Az ábrán a wave variables névvel jelölt dobozok azon (u m,e ; v m,e ) változókat jelentik, melyeket felírhatunk az alábbi formában: (1) (2) (3) Az u m és v m az ábrán a master oldalon be és kimenő jelek, míg az u e és v e jelek a slave oldalon hasonlóan a be és kimeneti jelek. A csatornában keletkező energiát a következő egyenlettel írhatjuk fel: Törekednünk kell arra, hogy a minimalizáljuk a hibát a slave x e és a master x m pozíciója között. Ennek minimalizáláshoz a bevezetünk egy α paramétert, mely egy adaptív erősítés a master és a slave változói között. α-t felhasználva felírhatjuk a következő összefüggéseket: A fenti egyenleteket felhasználva felírható a csatornában lévő teljes energia: (4) (5) A fenti kifejezésből az energia csak akkor lesz minden késleltetésre pozitív, ha (6) (7)
Látható hogy a késleltetés irányonként eltérő nagyságú, és mind a két irányban időtől függ. Ahhoz hogy minimalizáljuk az x m és x e változókat, hiba felírható, ha a (2), (3) és (4) egyenletekkel behelyettesítünk: (8) A [1+ forrás szerint a α i -nek teljesítenie kell a (7) - feltételt is., választással élve, megfelelően kicsi lesz a hiba. Mivel Gyakorlatban a T változását lehet mérni az alkalmazások többségében, így számítása nem ró újabb terhet a rendszerre. A [1] és *2+ forrásban közölnek még egyéb eredményeket is, melyek felhasználják többek között a csatornák n p és n e skálázását is, mivel nálunk a csatorna IP hálózatban realizálódik, itt nem történik semmiféle skálázás a kimeneten a bemenethez képest. Az egyes csomagokban közölt jelek, nem torzulnak kis mértékben sem a csatornán áthaladva. 3. Kommunikácó LabVIEW-val (TCP/IP) A LabVIEW 6.1 számos módszert kínál arra, hogy a virtuális műszerünket hálózaton esetleg weben keresztül elérhessük: - web szerveren keresztüli elérés. - Communication eszköztár fellelhető kommunikációs protokollokat használó subvi-ok használata LabVIEW, mint Web Szerver A LabVIEW 6.1-es verziója képes web szerverként üzemelni. Ilyenkor a LabVIEW segítségével egy távoli számítógépről vagy webes felületen böngészőből elérhető a gépünkön tárolt virtuális műszereket (VI-okat). Ehhez csak annyit kell tenni, hogy Tools/Options menüben kiválasztjuk a Web Server: Configuration opciót a legördülő menüből. Itt beállíthatjuk, hogy szeretnénk engedélyezni a web servert, valamint néhány paraméterét, mint például hogy mennyi legyen a time out, melyik porton lehessen csatlakozni. Fontos megadni, hogy melyik mappában találja meg a publikálni kívánt VI-okat, valamint a log file helyét. Majd a Web Server: Visible VI almenüben, kiválasztjuk, hogy pontosan melyik nevű VIokat lehessen elérni. Ezeknek kötelező a fentebb kiválasztott mappában lennie. A Web Server: Browser Acces almenüben adhatjuk meg, hogy mely IP címekről engedélyezünk hozzáférést a Web Szerverünkhöz. Továbbá beállíthatjuk, hogy milyen jogosultsága lehet a LabVIEW programhoz csatlakozónak: - Allow Viewing and Controlling engedélyezi a monitorozást és a vezérlést is - Allow Viewing csak monitorozni enged - Deny Acces tiltás. (Ez az alapértelmezett is, ha valaki még nincs beregisztrálva)
Megjegyzendő, hogy sajnos az egyes mai vírusirtók és tűzfalak kártevőnek észlelik a Web szerverünkhöz csatlakozni kívánókat, ezért célszerű ezen programokban külön engedélyeztetni a csatlakozást. Csatlakozás a távoli alkalmazáshoz az Operate / Connect Remote Panel opcióval lehet. Ahhoz, hogy a csatlakozás sikeres legyen szükséges, hogy a VI fusson a szerver gépen. Egy VIhoz több felhasználó is csatlakozhat egyszerre, és figyelhetik az alkalmazás állapotát. Ha valaki állítani is akar valamely vezérlő elemen, akkor jobb gomb Request control opció segítségével megteheti ezt, ilyenkor a többiektől elveszi ideiglenesen a vezérlési jogosultságot a rendszer. Egy időben egyszerre csak egy felhasználó vezérelheti az alkalmazást, a szervergép előtt ülő felhasználó is csak egy néző lesz, ő is ugyanúgy versenyez az alkalmazás használatáért. Ha web böngészőre szeretnénk publikálni az alkalmazásunkat, akkor azt a Tools / Web Publishing Tool segítségével tehetjük meg. itt beállíthatjuk, hogy a weblapon milyen szöveg jelenjen még mega VI alatt és felett, hogy milyen módon szeretnénk hogy lássák a többiek az alkalmazást (Monitor, vagy Embended ilyenkor vezérleni is tudják a távoli felhasználók). Majd a lemezre mentetjük a elkészült honlapot, ugyanis a LabVIEW egy.htm file-t generál. A VI-nak a szerver itt is futnia kell, hogy tudják a távoli kliensek használni. 2. ábra: Böngészőből elérhető LabVIEW program
A megoldás hátránya, hogy nem biztosít semmilyen titkosítást és más védelmet a fentieken kívül, valamint hogy ha képi információk akarunk hasonló módon átvinni (mondjuk egy web kamera képét), akkor az csak úgy lehetséges, hogy a VI kirajzolja a képet egy Picture elemre. Ilyenkor a kirajzolt kép is átmegy a hálózaton, de sajnos bitmap formájában, ami megterhelő a hálózat számára. TCP és UDP protokollok LabVIEW-ban Másik módszer az, hogy az alkalmazásunk közvetlenül ír/olvas a hálózatról. Ezt a LabVIEW Communication Toolbox-ában fellelhető elemek segítségével lehet. Két féle kommunikációt támogat IP hálózaton keresztül: TCP és UDP. Mind a két protokoll byte sorozatot küld át a hálózaton, melyet a LabVIEW stringként (karaktertömbként) kezel. Pontosan be kell állítani a fogadandó adat hosszát, különben a következő jelenség áll elő, ha rövidebb adatot fogadunk, mint azt előre beállítottuk: - dummy adat (memóri szemét) kerül a változó üresen maradt helyére, - a következő TCP olvasás annyival később kezdi el olvasni a neki szánt adatsort, amennyivel kevesebbet olvasott a korábbi olvasás során, azaz az első x db. karaktert figyelmen kívül hagyja. Így célszerű tökéletes szinkronizálót tartani a két program között, azzal, hogy pontosan tudjuk, hogy mikor milyen hosszúságú adatfolyamot küldünk át a hálózaton, különben a küldött és kapott adatok nagyon elcsúsznak egymástól. A TCP és az UDP protokollok kezelésének működése meglehetősen hasonló. TCP kapcsolat építésére az alábbi elemeket használhatjuk fel: - TCP Listen TCP porton való hallgatózás bejövő kapcsolatra várva, - TCP Open Connection TCP kapcsolat nyitása - TCP Read TCP portól olvasás - TCP Write TCP port írása - TCP Close Connection TCP kapcsolat zárása - TCP Open Listener létrehoz egy Listenert, mint a TCP Listen, csak nem vár bejövő kapcsolatra - TCP Close Listener bezárja a Listenert UDP esetén csak négy művelet áll rendelkezésünkre: - UDP Open kapcsolat nyitása egy porton, - UDP Write írás egy UDP portra, - UDP Read olvasás egy UDP portról, - UDP Close kapcsolat zárása.
A TCP kapcsolat kiépítése a következőképen történhet LabVIEWban: A szerveralkalmazás, létrehoz egy Listenert a TCP Listen eszköz segítéségével, és bejövő kapcsolatra vár. Ha beérkező kapcsolatról értesül, akkor a TCP Listen a kimenetén kiad egy kapcsolat azonosítót (Connection ID), a bejövő kapcsolat címét, valamint a portját. Ekkor Majd a TCP Write segítségével adatokat küld a kliensnek, vagy a TCP Read segítségével adatokat fogad a klienstől. A munka végeztével pedig visszatér a várakozó állapotba, és várja az újabb klienst. A kliens a TCP Open Connection segítségével nyit kapcsolatot, majd megkezdi az adást/ fogadást. A végén TCP Close Connection subvi segítségével zárjuk a kapcsolatot. Alkalmazásomban a TCP port mellett döntöttem a következő okok miatt: - TCP csomagok biztosan célba érnek - TCP csomagok sorrendhelyen érnek célba - TCP csomagok hiba nélkül érnek célba A fenti tulajdonságokra azért van szükség, mert a képeket JPEG formátumban továbbítom, és a LabVIEW a JPEG kép mellé szükségeltetik egy ColorTable nevű változó is (szín tábla), amiben leírja, hogy melyik színkód melyik színnek felel meg. Ez az információ szorosan összefügg a képpel, a kép színei jelentősen torzulnak, a kép használhatatlan lesz, ha a ColorTable információ nem áll rendelkezésre, vagy nem a helyes információ áll rendelkezésre. 4. Kép átvitele a hálózaton Mivel vizuális visszacsatolást használ az alkalmazásom nagyon fontos, hogy a képeket hatékonyan küldjük át a hálózaton. A képfeldolgozás a számítástechnikában mindig is erőforrás igényes feladatok közé tartozott. A tanszéken rendelkezésre álló hálózati sebesség az erős tűzfal szabályok miatt 300-400 kbyte-ra tehető. Képi információt egy viszonylag régebbi webkamera szolgáltatja melynek alapértelmezett felbontása 352*288 pixel. Természetesen a kamera tudna nagyobb felbontást is, de mint majd látjuk ekkora méretű video JPEG kódolása és a hálózaton való átküldése is leterheli a hálózatot. Az alábbi táblázatban összefoglaltam mekkora sebességű hálózatra lenne szükség, különböző méretű és minőségű képek átküldésére: A kép mérete Színek száma 15 FPS-hez szükséges sávszélesség FPS (300 kb/s-os hálózaton) 640*480 3 ~13 MB/sec 0.3333 352*288 3 4.3MB/sec ~1 352*288 (Jpeg)* 3 890 kb/sec 5-6 kép/sec 320*240 (Jpeg)* 1 ~13-18kB/sec 20-23
Amint a táblázatból is látszik nagy képek átküldése nem reális követelmény. A webkamerával előállított kisebb képből is jó, ha egyet át tudunk küldeni másodpercenként a kliensnek, igazi vezérlést nem lehet vele megvalósítani. A csillaggal jelölt és kiemelt sorokban lehet látni a tömörített képeket. A tömörítés mérete kb 1:5 volt, melynek köszönhetően sikerült a színes kép esetén 5-6 FPS (Frame Per Secundum) sebességet elérni, ami prezentációs célokra megfelelő, pontos irányításhoz azonban még mindig elégtelen. A laborban rendelkezésre állt, egy 320*240-es felbontású analóg, monokróm kamera, melyet egy a számítógépbe szerelt digitalizáló kártyán keresztül tudtunk elérni. A kamera képe fekete-fehér volt, mely a JPEG kódolásnak köszönhetően még az 1:5-ös tömörítésnél is jobban sikerült becsomagolni. A táblázatban feltüntetett elméleti határt nem sikerült elérni, mivel a szervert futtató számítógép teljesítménye sajnos nem volt elegendő ilyen gyors tömörítéshez. Méréseim alapján körülbelül 13-15 FPS sebességgel mozgott a kép, és volt egy 2-3 másodperces állandó csúszása. A video sebessége most már lehetővé tett pontosabb irányítást is. 3. ábra: A kliens által láttot kép. Általánosságban megjegyezhető, hogy szerencsésebb lenne az egész videostreamet valamilyen módon tömöríteni, például MPEG kódolással, mivel ez figyelembe venné az egymás utáni képekben rejlő redundanciát, és ennél nagyobb felbontású jobb minőségű képek átküldésére is lehetőségünk lenne, sajnos a LabVIEW ezt nem támogatja, így c vagy c++ kódban kellene ezt implementálni. A képfeldolgozás általam használt pontos menetét az elkészült rendszer menüpont alatt ismertetem bővebben.
5. Elkészült rendszer Az alábbiakban ismertetem az keretrendszer elkészült komponenseit. Master.vi 4. ábra: Master.vi front panelje A Front Panelon látható vezérlők, és megjelenítők: - Picture: a kamera által szolgáltatott kép. - Camera Index: a szervez számítógépéhez csatlakoztatott kamerák közül ezen sorszámút használja az alkalmazás. - Incoming Message: ide írja ki a klienstől kapott utolsó parancsot - Image Sent!: mérőszám, mely számolja az elküldött képek mennyiségét (hálózati forgalomanalízisre használható) - Exit: kilépés - Error in és Error out: A különböző komponensekhez tartozó hiba kimeneteket jelenítik meg. (Error out 5 bejövő kapcsolat esetleges hibája, Error out 3 képfeldolgozás hibája, a error in bejövő hiba, error out a rendszer kimenő hibája). - colortable: A képhez tartozó színtérkép - flattened image data: a képpontok adatai egydimenziós tömbbe elhelyezve.
A master működése a következő: - Feltételezi, hogy a robotot futtató Interpreter program (GT6A Interpreter) már fut, ha nem akkor hibával leáll. - Mivel a kamerát automatikusan indítja már indulás előtt be kell állítani a kamera indexét - Sikeres indulás után, bejövő kapcsolatra vár, és mutatja a kamera képét - Bejövő kapcsolat esetén, elkezdi adni a képi információt és fogadni a robotnak szánt irányító parancsokat. A robotot irányítja a parancsnoknak megfelelően. Bejövő kapcsolat esetén a képről információt tartalmazó indicatorok frissülnek, az Image Sent! kijelző is számolni kezdi a képeket. - Kapcsolat bontása után újabb kapcsolatra vár. Master.vi megvalósítása: A program három párhuzamosan futó while ciklusból áll. Ezek a kamera képének felvevése, és kódolása, a kép átküldése a hálózaton, és a robotvezérlő parancsok futtatása funkciókat valósítják meg. A kép feldolgozása és JPEG kódolás: 5. ábra: Kép feldolgozása A fenti ábrán látható, hogy először a kamerát inicializálja a program, majd el is indítja. A kódolást az általam készített GetPicture.vi végzi. A képet, a hozzátartozó ColorTable-t, valamint a kép méretét tartalmazó clustert egy case szerkezet segítségével szinkronizálva adom át egy-egy lokális változónak (indicatornak), így nem fordulhat elő, hogy a képhez nem a hozzá tartozót ColorTable-t rendeljük kirajzolásnál. 6. ábra: JPEG kódolás
A bemenetül kapott Camera Session Reference segítségével snap shot képet csinál a kameráról, majd lementi JPEG formátumban, amit egy JPEG olvasó beolvas, majd a JPEG kép paramétereit kiküldi a kimenetre (a képet tartalmazó egydimenziós tömböt, melyben a kép adatai sorfolytonosan helyezkednek el (flattened image data), a pozícióját és méretét (rect), és a (ColorTable) színinformációkat. A képküldést megvalósító ciklus: 7. ábra: kép küldése A kép küldését a szerver a 19850-es porton végzi. Ciklusba lépve TCP Listen eszköz segítségével, kapcsolatra vár. Majd ha kapcsolat nyílt, akkor a belső ciklus kiolvassa a lokális változóban kapott ColorTable (színtábla), flattened image data (a kép maga), imagerectangle (a kép pozíciója és mérete) értékeket. Egy for ciklus leszámolja a ColorTable-ben található színek számát, majd egyesével az egyes színekhez tartozó integer értékeket átalakítom stringekké, amiket ciklusonként hozzáfűzöm a már kész stringhez (piros keret a fenti ábrán). Ezzel párhuzamosan összeállítok egy TCP csomagot,mely a kép méretét, a képet tartalmazó egydimenziós tömb méretét, a stringgé alakított ColorTable méretét, tartalmazza. Ezt neveztem el Start keretnek, minden kép küldése ezzel a kerettel indul (zöld kerettel jelölt rész). A keretet elküldés előtt feltöltöm még fix 32 karakter hosszúra. Az első keret után küldöm el ColorTable-t, majd a képet, végül egy záró frame-t, mely az //End// stringet tartalmazza. A belső ciklus egészen addig fut, míg a kliens nem bontja a kapcsolatot. Ekkor a master is zárja a kapcsolatát. A külső ciklusban szereplő TCP Listen timeout ideje 1 másodperc. Ilyenkor a case szerkezet TRUE ága fut le, azaz jelzi, hogy a várakozás közben hiba történt. Ha ez a hiba a Connection timed out, Connection closed, vagy a Connection is not connect, akkor a hibát jelző flaget FALSE-ra állítjuk, majd újrakezdődik a kapcsolatra való várakozás.
LabVIEW kódban: 8. ábra: a Timeout lekezelése A robot vezérlése: 9. ábra: Robot vezérlése a Master.vi-ban A robot vezérléséhez ugyancsak egy TCP csatornát nyit a program, és várunk a csatlakozásra. Ehhez a 19851-es portot használja. Miután valaki kapcsolódott, egy while ciklusban folyamatosan olvassa a bemenetet, és a kapott parancsokat feldolgozza. Ez két fajta parancs lehet: - Joint+X, és Joint-X, ahol X a csukló száma, a + és az tengelykörül forgás irányát jelentik. Ez a parancs a robotot csuklónként vezérli. Mindegy egyes parancs 1 fokkal forgatja odébb a robotot. A robot vezérlését a *4] irodalomban is felhasznált robotvezérlő subvi-t használtam. - NOOOOOP: nem érkezik parancs. Ezt a kliens küldi, mikor nem adnak ki vezérlést.
Client.vi 10. ábra: Client.vi front panel A Client.vi kezelői felülete: - Report Messages: esetleges hibaüzenetek megjelenítése, hálózatról érkező információk megjelenítése - Address: a szerver IP címe, melyhez csatlakozni kívánunk - Tengelyek: a csuklókat ezen gombok segítségével lehet vezérelni - Exit: Kilépés - Joint Command: a kiadott csuklóparancsok száma - First Frame: az elsőként kapott keret tartalma (a kép metaadatai) - ImageFlattenedData: A kép képpontjainak értéke egydimenziós tömbben tárolva - Error out: hiba kimenet A kliens működése a következő: - Indítás elött meg kell adni a Szerver IP címét - Indítás után megjelenik a szerver által szolgáltatott kép - Robot kész a vezérlésre, a gombok segítségével - Exit gombra kiléphetünk A Client.vi két párhuzamos while ciklusból áll. Az egyik while ciklus fogadja a képeket szervertől, a második pedig a felhasználó parancsait továbbítja a szerver felé.
A képeket fogadó program részlet: 11. ábra: Kliens program képeket fogadó részlete A kliens indításkor megkísérel kapcsolatot nyitni a szerveralkalmazással, amennyiben sikerül egy végtelenített ciklus segítségével minden körben egy képet olvas ki a hálózatról és rajzol ki az alábbi lépésekben: - Első lépésben megkapja a Start frame-t, amely a Start/ prefixummal kezdődik. Majd sorba kinyeri a képhez szükséges információkat (kép helye és mérete, ColorTable mérete) (piros kerettel jelölt rész) - Visszaállítja a második csomagból a ColorTable-t (zöld kerettel jelölt rész) - Megkapja a képet, melyet a korábban kapott információk segítségével kirajzol (kék keretes rész). - Fogadja a zárókeretet (//End//) - Ha a kapcsolat megszakadt, vagy valaki a stop gombot megnyomta akkor kilép a ciklusból és bontja a kapcsolatot (így nem marad félig nyitott kapcsolat) A vezérlési információkat elküldő programrészlet: 12. ábra: robotot vezérlő parancsok elküldése
A blokkséma működése: - Egy string tömbben tárolódnak a parancsok - Az parancsok továbbítása a TCP 19851-es porton történik - A while ciklus elején található huzalozás választja ki a gombnak megfelelő parancsot - Ha nincs lenyomva gomb, akkor a NOOOOOP üzenetet továbbítódik - Exit gomb hatására a ciklus leáll, a kapcsolat bezárásra kerül 6. Továbblépési lehetőségek A továbbiakban szeretném javítani a kép továbbításának hatékonyságát, melyhez a korábban már említett MPEG kódolás egy jó megoldást nyújthat. IP kamera használata tovább gyorsítaná a rendszert. Ez a fajta kamera, ugyanis hardveresen támogatja a hálózatra történő képfolyamok továbbítását, valamint beágyazott szoftvereinek köszönhetően gyors tömörítési eljárásokat is biztosít. Ezzel levehetnénk a tömörítés és továbbítás terhét a Host számítógépről. A beszámoló elején említett szabályozások implementálása is szükséges még, melyeket alkalmazva bonyolultabb mozgásokat is előírhatunk a robotnak. Több fajta szabályozási mechanizmus implementálásával lehetőségünk nyílna azok összehasonlítására is. Az önálló laboratóriumi munka során foglalkoztam azzal is, hogy egy gamepad segítségével vezéreljük a robotot. Sajnos a gamepad a munka közepén tönkre ment, javítása után pedig kiderült, hogy LabVIEW 6.1 alatt a gamepad kezelése a rendelkezésre álló eszközökkel nem lehetséges. LabVIEW 6.1-hez nem rendelkeztem olyan szoftvercsomaggal, ami egy USB eszköz meghajtását lehetővé tette volna. Ezért a Microsoft DirectX SDK-ban lévő Direct Input függvénykönyvtár segítségével c++ függvényt írtam a Gamepad kezeléséhez, majd sikerült olyan formátumban a kapott kódot lefordítani, hogy az a LabVIEW Call Library Function Node eszközének segítségével futtatni tudtam. (A Call Library Function Node subvi egy olyan függvényhívást tesz lehetővé, ami egy c vagy c++ kódban írt függvényt egyszer meghív adott paraméterekkel.) A gamepad csak akkor ad vissza helyes információt a vezérlői állapotáról, ha az inicializálása során a gombok és pöckök alap állapotban állnak. Így egyetlen függvényből nem hívható meg a gamepad kezelő program, mivel ekkor minden egyes függvényhíváskor inicializálnánk, lekérdeznénk, majd bezárnánk az eszköz kezelőjét. Sajnos a LabVIEW 6.1 olyan c vagy c++ függvényeket tud csak meghívni, amelyek paraméterei és visszatérési értékei az alap típusok (integer, string, char, tömb) közül kerülnek ki. Nem támogatja a c vagy c++ programok párhuzamos futtatását, és a velük történő kommunikációt (közös memória területen keresztül, vagy referenciák átadásával, vagy memória terület átadásával) sem. Érdemes lehet megvizsgálni, hogy egy modern negyedik generációs programnyelvben megírt program (például.net) képes e kommunikálni a Master.VI-jal a TCP protokollon keresztül. Ha képes, akkor egy alkalmas.net nyelvvel megírt programmal lehet helyettesíteni a kliens programját.
7. Képjegyzék: 1. ábra: teleoperációs rendszer modellje forrás: Irodalom *1+... 3 2. ábra: Böngészőből elérhető LabVIEW program... 6 3. ábra: A kliens által láttot kép.... 9 4. ábra: Master.vi front panelje... 10 5. ábra: Kép feldolgozása... 11 6. ábra: JPEG kódolás... 11 7. ábra: kép küldése... 12 8. ábra: a Timeout lekezelése... 13 9. ábra: Robot vezérlése a Master.vi-ban... 13 10. ábra: Client.vi front panel... 14 11. ábra: Kliens program képeket fogadó részlete... 15 12. ábra: robotot vezérlő parancsok elküldése... 15 A meg nem jelölt forrású képeket magam készítettem! 8. Felhasznált irodalom [1] Moussa Boukhnifer and Antoine Ferreira: Passive Bilateral Control of Teleoperators under Time Delay and Scaling Factors 44th IEEE Conference on Decision and Control, and the European Control Conference; Seville, Spain, December 12-15, 2005 [2] A. Aziminejad, M. Tavakoli, R.V. Patel, M. Moallem: Stability and performance in delayed bilateral teleoperation: Theory and experiments Control Engineering Practice, journal, homepage: www.elsevier.com/locate/conengprac 2008 may [3] Kiss György: LabView alapú virtuális betanítópult megvalósítása és robotprogram generálása képi információk alapján Szakdolgozat, BME Irányítástechnika és Informatika Tanszék (2008. december) [4] Simon Csaba: Szenzorcsatolt robot irányítása LabVIEW környezetben Szakdolgozat, BME Irányítástechnika és Informatika Tanszék (2008. december)