Sem vložte zadání Vaší práce

Sem vložte zadání Vaší práce.

České vysoké učení technické v Praze Fakulta informačních technologií Katedra počítačových systémů

Diplomová práce

Použití hračky pro zprostředkování informace uživateli Bc. Miroslav Mužný

Vedoucí práce: Dr. Ing. Tomáš Macek

10. května 2012

Poděkování Tímto bych rád poděkoval vedoucímu diplomové práce, Dr. Ing. Tomáši Mackovi za pomoc a cenné rady při její tvorbě.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů. V souladu s ust. § 46 odst. 6 tohoto zákona tímto uděluji nevýhradní oprávnění (licenci) k užití této mojí práce, a to včetně všech počítačových programů, jež jsou její součástí či přílohou a veškeré jejich dokumentace (dále souhrnně jen „Dílo“), a to všem osobám, které si přejí Dílo užít. Tyto osoby jsou oprávněny Dílo užít jakýmkoli způsobem, který nesnižuje hodnotu Díla a za jakýmkoli účelem (včetně užití k výdělečným účelům). Toto oprávnění je časově, teritoriálně i množstevně neomezené.

V Praze dne 10. května 2012

..................... 7

České vysoké učení technické v Praze Fakulta informačních technologií c 2012 Miroslav Mužný. Všechna práva vyhrazena.

Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.

Odkaz na tuto práci Miroslav Mužný. 0.0.0: Diplomová práce. Praha: ČVUT v Praze, Fakulta informačních technologií, 2012.

Abstract Master thesis is focused on utilization of Furby toy as rather less traditional user interface. The first part of the document presents summary of existing similar systems and concepts. Special attention is devoted to the Internet of Things environment, especially from security viewpoint. Result of thesis is also implementation based on flexible modular architecture. Several sample scenarios were selected for the environment of home, office as well as public areas. The implementation is evaluated using formal test on 10 users. The results are presented in the text. Keywords Furby, internet of things, machine-to-machine, lightweight cryptography, digital pet, smart companion, Kinect, XVB, VoiceXML

9

Abstrakt Práce se zabývá využitím hračky Furby jako netradičního uživatelského rozhraní. Součástí práce je rešerše podobných existujících systémů a pojmů. Zvláštní pozornost je věnována prostředí "Internetu věcí" především z pohledu bezpečnosti. Výsledkem práce je implementace modulárně rozšiřitelného řešení. Pro účely použití v prostředí domácnosti, kanceláře a veřejných prostorách bylo vytypováno několik ukázkových scénářů. Řešení je vyhodnoceno formálním uživatelským testem s 10 uživateli, jehož výsledky jsou v práci prezentovány. Klíčová slova Furby, internet věcí, lehká kryptografie, digitální zvířátko, chytrý společník, Kinect, XVB, VoiceXML

10

Obsah Úvod 17 Struktura práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1 Rešerše 1.1 Popis vybraných zařízení . . . . 1.2 Furby . . . . . . . . . . . . . . 1.3 Související pojmy . . . . . . . . 1.4 Možnosti bezpečné autentizace 1.5 Architektura existujících řešení 1.6 Závěr . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

19 19 23 25 28 29 31

2 Popis řešení 2.1 Popis architektury . . . . . . . . . . 2.2 Ovládací aplikace . . . . . . . . . . . 2.3 Navržené a implementované scénáře 2.4 Kinect . . . . . . . . . . . . . . . . . 2.5 Talking Head . . . . . . . . . . . . . 2.6 Webové rozhraní . . . . . . . . . . . 2.7 Shrnutí . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

33 33 36 45 51 53 55 59

. . . . . .

. . . . . .

3 Testování 61 3.1 Formální test s uživateli . . . . . . . . . . . . . . . . . . . . . . 61 3.2 Zkušenosti a reakce uživatelů na netradiční UI . . . . . . . . . 66 3.3 Testování scénáře s aplikací Talking Head . . . . . . . . . . . . 68 Závěr

69

Literatura

71

A Seznam použitých zkratek

75 11

B Instalační příručka 77 B.1 Furby ovládací aplikace . . . . . . . . . . . . . . . . . . . . . . 77 B.2 Kinect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 B.3 Talking Head . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 C Uživatelská příručka 81 C.1 Konfigurace aplikace editací souboru config.xml . . . . . . . . . 81 D Dotazník

85

E Obsah přiloženého CD

87

12

Seznam obrázků 1.1 1.2 1.3 1.4 1.5 1.6

Tamagoči (převzato z (26)) . . . . . . . . . . . . . . . . . Zařízení Karotz (převzato z (42)) . . . . . . . . . . . . . . Tuxdroid (převzato z (27)) . . . . . . . . . . . . . . . . . Robotický pes Aibo (převzato z (50)) . . . . . . . . . . . Hračka Furby (převzato z (7)) . . . . . . . . . . . . . . . . Softwarová architektura zařízení Karotz (převzato z (53))

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

20 21 21 22 24 31

2.1 2.2 2.3 2.4 2.5 2.6 2.7

Nákres architektury řešení . . . . . . . . . . . . . . . Ovládací aplikace . . . . . . . . . . . . . . . . . . . . Stavový diagram navrženého ovládání hračky Furby Nákres architektury aplikace . . . . . . . . . . . . . OAuth autentizace (převzato z (21)) . . . . . . . . . Konfigurace dialogového menu ve webovém rozhraní Plánování akcí ve webovém rozhraní . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

34 37 38 41 51 57 58

3.1

Graf vyhodnocení formálního testu s uživateli . . . . . . . . . . . .

65

13

. . . . . . .

. . . . . . .

. . . . . . .

Seznam tabulek 2.1 2.2

Význam označení pole field . . . . . . . . . . . . . . . . . . . . . . Tabulka použitých knihoven třetích stran . . . . . . . . . . . . . .

40 45

3.1

Hodnocení dotazníkových otázek . . . . . . . . . . . . . . . . . . .

62

15

Úvod V dnešní době je možné pozorovat snahu přiblížit ovládání PC co nejblíže člověku. Existuje nespočet různých forem, ve kterých je uživatelské rozhraní ztvárněno, ať již softwarových či hardwarových. Některé z nich jsou svou funkčností omezeny, další pak zprostředkovávají plnohodnotný přístup k informacím v uživatelsky přístupnější podobě. Velice populárním prostředkem jak docílit přívětivějšího přijetí uživatelem, je ztvárnit vstupně/výstupní zařízení počítače do podoby avatara. Jeho konkrétních reprezentací se nabízí velmi mnoho a na trhu jej lze nalézt jako králíčka, tučňáka, psa, virtuální asistentku i v jiných podobách. Cílová skupina uživatelů těchto zařízení není pevně určena, je možné nalézt je v podstatě všude. O jejich popularizaci se pak starají zejména multimediální servery typu Youtube, kde je vystaveno velké množství videí předvádějící tato zařízení. Velkou část z nich pak tvoří prezentace zařízení, vytvořených v domácím prostředí. Právě v těch je většinou možné nalézt značnou míru invence a inspirace. Spolu s rozvojem těchto zařízení se začínají formovat některé technologie, které mají umožnit jejich propojení, popř. spolupráci. Jednou z nich je koncept Internetu věcí, jenž si mimo jiné klade za cíl vytvořit vhodnou platformu pro tento účel. Spolu s jeho vývojem, se však otevírá mnoho otázek, týkajících se bezpečnosti zařízení, v této síti připojených. Naší snahou je také zmapovat aktuální stav týkající se bezpečnosti v této oblasti. V této práci se zabýváme vytvořením avatara z hračky Furby. V rámci studentských prací byla v minulosti původní hračka vybavena elektronikou, umožňujícím ovládat hračku pomocí PC prostřednictvím bezdrátového rozhraní Bluetooth. V bakalářské práci (47) jsme položili základ architektury, která by mohla sloužit k obsluze zařízení zejména pomocí hlasu. Zároveň jsme navrhli několik základních scénářů. Hlavní motivací k tvorbě diplomové práce bylo rozšířit architekturu tak, aby šla využít i s jiným typem zařízení. Spolu s tím pak umožnit konfiguraci aplikace ve formě načítatelných modulů. Kromě toho bylo naším cílem rozšířit počet scénářů, které jsou uživateli dostupné. Jako zajímavá se dále ukázala možnost, implementovat vzdálené ovládání 17

Úvod zprostředkované zařízením Kinect. Výsledkem naší snahy je modulárně rozšiřitelná architektura. Zásuvné moduly lze použít k získávání informací a jejich zprostředkování pomocí hračky Furby. Modulární architektura rovněž umožňuje přidávat další hardware komponenty, sloužící k ovládání hračky Furby. Druhou oblastí zájmu našeho zkoumání, bylo zhodnocení postoje a vnímání vytvořeného prototypu uživatelem. Kromě komentářů a připomínek, které se sešly v rámci iterativního návrhu aplikace, jsme provedli i formální test, pomocí kterého jsme dokázali objektivně zhodnotit postoj uživatele. Test jsme navrhli provést ve formě dotazníku, předloženého uživateli po předvedení ukázkového scénáře. Ten má za cíl seznámit uživatele s ovládáním Furbyho a s některými jeho funkcemi. Scénář využívá zároveň dálkové ovládání pomocí výše zmíněného zařízení Kinect. Dotazník je tvořen několika otázkami s možností odpovědi na diskrétní stupnici, případně otevřenou odpovědí.

Struktura práce Práci jsme rozdělili do několika větších celků, ve kterých pak dále popisujeme dílčí části práce. První kapitolou práce je rešerše existujících zařízení a konceptů, které se vztahují k řešenému tématu diplomové práce. Vzhledem k velkému rozsahu jsme několik vybraných zařízení popsali podrobně, u dalších pak pouze uvedli zdroj s dalšími dostupnými informacemi. Cílem rešeršní části je také uvést do kontextu několik pojmů, které jsou často zmiňovány v souvislosti s těmito zařízeními. Věnujeme se zde také popisu bezpečnostních aspektů, vztahujících se k zmíněným konceptům. Ve druhé kapitole popisujeme řešení a implementaci funkčních celků. V počátku je nastíněna architektura řešení s popisem jednotlivých prvků. Dále rozebíráme jednotlivé implementované scénáře. V rámci kapitoly se zmiňujeme o zařízení Kinect a programu Talking Head, které jsme do práce zakomponovali. Poznatky z testování a uživatelské zkušenosti shrnujeme ve třetí kapitole. Její část věnujeme subjektivním dojmům a pozorováním, které vznikly v rámci několika iterací testování. Dále je její součástí formální test s uživateli, jež si klade za cíl zmapovat názor a postoj oslovených účastníků k netradičnímu uživatelskému rozhraní v reakci na předvedený ukázkový scénář. Vyhodnocení testu jsme zařadili do čtvrté kapitoly. Zamýšlíme se zde nad užitečností zařízení, jeho nedostatky, omezeními a náměty ze strany uživatelů. V kapitole Závěr shrnujeme výsledky práce a uvádíme příklady některých z možných pokračování ve vývoji.

18

Kapitola

Rešerše V této části bychom chtěli představit několik zařízení a pojmů vztahujících se k tématu diplomové práce. Kapitola začíná seznámením s příklady již existujících hraček, robotů a společníků. Zvláště se věnujeme hračce Furby. Následuje vysvětlení několika pojmů, které jsou často zmiňovány v souvislosti s těmito zařízeními. Značnou část kapitoly se zabýváme konceptem Internetu věcí a jeho bezpečnostními specifiky. V závěru se věnujeme rozboru architektur vybraných zařízení.

1.1 1.1.1

Popis vybraných zařízení Tamagoči

Tamagoči (45) je příkladem jednoho z prvních zařízení patřících mezi tzv. "digital pets"(digitální, virtuální zvířátko). Jedná se o plastovou kapesní hračku, které dominoval poměrně velký displej. Hračka byla uvedena na trh v roce 1997 firmou Bandai. Uživatel byl postaven před jednoduchý úkol. Měl se postarat o virtuální zvířátko. Potřeby zvířátka byly rozmanité a vyžadovaly pozornost uživatele v různých chvílích herního cyklu. Herní cyklus trval cca 25 - 30 dní. Slovo tamagoči je zajímavé svým původem. Vzniklo pomocí tzv. blendingu ze slov tamago (vajíčko) a tomodači (kamarád)(55).

1.1.2

Nabaztag/Karotz

Zařízení Nabaztag (46) bylo představeno v roce 2006 dnes již neexistující firmou Violet. Zařízení v podobě králíčka má plnit funkci internetového společníka. Z funkčního hlediska je na tom Nabaztag velmi podobně jako Furby, nicméně architektura řešení je odlišná. Nabaztag ve své základní verzi umí upozornit na příchozí emailové zprávy, číst titulky zpráv, přehrávat internetová rádia a funguje zároveň jako budík. V průběhu let se dostalo na trh několik vylepšených verzí králíčka, poslední verze pak změnila označení ze jména Na19

1

1. Rešerše

Obrázek 1.1: Tamagoči (převzato z (26))

baztag na Karotz. Zařízení je tvořeno mikrokontrolérem PIC18F6525, pamětí, 802.11b Wi-Fi modulem, dvěma motorky obsluhujících pohyb uší, Audio-PCM modulem a reproduktorem. V novějších verzích byl také přidán mikrofon, USB port a RFID modul. Interakce s uživatelem probíhala pomocí pohybu uší, světelné signalizace a zvukového výstupu. Akce králíčka byly vykonávány na základě předem daného časového harmonogramu, který byl nastavitelný pomocí webového rozhraní. I přes velkou prodejní úspěšnost a zisk několika ocenění, společnost stojící za vznikem králíka Nabaztag zkrachovala. Ještě dnes však existuje několik alternativní serverů, které umožňují jejich provoz. Nabaztag je slovo Arménského původu a v českém překladu znamená zajíc, případně kožka.

1.1.3

Tuxdroid

Spolu s tím jak rostla popularita a prodejnost králíka Nabaztag, vznikaly další návrhy či koncepty podobných zařízení. Jedno z těch, které se skutečně dostalo na trh je zařízení jménem Tuxdroid (27). Jak již název napovídá, firma Kysoh se při vymýšlení designu hračky inspirovala u tučňáků. Tuxdroid má spolu s Nabaztagem několik společných rysů - zůstaly pohyblivé části těla (namísto uší ploutve), světelná signalizace se přesunula do očí. Důležitou odlišností je, že bezdrátový interface hračky sice operuje v pásmu 2,4 GHz, nicméně neimplementuje TCP/IP stack. Uživatel je tedy nucen pro bezdrátovou komunikaci použít na straně PC dodávaný USB dongle. Je vidět, že se výrobci hračky poučili z některých chyb a nedostatků, které se objevily u výrobku Nabaztag. Architekturu navrhli jinak a postupně ji vylepšovali. Součástí bylo také SDK, které bylo poskytnuto uživatelské komunitě. Konečným výsledkem však byl příliš složitý a nejasný návrh. Firma však i přes to, že prodejní cena byla 20

1.1. Popis vybraných zařízení

Obrázek 1.2: Zařízení Karotz (převzato z (42))

mnohem nižší než u králíka Nabaztag, zkrachovala, a zbyla pouze software spravující komunita. Obrázek 1.3: Tuxdroid (převzato z (27))

1.1.4

Telebuddy

Avatar Telebuddy (29) byl představen na konferenci Expo 2000. Jde o zařízení v podobě opičky, které zprostředkovává přenos zvukové a obrazové informace. Účelem je umožnit uživateli teleprezenci na vzdálených místech. Kromě kamery, mikrofonu a reproduktoru je na avataru umístěno několik senzorů. Připojení je zajištěno dvěma bezdrátovými rozhraními, pracujícími na frekvencích 433 MHz a 2.4 GHz. Bylo představeno a ukázáno několik scénářů použití takového zařízení. Pro vytvoření žádaného efektu byl důležitý zejména fakt, že zařízení bylo navrhnuto jako snadné pro přenos a esteticky zdařile ztvárněno. 21

1. Rešerše Podoba opičky navíc vzbuzovala v návštěvnících zvědavost a nadšení, což je pro úspěch zařízení takového typu zásadní.

1.1.5

Aibo

