Použití simulátoru Webots na vývoj aplikací pro robot Nao

CENTER FOR MACHINE PERCEPTION

Pouˇzit´ı simulátoru Webots na vývoj aplikac´ı pro robot Nao CZECH TECHNICAL UNIVERSITY IN PRAGUE

Bc. Martin Bresler [email protected]

CTU–CMP–2011–08

Lze z´ıskat na http://cmp.felk.cvut.cz/∼breslmar/DP Bresler.pdf Vedouc´ı: RNDr. Daniel Pr˚ uˇ sa, Ph.D.

Research Reports of CMP, Czech Technical University in Prague, No. 8, 2011 ISSN 1213-2365

´ PRCE DIPLOMOVA

2. srpna 2011

Published by Centrum strojového vn´ımán´ı, Katedra kybernetiky ˇ Fakulta elektrotechnická CVUT Technická 2, 166 27 Praha 6 fax: (02) 2435 7385, tel: (02) 2435 7637, www: http://cmp.felk.cvut.cz

Pouˇ zit´ı simul´ atoru Webots na v´ yvoj aplikac´ı pro robot Nao Bc. Martin Bresler 2. srpna 2011

vii

Podˇ ekov´ an´ı Chtˇel bych podˇekovat vˇsem, kteˇr´ı mi jak´ ymkoliv zp˚ usobem pomáhali s pˇr´ıpravou diplomové práce. Jedná se zejména o vedouc´ıho práce, RNDr. Daniela Pr˚ uˇsu, Ph.D., za rady a veˇskerou jeho pomoc. Dále bych chtˇel podˇekovat Dr. YeaShuanu Huangovi za pomoc na taiwanské univerzitˇe CHU, kde jsem na diplomové práci posledn´ı semestr pracoval. V neposledn´ı ˇradˇe dˇekuji sv´ ym pˇrátel˚ um a spolubydl´ıc´ım za podporu a trpˇelivost. ix

Abstract The topic of this diploma thesis is to assess the suitability of robotic simulator Webots for Nao robot applications implementation. The thesis includes solutions to few tasks which deal with the robot spatial orientation. Their focus corresponds to the objectives of HUMAVIPS project. Two applications extending the robot’s navigation abilities were proposed and implemented. First one allows the robot to track a set of special graphical landmarks creating a path. Second one brings a possibility to detect a position of obstacles marked by graphical symbols. From detected objects it creates a map in which it can find the shortest path. During the applications creation the overall usefulness and benefit of the simulator were evaluated. The evaluation is mainly aimed to the possibility of transferring an application on a real robot. Some problems caused by using the simulator were revealed. The thesis deals with them as well.

Abstrakt Tématem práce je zhodnocen´ı vhodnosti vyuˇzit´ı robotického simulátoru Webots pˇri v´ yvoji obsluˇzn´ ych aplikac´ı pro robota Nao. Souˇca´st´ı práce má b´ yt ˇreˇsen´ı nˇekolika u ´loh, které by se vˇenovaly prostorové orientaci robota. Jejich zamˇeˇren´ı by mˇelo alespoˇ n rámcovˇe korespondovat s c´ıli projektu HUMAVIPS. Byly navrˇzeny a implementovány dvˇe aplikace rozˇsiˇruj´ıc´ı moˇznosti navigace robota v prostoru. Prvn´ı z nich umoˇzn ˇuje robotovi sledovat sérii na zemi um´ıstˇen´ ych znaˇcek, jeˇz tvoˇr´ı stopu. Druhá pˇrináˇs´ı moˇznost detekovat pozici pˇrekáˇzek oznaˇcn´ ych speciáln´ımi znaˇckami. Z nalezen´ ych objekt˚ u je vytváˇrena mapa, ve které je aplikace schopna nalézt nejkratˇs´ı cestu. Behˇem vytváˇren´ı aplikac´ı byl hodnocen pˇr´ınos a pouˇzitelnost simulátoru. D˚ uraz byl kladen zejména na pˇrenositelnost aplikace ze simulátoru na skuteˇcného robota. Bylo odhaleno nˇekolik problém˚ u, jeˇz pouˇz´ıván´ı simulátoru pˇrináˇs´ı. Práce se zab´ yvá rovnˇeˇz jejich ˇreˇsen´ım.

xi

Obsah Seznam pouˇ zit´ ych zkratek

4

Seznam obr´ azk˚ u

4

Seznam tabulek

4

´ 1. Uvod

6

2. Obecn´ a charakteristika simul´ atoru Webots 2.1. Roboti . . . . . . . . . . . . . . . . . . . . . . . 2.2. Svˇet . . . . . . . . . . . . . . . . . . . . . . . . 2.3. Podpora robota Nao . . . . . . . . . . . . . . . 2.3.1. Nedostupné funkce v simulátoru Webots

. . . .

. . . .

´ 3. Uloha 1 - Stopovan´ a 3.1. Z´ıskan´ı obrazu z kamery . . . . . . . . . . . . . . . 3.2. Zpracován´ı obrazu . . . . . . . . . . . . . . . . . . 3.3. V´ ypoˇcet polohy znaˇcky . . . . . . . . . . . . . . . . 3.4. Pohyb robota po trase . . . . . . . . . . . . . . . . 3.4.1. Popis algoritmu . . . . . . . . . . . . . . . . 3.4.2. Popis problému s ch˚ uz´ı robota v simulátoru ˇ 3.4.3. Reˇsen´ı problému s ch˚ uz´ı robota v simulátoru 3.5. Zhodnocen´ı dosaˇzen´ ych v´ ysledk˚ u . . . . . . . . . . 3.5.1. Pˇresnost detekce znaˇcek . . . . . . . . . . . 3.5.2. Hodnocen´ı simulátoru . . . . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

. . . . . . . . . .

. . . .

8 9 9 10 11

. . . . . . . . . .

14 14 15 16 19 19 20 20 22 23 23

´ 4. Uloha 2 - Bludiˇstˇ e 25 4.1. Podoba bludiˇstˇe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2. Struktura aplikace a pouˇzité knihovny . . . . . . . . . . . . . . . 26 4.3. Souˇradn´ y systém a pˇresná detekce polohy pˇrekáˇzek . . . . . . . . 27 4.3.1. Detekce znaˇcky pomoc´ı knihovny ARToolKit . . . . . . . . 28 4.3.2. V´ ypoˇcet projekˇcn´ı matice pomoc´ı algoritmu P3P . . . . . 28 4.3.3. V´ ypoˇcet polohy bod˚ u znaˇcky v souˇradném systému robota (relativn´ı pozice) . . . . . . . . . . . . . . . . . . . . . . . 29 4.3.4. V´ ypoˇcet pozice rohov´ ych bod˚ u bedny (v p˚ udorysu) v souˇradném systému mapy . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.3.5. Zpracován´ı nové informace o poloze pˇrekáˇzky . . . . . . . 31 4.4. SLAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.4.1. Aktualizace stavu pomoc´ı odometrick´ ych dat . . . . . . . . 33 4.4.2. Aktualizace stavu pomoc´ı znovu detekovan´ ych znaˇcek . . . 34 1

4.4.3. Pˇridán´ı novˇe detekovan´ ych znaˇcek do systému 4.5. Vizualizace mapy a hledán´ı nejkratˇs´ı cesty . . . . . . 4.5.1. Zp˚ usob vykreslován´ı mapy . . . . . . . . . . . 4.5.2. V´ ypoˇcet trasy pˇri procházen´ı bludiˇstˇe . . . . . 4.6. Ovládán´ı robota a jeho pohyb v bludiˇsti . . . . . . . 4.6.1. Rozhl´ıˇzen´ı . . . . . . . . . . . . . . . . . . . . 4.6.2. Zadán´ı c´ılové lokace uˇzivatelem . . . . . . . . 4.6.3. Automatické mapován´ı . . . . . . . . . . . . . 4.7. Zhodnocen´ı dosaˇzen´ ych v´ ysledk˚ u . . . . . . . . . . . 4.7.1. Pˇresnost mapován´ı . . . . . . . . . . . . . . . 4.7.2. Hodnocen´ı simulátoru . . . . . . . . . . . . .

. . . . . . . . . . .

35 35 36 37 39 39 39 39 40 40 42

5. Shrnut´ı probl´ em˚ u se simul´ atorem Webots 5.1. Problémy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1. Synchronizace kontroleru NaoQi a simulátoru Webots . . . 5.1.2. Pˇrenos obrazu . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.3. Nepodporované systémy robota Nao v simulátoru Webots . 5.1.4. Nedostupné funkce v simulátoru Webots verze EDU . . . . 5.2. Evaluace prostˇred´ı . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1. Zmˇena parametr˚ u scény . . . . . . . . . . . . . . . . . . . 5.2.2. Ovládán´ı kamery . . . . . . . . . . . . . . . . . . . . . . .

44 44 44 45 45 45 46 46 47

6. Z´ avˇ er

48

A. Obsah pˇriloˇ zen´ eho DVD

50

B. N´ avod ke kompilaci u ´loh

51

C. Seznam kl´ avesov´ ych zkratek k aplikaci Bludiˇstˇ e

54

Literatura

55

2

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

Seznam pouˇ zit´ ych zkratek Zkratky vyskytuj´ıc´ı se v diplomové práci. 2D 3D CW CCW GPS ID SDK SLAM VRML

Two Dimension(al) Three Dimension(al) Clockwise Counterclockwise Global Positioning System Identification Software Development Kit Simulatneous Localization And Mapping Virtual Reality Modeling Language

3

Seznam obr´ azk˚ u 2.1. Strom scény, kter´ y obsahuje prototypov´ y soubor NaoV3R, pˇredstavuj´ıc´ı robota Nao. Na obrázku je vidˇet, které parametry je moˇzné mˇenit pˇr´ımo v simulátoru. . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. 3.2. 3.3. 3.4. 3.5. 4.1. 4.2. 4.3. 4.4. 4.5.

4

Pˇrehled pˇripraven´ ych znaˇcek pro detekci pomoc´ı ARToolKitu . . . Pˇriˇrazen´ı svˇetov´ ych souˇradnic roh˚ um a stˇredu znaˇcky . . . . . . . Znázornˇen´ı polohy kamery a znaˇcky . . . . . . . . . . . . . . . . . Znázornˇen´ı polohy znaˇcky v obraze . . . . . . . . . . . . . . . . . Nástroje ke kontrolován´ı synchronizace dostupné v simulátoru Webots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16 17 18 19

Sn´ımek bludiˇstˇe pro testován´ı a demonstraci aplikace . . . . . . . Hlavn´ı okno aplikace obsahuj´ıc´ı menu a vizualizaci mapy . . . . . Formuláˇr k nastaven´ı parametr˚ u pˇri pˇripojován´ı aplikace k robotu Grafické vyjádˇren´ı vztah˚ u bˇehem projekce . . . . . . . . . . . . . Vizualizace mapy . . . . . . . . . . . . . . . . . . . . . . . . . . .

25 27 27 29 37

21

Seznam tabulek 3.1. Srovnán´ı skuteˇcn´ ych a namˇeˇren´ ych vzdálenost´ı markeru od robota bˇehem testován´ı pˇresnosti algoritmu. . . . . . . . . . . . . . . . .

23

4.1. V´ ysledky testován´ı pˇresnosti detekce beden vyjádˇreny jako vzdálenost stˇredu detekované bedny od správné pozice v závislosti na vzdálenosti bedny od robota a u ´hlu jej´ıho natoˇcen´ı v˚ uˇci robotovi. . . . . . . . 41 4.2. V´ ysledky testován´ı pˇresnosti detekce beden vyjádˇreny jako odchylka natoˇcen´ı bedny v závislosti na vzdálenosti bedny od robota au ´hlu jej´ıho natoˇcen´ı v˚ uˇci robotovi. . . . . . . . . . . . . . . . . . 41

5

´ 1. Uvod Robot Nao firmy Aldebaran Robotics je mal´ y humanoidn´ı robot, se ˇsirokou ˇskálou vyuˇzit´ı. Jedná se o nejvyuˇz´ıvanˇejˇs´ıho robota, urˇceného pro akademické u ´ˇcely. Spoleˇcnost Aldebaran Robotics se jeho prostˇrednictv´ım snaˇz´ı vytvoˇrit standard, kter´ y by mohla vyuˇz´ıvat vˇetˇsina student˚ u vˇsech r˚ uzn´ ych u ´rovn´ı studuj´ıc´ıch robotiku. Sami studenti by mˇeli také pomáhat pˇri jeho v´ yvoji. Zdokonalován´ım robota se zab´ yvá celá ˇrada svˇetov´ ych univerzit, které také spolupracuj´ı na spoleˇcn´ ych projektech.

ˇ Jedn´ım z nejd˚ uleˇzitˇejˇs´ıch projekt˚ u, kterého se u ´ˇcastn´ı i CVUT v Praze, je program HUMAVIPS [1], jenˇz má za c´ıl zdokonalovat zejména softwarové vybaven´ı robota. Hlavn´ım c´ılem projektu je vytvoˇrit program, kter´ y by robotovi umoˇzn ˇoval interakci s lidmi. Pˇr´ıkladem takové interakce m˚ uˇze b´ yt upoutáván´ı pozornosti na veletrz´ıch nebo pomoc star´ ym lidem. Nao by mˇel b´ yt schopen dˇelat star´ ym lidem spoleˇcnost a usnadˇ novat jim napˇr´ıklad práci s elektronickou poˇstou, kterou je schopen pˇredˇc´ıtat. Aby mohl Nao tohoto c´ıle dosáhnout, je vybaven celou ˇradou senzor˚ u, pohybov´ ych a indikaˇcn´ıch prvk˚ u. Jeho hardwarové vybaven´ı je detailnˇe popsáno v oficiáln´ı dokumentaci [14, advanced/hardware]. Robot Nao je univerzáln´ım robotem, kter´ y si najde m´ısto nejen ve ˇskolách. Snahou jeho tv˚ urc˚ u je prosadit robota také na mezinárodn´ıch soutˇeˇz´ıch, kde spolu zápol´ı roboti vˇsech moˇzn´ ych v´ yrobc˚ u v r˚ uzn´ ych discipl´ınách. Jedn´ım takov´ ym ´ projektem, v nˇemˇz je robot Nao zapojen, je projekt RoboCup [2]. Uˇcast v tomto projektu pˇrináˇs´ı robotovi popularitu a zajiˇst’uje mu zájem nadˇsenc˚ u, kteˇr´ı také 6

pomáhaj´ı s jeho v´ yvojem. Souˇca´st´ı projektu je mimo jiné kategorie Standard Platform League, ve které soupeˇr´ı celé muˇzstvo robot˚ u v kopané. V této discipl´ınˇe se m˚ uˇze vyuˇz´ıvat jenom jeden konkrétn´ı typ robota a v´ yvojáˇri zdokonaluj´ı pouze tzv. kontrolery, které roboty ˇr´ıd´ı. Oficiáln´ım robotem byl do roku 2008 robot Aibo firmy Sony. Od roku 2008 se oficiáln´ım robotem stal Nao, coˇz svˇedˇc´ı o jeho velké vˇsestrannosti a dobrém designu. Pokud by chtˇel nˇekdo vyv´ıjet obsluˇznou aplikaci pro robota Nao, je nutné, aby ho mˇel k dispozici. To nen´ı ovˇsem vˇzdy moˇzné, protoˇze robot je pomˇernˇe drah´ y. K dispozici je vˇetˇsinou jeden nebo dva exempláˇre v laboratoˇri. Pokud chce tedy nˇekdo pracovat s robotem, aniˇz by k nˇemu mˇel stál´ y pˇr´ıstup (napˇr. se u nˇej stˇr´ıdá v´ıce lid´ı), je v´ yhodné pouˇz´ıt simulátor. V souˇcasné dobˇe existuj´ı dva robotické simulátory nab´ızej´ıc´ı podporu robota Nao. Jedná se o simulátor Webots firmy Cyberbotics [4] a simulátor Miscrosoft Robotics Developer Studio [3]. Prvn´ı z jmenovan´ ych nab´ız´ı silnˇejˇs´ı podporu robota Nao. Spoleˇcnost Cyberbotics dokonce provozuje virtuáln´ı verzi jiˇz zm´ınˇené kopané, která se jmenuje RobotStadium. V´ yvojáˇri d´ıky tomu mohou své kontrolery testovat v simulátoru, jak obstoj´ı v souboji s kontrolery jin´ ych t´ ym˚ u. Tyto virtuáln´ı zápasy prob´ıhaj´ı kaˇzd´ y t´ yden. V´ yvojáˇr˚ um staˇc´ı do uzávˇerky uploadovat své kontrolery a t´ım jsou automaticky zapsáni do soutˇeˇze. Na webov´ ych stránkách discipl´ıny RobotStadium jsou poté zveˇrejnˇeny v´ ysledky a je moˇzné sledovat videozáznamy vˇsech utkán´ı, která prob´ıhaj´ı pˇr´ımo v simulaˇcn´ım prostˇred´ı. Pˇr´ınos simulátoru tedy tkv´ı i v tom, ˇze je moˇzné robota, potaˇzmo jeho kontroler, testovat rychleji neˇz v reálu. Nav´ıc je testován´ı provádˇeno ve virtuáln´ım prostˇred´ı, kde m˚ uˇzeme nastolit podm´ınky, jak´ ych bychom v reálu dosahovali tˇeˇzko nebo s vyˇsˇs´ımi náklady. Pro tuto diplomovou práci byl zvolen právˇe simulátor Webots a to z toho d˚ uvodu, ˇze nab´ız´ı lepˇs´ı moˇznosti simulace robota Nao. C´ılem této práce je zhodnotit vhodnost simulátoru Webots pˇri v´ yvoji obsluˇzn´ ych aplikac´ı pro robota Nao. Souˇca´st´ı práce bude ˇreˇsen´ı nˇekolika menˇs´ıch u ´loh, které budou demonstrovat moˇznosti simulátoru, robota a jejich vzájemného propojen´ı. Téma tˇechto u ´loh by mˇelo alespoˇ n rámcovˇe korespondovat s c´ıli projektu HUMAVIPS. Jejich zamˇeˇren´ı bude souviset s prostorovou orientac´ı a navigac´ı robota, jeˇz je pˇri interakci s lidmi také velmi d˚ uleˇzitá. Bˇehem práce budu brát zˇretel zejména na to, do jaké m´ıry bude v´ ysledná obsluˇzná aplikace vytvoˇrená s pomoc´ı simulátoru pouˇzitelná pro skuteˇcného robota. Souˇcasnˇe v práci budu popisovat veˇskeré klady a zápory simulátoru a veˇskerá u ´skal´ı, která práce se simulátorem Webots pˇrináˇs´ı. Na zaˇca´tku uvedu obecné vlastnosti simulátoru. Aˇckoliv se v technické literatuˇre slovo ”robot” ˇcasto skloˇ nuje jako neˇzivotné, já budu ve své práci pouˇz´ıvat ˇzivotné skloˇ nován´ı podle vzoru pán. D˚ uvodem je fakt, ˇze Nao je humanoidn´ı robot urˇcen´ y k interakci s lidmi a neˇzivotné skloˇ nován´ı mi v takovém pˇr´ıpadˇe nepˇripadá na m´ıstˇe.

7

2. Obecn´ a charakteristika simul´ atoru Webots V této kapitole uvedu základn´ı informace o tom, jak simulátor vypadá a jak se pouˇz´ıvá. Detailn´ı informace o interface a veˇsker´ ych funkc´ıch jsou obsaˇzeny v referenˇcn´ı pˇr´ıruˇcce [5]. Simulátor Webots je neustále se vyv´ıjej´ıc´ı software. Tato práce popisuje simulátor ve verzi 6.3.1. Prvn´ı d˚ uleˇzitou vˇec´ı je, jak simulátor spustit. Licenˇcn´ı systém a postup, jak Webots zprovoznit, je k nalezen´ı v pr˚ uvodci [6, sekce 1.3]. K vypracován´ı diplomové práce mi byl poskytnut Webots 6 EDU floating lincense, coˇz znamená, ˇze mám k dispozici hardwarov´ y kl´ıˇc, kter´ y umoˇzn ˇuje spustit floating license server. Pokud chci spustit Webots, mus´ım se k tomuto serveru pˇripojit. Je moˇzné se k vlastn´ımu serveru pˇripojovat pˇres localhost. V praxi je moˇzné spustit floating license server na nˇejakém serveru a kdo bude potˇrebovat, m˚ uˇze se k nˇemu pˇripojit pomoc´ı internetu. Hardwarov´ y kl´ıˇc, kter´ y mám k dispozici, nese pouze jednu licenci, ale i tak by mohlo stˇr´ıdavˇe vyuˇz´ıvat Webots v´ıce uˇzivatel˚ u. Nev´ yhodou ovˇsem je, ˇze mus´ı b´ yt uˇzivatel stále online. Zkratka EDU znamená ˇskoln´ı verzi, která nepodporuje nˇekteré funkce, napˇr. tˇr´ıdu supervisor [6, sekce 6.2]. Na zaˇcátku práce se simulátorem je tˇreba vytvoˇrit projekt, kter´ y má následuj´ıc´ı adresáˇrovou strukturu, jeˇz mus´ı b´ yt dodrˇzována: • controllers Obsahuje soubory kontroler˚ u jednotliv´ ych robot˚ u. • motions Soubory definuj´ıc´ı konkrétn´ı pohyby robot˚ u. • plugins Obsahuje r˚ uzné pluginy (napˇr. pro podporu fyziky apod.). • protos Prototypové soubory robot˚ u. – textures Soubory s texturami pro roboty. • videos V simulátoru natoˇcené video soubory. • worlds Soubor s VRML modelem svˇeta. – textures Pouˇzité textury ve svˇetˇe. Simulátor je vybaven pr˚ uvodcem, kter´ y vytvoˇr´ı projekt vˇcetnˇe adresáˇrové struktury. Projekt nemus´ı nˇekteré vˇeci obsahovat a z toho d˚ uvodu m˚ uˇze nˇekter´ y adresáˇr chybˇet. Základem projektu jsou roboti a scéna. Tyto dvˇe vˇeci by tedy chybˇet nemˇely. 8

2.1. Roboti

