3. OKO - experimentální program pro nevidomé a slabozraké osoby v neznámém prostředí

Ing. Roman Berka, Praha


3.1 Úvod

3.1.1 Motivace

V průběhu několika posledních desetiletí prudce narůstají nároky moderní civilizace na člověka, který používá stále dokonalejší, ale o  to složitější technologii pro získávání informací, komunikaci nebo dopravu. Jedním z  problémů s  tím souvisejících je orientace v mnohdy složitých komplexech veřejných budov jako jsou letiště, nádraží, podzemní dráha nebo jiné prostory. Tento problém doléhá v podstatně větší míře právě na nevidomého člověka za situace, kdy se ocitá v neznámém prostředí a jeho snahou je zorientovat se v tomto prostředí tak, aby byl schopen se přesunout na nějaké požadované místo.

Z tohoto důvodu vznikla myšlenka navrhnout a vytvořit jednoduchý systém, který umožní “nacvičit” si předem pohyb v neznámém prostředí a naučit se v něm orientovat. Takový systém by pak mohl být k  dispozici k  soukromému užívání i na veřejných místech (kde by plnil úlohu informátora o  daném interiéru). Příslušná data by pak mohla být k  dispozici např. prostřednictvím sítě INTERNET.

Tato kapitola se zabývá problémy spojenými s  návrhem experimentální aplikace s  cílem zjistit účelnost výše popsaného systému. Text této a některých následujících kapitol je z  důvodu obsahové kompaktnosti v některých místech poněkud hlouběji odborně orientován na problematiku související s  výpočetní technikou. Čtenář, který není na tuto oblast svojí odborností zaměřen, může takové části přeskočit.

Koordinace práce probíhá ve spolupráci s  nevidomým panem Kučerou, kterému patří dík za nemalé podnětné myšlenky.

3.1.2 Požadavky na systém

Výše zmíněný systém je určen k  použití široké veřejnosti. Z tohoto důvodu a z  faktu, že jde o  výhradně nevidomé osoby, plynou následující požadavky:

 - 12 h - sever  - 3 h - východ  - 6 h - jih  - 9 h - západ

Systém by měl dále umožňovat využití různých dat popisujících různé scény. Tato data musí být snadno dosažitelná a musí existovat způsob, jak je jednoduše, rychle a levně vytvářet a přenášet prostřednictvím počítačových sítí.

Určování směru v časových údajích

Obrázek 3.1: Určování směru v časových údajích.

Vlastní aplikace s  níž uživatel bude pracovat musí umožnit komunikaci přes speciální periferní zařízení, která jsou určena pro nevidomé. Běžně používaná zařízení tohoto druhu nekladou žádné speciální požadavky na aplikaci, protože jejich ovladače předávají data na standardní vstup (zpravidla klávesnice) a odebírají data ze standardního výstupu, kde jsou dále transformována do zvukové podoby nebo do Braillova písma. Z toho plyne jediný požadavek, aby aplikace pro komunikaci používala standardní vstup i výstup, což je výhodné i z  hlediska vývoje a ladění.

3.2 Rozbor problému

Řešení problému je založeno na aplikaci, která bude komunikovat s  nevidomým a na jeho dotazy a povely mu poskytne informace o  prostředí, v němž se nachází a udá mu směr k  zadanému cíli. Tato aplikace může využívat data, popisující informaci o  geometrii a logické struktuře objektů ve scéně.

Při každém dotazu je potřeba nevidomému popsat a pojmenovat objekty, které se nacházejí před ním do určité vzdálenosti. Proto je nutné ukládat informace o  objektech v takové podobě, aby byly přímo použitelné pro výstup v přirozeném jazyce. Dále je nutné udat orientaci těchto objektů vzhledem k  pozorovateli (a to opět v časových údajích). Proto musí být každý objekt orientovaný nebo musí umožnit nějakým způsobem tuto orientaci určit.

Poslední důležitou informací je udat směr k  nejbližšímu bodu na cestě k  danému cíli. Proto je třeba uchovávat informace o  směru vedoucímu k  cíli, aby bylo možné kdykoliv najít požadovanou cestu. Systém by tedy neměl omezovat v pohybu po virtuální scéně a měl by umožnit uživateli seznámit se s  prostředím a naučit se v něm orientovat. Na druhé straně, program musí být schopen kdykoliv poradit, kterým směrem je možné se dostat na správné, místo popřípadě se vrátit na výchozí pozici. Z požadavku na návrat do výchozí pozice plyne i to, že musí být uchovány informace o  historii pohybu.

