% !TeX root = ../thesis.tex %---------------------------------------------------------------------------- \chapter{Felhő alapú robot vezérlés} \label{chapter:ursim} %---------------------------------------------------------------------------- A negyedik ipari forradalom az "okos" gyártásról szól. A korábban helyileg telepített számítási erőforrásokat felhasználó előre meghatározott, kötött gyártás irányítást leváltja a \gls{felho} alapú folyamat irányítás és optimalizálás. Itt már nem csak a gyártás a lényeg, a folyamatok elemzésével és mély megértésével a hangsúly a precíz optimalizációra és produktivitás növelésre hegyeződik ki. Ehhez felhasználják az ipar legújabb vívmányait: Egyre nagyobb teret hódít az Ipari \acrshort{iot} (\acrshort{iiot}), a mesterséges intelligencia és gépi tanulás, a gép-gép kommunikáció, valósidejű adatgyűjtés, \textit{Big Data} és még sok minden más\cite{whatisindustry4}. A robotvezérlés precíz időzítést igényel, hiszen itt pár-tíz milliszekundumos eltérések akár katasztrofális következményekkel járhatnak. Éppen ezért sokáig a robotok közvetlen vezérlésének kiszervezése a felhőbe nem volt megoldható. A peremhálózati rendszerekkel viszont ez megváltozhat. Ez az alkalmazás a peremhálózati rendszerek alacsony késleltetését aknázza ki. Hiszen a robotika vezérlésnél fontos a precíz irányítás, úgy vélem itt különösen jól alkalmazható ez a technológia. A peremhálózati rendszereknek hála tovább csökkenthetővé válik a gyárakban helyben telepített informatikai infrastruktúra mértéke, hiszen több alkalmazás válik \gls{felho}be "költöztethetővé" és ezáltal annak előnyeit is nagyobb mértékben lesznek képesek kihasználni a gyártósorok. , Ebben a feladatban egy már rendelkezésre álló demót alakítottam át úgy, hogy az kihasználja a peremhálózati rendszerek adta lehetőségeket. \section{Környezet ismertetése} % Általánosan a robotkar cumók ismertetése A feladat megkezdésekor rendelkezésemre állt egy gondosan megtervezett demó szcenárió, amely kifejezetten a hálózati késleltetés jelentőségének bemutatására lett tervezve. Ez a szcenárió magában foglalja mind a szoftveres és a hardveres megoldást. A kettőt összekötő hálózatot és még egyedileg 3D nyomtatott munkadarabokat is. \subsection{\textit{Universal Robots}} A demóban használt robotkarokat az \textit{Universal Robots} nevű dán vállalat tervezi és gyártja. A gyártó palettáján több robotkar is megtalálható. Ez az írás idejében kétszer négy modellt jelent, az \textit{UR3} és \textit{UR3e}, az \textit{UR5} és \textit{UR5e}, az \textit{UR10} és \textit{UR10e} illetve az \textit{UR16e}. Mindegyik robotkar egyre növekvő módon egyre növekvő kihívásoknak képes eleget tenni. % TODO: Cite Az \textit{Universal Robots} által gyártott robotkarok vezérlését a hozzákapcsolt \textit{Control Box} végzi. Ez lényegében egy Mini-ITX számítógép ami egyéni \Gls{linux} alapú operációs rendszert futtat. Ezen a számítógépen fut a robotkarok alacsony szintű vezérlője, amelyet különböző hálózati protokollok segítéségével kezelhetünk, illetve a grafikus felület, amely lokális kapcsolaton csatlakozik ezekhez az interfészekhez\cite{urscriptreference}. A demóhoz használt két robotkar típusa \textit{UR3} és \textit{UR3e}. \subsubsection{Fizikai jellemzők} Jellemzően többfajta felépítésű robotkar létezik. A demó során használt mindkettő robotkar csuklós felépítésű, azaz a az emberi karhoz hasonlóan hajlatokkal (joint) rendelkezik a merev tagok között. A használt robotkarok hat darab ilyen hajlattal rendelkeznek, amely kellő szabadságot nyújt nekik a mozgás terén. A hat jointból ötöt +/- 360$\deg$ lehet elforgatni, az utolsót amely a robotkar "csuklóját" adja pedig végtelenszer lehet körbeforgatni. Egy ilyen robotkar képes fél méteres (500mm) körön belül mozgásokat végezni, és három kilogramm hasznos terhet mozgatni. Maga a robotkar saját súlya 11 kilogramm\cite{ur3_specs}. A két robotkar végére két különböző gripper van telepítve, mindkettő \textit{OnRobot} gyártmány, viszont az egyik egy \textit{rg2} a másik pedig \textit{rg2-ft}. Fizikai jellemzőit tekintve a két gripper hasonló: mindkettő képes legalább 100mm-re kinyílni és 2 kilogramm erővel vízszintesen tömeget megemelni. A szorításra maximum 40 Newton erőt képesek kifejteni\cite{rg2datasheet,rg2tftdatasheet}. A fő különbséget a gripperek kommunikációs interfésze nyújtja. \subsubsection{Kommunikációs interfész} Az demó által használt \textit{Universal Robots} robotkarok többféle kommunikációs interfésszel rendelkeznek, amelyeket a \textit{Control Box} valósít meg\cite{robot_client_interfaces}: \begin{itemize} \item \textbf{Primary/Secondary Interfaces}: A robotok vezérlő szoftvere két interfészt tart fenn a robotkar státuszának módosítására és megfigyelésére. Az elsődleges (primary) interfészen olvasni és írni is lehet a robot állapotát a másodikon csak olvasni. Elsősorban ez az interfész a grafikus kezelőfelülettel történő kommunikációra lett kifejlesztve. URScript parancsokat képes küldeni és fogadni 10Hz-es rátával (Azaz nagyjából 100ms gyakoriság). \item \textbf{Real-time Interfaces}: A valós idejű interfész működése hasonló az előbb említett elsődleges másodlagos intefész működéséhez. Úgyanúgy státuszt tudunk vele megkapni és URScript parancsokat fogad. A fő különbség a működési ráta. Itt akár 500Hz-es rátát is elérhetünk (azaz nagyjából 2ms gyakorisággal küldhetünk vagy fogadhatunk valamilyen információt)\cite{robot_controll_tcpip}. \item \textbf{Dashboard Server}: A robot grafikus kezelőfelületét is képesek vagyunk közvetlenül, programozottan vezérelni \acrshort{tcp} kapcsolaton keresztül. Ez olyan alapvető funkciókat enged végrehajtani, mint a az eltárolt programok betöltése, futtatása, felhasználók hozzáférési szintjének szabályozása, és alapvető robot státusz információk lekérdezése. \item \textbf{Socket Communication}: Ez egy alacsony szintű \acrshort{tcp} alapú kommunikáció, amelyben a robot kliensként viselkedik és a szerver amihez kapcsolódik látja el utasításokkal. Természetesen ezen a protokollon is \textit{URScript} parancsokat adhatunk ki, ezekben segítő utasítások vannak a kapcsolat életciklusának kezelésére. \item \textbf{\acrshort{xml}-\acrshort{rpc}}: Ez a protokol lehetőséget ad sokkal széles körűbb alkalmazásokra, mint az előbbiekben említett \textit{URScript}et használó protokollok. Hiszen az egyes funkcióit a robotoknak a paraméterekkel együtt függvényhívás szerűen végezhetjük. Ezzel sokkal komplexebb programok készíthetőek. \item \textbf{\acrfull{rtde}}: Az \acrshort{rtde}-t egy robosztus megoldásnak tervezték, amely kiválthatja a \textit{Real-time} interfészt. Lehetővé teszi az \textit{UR} kontroller számára az egyéni státusz-adat és regiszter állapotok átvitelét. Ez az interfész valósidejű szinkronizációt tesz lehetővé akár 125Hz-es rátával (8ms/üzenet). \end{itemize} Emellett a hozzákapcsolt grippereknek is lehet önálló kommunikációs interfésze. Míg az \textit{OnRobot RG2} csak a robotkarra kapcsolható közvetlen, így azt a fent említett kommunikációs protokollok segítségél, a robotkaron keresztül lehet vezérelni, az \textit{RG2-FT} lehetővé teszi, hogy közvetlenül a hálózatra csatlakoztassuk a grippert ezzel önálló módon kezeljük azt. \subsubsection{\textit{URScript}} Az \textit{URScript} imperatív, interpretált szkriptnyelv, amelyet elsősorban robotikai alkalmazásokra fejlesztettek ki\cite{urscriptreference}. A nyelv szintaktikája sokban hasonlít a \Gls{python} programozási nyelvre. A fő eltérés a pythonhoz képest, hogy explicit jelezni kell, ha egy blokk véget ér (\texttt{end} kulcsszó). URScript snippeteket gyakran \textit{on-the-fly} tudunk küldeni valamilyen \acrshort{tcp} kapcsolaton keresztül. Feltételezhetően ez miatt kell jelölni a blokkok végét, hiszen másként nem lenne lehetősége a vezérlő szoftvernek eldönteni, hogy egy blokk véget ért-e. Az \textit{URScript} programokban lehetőség van többszálúsítást alkalmazni. Az egyes szálakat, hagyományos módon függvény szerűen tudjuk definiálni. Mivel az \textit{URScript} elsődleges felhasználása, hogy robotokat vezéreljen valós időben, ezért az ütemezése a szálaknak is erre alapozott. A robotokat 125Hz-es rátával kell vezérelni (azaz 8ms-ként kell utasítást adni neki). Hogy ezt megvalósíthassa, a végrehajtó környezet minden szálnak pontosan 8ms időt allokál, hogy fusson. A futásra készen álló szálakból \textit{round-robin} stílusban választ az ütemező. % TODO itt kibogarászni hogy a physical idő meg a timeframe-ek hogy vannak \subsubsection{Szimulátor} Természetesen a tanszéken csak kettő robotkar van, amelyek nem állnak mindig készen a tesztelésre. A fejlesztés és a tesztelés megkönnyítésére több szimulátor is megvizsgálásra került a Demót összeállító csapat által. Végül a leghatékonyabban használhatónak a \textit{DockURSim}\footnote{\url{https://github.com/ahobsonsayers/DockURSim}} bizonyult. Lényegében a \textit{DockURSim} a robotkarokat közvetlenül irányító, \textit{Control Box}on futó szoftver becsomagolva egy \textit{Docker} konténerbe. Konkrét robotkart nem irányít, de a kommunikációs interfészeket és azok funkcionalitását teljes mértékben implementálja. Lehetőségünk van a beépített \acrfull{rdp} szerveren keresztül grafikus felületet\footnote{Ez a grafikus felület a \textit{Teach Pendant}on grafikusan kezelhető felület.} kezelni és ott meg tudjuk figyelni a robotkar mozgását. Egyetlen hátránya ennek a megoldásnak, hogy a robotkarokat önállóan egy izolált környezetben tudja csak szimulálni, így a környezet fizikai hatásai, a gripperek működése és a robotkarok egymással való találkozását nem képes modellezni. \subsection{Demó} A megvalósított demó egy általános összeszerelési szcenáriót mintáz. Ebben a szcenárióban a két robotkar egyenként felemelnek egy-egy munkadarabot. Ezeket a levegőben összeillesztik, majd ezután az egyik robotkar elengedi, a másik pedig leteszi. Bár egyszerűnek tűnik, ebben a szcenárióban nagy hangsúly helyezkedik a hálózat pontos időzítésérére. Hiszen a kritikus ponton, amikor a két robotkar össze illeszti a munkadarabot kiemelten fontos, hogy egyszerre mozogjanak, hiszen ha ez nem sikerül, akkor összeillesztés helyett eltörik a munkadarabot. A következőkben részletesen bemutatom a demó felépítését és működését. \subsubsection{Környezet} A demó szcenáriót lejátszó robotkarok egy asztalon kerültek telepítésre. Két oldalt a két robotkar helyezkedik el. A robotkaroknak a szcenáriót tervező csapat találó módon az Erik és a Fred neveket adták. Az Erik nevezetű robotkaron található az \textit{rg2-ft} típusú gripper, amely önállóan csatlakozik a hálózatra, ezzel szemben a Fred nevezetű robotkaron lévő gripper a robotkar kommunikációs interfészén keresztül kapja az információt. \begin{figure}[h!] \centering \includegraphics[width=0.6\textwidth]{figures/work_table} \caption{A demó környezet elemeit tartalmazó asztal alaprajza} \label{fig:work_table} \end{figure} Az asztalon a két munkadarabnak kijelölt helye van, ahonnan a robotkarok felemelik, az összeillesztés az asztal közepénél történik, majd valahol itt is helyezi el a kész darabot. A környezet vizuális bemutatásául \aref{fig:work_table}.\ ábra szolgál. \subsubsection{Vezérlés} A demo vezérlésére a munkám elején egy monolit Python program állt rendelkezésemre. A program úgy lett tervezve, hogy elindításával csatlakozik mindkettő robotkar \acrshort{rtde} interfészére. Majd sorban elküldi a robotkaroknak a demo végrehajtásához szükséges utasításokat. A % TODO gripper vezérlését \acrshort{rest} apin keresztül végzi. A két robotkar vezérlése két külön szálon valósítja meg. Mindkettő szálon egymás után következnek az utasítások, a kritikus szinkronizációs részek egyszerű szál-szinkronizációs primitívekkel vannak megoldva. A programban több futtatási mód is implementálva van. Egyrészt választani lehet a végrehajtás sebességét gyors és lassú között. Ez a robotkarok mozgási sebességét befolyásolja. Emellett lehetőség van "Jogging" módban futtatni. Ebben a módban a program minden mozdulat végrehajtása előtt várakozik egy gomb lenyomására a további parancsok kiadása előtt. Így lehetőség adódik az esetleges hibás mozgások hibakeresésére illetve a program teljesen automatikus lefuttatása előtt manuális tesztelésre. A program a konfigurációs beállításait egy \gls{ini} fájlban tárolja. Ezek a konfigurációs beállítások elsősorban a robotkarok és a hozzá tartozó Gripperek hálózati címeit adja meg illetve a konkrét sebesség módokhoz tartozó konfigurációs értékeket. Az \gls{ini} fájl mellett a program a konkrét lépésekhez tartozó koordinátákat egy \textit{Microsoft Excel} \gls{xlsx} fájlból olvassa ki. Ebben a fájlban mindkét robotkarhoz tartozóan fel vannak sorolva a koordináták mind tool- és joint térben. %TODO verify naming \section{Tervezés} % Itt foglalom össze, hogy hogy terveztem meg ezt a fost % funkcionális felbontás % külön lehet írni a magas szintű tervezésről és egyes szoftverek architektúrájáról % Itt le lehet írni a controller magas szintű terveit, plugin architektúrát % tervezés és a nehézségek nem tételesen de hasonlóan struktúrálva % Illetve a komoly megoldásaim % Kiemelve a szinkronizációs problémákat, illetve (korábban) leírva hogy pontosan milyen problémát is próbálok megoldani ezzel azaz mér van szükség rá % Ide valszeg be fog kerülni Máté Miklós munkájáról is egy kis írás % ha nagyon kevés oldal van, akkor itt tudok írni a fejlesztői környezetről is illetve a tesztelésről % Szinkronizációs protokol lófasznál ne felejtsek el írni az NTP-ről és PTP-től \begin{figure}[h!] \centering \includegraphics[width=1\textwidth]{figures/ursim_services_plan-clean} \caption{A tervezett mikroszolgáltatások a futtatási környezetük szerint csoportosítva} \label{fig:usrsim_services_plan-clean} \end{figure} \section{Implementáció} % Hát itt kénytelen leszek kódot magyarázni szerintem % Redis % Technológia stack % az egyes mikroszolgáltatások különszedve % Le lehet írni azt is hogy hogyan extractoltam ki a lépéseket az eredeti kódból, erről egy egész szekciót lehetne írni % Tiny HTTP Szerver, endpointok felsorolása % Pluginok compilerekkel % Esetleg pluginok felsorolással % A programok felépítéséről is lehet írni