Robotické zvířátko v podobě psa, Aibo (50), je produktem firmy Sony. V tomto případě se zčásti jedná také o umělecké dílo, o čemž svědčí i to, že původní návrhy designu jsou součástí Muzea Moderního Umění, Smithsonianovy instituce. Tento robot je narozdíl od výše zmíněných zařízení schopen pohybu, prostor okolo sebe snímá pomocí na něm umístěné kamery. Tím se také Aibo dokáže dostat ke své dokovací stanici. Software zajišťující obsluhu robota je umístěn na kartě Memory Stick. Je schopen porozumět hlasovým povelům uživatele. Aibo umí zareagovat na více než 100 příkazů. Šťastní majitelé pak po určitý čas mohli modifikovat chování Aiba jeho přeprogramováním. Po zásahu ze strany Sony, kdy bylo toto přímé přeprogramování zmemožněno, však bylo vydáno několik nástrojů, které umožňovaly vývoj software pro Aiba. V roce 2006 Sony ukončilo prodej Aiba, nicméně jeho podpora bude pokračovat do roku 2013 a vývoj technologie stojící za Aibem zůstane nepřerušen . Aibo je zkratkou pro Artificial Intelligence roBOt. Japonské aib pak v překladu znamená partner, kamarád.

Obrázek 1.4: Robotický pes Aibo (převzato z (50))

1.1.6

Nao humanoid

V roce 2004 začala francouzská společnost Aldebaran Robotics s vývojem robota Nao (33). Jeho konstrukce je velmi podobná lidské postavě. Vyráběn je v několika verzích, které se liší počtem stupňů volnosti (21 - 25). Tento robot poměrně brzy (2007) nahradil ve známé soutěži Robocup právě výše zmíněného Aiba. Vývoj robota Nao pokračuje nadále. Firma navíc rozhodla o otevření zdrojových kódů. 22

1.2. Furby

1.1.7

Ananova

Zástupcem 3D virtuálních avatarů, je například avatar Ananova (2), zprostředkovaný serverem ananova.com. Ten kromě agregace zpráv z webových zdrojů, poskytuje také jejich reprodukci uživateli. K tomu používá věrný 3D model hlavy ženy a TTS engine spolu se synchronizací pohybů rtů, což vytváří obraz věrohodnosti.

1.1.8

Další zařízení

Kromě výše zmíněných zařízení existuje několik jiných, které je vhodné alespoň zmínit. Uvádíme proto seznam dalších zařízení: • Naughty Duck - amatérský projekt, ve kterém je plyšová hračka vybavena elektronikou a ovládaná ze strany PC podobně jako Furby (20). • Animatronic Cat Ears - výrobek inspirovaný zařízením Necomimi. Náhlaní souprava v podobě elektronicky ovládaných uší slouží k vyjádření emocí (3). • Robosapien - robot humanoid s devíti stupni volnosti. Umožňuje uchopit, případně přesouvat lehčí předměty (56). • Genibo - zařízení podobné robotu Aibo, které je nicméně navrženo tak, aby svým vzhledem a pohyby připomínalo mnohem více psa (36). • iHippo - elektronicky vybavená plyšová hračka v podobě hrocha (9).

1.2

Furby

Elektronická hračka Furby byla uvedena na trh firmou Tiger v roce 1998. Jedná se o velmi úspěšnou hračku, což potvrzuje fakt, že firma Tiger prodala v letech 1998 - 2000 přes 40 milionů kusů. Furby je chlupaté zvíře s několika pohyblivými prvky a senzory. Po zapnutí začne na uživatele mluvit jazykem zvaným furbština. Tu tvoří soubor několika málo vět. Postupem času však začíná Furby mluvit více jazykem anglickým a vést s uživatelem jednoduchou konverzaci. V závislosti na stavu jeho senzorů a hlasovém vstupu uživatele byl navíc Furby naprogramován tak, že některé opakoval častěji než jiné. To vyústilo v zajímavou skutečnost, a to že v USA byl vydán zákaz výskytu hraček tohoto typu ve státních kancelářích (35). Případ se odehrál konkrétně ve státu Maryland v místní kanceláři NSA a zákaz vyplynul z klasifikování Furbyho jako záznamového zařízení. 23

1. Rešerše

Obrázek 1.5: Hračka Furby (převzato z (7))

Pohyblivé prvky Součástí hračky je několik pohyblivých prvků, které slouží zejména k vyjádření emocí Furbyho. Jsou obsluhovány dvěma motorky. První z nich je umístěn v horní části hračky. Obsluhuje pohyb uší, otevíraní a zavírání očí. Tyto dva pohyby se provádějí synchronně, tím lze vytvořit potřebné vyjádření emocí. Směr jejich pohybu je dán směrem pohybu motorku. Výhodou je, že každou z těchto poloh lze dosáhnout absolutně i relativně vůči aktuální poloze. Naopak je tomu u druhého motorku, který zajišťuje pohyb nohou a zároveň otevírání zobáku. U tohoto motorku lze regulovat jeho výkon a tím zrychlovat/zpomalovat pohyb nohou, případně to, jak moc se otevře zobák.

Senzory Na Furbym jsou umístěny kromě pohyblivých prvků také 4 senzory, z nichž 3 jsou jednoduché mechanické spínače. Ty jsou umístěny na břiše, zádech a v zobáku. Pro umožnění lepšího stisku je na spínači na zádech i na břichu umístěn plastový element. Ten výrazně rozšiřuje plochu pro zmáčknutí a tím tuto činnost značně usnadňuje. Mechanický spínač v zobáku je řešen podobným způsobem jako předchozí dva. Posledním ze senzorů je polohový senzor, umístěný ve vnitřnostech Furbyho. Ten se uplatňuje v několika původních Furbyho scénářích (Furby reaguje na položení na záda). 24

1.3. Související pojmy

Předchozí práce na hračce Furby Myslím, že v této části je také vhodné zmínit několik předchozích prací, které se věnovaly hračce Furby a na něž moje práce navazuje. V první řadě je to práce Tomáše Kunce (41). Práce se věnovala návrhu, realizaci a testování základní desky s bluetooth modulem, který umožňuje ovládat hračku bezdrátově. Dalším příspěvkem byla práce Jana Bartoška (34), jejímž výsledkem je DLL knihovna, která umožňuje výrazně snadnější práci s Furbyho prostředky.

1.3 1.3.1

Související pojmy Digital pet

Jeden z pojmů, který se úzce vztahuje k tématu diplomové práce, je digital pet. Představuje typ umělého lidského společníka, který nemá konkrétní fyzickou podobu, prochází však několika fázemi vývoje. Uživatel bývá často postaven před konkrétní cíl, někdy je intenzita hry ponechána na něm. Hlavní roli představuje interakce s uživatelem. Ta je prováděna několika způsoby: • Akce prováděné v závislosti na oslovení/volání • Asynchronně vyvolané akce • Reakce vyvolané pomocí senzoru (dotek, osvětlení, ...) • Trénování, zlepšování, posunutí vývojového cyklu vpřed • Komunikace s elektronickými společníky stejného či podobného typu S postupujícím vývojem technologií se zvětšuje věrohodnost takového společníka, což hlavně u dětí může vyvolat zkreslené představy a dojmy. Jeden z výzkumů, který se tímto jevem zabýval provedla prof. Sherry Turkle z Massachusettského technologického institutu. V jeho rámci bylo dětem ve věku od 5 do 10 let ve škole rozdáno několik elektronických hraček Furby, ve verzi Classic. U dětí bylo pozorováno přiřazení určité identity hračce, spolu s vytvořením názoru, že hračka je živá v pozměněném slova smyslu. Vytvoření názoru výrazně podporovalo pozorování náhodných či nečekaných reakcí ze strany Furbyho. Při nefunkčnosti hračky se neopak cítily podvedeny, zrazeny a o novou už nejevily zájem. Hračka se jim pak nadále jevila jako přístroj (37).

1.3.2

Smart Companion (Ambient device)

Jedním z nových konceptů, které se objevily kolem roku 2002 je tzv. chytrý společník. Stejně jako digital pet může mít mnoho ztvárnění. Jeho hlavním cílem však není pobavit, ale poskytovat uživateli agregované informace z různých zdrojů. Příkladem je zařízení jménem Ambient orb. To je ztvárněno do 25

1. Rešerše podoby věštící koule měnící barvy dle změny informace z různých kanálů. Těmi mohou být například předpověď počasí, vývoj stavu akcií na burze, stav ankety mapující názor na jistou skutečnost a jiné. Dalším příkladem může být produkt firmy Chumby Industries, jménem Chumby (38). V podobě embedded počítače s obrazovkou agreguje informace ze sociálních sítí a zpravodajských serverů. Pomocí dotykové obrazovky dokáže zpracovat vstup uživatele.

1.3.3

Internet of Things a jeho bezpečnostní aspekty

V českém překladu "Internet věcí", představuje pohled na internet jako síť vzájemně propojených unikátních předmětů. To je umožněno zejména miniaturizací potřebné technologie, snížením spotřeby energie, schopností zařízení umístěných vevnitř přijímat/vysílat geolokační signál a jinými aspekty. Zařízení jsou v této síti propojeny zpravidla bezdrátově, není to však podmínkou. Pojem Internet of Things je úzce spjat s pojmem Web of Things. Rozdíl je v tom, že nastavení jednotlivých vlastností a funkcí daného zařízení v síti Web of Things je přístupné přes webové API. V současné době je v provozu několik webových služeb pro Internet věcí. Příkladem mohou být servery Pachube, Exosite portal a jiné. Všechny z nich slouží ke sběru a interpretaci dat v reálném čase. Jednou ze současných možností, jak tyto data využít, je použití uživatelem definovaných alarmů, které mohou upozornit na změnu trendu, překročení předem dané hodnoty či jiné vlastnosti. Výše zmíněné portály umožňují přistupovat také k datům zařízení ostatních členů zapojených v síti. Je však samozřejmě nutné, aby uživatel vlastnící toto zařízení přístup schválil. Mezi zařízeními, které mohou být součástí Internetu věcí jsou mezi jinými i věci denní potřeby jako toustovač, lednice, mikrovlná trouba, automobil. Obecně to jsou všechna zařízení, která mohou přispět jakoukoliv informací sebranou senzorem, čidlem případně jiným způsobem. Kromě známých fyzikálních veličin to je např. i geolokační signál. Je důležité zmínit, že součástí Internetu věcí jsou nejen jednoznačně identifikovatelná zařízení, která svými daty do sítě přispívají. Součástí jsou totiž i zařízení data konzumující. Již dnes existuje několik studií o možnostech, které zpracování informací z připojených zařízení přinese. Níže uvádíme několik z nich: • Týdeník The Economics (30) uvádí studii o monitorování skotu pomocí senzoru implantovaného v jejich uchu. Data zprostředkovaná senzorem (pohyb, zdraví) budou využita k zajištění zdravějšího masa pro odběratele. • V knize "The Fortune at the Bottom of the Pyramid: Eradicating Poverty Through Profits"(48) je uvedeno několik statistik porovnání životního standardu ve čtvrtích města Bombaj. Jedna ze statistik uvádí výrazný nepoměr mezi cenami za kubický metr vody ve čtvrtích města, 26

1.3. Související pojmy umístěných velmi blízko sebe. Tento rozdíl je způsobený neoptimální distribuční infrastrukturou a nelegálním odčerpáváním vody. Inteligentní senzory a systémy umožní místním autoritám identifikaci a odstranění problémů vzniklých v distribuční síti . Jedním z předpokladů pro rozvoj Internetu věcí je rozšíření technologie IPv6. Tato nutnost vyplývá z počtu zařízení připojených do sítě a s tím spojené spotřeby IP adres. Dalším z předpokladů je vypracování standardů, umožňujících přenos IPv6 paketů mezi různými typy sítí. V tomto ohledu je jednou z nejaktivnějších organizací IEEE (12). Rozvoj Internetu věcí je dále spjat s několika problémy týkajících se způsobu autentizace, bezpečnosti přenosu dat a jednoznačné identifikace zařízení v síti. Problematika bezpečnosti Internetu věcí je velmi podobná současné situaci bezpečnosti klasického Internetu. Konkrétní typy útoků však mohou být realizovány jinými prostředky. Příkladem je útok typu DoS, realizovaný vysíláním elektromagnetického signálu a následným zahlcením limitovaných zdrojů zařízení v IPv6 síti. Některá rizika mohou v Internetu věcí nabývat na významu. V úvahu připadá například fyzická destrukce zařízení, popř. extrakce klíče, které je možné snadněji provést díky lepšímu přístupu k zařízení. Faktem je, že známé a široce používané šifrovací standardy a algoritmy byly navrhovány s předpokladem možnosti využití určitého výpočetního výkonu. Jejich použití v zařízeních Internetu věcí s omezenou pamětí a výkonem je tedy předmětem budoucího testování a zkoumání. Často zmiňovaným pojmem v tomto kontextu je tzv. "lehká kryptografie"(lightweight cryptography) (39). Šifry či protokoly, řadící se do této skupiny, jsou navrženy pro použití s omezenými výpočetními zdroji a v omezených prostředích (například RFID zařízení, bezkontaktní čipové karty, senzory a jiné). Důležité je, že slovo "lehký"v tomto případě neznamená snížení bezpečnosti. Standardizační projekt lehké kryptografie, ISO/IEC 29192, popisuje "lehké"vlastnosti na základě cílové platformy. V hardwarových implementacích jsou hodnotícími kritérii plocha čipu či spotřeba energie. U softwarových implementací pak velikost kódu a spotřeba paměti RAM. 1.3.3.1

Blokové šifry

Pro blokové šifrování byl vybrán standard AES. Kromě něj bylo navrženo několik dalších, např. CLEFIA, PRESENT. Obě šifry nedávno (leden 2012) získaly ISO standard ISO/IEC 29192 (15). 1.3.3.2

Proudové šifry

V kategorii proudových šifer jsou kandidáty pro použití šifry Grain v1, MICKEY v2 a Trivium, mající "lehké"vlastnosti. Všechny tři vzešly z projektu ECRYPT II eSTREAM (8). 27

1. Rešerše 1.3.3.3

Hashovací algoritmy

Soutěž SHA-3 vyhlášená NIST (19), jejíž cílem je vybrat novou hashovací funkci, má 5 finalistů. Žádná z nich však nemá "lehké"vlastnosti. V současné době však vzniká soutěž o hashovací funkci pro RFID. Jedním z kandidátů je lehká hash PHOTON, zabírající minimální křemíkovou plochu. Návrh hashe PHOTON vychází z AES a jeho konstrukce je typu houby (sponge) (31). 1.3.3.4

Asymetrická kryptografie

V oblasti asymetrické kryptografie jsou požadavky šifer a protokolů na dostupné výpočetní zdroje značně vyšší než u symetrické kryptografie. Vývoj situace se v současné době ubírá směrem k použití některé ze šifer využívající eliptické křivky (39). S nástupem konkrétních technických řešení je pravděpodobné, že bude k dispozici připravená sada funkcí, jejíž použití bude zpočátku volitelné (49). Důležitá je také otázka implementace technologií využívající síťové prostředky do běžně používaných zařízení, kde bude značnou roli hrát cena. V neposlední řadě je nutné počítat s tím, že většina zařízení bude třeba asociovat se skupinou osob, a nikoliv s jednou osobou tak, jak je tomu v dnešních aplikacích. O velikosti významu bezpečnosti Internetu věcí svědčí nadcházející, již 3. mezinárodní konference věnovaná tomuto tématu (13). S rozvojem Internetu věcí je počítáno také v akčním plánu CORDIS(49), vypracovaném komisí evropských společenství. Dokument obsahuje několik směrů činností, které se mimo jiné zabývají identifikací vznikajících rizik a sledováním otázek soukromí a osobních údajů.

1.3.4

Shrnutí

Je vidět, že společné vlastnosti a funkce výše zmíněných zařízení by se daly shrnout do několika pojmů. Je však těžké nalézt hranici mezi těmito pojmy a striktně zařadit zařízení do jedné z kategorií. Spolu s přibývající funkcionalitou se navíc tyto pojmy neustále formují a také vznikají nové. Je nutné dodat, že v poslední době dynamiku rozvoje v této oblasti značně určuje trend neustále se rozvíjejících sociálních sítí. Logicky se zde totiž nabízí asociace zařízení jako společníka s entitou v sociální síti. Je zajímavé pozorovat, že každé nové zařízení uvedené na trh je vyjímečné, protože integruje jedinečnou sadu funkcí a přináší vlastní architekturu.

