O programování kolaborativních robotů aneb Budou průmyslové aplikace programovat studenti?

Pod pojmem „Průmysl 4.0“ si už skoro každý dokáže něco představit – ať už je to intenzívní využití senzorů ke sledování výroby, připojení cloudových úložišť k agregování těchto dat a generování reportů, nebo automatizace samotných továren pomocí robotických pracovníků. Od nepaměti však k rozvoji elektroniky a počítačů patří ještě jedna výzva, a tou je zjednodušování uživatelského rozhraní a rozšiřování řad uživatelů, kteří chápou, co se v systému děje, případně jak jej upravit.

S příchodem nové průmyslové revoluce tomu není jinak a neviditelná ruka trhu nasměrovala výrobce robotických systémů do bezprecedentního směru – vytvářet či měnit programovou výbavu robota má zvládnout i řadový zaměstnanec bez vzdělání v IT nebo elektrotechnice.

Od Assembleru k Legu

Těm nešťastníkům, kteří pamatují psaní desítek řádek kódu v Assembleru, jen aby na chvíli roztočili motor připojený k PLC, připadala možnost využít jazyk C jako spása. Od počítačového pravěku však uplynulo mnoho času, a jak víme díky lingvistice, i jazyk se časem mění. Snad nikde tento fakt není tak očividný, jako právě u počítačů, kde se s každou další vrstvou abstrakce jazyk přibližuje reálné lidské mluvě. Z pro smrtelníka nesmyslných sekvencí znaků, které snad „magicky“ rozhýbaly obrazovku monitoru, se staly grafické kostičky, které pochopí a ovládne i desetileté dítě.

Obrázek 1: Užití projektu Blockly ve webovém prohlížeči. [1]

Například projekt Blockly vyšel na světlo světa skoro před osmi lety. Pod taktovkou společnosti Google a univerzity MIT umožňuje nováčkům v IT pochopit základní principy a struktury programování. Co se robotů týče, v současnosti jej můžete použít například společně s edukativním robotem Ozobot. Obdobným směrem se v roce 2013 vydala i společnost Lego, která díky svým stavebnicím Mindstorms vychovává nové programátory jak na středních, tak vysokých školách.

Obrázek 2: Příklad užití programovacího rozhraní pro výukového robota Lego EV3. [2]

KOS-TIČ-KY!

No dobrá, ale co mají společného dětské hry a továrny, kde je potřeba svářet, pájet, lisovat a vůbec dělat nebezpečné věci? Na první pohled nic, ale s přihlédnutím k předchozím odstavcům si musíme uvědomit, že nastavit „robůtka“ tak, aby jel z místa A do místa B a zpátky, se učí děti od doby, kdy ovládnou čtení, psaní, počítání... a myš. A takové překládání výrobku z pásu do plata přece není nic jiného než program „jeď do A, vezmi díl, jeď do B, odlož díl, opakuj“.

Obdobné uživatelské rozhraní, jako jsme si představili v předchozí kapitole, nabízí prakticky všichni výrobci kolaborativních robotů. Jednoduchý program je pak intuitivní formou schopen vytvořit i nekvalifikovaný dělník či mladý brigádník a je jedno, jestli se mu do ruky dostane robot Sawyer z dílny Hahn Robotics, nebo UR10 od Universal Robots – filosofie je obdobná, stroj musí umět oživit prakticky kdokoliv.

Obrázek 3: Programovací rozhraní Intera 5 zobrazuje animaci reálného robota Sawyer. [3]

Teoreticky teď můžeme dojít k závěru, že továrnu může automatizovat i malé dítko. Ale je tomu tak? Stačí krátká a upřímná odpověď? Pak zní: „Ne.“

Návrat do reality

Nasadit robota do továrny však není tak jednoduchá a přímočará úloha, jak by se mohlo zdát. Když pomineme čistě manažerské a byznysové úkony, jako jsou smlouvy o financování, funkční specifikace a akceptační protokoly, stále nám zůstanou podproblémy, které se nevyřeší skládáním kostiček na libovolné obrazovce.