Pohyb ve scéně lze připodobnit k  procházení mapy vnitřku budovy nebo určité oblasti. Proto lze nahlížet na data popisující scénu jako na takovou mapu, v níž jsou jednotlivé objekty znázorněny symboly. Pak je celý problém převeden do 2D a radikálně zjednodušen. Zde zůstává pouze jediný nedostatek nastávající v případě přecházení z  jedné scény do druhé resp. z  jednoho poschodí vícepatrové budovy do jiného.

To však lze řešit pomocí událostí (kolize s  objektem dveře) a odkazy na příslušný soubor obsahující mapu další místnosti.

Pro vytváření map zřejmě musí existovat speciální aplikace, která bude generovat popis scény ve vhodném formátu. Speciální aplikace to musí být proto, že pohyb po scéně vyžaduje znalost logické struktury dat a to, bohužel, u  dat vyprodukovaných různými již existujícími systémy nemůže být zaručeno.

Na druhé straně aplikace určená pro generování jednoduchých map by neměla nahrazovat již existující programy na kreslení a měla by využívat jejich vlastností. Zde je tedy požadavek na minimální programátorskou práci.

Následující část textu se týká dostupných programátorských a aplikačních nástrojů, využitelných pro účely této práce. 3.2.1 Programové nástroje

Celý vlastní výukový program bylo nutno implementovat. Pro jeho realizaci se nabízela řada programovacích jazyků, z  nichž v úvahu přicházejí C a C++ vzhledem k  jejich rozšířenosti a dostupnosti na všech platformách. S ohledem na strukturu dat použitých k  popisu scény, byl zvolen jazyk C++.

Pro generování dat lze použít několik softwarových produktů z  oblasti CAD nebo i DTP. Jsou to AutoCAD firmy Autodesk, Corel Draw, Microstation a celá řada menších a levnějších kreslících programů. Aplikace, pro generování mapy, by měla být dostupná především na platformě PC. Dále je požadována jistá otevřenost použitého systému pro snadné přizpůsobení aplikaci a dalším požadavkem je rychle zvládnutelný a čitelný formát pro přenos dat mezi aplikacemi generující mapy a aplikací, která mapu používá.

Výše uvedené požadavky splňuje právě systém Auto CAD, který je dostatečně otevřený a je využíván velkým počtem organizací a firem. Proto byl použit tento CAD systém k  implementaci generátoru map.

Výběr Auto CADu souvisí také s  formátem dat, kterým je v tomto případě DXF (Drawing eXchange Format). DXF je poměrně dobře čitelný a strojově zpracovatelný. Strukturu tohoto formátu popisuje následující text.

DXF kód typ hodnoty význam
0 - 9 řetěz identifikace sekcí, jména entit, konce sekce
10 - 37 Real souřadnice
38, 39 Real zdvih a výška
40 - 59 Real měřítka a úhly

60 - 79

Integer

barva, počet, módy

80 - 209

 

nevyužito

210, 220, 230

Real

souřadnice směrových vektorů

999

řetěz

komentář

1000 - 1071

různé

rozšířená entita



Tabulka 3.1: DXF kód a jeho význam

3.2.2 Formát DXF DXF soubor je tvořen čtyřmi sekcemi: Každá sekce je tvořena posloupností textových položek, každá položka je zapsána ve dvou řádcích pod sebou. První řádek obsahuje tzv. DXF kód, kód skupiny (DXF group code) a druhý řádek pak hodnotu položky. První řádek identifikuje položku DXF souboru, druhý řádek je pak vlastní hodnota, interpretovaná podle typu DXF kódu. v [1] je uveden přehled kódů entit a tabulka DXF kódů. Syntakticky se DXF kód zapisuje na první tři pozice odprava formát FORTRANU 13), hodnota položky se zapisuje podle svého typu (text odleva, reálné hodnoty odleva, integer odprava (od 5. pozice)).

PŘÍKLAD:
0
LINE
8
ZIDKA
10
22.5

DXF kód identifikuje jednak typ položky a jednak její význam. V tabulce 3.1 je uvedena přehledně souvislost DXF kódu, typu a významu položky (podrobnější informace viz. [1]).