1.4

Možnosti bezpečné autentizace

Volba typu autentizace k představeným zařízením závisí vždy na konkrétním druhu architektury obslužné aplikace. Je zřejmé, že u zařízení zcela závis28

1.5. Architektura existujících řešení lých na vzdáleném serverovém prostředí, je nutné implementovat metodu, jak k tomuto prostředí vzdáleně autentizovat. Naopak, u lokálně provozovaných aplikací tato nutnost odpadá a celá autentizace se redukuje pouze na fyzický přístup k zařízení. Vzhledem k tomu, že v současné podobě tyto zařízení neposkytují přístup k citlivým informacím, je k zamyšlení, zdali vůbec implementovat autentizační mechanismus. Zařízení Nabaztag bylo nutné při prvotním použití asociovat pomocí sériového čísla k webserveru s ovládací aplikací. Poté uživatel získal profil, ke kterému mohl přistupovat jím zvoleným heslem. U zařízení Karotz je tato registrace volitelná, nicméně je po ní uživateli umožněno používat většinu důležitých funkcí.

1.5 1.5.1

Architektura existujících řešení Nabaztag

V červenci roku 2011 byly uvolněny zdrojové kódy aplikace a popis architektury zařízení Nabaztag. Tyto dokumenty se vztahují k již pozměněnému návrhu z roku 2008. Hlavní změnou v této implementaci bylo použití standardního XMPP protokolu (Extensible Messaging and Presence Protocol) a celkové zrychlení reakcí zařízení na vnější podněty. K obsluze zařízení sloužily 4 servery, spravované firmou Violet. První z nich zajišťoval obsluhu konfigurace zařízení pomocí webového rozhraní. Rozhraní bylo napsáno v jazyce Java. Druhý ze serverů zajišťoval obsluhu choreografie pohybu a přehrávání zvukových stop. Třetí z nich generoval akce na uživatelem přiloženém RFID k zařízení Nabaztag. Tyto akce byly konfigurovatelné pomocí webového rozhraní. Poslední server pak implementoval zpracování příchozích XMPP zpráv a generování následné odpovědi, opět ve formě XMPP zprávy.

1.5.2

Telebuddy

Základ architektury avatara Telebuddy se stával z lokálního serveru, vzdáleného serveru a samotného avatara. Lokální server poskytoval zachytávání audia/videa a služby TTS. K tomuto serveru se pak Telebuddy připojoval pomocí bezdrátového rozhraní. Server vzdálený potom poskytoval správu uživatelů, webové služby, broadcast audia/videa a chatovou službu. Webová služba integrovaná na stránkách vývojového institutu umožňovala následující: • Použít chat místnost pro odeslání zprávy jednomu či více připojeným uživatelům • Prohlížet dříve kladené otázky, zpracované pomocí TTS výstupu avatara Telebuddy 29

1. Rešerše • Odeslat krátkou zprávu či komentář společně s projevem emocí pomocí avatara • Ověřit dostupnost živého vysílání audia/videa Všechna přenášena multimédia byla na vzdáleném serveru archivována.

1.5.3

Karotz

U novější verze zařízení Nabaztag není známo tolik informací, jako o jeho předchůdci. Z materiálů dostupných na stránce jeho výrobce jsou však známé následující fakta. Na hardware výbavě je instalován operační systém Linux, který zajišťuje běh několika samostatně pracujících modulů. • Modul Controller zajišťuje sběr dat z externího serveru a dohlíží na celkový chod zařízení • Modul Karotz to Karotz slouží k VoIP komunikaci mezi dvěma Karotz avatary • Scheduler je modul zajišťující plánování a spouštění různých akcí • KarotzVM je virtuální stroj, poskytující spouštění Karotz aplikací • Změnu nálad a chování Karotz pak obstarává Spirit Manager modul Mezi integrovaná vstupně/výstupní zařízení patří: • RFID modul sloužící k detekci a čtení RFID čipu • Hlasový modul pro rozpoznávání a syntézu řeči • Multimédia modul zajišťující čtení a přehrávání multimedií z externího zdroje (flash paměť nebo internetový stream) • Webkamera • Dotykový senzor • Přední LED diody s nastavitelnou intenzitou • Pohyblivé uši sloužící zároveň jako vstupní zařízení Aplikace pro zařízení Karotz se vymezují na dva typy: 1. Aplikace vzdálené, které používají web API. To umožňuje jejich provoz na velké škále zařízení a vývoj v mnoha programovacích jazycích. 2. Embedded aplikace vytvořené v jazyce JavaScript s využitím SDK pro Karotz platformu. 30

1.6. Závěr

Obrázek 1.6: Softwarová architektura zařízení Karotz (převzato z (53))

1.6

Závěr

Počet zařízení, podobných uvedeným příkladům, je značně velký a jejich počet neustále narůstá. Jedním z důvodů je úspěšnost jejich prodeje, která je nicméně závislá na mnoha faktorech. Je možné pozorovat, že vizuální zpracování, uživatelská přívětivost a cena jsou jedny z hlavních motivací ke koupi podobného zařízení. Počet implementovaných scénářů není zásadní, případná rozšiřitelnost funkčnosti zařízení je však výhodou. Důležitá je robustnost architektury. Časté výpadky služeb mohou uživatele odradit od používání zařízení. Významnou roli hraje také intuitivnost ovládání, které by měl mít uživatel možnost konfigurovat. Funkce inteligentního přizpůsobení a schopnost učení u většiny zařízení schází a nezdá se, že by měly výrazný vliv na jeho úspěch. Funkce rozpoznáváni řeči nebyla do nedávné doby implementována jako jeden ze způsobů ovládání. Její aplikace je předmětem současnosti. Autorizace funkcí ze strany uživatele tak byla prováděna pomocí senzorů umístěných na zařízení. Jeden ze zajímavých způsobů přineslo zařízení Karotz, které k tomuto účelu využívalo RFID tagů, asociovaných s konkrétními funkcemi. Velkou část na prodejním úspěchu tvoří uživatelská komunita, která se vytvoří okolo zařízení. Poskytuje zejména důležitou zpětnou vazbu a přispívá k obohacování kolekce funkcí, které zařízení poskytuje. To je podmíněno vydáním SDK, které může komunita využívat. K sdělování zkušeností s používáním zařízení slouží zejména sociální sítě typu Facebook. Kladná uživatelská odezva na těchto sítích může značně ovlivnit úspěch zařízení na trhu. Typ architektury zařízení, vzhledem k autorizaci klíčových funkcí a zpra31

1. Rešerše cování dat lze v zásadě rozdělit na: lokální, vzdálenou a hybridní, která je kombinací předchozích dvou. Dnes asi komerčně nejúspěšnější zařízení, Karotz používá hybridní architekturu, stejně jako Telebuddy. Je zřejmé, že v případě závislosti zařízení na některé ze vzdálených aplikací jsou v případě chyby či výpadku služby zasažena všechna zařízení, což je jedna z příčin neúspěchu zařízení Nabaztag. Centralizovaná správa této aplikace je však samozřejmě jednodušší. Výhodou lokálně běžící aplikace je možnost použití zařízení i bez připojení k Internetu. Je však nutné spravovat několik různých verzí a jejich update není jednorázová záležitost.

32

Kapitola

Popis řešení 2.1

Popis architektury

Architektura řešení je složena z několika dílčích celků. Jde o obecnější architekturu, která není závislá na hračce Furby. Vytvořená architektura je navržena modulárně a umožňuje uživatelskou konfiguraci načítaných modulů. Jednou ze služeb, které aplikace poskytuje je funkce monitorování jejího stavu. Důležitost monitorování se projeví zejména při dlouhodobém provozu aplikace. Níže bychom chtěli uvést význam a funkci jednotlivých prvků celé architektury.

2.1.1

VoiceXML

Jazyk VoiceXML (54) slouží k popisu dialogu. Je to XML jazyk poskytující prostředky pro řečově ovládané aplikace. Pro řečovou syntézu používá vstup formátovaný dle standardu SSML (25). Pomocí něj je možné v průběhu zpracování VoiceXML dokumentu modifikovat parametry hlasu a přízvuku. Jazyk VoiceXML neurčuje způsob rozpoznání mluveného slova či věty. Nabízí několik několik způsobů jak zapsat gramatiku tyto slova či věty definující (standardně ve formátu JSGF (17), je možné použít i jiné). V roce 2000 byla veřejnosti představena verze jazyka 1.0, o rok později pak verze 2.0. Ta byla rozšířena do několika příbuzných jazyků pro popis dialogových systémů. Vznikl tak návrh W3C konsorcia - Speech interface framework (14). Součástí specifikace standardu VoiceXML je také Voice ID (51). Jde o způsob uživatelské autentizace hlasem, založené na faktu, že hlasové charakteristiky každého člověka jsou různé. Rozhodovací kritéria systému jsou založena na charakteristikách vzniklých specifickým tvarem lidského hrdla a úst. Díky tomu není systém při rozpoznávání citlivý k emotivním změnám hlasu. 33

2

2. Popis řešení

2.1.2

Architektura řešení

V úvodu zmíníme komponenty aplikace, které jsme měli k dispozici a ze kterých jsme vycházeli: • DLL knihovna pro ovládání hračky Furby pomocí rozhraní bluetooth(34) • VoiceXML Browser Charlie(54) • Web server Apache(52) • Distribuce ActiveState Perl(32) • Aplikace Talking Head(40) • Knihovna obsluhující Kinect Než se budeme věnovat jednotlivým konkrétním částem architektury, uvedeme a popíšeme schématický diagram znázorňující strukturu navržené architektury.

Obrázek 2.1: Nákres architektury řešení Furby je připojen pomocí bluetooth rozhraní k PC. Obsluhu spojení zajišťuje již dříve vytvořená DLL knihovna v bakalářské práci Jana Bartoška (34). Cílem jeho práce bylo integrovat audio funkce bluetooth modulu do PC. DLL knihovnu jsme integrovali do naší ovládací aplikace. Po příchodu asynchronní 34

2.1. Popis architektury události o změně stavu některého ze senzorů umístěných na hračce Furby, je pomocí TCP/IP protokolu poslán požadavek VoiceXML browseru na spuštění některého ze skupiny scénářů. Jeho umístění je zadáno jako URL adresa perl skriptu na lokálně běžícím serveru Apache. Samotný perl skript je volán skrze cgi bránu serveru Apache a výsledkem jeho provedení je VoiceXML dokument připravený ke zpracování. VoiceXML dokument je vrácen zpět VoiceXML browseru, který ho interpretuje. V průběhu interpretace program zasílá ovládací aplikaci informace o aktuálním stavu zpracování dokumentu. Ty jsou aplikací zpracovány a vyhodnoceny. Na jejich základě jsou pak ovládány Furbyho motorky, zajišťující pohyb uší, nohou a zobáku. V naší práci používáme prototyp hračky Furby, u které nevyužíváme přenos zvuku pomocí bluetooth rozhraní. Důvodem je nízká kvalita integrovaného mikrofonu. Pro snímání zvuku používáme mikrofon AKG (1), který je připojen přímo k mikrofonnímu vstupu PC. Audio výstup VoiceXML browseru je přenášen drátovým spojením přímo do reproduktorku umístěného v hračce Furby. Datové spojení je zprostředkováno pomocí rozhraní bluetooth. V budoucnu uvažujeme o sjednocení provozu datového a audio kanálu přes bluetooth rozhraní.

2.1.3

VoiceXML browser

K zpracování hlasového vstupu/výstupu používáme VoiceXML browser, Charlie (10), který dokáže interpretovat VoiceXML. V základním režimu VoiceXML browser nepodporuje vzdálené ovládání. Tento konkrétní browser je navržen pro běh v několika různých režimech lišících se ve způsobu otevření/uzavření mikrofonu: • Push to Speak - mikrofon je otevřen po přijetí příkazu k otevření, uzavřen po přijetí příkazu k uzavření • Push to Activate - mikrofon je otevřen po přijetí příkazu k otevření, uzavřen po rozpoznání slova nebo ticha • Always Listen - mikrofon je otevřen automaticky, uzavřen po rozpoznání slova nebo ticha VoiceXML browser umožňuje ovládání pomocí protokolu XVB postaveného nad TCP/IP protokolem. Detailní specifikace XVB je neveřejná, pro realizaci práce jsme ji měli k dispozici. Obecně, je jeho použitím uživatel schopen ovlivnit stav zpracování VoiceXML dokumentu, přijímat události případně předkládat VoiceXML soubory ke zpracování. Události jsou krátká oznámení různého druhu, které program odesílá v průběhu sekvenčního zpracování VoiceXML dokumentu. Na těchto oznámeních jsme založili stavový automat implementovaný v C++ aplikaci. Nejedná se o události jazyka VoiceXML (značky "nomatch", "noinput", "error", "help") 35

2. Popis řešení ale o zprávy signalizující stav zpracování prvků ve struktuře VoiceXML dokumentu. Příklad oznámení XVB protokolu o začátku zpracování pole "address_field" VoiceXML dokumentu: <xvb>

2.1.4

Perl

Pro generování VoiceXML souboru využíváme služeb programovacího jazyka Perl. Použili jsme nejznámější distribuci ActiveState Perl, která je volně dostupná. Využití některého ze skriptovacích jazyků se ukázalo nezbytné ve chvíli, kdy jsme potřebovali využít některou z funkcí kterou VoiceXML, případně JavaScript neposkytují. Vzhledem k snadné instalaci, konfiguraci a široké nabídce rozšiřujících modulů jsme zvolili právě jazyk Perl.

2.1.5

Server Apache

Webový server Apache slouží ke zprostředkování webového obsahu. V architektuře naší aplikace zajišťuje zpracování Perl skriptu prostřednictvím cgi brány. Výhodou, je možnost přímého zadání URL adresy skriptu jako parametru VoiceXML browseru. Apache server používáme zároveň k poskytnutí webového interface, pro základní konfiguraci a kontrolu Furbyho.

2.2

Ovládací aplikace

Vzhledem k povaze aplikace, jsme se rozhodli rozdělit ji na několik funkčních částí. Jedním z důvodů je také možnost použití jednotlivých celků v rámci jiné aplikace, kde by Furby mohl být nahrazen jiným zařízením. Aplikace je navržena modulárně. Tento návrh umožňuje implementovat jednotlivé funkční části scénářů do zvláštních DLL knihoven. Na obrázku 2.2 lze vidět, že kód implementovaný v DLL knihovnách může sloužit jak k obsluze vstupně/výstupních zařízení (např. Kinect), tak k získávání dat pro konkrétní scénáře (např. scénář Počasí).

2.2.1

Navržené ovládání Furbyho

Ovládání jsme navrhli tak, aby jsme maximálně využili dvě přístupná tlačítka ze tří celkových, které jsou na hračce Furby umístěné. Zadnímu tlačítku jsme přiřadili funkci "Cancel", neboli slouží k přerušení spuštěného scénáře v jakémkoliv stavu. U předního tlačítka rozlišujeme jedno stlačení a dvojklik. Ve 36

2.2. Ovládací aplikace

Obrázek 2.2: Ovládací aplikace

standardní konfiguraci je po jednom stlačení předního tlačítka vyvolána 1. úroveň menu, po dvojkliku pak uživatelem definovaná funkce. Čidlo v zobáku může mít také přiřazeno vlastní funkci. Nyní budeme mluvit o vláknech a jejich funkci v kontextu aplikace. Aplikace má 2 hlavní obslužná vlákna, jsou jimi vlákna QueueThread a CharlieThread.

2.2.2

Vlákno QueueThread