2.1. Roboti Simulátor Webots nen´ı urˇcen v´ yhradnˇe pro simulaci robota Nao. Simulátor podporuje celou ˇradu jin´ ych robot˚ u r˚ uzn´ ych v´ yrobc˚ u a umoˇzn ˇuje vytváˇret roboty nové. D´ıky této moˇznosti je simulátor vhodn´ y do ˇskol, kde mohou studenti zaˇc´ınat od robot˚ u velmi jednoduch´ ych, vlastnoruˇcnˇe vyroben´ ych. Pro kaˇzdého robota je moˇzné pˇr´ımo v simulátoru psát obsluˇznou aplikaci, tzv. kontroler. Kontroler m˚ uˇze ovládat jednotlivé motory robota, m˚ uˇze zpracovávat data ze senzor˚ u a celkovˇe robota oˇzivit. Jednoduchost vytváˇren´ı robot˚ u a psan´ı jejich kontroler˚ u je patrná z tutoriálu [6, kapitola 7]. Simulátor podporuje celou ˇradu programovac´ıch jazyk˚ u, ve kter´ ych lze kontrolery programovat. Nejpouˇz´ıvanˇejˇs´ım je C++ a Java, ale nab´ız´ı i Python nebo MATLAB. Jakmile je robot vytvoˇren, je moˇzné ho uloˇzit do souboru .proto (tzv. prototypov´ y soubor). Jedná se o typ souboru, ve kterém jsou uloˇzeny také prototypy vˇsech jiˇz existuj´ıc´ıch robot˚ u, mezi které patˇr´ı i Nao. V souboru je uloˇzena jeho podoba a funkˇcnost. Pokud tedy chceme s nˇejak´ ym robotem pracovat, staˇc´ı nám naˇc´ıst jeho prototypov´ y soubor a pˇriˇradit mu kontroler. Samozˇrejmˇe je moˇzné modifikovat soubory vˇsech jiˇz existuj´ıc´ıch robot˚ u, takˇze lze upravovat i podobu robota Nao. Lze tak napˇr´ıklad mˇenit jeho barvu, coˇz se m˚ uˇze hodit v pˇr´ıpadˇe, kdy budeme m´ıt ve scénˇe v´ıce robot˚ u a budeme je cht´ıt rozliˇsit.

2.2. Svˇ et Pokud chceme robota jakkoliv testovat, je potˇreba ho zasadit do virtuáln´ıho svˇeta. Pro jeho popis vyuˇz´ıvá Webots rozˇs´ıˇrené VRML V2.0 [7] nazvané VRML SIM V6.0. Svˇet je tak moˇzné tvoˇrit pomoc´ı libovolného VRML editoru, nebo dokonce psát pˇr´ımo v textovém editoru. Simulátor je ovˇsem vybaven vlastn´ım editorem scény, kter´ y samozˇrejmˇe podporuje i rozˇs´ıˇren´ı jazyka VRML SIM V6.0. Editor je pˇredstavován stromem scény, do kterého lze vkládat nové uzly a stávaj´ıc´ı uzly mˇenit. Snadno lze tak vytvoˇrit vhodnou testovac´ı scénu pro vlastn´ıho robota. Roboti jsou v prototypov´ ych souborech také popisováni jazykem VRML SIM V6.0 a simulátor umoˇzn ˇuje nˇekteré parametry obsaˇzené v tˇechto souborech upravovat pˇr´ımo pomoc´ı stromu scény, takˇze napˇr´ıklad jiˇz zm´ınˇenou zmˇenu barvy robota lze provést pˇr´ımo v simulátoru a nen´ı nutné ruˇcnˇe pˇrepisovat prototypov´ y soubor. Parametry, které bude moˇzné mˇenit v simulátoru, jsou uvedeny vˇzdy na zaˇcátku prototypového souboru. Obrázek 2.1 ilustruje, jak vypadá strom scény a parametry, které lze modifikovat pˇr´ımo v simulátoru. 9

2. Obecná charakteristika simulátoru Webots

Obr´ azek 2.1. Strom scény, kter´ y obsahuje prototypov´ y soubor NaoV3R, pˇredstavuj´ıc´ı robota Nao. Na obr´ azku je vidˇet, které parametry je moˇzné mˇenit pˇr´ımo v simulátoru.

2.3. Podpora robota Nao Robot Nao je uloˇzen v prototypovém souboru NaoV3R.proto. Stejnˇe jako Cyberbotics vydává nové verze simulátoru, tak ˇcas od ˇcasu uveˇrejn´ı novou verzi tohoto souboru. Typicky k tomu docház´ı, pokud dojde k nˇejakému v´ yvoji na robotovi Nao. Kontroler k robotu Nao lze psát rovnou v simulátoru na n´ızké u ´rovni, kdy kontroler pˇr´ımo ovládá polohy kloub˚ u a sám zpracovává informace ze senzor˚ u. Vytváˇren´ı takového kontroleru m˚ uˇze b´ yt zdlouhavé, kontroler je jedno´ uˇcelov´ y a nen´ı moˇzné ho pˇr´ımo pouˇz´ıt na reálném robotovi. Reáln´ y robot ˇr´ıd´ı framework NaoQi, kter´ y nab´ız´ı celou ˇradu funkc´ı a pˇredstavuje souˇcasnˇe interface, pˇres kter´ y je moˇzné se k robotovi pˇripojit. Pokud bychom chtˇeli pouˇz´ıvat kontroler vytvoˇren´ y v simulátoru, museli bychom NaoQi nahradit a t´ım bychom se pˇripravili o spoustu funkc´ı, které nám m˚ uˇze nab´ıdnout. Pˇresto se takto vytvoˇrené kontrolery pouˇz´ıvaj´ı napˇr. v soutˇeˇzi RobotStadium, protoˇze jsou jednoduché a rychlé. Pˇr´ıklady takov´ ych kontroler˚ u je moˇzné nalézt po instalaci simulátoru ve sloˇzce \projects\contests\robotstadium\controllers. Simulátor Webots je ovˇsem vybaven speciáln´ım kontrolerem nazvan´ ym naoqi for webots, kter´ y je univerzáln´ı, je open-source a pokud chceme robota ovládat, mus´ıme pro nˇej napsat obsluˇznou aplikaci. Jeho kódy a CMake projekt je um´ıstˇen ve sloˇzce \projects\robots\nao\controllers\naoqi for webots. Postup, jak jej zkompilovat a pˇripravit k pouˇzit´ı, je moˇzné nalézt v pˇriloˇzeném ”readme” souboru nebo na stránkách spoleˇcnosti [8]. Bˇehem práce jsem byl vˇsak nucen modifikovat jeho 10

2.3. Podpora robota Nao zdrojové kódy. Jsou uloˇzeny na pˇriloˇzeném DVD ve sloˇzce \Projekty\naoqi for webots. Aby vˇse správnˇe fungovalo, je tˇreba je ke kompilaci pouˇz´ıt. Postup vˇsak jinak z˚ ustává stejn´ y. Kontroler naoqi for webots vyuˇz´ıvá simulaˇcn´ı rozhran´ı kontroleru NaoQi. To nemus´ı bˇeˇzet pouze na skuteˇcném robotovi, ale také virtuálnˇe na poˇc´ıtaˇci. Pˇri spuˇstˇen´ı simulace se tedy spust´ı NaoQi a spoj´ı se s naoqi for webots, kter´ y nahrazuje skuteˇcného robota. Naoqi for webots je pˇr´ımo spojen se simulátorem, z´ıskává tak informace ze vˇsech senzor˚ u a neustále je pˇredává NaoQi, kter´ y informace zpracuje a vrac´ı informace o své reakci. Obsluˇzná aplikace, kterou v´ yvojáˇr vytvoˇr´ı, se pˇripojuje k NaoQi, jak by tomu bylo i pˇri práci se skuteˇcn´ ym robotem. Kontroler Naoqi for webots tak svou funkc´ı pˇripom´ıná sp´ıˇse interface. Tento postup umoˇzn ˇuje vyuˇzit´ı funkc´ı NaoQi, viz dokumentace [14, API]. Bohuˇzel simulaˇcn´ı rozhran´ı NaoQi neumoˇzn ˇuje vyuˇz´ıt veˇskeré funkce, ˇc´ımˇz jsme pˇri práci se simulátorem znaˇcnˇe omezeni. Samotn´ y model robota postrádá nˇekteré prvky (napˇr. mikrofony a reproduktory). S t´ım souvis´ı absence funkc´ı pracuj´ıc´ıch se zvukem v simulaˇcn´ım rozhran´ı.

2.3.1. Nedostupn´ e funkce v simul´ atoru Webots Pˇri práci se simulátorem Webots bude v´ yvojáˇr omezen t´ım, ˇze nem˚ uˇze pouˇz´ıt vˇsechny funkce, které skuteˇcn´ y robot nab´ız´ı. Nˇekteré nejsou dostupné z toho d˚ uvodu, ˇze nejsou v˚ ubec ”hardwarovˇe” podporovány, coˇz znamená, ˇze prototyp robota nemá vymodelováno nˇejaké zaˇr´ızen´ı. V tomto pˇr´ıpadˇe je zcela nemoˇzné danou vˇec simulovat, aniˇz by se mˇenil prototypov´ y soubor robota. Druh´ ym d˚ uvodem m˚ uˇze b´ yt fakt, ˇze funkce je souˇcást´ı NaoQi, které nen´ı open-source a danou funkci nezpˇr´ıstupˇ nuje simulaˇcn´ımu rozhran´ı. V takovém pˇr´ıpadˇe je moˇzné vytvoˇrit vlastn´ı funkci, která odvád´ı podobnou práci. V této kapitole uvád´ım v´ ypis základn´ıch modul˚ u, které nejsou v simulátoru Webots dostupné. Seznam veˇsker´ ych modul˚ u vˇcetnˇe jejich detailn´ıho popisu, které NaoQi API nab´ız´ı, je moˇzné nalézt v dokumentaci [14, API]. Nepodporovan´ a zaˇr´ızen´ı v modelu robota Nao • Mikrofony a reproduktory Simulátor v˚ ubec nepracuje se zvukem, takˇze nen´ı moˇzné do scény pˇridat ˇza´dn´ y zdroj zvuku. Z toho d˚ uvodu nen´ı model robota vybaven mikrofony ani reproduktory. Bohuˇzel tak nen´ı moˇzné vyuˇz´ıt celou ˇradu funkc´ı, které se zvukem pracuj´ı. Patˇr´ı mezi nˇe pˇredevˇs´ım syntetizátor a rozpoznáván´ı ˇreˇci. Simulátor tedy nen´ı v ˇzádném pˇr´ıpadˇe vhodn´ y pro v´ yvojáˇre, kteˇr´ı chtˇej´ı vyv´ıjet aplikace zaloˇzené na práci s audio daty. Konkrétnˇe nen´ı moˇzno pracovat s následuj´ıc´ımi moduly: – ALAudioDevice – ALAudioPlayer – ALAudioSourceLocalization – ALSoundDetection – ALSpeechRecognition – ALTextToSpeech 11

2. Obecná charakteristika simulátoru Webots • LED Model robota nemá vymodelovány ˇzádné LED, které jsou vyuˇz´ıvány k indikaci stavu robota a k vyjadˇrován´ı jeho ”pocit˚ u” pˇri interakci s lidmi. V simulátoru tedy nen´ı dostupn´ y modul: – ALLeds • IR diody a Bluetooth Model robota nen´ı vybaven IR diodami a zaˇr´ızen´ım bluetooth, které jsou pouˇz´ıvany ke komunikaci mezi dvˇema roboty nebo k zadaván´ı pˇr´ıkaz˚ u. Nejsou tedy dostupné tyto moduly: – ALBluetooth – ALInfrareds • Prsty a tlaˇ c´ıtka na hlavˇ e Model robota nemá vymodelovány prsty a tlaˇc´ıtka na hlavˇe. Nen´ı tak moˇzné v simulátoru vyv´ıjet aplikaci, která by se snaˇzila o to, aby robot nˇeco uchopil. Tlaˇc´ıtka na hlavˇe jsou vyuˇz´ıvána k ovládán´ı robota ˇci k aktivaci pˇredem pˇripraven´ ych funkc´ı. V simulátoru tedy nemaj´ı v podstatˇe ˇza´dn´ y smysl. Tento fakt nezabraˇ nuje pouˇz´ıván´ı ˇza´dného modulu. Pouze je ovlivnˇen modul ALMotion, ve kterém nen´ı moˇzné pracovat s následuj´ıc´ımi klouby: – – – –

LWristYaw LHand RWristYaw RHand

Nepodporovan´ e moduly v simulaˇ cn´ım rozhran´ı NaoQi • • • • • • •

ALFaceDetection ALFaceTracking ALLandMarkDetection ALRedBallDetection ALRedBallTracker ALVisionRecognition ALVisionToolbox

Veˇskeré moduly, které nejsou podporovány simulaˇcn´ım rozhran´ım kontroleru NaoQi, souvis´ı se zpracován´ım obrazu. Pˇri prác´ı se skuteˇcn´ ym robotem dokáˇzou tyto funkce znaˇcnˇe ulehˇcit práci. Pˇri práci se simulátorem nic nebrán´ı v´ yvojáˇri vytvoˇrit vlastn´ı funkce, které by urˇcit´ ym zp˚ usobem nahrazovaly ty vestavˇené. Pˇri pˇrenosu obsluˇzné aplikace na skuteˇcného robota je pak moˇzné funkce nahradit zpˇet tˇemi vestavˇen´ ymi.

12

2.3. Podpora robota Nao Ze seznamu zaˇr´ızen´ı a modul˚ u, které v simulátoru Webots nelze pouˇz´ıt, je patrné, ˇze v´ yvojáˇr pracuj´ıc´ı se simulátorem je znaˇcnˇe omezen. Simulátor se v podstatˇe nejv´ıce hod´ı k vytváˇren´ı aplikac´ı, které vyuˇz´ıvaj´ı obraz z´ıskan´ y z kamery, pˇr´ıpadnˇe data z ultrazvukov´ ych senzor˚ u, a vytváˇr´ı nˇejakou choreografii. Takovou aplikac´ı je napˇr´ıklad zm´ınˇen´ y fotbal. Simulátor se naopak nehod´ı k vytváˇren´ı aplikac´ı, které maj´ı za c´ıl interakci robota s lidmi, protoˇze tam jsou velmi d˚ uleˇzité drobné detaily, jak´ ymi jsou LED, zvuky, pohyb prst˚ u a podobnˇe.

13

´ 3. Uloha 1 - Stopovan´ a C´ılem této u ´lohy je navrhnout, implementovat a v simulátoru Webots odzkouˇset obsluˇznou aplikaci robota Nao, která by umoˇzn ˇovala, aby robot sledoval sérii znaˇcek um´ıstˇen´ ych na zemi. Pˇredpokládá se, ˇze ze znaˇcek by byla sestavena bezpeˇcná trasa, která by dovedla robota z m´ısta A do m´ısta B, pˇr´ıpadnˇe i zpˇet v opaˇcném smˇeru. Robot bude postupovat tak, ˇze se bude rozhl´ıˇzet a hledat znaˇcku. Ty maj´ı své poˇrad´ı a robot bude hledat vˇzdy tu, která je na ˇradˇe. V okamˇziku, kdy pˇr´ısluˇsnou znaˇcku nalezne, vypoˇc´ıtá jej´ı polohu a vydá se jej´ım smˇerem. Jakmile doraz´ı na znaˇcku, zaˇcne hledat dalˇs´ı. Takto postupuje tak dlouho, dokud nedoraz´ı k posledn´ı. ´ Uloha má následuj´ıc´ı pˇr´ınos: • Otestuje schopnost simulátoru simulovat kameru robota a pˇrenos obrazu do obsluˇzné aplikace. • Otestuje schopnost simulátoru simulovat pohyb robota v prostoru. • Rozˇs´ıˇr´ı moˇznosti navigace robota.

3.1. Z´ıskan´ı obrazu z kamery Nao je vybaven dvˇema kamerami poskytuj´ıc´ımi rozliˇsen´ı 640×480 pixel˚ u pˇri rychlosti sn´ımán´ı 30 fps. Podrobné informace k obˇema kamerám jsou k dispozici v oficiáln´ı dokumentaci [14, advanced/hardware/video camera]. Simulátor Webots umoˇzn ˇuje mˇenit základn´ı parametry kamery, kter´ ymi jsou rozliˇsen´ı a zorn´ yu ´hel. Já jsem ve vˇsech pˇr´ıpadech vyuˇz´ıval horn´ı kameru s pln´ ym rozliˇsen´ım 640×480 pixel˚ u. Zorn´ y u ´hel jsem nastavil shodnˇe s kamerou skuteˇcného robota 58◦ diagonálnˇe. Ovladaˇc robota NaoQi, kter´ y je nainstalován u skuteˇcného robota, disponuje ˇradou funkc´ı pro zpracován´ı obrazu. Pro tuto u ´lohu se jako nejzaj´ımavˇejˇs´ı jev´ı detekce speciáln´ıch kruhov´ ych znaˇcek zvan´ ych Naomark (viz dokumentaci [14, API / ALLandMarkDetection]), která by byla vhodná pro u ´lohu stopován´ı. Tato funkce bohuˇzel nen´ı podporována simulaˇcn´ım rozhran´ım, které NaoQi nab´ız´ı a které simulátor Webots vyuˇz´ıvá. Proto jsem musel zvolit jin´ y zp˚ usob detekce znaˇcek. Jak se pozdˇeji ukázalo, vestavˇená funkce detekuj´ıc´ı Naomarky stejnˇe nen´ı dostateˇcnˇe spolehlivá pro podobné pouˇzit´ı. Pojednává o tom ˇclánek Integration of the Humanoid Robot Nao inside a Smart Home [19], ve kterém se autoˇri vˇenuj´ı navigaci robota v domác´ım prostˇred´ı. Pˇred samotnou detekc´ı znaˇcek je potˇreba z´ıskat ze simulátoru obraz, kter´ y sn´ımá virtuáln´ı kamera robota. Simulaˇcn´ı rozhran´ı ovladaˇce NaoQi nab´ız´ı sadu funkc´ı, které umoˇzn ˇuj´ı naˇcten´ı obrazu z pamˇeti ovladaˇce, kam je obraz cyklicky ukládán. Pro potˇreby u ´lohy je nejvhodnˇejˇs´ı pouˇz´ıt funkci getImageRemote (viz 14

3.2. Zpracován´ı obrazu dokumentaci [14, API / ALVideoDevice]). Já jsem pouˇzil pro práci s obrazem knihovnu OpenCV [9], která nab´ız´ı ˇsirokou ˇskálu funkc´ı pro zpracován´ı obrazu. Po naˇcten´ı dat pomoc´ı vybrané funkce je tedy obraz ukládán do struktury IplImage, kterou OpenCV standardnˇe pouˇz´ıvá. Tento postup lze pouˇz´ıt i v pˇr´ıpadˇe, ˇze pracujeme se skuteˇcn´ ym robotem, protoˇze funkce jsou stejné jak pro bˇeˇzné, tak pro simulaˇcn´ı rozhran´ı. Rozd´ıl je jenom v tom, ˇze v pˇr´ıpadˇe simulace je do pamˇeti ovladaˇce NaoQi obraz cyklicky ukládán rozhran´ım simulátoru Webots a nen´ı pˇrirozenˇe naˇc´ıtán z kamery. Komunikace NaoQi s obsluˇznou aplikac´ı bohuˇzel nen´ı optimalizována a dosahuje velmi podpr˚ umˇern´ ych rychlost´ı. To plat´ı jak pro skuteˇcného robota, tak pro simulaˇcn´ı rozhran´ı. V´ ysledkem je, ˇze pokud bychom takto sn´ımali scénu, dosáhneme maximálnˇe pˇrenosové rychlosti 1fps, coˇz je pro vˇetˇsinu aplikac´ı nedostaˇcuj´ıc´ı. Tohoto problému jsou si v´ yvojáˇri robota vˇedomi a pracuj´ı na vylepˇsen´ı. Pˇrenosov´ y protokol byl vylepˇsen ve verzi SDK 1.8.16, kde dosahuje rychlosti 10 fps. Jednou moˇznost´ı, jak pˇrenos zlepˇsit, by tedy mohl b´ yt pˇrechod na novˇejˇs´ı verzi Aldebran SDK. Druhou moˇznost´ı je pouˇzit´ı speciáln´ıho middlewaru pro pˇrenos dat z robota [24]. Pˇri jeho pouˇzit´ı je moˇzné dosáhnout pˇrenosové rychlosti 30fps. V pˇr´ıpadˇe, ˇze pracujeme se simulátorem, nen´ı pˇr´ıliˇs vhodné ovladaˇc NaoQi pro sn´ımán´ı obrazu pouˇz´ıvat. T´ım docház´ı k tomu, ˇze v simulátoru Webots vznikne obraz virtuáln´ı scény, kter´ y je nahrán do pamˇeti NaoQi, odkud je potom naˇc´ıtán obsluˇznou aplikac´ı robota. Kdyby byla komunikace s NaoQi dostateˇcnˇe rychlá, tento mezikrok by v˚ ubec nevadil a naopak by bylo v´ yhodné, ˇze by naˇc´ıtán´ı obrazu fungovalo stejnˇe v simulaci jako v pˇr´ıpadˇe skuteˇcného robota. Protoˇze tomu tak nen´ı (pouˇzit´ı middlewaru by bylo sloˇzitˇejˇs´ı), byl jsem nucen hledat ˇreˇsen´ı v meziprocesové komunikaci, pomoc´ı které bych bˇehem poˇrizován´ı obrázku obeˇsel NaoQi. Rozhodl jsem se vyuˇz´ıt knihovnu Boost [10], která je vyuˇz´ıvána Aldebaran SDK, tud´ıˇz ji má k dispozici kaˇzd´ y, kdo s robotem Nao pracuje. Moˇznost´ı, jak propojit dva nezávislé procesy na jednom poˇc´ıtaˇci, je v´ıce. Já jsem zvolil sd´ılenou pamˇet’ [11, Boost.Interprocess / Sharing memory between processes]. Toto ˇreˇsen´ı spoˇc´ıvá v tom, ˇze kontroler naoqi for webots vytvoˇr´ı sd´ılenou pamˇet’ a m´ısto toho, aby obraz uloˇzil do pamˇeti ovladaˇce NaoQi, uloˇz´ı ho do této pamˇeti. Obsluˇzná aplikace se poté pˇripoj´ı ke sd´ılené pamˇeti, odkud si obraz naˇcte. Zápis a ˇcten´ı mus´ı b´ yt samozˇrejmˇe synchronizovány pomoc´ı zámk˚ u vzájemného vylouˇcen´ı (tzv. mutexy). Obsluˇznou aplikaci je moˇzné implementovat tak, ˇze se na zaˇcátku definuje, zda je urˇcena pro simulátor, nebo pro skuteˇcného robota. Na m´ıstˇe naˇcten´ı obrazu se implementuj´ı obˇe varianty a provede se pouze ta, která odpov´ıdá definici. T´ım je zaruˇceno, ˇze na simulátoru vyvinutá aplikace bude spustitelná na skuteˇcném robotovi pouze po zmˇenˇe nastaven´ı (a opˇetovné kompilaci).

