Ovládání RC modelu pomocí Wi-fi. Pavel Valenta

Transkript

1 Zadání Cílem práce je návrh a implementace bezdrátového ovládání RC modelu s využitím technologie Wi-Fi. Přímé ovládání modelu bude realizováno pomocí servo motorů, řízených prostřednictvím mini-itx počítače/smartphonu s operačním systémem. Pro vzdálené ovládání se bude používat laptop, nebo jiný klient podporující Wi-Fi. Aplikace pro vzdálené ovládání bude zobrazovat provozní data získaná z modelu, jako je stav zařízení, obraz z kamery nebo informace ze systému GPS. Bezdrátový komunikační protokol musí být spolehlivý, během přenosu dat nesmí docházet ke ztrátám informací, které by model učinily neovladatelným. Celý projekt dokumentujte na volně dostupném serveru určenému pro podporu vývoje SW. i

2 ii

3 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Bakalářská práce Ovládání RC modelu pomocí Wi-fi Pavel Valenta Vedoucí práce: Ing. Martin Komárek Studijní program: Softwarové technologie a management, Bakalářský Obor: Softwarové inženýrství 23. května 2011

4 iv

5 v Poděkování Děkuji Ing. Martinovi Komárkovi za ochotu a trpělivost při vedení této práce.

6 vi

7 vii Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). Obsah této práce je možné volně šířit při zachování podmínek plynoucích z licence BSD. Ve Velkých Přílepech dne

8 viii

9 Abstract This thesis deals with controlling RC models over Wi-Fi networks. It describes implementation of wireless control of an RC model and devices build within it. Communication between model and controller takes place on an computer network and is based on ISO/OSI model with the use of standard transport layer protocols. Abstrakt Bakalářská práce se zabývá ovládáním RC modelů s použitím síťové technologie Wi-Fi. Práce popisuje implementaci bezdrátového ovládání RC modelu a v něm zabudovaných zařízení. Komunikace mezi modelem a ovladačem probíhá na počítačové síti a je založená na využití ISO/OSI modelu a standardních síťových komunikačních protokolů. ix

10 x

11 Obsah 1 Úvod 1 2 Specifikace problému Historie rádiového ovládání Mechanické ovládání modelů Klasické rádiové ovládání modelů Teorie použití Wi-Fi Popis technologie Wi-Fi Přínosy Wi-Fi sítě pro ovládání modelů Model ISO/OSI Komunikační protokoly transportní vrstvy OSI Analýza Analýza požadavků Funkční požadavky Obecné požadavky Hardwarová část práce Softwarová část práce Podobné realizované projekty Analýza realizovaných řešení Analýza projektu WiFi Robot Návrh HW řešení SW řešení Architektura SW a komunikace Server Klient Funkce zajištění modelu a černé skříňky Uživatelské akce Diagram nasazení Diagramy tříd xi

12 xii OBSAH 5 Realizace Poznámky k realizaci Vývojové prostředí Nástroje Symbian C Qt framework Symbian emulátor Integrace Symbian C++ v Qt aplikacích Komunikace se zařízením Pololu Maestro Komunikační protokoly Realizace v Symbian C++ a standardním C Síťová komunikace Protokol TCP Protokol UDP Realizace v Qt Serverová aplikace Implementace Jádro Rozhraní Nasazení serverové aplikace na počítač formátu mini-itx Klientská aplikace pro systém Android Popis klientské aplikace Specifické vlastnosti systému Android Využití pohybového senzoru Grafické rozhraní Komunikace se serverovou aplikací Nasazení na reálném zařízení Testování Testování kódu Jednotkové testy Testy komponent Testování komunikace Komunikace s HW Síťová komunikace Testování reálné funkčnosti Závěr 29 8 Seznam použitých zkratek 33 9 Instalační a uživatelská příručka Serverová aplikace Předpoklady k provozu serverové aplikace Spuštění serverové aplikace a práce se zdrojovými kódy Klientská aplikace

13 OBSAH xiii Použití na reálném zařízení bez instalace Android SDK Práce se zdrojovými kódy a instalace pomocí Android SDK Obsah přiloženého CD 37

14 xiv OBSAH

15 Seznam obrázků 2.1 Grafické znázornění vrstev modelu OSI [6] Fotografie modelu z projektu WiFi Robot Diagram nasazení Diagram tříd serverové aplikace Diagram tříd klientské aplikace pro systém Android Rotační osy relativní k Zemi [24] Ovládání klientské aplikace pomocí tlačítek Ovládání klientské aplikace pomocí pohybového senzoru. Zařízení bylo v momentě zachycení tohoto obrázku nakloněno doprava a nahoru xv

16 xvi SEZNAM OBRÁZKŮ

17 Kapitola 1 Úvod Smyslem této práce je zvýšení komfortu ovládání RC modelů přesunem ovládání z hardwarových zařízení na úroveň počítačových aplikací. Motivací je vytvoření způsobu ovládání, které umožní řízení modelu z běžně dostupných zařízení s podporou Wi-Fi (například laptop nebo smartphone), bez nutnosti použití speciálního ovladače se specifickou dvojicí vysílače a přijímače. To umožní mimo jiné získat plnou kontrolu nad samotným modelem, komunikací mezi ovladačem a modelem a dále možnost použití, správy a ovládání dalších zařízení integrovaných do modelu. Do modelu bude nutné umístit počítač ve formě smartphonu nebo formátu mini-itx. Cílem práce je analyzovat možnosti využití Wi-Fi pro ovládání modelu s použitím modulů s dalšími funkcemi (například s kamerou a GPS přijímačem), navrhnout vhodné řešení tohoto problému a toto řešení implementovat. Součástí řešení je funkční aplikace pro vzdálené ovládání modelu ve verzi pro osobní počítač nebo mobilní telefon. 1

18 2 KAPITOLA 1. ÚVOD