Při návrhu architektury aplikace se ukázalo, že bude třeba implementovat obslužný mechanismus pro asynchronní spouštění kódu v závislosti na čase. Tato nutnost vyplynula z potřeby pravidelně a na ostatním celku aplikace nezávisle, aktualizovat data pro implementované scénáře. Příkladem je scénář Počasí, kterému je třeba v pravidelných intervalech aktualizovat data z webového serveru. Vlákno QueueThread je zodpovědné za zpracování časově závislých akcí. Základním prvkem je prioritní fronta, ve které jsou uchovávány ukazatele na instance třídy QueueItem, tedy prvku fronty. class QueueItem{ SYSTEMTIME t; int interval; bool repeated; FurbyPlugin *p; string optional; 37

2. Popis řešení

Obrázek 2.3: Stavový diagram navrženého ovládání hračky Furby

}; V této třídě je také definovaný operátor <, sloužící k porovnání 2 instancí QueueItem dle času t. Takto definovaný operátor zajišťuje seřazení dle času vzestupně. Při inicializaci fronty je volána funkce fillQueue všech načtených modulů, které mohou přidat několik prvků do fronty spolu s tím, že nastaví ukazatel p na svou vlastní instanci. Čas t je možné nastavit s minutovou granularitou, stejně tak interval, který udává počet minut do dalšího opakování. Při testování vyšlo najevo že při použití funkce sleep k čekání vlákna, dochází k poměrně velkému časovému driftu a proto byly použity funkce SetWaitableTimer, WaitForSingleObject, u kterých k tomuto driftu nedochází. Při dosažení času t je umožněno vláknu volat některou z funkcí instance modulu FurbyPlugin.

2.2.3

Vlákno CharlieThread

Vlákno CharlieThread implementuje stavový automat který zpracovává příchozí události VoiceXML browseru. Zároveň používá PluginManager k zjištění, zda některý z načtených modul implementuje funkci specifikovanou v příchozí 38

2.2. Ovládací aplikace události. Pokud implementuje, je zavolána odpovídající funkce invoke daného modulu, které je opět předán ukazatel na callback funkci, provádějící konkrétní Furby akci. Pro rozlišení příchozích událostí jsme použili rozdílné označení prvku typu field ve zpracovávaném VoiceXML souboru. Označení jiných nabízejících se elementů ve struktuře VoiceXML souboru by totiž nemělo žádaný efekt. VoiceXML browser při zpracování prvku typu block nečeká na přehrání vložených prompt bloků a neodesílá tak asynchronně námi žádané události. Jiné elementy zase neumožňují vnoření prompt bloků. Níže uvádíme příklad VoiceXML souboru s formulářem a prvkem typu field. Prvek field má nastavený parametr name s hodnotou dup.

<prompt timeout="0.1s"> <noinput>

Důležitým poznatkem při implementaci stavového automatu bylo zjištění o nepřesnosti motorků Furbyho. V rámci DLL knihovny jsou implementovány funkce, zajišťující posun motorku do pozice předané parametrem funkce. Zpětná vazba motorku však není dostatečně přesná a často dochází k zacyklení v nekonečné smyčce, kterou lze ukončit pouze vypnutím zařízení. Řešením se ukázalo definování několika diskrétních stavů polohy motorku s přechody definovanými časovými intervaly. Těchto intervalů bylo dosáhnuto pomocí aktivního čekání s pomocí funkce jazyka C++ - clock() (5). Označení pole field jsme zvolili jako 3-písmenou zkratku, případně kombinace 3-písmenných zkratek. Nepovolené zřetězení zkratek je ošeřeno ve stavovém automatu, implementovaném ve vlákně CharlieThread. Automaticky je prováděno otevírání zobáku při přehrávání libovolného promptu jazyka VoiceXML. Stejně tak jsme přidali automatické zvednutí uší upozorňující na to, že bude otevřen mikrofon (od uživatele je očekáván vstup).

2.2.4

Plugin Manager

Námi navržená architektura je modulární. Jednotlivé funkční celky vytváří zvláštní DLL knihovny (moduly), které jsou pak do aplikace postupně načítány. Moduly umožňují provádění kódu autorizovaného ze strany VoiceXML, 39

2. Popis řešení Klíčové slovo usm mra zob blk dup

Význam pohyb uší do horní polohy, vyjadřující úsměv pohyb uší do dolní polohy, vyjadřující smutek otevření zobáku označení elementu field, který nečeká na uživatelský vstup zhoupnutí provedené pomocí spodního motorku Tabulka 2.1: Význam označení pole field

nebo se jejich kód může spouštět samostatně, v určených časových intervalech. Plugin manager zajišťuje načítání a volání funkcí jednotlivých modulů. Implementací modulu je myšlena třída implementující obecné rozhraní (v jazyce C++ je tedy odvozena od abstraktní třídy obsahující pouze čistě virtuální metody). Rozhraní modulů definuje Plugin Manager. Modul je kompilován jako dynamická knihovna, která je načítána za běhu pomocí funkce LoadLibrary. Registrace modulu do seznamu načtených modulů probíhá voláním exportované funkce modulu. Návrh aplikace uživateli umožňuje zvolit si, které moduly budou při startu aplikace načteny. Konfiguraci načítaných modulů je možné provádět v konfiguračním souboru config.xml a také pomocí webového rozhraní. Při návrhu bylo třeba brát v úvahu rozdílné požadavky na funkce modulů. Nutnost definovat více typů rozhraní se projevilo při snaze o zakomponování vzdáleného ovládání pomocí přístroje Kinect. Control Plugin Modul je spouštěn jako samostatné vlákno. Rozhraní je tvořeno pouze jednou funkcí, které je poskytnut callback pro volání Furby specifických funkcí (ovládání motorků). Rozhraní je definováno takto: • virtual void* run() = 0; Příkladem tohoto typu modulu je implementace ovládání pomocí zařízení Kinect. Furby Plugin Návrh rozhraní pro tento typ modulu vychází ze zkušenosti z bakalářské práce. V té byly veškeré funkce implementovány nemodulárně, což velmi výrazně omezovalo variabilitu programu. U některých typů scénářů navíc docházelo k nechtěnému zpoždění při předání informace z internetového zdroje uživateli. Tuto prodlevu jsme eliminovali pravidelným předzpracováním a uložením těchto údajů do souboru. Některé moduly však poskytují informace, jejichž 40

2.2. Ovládací aplikace

Obrázek 2.4: Nákres architektury aplikace

aktuálnost je více časově omezena (např. modul poskytující informace o stavu na burzovním trhu). Proto si uživatel v nastavení modulu může zvolit, zda chce informace předzpracovat, nebo raději dostat informaci aktuální za cenu mírného zpoždění. Nastavení se opět provádí v souboru config.xml nebo pomocí webové aplikace. 41

2. Popis řešení Rozhraní je definováno takto: • virtual bool implements(std::string ) = 0; • virtual bool invoke(bool (*) (FurbyAction)) = 0; • virtual bool asyncAction(bool (*) (FurbyAction), std::string optional) = 0; • virtual bool fillQueue(std::priority_queue, pless >&) = 0; Všechny výše definované funkce musí navržený modul implementovat. Význam jednotlivých funkcí je následující: • funkce implements - vrací hodnotu true pokud modul implementuje funkci definovanou parametrem typu std::string, v opačném případě vrací false • funkce invoke - zde je umístěn funkční kód modulu, vrací hodnotu true v případě úspěšného provedení, v opačném případě vrací false. Parametrem je pointer na funkci furbyControl, kterou může modul využít ke spouštění furby specifických funkcí (pohyb motorku, spuštění scénáře,...) • funkce fillQueue - do této funkce je možné umístit kód, který naplní frontu událostí předanou parametrem. Jinými slovy, pokud modul implementuje jakoukoliv funkčnost ve funkci asyncAction, je nutné aby registroval svůj modul vložením instance třídy QueueItem do prioritní fronty. Registraci modulu je nutné provést pouze jednou, případné opakované spouštění je zajištěno automaticky. Po úspěšné registraci modulu vrací hodnotu true, v opačném případě false. Podrobnosti o třídě QueueItem jsou uvedeny dále v textu. • funkce asyncAction - slouží k možnosti implementovat asynchronně spouštěný kód v závislosti na aktuálním čase. V něm je opět možné využít ukazatel na funkci furbyControl, pro furby specifické funkce. Návratová hodnota true značí úspěšné vykonání kódu, v opačném případě je vrácena hodnota false. Pokud je vykonání kódu uvnitř funkce asyncAction neúspěšné (vrácena hodnota false) je automaticky naplánované opakované spuštění posunuté o 1 minutu vpřed.

2.2.5

Autorizace scénářů

Autorizace scénářů je založena na příchozích událostech z VoiceXML browseru. Ke spuštění funkce implementované některým z načtených modulů je tedy možné využít parametru name prvku field VoiceXML dokumentu. 42

2.2. Ovládací aplikace Příkladem může být scénář Počasí. Níže uvádíme popis sekvence volání při nastavení, kdy má modul poskytovat aktuální informace (nestahují se pravidelně předem). 1. Zpracování prvku field s parametrem name definovaným jako weather ve VoiceXML dokumentu 2. Příchod XVB události z VoiceXML browseru 3. Volání funkce implements všech načtených modulů 4. Odpověď modulu WeatherPlugin návratovou boolean hodnotou true 5. Volání funkce invoke modulu WeatherPlugin 6. Ve funkci invoke se provede načtení a parsování informace o počasí 7. Následuje volání funkce FurbyAction s parametry, nesoucí informaci o počasí 8. Odeslání požadavku VoiceXML browseru o načtení scénáře s danou informací Druhým případem je nastavení modulu, při kterém má poskytovat předem zpracované informace. Pro tento případ je implementováno vlákno QueueThread. Po dosažení času t definovaného v instanci třídy QueueItem je volána funkce asyncAction instance modulu, na který instance QueueItem ukazuje. Ve funkci asyncAction je pak implementována výkonná část kódu. Je předpoklad, že u některých modulů bude třeba volat funkce, které využívají DLL knihovnu k obsluze hračky Furby. Proto je při volání asyncAction předán také ukazatel na callback funkci, která toto zajišťuje. Příklad sekvence volání při nastavení, ve kterém jsou data pro scénář počasí stahována předem. 1. Volání funkce asyncAction modulu WeatherPlugin vláknem QueueThread v daných časových okamžicích 2. Ve funkci asyncAction se provede načtení, parsování a uložení informace o počasí do souboru 3. Při vyvolání scénáře Počasí uživatelem, se tyto informace ze souboru načtou a předají uživateli 43

2. Popis řešení

2.2.6

Struktura a význam funkce furbyControl

Mnoho z implementovaných modulů vyžaduje využití specifické funkce (pohyb motorkem,...) pro použití s hračkou Furby. Proto jsme vytvořili callback funkci, jíž je jako parametr předávána struktura FurbyAction. Funkce je v kódu implementována na stejné úrovni jako obsluha vláken QueueThread a CharlieThread, proto ji nazýváme callback funkcí. Díky tomu je možné, modifikovat funkci furbyControl tak, aby obsluhovala i jiné zařízení než hračku Furby. Strukturou FurbyAction je možné specifikovat, jaké akce, mající přímou vazbu na Furby DLL knihovnu, se mají spouštět. Zároveň je možné tímto způsobem použít aplikaci k obsluze jiného zařízení, tj. nepropagovat vazbu na konkrétní knihovnu sloužící k obsluze vstupně/výstupního zařízení do dílčích částí programu. Strukturu FurbyAction jsme navrhli následovně: struct FurbyAction{ int swingMoves; bool smile, scowl, roll, stop; std::string playScenario, scenarioParameters, say; }; Význam jednotlivých položek struktury je dán: • swingMoves - počet zhoupnutí provedeného pomocí dolního motorku • smile - pohyb uší do horní polohy, vyjadřující úsměv • scowl - pohyb uší do dolní polohy, vyjadřující smutek • roll - navrácení uší do domovské polohy • stop - pomocná proměnná určující, zda bude zastaven jiný scénář (pokud právě probíhá) • playScenario - jméno scénáře ke spuštění pomocí VoiceXML browseru • scenarioParameters - parametry předané danému scénáři • say - textový řetezec určený k přehrání pomocí VoiceXML browseru

2.2.7

Uživatelská konfigurace

Konfiguraci aplikace a jednotlivých modulů jsme navrhli v podobě XML souboru, který je umístěn v adresáři s aplikací. Detailní popis konfigurace ovládací aplikace a jednotlivých scénářů je popsán v příloze. 44

2.3. Navržené a implementované scénáře Název RapidXml cURL twitcURL

Použití XML Parser Přenos dat po protokolu HTTP Přístup k Twitter API

Homepage http://rapidxml.sourceforge.net http://curl.haxx.se/ http://code.google.com/p/twitcurl/

Tabulka 2.2: Tabulka použitých knihoven třetích stran

2.2.8

Použité knihovny třetích stran

V aplikaci jsme použili 3 "opensource"knihovny k zpracování operací, pro které standardní knihovny jazyka C++ neposkytují odpovídající prostředky. Snažili jsme se zvolit knihovny implementující pouze námi využívané funkce a vyhnout se tak použití větších a komplexních knihoven, jako je např. Boost (4). Kromě nárůstu velikosti celého projektu by hrozilo zanesení závislosti na konkrétní verzi knihovny, což je nežádoucí. Konkrétní licence jednotlivých knihoven: • cURL - MIT/X derivate license (6) • RapidXML - MIT License (24) • twitcURL - MIT License (28)

2.3

Navržené a implementované scénáře

V rámci diplomové práce jsme navrhli a implementovali několik scénářů využívající hračku Furby jako vstupně/výstupní zařízení. Scénáře dělíme do dvou hlavních skupin: infotainment a entertainment. • infotainment scénáře - mají za cíl uživateli zprostředkovat informaci nebo upozornit na určitou skutečnost • entertainment scénáře - hlavním cílem scénáře není zprostředkování informace, jde zejména o pobavení uživatele Námi navržené scénáře spadají zejména do skupiny infotainment scénářů. Mezi entertainment scénáře se řadí námi integrované hry Matematika a Lodě, dále pak přenesené scénáře originální hračky Furby (taneček, zpěv písničky).

2.3.1

Scénář Počasí

Scénář Počasí patří do skupiny tzv. infotainment scénářů stejně jako scénáře Burza a Citáty. Cílem scénáře je informovat uživatele o aktuálním počasí, případně o předpovědi na další dny, pokud si ji uživatel vyžádá. Předpověď se vztahuje k městu, které je možné konfigurovat v konfiguračním souboru nebo pomocí webového rozhraní. 45

2. Popis řešení 2.3.1.1

Návrh dialogu

Dialog jsme navrhli tak, aby byl uživatel schopen si kromě aktuální předpovědi vyslechnout i předpověď na některý z následujících dnů. Dále by při opakovaném spouštění scénáře neměl být uživatel obtěžován příliš dlouhou frází s nepodstatnými informacemi. Níže uvádíme příklad dialogu, ve kterém si uživatel vyžádá předpověď počasí na následující den. • Uživatel: What’s the weather? • Furby: Temperature at Prague is 14 degrees. • Furby: It’s overcast. Wanna know forecast? • Uživatel: < For tomorrow | after tomorrow | for {jméno zítřejšího dne} | for {jméno pozítřejšího dne} > • Furby: Temperature at Friday will be between 10-13 degrees celsius.

2.3.2

Scénář Burza

Dalším ze skupiny infotainment scénářů je scénář Burza, informující o aktuálním stavu akcií na burze. Scénář není interaktivní, tedy od uživatele není očekáván jakýkoliv vstup. Společnost, jejíž stav akcií je zjišťován je možné konfigurovat. 2.3.2.1

Návrh dialogu

Vzhledem k neustále měnící se hodnotě, která je předmětem sdělení, jsme ponechali tuto část dialogu bez určení časového údaje. • Uživatel: Market situation • Furby: Last trade value is 182.23

2.3.3

Scénář Citáty

Scénář Citáty, který je na pomezí skupin infotainment a entertainment scénářů, uživateli umožňuje vyslechnout si několik citátu z webu. 2.3.3.1

Návrh dialogu

Po spuštění scénáře je uživateli okamžitě poskytnut první z dostupných citátů a následně nabídnuto přečtení některého z dalších. Příkladem dialogu, ve kterém jsou uživateli sděleny 2 citáty je: • Uživatel: Tell me a quote 46

2.3. Navržené a implementované scénáře • Furby: Words ought to be a little wild for they are the assaults of thought on the unthinking. John Maynard Keynes • Furby: Wanna read next quote ? • Uživatel: < Yes | No > • Furby: College isn’t the place to go for ideas. Helen Keller • Furby: Wanna read next quote ? • Uživatel: < Yes | No >

2.3.4

Scénář Twitter

