Cloud Robotika: vplyv cloud computingu na budúcnosť robotiky (3)

Existujú dva základné spôsoby, ako môžeme zariadenie (robota) prepájať s cloudom:

• Priame prepojenie, čo znamená, že nepotrebujeme žiadny medzičlánok medzi robotom a cloudom. Na robotovi bude bežať skript, v ktorom bude vyriešená komunikácia s cloudom. Počítač možno použiť na spustenie tohto skriptu (čo sa dá v prípade potreby zautomatizovať).
• Nepriame prepojenie, čo znamená, že sa používa počítač alebo externý server slúžiaci ako sprostredkovateľ komunikácie.

Tieto dva typy komunikácie robota s cloudom sú znázornené na obr. 1.

Prehľad technológií využiteľných pri komunikácii robota s cloudom

Existuje niekoľko rôznych technológií použiteľných pri komunikácii robota s cloudovou službou. Výhoda pripojenia robota na cloud je možnosť využiť výpočtový výkon cloudu na zložité úlohy. Rovnako možno používať úložiská nachádzajúce sa na cloude, konkrétne pri Windows Azure [2] (ktorý používame u nás v laboratóriu) – Azure SQL storage, blob storage a table storage opísané v [3]. Z tohto dôvodu netreba ukladať v internej pamäti robota veľké objemy dát. Potrebné dáta možno stiahnuť z úložiska podľa potreby. Keďže robot odbremeníme od zložitých výpočtov, ušetríme mu energiu, ktorú môže využiť na inú činnosť, čo je aj jeden z dôvodov, prečo vzniká odvetvie cloudovej robotiky.

Keď hovoríme o servisne orientovanej architektúre, treba spomenúť najmä metódy SOAP (Simple Object Acces Protocol) a REST (Representation State Transfer). SOAP vyvinula firma Microsoft. Ide o štandard, pri ktorom sa posielajú údajové štruktúry zakódované v tvare podobnom XML. WSDL (Web Services Description Language) súbor určuje, ako bude tento posielaný XML kód vyzerať. Existujú technológie, napríklad WCF, pri ktorých netreba WSDL súbor písať ručne, ale je automaticky vygenerovaný. V prípade používania Google App Engine [4] treba tento súbor písať ručne. WSDL súbor je založený na syntaxi XML schémy.

REST predstavuje oproti SOAP omnoho jednoduchšiu alternatívu. Namiesto XML sa REST spolieha v mnohých prípadoch na jednoduché URL. Nasledujúca sekcia zhŕňa výhody SOAP oproti REST a naopak.

Výhody SOAP:

• jazyková a platformová nezávislosť (REST vyžaduje použitie HTTP),
• dobre pracuje v distribuovanom podnikovom prostredí (REST predpokladá priamu komunikáciu point-to-point),
• štandardizovanosť,
• poskytuje značnú rozšíriteľnosť vo forme WS štandardov,
• zabudované spracovanie chýb, 
• automatizácia pri použití istých programovacích jazykov.

Výhody REST:

• ľahšie sa používa a je flexibilnejší,
• nevyžaduje drahé nástroje na interakciu s webovými službami,
• menšia krivka učenia,
• efektívnejší (SOAP používa XML pre všetky typy správ, REST vie používať aj menšie formáty),
• rýchlejší (nevyžaduje rozsiahle spracovanie),
• bližší ostatným webovým technológiám vo filozofii dizajnu.

Schéma cloudovej služby, v ktorej sa nachádza aj komunikácia aplikácií s touto službou pomocou servisne orientovanej architektúry, je znázornená na obr. 2.

Okrem servisne orientovanej architektúry existujú ďalšie možnosti komunikácie s cloudovou službou. GET a POST môže byť výhodné pri posielaní súborov:

• GET – dáta prenášané touto metódou sú viditeľné v URL adrese v texte za otáznikom. Výhodou je, že používateľ vidí, aké dáta odosiela. Nevýhodou je nevhodnosť využívania tejto metódy pri odosielaní citlivých dát (hesiel a pod.).
• POST – dáta nie sú viditeľné a prenášajú sa skryto na serveri. Metóda je vhodná aj na prenášanie citlivejších dát.

Zaujímavá technológia je tiež SignalR [6] od spoločnosti Microsoft. ASP.Net SignalR používa technológiu websockets a je to knižnica, pomocou ktorej je jednoduché vytvárať obojsmernú komunikáciu medzi klientom a webovým servisom takmer v reálnom čase.

Využitie SOAP na prepájanie robota s cloudom

Skúmali sme dva spôsoby, ako sprostredkovať komunikáciu robota NAO s Windows Azure pomocou SOAP. Na cloude sa nachádzala služba WCF, ktorá očakávala požiadavku od klienta.