19 Kapitola 2 Specifikace problému 2.1 Historie rádiového ovládání Bezdrátové ovládání pomocí rádiových vln je známé od roku 1897, kdy Nikola Tesla vytvořil model lodi, který ze břehu bezdrátově ovládal pomocí rádiových vln. Velkému rozvoji rádiového ovládání přispěly válečné konfliky. Technologie rádiového ovládání se využívala především ve vojenství pro řízení letové dráhy bomb, ale i pro vzdálené ovládání velkých bezposádkových strojů jako jsou tanky a lodě [1]. Rozšíření tranzistorů v šedesátých letech minulého století snížilo cenu a umožnilo širší použití technologie rádiového ovládání a zpřístupnění většinové populaci. 2.2 Mechanické ovládání modelů Přímé ovládání modelu je implementováno s použitím modelářských servo motorů - elektromotorů s možností kontroly pozice, které svým pohybem řídí pohyb přímých ovládacích prvků modelu, např. natočení kol u modelů aut nebo klapky u modelů letadel. Řízení servomotorů je typicky realizováno pomocí pulzně šířkové modulace (PWM). Servomotor přijímá pulzy s určitou šířkou a překládá je na pozici. Typicky má servomotor rozsah pohybu 90, potom šířka pulzu 1,5 ms je vždy přeložena na neutrální pozici - pozici 45. Zmenšování šířky pulzu až k 1,25 ms určuje pozici mezi 0 a 45 a naopak zvětšování šířky pulzu bude přeloženo na pozici od 45 do 90 [2]. 2.3 Klasické rádiové ovládání modelů Servomotory jsou řízeny pomocí řídícího signálu, který je možné servomotoru poslat pomocí bezdrátové dvojice vysílače a přijímače. Vysílač (vzdálený ovladač) signály pro jednotlivé servomotory zmoduluje do jediného rádiového signálu. V modelu je rádiová vlna přijata a demodulována na signály pro jednotlivé servomotory. Starý a stále běžně používaný způsob komunikace pro přenos informace z ovladače do modelu je jednoduchý přenos po rádiových vlnách s frekvencí v řádu megahertz. Typicky 3

20 4 KAPITOLA 2. SPECIFIKACE PROBLÉMU jsou to frekvence od 27 do 72 MHz [3]. Problémem je velká náchylnost k rušení více zařízení na stejné frekvenci. Moderní způsob komunikace je využití rádiových vln o frekvenci 2,4 GHz. Zvýšení frekvence přináší menší nároky na elektrickou energii a větší odolnost proti rušení od dalších vysílačů a elektromagnetického šumu z elektromotorů. Negativní vlastností vyšší frekvence je menší prostupnost pevnými objekty. Použití systému na frekvenci 2,4 GHz nabízí řešení pro problémy s rušením více modelů. Systém pracuje s kmitočtovým spektrem 2,4000 až 2,4835 GHz, rozděleným na 80 kanálů. Podle rozdílné implementace různých výrobců si systém buďto vyhradí dva kanály, hlavní a záložní, pro nerušenou komunikaci (výrobky firmy JR/Spektrum), nebo kanály trvale neblokuje a neustále mění použitý kmitočet (výrobky firmy Futaba). Teoreticky je tedy možné na frekvenci 2,4 GHz spolehlivě, a bez vzájemného rušení provozovat až 40 modelů [4]. 2.4 Teorie použití Wi-Fi Popis technologie Wi-Fi Pojem Wi-Fi se používá pro obecné označení bezdátové komunikace v lokálních počítačových sítích (standardy IEEE ). Jedná se o bezdrátový přenos na volně použitelných frekvencích 2,4 GHz a 5 GHz. Wi-Fi obstarává funkce fyzické a spojové vrstvy modelu OSI [5] Přínosy Wi-Fi sítě pro ovládání modelů Hlavním rozdílem proti klasickému rádiovému ovládání modelů je změna pohledu na zařízení z "černé skříňky", která na vstup ovladače reaguje pohybem modelu, na komunikaci pomocí počítačové sítě. Jako přijímač a vysílač slouží počítače propojené bezdrátovou sítí. Počítače nám narozdíl od jednoduchých čipů umožňují pokročilé programování a běh přijímače a vysílače jako aplikací, které mají možnost spolupracovat s dalšími hardwarovými moduly nezávisle na ovládání a bez fixace na specifický hardware. Rušení při provozu více zařízení na stejné frekvenci může být filtrováno definováním modelu, který vysílaným datům rozumí a byl spojen s vysílačem. Použití počítače v modelu je umožněno vývojem směřujícím k miniaturizaci, přijímačem může být minipočítač s nízkou spotřebou elektrické energie. V oblasti přenosu signálu Wi-Fi přináší spoustu možností pro řízení komunikace, především bezpečnosti přenosu, pomocí definovaných komunikačních protokolů a referenčního modelu ISO/OSI Model ISO/OSI Model OSI rozděluje komplexní komunikační systém do sedmi vrstev. Každá vrstva má svůj specifický úkol a nestará se o činnost ostatních vstev [6]. Klasická rádiová komunikace z pohledu OSI modelu využívá pouze fyzickou (rádiové vlny) a datovou vrstvu (zakódované ovládací signály) a komunikace probíhá pouze jedním směrem. Jednotlivé vrstvy OSI modelu jsou znázorněny na obrázku 2.1.

21 2.4. TEORIE POUŽITÍ WI-FI 5 Při použití komunikace podle tohoto modelu se řídící aplikace nemusí starat o fyzické parametry komunikace. Vysílající aplikace svá data předá do nižší vrstvy, kde dojde k postupnému zapouzdření až do vrstvy první a odeslání po médiu. Přijímající aplikace podobně dostane pouze data odeslaná vysílací aplikací, oproštěná od ostatních dat potřebných k uskutečnění fyzické komunikace. Obrázek 2.1: Grafické znázornění vrstev modelu OSI [6] Komunikační protokoly transportní vrstvy OSI Transportní (čtvrtá) vrstva OSI modelu zajišťuje vlastní přenos dat pro vyšší vrstvy. Výběr vhodného komunikačního protokolu umožnuje ovlivnit přístup ke kvalitě zprostředkovaného datového přenosu, jelikož nižší vrstvy nemají žádnou kontrolu doručení. Typickými zástupci jsou protokoly TCP a UDP. TCP protokol představuje protokol s aktivním spojením, který je díky potvrzování přijatých paketů odolný proti ztrátám při fyzickém přenosu. Vyšším vrstvám tedy neuniknou žádná data. Je vhodný pro přenosy kde je jistota doručení kritická. UDP protokol je naopak bezespojový protokol, který se nestará o stav a pořadí doručení. Hlavní využití UDP protokolu je pro přenosy typu vzdáleného sledování videa v reálném čase, kde ztracené pakety nemají výrazný vliv na kvalitu.

22 6 KAPITOLA 2. SPECIFIKACE PROBLÉMU

23 Kapitola 3 Analýza 3.1 Analýza požadavků Funkční požadavky 1. Systém bude umožnovat vzdálené ovládání servomotorů pomocí klientské aplikace. 2. Systém bude zobrazovat obraz z kamery umístěné v modelu a informace z GPS přijímače. 3. Systém zařídí zajištění modelu v případě ztráty spojení. Zajištěním modelu je myšleno například zastavení v případě modelu automobilu nebo bezpečné přistání v případě modelu letadla. 4. Systém bude na straně serveru vytvářet logovací soubory s provozními informacemi modelu. Logovací soubor bude obsahovat čas kdy byl model používán, přijaté příkazy od ovladače a infromace z GPS Obecné požadavky 1. Systém bude funkční na operačních systémech s podporou jazyka C++. Aplikace budou využívat standardní knihovny jazyka. 2. Systém zajistí spolehlivý přenos dat mezi modelem a ovladačem. Data určená pro ovládání modelu se nesmí ztrácet. 3. Model bude s ovladačem spojen pomocí sítě Wi-Fi. 4. Ovladačem se bude moci stát počítač s podporou Wi-Fi, ve formě laptopu nebo smartphonu, s nainstalovanou klientskou aplikací. 7