Sociální síť Twitter umožňuje snadným způsobem umisťovat krátké příspěvky, které je možné přiřadit do kontextu použitím tzv. hashtagu. Hashtag je druh řetězce začínající symbolem hash. Při použití hashtagu ve vyhledávání jsou vypsány chronologicky všechny příspěvky tento hashtag obsahující. Na internetu je možné nalézt mnoho agregátorů příspěvků na základě nalezených hashtagů. Na tomto principu funguje i scénář Twitter, v němž je možné poslat pomocí sítě Twitter vzkaz uživateli, který má v čase odeslání příspěvku běžící aplikaci. V tomto scénáři jsme implementovali zpracování jednoduchého vzkazu ve formátu #ibmfurby say Something kde #ibmfurby say jsou klíčová slova a Something libovolný řetězec. Ten je po parsování vzkazu odeslán na TTS výstup spolu s otevřením zobáku Furbyho. Vzkazy odeslané v čase kdy aplikace neběží jsou zahazovány a nelze je bez použití webového rozhraní zpětně vyvolat.

2.3.5

Scénář Alarm

Scénář Alarm jsme navrhli jako jednoduché upozornění v čase definovaném uživatelem. Tento čas může být nastaven s minutovou granularitou. Po jeho dosažení se Furby zakýve a oznámí spuštění alarmu.

2.3.6

Scénář Email

Notifikaci o příchozím emailu jsme integrovali s využitím API programu Lotus Notes (18). Program Lotus Notes lze nastavit tak, aby povolil přístup k lokální instanci spuštěného programu s Lotus ID pomocí C++ API bez hesla. Vzhledem k neexistenci funkce pro přímou kontrolu nových emailů bylo třeba najít způsob jak tuto funkci nahradit. Vyhovujícím řešením se ukázalo použití funkce GetAllUnreadEntries. Tato funkce vrací kolekci emailů, které jsou označeny jako nepřečtené, avšak až po tom, co proběhne replikace do 47

2. Popis řešení lokální databáze. Pro správnou funkčnost tohoto scénáře je tedy nutné nastavit interval lokální replikace emailů v programu Lotus Notes v délce stejné či kratší než je interval kontroly emailu pomocí funkce GetAllUnreadEntries. Po zjištění nového nepřečteného emailu se Furby zakýve a ohlásí příchod emailu.

2.3.7

Scénář Světlo

Jako jedno z možných použití námi navrženého zařízení se ukázalo hlasové ovládání některé z periferií připojených k PC. V ukázkové implementaci takovéto funkce jsme využili vývojový kit Arduino, připojený pomocí USB rozhraní. Ten slouží jako spínač žárovky, ovládaný pomocí námi zvoleného formátu příkazu. Tento scénář je typickou ukázkou autorizace jedné či více funkcí implementovaných v C++ aplikaci ze strany VoiceXML.

2.3.8

Scénář Kukačky

Scénář Kukačky vychází z faktu, že Furby samotný nemá žádné signalizační prvky, které by mohly informovat o tom, že je připojen k PC. Proto jsme implementovali jednoduchou a zároveň užitečnou formu notifikace uživatele, při níž se Furby každou čvrthodinu zakýve. Při celé hodině se pak zakýve dle počtu hodin.

2.3.9

Funkce Monitor

Při testování aplikace vznikla potřeba monitorovat její stav a informovat o jeho změně. K tomuto účelu jsme využili službu jednoho z portálů umožňující sběr dat od zařízení připojených k internetu. Uživatel může zvolit interval mezi odesláním informace o stavu aplikace na tento server. Ve výchozím nastavení je toto upozornění odesláno formou emailu při nepřijetí informace o stavu aplikace v intervalu delším než 2 minuty.

2.3.10

Funkce Plánovač

Tento modul umožňuje plánované spouštění scénářů poskytující interakci s uživatelem. Spuštění lze naplánovat na konkrétní datum a čas bez opakování, případně s opakováním v denních či týdenních periodách. Datum a čas je možné zadat ve formátu mm/dd/yy hh:mm. Konfigurace se provádí v konfiguračním souboru, případně prostřednictvím webového rozhraní.

2.3.11

Hry Matematika a Lodě

Matematika a Lodě jsou hry implementované v jazyku VoiceXML, které jsme upravili tak, aby byly interpretovalné hračkou Furby a využívaly jej k vyjádření emocí a nálad. Přepis těchto her ukazuje na způsob, jakým je možné využít 48

2.3. Navržené a implementované scénáře v aplikaci implementovaný stavový automat s autorizací ze strany VoiceXML souboru.

2.3.12

Vlastnosti a funkce původní verze hračky Furby

V naší implementaci jsme chtěli zachovat některé z funkcí a vlastností původní verze hračky Furby od firmy Hasbro. V té bylo možné použít několik málo hlasových příkazů ke spuštění jednoduchých scénářů. Povely a odpovídající scénáře, které jsme implementovali do naší aplikace jsou: • Show me a dance - spustí smyčku Furbyho pohybů spolu s přehráním zvukové stopy • Sing me a song - spustí krátkou zvukovou nahrávku • Tell me a quote - v původní verzi zněl příkaz "Tell me a joke". Vtipy jsme v naší verzi nahradili citáty.

2.3.13

Využité webové služby

Jako zdroj dat pro implementované scénáře používáme několika webových služeb. Služby jsme volili zejména podle formátu, ve kterém poskytují výstup a podle rozsahu poskytovaných dat. Dále jsme brali v úvahu poskytované API a uživatelskou přívětivost GUI. V současné době využívají webové služby několik možností pro formátování poskytovaného výstupu. Mezi nejpoužívanějšími formáty jsou: XML, JSON, CSV, TXT. Upřednostnili jsme proto služby poskytující data v některém z těchto formátů. 2.3.13.1

Scénář Počasí

Pro scénář Počasí používáme jako zdroj dat server Google, konkrétně službu Google Weather. Ten poskytuje aktuální stav počasí s předpovědí na další 3 dny v lokalitě, předané jako parametr HTTP požadavku metodou GET. Níže uvedené URL je příkladem požadavku na předpověď počasí v Praze. Výstup je formátován jako XML, k jehož zpracování používáme knihovnu RapidXML. http://www.google.com/ig/api?weather=Praha 2.3.13.2

Scénář Burza

Burzovní informace získáváme ze serveru Yahoo. Stejně jako v případě serveru Google je i zde parametr zadáván jako součást URL. Tímto parametrem je 3-4 písmenná zkratka firmy. Výstup je formátován CSV soubor. K jeho zpracování tudíž není třeba dodatečných knihoven. Následující URL vede k získání souboru s údaji o stavu akcií společnosti IBM Česká republika, spol. s r.o. 49

2. Popis řešení http://download.finance.yahoo.com/d/quotes.csv?s=IBM 2.3.13.3

Scénář Citáty

Ve scénáři citáty jsme jako zdroj dat zvolili jeden z RSS webových agregátorů. V průběhu ladění aplikace se ukázalo, že některé ze slov obsažených v citátech (zejména jména a geografické názvy) nejsou zpracovatelné pomocí TTS výstupu. Proto jsou při signalizovaném neúspěšném zpracování nahrazeny dalšími v pořadí. http://feeds.feedburner.com/quotationspage/qotd 2.3.13.4

Scénář Twitter

Knihovna twitCurl umožňuje snadně využívat API, které poskytuje server Twitter. Z této knihovny jsme využili funkci vyhledávání dle hashtagu. Návratovou hodnotou funkce je string obsahující výsledek vyhledávání ve formátu XML, který dále parsujeme a následně voláme callback funkci k provedení konkrétní akce. Odpovědí na úspěšné provedení takto poslaného příkazu je přidání příspěvku na vlastní účet. Tak si autor může ověřit zda se jeho vzkaz skutečně provedl. Přidání příspěvku je možné pomocí metody statusUpdate. Před samotným voláním této funkce je nutné se ke svému účtu autentizovat metodou OAuth (21). OAuth protokol je poměrně novým přístupem k problému, jak umožnit uživateli aplikace přístup k webové službě, bez předání přístupových údajů třetí straně. Uživatel je po požadavku o poskytnutí přístupu k dané službě přesměrován na webovou stránku této služby, kde se klasicky autentizuje. Poté je aplikaci vystaven jeden či více API klíčů, poskytující přístup k omezené sadě funkcí. Obrázek 2.5 ukazuje jednotlivé kroky v průběhu autentizace pomocí protokolu OAuth. 2.3.13.5

Funkce monitorování

K uchování informace o tom, zda je aplikace spuštěná a běží jsme využili služby portálu Exosite. Portál poskytuje přehledné API a jednoduché GUI. Navíc je zde možné nastavit několik různých variant notifikací a varování. Autentizace pro zápis hodnoty asociované k danému zařízení je provedena pomocí předání klíče zařízení v hlavičce HTTP požadavku. Důležitou vlastností této služby je možnost nastavit viditelnost takto zaslaných údajů pro ostatní uživatele. Ta je v případě tohoto typu údajů nepodstatná, nicméně pro některé druhy aplikací kritická. Kromě datové řady state, která určuje stav aplikace, udržujeme také datovou řadu resources. Ta signalizuje, zda jsou všechny využívané webové zdroje dostupné. 50

2.4. Kinect

Obrázek 2.5: OAuth autentizace (převzato z (21))

Příklad požadavku k zapsání hodnoty 1 do datové řady pojmenované state je uveden níže. POST / HTTP/1.1 X-Exosite-CIK: 11223344556677889900aabbccddeeff Host: m2.exosite.com/api:v1/stack/alias Content-Type: application/x-www-form-urlencoded Content-Length: 7 state=1

2.4

Kinect

V rámci diplomové práce jsme do aplikace zaintegrovali vzdálené ovládání pomocí zařízení Kinect. Motivací k tomuto kroku, bylo umožnit uživateli spouštět některé ze scénářů hračky Furby gestem. To je výhodné v situaci, kdy je uživatel svázán nedostatkem času, nebo nemá přímý přístup k zařízení. Obsluha zařízení Kinect byla implementována jako samostatný modul. Možnost ovládat hračku Furby lokálně je při použití Kinectu zachována. Ovládání pomocí Kinectu je však možné pozastavit, aby při lokálním používání nedocházelo k rušení. Při implementaci jsme vycházeli z již předpřipravené knihovny, která Kinect využívá k detekci přítomnosti člověka. Knihovna byla vyvíjená v rámci výzkumého projektu ve společnosti IBM Česká republika, spol. s r.o. (10). 51

2. Popis řešení

2.4.1

Popis zařízení

Kinect je produktem firmy Microsoft, která jej vydala v roce 2010. Jde zařízení, které ve své původní verzi bylo určeno jako doplněk herní konzole Xbox, která umožňuje hrát některé z her pomocí gest a pohybů. To je umožněno integrací RGB kamery, hloubkového senzoru a všesměrového mikrofonu. RGB senzor je využit zejména k rozpoznávání obličeje. Hloubkový senzor, který je tvořen infračerveným projektorem a monochromatickým CMOS senzorem umožňuje trojrozměrné snímání prostoru (44). Tento Kinect je možné použit po připojení redukce konektoru také na PC. K vývoji aplikací využívajících Kinect pro XBox je možné využít některé z volně dostupných knihoven. V únoru 2012 firma Microsoft vydala novou verzi Kinectu, která je určená pro použití v operačním systému Windows. K této verzi již firma Microsoft vydala oficiální SDK, které je možné použít k vývoji vlastního software. Kinect pro Windows se od původního liší v několika ohledech. Umožňuje využívat hloubkový senzor až do vzdálenosti 40 cm od Kinectu. Původní verze uměla tento senzor využít až od vzdálenosti 80 cm. Mezi další změny patří kratší délka USB kabelu, jehož zkrácení bylo nutné pro zachování kompatibility při použití u různých základních desek.

2.4.2

Implementace

Obsluha zařízení Kinect je implementován jako Control plugin. Běží tedy v samostatném vlákně jako nekonečná smyčka ve které je prováděna obsluha událostí přicházejících ze zařízení Kinect. Pro provedení konkrétní akce po příchozí události využívá knihovna OpenNI callback funkcí. Tyto funkce je nutné po inicializaci zařízení registrovat k jedné či více události, které Kinect dokáže rozpoznat. Událostí může být např. příchod nového uživatele, provedení některého z gest, zaregistrování uživatelovy ruky a jiné. K využití těchto callback funkcí v kooperaci s hračkou Furby je třeba v modulu před jeho spuštěním přiřadit ukazatel na funkci furbyControl, pomocí níž je možné vykonat Furby specifické akce. Přiřazení ukazatele je provedeno při registraci modulu Plugin Managerem před spuštěním vlákna. V naší implementaci jsme použili knihovnu OpenNI (23), která poskytuje API pro programování aplikací v jazyku C++. Dále pak knihovnu OpenCV (22) pro zobrazení ladících oken, které jsme využili k ladění aplikace. Použití takového zařízení může být výhodné např. v kancelářském prostředí, kde by jednotlivá gesta autorizovala spuštění některého z interaktivních scénářů. Tuto funkčnost jsme implementovali a otestovali. Další scénář použití zařízení Kinect ve spojení s hračkou Furby byl předveden při příležitosti akce IBM Forum 2012 (11). Významným přínosem této akce bylo možnost pozorovat reakci uživatelů na netradiční uživatelské rozhraní a také míru schopnosti nezkušeného uživatele vykonat rozpoznatelná gesta, které mu byly popsány pouze hlasovým výstupem. 52

2.5. Talking Head

2.4.3

Příklad scénáře

Scénář je navržen formou postupného seznamování a učení uživatele jak ovládat hračku Furby prostřednictvím zařízení Kinect a následně lokálně, tedy tlačítky a hlasem. Reakcí na příchozí události ze zařízení Kinect v režimu vzdáleného učení je informování uživatele o dalším očekávaném kroku (provedení gesta). Po dokončení učícího režimu Furby, na uživateli již známá gesta, reaguje interpretací dat některé z informačních služeb (počasí, burza). Scénář počítá také s možností interakce více uživatelů. Z toho důvodu jsme prostor před Kinectem rozdělili do 3 zón, jejichž hranice jsou konfigurovatelné. • zóna 0 - prostor těsně před Kinectem, prostor pro lokální interakci s hračkou Furby • zóna 1 - prostor za zónou 0, prostor pro vzdálenou interakci 1 osoby s hračkou Furby • zóna 2 - prostor za zónou 1 Pokud se Furby nenachází v lokálním či vzdáleném učícím režimu, reaguje v závislosti na počtu osob v zónách 1 či 2. Pokud na výzvu Furbyho není detekována žádná odezva ze strany uživatele, je výzva ještě jednou zopakována. Poté Furby v tomto stavu přetrvává bez dalších upozornění uživatele. Funkci opakovaných výzev jsme implementovali pomocí uložení pointeru na poslední volanou funkci při změně stavu. Tento pointer potom využíváme po uplynutí času definovného konstantou.

2.5

Talking Head

Aplikace Talking Head je ukázkou jednoho z možných vstupně/výstupních zařízení zakomponovaných do vytvořeného toolkitu a využívající jeho služby.

2.5.1

Popis aplikace

Talking Head (40) je aplikace umožňující komplexní obsluhu 3D modelu hlavy zobrazeného na obrazovce. K tomuto účelu je připraveno API v jazyce C a Java. Aplikace je postavena na architektuře typu klient server. K serveru, který zpracovává klientské požadavky a obsluhuje hlavu, je možné se připojit z více klientů zároveň. Server podporuje několik typů těchto požadavků a očekává jejich odeslání ve formátu XML. Základními elementy XML formátovaného dokumentu, které využíváme jsou • <speak> - tag <speak> slouží k obsluze promluv hlavy, uzavírá text který je určen k přečtení 53

2. Popis řešení • - všechny elementy uzavřené v tagu jsou serverem aplikace souhrnně zpracovány. Těmito vnořenými tagy mohou být – - tag je možné využít ke kontrole mimiky hlavy, jejího pohybu a umístění – - do tagu je možné umístit text, který má být zobrazen na obrazovce s mluvící hlavou

2.5.2

Implementace

V implementaci aplikace Talking Head, jsme využili již existující API v jazyce C, které jsme integrovali do nového modulu našeho toolkitu. Režii spouštění serverové části jsme do aplikace nezanesli a implementovali pouze klientskou část. Dále bylo třeba upravit funkce námi definovaného rozhraní tak, aby se dala provádět autorizace rozdílných akcí modulu. Předávaný parametr typu string, který je předáván funkci init, jsme využili zároveň ke specifikaci typu akce. Tento typ akce je v parametru umístěn za oddělující dvojtečkou. Znamená to například, že pro volání modulu ecaf a spuštění akce init je nutné Plugin Manageru předat string ve formátu ecaf:init Struktura furbyAction spolu s funkcí furbyControl v podobě, v jaké jsou popsány v kapitole 2.2 neumožňovaly volání funkcí jednoho modulu z druhého. Proto jsme strukturu rozšířili o prvek typu std::string s názvem pluginCall. Pomocí něj je možné možné autorizovat funkce jiných načtených modulů stejným způsobem, jako při zpracování příchozích XVB událostí.

