Čechům se podařil průlom v „teleportaci“. Skutečný svět lze živě přenášet do virtuálního

České firmě Pocket Virtuality, za kterou stojí spoluzakladatel Bohemia Interactive Jan Hovora, se podařilo překonat další milník vedoucí k virtuální „teleportaci“. Platforma Fata Morgana umí v reálném čase přenášet obraz snímání brýlemi Microsoft HoloLens 2 pro rozšířenou realitu (AR), spojovat ho s dalšími 3D informacemi a zobrazovat ho uživatelům například ve virtuální realitě (VR).

Firma, do které investoval fond Touzimsky Kapital, dokáže zpracovávat obraz z AR brýlí společně s dalšími zdroji dat, jako jsou IR, makro, stereo či termální kamery přidělané na samotný headset. Pocket Virtuality si na HoloLens dělají vlastní úpravy.

Fata Morgana míří k využití v průmyslu a dalších oblastech. Myšlenkou je, že si pracovník nasadí HoloLens, bude se pohybovat například u nějakého stroje a přenášet obraz do vzdáleného centra. Tam bude možné vidět přenášený obraz tak, jak ho vidí pracovník na místě. Nabízí se tak nasazení při údržbě a tak dále. Produkt testují Škoda a Škoda JS nebo Aero Vodochody.

Pocket Virtuality také dokázali platformu napojit na ROS operační systémy robotů a dronů. Je tak možné přistupovat k jejich senzorům a ovládat je.

Jan Hovora v rozhovoru pro Lupu popisuje další detaily.

Autor: Jan Sedlák Jan Hovora, Pocket Virtuality

Začali jste si dělat vlastní úpravy na AR brýlích HoloLens 2, zaujalo mne například přimontované aktivní chlazení. Jaké přesně změny děláte a proč je to potřeba?

Neupravujeme přímo brýle, ale konstruujeme a 3D tiskneme různé doplňky. Některé se do výsledných produktů dostanou, některé ne. Ve Starter Kitu je například speciální štít, který z HoloLens udělá VR brýle. Zakryje výhled, ale nechá volné senzory s tím, že je možné nasadit měkčenou obrubu z VR headsetu. Dále jsme vyvinuli obecný nástavec, který nám umožňuje připojovat různé typy kamer a zároveň nasazovat na vestavěnou kameru v HoloLens různé typy filtrů a předsádek. Z tohoto prototypu pak vzniklo finální řešení pro Fata Morgana Camera Kit, kde je jednoúčelový nástavec s integrovanou makro kamerou a klip, jenž umožňuje zároveň brýle za chodu nabíjet a mít připojený kamerový nástavec.

Zde je důležité vysvětlit, že i když HoloLens běží na Windows, nemůžete k nim jen tak připojit USB kameru jako k počítači a začít ji používat. Museli jsme napsat vlastní nízkoúrovňový přístup k těmto zařízením.

Pro Teleportation Kit, na němž stále pracujeme, bude existovat podobný systém se stereokamerou a možná i externí chlazení, a to jak vepředu na HPU (Holographic Processing Unit), tak vzadu na CPU – uvidíme, zda to bude potřeba. Důvodem je to, že při teleportaci brýle extrémně zatěžujeme. Procesor tak na 150 procent a podobné je to u HPU. Při „teleportaci“ totiž využíváme research mode, tedy čteme low level data ze všech strukturálních senzorů a posíláme je ven. Velmi to tlačí na sběrnici, kvůli kompresi na CPU a stejně tak na Wi-Fi modul.

Jste schopní v reálném čase přenášet video z rozšířené reality z více zařízení. Jak to technicky funguje?

Náš systém umožňuje přijímat a zpracovávat datový stream z N připojených brýlí, na kterých mohou být navíc další dodatečné kamery. Kromě toho do systému může přicházet obraz z dalších zařízení namapovaných na takzvané FM zařízení. To tvoří jakýsi datový můstek mezi například statickými kamerami, roboty a podobně. Každé takové zařízení je navíc v našem systému plně prostorově lokalizované.

Všechna tato zařízení jsou připojena do naší sítě pomocí speciálního síťového protokolu FM Link. Systém jim vytváří avatary, mapuje na ně ovládací prvky a podobně. Síťový protokol podporuje něco jako kanály. Ty mohou mít různé priority. Pokud se tedy úplně nenasytí pásmo, RT streamy stále poběží s poměrně malou latencí. U dat s nižší prioritou se latence začne zvětšovat.

