% !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