Toto zadání je podepsané děkanem a vedoucím katedry, musíte si ho vyzvednout na studiijním oddělení Katedry počítačů na Karlově náměstí,

Na tomto místě bude oficiální zadání vaší práce • Toto zadání je podepsané děkanem a vedoucím katedry, • musíte si ho vyzvednout na studiijním oddělení Katedry počítačů na Karlově náměstí, • v jedné odevzdané práci bude originál tohoto zadání (originál zůstává po obhajobě na katedře), • ve druhé bude na stejném místě neověřená kopie tohoto dokumentu (tato se vám vrátí po obhajobě).

Official thesis specification should be here • Ask study office on our department to obtain it! • You have to post two copies – original and copy of your thesis. • Official thesis specification has to be placed in each of them (original and copy). • You receive back the thesis copy after succesful defension of your thesis. • The original of your thesis is hold on departmnet after the defension.

Pokyny • Projednejte osnovu práce se svým vedoucím! Každému vedoucímu a typu práce nemusí níže prezentovaná osnova vyhovovat. • Čtěte pokyny v komentářích zdrojého souboru (.tex). Je tam mnoho užitečných informací.

Instruction • Discuss the intended structure of your thesis with your supervisor! Not each supervisor is satisfied with structure suplied in this document! • Read insructions in comments in the source code of this document (.tex file). Many useful additional instructions are included.

ii

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Diplomová práce

Vizualizace v e-learningových systémech pro mobilní robotiku Bc. Štěpán Rezek

Vedoucí práce: RNDr. Miroslav Kulich, Ph.D.

Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika 21. května 2009

iv

v

Poděkování Chtěl bych poděkovat především vedoucímu mé diplomové práce Dr. Miroslavi Kulichovi, za vedení mé práce a nesčetné množství času, který mi věnoval. Dále bych chtěl poděkovat všem lidem z laboratoře mobilní robotiky, kteří byli ochotni mi kdykoliv podat pomocnou ruku a v neposlední řadě svým rodičům a mé přítelkyni za netuchuající morální podporu.

vi

vii

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 22. 5. 2009

.............................................................

viii

Abstract The following work summarizes findings about problems in visualization of mobile robots and describes possible solutions to some adherent problems. The work describes and compares present technologies used for visualization, it also contains an implementation of one solution designed to be used in SyRoTek system. The main contribution of this work is in the concept and realisation of algorithm capable of solving the Augment Reality occlusion problem to some extent, and in the implementation of comprehensive solution designed to show visualizations of mobile robots. This implementation comprises solutions starting from, but not limited to, reading pictures from camera and getting data from robot, to rendering the processed data on end-user’s workstation.

Abstrakt Tato práce shrnuje poznatky o problematice vizualizace v robotických systémech a popisuje řešení některých problémů s touto problematikou spjatých. Práce popisuje a srovnává současné techniky používané pro vizualizaci, její součásti je i implementace řešení navrženého pro použití v systému SyRoTek. Její hlavní přínos spočívá v návrhu a realizaci algoritmu pro řešení problému zákryvů v rozšířené realitě, a dále v implementaci uceleného systému pro vizualizaci v mobilní robotice. Ten pokrývá problematiku od snímání obrazu z kamery a získání údajů z robotu až po zobrazení zpracovaných dat na uživatelově počítači.

ix

x

Obsah 1 Úvod

1

2 Popis problému, specifikace cíle

3

3 Robotická prostředí 3.1 Player/Stage . . . . . . . . . . . . 3.1.1 Stage . . . . . . . . . . . . 3.1.2 Gazebo . . . . . . . . . . . 3.2 eXperimental Robotics Framework 3.3 Microsoft Robotics Studio . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

5 5 6 7 8 8

4 SyRoTek 11 4.1 Podsystém vizualizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5 Rozšířená realita 5.1 Implementace rozšířené reality . . . . . . . . . . . 5.1.1 Rozpoznávání podle umístění . . . . . . . 5.1.2 Rozpoznávání podle vzorů . . . . . . . . . 5.1.3 Rozpoznávání podle známého 3D modelu 5.2 Problém zákryvů . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

17 17 18 18 18 19

6 Realizace vizualizační komponenty 6.1 Přístup k serveru a načítání údajů o robotu . . . . . . . . . . . . . . . . 6.2 Model prostředí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Vykreslování senzorických dat a údajů o robotu . . . . . . . . . . . . . . 6.3.1 Řešení problému zákryvů . . . . . . . . . . . . . . . . . . . . . . 6.4 Zpracování videa a jeho přenos po síti . . . . . . . . . . . . . . . . . . . 6.4.1 Komponenta vstupu videa z pipeline GStreameru (videosink ) . . 6.4.2 Komponenta výstupu videa z pipeline GStreameru (videosource) 6.5 Přenos pohledu na arénu pomocí protokolu http . . . . . . . . . . . . . . 6.6 Kalibrace kamery a oprava obrazu . . . . . . . . . . . . . . . . . . . . . 6.7 Obraz v obraze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

21 21 23 24 27 29 31 32 33 33 36

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

7 Testování a srovnání s existujícími řešeními 39 7.1 ArDev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 7.2 Stage verze 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 7.3 Gazebo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 xi

xii

OBSAH

8 Závěr

45

Literatura

47

A Seznam použitých zkratek

49

B Instalační a uživatelská příručka

51

C XML Schema souboru struktury arény

53

D Obsah přiloženého DVD

55

Seznam obrázků 1.1

Robotický pes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

3.1 3.2 3.3

Simulátor Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simulátor Gazebo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . eXperimental Robotics Framework . . . . . . . . . . . . . . . . . . . . . .

7 7 9

4.1 4.2 4.3 4.4

Schematicky plán arény . . . Robot projektu SyRoTek . . . Podsystém vizualizace . . . . Vstupy a výstupy vizualizační

5.1 5.2 5.3

Autonavigace s rozšířenou realitou . . . . . . . . . . . . . . . . . . . . . . 17 Příklad vzoru pro hledání objektu v rozšířené realitě . . . . . . . . . . . . 19 Problém zobrazení zákryvů . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13

Modely prostředí a robotu . . . . . . . . . . . . . . . K pojmům roll, pitch a yaw . . . . . . . . . . . . . . Charakteristika sonaru . . . . . . . . . . . . . . . . . Zjednodušená reprezentace dat ze sonaru . . . . . . . Umístění sonaru vzhledem ke světovým souřadnicím Informace získané z laserového dálkoměru . . . . . . Ilustrativní obrázek k řešení problému zákryvů . . . Pipeline GStreameru. . . . . . . . . . . . . . . . . . . Vstupní a výstupní pipeline . . . . . . . . . . . . . . Optické vady . . . . . . . . . . . . . . . . . . . . . . Projekce 3D prostoru na 2D plochu . . . . . . . . . . Korekce zkreslení . . . . . . . . . . . . . . . . . . . . Obraz v obraze . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

24 25 25 26 26 27 29 30 31 34 35 36 36

7.1 7.2 7.3 7.4

Porovnání vizualizací dat ze sonaru . . . . . . . . . . . . . . . Pohled na robotickou arénu pomocí vizualizační komponenty ArDev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pohled na model robotické arény v simulátoru Stage verze 3 .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

40 41 43 44

. . . . . . . . . . . . . . . . . . . . . komponenty

xiii

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

11 12 14 15

xiv

SEZNAM OBRÁZKŮ

Seznam tabulek 7.1 7.2 7.3

Počítače použité pro testování . . . . . . . . . . . . . . . . . . . . . . . . . 42 Porovnání výkonnosti na různých počítačích . . . . . . . . . . . . . . . . . 42 Porovnání výkonnosti v závislosti na počtu zobrazených robotů . . . . . . 42

xv

xvi

SEZNAM TABULEK

Kapitola 1

Úvod Vizualizace v systémech mobilních robotiky zahrnuje poměrně velké množství problémů, s nimiž se robotika potýká a k nimž existuje nemalé množství možných řešení a přístupů. Mezi takové problémy se řadí i vizualizace senzorických dat, jíž se věnuje velká část této práce. Abychom si mohli představit, co je vlastně myšleno problematikou vizualizace v robotice, můžeme si za příklad zvolit např. robotického psa, načrtnutého na obr. 1.1.

Obrázek 1.1: Robotický pes

Otázek, na něž hledáme odpověď, najdeme mnoho. Kupříkladu samotné zobrazení robota – pokud umístíme reálného robota do reálného prostředí, jak nejlépe bychom ho měli snímat? Budeme předpokládat, že se na robota díváme pomocí nějaké kamery, či máme zobrazovat svět z pohledu očí robota (psa)? Lze předpokládat, že robot má také nějaké senzory, např. infračervené nebo laserové, které mu umožňují budovat si přibližný model okolního světa. Jak máme zobrazit data získaná z těchto senzorů? Jak spojíme jeho „představu“ okolního světa s tím, co vidí člověk na kameře? Robot také jistě někam směřuje, a jistě odněkud přišel – jak zobrazíme směr jeho chůze, a jak zobrazíme to, co již ušel? Jak zobrazíme jeho rychlost, stav jeho baterií, teplotu? Co když budeme chtít více pohledů z různých kamer ve stejný čas, jak je zobrazíme? Jak smícháme obraz z kamery s tím, co dalšího chceme o stavu robota znát? A jak tyto informace dostaneme k uživateli, který chce robota ovládat? Na tyto otázky se pokouší tato práce nalézt odpovědi. 1

2

KAPITOLA 1. ÚVOD

Kapitola 2

Popis problému, specifikace cíle Tato práce si klade za cíl seznámit čtenáře s problematikou vizualizace v robotických systémech a navrhnout vizualizační nástroj pro prostředí SyRoTek, což je systém pro vzdálenou výuku robotiky. Tento nástroj by se měl zabývat následujícími oblastmi: 1. Vyčítání obrazu z kamery, popř. jiných zdrojů obrazu, 2. vyčítání a zpracování dat z robotu, a to jak fyzického, tak jeho simulace, 3. spojení těchto informací do podoby vhodné pro zobrazení koncovému uživateli, přičemž tato část by měla zahrnovat • vhodný způsob zobrazení senzorických dat, dat o ujeté dráze robotu a strukturu okolního prostředí (překážky a ostatní roboty), • řešení zobrazení zákryvů (occlusions) vzniklých spojením dat reálného světa s daty virtuálními, • zobrazení více pohledů na jednu plochu (např. z více kamer), • korekce chyb obrazu z kamery (především soudkovitost), • transformace souřadnic z obrazu získaného kamerou; a 4. transport výsledného obrazu koncovému uživateli, zobrazení na webových stránkách a případně jeho uložení na disk počítače pro opětovné použití. Problematika vizualizace v robotických systémech je v této práci rozdělena do několika částí. První z nich, které se věnuje kapitola 3, se týká volby robotického prostředí (frameworku). Účelem těchto prostředí je zapouzdřit ovládání a vyčítání informací z robotu, a vizualizace robotických simulací. Mezi nejpoužívanější z nich můžeme zařadit Player/Stage [4], jeho nadstavbu eXperimental robotics framework [17] a Microsoft Robotics Studio [13]. Následující kapitola podává úvod do architektury projektu SyRoTek [10]. Cílem tohoto projektu, jehož součástí bude i vizualizační nástroj navržený v této práci,je vývoj nových algoritmů, metod a postupů e-learningu v oblasti mobilní robotiky a umělé inteligence a jejich integrace do unikátního multi-robotického pracoviště. 3

4

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE

Kapitola 5 podává úvod do problematiky rozšířené reality (Augmented Reality), podává stručný popis technik, které se v ní používají a ukazuje některá z jejich možných i reálných použití. Poslední kapitola využívá poznatků uvedených v předchozích částech a popisuje jednotlivé problémy a jejich řešení ve vztahu k vizualizaci v robotickém systému SyRoTek.

Kapitola 3

Robotická prostředí Cílem robotických prostředí, neboli frameworků, je usnadnit výzkum v oblasti robotiky a senzorických systémů. Typicky se jedná o jakousi mezivrstvu mezi programem ovládajícím robot a hardware robotu. To si můžeme zjednodušeně představit na příkladu operačních systémů pro osobní počítače. Operační systém nabízí funkce, které jsou na hardware nezávislé, jako např. čtení/zápis do souboru, zobrazení grafiky na monitoru počítače, tisk dokumentů ad. K operačním systémům pak existuje nepřeberné množství ovladačů napsaných přímo pro určitý hardware. Tyto ovladače pak implementují funkce pro přístup k sektoru na disku, vykreslení primitivní grafické struktury, poslání shluku bajtů na tiskárnu atd. Výsledkem pak je skutečnost, že pokud píšeme aplikaci určenou pro daný operační systém, nemusíme se vůbec starat o to, na jakém hardwaru naše aplikace poběží, ale postačí nám pouze volat funkce operačního systému, který tato volání pomocí ovladačů převede na formát používaný přímo daným hardware. Na stejném principu pak funguje i většina robotických prostředí - poskytují metody pro komunikaci s roboty, přičemž tyto jsou nezávislé na použitém hardwaru, a jejich volání je převedeno pomocí ovladačů do takového formátu, s nimž je schopen pracovat daný kus opravdu použitého hardware. Mimoto tyto frameworky často poskytují simulátory, které napodobují činnost robotů a okolního prostředí. Pro vývoj a prvotní testování robotických algoritmů tedy nepotřebujeme fyzický robot, ale postačí nám dobře nastavený simulátor, který bude robot napodobovat. Robotické frameworky často poskytují i vizualizační nástroje, které umožňují pohled na (obvykle simulovanou) robotickou scénu.

3.1

Player/Stage

Player je pravděpodobně nejpoužívanější prostředí pro kontrolu robotů a senzorů na světě. Jeho součástí jsou i dva simulační moduly, a to Stage (pro dvourozměrné vizualizace) a Gazebo (pro třírozměrné simulace, implementuje i některé fyzikální zákony). Mezi jeho přednosti můžeme zařadit: • podporu běžně používaných robotických platforem a senzorů již v základní instalaci, 5