Za jakých podmínek jste schopní tohoto dosahovat?

Samozřejmě záleží na konektivitě. Pokud bude brýlí a na nich připojených kamer hodně, je vhodné, aby každé brýle nebo robot měly ideálně vlastní Wi-Fi router.

Jaké podmínky budou potřeba pro běžný provoz?

V běžném provozu potřebujeme na místě obvykle jedny, nebo maximálně dvoje brýle. K tomu tradičně jeden nebo dva videostreamy, k čemuž stačí slušně fungující mobilní LTE Wi-Fi router, pokud jste v terénu. Když jste v továrně, je většinou k dispozici Wi-Fi. Důležité je si také říci, zda máte na místě přenosný počítač k předzpracování a kompresi dat. Obvykle totiž data, která mají opustit místo, nemusí být jen zašifrována, ale chcete z nich odstranit i citlivý obsah. Pak je lokální předzpracování na místě a mimo brýle nutné.

Fata Morgana od Pocket Virtuality:

S jak velkými datovými toky, kompresi a předzpracováním edge zařízení pracují?

Většinou jde o stovky megabitů za sekundu. Toto je zajímavé, ale ne úplně jednoduché téma. Pokud máte k dispozici Wi-Fi, ukazuje se, že je lepší méně tlačit na kompresi a více využívat pásmo. Komprese, co se týče zátěže CPU a GPU, je poměrně drahá v případě, že u toho máte ještě zobrazovat 3D obsah, provádět sken a tak dále. Takže v našem případě v podstatě tlačíme MJPG z hlavní kamery HoloLens. To samé děláme z připojených kamer, kdy by bylo ideální dokázat číst MJPG přímo z připojené kamery (vybírat jen takové, které to umí) a jen ho posílat dál. To se nám bohužel kvůli různým chybám ve Windows nedaří a musíme číst RAW data a na nich dělat kompresi.

Zde se objevuje další zádrhel. Většina kamer, které se používají ve vidění, včetně té v HoloLens, pracují s YUV, protože pro většinu aplikací tohoto typu stačí pracovat jen s jasem. Problém spočívá v tom, že systémový Windows UWP hardwarový kompresor JPG umí pracovat pouze s RGB, které následně opět převádí do YUV, protože na tom je komprese JPG založená. Tato operace je navíc zoufale neefektivně napsaná a nesmírně zatěžuje procesor, kdy 90 procent času komprese na HoloLens zabírá tento převod barevných prostorů.

Z toho důvodu jsme se původně pokoušeli implementovat vlastní JPG kompresi, ale ani nejrychleji napsaná CPU komprese nemá šanci oproti té hardwarově akcelerované. Takže jsme nakonec zvolili střední cestu a napsali v assembleru vlastní převod barevných prostorů místo používání toho systémového, což zlepšilo propustnost asi pětkrát. Nyní jsme schopní na rozdíl od systémového streamování obrazu dostat ven i Full HD, případně několik datových streamů naráz. Ideální by bylo, aby k tomu převodu vůbec nemuselo docházet, ale to se současnou verzí operačního systému HoloLens bohužel není možné. Obojí má Microsoft od nás nahlášené.

Co je zač vaše vlastní videostreamovací platforma?

V podstatě se jedná spíše o vlastní datový kontejner. MJPG, MPG ani Windows UWP (Media Foundation) nemají dobře řešená metadata a my potřebujeme s každým snímkem poslat mnoho dalších dat. Potřebujeme například zařídit, aby snímky ze všech kamer a hloubková mapa přišly ve stejný okamžik a aby obsahovaly lokalizaci v prostoru v každém snímku a další parametry kamery. Náš videoformát přesně toto umožňuje a navíc pracuje s prioritizací a cache.

Umíte také připojit roboty, kteří mají ROS systém. To znamená, že se můžete přes API dostat k jejich senzorům, ovládáním a podobně?

Trochu už jsem to nakousnul v dřívější odpovědi. Každý objekt v našem systému je vlastně něco jako avatar, který nabízí ostatním objektům nějaké komunikační rozhraní, a to jak pro příjem dat, tak pro vlastní ovládání (záleží, jaké možnosti deklaruje). Tyto objekty mohou být skutečné a avatar je jejich virtuální reprezentací (digitální dvojče), nebo mohou být zcela virtuální. Tento přístup umožňuje, aby jakýkoliv IoT nebo robotický systém mohl být mapován do naší platformy.