Ako prvý spôsob sme testovali vytvorenie WCF klienta v programovacom jazyku C#. Tento spôsob je najjednoduchší, pretože aj WCF služba na cloude bola vytvorená v tomto jazyku a z toho dôvodu možno pri komunikácii používať objekty tried nachádzajúcich sa vo frameworku .NET. Podrobný opis WCF sa nachádza v [1]. Nevýhodou používania WCF klienta napísaného v jazyku C# je nutnosť mať počítač ako medzičlánok medzi cloudom a robotom, pretože na robotovi typu NAO nemožno natívne spúšťať programy napísané v tomto jazyku.

Z predchádzajúcej časti vyplýva nutnosť zmeniť programovací jazyk v prípade potreby vynechania počítača ako prostredníka medzi cloudovou službou a robotom NAO. Vybrali sme si jazyk Python, ktorý je najintuitívnejší a priamo podporovaný na prácu s NAO.

Dostupných je niekoľko knižníc na vytváranie SOAP klienta v jazyku Python, niektoré sú spomenuté v nasledujúcej sekcii:

• SOAPy [7] – kedysi bol považovaný za najlepšiu knižnicu na prácu so SOAP pre Python. Táto knižnica už nie je podporovaná a nie je kompatibilná s jazykom Python verzie 2.5 a vyššej.
• ZSI [8] – knižnica bola náročná na používanie a vývoj v ZSI je veľmi pomalý pre komplikovanosť knižnice. 
• SUDS [9] – je jednoduchý na vytváranie SOAP klientov. Vytváranie SOAP služby je však zložitejšie.
• Spyne [10] – opačný prípad ako pri SUDS. Pomocou spyne je jednoduché vytvoriť SOAP servis, ale vytvorenie klienta je zložitejšie. Veľkým mínusom spyne je chýbajúca dokumentácia.
• Pysimplesoap [11] – veľmi zjednodušená verzia SOAP. Je však vhodná na oboje: na vytváranie klienta aj služby.

V poslednej časti tohto článku si ukážeme tri typy úloh, ktoré sa môžu vyskytnúť pri komunikácii robota s cloudom a takisto problémy, ktoré môžu vzniknúť pri týchto úlohách, ak na vytvorenie SOAP klienta používame iný jazyk ako na vytvorenie servisu na Windows Azure.

Typy úloh pri komunikácii robota s cloudom pomocou SOAP a problémy s nimi spojené

Rozhodli sme sa testovať SOAP na troch rôznych typoch úloh:

• robot pošle jednoduchý text na cloud, text sa na cloude zmení, pošle sa späť robotovi a ten ho povie,
• robot pošle súbor, ktorý bude mať uložený u seba v pamäti na cloud a na cloude sa uloží do dátového úložiska,
• riadenie robota prostredníctvom cloudu – keď používateľ klikne na tlačidlo „dopredu“, robot začne kráčať dopredu.

Prvou úlohou, pri ktorej sme testovali SOAP, bolo, že NAO poslal na cloud reťazec, napríklad „hello world“ a na cloude sa pridali slová „from the cloud“. Následne sa táto veta poslala späť robotovi a ten ju povedal. Tento typ úloh je najjednoduchší, keďže Python aj C# majú prácu s reťazcami podobnú.

Druhý typ úlohy bol prenos súboru z robota na cloud. Tento typ úlohy môže byť v cloudovej robotike zaujímavý, pretože robot nemusí mať u seba uložené veľké množstvo dát. Ak program na robotovi vytvorí nejaký súbor, ten ho nemusí neustále skladovať v pamäti, ale môže ho poslať na cloud. V prípade potreby si ich robot môže hocikedy stiahnuť z cloudu, takže nemusia byť veľké požiadavky na jeho pamäť. Prenos súboru medzi robotom a cloudom je zložitejšia operácia ako jednoduchá modifikácia reťazca. Je to z toho dôvodu, že neexistuje jednotná reprezentácia súboru v jazykoch Python a C#, keďže stream je v jazyku Python reprezentovaný inak ako v jazyku C#.

Prvotnou myšlienkou bolo načítať súbor ako pole bytov, lenže ako sa ukázalo, ani reprezentácia polí nie je jednotná. Následne sme testovali načítavanie jednotlivých bytov, poslali ich ako jeden reťazec znakov a následne sme sa ho pokúsili na strane cloudu rozkódovať. Aj táto alternatíva zlyhala, pretože niektoré byty majú až dva znaky (jeden znak je obrátená lomka) a previesť takéto pole späť na súbor je príliš komplikované. Konečným riešením bolo nakoniec načítať súbor po bytoch, tie rozložiť na bity a poslať nakoniec reťazec núl a jednotiek na Windows Azure. WCF servis obsahoval funkciu prijímajúcu ako parameter reťazec bitov. Táto funkcia tento reťazec dekóduje späť na pole bytov a ten je uložený ako súbor zodpovedajúceho formátu v cloudovom úložisku.

