České vysoké učení technické v Praze Fakulta elektrotechnická
Diplomová práce
Kontextová inteligentní navigace – klientská aplikace Bc. Petr Podhorský
Vedoucí práce: Ing. Jan Koutník, Ph.D. Studijní program: Elektrotechnika a informatika (magisterský), strukturovaný Obor: Výpočetní technika Červen 2009
ii
Poděkování Rád bych poděkoval Ing. Janu Koutníkovi, Ph.D. za pomoc a vedení této práce a kolegovi Bc. Jakubovi Zahradníkovi, který navrhoval serverovou část, za vynikající spolupráci při návrhu společných částí. Kromě toho bych chtěl dále poděkovat i všem mým blízkým za jejich podporu a trpělivost. iii
iv
Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů. (autorský zákon). V Praze dne 18. 5. 2009
……………………………. v
vi
Abstrakt Cílem této práce bylo vytvoření navigačního softwaru, který bude zpracovávat data z GPS modulu a akcelerometru, a na jejich základě navigovat uživatele k vytyčenému cíli. Software byl vyvinut jako klientská aplikace, která může fungovat jak v offline režimu, tak připojená k navigačnímu serveru, který je výsledkem jiné diplomové práce, komunikuje s jednotlivými klienty a nabízí komplexnější funkce, například přistoupení chodce do auta s podobnou trasou. Výsledkem je fungující mobilní aplikace, která byla vyzkoušena na několika mobilních telefonech, obsahuje mapové podklady pro Prahu a umožňuje aktualizaci map o statistiky průjezdnosti i složitější navigační scénáře.
Abstract This work aims to develop navigation software, which will process data from a GPS module and an accelerometer, and it will navigate a user to desired destination based on this information. The software was developed as a client application that can work in offline mode, as well as connected to a navigation server, which is result of another diploma thesis. The application communicates with all clients and allows more complex functions, such as loading a pedestrian to a car with similar destination. The result is a mobile application that was tested on a several mobile phones containing maps of Prague, allowing data update with traffic statistics and together with the cooperating server it is capable of complex routing scenarios.
vii
viii
Obsah 1
Úvod....................................................................................................................... 1 1.1 Motivace pro vytvoření aplikace ..................................................................... 1 1.2 Existující řešení ............................................................................................... 1 1.3 Uživatelské požadavky a scénáře užití ............................................................ 2 1.4 Systémové požadavky ..................................................................................... 2 1.5 Specifikace cílů práce...................................................................................... 2 2 Teorie ..................................................................................................................... 3 2.1 Rozpoznávání kontextu ................................................................................... 3 2.2 Zjišťování polohy ............................................................................................ 8 2.2.1 Global Positioning System ....................................................................... 8 2.2.2 Triangulace pomocí satelitů ..................................................................... 8 2.3 Navigace .......................................................................................................... 9 2.3.1 Nejbližší bod v mapě ............................................................................... 9 2.4 Aktualizace map ............................................................................................ 10 2.5 Složitější scénáře navigace ............................................................................ 10 3 Implementace ....................................................................................................... 13 3.1 Volba vývojových prostředků ....................................................................... 13 3.2 Architektura aplikace .................................................................................... 14 3.3 Data z akcelerometru ..................................................................................... 15 3.3.1 WiiMote ................................................................................................. 15 3.4 Zjišťování polohy .......................................................................................... 17 3.4.1 Připojení k GPS modulu ........................................................................ 17 3.4.2 Location API .......................................................................................... 17 3.4.3 NMEA 0183 ........................................................................................... 18 3.5 Navigace ........................................................................................................ 19 3.5.1 Celkové zpracování dat pro navigaci ..................................................... 19 3.5.2 Načítání mapy ........................................................................................ 20 3.5.3 Nalezení trasy......................................................................................... 20 3.6 Připojení k navigačnímu serveru ................................................................... 21 3.6.1 Nahrávání projetých tras na server ........................................................ 22 3.6.2 Stažení aktualizované mapy ze serveru ................................................. 23 3.6.3 Složitější scénáře navigace .................................................................... 23 3.7 Uživatelské rozhraní ...................................................................................... 24 3.7.1 Hlavní obrazovka ................................................................................... 24 3.7.2 Reakce na klávesy .................................................................................. 25 3.7.3 Spořič obrazovky ................................................................................... 25 3.8 Zobrazení mapy ............................................................................................. 26 3.8.1 Umístění kamery .................................................................................... 26 3.8.2 Vykreslování po vrstvách ...................................................................... 27 3.8.3 Zobrazení názvů ulic .............................................................................. 27 3.8.4 Načítání objektů k zobrazení ................................................................. 29 3.9 Jazykové verze .............................................................................................. 31 3.10 Nastavení aplikace......................................................................................... 32 3.10.1 Uživatelské rozhraní .............................................................................. 32 3.10.2 Poloha .................................................................................................... 32 3.10.3 Rozpoznání kontextu ............................................................................. 33 3.10.4 Komunikace ........................................................................................... 33 3.11 Instalace aplikace .......................................................................................... 34 ix
4
5 6 7 8 9
x
3.11.1 Symbian ................................................................................................. 34 3.11.2 Windows Mobile .................................................................................... 34 Testování .............................................................................................................. 35 4.1 Rozdíl mezi emulátorem a reálným prostředím ............................................ 35 4.1.1 Připojení emulátoru k GPS modulu ....................................................... 36 4.2 Operační systémy .......................................................................................... 36 4.2.1 Symbian ................................................................................................. 36 4.2.2 Windows Mobile .................................................................................... 36 4.3 Uživatelské rozhraní ...................................................................................... 37 4.3.1 Hlavní obrazovka aplikace ..................................................................... 37 4.3.2 Spořič obrazovky ................................................................................... 37 4.4 Detekce kontextu ........................................................................................... 38 4.5 Příklady použití ............................................................................................. 40 4.5.1 Standardní navigace k cíli ...................................................................... 40 4.5.2 Složitější scénáře .................................................................................... 42 4.6 Testované zařízení ......................................................................................... 44 4.6.1 Nokia N73 .............................................................................................. 44 4.6.2 Asus P750 .............................................................................................. 44 4.6.3 HTC Touch ............................................................................................ 47 Závěr .................................................................................................................... 49 Budoucnost .......................................................................................................... 51 Seznam literatury ................................................................................................. 53 Obsah přiloženého CD ......................................................................................... 55 Přílohy .................................................................................................................. 57 9.1 Ukázka NMEA 0183 ..................................................................................... 57
1 Úvod 1.1 Motivace pro vytvoření aplikace V dnešní době existuje řada navigačních aplikací, které mají za cíl pomáhat uživateli a informovat ho o správném směru jeho cesty, nabízet blízké body zájmu či informovat včas o dopravních komplikacích tak, aby se jim mohl úspěšně vyhnout. Se vzrůstajícími možnostmi zařízení a datových zdrojů se tlačí do popředí zájmu produkty, které kromě pouhé interpretace dat dokážou i predikovat potřeby uživatele a chovají se určitým způsobem inteligentně. U navigace je vždy velký počet vstupních parametrů, které je nutné nějakým způsobem z hlediska aplikace zjistit. Nejde jen o cíl trasy, ale také možnosti přepravy (auto, hromadná doprava, pěšky, kolo), možnosti složitějších scénářů (jeden uživatel může přepravit druhého) atd. Některé z těchto údajů se nijak predikovat nedají (například cíl trasy), nicméně jiné je možné zjistit pomocí propojení jednotlivých zařízení (složitější scénáře) nebo detekovat na základě různých měření (detekovat jízdu automobilem či chůzi pěšky). Uživatel tedy v ideálním případě pouze zadá cíl své trasy a všechny další parametry navigace jsou již zjištěny automaticky.
1.2 Existující řešení Na aktuálním trhu existuje velké množství různých navigačních systémů, které se liší jak v datech, tak ve schopnostech navigace. Pro srovnání bylo při tvorbě této práce nejvíce přihlíženo k aplikaci TomTom Navigator (http://www.tomtom.com/), která spolehlivě funguje na mobilních telefonech, které byly převážně použity pro testování. Jako další existující řešení lze jmenovat například Nokia Maps (http://www.nokia.com/), Garmin Nüvi (http://www.garmin.cz/) nebo MIO Moov (http://www.mio.com/cz/). Některé modely obsahují velmi podrobné datové podklady, takže mohou uživatele instruovat i o jednotlivých jízdních pruzích na křižovatkách atd. Všechny existující navigace mají několik společných vlastností. Mezi ně patří zaměření pro konkrétní účel (navigaci, která je určena do auta, není dost dobře možné použít při turistické vycházce), nejsou schopny rozeznat aktuální kontext (jestli jde uživatel pěšky nebo jede autem) a nebyly od začátku navrženy pro dynamickou aktualizaci map – postupnou úpravu mapových podkladů na základě měřených dat. Poslední bod, tedy aktualizaci, je nutné upřesnit. Navigace podporují aktualizaci map přes Internet nebo jakýkoliv jiný způsob přenosu dat, ale nevyužívají data, která jsou tvořena pohybem samotných uživatelů navigace (a představují tedy pro autora velmi levný způsob, jak vylepšit navigační schopnosti aplikace). Výjimkou k používání statistik průjezdnosti silnic podle dne v týdnu (a denní doby) je technologie TomTom IQ Routes, ta však byla v době plánování této práce na počátku a je určena pouze pro řidiče automobilů (nepodporuje změnu kontextu).
1
1.3 Uživatelské požadavky a scénáře užití Navigační aplikace představují pro uživatele jednoduchý způsob, jak kdykoliv zjistit svoji aktuální polohu a nalézt trasu k zadanému cíli. Předpokládané využití je tedy takové, že chodec či řidič vozidla zapne navigační aplikaci, ta sama pozná aktuální kontext uživatele (chůze nebo jízda automobilem) a vzhledem k tomuto zjištění a dalším údajům (průjezdnost trasy v konkrétní denní dobu a den v týdnu) navrhne nejlepší možnou trasu k cíli. Pokud je takto navigováno více uživatelů, měla by aplikace nabídnout možnost, zdali nebude výhodnější pro chodce, že by přistoupil do vozidla jedoucího stejným směrem (pokud se oba účastníci znají a k této možnosti svolí).
1.4 Systémové požadavky Cílem této práce je navrhnout a implementovat inteligentní navigační software pro mobilní zařízení, který bude zpracovávat polohu z GPS přijímače, bude provádět rozpoznávání kontextu uživatele (např. chůze, jízda autem) analýzou údajů z akcelerometru a podle něj bude provádět navigaci. Jako mapové podklady budou použita data, která dodá server, který je tvořen v rámci další diplomové práce. (1) Původní data, která byla vytvořena v rámci již hotové diplomové práce, nejsou použitelná pro účely navigační aplikace (neobsahují všechny potřebné údaje a nemají odpovídající formát). Data získaná z používání aplikace budou zpětně analyzována na serveru a použita pro tvorbu statistik průjezdnosti jednotlivých tras tak, aby docházelo k co nejlepší navigaci uživatele. Tento bod by mohl být v rozporu se soukromím uživatelů, protože z mobilního zařízení by byla odesílána data o jejich pohybu, nicméně tato práce nemá za cíl vytvořit hotovou fungující komerční aplikaci, ale prototyp, který by ukazoval možnosti v tomto směru. Samotné zpracování údajů by pak ve skutečnosti muselo být pochopitelně technicky (šifrování a mazání zpracovaných dat) a právně ošetřeno (souhlas uživatele s poskytnutím dat pro tvorbu statistik). Poslední požadavkem je navrhnutí složitějších scénářů navigace, například když chodec přistoupí do auta jedoucího stejným směrem.
1.5 Specifikace cílů práce Následuje seznam cílů této práce, které byly vytyčeny na základě požadavků: Vytvořit mobilní aplikaci, která bude komunikovat s GPS přijímačem a akcelerometrem. Na základě akcelerometru vyhodnocovat kontext uživatele (jízda autem, chůze pěšky). Mapové poklady využít pro zobrazení mapy a nalezení nejkratší trasy k cíli. Aplikaci vytvořit tak, aby umožňovala připojení k serveru, který bude podporovat aktualizaci statistik průjezdnosti tras a složitější navigační scénáře. Otestovat výslednou aplikaci v reálném prostředí.
2
2 Teorie 2.1 Rozpoznávání kontextu Jedním z cílů této práce je rozpoznávat kontext uživatele, na jehož základě se pak bude aplikace snažit navrhovat nejlepší možnou navigaci. Vzhledem k tomu, že navigace musí z principu nějakým způsobem pracovat s aktuální polohou, bylo by možné detekovat (odhadovat) kontext podle změny polohy (např.: chodec se nebude nikdy pohybovat rychleji než 10 km/h). Tato detekce však nemusí být nejlepší možná – pokud se auto zastaví v koloně a bude pomalu popojíždět (poměrně častý případ), bude výsledek nesprávný. Lepší možností se jeví využití toho, že lidská chůze představuje periodický pohyb, na rozdíl od auta či jiného dopravního prostředku (vibrace způsobené motorem lze zanedbat). Zmíněný periodický pohyb je nejznatelnější na ose Y (pokud předpokládáme, že osa Y je ve směru gravitačního působení Země) a kolísá kolem hodnoty 1 G. Pro zjištění periodicity zašuměného signálu se jeví jako vhodná Fourierova transformace, jejímž výsledkem je spektrum amplitud na diskrétních frekvencích. U dopravních prostředků má signál (až na malý šum) pouze stejnosměrnou složku, ale chůze má jasně rozlišitelné hodnoty na nízkých frekvencích (frekvence jednotlivých kroků) – viz obrázek 2.2. Následují naměřené hodnoty pro různé kontexty a výsledky Fourierovy transformace na těchto datech. Na svislé ose je součet hodnot zrychlení pro všechny tři osy (důvody jsou rozebrány v kapitole 0), na horizontální ose je pak časová složka v případě měření dat nebo spektrum frekvencí měřených dat.
Obrázek 2.1 Chůze po rovině – naměřené hodnoty zrychlení
3
Obrázek 2.2 Chůze po rovině – výsledek FT - frekvenční spektrum zrychlení
Z výsledků Fourierovy transformace záznamu pořízeného při chůzi je jasně vidět, že se jedná z hlediska zrychlení o periodický pohyb. U jízdy autem, jejíž záznamy následují, již tato periodicita není (výsledek FT obsahuje při zanedbání velmi malých hodnot, způsobených nepřesností měření, zatáčkami a nerovností silnic, pouze střední hodnotu).
Obrázek 2.3 Jízda autem – naměřené hodnoty zrychlení
4
Obrázek 2.4 Jízda autem – výsledek FT - frekvenční spektrum zrychlení
Následuje záznam z jízdy metrem. Z dat není tímto způsobem možné odlišit, jestli jde o auto či metro. V obou případech jde převážně o přímočarý pohyb. U auta sice dochází k zatáčení, akceleraci či brzdění častěji než u metra, ale nejde o charakteristiku, která by se dala analyzovat v krátkých časových intervalech. Aby bylo možné tyto dva způsoby dopravy odlišit, bylo by nutné analyzovat minimálně několikaminutový záznam. Auto však může absolvovat trasu, která bude podle zrychlení vypadat stejně jako trasa metra a tento způsob rozlišení tedy není vhodný. Pro tuto práci jde u metra jen o zkoumání, zdali by se daný způsob zjišťování kontextu dal využít i pro jiné případy, než je auto a chůze, protože pokud je uživatel v metru, nelze určit polohu pomocí přijímače GPS a nefunguje tedy navigace (možností by byla například triangulace pomocí BTS buněk, ale tento způsob určení polohy nebyl v rámci této práce implementován).
Obrázek 2.5 Jízda metrem – naměřené hodnoty zrychlení
5
Obrázek 2.6 Jízda metrem – výsledek FT - frekvenční spektrum zrychlení
Na závěr je připojen pro zajímavost výsledek analýzy dat při situaci, kdy jde uživatel po schodech. Z hlediska tohoto přístupu se jedná o podobný výsledek jako v případě chůze po rovině. Při porovnání je vidět, že chůze po schodech obsahuje větší amplitudy (zobrazený případ je chůze ze schodů), ale tento poznatek se nedá jednoduše uplatnit (bylo by nutné na toto vytvořit odpovídající statistiku). Změna velikosti amplitudy proti chůzi po rovině záleží také na konkrétních fyzických dispozicích daného člověka, situaci (pospíchá nebo je fyzicky indisponován) atd.
Obrázek 2.7 Chůze po schodech – naměřené hodnoty zrychlení
6
Obrázek 2.8 Chůze po schodech – výsledek FT - frekvenční spektrum zrychlení
Pro rozpoznání kontextu se ukázala funkční jednoduchá podmínka, která rozpoznává chůzi tehdy, pokud je některá z amplitud ve spektru větší než 0,2 (experimentálně odvozeno; je vynechána pochopitelně stejnosměrná složka), v jiných případech jde pak o dopravní prostředek (automobil, metro, tramvaj atd.). Na základě zmíněné logiky je tedy možné rozpoznávat jízdu automobilem (nebo jiným dopravním prostředkem) a chůzi pešky. Lze tedy splnit cíl specifikovaný v kapitole 1.5.
7
2.2 Zjišťování polohy 2.2.1 Global Positioning System Pro zjišťování aktuální polohy se používá GPS (Global Positioning Systém), družicový systém určený původně pro armádní využití USA. Jde o systém složený z 32 družic, které obíhají ve výšce 20 200 km nad povrchem Země. S pomocí družic je možné kdekoliv na Zemi zjistit přesný čas a aktuální polohu s přesností na desítky metrů. Kromě základní triangulace je možné použít ještě řadu korekcí, pomocí kterých lze zvýšit přesnost určení polohy až na jednotky centimetrů. Některé z těchto korekcí nejsou ale dostupné civilnímu obyvatelstvu (používá je například armáda). Celý systém je rozdělen do tří segmentů: kosmický, řídící/kontrolní a uživatelský. Kosmický segment je reprezentován družicemi, které obíhají kolem Země po šesti kruhových drahách a ty jsou nastaveny tak, aby na každém bodě na Zemi bylo možné provést triangulaci polohy. Řídící a kontrolní segment je rozdělen na několik částí: velitelství (Navstar Headquarters na letecké základně Los Angeles v Californii v USA), řídící středisko, tři povelové stanice a osmnáct monitorovacích stanic. Řídící a kontrolní segment monitoruje kosmický segment, zasílá povely družicím, provádí jejich manévry a údržbu atomových hodin. Výsledek jejich monitoringu je zveřejňován v navigační zprávě každé družice a jejich platnost je řádově několik hodin. (2) Uživatelský segment je pak reprezentován uživatelskými přijímači, které přijímají signál z aktuálně viditelných družic (pro danou polohu) a na základě přijatých dat (a předem definovaných parametrů) spočítají polohu, nadmořskou výšku a zobrazí přesný čas a datum.
2.2.2 Triangulace pomocí satelitů Každá družice GPS systému vysílá signál, který obsahuje informace o aktuálním čase (čas, který je na atomových hodinách umístěných v družici). Pokud je dostupný signál ze čtyř družic, lze určit přesné místo v prostoru, ze kterého se provádí měření. Celý princip lze vysvětlit na průniku kulových ploch. Pokud je k dispozici údaj pouze o jedné ploše (tedy jeden údaj o vzdálenosti), existuje nekonečně mnoho bodů, pro které platí údaj o vzdálenosti od středu. V případě dvou ploch, které mají průnik, jde sice stále o nekonečně mnoho bodů, ale tyto body již leží na kružnici (jak je vidět na Obrázek 2.9 Ukázka průniku dvou obrázku). U tří ploch zbývají z této kružnice dva kulových ploch, které reprezentují naměřenou vzdálenost od družice body (které jsou ve správné vzdálenosti od všech tří středů pomyslných koulí). Čtvrtá kruhová plocha má pak průnik už jen s jedním z těchto bodů.
8
Přesnou polohu lze tedy zjistit pomocí signálu ze čtyř družic. Nicméně v mnoha případech je možné určit polohu pouze pomocí tří, protože jeden ze dvou bodů, které zůstaly jako možné výsledky, je příliš vzdálen od povrchu Země nebo se pohybuju příliš vysokou (nereálnou) rychlostí. Pomocí GPS modulu připojeného k mobilnímu zařízení lze tedy určit polohu (a rychlost pohybu) uživatele, zobrazit odpovídající část mapy pro navigaci a aktuální polohu použít jako výchozí bod pro hledání trasy.
2.3 Navigace Cílem navigace je informovat uživatele o jeho aktuální pozici a především zobrazovat trasu do předem vytyčeného cíle (spolu s dalšími údaji, jako jsou vzdálenost do cíle, odhadovaný čas na zbytek trasy, čas předpokládaného příjezdu, vzdálenost do další změny směru atd.). Vyhledávání trasy (stručný popis implementace v kapitole 3.5.3) je závislé na aktuálním kontextu a preferencích uživatele. V případě chůze již není nutné další parametry většinou specifikovat (nehrozí dopravní zácpy, poplatky na dálnici atd.), ale u jízdy autem se rozlišují typy tras – nejkratší (ohodnocení trasy je založeno pouze na ujeté vzdálenosti) či nejrychlejší (může jít o delší trasu, kde je možné jet větší rychlostí, takže celkový čas nutný pro dosažení cíle je nejmenší). Algoritmy, které jsou použiti pro vyhledávání trasy, jsou detailně rozebrány v diplomové práci, která se zabývá serverovou částí celého řešení (1), a jejich použitím lze splnit cíl práce (uvedený v kapitole 1.5), aby byl uživatel navigován nejkratší (nejrychlejší) cestou k cíli.
2.3.1 Nejbližší bod v mapě Vzhledem k použitému způsobu zjišťování polohy je nutné počítat s určitou chybou měření. Zjištěná poloha tedy nemusí přesně odpovídat skutečné pozici. Pro účely navigace ale můžeme předpokládat, že uživatel se s mobilním zařízením nachází na cestě (ulice, běžná silnice, dálnice, pěší stezka), která je zanesena v mapě a lze ji použít pro navigační účely. Je nutné tedy zjistit nejbližší cestu (silnici) k aktuální poloze a nejbližší bod na této cestě pro zobrazení, kde na trase se uživatel nachází, kolik zbývá do cíle atd. Každý úsek cesty je tvořena minimálně dvěma body a skládá se tak z jedné či více úseček. Problém se tedy redukuje na zjištění vzdálenosti bodu od úsečky a nejbližšího bodu na úsečce od zadaného bodu. Pak se tento postup opakuje pro všechny cesty (jejich úsečky) v okolí, a vybere se ta nejbližší – tím lze odhadnout (kvůli nepřesnosti určování polohy) umístění na cestě. Pro zjištění vzdálenost bodu (souřadnice {xa, ya}) od přímky (parametrické vyjádření ) lze použít jednoduchý výpočet:
9
U úsečky ale může nastat případ, kdy zadaný bod není nejblíže „tělu“ úsečky, ale jednomu z jejích konců.
Obrázek 2.10 Možné případy pro zjišťování vzdálenosti mezi bodem a úsečkou
Pro rozlišení jednotlivých případů se zkonstruují dvě přímky kolmé na úsečku, každá z nich prochází jedním z konců úsečky (body A a B). Každá z přímek rozděluje rovinu na dvě poloroviny a pomocí průniku těchto polorovin lze ověřit, zdali zadaný bod (na obrázku bod C) je nejblíže tělu úsečky nebo jednomu z koncových bodů (v případě bodů D nebo E).
2.4 Aktualizace map Navigace pomocí mobilního zařízení je lepší oproti klasické papírové mapě už jen z toho důvodu, že zobrazuje aktuální pozici uživatele a odpadá tak hledání v mapě. Data jsou však stále stejná jako v papírové podobě. Další možností, jak vylepšit schopnosti navigace je použití lepších dat, které se dynamicky mění v závislosti na situaci. Data v závislosti na čase jsou nejvýhodnější ve městech, kde je průjezdnost velmi odlišná v různých částech dne (někdy je situace taková, že chůze je rychlejší než jízda autem). Pro tvorbu časové závislých dat je nutné zaznamenávat průjezdnost tras, které uživatel projíždí či prochází. Problém je ten, že určení polohy nemusí být přesné a určení ulice nebo cesty, na které se uživatel nachází je nutné určitým způsobem odhadnout (popsáno v kapitole 2.3.1). Záznamy pro aktualizaci mapy tedy obsahují souřadnice ulic a cest, které uživatel prochází a čas na nich strávený. Tato data je pak nutné zpracovat na serveru, protože jde o poměrně náročnou operaci (a při použití serveru je možné využívat trasy všech připojených uživatelů, ne jen jednoho), a zpětně stáhnout na mobilní zařízení uživatele. Tím je splněn cíl z kapitoly 1.5 o aktualizaci map o statistiky průjezdnosti.
2.5 Složitější scénáře navigace Běžné využití navigace je takové, že chodec či řidič motorového vozidla zadá do aplikace cíl cesty a navigace bere v úvahu pouze mapové podklady. V případě vozidla je tento způsob navigace dostačující, protože auto je obecně nejrychlejším dopravním prostředkem. Pro chodce je však výhodné zjistit, zdali někdo z jeho známých nejede v danou chvíli autem a nemá podobnou trasu. Pokud ano, je možné řešit případ, kdy část jejich trasy je společná a výrazně se tak urychlí trasa chodce. 10
Celkové počítání ideální trasy s použitím známých kontaktů, které v danou chvíli také cestují, může být poměrně složitě (závisí také na tom, jestli se řeší možnosti, že chodec může využít za celou svoji trasu pouze jednoho automobilu nebo libovolného množství). Speciální případy, které mohou nastat (nastanou) a je třeba je zkontrolovat, jsou: přistoupení chodce do auta (tedy změna jeho kontextu a absolvování tohoto setkání), odchýlení se od trasy (ať už před přistoupením chodce nebo až po něm), vystoupení chodce z auta. Z pohledu klienta je nutné řešit pouze jednoduché operace: hledání trasy přes centrální server, periodické posílání aktuální pozice a kontextu, zjišťování možnosti někoho svézt (řidič může spěchat či mít automobil již plně naložený) a aktualizaci trasy (aby obsahovala nástupní a výstupní body „pasažérů“). Tím je možné splnit cíl práce z kapitoly 1.5, aby aplikace podporovala připojení k serveru a složitější navigační scénáře. Všechny potřebné operace pro funkčnost těchto scénářů byly implementovány v rámci komunikace s navigačním serverem. (1) Více o implementaci v kapitole 3.6.3.
11
12
3 Implementace 3.1 Volba vývojových prostředků Aplikace je určena pro mobilní zařízení a podle toho byly voleny vývojové prostředky. Pro tuto oblast je možné volit z velkého množství prostředků, například C++ v případě vývoje pro Symbian či .NET Compact Framework pro Windows Mobile. Aby bylo možné výslednou aplikaci používat v co nejširším spektru produktů, je nutné použít jazyk a formát aplikace, který podporují všechny. Z tohoto požadavku vyplývá implementace aplikace v Javě (konkrétně J2ME, což je specifikace určená pro mobilní zařízení), kterou zvládá většina zařízení (nezávisle na operačním systému). Nevýhodou mohou být rozdílné implementace Javy a různá podpora jednotlivých knihoven (JSR), nicméně tento problém lze pak již řešit u konkrétního zařízení (updatem firmwaru či instalací jiné implementace J2ME). Pro Javu existuje několik vývojových prostředí, která jsou zdarma dostupné. Nejznámější z nich jsou Eclipse a NetBeans, které poskytují srovnatelné prostředky k vývoji. Pro implementaci této práci bylo zvoleno prostředí NetBeans, kvůli automaticky obsažené podpoře vývoje mobilních aplikací (není nutné doinstalovávat žádný toolkit nebo jiné nezbytné knihovny).
13
3.2 Architektura aplikace Na obrázku 3.1 je znázorněna architektura celé aplikace. Klíčovou komponentou je třída Navigator, která se stará kromě celkového zpracování dat pro navigaci (podrobně rozebráno v kapitole 3.5.1) také o připojení k navigačnímu serveru a záznam dat pro tvorbu statistik o průjezdnosti jednotlivých tras. Vstupní bodem celé aplikace je třída CxNavi1, která je poděděna od třídy MIDlet a zajišťuje ukládání informací o výjimkách, detekuje možnosti mobilního zařízení (podporu 3D zobrazení či přístup k souborovému systému) a stará se o prvotní nastavení uživatelského rozhraní.
Obrázek 3.1 Architektura celé aplikace - hlavní komponenty. U komponent je v závorce uveden název třídy ve zdrojovém kódu, která za danou funkci zodpovídá
1
Cx je prefix, zkratka pro „Context“, který byl ve zdrojovém kódu použit v případech, kdy by mohlo dojít ke jmenným konfliktům s již existujícími třídami J2ME
14
3.3 Data z akcelerometru Data z akcelerometru (pro detekci kontextu – teorie v kapitole 2.1) jsou v této práci měřena pomocí ovladače WiiMote (jde o externí zařízení, více na webu (3)), nicméně existuje řada mobilních telefonů, které čidlo pro měření akcelerace mají přímo zabudované. Jde například o telefony Nokia N95, N82 nebo 5500. Během implementace aplikace nebyl však žádný z uvedených telefonů k dispozici a nebylo tedy možné vyzkoušet tento způsob měření. Pro analýzu dat je pak použita jednoduchá implementace Fourierovy transformace, která je uvedena na stránce http://cnx.rice.edu/content/m12016/latest/. (4)
3.3.1 WiiMote WiiMote je zkratka od Wii Remote, což je název ovladače herní konzole Nintendo Wii. Nintendo Wii je konzolí 7. generace, která soupeří s konkurenčními Microsoft Xbox 360 nebo Sony PlayStation 3. Na rozdíl od ostatních konzolí, Nintendo nevolilo jen cestu vyššího výkonu, lepší grafiky a efektů, ale rozdílný přístup v ovládání. Ovladač WiiMote umí stejně jako jiné bezdrátovou komunikaci s konzolí, ovládání her (aplikací) pomocí tlačítek (čtyřsměrová i klasická) a zpětnou vazbu pomocí generátoru vibrací. Přidává Obrázek 3.2 Nintendo Wii však měřic zrychlení (dále jen akcelerometr) ve všech třech osách. Pomocí těchto hodnot je tedy možné reagovat na pohyb (např. simulace hraní tenisu) i natočení ovladače (ovladač může například reprezentovat ovladač „plynu“ na motocyklu a jeho natočením může virtuální motocykl zrychlovat či zpomalovat). V této práci využíváme hodnot z akcelerometru ke zjištění, zdali se uživatel (osoba držící ovladač) pohybuje v autě (či jiném dopravním prostředku) nebo jde pěšky. Zajímá nás tedy pouze složka, která představuje gravitační sílu. Problém je ten, že osy akcelerometru ovladače nemusí být nutně srovnány s osami pohybujícího se vozidla (např. dopředný pohyb po ose Z, gravitační síla na ose Y) či pěšky jdoucího uživatele. Tento ideální případ nastává pouze tehdy, pokud je ovladač položen na zadní stranu a nasměrován do směru pohybu. Pokud ale dojde k tomu, že je ovladač položen jinak (např. pohozen v tašce nebo batohu), osy mohou být libovolně natočené.
Obrázek 3.3 Ovladač WiiMote a orientace čidla pro akceleraci
Určitou možností by bylo předpokládat, že se ovladač netočí kolem svých os a reflektuje opravdu pouze změny gravitační složky. Z průměru posledních několika měření by pak bylo možné zjistit vektor, pomocí kterého by se spočítalo natočení 15
oproti ideálnímu (0 1 0) a při každém novém měření udělat toto otočení (transformaci). Ukázalo se však, že daleko jednodušším a stejně dobrým řešením je pouhé sečtení všech tří os akcelerometru. Vznikne tak skalární veličina, se kterou je možné pracovat stejně jako s gravitační složkou. Přesto, že protokol pro ovládání a čtení hodnot je pro ovladač WiiMote dobře popsán, není situace úplně jednoduchá. Cílem této práce bylo vytvoření multiplatformní aplikace, což mělo za následek volbu J2ME jako platformy pro vývoj. JSR 82 (Bluetooth API and OBEX API) nepodporuje podle oficiálních specifikací připojení na porty (PSM) nižší než 0x1001. Ovladač přitom používá porty 11 a 13. Z midletu tedy není možné připojit ovladač přímo, ale je nutné zvolit nějakou proxy aplikaci, která je nativní pro daný operační systém a zpřístupní data například na lokálním TCP portu. Pro účely této práce byla použita aplikace Obrázek 3.4 Proxy aplikace pro WiiMote WiiConnect (na obrázku; lze ji nalézt na adrese http://symbianresources.com/projects/wiirider.php). Jde o hotovou (bez zdrojových kódů) aplikaci určenou pro operační systém Symbian (ten je přítomen na mobilních telefonech Nokia). Z nutnosti mít puštěnou k vlastní aplikaci i proxy plyne další problém (kromě toho uživatelského, kdy uživatel musí ručně spouštět nejdřív proxy a pak samotný midlet). Pokud je aplikace náročná na výpočetní výkon mobilního zařízení, může dojít k tomu, že proxy aplikace přijímající data od ovladače přestane stíhat zpracovávat údaje (což má za následek jejich výrazné zpoždění či nedodání klientské aplikaci). Tomuto problému se nepodařilo vyhnout ani nastavením vláken na nižší prioritu (buď tedy sama proxy aplikace běží s nižší prioritou, nebo JVM bere v úvahu prioritu vláken pouze v rámci Java aplikací a ne vzhledem k celému systému). Zbývá tedy pokusit se co nejméně zatěžovat zařízení během aplikace a v určitých momentech (v této práci po vykreslení obrazovky, což je nejnáročnější část na výkon) pozastavit aplikaci a počkat na doručení dat od proxy aplikace (nikdy ale není možné dopředu vědět, kolik těchto dat je, takže je nutné se „spokojit“ alespoň s několika a pak pokračovat v běhu). Další informace o ovladači WiiMote lze nalézt na webu. (3)
16
3.4 Zjišťování polohy 3.4.1 Připojení k GPS modulu Pro získávání dat z GPS modulu je možné zvolit různé metody. Pro J2ME aplikace je nejjednodušší použít Location Based Services API (JSR-179, dále jen Location API), které poskytuje transparentní přístup k údajům, které je možné získat z aktuálně připojených zařízení nebo daného mobilního zařízení. Aplikace tedy pouze zadá této vrstvě požadavky na přesnost (horizontální či vertikální přesnost) či úplnost údajů (měření rychlosti, směru atd.) a buď je jí vrácen odkaz na odpovídající zdroj dat (Provider) nebo se vrátí pouze prázdná reference. Výhodou zmíněného přístupu je jednoduchost – programátor se nemusí starat o konkrétní implementační detaily a podle schopností zařízení může využívat kromě GPS například i triangulaci přes BTS buňky (v případě, že tuto službu operátor a zařízení podporuje) – během implementace tedy nemusí být známy všechny možné způsoby zjišťování polohy. Mezi nevýhody patří menší počet údajů, které je možné přes Location API zjistit (aplikace například neví, které satelity u GPS používá nebo zdali se používá korekce), a hlavně absence podpory u některých zařízení (konkrétně např. zařízení s operačním systémem Windows Mobile). Alternativou použití Location API je přímé připojení k GPS modulu pomocí nějakého z podporovaných protokolů, kde si aplikace všechny údaje zjišťuje a vypočítává sama. Jde sice o složitější přístup, ale výsledkem může být lepší funkčnost/použitelnost celého řešení. Nevýhodou je, že přímé připojení je již implementováno pro konkrétní protokol a nejedná se tedy o abstraktní vrstvu jako v případě Location API, z čehož vyplývá, že lze použít pouze ty zařízení a protokoly, pro které byla aplikace během implementace navržena. Nejlepší volbou je v aplikaci kombinovat oba zmíněné způsoby zjišťování polohy a používat ten, který je aktuálně dostupný a vhodnější.
3.4.2 Location API Location API je součástí J2ME, konkrétně jde o package javax.microedition.location. (5) Jak již bylo popsáno výše, jde o transparentní přístup ke zjišťování polohy. Užití Location API je rozděleno na dva kroky – dotázání se na poskytovatele dat (LocationProvider) a samotné čtení dat. Při zjišťování poskytovatele je nutné specifikovat řadu kritérií, kterým musí výsledná data odpovídat (horizontální a vertikální přesnost, spotřeba energie, rychlost reakce, informace o adrese a další). Definice kritérií (v Java kódu) může vypadat například takto: Criteria crit1 = new Criteria(); crit1.setHorizontalAccuracy(25); // 25m crit1.setVerticalAccuracy(25); // 25m crit1.setPreferredResponseTime(Criteria.NO_REQUIREMENT); crit1.setPreferredPowerConsumption(Criteria.POWER_USAGE_HIGH);
17
crit1.setCostAllowed(false); crit1.setSpeedAndCourseRequired(false); crit1.setAltitudeRequired(false); crit1.setAddressInfoRequired(false);
Po zjištění odpovídajícího poskytovatele dat stačí nastavit posluchače (třída implementující rozhraní LocationListener), který bude zpracovávat data o aktuální pozici. Třída musí implementovat metody locationUpdated (informace o aktuální poloze) a providerStateChanged (informace o stavu dat – jestli jsou k dispozici, nedostupná, dočasně nedostupná nebo je služba mimo provoz).
3.4.3 NMEA 0183 Jak už bylo napsáno výše, přímé připojení k GPS modulu pomocí protokolu NMEA 0183 je alternativou k použití Location API. V případě operačního systému Windows Mobile může jít také o jedinou možnost, jak získat data o aktuální poloze. Protokol NMEA 0183 je čistě textový protokol, kdy GPS modul neočekává žádné příkazy a připojenému zařízení pouze periodicky posílá informace o aktuální poloze, satelitech, kvalitě signálu atd. Druh informací je rozlišen typem zpráv a každá zpráva je uložen na jednom či více řádcích (na více řádcích jsou informace o družicích, které jsou aktuálně viditelné a používají se pro zjištění polohy), které jsou od sebe oddělené dvojicí znaků CR a LF (ASCII kódy 13 a 10). V aplikaci jsou zpracovány zprávy GPRMC a GPGGA. Obě obsahují informace o aktuální poloze, GPGGA dále obsahuje indikaci, jestli je pro zjištění polohy použito diferenční GPS (větší přesnost polohy). V rámci jedné zprávy je řada údajů (tokenů), které jsou od sebe odděleny čárkou. Formát není samopopisný a v případě absence některého z údajů je nutné zachovat oddělovače (čárky) mezi údaji. GPRMC (Recommended Minimum Specific GPS/TRANSIT Data) Příklad: $GPRMC,170138.615,A,4912.2525,N,01635.0378,E,0.04,16.43,280705,,*32
GPGGA (Global Positioning System Fix Data) Příklad: $GPGGA,170139.615,4912.2526,N,01635.0378,E,1,07,1.0,357.5,M,43.5,M,0. 0,0000*7D
Delší ukázka dat je v příloze 9.1 a další informace o NMEA 0183 je možné nalézt na webu. (6) Kromě připojení k GPS modulu lze kromě NMEA 0183 využít také další protokoly, například SiRF, který je binární a jeho použití nebylo v rámci této práce implementováno.
18
3.5 Navigace 3.5.1 Celkové zpracování dat pro navigaci Aplikace zpracovává pro navigaci uživatele velké množství dat (poloha, kontext uživatele, aktuální trasa), které jsou pak prezentovány uživateli. Od samotného uživatelského rozhraní je toto zpracování odděleno do samostatné třídy Navigator. Při každém nové informaci o aktuální poloze předává třída Navigator tuto informaci společně s dalšími údaji (rychlost, směr pohybu) uživatelskému rozhraní. Rychlost a směr pohybu jsou počítány z údajů za posledních několik sekund, aby v případě krátkých intervalů mezi zprávami nedocházelo k nepřesnostem (kdyby byly hodnoty počítány pouze z posledních dvou zpráv, údaj by nemusel být přesný a v případě doručení dvou stejných zpráv ve stejný čas by nebylo vůbec možné rychlost nebo směr pohybu určit). Pomocí zmíněné třídy je také realizováno zjišťování trasy ze zadaného startovního bodu (pokud není zadán, předpokládá se aktuální poloha mobilního zařízení) do cílového bodu. Odkaz na instanci této trasy (MapRoute) je uložen v rámci třídy a v případě, že při aktualizace polohy dojde ke zjištění, že se uživatel odchýlil od zadané trasy (jeho aktuální poloha neleží na trase po určitý časový interval), dojde k automatickému přepočítání trasy (z aktuální polohy do původně zadaného cíle). Změna zobrazení pro uživatele je pak vyvolána metodou (událostí) routeConstructed, kterou musí implementovat posluchač (listener) třídy Navigator (což je v tomto případě hlavní obrazovka aplikace, která se stará o vizuální zprostředkování údajů uživateli). Při samotném vyhledávání trasy je zohledněn kontext uživatele, který může být buď zjištěn automaticky na základě hodnot z akcelerometru (teorie v kapitole 2.1, implementace popsána v kapitole 0) nebo nastaven manuálně uživatelem.
Obrázek 3.5 Napojení třídy Navigator na další komponenty aplikace (zjištění kontextu a polohy, záznam a vyhledání trasy k cíli).
19
3.5.2 Načítání mapy Jedním z velkých problémů, který se objevil během implementace, je absence třídy RandomAccessFile v J2ME. Tato třída slouží pro náhodný přístup k souboru – možnost skoku na jakoukoliv pozici v souboru (ať už pro čtení nebo zápis) v konstantním čase. J2ME bohužel podporuje pouze proudový přístup, kdy se se soubory pracuje stejně jako s připojeními na síti. Tato možnost je silně nedostatečná, protože mapové podklady mohou být i desítky MB velké a nelze je držet najednou v paměti (dostupná paměť mobilního zařízení se počítá spíše na jednotky MB), ani při každém přístupu otevírat konkrétní soubor a „najížděť“ na požadovanou pozici. Aby bylo možné tento nedostatek v rámci této práce obejít, byly využity menší mapové podklady (pro testování obsahují pouze Prahu). Tyto data je pak už možné nahrát kompletně do paměti a emulovat náhodný přístup k souboru. Náhodný přístup k souboru je implementován ve třídě CxRandomAccessFile (interpretuje binární reprezentaci všech primitivní typů přímo z paměti), která obsahuje rozhraní DataInput, aby ji bylo možné využít stejně jako jiný způsob čtení. Samotné objekty, které jsou načítány, byly implementovány v rámci diplomové práce, která se zabývá tvorbou serveru. (1)
3.5.3 Nalezení trasy Celá mapa je uložena jako množina uzlů a hran, kdy hrany představují ulice (či jejich části) a uzly jsou jejich koncové body. Hledání trasy je tedy možné realizovat pomocí známých algoritmů z teorie grafů (Dijkstra nebo A*). Prohledávání mapy za účelem nalezení trasy probíhá algoritmem A*. Ohodnocení hran je závislé na tom, jestli je cílem najít trasu nejrychlejší nebo nejkratší. U nejkratší cesty je ohodnocení hran přímo závislé na vzdálenosti, u nejrychlejší trasy pak dochází k přepočtu na čas nutný k překonání jednotlivých úseků trasy podle aktuálního kontextu (u chůze pěšky jde o konstantní rychlost, u jízdy autem je pak rychlost odvozena od typu silnice). Množina uzlů, která je prohledávána, je omezena během expandování tak, aby nedošlo k vyčerpání paměti (používá se prioritní fronta a při jejím zaplnění se vypustí uzly, u kterých je odhadnutá cesta nejdelší). Pokud je aplikace v online režimu, tedy připojena k navigačnímu serveru, probíhá hledání přes server, který má informace o dalších účastnících či dodatečné zdroje dat. V offline režimu pak probíhá hledání přímo na mobilním zařízení pomocí stejných algoritmů (třídy starající se o nalezení trasy na serveru jsou obsaženy i v mobilní části), které jsou implementovány na serveru. Více informací o implementaci hledání trasy lze nalézt v diplomové práci, která se zabývá serverovou částí celého řešení. (1)
20
3.6 Připojení k navigačnímu serveru Při použití externích zdrojů (například spojů MHD) či v případě složitějších scénářů je nutné použít připojení k serveru, který poskytuje odpovídající rozhraní pro tyto případy. Server je výsledkem jiné diplomové práce (1), která byla zhotovena jako doplněk k této. Připojení používá TCP spojení na předem specifikované porty, na kterých server naslouchá (klient, tedy mobilní zařízení uživatele, nemusí mít veřejnou IP adresu). Komunikace je implementována ve třídách ProtocolClient a ProtocolServer v package communication, kdy jedna třída (ProtocolClient) zodpovídá za zprávy (poslání aktuální pozice uživatele, dotaz na cestu atd.) poslané na server (a za odpovědi na tyto zprávy) a druhá za zprávy ze serveru (dotázání se jednoho uživatele, zda může autem svézt jiného). Tabulka 3-1 Zprávy posílané z klienta na server
Zpráva
Popis zprávy
MESSAGE_GET_MAP
Stažení aktualizovaných mapových podkladů ze serveru (ať už jde o nové údaje, například silnice, nebo lepší statistiky pro navigaci)
MESSAGE_FIND_ROUTE
Nalezení trasy mezi zadanými body s určeným kontextem a v daném čase
MESSAGE_SET_FRIENDS
Nastavení kontaktů, které lze využít v případě složitějších scénářů (chodec přistoupí do auta) – tato zpráva se posílá hned po připojení k serveru
MESSAGE_UPDATE_STATE
Aktualizace pozice uživatele
Nahrání absolvované trasy na server MESSAGE_UPDATE_SNAPPED_TRACK pro účely tvorby statistik (nahrávají se souřadnice ulic a čas na nich strávený) Tabulka 3-2 Zprávy posílané ze serveru na klienta
Zpráva
Popis zprávy
Při vyhledávání trasy přes server je posílána tato zpráva s informací o možné cestě k cíli – tato cesta je MESSAGE_ROUTE_DESCRIPTION_UPDATE pomocí těchto zpráv postupně upřesňována podle toho, jak jiní uživatelé (řidiči) odpovídají, jestli mohou někoho svézt
21
MESSAGE_DRIVE_USER_QUESTION
Dotaz na uživatele, který jede autem, zdali je ochotný svézt jiného (chodce)
MESSAGE_ROUTE_PATH_UPDATE
Seznam bodů, přes které musí probíhat navigace (při složitějších scénářích, kdy autu a chodci je předán bod nástupu a výstupu)
MESSAGE_FRIEND_STATE
Informace o pozici a kontextu jiného uživatele, kterého má aktuální uživatel v kontaktech
MESSAGE_MUST_REROUTE
Pokyn serveru klientovi, že je nutné provést přepočítání trasy (například když se změní podmínky pro trasu v případě složitějšího scénáře)
3.6.1 Nahrávání projetých tras na server Aby bylo možné navigovat podle statistiky průjezdnosti ulic v různých časových intervalech během dne či týdne, je nutné tyto statistiky nejprve dynamicky tvořit pomocí analýzy pohybu jednotlivých uživatelů. Určení silnice (ke kterému dochází ve tříde Navigator při každé aktualizaci polohy pomocí GPS modulu), na které se uživatel nachází i v případě nepřesnosti zjištění polohy, je popsáno v kapitole 2.3.1. Je nutné však počítat s tím, že silnice bude určena nesprávně (například u křižovatek může lehce dojít k „přeskoku“ na vedlejší silnici) a bylo by dobré tedy tyto výsledky eliminovat. Při projíždění nebo procházení cesty je předpoklad takový, že první bod, který odpovídá tomuto úseku je blíže jednomu konci pomyslné úsečky a poslední bod druhému. Protikladem je nesprávné určení, kdy body „přichycené“ k úsečce, která na mapě představuje ulici, jsou pouze u jednoho konce úsečky. Výsledkem záznamu trasy je seznam dvojic bodů v mapě (uložené v instanci třídy GpsSnappedTrack), které představují silnice či cesty (případně jejich části, pokud jsou složeny na mapě z více bodů), a čas, který uživatel na daném úseku strávil. Zmíněný čas je pak možné porovnat s referenční hodnotou (která je určena délkou úseky a povolenou rychlostí v případě auto či očekávanou rychlostí u chodce) a upravit statistiku pro daný úsek (pro daný časový interval). Záznamy jsou opakovaně nahrávány na server, který je zpracuje a upraví odpovídajícím způsobem své mapové podklady. K nahrávání dochází každých 30 sekund nebo v případě zaznamenání 50 úseků (podle toho, která podmínka je splněná dříve; u využívání statistik ze serveru je předpokládáno permanentní připojení k serveru).
22
Aktualizovaná data si pak mohou klienti stáhnout zpět k sobě. Tímto způsobem lze velmi jednoduše a automaticky upravovat navigační data a směřovat tak uživatele co nejlépe.
3.6.2 Stažení aktualizované mapy ze serveru Samotné stahování aktualizovaných mapových podkladů je řešeno univerzálně – dochází k přímému přenosu souborů, ve kterých jsou uložena data. Klient pouze zažádá o data s určitými kritérii a server vrátí postupně názvy souborů, jejich velikost a následně samotná data. Kritéria (třída MapDataDescriptor) nemusí být nutně specifikována, pak server vrátí implicitní sadu dat. Pomocí těchto kritérií je však možné upřesnit nejen souřadnice (které tvoří polygon v mapě), ale i typ dat (druhy silnic, oblastí atd.).
3.6.3 Složitější scénáře navigace Během složitějších scénářů je veškeré počítání trasy a možností navigace realizováno na centrálním serveru. Celý proces je iniciován navigací do zadaného bodu (zpráva MESSAGE_FIND_ROUTE). Server se následně zeptá řidičů, které je možné využít, jestli jsou ochotni pěšího svézt (MESSAGE_DRIVE_USER_QUESTION). Během postupných odpovědí od řidičů upřesňuje (a zlepšuje) server trasu a informace o ní posílá chodci, který kdykoli může proces ukončit a přijmout či odmítnout aktuální trasu. Po přijmutí je poslána celá trasa ze serveru klientovi (všem účastníkům scénáře), který aktualizuje vyznačení trasy v mapě, vzdálenost do cíle a další údaje. Každý z účastníků si může zobrazit itinerář cesty, kde jsou zmíněny body, kde chodec nastupuje do automobilu či z něj vystupuje. Tyto informace jsou přenášeny ve zprávě MESSAGE_ROUTE_PATH_UPDATE.
23
3.7 Uživatelské rozhraní Na obrázku 3.6 je znázorněn dialogový model celé aplikace. Ihned po spuštění je zobrazena hlavní obrazovka, kde je vidět mapa spolu s aktuálními údaji. Na této obrazovce se v případě potřeby mohou objevit doplňující informace (například při složitějších navigačních scénářích). Pomocí menu se pak může uživatel dostat na další obrazovky – zadání požadovaného cíle trasy a nastavení aplikace.
Start aplikace
Konec aplikace
Hlavní obrazovka (mapa, aktuální informace)
* Dotaz na uživatele při složitějším navigačním scénáři
Nastavení
Zadaní cíle trasy
* Itinerář
Obrázek 3.6 Model uživatelského rozhraní aplikace
3.7.1 Hlavní obrazovka Vzhledem k tomu, že hlavní účel aplikace je navigovat uživatele, primární obrazovka je určena pro zobrazení mapy, vzdálenosti k cíli, aktuální rychlosti a další okamžitých údajů relevantních pro uživatele. Každá ze zmíněných položek pochopitelně potřebuje své místo na displeji a u přenosných mobilních zařízení je displej znatelně menší než například u osobního počítače či integrované navigace do auta. Cílem je tedy využít displej mobilního zařízení co nejvíce. Některé operační systémy (například Windows Mobile) umožňují Java aplikacím využít téměř celou plochu displeje, pouze zobrazí navíc stavový řádek pro spouštění dalších aplikací, informaci o stavu baterie atd. Jiná situace je Obrázek 3.7 Navrhované například u telefonů Nokia se systémem Symbian. Při rozložení prvků na hlavní spuštění midletu je poměrně velká část displeje zabrána obrazovce aplikace názvem aktuálního okna, který je v případě navigace nepodstatný. Pro kompletní využití displeje je možné využít tzv. fullscreen mode, kdy dostane midlet k dispozici celou plochu displeje. Výhodou je tedy plné využití možné plochy k zobrazování, nevýhodou je nutnost se starat o funkční klávesy mobilního
24
zařízení a odpovídajícím způsobem na ně reagovat (J2ME framework sice i v celoobrazovkovém režimu reaguje na stisky kláves, ale vizuálně již nejsou tlačítka zobrazeny). Pro jednoduché použití celé plochy displeje slouží třída CxCanvas. Umožňuje použití jak v normálním, tak celoobrazovkovém režimu – podle nastavení se pak sama stará o zobrazování tlačítek a volání odpovídajících funkcí, nebo vše předá standardním metodám.
3.7.2 Reakce na klávesy Při stisku klávesy mobilního zařízení musí aplikace reagovat odpovídajícím způsobem. Kódy klávesy se však mohou u různých zařízení lišit (jde o směrové nebo funkční klávesy). Třída Canvas poskytuje definované konstanty pro jednotlivé klávesy, zařízení může ale zasílat kódy jiné. K tomuto účelu je implementována třída KeyResolver, která obsahuje funkce pro konkrétní klávesy, rozlišující, zdali je daná klávesa stisknuta nebo není. Příklad pro jednu klávesu: public class KeyResolver { ... public static boolean isUpKey(int key) { return key == -1 || key == Canvas.UP || key == -57377; } ... }
3.7.3 Spořič obrazovky Během implementace a průběžného testování se objevil problém, že testovaný přístroj (Nokia N73) vždy po krátké neaktivitě ze strany uživatele začal zobrazovat spořič obrazovky (displej je celý tmavý až na údaj o aktuálním čase a případných nepřečtených zprávách či nepřijatých hovorech). Základní sada dostupný metod a funkcí v J2ME neobsahuje možnost, jak zamezit spouštění spořiče obrazovky. U mobilních zařízení značky Nokia lze použít package com.nokia.mid.ui, který obsahuje třídu DeviceControl. Pomocí zmíněné třídy je možné nastavovat jak podsvícení displeje, tak zapnout/vypnout vibrace přístroje. Dle dokumentace, funkce setLights by měla kromě nastavení podsvícení zároveň zamezit spuštění spořiče. Aby došlo k permanentnímu zamezení, je doporučeno periodické volání funkce setLights, s intervalem kratším než je spuštění spořiče (což je 15 s nebo více). Část dokumentace funkce setLights (10): „This function may also be used to prevent screen saver appearance (supported in S60 devices starting from S60 3rd Ed FP1, except for some early FP1 devices). Calling this function once will delay the screen saver appearance but does not disable it permanently. Thus, if the screen saver should be wholly disabled, it is needed to call the function repeatedly for example in a
25
separate thread. The delay between two calls should be smaller than the time-out of the screensaver (the time-out may be for example 15 seconds or more depending on the used device).“
3.8 Zobrazení mapy Mapa pro navigaci se zobrazuje v 3D zobrazení, což umožňuje její natáčení (podle směru pohybu uživatele) a naklopení (podle rychlosti – při pomalém pohybu se mapa zobrazuje téměř shora, při rychlém se pak natáčí tak, že je vidět více do dálky). Pro 3D zobrazení je použita knihovna „Mobile 3D Graphics API“ (dále jen M3G (7)), která rozšiřuje možnosti J2ME právě o 3D zobrazování. Nejde o knihovnu Java 3D, která je určena pro J2SE a je navržena pro stolní počítače, které mají podstatně větší paměť a Obrázek 3.8 Zobrazení mapy (rotace a naklopení podle pohybu) výpočetní výkon. M3G je jednoduché API (package javax.microedition.m3g, (8)), které poskytuje vše potřebné pro 3D zobrazení objektů. Vzhledem k tomu, že samotná navigace používá sférické souřadnice (zeměpisná délka a šířka) je nutné je pro zobrazení převést na jiné (rovinné) ze dvou důvodů: kvůli zaokrouhlování ve 3D (u GPS souřadnic je nutná velká přesnost – na několik desetinných míst) a také kvůli jednoduchým výpočtům pozice kamery, rotace atd. Intuitivní se pro tento účel jeví takový přepočet, kdy jednotka v 3D světe bude jednotka délky, tedy metr. U přepočtu je zanedbán přesný tvar Země a je předpokládán tvar koule (obvod rovníku 40 075 km). Pro převod zeměpisné šířky stačí vynásobit souřadnici počtem metrů na stupeň, u zeměpisné délky je nutné ještě tento výpočet vynásobit funkcí sin, která se vzrůstající šířkou upraví výsledné souřadnice (jeden stupeň zeměpisné délky na rovníku představuje daleko více kilometrů než jeden stupeň blízko jednoho z pólů).
3.8.1 Umístění kamery Umístění a natočení kamery ovlivňuje to, co uživatel na displeji uvidí. Během navigace je kamera nastavena tak, že je namířena na bod, který představuje aktuální pozici uživatele. Umístění samotné kamery je odvozeno od toho, jak rychle se uživatel pohybuje. Pokud jde pěšky a jeho rychlost je tedy malá (okolo 5 km/h), je kamera umístěna téměř nad jeho pozicí a mapa se tedy jeví jako 2D. Při větších rychlost se ale umístění mění takovým způsobem, že je vidět v mapě dále dopředu (kamera zůstává za aktuální pozici, tedy proti směru pohybu, a natáčí se směrem k horizontu). Dalším atributem je rotace. V běžném režimu se kamera natáčí tak, aby kopírovala směr pohybu a mapa tedy byla zobrazena tak, že to, co je před uživatelem 26
ve skutečnosti, je na mapě nahoře. V některých případech (například při porovnávání s papírovou mapou) může být výhodné natočení kamery takové, kdy je sever nahoře (stejná orientace jako všechny klasické mapy. Aplikace se mezi režimy „sever nahoře“ (v tomto režimu je kamera vždy umístěna přímo nad aktuální pozicí nezávisle na rychlosti) a „podle pohybu“ přepíná pomocí položky „Přepnout pohled 3D/shora“ v menu (či stiskem klávesy „2“).
3.8.2 Vykreslování po vrstvách Během implementace docházelo při vykreslování k artefaktům, které byly způsobeny malou rozlišovací schopností depth-bufferu (pole reprezentující pro každý renderovaný pixel vzdálenost od kamery – pixel je možné překreslit pouze tehdy, kdy je vzdálenost pro novou hodnotu pixelu menší nebo rovna než aktuálně nastavená). Pokud byla zobrazena například řeka a přes ni ostrov či silnice, docházelo k prolínání obou objektů i tehdy, když byly od sebe ve virtuálním světě na ose Y vzdáleny a odděleny. Zmíněný problém se podařilo vyřešit tak, že mapa se vykresluje „po vrstvách“. Každá vrstva je reprezentována skupinou objektů (M3G třída Group), které se nemohou překrývat. V jedné vrstvě jsou tedy vodní plochy, v další silnice atd. Při samotném vykreslování se pak nastaví vymazání cílové grafiky (vykreslí se pozadí scény) pouze u první vrstvy, u dalších se tento výmaz vypne. Druhá vrstva a všechny další tedy již kreslí do hotového obrázku 3D scény a pouze ho překreslují (lepší termín je možná „dokreslují“). Zapnutí/vypnutí překreslování: world.getBackground().setColorClearEnable(true/false);
3.8.3 Zobrazení názvů ulic Aby byla navigace přehledná a jasná, je nutné zobrazit uživateli nejen samotné objekty na mapě (silnice, vodní plochy atd.), ale také názvy ulic. Pro menší paměťovou a výpočetní náročnost bylo zvoleno vykreslování textů přímo do výsledného obrazu 3D scény. Jinou možností by bylo použití další vrstvy silnic s texturami, které by obsahovaly názvy ulic (zde je problém ten, že při pohybu uživatele se mapa natáčí a mohlo by dojít k otočení některých textů i o 180° - bylo by tedy nutné všechny souřadnice textur přepočítávat a opravovat), nebo použití spritů (2D objekt ve 3D scéně, který je vždy natočen směrem k virtuální kameře; je nutné také použití textur). U vykreslování textů přímo 2D není žádný problém s natočením textů nebo nutností generovat textury, jen je nutné zjistit, který pixel (souřadnice {x, y}) odpovídá danému bodu v 3D prostoru (souřadnice {x, y, z}) kde by bylo vhodné název ulice zobrazit. Každý bod v 3D scéně je transformován do 2D souřadnic pomocí série násobení matic, které představují jednotlivé objekty, které ovlivňují umístění – od transformace samotného objektu a jeho „rodičů“ až po transformaci celého 3D světa,
27
kamery a projekční transformace (ve které jsou uloženy hodnoty o velikosti úhlu pohledu, poměru stran zobrazovacího zařízení atd). Pro převod z 3D do 2D tedy stačí získat všechny relevantní transformace, jejich matice pronásobit a pomocí výsledné matice transformovat pozici textu. Výsledkem bude matice, která bude obsahovat souřadnice pro zobrazení na 2D displeji (v rozmezí [-1;-1] až [1;1], což je nutné převést na skutečné souřadnice pixelů).
Obrázek 3.9 Pipeline M3G: V horní části se skládají trojúhelníky (se všemi nutnými atributy), které se tak připravují na vykreslení. V dolní části pak dochází k finálním transformacím a převodu do výsledného 2D obrazu. Obrázek převzat z http://www.cs.lth.se/EDA075/assignment1/jsr184-specification1.0/javax/microedition/m3g/Graphics3D.html (9).
Pro jednoduchost projekt obsahuje třídu TextNode, která dědí od objektu Group a obsahuje tedy všechny funkce 3D objektu (nutné pro transformaci v 3D prostoru). Její funkce render pak převede pozici objektu na {x, y} souřadnice a zavolá standardní metodu Graphics.draw pro vykreslení textu. Následuje zkrácený (bez komentářů) výpis funkce render, která obsahuje všechny nutné převody: public void render(Graphics g, Graphics3D g3D, Camera camera, int viewportWidth, int viewportHeight) { camera.getCompositeTransform(cameraTransform); camera.getProjection(projectionTransform);
28
getCompositeTransform(textTransform); cameraTransform.invert(); cameraTransform.postMultiply(textTransform); projectionTransform.postMultiply(cameraTransform); projectionTransform.get(textMatrix); float x = textMatrix[3]; float y = textMatrix[7]; float z = textMatrix[11]; int middleWidth = viewportWidth >> 1; int middleHeight = viewportHeight >> 1; outX = middleWidth + (int) (x / z * middleWidth); outY = middleHeight - (int) (y / z * middleHeight); if (outX > 0 && outX < viewportWidth && outY > 0 && outY < viewportHeight) { g.drawString(text, outX, outY, anchor); } }
3.8.4 Načítání objektů k zobrazení Aby měla aplikace dostatečně rychlou odezvu a byl šetřen výkon a paměť mobilního zařízení, je nutné načítat a zobrazovat (vykreslovat) pouze ty objekty, které mají být aktuálně vidět (s určitou rezervou na načtení dalších dat, aby případný pohyb nezpůsobil, že na mapě bude vizuální mezera). Zobrazení v 3D je určeno nastavením kamery, tedy kromě jejího umístění a natočení také velikostí zorného pole a poměrem stran. Vzhledem k tomu, že všechny objekty jsou zobrazeny v rovině, pro kterou platí , stačí vytvořit z pozice kamery čtyři paprsky (rohy displeje), které se s touto rovinou protínají a jejich průniky reprezentují polygon, který uživatel na mapě vidí. Jednotlivé paprsky představují krajní body v prostoru, které uživatel ještě může vidět. Paprsek pro levý horní roh je tedy nejprve vytvořen jako vektor –
a pak transformován stejně jako
samotná kamera (jejíž implicitní vektor natočení je
).
Tabulka 3-3 Vektory paprsků pro jednotlivé rohy displeje
Roh displeje
Vektor paprsku při implicitním natočení kamery
Levý horní Pravý horní Levý dolní Pravý dolní
29
Při zjišťování polygonu, který představuje plochu v mapě pro zobrazení, je nutné, aby se paprsky představující jednotlivé rohy kamery, protnuly s rovinou . Se vzrůstající rychlostí pohybu uživatele se kamera postupně natáčí tak, aby byl vidět větší úsek mapy ve směru pohybu, a může tedy dojít k tomu, že paprsky pro horní rohy nebudou mít žádný průnik s rovinou mapy (ve směru pohybu). Při nastavení jejich vektorů je tedy nutné kontrolovat jejich Y složku a pokud je záporná, zvolit jiný způsob určení bodů v mapě pro určení polygonu k zobrazení. V práci byl použit algoritmus, který v této situaci vezme body, které odpovídají průnikům pro dolní rohy kamery a od těchto bodů vede úsečky (již v rovině mapy) ve směru paprsků o předem definované velikosti (2 km). Výsledek je ten, že při velké rychlosti se zobrazují body vzdálené maximálně 2 km. Následuje obrázek ilustrující parametry zobrazení ve 3D.
Obrázek 3.10 Ilustrace nastavení kamery (na obrázku "Eyepoint"), FOV = Field Of View (velikost zorného pole), Aspect ratio je poměr mezi horizontální a vertikální stranou výsledné plochy. Obrázek převzat z http://www.codinghorror.com/blog/archives/000937.html.
Samotné načítání objektů z databáze může být v případě více objektů (větší plochy k zobrazení) časově náročné a objekty se tedy načítají v samostatném vlákně. Zde je nutné synchronizovat přístup k seznamu objektů v 3D světě tak, aby nedocházelo ke kolizím při vykreslování (pokud se stane, že je objekt přidáván/ubírán do 3D světa v momentě volání funkce render, skončí vykreslování výjimkou).
30
3.9 Jazykové verze Aplikace je navržena tak, aby byla umožněna uživateli volba jazyka uživatelského rozhraní a bylo snadné případně přidat novou jazykovou verzi (aktuálně aplikace podporuje češtinu a angličtinu). Z tohoto důvodu jsou všechny textové řetězce, které se zobrazují, uloženy v samostatném textovém souboru (každá jazyková verze má svůj soubor), který obsahuje překlady. Každý textový řetězec je jednoznačně identifikován na základě textového identifikátoru, který je v hierarchické formě (jednotlivé „sekce“ jsou odděleny tečkami). Například text reprezentující popis pro volbu zdroje dat pro detekci kontextu uživatele má identifikátor „Settings.ContextRecognition.Type“. Hierarchický zápis má dvě výhody. První z nich je ta, že nedochází k nechtěnému přepsání či použití špatného textového řetězce během implementace (například „Type“ se v aplikaci objevuje víckrát, ale pokaždé v jiném smyslu). Druhá je ta, že pokud není v textovém souboru uveden překlad v daném jazyce, „odstřihne“ se začátek identifikátoru až k poslední tečce a vrátí se jako text. Výsledek je ten, že v případě, kdyby například pro výše uvedený identifikátor chyběl překlad, na obrazovce pro nastavení detekce kontextů bude mít seznam nadpis „Type“, což sice nebude pravděpodobně v dané jazykové verzi správně, nicméně je to lepší než prázdné místo nebo krkolomný a dlouhý řetězec ve stylu „SettingsContextRecognitionType“. Třída, která se o překlady stará je v package localization a jde o singleton (v rámci aplikace je použita pouze jedna instance). Při jejím prvním použití se do paměti načtou všechny překlady pro aktuálně nastavený jazyk a v nich se pak vyhledává. Příklad použití třídy: Translations.Current().GetString("Settings.ContextRecognition.Type")
Textové soubory pro překlad jsou uloženy přímo jako součást midletu, není nutné je tedy donahrávat k aplikaci a uživatel nemusí potvrzovat žádost o přístup k souboru. Ukázka souboru s překlady (pouze část): Cancel
Zrušit
City.Name
Město
Context
Kontext
ContextRecognitionProviders.None
Žádný
ContextRecognitionProviders.Simulation
Simulace
ContextRecognitionProviders.WiiMote WiiMote
Na každé řádce je uložena jedna dvojice pro překlad – nejprve je uložen identifikátor a pak odpovídající text. Hodnoty jsou odděleny znakem Tab. Tuto speciální hodnotu nesmí tedy identifikátor obsahovat (což se ale nepředpokládá), samotný překlad už ale ano (řádka se rozděluje pouze podle prvního výskytu).
31
3.10 Nastavení aplikace Aplikace potřebuje ke svému běhu celou řadu nastavení, z nichž některé jsou určeny pro zvýšení komfort uživatele (např. jazyk aplikace), jiné jsou nutné pro správný běh všech funkcí (zdroj GPS dat, zdroj dat akcelerometru atd.). K tomuto účelu midlet používá permanentní úložiště dat (dále jen RMS – podle package javax.microedition.rms), které je určeno vždy pouze odpovídající aplikaci. Různé J2ME aplikace si tedy nemohou přepsat své údaje a nastavení a není nutné řešit ani lokaci toho úložiště (jestli jej mobilní zařízení uchovává přímo v telefonu či na paměťové kartě). Aby nebylo nutné při každé změně množiny ukládaných dat mazat všechna nastavení a zjišťovat je znovu, jsou všechna nastavení uložena v rámci slovníku, který obsahuje páry {název, hodnota}. Každá hodnota je tedy jednoznačně určena svým názvem a není třeba řešit pořadí hodnot (což by byl případ, kdyby se ukládala struktura bez názvů hodnot s předem definovaným rozložením). Aplikace obsahuje třídu StoredDictionary, která poskytuje výše zmíněné funkce. Přístup k nastavení v rámci celé aplikace probíhá přes třídu CxNavi, která reprezentuje spuštěný midlet. Ukázka zjištění hodnoty z nastavení: CxNavi.OneAndOnly.Settings().getInteger("ContextRecognition.Type", 1);
-
3.10.1 Uživatelské rozhraní Fullscreen – použití celoobrazovkového režimu, aby byla maximálně využita možná plocha displeje (vhodné u operačního systému Symbian). Větší písmo – použití většího písma (výhodně u zařízení s Windows Mobile, kde je standardní písmo hůře čitelné). Jazyk – jazyk uživatelského rozhraní (čeština nebo angličtina). Názvy ulic – zobrazování názvů ulic v 3D zobrazení mapy (vypnutí urychlí zobrazování). Textury – místo jednotlivé barvy bude na silnice použita textura (zobrazení je výpočetně náročnější a na testovaných telefonech se objevil problém při použití textury na velkém množství 3D objektů najednou).
3.10.2 Poloha Zdroj dat – žádný (zjišťování polohy není zapnuta a navigace tedy nefunguje; tato hodnota slouží pouze jako výchozí nastavení), Location API (poloha je zjišťována přes rozhraní Location API, telefon však nemusí tento způsob podporovat – například v případě OS Windows Mobile), NMEA 0183 (přímé připojení k GPS modulu, který podporuje textový protokol NMEA 0183), Statické souřadnice (poloha je určena staticky zadanými souřadnicemi), Simulace (poloha je stejně jako v předchozí možnosti určena souřadnicemi, ale okolo těchto souřadnic opisuje pomyslnou kružnici, aby bylo možné otestovat pohyb v mapě; poslední dvě možnosti jsou určeny pouze pro testovací účely), GPS záznam (přehrává dříve pořízený záznam; přehrávání se dá zrychlit pomocí nastavení „Faktor rychlosti přehrávání“). 32
Zeměpisná šířka – statické nastavení zeměpisné šířky pro účely simulace (pro Prahu například 50.0732395). Zeměpisná délka – statické nastavení zeměpisné délky pro účely simulace (pro Prahu například 14.414586). URL GPS modulu – adresa pro přímé připojení k GPS modulu, pro zařízení připojené přes BlueTooth má adresa tvar „btspp://bluetoothAddress:1“ (např.: btspp://0012ab34cd56:1“). Záznam GPS pro simulaci – název soubor na paměťové kartě pro GPS simulaci (musí být vybrán zdroj dat „GPS záznam“). Faktor rychlosti přehrávání – rychlost přehrávání GPS záznamu (1 = normální rychlost, 2 = dvojnásobná atd.).
3.10.3 Rozpoznání kontextu Zdroj dat – žádný (rozpoznávání kontextu není prováděno, uživatel musí kontext nastavovat manuálně), simulace (aplikace simuluje hodnoty akcelerometru), WiiMote (zrychlení je měřeno pomocí ovladače WiiMote pro herní konzoli Nintendo Wii); během implementace se nepodařilo zapůjčit žádný mobilní telefon, který by obsahoval integrovaný akcelerometr, proto aplikace nepodporuje tento způsob zjištění dat. Faktor změny kontextu – kontext uživatele je detekován periodicky v krátkých časových intervalech a tato hodnota udává nutný počet těchto intervalů, které musí následovat, aby byla změna kontextu (nová hodnota) brána jako relevantní (zabraňuje rychlému přepínání v situacích, kdy se uživatel během chůze krátce zastaví nebo naopak v autě když pohne s akcelerometrem).
3.10.4 Komunikace Používat server – ovlivňuje, jestli má aplikace pro navigaci využívat spojení se serverem (který poskytuje podporu složitějších navigačních scénářů, externí zdroje dat jako například MHD atd.). Uživatelské jméno – jednoznačný identifikátor uživatele pro připojení k serveru. Přátelé – uživatelská jména kontaktů, jejichž polohu je možné zobrazit na displeji a využít u složitějších scénářů navigace (chodec přistoupí do auta atd.). Server URL – adresa navigačního serveru, například „socket://127.0.0.1“.
33
3.11 Instalace aplikace 3.11.1 Symbian Samotná aplikace se skládá ze dvou souborů (CxNavi.jad a CxNavi.jar), které stačí do mobilního zařízení zkopírovat a pomocí správce souborů otevřít (otevírá se soubor CxNavi.jad). Systém se pak již jen zeptá, jestli si uživatel opravdu přeje nainstalovat zvolenou aplikaci, a dále požádá o zvolení cílového umístění aplikace (telefon či paměťová karta). Kromě zmíněných instalačních souborů aplikace je ještě nutné zkopírovat na paměťovou kartu do kořenové složky také soubory s mapou. V případě operačního systému Windows (na uživatelském počítači) je nejjednodušší použít aplikaci Nokia PC Suite, která umožňuje jednoduchý přístup jak k datovému obsahu telefonu, tak paměťové karty (zařízení se nemusí k počítači ani připojovat kabelem, stačí zvolit bezdrátové připojení BlueTooth). Po samotné instalaci aplikace je nutné ještě provést základní nastavení (která jsou popsána v kapitole 3.10) pro správný běh programu (zdroj dat pro určení polohy a kontextu).
3.11.2 Windows Mobile Stejně jako u operačního systému Symbian stačí do mobilního zařízení nahrát soubory aplikace (CxNavi.jad a CxNavi.jar). Možností nahrání souborů je více – například zkopírování pomocí průzkumníka z počítače do mobilu či vystavení souborů na adresu, kterou je pak nutné otevřít pomocí Internet Exploreru ve Windows Mobile. V obou zmiňovaných případech se automaticky spustí Java prostředí, které se nejprve zeptá na instalaci aplikace a následně je možné program spustit. Stejně jako v případě operačního systému Symbian je nutné zkopírovat mapové podklady do kořenové složky paměťové karty.
34
4 Testování Během implementace byla aplikace testována v první řadě přímo v emulátoru (který je součástí vývojového prostředí), který sice umožňuje rychlé otestování funkčnosti, ale nesimuluje prostředí mobilního zařízení do všech detailů. Při prokázání správné funkce aplikace v emulátoru byla aplikace následně testována na skutečných mobilních zařízeních – převážně na mobilních telefonech Nokia N73 a E65.
4.1 Rozdíl mezi emulátorem a reálným prostředím Emulátor (rozhraní na obrázku 4.1) umožňuje rychlé otestování aplikace a zároveň je téměř nepostradatelným nástrojem při hledání chyb, protože pomocí něho je možné provést krokování aplikace, zastavení na předem definovaných bodech (breakpoints) a zjistit aktuálního hodnotu proměnných. Největším rozdílem mezi emulátorem a skutečným mobilním zařízením se ukázala rychlost provádění programu. Nešlo přitom jen o konstantní zrychlení/zpomalení všech částí rovnoměrně, ale velmi rozdílným způsobem. Problém s rychlostí se ukázal nejznatelněji při načítání mapy do 3D. V emulátoru trvalo samotné načtení i konstrukce 3D objektů zhruba stejný čas. V mobilním telefonu ale došlo k tomu, že konstrukce objektů trvala několikanásobně déle (při prvním testování, kdy byla zapnuta korekce zobrazení polygonů, se jednalo o desetinásobky). Aplikaci bylo tedy nutné optimalizovat a tvořit s ohledem na rychlost. Dalším rozdílem je bezpečnost. V emulátoru je totiž možné vypnout všechny dotazy na uživatele ohledně Obrázek 4.1 Rozhraní emulátoru povolení pro aplikaci (např. otevření souboru, zápis do souboru). V telefonu je tato možnost ale podporována pouze pro podepsané aplikace. Pokud by tedy aplikace například potřebovala ke svému běhu 100 otevření souboru, v emulátoru se problém neobjeví, ale v mobilním telefonu se bude operační systém 100x tázat uživatele, zdali povolí přístup k souboru. Funkce je splněna, ale prakticky je aplikace v tomto bodě nepoužitelná (pokud není podepsána a správně nastavena). 35
4.1.1 Připojení emulátoru k GPS modulu Aplikace obsahuje možnosti simulace polohy, aby bylo možné otestovat zobrazení mapy, navigační schopnosti atd. Lepší než simulace je ale k otestování lepší využití GPS modulu a skutečných dat. GPS modul, který je spárován s počítačem, je připojen k virtuálním sériovému portu, a stačí tedy použít jednoduchý „redirector“ (aplikace přeposílající data ze sériového portu na TCP port, zdrojový kód je na přiloženém CD). V aplikaci je nutné pro tento způsob získávání GPS dat nastavit zdroj dat „NMEA 0183“ a adresu GPS modulu „socket://127.0.0.1:port“, kde port představuje číslo TCP portu, na kterém čeká „redirector“.
4.2 Operační systémy 4.2.1 Symbian U operačního systému Symbian nebyly použity žádné nástroje, které by nějakým způsobem ulehčily testování, pouze k přenosu instalačních souborů byl využít balík Nokia PC Suite, který se dodává standardně s každým mobilním telefonem Nokia.
4.2.2 Windows Mobile K mobilnímu zařízení, které obsahuje operační systém Windows Mobile, je dodávána aplikace Microsoft ActiveSync, která zajišťuje spojení mezi počítačem a zařízením. Pomocí tohoto nástroje je možné velmi jednoduše nahrávat soubory (instalační soubory aplikace) a následně v zařízení vyvíjenou aplikaci testovat. Pro jednoduchost je možné pomocí spojení ActiveSync využít některý z programů na ovládání mobilního zařízení a ovládat tak vše pomocí počítače (s výhodou použití klasické klávesnice a myši), kdy se obrazovka zařízení (její obsah) zobrazuje v malém okně (které odpovídá rozlišení původního displeje). Při tvorbě této práce byl Obrázek 4.2 Aplikace spuštěná pod OS Windows Mobile použit software My Mobiler, které lze stáhnout (jde o volně šiřitelnou aplikace) z adresy http://www.mtux.com/ (instalaci do připojeného zařízení s OS Windows Mobile provede aplikace sama a lze jej bez problémů používat). Výhodou tohoto vzdáleného ovládání je také snadná tvorba screenshotů za účelem tvorby nápovědy, dokumentace či výsledků testování. Kromě samotného ovládání obsahuje My Mobiler také nástroj nazvaný Mobile Explorer, který je možné použít pro přenos souborů z/do mobilního zařízení.
36
4.3 Uživatelské rozhraní 4.3.1 Hlavní obrazovka aplikace Hlavní obrazovka byla testována na funkčnost správného vykreslení mapy a trasy k uživatelem definovanému cíli. Kromě toho bylo také ověřeno správné zobrazení aktuálních údajů a možnost změny zobrazení pomocí směrových kláves (přiblížení a oddálení) a uživatelské nabídky (změna natočení mapy). Aktuální trasa k vytyčenému cíli je vyznačena červenou barvou a v dolní části obrazovky je vzdálenost, která uživateli k cíli zbývá (spolu s odhadnutým časem, který je odvozen od vzdálenosti a aktuálního kontextu). Na mapě je vyznačena aktuální poloha uživatele červeným křížkem – ten označuje přesnou polohu určenou pomocí přijímače GPS. Modrý křížek pak symbolizuje bod na nejbližší ulici (či cestě) k aktuální poloze. Název této ulice je pak zobrazen pod mapou. Ulice, které jsou průjezdné pouze jedním směrem, jsou označeny černými šipkami ve směru možné jízdy. Barvou je vyznačen druh silnice, kdy bílá je běžná silnice a barevné pak symbolizují rychlejší druhy komunikace (motorová, dálnice atd.). V pravé dolní části je pak zobrazena aktuální rychlost a kontext uživatele (ať už je detekovaný automaticky nebo zvolen manuálně).
Obrázek 4.3 Ukázka hlavní obrazovky aplikace
4.3.2 Spořič obrazovky I přes využití funkce setLights (jejího periodické volání v samostatném vlákně) dle její dokumentace, která je zmíněna v kapitole 3.7.3, se nepodařilo u mobilních zařízení značky Nokia zamezit zobrazení spořiče obrazovky. Problém nastal i u základního smyslu funkce setLights – nastavení podsvícení. I v případě periodického volání setLights každých 5s docházelo k tomu, že podsvícení 37
telefonu chvílemi sláblo. Toto chování se dá vysvětlit tak, že následné volání setLights se stejnými parametry nemá účinek, dokud nepomine účinek prvního volání.
4.4 Detekce kontextu Rozlišování kontextu uživatele, tedy jestli jde pěšky nebo jede autem, bylo možné vyzkoušet pouze na telefonech s operačním systémem Symbian (konkrétně Nokia N73), kde bylo možné použít proxy aplikaci (instalační soubor WiiConnect.sisx je na přiloženém CD) pro připojení k ovladači WiiMote. Samotné rozlišování kontextu fungovalo spolehlivě ve všech testovaných situacích. V případě jízdy tramvají nebo metrem aplikace detekovala „auto (dopravní prostředek)“, což je správně, protože z hlediska akcelerace jde o ten samý pohyb. U telefonů, kde není možné detekci kontextu spustit, je možné aktuální kontext nastavit manuálně (šipkami vlevo/vpravo). Následuje několik ukázek detekce kontextu. Trasa je zobrazena v aplikaci Google Earth (11), kontext uživatele je odlišen barvou. Žlutá (světlá) barva značí chůzi, fialová (tmavá) značí dopravní prostředek (v těchto případech auto či tramvaj). V prvním případě (viz obrázek 4.4) zobrazuje záznam případ, kdy šel uživatel pěšky, pak jel chvíli autem a zbytek trasy šel opět pěšky (záznam pořízen na Praze 10).
Obrázek 4.4 Trasa v Google Earth (Praha 10) – uživatel šel část pěšky (žlutá barva), pak autem (fialová) a pak pokračoval opět pěšky (žlutá)
38
Druhá situace (viz obrázek 4.5) byla zaznamenána na Praze 5, kdy jde uživatel pěšky, nasedne do tramvaje (zastávka Anděl), o zastávku později vystoupí (zastávka Zborovská) a jde další část trasy pěšky.
Obraázek 4.5 Trasa v Google Earth (Praha 5) – uživatel šel pěšky (žlutá barva), uprostřed trasy se svezl jednu zastávku tramvají (fialová barva, ze stanice Anděl na stanici Zborovská)
Poslední záznam (viz obrázek 4.6) byl pořízen pouze za jízdy autem, kdy uprostřed záznamu došlo k nesprávnému určení kontextu vlivem nerovnosti silnice.
Obrázek 4.6 Trasa v Google Earth (Strakonická směrem na Prahu) – záznam jízdy autem, kdy uprostřed (žlutá barva) došlo k nesprávnému vyhodnocení kontextu vlivem nerovnosti silnice
39
Záznam trasy byl pro Google Earth připraven pomocí online utility GPS Visualizer (12), kde lze obarvit trasu uloženou v GPX souboru podle nadmořské výšky (která je nastavena podle zjištěného kontextu). GPX soubor (GPX je univerzální formát pro záznam GPS dat) byl vytvořen pomocí aplikace GPS Babel (13), která slouží pro převod mezi mnoha formáty (včetně GPX a textového souboru s hodnotami oddělenými tabulátorem), ale neumožňuje obarvení trasy podle nadmořské výšky.
4.5 Příklady použití 4.5.1 Standardní navigace k cíli Následuje příklad, jaké informace a údaje zobrazuje aplikace uživateli během navigace na vytyčený cíl. Při spuštění aplikace je nutné počkat, než je možné pomocí GPS modulu určit aktuální polohu (obrázek 4.7). Po určení polohy je zobrazena mapa (obrázek 4.8) s aktuální pozicí uživatele (červený křížek reprezentuje přesnou polohu získanou z GPS modulu, modrý křížek je pak nejbližší pozice na přilehlé cestě).
Obrázek 4.7 Aplikace zjišťuje aktuální polohu
Obrázek 4.8 Zobrazení aktuální polohy v mapě
Po načtení mapy uživatel zadá cíl své trasy (obrázky 4.9 a 4.10). Cíl se specifikuje výběrem ulice. Během postupného zadávání aplikace nabízí možné cíle a v případě, že požadovaná ulice je jako první v seznamu, může uživatel volbu potvrdit pomocí tlačítka „Vybrat“.
40
Obrázek 4.9 Výběr ulice
Obrázek 4.10 Výběr ulice, uživatel potvrdí svůj cíl
Po zadání cíle je vyhledána optimální trasa a je znázorněna červenou barvou v mapě (viz obrázky 4.11 a 4.12). Současně je zobrazena vzdálenost do cíle a odhadovaný čas nutný k přepravě do cíle.
Obrázek 4.11 Navigace během cesty (naklopení mapy kvůli vysoké rychlosti - v tomto případě jde o simulaci)
Obrázek 4.12 Navigace během cesty
41
4.5.2 Složitější scénáře Během testování byl simulován případ, kdy chodec a automobil mají větší část trasy stejnou a je tedy možné využít automobilu pro svezení chodce. Prvním krokem je zadání cíle navigace (screenshoty jsou z pohledu chodce, ne automobilu). Server na tento dotaz nabídne trasu (vzdálenost a čas), kterou může klient přijmout.
Obrázek 4.13 Pohled chodce před navigací (je vidět i druhý účastník)
Obrázek 4.14 Nabídka nalezené trasy ze serveru
Po přistoupení chodce do automobilu jedou pak oba společně až do místa výstupu. Během této části cesty se kontext chodce přepne na „automobil“ a funguje pro oba zúčastněné stejně (při sjetí z trasy dojde ke stejnému přepočítání trasy u obou).
Obrázek 4.15 Nastoupení chodce do automobilu
42
Obrázek 4.16 Blízko místa vystoupení chodce
Po vystoupení z automobilu se jejich cesty dělí a chodec musí zbytek do svého cíle dojít pěšky.
Obrázek 4.17 Chodec pokračuje po vystoupení dále ke svému cíli
43
4.6 Testované zařízení 4.6.1 Nokia N73 Během samotného vývoje byla aplikace testována převážně na mobilním telefonu Nokia N73. Telefon podporuje nutnou knihovnu M3G, která je nutná pro zobrazení mapy, a také Location API pro transparentní způsob zjišťování polohy. Bylo tedy možné vyzkoušet všechny možnosti aplikace. Nevýhodou je pomalé provádění Java bytecode, ale i přes tento problém byla výsledná aplikace ve všech směrech použitelná.
Obrázek 4.18 Nokia N73 s navigační aplikací
4.6.2 Asus P750 Pro účely testování aplikace byl zapůjčen také mobilní telefon Asus P750 s operačním systémem Windows Mobile 6 Professional. Zmíněný telefon bohužel nepodporuje ve výrobním nastavení M3G, které je nutné k zobrazení mapy, a navigace je tedy nepoužitelná. Aby nedošlo k výjimce a pádu celé aplikace, je před samotnou inicializací provedena kontrola na podporu M3G. Následuje screenshot (vlevo), jak vypadá aplikace po spuštění na zařízení, které neobsahuje podporu pro M3G. Dále je zobrazen výsledek analýzy programu „M3G Diagnostics“, který slouží k jednoduchému a spolehlivému otestování schopností zobrazování konkrétního zařízení (tato aplikace je dostupná například na adrese http://handheld.softpedia.com/get/Desktop-and-Shell/Development/M3GDiagnostics-72666.shtml).
44
Obrázek 4.19 Výsledek spuštění aplikace
Obrázek 4.20 Výsledek spuštění M3G Diagnostics
Kód na kontrolu, jestli mobilní zařízení podporuje M3G: try { Class.forName("javax.microedition.m3g.Graphics3D"); capableM3G = true; } catch (ClassNotFoundException ex) { capableM3G = false; }
U zmíněného zařízení (Asus P750) byla vyzkoušena i implementace Javy „IBM MIDP 2.0 Java Emulator 2.3“ (zařízení obsahuje z výroby nainstalovanou implementaci od společnosti Esmertec), nicméně výsledek, co se týká podpory M3G, byl stejný. Řešením by bylo implementovat ještě druhý typ zobrazování mapy a to 2D pomocí standardních vykreslovacích funkcí. Telefon (v případě předchozích dvou implementací) však nepodporuje ani přístup k souborovému systému, takže i v případě možnosti zobrazování by nebylo možné například ukládat uživatelská data na paměťovou kartu či vnitřní paměti telefonu (bylo by nutné využít RMS, které může být ale značně omezené, a mapové podklady mít jako součást midletu). String pimVersion = System.getProperty("microedition.pim.version"); if (pimVersion != null) { capableFileConnection = true; } else { capableFileConnection = false; }
Po otestování telefonu HTC Touch (dále v této práci), který podporuje M3G i přístup k souborům, byla vyzkoušena i implementace Javy (Intent MIDlet Manager, 45
instalační soubor Risidoro_Intent_MIDlet_Manager_11.1.7.1034.cab je na přiloženém CD) použité v telefonu HTC. Při spuštění pod touto implementací bylo možno používat jak M3G, tak i přístup k souborům. Aplikace obsahuje kontrolní obrazovku (na obrázku), kde je vypsaná přítomnost podpory všech nezbytných funkcí, informace o poslední chybě, kořenové složky úložiště mobilního zařízení atd.
Obrázek 4.21 Ladící informace aplikace
Telefon obsahuje interní modul GPS, který je připojen na portu COM2. Aplikace vytvořené v Javě se ale nemohou připojit přímo na sériový port a je nutné (podobně jako u ovladače WiiMote) použít proxy aplikaci. Zde jde čistě o přeposlání dat ze sériového portu na TCP port, který již je možné otevřít. Jako proxy byla použita aplikace Gps Port (soubor GpsPortPPC.exe je na přiloženém CD), která naslouchá při standardním nastavení na portu 20175 a při připojení na tento TCP port odesílá vše, co přijde na nastavený COM port (zde číslo 2). Navigační aplikace pak dostává zprávy v protokolu NMEA 0183, které dále zpracovává a používá pro určení polohy. Pro tento způsob připojení je nutné v nastavení aplikace nastavit zdroj dat pro určení polohy „NMEA 0183“ a URL GPS modulu na „socket://127.0.0.1:20175“.
46
Pro kontrolu stavu připojení k GPS modulu a celkového určení polohy je k dispozici zvláštní obrazovka. Obsahuje jak aktuální polohu, tak také v případě použití NMEA protokolu kvalitu signálu (0 – signál ze satelitu není dostupný, 1 – základní určení polohy, 2 – poloha byla určena a zpřesněna pomocí korekce DGPS) a několik posledních zpráv, které modul poslal.
4.6.3 HTC Touch
Obrázek 4.22 Ladící obrazovka určení polohy
Dalším testovaným telefonem s operačním systémem Windows Mobile byl HTC Touch. Na rozdíl od telefonu Asus P750, podporuje telefon (s implementací Javy, která byla nainstalována od výrobce) zobrazení pomocí M3G i umožňuje Java aplikacím přístup k souborovému systému a není tedy problém s načítáním map z paměťové karty či zápis naměřených dat.
47
48
5 Závěr Během práce byla navrhnuta a implementována navigační aplikace, která zpracovává údaje o aktuální poloze z GPS přijímače a rozpoznává kontext uživatele (jestli jde pěšky nebo jede autem). Data z GPS modulu jsou zjišťována dvěma způsoby: použitím abstraktní vrstvy Location API nebo přímým připojením k modulu pomocí protokolu NMEA 0183. Kontext uživatele je detekován na základě hodnot z akcelerometru, který je součástí ovladače (WiiMote) herní konzole Nintendo Wii. Tato funkce byla úspěšně ověřena během testování. Během tvorby práce nebyl k dispozici žádný mobilní telefon, který by akcelerometr obsahoval přímo, a nebylo tedy možné tento přístup vyzkoušet a použít. Data získaná pohybem uživatele jsou nahrávány zpět na navigační server, který pomocí těchto údajů zlepšuje statistiky průjezdnosti tras během různých časových intervalů. Na závěr byly vyzkoušeny případy složitějších navigačních scénářů, kdy chodec využívá auta jedoucího podobným směrem (například: chodec a automobil mají stejný výchozí bod, ale trasa chodce je delší – sveze se tedy autem až do takového místa, kde je to pro něj ještě výhodné a zbytek dojde pěšky). Cíle vytyčené na počátku této práce byly tedy splněny a aplikace se během testování ukázala jako funkční. Software však obsahuje několik komponent, jejichž vylepšení může být subjektem dalších prací (v některých případech to pravděpodobně ani není možné důsledkem absence některých klíčových komponent přímo v J2ME).
49
50
6 Budoucnost Aplikace vytvořená v rámci této práce byla implementována jako prototyp a není určena pro okamžitě komerční využití. Obsahuje řadu funkcí, které by bylo vhodné doplnit, případně vylepšit. U rozpoznávání kontextu byl v rámci práce dostupný pouze ovladač pro konzoli Wii a chybí tedy podpora akcelerometru obsaženého přímo v mobilním telefonu (těchto telefonů je na trhu čím dál více). Kromě toho je určování situace uživatele odvozeno pouze z údajů o zrychlení, což by šlo pravděpodobně zlepšit dalšími daty – například pomocí aktuální rychlosti (chodec se nikdy nebude pohybovat rychleji než cca 20 km/h) či typu silnice (na dálnici půjde většinou o automobil, v pěší zóně o chodce). Další hlavní funkce aplikace, tedy určování polohy, může být také vylepšena. Kromě podpory dalších zařízení (GPS modulů) implementací binárního protokolu SiRF jde především o použití některé z korekcí signálu, aby nedocházelo k nepřesným údajům a výpočtům. Jako největší problém a překážka do budoucna se jeví použití větších mapových podkladů. Jak již bylo zmíněno v kapitole 3.5.2, Java pro mobilní zařízení nepodporuje náhodný přístup k souboru. V této práci byl tento přístup emulován tak, že všechna mapová data se načetla do paměti. Toto pochopitelně není možné u větších souborů, protože paměť mobilního zařízení je značně omezena. Bude tedy nutné zjistit, jak tento nedostatek obejít, nebo počkat, zdali v některé z budoucích verzí Javy nebo podpůrných knihoven bude potřebná třída (RandomAccessFile) implementována. Další vylepšení a funkce je pak možné plánovat souběžně s úpravou navigačního serveru – zde je myšlena například plná podpora MHD, informování o aktuálních dopravních komplikacích (zvýšený stupeň provozu, nehody) atd.
51
52
7 Seznam literatury 1. Zahradník, Jakub. Kontextová inteligentní navigace - serverová podpora. Praha : ČVUT, 2009. 2. Global Positioning System. [Online] 12. 4 2009. http://www.gps.gov/. 3. Wii.com. [Online] 8. 5 2009. http://wii.com/. 4. Decimation-in-time (DIT) Radix-2 FFT. [Online] 10. 3 2009. http://cnx.rice.edu/content/m12016/latest/. 5. javax.microedition.location (JSR179 Location API for J2ME). [Online] 20. 2 2009. http://www.forum.nokia.com/document/Java_Developers_Library_v2/GUID4AEC8DAF-DDCC-4A30-B82023F2BA60EA52/javax/microedition/location/package-summary.html. 6. GPS a komunikační protokol NMEA - 3 (dekódování dat). [Online] 12. 4 2009. http://www.abclinuxu.cz/clanky/ruzne/gps-a-komunikacni-protokol-nmea-3dekodovani-dat. 7. Getting Started With the Mobile 3D Graphics API for J2ME (JSR 184). [Online] 12. 4 2009. http://developers.sun.com/mobility/apis/articles/3dgraphics/. 8. javax.microedition.m3g Class Hierarchy (Mobile 3D Graphics API (M3G)). [Online] 28. 2 2009. http://www.forum.nokia.com/document/Java_Developers_Library_v2/GUID07274ED2-697C-4987-ABE9-7FFE82605633/javax/microedition/m3g/packagetree.html. 9. Graphics3D (Mobile 3D Graphics API (M3G)). [Online] 24. 4 2009. http://www.cs.lth.se/EDA075/assignment1/jsr184-specification1.0/javax/microedition/m3g/Graphics3D.html. 10. DeviceControl (Nokia UI API). [Online] 12. 4 2009. http://www.forum.nokia.com/document/Java_Developers_Library_v2/GUID237420DE-CCBE-4A74-A129572E0708D428/com/nokia/mid/ui/DeviceControl.html#setLights(int,%20int). 11. Google Earth. [Online] 9. 5 2009. http://earth.google.com/. 12. GPS Visualizer. [Online] 9. 5 2009. http://www.gpsvisualizer.com/. 13. GPSBabel. [Online] 9. 5 2009. http://www.gpsbabel.org/.
53
54
8 Obsah přiloženého CD install/ - instalační soubory podpůrných aplikací src/ – zdrojové soubory aplikace text/ - text této práce v několika formátech readme.txt – základní informace
55
56
9 Přílohy 9.1 Ukázka NMEA 0183 Následuje krátký úsek dat, který obsahuje zprávy protokolu NMEA 0183 ve chvíli, kdy GPS modul dokázal určit polohu přijímače. $GPGSV,3,1,11,25,51,059,39,13,40,082,40,23,10,090,,16,04,024,*7A $GPGSV,3,2,11,07,72,081,29,08,58,204,18,10,42,302,,02,25,241,*76 $GPGSV,3,3,11,24,14,323,,04,10,206,,28,05,167,*46 $GPRMC,141731.633,V,,,,,,,170409,,,N*41 $GPGGA,141732.633,,,,,0,00,,,M,0.0,M,,0000*52 $GPGSA,A,1,,,,,,,,,,,,,,,*1E $GPGSV,3,1,11,25,51,059,39,13,40,082,40,23,10,090,,16,04,024,*7A $GPGSV,3,2,11,07,72,081,28,08,58,204,18,10,42,302,,02,25,241,*77 $GPGSV,3,3,11,24,14,323,,04,10,206,,28,05,167,*46 $GPRMC,141732.633,V,,,,,,,170409,,,N*42
Mezi předchozí a následující zprávou přijímač určil aktuální polohu $GPGGA,141733.633,5004.1640,N,01424.1776,E,1,03,6.2,166.1,M,45.5,M,,0000*5C $GPGSA,A,2,25,13,07,,,,,,,,,,6.3,6.2,1.0*31 $GPGSV,3,1,11,07,72,081,28,25,51,059,39,13,40,082,40,23,09,090,*76 $GPGSV,3,2,11,16,04,023,,08,58,204,18,10,42,302,,02,25,241,*74 $GPGSV,3,3,11,24,14,323,,04,10,206,,28,05,167,*46 $GPRMC,141733.633,A,5004.1640,N,01424.1776,E,0.24,332.95,170409,,,A*6E $GPGGA,141734.637,5004.1640,N,01424.1770,E,1,03,6.2,166.1,M,45.5,M,,0000*59 $GPGSA,A,2,25,13,07,,,,,,,,,,6.3,6.2,1.0*31 $GPGSV,3,1,11,07,72,081,28,25,51,059,39,13,40,082,40,23,09,090,*76 $GPGSV,3,2,11,16,04,023,,08,58,204,18,10,42,302,,02,25,241,*74 $GPGSV,3,3,11,24,14,323,,04,10,206,,28,05,167,*46 $GPRMC,141734.637,A,5004.1640,N,01424.1770,E,0.16,292.40,170409,,,A*69 $GPGGA,141735.637,5004.1639,N,01424.1765,E,1,03,6.2,166.1,M,45.5,M,,0000*52
57
