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í 17. května 2011

4 iv

5 v Poděkování Zde můžete napsat své poděkování, pokud chcete a máte komu děkovat.

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). Ve Velkých přílepech dne

8 viii

9 Abstract This thesis deals with controlling RC models using 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 i 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 Teorie 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 Nefunkční 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í Realizace Poznámky k realizaci Vývojové prostředí Nástroje xi

12 xii OBSAH 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í Klientská aplikace pro systém Android Popis klientské aplikace Specifické vlastnosti systému Android Využití pohybového senzoru Komunikace se serverovou aplikací Realizace Testování Testování kódu Jednotkové testy Testy komponent Testování komunikace Komunikace s HW Síťová komunikace Testování funkčnosti Testování funkčnosti serveru Testování funkčnosti klienta Testování celkové funkčnosti Závěr 27 8 Seznam použitých zkratek 31 9 Instalační a uživatelská příručka Obsah přiloženého CD 35

13 Seznam obrázků 2.1 Grafické znázornění vrstev modelu OSI Fotografie modelu z projektu WiFi Robot Diagram nasazení Rotační osy relativní k Zemi Seznam přiloženého CD příklad xiii

14 xiv SEZNAM OBRÁZKŮ

15 Kapitola 1 Úvod Smyslem této práce je zvýšení komfortu ovládání RC modelů přesunem ovládání 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 a 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. Zvýšení komfortu ovládání se promítne ve vyšších nákladech, 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í problému a implementovat jej v podobě specifického modelu. 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

16 2 KAPITOLA 1. ÚVOD

17 Kapitola 2 Teorie 2.1 Historie rádiového ovládání Bezdrátové ovládání modelů pomocí 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 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]. Implementace tranzistorů v šedesátých letech 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í bude přeloženo na pozici od 45 do 90 [2]. 2.3 Klasické rádiové ovládání modelů Servomotory jsou vzdáleně řízeny pomocí rádiových vln. 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 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. 3

18 4 KAPITOLA 2. TEORIE 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ší propustnost 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ž 0,4835 GHz, rozděleným na 80 kanálů. Podle 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. 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.

19 2.4. TEORIE POUŽITÍ WI-FI 5 Obrázek 2.1: Grafické znázornění vrstev modelu OSI Komunikační protokoly transportní vrstvy OSI Transportní (čtvrtá) vrstva 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 vzdálené sledování videa v reálném čase, kde ztracené pakety nemají výrazný vliv na kvalitu.

20 6 KAPITOLA 2. TEORIE

21 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. System 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 Nefunkční 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. Systém bude udržovat Wi-Fi spojení s ovladačem. 4. Ovladačem se bude moci stát počítač s podporou Wi-Fi a klientskou aplikací, ve formě laptopu nebo smartphonu. 7

22 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 Řízení mechanického ovládání Jádro modelu - zařízení, které řídí funkci modelu a komunikaci s ovladačem Integrace zařízení v modelu Ovladač Napájení 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. Ovladače kompletně připravené pro tento účel s různými typy vstupních portů, s kompletní dokumentací a programovatelné v některém z vyšších jazyků se dají pořídit od výrobců robotických součástek. Za jádro modelu je pokládáno zařízení, které řídí všechny 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 jasně 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 ovladačem servomotorů, použití technologie Bluetooth by znamenalo další bezdrátové spojení a instalaci dodatečného modulu zajišujícího přemostění, naopak technologie USB-OTG pro mobilní zařízení může znamenat problémy se systémovou spojení s řídící jednotkou servomotorů a především vysokou pořizovací cenu. K mobilnímu telefonu také není možné připojit externí Wi-Fi anténu což může znamenat problémy s dosahem. 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í 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í, 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.