3.2. Zpracov´ an´ı obrazu Zpracován´ım obrazu se v této u ´loze mysl´ı detekce znaˇcky. K detekci jsem vyuˇzil open-source C++ knihovnu ARToolKit [12], jeˇz slouˇz´ı k vytváˇren´ı aplikac´ı pro 15

´ 3. Uloha 1 - Stopovaná augmentovanou realitu1 . Tato knihovna nab´ız´ı mimo jiné funkci, jenˇz v obrazu detekuje ˇctvercové znaˇcky, které jsou ohraniˇcené ˇcern´ ym rámem, uvnitˇr kterého je znak, podle nˇejˇz je urˇcen identifikátor (ID) znaˇcky. Knihovna nab´ız´ı aplikaci pro vytváˇren´ı nov´ ych znaˇcek, takˇze je moˇzné jich vytvoˇrit dostatek pro jakoukoli potˇrebu. Sadu znaˇcek, kterou jsem pˇripravil pro svou u ´lohu, je moˇzné vidˇet na obrázku 3.1. Pro samotnou detekci nen´ı velikost znaˇcky podstatná (ˇsablona z˚ ustává stejná), avˇsak pro pozdˇejˇs´ı v´ ypoˇcty je nutné ji znát. Já jsem zvolil velikost znaˇcky 160 mm, coˇz by podle dosaˇzen´ ych v´ ysledk˚ u mˇelo b´ yt dostateˇcné pro spolehlivou detekci na vzdálenost aˇz zhruba tˇr´ı metr˚ u. Funkce zajiˇst’uj´ıc´ı detekci znaˇcky detekuje veˇskeré znaˇcky, jejichˇz vzor je naˇcten v pamˇeti. Kaˇzdému vzoru je pˇri naˇcten´ı pˇriˇrazeno ID. Pˇri detekci poskytuje funkce tyto základn´ı informace o znaˇcce: • • • •

ID nalezené znaˇcky Vˇerohodnost Pozice stˇredu a rohov´ ych bod˚ u znaˇcky Natoˇcen´ı znaˇcky

Je tedy moˇzné zpracovávat pouze znaˇcky, jenˇz byly kvalitnˇe nadetekovány (experimentálnˇe jsem zvolil práh vˇerohodnosti 0,4) a maj´ı ID znaˇcky, která je na trase robota právˇe na ˇradˇe.

0.

1.

2.

3.

4.

5.

6.

7.

8.

9.

Obr´ azek 3.1. Pˇrehled pˇripraven´ ych znaˇcek pro detekci pomoc´ı ARToolKitu

3.3. V´ ypoˇ cet polohy znaˇ cky Jakmile pomoc´ı ARToolKitu z´ıskám polohu rohov´ ych bod˚ u a stˇredu znaˇcky v obraze, mohu vypoˇc´ıtat relativn´ı polohu znaˇcky v˚ uˇci pozici robota v reálném svˇetˇe. V´ ypoˇcet je zaloˇzen na tˇr´ıbodovém algoritmu P3P [21, pˇrednáˇska 4], pomoc´ı kterého je moˇzné vypoˇc´ıtat projekˇcn´ı matici kamery. Pro tuto u ´lohu nen´ı nutné poˇc´ıtat pˇr´ımo projekˇcn´ı matici, ale staˇc´ı provést prvn´ı ˇca´st v´ ypoˇctu, ve kterém 1

Augmentovan´ a realita pˇredstavuje vkl´ adán´ı virtuáln´ıch objekt˚ u do skuteˇcné scény. Pˇr´ıkladem mohou b´ yt speci´ aln´ı efekty ve filmu.

16

3.3. V´ ypoˇcet polohy znaˇcky se urˇcuje vzdálenost jednotliv´ ych bod˚ u od kamery. Detekc´ı znaˇcky z´ıskám polohu pˇeti bod˚ u, ale algoritmus P3P pracuje pouze se tˇremi body, proto mi staˇc´ı poˇc´ıtat s rohy znaˇcky. Ve v´ ysledku cyklicky vyb´ırám 3 ze 4 bod˚ u. Pro kaˇzdou trojici bod˚ u m˚ uˇze nav´ıc vyj´ıt nˇekolik ˇreˇsen´ı. Veˇskeré v´ ysledky vzdálenost´ı ukládám a nakonec je pr˚ umˇeruji. T´ım dostanu vzdálenost kamery od stˇredu znaˇcky. Pˇresnˇeji ˇreˇceno, algoritmus pracuje se tˇremi páry (bod v obraze / bod v reálném svˇetˇe). Proto mus´ım vˇsem bod˚ um pˇriˇradit 3D souˇradnice. Nejjednoduˇsˇs´ı pro mˇe bylo zvolit stˇred soustavy ve stˇredu znaˇcky. Souˇradnice vˇsech bod˚ u pak popisuje obrázek 3.2. D´ıky znalosti skuteˇcného rozmˇeru znaˇcky mohu souˇradnicovou vzdálenost snadno pˇrevést na metry.

Obr´ azek 3.2. Pˇriˇrazen´ı svˇetov´ ych souˇradnic roh˚ um a stˇredu znaˇcky

V´ ypoˇcet vzdálenosti ke stˇredu znaˇcky mi ale nestaˇc´ı. Vzdálenost je urˇcena od kamery. Je tedy nutné pomoc´ı Pythagorovy vˇety pˇrepoˇc´ıtat vzdálenost ”po zemi”(na v´ yˇsku, ve které se kamera právˇe nacház´ı, se m˚ uˇzeme dotázat NaoQi ). Pokud by byla znaˇcka nalezena pˇresnˇe uprostˇred obrazu, staˇcilo by, aby ˇsel robot stále rovnˇe a po uraˇzen´ı vypoˇc´ıtané vzdálenosti by stál v jej´ım stˇredu. Znaˇcka ovˇsem m˚ uˇze leˇzet r˚ uznˇe vzdálena od stˇredu obrazu, a proto je tˇreba vzdálenost, kterou má robot urazit, rozdˇelit na x-ovou a y-ovou sloˇzku – ∆x a ∆y. Situace je znázornˇena na obrázku 3.3. Souˇradn´ y systém robota je znázornˇen na témˇze obrázku. Osa y tedy pˇredstavuje posun robota do strany. Nejprve je tˇreba vypoˇc´ıtat tuto y-ovou sloˇzku, kterou jsem oznaˇcil ∆y. Opˇet pomoc´ı Pythagorovy vˇety je moˇzné z této vzdálenosti vypoˇc´ıtat x-ovou sloˇzku, kterou jsem oznaˇcil jako ∆x. ∆x =

p l2 − ∆y 2

(3.1)

Z˚ ustává tak otázka, jak vypoˇc´ıtat ∆y. Na obrázku 3.4 je situace rozkreslena detailnˇeji. Vzdálenosti ∆y zde odpov´ıdá vzdálenost |CV|, kde C je stˇred znaˇcky a V je bod na vertikáln´ı ose obrázku ve v´ yˇsce bodu C. K v´ ypoˇctu této vzdálenosti je tˇreba znát pˇrepoˇcet z pixel˚ u na metry. Ten je kv˚ uli perspektivˇe v kaˇzdé hladinˇe 17

´ 3. Uloha 1 - Stopovaná

Obr´ azek 3.3. Zn´ azornˇen´ı polohy kamery a znaˇcky: d ... vzdálenost znaˇcky od kamery, h ... v´ yˇska kamery, l ... vzd´ alenost znaˇcky v p˚ udorysu

obrázku jin´ y, avˇsak pro jednu hladinu stejn´ y (´ useˇcka CV je ovˇsem horizontáln´ı). K tomuto pˇrepoˇctu je tˇreba zmˇeˇrit vzdálenost |CH| jak v pixelech, tak v metrech. V prvn´ım pˇr´ıpadˇe m˚ uˇzeme tuto hodnotu snadno odeˇc´ıst z obrázku. Ve druhém pˇr´ıpadˇe ji mus´ım vypoˇc´ıtat z troj´ uheln´ıku CSH (S je stˇred hrany KL, kde body K a L jsou um´ıstˇeny nejv´ıce vpravo). Tento troj´ uheln´ık je v reálném svˇetˇe pravo´ uhl´ y, ale v obraze nikoliv. Proto je tˇreba tyto 3 body transformovat homografi´ı [16, strany 69-71], která transformuje rohy znaˇcky do rohu ˇctverce o stejnˇe dlouh´ ych stranách, jako má znaˇcka v reálném svˇetˇe. K v´ ypoˇctu homografie jsem vyuˇzil funkci cvFindHomography z knihovny OpenCV. V takto transformovaném troj´ uheln´ıku vypoˇc´ıtám snadno pomoc´ı Pythagorovy vˇety vzdálenost |CH| v metrech (znaˇceno |CH|m ): |CH|m =

p |CS|2m − |HS|2m

(3.2)

Vzdálenost |CV|m a tud´ıˇz poˇzadovanou y-ovou sloˇzku vzdálenosti ke znaˇcce vypoˇc´ıtám jiˇz snadno podle vzorce: ∆y = |CV |m = |CV |

|CH|m |CH|

(3.3)

K v´ ypoˇctu vzdálenosti kamery od stˇredu znaˇcky jsem vytvoˇril funkci p3pDistance a k rozkladu vzdálenosti na sloˇzku ∆x a ∆y funkci decomposeXY. Obˇe funkce jsou um´ıstˇeny v souboru p3pdistance.h resp. p3pdistance.cpp. Detaily k funkc´ım viz programátorská dokumentace. 18

3.4. Pohyb robota po trase

Obr´ azek 3.4. Znázornˇen´ı polohy znaˇcky v obraze

3.4. Pohyb robota po trase 3.4.1. Popis algoritmu Pˇredpokládá se, ˇze algoritmus, kter´ y provede robota po trase vytyˇcené znaˇckami, je spuˇstˇen v okamˇziku, kdy robot stoj´ı v m´ıstˇe, odkud m˚ uˇze vidˇet prvn´ı znaˇcku. Dále se pˇredpokládá, ˇze trasa je postavena tak, aby z kaˇzdé znaˇcky bylo moˇzné vidˇet znaˇcku následuj´ıc´ı a nebyla mezi nimi ˇza´dná pˇrekáˇzka. Algoritmus jsem tedy implementoval tak, ˇze se po spuˇstˇen´ı zaˇcne robot rozhl´ıˇzet a rozhl´ıˇz´ı se, dokud nenalezne prvn´ı znaˇcku. Jakmile ji nalezne, vypoˇc´ıtá jej´ı polohu a vydá se k n´ı. Zde se opˇet bude rozhl´ıˇzet, dokud nenelazene dalˇs´ı. Tak pokraˇcuje, dokud nedoraz´ı k posledn´ı znaˇcce. Bˇehem rozhl´ıˇzen´ı robot nikam nechod´ı a pˇresun k dalˇs´ı znaˇcce je pˇr´ımoˇcar´ y. Robot se tedy vˇzdy rozhl´ıˇz´ı na jednom m´ıstˇe a pokud znaˇcku nenalezne, otoˇc´ı ve smˇeru hodinov´ ych ruˇciˇcek o 60◦ a opˇet se rozhl´ıˇz´ı. Bˇehem rozhl´ıˇzen´ı natoˇc´ı hlavu do 9 r˚ uzn´ ych poloh, které jsou kombinac´ı 3 u ´rovn´ı sklopen´ı a3u ´rovn´ı natoˇcen´ı: ´ • Urovnˇ e sklopen´ı hlavy dol˚ u v˚ uˇci vodorovné poloze ◦ – 0 – 12◦ – 29,5◦ (maximum) • Natoˇcen´ı hlavy v˚ uˇci natoˇcen´ı robota – -30◦ (minimum) – 0◦ – 30◦ (maximum) K nadefinován´ı pohybu hlavy jsem vyuˇzil aplikaci Choregraphe, která je souˇca´st´ı bal´ıˇcku Aldebaran SDK. Z této aplikace je moˇzné pro jakoukoliv sekvenci pohyb˚ u generovat odpov´ıdaj´ıc´ı C++ kód. Já jsem tyto kódy um´ıstil do souboru movement.h resp. movement.cpp. K otoˇcen´ı robota jsem pouˇzil funkci walkTo, 19

´ 3. Uloha 1 - Stopovaná kterou nab´ız´ı framework NaoQi. Pˇri volán´ı této funkce se zadáváj´ı pouze relativn´ı souˇradnice x a y, kam má robot doj´ıt, a u ´hel, o kter´ y se má robot otoˇcit.

3.4.2. Popis probl´ emu s ch˚ uz´ı robota v simul´ atoru K pˇresunu robota k dalˇs´ı znaˇcce jsem chtˇel opˇet pouˇz´ıt funkci walkTo, která je velmi vhodná a jiˇz jsem s n´ı pˇriˇsel do styku pˇri práci se skuteˇcn´ ym robotem, kde funguje spolehlivˇe. Pˇri testován´ı algoritmu na simulátoru jsem ale zjistil, ˇze funkce zde nepracuje, jak by mˇela. Pˇri testován´ı na jednoduché aplikaci, která pouze zavolala funkci s parametry k ujit´ı jednoho metru dopˇredu, jsem ovˇeˇril, ˇze robot ujde vˇzdy kratˇs´ı, promˇenlivou vzdálenost a pˇri sledován´ı simulátoru jsem pozoroval podezˇrelé pohyby robota, které vedly k tomu, ˇze robot dˇelal napˇr. kroky na m´ıstˇe nebo se naklánˇel a mˇenil smˇer. Kontaktoval jsem podporu simulátoru Webots, kde mi bylo sdˇeleno, ˇze se jedná o chybu zp˚ usobenou nesynchronn´ım bˇehem kon´dajnˇe vˇed´ı, ale nemaj´ı ˇcas se j´ım troler˚ u NaoQi a naoqi for webots. O tomto jevu u zab´ yvat. Cel´ y problém tkv´ı v tom, ˇze kontroler NaoQi má svou ˇcasovou základnu. Pokud obsluˇzná aplikace zavolá funkci walkTo, NaoQi zaˇcne mˇenit polohy kloub˚ u a dˇelá to nezávisle kaˇzd´ ych 40 ms. Naproti tomu naoqi for webots má zase svou ˇcasovou základnu a kaˇzd´ ych 40 ms si vyˇzádá polohy kloub˚ u od NaoQi. Funkce by pracovala správnˇe, kdyby toto prob´ıhalo synchronnˇe. Bohuˇzel tomu tak nen´ı a pokud je napˇr´ıklad procesor hodnˇe zat´ıˇzen a simulátor resp. jeho kontroler u se opozd´ı, NaoQi naoqi for webots je zaneprázdnˇen a s pˇreˇcten´ım poloh kloub˚ neˇceká. V´ ysledkem je, ˇze pohyby nejsou plynulé nebo jsou v kritick´ ych pˇr´ıpadech u ´plnˇe chybné. Simulátor má dokonce nástroj monitoruj´ıc´ı synchronizaci obou kontroler˚ u, kter´ y je um´ıstˇen v pravém doln´ım rohu okna simulátoru (viz obrázek 3.5a). Pokud NaoQi pˇredb´ıhá, hodnota klesá pod 1.0 (hodnota 1.0 odpov´ıdá plné synchronizaci). V uzlu WorldInfo, jenˇz je prvn´ım uzlem VRML stromu, je poloˇzka runRealTime (viz brázek 3.5b). Pokud je tato poloˇzka zatrhnuta, konuˇze doj´ıt k tomu, ˇze troler naoqi for webots ˇceká na NaoQi, a t´ım pádem nem˚ by ukazatel synchronizace ukazoval vˇetˇs´ı hodnotu neˇz 1.0. V´ ysledkem je jednostranná synchronizace. NaoQi vˇsak stejnˇe nikdy nepoˇcká, takˇze chyba je pouze zm´ırnˇena. Protoˇze NaoQi nen´ı (narozd´ıl od naoqi for webots) open-source a nen´ı tedy moˇzné jej upravit, nedá se s t´ımto problémem nic dˇelat. V praxi tedy nen´ı moˇzné v simulátoru tuto funkci pouˇz´ıvat tam, kde poˇzadujeme pˇresnost. Je tˇreba pˇrij´ıt s jin´ ym ˇreˇsen´ım, jak pˇresunovat robota v prostoru. Pˇri psan´ı obsluˇzné aplikace jsem pouˇzil opˇet dvoj´ı implementaci, protoˇze pokud aplikace nebˇeˇz´ı na simulátoru, nen´ı d˚ uvod se funkci walkTo vyh´ ybat. Pokud nám ale nejde o pˇresnost (napˇr. pˇri otoˇcen´ı robota bˇehem rozhl´ıˇzen´ı nen´ı podstatné, jestli se otoˇc´ı pˇresnˇe o 60◦ ), je moˇzné funkci walkTo volat, i pokud pracujeme se simulátorem.

ˇ sen´ı probl´ 3.4.3. Reˇ emu s ch˚ uz´ı robota v simul´ atoru Existuje nˇekolik zp˚ usob˚ u, jak vyˇreˇsit problém s ch˚ uz´ı robota v simulátoru, a vˇsechny spoˇc´ıvaj´ı ve vyhnut´ı se funkci walkTo. 20

3.4. Pohyb robota po trase

a) ukazatel nizace

synchro-

b) poloˇzka runRealTime v uzlu WorldInfo

Obr´ azek 3.5. N´ astroje ke kontrolován´ı synchronizace dostupné v simulátoru Webots

Nevyuˇ z´ıvat pohyb robota Simulátor je vybaven speciáln´ım kontrolerem pojmenovan´ ym Supervisor, jenˇz je schopen pohybovat jak´ ymikoliv pˇredmˇety. Pomoc´ı meziprocesové komunikace je tak moˇzné vydat pˇr´ıkaz k posunut´ı robota na poˇzadované m´ısto. Tento postup nep˚ usob´ı pˇr´ıliˇs dobˇre a nav´ıc nen´ı dostupn´ y s licenc´ı EDU. Vyuˇ z´ıt funkci setWalkTargetVelocity Pomoc´ı zm´ınˇené funkce je moˇzné nastavit délku kroku a frekvenci krok˚ u robota, ˇc´ımˇz je moˇzné manuálnˇe ovládat jeho ch˚ uzi. Pˇri pouˇzit´ı této funkce docház´ı ke stejné chybˇe, jako bychom pouˇzili funkci walkTo. V tomto pˇr´ıpadˇe ale máme v´ yhodu v tom, ˇze m˚ uˇzeme nastavit frekvenci krok˚ u. Pokud nastav´ıme frekvenci n´ızkou, nastaven´ı kloub˚ u se bude bˇehem ch˚ uze mˇenit pomaleji a riziko, ˇze dojde k velké chybˇe bˇehem desynchronizace simulátoru Webots s kontrolerem NaoQi, bude malé. T´ımto ˇreˇsen´ım chybu neodstran´ıme, ale v´ yraznˇe ji sn´ıˇz´ıme. Naprogramoval jsem funkci walkTo2, která pˇrepoˇc´ıtá souˇradnice, kam má robot doj´ıt, na u ´hel natoˇcen´ı a vzdálenost. Poté volá funkci setWalkTargetVelocity s n´ızkou frekvenc´ı krok˚ u. Robot je nejprve natoˇcen správn´ ym smˇerem a poté vyslán kupˇredu, aby uˇsel pˇr´ımoˇcaˇre danou vzdálenost. Nev´ yhodou této funkce je, ˇze chyba (i kdyˇz malá) je stále nahodilá a robot jde pomaleji neˇz pˇri pouˇzit´ı funkce walkTo. V´ yhodou je, ˇze tato funkce m˚ uˇze b´ yt pouˇzita i pˇri práci se skuteˇcn´ ym robotem, kde m˚ uˇze b´ yt v urˇcit´ ych pˇr´ıpadech niˇzˇs´ı rychlost pohybu vyˇzadována. Pokud pracujeme se simulátorem, je moˇzné toto ˇreˇsen´ı jeˇstˇe vylepˇsit t´ım, ˇze budeme ˇc´ıst polohu robota ze simulátoru a pokud po zavolán´ı funkce walkTo2 skonˇc´ı na jiném m´ıstˇe, neˇz by mˇel, zavoláme funkci znovu tak, aby doˇslo k upˇresnˇen´ı pozice. Takto lze postupovat rekuzivnˇe, dokud chyba neklesne pod urˇcit´ y práh. ˇ Cten´ı polohy robota lze uskuteˇcnit napˇr´ıklad pomoc´ı tˇr´ıdy Supervisor. Pokud tuto tˇr´ıdu nemáme k dispozici, je moˇzné pozici robota zjistit zapojen´ım zaˇr´ızen´ı GPS. Robot Nao takov´ ym zaˇr´ızen´ım vybaven nen´ı, ale simulátor Webots ho nab´ız´ı a je 21

´ 3. Uloha 1 - Stopovaná moˇzné upravit prototypov´ y soubor robota a zaˇr´ızen´ı GPS robotu pˇridat. Pokud to udˇeláme, staˇc´ı upravit kontroler naoqi for webots tak, aby v kaˇzdém kroku pˇreˇcetl souˇradnice, které GPS zaˇr´ızen´ı udává, a uloˇzil je do sd´ılené pamˇeti. Souˇradnice odpov´ıdaj´ı poloze robota v souˇradném systému simulátoru. Pohybovat robotem pˇr´ımo prostˇrednictv´ım kontroleru naoqi for webots Kontroler naoqi for webots ˇcte polohy kloub˚ u z NaoQi a zde docház´ı k chybˇe. Tyto polohy ovˇsem m˚ uˇze naˇc´ıtat napˇr´ıklad ze souboru .motion jako jak´ ykoli jin´ y kontroler, kter´ y pracuje s robotem pˇr´ımo, bez pouˇzit´ı NaoQi. Z nˇekolika d´ılˇc´ıch pohyb˚ u lze sloˇzit ˇretˇezec, jenˇz by dovedl robota na poˇzadované m´ısto. Staˇc´ı k tomu ze souˇradnic relativn´ı pozice, kam má robot doj´ıt, vypoˇc´ıtat u ´hel otoˇcen´ı robota a vzdálenost, kterou pak má uj´ıt. Já jsem vyuˇzil tyto d´ılˇc´ı pohyby: • • • • • • •

otoˇcen´ı doprava / doleva otoˇcen´ı doprava / doleva otoˇcen´ı doprava / doleva otoˇcen´ı doprava / doleva ch˚ uze dopˇredu 50cm ch˚ uze dopˇredu 10cm ch˚ uze dopˇredu 1cm

o o o o

u ´hel u ´hel u ´hel u ´hel