24 8 KAPITOLA 3. ANALÝZA 3.2 Hardwarová část práce Pro ovládání modelu je z třeba vyřešit následující hardwarové problémy: Mechanické ovládání modelu - mechanické ovládání modelu je nejlépe zajištěno pomocí servomotorů podle vzoru klasického ovládání modelů, jak je popsáno v sekci 2.2 v druhé kapitole. Řízení servomotorů je nejlépe realizováno pomocí jednoúčelového mikroprocesoru s deskou plošného spoje s konektory pro připojení servomotorů a s portem pro vstup instrukcí z nadřazené řídící jednotky. Mikroprocesor má nastavené požadované reakce na příslušné vstupy. Hardwarová zařízení kompletně připravená pro tento účel se dají pořídit od výrobců robotických součástek. Jedním z výrobců robotických součástek je firma Pololu, která je výrobcem hardwarové jednotky použité při tvorbě této práce [8]. Nabízené modely se liší různými typy vstupních portů, jsou však typicky dodávány s kvalitní dokumentací a programovatelné v některém z vyšších jazyků. Jádro modelu a integrace zařízení - za jádro modelu je pokládáno zařízení, které řídí všechna ostatní zařízení v modelu a umožňuje komunikaci s ovladačem. Jádrem ovládání modelu musí být mikropočítač s podporou Wi-Fi, buď ve formě miniaturního počítače typu mini-itx nebo smartphonu. Použití smartphonu v parametrech převažuje nad použitím klasického minipočítače, není totiž potřeba řešit otázky rozměrů, napájení a integrace externích modulů. Nevýhodou je potom interakce s hardwarovým ovladačem servomotorů, jelikož smartphonu chybí standardní USB rozhraní. Tento problém je možné vyřešit použitím bezdrátového spojení pomocí Bluetooth, nebo použitím funkce USB Host, která umožní ke snartphonu připojovat standardní USB zařízení jako k normálnímu počítači. Použití technologie Bluetooth by znamenalo další bezdrátové spojení a instalaci dodatečného modulu zajišujícího přemostění.technologie USB-OTG [9] pro mobilní zařízení v současné době není široce podporována a je dostupná pouze v některých nových zařízeních. Můžou se tedy vyskytnout problémy s implementací tohoto typu spojení s jednotkou servomotorů. K mobilnímu telefonu také není možné připojit externí Wi-Fi anténu což může znamenat problémy s dosahem. Ovladač - ovladačem modelu se z hardwarového hlediska může stát každý přístroj schopný připojit se na Wi-Fi síť, který splňuje nároky klientské aplikace. Tyto podmínky splňuje většina moderních laptopů a mobilních telefonů. Napájení - napájení je možné zajistit pomocí vhodného zapojení standardních tužkových baterií typu AA nebo použitím speciálních modelářských baterií s vhodnými parametry. V modelu je třeba napájet především servomotory. Při použití mini-itx počítače jako jádra systému je třeba zajistit vyšší napájecí napětí, typicky 12 voltů. Smartphone má vlastní integrovanou baterii. Rozlišení, které síťové zařízení bude přístupovým bodem a které bude fyzickým klientem nemá vliv na funkci aplikace a vhodnost řešení závisí na konkrétním použití. Umístění fyzického přístupového bodu do modelu má hlavní přednost v nezávislosti na dalším zařízení a umožňuje snadné předání modelu jinému ovladači mimo dosah původního.

25 3.3. SOFTWAROVÁ ČÁST PRÁCE Softwarová část práce Problém vzdáleného ovládání modelu je relativně jednoduchý a nevyžaduje spolupráci s databázovým či jiným software, ani rozlišování uživatelských rolí. Při volbě architektury se tedy zdá nejvhodnější jednoduchý model Klient-Server. Model by v tomto případě představoval serverovou aplikaci, kterou je možné přímo ovládat klientskou aplikací bežící v ovladači. Umístění serverové aplikace do modelu se jeví jako vhodnější řešení z důvodu pohledu na model jako na hlavní součást systému ovládání. Mimo to nabízí další možnosti využití modelu - podpora více připojených ovladačů v jeden okamžik nebo předávání kontroly nad modelem mezi více ovladači. Umístění serverové aplikace do modelu umožní vzdálené ovládání modelu přes síť internet bez potřeby dalšího hardware. 3.4 Podobné realizované projekty Analýza realizovaných řešení Ovládání modelu s využitím Wi-Fi je typicky řešeno využitím převodníku mezi sériovým portem a Wi-Fi sítí. K modelu je potom možné přes počítačovou síť pomocí virtuálního sériového portu přistupovat tak, jako kdyby byl fyzicky připojený. Tento způsob řešení má výhodu v nenáročnosti na zdroje, ale jeho jednoduchost neumožňuje komplexní řízení přenosu a procesů v samotném modelu. Tento způsob narozdíl od řešení realizované v této práci nepotřebuje integraci počítače do modelu, protože ovladač by komunikoval přímo s mikroprocesorem řídícím servomotory. Ovládání bez integrace počítače do modelu je hardwarově jednoduché, ale daní za jednoduchost takového ovládání je nemožnost snadné integrace dalších zařízení (kamery, GPS, apod.) do modelu a ztráta všech funkcí které počítač nabízí. Druhé řešení, které je bližší této práci, představuje využití Wi-Fi routeru umístěného v modelu. Tento způsob řešení nejlépe popisuje projekt WiFi Robot Analýza projektu WiFi Robot Tento projekt představuje úspěšné bezdrátové ovládání modelu auta s použitím Wi-Fi. Koncept projektu je stejný s touto prací, odlišuje se především ve výběru zařízení pro příjmé ovládání modelu. Informace o tomto projektu jsou dostupné na internetových stránkách autora [7] Základem projektu je použití síťového routeru s alternativním firmware založeným na systému linux na místě hlavního ovladače modelu a použití vlastního mikroprocesoru pro řízení servomotorů s využitím řídících čipů z původního modelu. Komunikace mezi routerem a ovladačem servomotorů je řešena pomocí sériového rozhraní. Pro zobrazení videa z modelu je použita IP kamera připojená k routeru, která není integrovaná do ovládací aplikace a přístup k ní je realizován přes internetový prohlížeč pomocí protokolu HTTP. Využití poměrně velkého routeru vedlo autora projektu k radikální přestavbě modelu, spíše než jako model tedy výsledek projektu vypadá jako router na kolečkách. Toto řešení je nevhodné pro menší modely, kde je potřeba hardwarová zařizení šetrně integrovat. Ovládací software představuje jednoduché převedení příkazů na instrukce pro mikroprocesor na straně serveru a ovládání pomocí čtyř tlačítek na straně klienta.