23 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ší model Klient-Server. Model by v tomto případě představoval serverovou aplikaci, kterou je možné přímo ovládat klientskou aplikací v ovladači. Umístění serverové aplikace do modelu je preferováno 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ání kontroly nad modelem jinému ovladači. Využití serverové aplikace umožní vzdálené ovládání modelu přes internet bez další úpravy software. 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 (a neumožnuje tedy snadnou integraci videokamery a systému GPS), jelikož ovladač by komunikoval přímo s mikroprocesorem řídícím servomotory. 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 [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í 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". 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. 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.

24 10 KAPITOLA 3. ANALÝZA Obrázek 3.1: Fotografie modelu z projektu WiFi Robot

25 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 mobilní telefon Nokia N8 s operačním systémem Symbian a funkcí USB-OTG [9] a s integrovanou kamerou a přijímačem GPS. Standardním ovladačem bude Laptop s Wi-Fi adaptérem. 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. Napájení mobilního telefonu a laptopu zajistí 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 ovladače 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 a bude poslouchat na dvou 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

26 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ě změny zařízení. Přehled rozdělení serverové části softwaru na jednotlivé komponenty a rozhraní: Ovladač servomotorů - ovladač zařízení Pololu Micro Maestro 6-Channel USB Servo Controller, na které jsou připojeny servomotory TCP a UDP server - komponenty představující servery, zajišťující komunikaci s ovladačem pomocí různých protokolů Ovladač GPS - zajištění komunikace s konkretním GPS modulem. Ovladač kamery - zajištění komunikace s konkretní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 Rozhraní pro komunikaci s kamerou Rozhraní pro ovládání servomotorů Rozhraní síťovou komunikaci 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 a UDP klient - komponenty představující klienty v síťovém spojení se serverem Grafické rozhraní Jádro ovladače - interpretace uživatelských akcí a zajištění správné funkce komponent Rozhraní pro síťovou komunikaci Funkce zajištění modelu a černé skříňky Speciální činností 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 se daný problém stal.

27 4.3. DIAGRAM NASAZENÍ 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. Ovládání dle typu modelu - v nejjednodušším případě vpřed/vzad/vlevo/vpravo u automobilu 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í

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

29 Kapitola 5 Realizace 5.1 Poznámky k realizaci Projekt byl 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 v následující kapitole, a absencí reálného zařízení, je finální realizace po dohodě s vedoucím práce provedena na mini-itx systému ALIX [11] na platformě Linux, se zajištěním maximální možné multiplatformnosti 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]. 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 velkou náročnost na znalosti a zkušenosti programátora. 15

30 16 KAPITOLA 5. REALIZACE 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 vyjímek 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ů, 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í servomotor 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

31 5.3. KOMUNIKACE SE ZAŘÍZENÍM POLOLU MAESTRO 17 č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řech 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 následující: 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ů. Tuto podmínku splňuje 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 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 (speciální implementace pole v Symbian C++) 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.

32 18 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 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 [18]. _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 5.4 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 proto 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.

33 5.5. SERVEROVÁ APLIKACE 19 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žnoval ovládání modelu. 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

34 20 KAPITOLA 5. REALIZACE 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 [19]. Ú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 void 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 void 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 void 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 f o r s e r v o v i r t u a l void 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 i n two bytes v i r t u a l char getmovingstate ( ) = 0 ; // r e t u r n s moving s t a t e r e p r e s e n t e d by 0 or 1 } ; Zdrojový kód 5.2.: Abstraktní třída definující rozhraní pro sériovou komunikaci v serverové aplikaci

35 5.6. KLIENTSKÁ APLIKACE PRO SYSTÉM ANDROID 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 [20]. 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 [21]. Vývojovým prostředím pro Android program 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 [22]. 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. 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.

36 22 KAPITOLA 5. REALIZACE Využití pohybového senzoru Ovládání pohybového senzoru v systému Android využívá třech os relativních k Zemi, které jsou znázorněny na obrázku 5.1 z dokumentace třídy SensorManager v balíčku android.hardware [23]. 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. Obrázek 5.1: Rotační osy relativní k Zemi 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 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 [24]. 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 Realizace

37 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 [25]. 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 [26] 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. 23

38 24 KAPITOLA 6. TESTOVÁNÍ Síťová komunikace Testování síťové komunikace bylo provedeno při běhu programu zachycením odesílaných a přijímaných paketů programem Wireshark [27]. Analýza zachycených paketů posloužila k ověření, zda jsou odesílány správné zprávy jako reakce na uživatelské akce. Dále byla ověřena předpokládaná funkce protokolů TCP a UDP. 6.3 Testování funkčnosti Testování funkčnosti serveru bli Testování funkčnosti klienta blo Testování celkové funkčnosti blu

