% !TeX root = ../thesis.tex
%----------------------------------------------------------------------------
\chapter{Felhő alapú robot vezérlés implementáció}
\label{chapter:ursim}
%----------------------------------------------------------------------------

% Ipar 4.0 ???
% Szóval van ezt a 4. ipari forradalom
% itt irodalom kutatjuk, hogy hogy jön ez össze a cloudból irányitott dolgokkal
% Leírom hogy a peremhálózatok itt mennyire király módon tudnak a segítségünkre válni
% mert az fellendíti, meg nagyon felhő


\cite{whatisindustry4}

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{Universal Robots}
% Általános leírás a robotkarokról, meg hogy ezek a csávók gyártanak ilyeneket


\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}

% RTDE Interface

\cite{robot_client_interfaces}

\begin{itemize}
	\item \textbf{Primary/Secondary Interfaces} 
	\item \textbf{Real-time Interfaces}
	\item \textbf{Dashboard Server}
	\item \textbf{Socket Communication}
	\item \textbf{XML-RPC}
	\item \textbf{\acrfull{rtde}}
\end{itemize}

% Említeni a grippereket is 


\subsubsection{Szimulátor}
% Dockursim

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ó, a \textit{Teach Pendanton} 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 grafikus felületet 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