26 10 KAPITOLA 3. ANALÝZA Projekt je distribuován pod licencí GNU GPL v2 a představuje vhodnou inspiraci a ukázku základní funkčnosti pro tuto práci. Obrázek 3.1: Fotografie modelu z projektu WiFi Robot

27 Kapitola 4 Návrh 4.1 HW řešení Model bude ovládán pomocí standardních modelářských servomotorů, které budou řízeny ovladačem Micro Maestro 6-Channel USB Servo Controller [8] firmy Pololu. Jádrem modelu bude mini-itx počítač ALIX [11]. Ovladačem bude mobilní telefon s operačním systémem Android. Přenos signálů z mobilního telefonu do ovladače servomotorů bude zajištěno pomocí USB kabelu. Komunikace mezi mobilním telefonem a ovladačem bude probíhat bezdrátově pomocí sítě Wi-Fi, kde mobilní telefon bude představovat Acess Point, ke kterému se bude ovladač připojovat. Napájení servomotorů elektrickou energií zajistí čtyři tužkové baterie typu AA zapojené v sérii. Pro napájení mini-itx počítače v modelu je třeba zdroj s napětím v rozsahu 7-20 voltů. Napájení mobilního telefonu v roli ovladače zajistí jeho integrovaná baterie. Pro úpravu mechanického ovládání modelu je z hardwarového hlediska nutné připojit nebo odpojit servomotory od jejich ovladače. Zvolený model hardwarové jednotky pro ovládání servomotorů podporuje připojení až šesti servomotorů. 4.2 SW řešení Architektura SW a komunikace Pro ovládací software je zvolena architektura podle modelu Klient-Server. Serverová část aplikace poběží na modelu, kde bude na síti Wi-Fi komunikovat na dvou síťových portech a čekat na příchozí spojení z ovladače. Jeden port bude vyhrazen výhradně pro přenos instrukcí k ovládání modelu a druhý port bude určen na přenos ostatních dat, která nejsou kritická pro základní funkci modelu. Přenos instrukcí z klienta na server bude probíhat s využitím protokolu TCP pro zajištění správného doručení instrukcí. Přenost ostatních dat zajistí nereabilní protokol UDP. 11

28 12 KAPITOLA 4. NÁVRH Server Serverový software je navrhnutý pro realizaci ve formě aplikace pro mobilní telefon s operačním systémem Symbian. Serverová část softwaru bude rozdělena na jednotlivé komponenty s konkrétním účelem. Komunikace mezi jednotlivými komponentami a jádrem bude definována použitím specifických rozhraní. Použití rozhraní přináší možnost abstraktně definovat komunikaci uvnitř aplikace a umožňuje snadnou úpravu ovladačů v případě fyzické změny zařízení. Serverová část softwaru bude rozdělena na následující komponenty a rozhraní: Ovladač servomotor - ovladač zařízení Pololu Micro Maestro 6-Channel USB Servo Controller, na které jsou připojeny servomotory TCP server - komponenta představující server pro síťový přenos mezi serverem a klientem pomocí TCP protokolu. UDP server - komponenta představující server pro síťový přenos mezi serverem a klientem pomocí UDP protokolu. Ovladač GPS - zajištění komunikace se specifickýn GPS modulem. Ovladač kamery - zajištění komunikace se specifickým kamerovým modulem. Jádro modelu - zajištění hlavního řízení modelu a správné funkce komponent. Rozhraní pro komunikaci s GPS modulem - definice metod pro komunikaci s GPS modulem. Rozhraní pro komunikaci s kamerou - definice metod pro komunikaci s kamerou. Rozhraní pro ovládání servomotorů - definice metod pro komunikaci s hardwarovou jednotkou pro řízení servomotorů. Rozhraní síťovou komunikaci - definice metod pro síťovou komunikaci mezi serverem a klientem Klient Klientský software bude realizován jako aplikace pro osobní počítač. Klientská část softwaru bude, podobně jako část serverová, rozdělena na následující komponenty a rozhraní: TCP klient - komponenta představující klienta pro síťový přenos pomocí TCP protokolu. UDP klient - komponenta představující klienta pro síťový přenos pomocí UDP protokolu. Grafické rozhraní Jádro ovladače - interpretace uživatelských akcí a zajištění komunikace mezi komponentami. Rozhraní pro síťovou komunikaci - definice metod pro síťovou komunikaci mezi klientem a serverem.

29 4.3. DIAGRAM NASAZENÍ Funkce zajištění modelu a černé skříňky Speciální funkcí serverové aplikace bude akce v případě ztráty spojení nebo blížícím se vybití baterií. V případě použití tohoto ovládání na model letadla bude připraven protokol pro minimalizování škod při pádu, který by nastal v případě výpadku spojení. Systém bude zaznamenávat stav a veškeré provedené akce v přehledném textovém formátu do obyčejného souboru. Z tohoto souboru bude možné v případě problému zjistit z jaké příčiny daný problém nastal Uživatelské akce Uživatel bude moci na ovladači provádět následující akce: Výběr modelu - rozlišení pomocí IP adres v případě více modelů na jedné síti. Nastavení ovládání dle typu modelu - přiřazení ovládacích prvků k jednotlivým servomotorům. Zobrazení dat z videokamery Zobrazení lokace dle systému GPS Kontrola stavu spojení a modelu Zobrazení záznamu provedených akcí modelu 4.3 Diagram nasazení Diagram nasazení zobrazuje jednotlivé součásti kompletního systému, včetně znázornění komunikačních cest mezi jednotlivými zařízeními, aplikacemi a jejich komponentami. Diagram nasazení je na obrázku Diagramy tříd Třídní diagramy definují vnitřní strukturu serverové a klientské aplikace. Serverová aplikace rc-wifi-server, jejíž třídní diagram je na obrázku 4.2, je navržena s použitím jazyka C++ a jeho nadstavby frameworku Qt. Klientská aplikace rc-wifi-client (obrázek 4.3) je navržena v jazyce Java pro systém Android. Tyto použité technologie jsou popsány v příslušných sekcích následující kapitoly.

30 14 KAPITOLA 4. NÁVRH Obrázek 4.1: Diagram nasazení

31 4.4. DIAGRAMY TŘÍD 15 Obrázek 4.2: Diagram tříd serverové aplikace

32 16 KAPITOLA 4. NÁVRH Obrázek 4.3: Diagram tříd klientské aplikace pro systém Android

