small fixes
This commit is contained in:
parent
93f5317427
commit
335abf4c78
@ -137,14 +137,14 @@ A rendszerhez készült egy webes kezelőfelület is, amelyet hallgatótársunk
|
||||
Az általunk tervezett és implementált mikroszolgáltatások működéséről és felelősségeiről egy rövid leírás olvasható az alábbiakban.
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Input Service} Ez az a szolgáltatás amely a felhőbe érkező hangfájlokat fogadja. Ennek a szolgáltatásnak a felelőssége ellátni az egyes hangmintákat címkével. Ezeket a címkéket lokálisan egy relációs adatbázisban is letárolja a hangfájlhoz tartozó egyéb információkkal együtt. A fogadott hangfájlt továbbküldi a \textit{Storage Service} számára. Miután az sikeresen eltárolta, ez a szolgáltatás az üzenetsorba publikál egy üzenetet hogy értesítse a feliratkozókat az új hangminta érkezéséről.
|
||||
\item \textbf{Input Service} Ez az a szolgáltatás, amely a felhőbe érkező hangfájlokat fogadja. Ennek a szolgáltatásnak a felelőssége ellátni az egyes hangmintákat címkével. Ezeket a címkéket lokálisan egy relációs adatbázisban is letárolja a hangfájlhoz tartozó egyéb információkkal együtt. A fogadott hangfájlt továbbküldi a \textit{Storage Service} számára. Miután az sikeresen eltárolta, ez a szolgáltatás az üzenetsorba publikál egy üzenetet, hogy értesítse a feliratkozókat az új hangminta érkezéséről.
|
||||
|
||||
\item \textbf{Storage Service} Ez a szolgáltatás valósítja meg a hangfájlok hosszútávú tárolását egy objektum tárolóban. Képes kérésre visszaadni a hangfájlokat, illetve törölni is a mintákat.
|
||||
|
||||
|
||||
\item \textbf{\acrshort{ai} Service} Ez a szolgáltatás valósítja meg a beérkezett hangmintán hallható madár hang konkrét azonosítását. Ehhez \acrshort{cnn} algoritmust használ. Mind a folyamat elkezdéséhez szükséges üzenet fogadását, mind az eredmény publikálását üzenet sorokra kapcsolódva valósítja meg. A működéséhez szükséges modellt a \textit{Model Service} komponensből tölti le, amellyel \acrshort{rest} interfészen kommunikál. A hangmintát tag alapján a \textit{Storage Service}-ből tölti le címke alapján. Az adott eredmény egy hangminta címkéje és a felismert osztály (amely modelltől függően egy madár faj lehet).
|
||||
\item \textbf{\acrshort{ai} Service} Ez a szolgáltatás valósítja meg a beérkezett hangmintán hallható madár hang konkrét azonosítását. Ehhez \acrshort{cnn} algoritmust használ. Mind a folyamat elkezdéséhez szükséges üzenet fogadását, mind az eredmény publikálását üzenet sorokra kapcsolódva valósítja meg. A működéséhez szükséges modellt a \textit{Model Service} komponensből tölti le, amellyel \acrshort{rest} interfészen kommunikál. A hangmintát a \textit{Storage Service}-ből tölti le címke alapján. Az adott eredmény egy hangminta címkéje és a felismert osztály (amely modelltől függően egy madár faj lehet).
|
||||
|
||||
\item \textbf{Model Service} Ez egyfajta okos tároló a rendszerben használt különböző \acrshort{mi} algoritmusok által használt modellek tárolására és kezelésére. Nem csak magát a modellt de arról különböző metaadatokat is képes eltárolni, amelyeket automatikusan olvas be a modellből. Ilyen például, hogy milyen modelleket képes azonosítani, ezekből melyik jelent veszélyt vagy, hogy az előfeldolgozásánál a hangnak milyen paramétereket kell használni.
|
||||
\item \textbf{Model Service} Ez egyfajta okos tároló a rendszerben használt különböző \acrshort{mi} algoritmusok által használt modellek tárolására és kezelésére. Nem csak magát a modellt, de arról különböző metaadatokat is képes eltárolni, amelyeket automatikusan olvas be a modellből. Ilyen például, hogy milyen osztályokat (esetünkben madarakat) képes azonosítani, ezekből melyik jelent veszélyt vagy, hogy az előfeldolgozásánál a hangnak milyen paramétereket kell használni.
|
||||
|
||||
\item \textbf{Results Service} Ez a szolgáltatás az egyes mintákra való kiértékelések eredményét tárolja le. Minden mintára az eredmények egyértelműen visszakereshetőek és lekérdezhetőek. Ennek a megoldására relációs adatbázist használ.
|
||||
|
||||
|
||||
@ -42,7 +42,7 @@ Dockerben az alkalmazást és környezetét úgynevezett képfájlokban (image)
|
||||
|
||||
Manapság egyre jobban terjed a konténer alapú szoftver fejlesztés és a felhő alapú megoldások \cite{containermarketshare}. Az egyik legnépszerűbb ilyen felhő implementáció a \textit{Kubernetes}. A \textit{Kubernetes} egy konténer orkesztrációs platform, amely felügyeli és kezeli az egyes alkalmazásokat vagy szolgáltatásokat megvalósító konténerek életciklusát egy multihoszt környezetben.
|
||||
|
||||
Az életciklus kezelés mellett több hasznos szolgáltatást is nyújt. Ilyenek az automatikus szolgáltatás felderítés és terhelés elosztás, tárhely orkesztráció, konfiguráció kezelés. Bizonyos, megfelelően felkonfigurált helyzetekben a \textit{Kubernetes} képes alapszintű hibajavításra is, bizonyos szolgáltatások programozott újraindításával.\cite{kubernetes_docs}
|
||||
Az életciklus kezelés mellett több hasznos szolgáltatást is nyújt. Ilyenek az automatikus szolgáltatás felderítés és terhelés elosztás, tárhely orkesztráció, konfiguráció kezelés. Bizonyos, megfelelően felkonfigurált helyzetekben a \textit{Kubernetes} képes alapszintű hibajavításra is, bizonyos szolgáltatások programozott újraindításával \cite{kubernetes_docs}.
|
||||
|
||||
Kubernetes klaszternek nevezzük azt a multihoszt környezetet, ahol több -- egymással hálózatba kötött -- számítógép (fizikai vagy virtuális) valósítja meg a \textit{Kubernetes} környezetet.
|
||||
|
||||
@ -169,7 +169,7 @@ Mindezek mellett két további két rendszerszolgáltatást is tartalmaz, ezek a
|
||||
|
||||
\subsection{Project EVE}
|
||||
|
||||
A Project EVE célje egy különálló, direkt peremhálózati rendszerek megvalósítására tervezett operációs rendszer fejlesztése. A \Gls{linux} alapokra épül, erre épülő operációs rendszerük neve az EVE-OS. A rendszer célja a fejlesztés, orchestráció egyszerűsítése és egy nyílt platform létrehozása. Az EVE-OS jelenleg támogat Docker konténereket, virtuális gépeket és Kubernetes klasztereket, viszont utóbbi támogatása kezdetleges.
|
||||
A Project EVE célje egy különálló, direkt peremhálózati rendszerek megvalósítására tervezett operációs rendszer fejlesztése. \Gls{linux} alapokra épített operációs rendszerük neve az \textit{EVE-OS}. A rendszer célja a fejlesztés, orchestráció egyszerűsítése és egy nyílt platform létrehozása. Az \textit{EVE}-OS jelenleg támogat \textit{Docker} konténereket, virtuális gépeket és \textit{Kubernetes} klasztereket, viszont utóbbi támogatása kezdetleges.
|
||||
|
||||
A projekt tervezése során kiemelt figyelmet fordítottak a a teljesítmény optimalizálásra. Lehetőség van az operációs rendszerben hogy a processzor és GPU erőforrásokat az egyes alkalmazások számára dedikáltan rendelje hozzá, valamint lehetséges távolról befolyásolni a processzor, memória, hálózat és egyéb erőforrások ütemezését. Mindezek mellett hangsúlyosak a biztonsági szempontok is mind hardveresen és szoftveresen is: A nem használt \acrshort{io} portokat ki lehet kapcsolni. A használt szoftverek távoli és automatizált frissítése is lehetséges. Az EVE-OS a rajta futó alkalmazásoknak további védelmet nyújt a policy alapú, elosztott tűzfal alkalmazásával. A fejlesztők igyekeznek az rendszert úgy konfigurálni, hogy az biztonságos alapbeállításokkal rendelkezzen.
|
||||
|
||||
@ -182,11 +182,11 @@ A különböző backendek támogatása azzal jár, hogy ezeket egységes absztra
|
||||
|
||||
A többi bemutatott megoldással szemben az \textit{Akarino Edge Stack} egy specifikáció halmaz, amely igyekszik a peremhálózati rendszerek fejlesztése során gyakran felmerülő problémákra tervezési mintákat adni.
|
||||
|
||||
Ezek a specifikációk lefednek számos az peremhálózati számítástechnika esetében releváns felhasználási területet, például a valós idejű játékokat, videófeldolgozást és elosztott gépi tanulást. A specifikációk megalkotása során cél a komplexitás minimalizálása véges számú lehetséges konfiguráció alkalmazásával. A specifikációk biztonsági szempontokból validálásra kerülnek.
|
||||
Ezek a specifikációk lefednek számos, a peremhálózati számítástechnika esetében releváns felhasználási területet, például a valós idejű játékokat, videófeldolgozást és elosztott gépi tanulást. A specifikációk megalkotása során cél a komplexitás minimalizálása véges számú lehetséges konfiguráció alkalmazásával. A specifikációk biztonsági szempontokból validálásra kerülnek.
|
||||
|
||||
% TODO befejezni
|
||||
|
||||
\subsection{StarlingX}
|
||||
%\subsection{StarlingX}
|
||||
|
||||
% TODO erről is írni valamit
|
||||
|
||||
@ -208,7 +208,7 @@ Az \textit{\acrshort{aws} \acrshort{iot} Greengrass} egy az \textit{Amazon} ált
|
||||
|
||||
A rendszer két fő részből áll. Az egyik az \acrshort{aws} felhőben futó szolgáltatások halmaza, a másik pedig a peremhálózati rendszerre telepíthető\footnote{Az \textit{\acrshort{aws} \acrshort{iot} Greengrass} támogatja azt a megközelítést is ahol a peremhálózat maga a végeszközök rendszere. Ennek megfelelően a \enquote{kliens} alkalmazást oda is lehet telepíteni.} (itt átjáróként hivatkozott) \enquote{kliens} szoftver. Az \acrshort{iot} eszközök ezen az átjárón futó szoftverrel kommunikálnak. Az itt futó peremhálózati szolgáltatások pedig az interneten keresztül kommunikálnak az \acrshort{aws} felhőben futtatott többi komponenssel.
|
||||
|
||||
A két fő rész képes bizonyos ideig egymástól teljesen függetlenül üzemelni. Ha megszakad az összeköttetés a perem és a felhő rendszer között, akkor azok a peremhálózati rendszer képes továbbra is zavartalanul kiszolgálni az \acrshort{iot} eszközöket.
|
||||
A két fő rész képes bizonyos ideig egymástól teljesen függetlenül üzemelni. Ha megszakad az összeköttetés a perem és a felhő rendszer között, akkor a peremhálózati rendszer képes továbbra is zavartalanul kiszolgálni az \acrshort{iot} eszközöket.
|
||||
|
||||
A szolgáltatás árazása az első tízezer csatlakoztatott eszköz esetében havi szinten \$0.16, viszont ebben az árban egyéb \acrshort{aws} szolgáltatások nem tartoznak bele, ami egy konkrét alkalmazás esetében jóval magasabb költségeket is eredményezhet
|
||||
|
||||
@ -217,7 +217,7 @@ A szolgáltatás árazása az első tízezer csatlakoztatott eszköz esetében h
|
||||
Sajnos itt egyértelműen úgy értelmezik a peremhálózati rendszereket, mint ami konkrétan az \acrshort{iot} eszközökön fut, így ez a feladat megoldása szempontjából nem alkalmas. Jelen bemutatása csak a teljesebb kép bemutatását szolgálja.
|
||||
|
||||
|
||||
Az \textit{Azure \acrshort{iot} Edge} egy a \textit{Microsoft} által fejlesztett menedzselt (szintén \acrshort{paas}) platform. A rendszer lehetőséget nyújt \acrshort{iot} eszköztár menedzselésére, azokon távoli frissítéseket végezni és az önálló eszközök állapotát megfigyelni. Szükség esetén irányított beavatkozásra is lehetőséget az egyes eszközökön.
|
||||
Az \textit{Azure \acrshort{iot} Edge} egy a \textit{Microsoft} által fejlesztett menedzselt (szintén \acrshort{paas}) platform. A rendszer lehetőséget nyújt \acrshort{iot} eszköztár menedzselésére, azokon távoli frissítéseket végezni és az önálló eszközök állapotát megfigyelni. Szükség esetén irányított beavatkozásra is lehetőséget ad egyes eszközökön.
|
||||
|
||||
A rendszer felépítése három fő komponensből áll. Az első az \textit{\acrshort{iot} Edge modules} amely a konkrét futtatható alkalmazásokat jelenti. Ezeknek a futtatásáért felel az \textit{\acrshort{iot} Edge runtime} amelyet az \acrshort{iot} eszközökön kerül telepítésre. És maga a \textit{cloud-based interface} amely a rendszer távoli monitorozásáért és kezeléséért felel.
|
||||
|
||||
|
||||
@ -9,26 +9,26 @@ A negyedik ipari forradalom az \enquote{okos} gyártásról szól. A korábban h
|
||||
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 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.
|
||||
|
||||
\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 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
|
||||
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
|
||||
|
||||
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}.
|
||||
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.
|
||||
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.
|
||||
|
||||
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 \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}.
|
||||
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}.
|
||||
|
||||
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.
|
||||
|
||||
@ -38,31 +38,31 @@ A két robotkar végére két különböző gripper van telepítve, mindkettő \
|
||||
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{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).
|
||||
|
||||
\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{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 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{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{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).
|
||||
\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).
|
||||
\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.
|
||||
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.
|
||||
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.
|
||||
A fő eltérés a \gls{python} programozási nyelvhez 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.
|
||||
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 a szálak ütemezése 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
|
||||
A robotokat 125Hz-es rátával kell vezérelni (azaz 8ms-ként kell utasítást adni nekik). 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} ütemezés szerint választ az ütemező. % TODO itt kibogarászni hogy a physical idő meg a timeframe-ek hogy vannak
|
||||
|
||||
|
||||
\subsubsection{Szimulátor}
|
||||
@ -75,7 +75,7 @@ Egyetlen hátránya ennek a megoldásnak, hogy a robotkarokat önállóan egy iz
|
||||
|
||||
\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.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
@ -83,7 +83,9 @@ A következőkben részletesen bemutatom a demó felépítését és működés
|
||||
|
||||
\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.
|
||||
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.
|
||||
|
||||
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
|
||||
@ -92,35 +94,33 @@ A demó szcenáriót lejátszó robotkarok egy asztalon kerültek telepítésre.
|
||||
\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}
|
||||
\label{sec:ursim_demo_control}
|
||||
|
||||
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 demo vezérlésére a munkám elején egy \gls{python} nyelven megírt monolit 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} \acrshort{api}-n 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 két robotkar vezérlése két külön szálon van megvalósítva. 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 \enquote{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 programban több futtatási mód is implementálva van. Egyrészt gyors és lassú végrehajtás sebesség között lehet választani. Ez a robotkarok mozgási sebességét befolyásolja. Emellett úgynevezett \enquote{Jogging} módban is lehet az alkalmazást 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.
|
||||
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
|
||||
|
||||
A fenti monolit demó felhő és perem számítástechnikai rendszerbe való átültetése úgy, hogy annak előnyeit megfelelően ki tudja használni alapos tervezést igényelt.
|
||||
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.
|
||||
|
||||
\subsection{Keretrendszer}
|
||||
|
||||
\Aref{sec:frameworks}.\ szekcióban több keretrendszert is megvizsgáltam. Ezek közül a \textit{KubeEdge}-t választottam.
|
||||
\Aref{sec:frameworks}.\ szekcióban több keretrendszert is megvizsgáltam. Ezek közül a \textit{KubeEdge}-et választottam.
|
||||
|
||||
A kiválasztásának fő oka az volt, hogy támogatja a mikroszolgáltatás architektúrát, emellett -- a leírása alapján -- könnyen lehet alkalmazni, hiszen ha az alkalmazásunk konténerből futtatható, alig kell rajta módosítani, hiszen a \textit{KubeEdge} képes ezeket a konténereket beütemezni, hogy a peremhálózaton futhassanak. Így a korábban szerzett mikroszolgáltatás alapú alkalmazásfejlesztési tapasztalataimat itt könnyen tudtam hasznosítani.
|
||||
|
||||
Mindemellett \aref{sec:birbframework}.\ szekcióban kifejtettek alapján a másik alkalmazásomat is \textit{KubeEdge} alapokra építettem fel. Ennek köszönhetően a későbbi méréseimet is egyforma környezetben tudom végezni, ezzel egyszerűsítve azok implementációját amellett, hogy a két alkalmazáshoz nem kell két külön keretrendszert megismernem és fejleszteni rá.
|
||||
|
||||
A \textit{KubeEdge} használatának további előnye, hogy az általam már jól ismert \textit{Kubernetes} konténer orkesztációs platformra épül. Így a telepítése és megismerése számomra egyszerűbb.
|
||||
A \textit{KubeEdge} használatának további előnye, hogy az általam már jól ismert \textit{Kubernetes} konténer orkesztációs platformra épül így a telepítése és megismerése számomra egyszerűbb.
|
||||
|
||||
\subsection{Architektúra}
|
||||
|
||||
@ -139,7 +139,7 @@ A végleges funkcionálisan felbontott részegységekről \aref{fig:usrsim_servi
|
||||
|
||||
\subsubsection{\textit{On-site} réteg}
|
||||
|
||||
Mivel azt szeretnénk, hogy a telephelyen belüli (On-site) rendszer a lehető legminimálisabb legyen, így oda csak maga a robotkar -- és a hozzá tartozó \textit{Control Box} amely az alacsony szintű vezérlését megvalósítja -- kerül. Természetesen ebből több is kerülhet egy telephelyre, vagy akár több telephelyet is vehetünk.
|
||||
Mivel azt szeretnénk, hogy a telephelyen belüli (On-site) rendszer a lehető legminimálisabb legyen, így oda csak maga a robotkar -- és a hozzá tartozó \textit{Control Box} amely az alacsony szintű vezérlését megvalósítja -- kerül. Természetesen ebből több is kerülhet egy telephelyre, vagy akár több telephelyre kihelyezett rendszert is irányíthatunk egyszerre.
|
||||
|
||||
\subsubsection{Peremhálózati réteg}
|
||||
\label{sec:edge_layer_plans}
|
||||
@ -158,7 +158,7 @@ Mivel a legmagasabb réteg -- a felhő -- és a középső réteg között a kap
|
||||
|
||||
Mivel a peremhálózati rétegben már kialakítottunk egy absztrakciót, amely elfedi a késleltetési problémákat a felhő réteg elől, így a felhő rétegben futó szoftver ezt biztonságosan tudja használni a robotkar mozgatására.
|
||||
|
||||
Az Ipar 4.0 megközelítésben különös szerepet játszik a \textit{Big Data}, azaz a nagy mennyiségű adat gyűjtése és feldolgozása és ennek felhasználása,
|
||||
Az Ipar 4.0 megközelítésben különös szerepet játszik a \textit{Big Data}, azaz a nagy mennyiségű adat gyűjtése és feldolgozása és ennek felhasználása.
|
||||
|
||||
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.
|
||||
|
||||
@ -180,7 +180,7 @@ Szerettem volna egy olyan végrehajtási környezetet megalkotni, ahol könnyen
|
||||
|
||||
Munkám során mások is dolgoztak a robotkarok alacsony szintű vezérlésén. Terveink szerint ezeket a törekvéseket egy projektben fogjuk majd egyesíteni. Ez is alátámasztotta a dinamikusan cserélhető funkcionalitás szükségességét.
|
||||
|
||||
Ezek motiválták, hogy az egyes utasításokat önálló komponensbe szervezzem. Ezeket a komponenseket \textit{plugin}-nak neveztem el. A \textit{program} által végrehajtható utasításokat az egyes \textit{plugin}-ok implementálják. Egy \textit{plugin} többet is akár illetve egy utasítást több \textit{plugin} is implementálhat\footnote{Ilyen esetben csak egy \textit{plugin}-t használhatunk egyszerre}. Ennek köszönhetően egy utasítás mögött egy másik \textit{plugin} használatával könnyen lecserélhetjük a funkcionalitást. A program futtatása előtt definiálni kell, hogy konkrétan melyik \textit{plugin}-okat szeretnénk használni a futtatás során.
|
||||
Ezek motiválták, hogy az egyes utasításokat önálló komponensbe szervezzem. Ezeket a komponenseket \textit{plugin}-nak neveztem el. A \textit{program} által végrehajtható utasításokat az egyes \textit{plugin}-ok implementálják. Egy \textit{plugin} többet is akár, illetve egy utasítást több \textit{plugin} is implementálhat\footnote{Ilyen esetben csak egy \textit{plugin}-t használhatunk egyszerre}. Ennek köszönhetően egy utasítás mögött egy másik \textit{plugin} használatával könnyen lecserélhetjük a funkcionalitást. A program futtatása előtt definiálni kell, hogy konkrétan melyik \textit{plugin}-okat szeretnénk használni a futtatás során.
|
||||
|
||||
Egy \textit{plugin} által definiált utasítás a funkcionalitás mellett annak végrehajtásának vége előtti megszakítását is implementálnia kell, hiszen bármikor előfordulhat olyan helyzet, hogy le kell állítani a futtatást. Emellett a végrehajtás állapotának megfigyelhetőségéhez szükséges funkciókat is meg kell valósítania.
|
||||
|
||||
@ -193,7 +193,7 @@ Mivel itt már nem két szál összehangolásáról van szó hanem két egymást
|
||||
|
||||
Alapos kutatás után sajnos nem találtam erre a problémára teljes, kész megoldást, ezért kidolgoztam egy saját megoldást.
|
||||
|
||||
Mivel fontos, hogy a szinkronizáció pontos legyen minden komponensnél, ezért annak az ötletét, hogy hálózaton küldött üzenetek szolgáljanak a szinkronizáció alapjául teljesen elvetettem.
|
||||
Mivel fontos, hogy a szinkronizáció pontos legyen minden komponensnél, ezért annak az ötletét, hogy hálózaton küldött üzenetek szolgáljanak a szinkronizáció alapjául, teljesen elvetettem.
|
||||
|
||||
Ezzel szemben lehetőség van a futtató környezetet adó fizikai számítógépek óráinak meglepően precíz szinkronizációjára. \Aref{append:timesync}.\ függelékben ezt részletesebben is tárgyalom. Ezt alapul véve kidolgoztam egy kellően precíz szinkronizációs protokollt.
|
||||
|
||||
@ -212,14 +212,14 @@ A szinkronizációs folyamat időbeni lefutása \aref{fig:pyprocsync_flow} ábr
|
||||
\label{fig:pyprocsync_flow}
|
||||
\end{figure}
|
||||
|
||||
Az protokoll arra hagyatkozik, hogy ismerjük, hogy hány komponenst kell szinkronizálni. Mindig, amikor egy program a szinkronizációs ponthoz érkezik, akkor atomikus módon megnövel egy számlálót, ha a számláló értéke egyezik, a várakozó komponensek számával, akkor az utolsó komponens a pillanatnyi rendszeridőhöz hozzáad egy fix értéket, és ezt kihirdeti a többi komponens felé\footnote{Ha feltételezzük, hogy a rendszeridők szinkronban vannak, akkor lényegében mindegy, hogy melyik komponens hirdeti ki.}. Erre a hozzáadásra azért van szükség, hogy ellensúlyozza azt az időt (ami a hálózati késleltetésből adódóan változó lehet), amíg az üzenet eljut minden komponenshez. Ezek után a komponensek a kihirdetett időben folytatják a végrehajtást.
|
||||
A protokoll arra hagyatkozik, hogy ismerjük, hogy hány komponenst kell szinkronizálni. Mindig, amikor egy program a szinkronizációs ponthoz érkezik, akkor atomikus módon megnövel egy számlálót, ha a számláló értéke egyezik, a várakozó komponensek számával, akkor az utolsó komponens a pillanatnyi rendszeridőhöz hozzáad egy fix értéket, és ezt kihirdeti a többi komponens felé\footnote{Ha feltételezzük, hogy a rendszeridők szinkronban vannak, akkor lényegében mindegy, hogy melyik komponens hirdeti ki.}. Erre a hozzáadásra azért van szükség, hogy ellensúlyozza azt az időt (ami a hálózati késleltetésből adódóan változó lehet), amíg az üzenet eljut minden komponenshez. Ezek után a komponensek a kihirdetett időben folytatják a végrehajtást.
|
||||
|
||||
|
||||
A szinkronizációs megoldást önállóan elérhető \gls{python} csomagként is publikáltam, így más projektekben is felhasználható\footnote{\url{https://github.com/marcsello/pyprocsync}}. Sajnos az implementáció csak \textit{Redis}-el működik.
|
||||
|
||||
\subsubsection{Megfigyelés és vezérlés}
|
||||
|
||||
A szolgáltatásnak lehetőséget kell adni arra, hogy megfigyelhető és beavatkozható legyen a működése. Erre a célra egy \acrshort{http} \acrshort{api}-t terveztem.
|
||||
A szolgáltatásnak lehetőséget kell adni arra, hogy működése megfigyelhető és beavatkozható legyen. Erre a célra egy \acrshort{http} \acrshort{api}-t terveztem.
|
||||
|
||||
Azért ezt a megoldást választottam, mert a \acrshort{http} protokoll kellően elterjedt, ezért széleskörűen támogatott. Mivel a futtatókörnyezet \textit{Kubernetes} alapú, ezért ez a legkönnyebben kezelhető hálózati erőforrás. %TODO: alátámasztani/megindokolni
|
||||
|
||||
@ -237,7 +237,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 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.
|
||||
|
||||
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.
|
||||
|
||||
@ -245,7 +245,7 @@ A szolgáltatásba fel lehet tölteni a felhasználó által megírt programot,
|
||||
|
||||
Erre a komponensre is szintén azért van szükség, mert a felhőbe telepített komponenseket nem szerettem volna túlzottan bonyolulttá tenni.
|
||||
|
||||
Mivel a programok előre definiált formában léteznek, ezért kell egy komponens ami felel azért, hogy azoknak betöltését és végrehajtását elindítsa a peremhálózaton.
|
||||
Mivel a programok előre definiált formában léteznek, ezért kell egy komponens, ami felel azért, hogy azoknak betöltését és végrehajtását elindítsa a peremhálózaton.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user