2.5.3

Příklad scénáře

Ve scénáři s aplikací Talking Head, jsme využili již existujícího napojení na zařízení Kinect. Cílem této demo aplikace je uvítat a informovat návštěvníky některé z přednášek či akcí o jejich programu. Aplikace je v tomto scénáři provozována na dotykovém kiosku nad nímž je umístěn Kinect. Ten slouží k detekci přítomnosti jedné či více osob. Pokud je před kioskem přítomna právě jedna osoba po dobu definovanou konstantou, je spuštěna uvítací promluva hlavy. Následně je z webu stažen soubor s informacemi o akcích, který poté rozparsujeme a pomocí API aplikace Talking Head zobrazíme na obrazovce. Po odchodu uživatele je obnoven původní stav obrazovky. Lze vidět, že navrhnutá architektura umožňuje využít výstup funkcí jednoho z načtených modulů pro kontrolu jiného. V tomto případě je autorizace funkcí nabízených module obsluhující aplikaci Talking Head prováděna z modulu obsluhující Kinect. 54

2.6. Webové rozhraní

2.6

Webové rozhraní

Vytvoření webového rozhraní sloužícího ke konfiguraci ovládacího software hračky Furby vyplynulo ze stále se zvětšující množiny konfigurovatelných parametrů. Vyhledávání jejich významu a možných nabývajících hodnot je pro uživatele zdlouhavé. Samotná editace konfiguračního souboru také není pro uživatele neznalého formátu XML úplně srozumitelná. Webové rozhraní jsme navíc využili ke konfiguraci dialogového menu, které manuální editací konfiguračního souboru pozměnit nelze.

2.6.1

Použité technologie

Implementaci jsme provedli v jazyku Perl, který je stejně jako stejně jako skripty scénářů zpracováván skrze cgi bránu. Výsledkem je vygenerovaná HTML stránka zobrazená uživateli v prohlížeči. Dále používáme služeb javacriptových knihoven simpleModal (43) a JQuery (16).

2.6.2

Popis použití ve vztahu k hračce Furby

Webové rozhraní úplně nahrazuje manuální spouštění VoiceXML browseru a ovládací aplikace. Jeho použití však zůstává volitelné a není nutnou podmínkou k provozu aplikace. Zároveň je pomocí něj možné za běhu aplikace pozastavit či znova spustit moduly pro vzdálené ovládání a provádět celkovou konfiguraci aplikace.

2.6.3

Popis funkčnosti

Obsah webového rozhraní je generován dynamicky. Data potřebná k vygenerování jsou získána pomocí exportovaných funkcí DLL knihoven představující jednotlivé moduly. Tyto funkce vracejí data, která jsou určena direktivami DEFINE preprocesoru jazyka C. Výhodou je možnost aktualizace aplikace pouze poskytnutím DLL knihovny, případně mediálních souborů jako obrázky a zvuky, bez nutnosti jakkoliv zasahovat do kódu webového rozhraní či konfiguračního souboru. Následuje ukázka použití těchto direktiv u modulu Burza. #define #define #define #define

NAME "Stocks Plugin" ABOUT "Actual information about stocks in a Furby way" PARAMETERS "Company:string;Daemonized:bool" DEPENDS_ON "FetchPlugin XMLPlugin"

Sémantika je dána následovně • NAME - jméno modulu • ABOUT - krátký text o funkci modulu 55

2. Popis řešení • PARAMETERS - parametry modulu oddělené středníkem, za jménem parametru je po dvojtečce očekáván typ parametru. Akceptovány jsou typy string, integer a bool. Podle nich je potom přizpůsoben formulářový prvek ve webovém rozhraní. • DEPENDS_ON - výčet pomocných knihoven na kterých je modul závislý oddělených mezerou Níže uvádíme příklad exportované funkce name() vracející typ LPSTR (Long pointer to string) extern "C" __declspec(dllexport) LPSTR name() { return NAME; } 2.6.3.1

Spouštění aplikace a indikace jejího stavu

Uživatel může spustit, případně ukončit aplikaci pomocí webového rozhraní. Dialog pro tuto činnost je možné vyvolat kliknutím na obrázek hračky Furby v levém dolním rohu. Stav spouštění je zobrazován v indikátoru a ve stavovém řádce. Spuštění aplikace lze v jakékoliv fázi zastavit. Stav spuštěno/vypnuto je signalizován barvou obrázku hračky Furby v levém dolním rohu - černobílý obrázek indikuje vypnutou aplikaci, barevný zapnutou. Tento stav je sdílen v rámci session pro všechny stránky aplikace. Spuštění aplikace provádíme pomocí volání AJAX funkce, po kterém si v session uchováme process ID, jako identifikátor pro pozdější ukončení. Funkce jazyka Perl vytvářející nový proces je obsažena v modulu Win32::Process. Pro ukončení procesu VoiceXML browseru je použita funkce kill, pomocí které vyšleme procesu signál SIGHUP. V případě že se uživatel rozhodne proces spouštění aplikace v jeho průběhu ukončit, je stejný způsob ukončení použit i pro ovládací aplikaci. Pro tento případ jsme implementovali funkci pro zpracování signálu SIGHUP a na tento signál zavěsili pomocí funkce BOOL __stdcall SetConsoleCtrlHandler(PHANDLER_ROUTINE HandlerRoutine, BOOL Add) V okamžiku, kdy se uživatel rozhodne aplikaci ukončit po jejím úspěšném spuštění, je namísto signálu SIGHUP aplikaci poslán příkaz quit pomocí TCP/IP protokolu na port 20248, po jehož přijetí proběhne korektní ukončení aplikace. Ve stejném dialogovém okně je možné aktivovat nebo deaktivovat moduly pro vzdálené ovládání, jejichž stav je opět promítnut v konkrétní session. 2.6.3.2

Konfigurace modulů

Jména a typy modulů jsou načteny pomocí volání exportovaných funkcí DLL knihoven s moduly. Volání je umožněno použitím modulu Win32::API jazyka 56

2.6. Webové rozhraní Perl. Již konkrétní nastavené hodnoty těchto parametrů jsou načteny z aktuálního konfiguračního souboru aplikace a dle těchto údajů jsou následně vygenerovány předvyplněné formuláře modálních oken. Tyto konfigurační okna lze vyvolat kliknutím na obrázek modulu. Následně dojde při načtení stránky k navěšení AJAX funkcí na událost onChange formulářových prvků. Tyto funkce zajišťují zápis změněných parametrů zpět do konfiguračního souboru aplikace. 2.6.3.3

Konfigurace dialogového menu

Strukturu dialogového menu, pomocí něhož uživatel komunikuje s hračkou Furby, je možné měnit přetahováním drag & drop prvků v seznamu. Uživateli jsou nabídnuty 2 úrovně menu, přičemž do 1. úrovně se dostane po stisku předního tlačítka a tudíž není potřeba definovat gramatiku k jeho dosažení. Pro přesun do 2. úrovně menu a spuštění některého z interaktivních modulů je možné tuto gramatiku dodefinovat pomocí textových polí, umístěných ve stejném řádku seznamu. Gramatika je změněna dynamicky pomocí události onChange textového pole a technologie AJAX (konkrétně modulu CGI::Ajax jazyku Perl), která zajišťuje zápis provedených změn do souboru. Struktura menu je změněna podobným způsobem a liší se pouze v události, která spouští AJAX požadavek (v tomto případě je to událost dropped).

Obrázek 2.6: Konfigurace dialogového menu ve webovém rozhraní

2.6.3.4

Plánování akcí

Stránka s názvem Schedule je grafickou nadstavbou pro modul Plánovač. Jejím prostřednictvím je možné uživatelsky přívětivým způsobem nastavit typ 57

2. Popis řešení akce, čas jejího spuštění, případně interval opakování. Naplánované akce lze libovolně přidávat, odstraňovat, případně editovat. U každé položky v tomto seznamu akcí je uživateli zobrazeno kolik zbývá času do jejího spuštění. V případě že je u akce nastaven interval opakování, je tento čas zobrazen i graficky, procentuálním podbarvením pole se zbývajícím časem. Na stránce jsme implementovali časovač, který v minutových intervalech přepočítává zbývající čas do spuštění akce a na stránce ho poté aktualizuje. Díky použití volání AJAX funkcí není nutné stránku po každé R/W operaci aktualizovat.

Obrázek 2.7: Plánování akcí ve webovém rozhraní

2.6.3.5

Widgety

V průběhu vývoje a testování aplikace se ukázalo, že některé moduly vyžadují kromě možnosti konfigurovat parametry také další prvek pro interakci s uživatelem. Pro tento případ jsme vyhradili pravý panel webové aplikace, kde je možné umístit k modulu panel s informací či funkčním HTML prvkem (tlačítkem a jiným). K existujícím modulům jsme implementovali dva ukázkové widgety. Jedním z nich je Twitter widget. Jeho funkcí je agregace twitter příspěvků, které jsou na síti vystaveny ve formátu zpracovatelném pomocí Twitter modulu. Uživateli je po připojení k hračce Furby zobrazen náhled pěti posledních příspěvků s možností si je znova přehrát. Druhým implementovaným widgetem je panel zobrazující nejbližší akci, která bude spuštěna Plánovačem. 58

2.7. Shrnutí

2.7

Shrnutí

V této kapitole popisujeme námi navrženou architekuru aplikace a implementaci dílčích celků. V úvodu zmiňujeme externí aplikace a závislosti, které využíváme společně s jejich významem v kontextu aplikace. Zvláštní pozornost věnujeme návrhu interface jednotlivých typů modulů. Dále se zabýváme rozborem navržených scénářů a s němi spojených dialogů. U scénářů využívajících některou z webových služeb tyto služby samostatně Zvlášť uvádíme zakomponování zařízení Kinect, sloužící k vzdálenému ovládání, a aplikaci TalkingHead, kterou používáme jako jednu z možných dalších vstupně/výstupních platforem. Závěr obsahuje popis námi vytvořeného webového rozhraní, které používáme k celkové obsluze aplikace a její konfiguraci. Vytvořenou aplikaci lze použít k obsluze i jiných zařízení či SW produktů s využitím většiny implementovaných služeb. Při provozu aplikace např. v kiosku nebo jiném veřejném prostředí je velmi užitečný modul pro monitorování takto nastaveného dema. Umožňuje značně rychlejší odezvu na případné chyby v implementaci. Při implementaci scénářů jsme doposud nevyužili čidlo indikující zda Furby stojí či leží. Jeho použití si nicméně dokážeme představit hlavně u bezdrátové verze, kde nejsou na obtíž okolní kabely.

59

Kapitola

Testování Při iterativním vývoji námi navrženého řešení, jsme shromáždili značný počet námětů a připomínek od nezávislých pozorovatelů. Tyto náměty pro nás byly velmi cennou zpětnou vazbou. Pro objektivní posouzení použitelnosti navrženého řešení však bylo nutné provést formální test s uživateli.

3.1

Formální test s uživateli

Níže uvádíme seznam otázek, které byly součástí formálního testu. Stupnice hodnocení je nastavena od 1 do 10, přičemž 10 znamená nejvíce kladnou odpověď, 1 nejvíce zápornou. U každé otázky je vynechán prostor pro případný komentář. Dotazník, který byl předložen uživatelům, je součástí přílohy. Testování aplikace s připojenou hračkou Furby proběhlo na konfiguraci: • Intel Core 2 Duo 2.4 GHz, 2 GB RAM • Windows XP Professional • Grafická karta: Mobile Intel GMA 4500MHD Testování aplikace ve scénáři spolu s aplikací Talking Head proběhlo na konfiguraci: • Intel Core2 Duo 2.4 GHz, 3 GB RAM • Windows XP Professional • Grafická karta: ATI Mobility FireGL V5200

3.1.1

Průběh formálního testu

Formální test se skládal z několika částí, kterými byly: • Představení hračky Furby 61

3

3. Testování • Předvedení scénáře se zařízením Kinect (postupné učení vzdáleného a lokálního ovládání hračky Furby) • Ukázka webového rozhraní, sloužící ke konfiguraci a ovládání • Vyplnění formuláře s otázkami Formální test byl proveden s každým účastníkem samostatně, tak aby nedocházelo k jejich vzájemnému ovlivňování. Účastníky testu byli lidé, kteří neměli předchozí zkušenosti s používáním hračky Furby.

3.1.2

Vyhodnocení formálního testu

K statistickému ohodnocení otázek, u nichž byla uvedena hodnotící stupnice jsme použili střední hodnotu a rozptyl. Otázka 1. Přáli byste si hračku Furby vlasnit a mít umístěnou na kancelářském stole ?

Střední hodnota (µ)

Rozptyl (σ 2 )

9

0.6

2. Jak hodnotíte vizuální stránku hračky Furby ?

9.3

0.41

3. Myslíte si, že je ovládání hračky Furby přirozené ?

8.2

0.96

4. Považujete ovládání řečí za dostatečně robustní ?

6.9

0.89

9.1

0.49

9.5

0.25

7. Jaké další funkce byste od hračky Furby očekávali ?

—

—

8. Je podle Vás webové rohraní dostatečně intuitivní ?

8.4

1.04

5. Rozuměli jste všem pokynům a sdělením, které Vám Furby předal ? 6. Myslíte si, že je vzdálené ovládání pomocí zařízení Kinect užitečné ?

Tabulka 3.1: Hodnocení dotazníkových otázek

62

3.1. Formální test s uživateli 3.1.2.1

Hodnocení otázky č. 1

Uživatelé odpovídali na otázku kladně. Všichni si dokáží představit její použití v domácím či kancelářském prostředí. V sekci komentářů souvisejících s otázkou byla zmíněna připomínka předpokládající bezdrátové spojení s PC v reálném nasazení. Hračka Furby bezdrátový přenos zvuku podporuje, nicméně integrovaný mikrofon by pro tento účel bylo nutné vyměnit za kvalitnější. 3.1.2.2

Hodnocení otázky č. 2

Vzhled hračky Furby u uživatelů vyvolal kladné pocity. Komentáře se týkaly možného negativního přijetí vzhledu hračky malými dětmi, pro které byla nicméně původní verze hračky určena. 3.1.2.3

Hodnocení otázky č. 3

Nejvíce komentářů v testu bylo uděleno k otázce týkající se navrženého ovládání. Rozporuplně působila funkce dvojkliku, která kvůli nepřesnosti senzoru často uživatele mátla. Jeden z testujících také vyjádřil názor, že by tuto funkci nevyužil vůbec. Několik komentářů se zmiňovalo o užitečnosti funkce zadního tlačítka, které slouží k okamžitému přerušení probíhajícího scénáře. Velmi užitečnou byla shledána možnost vyvolání nápovědy v obou úrovních dialogového menu. Ve všech komentářích udělených k otázce se vyskytla zmínka o užitečnosti gesta zvednutých uší Furbyho, symbolizující otevření mikrofonu. 3.1.2.4

Hodnocení otázky č. 4

Ve většině komentářů bylo uvedeno, že dochází poměrně často k přeslechům, vedoucím ke spuštění jiného scénáře než žádá uživatel, případně k jakémukoliv spuštění nedojde vůbec. Jednou z možností, jak tento jev omezit, je definovat co nejvíce ortogonální gramatiku k spouštění scénářů. Další možností je snížení hlasitosti nastavené na mikrofonním vstupu. V úvahu připadá také kompletní výměna mikrofonu za citlivější. 3.1.2.5

Hodnocení otázky č. 5

Z výsledků jde pozorovat, že velká část uživatelů neměla problém s porozuměním textům, které byly zpracovány pomocí TTS. Dle názoru testujících však reproduktor hračky Furby není vhodný pro samostatné použití bez přídavných reproduktorů. V části komentářů byla zmíněna skutečnost, že použitý hlas TTS enginu neodpovídá vizuálnímu zpracování hračky Furby. Uživatelé dle testu očekávali hlas více hravý a spíše ženský než mužský. Pro dosažení tohoto výsledku by bylo třeba použít rozdílnou verzi programu Charlie browser. 63