Entity, položky tabulek, oddělovače sekcí a konec souboru mají kód 0 následovaný jménem, které charakterizuje položku.

Díky podpoře bloků a jejich atributů je možné s  úspěchem využít této vlastnosti k  začlenění negrafických informací (slovní charakteristiky objektů) do DXF souboru v rámci jedné struktury dat.

3.3 Návrh řešení

Jak již bylo naznačeno v předchozím textu je řešení rozděleno do dvou podproblémů. První částí bude implementace aplikace CAD systému Auto CAD firmy Autodesk, Inc. a druhá část se týká nové aplikace (pracovně nazvané OKO) implementované v jazyce C++ určené k  vlastnímu tréninku. Mezi těmito aplikacemi budou data přenášená prostřednictvím DXF formátu.

3.3.1 Editor map

První ze jmenovaných aplikací je editor map. Systém AutoCAD nabízí několik vývojových nástrojů: AutoLISP (interpret jazyka LISP), vývojová prostředí ADS (AutoCAD Development Systém) a ARX (AutoCAD Runtime eXtension - od verze 13). Z hlediska rychlé přenositelnosti a s  přihlédnutím k  jednoduchosti aplikace byl použit AutoLISP.

Model Wilsonova nádraží: globální pohled

Obrázek 3.2: Model Wilsonova nádraží: globální pohled

Editor map má za úkol poskytnout prostředí pro tvorbu map použitelných tréninkovou aplikací OKO. Tento editor musí umožnit tvorbu map např. takových prostor jako je pražské hlavní nádraží. Obrázky 3.2 a 3.3 ukazují poměrně složitý model vstupní haly tohoto nádraží.Taková data by však byla velmi obtížně zpracovatelná pro daný účel, proto se v editoru pracuje pouze s  dvoudimenzionálními objekty. Model Wilsonova nádraží pak bude vypadat ve 2D jako půdorys na obr. 3.4.

UŽIVATELSKÝ POPIS

Při tvorbě mapy bude autor využívat prostředí návrhového systému Auto CAD. Aplikace napsaná v jazyce AutoLISP nemá pro vytváření map zcela zásadní význam, ale měla by urychlit práci při vkládání nejrůznějších objektů do mapy. Celý proces probíhá v následujících krocích. v první fázi si autor připraví grafické symboly, které bude používat v mapě jako překážky. Každý z  těchto symbolů musí být definován jako blok (BLOCK) v AutoCADu a každý takový blok musí obsahovat atributy definované podle předem daných pravidel (viz. 3.3.1). Takto připravená data jsou uložena do souboru, který je použit jako tzv. prototyp při vytváření každé nové mapy. Tento způsob umožňuje použít jednou nadefinované symboly vícekrát.

Model Wilsonova nádraží: detail


Obrázek 3.3: Model Wilsonova nádraží: detail.

Model Wilsonova nádraží: půdorys


Obrázek 3.4: Model Wilsonova nádraží: půdorys.

Aplikace v AutoLISPu se uplatní v okamžiku vkládání jednotlivých symbolů do mapy. Její činnost spočívá v tom, že po vytvoření prototypu na uživatelův příkaz appinit, projde databází všech nedefinovaných bloků a sestaví jejich soupis podle jmen, kterou pak použije pro sestavení nového menu. Po natažení prototypu do výkresu nové mapy se toto menu objeví na ovládací liště v prostředí AutoCADu. Toto menu je pak používáno pro vkládání objektů do mapy.

Po vytvoření mapy musí být vloženy informace o  tom, jak se dostat z  výchozího bodu na nějaké jiné místo. Jinými slovy autor navrhne trasy mezi význačnými body vytvořené mapy. Tyto trasy jsou na mapě znázorněny lomenými čarami a tak budou i uloženy jako speciální typ bloku (Toto je uživatelsky poněkud krkolomný způsob, neboť pro každou trasu je nutné definovat zvláštní blok. Naproti tomu je definice bloku v daném prostředí jediný způsob, jak sdružit grafickou informaci s  atributy, tedy negrafickou informací). Jednotlivé body lomené čáry pak slouží k  orientaci ve scéně. Příkladem takové cesty v mapě je obrázek 3.5. Po ukončení práce je soubor uložen do souboru ve formátu DXF.

Označování významných tras


Obrázek 3.5: Označování významných tras.

FUNKČNÍ POPIS

