Budapesti Műszaki és Gazdaságtudományi Egyetem Távközlési és Médiainformatikai Tanszék
Beszédkeltés mobil eszközökben Speech synthesis in mobile devices Diplomaterv 2005
Készítette: Tóth Bálint Pál villamosmérnök jelölt
Tanszéki konzulens: Dr. Németh Géza BME, Távközlési és Médiainformatikai Tanszék Ipari konzulensek: Kiss Géza, BME, Távközlési és Médiainformatikai Tanszék J. Prof. Andreas Rausch, TU Kaiserslautern
TARTALOMJEGYZÉK Összefoglaló .......................................................................................................................... 4 Abstract.................................................................................................................................. 5 1. Bevezető ............................................................................................................................ 6 2. Problémafelvetés ............................................................................................................... 7 3. A mesterséges beszédkeltés áttekintése a mobil eszközök szempontjából ....................... 9 3.1. Kötött szótáras szöveg-beszéd átalakító ................................................................... 10 3.2. Formánsszintetizátorok............................................................................................. 10 3.3. Diádos és triádos beszédszintetizátor ....................................................................... 11 3.4. Korpusz alapú szintetizátor ...................................................................................... 12 4. Mobil eszközök áttekintése ............................................................................................. 12 5. A Windows Mobile és a Symbian alapú mobil eszközök áttekintése ............................. 15 5.1. Windows Mobile (Windows CE) alapú rendszerek ................................................. 16 5.2. Symbian OS alapú rendszerek.................................................................................. 19 6. A Windows Mobile és a Symbian alapú mobil eszközök által felvetett problémák ....... 21 6.1. Felmerülő problémák a beszédszintézis szempontjából........................................... 23 6.2. Felmerülő problémák ember-gép kapcsolat szempontjából ..................................... 24 7. Beszédalkalmazás mobil eszközökre............................................................................... 26 7.1. Lehetséges felhasználói rétegek ............................................................................... 26 7.2. Lehetséges alkalmazások.......................................................................................... 28 8. Megvalósított rendszerek................................................................................................. 30 8.1. Rendszer beszédsérültek részére (első verzió, PDA) ............................................... 31 8.1.1. A rendszer célja ................................................................................................. 31 8.1.2. Problémafelvetés ............................................................................................... 32 8.1.3. A rendszer felépítése ......................................................................................... 39 8.1.4. A rendszer működése ........................................................................................ 44 8.1.5. A rendszer által felvetett problémák.................................................................. 51 8.1.6. Jövőbeli tervek................................................................................................... 54 8.2. Rendszer beszédsérültek részére (második verzió, PDA és Smartphone)................ 54 8.2.1. A rendszer célja ................................................................................................. 54 8.2.2. Problémafelvetés ............................................................................................... 55 8.2.3. A rendszer felépítése ......................................................................................... 55 8.2.4. A rendszer működése ........................................................................................ 57 2
8.2.5. A rendszer által felvetett problémák.................................................................. 59 8.2.6. Jövőbeli tervek................................................................................................... 60 8.3. Rendszer beszéd- és/vagy hallássérültek részére (Laptop, Tablet PC, asztali PC) .. 60 8.3.1. A rendszer célja ................................................................................................. 61 8.3.2. Problémafelvetés ............................................................................................... 61 8.3.3. A rendszer felépítése ......................................................................................... 62 8.3.4. A rendszer működése ........................................................................................ 63 8.3.5. A rendszer által felvetett problémák.................................................................. 65 8.3.6. Jövőbeli tervek................................................................................................... 66 8.4. Pulzus érték kijelző grafikai és beszéd kimenetekkel (Windows Mobile, Symbian OS)................................................................................................................................... 66 8.4.1. A rendszer célja ................................................................................................. 68 8.4.2. Problémafelvetés ............................................................................................... 68 8.4.3. A rendszer felépítése ......................................................................................... 69 8.4.4. A rendszer működése ........................................................................................ 72 8.4.5. A rendszer által felvetett problémák.................................................................. 75 8.4.6. Jövőbeli tervek................................................................................................... 78 8.5. Kísérlet ..................................................................................................................... 78 8.5.1. A kísérlet célja ................................................................................................... 79 8.5.2. A kísérlet részei ................................................................................................. 79 8.5.3. A mérési környezet............................................................................................ 82 8.5.4. A mérő alkalmazás ............................................................................................ 83 9. Eredmények ..................................................................................................................... 85 10. Jövőbeli tervek............................................................................................................... 86 11. Összefoglalás ................................................................................................................. 86 12. Köszönetnyilvánítás ...................................................................................................... 87 Irodalomjegyzék .................................................................................................................. 88
3
Összefoglaló Napjainkban egyre nagyobb a mobil eszközök, a mobiltelefonok népszerűsége. A telefonáláson túl a mai „okostelefonokkal” internetezhetünk, fényképezhetünk, zenét hallgathatunk, játszhatunk; a lehetőségek száma szinte végtelen. A telefonokon kívül léteznek más mobil készülékek is (pl. PDA), melyek egyszerűbbé próbálják tenni mindennapi életünket. A legtöbb feladat már nem speciális eszközökkel, hanem általános célú hardverre készült szoftverekkel oldható meg. Azonban a nem megfelelően megtervezett és kidolgozott rendszerek a mobil eszközök korlátozott teljesítménye, szövegbeviteli
módja,
képernyőmérete
és
multimédiás
szolgáltatásai
miatt
használhatatlanok lesznek. Diplomamunkám célja, hogy bemutassa a legújabb „okos” mobil eszközöket, megvizsgálja előnyeiket és hibáikat mesterséges beszédkeltés és embergép kapcsolat szempontjából, továbbá lehetséges megoldásokat kínáljon a problémákra kutatásaim és fejlesztéseim mintáin át. Dolgozatomban két nagyobb rendszert ismertetek. Az első beszédsérült emberek számára kínál kommunikációs segítséget szemtől szembeni és telefonos beszélgetésekhez okostelefon, személyi digitális asszisztens (Personal Digital Assistant, PDA) és asztali számítógép platformokon. Így a beszédsérült ember kiválaszthatja a számára legalkalmasabb változatot egy-egy feladat megoldásához (pl. bevásárlás, banki ügyintézés, telefonos beszélgetés a barátokkal, stb.). Megvizsgálom a korábbi, hasonló célú eszközöket, és az új rendszer szükséges szolgáltatásait a korábbi eszközök tulajdonságai és a célplatform sajátosságai alapján tervezem meg. A beszédképesség hiánya mellett sokszor egyéb problémákkal is küzdenek a célfelhasználók (pl. koordinációs zavarok, rossz látás, stb.), így a rendszert számukra is használhatóvá kellett tennem. A diplomamunkámban bemutatásra kerülő második rendszer a német-magyar BelAmi együttműködés keretein belül készült. A BelAmi kutatásainak és fejlesztéseinek a részét képző, professzionális biciklisták felügyelt edzését megvalósító kutatási és fejlesztési munkán belül a beszédkimenet interfész mobil eszközökön való megvalósítása volt a feladatom. Dolgozatomban bemutatom a rendszert, ezen belül ismertetem a beszédkimenet fontosságát és a felmerülő problémákat. A kutatás részeként egy kísérletet is előkészítettem, melyre az elkövetkező hónapban kerül sor. A korábbi és a saját rendszerek, a felmerülő problémák és a lehetséges megoldások ismertetésén túl dolgozatomban jövőbeli terveimre is kitérek.
4
Abstract Recently mobile devices are more and more popular. Cellular phones comprise the largest market share of mobile devices and have overgrown their standard role. We use our smartphones beyond telephony for surfing on the net, making pictures, listening to music, playing, etc. Apart from cell phones other mobile devices also help our everyday life, e.g. personal digital assistants (PDA). Nowadays most of the mobile solutions are software developments for general hardware, and not application specific devices. But inappropriate design and development (not taking into account the display size, the input method, the performance and the multimedia services of the mobile device) can result in useless systems. The goal of my master's thesis is to introduce the latest smart mobile devices, investigate their advantages and disadvantages in the aspect of speech synthesis and human-machine interaction, and to give possible solutions through presenting examples of my research and development work. In the thesis I introduce mainly two systems. The first one is a communicational aid platform for speech impaired people for face-to-face and telephone conversations. The system exists on smartphones, PDAs and desktop computers. Consequently speech impaired people can choose the best solution for their actual purpose (e.g. shopping, business, talking with friends on the phone, etc.). I investigate previous systems, and according to their attributes and the properties of the actual computer platform I design the necessary and additional services of the new system. In many cases speech impaired people have other difficulties also (e.g. co-ordination problems, impaired vision), thus the system must be able to adapt to their needs as well. The other system, which is introduced in my diploma thesis, is a part of a project, which is designed and supervised by the BelAmi German-Hungarian research cooperation. The project aims the assisted training of professional bicyclists; my part was to develop speech output interfaces on mobile clients. In the current paper I introduce the system, the necessity of speech output, and the related problems. As a part of the research I have prepared with the German colleagues an experiment based on the idea of Dr. Géza Németh. The purpose of the experiment is to investigate the perception of text-to-speech systems under physical load. Apart from the investigation of the systems, the problems and the solutions, I also introduce my future plans in my master's thesis.
5
1. Bevezető Közel egy évtizeddel ezelőtt még különleges dolognak számított, ha valaki az autójából telefonált, vagy ha egy zsebszótár méretű készüléken szöveget tudott szerkeszteni. Ma már ezek a technológiák elavultak, tíz év alatt megváltozott a hordozható eszközök világa, és az általuk kínált lehetőségek. Már nem meglepő, ha mobil eszközünkkel lekérdezzük az aktuális pozíciónkat, a beépített böngésző programmal az interneten keresztül megkeressük a hozzánk legközelebb eső szállodát, amit rögtön fel is hívunk. Természetesen még rengeteg példával lehetne illusztrálni, hogy milyen sok területen jelenthetnek könnyebbséget, segíthetnek a zsebben hordozható mobil készülékek. Azonban számos kérdést is felvetnek a mobil eszközök. Sokszor kerülünk olyan szituációba, amikor nem tudjuk figyelemmel követni a készülék képernyőjén megjelenő jelzéseket, riasztásokat (pl. vezetés, kerékpározás, autószerelés közben). Gondolnunk kell a fogyatékkal élő emberekre is. Számukra a jelen és jövő telekommunikációs technológiái új lehetőségeket jelenthetnek életük minőségének javításában, abban az esetben viszont, ha kényszerűen kimaradnak a fejlődésből, igen hátrányos helyzetbe kerülhetnek. Fontosnak tartom, hogy a fogyatékos emberek életszínvonalát javítsák a rendelkezésre álló mobil eszközök, továbbá hogy a fogyatékok nélkül élő embereknek könnyebb és kényelmesebben legyen a már sokak életének részét képző mobil készülékek használata. A mobil világ számos területe még nincs megfelelően kidolgozva, a legtöbb még sok kutatói és fejlesztői munkát kíván. Diplomamunkámban az ember-gép kapcsolat és a mesterséges beszédkeltés szempontjából vizsgálom meg korunk mobil eszközeit. A bevezető után a második fejezetben elemzem a mobil készülékekkel kapcsolatosan felmerülő problémákat, majd a harmadik fejezetben a legfontosabb mesterséges beszédkeltési (Text-To-Speech, TTS) technológiákat ismertetem vázlatosan, és megvizsgálom azokat a mobil eszközök szempontjából. A negyedik fejezetben röviden bemutatom a mobil eszközök történelmét, majd a következő fejezetben rátérek korunk „okostelefonjainak” Európában legelterjedtebb két operációs rendszerére, a Symbian OS-re és a Windows Mobile-ra. Bemutatom mindkét rendszert és ismertetem alapvető felépítésüket. A hatodik fejezetben megvizsgálom a két platform hátrányait, hiányosságait, melyeket kutatási és fejlesztési munkám során le kellett küzdenem, továbbá kiemelem az ember-gép kapcsolat és a mesterséges beszédkeltés által felvetett problémákat. A hetedik
6
fejezetben megvizsgálom a lehetséges felhasználói rétegeket, és példával illusztrálom, hogy az egyes felhasználói csoportok számára milyen alkalmazások lehetnek előnyösek. A nyolcadik fejezetben ismertetem kutatási és fejlesztési munkáim, a velük kapcsolatos problémákat és a lehetséges megoldásokat. Az elmúlt években két fő részre osztható munkám: az egyik terület a beszédsérült emberek számára készült kommunikációs segédeszközökkel, a másik pedig professzionális biciklisták edzését segítő rendszerben a beszédkimenet integrációjával foglalkozik. Az első témával a nyolcadik fejezet első három alfejezetében, a másodikkal az utolsó kettőben foglalkozom. Dolgozatom végén röviden összefoglalom az elért eredményeket és kitérek jövőbeli terveimre.
2. Problémafelvetés A számítástechnika és a távközlés világában korábban soha nem látott sebességgel fejlődnek, jelennek meg az új technológiák és szolgáltatások, megváltoztatva ezzel az emberek mindennapi életét. Az új technológiák olyan tudományoknak is utat nyitottak, melyek elméletének megvalósítása korábban nem, vagy csak hatalmas költségek árán volt lehetséges. A speciális hardvereket részben felváltották a számítógépen és egyéb eszközökön futó szoftvermegoldások, melyeknek köszönhetően jelentősen csökkentek a költségek. A fejlődés a távközlést is elérte. Egyrészt az Internet meghódította a világot, másrészt pedig megjelentek a mobiltelefonok. Kezdetben magas áruk és nagy méretük miatt még nem volt megjósolható, hogy néhány éven belül túl fogják szárnyalni a vezetékes telefonok elterjedtségét. A mobil eszközök is jelentősen átalakultak a kezdetek óta: korábban fekete-fehér kijelzőjük volt és csupán telefonálni lehetett velük. Később megjelent a szöveges üzenetküldés lehetősége (Short Message Service, SMS), melyet számos új technológia követett (felhasználói profilok, határidőnapló, diktafon, stb.). Ma már nem meglepő, ha mobil eszközünkkel internetezünk, fényképezünk, játszunk vele, vagy előre eltárolt zenét, illetve valamelyik rádióadó műsorát hallgatjuk rajta. Vizsgáljuk meg röviden a legújabb, harmadik generációs mobiltelefonok alapvető tulajdonságait. Az új készülékek minimum 80-90 órányi készenléti, és 6-8 órányi beszélgetési idővel rendelkeznek, emellett 400 Mhz-en átlagosan 200-300 MIPS-re
7
(Million Instructions Per Second, millió művelet másodpercenként) képesek.1 Képernyő méretük igen változó, az átlagos legkisebb képernyők2 27.3 mm x 27.3 mm, az átlagos legnagyobb képernyők3 pedig 57 mm x 76 mm nagyságúak és általában 16 bites színmélységet támogatnak, azaz 65536 színt tudnak megjeleníteni. A mobil eszközök sebességének köszönhetően olyan bonyolult számítási műveletek is implementálhatóak, melyekre korábban csak a személyi számítógépen volt lehetőség (pl. szöveg-beszéd átalakítás), továbbá a nagy kijelzőnek és a különböző adatbeviteli módoknak (gombok, érintőképernyő, hang) köszönhetően megfelelő tervezéssel intuitíven használható embergép kapcsolat (Human Computer Interaction, HCI) hozható létre. Fontos odafigyelni a mobil eszközök sajátosságaiból adódó megkötésekre is, melyek a korábban említett méret- és teljesítménybeli tulajdonságaikból fakadnak. Új alkalmazások tervezésénél szem előtt kell tartani a mérsékelt számítási kapacitás miatti késleltetéseket, a lassú működést, a képernyő méretéből adódó határokat és a személyi számítógép adatbeviteli eszközeihez viszonyítva lassú adatbevitelt is. Lényeges figyelembe venni, hogy a számítógépen működő alkalmazásokat nem lehet egy az egyben a mobil eszközre implementálni, hiszen így sokszor kezelhetetlenné válik az eredetileg könnyen használható alkalmazás. Nem létezik pontos útmutatás, szabvány arra vonatkozóan, hogyan lehet jól és intuitív módon használható programot készíteni mobil eszközökre – nem is létezhet, hiszen minden programnak más a célja, más a felhasználói célcsoportja, így a megvalósításnak is különbözni kell. Egyes gyártók megadnak a felhasználói felületre vonatkozó ajánlásokat, azonban mivel ezek a mobil piac csupán egy kis részére érvényesek, ezért nem jelentenek általános megoldást. Általános megoldás nem is létezik, azonban néhány szabályt érdemes mindig betartani: 1. Használjunk minél kevesebb grafikai elemet, és ezeket induláskor töltsük be, hogy ne futási időben lassítsa a rendszer működését. 2. Amennyire lehet, kerüljük a számításigényes algoritmusokat (pl. lebegőpontos számítások, iteratív eljárások, stb.) 3. Legyen egyszerű a felhasználó felület, minimalizáljuk a menük és a menüpontok számát. 1
DSPs for next-generation cell phones balance performance and power, forrás: http://www.edn.com/article/CA54568.html 2 Nokia 6230 készülék 3 iPAQ h5550 készülék
8
4. A rendszer használatához minél kevesebbet kelljen a felhasználónak adatbeviteli módszereket alkalmaznia, illetve egyazon esemény (pl. jobbra gomb lenyomása) többszöri bekövetkezésének esetén érdemes más és más funkciókat biztosítani.
3. A mesterséges beszédkeltés áttekintése a mobil eszközök szempontjából A mesterséges beszédkeltés kezdete Kempelen Farkas nevéhez fűződik, aki elméletét és elméletének igazolására szolgáló mechanikus beszélőgép (1. ábra) elkészítésének részleteit 1791-ben megjelent könyvében ismerteti [1]. Az első elektronikus beszélőgépet Homer Dudley 1939-ben, a Bell Laboratóriumban készítette. A következő nagy előrelépést az integrált áramkörök megjelenése jelentette, ettől kezdve sokkal kisebb méretben tudtak beszédkeltőket előállítani és egyben jobb minőséget nyújtani.
1. ábra - Kempelen Farkas beszélőgépe
A számítógépek megjelenésével lehetőség nyílt arra, hogy a drága, speciális eszközök
helyett
a
mesterséges
beszédkeltési
algoritmusokat
a
számítógépen
implementálják. A mobil eszközök fejlődésének köszönhetően ma már nem jelent különösebb problémát a készülékeken szintetizált beszéd megszólaltatása sem, azonban az aktuális rendszer szempontjából a legmegfelelőbbet kell több szöveg-beszéd átalakítási technológia közül a tervezés folyamán kiválasztanunk. Dolgozatomban a jelenleg legjelentősebb négy technológiát vizsgálom meg.
9
3.1. Kötött szótáras szöveg-beszéd átalakító A kötött szótáras szöveg-beszéd átalakító előre meghatározott szöveget képes felolvasni. Ilyen rendszer lehet például a számfelolvasó, a banki rendszerek vagy például a vasúti pályaudvaron a „bemondó”. A kötött szótáras szövegfelolvasó előre eltárolt egységekből (gyakran szavakból vagy nagyobb egységekből) rakja összes a kívánt mondatot. Azonban egy ilyen rendszer elkészítése nem egyszerű feladat. A legtöbb nehézséget a szavakat, mondatrészeket, mondatokat tartalmazó adatbázis elkészítése jelenti. Az adatbázis építése során számos problémát kell leküzdenünk, vizsgáljuk meg a legjelentősebbeket: 1. Fontos tartani a megfelelő prozódiát. Amennyiben például egy szó mondatkezdő helyen található, a szónak prozódia szempontjából is meg kell felelnie a mondatban elfoglalt kezdőhelyével. 2. Fontos, hogy az adatbázisban tárolt hanganyag hangereje azonos legyen. 3. A hanganyag felvétele során professzionális bemondók esetén is számolnunk kell azzal, hogy néhány óra folyamatos beszéd után a beszélőnek megváltozik a hangszíne. E hangszínbeli változás jelentősen csökkentheti a kötött szótáras szöveg-beszéd átalakító minőségét. Mobil eszközök szempontjából nem kell számolnunk jelentős teljesítménybeli problémákkal, azonban a tárkapacitásra fontos odafigyelnünk, hiszen egy több száz elemből álló adatbázis mérete több tíz megabájt is lehet, mely jelenleg a legtöbb mobil eszköz esetén kritikus korlát. A rendszer számára szükséges hely csökkentése érdekében érdemes a hanganyagot tömörített formában tárolni. Tömörítés esetén azonban szem előtt kell tartani, hogy minél bonyolultabb algoritmust használunk, annál több időt fog a lejátszás során a kitömörítés igénybe venni. Érdemes továbbá figyelembe venni a mobil eszköz hardver specifikációit, hogy milyen minőségben képes hangot megszólaltatni; ennél a minőségnél jobbat nem érdemes a hangadatbázisban tárolni.
3.2. Formánsszintetizátorok A formánsszintetizátorok a beszédet fizikailag modellezik formánsai alapján. Formánsnak
nevezzük
a
beszéd–spektrum
burkolójának
maximumait
[2a].
A
10
formánsszintetizátorok nagy előnye, hogy hangminták nélkül működnek, így helyigényük minimális, mely meghatározó a mobil eszközök szempontjából. További előnyük, hogy a beszédhang sebességét bármekkorára növelhetjük, ameddig az ember fel tudja dolgozni a hallottakat, a beszéd érthető marad. Ezen tulajdonság igen fontos például a látássérült emberek számára készült programok esetén, hiszen ezeknek az embereknek fontos, hogy minél gyorsabban hallhassák az információt, amit a látó emberek elolvasnak. Esetenként a látássérültek háromszor, négyszer gyorsabb beszédet is megértenek, mint amihez a látók füle hozzászokott, így a formánsszintetizátorok jó megoldást jelenthetnek számukra. Előnyt jelent a formánsszintetizátorok esetén, hogy a hangot meg lehet változtatni, így az egyéni preferenciáknak megfelelőre lehet szabni. Ezeknek a rendszereknek a hátránya, hogy nem természetes, robotszerű hangjuk van.
3.3. Diádos és triádos beszédszintetizátor A diádos és triádos beszédszintetizátorok adatbázisban tárolt, az adott nyelvhez tartozó két vagy három hang kapcsolódását tartalmazó, ún. diádokból / triádokból [2b] készítik el a felolvasandó szöveghez tartozó hullámformát. Az adatbázis tartalmazza az adott nyelvhez tartozó összes diádot / triádot, melyeket futásidőben illeszt egymáshoz, és valamilyen digitális jelfeldolgozási technikával előre meghatározott szabályok alapján helyezi rá a prozódiát. A diádos és triádos beszédszintetizátorok hangja a formánszintetizátoroknál sokkal természetesebb, azonban a hozzá tartozó adatbázis nyelvétől, a megkülönböztetett hangok számától és a hangminták minőségétől függően több tíz megabájtot is elfoglalhat.4 További problémát jelent, hogy a beszédet csak gondos tervezés mellett lehet egy bizonyos fokig gyorsítani, és minden beszédhanghoz külön adatbázist kell készítenünk. A Profivox magyar szöveg-beszéd átalakító esetén a 11 kHz-es, 8 bites diádos adatbázis 3.4 megabájtot foglal el, A-law kódolással tárolva az emberi fül számára szinte egyforma jó minőséget kapunk 1.7 megabájton. A mai modern mobil eszközök bőven rendelkeznek ekkora tárkapacitással, azonban a többnyelvűség csak bizonyos fokig megoldható a mobil eszközön a helyigény miatt. Alternatív megoldásként a beszédszintézist elvégezhetjük egy Internetre kapcsolódó szerveren, és onnan valamelyik rendelkezésre álló adatkapcsolaton (GPRS, EDGE, WiFi, stb.) keresztül a szintetizált szöveget lekérve, bufferelve játszhatjuk le a mobil kliensen (lásd 8.2. fejezet). Előnyt 4
A spanyol nyelv kb. 800, a magyar kb. 1400, a német pedig kb. 2500 diádot tartalmaz.
11
jelent, hogy a mobil eszközök hangkimenete rontja a telefonos beszéd minőségét, így a diádos és triádos beszédszintetizátorok hangja mobilkészülékeken sokszor megközelíti a természetes beszédhang minőségét.
3.4. Korpusz alapú szintetizátor A korpusz alapú szöveg-beszéd átalakító rendszerek [3] hatalmas adatbázist használnak. A tervezés során akár több tíz órányi hanganyagot is felvesznek, melyet a legkisebb egységtől a legnagyobbig (fonéma, szótag, morféma, szó, mondatrész, mondat) indexelt adatbázisba rendeznek. Futásidőben az adatbázis elemeihez tartozó címkék alapján bonyolult algoritmus dönti el, hogy mely elemekből építse fel a mondatokat. Fontos, hogy ezen technológia próbálja a digitális jelfeldolgozást minimalizálni annak érdekében, hogy a természetességet minél jobban megőrizze. Jelenleg a korpusz alapú rendszerek minősége közelíti meg legjobban a természetes beszédet. A korpusz alapú rendszerek hangkarakterisztikáját és beszédsebességét nem lehet változtatni, továbbá adatbázisuk akár több gigabájtos is lehet, így mobil eszközökön való helyi futtatásuk egyelőre lehetetlen.5 Alternatív megoldásként alkalmazható az előző pontban felvázolt szöveg-beszéd átalakítás szerverre való áthelyezése.
4. Mobil eszközök áttekintése A mobil eszközök az elmúlt évtizedekben jelentős fejlődésen mentek keresztül, mely elsősorban a nagy iramban növekedő mobiltelefon piacnak köszönhető. A mobil eszközök történelmének kezdete a 70-es évekre tehető; a szövegszerkesztő (word processor) számítógépek voltak az első „hordozható” készülékek. Természetesen ezek esetében nem a mai értelemben vett hordozhatóságról volt szó; 6-8 inches CRT monitorral ellátott táska, néha bőrönd méretű eszközök voltak, azonban korukban forradalminak számítottak. Az első ilyen gépek közé tartozott az IBM gyár Mag-Card Selectric készüléke, melynek egysoros LCD kijelzőjén lehetett a kinyomtatandó szöveget szerkeszteni. A korai 70-es években a Lexitron és Vydec piacra bocsátotta a CRT képernyős szövegszerkesztő rendszerét, de az igazi áttörést a Jef Raskin által tervezett Canon Cat (2. ábra) hozta meg.6 5
Természetesen már léteznek memóriakártyák, melyek több gigabájt tárkapacitást is képesek biztosítani a mobil eszközökön, azonban egy általános célú alkalmazást nehéz úgy terjeszteni, hogy futásához a programon kívül drága hardver elemeket is vásárolni kell. 6 Information appliance, forrás: http://en.wikipedia.org/wiki/Information_appliance
12
A mobil eszközök történelmében a következő lépést a laptop számítógépek megjelenése jelentette. Pontosan nehéz meghatározni, hogy mely eszköz tartozik már a laptop kategóriába, de számos forrás az Epson HX-20 készüléket (2. ábra) jelöli meg az első laptopnak. Azóta a laptop számítógépek hosszú utat jártak be, méretük egyre csökkent, kapacitásuk, teljesítményük egyre nőtt, és készenléti idejük egyre hosszabb lett. Napjainkban már nem számítanak ritkaságnak a 2-3 kilogrammos, érintés-érzékeny, TFT képernyős, akár 6-8 óra hosszan is működő hordozható számítógépek.
2. ábra - Canon Cat (bal), Epson HX-20 (jobb)
A mai értelemben vett, párszáz grammos, notesz méretű mobil eszközök kezdete a 80-as évekre tehető. 1980 júliusában jelent meg a Radio Shack Pocket Computer PC-1, melynek egysoros, 24 karakteres LCD kijelzőjén akár BASIC programokat is írhattunk.7 Igen nagy előrelépés volt az 1989-ben kiadott, MS-DOS kompatibilis Atari Portfolio nevű eszköz. Ebben már 4.92 Mhz-es processzor, 128 kilobájt RAM és 260 x 64 pixel felbontású képernyő volt található. A személyi digitális asszisztensek (Personal Digital Assistant, PDA) kora a 90-es években kezdődött. A PDA-k egyik legjelentősebb zászlóshajójának az 1993-ban megjelent, toll (stylo) alapú Apple Newton eszközöket tartják. A második generációs PDA-k közül a legjelentősebb a Palm Pilot volt, melyben a Newtonhoz képest már sokkal jobban alkalmazható célszoftverek, és már használható kézírás felismerő modul volt beépítve. A Palm-ok fejlődésével párhuzamosan a Psion PDA készülékei is megjelentek a piacon; az első a Series 3a volt, SIBO operációs rendszerrel. A Palm elsősorban az amerikai, a Psion pedig az európai piacot hódította meg. A Psion 1994-ben új operációs rendszer fejlesztésébe kezdett, így jött létre a SIBO utódjaként az immár 32 bites Protea operációs rendszer. 1997-ben megjelent a Psion Series 5, mely már az új operációs rendszerrel működött. Ebben az időben jelent meg a Nokia cég 7
History of Handtops, forrás: http://www.handtops.com/show/news/35/0/History_of_Handtops.html
13
9000-es Communicator mobilkészüléke is, melyen a 16 bites GEOS operációs rendszer futott, amit a Geoworks fejlesztett ki. A Psion olyan üzleti partnereket keresett, akik segítségével mobil eszközeik GSM (Global System for Mobile Communications, GSM) kommunikációra alkalmassá válhatnak. Így jött létre 1998. június 24.-én a Symbian, melynek kezdetben a Psion, a Nokia és az Ericsson volt a tagja, majd októberben a Motorola és a Matsushita (ismertebb nevén Panasonic és Technics) is csatlakozott hozzájuk. A Symbian operációs rendszer elsődleges célja, hogy minimalizálja a szükséges erőforrásokat, de emellett a különböző technológiák adta lehetőségeket is kihasználja. A Symbian Series 80 alapú legújabb Nokia 9300-as és 9500-as kommunikátorok (3. ábra) Bluetooth, Infra, GPRS, EDGE mellett már WiFi kapcsolatot is képesek létrehozni. A Symbian jelenleg az „okostelefonok” legelterjedtebb operációs rendszere.
3. ábra - Nokia 9500, Symbian Series 80
A Microsoft sem maradt ki a mobil eszközök piacáról. A Windows CE 1.0 1996 novemberében jelent meg; ekkor hat cég, a Casio, a Compaq, a HP, az LG Electronics, a NEC, és a Philips döntött úgy, hogy Windows CE alapú mobil eszközöket fog gyártani. Ezután sorra jelentek meg új verziók és javítások a platformhoz, míg 2000 április 19.-én a Microsoft bejelentette az első generációs, Windows CE 3.0 operációs rendszeren alapuló Pocket PC 2000-et (4. ábra). A felhasználók szempontjából a Pocket PC nagy előnye, hogy könnyedén szinkronizálhatóak a Windows alapú számítógépen található levelező klienssel, határidőnaplóval, és egyéb hasznos programokkal. A fejlesztőknek pedig nagy könnyebbséget jelent, hogy a Windows platformon már megismert API-k (Application Programming Interface, API) bizonyos mértékben szűkített változatát a mobil eszközökön is használhatják.
14
4. ábra - Pocket PC 2000 (bal), Pocket PC 2002 (közép), Pocket PC 2003 (jobb) kezdőképernyő
A Windows CE mobiltelefonos változata 2002-ben jelent meg Smartphone 2002 néven, melyet nem sokkal a számos újítást és hibajavítást tartalmazó Smartphone 2003 rendszer követett. Jelenleg a Pocket PC 2003 és Smartphone 2003 rendszereket közösen, Windows Mobile 2003-nak hívják. A Microsoft 2005 május 10.-én jelentette be az újgenerációs PDA-k és Smartphone-ok bővített funkciókkal rendelkező új operációs rendszerét, a Windows Mobile 5.0-t (5. ábra).
5. ábra - Windows Mobile 5.0, Smartphone
5. A Windows Mobile és a Symbian alapú mobil eszközök áttekintése Az
előző
fejezetben
ismertettem a
mobil
eszközök
rövid
történelmét.
Természetesen csak a legfontosabb pontokat emeltem ki. Dolgozatom további részében a Windows Mobile és a Symbian operációs rendszerű mobil eszközöket vizsgálom meg.
15
A Symbian elsősorban az „okostelefonok” operációs rendszere, robosztus felépítésének köszönhetően verziótól és fordítástól (build-től) függően támogatja a legújabb technológiákat is. A Windows Mobile a Pocket PC alapú PDA-k világában jelent meg először, elsődleges célja nem a telefonálás, hanem a fontos információk hordozhatóságának és kezelésének a megkönnyítése volt. A Windows Mobile telefonos változata is a Pocket PC operációs rendszer egy módosított változata. Mint a következő pontokban látni fogjuk, a Windows Mobile esetén a telefonálás lehetősége az operációs rendszerben más kommunikációs modulokkal egy szinten épül be, melyet egyszerűen ki is lehet hagyni (pl. a telefonálásra nem alkalmas PDA-k), a Symbian esetén pedig külön „telefónia modul” gondoskodik a különböző technológiák (GSM, CDMA, GPRS, stb.) támogatásáról, és részben erre épül a többi kommunikációs szolgáltatás.
5.1. Windows Mobile (Windows CE) alapú rendszerek A Windows CE alapú rendszerek alatt a Microsoft Windows Mobile készülékeket értjük, ezen belül is a Pocket PC és a Smartphone eszközöket. Számos típusuk létezik különböző gyártóktól és forgalmazóktól. A Pocket PC alapú rendszerek általában kb. 57 mm x 76 mm méretű, érintés-érzékeny képernyővel, a Smartphone alapú rendszerek pedig kb. 46 mm x 36 mm méretű képernyővel rendelkeznek. A Pocket PC-k esetén az adatbevitel tollal (ún. stylo-val) történik, és különböző módokon adhatunk meg szöveget: szoft-billentyűzettel (a képernyő alsó egyharmadában egy virtuális billentyűzet segítségével vihetjük be a szöveget), betűfelismerővel és szövegfelismerővel. Smartphoneok esetén a mobiltelefonok világában már megszokott módon, a tizenkét gombbal vihetünk be szöveget az eszközbe. A PDA-k egy része GSM modullal is el van látva, így lehetséges velük telefonálni. A Smartphone-ok természetesen szintén képesek telefonálásra, de a GSM funkciókat kikapcsolva személyes digitális asszisztensként is használhatjuk ezen készülékeket. A használt szolgáltatásoktól (pl. Bluetooth) és a háttérvilágítás erősségétől függően átlagosan 4 nap készenléti, és 8 óra beszélgetési időt garantálnak a gyártók. A Windows Mobile készülékek támogatják a .NET Compact Framework-öt, mely az asztali számítógépeken futó .NET Framework [4a] korlátozott erőforrású, elsősorban mobil készülékekre elkészített változata. Segítségével a mobil eszközön felügyelt (managed) kódot futtathatunk, melynek nagy előnye, hogy platform független, így például a Pocket PC-re megírt programok futnak Smartphone készülékeken is. A .NET CF teljes mértékben objektumorientált, támogatja az XML web szolgáltatásokat, az ADO.NET-et, és
16
elsődleges programozási nyelve a C#. Más programozási nyelveken is lehet fejleszteni .NET CF-re, azonban a C#-ot a .NET-hez dolgozták ki, és nem egy korábbi nyelvet alakítottak .NET kompatibilisre (mint például a Visual Basic-et). Annak érdekében, hogy a Windows CE alapú Windows Mobile készülékeket jobban megismerjük, vizsgáljuk meg az operációs rendszer felépítését (lásd 6. ábra). OEM réteg Az OEM rétegben található rendszerindító modul felelős az eszköz inicializálásáért (egyes rendszereknél a rendszerindító modul a memórián túl akár USB-n vagy Ethernet-en keresztül is képes a rendszer indításához szükséges fájlokat letölteni és futtatni). A konfigurációs állományok az operációs rendszer fordításakor játszanak szerepet, esetünkben ez a rész nem lényeges, hiszen a Windows Mobile platform már le van fordítva a készüléken. A driver modul felelős a fizikai és virtuális eszközök kezeléséhez szükséges interfészért, az OAL modul pedig a hardver és a kernel közötti kapcsolatot teremti meg. Az OAL
modul
felel
többek
között
a
megszakításokért,
az
időzítőkért
és
az
energiagazdálkodásért. Operációs rendszer réteg Az egész rendszer magja az operációs rendszer rétegben található kernel, amely a szálak, a folyamatok és a memória kezeléséért felelős. A kommunikációs szolgáltatások és hálózat (Communication Services and Networking) modul felelős a vezetékes és vezeték nélküli kommunikációért. Az eszközkezelőt (Device Manager) rendszerindulásakor a kernel tölti be, folyamatosan fut a háttérben, feladata a rendelkezésre álló eszközök vezérlése. A felhasználói felület és eseménykezelő modul (Graphic Windowing and Event System, GWES) a felhasználó, az alkalmazás és az operációs rendszer közötti interfész. Windows CE alatt ez a modul egyesíti a Win32 API-t, a felhasználói- (User Interface, UI) és a grafikus felületet (Graphical Device Interface, GDI) kezelő könyvtárakat. A multimédia modul teszi lehetővé mobil eszközünkön a hang, a videó és a grafikai megoldásokat. Az objektum tár (Object Store) foglalja magába a mobil eszközön található összes információt, beleértve a ROM-ban és RAM-ban tárolt programokat, az adatbázisokat és a registry információkat. A ROM-ban tárolt adatok akkor is megmaradnak, ha az eszköz energiaellátás nélkül marad. A Core DLL modul felelős a kernel
és
egyéb
alacsony
szintű
programok
futtatásáért.
Az
alkalmazás-
és
szolgáltatásfejlesztés modul (Application and Services Development) biztosítja a 17
fejlesztést; lehetővé teszi a különféle programozási nyelvek és technológiák (pl. ATL, C, COM, DCOM, LDAP, SOAP, SQL Server, MFC, .NET Compact Framework, stb.) használatát. Alkalmazás réteg A felhasználói felület (User Interface) modul az ember-gép kapcsolatért felelős. Többek között ez felel a szoftver alapú szövegbeviteli módszerekért (pl. szoftveres billentyűzet), a toll (stylo) kezeléséért, továbbá az egér szimulálása és a kisegítő lehetőségek (Accessibility) is ennek a modulnak a feladatai. A Windows CE alkalmazás modul tartalmazza az operációs rendszerhez tartozó, ROM-ban tárolt programokat, a saját alkalmazás (Custom Appication) modul pedig a felhasználó által telepített programokat foglalja magába. Az internet-kliens szolgáltatások (Internet Client Services) modul segítségével könnyen készíthetünk böngésző alapú alkalmazásokat.
A Windows CE architektúrája Alkalmazás réteg
Saját alkalmazás modul
Internet-kliens szolgáltatások modul
Felhasználói felület modul Windows CE alkalmazás modul
Alkalmazás- és szolgáltatásfejlesztés modul Core DLL
Operációs rendszer réteg Objektum tár
Multimédia modul
Felhasználói felület és eseménykezelo modul
Eszközkezelo
Kommunikációs szolgáltatások és hálózat modul
Kernel
OEM réteg
OEM adaptációs réteg (OAL) Rendszerindító modul
Konfigurációs állományok
Driver-ek
Hardver réteg
6. ábra - A Windows CE 5.0 operációs rendszer általános architektúrája8
8 Windows CE Architecture, forrás: http://msdn.microsoft.com/library/default.asp?url=/library/enus/wceintro5/html/wce50conIntroducingWindowsCE.asp
18
5.2. Symbian OS alapú rendszerek A Symbian operációs rendszer jelenleg harminc, hamarosan közel ötven különböző típusú mobilkészüléken működik, és a jövőben ez a szám folyamatosan növekedni fog. A Symbian alapú készülék teljes listája megtalálható a Symbian hivatalos honlapján.9 A képernyők kijelzőjének a mérete a Symbian készülékek esetén is igen változó, az átlagos méret 4 cm x 6 cm 200 x 320 képpont felbontása mellett.10 Nagyobb méretű készülékek esetén a képernyő felbontása lehet akár 640 x 200 képpont is.11 Az adatbevitel módját a hardver határozza meg; készüléktől függően történhet a telefon gombjaival (12-15 gomb), QWERTY billentyűzettel és érintés-érzékeny képernyő segítségével. A Symbian operációs rendszer nagy hangsúlyt fektet az erőforrás takarékosságra; a használt szolgáltatásoktól függően akár 12 nap maximális készenléti és 10 óra maximális beszélgetési időt garantálnak a gyártók egyes készülékek esetén. A Symbian OS felépítése (7. ábra) jelentősen eltér az előző pontban megismert Windows Mobile architektúrájától. Természetesen a Symbian OS egyes verzióinak a felépítése között is lehetnek kisebb-nagyobb eltérések, dolgozatomban a Symbian OS v8.0 architektúráját mutatom be. Az operációs rendszer felépítése és alkotóelemei a 7. ábrán láthatók. A bázis modul az alapja minden Symbian alapú eszköznek. Ennek a használata miatt lehetséges, hogy ugyanaz az operációs rendszer teljesen különböző felépítésű hardvereken is fusson. A bázis modul tartalmazza többek között a kernelt, a drivereket (pl. DTE, DCE soros port, USB, LCD, MMC kártyák, billentyűzet, stb.), a fájl szervert (beépített RAM meghajtó, beépített NOR és NAND flash, MMC és SD kártya támogatás) és az alapkönyvtárakat (C Standard Library, relációs adatbázis-kezelő API, folyam kezelés). A bázis modulra épül az összes többi egység. A telefónia modul lehetőséget nyújt különböző távközlési szabványok használatára (pl. GSM, GPRS, EDGE, CDMA, 3GPP2 cdma2000, 3GPP W-CDMA), így a telefongyártók könnyen módosíthatják a telefonok által támogatott rendszereket. A kommunikációs modul a hálózati kommunikációért felelős (IPv4 & IPv6 dual stack, TCP, UDP, ICMP, PPP, DNS, SSL, Telnet, ethernet, FTP, HTTP, WAP). A PAN (Personal Area Network) egység segítségével Bluetooth, infravörös és USB kapcsolaton keresztül érhetjük el a közeli hálózatokat. 9
Symbian OS phones, forrás: http://www.symbian.com/phones/ Például a Motorola A925 készülék esetén a képernyő 40 x 61 cm, a felbontás pedig 208 x 320 képpont. 11 A Nokia 9500 esetén. 10
19
A
biztonsági egység felelős
a titkosított tartalmak kódolásáért,
illetve
visszafejtéséért, a tanúsítványok kezeléséért, a digitális jogkezelésért (Digital Rights Management, DRM) és az alkalmazások telepítéséért. A multimédia modul audió és videó tartalmak felvételére, lejátszására és adatfolyamként kezelésére (streaming) ad lehetőséget. A modulban található OpenGL ES pedig háromdimenziós grafikák valós idejű számítását teszi elérhetővé. Az alkalmazás keretrendszer modul felelős a programok futtatásáért és a felhasználói felületek (Graphical User Interface, GUI) kezelésért. Az alkalmazás modul az operációs rendszerbe beépített alapvető alkalmazásokat (pl. névjegyzék, naptár, feladatok) és azok adatainak eléréséhez szükséges API-kat tartalmazza. Az üzenetküldő modul segítségével SMS, EMS, MMS, és e-mail üzeneteket küldhetünk, a modul részét képező "Send-As" API segítségével könnyen megtehetjük ezt saját alkalmazásunkból is. A Symbian operációs rendszer architektúrájának a legfelső szintjén kínálja a mobil eszközökön használt Java MIDP keretrendszert. A Symbian v8.0 operációs rendszer támogatja mind a J2ME MIDP 2.0-t, mind pedig a CLDC 1.1-et.
A Symbian OS architektúrája
Alkalmazás modul
Java MIDP
Üzenetküldo modul
CLDC 1.1 Alkalmazás keretrendszer modul
Multimédia modul
Biztonsági egység
Personal Area Network (PAN) modul
Kommunikációs modul
Telefónia modul
Bázis modul (kernel, fájl szerver, driverek, könyvtárak)
7. ábra - A Symbian OS v8.0 általános architektúrája12
12 Symbian OS Version 8.0 functional description, forrás: http://www.symbian.com/technology/symbos-v8xdet.html
20
6. A Windows Mobile és a Symbian alapú mobil eszközök által felvetett problémák A mobil eszközök egyre több lehetőséget kínálnak a fejlesztők számára, és így komplex feladatok ellátására is alkalmassá váltak. Alkalmazás- és rendszerfejlesztés szempontjából fontos a kényelmes és intuitív fejlesztői környezet. Windows Mobile készülékekre, hasonlóan az asztali számítógépekhez, Visual Studio fejlesztői környezetben készíthetünk programokat. A Symbian OS-hez nem adtak ki külön grafikus fejlesztői környezetet, azonban a fordító programokat tökéletesen lehet integrálni a már meglévő fejlesztői környezetekbe - így a Visual Studio-ba - is. A fejlesztés első fázisaiban, és olyan programok esetén, ahol a mobil eszköz speciális (pl. kommunikációs: GSM, Bluetooth, IrDA, stb.) moduljaira nincs szükségünk, az emulátort javallott használni. Az emulátor a program futtatása esetén egy új ablakban jelenik meg, első indításakor – a hardverhez hasonlóan – először boot-ol, inicializálja az operációs rendszert, betölti a meghajtókat, majd megjelenik a kezdőképernyő (Home
Screen). Ezek után átmásolhatjuk és telepíthetjük (deploy) az alkalmazásunkat a személyi számítógépről a mobil eszközre, majd futtathatjuk azt. Nem emulálható szolgáltatások (pl. Bluetooth) esetén, illetve a fejlesztés későbbi fázisaiban át kell térnünk a mobil eszközre. Azonos operációs rendszert futtató, de különböző gyártótól származó készülékek esetén is számolnunk kell kompatibilitás problémákkal. Ez egyrészt lehet az operációs rendszer által felhasznált modulok, másrészt pedig a különböző forgalmazók által testreszabott szolgáltatások miatt. Az említett első kompatibilitási problémát okozhatja például az, hogy a Windows Mobile eszközök egy része Bluetooth kommunikációhoz a Windows Bluetooth protokollt, másik része pedig a Widcomm Bluetooth protokollt használja. A Bluetooth kezelését ezért alacsony szinten kell létrehozni, a két külön protokollhoz külön kommunikációt megvalósító osztályra van szükség (magasabb szinten – pl. Java, .NET – még nincs megfelelően támogatva mobil eszközökön a Bluetooth kommunikáció). Ennek hiányában alkalmazásunk nem lesz futtatható mindkét típusú rendszeren. A felvetett második esetre példa, hogy a telefonálásra képes Pocket PC készülékek esetén különbözőek azon registry bejegyzések, melyek megadják azt a programot, melyet az operációs rendszer automatikusan lefuttat bejövő telefonhívás esetén. Még több problémát vet fel az operációs rendszer különböző verziói közötti átjárás. A különbséget itt is alapvetően két dolog okozhatja: egyfelől a hardver továbbfejlesztése, 21
mely egyes esetekben új funkciók (pl. új kommunikációs csatorna) megjelenését, máskor pedig meglévők megszüntetését (pl. régi, elavult kommunikációs csatorna) okozza. A másik problémát az operációs rendszerek modul vagy magasabb szinten való átszervezése jelentheti. Előfordul, hogy újabb operációs rendszerekben a korábbi rendszerekben megismert függvények másképp működnek, vagy teljesen el is tűnhetnek. Természetesen eltérő verziószámú operációs rendszerek esetén is szembesülnünk kell a különböző készülékek esetén felmerülő problémákkal. A beszédszintézis szempontjából a legnagyobb bajt az okozza, hogy mobil eszközökre egyelőre nem létezik egységesített beszédszintézis interfész, mint például a Windows operációs rendszerű számítógépeken már megszokott és jól bevált SAPI (Speech Application Programming Interface, SAPI) [5]. Ez okból kifolyólag a mobil eszközön működő beszédalkalmazásokat az eredetitől eltérő nyelvekre csak a program forráskódjának módosításával lehetne átírni. De a forráskódot csak a legritkább esetben teszik közzé; nyílt forráskódú mobil eszközön futó beszédalkalmazást kutatásaim során nem találtam. Tehát a beszédalkalmazás csak azon a nyelven tud szöveget felolvasni, amelyik nyelvre megírták, más nyelven (esetünkben általában magyarul) sehogyan sem lehetséges „beszédre bírni”. A bemutatott problémákra szinte minden fejlesztés esetén figyelnünk kell. Mobil eszközökön futó beszédalkalmazások esetén további kérdések is felmerülnek. Az alkalmazás típusától függően döntésekre, sokszor kompromisszumokra van szükség a beszédszintézis és az ember-gép kapcsolatának a szempontjából. Amikor beszédalkalmazást tervezünk mobil eszközre, a fejlesztés megkezdése előtt el kell döntenünk, hogy az alkalmazás milyen típusú mobil eszközökön fog futni. Amennyiben speciális alkalmazást készítünk, melynél feltételezhető, hogy a felhasználó az alkalmazás miatt fog mobil eszközt vásárolni (pl. alkalmazás beszédsérültek részére), a kiválasztott eszköztől függhet a program sikere. Ez esetben teljes mértékben a kiválasztott mobil eszközre szabhatjuk az alkalmazást, így, bár a kész alkalmazás forráskód módosítás nélkül nem lesz megfelelően skálázható, a felhasználók speciális igényeit jobban ki tudja szolgálni. Ha az alkalmazás általános célú, nagy számú felhasználót céloz meg, számolnunk kell a különböző márkájú és típusú készülékekkel. Ebben az esetben sokkal gondosabb tervezési és fejlesztési munkára van szükség, és sokszor csak kevesebb funkciót lehetséges megvalósítani, azonban az alkalmazás sokkal több eszközön fog megfelelően futni.
22
A következő pontokban részletesebben megvizsgálom a beszédszintézis és az ember-gép kapcsolat által felvetett problémákat, és a lehetséges megoldásokat.
6.1. Felmerülő problémák a beszédszintézis szempontjából A beszédszintézis szempontjából figyelembe kell vennünk egyrészt a hangkimenet típusait, minőségüket, másrészt pedig a processzor sebességét és az eszköz tárkapacitását. A hangkimenet típusa lehet a beépített hangszóró, jack kimenetre csatlakoztatott fejhallgató, illetve hangfal. Telefonhívás esetén a telefonvonal is lehet hangkimenet. A fejlesztés kezdetekor el kell döntenünk, hogy az alkalmazás ezek közül melyeket fogja használni. Minden esetben érdemes tesztelni a beszédszintetizátort, hogy megállapítsuk mi az a minimális mintavételi frekvencia és kvantálási felbontás, ahol még a beépített hangszóró minőségégből adódóan nem hallatszik különbség a jobb és a gyengébb minőség között. A telefonvonal tulajdonságai alapján 8kHz-es adatbázis elég lehet, azonban az alkalmazástól függően a kiválasztott adatbázist a többi hangkimeneten is fontos tesztelni. Problémát okozhat a mesterséges beszéd érthetőségének a szempontjából a nem elég nagy hangerő, a hangszóró torzítása és a nem megfelelő hangszín. Sajnos a mobil eszközök esetén nincs szigorú előírás, a készülékek hangkimeneteinek a minősége jelentősen eltérhet egymástól, ezért a platformválasztás után érdemes rendszerünket a legelterjedtebb készülékeken kipróbálni. További problémát okozhat a mobil eszköz teljesítménye és tárolókapacitása. Egy SD kártyáról, egy szálon futó, egynyelvű formáns, diádos vagy triádos szintetizátor esetén a mai készülékek által nyújtott több mint 200 MIPS elegendő. A diádos és triádos szintetizátorok adatbázisainak a helyigénye sem jelent akadályt a legújabb mobil eszközök esetén. Korpusz alapú beszédszintetizátorok, illetve több szálon futó, több nyelvű rendszerek esetén azonban könnyen elérhetjük a mai mobil eszközök korlátait; ekkor kompromisszumot kell kötni a megvalósított funkciók és a használhatóság között. Alternatív megoldásként áthelyezhetjük a beszédszintézist a szerver oldalra, ahonnan már csak a szintetizált szöveget tölti le alkalmazásunk (lásd 8.2. fejezet). Természetesen még számos sajátossága van a mobil eszközöknek, melyekre fontos odafigyelni. Példa erre a négybájtos igazítás (4 bytes alignment). A mai mobil eszközök jelentős része már ARM processzort használ. Az ARM processzorok esetén a négybájtos igazítás követelmény. A fordítóprogram a legtöbb esetben erről automatikusan gondoskodik, azonban speciális esetekben nekünk kell biztosítani, hogy a struktúrák
23
határai a négybájtos határon belül legyenek. Amennyiben ezt nem vesszük figyelembe, alkalmazásunk hibásan fog működni. A beszédszintetizátorok mobil eszközre való átírásakor is fontos figyelni a négybájtos igazításra.
6.2. Felmerülő problémák ember-gép kapcsolat szempontjából A felhasználók szempontjából egy rendszer hasznosságát és használhatóságát a rendszer kezelhetősége és funkciói határozzák meg. Amennyiben egy program nem valósít meg könnyen használható, intuitív ember-gép kapcsolatot, a felhasználók könnyen motivációjukat vesztik a rendszer használatában. Megfelelő felhasználói felület, funkciók és vezérlés hiányában a legjobb ötletek is könnyen semmibe veszhetnek, ezért különösen fontos minden alkalmazás esetén gondosan megtervezni és implementálni az ember-gép kapcsolatot. A mobil eszközök esetén sincs ez másképp, sőt az eszköz méreteiből adódó hátrányok (képernyő kis mérete, lassú adatbeviteli módok) számos nehézséget okoznak. Mobiltelefonok esetén az átlagos képernyőméret kb. 27 mm x 27 mm 128 x 128 vagy 256 x 256 képpontos felbontás mellett. PDA készüléknél a képernyő 57 mm x 76 mm nagyságú és 240 x 320 képpont felbontású. Természetesen nem lehet a két esetet egyként kezelni, hiszen eltérő felépítést igényel egy kicsi és egy mérsékelt méretű kijelző esetén a felhasználói felület. Azonban, mint az az élet szinte minden területére igaz, itt sincs másként, sokszor a legjobb a legegyszerűbb megoldás. Mindkét esetben érdemes minimalizálnunk a felhasználói vezérlők (user control) és a menüpontok számát, így egyszerűbbé tehetjük az alkalmazás kezelését. A felhasználói felület mobil eszközre való implementálásakor a következő pontok figyelembevételét javasolom: 1. Tervezzünk egy új felhasználói felületet, vagy implementáljunk egy más platformon már meglévőt. 2. Vizsgáljuk meg a felhasználói felület elemeit, és töröljük a feleslegeseket. 3. Vizsgáljuk meg a modális és nem modális dialógusablakokat, távolítsuk el a felugró (pop-up) ablakokat. 4. Vonjuk össze a hasonló tartalmú menüpontokat, almenüket. 5. Távolítsuk el a felesleges menüpontokat, almenüket és eszköztár (toolbar) ikonokat.
24
Az ismertetett pontokat követve a felhasználói felület minimális elemet fog tartalmazni. Azonban ez önmagában még nem elég, a felületnek intuitív módon használhatónak is kell lennie. Az intuitív felhasználói felület megtervezése összetett feladat, a tervezés során a legfontosabb szempontok az eszköz mérete, az adatbeviteli mód (telefongombok, érintőképernyő, szoft-billentyűzet) és az alkalmazás célja. Érdemes néhány pontot itt is betartani, hogy a felhasználói felület könnyen és intuitívan használható legyen: 1. Kövessük a mobil eszköz operációs rendszerén általánosan használt felhasználói vezérlőket, azok elérési helyét és funkcióját. Egyes mobil eszközök esetén léteznek előírások a képernyő elrendezését és az eszköz gombjai által elérhető funkciókat illetően. A legtöbb Symbian alapú készüléken megszokott, hogy a képernyő alján található két menüpont közül a bal oldali a funkciók kiválasztását, a jobb oldali pedig az eggyel való visszalépést jelenti. Windows Mobile készülékek esetén a bal oldali szoft-billentyűt az alkalmazás fő funkciójának, a jobb oldali gombot pedig az alkalmazás főmenüjének az eléréséhez ajánlják. A felhasználók megszokják az adott mobil eszköz kezelését, így amennyiben hasonló a programunk, gyorsabban megtanulják annak használatát is. Ezért érdemes a kiválasztott mobil platform operációs rendszerébe integrált alkalmazásokat megvizsgálni, és saját programunkat hasonló felépítésűre tervezni. 2. Előnyös, ha a fontos funkciókat egyszerűen és gyorsan el lehet érni. Amennyiben a mobil eszköznek vannak gombjai, érdemes a gombokhoz rendelni a legfontosabb funkciókat.
Érintőképernyő
esetén
szoft-gombok
elhelyezésével
és
speciális
mozdulatokra („gesture”-ökre) való reakcióval tehetjük könnyebbé programunk használatát. "Gesture"-nek nevezzük a gyors, egyértelmű mozdulatot kifejező „rajzolást”. Például „gesture”-nek hívjuk, ha határozott mozdulattal a bal alsó sarokból a jobb felső sarokba húzunk az érintőképernyőre egy képzeletbeli vonalat. Tovább könnyíthetjük az alkalmazás használatát „rejtett” funkciók bevezetésével. Ezek alatt olyan lehetőségeket értek, melyek nem feltétlen szükségesek a rendszer használatához, azonban jelentősen megkönnyítik azt. 3. Érdemes a felhasználói felületet testreszabhatónak tervezni. Az alapvető megjelenésen (betű méret, betű szín, háttérszín, stb.) túl bizonyos esetekben hasznos a 25
felhasználóknak vagy az adminisztrátoroknak megadni a lehetőséget, hogy az alkalmazást a legapróbb részletekig igényeiknek megfelelőre alakíthassák. Ez vonatkozik a felhasználói felület elrendezésére, a felhasználói felület által elérhető funkciókra és billentyűkombinációkra. Például a beszédsérültek számára készült rendszereket érdemes így megtervezni. A beszédsérült emberek egy részének más fogyatékosságokkal is meg kell küzdenie, és ennek következtében eltérőek az igényeik. Egyes értelmi fogyatékos beszédsérültek esetén előfordulhat, hogy például a képernyő alsó részén található fehér hátterű szövegdobozt nem tudják használni, azonban a képernyő felső részén található piros színűt igen. Természetesen ezen esetekben egy adminisztrátor (pl. a beszédsérült orvosa, családtagja) segít a felhasználónak megtalálni számára a legelőnyösebb elrendezést. Másik példa a látási és koordinációs problémákkal küzdő beszédsérült. Számukra sem lehetséges egy általános megoldást találni, hiszen a fogyatékosságok mértéke és az egyéni preferenciák minden felhasználó esetén eltérőek. Így számukra is előnyös, ha igényeiknek megfelelően tudnak beállítani bizonyos paramétereket.
7. Beszédalkalmazás mobil eszközökre Mint minden fejlesztés esetén, mobil eszközöknél is legelső lépésként el kell dönteni, hogy a leendő rendszernek mi az elsődleges célja, és kik fogják használni. Meg kell terveznünk, hogy az alkalmazás széles rétegeket céloz-e meg, vagy kevesebb ember számára lesz használható, azonban számukra nagyon nagy segítséget fog jelenteni. Ezért mindenképp fontos a fejlesztés megkezdése előtt megvizsgálni a lehetséges felhasználói csoportokat.
7.1. Lehetséges felhasználói rétegek Mobil beszédalkalmazás szempontjából négy nagyobb csoportra osztom a lehetséges felhasználókat: beszédsérült felhasználók; látássérült felhasználók; fogyaték nélkül élő, speciális felhasználói réteg és végül az általános felhasználói réteg. Minden csoportnak megvannak az egyedi tulajdonságai, azonban a csoportok között átfedések is lehetnek. Például egy üzenet-felolvasó rendszer elsősorban az általános felhasználói réteg számára készül, azonban nagy segítséget jelent a látássérült embereknek is. Vizsgáljuk meg részletesen az egyes csoportokat, melyek kapcsolatát a 8. ábra mutatja.
26
Beszédsérült (és beszélni nem tudó) emberek A beszédsérült emberek számára mind a szemtől szembeni párbeszédek, mind pedig a telefonos beszélgetések során igen fontos a mobil beszélőalkalmazás. A beszédsérült emberek szemtől szembeni beszélgetéseket legtöbbször nehézkesen ugyan, de le tudnak bonyolítani, telefonos párbeszédekre azonban harmadik személy segítsége nélkül képtelenek. Azonban nincs mindig jelen valaki, aki segíteni tudna a beszédsérült embernek a telefonálásban, továbbá a harmadik ember bevonása egy párbeszédbe személyes, diszkrét témák esetén igen kellemetlen lehet. A telefonálási képesség hiánya esetenként, például tűz vagy szívroham esetén akár tragédiához is vezethet. A kommunikációs nehézségeken túl lelki problémákon is segíthet egy beszédsérült emberek részére készült beszédalkalmazás. Mint más fogyatékokkal élő emberek, a beszédsérültek is hátrányos helyzetben vannak a fogyatékok nélkül élő emberekkel szemben. Továbbá a beszédképesség elvesztése sokszor kilátástalan, elkeseredett helyzetbe hozza őket. E két ok számos esetben vezethet olyan súlyos lelki problémákhoz is, mint például a depresszió. Amennyiben azonban a beszédsérült emberek számára egy beszédalkalmazás segítségével megteremtjük annak a lehetőségét, hogy a fogyatékok nélkül élő emberekhez hasonlóan tudjanak kapcsolatot teremteni környezetükkel, a beszédsérült emberek kommunikációs problémákból adódó lelki bajain is segíthetünk.
Vakok és gyengénlátók A látássérült emberek számára a mobilkészülékek használata igen nehézkes, széleskörű funkcióiknak az elérése pedig szinte lehetetlen, hiszen míg nem tudják, hogy mit mutat a mobil eszköz képernyője, addig képtelenek megfelelően vezérelni azt. Ezért fontosak az olyan beszédalkalmazások számukra, melyek a képernyő tartalmáról, és az egyes eseményekről hang vagy beszédüzeneteket küldenek. Fontos kiemelni, hogy a képernyő felolvasó programok nem jelentenek általános megoldást – nem nyújtanak mindent, amit a beszédsérült számára egy beszédalkalmazás jelenthet –, hanem csak egyes elektronikus eszközök használatát teszik a látássérült emberek számára lehetővé. Ez a mai világban már alapkövetelmény, a látássérült embereknek igen fontos, hogy használhatóak legyenek számukra is a számítógépek és a mobil eszközök. A látássérült emberek számára a mobil eszköz kimenete a beszédszintézis, ennek segítségével kapják meg azon információkat, melyeket a látó emberek a képernyőn keresztül észlelnek. 27
Fogyaték nélkül élő, speciális felhasználói réteg A harmadik felhasználói csoportot alkotják azok az emberek, akiknek valamilyen közös szempont alapján szükséges a beszédalkalmazás használata mobil eszközökön. Általában olyan speciális igénnyel rendelkeznek ezek a felhasználók, hogy igényeiknek nem megfelelőek az általános felhasználói réteg számára készült alkalmazások. Ezért nekik külön fejlesztésekre van szükségük, mely jelentősen megemelheti a költségeket. Ebbe a kategóriába tartozhatnak kutató laboratóriumok, közszolgálati szervek (mentők, rendőrök, tűzoltók), sportegyesületek, brókerirodák, továbbá szintén ebbe a csoportba tartozik a professzionális kerékpárosok edzését segítő rendszer, melyet a 8.4. fejezetben fogok részletesen ismertetni.
Általános felhasználói réteg A legtöbb embert az általános felhasználói réteg foglalja magába. Ezek az emberek a mobil eszközüket nap, mint nap használják, egy részük csak az alapvető funkciókat (pl. telefonhívás, SMS, telefonkönyv), mások az összetettebbeket is (GPRS, Bluetooth, stb.) igénybe veszik. Természetesen a használt funkcióknak megfelelően sok csoportot különíthetünk el, dolgozatomban azonban nem térnék ki ezek elemzésére, mert a beszédalkalmazás szempontjából nem lényegesek. A fogyatékokkal élő emberek korábban ismertetett két csoportja egyben az általános felhasználói réteg alcsoportjai is.
Fogyaték nélkül élo, speciális felhasználói réteg
Beszédsérült emberek
Látássérült emberek
Általános felhasználói réteg
8. ábra - Lehetséges felhasználói csoportok mobil beszédalkalmazás esetén
7.2. Lehetséges alkalmazások A lehetséges alkalmazások előtt definiálom a vékony és vastag kliens fogalmát. Vékony kliens esetén a mobil eszközön semennyi (pl. böngésző), vagy csak minimális saját kód fut le, a kliens csak megjelenítésre szolgál, a többi feladatot a szerver végzi.
28
Vastag kliens esetén a mobil eszközön történik az adatkezelés és a számítás, de természetesen ez esetben is kapcsolatban van alkalmazásunk egy, vagy több szerverrel is. A honlapokat tipikusan a vékony kliens kategóriába soroljuk. Amennyiben olyan honlapot szeretnénk készíteni, mely a mobil eszközön is könnyen használható, el kell készíteni az internetes oldalnak a mobilkészülékekre szánt változatát. Számos problémát vet fel a honlapok mobil eszközökre való adaptálása, azonban a dolgozatomban csak a vastag kliensekkel foglalkozom. Vizsgáljuk meg röviden, hogy milyen esetekben szükséges, vagy lehet hasznos egy beszédalkalmazás mobil eszközökön az előző pontban megismert felhasználói csoportok esetén. Az általános felhasználói réteg és a fogyaték nélkül élő, speciális felhasználói réteg számára elsősorban olyan esetekben hasznos a beszédalkalmazás, amikor a mobil eszközükhöz sehogyan sem, vagy csak mérsékelt módon tudnak hozzáférni. Az általános felhasználói rétegre példa, hogy járművezetés közben, ha egy új üzenet érkezik, vagy szeretnénk megtudni a legfrissebb híreket, veszélyes a mobil eszközt kezelni, mert elvonja a figyelmünket. Ebben az esetben kézenfekvő a beszédalkalmazás használata az információk felolvasására. Fogyaték nélkül élő, speciális felhasználói réteg számára készült alkalmazások közé sorolom a 8.4. fejezetben bemutatásra kerülő professzionális kerékpárosok számára készülő rendszert. A rendszer a felhasználók csak egy kis csoportját érinti, azonban számukra szükséges, hogy biciklizés közben a környezetük paramétereiről (szívritmus, sebesség, légellenállás, az edző tanácsai) információhoz jussanak a mobil eszközhöz csatlakoztatott fejhallgatón keresztül . Látássérült felhasználók számára fontos, hogy ismerjék a képernyő tartalmát. Megkülönböztethetünk kiegészítő és általános képernyő felolvasó alkalmazást. Az első esetben egy programban megadjuk a lehetőséget a beszédkimenetre (pl. a telefonkönyvben, ha kiválasztunk egy nevet, az alkalmazás felolvassa azt), a második esetben pedig egy külön program elemzi a képernyő tartalmát, és beállítástól függően felolvassa az egészet, vagy egy részeit (pl. SpeechPAK TALKS 2.0, ScanSoft13). Természetesen a második megoldás sokkal előnyösebb, azonban kivitelezése jóval nehezebb az elsőhöz képest. Az eltérő platformok miatt nem lehet olyan általános szövegfelolvasót készíteni, mely minden készüléken működni fog, azonban az is megfelelő megoldást jelenthet, ha néhány készüléken létezik általános szövegfelolvasó, hiszen a látássérült emberek ekkor ezeket a
13
SpeechPAK TALKS, forrás: http://www.scansoft.com/speechworks/talks/
29
mobil eszközöket fogják megvásárolni. További problémát jelent az alkalmazás implementálása különböző nyelvekre. Bizonyos típusú mobil eszközök támogatják a globális helymeghatározó rendszert (Global Positioning System, GPS). A GPS és megfelelő részletességgel indexelt térkép segítségével információkat nyerhetünk a felhasználó aktuális környezetéről, és beszédkimenet segítségével ismertethetjük azt a látássérült emberekkel. Szintén a látássérült felhasználók, de elsősorban a fiatalabb korúak számára készülő háromdimenziós játékok esetén is GPS-t használnak [6]. Ezen programokban is érdemes minél több helyen beszédkimenetet alkalmazni, hogy a látássérült felhasználóknak minél több segítség álljon rendelkezésükre. A beszédsérült és beszélni nem tudó emberek életét jelentősen megkönnyíti, életszínvonalukat javítja minden kommunikációs segédeszköz. Azonban nem várhatjuk el egy rendszertől sem, hogy segítségével olyan gyorsan tudnak majd a beszédsérültek környezetükkel kommunikálni, mint a fogyatékok nélkül elő emberek. Igaz, hogy a kommunikáció esetenként igen lassú is lehet, de ezen alkalmazások egy fontos kapcsolatot jelentenek a beszélő és beszédsérült emberek között, megnyitva új, eddig elérhetetlen kommunikációs
csatornákat
(pl.
telefonbeszélgetés).
A
beszédkommunikációs
segédeszközöket részletesen elemzem a 8.1., 8.2. és 8.3. fejezetekben. Mindegyik felhasználói csoport esetén csupán egy-egy példával szemléltettem a lehetséges beszédalkalmazásokat, de természetesen az összes csoport számára még számos rendszer lehetséges és szükséges.
8. Megvalósított rendszerek A nyolcadik fejezetben az általam kifejlesztett rendszereket mutatom be. Minden esetben először a rendszer célját ismertetem, majd a problémafelvetés részben megvizsgálom a szükségességét, és a felmerülő kérdéseket. Ezek után ismertetem a rendszer legfontosabb funkcióit, majd a működésére térek rá, továbbá kiemelem a rendszer által felvetett legfontosabb problémákat, majd röviden a rendszerrel kapcsolatos jövőbeli tervekről írok. Az első két, beszédsérült emberek részére készült rendszer igen hasonló egymáshoz, a különbség a kettő között az, hogy az első csak PDA, a második pedig PDA
30
és Smartphone készülékeken is működik, továbbá a második verzióban már a szerver alapú többnyelvűség is megoldott. A harmadik rendszer kapcsolódik az első kettőhöz, azonban jelenleg nem mobil eszközökön működik, csak a jövőben tervezzük mobilkészülékekre való implementálását. A 8.3. fejezetben megvizsgálom a beszéd- és/vagy hallássérült emberek részére készült rendszert, és a mobil eszközre való adaptálásával kapcsolatos problémákat. Negyedikként a Kaiserslauterni Műszaki Egyetem Környezeti Intelligencia Laboratóriumában (Ambient Intelligence Laboratory, AmI Lab) végzett munkámat és a BelAmi német-magyar együttműködés keretein belül készülő professzionális, biciklisták edzését segítő rendszert ismertetem, majd végül az Ami Lab-al közösen tervezett és jelenleg kivitelezés alatt álló kísérletről számolok be.
8.1. Rendszer beszédsérültek részére (első verzió, PDA) Az első alkalmazás beszédsérült emberek számára nyújt segítséget. Az alkalmazás neve MonddKi, és Pocket PC alapú PDA készülékeken működik. Az alkalmazás első verziója Pocket PC 2000 alapú Siemens SX45 készülékre készült el eVC++ 3.0 fejlesztői környezetben. A platformok és a programozási nyelvek fejlődésével jelenleg a MonddKi .NET Compact Framework rendszeren fut, mind PDA, mind pedig Smartphone készülékeken (lásd 8.2. fejezet).
8.1.1. A rendszer célja Az Európai Unióban (EU-ban) a beszédtehetségüket teljesen vagy szinte teljesen elvesztett emberek száma körülbelül kétmillióra tehető.14 Az ember beszédképességét sokféleképpen vesztheti el. Bekövetkezhet bizonyos betegségek (pl. agyvérzés), idegrendszeri zavarok, külső behatások (pl. baleset, műtét) következtében. A beszédsérült emberek jelentős része idős ember, akik sokszor egyéb fogyatékosságtól is szenvednek (pl. rossz látás, koordinációs zavarok). A beszélni nem tudó emberek számára nagyon nehéz a mindennapi életben való helytállás; problémát jelent mind az élő, szemtől szembeni, mind a telefonon keresztül való kommunikáció. Ez nemcsak magánéletükben jelent súlyos gondot, hanem a munka szempontjából is hátrányban vannak az egészséges emberekkel szemben. Ezen túl számos 14 Telephone users with disabilities – the numbers, forrás: http://www.tiresias.org/phoneability/telephones/user_numbers.htm
31
kellemetlen helyzetbe kerülhet a beszélni nem tudó ember, de sajnos akár halálhoz is vezethet a beszédképesség hiánya (pl. érzi a szívroham előjeleit, de nem tud senkit sem felhívni telefonon segítségért). Ezért számukra nagyon fontos egy, az elvesztett beszédképességüket pótló rendszer, mely által a beszéddel való kommunikáció újra elérhetővé válik. A beszédkészség elvesztése – főleg eleinte – a legtöbb esetben kisebb és nagyobb mértékű lelki betegségeket (depresszió, szorongás, fóbiák) is okozhat. A beszédkészségét nemrég elvesztett ember nehezen tudja elfogadni azt a tényt, hogy a továbbiakban a természetes beszéd, mint kommunikációs csatorna nem létezik számára. Ezért egy rendszer, mely pótolja az elvesztett képességet, nem csak kommunikációs, hanem mentális problémákon is képes segíteni. Sokkal kedvezőbb a helyzetük azoknak az embereknek, akik beszédképességüket csak időlegesen vesztik el, például gégeműtét miatt. Számukra nem létfontosságú, azonban igen hasznos és kényelmes lehet egy beszélő rendszer használata a kritikus időszak alatt. A beszélni nem tudó emberek számára tehát több szempontból is kiemelt fontosságú egy olyan rendszer, melynek segítségével az elvesztett beszédkészségüket pótolni tudják. A technika fejlődésével ma már egyre tökéletesebb beszélő rendszerek megalkotására nyílik lehetőség, így a beszédsérült emberek bizonyos mértékben pótolni tudják az elvesztett képességüket. A fejlesztés célja egy olyan kommunikációs segédeszköz megalkotása, mely lehetővé teszi a gyors, kötetlen, szemtől szembeni és telefonos párbeszédeket.
8.1.2. Problémafelvetés Ebben a fejezetben először megvizsgálom a létező beszédkommunikációt kisegítő rendszereket, majd megfogalmazom a leginkább szükséges szolgáltatásokat. Szót ejtek továbbá a hardver megválasztásának okáról, és bemutatok néhányat a kiválasztott hardveren már létező beszédalkalmazások közül.
Korábbi rendszerek Annak érdekében, hogy a beszédalkalmazás jól használható legyen, számos korábbi beszélő rendszert vizsgáltam meg. Próbáltam a hasznos tulajdonságaikat megtartani, mobil eszközön megvalósítani azokat, illetve új, a korábbi rendszerek hiányosságainak elemzése
32
alapján kidolgozott funkciókat létrehozni. Lássuk a beszédalkalmazás szempontjából fontosabb rendszereket. a) Igen tanulságos egy svéd, beszélni nem tudó tinédzser példája [7]. Ő volt az első, aki a svéd TTS rendszert beszédkommunikációt kisegítő eszközként használta 1978-ban. A hardver egy kerekeken guruló mikroszámítógép volt, a szöveget egy billentyűzet és a szájával irányított
pálca
segítségével
vitte
be.
Először
még
a
mondatok
megformálásával is gondjai voltak, azonban idővel a vele való beszélgetés egyre inkább hasonlított egy szokványos párbeszédre. Kommunikációs készségének fejlődésével együtt egyre jobb teljesítményt nyújtott az iskolában is. Korábban sokszor problémát okozott számára, hogy társainak nem tudott rögtön válaszolni, és azokkal a diákokkal, akik még nem tudtak olvasni, csak mutogatással tudta magát megértetni. Ekkortól kezdve semmi kétség nem férhetett a beszélő rendszerek előnyeihez, bár a fent említett készülék mára már nagyon elavultnak számít. Mégis sokat tanulhatunk az esetből, mely megmutatja, hogy milyen mértékben változtathatja meg a beszélni nem tudó ember életét egy beszélő alkalmazás. b) Jelentősen segítik a beszélni nem tudók kommunikációs lehetőségeit a Bliss szimbólumokon [8] alapuló beszélő rendszerek (mint például a Blisstalk, 1981) [7] és számítógépes programok (pl. Blissvox, 1994) [9]. A Bliss szimbólumrendszer alapját Karl Blitz dolgozta ki az 1940-es években. Eredeti célja egy egységes – nyelvtől, nyelvjárástól független – kommunikációs modul megalkotása volt. A rendszer szimbólumok segítségével ír le szavakat, szószerkezeteket. Leegyszerűsítve a Bliss szimbólumokon alapuló beszélő alkalmazások bemenete(i) szimbólum(ok), kimenete pedig szintetikus hang. A Bliss szimbólumokon alapuló rendszerekből megtanultuk, hogy esetenként hasznos a szöveget korábban eltárolt, akár képekkel jelölt egységekbe „tömöríteni”. c) Az asztali számítógépek az 1980-as évek közepétől kezdtek el „beszélni”. Az egyik leginkább közkedvelt szoftver a Macintosh számítógépeken futó „Talking Moose” (Steve Halls, 1986) nevű program volt.15 Az alkalmazás figyelemmel kísérte a felhasználó tevékenységét, és annak megfelelő kijelentéseket mondott, kérdéseket tett 15 Wired News: Hey Mac, the Moose is Loose, forrás: http://www.wired.com/news/culture/0,1284,45915,00.html
33
fel, de esetenként teljesen váratlanul vicces mondatokkal is szórakoztatta a számítógép előtt ülőt. A „Talking Moose” azonban nem egy beszédkommunikációt kisegítő alkalmazás volt. Jelentősége, hogy ez volt az első világszerte elterjedt beszélő alkalmazás. d) A Multi-Talk rendszerek igen hasznos beszédkommunikációt kisegítő eszközök (Galyas és Rosengren, 1989) [7]. Egy Epson billentyűzet segítségével lehet a szöveget bevinni, majd négy nyelven kimondatni azt a készülékkel. A nyelvet a szerkezeten található megfelelő gomb segítségével lehet kiválasztani. A Multi-Talk több hasznos funkcióval is rendelkezik, mint például a változtatható kontrasztú kijelző, vagy a külön gomb az utolsó mondat megismétlésére. A beépített printer segítségével pedig bármikor ki lehet nyomtatni a begépelt szöveget. A szabad szöveg bevitelén túl lehetőség van előre megírt mondatok kimondatására, továbbá léteznek az úgynevezett üzenetek („messages”), melyek előre megírt mondatok, amiket szükség szerint egészíthet ki a felhasználó. Ezeken túl még számos hasznos funkcióval rendelkeznek a Multi-Talk rendszerek, melyek sok-sok ember életét könnyítették meg. Mindazonáltal a fejlesztés szinte lehetetlen „külsősök” számára, és a célhardver napjainkban már elavult és a telefonálás sem megoldott rajta. A Multi-Talk rendszereket elemezve több funkciót fontosnak ítéltem (pl. kijelző megjelenésének változtatása, messages, egyszerű funkcióbillentyűk), melyeket részben átvettem, részben pedig továbbfejlesztettem. e) Az 1990-es évektől a laptop számítógépek egyre inkább elérhetővé váltak az átlagember számára is, s így már beszédkommunikációt kisegítő célokra is alkalmazhatók lettek. A laptopoknak minden tulajdonságuk megvolt, amivel az eddigi rendszerek rendelkeztek, sőt, a fejlesztés sokkal egyszerűbb volt ezekre a készülékekre, mint például egy Multi-Talk rendszerre. Igen fontos beszélő rendszer az elsősorban laptop számítógépekre fejlesztett, de asztali számítógépeken is futó Voxaid (Olaszy Gábor és Németh Géza, 1993) [10]. A rendszer használhatóságát mi sem bizonyítja jobban, mint az, hogy egy agyvérzés miatt beszélni nem tudó idős hölgy több mint tíz évig a Voxaid segítségével kommunikált környezetével. A program szolgáltatásai között szerepel a szabad szövegbevitel és az
34
előre rögzített mondatok felolvasása. Egy opcionálisan csatlakoztatható szerkezettel a telefonálás is megoldható. A rendszer hátrányokkal is rendelkezik, részben a régebbi technológia fejletlensége miatt: nehézkes folyamatosan egy laptopot hordani, továbbá a monokróm megjelenítés helyett színekkel jobban ki lehetne emelni a lényeget, illetve a felhasználó számára hasznos volna a változtatható betű- és háttérszín. Mindezek mellett az egyszerűbb telefonálási lehetőség is előnyös lenne. Mindazonáltal a Voxaid több tulajdonságát (szabad szövegbevitel, előre eltárolt mondatok) megtartottam, néhányat pedig (pl. korlátlan számú mondat eltárolása, kényelmesebb telefonálás, stb.) továbbfejlesztettem. Számos rendszert készítettek már beszélni nem tudó emberek részére, azonban a telefonálás egyik esetben sem volt egyszerűen kivitelezhető. Áthidaló megoldásként sokszor a hang kimenetét a telefonkagylóhoz vezették, azonban ez nem jelent kényelmes megoldást. A korábbi készülékek méretei sem megfelelőek a mindennapos használathoz. A legkisebb rendszer a felsoroltak közül a laptop alapú beszédalkalmazás volt, azonban egy idős ember számára a laptop „cipelése” is komoly nehézséget jelenthet.
Szükséges szolgáltatások A
hardver
kiválasztása
előtt
a
mindenképp
szükséges,
megvalósítandó
szolgáltatásokat gyűjtöttem össze. Fontosnak tartottam, hogy ne a hardver szabja meg a program szolgáltatásait, hanem a kívánt szolgáltatások alapján válasszuk ki a legmegfelelőbb hardvert. Hogy a program jól használható beszédalkalmazás legyen, a következő szolgáltatásokat tartottam a legfontosabbaknak:
Szabad szövegbevitel A felhasználónak lehetőséget kell adni kötetlen szövegbevitelre. A szöveget lehessen tárolni, és később újra előhívni. Így hosszabb párbeszédek esetén a felhasználó előre eltárolhatja a lehetséges válaszokat, később előhívhatja azokat, a beszélgetés során pedig csak választania kell közülük. A szabad szövegbevitel teremti meg a beszélni nem tudó ember számára a kötetlen beszéd lehetőségét.
Sablon (kötött) szövegek Fontos, hogy a felhasználó tudjon az előre megírt mondatokból gyorsan, egyszerűen választani. Hasznos a mondatok tartalmuk szerinti kategóriákra bontása. A 35
mondatokat és a kategóriákat külön programból lehet szerkeszteni. Az előre megírt mondatok igen hasznosak a kellemetlen helyzetek gyors megoldásában (pl. „Fáj a jobb lábam!”, „Rosszul érzem magam.”, stb.), de a párbeszédet is gördülékenyebbé teszi (pl. „xy vagyok.”, „Örülök, hogy találkoztunk!”, stb.).
Szöveg felolvasása A programnak fel kell tudni olvasni a felhasználó által beírt szöveget (az egészet, vagy a felhasználó által meghatározott részeit), illetve az előre eltárolt mondatokat.
Gyors szövegbeviteli módszer Mivel a beszélő alkalmazást a felhasználó más emberekkel való kommunikációra használja, lényeges a megfelelő sebességű szövegbeviteli módszer.
Telefonálás Nagyon fontos a telefonálás megoldása, hiszen ez olyan kommunikációs csatorna, mely egy beszélni nem tudó ember számára elérhetetlen marad megfelelő rendszer segítsége nélkül. Míg szemtől szembe papírra le tudja írni, vagy el tudja mutogatni közlendőjét, telefonon képtelen segítség nélkül kommunikálni. Ezért mind az eszköznek, mind az alkalmazásnak támogatnia kell a telefonálás lehetőségét.
Kisegítő lehetőségek, testreszabhatóság Mivel az alkalmazást elsősorban idős emberek fogják használni, ezért igen fontos, hogy be tudják állítani a számukra legjobban olvasható formát. Ezért fontos, hogy a betűk színét, háttérszínét és méretét változtatni lehessen. Ezáltal a gyengén látók is tudják használni a programot.
Hardverválasztás A hardver kiválasztása nem volt egyszerű feladat. A célnak nem megfelelő hardver esetén ugyanis még a legjobb szoftver is használhatatlanná válik. Fontos, hogy a hardver kis méretű legyen, de ezzel szemben a nagy kijelző és a könnyű szövegbeviteli mód is lényeges szempont. Ezek alapvetően ellentmondásos tulajdonságok, ezért egyfelől a hardverválasztás kompromisszumokkal járt, másrészt azon kihívást kellett megoldani, hogy az eszköz hiányosságait, hátrányait az alkalmazás sokrétű funkciói kompenzálják. A
36
választás először a Pocket PC alapú PDA készülékekre esett, majd a későbbiekben az alkalmazást más platformokra is elkészítettem (lásd 8.2., 8.3. fejezet). Lehetőségem nyílt több PDA készüléken is tesztelni a kész alkalmazást. A BMETMIT Beszédkutató Laboratóriumában két darab Siemens SX45 Pocket PC 2000 alapú PDA áll rendelkezésre. Ezen túl az Mobile Information Technologies Systems (M.I.T.
Systems) nevű céggel kötött együttműködési megállapodásnak köszönhetően lehetőségem nyílt további három, Pocket PC 2002 alapú PDA-n is tesztelni az alkalmazást (9. ábra).
9. ábra - Az tesztelt PDA készülékek (bal fent: Siemens SX45, jobb fent: HP Jornada, bal lent: Qtek 1010, jobb lent: T-Mobile)
Összesen a következő eszközökön volt lehetőségem fejleszteni és tesztelni a beszélő alkalmazást:
37
•
Siemens SX45 (Pocket PC 2000) – beépített telefonnal rendelkezik.
•
T-Mobile PDA (Pocket PC 2002) – beépített telefonnal rendelkezik.
•
HP Jornada (Pocket PC 2002) – nem rendelkezik beépített telefonnal.
•
Qtek 1010 (Pocket PC 2002) – beépített telefonnal rendelkezik. A PDA megfelelő eszköz egy beszélni nem tudó embereket segítő beszélő
alkalmazás kifejlesztéséhez, azonban számos hátránnyal is rendelkezik. A fejlesztés során sokszor a Pocket PC egyes verziói és a különböző típusú készülékek közötti kompatibilitási problémákkal kellett szembesülnöm, melyek megoldását a hiányos
Software Development Kit (SDK) sokszor hátráltatta. Már létező PDA alapú beszédalkalmazások áttekintése és értékelése Pocket PC alapú PDA készülékekre elsősorban angol nyelven már léteznek beszélő alkalmazások. Ezen programok áthidaló megoldásként még csaknem alkalmasak lennének a
beszélni
nem
tudó
emberek
számára
kommunikációs
eszközként,
azonban
„magyarosítani” nem lehet őket. Kutatásom során kevés Pocket PC alapú PDA készülékeken futó beszédalkalmazást találtam. Az IconSpeak16 program esetén táblázatba rendezett ikonokat segítségével mondathatunk ki szavakat, formálhatunk mondatokat. Az alkalmazás szöveg-beszéd átalakító motort használ, de képes előre rögzített hanganyag lejátszására is. Ez a rendszer túlságosan merev a mindennapi használathoz, csak a legfontosabb közlendők kimondatására alkalmas, összetettebb párbeszédek kialakítása nem lehetséges. A Fonix cég iSpeak nevű beszélőalkalmazása17 elektronikus leveleket (e-maileket) és szövegállományokat képes felolvasni. Az iSpeak nem beszédkommunikációt segítő rendszer,
azonban
szükség
esetén
e
célra
is
lehet
használni:
segítségével
szövegszerkesztőben (pl. Pocket Word-ben) megírt szöveget olvastathatunk fel. Ez természetesen nem felhasználóbarát megoldás, de az előző rendszertől eltérően lehetőséget ad a szabad szövegbevitelre. A SAPI hiánya okozta nyelvi problémán túl a mobil eszközökön futó kommunikációt segítő beszédalkalmazások sokkal kevesebb funkcióval rendelkeznek, mint 16
IconSpeak Palm PC software augmentative communications aid for people with impaired speech, forrás: http://www.bostock.com/IconSpeakInternational.htm 17 Fonix iSpeak for Pocket PC, forrás: http://www.pdasupport.com/FonixiSpeakPocketPC.htm
38
ami szükséges egy beszélni nem tudó ember mindennapjainak jobbá tételéhez, életminőségének javításához. Ezért szükségesnek tartottam a beszédképességüket elvesztett
emberek
számára
beszédkommunikációt
kisegítő,
magyar
nyelvű
beszélőalkalmazás kifejlesztését mobil eszközökre.
8.1.3. A rendszer felépítése A program tervezése és elkészítése során végig szem előtt kellett tartanom a célfelhasználók táborát – elsősorban az idős, számítógéphez nem értő embereket. Intuitív módon használható, könnyen áttekinthető felhasználói felületre volt szükség. A program által megvalósított funkciók többféleképpen elérhetőek – menüből, eszköztárból és egyéb úton is –, így a felhasználóra bízom a számára legegyszerűbb és leggyorsabb módszer kiválasztását. Az alkalmazás három fő részből áll: szabad szöveg, kötött szöveg és félig-kötött szöveg. A felhasználó könnyen elsajátíthatja a program használatát az alkalmazáshoz készült felhasználói kézikönyv segítségével. A következőkben képekkel illusztrálva, röviden áttekintem a program egyes részeit.
Szabad szöveg Szabad szöveg esetén a felhasználó egy – a személyi számítógépeken futó programokhoz hasonló – szövegszerkesztő-szerű mezőbe írhat. A szokásos szerkesztési funkciók (másolás, kivágás, törlés, beillesztés) természetesen rendelkezésünkre állnak. A programmal felolvastathatjuk az egész beírt szöveget, annak egy kijelölt részét (pl. a 10. ábra esetén a program a „fogad” szót olvassa fel), vagy azt a sort, ahol éppen a kurzor található. A felolvasás bármikor megszakítható. Az alkalmazás képes a beírt szöveget eltárolni, és már eltárolt szövegeket előhívni. Amennyiben kötött vagy félig-kötött szöveg módba váltunk át, a szabad szöveg tartalma megmarad, továbbá a másik két mód mondatait át lehet másolni a már meglévő szabad szöveg végére. A szabad szöveg lehetőséget nyújt a felhasználó számára bármilyen szöveg megkötések nélküli, szabad bevitelére. Előre láthatóan összetettebb, fontos, nem sablonos párbeszédek esetén hasznos és célszerű lehet előre megírnia a felhasználónak a kérdéseket és válaszokat (akár több variációt is), amelyeket vélhetőleg használni fog. Ezáltal sokkal
39
gyorsabb, gördülékenyebb kommunikáció valósítható meg, mintha a beszélgetés közben kellene beírni a mondatokat.
10. ábra - Szabad szöveg
A mindennapokban sokszor használt, gyakori mondatok esetén a felhasználónak a kötött és a félig-kötött szöveg lesz segítségére.
Kötött szöveg Kötött szöveg esetén (11. ábra) a korábban eltárolt, kategóriákba rendezett mondatok közül választhat a felhasználó. A kiválasztott mondato(ka)t fel lehet olvastatni a program segítségével, valamint át lehet másolni a szabad szövegbe, hogy ott a felhasználó szabadon módosíthassa azokat. A kategóriáknak bármennyi alkategóriája lehet, bármilyen mélységig, továbbá a kategóriák bármennyi mondatot tartalmazhatnak. A kategóriákat és a mondatokat külön program segítségével szerkeszthetjük. A kötött szöveg igazán gyors kommunikációt tesz lehetővé. Kiválóan alkalmas a kellemetlen és a veszélyes szituációk megoldására, elkerülésére, de a hétköznapi életben is kifejezetten hasznos lehet (pl. üdvözlés, bemutatkozás, általános kérdések, stb.).
40
11. ábra - Kötött szöveg
Félig-kötött szöveg A kötött szövegnél nagyobb szabadságot, a szabad szövegnél pedig gyorsabb kommunikációt valósít meg a félig-kötött szöveg. A félig-kötött szöveg két részből áll. Félig-kötött szöveg módba kapcsolva először a kötött szöveg módhoz hasonló felület jelenik meg a felhasználó előtt. Félig-kötött szöveg esetén is előre megírt, kategóriákba rendezett mondatok közül lehet választani. A kategóriáknak ebben az esetben is végtelen sok alkategóriája lehet bármilyen mélységig. Miután a felhasználó kiválaszt egy mondatot, a program átvált a félig-kötött szöveg második részére, ahol az előzőleg kiválasztott mondat bizonyos, előre meghatározott részei szerkeszthetőek (lásd 12. ábra – A <mennyi> és a <mit> mezők szerkeszthetők csupán; a jobb oldali képen a <mennyi> már át van írva 25-re.). A nem szerkeszthető részekbe nem lehet belépni a kurzorral. A szerkeszthető részek közötti léptetés a 12. ábrán látható, a „<” és „>” gombok segítségével történik. Léptetés esetén az aktuális szerkeszthető szöveget kijelöli a program, így a felhasználó amint elkezd gépelni, a korábban beírt szöveg eltűnik. Amennyiben nem szerkeszthető mezőre próbál lépni a felhasználó, akkor a kurzor mindig a legközelebbi szerkeszthető szöveg kezdetéhez/végéhez ugrik. A félig-kötött szöveg esetén is lehetséges bemásolni a mondatot a szabad szövegbe, ahol már bármely részét változtathatjuk, illetve elmenthetjük, és később betölthetjük azt. A mondatok, a kategóriák külön programmal szerkeszthetőek (MonddKiAdmin), és a mondatok kötött részeit is ennek a programnak a segítségével határozhatjuk meg.
41
A
félig-kötött
szöveg
biztosítja
a
felhasználók
számára
a
gyors,
beszédkörnyezetnek megfelelően alakítható kommunikációt. A megfelelően kialakított kategóriák és mondatok esetén a szabad szöveget csak igen ritka esetekben szükséges használni.
12. ábra - Félig-kötött szöveg
Egyéni beállítások Mivel a MonddKi alkalmazást elsősorban idős emberek fogják használni, ezért fokozottan oda kellett figyelnünk a felhasználói felület kialakítására. Nem tudhatjuk előre, kinek mi a legmegfelelőbb, ezért a felhasználó meg tudja változtatni a betűk méretét, színét és háttérszínét. A felhasználó három előre megadott érték közül választhatja ki a betűk méretét, vagy akár saját kézzel is beírhatja a kívánt nagyságot. Túl kis betűméret esetén a szöveg nem lesz könnyen olvasható, túl nagy betűméret esetén pedig kevés szöveg fér ki a képernyőre. A felhasználó a betűk színét és háttérszínét nyolc előre eltárolt, az RGB alapkomponenseiből kikevert színből választhatja ki.
Egyéb szolgáltatások A MonddKi alkalmazásnak van egy igen hasznos funkciója, melyet a kézikönyvből tudhat meg a felhasználó. A koordinációs zavarok esetén az eszköztár és a menü nehézkes kezelése hátráltatja a szöveg kimondatását. Ezt a problémát először az ikonok méretének megnövelésével szerettem volna megoldani, azonban így nagyon lecsökkent a PDA képernyőjén a használható felület mérete.
42
Alternatív megoldásként, amennyiben a felhasználó hosszan nyomva tartja a képernyő egy részét – ezt akár az ujjaival is megteheti – a MonddKi az aktuális módtól függően a legértelemszerűbb szöveget olvassa fel (lásd 8.1.4. fejezet). Így a felhasználónak sokkal nagyobb terület áll rendelkezésre a szöveg kimondatására, mint nagyobb ikonok esetén.
Telefonálás A beszélni képtelen emberek számára a kommunikáció ezen formája segítség nélkül nem megoldható. Az eddigi, PC-re fejlesztett, funkcióit és célját tekintve hasonló programok esetén a telefonálás megoldása nehézkes volt. Egy Voice Modem-re és egy hangkártyára volt szükség. Két fajta megoldás létezett: a hangkártya kimenetét rákötötték a Voice Modem hangbemenetére, vagy szoftveres úton a szintetizált szöveget egyenesen a Voice Modem-nek küldték. A Pocket PC alapú PDA készülékek egy része telefon is egyben, így ezekkel a készülékkel igen egyszerűen tudnak a beszédsérült emberek telefonálni a MonddKi segítségével: a telefonálás ideje alatt az eszközön megszólaltatott beszéd hallatszik a vonal másik végén.
Adminisztrátori funkciók Mint már korábban utaltam rá, a MonddKi adatbázisainak a szerkesztéséhez létezik egy különálló program, melynek a neve MonddKiAdmin. Az alkalmazás segítségével a kötött és a félig kötött szöveg kategóriáit, mondatait szerkeszthetjük, törölhetjük, és újakat hozhatunk létre. Továbbá a program segítségével lehetőségünk nyílik a félig kötött mondatok szerkeszthető részeinek megadására is (13. ábra). Fontosnak tartottam az adminisztrációs felület különválasztását a programtól. A
MonddKiAdmin elsősorban nem a beszélni nem tudó emberek számára, hanem a betegek orvosainak és a program terjesztőinek készült. A MonddKi alkalmazást igyekeztem minél egyszerűbbnek, átláthatóbbnak megtervezni és elkészíteni. Egy komplex, adminisztrációs résszel is rendelkező kezelőfelület esetleg összezavarná, kedvüket venné a számítógéphez nem értő átlagfelhasználóknak, és esetleg nem a szoftver beszédkommunikációs részének használatára koncentrálnának. Továbbá el akartam kerülni, hogy az adatbázist a program használata közben véletlenül „elrontsák”, átírják.
43
13. ábra - MonddKiAdmin, félig-kötött szöveg szerkesztése
8.1.4. A rendszer működése A MonddKi első verziója C++ nyelven, Embedded Visual Studio 3.0 alatt, a második, PDA-n és Smartphone-on (lásd 8.2. fejezet) futó változata C# nyelven, Visual Studio .NET 2003 Professional alatt készült el. Ebben a fejezetben a MonddKi első verziójának a működését mutatom be röviden. A fejlesztés során számtalanszor ütköztem nehézségekbe. Ezek nagy részét elsősorban a hiányos, nem megfelelően részletes dokumentáció okozta. Ezen kívül problémát jelentett a különböző típusú készülékek közötti kompatibilitás is, annak ellenére, hogy ugyanolyan verziószámú Pocket PC futott rajtuk. A Pocket PC operációs rendszer egyes verziói között sajnos még több kompatibilitási problémával kellett számolnom.
Szövegfelolvasó (Text-To-Speech, TTS) alrendszer A
Budapesti
Műszaki
és
Gazdaságtudományi
Egyetem
Távközlési
és
Médiainformatikai Tanszékének Beszédkutató Laboratóriumában kifejlesztett Multivox (MonddKi első változata) és Profivox (MonddKi második verziója) szövegfelolvasó rendszert használtam. Külön dinamikusan linkelt könyvtárra (Dynamically Linked Library, DLL) volt szükség a Siemens SX45, a másik három PDA (HP Jornada, T-Mobile, Qtek 1010) és az asztali számítógépen futó Pocket PC emulátor esetén. Ez a processzorok utasításkészletei közötti különbségek miatt merült fel. Így a Siemens SX45-höz MIPS, a másik három PDAhoz ARM, az emulátorhoz pedig x86 utasításkészletű fordítás készült.
44
A program fontosabb részeinek vázlatos felépítése A MonddKi alkalmazás első verziója az MFC (Microsoft Foundation Class) segítségével készült C++ nyelven. Erőforrás megtakarítás céljából nem Document-View, hanem dialógus alapú a program. A gyors működés érdekében a három fő rész (kötött, félig-kötött és szabad szöveg) ablakait a program indításakor hozom létre, és csak a végén törlöm azokat. A módok közötti váltás esetén a fölösleges ablakokat elrejtem, és a szükségeseket hozom előtérbe. Így a többi ablak tartalma változatlan marad. Ezek nem használnak sok memóriát, így állandó jelenlétük nem okoz problémát. A menü és az eszköztár az adott módban elérhető funkciók függvényében változik, de az állandó funkciók (pl. szöveg felolvasása), a könnyű kezelhetőség érdekében mindhárom mód esetén ugyanazon a helyen található meg. A továbbiakban ismertetem a program három fő részét.
Szabad szöveg A szabad szöveg rész a CEdit osztályból származik. A szabad szöveg elkészítése hasonított egy egyszerű szövegszerkesztő megírásához. A származtatott osztályban „a képernyő hosszan való nyomva tartása” eseményt is kezelnem kellett: amennyiben van kijelölt szöveg, akkor azt, amennyiben nincs semmi kijelölve, akkor az egész szöveget átmásolja a program egy LPTSTR típusú, dinamikusan létrehozott szövegbufferbe, majd paraméterként továbbítja azt a beszélő motornak. Egész / kijelölt szöveg felolvasása a menüből vagy az eszköztárból ugyanígy történik, míg az aktuális sor (amelyiken épp áll a kurzor) felolvasása esetén az adott sort másolja át a program a szövegbufferbe.
Kötött szöveg Kötött szöveg esetén a mondatok kategóriákra bontását fa struktúrával oldottam meg. A fa struktúra (fa)elemekből és bejegyzésekből áll. Elem alatt a fa ágait (a kategóriákat, pl. Saját Mondatok; Párbeszéd; Bevásárlás; stb.), bejegyzés alatt pedig a felolvasandó szöveget (pl. „Ez mennyibe kerül?”) értem. Egy bejegyzés bármennyi mondatból állhat. Egy elemnek lehetnek alelemei és bejegyzései (pl. a „Párbeszéd” egyik bejegyzése lehet a „Mi történt a mai napon?” mondat, hisz ez a „Párbeszéd” minden alkategóriájában lehetséges kérdés).
45
Ennek megfelelő hierarchiájú fa struktúrát támogató osztályt a MonddKi első verziója fejlesztésekor nem találtam, ezért saját osztályt írtam erre a célra. A második verzióban már a C# programozási nyelvben támogatott XML struktúrát használom [4b]. A saját osztály neve COwnTree. A MonddKi és a MonddKiAdmin alkalmazások szempontjából a COwnTree elsődleges funkciója, hogy a paraméterként átadott fájlból beolvassa az elemeket és bejegyzéseket, és eltárolja azokat a memóriába. A
MonddKiAdmin megfelelő működése érdekében az osztálynak elemeket, bejegyzéseket kell tudnia beszúrni, törölni, és az egész fát fájlba menteni. A fát a következő struktúrában tárolom, melyet a CFile osztály segítségével kezelek: ["Első kategória"] { ["Első kategória/első alkategória"] { "Első kategória/első alkategória-1. mondat" ["Első kategória/első alkategória/első al-alkategória"] { "Első kategória/első alkategória/első al-alkategória–1. mondat" } ["Első kategória/első alkategória/második al-alkategória"] { "Első kategória/első alkategória/második al-alkategória-1. mondat" "Első kategória/első alkategória/második al-alkategória-2. mondat" ["Első kategória/első alkategória/második „al-alkategória/első „al-al-alkategória"] { "Első kategória/első alkategória/2. „al-alkategória/első al-al-alkategória–1. mondat" } } } ["Első kategória/második alkategória"] { "Első kategória/második alkategória-1. mondat" "Első kategória/második alkategória-2. mondat" } } ["Második kategória"] ...
Mint láthatjuk az elemek és a bejegyzések mindig idézőjelek között vannak. Elemek esetén az idézőjeleket szögletes zárójelek határolják, az elem alelemeit és bejegyzéseit kapcsos zárójel fogja közre. A kötött szöveg esetén a képernyő két részre oszlik: a képernyő felső részen látható fa szerkezet az elemeket, az alsó részén található „felsorolás” pedig a bejegyzéseket 46
tartalmazza. Az előbbit egy CTreeCtrl-ből, az utóbbit pedig egy CListBox-ból származtatott saját osztályból kezelem. A saját osztályok nevei CTreeEdit és CListEdit. Ez esetben is külön figyelem a CTreeEdit származtatott osztályban a duplaklikk / a képernyő hosszan való nyomva tartása eseményt (azért csak a CTreeEdit-ben, mert a CListEdit esetén nem lenne értelme, mivel szimpla klikk esetén is kimondja a bejegyzést a program), mely bekövetkezése esetén a kiválasztott elem tartalmát a beszélő motornak paraméterként elküldöm felolvasás céljából. Ha kiválasztunk egy elemet a felső ablakban, akkor annak bejegyzéseit a COwnTree által korábban feltöltött fából olvassa ki a program. Az elemeket a CTreeCtrl osztály sajátosságainak köszönhetően elég egyszer kiolvasni, de a CListBox-nak minden elem esetén más a tartalma (lásd 14. ábra), így azt elemváltáskor frissíteni kell.
Adatok
Megjelenítés
(COwnTree)
(elemek, CTree)
Megjelenítés (bejegyzések, CListBox) 14. ábra - A kötött szöveg elemeinek és bejegyzéseinek memóriában tárolt adatok alapján való megjelenítése
A fát a következő két struktúrával írtam le: struct ItemText { ItemText* pNext; ItemText* pPrev; LPTSTR sTitle; }; struct TreeItem { ItemText* pContent; TreeItem* pSubItem; TreeItem* pSuperItem; TreeItem* pNext; TreeItem* pPrev; HTREEITEM TItem; LPTSTR sTitle; };
A pNext a következő elemre (az ItemText struktúra esetén bejegyzésre), a pPrev az előző elemre (az ItemText struktúra esetén bejegyzésre), a pSubItem egy elem alelemei
47
közül az elsőre mutat, a pSuperItem pedig arra az elemre, melynek az adott elem az aleleme. A pContent egy ItemText típusú struktúrára mutat, az sTitle-ben tároljuk az elem / bejegyzés tartalmát (pl. kategória neve). A TItem-re azért van szükségünk, hogy az elemeinket a CTree objektumban azonosítani tudjuk. Ez teremti meg a kapcsolatot a saját fa osztályunk és a CTree osztály között. A fa struktúrára egy példát ábrázol a 15. ábra. Memóriaterületet a fa elemei (TreeItem) és bejegyzései (ItemText) számára a
LocalAlloc függvénnyel foglalok. Ezen túl természetesen az elemek és bejegyzések tartalmának (sTitle) is külön lefoglalok az sTitle karakterlánc hosszúságának megfelelő memóriaterületet. pNext(N-1)
pNext( N)
(N-1). elem
N. elem pPrev(N) pSu perItem
pSubItem(N) pContent(N)
(N+1). elem pPrev (N+1) pSuperItem(2) pNext(1.)
N/1. alelem
N/2. alelem pPrev (2.)
N/1. bejegyzés
pNext(N/1b )
pPrev (N/1b )
N/1. bejegyzés
15. ábra - Példa a fa struktúrára
A félig-kötött szöveg is egy az egyben ezeket az osztályokat (COwnTree,
CTreeEdit és CListEdit) használja. A CListEdit egy flag alapján dönti el, hogy épp melyik módban (félig-kötött vagy kötött szöveg) van a program.
Félig-kötött szöveg A program egyik legkomplexebb része a félig-kötött szöveg. Ez esetben az előre elkészített adatbázisban található kategóriák szerint rendezett mondatok közül kiválasztunk egyet, melynek csak bizonyos – előre meghatározott – részeit szerkeszthetjük, illetve a szerkeszthető részek között „ugrálhatunk”. A félig kötött szöveg megírásakor kihasználtam a unicode kódolás nyújtotta előnyöket. A unicode a hagyományos (egy bájtos) módszerrel szemben két bájton tárolja a karaktereket, így lehetővé teszi például távol-keleti nyelvek szimbólumainak, betűinek a megjelenítését. Mivel a magyar nyelv esetén nincsenek ilyen szimbólumok, ezért a unicode
48
második bájtját tetszés szerint változtathatom. Mivel a Pocket PC alapú PDA-k mindegyike unicode alapú, ezért mindenképp unicode-ot kell használnom – még ha ez szöveg fájlok esetén kétszer akkora méretet is jelent. A módszerem a következő: a félig-kötött szöveg nem szerkeszthető részeinek az elejét és a végét megjelöltem (az adott sztring első és utolsó betűjének második bájtját 20H-ra állítottam, ezt a továbbiakban maszkolásnak hívom), majd a kötött szöveggel megegyező módon eltároltam – így az adatbázis struktúráján nem kellett változtatnom. A speciális, unicode-ba rejtett jeleket az MFC CEdit osztályából származtatott saját osztályom (CHFEdit) kezeli. A CHFEdit osztály akkor lép működésbe, amikor a CEditList azt az eseményt kapja, hogy valamelyik elemét kiválasztották. Természetesen itt is hasonlóan működik a korábban már bemutatott duplaklikk / a képernyő hosszan való nyomva tartása esetén a kiválasztott elem / bejegyzés felolvasása. A kötött szöveghez képest különbség, hogy most a bejegyzés esetén is értelme van a duplaklikknek / a képernyő hosszan való nyomva tartásának, hiszen szimpla klikk esetén a CHFEdit lép működésbe. Visszatérve a maszkoláshoz, a megjelenítéskor nem írhatom ki a maszkolt karaktereket (hiszen azok maszkolva nem is betűk, hanem különböző szimbólumok), ezért egy külön sztringben tárolom el a maszkokkal teli szöveget, és ezeket a maszkoktól megcsupaszítva jelenítem meg. Ezt függvényből teszem meg, mely először megvizsgálja a paraméterként átadott szövegbuffer összes karakterének felső bájtját, és amennyiben az 0x20H-val egyezik meg, akkor átírja 0x00H-ra, majd a maszkoktól mentes sztringet adja vissza. A program mindig a maszkolt szöveget vizsgálja, hogy épp szerkeszthető, vagy nem szerkeszthető helyen van-e a kurzor, a felhasználó pedig mindig a maszkoktól megcsupaszított szöveget látja, abban mozoghat. Ebből kifolyólag a CHFEdit osztályban minden billentyű megnyomása esetén a lenyomott karakternek megfelelően kell változtatnom a maszkolt szöveget. Külön oda kellett figyelnem a nyilak, ctrl, alt, shift, tab, enter, caps lock és backspace billentyűk kezelésére. Hogy a maszkolt szöveg frissítése megfelelő legyen, több feltételt is meg kellett vizsgálnom, hogy azok szerint frissítsem a maszkot. A felállított szabályrendszer a 16. ábrán látható. A szerkeszthető részek közötti navigációt is a CHFEdit osztály végzi. Külön van választva az előre és a hátra „ugrás”. Mindkét esetben először meghatározom a CEdit ablakban a kurzor pozícióját, majd a maszkban keresem az ezután következő / ezt 49
megelőző 0x20H maszkot. Ha megtaláltam, akkor az lesz a szerkeszthető mező eleje / vége (attól függően, hogy előre vagy hátra „ugrottam”). Ezután megkeresem a másik végét a szerkeszthető mezőnek, és a SetSel függvénnyel kijelölöm azt. A módszer hibamentes működéséhez számos feltételt kell megvizsgálnom (pl. a szöveg legelső/legutolsó karaktere maszkolt-e, a kurzor a szöveg legelején/legvégén van-e, stb.).
A bejövo karakter delete vagy backspace volt-e?
Nem
Volt-e kijelölt szöveg?
Volt-e kijelölt szöveg?
Nem
A CEdit ablak kurzor pozíciójával megegyezo helyre a begépelt karaktert beillesztése.
Igen
Igen
Igen Nem
Kijelölt szöveg helyére a begépelt karakter beillesztése.
Törlöm a kijelölt szöveget.
Backspace és nem a szöveg elején állt a kurzor? Igen (*)
Delete és nem a szöveg végén állt a kurzor? Igen (*)
A CEdit ablakban a kurzor elotti karakter pozíciójával megegyezo helyu karakter törlése a maszkban .
A CEdit ablakban a kurzor mögötti karakter pozíciójával megegyezo helyu karakter törlése a maszkban .
16. ábra - Félig kötött szöveg, a maszk frissítése (*: ezen a ponton még számos további feltételt kell még megvizsgálni, és azoknak megfelelően kell végrehajtani az utasítást)
A programnak arra is figyelnie kell, hogy a felhasználó nehogy nem szerkeszthető, azaz
maszkolt
szövegbe
lépjen
a
kurzorral.
Ezért
klikkelés
(void
CHFEdit::OnLButtonUp(UINT nFlags, CPoint point)) vagy felengedett billentyű (void CHFEdit::OnKeyUp(UINT nChar, UINT nRepCnt, UINT nFlags)) eseményre a program megvizsgálja a kurzor új pozícióját, és amennyiben nem szerkeszthető részbe esik, akkor a kurzor a legközelebbi szerkeszthető részre ugrik. Ez esetben is számos feltételt kell megvizsgálni (pl. kijelölt szöveg esetén a kijelölt szövegben van-e nem szerkeszthető rész, hol van a legközelebbi szerkeszthető szöveg, stb.).
50
8.1.5. A rendszer által felvetett problémák A rendszer fejlesztése során egyrészt hardver, másrészt pedig szoftver jellegű problémákkal kellett szembesülnöm, melyek közül a legfontosabbakat röviden ismertetem.
Hardver oldalról Hangerő Sajnos a PDA készülékek hangereje több esetben is halknak bizonyult, egyes készülékek esetén pedig enyhe torzítást is észleltem. Telefonálás esetén ez nem jelent problémát, az élő párbeszédek esetén azonban gondot okozhat a nem megfelelő hangerő. Zajos környezetben (pl. utcán, villamoson, boltban) sokszor csak közelről lehet hallani a PDA hangját. Természetesen így is lehetséges a kommunikáció, azonban nem kényelmes (kimondás közben a felhasználónak a beszédpartneréhez közel kell emelnie a készüléket). Sajnos sok készülék nem rendelkezik szabványos hangkimenettel (pl. ¼" jack, RCA), így az opcionális külső hangfal sem szolgál megoldásként. Továbbá a rendszernek pont az a lényege, hogy kicsi, egyszerű, mobil, ezért nem szeretnénk kiegészítőkkel „terhelni”.
Kijelző Bizonyos PDA készülékek kijelzőjének az olvashatósága nem minden körülmény között megfelelő. Van olyan készülék, mely kijelzője napfényben igen fakóvá válik, és olyan is van, amin a védőüveg túlságosan visszatükrözi a környezetet. A kijelző méretével kapcsolatosan már többször is szó esett arról, hogy kompromisszumot kell kötni a megjelenített információk mennyisége és a méret között.
Energiaellátás Igen fontos szempont, hogy mennyi ideig képes a készülék akkumulátorról működni. Jelen beszédalkalmazás esetén a két töltés közötti időt elsősorban a képernyő háttérvilágítása, a számolás, az audió kimenet használata és a telefonálással eltöltött idő befolyásolja. Újabb típusú készülékek (pl. Qtek 1010) méréseim alapján több mint nyolc óráig képesek működni a MonddKi folyamatos használata mellett. Telefonálás esetén ez az időtartam rövidebb. Nyolc óra beszélgetési időnek egy nap alatt elegendőnek kell lennie, hiszen beszélni tudó emberek sem beszélnek átlagosan többet napi nyolc óránál. Este pedig a készüléket a beszédsérült felhasználó újból fel tudja tölteni.
51
Törékenység A PDA készülékeken futó kommunikációt segítő alkalmazás célfelhasználói esetén számolnunk kell esetleges koordinációs zavarokkal is, melyek károsodást okozhatnak a készülékben (pl. leejtik). De hasonló „balesetek” a mindennapi használat során másokkal is előfordulhatnak. Ez a probléma a viszonylag drága készülékek esetén igen kritikus.
17. ábra - Heavy Armour 2000 PDA védőpáncél
Megoldást jelent a PDA-khoz készített páncél (ún. Armour, 17. ábra).18 A leírás szerint a páncél megvédi a PDA-t az ütéstől, víztől, hótól, párától, piszoktól, portól, karcolástól. A páncél ára a készülékhez képest nem jelentős, azonban korlátozza a készülék kényelmes használatát.
Gazdasági probléma Nem technikai jellegű, de az összes eddiginél jelentősebb probléma a PDA készülékek ára. Hazánkban az átlagkeresethez és a nyugdíjakhoz képest egy PDA készülék megvásárlása igen jelentős anyagi megterhelést jelent. Jelenleg a beszélni nem tudó emberek nem tudnak PDA készüléket TB támogatással vásárolni, továbbá mivel a PDA-k penetrációja hazánkban alacsony, így a cégek részéről sem jelentős egyelőre a Pocket PC alapú szoftverek iránti kereslet.
Szoftver oldalról Dokumentáció A mobil eszközök fejlesztésével kapcsolatos egyik legnagyobb, általános problémát a nem megfelelően részletes dokumentáció jelenti. Sokszor csak „próbálgatással” sikerül 18
Mobile Planet Product: Heavy Armor 3600 PDA Case, forrás: http://www.mobileplanet.com/private/pocketpc/product.asp?cat%5Fid=203&cat%5Fname=Accessorize&pf %5Fid=MP289629&dept%5Fid=3716&listing=1
52
egy-egy függvény pontos működését megfejteni. Néhány esetben a PDA készülék gyártójának a segítségét kell kérni, akik gyakran olyan megoldást javasolnak, ami nem szerepel sehol sem a dokumentációban. Az internetes fórumok19 is sokat segíthetnek a munkában. Bár sok esetben akadtam el hosszabb-rövidebb időre a nem megfelelően részletes dokumentáció miatt, általában találtam megoldást, vagy megkerülve a problémát az adott funkciót máshogyan valósítottam meg.
Telefonálás A telefonálási funkciók eléréséhez a Telephone Application Programming Interface (TAPI) nyújt segítséget. A hívásindítás egységes, azonban sajnos jelenleg nem lehet egységes helyen megadni, hogy bejövő hívás esetén melyik programot indítsa el az operációs rendszer. Ez a paraméter gyártófüggő, általában a registry-ben található, de a legtöbb készülék esetén más bejegyzés alatt. Sajnos ezeket a bejegyzéseket nem publikálja a gyártó, így csak a registry elemzésével lehet megtalálni azokat. A következő generációs, Windows Mobile 5.0 rendszerrel remélhetőleg szabványosítják ezt a paramétert. Természetesen így is tökéletesen lehet a MonddKi-t telefonálásra használni. Amennyiben olyan készüléken fut a program, amelyen nem tudtam a registry-t elemezni, bejövő hívás esetén az operációs rendszer az alap telefonszoftverre vált át, nem a MonddKi-re. Így minden bejövő hívás esetén vissza kell váltanunk a MonddKi-re, amit beállítástól függően egyszerűen megtehetünk például a készüléken található valamelyik gomb segítségével.
Soft Input Panel (SIP) méretének megnövelése A Pocket PC operációs rendszerek esetében a szövegbevitelt az ún. Soft Input Panel (SIP) biztosítja. A SIP a képernyő alsó részén található. Tapasztalataim szerint – elegendő gyakorlás után – a szoft-billentyűzet biztosítja a leggyorsabb szövegbevitelt. Csökkent látású és/vagy koordinációs zavarokkal küzdő emberek számára azonban a SIP virtuális billentyűinek használata problémát jelenthet. Ezért a jövőben szeretnék elkészíteni egy dupla nagyságú virtuális billentyűzetet. Igaz, hogy ez a képernyőnek több mint a felét elfoglalná, de a szövegbevitelt egyszerűbbé, gyorsabbá tenné.
19
Például: http://forums.devbuzz.com, http://www.pocketpcdn.com, http://www.codeproject.com
53
8.1.6. Jövőbeli tervek A MonddKi alkalmazás első verziójának a fejlesztése 2002 őszén kezdődött el. Azóta számos új technológia jelent meg, és a fejlesztés ideje alatt sok új ötlet merült fel. Ezért elkészítettem a MonddKi alkalmazás második változatát Pocket PC alapú PDA és Microsoft Smartphone készülékekre. A következő fejezetben ismertetem a legfőbb újdonságokat.
8.2. Rendszer beszédsérültek részére (második verzió, PDA és Smartphone) 2003 decemberében a kommunikációs segédeszköz beszédsérültek számára témával a Beszédkutató Laboratórium a Microsoft Junior Research Contest "Smartphone" keretében hozzájutott két Microsoft Smartphone készülékhez (Red E 1100, Orange SPV 200), így a fejlesztői munka már ezen platformokra is kiterjedt. A Windows Mobile 2003-as készülékeken a .NET Compact Framework elég megbízható volt már ahhoz, hogy alkalmas legyen komplex alkalmazás fejlesztésére. Így kezdődött el a fejlesztés .NET Compact Framework alatt Windows Mobile 2003 alapú készülékeken. A .NET CF-nek köszönhetően a Pocket PC alapú PDA-kon és a Microsoft Smartphone készülékeken ugyanaz a kód fut, azonban a felhasználói felületnek, a szövegbeviteli módnak és a telefonálásnak a sajátosságaira oda kell figyelni.
8.2.1. A rendszer célja A rendszer célja azonos az előző fejezetben ismertetekkel (lásd 8.1.1.), azonban most már két eszközön kínál kommunikációs segítséget a MonddKi. Mindkét eszköznek megvannak az előnyei és a hátrányai is. Pocket PC alapú PDA készülékek esetében gyorsabb a szövegbevitel, és nagyobb a felhasználói felület, azonban a készülék sérülékenyebb, mérete nagyobb, és a program vezérlése is lassabb. A MonddKi PDA-s változatát elsősorban hosszú, összetett beszélgetések kivitelezésére ajánlom. Microsoft Smartphone készülékek esetén a szövegbevitel lassabb, és a képernyő is kisebb méretű, azonban az eszköz könnyebben hordozható, kevésbé sérülékeny, és a program irányítása, továbbá a telefonhívások is gyorsabban kivitelezhetőek. A MonddKi Smartphone készülékeken futó változatát elsősorban rövid, szemtől szembeni (pl. bankban), vagy telefonos (pl. segélykérés) beszélgetésekhez ajánlom. 54
8.2.2. Problémafelvetés A fejlesztés végső célja egy olyan kommunikációs segédeszköz platform létrehozása, ahol a beszédsérült ember különböző méretű és tulajdonságú eszközök (pl. Smartphone, PDA, Tablet PC) közül választhat, azonban maga az alkalmazás az összes eszközön hasonló. Amennyiben minden platform esetén teljesen különbözne a forráskód, nagyon nehéz volna, és sok munkát venne igénybe új funkciók bevezetése. Ezért volt szükséges platform független rendszert választani. A MonddKi első verziójának elkészítésekor azonban még nem volt megfelelően használható sem a .NET Compact Framework, sem a JAVA MIDP a mobil eszközökön. Ezért először a C++ nyelvet és az MFC könyvtárat választottam, hiszen ezek elég elterjedtek, és igaz, hogy a forráskódot változtatni kell, és újra kell fordítani az alkalmazást ahhoz, hogy az egyik platformról a másikra átvihessük a programunkat, azonban minden Microsoft platformon igen hasonló a használatuk. A fejlesztés során azonban a mobil eszközök olyan sajátosságaiba ütköztem, melyek leküzdéséhez minden platformon jelentős változtatásokra lett volna szükség a program adaptálásához. Időközben sokat fejlődött a .NET Compact Framework és a JAVA MIDP is. Végül a .NET Compact Framework-öt választottam, mert egyrészt a Java MIDP-ben több funkció csak nagyon nehezen volt elérhető (pl. telefonálás), továbbá a Microsoft saját eszközein jobban támogatja a Microsoft alapú fejlesztéseket, több dokumentumot, segédanyagot és hibajavítást adnak ki hozzá. A .NET keretrendszerben készült programokat könnyen lehet a mobil eszközök és akár az asztali számítógép között is hordozni, de természetesen mindig figyelembe kell venni az adott platform teljesítményéből, felhasználói felületének méretéből és adatbeviteli módjából adódó sajátosságokat.
8.2.3. A rendszer felépítése A
MonddKi
második
verziója
felépítésében
azonos
a
8.1.3.
pontban
megismertekkel, most csak a jelentős újdonságokat ismertetem. Smartphone-on a szabad, a kötött- és a félig-kötött módok működése azonos a korábban bemutatottal, azonban a kötött- és a félig-kötött mód esetén egyszerre vagy csak a kategóriák, vagy csak a mondatok láthatóak. Könnyebb lett a módok közötti váltás is. A telefonon található joystick segítségével könnyen navigálhatunk az egyes módok között: a joystickot jobbra húzva a következő,
55
balra húzva az előző módra vált a program. Hasonlóan működik a program PDA készülékeken, azonban itt speciális mozdulatokkal (gesture-ökkel) válthatunk az egyes módok között: ha húzunk egy képzeletbeli vonalat balról jobbra, akkor a következő, ha jobbról balra, akkor az előző módra vált az alkalmazás (lásd 18. ábra).
Szabad szöveg
Kötött szöveg
Féligkötött szöveg
18. ábra - Váltási szekvencia a módok között
További újítást jelent, hogy az alkalmazás eltárolja a legtöbbször felolvasott mondatokat, így nem kell a felhasználónak saját adatbázisokat készítenie. A MonddKi figyelembe veszi, hogy hányszor és mikor volt a mondat felolvasva, hiszen nem egyenértékű, ha például egy mondatot egy héten tízszer, vagy az elmúlt egy órában ötször olvasott fel a program. Ezen adatok alapján rangsorolja a mondatokat a MonddKi. A második verzió egyik legnagyobb újítása az, hogy a beszédszintézis már egy központi szerveren is működhet, ahonnan a kliens csak a kész hanganyagot tölti le. Ez egy általános megoldást jelent; nem csak beszédsérültek számára készült kommunikációs segédeszközök esetén, hanem minden beszédalkalmazásnál (bármilyen platformon) használható. A szolgáltatásnak a StreamSpeech nevet adtam. Vizsgáljuk meg a legfőbb előnyeit: •
Tetszés szerinti szöveg-beszéd átalakító csatolható a rendszerhez, ami működik a szerveren, tehát nem szükséges, hogy legyen mobil kliensen futó változata. Így lehetőségünk van a mobil kliensen olyan szöveg-beszéd átalakító rendszerek megszólaltatására, melyeknek még nem létezik mobil eszközökön futó változata (mert nem készítették még el, vagy jelenleg nem lehetséges elkészíteni – pl. korpusz alapú beszédszintetizátorok).
•
Az előző pontban ismertetett tulajdonságnak köszönhetően bármennyi szövegbeszéd átalakító rendszer csatolható a mobil klienshez, így könnyű például többnyelvű támogatást kialakítani.
56
•
A szöveg-beszéd átalakító rendszerek a szerveren – védett helyen – maradnak, nem kerülnek ki minden kliensre, így nem kell a TTS rendszerek jogtalan újrafelhasználásától tartani.
•
A szerveren adatokat lehet gyűjteni a szöveg-beszéd átalakító rendszerek használatáról, a felolvastatott szövegekről (természetesen anonim módon, a felhasználók beleegyezésével). Ezen adatok alapján értékes statisztikákat lehet készíteni, hogy milyen irányban érdemes továbbfejleszteni a TTS rendszereket.
•
A szöveg-beszéd átalakító rendszer(ek) üzemeltetői forgalom utáni díjazást számlázhatnak ki.
8.2.4. A rendszer működése A rendszer felépítése szinte azonos a MonddKi első verziójával, de a második verziót újra kellett írnom C# nyelven. A régi, saját fejlesztésű adatbázis struktúrát felváltotta az XML (eXtended Markup Language, XML). Az adatbázis XML-ben a következőképp épül fel kötött szöveg esetén:
- Mondat 1.
- Mondat 2.
. . - Mondat N.
- Mondat 1.
- Mondat 2.
. . - Mondat M.
. .
Mint látható, a kategóriák nevét attribútumként, a mondatokat pedig tartalomként tárolom. A félig kötött szöveg kategóriáit és mondatait a kötött szöveghez hasonlóan tárolom, a szerkeszthető részeket pedig attribútumként a következőképpen adom meg:
57
<PartlyFixedText>
- Szerkeszthető, nem szerkeszthető.
- Szerkeszthető, nem szerkeszthető, megint szerkeszthető, megint nem szerkeszthető.
A kisebb újítások technológiai ismertetését dolgozatomból a tömörség kedvéért kihagyom, és rátérek a StreamSpeech szolgáltatás működésének ismertetésére. Ahogyan a 19. ábra is mutatja, a mobil kliens adatkapcsolat (pl. GPRS, EDGE, stb.) segítségével kapcsolódik az interneten keresztül a szerverhez, majd elküldi a szervernek a szintetizálni kívánt szöveget és a szintézisre vonatkozó beállításokat (nyelv, minőség, hang típusa, beszéd sebessége, stb.). Az autentikációhoz a kliens az egyedi IMEI vagy Bluetooth azonosítóját használja. A szerver azonosítja, hogy az adott kliens jogosult-e a StreamSpeech használatára, és hogy milyen felhasználói csoportba tartozik, továbbá beállítástól és a felhasználóval kötött szerződéstől függően a szerver eltárolja a kliens felöl érkező adatokat (vagy azok egy részét), majd a szerver kiválasztja a beállításoknak megfelelő szöveg-beszéd átalakító rendszert, és a szöveget nyers audió formátumú beszéddé alakítja. Ezek után a szerver a hanganyagot MP3 kódolással tömöríti, majd a kódolt anyagot vagy egy stream-ben küldi vissza a kliensnek, vagy pedig eltárolja egy ideiglenes helyen egy webszerveren, ahonnan a kliens HTTPS (Hypertext Transfer Protocol Secure, HTTPS) kapcsolaton keresztül tölti le. A kliens akár HTTPS-en keresztül, akár stream-en keresztül fogadja a hanganyagot, mindkét esetben buffereli, majd lejátssza azt. Jelenleg a kliens-szerver kommunikációt XML alapú web szolgáltatással (Web Service, [11]) oldottam meg, a hanganyagot pedig TCP/IP stream-en vagy HTTPS-en keresztül küldi a szerver a kliensnek. A jövőben az összes kommunikációt TCP/IP alapú stream-ekkel és HTTPS-el fogom megoldani, így Symbian alapú mobil eszközökre is egyszerűbb lesz a szolgáltatás implementálása. A
többnyelvűség
támogatása
érdekében
a
StreamSpeech
kiegészítő
szolgáltatásaként a szerveren tárolt konfigurációs fájlokat is letölti a kliens. Ezek a konfigurációs fájlok a kiválasztott nyelven tartalmazzák a menüpontokat, továbbá a kötöttés félig-kötött szöveg adatbázisainak a tartalmát. Jelenleg a kliens ezen adatokat is XML web szolgáltatások segítségével tölti le.
58
Mobil → szerver: szöveg (string), beállítások Szerver → mobil: szintetizált beszéd
Bázisállomás
Szerver 1. TTS 2. TTS
n. TTS
Mobil kliens
Internet
Adatbázis 19. ábra - A StreamSpeech szolgáltatás architektúrája
8.2.5. A rendszer által felvetett problémák A MonddKi második verziójának esetén is felmerülnek a 8.1.5. pontban ismertetett problémák. További nehézségeket vet fel a StreamSpeech szolgáltatás: •
Pénzügyi probléma
Mobil adatkapcsolat esetén a legtöbb esetben a le- és feltöltött adatmennyiség függvényében számláz a szolgáltató. A StreamSpeech próbálja MP3 kódolással minimalizálni a költségeket, azonban a szolgáltatás gyakori használata esetén sokba kerülhet az adatkapcsolat díja. Azonban várhatóan a mobil kapcsolatok árai is csökkenni fognak (egyes távol-keleti országokban a mobil internetezés díja alacsonyabb, mint hazánkban a vezetékes változaté). •
Sebességbeli probléma
Amennyiben
a
hálózat
jelentős
mértékben
terhelt,
késleltetéssel
és
csomagvesztéssel kell számolnunk. A probléma megoldása érdekében előnyös lehet QoS (Quality of Service) algoritmusokat használnunk. Erőforrás foglaló protokoll segítségével (Resource reSerVation Protocol, RSVP) hálózaton belül lefoglalhatjuk
59
a szükséges sávszélességet, hálózatok között pedig a DiffServ szolgáltatási osztályai segítségével adhatunk prioritást adatfolyamunknak. •
Személyiségi jogok
Ahhoz, hogy a felhasználók szokásairól adatokat tárolhassunk el a szerveren, a felhasználókkal szerződést kell kötni. A szerződés megkötése történhet a kliens szoftver első indítása alkalmával. Ebben az esetben a felhasználó megadhatja, hogy milyen adatokat hajlandó megosztani a szolgáltatóval, melyet a szolgáltató anonim módon, statisztikák készítésére használhat csak fel. Fontos odafigyelni, hogy a személyiségi jogok országonként változhatnak, így az esetleges lokalizáció során külön figyelmet kell fordítani a helyi törvényekre.
8.2.6. Jövőbeli tervek Az MonddKi alkalmazás mind Pocket PC alapú PDA, mind pedig Microsoft Smartphone készülékeken megfelelően működik. A közeljövőben szeretnénk felhasználói teszteket végezni beszédsérült emberek bevonásával. A tesztek során először megtanítanánk a beszédsérült embereket a MonddKi használatára, majd a rendszer mindkét változatát négy héten keresztül tesztelnék. Ez után egy, a MonddKi-vel kapcsolatos kérdőívet töltenének ki a felhasználók, mely fontos információkkal szolgálhat a program jövőjét tekintve, továbbá személyes konzultáció során ismernénk meg tapasztalataikat. A tesztek befejeztével az esetleg felmerülő hibákat javítani fogom, illetve az alkalmazást a beszédsérült felhasználók javaslatainak megfelelően módosítom. Ezen lépések után a mindennapi életben való használatra késznek tekinteném az alkalmazást, melyet természetesen a jövőben újabb verziók követnének.
8.3. Rendszer beszéd- és/vagy hallássérültek részére (Laptop, Tablet PC, asztali PC) Harmadik rendszerként a Windows alapú számítógépeken működő VoxAid PKI alkalmazást mutatom be. Igaz, hogy jelenleg a rendszer nem a klasszikus értelemben vett mobil eszközökön működik, azonban az előző két rendszerrel együtt egységet alkot20,
20
A VoxAid PKI-ben számos kiegészítő szolgáltatás is helyet kapott, továbbá beszédfelismerésre is alkalmas. A program moduláris felépítése miatt azonban a beszédfelismerő modul eltávolításával könnyen átalakítható csak beszédsérültek számára készült kommunikációs rendszerré.
60
továbbá a VoxAid PKI kiválóan működik akár a könnyen hordozható Tablet PC készüléken is. Jelen fejezetben röviden áttekintem a rendszer célját, felépítését és működését, továbbá megvizsgálom a rendszer mobil eszközökre való adaptálásának a lehetőségét.
8.3.1. A rendszer célja A hallás- és beszédsérült emberek az élet minden területén akadályokba ütköznek. A két kommunikációs csatorna hiánya olyan hátrányos helyzetbe hozza őket, ahonnan csak komoly elszántsággal, és megfelelő külső segítséggel tudnak továbblépni. A szájról olvasást csak kevesük tudja megtanulni, és nem minden szöveg és ember esetében képesek használni azt. Megfelelő száj- és arcmozgás szükséges ahhoz, hogy megértsék a közölt szöveg lényeget, és ez legtöbbször csak azok esetében sikerül, akikkel egyébként is sokat kommunikálnak. Jelenleg – amennyiben megengedhetik maguknak – jelbeszéd tolmács fordítja le a kézjeleket beszélt nyelvre, azonban ezt anyagi okok miatt általában csak a fontosabb eseményeken (pl. konferencia, előadás, nagyobb családi összejövetel, stb.) tudják igénybe venni. A hallás- és beszédsérült emberek számára a többi emberrel való kommunikációra léteznek áthidaló megoldások (pl. papírra, laptopba le-/beírni a szöveget), azonban ezek a módszerek telefonos beszélgetések lefolytatására alkalmatlanok. Jelen alkalmazás egy ISDN modem segítségével küldi és fogadja a hanganyagot (szintetizált vagy természetes „beszédet”) a telefonvonalról. A szoftver képernyője két fő részből áll: a bejövő és a kimenő szövegből. A bejövő szöveg-ablakban a beszédfelismerő modul által felismert szavak, mondatok jelennek meg, míg a kimenő szöveg ablakban a korábban megismert három lehetőség áll a felhasználó rendelkezésére (a szabad, a kötött, és a félig-kötött szöveg). A rendszer célja, hogy a hallás- és beszédsérült felhasználók telefonvonalon keresztül is tudjanak másokkal kommunikálni.
8.3.2. Problémafelvetés Kutatásom során nem találtam olyan kommunikációs segédeszközt, mely a beszédés hallássérült emberek számára beszédszintetizátor és beszélő-független beszédfelismerő segítségével lehetővé teszi a telefonálást. Magyarországon jelenleg az egyetlen telekommunikációs segítség a „Jelmondó”, a legnagyobb hazai vezetékes telefon vállalat
61
speciális szolgáltatása hallás- és beszédsérült emberek részére, melyet 2001-ben vezetett be. A szolgáltatás tulajdonképpen egy szöveges kommunikáció „beszéd gateway”-en keresztül. A szöveges kommunikációt vagy egy speciális készülékkel, vagy pedig egy számítógép és egy modem segítségével oldják meg, míg a „beszéd gateway”-t egy személy jelent, aki az írott szöveget beszéddé és a beszédet írott szöveggé alakítja. A telefontársaság nem számláz plusz költséget az egész nap rendelkezésre álló szolgáltatásért, mely igen fontos szempont a beszélni nem tudó emberek számára. A szolgáltatás hátránya, hogy a kapcsolás lassabb, mint egy normális telefonhívás esetén, személyes
jellegű
beszélgetésekre
nem
megfelelő,
a
távközlési
cég
számára
többletköltségekkel jár üzemeltetése és jelentős bevételt nem várhatnak tőle. A beszéd- és/vagy hallássérültek számára az ideális megoldást egy olyan rendszer jelentheti, mely segítségével könnyen, gyorsan, külső segítség nélkül a hagyományos telefonvonalra csatlakozva tudnak bármilyen típusú telefonkészüléket (akár mobil telefont is) felhívni vagy hívást fogadni, és a vonal túlsó végén lévő emberrel „beszélgetni”.
8.3.3. A rendszer felépítése A VoxAid PKI szöveg-beszéd átalakításának a részleteit nem mutatom be, mert azok igen hasonlóak a korábban megismertekhez, továbbá a rendszer összes funkcióját sem mutatom be. Csupán két szolgáltatást emelnék ki: a testreszabható felhasználói felületet, és a beszédfelismerő modult. A felhasználói felület igen jól testreszabható. A betűk színén, háttérszínén és méretén túl az egyes ablakok és ikonok elrendezését is beállíthatjuk. A beállításokat a program XML fájlban tárolja, minden felhasználói vezérlő (user control) esetén elmenti az elem pozícióját és méreteit. Ezt a fájlt tölti be, és ez alapján állítja be a képernyő elrendezését a VoxAid PKI induláskor. Ennek köszönhetően készíthetünk ún. preszeteket, melyek a képernyő egyedi elrendezéseit tartalmazzák. Így az egyes felhasználói csoportok számára különböző preszeteket adhatunk ki, melyeket saját igényeiknek megfelelően alakíthatnak tovább. Így a program felhasználói felülete, a forráskód újrafordítása nélkül jelentősen eltérhet különböző felhasználók esetén. A másik fontos funkció a beszédfelismerés lehetősége. A VoxAid PKI jelenleg a Beszédakusztikai
Laboratóriumban
kifejlesztett
beszélő-független,
kötött
szótáras
beszédfelismerő rendszert használja. Az automatikus beszédfelismerés összetett feladat, amelynek megvalósítására csak konkrét, jól meghatározott feltételek mellett van esély.
62
Még nagyon távol vagyunk az emberi hallás teljesítőképességétől, de még az emberek számára is megoldhatatlan feladat egy ismeretlen nyelven elhangzó hanganyag papírra vetése. Hasonlóképpen a gépi felismerőnek is szüksége van tanulásra – mind a nyelvi, mind az akusztikus információt valamilyen formában előre be kell vinnünk a rendszerbe. Ha egy nyelv szókészletének egy részével, hangjainak paramétereivel (spektrum, időbeli lefolyás) és kiejtési szabályaival megfelelő módon betanítunk egy gépi felismerőt, akkor az önálló szavakat, vagy akár hosszabb kifejezéseket is fel fog ismerni. Alacsony zajú környezetben a mai technológiával ez a beszélő személyétől függetlenül is megoldható, ha a kiejtés megközelíti az átlagosat. Azonban kötetlen, folyamatos beszéd felismeréséhez vagy a nagy háttérzajban történő felismeréshez szükségesnek látszik a nyelvi és tartalmi elemzés is, miként mi is csak azt ismerjük fel teljes bizonyossággal, amit meg is értünk. Ráadásul az emberi kommunikáció során többnyire maguk a beszélők sem fordítanak gondot a pontos és tiszta kiejtésre, eleve számítanak arra, hogy a hallgató a nyelvi ismeretei, valamint a tartalmi összefüggések alapján majd „kitalálja”, hogy mi is hangozott el [12]. Magyar nyelven ma még nem létezik folyamatos beszédfelismerő program, ezért a beszédfelismerő kötött szótárát úgy kell kialakítani, hogy az alkalmas legyen kötetlen beszélgetések lefolytatására. A telefon túlsó végén lévő felhasználó számára intuitív telefonos felhasználói felületet kell nyújtani ahhoz, hogy könnyen megtudhassa, hogy milyen szavak, szószerkezetek és mondatok felismerésére alkalmas a rendszer. A VoxAid PKI telefonhívás közben a grafikus felhasználói felületen kijelzi a vonal túlsó végéről jövő beszédet, a sikertelen felismerést és a lenyomott telefongombokat. Erre a felhasználó a szöveg-beszéd átalakító modul segítségével a korábban már ismertetett módokon válaszolhat.
8.3.4. A rendszer működése A rendszert az OTDK dolgozatomban
részletesen ismertettem [13], a
következőkben csupán a szöveg-beszéd, a beszéd-szöveg, a telefonos és a grafikus felhasználói felület együttműködését mutatom be. A TTS modul dinamikusan linkelt könyvtárként (DLL-ként) van a VoxAid PKI-ba beépítve. A felügyelt kód (managed code) tökéletesen együttműködik a Profivox nem felügyelt kódjával, csupán néhány függvény esetén kellett típuskonverziót végrehajtani a hívási paramétereken.
63
Az ISDN interfész az ISDN modemmel CAPI-n (Common ISDN Application Programming Interface, CAPI) keresztül, a CallCentre-rel pedig TCP/IP socketek segítségével
a 2605-ös porton keresztül kommunikál. A CallCentre része
a
beszédfelismerő modul. A VoxAid PKI és a CallCentre szintén TCP/IP socketek segítségével a 11111-es porton keresztül kommunikál egymással. A modulok kapcsolatát a 20. ábra szemlélteti.
VoxAid PKI sztring
szintetizált szöveg
üzenetek string raw audio
Profivox
parancsok
CallCentre
VoxAid PKI
ISDN interfész
CAPI
20. ábra - A VoxAid PKI és az általa használt modulok kapcsolata.
A
Budapesti
Műszaki
és
Gazdaságtudományi
Egyetem
Távközlési
és
Médiainformatikai Tanszékén kifejlesztett CallCentre nevű alkalmazás felelős a beszédfelismerés vezérléséért és a telefonálási funkciók biztosításáért. A VoxAid PKI és a CallCentre közötti kommunikációt saját osztály segítségével valósítom meg. Az üzeneteket bájt tömb formájában küldöm és fogadom. Az üzenetek egy része paraméter nélküli (pl.: PLAYABORT, PLAYABORTED, DTMFREC, stb.), míg a többit paraméterrel kell elküldeni, vagy paraméterrel érkezik (pl.: PLAY „fájlnév”, RECOGNIZED „felismert szó”, stb.). A VoxAid PKI indulásakor létrehozom a kapcsolatot a VoxAid PKI és a CallCentre között a System.Net.Sockets.TcpListener osztály segítségével, majd inicializálom a CallCentre-t. A VoxAid PKI telefonálás közben beszédfelismerő üzemmódba állítja a CallCentret, mely az emberi hang mellett folyamatosan figyeli, hogy nem jön-e DTMF jel. Amennyiben a telefonáló segítséget kér a telefongombok megnyomásával, vagy a felhasználó felolvastat egy szöveget, akkor a beszédfelismerést leállítja a VoxAid PKI a DTMFRECABORT üzenettel és beolvassa a telefonba a DTMF kódhoz tartozó szöveget.
64
A nyomógombokkal segítséget kérhet a telefon másik végén lévő felhasználó. A 2től 9-ig bármelyik gombot megnyomva a beszédfelismerés vagy a folyamatban lévő beszédszintézis megszakad, és a felismerhető szavakat kezdi el felolvasni a VoxAid PKI. Fontos ekkor blokkolt üzemmódba állítani a programot, melyből csak a PLAYED és DTMF üzenetek hatására lép ki, vagy lép tovább. Amennyiben a telefonvonal túlsó végén a korábban lenyomott gombot nyomják le ismét, akkor a következő betűre ugrik, amennyiben más gombot nyomnak le, befejezi a lejátszást és bekapcsolja a beszédfelismerést az alkalmazás. Ha a hallás- és beszédsérült felhasználó egy szöveget olvastat fel, minden ugyanígy zajlik, azzal a különbséggel, hogy bármely gomb megnyomása esetén leáll a beszéd. Amennyiben a beszédfelismerő modul felismerte a telefon túlsó végén lévő hanganyagot, a tartalomról a RECOGNIZED üzenet paramétereiben tájékoztatja a VoxAid PKI-t. Az alkalmazás mind a DTMF billentyűk lenyomását, mind pedig a felismert
szavakat, mondatokat a felhasználói felületen jelzi a beszédsérült ember számára. A VoxAid PKI program igen hasznos olyan emberek számára is, akik „csak” beszédképességüket vesztették el: a telefonvonalról a hangot a 11110 port-on keresztül küldi a CallCentre nyers audió formátumban a VoxAid PKI-nek 2048 bájt hosszú csomagokban, melyeket a System.Net.Sockets osztály segítségével fogadok. A bejövő adatokat bufferelem, és a program beállításaitól függően megszólaltatom a számítógép hangszóróin.
8.3.5. A rendszer által felvetett problémák A programozási nehézségekre dolgozatomban nem térek ki, hanem csak a beszédszöveg átalakítás szempontjából kritikus szótár kialakításával kapcsolatos problémákat ismertetem. Nehéz feladat kötetlen párbeszédekhez alkalmas kötött szótár kialakítása. Kompromisszumot kell kötni a szavak hossza, száma és a felismerés pontossága között. •
Minél hosszabb szavakat, szószerkezeteket, mondatokat használunk, annál pontosabb a beszédfelismerő. Azonban hosszú szóösszetételek esetén a telefon túlsó végén levő felhasználó nehezen jegyzi meg a lehetséges szószerkezeteket, és mindig segítséget kell kérnie, ami lassítja a kommunikációt.
•
A telefonvonal túlsó végén lévő felhasználó számára könnyebbséget jelent, ha rövid, hétköznapi szavakat is fel tud ismerni a beszédfelismerő motor. Azonban
65
minél több néhány szótagból álló szót használunk szótárunkban, annál nagyobb a valószínűsége annak, hogy összetéveszt két szót a beszédfelismerő motor. Öt-hat szótag felett válik igazán pontossá a beszéd-szöveg átalakító rendszer. Laboratóriumi tesztek alapján felépítettem és teszteltem egy kötött szótárat. A szótár valós életbeli használhatóságát a felhasználói tesztek fogják megállapítani.
8.3.6. Jövőbeli tervek Miután a VoxAid PKI alkalmazás néhány kisebb hibáját javítottam, a MonddKi-hez hasonlóan rátérek a felhasználói tesztekre. A felhasználói tesztek során egyrészt az alkalmazás, másrészt a beszédfelismerő szótár használhatóságát szeretném megállapítani. A visszajelzések alapján kijavítom a hibákat, és esetleg további felhasználói teszteket is elvégzek. Szintén fontosnak tartom az alkalmazás mobil eszközökre való átültetését. Mint azt a 8.1. és 8.2. fejezetben megismerhettük, a MonddKi alkalmazás működik PDA és Smartphone készülékeken, így a kritikus tényező a beszédfelismerő motor implementálása. Egyfelől problémát jelenthet a mobil eszközök alacsony teljesítménye, továbbá a legtöbb mobiltelefon a bejövő beszédet nem teszi elérhetővé a programok számára, mert az visszaélésre adna lehetőséget. Azonban így a beszédfelismerőnek sem lehetséges továbbítani a telefonvonalon érkező beszédet. A teljesítményről mérésekkel lehetne megmondani, hogy hány szó esetén ismeri még fel megfelelő sebességgel a szószerkezeteket a beszéd-szöveg átalakító. A bejövő beszédet pedig a mobilkészülék gyártók segítségével vagy a telefon operációs rendszerének alsórétegbeli működésének megismerésével és átírásával lehetne a beszédfelismerő számára elérhetővé tenni.
8.4. Pulzus érték kijelző grafikai és beszéd kimenetekkel (Windows Mobile, Symbian OS) A 8.4. fejezetben bemutatásra kerülő rendszer a BelAmi német-magyar kutatási és fejlesztési együttműködés részeként jött létre. A Dr. Gordos Géza és Dr. Dieter Rombach professzor urak vezetésével BelAmi (Bilateral German-Hungarian Research Collaboration on Ambient Intelligence Systems, BelAmi) német-magyar kutatói és fejlesztői munkában a kaiserslauterni Fraunhofer IESE, a Bay Zoltán Alkalmazott Kutatási Alapítvány, a Kaiserslauterni Műszaki Egyetem, a Budapesti Műszaki és Gazdaságtudományi Egyetem 66
és a Szegedi Tudományegyetem vesznek részt. A BelAmi célja környezeti intelligenciával (Ambient Intelligence, AmI) rendelkező rendszerek kutatása, tervezése és fejlesztése. A környezeti intelligencia kutatási területen belül a BelAmi elsősorban a járművezetés, a felügyelt otthon, a felügyelt gyártási folyamat és a felügyelt edzésterv eseteire koncentrál. Vizsgáljunk meg néhány példát, hogy milyen esetekben lehet hasznos a környezeti intelligencia az említett szakterületeken: •
"Smart Traveling": A járműben PDA készülék segíti a vezetést (forgalommal kapcsolatos információk, ajánlott útvonalak, ajánlott sebesség, stb.)
•
"Assisted Living": Az idős emberek életfunkcióit otthonukban szenzorok mérik, a mért értékek alapján egy monitor rendszer segíti a fontos értékeket (pl. szívritmus, vérnyomás, stb.) az ideális szinten tartani, illetve vészhelyzet esetén riasztani.
•
"Assisted Manufacturing": a rendelkezésre álló diagnosztikai eszközöket, kamerákat és szenzortechnológiákat integrálva olyan eszközöket lehet pl. mérnökök számára készíteni, mely hasznos információkat tartalmazó kijelzője akár a fejhez is rögzíthető.
•
"Assited Training": Egy professzionális kerékpárosokból álló csapat tagjai testének, teljesítményének és környezetének a változóit mérve valósidőben javaslatokat ad a rendszer, hogy a pillanatnyi állapotnak megfelelően melyik biciklista milyen pozíciót foglaljon el a csapaton belül. A javaslatokat a csapat edzője is figyelemmel kíséri. Én az utolsó kutatási és fejlesztési területben vettem részt, a felügyelt edzésben
(Assisted Training). Feladatom a mobil eszköz kommunikációjának megoldása volt Bluetooth-on keresztül egy központi egységgel, továbbá a mobil eszközön a központi egység felől érkező adatok grafikus megjelenítése, és a rendszer használatához szükséges beszédkimenet implementálása (a kerékpáros az adatokat headset-en keresztül hallja, a mobil eszköz például a zsebében van az edzés ideje alatt).
67
8.4.1. A rendszer célja A professzionális kerékpáros csapatok esetén igen nehéz és összetett feladat megállapítani, hogy milyen sorrendben kövessék egymást a csapat tagjai. További nehézséget jelent, hogy terheléstől, adott fizikai állapottól és a környezeti változóktól függően folyamatosan érdemes változtatni a csapattagok sorrendjét. A legnehezebb helyzetben mindig az első kerékpáros van, mert neki kell a legnagyobb légellenállást leküzdenie. Némely biciklisták teljesítménye lejtőn felfele, másoké lejtőn lefele, vagy sík terepen kiemelkedő. A rendszer célja, hogy a kerékpárosok szívritmusát, a pedálra nehezedő erőt, a kerékpár sebességét és a légellenállást figyelembe véve megállapítson egy optimális sorrendet (mely időben folyamatosan változik). Ezt a sorrendet a csapatot autóban követő edző egy számítógép segítségével figyelemmel követi, és amennyiben szükségesnek látja, módosítani tudja a sorrendet, üzeneteket tud küldeni a kerékpárosoknak – így felügyeli a rendszer döntésit, az edzés menetét. Feladatom a mobil kliens elkészítése volt, mely a környezeti változókról hang útján tájékoztatja a kerékpárost, ismerteti a központi egység javaslatait a biciklistával, továbbá kiegészítő funkcióként grafikusan kijelez minden elhangzott adatot. Így a rendszer és a felhasználó (biciklista) közötti interfész a mobil eszköz, és a rajta futó alkalmazás. Kutatási és fejlesztési munkám idején a rendszerben még csak a szívritmus mérése volt megoldva, így a kliens alkalmazás is csak erről tud tájékoztatást adni, azonban könnyedén kivitelezhető új értékek megjelenítése és felolvasása.
8.4.2. Problémafelvetés Alapvető kérdésként merült fel, hogy milyen platformot használjunk a kliens alkalmazáshoz. A döntés előtt megvizsgáltam a különböző Symbian szériákat (Series 60, 70, 80) és a Windows Mobile készülékeket. A központi számítógéppel való kommunikáció miatt csak olyan készülék jöhetett szóba, amely Bluetooth-képes volt. További szempont volt, hogy képes legyen az eszköz adatkapcsolat létesítésére (GPRS, EDGE, stb.), mely funkcióra a későbbi fejlesztések során szükség lehet. Fontos volt továbbá, hogy a készülék rendelkezzen fülhallgató kimenettel, hiszen a kerékpáros az üzeneteket hang útján kapja. További alapelvárás volt, hogy a készülék akkumulátora minél hosszabb időre lehetővé tegye a folyamatos számításokat, hanglejátszást és a vezeték nélküli kommunikációt.
68
A fenti szempontokat szem előtt tartva a Symbian Series 40 és 80 alapú Nokia 9500, és a Windows Mobile 2003 alapú T-Mobile SDA készüléket választottam. Mindkét készülék Bluetooth- és GPRS-képes, sőt, a Nokia 9500 támogatja az IEEE 802.11b (WiFi) szabványt, mely a rendszer későbbi továbbfejlesztése során előnyös lehet. Mindkét telefonhoz megfelelő minőségű fejhallgató csatlakoztatható, és paramétereik alapján nagy terhelés mellett is minimum 3-4 óra folyamatos használatra képesek. Beszéd kimenetként a Beszédakusztikai Laboratóriumban készített, előre eltárolt mondatokkal kiegészített német nyelvű számfelolvasót használtam. A számfelolvasó adatbázisa mellett a rendszerben használt üzeneteket is tartalmazza a hangadatbázis („Az ön pulzusa...”, „Az ön sebessége...”, „...túl alacsony.”, „...túl magas.”, „Kérem, csökkentse a terhelést!”, „Kérem, növelje a terhelést!”, stb.). A számfelolvasó program Windows Mobile készülékeken működött, de Symbian-os változata nem volt kész. A kliens alkalmazás kidolgozásán és fejlesztésén túl az én feladatom volt átírni a számfelolvasó programot Symbian operációs rendszerű készülékekre. A fejlesztés megkezdése előtt további kérdést vetett fel, hogy milyen programozási nyelven készítsem el a kliens alkalmazást. Először JAVA MIDP alapon szerettem volna implementálni a programot. A JAVA MIDP (Mobile Information Device Profile, MIDP) a JAVA keretrendszernek a mobil eszközökön futó, csökkentett képességű, erőforrás takarékos változata. Megvizsgáltam mind a Symbian, mind pedig a Windows Mobile rendszeren működő JAVA MIDP 2.0-t (JSR 118)21, mely ideálisnak látszott az alkalmazás fejlesztése szempontjából, hiszen segítségével ugyanazt a forráskódot mindkét eszközön fel tudtam volna használni. Kutatásom során azonban szembesülnöm kellett azzal, hogy az akkor aktuális Java Bluetooth API (JSR 82) nem tud megfelelően együttműködni a központi számítógép oldalán használt Bluetooth interfésszel a különböző mobil eszközökön. Így a választás végül Symbian esetén C++-ra, a Microsoft Smartphone esetén pedig a C#-ra esett. Symbian-nál a beépített Bluetooth API-t, Smartphone-nál pedig az OpenNETCF.org által kiadott, felügyelt kódban futó Bluetooth API-t használtam.
8.4.3. A rendszer felépítése Két részben ismertetem a rendszer felépítését: először az egész rendszer architektúráját, majd a kliens alkalmazásnak a rendszerhez való csatolását mutatom be.
21
Mobile Information Device Profile (MIDP), forrás: http://java.sun.com/products/midp/
69
Sebesség Szél Pulzus Pedál erő
Edző
21. ábra - A rendszer vázlatos felépítése (mért értékek: sebesség, szél, pulzus, pedálra ható erő)
A rendszer architektúrája
Minden kerékpáron található egy számítógép, a kerékpáros zsebében pedig egy mobilkészülék. A biciklin találhatóak a szenzorok, melyek a korábban ismertetett paramétereket mérik (21. ábra). A számítógépen a nyílt forráskódú, JAVA alapú JINI környezet fut.22 A JINI környezet segítségével könnyen lehet dinamikus elosztott rendszereket készíteni. Ez igen előnyös, hiszen a szenzorok lehet, hogy időnként nem elérhetőek (megszakad a kapcsolat), majd ismét rendelkezésre állnak. Ugyanilyen fontos a rendszer lehetséges kimeneteinek és adatbeviteli módjainak a dinamikus integrációja. A rendszerhez egyszerre több kimenetet és bemenetet is csatlakoztathatunk, melyek közül a rendszer a legnagyobb prioritásút választja ki. Kimenet lehet például egy LCD kijelző, egy Tablet PC a biciklista mellett haladó kocsiban, vagy a mobil eszközön a beszéd kimenet. Bemenet lehet egy egyszerű numerikus billentyűzet, a Tablet PC-n futó alkalmazás, vagy a mobil eszköz gombjai. A lehetséges ki- és bemeneteket nem a szolgáltatás neve (pl. keypad), hanem a szolgáltatási osztály (pl. InputService) alapján azonosítja a JINI
környezet. Amennyiben új eszközt csatlakoztatunk a rendszerhez, akkor az regisztrálja magát a megadott szolgáltatási osztályban, s így később könnyen lehet azonosítani. A kerékpárokon található számítógépek közül egy a mester, a többi szolga. Az adatokat a szolgák WiFi kapcsolaton keresztül a mester számítógépnek továbbítják, majd a mester az adatokat helyben dolgozza fel, vagy elküldi adatkapcsolaton keresztül (pl. GPRS) egy távoli szervernek, mely visszaküldi az eredményt. Az eredményeket a mester 22
Jini Network Technology, forrás: http://www.sun.com/software/jini/
70
szétosztja a szolgák között, és a szolga számítógépek pedig az aktuális kimeneti eszközön megjelenítik azt. Amennyiben az aktuális kimeneti eszköz a mobilkészülék, akkor Bluetooth vezeték nélküli kapcsolat segítségével továbbítja a szolga gép az adatokat. Lehetősége van a kerékpárosnak bizonyos paraméterek beállítására is, mely szintén megtehető a mobilkészülék segítségével, amennyiben a mobil eszköz az aktuális adatbeviteli forrás (lásd 8.4.4. fejezet). Jelenleg az a terv, hogy a szolga és a mester gépek Sony VAIO2 készülékek lesznek (lásd 22. ábra). Ezen készülékek mérete és súlya igen kicsi, azonban ez idő szerint sajnos csak a távol-keleten lehet megvásárolni őket.
22. ábra - Sony VAIO2
A mobil kliens és a rendszer kapcsolata
A mobil kliens és a kerékpárra szerelt számítógép között az adatátvitel Bluetooth vezeték nélküli kapcsolat segítségével történik. A legtöbb mobil eszköz, mely Bluetoothképes, a Bluetooth 1.1-et támogatja, így a Nokia 9500 és a T-Mobile SDA is. Mindkét esetben a Bluetooth API elrejti a Bluetooth bonyolult architektúráját [14], és a kapcsolat létrehozásához és az adatkommunikációhoz egy leegyszerűsített, stream alapú interfészt kínál. A Bluetooth 1.1 hatótávolsága 10 méter, mely jelen rendszer esetén bőven elegendő. A számítógépen és a mobil kliensen is meg kell adni a másik fél egyedi, 48 bites Bluetooth azonosítóját. Így biztosíthatjuk, hogy a mért adatok és a visszajelzések nem keverednek össze a csoport tagjai között. Amennyiben a JINI a mobil eszközt választja ki-, illetve bemeneti egységként, Bluetooth üzenettel jelzi azt. Amennyiben kimeneti egységként működik, a számítógép 500 ms-onként elküldi az aktuális értékeket, ha pedig bemeneti egységként, akkor a mobil eszköz 5000 ms-onként elküldi a beállításokat a számítógépnek. Első esetben az értékek gyors változása miatt érdemes gyakran küldeni az adatokat, a második esetben pedig azért 71
szükséges periodikusan küldeni, hogy a kapcsolat megszakadása esetén (pl. kikapcsol a telefon) gyorsan észlelje a hibát a JINI környezet, és másik adatbeviteli eszközre válthasson át. Az elosztott rendszer architektúrája szempontjából fontos, hogy az értékek elemzése a szolga vagy a mester számítógépen történik, soha sem a kliensen. Így lehet különválasztani a ki- és a bemeneti egységeket. Legyen például a bemeneti egység egy numerikus billentyűzet, a kimeneti egység pedig a mobil kliens. Ha a billentyűzet segítségével beállítunk egy minimum és egy maximum szívritmus értéket, akkor az értéket a bemeneti egység elküldi a szolga számítógépnek. A szolga számítógép folyamatosan fogadja a mért szívritmust, melyet elküld a kimeneti egységnek (jelen esetben a mobil kliens) és a mester számítógépnek. Amennyiben a pulzus magasabb, mint a maximum, vagy alacsonyabb, mint a minimum érték, a szolga számítógép külön üzenettel jelzi azt a kimeneti egységnek, tehát a mobil eszköznek; a mobil készüléken futó alkalmazás pedig rögtön – beállítástól függően – vizuális, hang és/vagy vibráló jelzéssel figyelmezteti a kerékpárost, hogy csökkentse vagy növelje a terhelést. A mobil kliens alkalmazást Pulse Monitor-nak neveztem el.
8.4.4. A rendszer működése A Pulse Monitor hasonló elven működik a Symbian alapú Nokia 9500 és a SDA Smartphone készülékeken. Mindkét esetben az alkalmazás először ellenőrzi, hogy be van-e kapcsolva a Bluetooth a készüléken23, és amennyiben igen, regisztrálja a Pulse Monitor Bluetooth szolgáltatást. Bluetooth kommunikáció esetén az egyik oldalon fut egy Bluetooth szolgáltatás (jelen esetben a Pulse Monitor), melyhez a másik fél kapcsolódik. Miután létrejött a kapcsolat, a két fél között socket alapú kommunikáció folyik. Amennyiben a mobil készülék a ki- és bemeneti eszköz, akkor folyamatosan, fél másodpercenként kapja a mért szívritmus értékét, és öt másodpercenként elküldi a beállított minimum és maximum értékeket. Amennyiben megszakad a kapcsolat, a Pulse Monitor újra inicializálja a szolgáltatást, és várja a másik felet, hogy kapcsolódjon hozzá.
A kapcsolat megszakadhat egyrészt átviteli hiba miatt, másrészt pedig azért, mert a JINI környezet más eszköznek osztotta ki a ki- és bemeneti szolgáltatást (pl. az autóban ülő
23
A Pulse Monitor esetén ajánlott a Bluetooth-t bekapcsolt, de nem "Discoverable" (felderíthető) állapotban hagyni, mert egyes mobil készülékek Bluetooth-on keresztül feltörhetőek. Amennyiben azonban a készüléket külső Bluetooth eszközök nem tudják megtalálni, kivédtük ezt a veszélyt.
72
edző a Tablet PC segítségével szeretné vizsgálni az adott kerékpáros fizikai és környezeti paramétereit). Symbian
esetén
az
alkalmazás
felhasználói
felületét
kezelő
kódrész
konstruktorában inicializálom a Bluetooth szolgáltatást. Két osztály felelős a Bluetooth kommunikáció megvalósításáért, az egyik az üzenet küldést és fogadást végzi, a másik pedig Bluetooth szolgáltatást kezeli. A szolgáltatás inicializálásakor regisztrálom a szolgáltatást és elkészítem a protokoll leírót (Protocol Descriptor). Ezután létrehozok egy socket-et, és amennyiben adat érkezik a socket-re, beolvasom és elemzem azt, hogy a Pulse Monitor számára jött üzenetről van-e szó. Amennyiben igen, az üzenetből kinyerem
az aktuális értéket, és továbbítom a beszéd és grafikus kimenet számára. Amennyiben adatbeviteli eszközként is működik a mobil kliens, egy ütemező öt másodpercenként elküldi a beállított értékeket. Ha a fogadó fél számára 15 másodpercig nem érkezik üzenet – és a bemeneti egység továbbra is a mobil készülék –, akkor kilép a fogadó üzemmódból, és újra próbál kapcsolódni a mobil klienshez. Ugyanez igaz a Bluetooth kapcsolat másik oldalán is: ha a Pulse Monitor három egymás utáni alkalommal nem tudja elküldeni az üzenetet, lebontja a kapcsolatot, majd újra inicializálja a socket-et, és várja a másik felet, hogy kapcsolódjon. Lehetséges, hogy a mobil készülék csak beviteli vagy csak kimeneti eszköz, ezért a rendszer hasonlóképp működik kimeneti üzemmódban is: ha a számítógép három alkalommal nem tudott adatot küldeni a mobil kliensnek, újra próbál kapcsolódni hozzá, és amennyiben a mobil kliens három alkalommal nem kapott adatot a megadott időintervallumon belül, akkor lebontja, majd újra megpróbálja felépíteni a kapcsolatot. A Windows Mobile alapú T-Mobile SDA esetén is hasonlóan működik a program. A különbségek a különböző programozási nyelvekből adódnak: a SDA esetén C#-ot, a Symbian esetén pedig C++-t használtam. Az OpenNETCF.org-nak köszönhetően a Bluetooth kommunikáció megvalósításához megbízható felügyelt osztály áll rendelkezésre .NET Compact Framework alatt C# nyelven. Ez esetben néhány függvényhívással létrehozom a szolgáltatást és a socket-et, és a program ezután már képes adatok fogadására és küldésére. További könnyebbséget jelent, hogy a .NET Compact Framework kivételkezelésnek (Exception handling) köszönhetően igen gyorsan és egyszerűen tudom jelezni, ha a kapcsolat megszakadt. A Pulse Monitorban alkalmazott számfelolvasó rendszer Windows Mobile készülékeken működött, azonban a Symbian OS-en futó változatát nekem kellett a meglévő forráskód alapján elkészítenem. A számfelolvasó C nyelvben volt megírva, így 73
először a forráskódot C++-ra kellett alakítanom, valamit el kellett készítenem a Symbian OS-re való fordításhoz szükséges állományokat ("solution" leíró bld.inf, "project" leíró MMP fájl). Néhány standard C függvényt nem támogat a Symbian C++ fordítója, ezek funkcióját saját függvényekben implementáltam. Ilyen például a char *_fcvt(double value, int count, int *dec, int *sign);
függvény, mely lebegőpontos számot karakterlánccá alakít. A számfelolvasó adaptálása során további problémát jelentett, hogy a Symbian OS esetén a hangkimenet kezelése teljesen különbözik a Windows Mobile rendszertől. A számfelolvasó a bemeneti szöveget elemzi, és a számítások alapján az adatbázisból előállít egy hullámformát a memóriában, melyet lejátszva szólal meg a kívánt szám vagy üzenet. Windows Mobile esetén a lejátszás a Winmm.lib (Windows Multimedia Library) könyvtárban található függvények segítségével történik. Symbian OS alatt újra kellett írnom a szövegfelolvasónak a hangkimenetet megvalósító részét. A Symbian OS alatt a hullámforma lejátszásához saját osztályokat hoztam létre, melyeket
részben
a
MMdaAudioPlayerCallback
és
a
CMdaAudioPlayerUtility
(MediaClientAudio.lib könyvtár szükséges hozzá) osztályokból származtattam. Az osztályok az 5.2. fejezetben ismertetett Symbian architektúrájának a „Multimédia moduljához” tartoznak. A NewL, NewLC, ConstructL függvényhármassal inicializálom a lejátszó
osztályomat,
a
NewDesPlayerL
segítségével
létrehozok
egy
CMdaAudioPlayerUtility osztályt. Az osztály létrejöttét a MMdaAudioPlayerCallback osztály MapcInitComplete callback függvénye jelzi. Ezután le tudom már játszani a hullámformát tartalmazó memóriaterületet, mely sikerességéről vagy kudarcáról a MMdaAudioPlayerCallback osztály MapcPlayComplete callback függvénye tájékoztat. A lejátszás működik, azonban a jövőben még meg kell oldanom, hogy aszinkron hívások esetén (több szálon futó programnál) ne indulhasson el addig új lejátszás, amíg az erőforrás le van foglalva. Ezt a funkciót az RMutex osztály segítségével fogom implementálni. Windows Mobile platformon a számok megjelenítésén túl grafikonon is megjelenítem a mért értékeket. A minimum és maximum érték beállítástól függően a program arányosan osztja fel a grafikont. Amennyiben a felhasználó a joystickot felfele nyomja, a grafikon mérete nő, a kijelzett számé csökken, ha lefele, akkor a kijelzett szám mérete nő, a grafikoné csökken (lásd 23. ábra). Továbbá ha a joystickot jobbra nyomja, akkor a grafikon felbontása csökken (nagyobb időintervallumon ábrázolja a mért
74
értékeket), ha pedig balra nyomja, akkor nő a részletesség. Ily módon a kerékpáros gyorsan tájékozódhat az edzés befejeztével az edzés közben mért értékekről. Ezen funkció Symbian OS alatt még nem készült el.
23. ábra - Pulse Monitor, skálázható megjelenés
8.4.5. A rendszer által felvetett problémák A mobil kliens alkalmazás több problémát is felvet. Mivel az adatátvitel vezeték nélküli, Bluetooth alapú, ezért létfontosságú, hogy a kommunikáció zavartalanul, megbízhatóan folyjon. A mobil eszközökben alkalmazott Bluetooth 1.1 sebessége 1.5 Mbps, ami a feladat számára bőven elegendő. Azonban számolnunk kell a környezeti zavarokkal is. Elméletben például egyéb Bluetooth eszközök megzavarhatják a kommunikációt, azonban nem találkoztam ilyen problémával. A CeBIT 2005 kiállításon méréseim alapján óránként több mint kétszáz Bluetooth-képes eszköz haladt el a rendszer mellett, de egyszer sem történt fennakadás. A biciklis környezetben természetesen ennél jóval kevesebb zavarral kell számolnunk. A Pulse Monitor-ban használt megbízható Bluetooth kommunikáció alapja, hogy egyszer párosítjuk a mobil készüléket és a számítógépet a 48 bites, egyedi Bluetooth azonosítójuk alapján, így működés közben egyszer sem kell felderítést (discovery-t) végrehajtanunk. Méréseim alapján felderítés esetén előfordulhat, hogy a felderítő készülékhez jóval közelebb eső Bluetooth eszköz (BT1) elnyomja a Bluetooth hatótávolságának a határán lévő másik Bluetooth eszköz (BT2) jeleit. Tehát a felderítés során csak BT1-et találjuk meg, de ha eltávolítjuk BT1-et a rendszerből, akkor látni fogjuk BT2-t (24. ábra).
75
10 m éter
éter 10 m
(b)
(a)
24. ábra - Bluetooth felderítési (discovery) „hiba”
Egyes tanulmányok szerint24 nagyon ritkán a WiFi is megzavarhatja a Bluetooth kommunikációt, azonban mind a WiFi, mint a Bluetooth kommunikációs protokollok robosztus hibadetektáló és javító mechanizmust tartalmaznak, így legtöbbször csak kis mértékben lelassul az adatátvitel, mely esetünkben a kevés adat átvitele miatt észre sem vehető. A CeBIT-en végzett méréseim során nem találkoztam a különböző vezeték nélküli technológiák interferenciájából adódó hibával. A Bluetooth kommunikációval kapcsolatosan további problémát vetett fel a Bluetooth soros viselkedése. Szerettük volna megoldani, hogy a kerékpáros Bluetooth, vezeték nélküli fejhallgatót használhasson, azon keresztül hallja a Pulse Monitor utasításait, információit. Azonban a mobil készülék egyszerre csak egy Bluetooth eszközzel képes kommunikálni, így ha a fejhallgatót csatoljuk a mobil eszközhöz (bound), akkor a kliens alkalmazás nem fogja tudni használni a Bluetooth-t. A Bluetooth következő verziója, a Bluetooth 2.0 gyorsabb adatátvitelt, gyorsabb válaszidőket, párhuzamos kommunikációt, nagyobb hatótávolságot és kisebb fogyasztást valósít meg. A Bluetooth 2.0 már megjelent, azonban mobil készülékekben még nem implementálták, így ameddig a mobil eszközök nem támogatják a Bluetooth 2.0-t, alternatív megoldásként vezetékes fejhallgatót használunk. Jelenleg a rendszerben csak a pulzusszámot mérik, így a kliens alkalmazás is csak ezen érték reprezentációjáért felelős. A jövőben több szenzorral fog működni a rendszer (sebesség, légellenállás, stb.), melyek értékeiről tájékoztatni kell a kerékpárost. Azonban 24 Wi-Fi™ and Bluetooth™ – Interference Issues, forrás: http://www.hp.com/rnd/library/pdf/WiFi_Bluetooth_coexistance.pdf
76
ha egyszerre több mint 4-5 paraméter értékéről szeretnénk informálni a felhasználót, gondosan meg kell terveznünk a beszédinterfészt. Legegyszerűbb megoldásként egymás után beolvashatjuk, hogy „Az ön aktuális... pulzusa... sebessége... szembeszél... stb.”, majd mindig a megfelelő helyen az aktuális értékeket. Azonban ha sok paraméter van a rendszerben, akkor ily módon nem lesz hatékony a beszédinterfész. Ezért mindenek előtt fontos a felhasználónak megadni a programból a lehetőséget, hogy mely értékek érdekesek a számára. Ekkor a kiválasztott paraméterek számától függően három szintet lehet megkülönböztetni: 1. Kevés paraméter (maximum 2-3) esetén a fent leírt módon, egymás után felolvastathatjuk a szöveg-beszéd átalakító programmal az értékeket, és hogy mire vonatkoznak. Ezek után hosszabb szünetet tartunk, hogy a kerékpárost ne terheljük folyamatos beszéddel. 2. Mérsékelt számú (5-6) paraméter esetén érdemes elhagyni a mondatrészeket, és csak rövid szavakkal jelezni, hogy mire vonatkozik az érték. Például: „Pulzus 98, sebesség 28, szembeszél 10, stb.”. Másik megoldás lehet, hogy az értéket és a hozzá tartozó mértékegységet mondatjuk ki. Például: „98 bpm, 28 km/h, 10 m/s, stb.”. Természetesen ez esetben lehetőséget kell adni a felhasználónak a segítség kérésre. Segítség kérés során az alkalmazás felsorolja név szerint is a paramétereket: „Pulzus 98 bpm, sebesség 28 km/h, szembeszél 10 m/s, stb.”. Így a kerékpáros könnyen megtanulhatja a sorrendből és a mértékegységekből, hogy melyik érték mire vonatkozik. Figyelni kell, hogy két paraméternek nem lehet azonos mértékegysége. Amennyiben ez mégis előfordulna, vagy az azonos mértékegységű értékek előtt fel kell olvasni, hogy melyik mire vonatkozik, vagy pedig a mértékegységeket úgy kell kialakítani, hogy ne legyenek azonosak (pl. két sebesség esetén az egyiket megadhatjuk km/h-ban, a másikat m/s-ban). 3. Sok (>6) paraméter esetén is javasolt az előző pontban ismertetett módszert alkalmazni, azonban ekkor már csak időnként érdemes a számokon túl bármi mást kimondatni. Például minden hatodik alkalommal ismereti a rendszer, hogy mire vonatkoznak az értékek („Pulzus 98, sebesség 28, szembeszél 10, stb.”), a többi esetben pedig csak az értékeket olvassa fel („98, 28, 10, stb”). A szöveg-beszéd átalakító gyorsításával lehet
77
javítani még a sebességen, azonban fontos ekkor odafigyelni, hogy magas fizikai terhelés mellett érthető maradjon a beszéd a kerékpáros számára (lásd 8.5. fejezet). Több mint egy paraméter esetén fel kell állítani egy prioritási sorrendet a paraméterek között, hogy amennyiben a paraméter értéke meghaladja a beállított maximumot, vagy alacsonyabb a minimumnál, akkor melyik paraméter esetén riasszon előbb. Például ha a kerékpáros szempontjából fontosabb, hogy a sebességet tartsa, mint a szívritmusbeli változás, akkor a mobil kliens először az alacsony sebességre, majd a magas pulzusra hívja fel a biciklista figyelmét.
8.4.6. Jövőbeli tervek A kutatás és fejlesztés nagy részét a Kaiserslautreni Műszaki Egyetem Környezeti Intelligencia laboratóriumában végeztem. A feladatommal időben készen lettem, és Hannoverben a CeBIT 2005 világkiállításon bemutattuk a rendszert. A kiállított rendszer egy kerékpárból, egy pulzusmérőből, egy LCD kijelzőből (kimeneti eszköz, numerikus érték kijelzése), egy Tablet PC-ből (ki- és bemeneti eszköz, numerikus érték kijelzése és grafikon rajzolása) és a mobil eszközből (ki- és bemeneti eszköz, beszédkimenet, numerikus érték kijelzése és grafikon rajzolása) állt; a kiállítás ideje alatt a rendszer jól, a mobil kliens pedig hiba nélkül működött. Hogy megállapítsuk, hogy a mobil eszközön milyen szöveg-beszéd átalakító rendszert a legérdemesebb használni, előkészítettünk egy kísérletet, melyről a 8.5. fejezetben részletesen beszámolok. A német-magyar közreműködés keretében jelenleg is folyik kutatói és fejlesztői munka annak érdekében, hogy a mobil kliens képes legyen beszédfelismerésre, így a biciklista beszéddel is be tudja állítani az értékeket, vezérelni tudja az alkalmazást.
8.5. Kísérlet A Kaiserslauterni Műszaki Egyetem Környezeti Intelligencia Laboratóriuma és a Budapesti Műszaki és Gazdaságtudományi Egyetem Beszédakusztikai Laboratóriuma Dr. Németh Géza egyetemi docens ötlete alapján közösen előkészített egy kísérletet, mely segítségével meg szeretnénk állapítani a különböző beszédszintetizátorok érthetőségét számfelolvasás esetén alacsony és magas fizikai terhelés mellett. A kísérlet megtervezésében és előkészítésében részt vett Dr. Németh Géza, Dr. Andreas Rausch, Dr.
78
Stephan Dutke, Dr. Thomas Jaitner, Dr. Bernd Schuermann, Marcus Trapp és jómagam. Feladatom a Beszédakusztikai Laboratóriumot képviselete, továbbá a német kollégákkal együttműködve
a
kísérlet
kidolgozása
és
előkészítése
volt
a
németországi
Kaiserslauternben. A kísérlet előkészítése befejeződött, a kivitelezésre a következő hónapokban kerül sor.
8.5.1. A kísérlet célja A kísérletnek három fő célja van: alacsony és magas terheltségi szinttől függően szeretnénk különböző szöveg-beszéd átalakító rendszerek esetén megállapítani a felhasználó egyéni preferenciáját, a felolvasott szöveg észlelését és megértését. Egyéni preferencia: meg szeretnénk vizsgálni, hogy különböző terheltségi szintek
esetén milyen típusú és minőségű beszédszintetizátorokat részesítenek előnyben a felhasználók. Az eredmények segítséget adnának annak eldöntéséhez, hogy a 8.4. pontban ismertetett mobil kliens esetén milyen szöveg-beszéd átalakító rendszert érdemes használni. Beszéd észlelése: különböző terheltségi szintek mellett eltérő lehet a felhasználó
„hallása”, alacsony terhelés mellett még lehet, hogy tisztán érti a számokat, de magas terhelés esetén már sokat tévesen észlel. A kísérletnek ezen részével meg szeretnénk állapítani, hogy magas terhelés alatt romlik-e, és ha igen, milyen mértékben a beszéd észlelése.
Szintén
vizsgáljuk,
hogy
hogyan
alakul
az
eredmény
különböző
beszédszintetizátorok esetén, és hogy van-e korreláció a beszédészlelés és az egyéni preferencia között. Beszéd megértése: elképzelhető, hogy a felhasználó észleli az adott szót, szavakat,
azonban azok tartalmával magas terhelés mellett már nincs tisztában, nem tudja a szöveget értelmezni. Ezért fontosnak tartottuk, hogy megvizsgáljuk alacsony és magas terhelés mellett, hogy mennyire értheti meg a felhasználó a különböző szöveg-beszéd átalakító rendszerek esetén a mesterséges beszédet.
8.5.2. A kísérlet részei A kísérlet két fő részből áll: a tesztalanyok egyéni teljesítményének a meghatározásából („Becslő fázis”) és a 8.5.1. pontban ismertetett pontok méréséből („Teszt fázis”). Mind a becslő fázis, mind a teszt fázis terembiciklin történik (lásd 25. ábra).
79
25. ábra - A kísérlethez felhasznált kerékpár
Becslő fázis (Evaluation phase)
Fontos megállapítanunk minden egyes tesztalany esetén, hogy mi az egyén alacsony és magas terhelési szintje, hisz ez minden ember esetén különböző. Pontatlan eredményt adna, ha minden ember esetén egy szívritmus érték tartozna az alacsony terheléshez, egy pedig a magas terheléshez. A legszembetűnőbb különbség a hétköznapi ember és a professzionális sportoló között van: a hétköznapi embernél terhelés esetén nő a szívritmus, professzionális sportolónál ideális esetben csökken. Természetesen az értékek egyénenként változnak. Az egyéni értékek meghatározása érdekében először a Conconi tesztet végzi el az összes tesztalany. A Conconi teszt segítségével állapítható meg az alanyok szívritmusa alacsony és magas terhelés esetén. A Conconi teszt bármely sport esetében kivitelezhető, mely során folyamatos fizikai terhelés éri az embert. A teszthez a sporteszközön (jelen esetben a kerékpáron) túl csak egy pulzusmérőre van szükség. A Conconi teszt során lassan növekvő terhelés mellett mérjük a tesztalany szívritmusát, míg az alany teljesen ki nem merül. A terhelést 500 méterenként növeljük. A teszt végére pontos adatokat kapunk az alany teljesítőképességéről, és a terhelés alatti szívritmus karakterisztikájáról. A Conconi tesztet egy 10 perces bemelegítő szakasz előz meg és egy 10 perces levezető szakasz követ.
80
Teszt fázis (Test phase)
A becslő fázist a teszt fázis követi. A kettő nem lehet egy napon, hogy az alanyoknak legyen idejük kipihenni magukat. A teszt fázis során mérjük a kísérlet szempontjából fontos információkat. A teszt fázis is két részre osztható: 1. Beszédészlelés, egyéni preferencia Százhúsz darab véletlenszerű számot (50 és 250 között) olvas fel a tesztalkalmazás. A számokat négy különböző szöveg-beszéd átalakító rendszer mondja ki. Két szám között véletlenszerűen 10..15 másodpercig várakozik az alkalmazás, hogy a tesztalany visszamondja az általa észlelt számot, melyet rögzít a program. A felvett hanganyagot összevetjük a felolvasott számmal, így meg tudjuk állapítani, hogy helyesen észlelte-e a beszédet a tesztalany. Továbbá nem csak a beszédészlelés megállapítására lesz jó a felvett hanganyag, hanem a beszédfelismerő betanításához is hasznos mintákat nyerünk. Az egyéni preferenciáról is ekkor gyűjtünk információt: a tesztalanynak miután visszamondta a számot, az érthetőséget osztályoznia kell 1-től 10-ig (1 - legrosszabb, 10 - legjobb). Amennyiben minden szám felolvasása 3 másodpercet vesz igénybe, legrosszabb esetben 36 perc hosszú lesz a kísérlet. 2. Beszédértés A beszédértés megállapításához az alany egyszerre két feladatot végez, így háromféleképp állapíthatjuk meg, ha fizikai terhelés során romlik az alany beszédértése: (a) csökken az első feladatban nyújtott teljesítménye, (b) csökken a második feladatban nyújtott teljesítménye, (c) a két feladat teljesítménye között bármilyen összefüggés észlelhető. Vizsgáljuk meg a két, párhuzamosan végzendő feladatot: Elsődleges feladat
A tesztalany azonos szöveg-beszéd átalakító rendszerrel képzett számpárokat hallgat. Két szám között 3 másodperc, két számpár között 10..20 másodperc telik el. Az esetek 50 százalékában a két szám azonos, az esetek 50 százalékában különböző. A tesztalanynak - miután elhangzott a két szám - a kerékpár kormányának jobb oldalára 81
szerelt gombok segítségével kell jeleznie, hogy azonos, vagy különböző számokat hallott-e. Összesen 60 számpárt olvas fel a mérő alkalmazás. Ha minden szám felolvasása 3 másodpercet vesz igénybe, maximum 29 perc hosszú lesz a kísérlet. A tesztet külön alanyokkal végezzük el alacsony, illetve magas terhelés esetén, továbbá két különböző beszédszintetizátort használunk a beszédértés vizsgálatához. Így összesen négy külön tesztalany csoportra van szükségünk, csoportonként minimum 15 emberrel. Másodlagos feladat
A tesztalanynak a kerékpár kormányának a bal oldalára szerelt gombot két másodpercenként kell lenyomnia végig a beszédértés mérése során. Az időzítés az emberek esetén fejben való számolással, vagy egy belső ritmussal hozható összefüggésbe, mely az emberi agy azonos részét terheli, mint a beszédfelismerés. Így az elsődleges és a másodlagos feladat azonos erőforrást használ, és feltételezhető, hogy az elsődleges, vagy a másodlagos feladatban bekövetkezett teljesítménybeli változás összefügg a másik feladat során nyújtott teljesítménnyel.
8.5.3. A mérési környezet Mindkét fázis esetén azonos helyszínen, a Kaiserslauterni Műszaki Egyetem területén folyik a kísérlet. A becslő fázis során egy szívritmus mérővel mérjük és tároljuk a tesztalany szívritmus karakterisztikáját. A mért adatokat minden mérés után a számítógépre másoljuk. A teszt fázis során egy erre a célra kifejlesztett alkalmazást használunk. Az alkalmazást a kísérlet megtervezése után fejlesztettem ki. A kísérlet során a következő adatokat szükséges eltárolnunk: •
Első szám értéke
•
Második szám értéke
•
Az alany válasza (azonos / különböző)
•
A második szám lejátszása és az alany válasza között eltelt idő [ms]-ban
•
A válaszok száma (lehet, hogy az alany többször nyomja le a válasz gombot)
•
A válasz helyessége (jól válaszolt-e az alany?)
•
A másodlagos feladat átlagos hibája (hány ms-al tér el a 2 másodperctől átlagosan)
•
Hangfelvétel a szünetekben
82
A kísérleti teremben két kerékpárt állítottunk fel, melyek kormányának a jobb oldalára egy kétgombos egeret, a bal oldalára pedig egy numerikus billentyűzetet erősítettünk (lásd 26. ábra). Az egér jobb gombja jelenti a pozitív, a bal gombja pedig a negatív választ. A numerikus billentyűzet segítségével végzi a tesztalany a másodlagos feladatot – két másodpercenként meg kell nyomni bármely billentyűt.
26. ábra - Bemenet az elsődleges (bal oldal) és a másodlagos (jobb oldal) feladat számára
8.5.4. A mérő alkalmazás A 8.5.3. pontban ismertetett paraméterek pontos mérésének érdekében készítettem egy mérőalkalmazást. Az alkalmazást .NET keretrendszer alatt, C# nyelven írtam. Hang ki- és bemenetként Bluetooth fejhallgatót használunk. A rendszerhez szükség volt különböző TTS rendszerek mintáira, melyeket vagy az egyes TTS rendszerek gyártóinak a honlapján található interaktív demo segítségével, vagy – amennyiben rendelkezésre állt – magával a szöveg-beszéd átalakító programmal készítettem el. A beszédészlelés és egyéni preferencia mérés során az alkalmazás különböző TTS rendszerekkel leképzett számokat játszik le, majd várakozik 10..15 másodpercet. A várakozás során az alkalmazás a mikrofonon keresztül bejövő hanganyagot WAV fájlban rögzíti. Ebben az esetben nem szükséges az előző pontban bemutatott összes paramétert mérni, elég időbélyeggel eltárolnunk a lejátszott számok értékét. A lejátszandó hangminták listáját szöveges fájlban adhatjuk meg. A beszédértés mérése során az alkalmazás figyeli a WM_LBUTTONDOWN (elsődleges feladat, az egér bal gombját lenyomták), WM_RBUTTONDOWN (elsődleges feladat, az egér jobb gombját lenyomták) és WM_KEYDOWN (másodlagos feladat, lenyomtak egy billentyűt) Windows üzeneteket, és amennyiben észleli valamelyiket, 83
időbélyeggel eltárolja azt. Méri továbbá a 8.5.3. pontban bemutatott összes paramétert, melyeket XML fájlba ment. Az XML fájl előnye többek között, hogy könnyen importálható táblázatkezelő programokba (pl. Excel), ahol az adatokat fel lehet dolgozni. A mérőalkalmazás által generált XML fájl a következő alakú: Elsődleges feladat + másodlagos feladat átlaghibája
Bálint Tóth Test phase - Numberreader Test 1. 197 <SecondNumber>197 False 2854 <ButtonsPressedCount>1 True <UserWereRight>False <MeanJitter>644 14 200506051516000977 200506051516020649 <SecondNumberPlayStart>200506051516050654 <SecondNumberPlayEnd>200506051516070246 200506051516100100 True ... ...
Másodlagos feladat
Bálint Tóth Test phase - Numberreader Test 1. <Tick> <Time>200506051516010638 13
84
<Tick> <Time>200506051516020890 13 ...
A mérőalkalmazás túl van a teszteken és a hibajavításon, a kísérlet kivitelezésre készen áll, melyre az elkövetkezendő hónapokban kerül sor.
9. Eredmények A 8.1. és 8.2. pontban ismertetett MonddKi és a 8.3. pontban bemutatott VoxAid PKI rendszerek használatra készen állnak. Jelenleg is keresünk együttműködő partnereket,
akiknek a segítségével javítani tudnánk az esetleges hibákat. A MonddKi alkalmazásról készült dolgozatommal a 2003-as kari TDK konferencián első helyezést értem el [15], a VoxAid PKI-ról készült dolgozatommal első helyezést értem el a 2004-es kari TDK konferencián, és második helyezést a 2005-ös OTDK konferencián [13]. A VoxAid PKI rendszert 2004. novemberében a Matáv PKI Tudományos Napok keretében mutattuk be, és a rendezvény kiadványában tanulmány jelent meg róla [16]. A MonddKi Smartphone-os verziójával első helyezést értem el a 2004-es Microsoft Imagine Cup magyar fordulóján. A MonddKi PDA-s változatával kapcsolatos kutatást és eredményeket nemzetközi konferencián közöltük [17]. A cikk alapján felkérést kaptunk, hogy írjunk egy fejezetet a "Intelligent Paradigms in Assistive and Preventive Healthcare" (kiadó: Springer, Németország) című 2006-ban megjelenő könyvben. A Pulse Monitor alkalmazás tökéletesen illeszkedik a jelenlegi professzionális kerékpárosok edzését segítő rendszerbe. A mobil klienst a hannoveri CeBIT 2005 során mutattuk be, ahol zavarkörnyezetben egy héten keresztül hiba nélkül működött. Ahogyan a 8.4.3. pontban ismertetett AmI rendszer tovább fejlődik, a Pulse Monitor-t is folyamatosan bővíteni fogom. A Pulse Monitor és jövőbeli kutatási és fejlesztési munkáink szempontjából igen fontos a 8.5. pontban ismertetett kísérlet eredménye. A kísérletet Dr. Németh Géza egyetemi docens ötlete alapján szoros együttműködésben dolgoztuk ki és készítettük elő a német kollégákkal Kaiserslautern-ben. A kísérletre a következő hónapokban kerül sor.
85
10. Jövőbeli tervek A MonddKi három, különböző előnyökkel és hátrányokkal rendelkező platformon használatra készen áll. A jövőben fel szeretnénk venni beszédsérült emberekkel a kapcsolatot, hogy megállapíthassuk a rendszer hiányosságait. A VoxAid PKI esetén is beszéd- és hallássérült felhasználókat keresünk, hogy segítségükkel a valós igényeknek megfelelően alakítsuk a beszédfelismerő kötött szótárát és az alkalmazás funkcióit. A hiányosságokat kiküszöbölve nagy segítséget jelenthet a két rendszer a beszéd- és/vagy hallássérült emberek számára. A BelAmi keretében is tovább folyik a kutatói és fejlesztői munka. A teljes rendszer első prototípusa várhatóan 2005. nyarának végére készül el. A 8.5. pontban ismertetett kísérletet is az elkövetkező hónapokban fogjuk elvégezni, mely jövőbeli kutatásokhoz is hasznos eredményekkel szolgálhat. A dolgozatom során ismertetett kutatási és fejlesztési munkáimat Ph.D. hallgatóként szeretném 2005. őszétől folytatni „Korszerű, beszédtechnológián alapuló infokommunikációs szolgáltatások” témában a Budapesti Műszaki és Gazdaságtudományi Egyetem Távközlési és Médiainformatikai Tanszékén.
11. Összefoglalás Dolgozatom elején bemutattam és elemeztem a jelenleg használt mesterséges beszédkeltési módszereket a mobil eszközök szempontjából, majd ismertettem a mobil készülékek rövid történelmét. Ezután két, korunk fejlett mobil eszközein futó operációs rendszert vizsgáltam meg: a Symbian OS-t és a Windows Mobile-t. A következő fejezetben a szöveg-beszéd átalakítás és az ember-gép kapcsolat szempontjából elemeztem a mobil készülékeket, majd megvizsgáltam a lehetséges felhasználói rétegeket, és ezen csoportok számára a lehetséges alkalmazásokat, rendszereket. A nyolcadik fejezetben rátértem az általam fejlesztett rendszerek ismertetésére. Először a beszédsérült emberek számára készült platform felépítését, működését, a vele kapcsolatos problémákat, és a lehetséges megoldásokat ismertettem. A nyolcadik fejezet második felében a BelAmi német-magyar együttműködés keretében Kaiserslauternben végzett kutatói és fejlesztői munkámat; a mobil eszközökön megvalósított beszédkimenet integrációját a professzionális biciklisták edzését segítő felügyelt rendszerbe, az ezzel kapcsolatos méréseket és a jövőben kivitelezendő kísérletet mutattam be. 86
Dolgozatom utolsó részében kitértem a tanulmányaim során elért eredményeimre, és röviden írtam jövőbeli terveimről is. Diplomamunkám célja a mobil készülékek, a mesterséges beszédkeltés és a felhasználó kapcsolatának a bemutatása és elemzése volt. Mindhárom csoport elemeinek vannak előnyei, hátrányai; kutatásom során elsődleges szempont, hogy a három csoport között megtaláljam azt az egyensúlyt, mely segítségével hasznos, jól használható rendszereket tervezhetünk meg és készíthetünk el. Az új technológiák új lehetőségeket rejtenek magukban, azonban a gyors fejlődés mellett mindig szem előtt kell tartanunk, hogy a gép van az emberért, és nem szabad több energiát befektetni, mint amennyit segít a rendszer. Az „okos-telefonok” esetén az ember-gép kapcsolat szempontjából igen fontossá válhat a beszédkimenet. Speciális (pl. fogyatékos embereknek készült) rendszerek és általános felhasználói réteget megcélzó mobil beszédalkalmazások igazolják, hogy van igény a grafikus felhasználói felületen túl beszédkimenetre is, azonban a mesterséges beszédkeltés mobil eszközökön még nagyon a kezdeteknél tart. Hasonlóan az újgenerációs mobil világ – azok az eszközök, melyek elég fejlettek komplex számítási műveletek és összetett rendszerek, beszédalkalmazások futtatására – is csak igen rövid múlttal rendelkezik. Fontosnak tartom, hogy a tudományterületet jobban megismerjem, keressek, és találjak megoldásokat, melyek megkönnyítik a fogyatékos és fogyaték nélkül élő emberek mindennapjait, melyek emelik az életszínvonalukat.
12. Köszönetnyilvánítás Köszönetemet szeretném kifejezni konzulensemnek, Dr. Németh Géza egyetemi docens Úrnak a téma felvetéséért, a tudományos kutatómunkába való bevezetésért és a folyamatos segítségért, melyet a kutatási és fejlesztési munkák, a tudományos dolgozatok és a pályázatok megírása során nyújtott számomra. Szeretném megköszönni Kiss Géza doktori hallgató kutatással és programozással kapcsolatos sok segítségét. Nagyon köszönöm továbbá családom szellemi támogatását és segítségét. Dolgozatom nagyapám, Dr. Gyires Béla matematikus emlékének ajánlom.
87
Irodalomjegyzék 1. Kempelen, F. Az emberi beszéd mechanizmusa, valamint a szerző beszélőgépének leírása, fordította Mollay Károly, Szépirodalmi Könyvkiadó, 1989. 2. a. Lemmetty, S. Review of Speech Synthesis Technology, Master's thesis, Helsinki University of Technology, 1999., 29-32 o.,
2. b. Lemmetty, S. Review of Speech Synthesis Technology, Master's thesis, Helsinki University of Technology, 1999., 32-37 o.,
3. Möbius, B. Corpus-Based Speech Synthesis: Methods and Challenges, Arbeitspapiere des Instituts für Maschinelle Sprachverarbeitung, University of Stuttgart, AIMS 6 (4), 2000., 87-116 o. 4. a. Prosise, J. Programming Microsoft .NET, Microsoft Press, 2002., 3-173 o. 4. b. Prosise, J. Programming Microsoft .NET, Microsoft Press, 2002., 603-659 o. 5. Parmod, G. MS SAPI 5 Developer's Guide, InSync Software Inc., 2001. 6. Velleman, E., Tol, R. van, Huiberts, S., Verwey H. 3D Shooting Games, Multimodal Games, Sound Games and More Working Examples of the Future of Games for the Blind, Proc. of Computers Helping People with Special Needs, 9th ICCHP, Párizs, Springer, 2004., 257-263 o. 7. Hunnicutt, S. The development of text-to-speech technology for use in communication aids, Applied Speech Technology, CRC Press, Inc., 1995, 547-563 o. 8. Blitz, C. K. Semantography, 2. kiadás, Semantography (Blissymbolics) Publications, Sydney, 1965. 9. Olaszi, P., Koutny, Y., Kálmán, S.L. From Bliss Symbols to Grammatically Correct Voice Output: a Communication Tool for People with Disabilities. International Journal of Speech Technology 5, 2002., 49-56 o. 10. Olaszi, G., Németh, G. VOXAID: An Interactive Speaking Communication Aid Software for the Speech Impaired, Proc. Eurospeech ’93 Volume 3, 1993, 18211824 o. 11. Wigley, A., Wheelwright, S. Microsoft .NET Compact Framework, Microsoft Press, 2003., 511-536 o.
88
12. Tatai, P., Gordos, G., Fegyó, T., Tatai, G. Kutatási eredmények az informatikában, Beszédtechnológia, VIII. Országos Neumann Kongresszus, 2003., 233-243 o. 13. Tóth, B. Távbeszélő készülék szimulálása hallás- és/vagy beszédsérült emberek részére, OTDK, Informatikai Tudományi szekció, 2005., 40 o. 14. Tanenbaum, A. S. Számítógép-hálózatok, Panem Könyvkiadó, 2004., 349-355 o. 15. Tóth, B. Mobil beszélő alkalmazások fogyatékos emberek részére, Budapesti Műszaki és Gazdaságtudományi Egyetem, Villamosmérnöki és Informatikai Kar, TDK, 2003., 57 o. 16. Kovács, J., Németh, G. Szolgáltatások a kapcsolattartásban korlátozottaknak, Felkészülés az új technológiák alkalmazására, Matáv Rt., 2004., 89-111 o. 17. Tóth, B., Németh, G., Kiss, G. Mobile Devices Converted into a Speaking Communication Aid, Proc. of Computers Helping People with Special Needs, 9th ICCHP, Párizs, Springer, 2004., 1016-1023 o.
89