60◦ 40◦ 10◦ 1◦

K vytvoˇren´ı .motion soubor˚ u s nadefinovan´ ymi pohyby jsem vytvoˇril script v jazyce Python, kter´ y lze pouˇz´ıt v aplikaci Choregraphe. Script kaˇzd´ ych 40ms zjist´ı od NaoQi, které bˇeˇz´ı virtuálnˇe v pozad´ı Choregraphe, polohy kloub˚ u a zap´ıˇse je do souboru ve formátu, kter´ y pouˇz´ıvá simulátor Webots. I zde docház´ı k chybˇe kv˚ uli ˇspatné synchronizaci. Opˇet mohu ale vyuˇz´ıt funkci setWalkTargetVelocity a nastavit niˇzˇs´ı rychlost ch˚ uze. Oproti ˇreˇsen´ı, kdy tuto funkci pouˇst´ım pˇr´ımo, má tento pˇr´ıstup v´ yhodu v tom, ˇze naˇcten´ı pohybové sekvence do souboru lze provádˇet opakovanˇe pˇri nezat´ıˇzeném procesoru a ponechat si nejlepˇs´ı v´ ysledek, kter´ y bude pak v praxi vˇzdy stejn´ y. Vytvoˇril jsem funkci walkToSimulation, která vyuˇz´ıvá sd´ılenou pamˇet’ k tomu, aby pˇredala kontroleru naoqi for webots souˇradnice, kam má robot doj´ıt. Dále jsem musel upravit naoqi for webots, kam jsem pˇridal funkci, jeˇz ˇcte sd´ılenou pamˇet’ a ˇceká na pˇr´ıkaz. Jakmile jej dostane, spust´ı mnou pˇripravené pˇr´ısluˇsné pohybové sekvence ze soubor˚ u .motion. Vu ´loze Stopovaná jsem nakonec pouˇzil pˇri práci se simulátorem funkci walkTo2, jej´ıˇz pˇresnost je pro potˇreby u ´lohy dostateˇcná. Pˇri práci se skuteˇcn´ ym robotem jsem vyuˇzil standardn´ı funkci walkTo.

3.5. Zhodnocen´ı dosaˇ zen´ ych v´ ysledk˚ u Na tomto m´ıstˇe uvedu, jak´ ych v´ ysledk˚ u jsem dosáhl pˇri testován´ı u ´lohy. D˚ uleˇzitá je zejména pˇresnost detekce znaˇcek a schopnost robota trasu bezpeˇcnˇe proj´ıt. Shrnu také pˇr´ınos a pouˇzitelnost simulátoru bˇehem práce na implementaci u ´lohy. 22

3.5. Zhodnocen´ı dosaˇzen´ ych v´ ysledk˚ u Simulátor umoˇzn ˇuje natáˇcet videa pˇr´ımo ve virtuáln´ım svˇetˇe, kde prob´ıhá simulace. Natoˇcil jsem tˇri videa, ve kter´ ych robot procház´ı tˇri r˚ uzná bludiˇstˇe. Dle mého názoru tato videa nejlépe ilustruj´ı, jak u ´loha funguje a jaké pˇresnosti bylo dosaˇzeno. Je moˇzné vidˇet i situaci, kdy dojde k desynchronizaci komunikace simulátoru s kontrolerem NaoQi, coˇz je provázeno nekontrolovan´ ymi pohyby robota. Video obsahuje i okno s pohledem robota, takˇze je moˇzné sldovat, kam se právˇe d´ıvá. Videa jsou uloˇzena na pˇriloˇzeném DVD.

3.5.1. Pˇresnost detekce znaˇ cek V´ ypoˇcet relativn´ı polohy znaˇcky vzhledem k pozici robota nen´ı pˇri pouˇzit´ı v´ yˇse popsaného postupu pˇriliˇs pˇresn´ y. Nepˇresnost roste se vzdálenost´ı robota od znaˇcky, k ˇcemuˇz docház´ı ze dvou d˚ uvod˚ u: 1. Z principu vˇeci plyne, ˇze pˇri vˇetˇs´ı vzdálenosti zp˚ usob´ı chyba v detekci bod˚ u v obraze vˇetˇs´ı chybu pˇri v´ ypoˇctu polohy znaˇcky. ˇ ım je znaˇcka dále od robota, t´ım vˇetˇs´ı je u 2. C´ ´hel, pod kter´ ym kamera robota znaˇcku sn´ımá. V tomto pˇr´ıpadˇe tato pˇr´ımá u ´mˇera mezi vzdálenost´ı znaˇcky a chybou jej´ı detekce ˇ pˇr´ıliˇs nevad´ı. Reˇsen´ım m˚ uˇze b´ yt bud’ sestaven´ı cesty, na které znaˇcky leˇz´ı bl´ızko u sebe, nebo vyuˇzit´ı opˇetovné detekce znaˇcky. Pokud by byla znaˇcka detekována ve vˇetˇs´ı vzdálenosti, neˇz zvolen´ y práh, robot by byl vyslán pouze do poloviny cesty a zde by provedl opˇetovnou detekci. Takto by bylo moˇzné postupovat rekurzivnˇe. V tabulce 3.1 uvád´ım mˇeˇren´ı chyby pˇri detekci znaˇcky. Z v´ ysledk˚ u plyne pr˚ umˇerná relativn´ı chyba detekce polohy znaˇcky 2,83 %. K velkému zlomu ve velikosti absolutn´ı chyby docház´ı u vzdálenosti 1,5 m, coˇz naznaˇcuje, ˇze tato hodnata by byla vhodná jako práh pˇri opakované detekci. Dosaˇzená pˇresnost je pro tuto u ´lohu dostaˇcuj´ıc´ı. Vzniklá chyba se totiˇz nikde nekumuluje, protoˇze pˇri detekci znaˇcky se vˇzdy poˇc´ıtá relativn´ı vzdálenost vzhledem k pozici robota. Tabulka 3.1. Srovn´ an´ı skuteˇcn´ ych a namˇeˇren´ ych vzdálenost´ı markeru od robota bˇehem testov´ an´ı pˇresnosti algoritmu. ˇ ıslo mˇ C´ eˇ ren´ı xreal [m] yreal [m] distreal [m] xmeasure [m] ymeasure [m] distmeasure [m] chybaabs [m] chybarel [%]

1. 0,0386 0,6030 0,6043 0,0391 0,6022 0,6035 0,0008 0,132

2. 0,1151 0,7536 0,7624 0,1201 0,7576 0,7671 0,0047 0,616

3. 0,3267 0,8950 0,9528 0,2936 0,8004 0,9394 0,0134 1,406

4. -0,2618 1,0981 1,1289 -0,2583 1,0797 1,1101 0,0188 1,665

5. 0,1377 1,2041 1,2119 0,1441 1,1683 1,1772 0,0347 2,863

6. 0,0558 1,3809 1,3821 0,0575 1,3061 1,3074 0,0747 5,405

7. -0,3164 1,4138 1,4488 -0,3133 1,3767 1,4119 0,0369 2,547

8. 0,2672 1,4452 1,4697 0,2714 1,3804 1,4068 0,0629 4,280

9. 0,0538 1,8856 1,8863 0,0555 1,7616 1,7622 0,1241 6,580

3.5.2. Hodnocen´ı simul´ atoru Tato jednoduchá u ´loha odhalila hned nˇekolik problém˚ u, kter´ ym je v´ yvojáˇr obsluˇzné aplikace vystaven bˇehem práce se simulátorem Webots. Prvn´ım z nich je 23

´ 3. Uloha 1 - Stopovaná pomal´ y pˇrenos obrazu, kter´ y se mi podaˇrilo u ´spˇeˇsnˇe vyˇreˇsit. Druh´ ym problémem je nepˇresnost v ch˚ uzi robota. Pˇri vyuˇz´ıván´ı vestavˇen´ ych funkc´ı kotroleru NaoQi m˚ uˇze b´ yt chyba veliká a nahodilá. V pˇr´ıpadˇe pouˇz´ıván´ı mé funkce walkTo2 je chyba stále nahodilá, ale znatelnˇe menˇs´ı. Pˇri pouˇzit´ı funkce walkToSimulation je chyba dána nejmenˇs´ım moˇzn´ ym u ´hlem natoˇcen´ı a nejmenˇs´ı moˇznou vzdálenost´ı, kterou m˚ uˇze robot urazit. Ani v jednom pˇr´ıpadˇe nen´ı moˇzné dosáhnout 100% pˇresnosti, coˇz je ale podobné jako ve skuteˇcnosti. Jedná se o robota, kter´ y se pohybuje po nohou. S t´ım souvis´ı, ˇze bˇehem jeho ch˚ uze nejsou poloha a u ´hel natoˇcen´ı vzhledem ke svˇetov´ ym souˇradnic´ım 100 % pˇresné, coˇz m˚ uˇze b´ yt zp˚ usobeno napˇr. nevhodn´ ym povrchem, po kterém se robot pohybuje. Po vyˇreˇsen´ı zm´ınˇen´ ych problém˚ u, které simulátor pˇrinesl, jsem byl schopen pomˇernˇe snadno odladit algoritmus tak, aby pracoval správnˇe, aniˇz bych mˇel k dispozici skuteˇcného robota. Po dokonˇcen´ı u ´lohy jsem otestoval obsluˇznou aplikaci na skuteˇcném robotovi. Staˇcilo ji pˇrekompilovat s nastaven´ım pro skuteˇcného robota, vytisknout si obrázky znaˇcek ve správné velikosti a sestavit trasu. Skuteˇcn´ y robot procházel trasu u ´plnˇe stejnˇe jako robot v simulátoru. Tato u ´loha tedy ukazuje, ˇze simulátor Webots je vhodn´ y k ladˇen´ı takov´ ychto aplikac´ı.

24

´ 4. Uloha 2 - Bludiˇstˇ e C´ılem této u ´lohy je navrhnout, implementovat a v simulátoru Webots odzkouˇset obsluˇznou aplikaci robota Nao, která by umoˇzn ˇovala mapován´ı neznámého prostˇred´ı, jeˇz by mˇelo podobu bludiˇstˇe, v nˇemˇz by se nacházely známé objekty. ´ Ukolem robota by bylo detekovat polohu objekt˚ u a urˇcit svou pozici v bludiˇsti. Robot by mˇel b´ yt schopen vyuˇz´ıt vytvoˇrenou mapu prostˇred´ı k nalezen´ı nejkratˇs´ı cesty z m´ısta A do m´ısta B. Obsluˇzná aplikace by mˇela b´ yt schopna vizualizovat mapu a proces mapován´ı. ´ Uloha má následuj´ıc´ı pˇr´ınos: • Otestuje do jaké m´ıry dokáˇze simulátor pomoci pˇri ladˇen´ı sloˇzitˇejˇs´ı aplikace • Rozˇs´ıˇr´ı moˇznosti navigace robota

Obr´ azek 4.1. Sn´ımek bludiˇstˇe pro testován´ı a demonstraci aplikace

4.1. Podoba bludiˇstˇ e Pro jednoduchost jsem k testován´ı a demonstraci u ´lohy vytvoˇril bludiˇstˇe, ve kterém se objevuje jedin´ y typ objektu, j´ımˇz je dˇrevˇená bedna o hranˇe 0,4 m. Tˇechto krabic je v bludiˇsti deset a kaˇzdá je oznaˇcena svou jedineˇcnou znaˇckou, kterou je schopen detekovat ARToolKit (stejná sada znaˇcek jako v u ´loze Stopovaná). Velikost znaˇcky jsem zvolil 12 cm, coˇz je kompromis mezi t´ım, aby byla znaˇcka dostateˇcnˇe velká pro kvalitn´ı detekci a dostateˇcnˇe malá, aby se veˇsla do 25

´ 4. Uloha 2 - Bludiˇstˇe zábˇeru kamery, kdyˇz se robot pˇribl´ıˇz´ı k bednˇe na velmi malou vzdálenost. Znaˇcka je um´ıstˇena uprostˇred kaˇzdé ze ˇctyˇr boˇcn´ıch stˇen ve v´ yˇsce 0,3 m. Bludiˇstˇe je dostateˇcnˇe velké, aby robot bˇehem mapován´ı nenarazil na jeho konec. Nen´ı c´ılem hranici bludiˇstˇe mapovat, takˇze jsem bludiˇstˇe nechal témˇeˇr neohraniˇceno. Pokud by byla potˇreba hranici bludiˇstˇe detekovat, je moˇzné ho napˇr. obehnat dostateˇcnˇe vysokou zd´ı, na které by byly um´ıstˇeny znaˇcky pˇr´ısluˇsej´ıc´ı zdi. Dalˇs´ı moˇznost´ı by bylo vyuˇz´ıt sonaru. Podoba bludiˇstˇe je na obrázku 4.1.

4.2. Struktura aplikace a pouˇ zit´ e knihovny K vizualizaci mapy jsem se rozhodl pouˇz´ıt C++ knihovnu Qt [13], která je jednou z nejpopulárnˇejˇs´ıch knihoven pro v´ yvoj aplikac´ı s grafick´ ym uˇzivatelsk´ ym rozhran´ım. Zároveˇ n je souˇcást´ı Aldebaran SDK, takˇze ji ten, kdo pracuje s robotem Nao, nemus´ı dodateˇcnˇe instalovat. Základem Qt aplikace, kterou jsem vytvoˇril, je hlavn´ı okno obsahuj´ıc´ı menu, pomoc´ı kterého je moˇzné celou aplikaci ovládat. Je v nˇem také vykreslována mapa. Hlavn´ı okno je moˇzné vidˇet na obrázku 4.2. Pˇripojován´ı k robotovi prob´ıhá pˇres formuláˇr (viz obrázek 4.3), kde je moˇzné nastavit IP adresu a port, na kterém robot poslouchá. Souˇcást´ı formuláˇre je také nastaven´ı mód˚ u, ve kter´ ych bude aplikace pracovat: • Real Robot Pokud je zatrhnuto toto nastaven´ı, aplikace by se mˇela pˇripojit ke skuteˇcnému robotovi a podle toho vyuˇz´ıvat odpov´ıdaj´ıc´ı funkce, coˇz se t´ yká zejména naˇc´ıtán´ı obrazu z kamery a ch˚ uze. • Simulation Pokud je zatrhnuto toto nastaven´ı, aplikace pˇredpokládá, ˇze se pˇripojuje k simulátoru. Opˇet budou pouˇz´ıvány odpov´ıdaj´ıc´ı funkce. • SLAM Zatrhnut´ım tohoto parametru doc´ıl´ıme toho, ˇze aplikace bude pracovat v módu, kdy pro urˇcován´ı pˇresné polohy robota bude pouˇz´ıvat systém SLAM (soubˇeˇzná lokalizace a mapován´ı). Tento systém je detailnˇe popsán v kapitole 4.4. • Exact Odometry Kdyˇz vybereme tento mód, nebude pouˇz´ıván systém SLAM. M´ısto toho bude aplikace zcela vˇeˇrit odometrick´ ym1 u ´daj˚ um. Pokud je aplikace pˇripojena k simulátoru, pˇresná poloha robota je naˇc´ıtána pˇres sd´ılenou pamˇet’. Tento mód je dobr´ y pro testován´ı samotné detekce pˇrekáˇzek. V praxi je moˇzné lokalizaci nahradit doplˇ nuj´ıc´ım systémem (napˇr. pouˇzit´ı extern´ı kamery [19] nebo lokalizace na základˇe rekonstrukce mnoˇziny ˇr´ıdk´ ych 3D bod˚ u [17]). Tˇr´ıda mainWindow pˇredstavuj´ıc´ı hlavn´ı okno je uloˇzena v souboru mainWindow.h resp. mainWindow.cpp. Bˇehem pˇripojován´ı k robotu jsou vytvoˇreny instance dalˇs´ıch dvou tˇr´ıd, které aplikace vyuˇz´ıvá. Prvn´ı z nich je tˇr´ıda Robot, která je uloˇzena v souboru robot.h resp. robot.cpp a která funguje jako interface 1

Odometrie je postup, pˇri kterém se odhaduje pozice robota podle dat z pohybov´ ych senzor˚ u.

26

4.3. Souˇradn´ y systém a pˇresná detekce polohy pˇrekáˇzek pro volán´ı funkc´ı NaoQi. Dále obsahuje veˇskeré funkce pro detekci pˇrekáˇzek a ovládán´ı robota. Druhou tˇr´ıdou je tˇr´ıda Mapping um´ıstˇená v souboru mapping.h resp. mapping.cpp. Jej´ım c´ılem je uchovávat informace o poloze robota a vˇsech detekovan´ ych pˇrekáˇzkách. Souˇcasnˇe nab´ız´ı funkce pro vykreslovan´ı mapy a hledán´ı nejkratˇs´ı cesty. K hledán´ı nejkratˇs´ı cesty jsem pouˇzil open-source knihovnu VisiLibity [20] vyuˇz´ıvaj´ıc´ı metodu grafu viditelnosti [18, stránky 12-14 ].

Obr´ azek 4.2. Hlavn´ı okno aplikace obsahuj´ıc´ı menu a vizualizaci mapy

Obr´ azek 4.3. Formul´ aˇr k nastaven´ı parametr˚ u pˇri pˇripojován´ı aplikace k robotu

4.3. Souˇradn´ y syst´ em a pˇresn´ a detekce polohy pˇrek´ aˇ zek Souˇradn´ y systém, v nˇemˇz bude bˇehem mapován´ı mapa vytváˇrena, je urˇcen v´ ychoz´ı polohou robota pˇri spuˇstˇen´ı aplikace. Robot tak zpoˇca´tku stoj´ı ve stˇredu souˇradné 27

´ 4. Uloha 2 - Bludiˇstˇe soustavy a hled´ı ve smˇeru osy y. Pˇresná detekce polohy bedny v souˇradném systému mapy se skládá z nˇekolika krok˚ u. Veˇskeré funkce pouˇzité bˇehem detekce jsou souˇcást´ı tˇr´ıdy Robot.

4.3.1. Detekce znaˇ cky pomoc´ı knihovny ARToolKit Detekce je takˇrka totoˇzná s detekc´ı znaˇcky v u ´loze Stopovaná. Rozd´ıl je pˇredevˇs´ım v tom, ˇze nehledáme pouze znaˇcku, která je na ˇradˇe, ale veˇskeré znaˇcky maj´ıc´ı vˇerohodnost vyˇsˇs´ı neˇz práh, kter´ y jsem pro tuto u ´lohu experimentálnˇe zvolil 0,5. Dalˇs´ı zmˇeny souvis´ı s rozd´ıln´ ym um´ıstˇen´ım znaˇcek a vyˇsˇs´ımi nároky na pˇresnost detekce. Funkce vyuˇz´ıvané knihovnou ARToolKit k v´ ypoˇctu pozice rohov´ ych bod˚ u znaˇcky ˇ dosahuj´ı pˇresnosti na jeden pixel. Casto se ale m˚ uˇze stát, ˇze odchylka bude jeˇstˇe vˇetˇs´ı. Z tˇechto d˚ uvod˚ u jsem se rozhodl zpˇresnit detekci rohov´ ych bod˚ u znaˇcky pomoc´ı funkce cvFindCornerSubPix z knihovny OpenCV. Tato funkce je schopná vypoˇc´ıtat polohu rohov´ ych bod˚ u se subpixelovou pˇresnost´ı. Nutné je pouze na zaˇcátku zadat odhad, kter´ ym jsou v mém pˇr´ıpadˇe pozice urˇcené knihovnou ARToolKit. Funkce vˇsak nedokáˇze upˇresnit pozici stˇredu znaˇcky, jelikoˇz se nejedná o rohov´ y bod. Protoˇze je ale znaˇcka ˇctvercová, mohu jeho polohu urˇcit jako pr˚ umˇer pozic vˇsech rohov´ ych bod˚ u. Zm´ınˇené dodateˇcné v´ ypoˇcty pomohly v´ yraznˇe zv´ yˇsit pˇresnost detekce znaˇcky. Kv˚ uli upevnˇen´ı znaˇcek na stˇenách beden m˚ uˇze pˇri urˇcitém rozm´ıstˇen´ı doj´ıt k tomu, ˇze znaˇcka bude leˇzet ve st´ınu. V takovém pˇr´ıpadˇe by ji ARToolKit s defaultnˇe vyuˇz´ıvan´ ym prahem jasu (defaultn´ı hodnota je 100) mohl pˇrehlédnout. K detekci ve st´ınu je tedy nutné vyuˇz´ıt niˇzˇs´ı práh. Ten se ale zase nehod´ı pro detekci na svˇetle. Byl jsem tedy nucen zavést dvoj´ı detekci, s n´ızk´ ym a vysok´ ym prahem, a poté oba v´ ysledky slouˇcit. Pokud je znaˇcka nalezena pomoc´ı obou prah˚ u, zachovávám pouze hodnoty z´ıskané pˇri pouˇzit´ı s vyˇsˇs´ım prahem. Jako v´ ysledek by bylo moˇzné pouˇz´ıt také pr˚ umˇer obou hodnot, ale tento postup je rychlejˇs´ı, pˇriˇcemˇz v´ ysledek je takˇrka stejn´ y. Hodnoty obou prah˚ u je moˇzné mˇenit v nastaven´ı aplikace pomoc´ı promˇenn´ ych AR THRESHOLD resp. AR THRESHOLD DARK.

4.3.2. V´ ypoˇ cet projekˇ cn´ı matice pomoc´ı algoritmu P3P Pro potˇreby této u ´lohy je jiˇz tˇreba vypoˇc´ıtat projekˇcn´ı matici. Princip je stejn´ y jako v u ´loze Stopovaná. Algoritmus, kter´ y neskonˇc´ı v´ ypoˇctem vzdálenost´ı k bod˚ um znaˇcky, ale dopoˇc´ıtá nejlepˇs´ı projekˇcn´ı matici, je obsaˇzen ve funkci p3pP um´ıstˇené v souboru p3pdistance.h resp. p3pdistance.cpp. Algoritmus P3P ke sv´ ym v´ ypoˇct˚ um potˇrebuje kalibraˇcn´ı matici kamery. Na n´ı velmi závis´ı kvalita z´ıskané projekˇcn´ı matice. Pˇri práci na u ´loze Stopovaná jsem poˇc´ıtal kalibraˇcn´ı matici pomoc´ı trojice navzájem kolm´ ych u ´bˇeˇzn´ık˚ u, které byly dány krychl´ı, jej´ıˇz obraz jsem poˇr´ıdil pˇr´ımo v simulátoru Webots. Tato metoda je velmi jednoduchá a nab´ız´ı pr˚ umˇernˇe kvalitn´ı v´ ysledek. K jej´ımu vysvˇetlen´ı viz [23, stránka 24]. Jej´ım u ´skal´ım je obt´ıˇznost urˇcen´ı pˇresné pozice roh˚ u krychle v obraze. Byl jsem tedy nucen pouˇz´ıt ke kalibraci nam´ısto krychle ˇsachovnici, která nab´ız´ı v´ıce bod˚ u. D´ıky tomu je poloha u ´bˇeˇzn´ık˚ u vypoˇc´ıtána na základˇe protnut´ı v´ıce 28