Implementace aplikace v AutoLISPu je založena na volání LISPových funkcí přímo z  prostředí AutoCADu. Skládá se ze dvou souborů: acad.lsp a exe.lsp.

Soubor acad.lsp obsahuje jedinou funkci STARTUP. Pro natažení aplikace je nutné, aby tento soubor byl přítomen v aktuálním adresáři. Jakmile je odtud AutoCAD spuštěn, proběhne kontrola, zda soubor acad.lsp existuje a v kladném případě je spuštěna funkce STARTUP, která provede nahraní funkcí obsažených v souboru eye.lsp.

Soubor eye.lsp obsahuje tři funkce. První z  nich create-item vytváří jednu položku menu. Druhá funkce, create-menu, slouží k  sestavení celého roletového menu z  názvů bloků a jeho začlenění do souboru jmeno.mnu, kde jmeno je název výkresu. Poslední funkce appinit aktivuje předchozí dvě funkce a vytvoří nové menu. Detailní informace je možné vyčíst přímo ze zdrojových kódů, které jsou součástí této práce.

K tomu, aby bylo možné zpracovávat DXF soubor navazujícím programem, je nutné při kreslení mapy dodržet jistá pravidla. Tato pravidla jsou popsána v následujícím textu.

PRAVIDLA PRO VYTVÁŘENÍ MAP v AUTOCADU

Mapa vytvořená pro aplikaci OKO popisuje zpravidla jednu místnost a je uložena v samostatném DXF souboru. Pokud je nutné obsáhnout více místností nebo je z  nějakého důvodu nutné rozdělit popis do více map, vznikne tzv. celek, který sdružuje více DXF souboru s  mapami, které jsou automaticky nahrávány např. při průchodu z  jedné místnosti do druhé. K tomuto slouží objekt typu ORTAL (viz. níže), který uchovává jména souborů obsahujících mapy obou sousedních místností. Každá taková místnost na mapě obsahuje symboly představující překážky rozmístěné po ploše.

Symbol překážky musí být definován jako blok ve smyslu programu AutoCAD s  atributy popsanými v dalším textu. Všechny ostatní informace , které nesplňují předepsaná kritéria, budou z  důvodu nejednoznačnosti ignorovány.

Při zpracování mapy se rozlišuje 6 typů bloků (překážek) podle charakteru nebezpečnosti kolize s  touto překážkou:

1. ACCESSIBLE - nejméně nebezpečná překážka,

2. PORTAL - dveře,

3. WALL - stěna, zábradlí, sloup,

4. OVERHEAD - překážka zavěšená nad hlavou,

5. HOLE - díra,

6. UNKNOWN - neznámá a tedy nejnebezpečnější překážka,

a 2 typy speciálních bloků

1. PATH - znázorňuje trasu,

2. DESCRIPTOR - charakterizuje místnost jako celek pomocí textového atributu.

Každý blok musí obsahovat, kromě své geometrické reprezentace, atributy. Všechny typy bloků mají definován atribut BLOCKTYPE udávající jeden z  osmi výše uvedených typů. Šest bloků reprezentujících překážky mají dále definovány atributy jméno (NAME - krátký název jednoznačný v rámci mapy, u  typu PORTAL jednoznačný v rámci všech map popisující celek) a kromě typu UNKNOWN, popis (DESCRIPTION - krátký jednořádkový popis objektu, který bude předáván uživateli během komunikace).

Typ PORTAL navíc definuje atributy udávající jméno DXF souboru s  aktuální mapou (atribut FILEIN) a jméno DXF souboru s  mapou sousední (atribut FILEOUT).

Typ PATH definuje atributy BLOCKTYPE, NAME a navíc dva atributy udávající jména cílových objektů (FROM, WHERE). Typ DESCRIPTOR musí být definován, ale není nutné jej do mapy vkládat. Vyznačuje se tím, že nemusí mít definovaná geometrická data. Jediný atribut BLOCKTYPE zde zcela výjimečně neobsahuje přímo popis typu, ale krátkou jednořádkovou informaci o  prostoru popisovaném mapou. Tato informace bude uživateli zobrazena vždy při vstupu do místnosti (tj. po nainicializování mapy).

Všechny výše popisované atributy jsou potřebné pro činnost navazující aplikace, a proto jsou povinné. Přehled těchto atributů a jejich přípustných hodnot je uveden v příloze A.