Jedna z nejrozsáhlejších kapitol nasazování robota je totiž jeho fyzické umístění, ukotvení do země či na strop, vyřešení pojezdů a klecí pro další zabezpečení pracoviště (které není u kolaborativního robota ve výchozím nastavení nutné, ale například svářečkou může ublížit i přes veškerou opatrnost na světě). Způsob dopravy dílů k robotovi i od něj by pak mohl vydat na vlastní podkapitolu a o vytváření vlastního „gripperu“ (chapadla) by mí kolegové určitě zvládli sepsat celá skripta. Na scénu musí přijít konstruktér, vše pečlivě prozkoumat, nastudovat a přeměřit, aby mohl vytvořit precizní 3D model, vymyslet dopravníky a udělat veškerou, řekněme, „statickou“ přípravu.

Šetříme na nejdražších položkách

Po odstranění managementu a konstruktérů se můžeme vrátit k programové výbavě robota a otázce, která je určitě jednou z primárních motivací zjednodušování programátorského rozhraní robotů: „Jde z procesu vyškrtnout drahý softwarový vývojář?“

Pro mnohé je to určitě lákavá představa, pro mě (jakožto pro drahého softwarového vývojáře) je to samozřejmě vize apokalypsy. Je však několik důvodů, proč se „nebojím“, že se něco takového v blízké budoucnosti stane, a zároveň jsou to důvody, proč si myslím, že čistě grafické rozhraní pro programování, nejen robotů, nepatří do profesionálního prostředí.

Analýza operace

Jak poskládat zmíněný program „jeď do A, vezmi díl, jeď do B, odlož díl, opakuj“ si asi dovede představit po přečtení a prozkoumání předchozího textu i čtenář programováním nepolíbený. Co když se má robot ale po cestě vyhnout překážce? A pak odložit díl dál, tam počkat, pak použít jiný nástroj a díl třeba nabarvit?

Práce programátora není přece jen psaní kódu, tomuto úkonu předchází důležitá analýza. Čím je operace složitější, tím těžší je si ji pomyslně rozkouskovat na související bloky. S počtem vstupů pak roste náročnost na logiku přechodu mezi jednotlivými povolenými stavy robota. A výsledný program není pouhou sumou jeho částí – román Romeo a Julie by také nedával smysl, pokud by byly kapitoly naskládány náhodně. Jak s oblibou říkám svým studentům se zájmem o programování: „Program je příběh o datech.“ A věřím, že stejně jako zkušený programátor, i Shakespeare před vlastním psaním příběhu začal rozvahou a analýzou, jak jednotlivé části rozumně propojit.

Obrázek 4: Část diagramu popisujícího operace potřebné k tomu, aby dva roboti společně uvařili kávu

Obrázek 5: Roboti čekají na novou objednávku kávy.

Je tedy zjevné, že k analýze reálného průmyslového projektu „amatér“ nestačí. I přes znalost „spojování kostiček“ mu totiž chybí teoretický aparát potřebný k úspěšné kompletaci úlohy. Můžete namítat, že stavový diagram není nic těžkého a udělat hlubokou a důslednou rozvahu přece může každý. Realita je však taková, že se mnohdy zmýlí i praxí ošlehaní veteráni a v průběhu časově nákladného vývoje zjistí, že se věc má zkrátka jinak.

Pokud se náš teoretický amatér dostane do takové hloubky, že vytvoří stavový diagram, s trochou štěstí si povšimne dvou zásadních věcí, které ho předtím nemusely vůbec napadnout, pro vývojáře běžného softwaru jde však o dennodenní chléb:

Zaprvé: Výjimky

