2021-12-15 21:26:36 +01:00
parent 07e66186f2
commit 5d3112976d
6 changed files with 231 additions and 220 deletions
							
							
								
							
							
						
@@ -10,23 +10,23 @@ A robotvezérlés precíz időzítést igényel, hiszen itt pár-tíz milliszeku
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 felhőbe \enquote{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.
Ebben a feladatban egy már rendelkezésre álló demonstráció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.
A feladat megkezdésekor rendelkezésemre állt egy gondosan megtervezett demonstrációs 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 három plusz egy 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
A demonstráció 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 három plusz egy 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}.
A demonstráció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 az emberi karhoz hasonlóan hajlatokkal (joint) rendelkezik a merev tagok között. 
Jellemzően többfajta felépítésű robotkar létezik. A demonstráció során használt mindkettő robotkar csuklós felépítésű, azaz 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$^\circ$ lehet elforgatni, az utolsót, amely a robotkar \enquote{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}.
							
							
							
								
							
						
@@ -35,18 +35,17 @@ A két robotkar végére két különböző gripper van telepítve, mindkettő \
\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}: 
Az demonstráción 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 100ms gyakorisággal küldhetünk vagy fogadhatunk valamilyen információt).
	
	\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 2ms gyakorisággal) \cite{robot_controll_tcpip}.
	\item \textbf{Real-time Interfaces}: A valós idejű interfész működése hasonló az előbb említett elsődleges és 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 2ms gyakorisággal) \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 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 robusztus 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).
							
							
							
								
							
						
@@ -67,30 +66,30 @@ A robotokat 125Hz-es rátával kell vezérelni (azaz 8ms-ként kell utasítást
\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. 
A tanszéken található kettő robotkar természetesen nem áll mindig rendelkezésre. Más csapatok más-más projektekben is használják. A fejlesztés és a tesztelés megkönnyítésére több szimulátor is megvizsgálásra került a projekten korábban dolgozó 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ó}
\subsection{Demonstráció}
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 felemel egy-egy munkadarabot. Ezeket a levegőben összeillesztik, majd ezután az egyik robotkar elengedi, a másik pedig leteszi.
A megvalósított demonstráció egy általános összeszerelési szcenáriót mintáz. Ebben a szcenárióban a két robotkar egyenként felemel 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.
A következőkben részletesen bemutatom ennek a szoftvernek a 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 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. 
A demonstrációs 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 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. 
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.
\begin{figure}[h!]
	\centering
	\includegraphics[width=0.6\textwidth]{figures/work_table}
	\caption{A demó környezet elemeit tartalmazó asztal alaprajza}
	\caption{A demonstrációs környezet elemeit tartalmazó asztal vázlatos alaprajza}
	\label{fig:work_table}
\end{figure}
							
							
							
								
							
						
@@ -110,20 +109,20 @@ Az \gls{ini} fájl mellett a program a konkrét lépésekhez tartozó koordinát
\section{Felkészítés a peremhálózati alkalmazásra} % Itt foglalom össze, hogy hogy terveztem meg ezt a fost
Alapos tervezést igényelt a fenti monolit demó átültetése egy felhő és perem számítástechnikai rendszerbe oly módon, hogy annak előnyeit megfelelően ki tudja használni.
Alapos tervezést igényelt a fenti monolit demonstráció átültetése felhő és perem számítástechnikai rendszerbe oly módon, hogy annak előnyeit megfelelően ki tudja használni.
\subsection{Architektúra}
Mivel a \textit{Kubefed} keretrendszert választottam az alkalmazásom futtatására, így ennek megfelelően kellett megválasztanom annak felépítését. Az alkalmazást mikroszolgáltatás architektúrára terveztem. \textit{Kubefed} használatával lényegében az alkalmazásunk (egy vagy több) \textit{Kubernetes} klaszterben fut. A mikroszolgáltatás architektúra az ilyen környezetben azért jó, mert az alkalmazás komponensek egymás belső működésétől függetlenek. Így amíg az egyes komponensek egymás \acrshort{api} felületét elérik, nem számít, hogy hol és milyen környezetben futnak. Természetesen a felületek elérése is egy összetett probléma önmagában, ennek megoldásáról \aref{chapter:dynamic_scheduling}.\ fejezet értekezik.
Ennek érdekében a tervezés első lépéseként felbontottam funkcionális egységekre a jelenlegi demó vezérlést. A felbontásnál viszont itt nem csak a funkcionális egységek elkülönítését tartottam szem előtt. Mivel egy három rétegű architektúrára tervezek, ezért figyelembe kellett vennem annak elvárásait és adottságait. 
Ennek érdekében a tervezés első lépéseként felbontottam funkcionális egységekre a jelenlegi demonstráció vezérlését. A felbontásnál viszont itt nem csak a funkcionális egységek elkülönítését tartottam szem előtt. Mivel egy három rétegű architektúrára tervezek, ezért figyelembe kellett vennem annak elvárásait és adottságait. 
A végleges funkcionálisan felbontott részegységekről \aref{fig:usrsim_services_plan-blocks}.\ ábra ad áttekintést. Érdemes megfigyelni, hogy végeredményében a három rétegű architektúránk egy három szintű robot vezérlést implementál, amely a vezérlési feladatokat egyre nagyobb absztrakcióval kezeli. Az egyes rétegeken belüli rendszerek tervezését a következő szekciókban ismertetem.
\begin{figure}[h!]
	\centering
	\includegraphics[width=0.9\textwidth]{figures/ursim_services_plan-blocks}
	\caption{Demó vezérlés felbontása funkcionális egységekre a futtatási környezet és a késleltetés igények szerint}
	\caption{Vezérlés felbontása funkcionális egységekre a futtatási környezet és a késleltetés igények szerint}
	\label{fig:usrsim_services_plan-blocks}