Po natažení nové mapy, je uživatel situován k  nějakému vstupnímu bloku. Proto každá mapa musí obsahovat alespoň jeden objekt typu PORTAL. Při umisťování a počáteční orientaci uživatele k  objektu PORTAL, je využito referenčních bodů atributů FILEIN a FILEOUT objektu typu PORTAL. Proto je tuto skutečnost nutné zohlednit při vytváření symbo lu pro tento typ objektů a umisťovat tyto atributy s  jejich referenčními body před a za objekt, jak je tomu na obrázku 3.6.

Umístění atributů FILEN a FILEOUT u  bloku typu PORTAL


Obrázek 3.6: Umístění atributů FILEN a FILEOUT u  bloku typu PORTAL.

Po iniciaci mapy je uživateli předána informace charakterizující prostor, v němž se nachází. Proto je nutné, aby každá mapa obsahovala definici bloku typu DESCRIPTOR, obsahující tuto informaci.

Posledním pravidlem je požadavek, aby každé dva symboly typu PORTAL, reprezentující stejné vstupní body (dveře) ve dvou sousedních místnostech, měli shodnou hodnotu atributu typu NAME.

3.3.2 OKO - procházení scény

Aplikace OKO slouží k  procházení mapy nevidomým uživatelem. v jistém smyslu jde o  aplikaci virtuální reality, kdy se uživatel seznamuje s  prostředím, aniž by se v něm musel přímo nacházet. Tato aplikace po spuštění musí nejprve načíst informace o  daném prostoru a to právě z  DXF souboru. Pak začíná komunikace mezi uživatelem a programem, kdy uživatel zadává jednoduché povely (viz. níže) a program na základě informací od uživatele a mapy vyhodnocuje jeho aktuální pozici a orientaci v prostoru.

UŽIVATELSKÝ POPIS

Po vstupu do scény dostane uživatel základní charakteristiku celého prostředí a přehled dosažitelných cílů. Uživatel bude mít možnost si nejprve vybrat jeden z  cílů. Pak začne celý proces, kdy uživatel komunikuje s  programem, končící na pokyn uživatele. Pro komunikace s  OKEM jsou k  dispozici tři druhy příkazů:

- krok <N>

krok 6 - posune model uživatele o  6 kroků aktuálním směrem

- otoc <N>

otoc 3 - natočí model uživatele na 3 hodiny, tj. o  90 o  ve směru hodinových ručiček

- zpet <N>

zpet 2 - vrátí stav o  dvě změny pozice nebo orientace uživatele zpět (implicitně je N = 1)

zpet vrátí stav o  jednu změnu pozice nebo orientace uživatele zpět

- ukaz - zobrazí informaci o  objektech v zorném poli

- vzdalenost [N]

vzdalenost 4 - nastaví vzdálenější hranici zorného pole na 4 kroky ( implicitně na 10)

vzdalenost - nastaví vzdálenější hranici zorného pole na 10 kroků

- skoncit - ukončí běh programu OKO

- ? - zobrazí tento seznam příkazů

Ze všech těchto příkazů bude uživatel potřebovat nejčastěji tři výkonné příkazy, což představuje únosnou mez náročnosti na ovládání. Příkazy, za nimiž je uveden parametr N v lomených závorkách < >, mají tento parametr povinný. Příkazy s  parametrem v hranatých závorkách [ ], mají tento parametr jako nepovinný. Parametr N je celé číslo, které v případě vzdáleností (příkazy krok, vzdalenost) udává počet kroků (délka kroku je nastavitelná). v případě příkazu otoc, jde o  azimut udávaný v časových jednotkách a příkaz zpět má jako parametr počet provedených příkazů, které se vrátí. Vnitřně jsou v programu délkové jednotky metry a úhly jsou počítány v obloukové míře.

Komunikace s  nevidomým probíhá následujícím způsobem: Uživatel zadá výkonný příkaz, kterým změní svoji polohu nebo orientaci. Program vyhodnotí novou pozici a otestuje, zda nedojde ke kolizi s  nějakou překážkou. Pokud je test kolize pozitivní, zareaguje program v závislosti na typu překážky a vydá výstražný signál podle stupně nebezpečnosti překážky. Při kolizi s  objekty typu WALL, HOLE, OVERHEAD a UNKNOWN, program nepovolí změnu pozice. Při kolizi s  typem PORTAL nastane přechod do sousední místnosti a tedy natažení nové mapy. A konečně při kolizi s  objektem typu ACCESSIBLE, je vydán výstražný signál, ale změna pozice je povolena. Po změně pozice nebo orientace je uživatel informován o  překážkách v jeho zorném poli. Tuto informaci je možné získat i příkazem ukaz. Navíc je zobrazena i informace o  směru k  nejbližšímu nezakrytému bodu na trase ke zvolenému cíli.