4.3. Souˇradn´ y systém a pˇresná detekce polohy pˇrekáˇzek pˇr´ımek a v´ ypoˇcet je pˇresnˇejˇs´ı. Pouˇzit´ım lepˇs´ı metody kalibrace kamery jsem opˇet v´ yraznˇe zv´ yˇsil pˇresnost detekce pˇrekáˇzek.

4.3.3. V´ ypoˇ cet polohy bod˚ u znaˇ cky v souˇradn´ em syst´ emu robota (relativn´ı pozice) Mám-li k dispozici projekˇcn´ı matici, mohu vypoˇc´ıtat smˇerov´ y vektor, kter´ y m´ıˇr´ı ze stˇredu kamery do stˇredu znaˇcky. Protoˇze souˇradn´ y systém, v nˇemˇz byla projekˇcn´ı matice vypoˇc´ıtána, má stˇred ve stˇredu znaˇcky, mohu nastavit mˇeˇr´ıtko smˇerového vektoru tak, aby ukazoval pˇr´ımo do stˇredu znaˇcky. T´ım vypoˇc´ıtám jej´ı relativn´ı polohu v˚ uˇci stˇredu kamery. D´ıky tomu, ˇze znám rozmˇer znaˇcky, mohu tento v´ ypoˇcet provést pro jak´ ykoliv bod na znaˇcce (pro jednoduchost budu ale dále uvádˇet, ˇze poˇc´ıtám se stˇredem znaˇcky). Vyjádˇren´ı v´ ypoˇctu matematicky (viz také [23, stránky 13-19]): P = [Q q]

(4.1)

C = −Q−1 q

(4.2)

d = −Q−1 m

(4.3)

X = C + λd

(4.4)

P je projekˇcn´ı matice skládaj´ıc´ı se ze submatice Q (rozmˇer 3×3) a vektoru q (P = (Q|q)). C je pozice kamery, m jsou 2D souˇradnice stˇredu znaˇcky v obraze a d smˇerov´ y vektor do stˇredu znaˇcky. X jsou 3D souˇradnice stˇredu znaˇcky (urˇcil jsem si jako 0). Pomoc´ı rovnice 4.4 tak mohu urˇcit mˇeˇr´ıtko λ, pomoc´ı nˇehoˇz jiˇz snadno z´ıskám relativn´ı pozici stˇredu znaˇcky v˚ uˇci poloze kamery. Grafické vyjádˇren´ı viz na obrázku 4.4.

Obr´ azek 4.4. Grafické vyj´ adˇren´ı vztahu pozice kamery (C), projekˇcn´ı roviny (π), bodu v obraze (m), bodu v prostoru (X) a smˇerového vektoru paprsku (d) (pˇrevzato z [23])

V´ yˇse popsan´ ym postupem jsem vypoˇc´ıtal relativn´ı polohu stˇredu znaˇcky v˚ uˇci kameˇre robota. Dále je potˇreba zapoˇc´ıtat polohu kamery (natoˇcen´ı a naklopen´ı 29

´ 4. Uloha 2 - Bludiˇstˇe hlavy robota) a pˇrepoˇc´ıtat na relativn´ı pozici stˇredu znaˇcky v p˚ udorysu v˚ uˇci ˇ pozici robota. Reknˇ eme, ˇze mám polohu stˇredu znaˇcky uloˇzenu ve vektoru p: p = λd

(4.5)

Nejprve zapoˇc´ıtám sklopen´ı hlavy a pˇrevedu na pozici v p˚ udorysu: x = p1

(4.6)

y = cos α · p3 − sin α · p2

(4.7)

α pˇredstavuje u ´hel sklopen´ı hlavy. Dále zb´ yvá vz´ıt v u ´vahu natoˇcen´ı hlavy, jeˇz je pˇredstavováno u ´hlem β: x = x · cos β − y · sin β

(4.8)

y = x · sin β + y · cos β

(4.9)

Cel´ y v´ ypoˇcet jsem naprogramoval ve funkci computePointPosition.

4.3.4. V´ ypoˇ cet pozice rohov´ ych bod˚ u bedny (v p˚ udorysu) v souˇradn´ em syst´ emu mapy K tomu, abychom urˇcili polohu bedny, nám staˇc´ı z´ıskat polohu dvou bod˚ u na znaˇcce. Já jsem zvolil postup, kdy vypoˇc´ıtám polohu levého a pravého bodu v polovinˇe v´ yˇsky znaˇcky. Oznaˇcme je A a B. Nejprve pˇrevedu relativn´ı polohu bodu v˚ uˇci poloze robota do souˇradné soustavy mapy t´ım, ˇze zapoˇc´ıtám pozici a natoˇcen´ı robota v mapˇe. Poté vytvoˇr´ım vektor spojuj´ıc´ı dva vybrané body: s = [Ax − Bx

Ay − By ]T

(4.10)

Tento vektor normalizuji na velikost 0,14 m, coˇz odpov´ıdá vzdálenosti krajn´ıho bodu znaˇcky od hrany krychle. Tento vektor poté pˇriˇctu k bodu A, resp. odeˇctu od bodu B. T´ım z´ıskám polohu prvn´ıch dvou vrchol˚ u ˇctverce, kter´ y bude v mapˇe pˇredstavovat nalezenou bednu. Poté vytvoˇr´ım kolm´ y vektor k vektoru s a normalizuji ho na velikost 0,4 m, coˇz odpov´ıdá velikosti bedny. Kolm´ y vektor m˚ uˇze b´ yt orientován dvˇema smˇery. Pˇriˇcten´ım nebo odeˇcten´ım vektoru k prvn´ım dvˇema bod˚ um ˇctverce dostanu zbylé dva body. To, jestli mám vektor pˇriˇc´ıst nebo odeˇc´ıst (souvis´ı s orientac´ı vektoru), závis´ı na vzájemné poloze robota a detekované znaˇcky. Nejjednoduˇsˇs´ım zp˚ usobem, jak to zjistit, je vektor zkusit pˇriˇc´ıst. Pokud z´ıskan´ y bod leˇz´ı k robotovi bl´ıˇze neˇz bod, ze kterého jsme vycházeli, mˇeli jsme odeˇc´ıtat. Neˇz je poloha pˇrekáˇzky zpracovávána dál, otestuji, jestli má tvar ˇctverce a jestli jeho hrana odpov´ıdá správné velikosti (je v toleranci, kterou jsem zvolil 1 cm). Pomoc´ı této jednoduché kontroly mohu ignorovat ˇspatné detekce. Jedna bedna má na vˇsech sv´ ych stˇenách um´ıstˇenu stejnou znaˇcku. V jednom obrázku je tedy moˇzné detekovat jednu znaˇcku v´ıcekrát, k ˇcemuˇz docház´ı, pokud je bedna natoˇcena k robotovi hranou. V takovém pˇr´ıpadˇe je pozice bedny poˇc´ıtána 30

4.3. Souˇradn´ y systém a pˇresná detekce polohy pˇrekáˇzek dvakrát a v´ ysledek pr˚ umˇerován. Nen´ı pˇri tom nutné zjiˇst’ovat, kterou stˇenu krychle robot právˇe vid´ı, protoˇze v´ ypoˇcet vrchol˚ u polygonu, kter´ y v mapˇe pˇredstavuje pˇrekáˇzku, je na tom nezávisl´ y. V´ yˇse popsan´ y algoritmus jsem implementoval ve funkci computePositionOfObstacle.

4.3.5. Zpracov´ an´ı nov´ e informace o poloze pˇrek´ aˇ zky Pˇrekáˇzky ve své aplikaci ukládám v podobˇe polygonu. Jsou tedy urˇceny v´ yˇctem vrchol˚ u a jsou uloˇzeny ve struktuˇre Polygon knihovny Visilibity, coˇz umoˇzn ˇuje je pozdˇeji vyuˇz´ıt pro v´ ypoˇcet nejkratˇs´ı cesty v takové podobˇe, v jaké jsou. Vrcholy jsou ˇrazeny proti smˇeru hodinov´ ych ruˇciˇcek (CCW) a prvn´ım vrcholem je vˇzdy ten nejspodnˇejˇs´ı, nejv´ıce vpravo. Protoˇze dopˇredu v´ım, kolik beden se m˚ uˇze ve scénˇe nacházet resp. kolik ˇsablon znaˇcek je naˇcteno v pamˇeti, jsou polygony uloˇzeny v poli. Pˇri opˇetovné detekci je pozice bedny pouze upravena. Aplikace nav´ıc ukládá veˇskeré detekované bedny do STL vektoru, coˇz slouˇz´ı ˇcistˇe pro u ´ˇcely ladˇen´ı aplikace. To, jak´ ym zp˚ usobem je s novˇe detekovanou bednou nakládáno, závis´ı na módu, ve kterém aplikace bˇeˇz´ı. Exact Odometry Pokud je konkrétn´ı pˇrekáˇzka detekována poprvé, je jej´ı poloha uloˇzena do pole. Souˇcasnˇe je vypoˇc´ıtána a uloˇzena relativn´ı pˇresnost detekce. Je totiˇz t´ım vyˇsˇs´ı, ˇc´ım niˇzˇs´ı je vzdálenost a u ´hel, pod kter´ ym byla identifikuj´ıc´ı znaˇcka pozorována. Relativn´ı pˇresnost tedy urˇcuji pomoc´ı dvou promˇenn´ ych. Prvn´ı z nich je vztaˇzena k vzdálenosti detekované pˇrakáˇzky od robota: arange =

1 range

(4.11)

Druhá je vztaˇzena k u ´hlu, pod kter´ ym byla pozorována znaˇcka, pomoc´ı které byla pozice pˇrekáˇzky vypoˇc´ıtána: abearing

α = π − 1

(4.12)

2

Pokud jde o opˇetovnou detekci, docház´ı zde k aktualizaci pozice pomoc´ı pr˚ umˇeru p˚ uvodn´ı a novˇe z´ıskané polohy pˇrekáˇzky. Bˇehem v´ ypoˇctu je nav´ıc zapojeno váhován´ı zaloˇzené na relativn´ı pˇresnosti detekce. Protoˇze mám relativn´ı pˇresnost vyjádˇrenu dvˇema nesluˇciteln´ ymi parametry, je tˇreba pr˚ umˇerován´ı provést dvakrát a pak pr˚ umˇerovat v´ ysledek. To popisuje následuj´ıc´ı vzorec pro v´ ypoˇcet x-ové souˇradnice jednoho bodu pˇrekáˇzky jako pr˚ umˇeru dvou souˇradnic x1 a x2 :

x=

(x1 arange1 +x2 arange2 ) (arange1 +arange2 )

+

(x1 abearing1 +x2 abearing2 ) (abearing1 +abearing2 )

2

(4.13) 31

´ 4. Uloha 2 - Bludiˇstˇe Dále je nutné aktualizovat i relativn´ı pˇresnost. Aktualizace se pro obˇe vyjádˇren´ı provád´ı shodnˇe podle vzorce: a=

a21 + a22 a1 + a2

(4.14)

SLAM V pˇr´ıpadˇe, ˇze aplikace vyuˇz´ıvá systém SLAM, je pozice pˇrekáˇzky uloˇzena a na jej´ı zpracován´ı se poˇcká, dokud nebude ukonˇceno rozhl´ıˇzen´ı a nebudou detekovány vˇsechny pˇrekáˇzky. Pˇri bˇehu SLAM algoritmu jsou pozice pˇrekáˇzek a pozice robota aktualizovány tak, aby pozice pˇrekáˇzek co nejv´ıce odpov´ıdaly pozic´ım v minulém kroku a pozice robota co nejv´ıce odpov´ıdala pˇredpokládané pozici. Systém SLAM je detailnˇe popsán v kapitole 4.4.

4.4. SLAM Jak jiˇz bylo ˇreˇceno, systém SLAM je pouˇz´ıván k soubˇeˇznému mapován´ı a lokalizaci robota bˇehem pr˚ uzkumu neznámého prostˇred´ı. Existuje v´ıcero pˇr´ıstup˚ u, jak tento problém ˇreˇsit. Ja jsem zvolil velmi rozˇs´ıˇren´ y a standardnˇe vyuˇz´ıvan´ y systém zaloˇzen´ y na EKF (Extended Kalman Filter), tzv. EKF SLAM. Jedná se o iterativn´ı metodu, která pracuje ve tˇrech kroc´ıch: 1. Aktualizace stavu pomoc´ı odometrick´ ych dat (posunut´ı robota) 2. Aktualizace stavu pomoc´ı znovu detekovan´ ych znaˇcek 3. Pˇridán´ı novˇe detekovan´ ych znaˇcek do systému Cel´ y princip je detailnˇe popsán v ˇclánc´ıch [22] a [15], ve kter´ ych systém pracuje se znaˇckami (feature points), které jsou urˇceny pouze svou polohou a jsou vyjádˇreny v polárn´ıch souˇradnic´ıch. Já ale vyuˇz´ıvám jako znaˇcky celé pˇrekáˇzky, které jsou kromˇe pozice urˇceny jeˇstˇe u ´hlem natoˇcen´ı. Prvn´ı moˇznost´ı, kterou jsem implementoval, je postupovat u ´plnˇe pˇresnˇe podle ˇclánku [22] a poˇc´ıtat pouze s pozic´ı stˇredu pˇrekáˇzky. To k lokalizaci robota staˇc´ı. Bˇehem v´ ypoˇctu druhého kroku je upravena pozice robota. Pozdˇeji je moˇzno na základˇe této zmˇeny upravit i natoˇcen´ı pˇrekáˇzek. Druhou moˇznost´ı je upravit matice, se kter´ ymi systém poˇc´ıtá tak, aby byla rotace znaˇcek obsaˇzena od samého zaˇcátku. Systém, kter´ y jsem navrhl, nav´ıc pracuje s pozicemi znaˇcek v kartézsk´ ych souˇradnic´ıch mapy. Samotné rovnice z˚ ustávaj´ı stejné, pouhá zmˇena matic je dostaˇcuj´ıc´ı. V´ yhodou takto vytvoˇreného systému je, ˇze pˇri hledán´ı ˇreˇsen´ı je vyuˇzita i informace o rotaci pˇrekáˇzky, která byla v prvn´ım pˇr´ıpadˇe ignorována a zapoˇc´ıtána aˇz pozdˇeji, mimo hlavn´ı v´ ypoˇcty systému SLAM. Dále uvedu, jakou pˇresnˇe maj´ı podobu matice rozˇs´ıˇreného systému SLAM. Základem systému je stavov´ y vektor X a kovarianˇcn´ı matice P. Obˇe entity jsou témˇeˇr stejné jako v systému z ˇclánku [22] pouze budou obsahovat nav´ıc natoˇcen´ı pˇrekáˇzek. Stavov´ y vektor bude m´ıt tedy rozmˇer (3 + 3n) × 1 a kovarianˇcn´ı matice 32

4.4. SLAM (3+3n)×(3+3n), kde n je poˇcet znaˇcek (pˇrekáˇzek). Kovarianˇcn´ı matice se skládá z následuj´ıc´ıch submatic romˇeru 3×3:   P r,r P r,1 P r,2 · · · P r,n  P 1,r P 1,1 P 1,2 · · · P 1,n     P 2,r P 2,1 P 2,2 · · · P 2,n  P=   .. .. .. ..  . .  . . . . .  n,r n,1 n,2 n,n P P P ··· P M˚ uj systém dopˇredu v´ı, kolik pˇrekáˇzek je ve scénˇe, takˇze stavov´ y vektor ani kovarianˇcn´ı matice v pr˚ ubˇehu mapován´ı nemˇen´ı svou velikost, jak je tomu v ˇclánku [22]. Jedna konkrétn´ı iterace skládaj´ıc´ı z v´ yˇse zm´ınˇen´ ych tˇr´ı krok˚ u je spuˇstˇena pokaˇzdé, kdyˇz se robot pˇresune z jednoho m´ısta na druhé a rozhlédne se. Bˇehem jedné iterace jsou upraveny pozice detekovan´ ych znaˇcek a pozice robota (stavov´ y vektor) a kovarianˇcn´ı matice. Jednotlivé kroky budou detailnˇeji popsány dále.

4.4.1. Aktualizace stavu pomoc´ı odometrick´ ych dat V tomto kroku je nejprve zmˇenˇen stavov´ y vektor, do kterého se uloˇz´ı aktuáln´ı pozice robota. Oznaˇcme pozici robota tˇremi promˇenn´ ymi x, y a α, které pˇredstavuj´ı souˇradnice a u ´hel natoˇcen´ı. Promˇenné ∆x, ∆y a ∆α pak budou reprezentovat zmˇenu od minulé iterace. Jako aktuáln´ı pozici pouˇz´ıvám jednoduˇse pozici, kam mˇel robot doj´ıt. Jde pouze o pˇrepsán´ı prvn´ıch tˇr´ı prvk˚ u vektoru X. Dále je nezbytné aktualizovat kovarianˇcn´ı matici, ve které se prom´ıtne pˇresnost, s jakou se robot pohybuje. K v´ ypoˇctu je tˇreba jakobián modelu predikce A, kter´ y má následuj´ıc´ı tvar:   1 0 −∆y A = 0 1 ∆x  0 0 1 Zm´ınˇená pˇresnost pohybu robota je obsaˇzena v matici Q maj´ıc´ı následuj´ıc´ı tvar:   c∆x2 c∆x∆y c∆x∆α Q =  c∆y∆x c∆y 2 c∆y∆α , c∆α∆x c∆α∆y c∆α2 kde c je konstanta vyjadˇruj´ıc´ı procentuáln´ı pˇresnost, s jakou je urˇcena aktuáln´ı pozice robota. Porovnán´ım s pˇresnou pozic´ı robota z´ıskanou ze simulátoru jsem dospˇel k chybˇe zhruba 10 %, tud´ıˇz jsem konstantu c nastavil na hodnotu 0,1. Tuto hodnotu lze mˇenit v nastaven´ı aplikace (v souboru settings.h). Aktualizace kovarianˇcn´ı matice pak prob´ıhá v nekolika kroc´ıch podle následuj´ıc´ıch vzorc˚ u: Pr,r = APr,r A + Q (4.15) Pr,i = APr,i

(4.16)

Pi,r = (Pr,i )T

(4.17) 33

´ 4. Uloha 2 - Bludiˇstˇe

4.4.2. Aktualizace stavu pomoc´ı znovu detekovan´ ych znaˇ cek Znovu detekovan´ ych znaˇcek m˚ uˇze b´ yt v´ıce a ˇc´ım v´ıce jich je, t´ım pˇresnˇeji m˚ uˇze b´ yt systém aktualizován. Algoritmus zpracovává postupnˇe kaˇzdou zvláˇst’ a pˇri kaˇzdé aktualizuje stavov´ y vektor a kovarianˇcn´ı matici, ˇc´ımˇz je pozmˇenˇena pozice robota a vˇsech novˇe detekovan´ ych znaˇcek. Oznaˇcme pozici znaˇcky z minulé iterace jako vektor z a novˇe detekovanou pozici jako vektor h. Oba vektory maj´ı tˇri sloˇzky, kdy prvn´ı dvˇe pˇredstavuj´ı souˇradnice a tˇret´ı natoˇcen´ı pˇrekáˇzky. K v´ ypoˇctu aktualizace je zapotˇreb´ı jakobián modelu pozorován´ı, kter´ y ˇr´ıká, jak se zmˇen´ı poloha detekované znaˇcky, pokud se zmˇen´ı poloha robota. Jakobián je vypoˇc´ıtán jako parciáln´ı derivace funkce f, která vyjadˇruje relativn´ı pozici pˇrekáˇzky v˚ uˇci poloze robota:     f1 (x, y, α) (h0 − x) cos α − (h1 − y) sin α f(x, y, α) = f2 (x, y, α) = −(h0 − x) sin α + (h1 − y) cos α f3 (x, y, α) h2 − α Jakobián má pak následuj´ıc´ı podobou:   − cos α sin α −(h0 − x) sin α + (h1 − y) cos α H =  − sin α − cos α (h0 − x) cos α + (h1 − y) sin α  0 0 −1 Tento jakobián je tˇreba poˇc´ıtat pro kaˇzdou znaˇcku. V tomto kroku je nav´ıc tˇreba jakobián rozˇs´ıˇrit, aby bylo pozdˇeji moˇzné udˇelat maticov´ y souˇcin s kovarianˇcn´ı matic´ı. Pro kaˇzdou znaˇcku i tak dostaneme matici: r 0 1 ··· G = H 0 0 ··· Dále jsou k v´ ypoˇctu znaˇcky:  1 V = 0 0

i

···

−H · · ·

n 0

potˇreba matice, které zapoˇc´ıtavaj´ı nepˇresnost mˇeˇren´ı pozice  0 0 1 0 , 0 1



 (h0 − x)d 0 0 0 (h1 − y)d 0 . R= 0 0 b

Konstanta d reprezentuje procentuáln´ı chybu v detekci pˇrekáˇzky ve smyslu polohy. Konstanta b pˇredstavuje absolutn´ı chybu v detekci pˇrekáˇzky ve smyslu orientace. Bˇehem testován´ı pˇresnosti detekce (viz kapitolu 4.7.1) jsem dospˇel k závˇeru, ˇze pr˚ umˇerná chyba v mˇeˇren´ı polohy je 3,5% a pr˚ umˇerná chyba v mˇeˇren´ı rotace je 1◦ . Konstanty jsem tedy nastavil na hodnotu 0,035 a 0,0174533 (v radiánech). Lze je opˇet mˇenit v nastaven´ı aplikace. Nakonec je moˇzné provést aktualizaci systému podle následuj´ıc´ıch vzorc˚ u:

34

S = GPGT + VRVT

(4.18)

K = PGT S−1

(4.19)

4.5. Vizualizace mapy a hledán´ı nejkratˇs´ı cesty

X = X + K(z − h)

(4.20)

P = P − KSK

(4.21)