Posledný typ úlohy bolo riadenie robota takmer v reálnom čase pomocou príkazov zadaných používateľom na našej cloudovej službe. Pri tomto type úloh bolo potrebné dobre navrhnúť SOAP klienta rovnako ako cloudovú službu, keďže v SOAP sa štandardne používa jednosmerná komunikácia. Systém sme navrhli tak, že klient volá funkciu cloudovej služby v pravidelných časových intervaloch a keď dostane odpoveď, vykoná zadanú činnosť. Pri použití viacerých robotov treba rozoznávať, ktorá správa prislúcha ktorému robotovi. Tento problém sa dá vyriešiť pridaním jedného zoznamu pre každého robota.

Pri testovaní SOAP na komunikáciu robota s cloudom sme mohli zanalyzovať vhodnosť tejto metódy pre jednotlivé typy úloh. Pri prenose reťazca na cloud, jeho následnej modifikácii a vrátení späť robotovi sa použitie SOAP ukázalo pre vývojára realizovateľné jednoduchým a zároveň účinným spôsobom. Pri prenose súboru z robota na cloud bolo použitie kombinácie WCF a Suds komplikovanejšie pre nekompatibilitu streamu v jazyku C# a jazyku Python. Aj napriek tomu, že sa nám to podarilo vyriešiť, nebolo to optimálne riešenie (pretože rozkladanie bytov na bity zbytočne zaberá výpočtový čas). Prenos súboru by bolo možné jednoduchšie realizovať pomocou metód GET a POST. Pri riadení robota pomocou rozhrania na cloude by bolo zasa vhodnejšie použiť technológiu websocket a knižnicu SignalR, ktorá je pre takéto úlohy navrhnutá.

Cloud robotika – zhrnutie

V tomto seriáli sme sa venovali problematike cloud robotiky ako možnosti využitia cloudových technológií v oblasti robotiky. V troch častiach sme sa postupne venovali tomu, na čom sa pracuje a čo sa testuje v našom laboratóriu.

V prvej časti seriálu sme sa venovali všeobecnému prehľadu o cloude a cloudovej robotike. Opísali sme, čo je to cloud a aké má vlastnosti. Tiež sme spomenuli existujúce systémy v cloudovej robotike, ako je RoboEarth alebo ASORO. V závere prvej časti sme povedali, aký dosah môže mať cloudová robotika na metódy UI a robotiky.

V druhej časti sme sa venovali špecifickej oblasti cloudovej robotiky, a to rozpoznávaniu obrazu ako cloudovej služby. Opísali sme architektúru a implementáciu daného systému, zároveň sme ukázali doterajšie experimenty vykonané na menších častiach tohto systému.

V poslednej časti sme spomenuli niekoľko možností, ako môže robot komunikovať s cloudovou službou, a podrobne sme sa zamerali na metódu SOAP. Opísali sme, čo znamená mať WCF službu na cloude, ako vytvoriť klienta komunikujúceho s touto službou v jazyku C#, resp. jazyku Python. Nakoniec sme uviedli tri úlohy, pri ktorých sme testovali SOAP.

Literatúra

[1] Windows Communication Foundation. [online]. Dostupné na: http://msdn.microsoft.com/en-us/library/vstudio/ms735119(v=vs.90).aspx.
[2] Windows Azure. [online]. Dostupné na: http://www.windowsazure.com/en-us/.
[3] Lorenčík, D. – Sinčák, P.: Towards Cloud Robotics Age. In: 13th Scientific Conference of Young Researchers 2013. s. 43 – 46.
[4] Google App Engine. [online]. Dostupné na: https://developers.google.com/appengine/?csw=1.
[5] http://www.worldtvpc.com/blog/wp-content/uploads/2012/07/windows_azure-diagram1.jpg
[6] SignalR. [online]. Dostupné na: http://signalr.net/.
[7] SOAPy. [online]. Dostupné na: http://soapy.sourceforge.net/.
[8] ZSI. [online]. Dostupné na: http://pywebsvcs.sourceforge.net/.
[9] SUDS. [online]. Dostupné na: https://fedorahosted.org/suds/.
[10] Spyne. [online]. Dostupné na: https://github.com/arskom/spyne.
[11] Pysimplesoap. [online]. Dostupné na: https://code.google.com/p/pysimplesoap/.