Terminus technicus, který každý programátor zná. Tzv. výjimka je neočekávaná situace, vzniknuvší za běhu programu. Uvedu jednoduchý příklad pro čtenáře, pro které je toto novinka: Na webové stránce vyplníte do kolonky „telefonní číslo“ řetězec „TOTO NENÍ TELEFONNÍ ČÍSLO“, aplikace na straně serveru se poté tento řetězec pokusí uložit k vašemu účtu jako telefonní číslo, ale databázový systém do této kolonky potřebuje... číslo. A tak vyvolá výjimku, operaci přeruší, všechny změny vrátí do původního stavu a uživateli pravděpodobně zobrazí chybovou hlášku.

V robotice, a speciálně při nasazení v průmyslu, dostává pojem Výjimka další rozměr. Počítačová či mobilní aplikace upozorní uživatele, a pokud je to možné, pokusí se o nějakou automatickou nápravu, nebo se prostě ukončí. To však v továrně není docela dobře možné, a je tedy nutné pečlivě ošetřit tyto výjimečné stavy. Co udělat, když robot nenabere nový díl? Co když mu cestou ke stroji upadne z gripperu? A pokud do něj někdo při sváření nebo lepení drkne, je díl k zahození, má začít od znovu, nebo pokračovat bez přerušení?

Obrázek 6: Ukázka kolize robota a zaměstnance, s pomocí produktu AIRSKIN vytvoříte kobota z jakéhokoli průmyslového robota. [4]

Tyto „základní“ výjimky nelze ošetřit tak prostě, jako je tomu v případě počítačových/mobilních/webových aplikací, kde mnohdy stačí danou aktivitu „nahrubo“ restartovat a doufat, že uživatele neotrávíme tak, aby aplikaci smazal. Továrnu však zastavit nemůžete, restartovat výrobní proces není jednoduché a zahodit každý díl při nejmenší nesrovnalosti v systému se může výrazně prodražit. Náš stavový diagram popisující celou operaci se tak značně rozrůstá o podproblémy ošetření těchto výjimečných situací – a prakticky v jakémkoli stavu se může operace přerušit. Diagram tak násobně bobtná, co se počtu stavů samotných týče, ale exponenciálně nám roste také množství povolených přechodů mezi těmito stavy, jelikož, na základě mnoha různých parametrů, třeba dokončenosti úlohy, požadavků na přesnost nebo podle zásahu operátora, může robot ze stavů výjimečných přecházet zpět do různých stavů běžné produkce a množství „cestiček“, kterými se může vydat, se rozšiřuje.

Zadruhé: Komunikace

Jedním z největším „show-stopperů“ (nepřekonatelnou překážkou k dosažení cíle) je fakt, že požadavky na nasazení robota do továrny se málokdy omezují na prosté, ba až tupé překládání dílu z místa na místo. Po robotu je požadována součinnost s externími systémy, ať už jde o dopravníky indikující přítomnost nového dílu, obsluhované stroje, které mají vlastní stavy, na které musí robot reagovat, či snad ERP systémy, jako je Helios, jež mohou robotu přikazovat, jaký typ/druh/barvu dílu mají zrovna vyrábět.

Toto je další z míst, kde se při integraci robota hodí „ostřílený“ vývojář, kterému dávají smysl pojmy jako interface, TCP/IP nebo PROFINET. Samotný návrh těchto komunikačních rozhraní, přes která si stroje vyměňují životně nutná data, je operace vyžadující zkušenost a cit pro techniku.

Obrázek 7: K tomu, aby si roboti povídali, bohužel nestačí dvě plechovky. [5]

Co se komunikace s externími systémy týče, rád bych zmínil ještě senzorovou výbavu pracoviště. Našich pět smyslů a generalizující inteligence nám umožňuje vidět problém a řešení intuitivně, počítače tak však nefungují, a každou kritickou podčást procesu je třeba ověřit. Z praxe posledních dní nás například trápily otázky „podařilo se robotovi korektně díl vložit do stroje / vyndat ze stroje?“, nebo „má robot na paletě další díly, nebo už má hotovo?“, ale je jich určitě nekonečná množina. Robot vám tyto otázky sám o sobě neodpoví, stroj, který obsluhuje, pravděpodobně také ne. Na scénu se tedy vrací konstruktér a ruku v ruce s vývojářem vymýšlí, kam, kudy a jaký zapojit senzor, vznikají požadavky na fyzickou změnu pracoviště a rozšiřuje se množina vstupů do programového toku, které mění logiku přechodů mezi povolenými stavy.