4.4.3. Pˇrid´ an´ı novˇ e detekovan´ ych znaˇ cek do syst´ emu V druhém kroku byly zpracovány veˇskeré znovu detekované znaˇcky, ale souˇcasnˇe byla aktualizována pozice robota i vˇsech znaˇcek, vˇcetnˇe tˇech detekovan´ ych poprvé. Jejich pozici tak staˇc´ı pouze pˇreˇc´ıst ze stavového vektoru X. Jeˇstˇe je ale tˇreba aktualizovat kovarianˇcn´ı matici. K tomu je opˇet tˇreba vypoˇc´ıtat jakobián modelu predikce vzhledem k pozici robota A a nav´ıc jeˇstˇe jakobián modelu predikce vzhledem k pozici znaˇcek, kter´ y má v naˇsem pˇr´ıpadˇe podobu jednotkové matice:   1 0 0 J = 0 1 0 , 0 0 1 Aktualizace kovarianˇcn´ı matice je opˇet provádˇena pro kaˇzdou novˇe pˇridanou znaˇcku zvláˇst’, a to podle následuj´ıc´ıch vzorc˚ u, ve kter´ ych i pˇredstavuje index právˇe pˇridávané znaˇcky a j postupnˇe index vˇsech ostatn´ıch znaˇcek: Pi,i = APr,r AT + JRJT

(4.22)

Pr,i = Pr,r AT

(4.23)

Pi,r = (Pr,i )T

(4.24)

Pi,j = A(Pr,j )T

(4.25)

Pj,i = (Pi,j )T

(4.26)

Obˇe varianty jsou v aplikaci implementovány a to, která bude vyuˇz´ıvána, je moˇzné nastavit v souboru settings.h pomoc´ı promˇenné SLAM MODE (hodnota 0 pˇredstavuje systém bez zapoˇc´ıtané rotace a hodnota 1 systém se zapoˇc´ıtanou rotac´ı). Obˇe varianty dosahuj´ı podobn´ ych v´ ysledk˚ u, avˇsak systém se zapoˇc´ıtanou rotac´ı trochu lépe vyrovnává chybu v rotaci pˇrekáˇzek a robota.

4.5. Vizualizace mapy a hled´ an´ı nejkratˇs´ı cesty Mapa se skládá z poˇca´tku souˇradné soustavy, pozice robota a pozic vˇsech pˇrekáˇzek. Bˇehem procházen´ı robota bludiˇstˇem je do mapy zakreslena i c´ılová pozice a vytyˇcená trasa, kterou má robot proj´ıt. Pokud je nastaven debug mód, jsou nav´ıc vykreslena i bezpeˇcnostn´ı pásma kolem pˇrekáˇzek (margin). Tato bezpeˇcnostn´ı 35

´ 4. Uloha 2 - Bludiˇstˇe pásma maj´ı stejn´ y tvar jako pˇrekáˇzky, pouze jsou vˇetˇs´ı a urˇcuj´ı m´ısto, kam se robot nesm´ı dostat, protoˇze by byl tak bl´ızko pˇrekáˇzce, ˇze by mohlo doj´ıt ke kolizi.

4.5.1. Zp˚ usob vykreslov´ an´ı mapy Tˇr´ıda Mapping je rozˇs´ıˇren´ım tˇr´ıdy QWidget z knihovny Qt. Jedná se o základn´ı tˇr´ıdu pouˇz´ıvanou k vykreslován´ı r˚ uzn´ ych entit. V aplikaci pouˇz´ıvám pouze vykreslován´ı geometrick´ ych element˚ u pomoc´ı tˇr´ıdy QPainter. Jak vykreslená mapa ˇ y kˇr´ıˇz pˇredstavuje poˇca´tek souˇradného vypadá, je vidˇet na obrázku 4.5. Cern´ systému. Zelená kruˇznice zobrazuje polohu robota, kde zelená ˇca´ra urˇcuje smˇer jeho natoˇcen´ı. Pokud je aplikace pˇripojena k simulátoru a vyuˇz´ıvá systém SLAM, je nav´ıc v mapˇe vykreslována i skuteˇcná pozice robota ˇcervenˇe, coˇz uˇzivateli ukazuje, jaké chyby se robot pˇri svém pohybu dopouˇst´ı. Modˇre jsou vykresleny aktuáln´ı polohy pˇrekáˇzek. V pˇr´ıpadˇe debug módu jsou vykreslovány veˇskeré v miˇ nulosti provedené detekce pˇrekáˇzek zelenou barvou. Cervenˇ e jsou zobrazeny skuteˇcné pozice pˇrekáˇzek, které jsou naˇcteny ze souboru. Verze simulátoru Webots EDU bohuˇzel nenab´ız´ı tˇr´ıdu Supervisor, která by umoˇznila naˇcten´ı skuteˇcn´ ych pozic pˇrekáˇzek pˇr´ımo ze simulátoru. Je tedy nutné pozice ruˇcnˇe pˇrepsat do souboru. Soubor, ze kterého jsou pozice naˇc´ıtány, jsem pojmenoval obstacleFile.txt. Pozice pˇrekáˇzky je uˇcena souˇradnicemi stˇredu a u ´hlem natoˇcen´ı. Formát zápisu vypadá následovnˇe: x1 x2 x3 . . . xn

y1 y2 y3 . . . yn

α1 α2 α3 . . . αn

Po naˇcten´ı souˇradnic stˇredu a u ´hlu natoˇcen´ı jsou vypoˇc´ıtány souˇradnice vˇsech ˇctyˇr ˇ vrchol˚ u ˇctverce, kter´ y reprezentuje pˇrekáˇzku. Ctverec je pak uloˇzen jako polygon ˇ do pamˇeti. Cten´ı souboru je tak provedeno pouze jednou pˇri spouˇstˇen´ı aplikace. Zobrazován´ı skuteˇcné polohy pˇrekáˇzek jde vypnout a zapnout v menu aplikace (klávesová zkratka CTRL + O). Tato moˇznost je dostupná pouze v pˇr´ıpadˇe, ˇze je aplikace pˇripojena k simulátoru. Dále je do mapy, jak jsem jiˇz v´ yˇse zm´ınil, zakreslena c´ılová pozice, kam se robot snaˇz´ı doj´ıt (ˇcerven´ y kˇr´ıˇzek), a vytyˇcená trasa. Ta je vizualizována jako posloupnost r˚ uˇzov´ ych u ´seˇcek, které spojuj´ı body, ´ cka pˇredstavuj´ıc´ı u kter´ ymi má robot proj´ıt. Useˇ ´sek, kter´ y má b´ yt právˇe pˇrekonán, je vˇzdy zv´ yraznˇena tuˇcnˇejˇs´ı ˇcarou. Bˇehem procházen´ı je tato u ´seˇcka pˇri dosaˇzen´ı koncového bodu vymazána. Margin kolem pˇrekáˇzek má tyrkysovou barvu. Pozice vˇsech bod˚ u jsou uloˇzeny v souˇradném systému mapy, kter´ y je vyjádˇren v metrech. Pro u ´ˇcely vykreslen´ı je tˇreba souˇradnice v metrech pˇrevést na souˇradnice v pixelech: xp = (range + xm − cx ) · (sw : 2 : range) 36

(4.27)

4.5. Vizualizace mapy a hledán´ı nejkratˇs´ı cesty

Obr´ azek 4.5. Vizualizace mapy: modré ˇctverce ... aktuáln´ı polohy pˇrekáˇzek, ˇcervené ˇctverce ... spr´ avn´ a poloha pˇrekáˇzek, tyrkysové ˇctverce ... margin kolem pˇrekáˇzek, zelené ˇctverce ... historie detekc´ı pˇrekáˇzek, ˇcern´ y kˇr´ıˇz ... poˇcátek souˇradné soustavy, zelen´ a kruˇznice ... aktu´ aln´ı poloha robota, ˇcerven´ y kˇr´ıˇzek ... c´ılová destinace, r˚ uˇzové u ´seˇcky ... napl´ anovan´ a trasa robota

yp = (range + ym − cy ) · (sh : 2 : range)

(4.28)

xp resp. yp jsou x-ová resp. y-ová souˇradnice bodu v pixelech. xm resp. ym jsou xová resp. y-ová souˇradnice bodu v metrech. range pˇredstavuje ˇs´ıˇrku i v´ yˇsku (mapa je ˇctvercová) oblasti, kterou mapa zachycuje (v metrech). cx resp. cy jsou x-ová resp. y-ová souˇradnice stˇredu mapy. sw a sh jsou ˇs´ıˇrka a v´ yˇska kresl´ıc´ı plochy v pixelech. Aplikace umoˇzn ˇuje stisknut´ım tlaˇc´ıtka myˇsi a následn´ ym taˇzen´ım posouvat mapu. Jedná se pouze o zmˇenu polohy stˇredu mapy cx a cy . Stejnˇe tak nab´ız´ı aplikace moˇznost zoomovat pomoc´ı koleˇcka myˇsi. V tomto pˇr´ıpadˇe jde o zmˇenu velikosti zobrazované oblasti range.

4.5.2. V´ ypoˇ cet trasy pˇri proch´ azen´ı bludiˇstˇ e K v´ ypoˇctu nejkratˇs´ı cesty z m´ısta A (aktuáln´ı poloha robota) do m´ısta B (c´ılová destinace) vyuˇz´ıvám knihovnu VisiLibity. Nalezená nejkratˇs´ı cesta je uloˇzena jako ˇretˇezec u ´seˇcek. Funkce getNextPointOnPath vypoˇc´ıtá nejkratˇs´ı cestu a poté vrát´ı pouze druh´ y bod (prvn´ı je ten, kde robot právˇe stoj´ı) na této cestˇe. Robot se poté k tomuto bodu vydá. Kdyby se mapa bˇehem cesty nezmˇenila (robot vˇsak neustále detekuje pˇrekáˇzky), vrátila by funkce pˇri dalˇs´ım volán´ı pouze dalˇs´ı bod, 37

´ 4. Uloha 2 - Bludiˇstˇe kter´ y je na ˇradˇe. Pokud by se ovˇsem mapa zmˇenila, byl by proveden nov´ y v´ ypoˇcet nejkratˇs´ı cesty. Jak jiˇz bylo ˇreˇceno, k v´ ypoˇctu nejkratˇs´ı cesty pouˇz´ıvá aplikace knihovnu VisiLibity vyuˇz´ıvaj´ıc´ı metodu grafu viditelnosti. Nejprve jsou vytvoˇreny spojnice vˇsech mezi sebou viditeln´ ych roh˚ u pˇrekáˇzek, v´ ychoz´ıho a c´ılového bodu. T´ım vznikne graf, ve kterém zb´ yvá nalézt nejkratˇs´ı cestu. Robot pak bude procházet po vybran´ ych bodech. M´ısto bod˚ u skuteˇcn´ ych prekáˇzek je vˇsak tˇreba pouˇz´ıt body ochranného pásma. To urˇcuje, jak bl´ızko se m˚ uˇze robot pˇri své cestˇe pˇribl´ıˇzit ˇ k pˇrekáˇzkám. C´ım bude bl´ıˇze, t´ım kratˇs´ı bude nalezená cesta, ale na druhou stranu vzroste riziko, ˇze robot nabourá napˇr. z d˚ uvodu nepˇresné detekce. Ochranné pásmo mus´ı b´ yt vˇsak aspoˇ n tak ˇsiroké, jak ˇsirok´ y je robot resp. jak´ y je polomˇer jeho bounding boxu. Já jsem zvolil ˇs´ıˇrku ochranného pásma 0,2 m, coˇz pˇri ˇs´ıˇrce robota 275 mm dává toleranci 62,5 mm. Skuteˇcné pˇrekáˇzky se kˇr´ıˇzit nemohou, ale jejich bezpeˇcnostn´ı pásma ano, pokud je mezi dvˇema pˇrekáˇzkami málo m´ısta, aby tudy robot proˇsel. V takovém pˇr´ıpadˇe knihovna VisiLibity neum´ı vypoˇc´ıtat nejkratˇs´ı cestu. Jednou z podm´ınek je prostˇred´ı s nepˇrekr´ yvaj´ıc´ımi se polygony. Nutnou uprávou knihovny bylo pˇridán´ı funkce, která by pˇrekr´ yvaj´ıc´ı se polygony slouˇcila. Pojmenoval jsem ji unite overlaping polygons. Aby mohla správnˇe fungovat, bylo tˇreba udˇelat jeˇstˇe dalˇs´ı drobné modifikace. Funkce postupnˇe testuje vˇsechny páry polygon˚ u, jestli se nepˇrekr´ yvaj´ı. K tomu jiˇz knihovna obsahovala funkci boundary distance, která poˇc´ıtá délku spoleˇcné hranice, jeˇz je v pˇr´ıpadˇe prol´ınaj´ıc´ıch se polygon˚ u nenulová. Pokud se prot´ınaj´ı, nahrad´ım je jedn´ım nov´ ym polygonem pˇredstavuj´ıc´ım jejich slouˇcen´ı. Jeho v´ ypoˇcet provád´ım postupn´ ym pˇridáván´ım bod˚ u, jeˇz lze popsat následuj´ıc´ımi kroky: 1. Vyber bod prvn´ıho (aktuáln´ıho) polygonu um´ıstˇen´ y nejv´ıce vlevo a pˇridej ho k v´ yslednému polygonu. 2. Pokud je posledn´ı pˇridan´ y bod vrcholem aktuáln´ıho polygonu, vyber jeho dalˇs´ı bod v CW poˇrad´ı. 3. Pokud posledn´ı pˇridan´ y bod nen´ı vrcholem aktuáln´ıho polygonu, pak je pr˚ useˇc´ıkem dvou hran. V takovém pˇr´ıpadˇe najdi hranu aktuáln´ıho polygonu, na které pr˚ useˇc´ık leˇz´ı, a vyber ten jej´ı vrchol, kter´ y leˇz´ı nalevo od hrany druhého polygonu. 4. Vytvoˇr z posledn´ıho a právˇe vybraného bodu u ´seˇcku. 5. Otestuj, jestli se u ´seˇcka neprot´ıná s nˇekterou z hran druhého polygonu. 6. Jestli ne, pˇridej koncov´ y bod u ´seˇcky k v´ yslednému polygonu. 7. Pokud ano, pˇridej pr˚ useˇc´ık u ´seˇcky a prot´ınaj´ıc´ı hrany k v´ yslednému polygonu. Oznaˇc druh´ y polygon jako aktuáln´ı. 8. Provádˇej body 2 aˇz 7 dokud se posledn´ı pˇridávan´ y bod nerovná prvn´ımu bodu. Jakmile jsou dva polygony slouˇceny, je tˇreba provést testován´ı pˇrekryvu od zaˇca´tku. Metoda nen´ı maximálnˇe efektivn´ı, ale vzhledem k n´ızkému poˇctu polygon˚ u zcela dostaˇcuj´ıc´ı. Po slouˇcen´ı jiˇz lze bez problému vypoˇc´ıtat nejkratˇs´ı cestu. 38

4.6. Ovládán´ı robota a jeho pohyb v bludiˇsti

4.6. Ovl´ ad´ an´ı robota a jeho pohyb v bludiˇsti K tomu, aby mohl robot u ´ˇcinnˇe mapovat bludiˇste, je nutné, aby j´ım procházel a rozhl´ıˇzel se. Aplikace nab´ız´ı dvˇe moˇznosti, jak robota rozpohybovat. Prvn´ı moˇznost´ı je manuáln´ı zadán´ı m´ısta, kam má robot doj´ıt. Druhou je aktivace automatického mapován´ı, kdy robot m´ısta vyb´ırá sám a procház´ı bludiˇstˇem, dokud nen´ı automatické mapován´ı vypnuto. Rozhl´ıˇzen´ı je základn´ım u ´konem, kter´ y robot neustále opakuje i bˇehem ch˚ uze.

4.6.1. Rozhl´ıˇ zen´ı Bˇehem rozhl´ıˇzen´ı robot nastav´ı hlavu do ˇsesti pozic, které jsou kombinac´ı natoˇcen´ı a sklopen´ı do nˇekolika u ´rovn´ı. Je to obdobné jako pˇri rozhl´ıˇzen´ı v u ´loze Stopovaná, pouze nen´ı nutné hlavu sklánˇet do nejniˇzˇs´ı u ´rovnˇe, protoˇze znaˇcky nejsou um´ıstˇeny na zemi, ale pomˇernˇe vysoko na stˇenˇe beden. V kaˇzdé poloze je poˇr´ızen sn´ımek, ve kterém jsou detekovány znaˇcky, pomoc´ı nichˇz jsou vypoˇc´ıtány polohy beden ve scénˇe. Rozhl´ıˇzen´ı jsem implementoval ve funkci lookAround.

4.6.2. Zad´ an´ı c´ılov´ e lokace uˇ zivatelem Pˇr´ıkaz lze zadat pomoc´ı menu aplikace (klávesová zkratka CTRL + G) a poté jiˇz staˇc´ı kliknout na poˇzadované m´ısto na mapˇe. Na m´ıstˇe se vykresl´ı pro kontrolu ˇcerven´ y kˇr´ıˇzek. Souˇradnice v pixelech jsou pˇrevedeny na souˇradnice na mapˇe. Robot se nejprve natoˇc´ı smˇerem, kam má doj´ıt, a rozhlédne se. Pokud bˇehem rozhl´ıˇzen´ı detekuje nˇejakou pˇrekáˇzku, dojde k aktualizaci mapy. Nyn´ı je spuˇstˇen algoritmus nalezen´ı nejkratˇs´ı cesty. Cesta se m˚ uˇze skládat z v´ıce bod˚ u, kter´ ymi by mˇel robot proj´ıt. V kaˇzdém bodˇe se robot znovu rozhlédne a pokud detekuje nˇejakou znaˇcku, pˇrepoˇc´ıtá nejkratˇs´ı cestu. Opˇetovnou detekc´ı po uraˇzen´ı urˇcité vzdálenosti totiˇz mohlo doj´ıt k upˇresnˇen´ı polohy pˇrekáˇzek, nebo dokonce k detekci nov´ ych, dosud neobjeven´ ych. Pokud by mˇel robot nav´ıc uj´ıt pˇr´ımoˇcaˇre v´ıce neˇz jeden metr, je tato trajektorie rozdˇelena a robot zastav´ı uprostˇred, aby se rozhlédl. Jakmile robot doraz´ı na zadané m´ısto, je moˇzné zadat nov´ y pˇr´ıkaz. Pokud je m´ısto nedosaˇzitelné (uvnitˇr pˇrekáˇzky nebo jej´ıho bezpeˇcnostn´ıho pásma), je na to uˇzivatel upozornˇen ve stavovém ˇrádku aplikace a je vyzván, aby vybral jiné m´ısto. Bˇehem ch˚ uze se m˚ uˇze mapa zmˇenit a nedosaˇzitelnost m´ısta se m˚ uˇze zjistit pozdˇeji. V tom pˇr´ıpadˇe je robot zastaven, uˇzivatel je upozornˇen zprávou ve stavovém ˇrádku a je moˇzné zadat dalˇs´ı pˇr´ıkaz.

4.6.3. Automatick´ e mapov´ an´ı Jakmile je automatické mapován´ı aktivováno (klávesová zkratka CTRL + S), robot sám neustále vyb´ırá m´ısta, na která se vydá. Ch˚ uze na vybrané m´ısto pak prob´ıhá obdobnˇe jako pˇri v´ ybˇeru uˇzivatelem, pouze se robot v kaˇzdém c´ılovém bodˇe otoˇc´ı kolem dokola a pˇritom se rozhl´ıˇz´ı. M´ısta jsou vyb´ırána náhodnˇe. Nejprve je náhodnˇe vybrána jedna z jiˇz detekovan´ ych pˇrekáˇzek a následnˇe je opˇet náhodnˇe vybrána jedna ze ˇctyˇr jej´ıch stˇen, ke které má robot pˇristoupit. Robot 39

´ 4. Uloha 2 - Bludiˇstˇe se tak nikdy nedostane mimo bludiˇstˇe, ale zároveˇ n se dostane za pˇrekáˇzky, aby vidˇel dále. Aktuálnˇe vybrané m´ısto je vˇzdy v mapˇe zakresleno ˇcerven´ ym kˇr´ıˇzkem. Aplikace opˇet kontroluje i bˇehem ch˚ uze, jestli je m´ısto dosaˇzitelné. Pokud nen´ı, je vybráno jiné. Automatické mapován´ı je moˇzné kdykoliv pˇreruˇsit (klávesová zkratka CTRL + E). Robot vˇsak jeˇstˇe dojde na naposled vybrané m´ısto.

4.7. Zhodnocen´ı dosaˇ zen´ ych v´ ysledk˚ u Pro demonstraci této u ´lohy jsem také natoˇcil sérii vide´ı. Dvˇe se vˇenuj´ı detekci pˇrekáˇzek a procházen´ı robota bludiˇstˇem za pouˇzit´ı pˇresného naˇc´ıtán´ı pozice robota ze simulátoru. V nich je vidˇet pˇresnost, s jakou jsou pˇrekáˇzky detekovány, a funkˇcnost algoritm˚ u ovládaj´ıc´ıch robota a hladej´ıc´ıch nejkratˇs´ı cestu. Zbylá dvˇe videa zachycuj´ı práci systému SLAM. Ten nen´ı pˇresn´ y a na videu je vidˇet, ˇze po pár iterac´ıch zaˇcne docházet k rychlému rozladˇen´ı systému. Protoˇze nezbytnou souˇcást´ı aplikace je vizualizace mapy, nenatáˇcel jsem videa pˇr´ımo v simulátoru. Pouˇzil jsem software sn´ımaj´ıc´ı vybranou ˇca´st obrazovky poˇc´ıtaˇce. Ve videu je tak moˇzné vidˇet celé okno simulátoru obsahuj´ıc´ı mimo jiné ukazatel synchronizace a hned vedle okno obsluˇzné aplikace zobrazuj´ıc´ı mapu. Vˇsechna videa jsou opˇet k dispozici na pˇriloˇzeném DVD.