33 Kapitola 5 Realizace 5.1 Poznámky k realizaci Projekt byl původně navržen k realizaci pro použití se smartphonem Nokia N8 a vývoj probíhal v emulátoru systému Symbian. Z důvodu převážně integračních problémů spojených s emulátorem systému Symbian, které jsou popsány na následujících stránkách, a absence reálného zařízení, je finální realizace po dohodě s vedoucím práce provedena na mini-itx systému s operačním systémem Linux. Při realizaci bylo myšleno na multiplatformnost a modularitu vytvářeného zdrojového kódu 5.2 Vývojové prostředí Nástroje Nokia nabízí dvě možnosti vývoje pro systém Symbian, starší framework Symbian C++ a od roku 2010 také podporuje jednodušší a multiplatformní Qt framework. Symbian C++ představuje zavedený způsob vývoje a v současné době je to jediná možnost jak využívat některé funkce systému. Oba způsoby vývoje lze s určitými omezeními kombinovat a vytvořit tak aplikaci v Qt, která využívá některé knihovny ze Symbian C++. Vývoj musí vzhledem k požadavům emulátoru probíhat na počítači s operačním systémem Windows. Možné vývojové prostředí tvoří Qt Creator, zaměřený jen na Qt, a Carbide C++, který umožnuje vývoj v nativním Symbian C++ i Qt. Popsané knihovny a programy potřebné k vývoji jsou k dispozici v balíčcích Qt SDK [12] a Symbian SDK [13] Symbian C++ Symbian C++ je označení pro programovací jazyk vyvinutý přímo pro operační systém Symbian, který vychází ze standardního C++. Tento jazyk vychází z konceptu použití jazyka C++ v mobilních zařízeních z devadesátých let minulého století a vyznačuje se velkou složitostí. Využívá velké množství speciálních konstrukcí (deskriptory, aktivní objekty, dvoufázové konstruktory a mnoho dalších), které nejsou v ostatních běžných jazycích používané [14]. 17

34 18 KAPITOLA 5. REALIZACE Symbian C++ se vyznačuje velkou nabídkou knihoven a optimalizovanou podporou pro zařízení se systémem Symbian. Omezením tohoto programovacího jazyka je použitelnost na pouze jedné platformě a velká náročnost na znalosti a zkušenosti programátora Qt framework Qt je nadstavba standardního C++. Tento framework, původně vytvořený pro tvorbu GUI, je multiplatformní a po převzetí vývojové společnosti firmou Nokia je plně podporován také operačním systémem Symbian. Ovládání běžných součástí mobilních zařízení (videokamera, senzory, apod.) je zajišťováno modulem Qt Mobility [15]. Qt je výrazně jednodušší než Symbian C++ a představuje vhodnější volbu pro vývoj mobilních aplikací. Je tomu tak z důvodu plánovaného ukončení vývoje systému Symbian a naopak očekávanému pokračování vývoje Qt. Využití frameworku Qt je podrobně popsáno v dokumentu od firmy Nokia [16] Symbian emulátor Část aplikace je možné vyvíjet v emulátoru systému Symbian, který je součástí frameworku Symbian SDK. Tento emulátor je podobný reálnému zařízení, ale podobně jako jazyk Symbian C++ je velmi složitý a není možné v něm pohodlně pracovat. Některé funkce, které jsou na reálném zařízení běžné (například použitelné síťové připojení) nefungují, a je potřeba je obejít pomocí časově náročné konfigurace podle nepřesné dokumentace, často s nejistým výsledkem. Zařízení Pololu Maestro pro ovládání servomotorů využívá spojení pomocí virtuálního sériového portu na rozhraní USB. Emulátor neumožňuje přejmout USB port hostitelského počítače, ale již vytvořené virtuální sériové porty hostitele využít dokáže. Od aplikace na reálné zařízení se kód programu liší pouze v několika řádcích v nastavení parametrů spojení. Videokamera není emulátorem podporována a funkčnost je třeba otestovat na reálném zařízení. Simulace spojení se systémem GPS s generováním trasy je v emulátoru možná. Připojení k počítačové síti je v emulátoru řešeno pomocí přístupového bodu Winsock, který vytváří virtuální kanál mezi dvěma porty na rozhraní localhost hostitelského počítače. Vytvoření virtální síťové karty s reálnou IP adresou v emulátoru a další možnosti připojení (pomocí simulace přenosu gprs nebo odchytávání paketu na hostitelském počítači) jsou z části popsány pouze pro předchozí verze emulátoru a pokusy o jejich implementaci vedou pouze k chybám ve funkčnosti emulátoru Integrace Symbian C++ v Qt aplikacích Kombinace Qt a Symbian C++ je možná pouze při správné implementaci a vhodném ošetření velké řady výjimek a omezení plynoucích z vlastností obou jazyků, tento problém podrobně popisuje dokument od firmy Nokia [17]. Pro využití obou jazyků je nutné využít vývojové prostředí Carbide C++, kde se projevuje skutečnost, že toto vývojové prostředí není pro Qt nativní. Z toho důvodu je práce více programátorsky náročná. Při vývoji Qt aplikace v Carbide C++ dochází například k nenalezení cest k některým souborům, k automatickému přepisování konfiguračních souborů a podobných problémů,

35 5.3. KOMUNIKACE SE ZAŘÍZENÍM POLOLU MAESTRO 19 které často končí nespecifickou chybou při kompilaci a v některých případech dokonce nefunguje kód, který v Qt Creatoru jde bez problémů. Praktická integrace Symbian C++ a Qt v emulátoru se ukázala jako velmi komplikovaná záležitost, kdy jednoduchý a plně funkční Symbian C++ kód pro ovládání servomotoru použitý v Qt aplikaci způsoboval pád celého emulátoru s obecnou chybou "Kernel Panic". Tento problém nebylo možné vyřešit v rámci času, který je pro tento projekt vyhrazen, jelikož vzhledem k výše popsané složitosti jazyka Symbian C++ a provozu emulátoru vyžaduje pokročilé a praktické znalosti této problematiky. 5.3 Komunikace se zařízením Pololu Maestro Komunikační protokoly Zařízení Pololu Maestro dokáže komunikovat pomocí tří různých komunikačních protokolů a reagovat na zprávy různých protokolů bez předchozí konfigurace. Jednotlivé protokoly se liší v podporovaných příkazech a velikosti zpráv. Podporované komunikační protokoly jsou podrobně popsány v dokumentaci k produktu Pololu Maestro [18]. Mini SSC Protocol - nejjednodušší z trojice protokolů. Lze jej použít pouze pro posun servomotoru a využívá pouze tři byty - identifikace protokolu, cílový servomotor a cíl pohybu. Cíl pohybu je narozdíl od ostatních protokolů určen pouze jedním bytem, kde decimální hodnota 127 znamená neutrální pozici, hodnoty a potom pozice mezi neutrální pozicí na negativní či pozitivní mezí. Compact Protocol - podporuje všechny příkazy v jednodušší formě než pololu protokol, použití v případě jediného zařízení na sériové lince. Pololu Protocol - nejsložitější protokol nutný v případně použití více zařízení řetězově připojených na jednu linku. Umožňuje vybrat cílové zařízení podle identifikačního bytu. Příklad rozdílů mezí délkami příkazů pro různé protokolu - zápis příkazu pro posunutí servomotoru s číslem 0 do neutrální pozice v jednotlivých protokolech: Mini SSC Protocol - [0xFF, 0x00, 0x7F] Compact Protocol - [0x84, 0x00, 0x70, 0x2E] Pololu Protocol - [0xAA, 0x0C, 0x04, 0x70, 0x2E] V tomto projektu je počítáno s ovládáním jednoduchého modelu pomocí zařízení s omezenými systémovými prostředky a bez nutnosti využití více zařízení Pololu Maestro. Proto je vhodné využití těch protokolů, které přenesou požadovaný příkaz pomocí nejmenšího počtu bytů. Toho dosáhneme použitím kombinace Mini SSC protokolu pro nastavování cíle pohybu a Compact protokolu pro všechny ostatní příkazy. Formáty zpráv jsou vypsány v tabulce 5.1.