v dalším kroku se uživatel může vrátit příkazem zpět nebo pokračovat jedním z  výkonných příkazů. Celý dialog pak může být kdykoliv ukončen příkazem skoncit. Ukázka takového dialogu je v příloze A.

FUNKČNÍ POPIS Po implementace programu OKO, byl zvolen jazyk C++ především proto, že objektový přístup dobře odpovídá struktuře zpracovávaných dat. Celý program je rozdělen do 11 modulů. Zpravidla každý modul odpovídá definici třídy, jejíž metody řeší určitou část problematiky. Obrázek 3.7 znázorňuje strukturu modulů a jejich závislost, vyjádřené šipkami směřujícími vždy k  závislému modulu.

Struktura modulů


Obrázek 3.7: Struktura modulů

Na vrcholu celé struktury je modul typedefs, který definuje všechny pomocné datové typy. Modul chain definuje třídy chain-item a chain, které slouží pro práci s  dynamicky zřetězenými seznamy. Velkou část struktury představují moduly definující grafické struktury. Jsou to geometry s  třídou gr-object, která reprezentuje obecný grafický objekt a dále moduly line, circle, arc, polyline definující stejnojmenné třídy pro reprezentaci grafických elementů přímka, kružnice, oblouk a lomená čára.

Grafické elementy jsou využívány třídami path a block sdruženými v modulu block. Tyto třídy představují bloky – překážky, umísťované do mapy a trasy navržené mezi důležitými body na mapě.

Čárkovaně je vyznačen modul window, který zajišťuje kontrolní vykreslování pohybu uživatele ve scéně, pokud je aplikace přeložena pro systém X Window v operačním systému UNIX. Verze přeložené pod OS DOS nemají tuto vlastnost.

Modul user definuje třídy user reprezentující uživatele v scéně a historii, která spravuje evidenci provedených příkazů. Modul parser definuje stejnojmennou třídu představující správu map a zajišťující inicializaci nově nahrávaných map. Celou strukturu uzavírá hlavní modul eye.

Na tomto místě je třeba se podrobněji zmínit o  třídě user, která z  pohledu programu představuje uživatele. Ten je geometricky reprezentován kruhem o  průměru odpovídajícímu průměrné šířce ramen člověka. Jeho zorné pole je reprezentováno obdélníkovým pásem o  stejné šířce a nastavitelné délce, která udává vzdálenost, do jaké bude prozkoumáno okolí uživatele při prohledávání oblasti (viz. obrázek 3.8).

Reprezentace uživatele a jeho zorného pole


Obrázek 3.8: Reprezentace uživatele a jeho zorného pole

v době běhu programu existuje vždy jen jeden objekt typu user a jeden nebo více objektů typu block a path. Objekt typu user v cyklech přebírá příkazy od uživatele, vyhodnocuje je a formou zpráv je dále zasílá do datové struktury reprezentující celou scénu (viz. obrázek 3.9).

Objekty reprezentující scénu


Obrázek 3.9: Objekty reprezentující scénu


V celém programu je použito mnoho různých algoritmů, jejichž detailní popis by zde neměl význam. Všechny se ale v podstatě podílejí na řešení dvou základních problémů:
  • detekce kolize uživatele s  překážkami a jejich identifikace,
  • prohledávání zorného pole uživatele a identifikace objektů, která se v něm nacházejí.
 Převedení všech geometrických dat do 2D se pozitivně projevuje právě při řešení těchto dvou problémů, neboť dochází k  významnému zjednodušení všech výpočtů. Rovněž použití objektového přístupu zde představuje přínos z  hlediska formalizace. Objekty reprezentující grafické entity mohou disponovat jakousi vlastní identitou, neboť každý z  nich “ví” jakou konkrétní entitu v mapě představuje a např. na dotaz, zda koliduje s  danou přímkou, je schopen odpovědět kladně nebo záporně. Po zaslání dotazu do dynamicky zřetelného seznamu takových objektů (viz. obrázek 3.9) může být odpovědí seznam všech objektů, které s  danou přímkou kolidují. Oba výše zmíněné problémy jsou řešeny právě takovým způsobem.