3. Testování 3.1.2.6

Hodnocení otázky č. 6

Výsledek testu říká, že ovládání pomocí zařízení Kinect je užitečné. Komentáře k otázce se týkaly zrobustnění detekce gest, která ještě není na dostatečně spolehlivé úrovni. Někteří z uživatelů by uvítali možnost spuštění některého z implementovaných scénářů v reakci na příchod či odchod ze zorného pole zařízení Kinect. V sekci komentářů bylo navrženo také několik nových gest, které by mohl Kinect detekovat. 3.1.2.7

Hodnocení otázky č. 7

Jedna z odpovědí k této otázce směřovala k vytvoření mobilní aplikace umožňující vzdálené ovládání, případně by jinak integrovala funkce hračky Furby. Dalším návrhem, byla možnost využít hračku Furby k přehrávání hudby, rádia či propojení se sociální sítí Facebook. Jiný komentář se zabýval integrací webkamery, která by mohla být umístěná místo očí a používána například pro komunikaci v programu Skype. Jeden z účastníků formálního testu také projevil zájem o implementaci obecného POP3/IMAP klienta, sloužícího ke kontrole emailu. 3.1.2.8

Hodnocení otázky č. 8

Výsledná střední hodnota říká, že uživatelé neměli závažnější problém s použitím webového rozhraní, nicméně je zde stále hodně prostoru k jeho vylepšování. Jedna z poznámek se zmiňovala o rozšíření kompatibility pro více prohlížečů, jelikož aktuální verze je navržena pro prohlížeč Firefox. Základní funkčnost je však zaručena i pro ostatní známé prohlížeče. Dalším návrhem byla možnost provádět aktualizace ovládací aplikace a pluginů skrze toto webové rozhraní, což by jistě bylo pro uživatele příjemné.

3.1.3

Shrnutí

K objektivnímu vyhodnocení navrženého řešení jsme využili formálního testu s uživateli, kteří měli možnost vyzkoušet netradiční uživatelské rozhraní vytvořené pomocí hračky Furby a zařízení Kinect. Při začátku testování byla znát určitá nejistota z neznámého uživatelského prostředí, nicméně proces postupného učení pomohl uživateli k poznání dostupných funkcí hračky Furby a jejich ovládání. Návrh ovládání byl v testu ohodnocen kladně, zejména díky vypracované nápovědě, přítomnosti aktivačního tlačítka a upozorňovacího gesta zvednutých uší. Funkci dvojkliku k rychlému spuštění zvoleného scénáře bez hlasové volby je nutné ještě zvážit, případně zrobustnit tak, aby nedocházelo k falešným spouštěním. Výsledek robustnosti ovládání řečí nebyl v testu příliš pozitivní, proto jsme navrhli několik možných úprav jak ho zlepšit. I přesto, že část testujících ovládala anglický jazyk na základní úrovni, nebylo pro ně 64

3.1. Formální test s uživateli problémem porozumět mluveným anglickým textům. K tomu dopomohly přídavné reproduktory, které značně zvyšovaly kvalitu zvuku. Dále přispěly také navržené dialogy s účelem používat co nejjednoduší anglické výrazy a zároveň krátké věty obalující konkrétní informaci, která má být uživateli předána. Možnost interagovat s hračkou Furby pomocí zařízení Kinect byla pro testující velmi atraktivní a v testu byla obohacena o několik návrhů týkajících se nových rozpoznatelných gest. Robustnost detekce gest je v tomto případě záležitostí použité knihovny OpenNI. Kromě přechodu k jiné knihovně obsluhující Kinect či napsání vlastního algoritmu je tedy jedinou možností počkat na vyšší verzi knihovny, umožňující robustnější detekci. Webové rozhraní, jehož možnosti jsme uživatelům ukázali po ukončení scénáře, je dle uživatelů dostatečně intuitivní. Zatím je však z větší části pouze grafickou nadstavbou nad konfiguračním souborem. Je zde však implementována poměrně důležitá konfigurace dialogového menu, možnost aktivace/deaktivace zařízení Kinect za běhu aplikace a několik málo jiných funkcí, které uživateli umožní to, co nelze provést manuální editací konfiguračního souboru. Z výsledků jde vidět, že námětů a nápadů na případné další funkce, které by mohla hračka Furby plnit, je více než dostatek. Několik uživatelů se dokonce nabídlo k pravidelnému zkoušení nových verzí, případně k dlouhodobému testování aktuální verze, což svědčí o zájmu nad tímto netradičním uživatelským rozhraním.

Obrázek 3.1: Graf vyhodnocení formálního testu s uživateli

65

3. Testování

3.2

Zkušenosti a reakce uživatelů na netradiční UI

Kromě formálního testu na 10 uživatelích, jsme v rámci iterativního návrhu aplikace implementované scénáře předvedli několika skupinám uživatelů. Získané poznatky jsou však pouze subjektivními dojmy, případně odpověďmi na neformálně položené otázky. Implementovaný scénář, kde jsme využili zařízení Kinect, byl předveden na akci IBM Forum 2012. Návštěvníci měli možnost vyzkoušet si ovládání Furbyho a následně vyjádřit svůj názor, případně připomínky. Je nutné poznamenat, že při tomto konkrétním nastavení aplikace jsme použili doplňkové externí reproduktory, jelikož reproduktorek integrovaný v hračce Furby není dostatečně hlasitý. Aktivní byly pouze některé z funkcí Furbyho a to scénáře Počasí, Burza, Taneček a Matematika. Tento omezený počet jsme zvolili pro zpřehlednění dialogového menu a také kvůli hlučnému okolnímu prostředí, které by neumožnilo jednoznačné rozpoznání.

3.2.1

Reakce uživatelů na netradiční uživatelské rozhraní v podobě hračky Furby a zařízení Kinect

Jedny z prvních reakcí bylo možné získat po příchodu uživatele a vysvětlení funkce vystavovaného zařízení. • Uživatelé byli potěšení, avšak ne překvapení možností interakce pomocí hračky Furby a zařízení Kinect • Hračka Furby je dle většiny uživatelů jednou z možných reprezentací designově zdařilého avatara • Nikdo z uživatelů neměl zkušenosti s použitím některého z dostupných elektronických společníků

3.2.2

Schopnost reakce uživatelů na pokyny předané pomocí TTS výstupu a interpretované hračkou Furby

Důležitým bodem sledování, byla schopnost porozumění uživatele pokynům, udělených hračkou Furby. • Uživatelé dostatečně rozuměli a chápali význam udělených instrukcí z hlediska kvality zvukové reprodukce. Vhodně zvolená se ukázala i gramatická náročnost vět v anglickém jazyce. • U vzdáleného ovládání pomocí zařízení Kinect většina uživatelů nedokázala provést požadovaná gesta dostatečně zřetelně. Snaha provést gesto správným způsobem se dramaticky snížila již po druhém, případně třetím neúspěšně provedeném gestu. V aplikaci jsme proto implementovali několik debuggovacích oken, které nám pomohly indikovat úspěšné detekování některého z gest. Okna zobrazují hloubkovou mapu, název aktuálně detekovaného gesta a číslo zóny, ve které se uživatel nachází. 66

3.2. Zkušenosti a reakce uživatelů na netradiční UI • V případě, že uživatel viděl způsob, jak provést gesto tak, aby se maximálně zvýšila pravděpodobnost správného rozpoznání, byl schopen velmi rychle tento způsob úspěšně napodobit. • V rámci lokálního učení nebyli uživatelé schopni správné manipulace se senzory umístěných na hračce Furby. To je způsobeno nedostatečnou přesností těchto senzorů a jejich špatnou přístupností. Zejména zadní tlačítko je velmi těžce použitelné i pro uživatele znalého jeho umístění. Jedno z možných pokračování práce by tedy mohlo být věnováno nahrazení těchto mechanických senzorů za dotykové. • Velmi kladně působilo gesto zvednutých uší Furbyho, upozorňující na otevření mikrofonu. • Emotivně nezabarvený hlas, formantového typu bez použití SSML tagů působil velmi ve spojení s tímto scénářem velmi věrně

3.2.3

Vedení dialogu

Další poznatky se týkají úspěšnosti uživatelů vést s hračkou Furby dialog. • Uživatelé byli schopni využít funkce nápovědy (vyvolatelnou několika různými povely) • Vzhledem k tomu, že konverzaci rušil všudypřítomný hluk, bylo rozpoznávání často neúspěšné. Tento neduh jsme se snažili alespoň částečně eliminovat stažením úrovně mikrofonu na přijatelnou úroveň

3.2.4

Robustnost aplikace

Vzhledem k délce trvání akce se také dala do jisté míry otestovat stabilita a robustnost ovládací aplikace a Charlie ebrowseru jako samostatně běžícího celku. Při tomto delším kontinuálním běhu aplikace se ukázalo několik chyb aplikace, které byly následně opraveny. Při spouštění jednoho konkrétního VXML souboru ve VoiceXML browseru docházelo pravidelně k pádu této aplikace, což se nicméně neukázalo jako implementační chyba aplikace či scénáře a tato chyba byla záhy opravena.

3.2.5

Shrnutí, přípomínky

Ač se to zdá jednoduché, zajistit robustní funkci pro větší množství uživatelů a v obtížném prostředí je složité. Velkou roli sehrálo nastavení zařízení Kinect, které je velmi citlivé na okolní prostředí. Je zřejmé, že nastavení tohoto zařízení při použití např. v kancelářském prostředí je třeba pečlivě zvážit. Pro správnou funkci je nutné vybrat vhodný prostor v zorném poli senzorů tak, 67

3. Testování aby nedocházelo k zachytávání falešných osob, nebo k nesprávnému rozpoznání gest. Tato situace se dá v současné době částečně řešit implementací vlastního middleware nad knihovnou OpenNI. Z akce IBM Forum vzešlo poměrně velké množství podnětů, směřujících k rozsahu funkcí, které by měl Furby poskytovat, k jeho nedostatkům a dalším souvisejícím záležitostem. Zároveň jsme byli schopni podchytit značné množství drobných chyb, při běžném testování těžko odhalitelných. Pozorování uživatelů při používání netradičního UI značně přispělo k dalšímu zdokonalení aplikace, a to zejména v úpravách navržených dialogů. Odpovědím na neformální otázky nelze připisovat velký význam, jsou nicméně nedílnou součástí testování.

3.3

Testování scénáře s aplikací Talking Head

Dalším testem prošla implementovaná aplikace ve scénáři s aplikací Talking Head a zařízením Kinect. Provoz probíhal na notebooku s připojeným externím monitorem nad kterým byl umístěný Kinect. Na externím monitoru bylo zobrazeno okno s mluvící hlavou, na obrazovce notebooku jsme sledovali ladící informace programu. Částečně jsme ověřili stabilitu aplikace díky nepřerušenému spuštění po dobu několika dní, během kterých obsluhovala aplikaci Talking Head a Kinect. Funkčnost komponenty zajišťující asynchronní spouštění akcí jsme ověřili použitím pluginu pro monitorování běhu aplikace a nastavením pravidelného stahování kalendáře s aktuálními událostmi. Bylo znát, že navržená aplikace spolu s načteným pluginem pro obsluhu zařízení Kinect využívá značné množství paměti a výrazně zatěžuje procesor. To vedlo k značnému zahřívání notebooku, které v několika případech vyústilo v jeho pád. Zlepšení v tomto ohledu může nastat s vydáním nové verze knihovny OpenNI, kterou používáme ke zpracování dat ze zařízení Kinect.

68

Závěr V rešeršní část jsme uvedli několik zařízení, sloužících ke zprostředkování informace uživateli. Vzhledem k jejich velkému počtu jsme detailně popsali několik známějších, další jsme pouze zmínili s odkazem na další informace. Spolu s vývojem těchto zařízení se začínají vytvářet pojmy, souhrnně popisující účel použití zařízení či jejich funkčnost a částečně tak usnadňují jejich kategorizaci. V kapitole se proto věnujeme rozboru několika z nich. Kromě popisných pojmů se v současné době formuje také několik konceptů, zabývajících se otázkou propojení a spolupráce těchto zařízení. V rešeršní části jsme se zaměřili na koncept Internet of Things a bezpečnostní specifika s ním související. V závěru kapitoly jsme uvedli příklad několika rozdílných architektur stávajících řešení. Lze pozorovat, že optimální architektura aplikace pro použití s těmito zařízeními není zcela jasně určena. Autoři komerčních zařízení se po dílčích úspěších či neúspěších poučili a za silné podpory uživatelské komunity software pro tato zařízení stále zlepšují. Na příkladu zařízení Tuxdroid je vidět, že přenechání přílišné volnosti v možnostech jak konfigurovat, ovládat a modifikovat chování zařízení vede ke značným komplikacím v návrhu architektury a jeho následném provozu. U zařízení Nabaztag centralizovaná správa a provoz zapříčinily nespokojenost a odliv uživatelů. To znamenalo faktický konec existence společnosti a tím i samotného zařízení. V naší práci jsme ukázali jednu z možností jak ztvárnit multimodální rozhraní v podobě hračky Furby. Při tvorbě architektury jsme vycházeli z návrhu vytvořeného v bakalářské práci (citace). Dílčí funkce jsme implementovali do zvlášť načítatelných dynamických knihoven, což umožňuje uživateli konfigurovat vlastní prostředí, které bude používat. Použitím takto navržené architektury je možné vytvářet nové scénáře k použití s hračkou Furby značně rychleji. Veškerá logika sloužící ke kooperaci Furbyho pohybů je implementována v ovládací aplikaci. Vývoj modulu či scénáře je tak možné provádět bez znalosti a použití konkrétních funkcí původní, k tomuto účelu sloužící DLL knihovny. Kromě několika nových scénářů jsme implementovali některé funkce zařízení Kinect tak, abychom umožnili vzdálené ovládání hračky Furby. 69

Závěr Integraci se zařízením Kinect jsme využili k obsluze aplikace Talking Head v rámci jednoduchého scénáře. Uživateli je umožněna konfigurace a ovládání aplikace pomocí webového rozhraní, bez nutnosti znát význam konfiguračních parametrů XML souboru. Provedli jsme formální test, který byl nezbytný k objektivnímu posouzení vnímání zařízení skupinou uživatelů. Test jsme vyhodnotili a komentáře uživatelů buďto přímo zapracovali nebo v práci zmínili jako možná vylepšení či opravy. Další pokračování práce může být vedeno v několika rovinách. Jednou z možností je rozšířit spektrum funkcí, které poskytuje vytvořený toolkit, k čemuž je možné využít neustále se rozrůstající počet webových služeb agregující nejrůznější informace, které mohou být pro uživatele zajímavé. Další cestou je nahrazení hračky Furby jiným zařízením, které by zastalo jeho funkci a případně navrhnout jiný systém ovládání. Ukázalo se také, že vzdálené ovládání pomocí zařízení Kinect je užitečné, nicméně je zde stále hodně prostoru k jeho vylepšování. Jde zejména o detekci gest, která není dostatečně robustní. Situace se však může zlepšit s vydáním nové verze knihovny OpenNI, která je použita pro obsluhu zařízení Kinect. Navržené webové rozhraní může být rozšířeno o funkci automatické aktualizace a možnost ovládání hračky Furby přes toto rozhraní, či o jiné funkce. Hračku Furby by bylo možné nahradit její bezdrátovou verzí, bez jakékoliv nutnosti změny zdrojového kódu aplikace. Je však třeba uvážit kvalitu použitého mikrofonu. S tím souvisí i možná implementace způsobu aktivace hračky Furby na základě vnějšího zvukového podnětu, jako je například bouchnutí do stolu. Velmi vhodnou hardwarovou úpravou by byla výměna senzorů, umístěných na hračce Furby za dotekové, které by značně usnadnily manipulaci s hračkou.

70