36 20 KAPITOLA 5. REALIZACE Příkaz Protokol Formát příkazu Set Target Mini SSC [0xFF, <servo>, <target>] Set Speed Compact [0x87, <servo>, <speed low bits>, <speed high bits>] Set Acceleration Compact [0x89, <servo>, <acc. low bits>, <acc. high bits>] Get Position Compact [0x90, <servo>] Get Moving State Compact [0x93] Get Errors Compact [0xA1] Go Home Compact [0xA2] Tabulka 5.1: Dostupné příkazy pro zařízení Pololu Maestro v nejjednodušším možném formátu Realizace v Symbian C++ a standardním C++ Knihovna Symbian C++ poskytuje knihovní třídy RCommServ a Rcomm pro obsluhu sériového portu, datové byty jsou uloženy v tzv. deskriptoru a odeslány pomocí metody write třídy Rcomm. Realizace pro spojení pomocí virtuálního portu na rozhraní USB se liší pouze v názvu CSY modulu a identifikace portu na prvních dvou řádcích. Ve standardním C++ je sériový přenos nejlépe realizován pomocí jednoduchého C kódu, pomocí kterého je sériový port otevřen jako vstupně-výstupní blokové zařízení, ke kterému je možné snadno přistupovat pomocí metod read a write [19]. _LIT(CSYMOD, "ECUART" ) ; // Symbian s e r i a l port d r i v e r name _LIT(PORTNAME, "COMM: : 3 " ) ; // f o u r t h com port name i n Symbian RCommServ s e r v e r ; RComm commport ; TRequestStatus s t a t u s ; s e r v e r. Connect ( ) ; // s t a r t s e r v e r s e r v e r. LoadCommModule(CSYMOD) ; // load d r i v e r commport. Open( s e r v e r, PORTNAME, ECommShared) ; // connect port to s e r v e r TInt s e r v o = 0 ; // s e r v o at p o s i t i o n 0 TInt t a r g e t = ; // n e u t r a l p o s i t i o n TBufC8<3> data ; // 8 b i t data d e s c r i p t o r used by Symbian C++ TPtr8 ptr = data. Des ( ) ; // p o i n t e r used as i t e r a t o r ptr. Append (0xFF) ; // i d e n t i f i c a t i o n f o r Mini SSC P r o t o c o l ptr. Append ( s e r v o ) ; // s e l e c t s e r v o ptr. Append ( t a r g e t ) ; // s e t t a r g e t commport. Write ( s t a t u s, data ) ; // w r i t e bytes to s e r i a l port Zdrojový kód 5.1.: Příklad implementace sériového přenosu v Symbian C++ s využitím Mini SSC protokolu

37 5.4. SÍŤOVÁ KOMUNIKACE Síťová komunikace Protokol TCP TCP komunikace je realizována pomocí zpráv zasílaných mezi serverem a klientem. Pro úspěšnou komunikaci pomocí protokolu TCP je nutné specifikovat formát zasílaných zpráv, kterému bude aplikace rozumět. S ohledem na omezené prostředky mobilních zařízení, a z toho plynoucí rychlost a spolehlivost komunikace, je nejvhodnější zprávy zasílat ve formátu číselného kódu. Zprávy zasílané po síti pomocí TCP protokolu tedy budou tvořeny pouze několika byty. Pro vzdálené ovládání servomotorů je třeba vycházet z výše uvedené specifikace protokolu sériové komunikace. Přesné definice TCP zpráv jsou uvedeny v tabulce 5.2. V tabulce je počet servomotorů omezen na 6 z důvodu použití jednoduchého hardwaru. Pro odlišení komunikace od serveru a klienta umožnění budoucího přehledného přidávání dalších příkazů začínají kódy zpráv od serveru pro klienta na čísle 100. Příkaz Kód Parametry Poznámky Set Target <servo> <target> 1 [0-5] [0-255] Set Speed <servo> <speed> 2 [0-5] [0-255] Set Acceleration <servo> <acceleration> 3 [0-5] [0-255] Get Position <servo> 4 [0-5] Odpovídá 101 Get Moving State <servo> 5 [0-5] Odpovídá 102 Get Errors 6 Odpovídá 103 Go Home 7 Position 101 [0-255] Odpověď na 4 Moving state 102 [0-1] Odpověď na 5 Errors 103 [0-255] Odpověď na 6 Tabulka 5.2: Možné druhy zpráv pro TCP komunikaci Protokol UDP Tento protokol je využíván k veškeré komunikaci, která nesouvisí s přímým ovládáním modelu. Konkrétní využití protokolu UDP v aplikaci představuje periodické zasílání informací o stavu a poloze servomotorů a mobilního telefonu. Po přijmutí žádosti o odesílání informací začne server zasílat UDP datagramy s příslušnými informacemi v periodách specifikovaných v žádosti a nestará se o stav doručení. Odesílání informací je potom možné podobně zastavit nebo upravit časový interval Realizace v Qt Qt v modulu QtNetwork nabízí třídy pro síťovou komunikaci pomocí protokolů TCP a UDP, které zajistí předpokládané chování protokolů. Realizace síťové komunikace tedy spočívá v nastavení přijímání zpráv a správných reakcí na příslušné zprávy pomocí signálů a slotů, zajištění komunikace s jádrem a vytvoření UDP serveru tak, aby při výpočetně náročném zasílání údajů neznemožňoval ovládání modelu.