4.7.1. Pˇresnost mapov´ an´ı Mapován´ı je sloˇzitou u ´lohou, protoˇze detekce pˇrekáˇzek nen´ı 100 % pˇresná a je závislá na pozici robota. Souˇcasnˇe vˇsak ani pozice robota nen´ı pˇresnˇe známa. V takov´ ych pˇr´ıpadech je tˇreba vyuˇz´ıt metodu souˇcasné lokalizace robota a mapován´ı prostˇred´ı (SLAM). Systém vycház´ı z detekce landmark˚ u (v mém pˇr´ıpadˇe pˇrekáˇzek) v minulém kroku a z pozice, kde by se robot mˇel podle oˇcekáván´ı nacházet. Systém pak ˇreˇs´ı v podstatˇe optimalizaˇcn´ı u ´lohu, kde se snaˇz´ı doc´ılit ˇ ım pˇresnˇejˇs´ı toho, aby se polohy pˇrekáˇzek a pozice robota co nejménˇe zmˇenily. C´ bude detekce znaˇcek a odhad polohy robota, t´ım vˇetˇs´ı má systém ˇsanci na u ´spˇech. U mobiln´ıch robot˚ u, pohybuj´ıc´ıch se na kolech, je vyuˇz´ıváno odometrick´ ych u ´daj˚ u, ze kter´ ych je moˇzno vypoˇc´ıtat, kam se robot za posledn´ı ˇcasov´ y u ´sek posunul. I v takovém pˇr´ıpadˇe docház´ı k chybˇe ve v´ ypoˇctu, protoˇze kola mohou prokluzovat apod. Robot Nao je ale humanoidn´ı robot pohybuj´ıc´ı se po nohou. Nam´ısto odometrie mus´ım spoléhat na to, ˇze robot od minulého kroku doˇsel na m´ısto, kam jsem ho poslal. Chyba ale v tomto pˇr´ıpadˇe m˚ uˇze b´ yt veliká zejména z toho d˚ uvodu, ˇze uraˇzen´ y u ´sek je daleko vˇetˇs´ı. Aplikace nab´ız´ı dva módy mapován´ı. Prvn´ı z nich spoléhá na to, ˇze pˇresná pozice robota je známa, coˇz je v pˇr´ıpadˇe pˇripojen´ı k simulátoru pravda. V tomto módu je tedy moˇzno vˇerohodnˇe otestovat pˇresnost detekce polohy pˇrekáˇzek. V druhém módu je pak moˇzno testovat celkovou pˇresnost pˇri pouˇzit´ı systému SLAM. Pˇresnost detekce polohy pˇrek´ aˇ zek Narozd´ıl od u ´lohy Stopovaná jsou v této u ´loze znaˇcky um´ıstˇeny svisle, takˇze u ´hel, pod kter´ ym se robot na znaˇcky d´ıvá, nezávis´ı na vzdálenosti. Naopak je 40

4.7. Zhodnocen´ı dosaˇzen´ ych v´ ysledk˚ u tˇreba vz´ıt v potaz natoˇcen´ı bedny v˚ uˇci robotovi. Bˇehem testu jsem tedy bednu um´ıst´ıl do pˇeti r˚ uzn´ ych vzdálenost´ı a natoˇcil ji pod pˇeti r˚ uzn´ ymi u ´hly (vˇzdy na jednu stranu, protoˇze pˇredpokládám symetrii). Porovnával jsem polohu detekované bedny s pˇredem známou polohou z´ıskanou ze simulátoru. Chyba je vyjádˇrena jako velikost posunut´ı stˇred˚ u (v metrech) a absolutn´ı rozd´ıl v natoˇcen´ı (ve stupn´ıch). Namˇeˇrené v´ ysledky jsou uvedeny v tabulkách 4.1 a 4.2. V prvn´ı z nich je uvádˇeno posunut´ı stˇred˚ u a nav´ıc je tu uvedena i pr˚ umˇerná relativn´ı chyba, která vycház´ı zhruba 3,5 %. V druhé tabulce je uvádˇen rozd´ıl natoˇcen´ı a také jeho pr˚ umˇerné hodnoty, které vycház´ı pˇribliˇznˇe 1◦ . Jak z namˇeˇren´ ych hodnot vypl´ yvá, chyba ve smyslu ˇspatné detekce stˇredu znaˇcky je pˇr´ımo u ´mˇerná vzdálenosti bedny. Pˇri mal´ ych vzdálenostech pak pˇriliˇs nezáleˇz´ı na natoˇcen´ı bedny v˚ uˇci robotu. Tento parametr zaˇc´ıná rozhodovat aˇz pˇri detekci na vˇetˇs´ı vzdálenost. Chyba v urˇcen´ı natoˇcen´ı bedny je naopak v´ıce nahodilá, avˇsak také je patrné, ˇze v pr˚ umˇeru roste se vzdálenost´ı a natoˇcen´ım bedny v˚ uˇci robotovi. Dosaˇzená pˇresnost je pro zadanou u ´lohu dostaˇcuj´ıc´ı. Tabulka 4.1. V´ ysledky testov´ an´ı pˇresnosti detekce beden vyjádˇreny jako vzdálenost stˇredu detekované bedny od správné pozice v závislosti na vzdálenosti bedny od robota a u ´hlu jej´ıho natoˇcen´ı v˚ uˇci robotovi.

´ Uhel [◦ ]

0 12 24 45 60 Rel. chyba [%]

0,7 0,0158 0,0210 0,0194 0,0174 0,0159 2,5577

Vzd´ alenost 1,0 1,5 0,0262 0,0457 0,0353 0,0212 0,0295 0,0396 0,0430 0,0416 0,0615 0,0501 3,9105 2,6431

[m] 2,0 0,0604 0,0729 0,0562 0,0690 0,1599 4,1835

2,5 0,1092 0,0952 0,0701 0,0961 0,1429 4,1082

Rel. chyba [%] 3,0625 3,0788 2,7970 3,3709 5,0938 3,4806

Tabulka 4.2. V´ ysledky testován´ı pˇresnosti detekce beden vyjádˇreny jako odchylka natoˇcen´ı bedny v z´ avislosti na vzdálenosti bedny od robota a u ´hlu jej´ıho natoˇcen´ı v˚ uˇci robotovi.

´ Uhel [◦ ]

0 12 24 45 60 Pr˚ um. chyba [◦ ]

0,7 1,0544 0,5392 0,3455 1,3671 0,8689 0,8689

Vzd´ alenost 1,0 1,5 0,2817 0,7706 0,3054 0,0292 0,0102 0,3209 1,9309 0,1851 1,9956 0,0103 0,9047 0,2632

[m] 2,0 0,6956 1,2061 1,3321 1,0657 0,4240 0,9447

2,5 1,1293 1,1293 4,4576 1,7131 0,8159 1,9062

Pr˚ um. chyba [◦ ] 0,7863 0,6990 1,2933 1,2524 0,8568 0,9776

Pˇresnost syst´ emu SLAM Je tˇeˇzké exaktnˇe ohodnotit pˇresnost systému SLAM. Jeho u ´kolem je upravit pozice nalezen´ ych pˇrekáˇzek a robota v závislosti na tom, jak byly vypoˇc´ıtany 41

´ 4. Uloha 2 - Bludiˇstˇe v minul´ ych kroc´ıch. Do jaké m´ıry se to správnˇe podaˇr´ı, záv´ıs´ı na pˇresnosti, s jakou byly detekovány jednotlivé znaˇcky, a pak také na tom, jak moc je robot vych´ ylen od pˇredpokládané pozice. M˚ uˇze se stát, ˇze nˇekterá pˇrekáˇzka bude nalezena ˇspatnˇe. ˇ ım vˇetˇs´ı je vˇsak jejich poˇcet, t´ım menˇs´ı bude dopad jedné chybnˇe detekované. C´ Vu ´loze Bludiˇstˇe je bohuˇzel pˇrekáˇzek velmi málo, takˇze se v momentˇe, kdy dojde k vˇetˇs´ım chybám v detekci nˇekolika z nich, zaˇcne systém rozlad’ovat. D˚ uleˇzitá je rovnˇeˇz poloha robota. Chyba v urˇcen´ı polohy robota je obvykle t´ım menˇs´ı, ˇc´ım menˇs´ı uraz´ı vzdálenost mezi jednotliv´ ymi iteracemi systému SLAM. V této u ´loze je bohuˇzel tato vzdálenost pomˇernˇe velká. Pro kaˇzdou iteraci je totiˇz tˇreba, aby se robot rozhlédl, coˇz je ˇcasovˇe velmi nároˇcn´ yu ´kon. Z toho d˚ uvodu nelze v´ ypoˇcet provádˇet ˇcastˇeji. V´ ysledkem je, ˇze systém SLAM, jak jej vyuˇz´ıvám, nen´ı pro u ´lohu pˇr´ıliˇs vhodn´ y. V prvn´ıch nˇekolika iterac´ıch jsou v´ ypoˇcty pomˇernˇe pˇresné. Je to zp˚ usobeno t´ım, ˇze pozice robota je v okamˇziku spuˇstˇen´ı algoritmu urˇcena naprosto pˇresnˇe. Na chybˇe v pozici robota velmi závis´ı chyba, s jakou budou nalezeny pˇrekáˇzky. S kaˇzdou dalˇs´ı iterac´ı se systém pomalu rozlad’uje, protoˇze iterace nejsou spouˇstˇeny dostateˇcnˇe ˇcasto a prostˇred´ı obsahuje málo znaˇcek. Postupnˇe se rozlad’ován´ı zrychluje, aˇz zaˇcne systém dávat zcela chybné v´ ysledky. Jak jiˇz bylo ˇreˇceno, tento jev nelze pˇresnˇe ˇc´ıselnˇe vjádˇrit. Dle mého názoru o pˇresnosti systému SLAM nejv´ıce vypov´ıdaj´ı videa, která jsem natoˇcil. Zobrazuj´ı prvn´ıch nˇekolik iterac´ı (jednotlivé iterace jsou spouˇstˇeny po rozhlédnut´ı robota, které je souˇcást´ı jeho ch˚ uze), ve kter´ ych je nejprve vidˇet, jak systém vyrovnává chyby. Pozdˇeji je bohuˇzel vidˇet, jak se systém zaˇc´ıná rozlad’ovat a nestaˇc´ı chyby korigovat. Videa jsou uloˇzena na pˇriloˇzeném DVD.

4.7.2. Hodnocen´ı simul´ atoru Vu ´loze Stopovaná byly jiˇz odhaleny základn´ı problémy simulátoru Webots. Bˇehem práce na této u ´loze jsem jiˇz na ˇzádné dalˇs´ı nenarazil. Naopak, simulátor mi poskytl znaˇcné v´ yhody pˇredevˇs´ım v tom, ˇze jsem si mohl velmi snadno pˇripravit scénu, která by mi co nejlépe pomohla u ´lohu odladit. Nejvˇetˇs´ı v´ yhodou byla bezesporu znalost pˇresné polohy pˇrekáˇzek, takˇze jsem vˇzdy vˇedˇel, jaké pˇresnosti aplikace bˇehem detekce dosahuje. Zde mi trochu scházela tˇr´ıda Supervisor, která by mi umoˇzn ˇovala pˇristupovat ke vˇsem objekt˚ um ve scénˇe. S jej´ı pomoc´ı bych mohl pozici pˇrekáˇzek naˇc´ıtat automaticky. Bez n´ı jsem musel pozice ruˇcnˇe pˇrepisovat, coˇz je pˇri ˇcast´ ych zmˇenách scény zdlouhavé. Dalˇs´ı v´ yhodou je, ˇze simulátor umoˇzn ˇuje robota mˇenit (zmˇenou jeho prototypového souboru). Pro u ´ˇcely testován´ı tak lze z´ıskat informace, kter´ ych bychom jinak nedosáhli. Já jsem napˇr´ıklad robota vybavil zaˇr´ızen´ım GPS, pomoc´ı nˇehoˇz jsem zjiˇst’oval jeho aktuáln´ı pozici. Touto u ´pravou jsem se vyhnul potˇrebˇe tˇr´ıdy Supervisor ke zjiˇstˇen´ı pozice robota. Aplikaci jsem bohuˇzel nemˇel moˇznost testovat na skuteˇcném robotovi z d˚ uvodu nedostatku ˇcasu a toho, ˇze nemám k dipozici bludiˇstˇe. Nicménˇe, aplikaci jsem naprogramoval tak, ˇze by mˇela bez problém˚ u pracovat i se skuteˇcn´ ym robotem. Velk´ ym rozd´ılem je, ˇze kamera simulovaného robota poskytuje bezchybné sn´ımky, které nejsou zat´ıˇzeny ˇza´dn´ ym ˇsumem. V praxi by se mohlo stát, ˇze detekce bude 42

4.7. Zhodnocen´ı dosaˇzen´ ych v´ ysledk˚ u ménˇe pˇresná z d˚ uvodu ménˇe kvalitn´ıch sn´ımk˚ u. Simulátor bohuˇzel neposkytuje ˇza´dnou vestavˇenou funkci ke zhorˇsen´ı kvality sn´ımku. Nab´ız´ı pouze zamlˇzen´ı, pˇr´ıpadnˇe sn´ıˇzen´ı (ale i zv´ yˇsen´ı) rozliˇsen´ı. Sn´ımek je samozˇrejmˇe moˇzno zat´ıˇzit ˇsumem pozdˇeji, aˇz pˇri jeho zpracováván´ı. Já jsem zkouˇsel sn´ımek zat´ıˇzit ˇsumem z normáln´ıho rozdˇelen´ı se smˇerodatnou odchylkou 20. Kvalita detekce se vˇsak v´ yraznˇe nezmˇenila, proto pˇredpokládám, ˇze by aplikace mˇela spolehlivˇe pracovat i se skuteˇcn´ ym robotem. Celkovˇe byl simulátor Webots velk´ ym pˇr´ınosem.

43

5. Shrnut´ı probl´ em˚ u se simul´ atorem Webots Bˇehem práce na u ´lohách jsem odhalil nˇekolik problém˚ u, kter´ ym mus´ı v´ yvojáˇr bˇehem v´ yvoje aplikac´ı pro robota Nao pomoc´ı simulátoru Webots ˇcelit. Problémy a jejich ˇreˇsen´ı jsou detailnˇe popsány v kapitolách zab´ yvaj´ıc´ıch se ˇreˇsen´ım u ´loh. Pro pˇrehlednost zde uvedu seznam tˇechto problém˚ u, jejich krátkou charakteristiku a zp˚ usob ˇreˇsen´ı. Dále zm´ın´ım i problémy drobnˇejˇs´ıho rázu nebo pouze dojmy z práce se simulátorem, které nebyly v´ yˇse zm´ınˇeny, protoˇze se pˇr´ımo net´ ykaly u ´loh.

5.1. Probl´ emy 5.1.1. Synchronizace kontroleru NaoQi a simul´ atoru Webots Charakteristika probl´ emu V komunikaci mezi kontrolerem NaoQi a kontrolerem naoqi for webots nen´ı zavedena ˇzádná synchronizace. V d˚ usledku toho m˚ uˇze pˇri zat´ıˇzen´ı poˇc´ıtaˇce docházet k nepˇredv´ıdan´ ym chybám v simulaci robota, které jsou zp˚ usobeny t´ım, ˇze simulátor nest´ıhá ˇc´ıst informace, které kontroler NaoQi poskytuje a neustále aktualizuje. Nejv´ıce je tato chyba znát pˇri pohybu robota, kde se mouhou ztrácet nˇekteré informace o tom, do jak´ ych poloh se maj´ı nastavit veˇskeré klouby. Pˇri ch˚ uzi tak robot m˚ uˇze j´ıt zcela ˇspatn´ ym smˇerem. ˇ sen´ı probl´ Reˇ emu Jedná se o nejvˇetˇs´ı problém pˇri pouˇzit´ı simulátoru Webots spoleˇcnˇe s robotem Nao. Zp˚ usob˚ u, jak pˇristoupit k tomuto problému je v´ıce, ale nelze jej zcela odstranit. Ve své práci jsem se zamˇeˇril pouze na problematiku s ch˚ uz´ı robota, protoˇze je to jediná oblast, kde byla absence synchronizace skuteˇcn´ ym problémem. 1. Provádˇet simulaci na v´ ykonném PC s v´ ykonn´ ym GPU bez jiného zat´ıˇzen´ı, aby komunikace prob´ıhala správnˇe i bez synchronizace. 2. Pouˇz´ıvat k ch˚ uzi funkci setWalkTargetVelocity, kde je moˇzné zpomalit pohyb ch˚ uze, a t´ım omezit vliv asynchronn´ı komunikace mezi kontrolery. 3. Vyuˇz´ıt k ch˚ uzi pˇredem definované pohyby uloˇzené v .motion souborech simulátoru Webots Postupy k ˇreˇsen´ı problému jsou detailnˇeji popsány v kapitole 3.4.3. 44

5.1. Problémy

5.1.2. Pˇrenos obrazu Charakteristika probl´ emu Pˇrenos obrazu z kamery do obsluˇzné aplikace, která robota ˇr´ıd´ı, je provádˇen ve dvou kroc´ıch. Nejprve je obraz pˇrenesen ze simulátoru do sd´ılené pamˇeti kontroleru NaoQi. Odtud je poté teprve zkop´ırován do pamˇeti obsluˇzné aplikace. Problém je v komunikaˇcn´ım protokolu, pomoc´ı kterého jsou pˇrenáˇsena data ze sd´ılené pamˇeti kontroleru NaoQi. Komunikace je velmi pomalá a pˇri práci s NaoQi, které je obsaˇzeno v Aldebaran SDK verze 1.6.13, lze dosáhnout maximálnˇe pˇrenosové rychlosti 1 fps. Protokol je stále upravován a jiˇz v dalˇs´ı verzi je moˇzné dosáhnout vyˇsˇs´ı rychlosti, která je vˇsak pro aplikace, kde je obraz velmi ˇcasto vyuˇz´ıván, nedostaˇcuj´ıc´ı. ˇ sen´ı probl´ Reˇ emu Pˇri práci se simulátorem vˇsak nen´ı potˇreba obraz nahrávat nejprve do pamˇeti kontroleru NaoQi, ale je moˇzné a v´ yhodné pos´ılat obraz rovnou obsluˇzné aplikaci. K tomuto u ´ˇcelu lze pouˇz´ıt meziprocesovou komunikaci a obraz ukládat do vytvoˇrené sd´ılené pamˇeti, do které mohou pˇristupovat jak kontroler naoqi for webots, tak obsluˇzná aplikace. T´ımto zp˚ usobem lze dosáhnout bez problém˚ u pˇreˇ sen´ı je nosové rychlost´ı 30 fps, coˇz je maximum, které zvládne kamera robota. Reˇ detailnˇe popsáno v kapitole 3.1.

5.1.3. Nepodporovan´ e syst´ emy robota Nao v simul´ atoru Webots Charakteristika probl´ emu Simuláˇcn´ı prostˇred´ı a model robota nepodporuj´ı nˇekteré systémy, kter´ ymi skuteˇcn´ y robot Nao disponuje. Seznam vˇsech tˇechto systém˚ u, které nemohou b´ yt simulovány, uvád´ım v kapitole 2.3.1. ˇ sen´ı probl´ Reˇ emu Podpora nˇekter´ ych systém˚ u by mohla b´ yt dodˇelána u ´pravou prototypového souboru robota a kontroleru. Doporujuˇcuji vˇsak sp´ıˇse vyˇckat na vydán´ı nov´ ych verz´ı simulátoru a prototypov´ ych soubor˚ u robota Nao, ve kter´ ych se postupnˇe objevuje podpora nov´ ych systém˚ u.

5.1.4. Nedostupn´ e funkce v simul´ atoru Webots verze EDU Charakteristika probl´ emu ˇ Skoln´ ı verze simulátoru Webots nenab´ız´ı nˇekteré funkce, které jsou dostupné ve verzi PRO. Kompletn´ı popis, kde jsou vidˇet rozd´ıly mezi obˇema verzemi, je moˇzné nalézt na stránkách spoleˇcnosti [4, Store/Webots]. Nejv´ıce vˇsak v´ yvojáˇr m˚ uˇze postrádat tˇr´ıdu Supervisor, pomoc´ı které je moˇzné ˇc´ıst, ale také mˇenit veˇskeré 45

5. Shrnut´ı problém˚ u se simulátorem Webots parametry scény bˇehem simulace. Bez této tˇr´ıdy je zjiˇst’ován´ı pozice robota nebo pohybován´ı pˇredmˇety sloˇzitˇejˇs´ı. Nen´ı vˇsak nemoˇzné. ˇ sen´ı probl´ Reˇ emu Bˇehem práce na u ´lohách jsem potˇreboval zjiˇst’ovat pozici robota ve scénˇe. Pomoc´ı tˇr´ıdy Supervisor by ˇslo tento u ´daj snadno zjistit pˇreˇcten´ım parametru scény, kter´ y ˇ tuto pozici udává. Reˇsen´ım ve verzi EDU je pouˇzit´ı modulu GPS, kter´ y je moˇzno robotovi virtuálnˇe ”nainstalovat”zmˇenou prototypového souboru. Detailn´ı popis tohoto postupu jsem uvedl v kapitole 3.4.3. Tˇr´ıda Supervisor by mohla b´ yt pouˇzita také k pohybován´ı pˇredmˇety bˇehem simulace. Dalo by se toho vyuˇz´ıt napˇr´ıklad pˇri testován´ı algoritm˚ u pro trackován´ı obliˇceje, kdy by tˇr´ıda Supervisor pohybovala obliˇcejem ve scénˇe. Pokud bychom chtˇeli tohoto efektu doc´ılit ve verzi EDU, je tˇreba kaˇzd´ y pohybuj´ıc´ı se pˇredmˇet vymodelovat jako robota. Tento postup je sloˇzitˇejˇs´ı a pracnˇejˇs´ı, ale je moˇzné dosáhnout v podstatˇe stejného v´ ysledku. Postup je následuj´ıc´ı: 1. Vytvoˇrit model robota, kter´ y bude pˇredstavovat objekt, kter´ ym chceme h´ ybat. 2. Pˇriˇradit robotovi 3 lineárn´ı servo motory, které budou m´ıt osy navzájem kolmé. T´ım bude moˇzné doc´ılit toho, ˇze se bude moci objekt h´ ybat do vˇsech stran. 3. Pˇriˇradit robotovi odbdobn´ ym zp˚ usobem 3 rotaˇcn´ı servo motory, které budou m´ıt taktéˇz osy navzájem kolmé. T´ım bude moˇzné doc´ılit toho, ˇze se bude moci objekt libovolnˇe otáˇcet. 4. Napsat vytvoˇrenému robotovi jednoduch´ y kontroler, kter´ y s n´ım bude pohybovat, jak budeme cht´ıt. 5. Pokud u robota nebude nastavena fyzika, bude se moci ve scénˇe pohybovat zcela bez omezen´ı.

5.2. Evaluace prostˇred´ı 5.2.1. Zmˇ ena parametr˚ u sc´ eny Simulátor Webots obˇcas vykazuje nestandardn´ı chován´ı pˇri zmˇenˇe parametr˚ u scény. Prvn´ım pˇr´ıkladem je, ˇze pokud spust´ıme simulaci, poté ji pˇreruˇs´ıme, zmˇen´ıme nˇejak´ y parametr (napˇr´ıklad pozici robota) a poté simulaci opˇet rozbˇehneme, tak se m˚ uˇze stát, ˇze se parametry vrát´ı na svou p˚ uvodn´ı hodnotu. K tomuto jevu docház´ı, zdá se, zcela nahodile. Avˇsak jakmile k nˇemu jednou dojde, docház´ı k nˇemu neustále aˇz do restartován´ı celého simulátoru. Tento problém m˚ uˇze velice zdrˇzovat, pokud chceme napˇr´ıklad v pr˚ ubehu simulace mˇenit ˇcasto pozici robota, coˇz jsem já konkrétnˇe potˇreboval pˇri mˇeˇren´ı pˇresnosti detekce znaˇcek na r˚ uznou vzdálenost. Dalˇs´ım pˇr´ıkladem je jev, kdy docház´ı ke zmˇenˇe natoˇcen´ı kamery, pokud zmˇen´ıme 46