Literatura (1) AKG. [cit. 2012-05-04]. Dostupné z WWW: (2) Ananova. [cit. 2012-05-04]. Dostupné z WWW: (3) Animatronic Cat Ears. [cit. 2012-05-04]. Dostupné z WWW: (4) Boost C++ Libraries. [cit. 2012-05-04]. Dostupné z WWW: (5) clock - C++ Reference. [cit. 2012-05-04]. Dostupné z WWW: (6) cURL and libcurl. [cit. 2012-05-04]. Dostupné z WWW: (7) Entertainment Earth. [cit. 2012-05-04]. Dostupné z WWW: (8) eSTREAM: the ECRYPT Stream Cipher Project. [cit. 2012-05-04]. Dostupné z WWW: (9) Hračka iHippo. [cit. 2012-05-04]. Dostupné z WWW: (10) IBM Česká republika. [cit. 2012-05-04]. Dostupné z WWW: (11) IBM FORUM 2012. [cit. 2012-05-04]. Dostupné z WWW: (12) The Institute of Electrical and Electronics Engineers. [cit. 2012-05-04]. Dostupné z WWW: 71

Literatura (13) Internet of Things 2012. [cit. 2012-05-04]. Dostupné z WWW: (14) Introduction and Overview of W3C Speech Interface Framework. [cit. 2012-05-04]. Dostupné z WWW: (15) ISO/IEC 29192-2:2012. [cit. 2012-05-04]. Dostupné z WWW: (16) JQuery. [cit. 2012-05-04]. Dostupné z WWW: (17) JSpeech Grammar Format. [cit. 2012-05-04]. Dostupné z WWW: (18) Lotus C/C++ API Toolkits for Lotus Notes. [cit. 2012-05-04]. Dostupné z WWW: (19) National Institute of Standards and Technology. [cit. 2012-05-04]. Dostupné z WWW: (20) Naughty Duck. [cit. 2012-05-04]. Dostupné z WWW: (21) OAuth Overview. [cit. 2012-05-04]. Dostupné z WWW: (22) OpenCV. [cit. 2012-05-04]. Dostupné z WWW: (23) OpenNI. [cit. 2012-05-04]. Dostupné z WWW: (24) RapidXml. [cit. 2012-05-04]. Dostupné z WWW: (25) Speech Synthesis Markup Language. [cit. 2012-05-04]. Dostupné z WWW: (26) Turist Romania. [cit. 2012-05-04]. Dostupné z WWW: (27) Tuxdroid Community. [cit. 2012-05-04]. Dostupné z WWW: (28) twitcURL. [cit. 2012-05-04]. Dostupné z WWW: 72

Literatura (29) Der Telebuddy Avatar. Zentrum für Graphische Datenverarbeitung Journal, Březen 2000: s. 3–6, [cit. 2012-05-04]. Dostupné z WWW: (30) Augmented Business. The Economist, Listopad 2010. (31) Hash rychlejší než foton? Sdělovací technika, Listopad 2011: str. 16, [cit. 2012-05-04]. Dostupné z WWW: (32) ActiveState: ActiveState ActivePerl. [cit. 2012-05-04]. Dostupné z WWW: (33) Aldebaran Robotics: Nao Humanoid. [cit. 2012-05-04]. Dostupné z WWW: (34) Bartošek, J.: Integrace audio funkcí BlueTooth modulu do PC. Bakalářská práce, ČVUT v Praze, Fakulta elektrotechnická, 2007. (35) CNN: Furby a threat to national security? January 1999, [cit. 2012-0504]. Dostupné z WWW: (36) Dasarobot: Genibo. [cit. 2012-05-04]. Dostupné z WWW: (37) Hafner, K.: What Do You Mean, ‘It’s Just Like a Real Dog’? Květen 2000, [cit. 2012-05-04]. Dostupné z WWW: (38) Industries, C.: Chumby. [cit. 2012-05-04]. Dostupné z WWW: (39) Katagi, M.; Moriai, S.: Lightweight Cryptography for the Internet of Things. Březen 2011, [cit. 2012-05-04]. Dostupné z WWW: (40) Kunc, L.; Kleindienst, J.: ECAF: Authoring Language for Embodied Conversational Agents. Proceedings of Text, Speech and Dialogue, 2007: s. 206–213, [cit. 2012-05-04]. Dostupné z WWW: (41) Kunc, T.: Ovládání hračky Furby přes BlueTooth. Bakalářská práce, ČVUT v Praze, Fakulta elektrotechnická, 2007. (42) Leblanc, D.: Karotz, le petit lapin sort le 25 avril ! Duben 2011, [cit. 2012-05-04]. Dostupné z WWW: 73

Literatura (43) Martin, E.: SimpleModal. [cit. 2012-05-04]. Dostupné z WWW: (44) Microsoft: Kinect Sensor Components. [cit. 2012-05-04]. Dostupné z WWW: (45) Mimitchi, K.: Tamagotchi History: In an Egg Shell. 2004, [cit. 2012-0504]. Dostupné z WWW: (46) Mindscape: Nabaztag Home Page. [cit. 2012-05-04]. Dostupné z WWW: (47) Mužný, M.: Hračka Furby jako vstupně/výstupní zařízení počítače. Bakalářská práce, ČVUT v Praze, Fakulta elektrotechnická, 2010. (48) Prahalad, C.: The Fortune at the Bottom of the Pyramid: Eradicating Poverty Through Profits. Pearson Prentice Hall, 2006. (49) Sean Turner, T. P.: Security Challenges For the Internet Of Things. Únor 2011, [cit. 2012-05-04]. Dostupné z WWW: (50) Sony: Aibo. [cit. 2012-05-04]. Dostupné z WWW: (51) TechTarget - SearchSecurity: VoiceID. Leden 20O4, [cit. 2012-0504]. Dostupné z WWW: (52) The Apache Software Foundation: Apache Server. [cit. 2012-05-04]. Dostupné z WWW: (53) Violet: Karotz’ software architecture. [cit. 2012-05-04]. Dostupné z WWW: (54) Voxeo: VoiceXML Development Guide. [cit. 2012-05-04]. Dostupné z WWW: (55) Wikipedia: Tamagotchi. [cit. 2012-05-04]. Dostupné z WWW: (56) WowWee: Robosapien. [cit. 2012-05-04]. Dostupné z WWW:

74

Příloha

Seznam použitých zkratek AJAX Asynchronous Javascript And XML CGI Common Gateway Interface HTML HyperText Markup Language DLL Dynamic Load Library XML Extensible Markup Language XVB XML Voice Browser API Application Programming Interface GUI Graphical User Interface HTTP HyperText Transfer Protocol URL Uniform Resource Locator USB Universal Serial Bus TTS Text To Speech TTS Text To Speech SSML Speech Synthesis Markup Language JSGF Java Speech Grammar Format UI User Interface AES-GCM Advanced encryption standard - Galois counter mode SDK Software Development Kit RFID Radio frequency identification device 75

A

A. Seznam použitých zkratek IEEE The Institute of Electrical and Electronics Engineers DoS Denial of Service RAM Random Access Memory NIST National Institute of Standards and Technology SHA Secure Hash Algorithm CORDIS Community Research and Development Information Service TCP/IP Transmission Control Protocol / Internet Protocol RGB Red Green Blue CMOS Complementary metal–oxide–semiconductor PC Personal computer CSV Comma-separated values JSON JavaScript Object Notation

76

Příloha

B

Instalační příručka B.1

Furby ovládací aplikace

Aplikaci je vzhledem k omezení použitého Bluetooth Stacku možné provozovat pouze pod operačním systémem Windows XP. Pro úspěšné spuštění a provoz je nutné postupovat dle následujících bodů: • Balíček Microsoft Visual C++ 2010 Redistributable - je nutné nainstalovat k správnému spuštění aplikace. Instalaci lze provést buďto z přiloženého CD (soubor vcredist.exe) nebo z webu (http://www.microsoft.com/download/en/details.aspx?id=5555). • Apache Server - je možné stáhnout ze stránky apache.org a poté nainstalovat s defaultním nastavením. Nainstalovaný server Apache pak spustit jako proces pod administrátorským nebo uživatelským účtem a nikoliv jako službu pod systémovým uživatelem. • ActivePerl - je možné získat na stránce activestate.org, poté nainstalovat s defaultním nastavením • Instalace ovládací aplikace - je třeba nakopírovat či naklonovat ovládací aplikaci z GIT repozitáře kamkoliv na disk • Soubory se scénáři - nakopírovat či naklonovat z GIT repozitáře do adresáře: c:\Program Files\Apache Software Foundation\Apache 2.2\cgi-bin\ Příkazy pro naklonování souborů z GIT repozitáře: git clone [email protected]:mmuzny/furby-app.git • Poinstalační nastavení 77

B. Instalační příručka – Nastavení brány CGI - pro zpracování Perl skriptů je nutné zkopírovat soubor cgi-lib.pl do adresáře c:\Program Files\Apache Software Foundation\Apache 2.2\cgi-bin\ – Instalace programu Charlie Ebrowser - program vzhledem k licenčním podmínkám není možné umístit na přiložené CD (pro další informace kontaktujte firmu IBM Česká Republika s.r.o.). Pro jeho instalaci je nutné zkopírovat složku charlie do stejného adresáře jako ovládací aplikace – Volitelné - Webové rozhraní - je nutné nakopírovat či naklonovat z GIT repozitáře zdrojové kódy webového rozhraní do adresáře c:\Program Files\Apache Software Foundation\Apache 2.2\cgi-bin\ Příkaz pro naklonování souborů z GIT repozitáře: git clone [email protected]:mmuzny/furby-web-interface.git K úspěšnému sestavení aplikace je nutné mít stažené Widcomm Bluetooth SDK ve verzi 6.1.0.1506 a cestu k němu nastavit ve vlastnostech projektu furby v programu Visual Studio. Cesta je v defaultním nastavení zadána relativně tak, že projekt furby hledá adresář SDK ve stejné adresářové úrovni jako je solution. Widcomm SDK je možné získat z adresy http://www.broadcom.com/support/bluetooth/sdk.php

B.2

Kinect

K zprovoznění pluginu obsluhující zařízení Kinect je třeba nainstalovat níže zmíněné soubory soubory v následujícím pořadí 1. openni-win32-1.5.2.23-dev.msi 2. SensorKinect-Win-OpenSource32-5.0.3.4.msi 3. sensor-win32-5.1.0.41-redist.msi 4. nite-win32-1.5.2.21-dev.msi Tyto soubory je možné získat ze stránek OpenNI (http://75.98.78.94/default.aspx) nebo z přiloženého CD. Pro úspěšné zkompilování aplikace je také nutné mít k dispozici knihovnu OpenCV ve verzi 2.3.1. Projekt ve Visual Studiu je nastaven tak, aby soubory hledal v adresáři C:\OpenCV\ 78

B.3. Talking Head

B.3

Talking Head

Server Talking Head je samostatně běžící aplikací, kterou vzhledem k licenčním podmínkám není možné umístit na přiložené CD (pro další informace kontaktujte firmu IBM Česká Republika s.r.o.) Start serveru je možné provést spuštěním dávkového souboru masha_emb.bat. V defaultním nastavení poté server naslouchá na IP adrese 127.0.0.1 na portu 40000. Pokud je v konfiguraci aplikace povolen plugin TalkingHead, připojí se po startu k serveru a nastaví počáteční polohu hlavy a okolní grafiku a v závislosti na události získané z Kinectu ovládá mluvící hlavu. Ke zkompilování pluginu je nutné mít sestavenou knihovnu Boost (boost.org) ve verzi 1.43 a cestu k ní nastavenou v konfiguraci projektu TalkingHead.

79

Příloha

C

Uživatelská příručka C.1

Konfigurace aplikace editací souboru config.xml

Jedním ze způsobů, kterým je možné aplikaci konfigurovat, je editace souboru config.xml umístěným ve složce s ovládací aplikací. Níže uvádíme popis elementů tohoto XML formátovaného dokumentu a zároveň jejich význam. • furby - top element dokumentu, v němž jsou uzavřena všechna nastavení • front_click - element - hodnota určuje jméno scénáře, který má být spuštěn po jednom stisknutí předního tlačítka • front - element - hodnota určuje jméno scénáře, který má být spuštěn po dvojitém stisknutí předního tlačítka • nib - element - hodnota určuje jméno scénáře, který má být spuštěn po stlačení tlačítka v zobáku • scenarios - element - specifikuje cestu ke složce se scénáři, v defaultním nastavení je tato cesta C:\Program Files\Apache Software Foundation\Apache2.2\cgi-bin\ • plugin - element - specifikuje nastavení jednoho konkrétního pluginu – name - parametr - určuje jméno pluginu – enabled - element - značí, zda je plugin povolen k načtení při startu aplikace, nabývá hodnot true nebo false – daemonized - element - určuje zda je plugin nastaven k pravidelnému stahování údajů ke scénáři z internetu, nabývá hodnot true nebo false 81

C. Uživatelská příručka – interactive - element - pomocný parametr, označující zda je plugin interaktivní, nabývá hodnot true nebo false Následují parametry jedinečné pro jednotlivé pluginy • LightPlugin - element port - označuje port, ke kterému je připojen kit Arduino, příklad hodnoty - COM2 • SchedulePlugin - element schedule - označuje konkrétní plánované spuštění některého ze scénářů – time - parametr - specifikuje čas spuštění scénáře ve formátu DD/MM/YYYY HH:MM – action - parametr - určuje plugin, který má být spuštěn. Parametr je možné využít i k spouštění samostatně existující Perl skriptů, generující VoiceXML soubor. Hodnota parametru je zadávána bez .pl přípony. Příklad hodnoty - StockPlugin. – repeated - parametr - umožňuje nastavit pravidelné opakování spouštění pluginu. Nabývá hodnot daily, weekly pro nastavení denního, týdenního opakování. Pro nastavení jednorázového spuštění je nutné zadat hodnotu never. Příklad naplánování denního spouštění scénáře Burza s prvním spuštěním 10.1.2012 v čase 13:40. <schedule time="01/10/2012 13:40" action="StockPlugin" repeated="daily"/> • KinectPlugin – circle - element - hodnota elementu circle určuje název pluginu, který má být spuštěn po provedeném gestu circle – push - element - hodnota elementu push určuje název pluginu, který má být spuštěn po provedeném gestu push – wave - element - hodnota elementu wave určuje název pluginu, který má být spuštěn po provedeném gestu wave Příklad nastavení, ve kterém je volán je přiřazen scénář Počasí k gestu circle, scénář Burza k gestu push a gesto wave ke scénáři generovanému skriptem WaveVxml.pl. WeatherPlugin StockPlugin <wave>WaveVxml • AlarmPlugin - alarm - element - označuje jedno konkrétní plánované spuštění alarmu 82

C.1. Konfigurace aplikace editací souboru config.xml – time - parametr - specifikuje čas spuštění alarmu ve formátu DD/MM/YYYY HH:MM – repeated - parametr - umožňuje nastavit pravidelné opakování spouštění alarmu. Nabývá hodnot daily, weekly pro nastavení denního, týdenního opakování. Pro nastavení jednorázového spuštění je nutné zadat hodnotu never.

83

Příloha

Dotazník • Přáli byste si hračku Furby vlasnit a mít umístěnou na kancelářském stole ? Hodnocení: 1 2 3 4 5 6 7 8 9 10 Komentář:

• Jak hodnotíte vizuální stránku hračky Furby ? Hodnocení: 1 2 3 4 5 6 7 8 9 10 Komentář:

• Myslíte si, že je ovládání hračky Furby přirozené ? Hodnocení: 1 2 3 4 5 6 7 8 9 10 Komentář:

• Považujete ovládání řečí za dostatečně robustní ? Hodnocení: 1 2 3 4 5 6 7 8 9 10 Komentář:

• Rozuměli jste všem pokynům a sdělením, které Vám Furby předal ? Hodnocení: 1 2 3 4 5 6 7 8 9 10 Komentář:

85

D

D. Dotazník • Myslíte si, že je vzdálené ovládání pomocí zařízení Kinect užitečné ? Hodnocení: 1 2 3 4 5 6 7 8 9 10 Komentář:

• Jaké další funkce byste od hračky Furby očekávali ? Komentář:

• Je podle Vás webové rohraní dostatečně intuitivní ? Hodnocení: 1 2 3 4 5 6 7 8 9 10 Komentář:

86

Příloha

Obsah přiloženého CD

readme.txt...................................stručný popis obsahu CD exe ....................... adresář se spustitelnou formou implementace drivers ............................... adresář s ovladači a knihovnami src impl...................................zdrojové kódy implementace thesis ...................... zdrojová forma práce ve formátu LATEX text ....................................................... text práce thesis.pdf ............................. text práce ve formátu PDF thesis.ps ................................ text práce ve formátu PS 87

E