38 22 KAPITOLA 5. REALIZACE 5.5 Serverová aplikace Implementace Serverová aplikace je rozdělena do příslušných komponent podle návrhu. Komponeny jsou implementovány ve formě tříd a využívány jádrem aplikace jako objekty. S vyjímkou sériové komunikace, je možné komponenty realizovat s využitím frameworku Qt s rozšířením Qt Mobility API. Pro sériovou komunikaci je nutné využít standardní C++, anebo v případě vývoje pro systém Symbian jazyk Symbian C Jádro Jádro slouží k vytvoření objektů komponent a zajištění vzájemné komunikace. Qt využívá neblokující systém signálů a slotů - objekty při událostech emitují signály, které je možně připojit k určitému slotu. Sloty je implementovány jako klasické metody, zachycení signálu se tak dá představit jako klasické volání metody. Volání slotů probíhá kdykoliv při zachycení signálu v hlavní programové smyčce a neblokuje běh programu [20]. Úkolem jádra je zachycovat tyto signály a zařídit komunikaci s dalšími objekty Rozhraní Rozhraní jsou implementována jako abstraktní třídy, které jsou děděny příslušnými komponentami. Kód těchto abstraktních tříd je psán pouze ve standardním C++. Rozhraní definují metody pro komunikaci mezi komponentami a jádrem aplikace a umožňují izolaci jednotlivých komponent. To je důležité u komponenty sériové komunikace, která musí být napsaná odlišně od zbytku aplikace, a její případné budoucí přepracování bude při implementaci stejného rozhraní možné bez modifikace ostatních komponent. Konkrétní implementace rozhraní je vidět v ukázce zdrojového kódu 5.2, která ukazuje, že komponenta ovládající sériovou komunikaci musí definovat metody dle protokolu specifikovaného v tabulce 5.1. Síťové rozhraní podobně definuje dvě metody pro přijímání a odesílání s využitím ukazatelů na znakové pole. c l a s s ServoCommunication { p u b l i c : ServoCommunication ( ) { } ; v i r t u a l ~ServoCommunication ( ) { } ; v i r t u a l bool s e t T a r g e t ( i n t servo, i n t t a r g e t ) = 0 ; // move s e r v o to s p e c i f i e d t a r g e t v i r t u a l bool setspeed ( i n t servo, i n t speed ) = 0 ; // s e t speed f o r s e r v o v i r t u a l bool s e t A c c e l e r a t i o n ( i n t servo, i n t a c c e l e r a t i o n ) = 0 ; // s e t a c c e l e r a t i o n v i r t u a l bool settargetallhome ( ) = 0 ; // move a l l s e r v o s to n e u t r a l p o s i t i o n v i r t u a l char g e t P o s i t i o n ( i n t s e r v o ) = 0 ; // r e t u r n s p o s i t i o n o f given s e r v o i n two bytes v i r t u a l char g e t E r r o r s ( ) = 0 ; // r e t u r n s e r r o r code from d e v i c e v i r t u a l char getmovingstate ( ) = 0 ; // r e t u r n s moving s t a t e } ; Zdrojový kód 5.2.: Abstraktní třída definující rozhraní pro sériovou komunikaci v serverové aplikaci

39 5.6. KLIENTSKÁ APLIKACE PRO SYSTÉM ANDROID Nasazení serverové aplikace na počítač formátu mini-itx Serverová aplikace byla nasazena na počítač PC Engines ALIX [11], konkrétně na model alix1d. Na toto zařízení byl nainstalován operační systém Ubuntu ve verzi LTS, který byl dále doplněn o knihovny Qt Na počítači bylo dále nastaveno připojení k Wi-Fi a zajištěno automatické připojení po spuštění. Serverová aplikace byla po instalaci přidána do zaváděcích skriptů a k jejímu spuštění dochází automaticky. Serverová aplikace nemá grafické rozhraní, proto byl na počítači z důvodu šetření výkonu zakázán X server a systém se spouští pouze v konzolovém režimu. 5.6 Klientská aplikace pro systém Android Popis klientské aplikace Klientská aplikace, která tvoří ovladač modelu je realizována jako aplikace pro smartphone s operačním systémem Android [21]. Klient se serverem komunikuje zasíláním definovaných zpráv pomocí standardizovaných protokolů TCP a UDP. Použití jiné platformy pro realizaci klientské aplikace tedy nemá vliv na funkci serveru. Platforma Android byla pro realizaci zvolena z důvodu jejího stále rostoucího podílu na trhu s mobilními telefony a možnosti vyvíjet a testovat běh aplikace na reálném zařízení. Ovládání modelu je řešeno pomocí tlačítek, která představují pohyb doleva a doprava, anebo s využitím pohybového senzoru telefonu, který je podrobněji popsán v sekci Hlavní okno klientské aplikace obsahuje tlačítka pro pohyb servomotorů, pro každý ovládaný servomotor jsou zobrazena tlačíka pro posun doleva a doprava z neutrální pozice. V menu aplikace je možné specifikovat IP adresu serveru, měnit počet ovládaných servomotorů a zapnout zobrazování provozních informací z modelu Specifické vlastnosti systému Android Android je označení pro operační systém Linux, který je modifikovaný pro použití v mobilním telefonu. Aplikace pro Android jsou spolu s jejich daty zkompilovány do jednoho instalačního.apk balíčku. Spuštěné aplikace běží ve virtuálním stroji, izolované od statních aplikací. Zdrojový kód Android aplikací je psaný v jazyku Java. Všechny nástroje potřebné pro vývoj jsou k dispozici v balíčku Android SDK [22]. Vývojové prostředí pro Android tvoří plugin Android Development Tools do programu Eclipse, který zároveň slouží k ovládání celého balíčku Android SDK. Komplexní informace o struktuře Android aplikací, které jsou potřebné k vývoji, jsou k dispozici na stránkách Android Developers [23]. Aplikace pro systém Android jsou tvořeny pomocí komponent Activities, Services, Content Providers a Broadcast Providers. Klientská aplikace představuje ovladač, který bude reagovat na uživatelské vstupy. Je tedy nutné jej realizovat jako Activity. Ostatní komponenty nejsou potřebné pro realizaci jednoduchého ovladače ve formě klientské aplikace. Activities - Activity je aplikace, která je tvořena jednou obrazovkou s jedním uživatelským rozhraním.

40 24 KAPITOLA 5. REALIZACE Services - služby bez uživatelského rozhraní, které běží v pozadí a mohou být využívány konkrétními Activity. Content Providers - správce aplikačních dat, řídí přístup k datům v souborovém systému. Broadcast Providers - komponenta, která zajišťuje komunikaci se systémem a ostatními aplikacemi. Tato komunikace je zajištěna zasíláním a přijímáním systémových zpráv Využití pohybového senzoru Systém používání pohybového senzoru v systému Android pracuje se třemi osami relativními k Zemi, které jsou znázorněny na obrázku 5.1 z dokumentace třídy SensorManager v balíčku android.hardware [24]. Hodnota Azimuth představuje rotaci kolem osy z, pitch rotaci kolem osy x a roll potom rotaci kolem osy y. Přístup k informacím z pohybového senzoru je realizován s využitím tříd Sensor (reprezentace jednoho senzoru), SensorManager (přístup k senzorům) a SensorEventListener (reakce na změny hodnot senzorů) z balíčku android.hardware. Použití těchto tříd umožní klientské aplikaci sledat pohyb a natočení zařizení a reagovat na ně odesláním příslušných zpráv pro server. V ovládací aplikaci je využito akcelerometru. Využívané hodnoty tohoto senzoru jsou pitch a roll. Aplikace je realizována pro ovládání s displejem svisle k zemi, kdy jsou obě tyto hodnoty nulové. Rozhodnutí pro realizaci pro tuto pozici zařízení vychází z předpokladu, že uživatel bude při ovládání modelu držet ovladač před sebou tak, aby snadno viděl na ovládaný model. Hodnoty pitch a roll se mění v závislosti na natočení v intervalu od -10 do 10. Serová aplikace pro komunikaci s hardwarovou jednotkou pro ovládání servomotorů, která je popsaná v kapitole 5.3.1, využívá rozsah 0 až 255. Hodnoty získané ze senzoru jsou na tento rozsah přepočítány a dále používány v tomto formátu jednotném pro zbytek klientské části a serverové aplikace. Obrázek 5.1: Rotační osy relativní k Zemi [24]

41 5.6. KLIENTSKÁ APLIKACE PRO SYSTÉM ANDROID Grafické rozhraní Grafické uživatelské rozhraní je v systému Android definováno v jednom nebo více XML souborech. Jednotlivé elementy grafického rozhraní jsou definovány v XML značkách. K těmto elemetům je v kódu možné přistupovat pomocí definovaného identifikátoru, a měnit tak jejich parametry. Ovládací aplikace využívá jednoho definovaného grafického rozhraní, které se mění v závislosti na zvoleném typu ovládání - pomocí tlačítek nebo senzoru. Mezi způsoby ovládání je možné přepínat pomocí tlačítka v menu. K ovládání pomocí tlačítek je nutné upozornit na nemožnost současného pohybu v osách x a y na zařízení bez podpory funkce Multitouch, která umožní registrovat více dotyků obrazovky ve stejném čase. Grafické rozhraní pro ovládání tlačítky je vidět na obrázku 5.2. Šipky uprostřed plní funkci tlačítek pro pohyb v osách x a y. Tlačítka + a - ovládají rychlost pohybového motoru v modelu. Levý panel zobrazuje informace o stavu a je v něm možné definovat, ke kterým portům hardwarové jednotky pro ovládání servomotorů jsou aktivní servomotory fyzicky připojeny. Hodnoty posunu v informačním panelu jsou zobrazeny ve formátu 0 až 255, kde hodnota 127 znamená neutrální pozici. V levém horním rohu je možnost přepínání mezi režimem Free, kdy je pohyb plně ovládán uživatelem a režimem Return, ve kterém se servomotory po uvolnění tlačítka vrací do neutrální pozice. Na obrázku 5.3 je vidět ovládání pomocí pohybového senzoru. Jediná změna oproti výše popsanému ovládání tlačítky je funkce šipek ve středu obrazovky. Nefungují již jako tlačítka, ale jako indikátory naklonění zařízení. Při naklonění zařízení se rozsvítí šipky směrů na které byl telefon nakloněn a v těchto šipkách se zobrazí hodnota úhlu naklonění. Vzhledem k tomu, že zařízení není možné udržet v přesně neutrální pozici, je kolem neutrálních hodnot pro obě osy malá tolerance. Přepínač režimů má při ovládání pomocí senzoru funkci vypnout/zapnout. Obrázek 5.2: Ovládání klientské aplikace pomocí tlačítek Komunikace se serverovou aplikací Zdrojový kód aplikací pro systém Android je psán v jazyce Java. Programování síťové komunikace pro Android se tedy neliší od aplikací pro použití na počítači. Potřebné třídy Socket

42 26 KAPITOLA 5. REALIZACE Obrázek 5.3: Ovládání klientské aplikace pomocí pohybového senzoru. Zařízení bylo v momentě zachycení tohoto obrázku nakloněno doprava a nahoru. pro protokol TCP a DatagramSocket pro protokol UDP jsou dostupné v balíčku java.net. Datové toky potřebné pro protokol TCP jsou dosupné v balíčku java.io. Dokumentace k třídám a balíčkum je dostupná na internetových stránkách Android Developer [25]. TCP spojení je vytvořeno pomocí socketu. K socketu je možné přistupovat pomocí datových toků - je možné zapisovat pomocí OutputStream a číst pomocí InputStream. UDP spojení je realizováno pomocí bezespojového datagramového socketu, který je možné přímo ovládat přes metody send a receive Nasazení na reálném zařízení Ovládací aplikace byla nasazena a testována na mobilním telefonu Vodafone 845 [26] s operačním systémem Android ve verzi 2.1. Tento mobilní telefon je v době tvorby této práce nejlevnějším z dostupných mobilních telefonů se systémem Android použitelných pro tuto aplikaci. Ovládací prvky grafického uživatelského rozhraní bylo možné přesně použít i na relativně malém displeji s rozlišením 240x320 pixelů bez podpory funkce multitouch. Není tedy možné plně využít ovládání pomocí tlačítek. Ovládání na tomto zařízení pomocí pohybového senzoru a spojení se serverovou aplikací pracují bez problémů. Vyvinutý systém tedy nemá vysoké nároky na zařízení a je možné jej použít i na takto levném mobilním telefonu.

43 Kapitola 6 Testování 6.1 Testování kódu Jednotkové testy Jednotkové testování ověřuje funkci jednotlivých metod izolovaných od zbytku programu. Pomocí jednotkového testování je v programu ověřena funkce netriviálních metod mimo GUI. V serverové aplikaci je jednotkové testování realizováno pomocí frameworku QTestLib [27]. Serverová aplikace neobsahuje GUI, proto je možné tento přístup k testování využít k otestování většiny metod. V klientské aplikaci je pomocí jednotkových testů ověřena funkce všech metod mimo GUI. Pro testování je použitý framework junit [28] Testy komponent Vzhledem k relativně malé velikosti jsou komponenty realizovány ve formě tříd. Testování komponent je podobné jednotkovému testování, jednotky však místo metod tvoří třídy. Smyslem testování komponent je ověření předpokládaného přístupu k objektu vytvořeného z příslušné třídy. Testování komponent je nutné k ověření správné komunikace mezi objekty. 6.2 Testování komunikace Komunikace s HW Při testování komunikace s hardwarem je ověřena správná reakce servomotorů připojených k jednotce Pololu Maestro na příkazy zasílané ze serverové aplikace. Testování bylo realizováno vytvořením pomocného programu s třídou ServoControl ze serverové aplikace, který zasílá sekvence příkazů které jsou v této třídě implementovány. Při běhu tohoto testovacího programu byla ověrěna fyzická reakce servomotorů na tyto příkazy. 27