5.2. Evaluace prostˇred´ı kontroler robota. Kamera je ˇcasto natoˇcena do opaˇcného smˇeru, takˇze nen´ı vidˇet scéna a je pak tˇeˇzké ji natoˇcit zpˇet (viz ovládán´ı kamery 5.2.2).

5.2.2. Ovl´ ad´ an´ı kamery Kamera se v simulátoru Webots ovládá ponˇekud neprakticky, coˇz m˚ uˇze v´ yvojáˇre zdrˇzovat. K ovládán´ı kamery se pouˇz´ıvá myˇs, kde je zoomován´ı ˇr´ızeno jednoduˇse koleˇckem a posun kamery ja aktivován pˇri stisku pravého tlaˇc´ıtka. Tyto dvˇe funkce pracuj´ı dobˇre, ale problém nastává pˇri rotaci kamery. K aktivaci rotace se pouˇz´ıvá levé tlaˇc´ıtko. Kamera ovˇsem rotuje kolem bodu, kter´ y je oznaˇcen v momentˇe stisku tlaˇc´ıtka. Na tento zp˚ usob se dá zvyknout, pokud hled´ıme na scénu tak, abychom vidˇeli dost objekt˚ u, kolem kter´ ych m˚ uˇzeme rotovat. Pokud ale kamera ujede (coˇz se m˚ uˇze stát samovolnˇe zmˇenou nˇejak´ ych parametr˚ u scény, viz kapitolu 5.2.1) a zaˇcne hledˇet do prázdna, je velmi obt´ıˇzné ji natoˇcit zpˇet, aby opˇet hledˇela na scénu.

47

6. Z´ avˇ er Seznámil jsem se s prostˇred´ım simulátoru Webots a byl jsem schopen implementovat ˇreˇsen´ı dvou u ´loh, které se zab´ yvaj´ı prostorovou orientac´ı a pohybem robota Nao. Prvn´ı u ´loha pˇrinesla moˇznost vytváˇret trasu ze série znaˇcek, které bude robot sledovat a pohybovat se tak po zvolené trajektorii z m´ısta A do m´ısta B. V´ ysledn´ y kód lze integrovat do vˇetˇs´ıch aplikac´ı, kde bude pohyb v prostoru pouze d´ılˇc´ım u ´konem. Ve druhé u ´loze jsem se vˇenoval mapován´ı prostˇred´ı, ve kterém jsou objekty oznaˇceny znaˇckami. Dosáhl jsem dostateˇcnˇe vysoké pˇresnosti detekce pˇrekáˇzek, v pˇr´ıpadˇe, ˇze je poloha robota známá. Aplikace je schopná rovnˇeˇz vypoˇc´ıtat nejkratˇs´ı cestu ke zvolenému m´ıstu na mapˇe a celou mapu vizualizovat. Systém vyuˇz´ıvaj´ıc´ı detekci objekt˚ u vˇsak nen´ı uzp˚ usoben k lokalizaci robota ve scénˇe. K tomu by muselo b´ yt znaˇcek mnohonásobnˇe v´ıce, coˇz nen´ı moˇzné v praxi provést. Nav´ıc by detekce musela prob´ıhat po uraˇzen´ı menˇs´ıch vzdálenost´ı, coˇz by zabralo velmi mnoho ˇcasu. Systém SLAM, kterému jsem se bˇehem ˇreˇsen´ı u ´lohy vˇenoval, je tedy velice nespolehliv´ y a nepˇresn´ y. Do vytvoˇrené aplikace vˇsak m˚ uˇze b´ yt integrován dalˇs´ı modul, kter´ y by nab´ızel jin´ y zp˚ usob lokalizace robota v prostˇred´ı. Vˇsechny mnou vytvoˇrené kódy jsou opatˇreny programátorskou dokumentac´ı. Bˇehem implementace u ´loh jsem evaluoval prostˇred´ı simulátoru Webots a také jsem odhalil nˇekolik problém˚ u, ke kter´ ym pˇri simulaci robota Nao docház´ı. Vˇse jsem detailnˇe zdokumentoval a pokud to bylo moˇzné, naˇsel nejlepˇs´ı moˇzné ˇreˇsen´ı problém˚ u. Ukázalo se, ˇze simulátor Webots nepodporuje nˇekteré systémy robota Nao. Nen´ı tedy vhodn´ y pro jeho simulaci, pokud je naˇs´ım c´ılem simulovat pravˇe tyto systémy. Je jich pomˇernˇe hodnˇe, avˇsak jedná se sp´ıˇse o minoritn´ı systémy, jejichˇz pouˇzit´ı nen´ı vˇetˇsinou tˇreba sloˇzitˇe ladit a tedy i simulovat. Nav´ıc s kaˇzdou dalˇs´ı verz´ı je schopen simulovat v´ıce a v´ıce systém˚ u, které má robot k dispozici. Napˇr´ıklad je ohláˇseno, ˇze v dalˇs´ı verzi bude obsaˇzen model robota s vymodelovan´ ymi prsty. D´ıky tomu, ˇze simulátor Webots nen´ı urˇcen pouze k simulaci robota Nao, ale umoˇzn ˇuje simulovat celou ˇradu jin´ ych robot˚ u a tvorbu sv´ ych vlastn´ıch prototyp˚ u, je dle mého názoru software vhodn´ y do ˇskol, kde by se dal vyuˇz´ıt ne jenom jako jedno´ uˇcelov´ y simulátor robota Nao, ale mohl by b´ yt vyuˇz´ıván rovnˇeˇz pˇri v´ yuce robotiky. Od chv´ıle, kdy byl vyb´ırán simulaˇcn´ı software k simulaci robota Nao pro tuto práci, ubˇehla jistá doba, bˇehem které doˇslo k jistému pokroku. Byl vytvoˇren dokonce zcela nov´ y simulaˇcn´ı software nazvan´ y NaoSim, kter´ y spolupracuje pˇr´ımo s aplikac´ı Choregraphe. Je zcela zamˇeˇren na simulaci robota Nao. V souˇcasné dobˇe vˇsak stále nen´ı v release verzi. Veˇsker´ y simulaˇcn´ı software, kter´ y je schopn´ y simulovat robota Nao, se neustále vyv´ıj´ı, protoˇze robot Nao je povaˇzován za robota, kter´ y pˇredstavuje budou48

cnost. Základn´ımi tˇremi moˇznostmi jsou v souˇcasné simulátory Webots, Miscrosoft Robotics Developer Studio a NaoSim. Vˇsechny z nich maj´ı problémy, kter´ ym mus´ı v´ yvojáˇr pˇri simulaci robota ˇcelit. Po prostudován´ı fóra spoleˇcnosti Aldebaran Robotics, kde lidé popisuj´ı zkuˇsenosti s ostatn´ımi simulaˇcnimi programy, a na základˇe vlastn´ıch zkuˇsenost´ı se simulátorem Webots se domn´ıvám, ˇze simulátor Webots je v souˇcasné dobˇe nejlepˇs´ı volbou. Zvláˇstˇe, pokud by byl vyuˇzit cel´ y jeho potenciál a jeho vyuˇz´ıván´ı by nebylo zamˇeˇreno pouze na robota Nao.

49

A. Obsah pˇriloˇ zen´ eho DVD • Knihovny Adresáˇr obsahuj´ıc´ı veˇskeré knihovny potˇrebné ke kompilaci u ´loh • Literatura Odborné ˇclánky, ze kter´ ych jsem ve své práci ˇcerpal • Projekty Aplikace k u ´lohám – Bludiste CMake projekt k vytvoˇren´ı aplikace k u ´loze Bludiˇstˇe – naoqi for webots CMake projekt k vytvoˇren´ı kontroleru naoqi for webots – Stopovana CMake projekt k vytvoˇren´ı aplikace k u ´loze Stopovaná • Videa Videa inlustruj´ıc´ı funkˇcnost vytvoˇren´ ych aplikac´ı – Uloha1-Stopovana Videa k prvn´ı u ´loze – Uloha2-Bludiste Videa k druhé u ´loze • Webots Instalaˇcn´ı soubor simulátoru Webots a vytvoˇrené virtuáln´ı svˇety k testován´ı u ´loh – Bludiste Virtuáln´ı svˇet k testován´ı u ´lohy Bludiˇstˇe – Stopovana Virtuáln´ı svˇet k testován´ı u ´lohy Stopovaná

50

B. N´ avod ke kompilaci u ´loh Aplikace k obˇema u ´lohám vyuˇz´ıvaj´ı nˇekolik extern´ıch C++ knihoven, které je tˇreba m´ıt nainstalovány. Nav´ıc je tˇreba aplikace nastavit, aby správnˇe pracovaly s NaoQi. Z toho d˚ uvodu uvád´ım struˇcn´ y návod, podle kterého je moˇzné obˇe aplikace u ´spˇeˇsnˇe zkompilovat. K obˇema u ´lohám jsem vytvoˇril CMake projekt. Zdrojové soubory jsou uloˇzeny na pˇriloˇzeném DVD v adresáˇr´ıch /Projekty/Stopovana a /Projekty/Bludiste. Postupnˇe uvedu veˇskeré knihovny, které v aplikac´ıch vyuˇz´ıvám, a postup, jak je správnˇe nastavit. • Aldebaran SDK verze 1.6.13 Jedná se o základn´ı soubor knihoven, které jsou nutné pro práci s robotem. Souˇcást´ı je i NaoQi a soubor toolchain-pc.cmake, kter´ y je pouˇz´ıván pro crosskompilaci celé knihovny pomoc´ı CMake. Archiv obsahuj´ıc´ı knihovnu správné verze je um´ıstˇen na pˇriloˇzeném DVD. Je zde um´ıstˇen i instalaˇcn´ı soubor k programu Choregraphe, pomoc´ı nˇehoˇz je moˇzné pˇr´ımo ovládat robota a snadno tak ovˇeˇrit, ˇze je vˇse správnˇe nastaveno. Je nutné instalovat právˇe tuto verzi, protoˇze aplikace jsou k n´ı uzp˚ usobeny a s jin´ ymi verzemi nejsou pˇr´ımo kompatibiln´ı. Pˇri instalaci knihovny doporuˇcuji postupovat podle instrukc´ı v dokumentaci [14, SDK ]. D˚ uleˇzité je zejména nastaven´ı systémové promˇenné PATH pˇridán´ım cest /path/to/sdk/bin a /path/to/sdk/lib. Pˇri vytváˇren´ı projektu pomoc´ı softwaru CMake je nutné zatrhnout moˇznost ”Specify toolchain file for cross-compiling”a poté zadat cestu k souboru /path/to/sdk/toolchain-pc.cmake. • OpenCV Na pˇr´ıloˇzeném DVD je instalaˇcn´ı soubor knihovny verze 2.1. Aplikace jsou testovány na této verzi, avˇsak mˇely by pracovat i s jin´ ymi verzemi. Spuˇsten´ım instalaˇcn´ıho souboru by se mˇelo vˇse nastavit a CMake by mˇel s knihovnou bez problému pracovat. Bˇehem instalace je d˚ uleˇzité zatrhnout moˇznost, aby instalaˇcn´ı program nastavil systémové promˇenné. Dále pak nen´ı nutné se o tuto knihovnu starat. • ARToolKit Na pˇriloˇzeném DVD je archiv se soubory knihovny verze 2.72.1. Aplikace jsou testovány na této verzi, avˇsak mˇely by pracovat i s jin´ ymi verzemi. Instalaci knihovny je moˇzné snadno provést v nˇekolika kroc´ıch: 1. Rozbalte archiv do libovolného adresáˇre, kter´ y oznaˇcme {ARToolKit} 51

B. Návod ke kompilaci u ´loh 2. Pˇridejte do systémové promˇenné PATH cestu {ARToolKit}/bin 3. Vytvoˇrte systémovou promˇennou ARTOOLKIT ROOT a nastavte ji na hodnotu {ARToolKit} Pro naˇse u ´ˇcely nen´ı nutné knihovnu kompilovat. • GSL Na pˇriloˇzeném DVD je instalaˇcn´ı soubor knihovny verze 1.8. Aplikace jsou testovány na této verzi, avˇsak mˇely by pracovat i s jin´ ymi verzemi. Instalaci lze provést v následuj´ıc´ıch kroc´ıch: 1. Spust’te instalaˇcn´ı soubor a nanistalujte knihovnu do libovolného adresa´ˇre, kter´ y oznaˇcme {GSL} 2. Vytvoˇrte systémovou promˇennou GSL ROOT a nastavte ji na hodnotu {GSL} • Qt4 Tato knihovna je sice souˇcást´ı Aldebaran SDK, ale bohuˇzel je zde ve verzi, která nen´ı s aplikac´ı kompatibiln´ı. Nav´ıc Aldebaran SDK neobsahuje vˇsechny jej´ı souˇca´sti. Je tedy nutné nainstalovat ji dodateˇcnˇe. Na pˇriloˇzeném DVD je instalaˇcn´ı soubor pro verzi 4.7.3 urˇcenou pro Microsoft Visual Studio 2008. V d˚ usledku toho, ˇze je knihovna Qt v poˇc´ıtaˇci v´ıcekrát, docház´ı k tomu, ˇze se mohou pouˇz´ıvat ˇspatné dynamické knihovny, protoˇze maj´ı pro obˇe verze stejn´ y název. Pro knihovnu, která je souˇca´st´ı Aldebaran SDK, jsou um´ıstˇeny ve sloˇzce (/path/to/sdk/bin), jeˇz mus´ı b´ yt uloˇzena v systémové promˇenné PATH pro správnou funkˇcnosti SDK. Pokud systém bude hledat nejprve v této sloˇzce, budou pouˇzity ˇspatné dynamické knihovny a aplikace nebude fungovat. V takové pˇr´ıpadˇe je nejjednoduˇsˇs´ı pˇridat soubory QtCore4.dll a QtGui4.dll pˇr´ımo do adresáˇre zkompilované aplikace. • Boost Tato knihovna je souˇcást´ı Aldebaran SDK a nen´ı nutné ji tedy nijak nastavovat. I v pˇr´ıpadˇe, ˇze je na poˇc´ıtaˇci jiˇz knihovna Boost nainstalována, nemˇelo by doj´ıt k ˇza´dn´ ym problém˚ um. Jakmile jsou vˇsechny potˇrebné knihovny nainstalovány a správnˇe nastaveny, je moˇzné pomoc´ı softwaru CMake vytvoˇrit projekt. Obˇe aplikace jsou vytvoˇreny jako REMOTE, coˇz znamená, ˇze nebˇeˇz´ı pˇr´ımo v procesoru robota, ale jsou vykonávány na extern´ım stroji a robotovi jsou pouze pˇredávány pˇr´ıkazy. V d˚ usledku toho je nutné v CMake bˇehem vytváˇren´ı projektu zatrhnout moˇznost {NAZEV PROJEKTU} IS REMOTE. Jakmile je projekt vytvoˇren, mˇel by j´ıt bez dalˇs´ıho nastavovan´ı zkompilovat. Pˇred spuˇsten´ım aplikace pro u ´lohu Stopovaná je nutné zkop´ırovat sloˇzku Data ze sloˇzky s projektem do sloˇzky se zkompilovanou aplikac´ı. V této sloˇzce jsou uloˇzeny 52

soubory se ˇsablonami znaˇcek, které má robot detekovat. Nav´ıc je tˇreba m´ıt pˇred spuˇstˇen´ım aplikace spuˇstˇen simulátor Webots s naˇcten´ ym správn´ ym virtuáln´ım svˇetem a spuˇsten´ ym kontrolerem naoqi for webots. Pˇred spuˇstˇen´ım aplikace pro u ´lohu Bludiˇstˇe je nav´ıc nutné zkop´ırovat soubor obstacleFile.txt ze sloˇzky s projektem do sloˇzky se zkompilovanou aplikac´ı. V tomto souboru jsou nadefinovány pozice pˇrekáˇzek pro virtuáln´ı svˇet Labyrinth.

53

C. Seznam kl´ avesov´ ych zkratek k aplikaci Bludiˇstˇ e Aplikace k u ´loze Bludiˇstˇe obsahuje grafické rozhran´ı, pomoc´ı kterého je moˇzné vˇse ovládat. K zajiˇstˇen´ı vˇetˇs´ıho pohodl´ı jsem aplikaci vybavil klávesov´ ymi zkratkami, jimiˇz lze rychle zadávat pˇr´ıkazy. Zde uvád´ım jejich seznam: • CTRL + C Je asociována s poloˇzkou v menu Connect robot a vyvolá formuláˇr pro pˇripojen´ı k robotovi. Je aktvn´ı pouze v pˇr´ıpadˇe, ˇze aplikace nen´ı k ˇza´dnému pˇripojena. • CTRL + D Je asociována s poloˇzkou v menu Disconnect robot a po jej´ım stisknut´ı se aplikace odpoj´ı od robota. Je aktivn´ı pouze v pˇr´ıpadˇe, ˇze je aplikace pˇripojena k robotovi. • CTRL + O Je asociována s poloˇzkou v menu Show simulator map. Jej´ım stisknut´ım se zap´ıná / vyp´ıná zobrazovan´ı skuteˇcn´ ych pozic pˇrekáˇzek. Je aktivn´ı pouze v pˇr´ıpadˇe, ˇze je aplikace pˇripojena k virtuáln´ımu robotovi v simulátoru. • CTRL + S Je asociována s poloˇzkou v menu Start mapping. Jej´ım st´ısknut´ım se zap´ıná automatické mapován´ı. Je aktivn´ı pouze v pˇr´ıpadˇe, ˇze je aplikace pˇripojena k robotovi a ten nevykonává ˇzádnou ˇcinnost. • CTRL + E Je asociována s poloˇzkou v menu Stop mapping. Jej´ım st´ısknut´ım se vyp´ıná automatické mapován´ı. Je aktivn´ı pouze v pˇr´ıpadˇe, ˇze je aplikace pˇripojena k robotovi a automatické mapován´ı je aktivn´ı. • CTRL + G Je asociována s poloˇzkou v menu Go to location. Po jej´ım stisknut´ı je uˇzivatel vyzván, aby vybral m´ısto, kam má robot doj´ıt. Je aktivn´ı pouze v pˇr´ıpadˇe, ˇze je aplikace pˇripojena k robotovi a ten nevykonává ˇza´dnou ˇcinnost. • CTRL + Q Je asociována s poloˇzkou v menu Quit a po jej´ım st´ısknut´ı se aplikace odpoj´ı od robota a poté se ukonˇc´ı. Je aktivn´ı stále.

54

Literatura [1] Webové stránky projektu HUMAVIPS. http://humavips.inrialpes.fr/. 6 [2] Webové stránky projektu RoboCup. http://www.robocup.org/. 6 [3] Webové stránky aplikace Microsoft Robotics Developer Studio. http://www.microsoft.com/robotics/. 7 [4] Webové stránky spoleˇcnosti Cyberbotics. http://www.cyberbotics.com/index.php. 7, 45 [5] Reference manual of webots simulator. http://www.cyberbotics.com/reference.pdf. 8 [6] User guide for webots simulator. http://www.cyberbotics.com/guide.pdf. 8, 9 [7] Webové stránky jazyka VRML. http://graphcomp.com/info/specs/sgi/vrml/spec/. 9 [8] Dokumentace ke kontroleru naoqi for webots. http://www.cyberbotics.com/nao/. 10 [9] Webové stránky knihovny OpenCV. http://opencv.willowgarage.com/wiki/. 15 [10] Webové stránky knihovny Boost. http://www.boost.org/. 15 [11] Dokumentace knihovny Boost. http://www.boost.org/doc/libs/1_45_0/doc/html/index.html. 15 [12] Webové stránky knihovny ARToolKit. http://www.hitl.washington.edu/artoolkit/. 15 [13] Webové stránky knihovny Qt. http://qt.nokia.com/products/. 26 [14] ALDEBARAN Robotics. Nao Documentation. http://academics.aldebaran-robotics.com/docs/site_en/index_ doc.html. 6, 11, 14, 15, 51 55

Literatura [15] A. Chatterjee, R. Olive, A. Chatterjee, and A. Rakshit. Development of a real-life ekf based slam system for mobile robots employing vision sensing. Expert Systems with Applications, 38:8266—-8274, 2011. 32 [16] R. I. Hartley and A. Zisserman. Multiple View Geometry in Computer Vision. Cambridge University Press, ISBN: 0521623049, 2000. 18 ˇ Fojt˚ [17] M. Havlena, S. u, D. Pr˚ uˇsa, and T. Pajdla. Towards Robot Localization ˇ and Obstacle Avoidance from Nao Camera. Technical report, CVUT v Praze, CMP, 2010. 26 [18] J. C. Latombe. Robot Motion Planning. Kluwer Academic Publishers Norwell, ISBN: 0792391292, 1991. 27 [19] A. Louloudi, A. Mosallam, N. Marturi, P. Janse, and V. Hernandez. Integration of the Humanoid Robot Nao inside a Smart Home. Technical report, ¨ Orebro University, Sweden, April 2010. 14, 26 [20] K. J. Obermeyer and Contributors. The VisiLibity library. http://www.VisiLibity.org, 2008. R-1. 27 [21] T. Pajdla. Teoretické základy vidˇen´ı, grafiky a interakce. Magistersk´ y kurz programu Otevˇrená Informatika, pˇrednáˇsky, letn´ı semestr 2010. On-line, http://cmp.felk.cvut.cz/cmp/courses/TZ/2010/Lecture/, staˇzeno 12.5.2010. 16 [22] S. Riisgaard and M. R. Blas. SLAM for Dummies, 2005. 32, 33 [23] R. Sara. 3d computer vision. Open Informatics Master’s Course, lectures, winter 2010. On-line, http://cmp.felk.cvut.cz/cmp/courses/TDV/2010W/lectures/ 3DV-lectures.pdf, verze 14.12.2010, staˇzeno 15.12.2010. 28, 29 [24] J. Wienke and S. Wrede. Tutorial on event-driven memory architectures in robotics, August 2010. 15

56

Použití simulátoru Webots na vývoj aplikací pro robot Nao

Recommend Documents