6

KAPITOLA 3. ROBOTICKÁ PROSTŘEDÍ • velmi přímočarý vývoj a testování robotických algoritmů, • dva simulátory, • systém ovladačů jako pluginů, • záznamy o činnostech a jejich zpětně přehrávání a • licenci GPL.

Player používá následující tři koncepty pro zajištění přenositelnosti mezi co největším množstvím platforem: interface (rozhraní) Obecný mechanismus předávání zpráv a hodnot určitému kusu hardwaru - specifikuje, že např. všechny objekty typu sonar mají hodnotu, která určuje, kam dohlédne paprsek sonaru interface (ovladač) Software, který komunikuje s určitým typem hardwaru a transformuje jeho vstupy/výstupy do takového formátu, který odpovídá jednomu nebo více rozhraním. device (zařízení) Ovladač přiřazený rozhraní. Specifikuje např., že ovladač sonaru SM900 implementuje rozhraní sonar. Player využívá architektury Klient/Server a jako protokol pro přenos dat používá TCP. V názvosloví Player u server značí počítač, který ovládá robot a klient je počítač, který vzdáleně komunikuje se serverem. Player samotný je napsán v jazyce C, a existují k němu klientské knihovny pro jazyk C, C++ a Python.

3.1.1

Stage

Stage simuluje populace mobilních robotů, jejich senzory a objekty v 2D prostředí, definovaném pomocí bitmapy. Stage byl navržen tak, aby umožňoval práci s multiagentními autonomními systémy. Proto poskytuje jednoduché a výpočetně nenáročné modely mnoha zařízení. To může mít za následek to, že tyto modely nebudou ve všech ohledech věrně odpovídat skutečným zařízením, na druhou stranu je však práce s nimi velmi jednoduchá. Stage je téměř výhradně používán jako zásuvný modul pro Player a obohacuje Player o množinu virtuálních zařízení, které lze použít pro simulace. Uživatel píše robotické kontroléry a algoritmy pro práci se senzory jako tzv. klienty pro server Player. Tito klienti by v ideálním případě neměli být schopni rozeznat rozdíl mezi tím, zda běží na virtuálním zařízení, či na zařízení skutečném. Díky své architektuře také Stage umožňuje psát algoritmy pro zařízení, která ve skutečnosti nemáme (ale umíme je nasimulovat). Stage mj. poskytuje simulaci sonaru, laserových dálkoměrů, detekci blobů (různě barevných objektů), odometru a diferenciálně řízené základny robotu. Příklad toho, jaký výstup můžeme dostat při použití simulátoru Stage zobrazuje obrázek č. 3.1.

3.1. PLAYER/STAGE

7

Obrázek 3.1: Simulátor Stage (obrázek převzat z [4])

3.1.2

Gazebo

Gazebo (viz obr. 3.2), stejně jako Stage, je simulátor populace mobilních robotů a jejich senzorů, ale v třírozměrném prostředí. Poskytuje realistickou odezvu senzorů a simuluje interakci mezi objekty založenou na fyzikálních zákonech mechaniky. I tento simulátor poskytuje množství virtuálních zařízení; můžeme jej tedy používat stejným způsobem jako Stage. Ovšem s tím rozdílem, že mapy prostředí jsou popsány vektorově, nikoli bitmapou. Díky implementaci některých fyzikálních zákonů mohou roboty před sebou tlačit nejrůznější věci, mohou je zvedat a pouštět na zem a interagovat s okolním světem obecně. Stejně jako Player a Stage je i Gazebo licencováno pod GPL.

Obrázek 3.2: Simulátor Gazebo (obrázek převzat z [4])

Přirozeně se naskýtá otázka, jestli má vůbec smysl používat pro simulace Stage, když Gazebo dokáže totéž a ještě něco navíc. Odpověď není jednoduchá, protože ano, dokáže simulovat totéž, ale má podstatně vyšší výpočetní nároky, které se zvyšují s počtem simulovaných robotů a složitostí okolního prostředí. V praxi se tedy Gazebo používá pro simulace populací robotů v řádu jednotek kusů, ovšem ve složitějším modelu prostředí. V ostatních případech je obvykle nutné použít Stage.

8

KAPITOLA 3. ROBOTICKÁ PROSTŘEDÍ

3.2

eXperimental Robotics Framework

Experimental Robotics Framework (zkráceně ERF ) je framework určený pro vývoj komponentových aplikací zabývajících se oblastí Human-Robot Interaction, HRI1 (tzn. interakce mezi člověkem a robotem). Cílem ERF je poskytnout vývojové prostředí, které umožní vývoj aplikací založených na HRI a které může být adaptováno na rozličné úkoly. A to do takové míry, aby se mohlo stát univerzální platformou pro komunikaci mezi člověkem a fyzikálním modelem světa, nejen robotickým. Některé z potenciálních aplikací, které mohou těžit z ERF, jsou aplikace zabývající se strojovým vnímaním, vývojem a laděním různých algoritmů, agentním chováním, vzdáleným ovládáním robotů atd. ERF poskytuje následující: • Perspektivní a ortogonální pohled kamery, • znovupoužitelnost kódu (komponent), • podporu pro množství video/web-kamer • načítání objektů z 3D Studia MAX, • konfiguraci pomocí XML, • vykreslování do více oken najednou, • přímý přístup k objektům OpenGL, • použití GLSL Shaderů a • implementaci systému komunikace mezi komponentami, de/serializace objektů a líné (lazy) načítání komponent. Tvůrci ERF si byli vědomi faktu, že Player/Stage je nejpoužívanější softwarová platforma pro mobilní robotiku, a i z tohoto důvodu ERF využívá právě prostředí Player pro přístup k senzorům a aktuátorům mobilních robotů. Jelikož jako komunikační vrstvu použivá ERF prostředky prostředí Player, může ERF zároveň transparentně pracovat jednak se simulacemi robotů v simulátorech Stage či Gazebo, ale i se skutečnými roboty.

3.3

Microsoft Robotics Studio

R Robotics Developer Studio 2008 (RDS) je prostředí běžící na platformě WinMicrosoft dows určené širokému spektru uživatelů pro vytváření robotických aplikací pro rozmanité robotické platformy. RDS používá svoje vlastní běhové prostředí nazvané Concurrency and Coordination Runtime (CCR), které pro komunikaci využívá softwarovou architekturu REST (Representational state transfer) a komponentovou architekturu. Dále poskytuje vizuální návrhář aplikací a nástroj pro simulaci. Podporované jazyky pro vývoj aplikací jsou C#, C++ a Visual Basic. 1 Human-Robot Interaction je poměrně mladý obor kybernetiky, který se zabývá vzájemnou interakcí mezi člověkem a robotem. Existuje dokonce již konference věnovaná přímo tomuto obor, viz např. [1]

3.3. MICROSOFT ROBOTICS STUDIO

9

Obrázek 3.3: eXperimental Robotics Framework (obrázek převzat z [17])

Typická aplikace pro ovládání robotu se skládá z několika vzájemně komunikujících komponent. No rozdíl od systému Player se RDS nesnaží o co nejvyšší úroveň abstrakce, ale každý výrobce robotické platformy musí vytvořit svou vlastní sadu komponent, které se pak dají použít v RDS. Jedním z robotů, které je možné ovládat z Robotics Studia je i virtuální robot, který žije ve 3D světě (s věrnou simulací fyzikálních zákonů). Hlavní nevýhodou tohoto prostředí je především obtížná rozšiřitelnost vizualizačního nástroje (program je čistě komerční a zdrojové kódy nejsou dodávány) a vazba na operační systém Windows. Stručný úvod do tohoto prostředí je popsán v [15].

10

KAPITOLA 3. ROBOTICKÁ PROSTŘEDÍ

Kapitola 4

SyRoTek Projekt SyRoTek, jehož součástí je i vizualizační komponenta popisovaná dále v této práci, je zaměřen na vytvoření systému pro robotickou tele-výuku. Projekt se skládá z několika součástí, přičemž pro pochopení jeho smyslu je vhodné tyto součásti popsat. První součástí je samotná robotická aréna, což je deska přibližně 3,5x4m s dřevěnými překážkami. Schematický plán arény je na obr. 4.1 (pohled z lokalizační kamery na již postavenou arénu je na obrázku 6.12). Tyto překážky mohou být buď statické, či pohyblivé; pod pohyblivými překážkami je elektrický motorek, který je dokáže vysunout.

Dokovací zóna Operační prostor

Mantinel

Překážky

Pohyblivé překážky

Obrázek 4.1: Schematicky plán arény V aréně se může pohybovat několik robotů. Tyto roboty jsou zařízení zkonstruovaná speciálně pro použití v projektu SyRoTek, jeden z nich je zobrazen na obrázku 4.2. Roboty jsou vybaveny následujícími senzory: • Snímače otáčení kol (IRC - incremental rotation counter), • sondy snímající aktuální proud tekoucí do motoru, 11

12

KAPITOLA 4. SYROTEK

Obrázek 4.2: Robot projektu SyRoTek • měření vnitřních napětí robotu (především napětí baterie), • senzory teploty důležitých částí robotu (baterie, výkonová elektronika), • akcelerometry, • infračervené dálkoměrné senzory, • sonarové dálkoměry a • senzory snímající barvu (resp. světlost či odrazivost) podlahy. Tuto množinu senzorů je možné v průběhu vývoje rozšířit o • gyroskop a • kompas. Volitelná konfigurace (senzory které nebudou instalovány v základní výbavě) dále zahrnuje • laserový dálkoměr a • kameru s integrovaným procesorem pro zpracování obrazu. Pro komunikaci mezi robotem a řídicím počítačem slouží komunikační modul. Ten používá jednak radiový přenos pro data, kde je nutné minimalizovat zpoždění přenosu (typicky řídicí signály) a za druhé wi-fi pro přenos objemnějších dat, kde zpoždění není kritické (typicky obraz z kamery). Dění v aréně bude možné sledovat z kamer snímajících hřiště. Jedna z těchto kamer, dále nazývána jako lokalizační, slouží k zjištění pozice jednotlivých robotů (robot má na své horní straně nakreslen symbol, který dokáže lokalizační software rozpoznat a na jeho základě vypočítat pozici robotu). Řídící počítač má za úkol řídit roboty, a to jednak podle pokynů uživatele, nebo v případě potřeby autonomně. Řízení podle pokynů uživatele můžeme dále rozdělit na řízení přímé, tzn. robot je řízen povely jako „Zatoč doleva“, „Rozjeď se“, „Zastav“ pomocí speciálního ovládacího softwaru, a nepřímé, kdy robot je řízen uživatelem definovaným algoritmem.

4.1. PODSYSTÉM VIZUALIZACE

13

Ke všem zařízením na robotech existují ovladače pro prostředí Player, robot tedy může být řízen i pomocí algoritmů napsaných obecně pro toto prostředí. K dispozici je také simulační prostředí, na němž běží simulátor Stage nakonfigurovaný tak, aby co nejvěrněji simuloval skutečné prostředí SyRoTek, včetně okolních robotů a použitých senzorů. Algoritmy napsané pro robot tedy může uživatel nejprve otestovat v simulaci, a posléze bez jakékoli změny kódu použít na fyzický robot. Plánované využití projektu je takové, že uživatel se ze svého počítače připojí k přístupovém serveru projektu SyRoTek, nahraje svůj ovládací algoritmus, ten se posléze spustí a on bude moci sledovat průběh algoritmu na svém monitoru pomocí videopřenosu. V obraze, který uživatel uvidí, budou jednak snímky z jedné (či více) kamer a také graficky znázorněná data ze senzorů robotu. Podrobný popis skládání obrazu uvádí kapitola 5.

4.1

Podsystém vizualizace

Pro účely této práce má největší význam část SyRoTku nazvaná podsystém vizualizace. Ta má za úkol získávání obrazu z kamer, jejich ukládání na disk, obohacení obrazu z kamery o další data (senzory, aktuální rychlost. . . ), skládání obrazu z více kamer, a streamování výsledného obrazu k uživateli a na webové stránky. Schematicky je tato část znázorněna na obr. 4.3 Vstupem podsystému je obraz z kamer. Kamery budou připojeny pomocí rozhraní Video4Linux(2), nebo pomocí IEEE-1394. V další části, nazvané předzpracování, značkování, ukládání, se provádí korekce obrazu, především soudkovitosti (více viz kapitola 6.6), a případné ukládání obrazu na disk pro další použití. Data mohou být dále zpracována pro okamžitý přenos k uživateli, nebo mohou být uložena, a zpracována až si je uživatel vyžádá (on-demand). Jak již bylo napsáno výše, do obrazových dat mohou být přidány další informace, jako jsou senzorická data ad. Toto zpracování má na starost komponenta na obrázku označená zeleně, která se může použít ve čtyřech situacích: • První situace je ta, kdy jsou data okamžitě předávána uživateli. V tomto případě se sejme snímek z kamery, k tomuto snímku se dodají další informace a tento jeden snímek je poslán na klientský počítač, kde je posléze zobrazen. Zde je třeba dodat, že snímek nemusí nutně pocházet pouze z jedné kamery, ale může být složen z pohledů z více kamer. • V druhém případě je nejprve celý videozáznam sezení s robotem zaznamenán na disk včetně informací o stavu senzorů, a na klientský počítač je poslán celý videozáznam obohacený o senzorická data. V tomto případě je nutné zajistit synchronizaci času stavu senzorů s časem snímku, aby bylo možné později zpětně zrekonstruovat stav arény. Toto by šlo řešit například očíslováním jednotlivých snímků, přičemž každému snímku by byl přiřazen právě jeden záznam o stavu souborů (zřejmě v odděleném souboru). Optimalizací tohoto přístupu by mohlo být zaznamenání jen změn stavu senzorů. Nezaznamenával by se tedy stav pro každý snímek, ale jen ty stavy, kde nastala nějaká změna oproti stavu předcházejícímu. • Ve třetím případě jsou poslána obrazová data a senzorická data na klientský počítač odděleně, a jejich skládání se provádí specializovanou aplikací až na klientské