V současné době máme těsně před dokončením datový můstek z ROSu (Robot Operating System) právě do této reprezentace. To nám umožňuje vytvořit virtuální kopii skutečného nebo simulovaného robota, přijímat data, která produkují jeho senzory, a ovládat ho, případně i impersonovat v reálném čase.

V dalších fázích chcete dělat spojení různých druhů dat. Jak by to mělo fungovat, aby to v praxi bylo použitelné? „Naházíte“ data do nějaké NoSQL databáze a nad tím budete stavět?

Představte si situaci, kdy máte sken z brýlí a k tomu sken z velkého statického laseru. Nebo ještě lépe vám brýle mapují prostředí, kam jdete, a vedle toho s vámi spolupracuje dron. Představte si třeba velkou loď se spoustou kontejnerů, kde ne ke všem se dostanete pěšky. V principu tím, že každý avatar ví, kde se nachází (díky našemu systému a SLAMu), všechna data, která získáváme, jsou lokalizovaná. To nám umožňuje je fúzovat, ať už klasickými metodami, jako je řídká fotogrammetrie nebo pomocí depth estimation neuronových sítí. V praxi používáme kombinaci obou metod.

Celý náš systém je postaven na tom, že jsou data uložena jako jakýsi strom, který tvoří graf scény. Náš síťový protokol se primárně stará o to, aby se průběžně tento graf synchronizoval mezi všemi zařízeními, která s ním pracují. Většina výpočtů nad touto strukturou musí probíhat v reálném čase, případně blízko reálnému času. Nevýhoda tohoto přístupu je, že se takový graf musí vejít do paměti a zároveň se z něj špatně dělá nějaký otisk v určitém okamžiku.

Proto velká data v listech takového stromu pak opravdu ukládáme do NoSQL databáze, která tvoří jakýsi zabezpečený šifrovaný data lake. Je to takový hybrid. Zároveň máme metody, jak zpracovávat datové proudy v reálném čase. Ty se do této struktury (grafu) jen linkují a stojí i mimo tento data lake.

Něco, čemu říkáme Brain, v takové struktuře uchovává všechna příchozí senzorická data a provádí nad nimi kontinuální výpočty. Ty pak zase do podobné struktury (tentokrát na server) ukládá. Taková struktura je výhodná v tom, že obsahuje uzly, ve kterých tato data mohou být rozdělena, asynchronně zpracovávána, a tudíž i zpracovávána ne v jednom stroji, ale případně v celém clusteru strojů.

Jak server, tak Brain tedy neustále nad touto strukturou něco kontinuálně počítají. To je trochu odlišné od klasické databázové koncepce, kdy přijde dotaz a pak se na něj odpovídá. V případě, že je nějaká session už uzavřená, prostě ji uložíme na disk. Tedy to, co se nejvíce podobná klasické databázi, jsou u nás statická data ve formě souborů na disku, něco jako otisky, ze kterých jsme případně schopní rekonstruovat a znovu oživit už zavřenou session.

Samozřejmě takové ty běžné věci, jako je seznam uživatelů, session, různé parametry na servery a podobně, jsou klasické SQL. Ale z hlediska fungování platformy jde více méně o minoritní záležitost. Je možné, že platforma bude v budoucnu přes API napojená na databázi zákazníka, protože to často souvisí se správou uživatelů a jejich práv.

Server v současné době běží na Windows, aby mohl být snadno nasazen lokálně do enterprise prostředí, případně do Azure cloudu. Brain běží na Linuxu. Hlavně proto, že v současné době neexistuje způsob, jak ve Windows rozumně spravovat GPU zdroje, které intenzivně využíváme. Brain totiž nedělá jen to, že pomocí různých metod rekonstruuje prostředí, ale na nižší úrovni spravuje GPU a paměť pro různé procesy, které jsou do rekonstrukce nebo úpravy videostreamu v reálném čase zapojeny. Přiřazují se joby a zdroje. V jistém smyslu je to takový trochu jednoúčelový operační systém. Do budoucna nás to nejspíše donutí migrovat server postavený na Windows také na Linux, abychom si zjednodušili údržbu a distribuci. Co se týče jazyků, je to mix C++, C# a v případě neuronových sítí také Pythonu.