3.4 Shrnutí

v tomto textu je prezentována implementace experimentálního systému pro nácvik pohybu nevidomého člověka v neznámém prostředí. Tento systém, tak jak je navržen by měl splnit základní požadavky na jednoduchost a tedy i přístupnost pro většinu potenciálních uživatelů. Implementace je v podstatě nezávislá na platformě, přesto se samozřejmě uvažuje zejména o  platformě PC. Je možno říci, že výpočetní nároky nejsou nijak vysoké vzhledem k  jednoduchosti algoritmů. Tyto nároky však rostou se složitostí map, a proto pak bude nutno počítat s  případným nasazením optimalizačních algoritmů redukujících počet zpracovávaných objektů scény. Výhledově je možné říci, že pokud by se ukázal takový systém jako užitečný, bylo by vhodné uvažovat o  vytvoření široce přístupné databáze s  mapami různých veřejně přístupných interiérů jako jsou stanice podzemní dráhy, nádraží, letiště, apod.



Příloha A
Doplňující informace k programu OKO

A.1 Pravidla popisu bloků a atributů

Následující tři tabulky shrnují pravidla pro vytváření bloků v programu AutoCAD tak, aby výsledný DXF soubor mohl být akceptován programem OKO.

Typ / vlastnosti Geometrie Měřítka v osách x a y Pozice Úhel natočení
PORTAL x x x x
OVERHEAD x x x x
HOLE x x x x
WALL x x x x
ACCESSIBLE x x x x
UNKNOWN x x x x
PATH x x x x
DESCRIPTOR - - - -


Tabulka A.1: Definice jednotlivých typů bloků

Typ / vlastnosti Označení typu Jméno objektu Stručný popis Jména souborů se soused. mapami Jména konc. objektů
PORTAL x x x x -
OVERHEAD x x x - -
HOLE x x x - -
WALL x x x - -
ACCESSIBLE x x x - -
UNKNOWN x x x - -
PATH x x x - -
DESCRIPTOR x - - - -


Tabulka A.2: Povinné atributy bloků

Atribut DXF označení Přípustná hodnota
typ bloku BLOCKTYPE viz. tabulky A.1, A.2
jméno bloku NAME řetězec
typ bloku DESCRIPTION řetězec
název souboru s mapou na vnitřní straně dveří FILEIN řetězec
název souboru s mapou na vnější straně dveří FILEOUT řetězec
jméno bloku na začátku trasy FROM řetězec
jméno bloku na konci trasy WHERE řetězec


Tabulka A.3: Přípustné hodnoty atributů


A.2 Ukázka dialogu uživatele s programem OKO

Po spuštění programu eye jmeno. dxf začne dialog následujícím způsobem:

Popis prostoru: nadrazni hala 100 x 100 kroku s vychody na jizni a zapadni strane.

Lokalizace: pata schodiste na severni strane haly.

Vyberte smer trasy stiskem cisla a klavesy ENTER, prosim.

0 jizni dvere

1 zapadni dvere

2 pokladna

3 WC

1 ENTER

prikaz: krok 30 ENTER

Pred vami jsou objekty:

trafika uprostred haly.

Smer k cili zapadni dvere: 2 hodiny.

prikaz: krok 20 ENTER

Zvukový signál.

Chyba kolize s objektem trafika uprostred haly.

prikaz: krok 19 ENTER

Pred vami jsou objekty:

trafika uprostred haly.

Smer k cili zapadni dvere: 3 hodiny.

prikaz: otoc 3 ENTER

Ve vasem zornem poli nejsou zadne objekty.

Smer k cili zapadni dvere: 12 hodin.

prikaz: krok 40 ENTER

Pred vami jsou objekty:

zapadni dvere vedouci na parkoviste.

Smer k cili zapadni dvere: 11 hodin.

prikaz: skonci ENTER

Dekuji za pouziti a nashledanou.

Následující obrázek dokumentuje předchozí dialog.
Postup uživatele ve scéně


Obrázek A.1: Postup uživatele ve scéně


PŘEDCHOZÍ KAPITOLA OBSAH  NÁSLEDUJÍCÍ KAPITOLA


[Domů  | Zpět]
Náměty a připomínky zasílejte na: web@braillnet.cz
Copyright © 1995 - 1999 SONS