\end{figure}
							
								
							
							
								
							
							
						
@@ -152,12 +151,12 @@ Az Ipar 4.0 megközelítésben különös szerepet játszik a \textit{Big Data},
Az adatok gyűjtése nem késleltetés érzékeny, ezért nem okoz problémát, ha a peremhálózatról egyenesen a felhőbe küldjük. Mivel a dolgozatom a \textit{Big Data} konkrét elemzésére nem tér ki, ezért az általam tervezett rendszerben a mérési adatokkal való tervezés kimerül azok gyűjtésében. 
\subsection{\textit{Single Robot Controller}} % Peremhálózati rendszer basically
\subsection{Peremhálózati szolgáltatások} % Peremhálózati rendszer basically
\label{sec:single_robot_contoller_plans}
\Aref{sec:edge_layer_plans}.\ szekcióban ismertetettek alapján terveztem meg a peremhálózati rendszerben futó mikroszolgáltatás halmazt. Jelenleg ez egyetlen egy mikroszolgáltatásból áll, ez az a szolgáltatás a \textit{program}ok futtatását valósítja meg.
Egy program egyszerre csak egy robotkar működését írja le, így egy ilyen komponens egyszerre csak egy robotkarhoz kapcsolódik. A demó végrehajtásához két komponensnek kell kapcsolódnia.
Egy program egyszerre csak egy robotkar működését írja le, így egy ilyen komponens egyszerre csak egy robotkarhoz kapcsolódik. A demonstráció végrehajtásához két komponensnek kell kapcsolódnia.
Emellett meg kell oldania olyan problémákat is, amelyek \aref{sec:ursim_demo_control}.\ szekcióban ismertetett programnál adottak -- vagy legalábbis közel-triviálisan megoldhatóak -- voltak. 
							
							
							
								
							
						
@@ -177,7 +176,7 @@ Egy \textit{plugin} által definiált utasítás a funkcionalitás mellett annak
\subsubsection{Szinkronizáció}
\label{sec:ursim_snyc_proto}
A demó során kiemelt szerepe van a két robotkar lépéseinek összehangolására kritikus pontokban. 
A demonstráció során kiemelt szerepe van a két robotkar lépéseinek összehangolására kritikus pontokban. 
Mivel itt már nem két szál összehangolásáról van szó hanem két egymástól független alkalmazásra, amelyek az architektúra, a peremhálózati keretrendszer és a futtatási környezetből adódóan jóformán csak hálózaton tudnak kommunikálni, ezért ez egy teljesen más megoldást kívánt.
							
								
							
							
								
							
							
						
@@ -227,7 +226,7 @@ A \textit{plugin}ek további funkcionalitást regisztrálhatnak, amiket az \acrs
Az architektúra, melyet \aref{sec:edge_layer_plans}.\ szekcióban bemutattam lehetővé teszi, hogy a felhőben futó komponensek bármilyen programot adjanak a peremhálózati réteg számára, legyen az automatikusan vagy részben automatikusan generált.
Mivel sem a demó, sem a dolgozatom szempontjából nem lényeges, hogy milyen módon keletkeznek a \textit{program}ok magas szinten, ezért itt csak egy egyszerű, előre elkészített programokat tároló szolgáltatást terveztem.
Mivel sem a demonstráció, sem a dolgozatom szempontjából nem lényeges, hogy milyen módon keletkeznek a \textit{program}ok magas szinten, ezért itt csak egy egyszerű, előre elkészített programokat tároló szolgáltatást terveztem.
A szolgáltatásba fel lehet tölteni a felhasználó által megírt programot, illetve le lehet tölteni onnan egy egyszerű \acrshort{rest} \acrshort{api} használatával.
							
							
							
								
							
						
@@ -240,12 +239,12 @@ Mivel a programok előre definiált formában léteznek, ezért kell egy kompone
Ennek a komponensnek a működése nagyban függ a konkrét keretrendszertől és futtató környezettől. Az alapvető feladata az, hogy szükség esetén egy absztrakcióval szolgáljon a konkrét programfuttatási eljárás fölé egyszerű \acrshort{rest} \acrshort{api} kiszolgálásával.
\subsubsection{\textit{Metrics Service}}
%\subsubsection{\textit{Metrics Service}}
% TODO: Ez mekkora kamu
% A metrika gyűjtés tervezése és implementációja még hátra van.
A metrika gyűjtésének folyamatát a diplomatervezés második felében fogom megtervezni és megvalósítani. 
%A metrika gyűjtésének folyamatát a diplomatervezés második felében fogom megtervezni és megvalósítani. 
\section{Implementáció} 
							
								
							
							
								
							
							
						
@@ -327,7 +326,7 @@ A \textit{plugin} által megvalósított egyetlen utasítás addig várakoztatja
Ez a \textit{plugin} regisztrál egy endpointot a \acrshort{http} \acrshort{api}-ban, amellyel a program végrehajtása folytatható. 
Ennek a pluginnek a használatával megvalósítható, a demóban is alkalmazott \textit{jogging} módú futtatás. A léptetés itt nem billentyűlenyomással, hanem az \acrshort{api} meghívásával történik.
Ennek a pluginnek a használatával megvalósítható, a demonstráció során is alkalmazott \textit{jogging} módú futtatás. A léptetés itt nem billentyűlenyomással, hanem az \acrshort{api} meghívásával történik.
\subsubsection{Egyebek}
							
							
							
								
							
						
@@ -341,7 +340,7 @@ A fent vázolt \textit{plugin}ek mellett készítettem néhány egyszerűbbet is
\subsection{\textit{Program} formátum}
A \textit{Program}ok felépítése és struktúrája egyszerű. Úgy alkottam meg, hogy mind ember által könnyen értelmezhető és szerkeszthető legyen, de könnyen értelmezhető legyen program által is. 
A robotkarok vezérlésének lépései az általam tervezett formátumú \textit{programokban} vannak összegyűjtve. A \textit{Programok} felépítése és struktúrája egyszerű. Tervezés során figyelembe vettem, hogy mind ember által könnyen értelmezhető és szerkeszthető legyen, de könnyen feldolgozható is legyen szoftver által is. 
A \textit{program} leírása tartalmazza első sorban annak verzióját. Ez a későbbi kompatibilitási problémák megoldásának egyszerűsítésére lett bevezetve, jelenleg csak az \texttt{1}-es verzió létezik. Az a program, ahol ennek a mezőnek az értéke nem \texttt{1} az érvénytelen.
							
								
							
							
								
							
							
						
@@ -381,7 +380,7 @@ program:
A program sémájának validálására a  \textit{Marshmallow}\footnote{\url{https://github.com/marshmallow-code/marshmallow}} könyvtárat használtam. Ezzel deklaratív módon tudtam validációs sémákat írni, amelyet minden komponensnél használtam, amely érintkezik valamilyen szinten \textit{program}okkal. Így a lehető leghamarabb vissza tudja utasítani a rendszer a hibás programokat.
Az eredeti demó mozgását futás időben fordítottam le az általam definiált \textit{program} struktúrára azáltal, hogy a demó programban a \gls{python} által biztosított reflexiókat használva, az egyes lépéseket lecseréltem arra, hogy fájlba mentse a az utasításokat és a paramétereiket. 
Az eredeti szoftver által vezérelt mozgást futás időben fordítottam le az általam definiált \textit{program} struktúrára azáltal, hogy a program kódjában a \gls{python} által biztosított reflexiókat használva, az egyes lépéseket lecseréltem fájlba mentő funkciókra amely rögzíti az utasításokat és a paramétereiket. 
%\section{Tesztelés}