Kuchařka z vás kuchaře nedělá

Pokud tedy známe všechny požadované stavy, všechny možné chyby, víme, jaké potřebujeme senzory a signály, můžeme se pustit do kódování, potažmo do operace, kterou můžeme brzy znát pod pojmem „kostičkování“. Záhy zjistíme, že osoba bez náležitého vzdělání či zkušeností je opravdu schopná z místa A do místa B přenést díl, má však problémy se zakomponováním externích dat do toku programu a se zapouzdřením jednotlivých celků do bloků, jehož výjimky jsou náležitě ošetřeny.

Naskýtá se otázka, která, dle mého skromného názoru, chyběla u analýzy při vymýšlení těchto „WYSIWYG“ systémů pro účely jiné než edukativní: „Mají firmy zájem ze všech svých řadových zaměstnanců vychovat programátory?“ Bez námitek chápu požadavky na jednoduchou administraci či drobné úpravy úloh, ale je potřeba, aby kompletní logice rozuměl každý? Rozumíte makrům Excelu? Ne? A znemožňuje vám to je používat?

Zlatá střední cesta

Aktuální stav z mého hlediska značně utlačuje klasické vývojáře na úkor zjednodušování zcela triviálních podúloh. Ano, z místa A do místa B tedy přejedeme po třech minutách programování, ale naopak zprovoznění komunikačního protokolu pomocí kostek trvá násobně déle než napsání 50 řádek kódu, které se o to bezpečně postarají, o nějaké dlouhodobé údržbě či verzování programu ani nemluvě.

Jakožto šéf softwarového vývoje vidím řešení přesně uprostřed. Nenuťme všem umění programování. Nenalhávejme si, že to není umění, ke kterému je třeba talent, a nesnažme se odříznout programátory, alespoň ne úplně. Střední cesta je pak vesměs přímočaré rozříznutí vývoje na dvě části: Nechte programátora nadefinovat stavy, rozhraní a externí komunikaci. Nechte jej vytvořit kostru programu, ať už v kostičkách, nebo kódem (a hádejte, co si sami zvolí), která bude tyto složitosti řešit a vyřeší i případné chyby a výjimky. Jakmile bude tato kostra, či snad „scénář nasazení“ hotov, může operaci dodělat kdokoliv – zbude v ní totiž přesně to, co demonstrují výrobci kobotů, když chtějí ukázat, jak oživí stroj za tři minuty, tedy „tady naber díl, přejeď jinam, pusť díl“ a podobné základní operace, které mohou být zdlouhavé, pokud vyžadujeme vysokou přesnost, a je nutné je dělat na místě nasazení robota, ale není k nim třeba vzdělání, praxe ani závratný intelekt.

Obrázek 8: Zaměstnanec ukazuje robotovi požadovanou pozici. [6]

Ideální stav si pak představuji coby dolaďování robota spíš jako sekvenci instalačních dialogů, než jako vytváření programu. Programátor vytvoří kostru operace, nadefinuje, co je potřeba k přechodu mezi jednotlivými kroky, apod., člověk nasazující robota nahraje program od vývojáře a zobrazí se mu dialog: „Jeďte do místa náběru.“ a tlačítko OK, pak „Stiskněte ovladač aktivace gripperu“ a tlačítko OK. Tímto by náš „nekvalifikovaný dělník“ dokázal robota nasadit, nastavit a přivést k životu, aniž by musel znát teorii programování či myšlenkové nástroje k analýze projektu.

Zdroje

Nahoru

Domů