39 Kapitola 7 Závěr Zhodnocení splnění cílů DP/BP a vlastního přínosu práce (při formulaci je třeba vzít v potaz zadání práce). Diskuse dalšího možného pokračování práce. 25

40 26 KAPITOLA 7. ZÁVĚR

41 Literatura [1] MEISSNER, BF. Advent of Wirelessly Controlled Torpedoes. Radiodynamics. < [2] Seattle Robotics Society. Whats a servo: A quick tutorial. < [3] TYSON, Jeff. How Radio Controlled Toys Work HowStuffWorks?. < [4] SADLER, Trevor. Exine Articles. Radio Controlled Hobbies - RC 2.4 GHz Radios. < 4-GHz-Radios&id= > [5] Wikipedia - The Free Encyclopedia - IEEE < [6] Infocellar. The OSI (Open System Interconnection) Model. < [7] BENNETT, Jonathan. Jbprojects.net. Projekt WiFi Robot. < [8] Pololu Robotics & Electronics. Micro Maestro 6-Channel USB Servo Controller. < [9] usb.org. USB On-The-Go and Embedded Host. < [10] Forum Nokia. Nokia Symbianˆ3 Developer s Library v0.9.1, Nokia Corporation, < [11] PC Engines. ALIX system boards. < [12] Forum Nokia. Symbian C++, < [13] Forum Nokia. Qt Tools, < 27

42 28 LITERATURA [14] S60 Platform: Comparison of ANSI C++ and Symbian C++, version 2.0, Nokia Corporation, < 36f953bf-59eb-4f41-9e60-f51f494c5d14/S60_Platform_Comparison_of_ANSI_ Cpp_and_Symbian_Cpp_v2_0_en.pdf.html> [15] Qt Reference Documentation. Qt Mobility 1.1, < [16] Qt for the Symbian Platform. version 1.2.: Nokia Corporation, < [17] Using Qt and Symbian C++ Together, version 1.2, Nokia Corporation, < [18] rabbit.eng.miami.edu. Unix, C, and C++, Function Reference, Unix Input and Output. < [19] Qt Reference Documentation. Signals & Slots. < [20] Android Developers. What is Android?, < [21] Android Developers. Android SDK, < [22] Android Developers. Application fundamentals, < [23] Android Developers. Reference - package android.hardware, < html> [24] Android Developers. Reference - package java.net, < [25] Qt Reference Documentation. QTestLib Manual. < [26] JUnit.org. Resources for Test Driven Developement. < [27] Wireshark Network protocol analyzer for Unix and Window. <

43 Kapitola 8 Seznam použitých zkratek API Application Programming Interface GPS Global Positioning System IEEE Institute of Electrical and Electronics Engineers IP Internet Protocol ISO International Organization for Standardization GUI Graphical User Interface HTTP Hypertext Transfer Protocol OSI Open Systems Interconnection model PWM Pulse-width Modulation RC Radio Control TCP Transmission Control Protocol UDP Used Datagram Protocol Wi-Fi Wireless Fidelity USB Universal Serial Bus USB-OTG Universal Serial Bus - On The Go 29

44 30 KAPITOLA 8. SEZNAM POUŽITÝCH ZKRATEK

45 Kapitola 9 Instalační a uživatelská příručka TODO. 31

46 32 KAPITOLA 9. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA

47 Kapitola 10 Obsah přiloženého CD TODO - Tato příloha je povinná pro každou práci. Každá práce musí totiž obsahovat přiložené CD. Viz dále. Může vypadat například takto. Váš seznam samozřejmě bude odpovídat typu vaší práce. (viz [? ]): Obrázek 10.1: Seznam přiloženého CD příklad Na GNU/Linuxu si strukturu přiloženého CD můžete snadno vyrobit příkazem: $ tree. >tree.txt Ve vzniklém souboru pak stačí pouze doplnit komentáře. 33

48 34 KAPITOLA 10. OBSAH PŘILOŽENÉHO CD Z README.TXT (případne index.html apod.) musí být rovněž zřejmé, jak programy instalovat, spouštět a jaké požadavky mají tyto programy na hardware. Adresář text musí obsahovat soubor s vlastním textem práce v PDF nebo PS formátu, který bude později použit pro prezentaci diplomové práce na WWW.