Máme zariadenia, roboty, ktoré sú vybavené rôznymi špecifickými senzormi, aktuátormi, softvérom a pod. Tieto zariadenia môžu byť rôzne. Za zariadenie môžeme považovať aj senzor, ktorý len generuje dáta o prostredí, ale tiež to môže byť robot, počítač, smartphone a pod. Nad zariadením je zvyčajne naprogramovaná tzv. obálka, čo je softvér umožňujúci komunikáciu medzi zariadením a udalostným serverom. Primárnou úlohou obálky je spracovanie odosielaných dát a požiadaviek takým spôsobom, aby si komunikujúce strany navzájom rozumeli. Táto časť celkovej architektúry bola predmetom nášho záujmu v prvej časti seriálu.
Dáta o prostredí generované pripojenými zariadeniami sa posúvajú do bloku učiace algoritmy, kde sa spracúvajú. V druhej časti seriálu sme sa podrobne venovali tomuto bloku. Opísali sme prístup k budovaniu bloku učiacich algoritmov ako množiny tzv. AI tehličiek. AI tehličky sú softvérové moduly, pričom každý modul rieši jednu konkrétnu úlohu a ich kolaboráciou možno riešiť zložité úlohy.
Ak je to možné a zároveň potrebné, tak v bloku extraktora pravidiel sa zo spracovaných dát generujú pravidlá o prostredí a následne sa ukladajú do databázy. Krátky pohľad do problematiky sme podali v prvej časti seriálu.
Obr. 1 Architektúra cloudového systému na podporu multirobotických systémov, upravená podľa [1]
Ak zariadenie (robot) odošle požiadavku o informáciu napríklad o tom, koľko ľudí sa nachádza v danej miestnosti, udalostný systém sa pozrie do databázy. Zistí sa, či sa daná informácia už v databáze nachádza a či je aktuálna. Ak je informácia v databáze dostupná, je vrátená zariadeniu. Ak sa tam taká informácia nenachádza, vytvorí sa postupnosť krokov, ako informáciu získať. Potom v bloku učiacich algoritmov prebehne výpočet a získa sa požadovaná informácia.
Zdanlivo posledná časť, ktorej sme sa dosiaľ nevenovali, je databáza. Predmetom nášho záujmu v tejto časti bude doplnenie skladačky o blok databázy, ktorý je kritický pre uchovávanie dôležitých dát a znalostí. Preskúmame možnosti synchronizácie dát získaných z rôznych inštancií jednej tehličky a pozrieme sa na bezpečnostné požiadavky navrhovaných databáz. Na záver ešte rozoberieme učiace prostredie pre robotického agenta. Uvedieme dve základné učiace prostredia a opíšeme rozdiely medzi učením na virtuálnych a reálnych zariadeniach.
Databázy
Blok databáz bude obsahovať celkovo dva typy databáz. Prvý typ databázy bude prístupný pre používateľov. Táto databáza bude obsahovať jednoduché pohyby, napríklad krok, zohýbanie sa, uchopenie predmetu. Používatelia budú schopní nahrávať tieto pohyby do databázy pohybov. Jedinou podmienkou toho, aby mohol používateľ nahrávať pohyby do databázy, je, že sa musí prihlásiť.
V našom systéme budeme vytvárať tri typy používateľov. Najnižší typ používateľa bude mať síce prístup do databázy pohybov, ale bude schopný iba sťahovať pohyby a nie ich nahrávať. Používateľ z vyššími právami sa bude nazývať administrátor. Tento typ používateľa bude mať rovnako ako predošlý typ právo sťahovať pohyby do databázy. Navyše bude však schopný ich aj nahrávať do databázy. Tiež bude mať práva mazať tieto súbory z databáz. Posledný typ používateľa ktorý sa bude nachádzať v našom databázovom systéme, sa volá super administrátor. Tento používateľ bude schopný nahrávať, mazať a sťahovať súbory. Navyše však bude schopný meniť práva ostatným používateľom; bude môcť dokonca meniť práva ostatným super administrátorom. Rovnako bude schopný vymazávať ostatných používateľov. Jedinou podmienkou bude, že nemôže zasahovať do vlastných práv ani zmazať samého seba. Dôvodom, prečo je to tak, je, aby vždy existoval super administrátor a aby sa nestalo, že k databáze sa nebude dať pristupovať.
Databáza bude mať prakticky aj štvrtý typ používateľa, aj keď tento typ nie je rovnocenným typom k zvyšným trom. Používateľ sa ním stane, keď sa prihlási pomocou nejakého iného typu účtu, čo môže byť napríklad účet google, respektíve facebook. Tento používateľ na začiatku nemá žiadne práva (nevie pristupovať k databázam). Musí počkať, kým mu super administrátor pridelí práva prístupu.
Na realizáciu nášho riešenia môžeme použiť dva technologické prístupy. Prvý prístup je založený na použití už existujúcej databázy. Uvažujeme, že by sme mohli použiť databázu vyvinutú v projekte RoboEarh [2]. Tento projekt bol schopný uchovávať tri typy dát. Prvým sú samotné pohyby, druhý typ sú sémantické informácie o pohyboch a nakoniec RoboEarth obsahuje aj sémantickú informáciu o prostredí robota. Keby sme použili túto databázu, bolo by potrebné vytvoriť obálku na manipuláciu s dátami v tejto databáze. Práva používateľov by ostali rovnaké, ako bolo opísané vyššie, a na základe toho, aké práva by mal ten-ktorý používateľ, by mohol pristupovať k databáze a meniť, respektíve sťahovať dáta. Problémom pri používaní tejto databázy je, že sa treba registrovať a nie je plná kontrola nad nahranými dátami. Tú by mali správcovia RoboEarth. Takže je výhodné vytvoriť si vlastné riešenie, kde by sme implementovali len funkcionalitu, ktorú bezprostredne potrebujeme. Zároveň by sme nad touto databázou mali plnú kontrolu a mohli by sme do nej podľa potreby zasahovať.
Vlastné riešenie by pozostávalo z kombinácie elementov nachádzajúcich sa v úložisku, ktoré sa ponúka poskytovateľom cloudovej služby. Napríklad pri použití Microsoft Azure [3] by robotickú databázu tvorila kombinácia tabuliek [4] a blobov [5]. Prvý Blob kontajner by obsahoval pohyby pre robota. V druhom Blobe by sa nachádzala informácia o vlastnostiach pohybu. Tabuľka bude obsahovať dôležité informácie, ako je názov pohybu a URL na stiahnutie daného súboru z Blob kontajnera.
Druhý typ databázy, ktorý bude náš systém obsahovať, je ten, kde ľudia nebudú môcť priamo prispievať (či neskôr budú môcť, bude ešte témou diskusie). Do tejto databázy budú môcť prispievať algoritmy priamo z učiaceho prostredia. Budú obsahovať výsledky učenia, či už v podobe výstupov z použitých metód, ako je napríklad súbor váh pri použití metódy spätného šírenia chyby v neurónovej sieti, alebo priamo pravidla, ktoré bude výsledkom extrakcie pravidiel.
Učiace prostredie
Učiace prostredie sa bude skladať z dvoch častí. Prvá časť je tá, ktorá sa bude nachádzať na cloude. Druhá časť bude využívať reálne prostredie. To bude spolupracovať s reálnymi zariadeniami. Táto časť sa bude používať vtedy, keď nebude možné nasimulovať reálny svet, napríklad pri interakcii človek – robot, kde treba pri učení interagovať s človekom. A keďže človeka je komplikované simulovať, používa sa reálne prostredie.
Simulačná mašina bude využívaná v prípade, že nebude potrebné reálne prostredie na učenie. Ako simulačný mechanizmus môže byť použitý profesionálne vytvorený simulátor alebo simulátor, ktorý nie presne znázorňuje reálny svet – to, či treba použiť úplný alebo len „približný“ simulátor, záleží na problémoch, ktoré chceme riešiť. Podmienkou však je, aby bolo možné vytvárať prostredie softvérovo, teda nie manuálne v simulátore. Následne prebehne učenie na tomto prostredí, takže je potrebné, aby použitý simulátor vedel prijímať „správy“ od učiacich algoritmov a na základe nich ovládať virtuálnych agentov. Jedným z možných prístupov v našej práci je využitie simulátora webots [6], ktorý bude nainštalovaný na cloude. Takto pripravený bude používaný ako simulačný mechanizmus. Hypotézu o použití simulátora webots ako učiaceho prostredia na cloude potvrdia (vyvrátia) až experimenty.
Udalostný server na základe požiadavky automaticky rozhodne, či stačí, aby sa požiadavka riešila v simulátore, alebo treba využiť reálne prostredie.
Zhrnutie
V úvode tohto príspevku sme zhrnuli všetky informácie o navrhovanej architektúre cloudového prostredia na podporu multirobotických systémov. Na príklade sme uviedli tok dát a ozrejmili sme funkcionalitu jednotlivých blokov architektúry. Podrobnejšie sme sa zamerali na ostávajúce dva bloky navrhovanej architektúry. Hovorili sme o bloku databázy, ktorá slúži na ukladanie dôležitých dát a vyextrahovaných znalostí. Diskutovali sme o jej návrhu, implementácii, bezpečnosti, efektívnosti a pod. Druhý podrobne rozobratý blok bol blok učiaceho prostredia. Tu sme rozobrali možnosť učenia a extrakcie znalostí v simulovanom prostredí pomocou simulovaných zariadení. Porovnali sme výhody a nevýhody učenia v reálnom a simulovanom prostredí a rozobrali sme aj to, kedy je ktoré prostredie vhodnejšie použiť.
Takto sme dospeli k záveru našej cesty, v ktorej sme objasňovali celkovú architektúru. Na záver by sme snáď mohli uviesť už len niekoľko výhod použitia opísanej architektúry, respektíve opisovaného systému. Výhodou tejto architektúry je, že jednotlivé bloky budú môcť pracovať samostatne aj ako časť jedného veľkého systému. A keďže blok učiacich algoritmov bude realizovaný ako množina AI tehličiek opísaných v [7], pôjde o maximálne modulárny systém. Pridanie nového algoritmu alebo funkcionality tak bude triviálne.
Literatúra
[1] Cádrik, T. – Ondo, J. – Mach, M. – Sinčák, P.: Základná architektúra cloudového prostredia na podporu multirobotických systémov (1). In: ATP Journal, 2015, ročník, číslo, strany?
[2] What is roboearth? [online]. Dostupné na: http://roboearth.org.
[3] Microsoft Azure. [online]. Dostupné na: http://azure.microsoft.com/en-us/.
[4] Table storage. [online]. Dostupné na: http://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-how-to-use-tables/.
[5] Blob storage. [online]. Dostupné na: http://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-how-to-use-blobs/.
[6] Webots. [online]. Dostupné na: http://www.cyberbotics.com/overview.
[7] Cádrik, T. – Ondo, J. – Mach, M. – Sinčák, P.: Základná architektúra cloudového prostredia na podporu multirobotických systémov (2). In: ATP Journal, 2015, ročník, číslo, strany 47
Záver seriálu
Ing. Tomáš Cádrik*
tomas.cadrik@tuke.sk,
+ 421 55 602 5101
Ing. Jaroslav Ondo
jaroslav.ondo@tuke.sk
+421 55 602 5111
doc. Ing. Marián Mach, CSc.*
marian.mach@tuke.sk
+421 556 022 571
prof. Ing. Peter Sinčák, CSc.*
peter.sincak@tuke.sk, +421 556 027 642
* Centrum pre inteligentné technológie
Katedra kybernetiky a umelej inteligencie
Technická univerzita v Košiciach
www.ai-cit.sk, www.kkui.tuke.sk, www.tuke.sk