KAPITOLA 4. SYROTEK 14

kamerový systém

předzpracování, značkování, ukládání

enkódování

systémové parametry

kompozice obrazu

on−line zpracování virtualní kamery

systémový čas

enkódování

uživatelské parametry

data ze senzorů

kompozice obrazu

off−line zpracování virtualní kamery

systémové parametry

prezentace proudy

soubory

uživatelské parametry

kompozice obrazu

zobrazení

specializovaná vizualizační aplikace

video soubory konvenční přehrávání proudů video přehřávač download souborů

přehrávání proudů download souborů

video a datové soubory

virtualní kamery

Obrázek 4.3: Podsystém vizualizace (obrázek převzat z [9])

4.1. PODSYSTÉM VIZUALIZACE

15

straně. Při použití tohoto řešení se může aplikace buď dotazovat oddělenými spojeními zvlášť na obrazové a senzorické údaje, či může být definováno na serverové straně takové rozhraní, které bude poskytovat jak obrazová, tak senzorická data. V tomto případě ovšem nelze použít přímo rozhraní frameworku Player, protože neposkytuje všechny požadované funkce (jako je např. přístup k obrazovým datům). Použití neupraveného rozhraní Player ovšem pravděpodobně stejně nebude možné, a to kvůli tomu, že rozhraní frameworku Player neřeší problematiku autorizace uživatelů, která je ale jedním z požadavků kladených na projekt SyRoTek. • V posledním případě jsou videozáznam sezení a senzorická data uloženy zvlášť, kdy na vyžádání je celý záznam poslán na klientský počítač a složení dat je provedeno zmíněnou specializovanou aplikací u klienta. I zde je nutné řešit problematiku synchronizace dvojice snímek-senzorické údaje. Při bližším pohledu na tyto čtyři možné způsoby použití vyplývá několik poznatků. První z nich je, že při aplikaci prvního či druhého přístupu není nutné mít na klientském počítači žádnou specializovanou aplikaci, ale postačí některý z běžných přehrávačů videa (např. VLC media player, http://www.videolan.org/vlc/). Na druhé straně ovšem toto řešení klade zvýšené nároky na serverovou část, kde musí dojít k obohacení videoproudu o další údaje. Při aplikaci třetího či čtvrtého přístupu jsou naopak nároky na serverovou část podstatně nižší, nicméně vzdálený uživatel si musí nainstalovat specializovanou aplikaci, schopnou smíchat obraz a data ze senzorů a zobrazit výsledek. S problémem smíchání obrazu se váže i otázka zobrazení „web kamery“, tedy obrázku na webových stránkách, obnovovaného například jednou za vteřinu. S přihlédnutím k těmto poznatkům se jeví jako rozumný kompromis vytvoření komponenty, jejíž funkcí bude smíchání obrazu s daty. Tuto komponentu pak bude možné použít jak na serverové straně, tak i jako součást klientské aplikace. Jednotlivé vstupy a výstupy této komponenty jsou schematicky znázorněny na obrázku 4.4.

Vizualizační komponenta

Obrázek 4.4: Vstupy a výstupy vizualizační komponenty Komponenta tedy musí být schopná • načíst videozáznam z disku, • sejmout data z kamery (připojené pomocí Video4Linux(2) či IEEE-1394),

16

KAPITOLA 4. SYROTEK • přijmout a zpracovat data o pozici robotu a stavu jeho senzorů, • sloučit videozáznam z jednoho či více zdrojů a data o pozici robotu a stavu jeho senzorů, • uložit výsledný záznam na disk, • zobrazit výsledek na monitor, • poslat výsledek jako videoproud po síti a • umožnit vzdálený přístup k výsledku pomocí internetového rozhraní.

Kapitola 5

Rozšířená realita V souvislosti s problematikou sloučení obrazových a senzorických dat je nutné podat základní úvod k problematice rozšířené reality (v anglickém jazyce augmented reality). Ve své podstatě se jedná o sloučení obrazu reálného světa s obrazem vytvořeným uměle, a to v reálném čase. Ukázku možného použití rozšířené reality podává obr. 5.1.

Obrázek 5.1: Autonavigace s rozšířenou realitou (obrázek převzat z [8]) Na obrázku vidíme ulici (obraz reálného světa) spolu s navigačními ukazateli pro zatočení doprava (obraz virtuálního světa). Přesnější definici podává poměrně hojně citovaná práce [2] Ronalda Azumy, zabývající se rozšířenou realitou: Systém rozšířené reality je takový, který 1. Kombinuje reálný obraz s umělým, 2. je interaktivní v reálném čase a 3. pracuje v třídimenzionálním prostoru.

5.1

Implementace rozšířené reality

Jak již bylo napsáno výše, rozšířená realita se zabývá skládáním obrazu reálného a virtuálního světa. S tím je spojeno několik, na první pohled nepříliš zřejmých, problémů. 17

18

KAPITOLA 5. ROZŠÍŘENÁ REALITA

Jeden z těchto problémů je požadavek interaktivity. Předpokládejme např., že se pokusíme realizovat prohlídky v muzeu s rozšířenou realitou. Každý návštěvník by dostal zařízení s kamerkou, které se vejde do ruky, a na jehož displeji se zobrazuje obraz z kamery. Pokud by návštěvník namířil kameru na některý známý objekt, dejme tomu vázu, na displeji by se k váze dokreslily další informace. Jak je váza stará, kde byla nalezena a případně krátká videosekvence, jak se tato váza vyráběla. Problém zde spočívá v tom, jak rozpoznat, že se uživatel dívá (přesněji řečeno, ukazuje kamerkou na) známý objekt, na něž má zařízení reagovat. Dnes využívaná řešení můžeme rozdělit do tří skupin: rozpoznávání podle umístění a natočení pozorovatele, rozpoznávání podle vzorů a rozpoznávání podle známého 3D modelu.

5.1.1

Rozpoznávání podle umístění

Jestliže známe umístění zařízení, tedy jeho polohu a směr pohledu, a známe zároveň i obvykle neměnnou polohu sledovaného předmětu, můžeme snadno určit, zda zařízení „vidí“ na objekt a na příslušné místo v obraze na displeji vykreslit požadované informace. Tento přístup využívá například aplikace WikiTude (http://www.mobilizy.com/ wikitude.php), která zobrazuje informace o památkách, na něž se uživatel dívá pomocí mobilního zařízení T-Mobile HTC G1 (s operačním systémem Android). To disponuje poměrně přesným GPS modulem a kompasem. Nevýhodou tohoto přístupu je požadavek vysoké přesnosti lokalizačního zařízení, obvykle GPS a kompasu, kterého není možné vždy dosáhnout, a také nutnost znalosti pozice sledovaného objektu. To není bohužel vždy možné, protože někdy přesná pozice sledovaného objektu není známa, či se dokonce pohybuje. Tento přístup samotný je také nedostačující, pokud je požadavkem řešení problému zákryvů (viz další kapitola).

5.1.2

Rozpoznávání podle vzorů

Strojové rozpoznávání jednoduchých vzorů v obrazu je v dnešní již poměrně dobře vyřešeno, proto se často využívá i v rozšířené realitě. Princip spočívá v tom, že hledaný objekt na sobě nese určitý vzor (případně je objekt sám hledaným vzorem). V okamžiku, kdy je tento vzor nalezen, je tím zároveň nalezen i hledaný objekt a na pozici vzoru můžeme vykreslit požadováné údaje. Ukázka jednoho takového vzoru je na obr. 5.2. Tento přístup má výhodu v tom, že nepotřebujeme vůbec znát pozici zařízení a objektu, ale stačí pouze najít dobře rozpoznatelný vzor. I to však může být problém, protože vzor se může stát pod určitým úhlem nerozpoznatelný. Také je nutné zařízení naučit na daný vzor, což v případě vázy není nereálné, ale v případě třeba památek již může být složitější. V některých situacích je tento přístup také téměř nepoužitelný, a to kupříkladu pro řešení problému automobilové navigace. Toto řešení se tedy používá spíše pro jednodušší aplikace. Jako ukázka může posloužit reklamní kampaň BMW na kabriolet MINI, kde si uživatel vytiskne stránku se vzorem a po spuštění patřičného programu a namíření této stránky na kameru se mu na místě vzoru vykreslí autíčko. Více viz http://www.mini.de/de/de/webcam/index.jsp.

5.1.3

Rozpoznávání podle známého 3D modelu

Tento přístup je zřejmě nejkomplikovanější, co se realizace týče, ovšem do značné míry řeší problém zákryvů. Princip spočívá v tom, že si nejdříve vytvoříme počítačový 3D

5.2. PROBLÉM ZÁKRYVŮ

19

Obrázek 5.2: Příklad vzoru pro hledání objektu v rozšířené realitě model prostředí, a potom hledáme korespondence mezi tímto modelem a viditelným prostředím. Tyto korespondence lze hledat podle umístění kamery, hledaného objektu nebo obojího (pak se jedná o rozšíření první možnosti řešení), nebo o čisté strojové rozpoznávání (což je zobecnění druhé možnosti). Kombinace 3D modelu a známé pozice objektů je využita v implementaci vizualizační komponenty v této práci, práce věnující se čistě strojovému rozpoznávání je např. [14]. Nevýhoda této metody je v nutnosti existence 3D modelu, což není vždy možné. Také nároky na rozpoznávání objektů jsou značné. V praktickém využití, za což můžeme považovat navigační systém do auta, se předpokládá využití kombinace všech zmiňovaných metod. Zde je model prostředí do značné míry znám, protože navigační software obsahuje geografickou 2D mapu prostředí. Rozpoznávání podle pozice je zde využito ve vztahu k pozici auta, která je známá ze systému GPS. Nakonec rozpoznávání podle vzorů se uplatňuje např. u dopravních značek, kdy nás systém může upozornit na lokální omezení maximální rychlosti, či u detekce auta jedoucího před námi – systém nás v tomto případě může upozornit na příliš krátký rozestup.

5.2

Problém zákryvů

U rozšířené reality se v některých případech setkáváme s problémem zobrazení zákryvů (v anglické literatuře occlusions). Podstatu tohoto problému je vhodné znázornit na příkladu. Na prvním obrázku, 5.3(a), můžeme vidět fotografii robotické arény s robotem a vykreslením bodů viditelných laserovým senzorem. Na tomto obrázku nebylo přihlédnuto k problematice zákryvů, proto je zde patrné nepřirozené zobrazení dat z laseru. To je vyřešeno na obrázku 5.3(b), kde byly nejdříve pomocí 3D modelu prostředí vypočítány jednotlivé zákryvy a až posléze byla vykreslena vizualizace senzoru tak, jak ji člověk očekává při pohledu z daného úhlu. Zákryvy se nejčastěji řeší právě využitím 3D modelu prostředí, kde jsou nejdříve vypočítány viditelné segmenty vykreslovaného objektu a pak jsou pouze tyto segmenty vykresleny do reálné scény. Obraz před vykreslením je ještě zapotřebí oprostit od optických vad, a to buď využitím sofistikovaných objektivů, nebo softwarovými úpravami (více v části 6.6). Existují i další metody řešení zákryvů, kupříkladu ty popisované v pracích [3, 6], nicméně žádná z těchto metod ještě není dostatečně stabilní pro reálné využití.

20

KAPITOLA 5. ROZŠÍŘENÁ REALITA

(a) Snímek bez řešení zákryvů

(b) Snímek s řešením zákryvů

Obrázek 5.3: Problém zobrazení zákryvů

Kapitola 6

Realizace vizualizační komponenty Tato kapitola se věnuje popisu realizace vizualizační komponenty. Při volbě programovacího jazyka bylo zvažováno buď použití jazyka C++, či Java. S ohledem na použitý robotický framework Player (který je použit i ve zbytku projektu SyRoTek) volba padla na jazyk C++. Cílový operační systém pro běh softwarové části projektu SyRoTek je Linux/FreeBSD, proto byl vývoj komponenty realizován na platformě Linux. Komponenta je ovšem navržena tak, že případný přenos na jiný operační systém (kupříkladu Windows či MacOS) by měla být poměrně triviální záležitostí. To z toho důvodu, že všechny použité knihovny (libplayerc++, Irrlicht, gstreamer a OpenCV) lze používat na Linuxu 2.6, Windows i MacOS X. Cílem této práce není navrhnout samostatnou knihovnu pro práci s videoformáty a přenos videa po síti, proto jsou všechny videovstupy a výstupy (vyjma výstupu typu „webkamera“) realizovány za pomocí knihovny GStreamer (http://gstreamer.freedesktop. org/). Více se této knihovně a problematice přenosu videa věnuje podkapitola 6.4. Pro vykreslování bylo nutné použít API pro vykreslování grafiky, a jelikož cílový systém je Linux, bylo zvoleno OpenGL. Nebylo však použito OpenGL samotné, ale grafický engine Irrlicht, http://irrlicht.sf.net/. Ten používá svoje vlastní API, které dokáže převést na volání funkcí nejen OpenGL, ale i DirectX. Grafických engine existuje několik, zvažovány byly ještě OGRE (http://www.ogre3d.org/) a CrystalSpace 3D (http://www.crystalspace3d.org/), ovšem Irrlicht z těchto tří nejlépe splňoval požadavky jednak na jednoduchost psaní aplikací, ale i na dostupnost všech uvažovaných funkcí a hardwarovou nenáročnost. Nutnost použití 3D engine vyplývá z poznatků, které přináší podkapitola 6.3.

6.1

Přístup k serveru a načítání údajů o robotu

Aby komponenta vůbec měla smysl, musí být schopná načíst data o pozici robotu, případně robotů, a stavu jeho/jejich senzorů. Komponenta pro vizualizaci využívá rozhraní robotického frameworku Player, které je realizováno jako spojení protokolem TCP na vyhrazeném portu. Komunikační protokol je definován serverem Player, jehož součástí jsou mj. klientské knihovny pro C++. Přístup k funkcionalitám frameworku Player je realizován konceptem unifikovaných rozhraní k jednotlivým senzorům, popř. jiným zařízením či datovým strukturám. Server Player je samostatná aplikace, nakonfigurovaná 21

22

KAPITOLA 6. REALIZACE VIZUALIZAČNÍ KOMPONENTY

tak, aby poskytovala pouze konkrétní rozhraní. Server muže například poskytovat následující rozhraní: position2d rozhraní pro vyčítání pozice robotu a změn hodnot jeho aktuátorů1 , ranger obecné rozhraní pro dálkoměrné senzory, sonar rozhraní pro vyčítání hodnot ze sonaru, ir rozhraní pro vyčítání hodnot z infračerveného dálkoměru. Server Player po spuštění naslouchá na definovaném TCP portu a po připojení klientské aplikace mění hodnoty příslušných aktuátorů a vyčítá hodnoty senzorů. Klientská aplikace komunikuje se serverem pomocí klientské knihovny serveru Player (libplayerc++ pro jazyk C++), která poskytuje datové struktury a volání metod pro získávání a nastavování údajů z/na server. Typický příklad komunikace se serverem pomocí klientské knihovny ukazuje následující kus kódu v C++: Listing 6.1: Komunikace se serverem Player 1 2 3

#include #include < l i b p l a y e r c++/p l a y e r c ++.h> #include <s e t >

4 5 6 7 8

i n t main ( i n t argc , char ∗ argv [ ] ) { using namespace PlayerCc ; PlayerClient r o b o t ( " localhost " ) ; // i n i c i a l i z a c e k l i e n t s k e knihovny , p r i p o j e n i k~ s e r v e r u na a d r e s e l o c a l h o s t

9 10

11

12

13

r o b o t . R e q u e s t D e v i c e L i s t ( ) ; // pozadavek na n a c t e n i seznamu z a r i z e n i ( pokud j e t e n t o krok vynechan , pak v o l a n i na n a s l e d u j i c i m radku v r a c i prazdny seznam ) s t d : : l i s t < p l a y e r c _ d e v i c e _ i n f o _ t > seznam = r o b o t . G e t D e v i c e L i s t ( ) ; // n a c t e n i seznamu v s e c h z a r i z e n i s t d : : l i s t < p l a y e r c _ d e v i c e _ i n f o _ t >:: i t e r a t o r i t ; // pomocna promenna , iterator s t d : : s e t < i n t > r o b o I d s ; // mnozina v s e c h i d e n t i f k a t o r u z a r i z e n i

14 15 16 17 18 19 20 21 22

/∗ n a s l e d u j i c i c y k l u s p l n i seznam i d e n t i f i k a t o r u temi , k t e r e n a l e z i z a r i z e n i s~ovladacem s t a g e ( takova z a r i z e n i j s o u pak povazovana za r o b o t y ) ∗/ f o r ( i t=seznam . b e g i n ( ) ; i t != seznam . end ( ) ; ++i t ) { i f ( strcmp ( i t −>drivername , " stage " ) == 0 ) { r o b o I d s . i n s e r t ( i t −>addr . i n d e x ) ; } }

23 24

seznam . c l e a r ( ) ;

25 26

s t d : : s e t < i n t >:: i t e r a t o r i t e r ; // pomocna promenna , i t e r a t o r

27 28

SonarProxy ∗∗ s o n a r y = ( SonarProxy ∗ ∗ ) m a l l o c ( s i z e o f ( SonarProxy ∗ ) ∗ r o b o I d s . s i z e ( ) ) ; // p o l e s t r u k t u r p r e d s t a v u j i c h s o n a r o v e s e n z o r y 1 Pod pojmem „aktuátor“ je zde míněno mechanické zařízení pro změnu pozice robotu. Typicky se tedy jedná např. o hnací motor.

6.2. MODEL PROSTŘEDÍ

23

P o s i t i o n 2 d P r o x y ∗∗ p o z i c e = ( P o s i t i o n 2 d P r o x y ∗ ∗ ) m a l l o c ( s i z e o f ( P o s i t i o n 2 d P r o x y ∗ ) ∗ r o b o I d s . s i z e ( ) ) ; // p o l e s t r u k t u r p r e d s t a v u j i c h p o z i c e robotu

29

30

/∗ n a s l e d u j i c i c y k l u s ukl ada do t c h t o p o l i i n f o r m a c e o~ s o n a r e c h a p o z i c i r o b o t u ∗/ int i = 0 ; f o r ( i t e r = r o b o I d s . b e g i n ( ) ; i t e r != r o b o I d s . end ( ) ; ++i t e r ) { s t d : : c o u t << ∗ i t e r << s t d : : e n d l ; SonarProxy ∗ sp = new SonarProxy(& robot , ∗ i t e r ) ; s o n a r y [ i ] = sp ; P o s i t i o n 2 d P r o x y ∗ pp = new P o s i t i o n 2 d P r o x y (& robot , ∗ i t e r ) ; p o z i c e [ i ] = pp ; i ++; }

31

32 33 34 35 36 37 38 39 40 41

int pocet = i ;

42 43

/∗ nekonecna smycka v y p i s u j i c i p o z i c e r o b o t u ∗/ for ( ; ; ) { double t u r n r a t e , s p e e d ; r o b o t . Read ( ) ;

44 45 46 47 48 49

s t d : : c o u t << " Udaje z~ robotu :\ n\t" ; f o r ( i = 0 ; i < p o c e t ; i ++){ s t d : : c o u t << i << " .: [" << p o z i c e [ i ]−>GetXPos ( ) << " ," << p o z i c e [ i ]−>GetYPos ( ) << "], " ; } s t d : : c o u t << s t d : : e n d l ;

50 51 52

53 54 55

}

56 57

// u k l i d ( sem s e program d o s t a n e pouze t e o r e t i c k y p r i p r e r u s e n i smycky ) f r e e ( sonary ) ; free ( pozice ) ;

58 59 60 61

}

Na řádku č. 8 se vytváří instance třídy PlayerClient s parametrem adresy serveru (v tomto případě localhost). Tato třída implementuje klientskou knihovnu a je zodpovědná za komunikaci mezi klientem a serverem Player. Zde je důležité poznamenat, že k serveru Player může být v jednu chvíli připojeno více klientů, nejedná se tedy o výhradní přístup. Na řádku 11 je použita metoda GetDeviceList(), která vrací seznam dostupných zařízení – tedy zařízení, s nimiž můžeme komunikovat. Dále, pokud má toto zařízení ovladač s názvem „stage“, je přidáno do seznamu zařízení, která budeme ovládat. V další části kódu, tedy na řádcích 33-39, je pro každé zařízení vytvořena instance třídy představující sonar (SonarProxy) a pozici (Position2dProxy) robotu. V následné nekonečné smyčce jsou pro každý robot přečteny informace o poloze a vypsány na standardní výstup. Pokud bychom chtěli změnit rychlost otáčení kol a úhel jejich otočení, posloužilo by k tomu zavolání pozice[i]->SetSpeed(rychlost, otoceni);.

6.2

Model prostředí

V kapitole 5 bylo zmíněno, že vizualizační komponenta potřebuje ke svému běhu znát 3D model prostředí (prostředím je zde míněno rozložení překážek, mantinelů ad.). Jednou

24

KAPITOLA 6. REALIZACE VIZUALIZAČNÍ KOMPONENTY

z možností, jak toto rozložení získat, je využít rozhraní map frameworku Player. Toto rozhraní je ovšem silně omezující v tom smyslu, že vrací pouze dvourozměrnou bitmapu, a není možné zde definovat další vlastnosti jednotlivých prvků (např. jejich jednoznačnou identifikaci, či zda jsou pohyblivé). Z tohoto důvodu se v popisované komponentě používá konfigurace prostředí pomocí XML souboru. Jeho XML Schema je uvedeno v dodatku C. V tomto popisu je uvedena pozice a rozměry každé překážky včetně jména. Tento konfigurační soubor je v komponentě pro vizualizaci zpracován třídou CArenaBuilder. Zde se pro každý element <cuboid> vytvoří 3D objekt, který je přidán do (OpenGL) scény. Ukázka možného výsledného modelu je na obr. 6.1(a). Do tohoto modelu je pak vykreslen model robotu, obr. 6.1(b). Tento model byl získán převodem schématu skutečného robotu projektu SyRoTek z aplikace Autodesk Inventor do modelu 3D Studio Max, přičemž počet polygonů byl snížen cca na 1/20. Celkový počet polygonů scény s jedním robotem je přibližně 2000, přičemž robot má cca 500 polygonů, data z laserového dálkoměru 360, data ze sonarů 16, data o ujeté trase 100 a překážky cca 1000 polygonů.

(a) 3D model překážek

(b) 3D model robotu

Obrázek 6.1: Modely prostředí a robotu

6.3

Vykreslování senzorických dat a údajů o robotu

Nedílnou součástí vizualizační komponenty je vykreslování senzorických dat a údajů o ujeté dráze robotu. Pro správné pochopení způsobu vykreslování je nutné uvést, jaký formát mají údaje o sonaru a laseru získané z klientské knihovny frameworku Player. Ke každému senzoru jsou k dispozici následující údaje o jeho pozici a otočení: x,y,z Souřadnice umístění senzoru, kde souřadnice jsou vztaženy ke středu robotu, roll úhel otočení v ose x, pitch úhel otočení v ose y a yaw úhel otočení v ose z (viz obr. 6.2).

6.3. VYKRESLOVÁNÍ SENZORICKÝCH DAT A ÚDAJŮ O ROBOTU

25

z

Yaw

Pitch Roll

y

x

Obrázek 6.2: K pojmům roll, pitch a yaw U sonaru můžeme pomocí klientské knihovny vyčíst vzdálenost překážky, od níž se sonarový paprsek odráží. Reálný sonar ovšem nevyzařuje ve formě monosvazkového paprsku, ale má vyzařovací charakteristiku ve formě laloku. Náčrtek takové charakteristiky je uveden na obr. 6.3. Popsat tuto vyzařovací charakteristiku není pro účely vizualizace příliš účelné, proto se v prostředí Player používá zjednodušený model, kdy je paprsku definován rozptyl. Tento přístup je využit i ve vizualizační komponentě. Výsledná reprezentace dat ze sonaru je ukázána na obr. 6.4. 0

270

90

180

Obrázek 6.3: Charakteristika sonaru Všechny třídy, které ve vizualizační komponentě zajišťují vykreslování senzorických dat, implementují rozhraní ISceneNode knihovny Irrlicht. Jejich inicializace se provádí v konstruktoru, aktualizace senzorických dat se provádí zavoláním funkce refreshData() a v okamžiku, kdy je požadováno překreslení dat, je zavolána funkce render(). V této funkci daný objekt vykreslí senzorická data. Vykreslování sonarových dat zajišťuje třída CSonarScreenNode. Pro každý paprsek se vykreslí jeden trojúhelník (polygon), přičemž první vrchol je pozice senzoru. Princip počítání souřadnic jednotlivých bodů trojúhelníku znázorňuje obr. 6.5. Na obrázku je znázorněn pohled jedním sonarovým senzorem. Pozice senzotu, získaná ze systému Player, je uváděna v relativních souřadnicích vůči středu robotu. Proto pro získání absolutních souřadnic umístění senzoru (rx , ry ) z relativní pozice (rx , ry )B potřebujeme provést transformaci podle vztahu:

26

KAPITOLA 6. REALIZACE VIZUALIZAČNÍ KOMPONENTY

y

p2

p1

ε d

x

Obrázek 6.4: Zjednodušená reprezentace dat ze sonaru. r je úhel rozptylu, d je délka paprsku

Obrázek 6.5: Umístění bodů sonaru vzhledem ke světovým souřadnicím.  je úhel rozptylu paprsku, d je délka paprsku, α je úhel otočení sonarového senzoru vůči robotu a δ je úhel otočení robotu vůči základním souřadnicím. S je střed robotu o souřadnicích S = (sx , sy ), R je bod umístění senzoru o souřadnicích a R = (rx , ry ) a p1 , p2 jsou vrcholy trojúhselníku znázorňujícího sonarová data.

6.3. VYKRESLOVÁNÍ SENZORICKÝCH DAT A ÚDAJŮ O ROBOTU

27



 cos δ sin δ (rx , ry ) = (sx , sy ) + · (rx , ry )TB . − sin δ cos δ Tím získáme souřadnice prvního bodu trojúhelníku. Zbylé dva určíme ze vztahu 

 cos α ±  sin α ±  · (rx , ry + d)T . (pnx , pny ) = − sin α ±  cos α ±  Pro vykreslení senzorických dat sonaru je tedy zapotřebí pro každý jeden sonar přesně jeden OpenGL polygon.

α

Princip laserového dálkoměru je takový, že je vypuštěn laserový paprsek, který se odrazí od překážky a z uplynulého času se zjistí požadovaná vzdálenost překážky. Tento paprsek je pak vyslán v mnoha různých úhlech, a to několikrát za vteřinu. Výstupem takového dálkoměru je pak obecně pole dvojic (úhel paprsku, vzdálenost překážky), přičemž těchto dvojic je tolik, do kolika úhlů byl paprsek vyslán. Zobrazení dat laserového dálkoměru je tedy o něco složitější, protože zde nemáme údaj o jednom, ale o několika (obvykle desítkách až stovkách) paprsků. Grafická reprezentace těchto dat by mohla vypadat kupříkladu tak, jak je ukázáno na obr. 6.6

Obrázek 6.6: Informace získané z laserového dálkoměru. α je úhel, který udává směr paprsku vůči nulové pozici. Zeleně je vyznačena překážka. Tento způsob reprezentace je sice možný (a využívá ho například Gazebo, viz obrázek 3.2), nicméně v praxi se nejčastěji využívá zobrazení těchto dat jako plocha. Zde se spojí vždy každé dva údaje se vzdálenosti s počátkem, čímž vznikne trojúhelník. Pokud se toto provede pro každé dva sousedící údaje, vznikne plocha ohraničená body v rovině dosažitelnými laserovým dálkoměrem. Ukázku, jak takové zobrazení může ve výsledku vypadat, podává obr. 5.3(b). Data z laserového dálkoměru jsou ve vizualizační komponentě vykreslována třídou CLaserScreenNode, která pro transformaci pozic bodů ze souřadné soustavy Playeru do scény Irrlichtu používá stejný přístup jako předcházející třída pro sonar. Počet polygonů, nutných pro zobrazení laserových dat, je roven počtu vzdáleností získaných ze senzoru - 1. Posledním vizualizovaným údajem jsou informace o ujeté dráze robotu. To zajišťuje třída CPathScreenNode, která si udržuje seznam bodů, na nichž se robot nacházel, a mezi těmito body vykresluje spojnice. Body jsou přidávány do tohoto seznamu jednou za určitou konstantu, typicky jednou za vteřinu. Počet polygonů (trojúhelníků) potřebných k vykreslení této ujeté trasy je roven 2 · (n − 1), kde n je počet uložených bodů.

6.3.1

Řešení problému zákryvů

Problém zákryvů, který byl představen v předchozí kapitole, má v kontextu projektu SyRoTek několik specifik, které jeho řešení do značné míry usnadňují. Mezi tato specifika

28

KAPITOLA 6. REALIZACE VIZUALIZAČNÍ KOMPONENTY

patří skutečnost, že je známa (poměrně přesně) pozice všech překážek, pozice kamer i data ze senzorů. Proto byl zvolen přístup s využitím modelu prostředí. V počátcích řešení tohoto problému nebylo uvažováno využití některého z API pro práci s grafickými kartami, jako je OpenGL nebo Direct3D. Místo toho byl vytvořen zásuvný modul pro framework GStreamer, jehož vstupem bylo video z kamery a senzorová data. Vizuální reprezentace těchto senzorových dat byla vykreslována do jednotlivých snímků videa pomocí 2D grafické knihovny Cairo (http://cairographics.org/) a výstupem modulu byly snímky překryté vizualizací senzorových dat. Oproti počátečním předpokladům ovšem tento přístup nešetřil výpočetními prostředky, ale spíše naopak – bylo nutné převádět obraz z videoformátu AYUV do RGB24 a naopak, což se ukázalo být procesorově poměrně náročnou operací. Také samotné vykreslování pixel po pixelu do každého snímku zabíralo nezanedbatelnou část procesorového času. Jako další část bylo plánováno vytvořit paměťovou reprezentaci prostředí a realizovat algoritmy, které by byly schopné vypočítat zákryvy objektů v tomto prostředí. Jelikož ale už samotné vykreslování do snímků videa bylo procesorově náročné, bylo od tohoto přístupu upuštěno a místo toho bylo rozhodnuto valnou část těchto výpočtů přenechat grafické kartě. Tento druhý přístup, tedy využití grafické karty pro výpočty zákryvů, se ve výsledku ukázal jako mnohem méně náročný nejen na hardware, ale především na programovou implementaci samotnou. Další výhodu, kterou s sebou toto řešení nese, je možnost simulace robotického prostředí bez jeho skutečné existence. Stačí totiž nevykreslit video, ale vykreslit viditelně překážky definované v modelu prostředí. Tím vzniká jednoduchý třídimenzionální simulátor pro framework Player, podobný simulátoru Gazebo (ovšem bez fyzikálního modelu). Jedinou nevýhodu, kterou s sebou tento přístup nese, je nutnost vlastnictví grafické karty s hardwarovou podporou OpenGL2 . Přístup k řešení problému je tedy takový, že je vytvořena 3D scéna v prostředí Irrlicht se všemi objekty a vizualizovanými senzorickými údaji, přičemž na pozadí je vykreslena textura, do níž se vykreslují jednotlivé snímky z videa. Zde ovšem nastává otázka, jak docílit výpočtu zákryvů v OpenGL scéně. Problém se pokouší přiblížit obrázek 6.7. Na tomto obrázku je kamera nasměrována tak, že vizualizace dat laserového dálkoměru a robot samotný jsou zčásti zakryty překážkou. Pokud bychom chtěli tuto scénu využít pro výpočet tvaru, který chceme zobrazit (zvýrazněná oblast na obr. 6.7(b)) a následně jej nakreslit přes data z kamery, musíme docílit toho, aby se místo všech překážek a jiných objektů v modelu vykreslilo pozadí scény (na obrázku je toto pozadí pouze černá plocha). Jedno z možných řešení, které známe např. z televizních předpovědí počasí, je asociovat všem objektům, které chceme „zprůhlednit“ nějakou předem definovanou barvu, a pak pixely této překreslit patřičnými pixely ze scény na pozadí. Na příkladu televizní předpovědi počasí3 to funguje podobně: meteorolog (či jen moderátor) je filmován před plátnem modré barvy a při postprocesingu obrazu se pixely modré barvy nahradí obrázkem o počasí. Pokud by si ale moderátor oblékl modré tričko, bude také „průhledný“. Tento přístup je možný, nicméně vyžaduje napsaní specializovaného shaderu, pravděpodobně v jazyce GLSL nebo Cg, pro míchání textur. Navíc zde vzniká problém, jak 2

Výpočty lze realizovat i softwarovou emulací, nicméně výsledná rychlost výpočtů a posléze i zobrazení samotné je přirozeně řádově pomalejší. Na testovacím stroji bylo dosaženo výkonu cca 400 snímků/s s grafickou kartou, a cca 40 snímků/s bez ní 3 Tato technologie, nazvaná klíčování, se dá považovat za jedno z historicky prvních reálných využití rozšířené reality

6.4. ZPRACOVÁNÍ VIDEA A JEHO PŘENOS PO SÍTI

(a) Pohled na arénu, data ze senzoru jsou zčásti zakryta překážkou.

29

(b) Označený výsek představuje požadovaný výsledek výpočtu zákryvů

Obrázek 6.7: Ilustrativní obrázek k řešení problému zákryvů zabránit možným stínům překážek, jak zajistit jejich stálou barvu i při pohledu z velké vzdálenosti atd. Z tohoto důvodu je lepší zvolit druhou metodu, jíž je vykreslení překážek bez zápisu do barevného bufferu (color buffer ), ale se zápisem do z-bufferu. Tím docílíme toho, že objekty sice nebudou viditelné, ale budou použity pro výpočet viditelnosti ostatních objektů scény. V OpenGL se toho dá docílit pomocí nastavení barevné masky: gl.glColorMask(false, false, false, false); v Direct3D podobně lpD3DDevice->SetRenderState(D3DRS_COLORWRITEENABLE, 0); a v Irrlichtu pomocí zavolání objekt->setMaterialFlag(irr::video::EMF_COLOR_MASK, false); na objekt, který chceme „zneviditelnit“. Tímto způsobem lze velmi elegantně vyřešit problém zákryvů bez nutnosti používaní speciálních shaderů a bez ztráty výkonu způsobené skládáním textur.

6.4

Zpracování videa a jeho přenos po síti

Jednou z klíčových funkcionalit komponenty pro vizualizaci je schopnost získávání obrazových dat z rozličných vstupů a schopnost exportu zpracovaných dat do několika typů výstupů. Shrnutí předpokládaných vstupů a výstupů podává obr. 4.4. Jak je již na první pohled zřejmé, nebylo by příliš vhodné tvořit celý systém vstupů a výstupů obrazových dat od základu celý. Lze totiž předpokládat, že v průběhu používání komponenty se mohou vyskytnout ještě další požadavky na nové typy vstupů či výstupů (např. streamování do dalších formátů, načítání obrazu přes protokol RTSP atd.), a komponenta by se musela upravit tak, aby tyto požadavky dokázala uspokojit.

30

KAPITOLA 6. REALIZACE VIZUALIZAČNÍ KOMPONENTY

Místo toho je tedy rozumné použít některou z multimediálních knihoven, které podporují pestrý výběr vstupních formátů. Tyto formáty pak umí převést do jediného formátu (např. pole RGB pixelů), který se předá vizualizační komponentě a ta nad ním provede vykreslovací operace. Příkladem budiž situace, kdy dostáváme obraz z černobílé kamery připojené pomocí rozhraní IEEE-1394, druhý obraz z barevné kamery připojené pomocí USB, do vizualizační komponenty tato data předáváme ve formátu RGB a ta je upraví a složí. Výstupem z komponenty jsou zase data ve formátu RGB, a jednak jsou pomocí RTSP přenášena ke klientovi a za druhé ukládána na disk. Pro všechny operace, které souvisí se získáním obrazu, s jeho překódováním, změnou velikosti, FPS a jeho streamováním můžeme použít multimediální knihovnu. Jediné, co musí být implementováno ve vizualizační komponentě, je propojení s multimediální knihovnou – tedy kód, který dokáže získat obrazová data z knihovny a předat je knihovně zpátky. Multimediálních knihoven, které přichází v úvahu (tzn. mají některou z OpenSource licencí, jsou do jisté míry nezávislé na použité platformě a poskytují všechny požadované funkce) je hned několik. Mezi ně můžeme zařadit již zmiňovaný GStreamer, dále mplayer (http://www.mplayerhq.hu/), NMM (http://www.networkmultimedia.org/) VideoLan (http://www.videolan.org/), xine-lib (http://www.xine-project.org/) a další. Pouze dvě z nich, a to GStreamer a NMM, využívají modulární architekturu. To znamená, že systém pro zpracování a přenos videa se skládá z jednotlivých modulů, které mezi sebou dokáží komunikovat a jsou spojeny do tzv. pipeline, což je jakési zapouzdření použitých modulů (nazývaných plugins) do jednoho celku. Při volbě mezi GStreamer em a NMM rozhodla ta skutečnost, že GStreamer je úspěšně využit v mnoha aplikacích, zatímco NMM má reálných použití jen poskrovnu. GStreamer také nabízí větší množství pluginů. Proto byl za multimediální knihovnu vybrán GStreamer. Pro bližší vysvětlení principu modulů a pipeline v GStreameru uvažujme např. situaci, kdy máme na vstupu video z kamery. K němu chceme dodat zvuk z mikrofonů, chceme změnit jeho rozlišení na 800x600 pixelů, chceme do horního pravého a dolního levého rohu přidat náhled ze dvou vedlejších kamer a toto video chceme překódovat do formátu H.264 a poslat po síti protokolem RTP. Výsledná pipeline by vypadala přibližně jako na obr. 6.8. alsa stream

video4linux2 stream

v4l2src

jpegdec

videoscale

v4l2src

jpegdec

videoscale

video4linux2 stream

Sekundární kamery

Klient

video4linux2 stream

v4l2src

videoscale

videomixer

x264enc

audioconvert

alsasrc

ffmux_mp4

rtpmp4gpay

Lokalizační kamera

rtpbin

UDP

GStreamer

Obrázek 6.8: Pipeline GStreameru. Pro využití GStreameru ve vizualizační komponentě jsou zapotřebí pipeline dvě. Jednu můžeme nazvat „vstupní“, přičemž ta má na starosti získávání videa z kamer a předání jednotlivých snímků vizualizační komponentě, a druhou „výstupní“, která vyzvedává snímky z vizualizační komponenty a distribuuje obrazový proud klientům. Schematické znázornění poskytuje obr. 6.9. V terminologii GStreameru se vstupy a výstupy

6.4. ZPRACOVÁNÍ VIDEA A JEHO PŘENOS PO SÍTI

31

komponenty nazývají pads, přičemž vstupní prvek je nazýván sink a výstupní source. Z pohledu GStreameru tedy vizualizační komponenta hraje v roli výstupního prvku ve vstupní pipeline, a v roli zdrojového prvku ve výstupní pipeline. Vstup z kamer

Převod formátu

Převod formátu

Výstup videoproudu

Vizualizační komponenta Sink

Source

Výstupní pipeline

Vstupní pipeline

Obrázek 6.9: Vstupní a výstupní pipeline Předpokládaným vstupem do vstupní pipeline je kamera, a to připojená buď pomocí IEEE-1394, či pomocí ovladače kompatibilního se standardem Video4Linux(2). GStreamer poskytuje moduly, které s těmito rozhraními dokáží spolupracovat: pro IEEE-1394 je to plugin dv1394src a pro Video4Linux v4lsrc, případně v4l2src. Předpokládaným výstupem z výstupní pipeline je uložení do souboru (v kodeku H.264) či rozesílání klientům pomocí protokolu RTP/UDP, což může zajišťovat plugin h264enc ve spolupráci s pluginem filesink, respektive plugin gstrtpsession ve spolupráci s pluginem udpsink. Zobrazování na obrazovku a přístup k obrázkům pomocí protokolu http není nutné řešit pomocí GStreameru, realizaci těchto dvou výstupů se věnují následující podkapitoly.

6.4.1

Komponenta vstupu videa z pipeline GStreameru (videosink )

Tato součást, označená na obr. 6.9 jako sink, má na starosti zpracování obrazového výstupu z pipeline GStreameru do takového formátu, s nímž dokáže pracovat vizualizační komponenta. Prakticky se jedná o plugin do GStreameru, který při příchodu každého rámce z videa (v očekávaném formátu RGB s 32 bitovou hloubkou) zkopíruje obsah tohoto rámce do textury Irrlichtu, která se pak vykreslí na pozadí OpenGL scény. Následující pseudokód se snaží přiblížit operace, které plugin provádí: global textura; callback function prijat_ramec(ramec) { pole_bajtu := konverze_na_pole_bajtu(ramec) textura := vytvoreni_textury_z_pole_bajtu(pole_bajtu) } function textura_na_pozadi() {

32

KAPITOLA 6. REALIZACE VIZUALIZAČNÍ KOMPONENTY

return textura } Implementace tohoto algoritmu je ve třídě CVideoPlayer, přičemž členská funkce označená v pseudokódu prijat_ramec se zde jmenuje on_new_buffer_from_source a funkce vracející texturu představující poslední přijatý rámec videa reprezentuje členská funkce getVideoTexture(). Pro implementaci byl použit objekt4 appsink, který slouží k usnadnění komunikace mezi aplikací a pipeline GStreameru právě tím, že se dá vložit jako plugin do pipeline a volá uživatelem definovanou funkci v okamžiku, kdy přijde nový video rámec.

6.4.2

Komponenta výstupu videa z pipeline GStreameru (videosource)

Význam této komponenty spočívá v tom, že umožňuje vkládat jednotlivé snímky do pipeline GStreameru. Toto vkládání se děje asynchronně, a to tak, že pipeline je nastaven počet snímků za vteřinu a za časovou konstantu rovnou 1/(počet snímků za vteřinu) vteřiny je zavolána funkce, která vrací rámec ve formátu RGB 32 bitové hloubky vhodný pro další použití v pipeline GStreameru. Pseudokód těchto operací může vypadat takto: global ramec; callback function pozadavek_na_ramec(ramec) { while ((snimek := pozadavek_na_snimek_obrazovky()) = false) { cekej() } ramec := textura_na_snimek(snimek) return ramec } Před detailním popsáním toho, jak algoritmus funguje, je nutné vysvětlit princip získávání snímku obrazovky. První metoda, která byla s úspěchem vyzkoušena, je založena na použití tzv. Multiple Render Targets, což je taková vlastnost grafické karty, která umožňuje vykreslování jedné scény do více výstupů (textur). Typicky se dá využít pro vykreslení celé scény do jedné textury, která pak může být aplikována na některý objekt scény. Pro získávání snímků scény se dá využít tak, že se celá scéna vykreslí do jedné textury a obsah této textury je zkopírován do operační paměti. Nevýhodou této metody jsou jednak její požadavky na vybavení počítače (je použitelná pouze pod DirectX 9 a vyšší, a pod OpenGL 2.1 a vyšší) a za druhé její výpočetní náročnost (kopírování dat z paměti grafické karty do operační paměti je poměrně pomalá operace). Z těchto důvodů proto byla použita druhá metoda, která spočívá v jednoduchém snímání vykreslovacího okna aplikace. Tento způsob sice vyžaduje otevřené okno s vykreslenou scénou, ale na druhou stranu je použitelný téměř na jakémkoliv stroji a je výpočetně nenáročný. 4 Nejedná se ovšem o objekt programovacího jazyka, nýbrž o objekt nad knihovnou GLib (http: //library.gnome.org/devel/glib/), nad níž je postaven celý GStreamer

6.5. PŘENOS POHLEDU NA ARÉNU POMOCÍ PROTOKOLU HTTP

33

U obou použitých přístupů nastává problém s asynchronností, kdy požadavek na obrázek vykreslené scény může přijít v okamžik, kdy scéna není vykreslená. V tom případě dostaneme černý obrázek, či obrázek s náhodnou směsí barev. Tento problém by se dal vyřešit vytvořením snímku obrazovky při každém vykreslení scény, nicméně toto řešení by zcela zbytečně plýtvalo výpočetními prostředky. Proto byl použit takový přístup, kdy snímek obrazovky je vytvořen až v okamžiku, kdy na něj byl předem vznesen požadavek. Funguje to tedy tak, že je (od jiného vlákna) nejdříve zaznamenán požadavek na snímek obrazovky, vlákno (či vlákna, pokud je jich více) požadující snímek se uspí, a v okamžiku vykreslení scény se vytvoří i snímek obrazovky, uspané vlákno se probudí a předá se mu tento snímek. Implementace algoritmu se skrývá ve třídě CVideoSource. Pro asynchronnost je zde využit objekt (ve smyslu jak jej chápe knihovna GLib) appsource. Výstupní pipeline je spuštěna v samostatném vlákně a je jí nastaven počet požadovaných snímků za vteřinu. V okamžiku, kdy je zapotřebí vyzvednout další snímek, se zavolá funkce push_buffer objektu CVideoSource, která vrací aktuální pohled na scénu.

6.5

Přenos pohledu na arénu pomocí protokolu http

Jedna z dalších požadovaných funkcí vizualizační komponenty spočívá v možnosti pohledu na robotickou arénu přes webové rozhraní. V principu se jedná o jednoduchou HTML stránku, na které je obrázek, automaticky obnovovaný jednou za určitou časovou konstantu (např. jednou za vteřinu). Obnovování stránky lze zajistit pomocí tagu <meta http-equiv="refresh" content="1"/> v hlavičce webové stránky, nebo pomocí kódu v JavaScriptu, případně i za použití technologie AJAX. Zajímavější část řešení leží na straně serveru, v tomto případě lze za „server“ považovat část vizualizační komponenty samotné. Třída CImageStreaming zajišťuje funkčnost http serveru, který na zadaném portu čeká na požadavky a obdrží-li nějaký, vrátí jako odpověď obrázek ve formátu jpeg reprezentující pohled na aktuální dění na robotické scéně. Princip získávání snímků obrazovky je stejný jako v případě výstupu videa do pipeline GStreameru, nejdříve je zaznamenán požadavek na snímek, poté je vlákno obsluhující požadavek od klienta uspáno a v okamžiku, kdy je snímek k dispozici, je vlákno probuzeno a odesílá tento snímek zpět ke klientovi ve formě pole bajtů. Kód čekající na požadavky běží v samostatném vlákně, aby obsluha TCP spojení neovlivňovala vykreslování OpenGL scény a naopak. Obsluha požadavků samotných se odehrává v samostatných vláknech, pro každé nové spojení je tedy vytvořeno nové spojení. Tím je zajištěno, že spojení může být v jeden okamžik několik (a to obecně dokonce tolik, kolik může v jednom okamžiku existovat běžících vláken).

6.6

Kalibrace kamery a oprava obrazu

Informace získané z kamery obsahují kvůli nedokonalosti objektivu některé optické chyby. Těchto chyb může být několik typů, nicméně pro účely této práce je nejdůležitější soudkovitost (barrel distortion), případně poduškovitost (pincushion distortion). Obě tyto optické vady znázorňuje obr. 6.10.

34

KAPITOLA 6. REALIZACE VIZUALIZAČNÍ KOMPONENTY

(a) Soudkovitost

(b) Poduškovitost

Obrázek 6.10: Optické vady Tyto vady se projevují u přímek mimoběžných s optickou osou tím, že se nezobrazí jako přímka, ale jako křivka. Příčinou je, že boční zvětšení závisí na vzdálenostech od osy. U soudkovitosti se zvětšení se vzrůstající vzdáleností zvětšuje, u poduškovitosti naopak zmenšuje. Zkreslení se běžně odstraňují pomocí clony, nicméně toto řešení není v daném případě možné (vyžadovalo by nákup jiného zařízení). Proto se tyto vady odstraňují softwarovou cestou, tzv. kalibrací. Pro vysvětlení principu kalibrace kamery je nutné popsat základy principu zobrazení třírozměrného prostoru na dvourozměrnou plochu5 . Problematika zobrazení kamerou bohužel přesahuje rámec této práce, proto je zde vysvětlena jen velmi stručně. Pro vyčerpávající vysvětlení lze doporučit publikaci [11]. Princip je znázorněn na obr. 6.11. Toto zobrazení (třírozměrného prostoru na dvourozměrnou plochu) můžeme popsat vztahem       xw u   v  = A R T  yw  , 0 1  zw  1 1

(6.1)

kde [u, v]T jsou souřadnice v ploše, [xw , yw , zw ]T jsou souřadnice v prostoru, A je matice kamery, R je matice otočení kamery a T je vektor posunutí kamery. Matice kamery je definována jako   αx γ u0 A =  0 αy v0  , 0 0 1

(6.2)

kde αx = f /px a αy = f /py (p je šířka jednoho pixelu, f je ohnisková vzdálenost), [u0 , v0 , 1] jsou souřadnice hlavního bodu (principal point, střed zkreslení) a γ je úhel natočení plochy (pro jednoduchost předpokládáme s = 0). 5

V následujícím textu předpokládáme homogenní souřadnice a model tzv. dírkové kamery

6.6. KALIBRACE KAMERY A OPRAVA OBRAZU

35

Obrázek 6.11: Projekce 3D prostoru na 2D plochu Zkreslení obrazu můžeme rozdělit do dvou skupin: radiální zkreslení a tangentoidní zkreslení. Radiální zkreslení je deformace obrazu okolo bodu definovaného jako střed zkreslení (do této skupiny patří již zmiňovaná soudkovitost a poduškovitost), a tangentoidní zkreslení je deformace kolmá na radiálně zkreslený bod. Tyto parametry se souhrnně označují jako koeficienty zkreslení, kc . Vnitřní parametry kamery (koeficienty zkreslení, ohnisková vzdálenost, šířka jednoho pixelu a souřadnice hlavního bodu) bývají někdy udávány výrobcem objektivu, nicméně nejčastěji je neznáme a musíme je změřit. K tomuto účelu existuje několik nástrojů. Ty pracují na principu, kdy za vstup mají několik (10-20) snímků se známým vzorem pořízených objektivem, ty porovnají s tím, jak by vzor měl vypadat nezkresleně a jejich výstupem jsou mj. vnitřní a vnější (rotace a translace) parametry kamery. Tyto parametry se posléze dají využít k vypočtení nezkresleného obrazu, neboli inverznímu mapování. Porovnání obrazu před a po korekci je patrné na obr. 6.12 (na tomto snímku je také vidět použitý vzor pro kalibraci). Kvůli složitosti modelu zkreslení neexistuje žádný obecný algebraický výraz pro tuto operaci, proto jsou k dispozici pouze numerická řešení. Pro zjištění těchto parametrů v implementaci nástroje pro vizualizaci byl použit Camera Calibration Toolbox for Matlab [5]. Pro výpočet inverzního mapování byla využita funkce Undistort() knihovny OpenCV [12] Dalším problémem, poměrně úzce spjatým s kalibrací, je transformace obrazových souřadnic do světových souřadnic. Zjednodušeně řečeno, účelem této transformace je pro každý pixel na bitmapě (obrázku) určit odpovídající bod v prostoru. V kontextu vizualizační komponenty má tato transformace zajistit, že budeme schopni v obrázku

36

KAPITOLA 6. REALIZACE VIZUALIZAČNÍ KOMPONENTY

(a) Před korekcí

(b) Po korekci

Obrázek 6.12: Korekce zkreslení získaném z kamery identifikovat pro každý pixel odpovídající souřadnice daného místa v modelu prostředí. Vstupem do této transformace je tedy obecně bod (a, b, c) na obrázku z kamery (což je v třírozměrném případě stereobraz, tzn. včetně informace o hloubce) a výstupem bod v prostoru, (x, y, z). Nalezení matice, která takové zobrazení popisuje, znamená určit korespondence mezi alespoň osmi body v obraze a prostoru. Pro nalezení této korespondence se nejčastěji využívá metoda nazvaná Singular value decomposition (SVD), jejíž vysvětlení už však výrazně překračuje rámec této práce. Vysvětlení celého procesu můžeme nalézt například v publikacích [11, 16]; pro nalezení korespendence byly v této práci použity nástroje vyvinuté v Gerstnerově laboratoři Katedry kybernetiky ČVUT.

6.7

Obraz v obraze

Poslední požadavek, který je diskutován v této kapitole, je možnost zobrazení pohledu na robotickou arénu z více kamer zároveň. Typické použití je takové, kdy je robot sledován některou z bočních kamer, a v malém výseku zobrazovacího okna je vykreslen přiblížený pohled z lokalizační kamery. Náčrt, jak by takové zobrazení mohlo vypadat, je na obr. 6.13.

Obrázek 6.13: Obraz v obraze Zobrazení obrazu v obraze lze realizovat pomocí rozšíření Render to Texture, jak je zmíněno v podkapitole 6.4.2. Toto řešení má ovšem vyjma nevýhod výše popsaných

6.7. OBRAZ V OBRAZE

37

ještě jednu další, a to nemožnost zobrazení textury na pozadí. Textura je vykreslována mimo modelovanou scénu, a to pomocí funkce draw2DImage() objektu IVideoDriver knihovny Irrlicht, která vykreslí na pozadí scény zadanou bitmapu. Pokud by se tedy nejprve vykreslil pohled z jedné kamery a obrázkem na pozadí, a pak teprve pohled z kamery druhé (a s jiným pozadím), s texturou reprezentující první vykreslení, pak tato textura by neobsahovala pozadí, které bylo nastaveno při jejím vytvoření. Tato vlastnost plyne z toho, že grafická karta nemá informaci o pozadí vykreslované scény, a proto při tvorbě prvního pohledu se do textury nevykreslí toto pozadí. Řešením problému je vykreslit scénu podobně jako při postupu s vykreslováním do textury, ale s tím rozdílem, že scéna není vykreslena do textury, ale rovnou na obrazovku. Postup kroků pak bude následující: 1. Nastavit oblast, do níž se má vykreslovat, na celou velikost obrazovky 2. Nastavit pozadí scény na pohled z boční kamery 3. Vykreslit všechny objekty scény při pohledu z boční kamery 4. Vymazat obsah z-bufferu 5. Nastavit oblast, do níž se má vykreslovat, na výsek velikosti obrazovky 6. Nastavit pozadí scény na pohled z horní kamery 7. Vykreslit všechny objekty scény při pohledu z horní kamery Nejvýznamnější jsou zde kroky 1 a 5, kde se definuje oblast, do níž se má vykreslovat. Scéna je tedy v podstatě vykreslena dvakrát, a to vždy pro pohled z jiné kamery, přičemž první pohled je zčásti „překreslen“ texturou a druhým pohledem. Tímto způsobem je samozřejmě možné realizovat pohled i z více než dvou kamer, a to opakováním kroků 4-7. Nicméně počet vykreslených snímků za vteřinu je pak n-krát nižší, kde n je počet pohledů. Je-li tedy při pohledu z jedné kamery dosahováno počtu 400 snímků za vteřinu, pak při pohledu ze dvou kamer to bude přibližně 200, při pohledu ze tří to bude přibližně 133 atd. Zajímavostí tohoto řešení je nutnost vyčistit z-buffer mezi vykreslením jednotlivých pohledů. Pokud bychom toto neprovedli, pak by se informace o umístění objektů v prvním pohledu přenášela i do druhého pohledu a informace o viditelnostech senzorických dat by byla překryta v tomto pohledu neexistujícími objekty. Zde se naskýtá otázka, kde je účelné spojovat obraz z více kamer. Zda na straně serveru, či klienta, a jak toto spojení provést. Otázka je úzce spojená s problematikou streamování dat (viz obr. 4.3), podívejme se proto na jednotlivé možnosti použití komponenty a možné způsoby řešení skládání obrazu z více kamer: • Data jsou okamžitě předávána uživateli. V tomto případě se jeví jako nejvhodnější složit data na serveru (např. pomocí pluginu videomixer knihovny GStreamer ), protože v opačném případě by musela být data ze všech kamer poslána na klientskou stranu odděleně, což by značně zvýšilo velikost toku dat přenášených po síti internet. To může být především v případě nízkokapacitního připojení uživatele k internetu neakceptovatelené.

38

KAPITOLA 6. REALIZACE VIZUALIZAČNÍ KOMPONENTY • Celý videozáznam sezení s robotem je nejprve zaznamenán na disk včetně informací o stavu senzorů, a na klientský počítač je (později) poslán tento videozáznam obohacený o senzorická data. I v tomto případě je nejvhodnější složit obraz ze všech kamer na straně serveru pomocí vizualizační komponenty, protože v opačném případě by uživatel nevystačil s jednoduchým přehrávačem videa, ale potřeboval by specializovanou aplikaci. • Obrazová a senzorická data jsou na klientský počítač posílána odděleně, a jejich skládání se provádí specializovanou aplikací až na klientské straně. Stejně jako v prvním případě, i zde se jeví jako nejvhodnější složit obraz ze všech kamer na straně serveru pomocí pluginu videomixer, a to pro zachování rozumné šířky požadovaného přenosového pásma. • V posledním případě jsou videozáznam sezení a senzorická data uloženy zvlášť, kdy na vyžádání je celý záznam poslán na klientský počítač a složení dat je provedeno specializovanou aplikací u klienta. Zde zřejmě není možné jiné řešení, než složení dat na straně serveru vizualizační komponentou.

Kapitola 7

Testování a srovnání s existujícími řešeními Testování probíhalo porovnáním výstupu z vizualizační komponenty s výstupem ze simulátoru Stage, otestováním funkčnosti na více počítačích a otestováním výkonnosti vizualizace. Při porovnání výstupu se simulátorem Stage bylo zjištěno, že zobrazení dat ze sonaru není v některých ohledech dostačující. Rozdíl spočívá v tom, že Stage zobrazuje výstup ze sonaru jako výseč kruhu, zatímco vizualizační komponenta (a taktéž i utilita playerv dodávaná s frameworkem Player ) jej zobrazuje jako trojúhelník. Což má za následek mírně odlišné vykreslení senzorických dat, a je nutné říci, že zobrazení tak, jak jej provádí Stage, je věrnější. Proto se jako nejlepší možnost jeví změnit vykreslovací funkci z trojúhelníku na kužel, který zřejmě nejlépe odpovídá představě výstupu ze sonarového senzoru. Z porovnání na obr. 7.1 také vyplývá, že koeficient rozptylu závisí na vykreslovací aplikaci, jak ukazuje porovnání obrázků 7.1(a) a 7.1(c). U zobrazení pomocí Stage se jednotlivé svazky nepřekrývají, zatímco u zobrazení pomocí playerv je jasně viditelné překrytí většiny z nich. Při porovnání vykreslení laserových dat nebyly zaznamenány významnější rozdíly, protože všechny tři zkoumané aplikace používají stejný přístup k vykreslování laserových dat. Další problém, na který ukázalo testování s prototypem robotické arény SyRoTek, je v nepřesných rozměrech a pozicích překážek reálného světa a jeho modelu definovaného v XML souboru. Upravené výsledky získané při tomto testování jsou na obr. 7.2. Na těchto obrázcích je v některých případech vidět, že senzor zdánlivě detektuje překážky, které v prostředí fyzicky nejsou. To ovšem není způsobeno nedokonalým modelem prostředí, ale omezeným dosahem senzorů. Další problémy spojené s modelem prostředí lze najít při podrobném zkoumání vykreslovaných dat vizualizační komponentou, kdy robot svými senzory „vidí“ překážku blíže, než ve skutečnosti je, nebo naopak vidí až dovnitř překážky. Na posledním ze čtveřice obrázků je viditelná i situace, kde kvůli velké odchylce mezi skutečným prostředím a jeho modelem robot svými senzory vidí za překážku. Řešení spočívá v důkladném přeměření fyzické arény, patřičné úpravě pozic překážek v modelu a v co nejlepší kalibraci kamery. Tento krok bohužel nemohl být proveden, protože v okamžiku testování komponenty ještě nebyla k dispozici žádná implementace projektu SyRoTek, která by umožňovala otestování fyzického robotu v aréně a vyčítání hodnot 39

KAPITOLA 7. TESTOVÁNÍ A SROVNÁNÍ S EXISTUJÍCÍMI ŘEŠENÍMI 40

(a) Zobrazení v simulátoru Stage

(b) Zobrazení pomocí vizualizační komponenty

Obrázek 7.1: Porovnání vizualizací dat ze sonaru

(c) Zobrazení utilitou playerv

41 jeho senzorů do formátu použitelného vizualizační komponentou. Dodatečná úprava modelu arény a změna kalibračních parametrů ale naštěstí nepředstavuje výrazný problém, protože nevyžaduje úpravu kódu v C++, ale pouze úpravu konfiguračních souborů.

Obrázek 7.2: Pohled na robotickou arénu pomocí vizualizační komponenty Funkčnost komponenty byla úspěšně otestována na třech různých počítačích. Souhrnný přehled jejich konfigurací a výsledků dosažených poskytují následující tabulky. Při testování výkonnosti byl vypnut http server a výstupní pipeline vůbec, vstupní pipeline byla nakonfigurována tak, aby přehrávala avi soubor. První test proběhl při pohledu na robotickou scénu v okně velikosti 1024x768 pixelů, druhý test při stejném pohledu, ale se zapnutým obrazem v obraze. Z výsledků je patrné, že počet vykreslených snímků (FPS) je velmi výrazně závislý na použité grafické kartě. Dále je patrné, že (oproti předpokladům) není FPS při použití více kamer poloviční, ale zpomalení je nižší, přibližně třetinové. Při testech na počítači č. 3 se FPS dostávalo k hranici použitelnosti, což bylo způsobeno především slabou grafickou kartou. Při detailním zkoumání bylo také zjištěno, že pokud je vynechán model robotu, FPS se výrazně zvýší (na počítači č. 1 na přibližně 720, na počítači 3 na 52). Pro ověření této hypotézy bylo otestováno ještě zobrazení s proměnným počtem robotů, a to na

42

KAPITOLA 7. TESTOVÁNÍ A SROVNÁNÍ S EXISTUJÍCÍMI ŘEŠENÍMI

CPU Operační systém Operační paměť Grafická karta

Počítač 1 Intel Core2 E8400, 3,0GHz OpenSuse Linux 11.0 x86_64, jádro 2.6.25 8GB ATI HD4850, 512MB RAM

Počítač 2 Intel Core2 E6850, 3,0GHz Gentoo Linux i686, jádro 2.6.27 3GB nVidia GTX280, 1GB RAM

Počítač 3 Intel Core Duo T2400, 1,83GHz Ubuntu 8.10 Linux i686, jádro 2.6.27 1GB Intel GMA950, 192MB RAM sdílená (ovladač OpenGL 1.4 - Mesa 7.2)

Tabulka 7.1: Počítače použité pro testování

Vykreslení scény bez obrazu v obraze [FPS] S obrazem v obraze

Počítač 1 300 180

Počítač 2 450 300

Počítač 3 32 19

Tabulka 7.2: Porovnání výkonnosti na různých počítačích počítači 1. Při pohledu na tabulku 7.3 lze usoudit, že model robotu má na výkon poměrně výrazný vliv. Nezanedbatelný je také vliv vykreslovaných senzorů, nicméně toto zpomalení je podstatně nižší než to, způsobené modelem robotu. Z těchto měření vyplývá, že prostor k optimalizacím se skrývá mimo jiné ve zjednodušení počtu polygonů robotu na nejnižší možnou, ale vizuálně ještě akceptovatelnou, hodnotu.

7.1

ArDev

Při srovnání s ostatními systémy je nutné zmínit práci spoluautora frameworku Player Tobyho Colletta [7]. Ten zde prezentuje podobnou aplikaci jménem ArDev, která slouží k vizualizaci senzorických dat pro framework Player. Její účel je prakticky totožný s vizualizační komponentou popisovanou v tomto dokumentu, nicméně existují zde některé zásadní rozdíly, přičemž ArDev má tyto nevýhody: Počet robotů 1 2 3 4 5

Se zobrazenými modely [FPS] 300 220 150 120 105

Bez zobrazených modelů [FPS] 690 650 630 620 600

Tabulka 7.3: Porovnání výkonnosti v závislosti na počtu zobrazených robotů

7.2. STAGE VERZE 3

43

1. nepočítá se zákryvy, 2. je postaven přímo nad OpenGL (na rozdíl od vizualizační komponenty, která abstrahuje pomocí Irrlichtu), 3. byl vyvíjen pouze pod Linux, 4. nepoužívá multimediální knihovnu, ale všechny funkce pro vstup/výstup implementuje sám, nebo pomocí knihoven (libdc1394,imagemagick,sdl. . . ) a 5. dosahuje malého počtu snímků za vteřinu (autoři se zmiňují cca o 15 FPS).

Obrázek 7.3: ArDev (obrázek převzat z http://sourceforge.net/projects/ardev/) ArDev nicméně poskytuje i některé vlastnosti, které vizualizační komponenta nemá. Mezi ně patří • podpora více typů senzorů, • grafické uživatelské rozhraní s bohatými možnostmi nastavení, • raytracing pro věrnější zobrazení senzorových dat v reálném prostředí. ArDev je distribuován pod licencí LGPL, teoreticky by tedy šlo realizovat vizualizační komponentu rozšířením a úpravou ArDevu. Toto řešení by ovšem vyžadovalo poměrně zásadní přeprogramování velké části jeho kódu, a to kvůli jeho omezením jmenovaným výše. Navíc by vyžadovalo další čas na pochopení struktury a jednotlivých programových částí ArDevu, a proto bylo toto řešení zavhrnuto.

7.2

Stage verze 3

Simulátor stage, ve své verzi 3, umožňuje pohled na zobrazovanou scénu pomocí perspektivní kamery. Jedná se tedy o 3D zobrazení podobné tomu, jaké poskytuje vizualizační komponenta. Zobrazování samotné je postaveno na OpenGL. Vizualizační komponenta by zčásti mohla být postavena právě na tomto simulátoru, nicméně ani toto řešení není vhodné. A to z podobných důvodů, jako v případě ArDev u

44

KAPITOLA 7. TESTOVÁNÍ A SROVNÁNÍ S EXISTUJÍCÍMI ŘEŠENÍMI

Obrázek 7.4: Pohled na model robotické arény v simulátoru Stage verze 3 – Stage vůbec nepočítá s vizualizací reálného světa, a proto neřeší problém zákryvů, nepotýká se s kalibrací kamery apod. Implementace obrazu v obraze zde také neexistuje. Použití tohoto řešení však skýtá také výhody, a to v oblasti bezproblémového propojení s frameworkem Player/Stage (jehož je Stage součástí).

7.3

Gazebo

Úvod k simulátoru Gazebo byl uveden v části 3.1.2, proto zde nebude popsán znovu. Co se týče použitelnosti jako vizualizační komponenty, pak platí podobný závěr, jako u Stage verze 3. Gazebo je primárně určeno pro simulaci, takže umožňuje nadefinovat velmi složité modely prostředí (kupříkladu patro nemocnice) s mnoha zařízeními, s nejrůznějšími modely robotů (chodící, kráčící, plovoucí, létající) a navrch umožňuje definovat modely vlastní. Zajímavá je také skutečnost, že Gazebo použilo pro vykreslování knihovnu OGRE, která se v některých ohledech dá srovnat s knihovnou Irrlicht, použitou pro vizualizační komponentu. Jedná se především o to, že i OGRE poskytuje abstrakci nezávislou na jazyku (OpenGL či Direct3D) a platformě (Windows, Linux či MacOS X), proto Gazebo je poměrně snadno přenositelné. Gazebo také používá vektorový popis prostředí (lépe řečeno, objektový). Simulátor Gazebo nicméně není určen pro vizualizaci reálného světa a Augmented Reality obecně, proto jeho možné použití v projektu SyRoTek je omezené.

Kapitola 8

Závěr Ve své práci jsem pokusil srhnout dosavadní poznatky spjaté s problematikou vizualizace v robotických systémech. Ze závěrů této práce vyplývá, že problémů, s nimiž se tato oblast potýká, je celá řada. Zřejmě nejtvrdší oříšek je problém zákryvů v rozšířené realitě, který pravděpodobně obecně není vůbec řešitelný. Člověk samotný totiž není v některých případech schopen rozpoznat, který objekt ze dvou viditelných je blíže a který dále. Demonstrovat to lze na příkladů dvou vlaků, které jedou po dvou kolejích proti sobě – předtím, než se minou, není člověk často schopen rozpoznat který vlak jede na přední koleji a který na zadní. Problém zobrazení senzorů v rozšířené realitě avšak v konkrétním případě projektu SyRoTek řešitelný je, protože je znám model prostředí, v němž se roboty pohybují, a je známa i pozice robotu a kamery. Pro vizualizaci simulací robotických systémů existuje mnoho aplikací, z nichž některé byly jmenovány, a knihoven usnadňujících práci s rozšířenou realitou existuje také bezpočet (jmenujme např. Artoolkit). Nicméně systémů, které řeší vizualizaci robotických systémů pomocí rozšířené reality je poskrovnu, a takový systém, který by při tom řešil i problém zákryvů, není doposud znám žádný. Tuto mezeru se pokouší má práce zaplnit a v tom tkví zřejmě její největší přínos. Při realizaci práce se ztratilo poměrně hodně času pokusy implementovat vizualizaci senzorických dat pomocí jednoduchého vykreslování bez modelu prostředí. To se v pokročilé fázi práce ukázalo jako naprosto nedostačující, a proto bylo nutné značnou část práce udělat znovu. Z toho důvodu vizualizační komponenta neobsahuje některé pokročilé funkce, jako je třeba realizace konceptu virtuálních kamer (což měl být pohled na robotickou arénu z místa, kde žádná kamera není, a jejíž obraz je vzniklý složením obrazu z dvou jiných kamer) či alespoň základní grafické rozhraní umožňující konfiguraci komponenty (jako v případě ArDevu). Konfigurace samotná vyždaduje ještě další úpravy. Také vykreslení některých senzorických dat není ideální (jak je ostatně zmíněno v kapitole 7), a v komponentě je na několika místech prostor pro optimalizaci. Komponenta, ač je na to připravena, nebyla přenesena na jiný systém než Linux. V těchto oblastech (ale nejen v nich) se tedy skýtají možná rozšířená a lze jimi navázat v případné další práci. I přes některé její nedostatky však lze zodpovědně prohlásit, že práce splnila svůj účel a realizovaný program je plně připraven pro použití v systému SyRoTek.

45

46

KAPITOLA 8. ZÁVĚR

Literatura [1] Hri ’09: Proceedings of the 4th acm/ieee international conference on human robot interaction, 2009. General Chair-Scheutz„ Matthias and General Chair-Michaud„ François and Program Chair-Hinds„ Pamela and Program Chair-Scassellati„ Brian. [2] R. Azuma. A survey of augmented reality. Presence, 6:355–385, 1995. [3] M. O. Berger. Resolving occlusion in augmented reality: a contour based approach without 3d reconstruction. In CVPR ’97: Proceedings of the 1997 Conference on Computer Vision and Pattern Recognition (CVPR ’97), page 91, Washington, DC, USA, 1997. IEEE Computer Society. [4] G. Biggs, T. Collett, B. Gerkey, A. Howard, N. Koenig, J. Polo, R. Rusu, and R. Vaughan. The player project: Free software tools for robot and sensor applications. http://playerstage.sourceforge.net, 2009. [5] J.-Y. Bouguet. Camera calibration toolbox for matlab. caltech.edu/bouguetj/calib_doc/, 2008.

http://www.vision.

[6] F. Bruno, F. Caruso, L. De Napoli, and M. Muzzupappa. Visualization of industrial engineering data visualization of industrial engineering data in augmented reality. J. Vis., 9(3):319–329, 2006. [7] T. H. J. Collett and B. A. MacDonald. Developer oriented visualisation of a robot program. In HRI ’06: Proceedings of the 1st ACM SIGCHI/SIGART conference on Human-robot interaction, pages 49–56, New York, NY, USA, 2006. ACM. [8] J.-P. L. Dorval and J.-F. Lalonde. Augmented-reality navigation system for ground vehicles, May 2004. [9] J. Faigl, J. Chudoba, M. Kulich, K. Košnar, L. Přeučil, and P. Štěpán. Syrotek: V007.1 - návrh koncepce internetového přístupu k systému. http://lynx1.felk. cvut.cz/syrotek/, 2009. [10] J. Faigl, J. Chudoba, M. Kulich, R. Mázl, J. Pavlíček, L. Přeučil, and P. Štěpán. Syrotek: Systém pro robotickou tele-výuku. http://lynx1.felk.cvut.cz/syrotek/, 2009. [11] R. I. Hartley and A. Zisserman. Multiple View Geometry in Computer Vision. Cambridge University Press, ISBN: 0521540518, second edition, 2004. [12] Intel inc. and opensource contributors. Opencv. http://opencv.willowgarage. com/wiki/, 2009. 47

48

LITERATURA

[13] i. Microsoft. Microsoft robotics: enabling academic, hobbyist and commercial developers to easily create robotics applications across a wide variety of hardware. http://msdn.microsoft.com/en-us/robotics/default.aspx, 2008. [14] S. H. Najafi Shoushtari. Fast 3D Object Detection and Pose Estimation for Augmented Reality Systems. Dissertation, Technische Universität München, München, 2006. [15] T. Petříček. Roboti od lega a microsoft robotics studio. http://www.vyvojar.cz/ Articles/429-roboti-od-lega-a-microsoft-robotics-studio.aspx, 2006. [16] M. Sonka, V. Hlavac, and R. Boyle. Image Processing, Analysis, and Machine Vision. Thomson-Engineering, 2007. [17] J. Xavier. experimental robotics framework. http://erff.berlios.de/dokuwiki/ doku.php, 2009.

Dodatek A

Seznam použitých zkratek 2D Two-Dimensional 3D Three-Dimensional AJAX Asynchronous JavaScript and XML API Application Programming Interface Cg C for Graphics, jazyk od společnosti nVidia pro programování shader jednotek grafických karet FPS Frames Per Second GLSL OpenGL Shading Language GPL General Public License HTML HyperText Markup Language HTTP HyperText Transfer Protocol LGPL Lesser General Public License SVN Subversion, systém pro správu verzí TCP Transmission Control Protocol USB Universal Serial Bus

49

50

DODATEK A. SEZNAM POUŽITÝCH ZKRATEK

Dodatek B

Instalační a uživatelská příručka Zdrojové soubory na přiloženém DVD jsou připraveny pro sestavení programu, který demonstruje některé možnosti vizualizační komponenty. Pro úspěšné sestavení je vyžadován operační systém Linux s verzí jádra 2.6.20 a vyšší, a jsou zapotřebí následující knihovny (v devel verzi): • gstreamer-0.10 • gstreamer-base-0.10 • gstreamer-app-0.10 • irrlicht, verze 1.6-svn • playerc++ • opencv Sestavení probíhá pomocí utility SCons (http://www.scons.org/), kterou je také zapotřebí mít nainstalovanou. V době psaní této práce ještě nebyla k dispozici produkční verze knihovny Irrlicht 1.6, proto je nutné použít její nejnovější verzi z svn. Návod, jak tuto verzi přeložit je k dispozici v souboru README projektu, zdrojový kód knihovny můžeme získat například vykonáním příkazu svn co https://irrlicht.svn.sourceforge.net/svnroot/irrlicht irrlicht SCons využívá balíčkovací systém pkg_config, proto pravděpodobně bude nutné vývojové sestavení přidat do cesty, v níž pkg_config hledá popisy nainstalovaných balíčků. Ukázkový popis pro Irrlicht verze 1.6 svn je v adresáři irrlicht-video/pc, přidání této cesty do seznamu popisů pro pkg_config provedeme pomocí nastavení proměnné PKG_CONFIG_PATH: irrlicht-video/config> PKG_CONFIG_PATH=../pc irrlicht-video/config> export PKG_CONFIG_PATH 51

52

DODATEK B. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA

Překlad ukázkového programu spustíme vykonáním příkazu scons v adresáři src vizualizační komponenty. Tento příkaz provede sestavení a vytvoří spustitelný soubor s názvem streaming. Poté je nutné spustit server Player na lokálním počítači s parametrem konfiguračního souboru. K této práci je přiložen ukázkový konfigurační soubor simple.cfg pro Player, a to v adresáři config/playerstage. Server Player můžeme tedy spustit příkazem irrlicht-video/config> player simple.cfg v konzoli. Konfigurační soubor syrotek.cfg ukázkové aplikace se nachází v adresáři config, přičemž jeho volby jsou následující: • version Verze vizualizační komponenty (číslo) • robot_mesh Cesta k modelu robotu ve formátu 3DS (řetězec) • idle_background Cesta k obrázku (ve formátu jpg, tga nebo png), který bude zobrazen na pozadí scény, když není přehráváno video (řetězec) • add_logo Určuje, zda-li se má do horního levého rohu vykreslit obrázek loga (1 = ano, 0 = ne) • logo_path Cesta k obrázku (jpg, png nebo tga), který bude zobrazen jako logo (řetězec) • input_avi Soubor ve formátu mpeg4, který bude přehrán při spuštění přehrávání (řetězec) • save_to_file Určuje, zda-li má být dění na robotické scéně zaznamenáno do videosouboru out.avi v aktuálním adresáři (1 = ano, 0 = ne) • hidden_obstacles Seznam jmen překážek (identifikovaných pomocí atributu name v konfiguračním souboru) oddělených čárkou, které nebudou vykresleny Po úspěšném sestavení, spuštění serveru Player a kontrole konfigurace je možné spustit ukázkový program. Program očekává, že jeho konfigurace bude v podadresáři config, proto je jej možné spustit z konzole následující posloupností příkazů (předpokládáme, že jsme ve složce src): irrlicht-video/src> cd .. irrlicht-video> src/streaming Po spuštění aplikace bychom měli vidět okno, které zobrazuje pohled na model robotické arény. Pohybovat se v něm dá pomocí kurzorových šipek a pomocí pohybů myši; další funkční klávesy jsou následující: A Spustí přehrávání videa na pozadí S Zastaví přehrávání videa na pozadí P Zapne/vypne obraz v obraze V Vypne/zapne absolutní průhlednost překážek a robotu ESC Uvolní kurzor myši Okno lze zavřít klávesovou zkratkou ALT+F4.

Dodatek C

XML Schema souboru struktury arény <x s : s c h e m a i d=" arena " xmlns="" x m l n s : x s=" http: // www . w3 . org /2001/ XMLSchema " x m l n s : t n s=" http: // www . syrotek . org / arena " elementFormDefault=" qualified " > <x s : e l e m e n t name=" arena " > <xs:complexType> <x s : c h o i c e minOccurs="0" maxOccurs=" unbounded "> <x s : e l e m e n t name=" cuboid "> <xs:complexType> <x s : s e q u e n c e> <x s : e l e m e n t name=" center " minOccurs="0" maxOccurs=" unbounded " > <xs:complexType> < x s : a t t r i b u t e name="x" type=" xs:string " /> < x s : a t t r i b u t e name="y" type=" xs:string " /> < x s : a t t r i b u t e name="z" type=" xs:string " /> <x s : e l e m e n t name=" size " minOccurs="0" maxOccurs=" unbounded "> <xs:complexType> < x s : a t t r i b u t e name="x" type=" xs:string " /> < x s : a t t r i b u t e name="y" type=" xs:string " /> < x s : a t t r i b u t e name="z" type=" xs:string " /> <x s : e l e m e n t name=" color " minOccurs="0" maxOccurs=" unbounded "> <xs:complexType> < x s : a t t r i b u t e name="a" type=" xs:string " /> < x s : a t t r i b u t e name="r" type=" xs:string " /> < x s : a t t r i b u t e name="g" type=" xs:string " /> < x s : a t t r i b u t e name="b" type=" xs:string " /> <x s : e l e m e n t name=" rotation " minOccurs="0" maxOccurs=" unbounded "> <xs:complexType> < x s : a t t r i b u t e name="x" type=" xs:string " /> < x s : a t t r i b u t e name="y" type=" xs:string " /> < x s : a t t r i b u t e name="z" type=" xs:string " />

53

54

DODATEK C. XML SCHEMA SOUBORU STRUKTURY ARÉNY

< x s : a t t r i b u t e name=" type " type=" xs:string " /> < x s : a t t r i b u t e name=" name " type=" xs:string " />

Dodatek D

Obsah přiloženého DVD |-- Dalsi dokumentace - další dokumentace k~projektu (jiná, než tato práce) | |-- Doxygen - vygenerovaná doxygen dokumentace tříd | | ‘-- html - ve formátu html | |-- Individualni projekt - text individuálního projektu, na nějž tato práce navazuje | ‘-- Starsi prezentace - prezentace projektu v~jeho rané fázi |-- Kalibrace - soubory související s~kalibrací | |-- Kalibracni obrazky - snímky použité pro kalibrace | |-- Opravene obrazky - kalibrační snímky po opravě obrazových chyb | ‘-- Vysledne parametry - výsledné parametry kalibrace |-- Ostatni - blíže nezařazené | |-- 3D modely - 3D modely robotu pro 3D Studio Max | |-- Ukazkove fotky areny - několik fotek robotické arény | |-- cairo_render2 - předchůdce vizualizační komponenty, projekt v~C++ | | ‘-- src - zdrojové soubory | ‘-- test-player - aplikace pro testování cairo_render | ‘-- src - zdrojové soubory |-- Text prace - vlastní text práce | ‘-- Zdroj v~LaTeXu - zdroj pro latex | ‘-- figures - obrázky a schémata |-- Utility - aplikace použité v~projektu | |-- Irrlicht Scene Editor - editor scén pro knihovnu Irrlicht | ‘-- Matlab calibration toolbox - utilita pro kalibraci ‘-- Zdrojove kody programu - zdrojové kódy aplikace ‘-- irrlicht-video - kořenový adresář projektu |-- config - konfigurační soubory | ‘-- playerstage - ukázkové konfigurační soubory pro Player/Stage |-- html - stránka pro přístup k~obrázkům z~komponenty (webové rozhraní) ‘-- src - samotné zdrojové soubory v~C++ 55