Pissarra multitàctil

PROJECTE FI DE CARRERA Títol: Pissarra Multitàctil Autor: Edmon Martínez Martí Titulació: Enginyeria Superior en Informàtica Director: Marta Fairen Gonzalez Departament: Llenguatges i Sistemes Informàtics Data: 18/01/11 PFC Pissarra Multitàctil Page 1 of 111 Índex de Continguts 1.Introducció..................................................................................................................................................................6 2.Objectius.....................................................................................................................................................................7 2.1Descripció del Projecte.........................................................................................................................................7 2.2Context del Projecte..............................................................................................................................................7 2.3Definició d'Objectius.............................................................................................................................................8 2.4Abast del Projecte..................................................................................................................................................9 3.Anàlisi d'Antecedents i Alternatives......................................................................................................................10 3.1Antecedents .........................................................................................................................................................10 3.1.1ReacTable......................................................................................................................................................11 3.1.1.1Funcionament.........................................................................................................................................11 3.1.1.2Cost........................................................................................................................................................12 3.1.1.3Especificacions.......................................................................................................................................12 3.1.2Jefferson Y. Han ..........................................................................................................................................13 3.1.2.1Productes................................................................................................................................................13 3.1.2.1.1Cost.................................................................................................................................................14 3.2Alternatives de Mercat.........................................................................................................................................15 3.2.1Promethean....................................................................................................................................................15 3.2.1.1Tecnologia..............................................................................................................................................15 3.2.1.2Software.................................................................................................................................................16 3.2.1.3Cost ...........................................................................................................................................................................16 3.2.2Smart Technologies.......................................................................................................................................17 3.2.2.1Hardware................................................................................................................................................17 3.2.2.2Software.................................................................................................................................................18 3.2.2.3Cost........................................................................................................................................................18 3.2.3ebeam............................................................................................................................................................19 3.2.3.1Hardware................................................................................................................................................19 3.2.3.2Software.................................................................................................................................................20 3.2.3.3Cost........................................................................................................................................................20 3.2.4Mimio............................................................................................................................................................21 3.2.4.1Hardware................................................................................................................................................21 3.2.4.2Software.................................................................................................................................................22 3.2.4.3Cost........................................................................................................................................................22 3.2.5Reflexió.........................................................................................................................................................23 4.Eines Utilitzades.......................................................................................................................................................24 4.1Software per al Processament d'Imatges i Detecció de Blobs............................................................................25 4.1.1BBTouch.......................................................................................................................................................26 4.1.2CCV (tBeta) - Community Core Vision.......................................................................................................26 4.1.3ReacTIVision................................................................................................................................................27 4.1.4TouchLib.......................................................................................................................................................27 4.1.5Touché...........................................................................................................................................................28 PFC Pissarra Multitàctil Page 2 of 111 4.1.6Funcionament del CCV.................................................................................................................................29 4.1.6.1Pantalla Principal...................................................................................................................................29 4.1.6.1.1Configuració....................................................................................................................................31 Consideracions FTIR:...............................................................................................................................31 4.1.6.2Pantalla de Calibratge............................................................................................................................31 4.1.6.2.1Configuració....................................................................................................................................32 4.2Protocol TUIO.....................................................................................................................................................33 4.2.1Conceptes bàsics...........................................................................................................................................34 4.2.2OSC...............................................................................................................................................................35 4.2.3TuioSimulator...............................................................................................................................................36 4.3Llenguatge de programació.................................................................................................................................37 4.4Entorn de desenvolupament.................................................................................................................................38 4.5Patrons de Disseny de Software..........................................................................................................................39 4.5.1Patró Singleton..............................................................................................................................................39 4.5.2Patró Observador...........................................................................................................................................39 4.6Software per la Interfície Gràfica: Qt.................................................................................................................40 4.6.1Signals i Slots................................................................................................................................................41 4.6.2Sistema d'Esdeveniments de Qt....................................................................................................................42 Com es reben.....................................................................................................................................................42 Com s'envien.....................................................................................................................................................42 4.7Software de Reconeixement Gestual....................................................................................................................43 4.7.1Grafiti............................................................................................................................................................44 4.7.2AME Patterns Library...................................................................................................................................44 4.7.3Sparsh_UI......................................................................................................................................................45 4.8Altres....................................................................................................................................................................46 4.8.1Microsoft Visio 7.0.......................................................................................................................................46 4.8.2Open Office...................................................................................................................................................46 5.Metodologia de Treball............................................................................................................................................47 5.1Planificació..........................................................................................................................................................48 5.1.1Qué és una iteració?......................................................................................................................................49 5.1.2Cicle de vida del RUP...................................................................................................................................50 5.1.3Reflexió.........................................................................................................................................................51 5.2C++ Coding Standards.......................................................................................................................................52 5.3Nom dels Fitxers:.................................................................................................................................................53 5.4Confecció del Subversion....................................................................................................................................54 6.Tecnologia Utilitzada...............................................................................................................................................55 6.1Tecnologies Tàctils..............................................................................................................................................55 6.1.1Superfícies Tàctils Basades en Resistència...................................................................................................56 6.1.2Superfícies Tàctils Basades en Capacitància................................................................................................57 6.1.2.1Panell Tàctil Basat en Capacitància de Superfície.................................................................................57 6.1.2.2Panell Tàctil Basat en Capacitància de Projecció..................................................................................58 6.1.3Superfícies Tàctils basades en Superfície d'Ona (SAW)..............................................................................59 6.1.4Superfícies Tàctils Òptiques (Optical Based Touch Surfaces)....................................................................59 6.1.4.1Frustrated Total Internal Reflection (FTIR)...........................................................................................60 6.1.4.2Diffuse Illumination (DI).......................................................................................................................61 PFC Pissarra Multitàctil Page 3 of 111 6.1.4.3Diffuse Surface Illumination (DSI)........................................................................................................62 6.1.4.4Laser Light Plane (LLP)........................................................................................................................63 7.Prototipus..................................................................................................................................................................64 8.Arquitectura del Software del Projecte.................................................................................................................65 8.1Casos d'Ús Significatius......................................................................................................................................66 8.2Vista Lògica.........................................................................................................................................................68 8.2.1Arquitectura del Software.............................................................................................................................68 8.2.2Vista..............................................................................................................................................................69 8.2.2.1La Recepció de les Dades......................................................................................................................69 8.2.2.1.1PMTuioListener..............................................................................................................................70 8.2.2.2L'Emissió de les Dades..........................................................................................................................71 8.2.2.2.1GestureEventHandler......................................................................................................................73 8.2.2.2.1.1Extensibilitat............................................................................................................................73 8.2.2.2.2ScribbleArea....................................................................................................................................74 8.2.2.2.2.1Extensibilitat............................................................................................................................75 8.2.2.2.3Scribbling Action............................................................................................................................75 8.2.2.2.4Esdeveniments Implementats..........................................................................................................76 8.2.2.2.5Extensibilitat...................................................................................................................................77 8.2.3Controlador...................................................................................................................................................78 8.2.3.1Reconeixement Gestual..........................................................................................................................79 8.2.3.1.1Sparsh_UI........................................................................................................................................79 8.2.3.1.2FIB-GestureServer..........................................................................................................................80 8.2.3.1.2.1GestureServer...........................................................................................................................81 8.2.3.1.2.1.1Interpretació .....................................................................................................................82 8.2.3.1.2.1.2Extensibilitat.....................................................................................................................82 8.2.3.1.2.2Group.......................................................................................................................................83 8.2.3.1.2.3Extensibilitat............................................................................................................................83 8.2.3.1.3Recepció i Gestió dels Esdeveniments enviats pel FIB-GestureServer..........................................84 8.2.3.1.3.1ClientController.......................................................................................................................85 8.2.3.1.4Extensibilitat...................................................................................................................................85 8.2.4Model............................................................................................................................................................86 8.2.4.1Informació sobre els Esdeveniments del Sistema..................................................................................87 8.2.4.2Informació relativa als Components......................................................................................................88 8.2.4.2.1Component......................................................................................................................................89 8.2.4.2.2Blackboard......................................................................................................................................90 8.2.4.2.2.1Extensibilitat............................................................................................................................90 8.2.4.2.3Toolbar............................................................................................................................................91 8.2.4.2.4Object..............................................................................................................................................91 8.2.4.2.4.1Modificacions Geomètriques dels Objectes:............................................................................92 8.2.4.3Classes Bàsiques....................................................................................................................................94 9.Pla de Desenvolupament del Projecte....................................................................................................................95 9.1Organització del Projecte....................................................................................................................................95 9.1.1Rols i Responsabiltats...................................................................................................................................96 9.1.2Suport ...........................................................................................................................................................96 9.2Planificació del Projecte.....................................................................................................................................97 9.2.1Elements a Implementar................................................................................................................................97 9.2.2Dates Límit i Mínims del Projecte................................................................................................................97 PFC Pissarra Multitàctil Page 4 of 111 9.2.3Planificació ...................................................................................................................................................98 9.2.3.1Etapes de la Implementació del Software..............................................................................................99 9.2.3.2Etapes de la Construcció del Prototipus...............................................................................................100 9.2.4Càlcul dels Costos.......................................................................................................................................100 9.2.4.1Cost de l'Aplicació...............................................................................................................................100 9.2.4.2Cost del Prototip...................................................................................................................................101 9.2.4.3Cost i Dedicació Total..........................................................................................................................101 10.Conclusions...........................................................................................................................................................102 10.1Resultats Obtinguts..........................................................................................................................................102 10.1.1En Quan al Sistema...................................................................................................................................102 10.1.2En Quan a la Metodologies de Treball......................................................................................................102 10.2Possibles Aplicacions......................................................................................................................................103 10.3Viabilitat del Projecte......................................................................................................................................103 10.4Línia de Treball a Seguir.................................................................................................................................104 10.4.1Software....................................................................................................................................................104 10.4.1.1Extendibilitat......................................................................................................................................104 10.4.1.2Independència Hardware....................................................................................................................104 10.4.2Hardware...................................................................................................................................................104 11.Agraïments............................................................................................................................................................105 12.Referències Bibliogràfiques ................................................................................................................................106 12.1Capítol 3. Anàlisi d'Antecedents i Alternatives...............................................................................................106 12.2Capítol 4. Eines Utilitzades.............................................................................................................................106 12.3Capítol 5. Metodologia de Treball..................................................................................................................107 12.4Capítol 6. Tecnologia Utilitzada.....................................................................................................................108 12.5Capítol 8. Arquitectura del Software i Extensibilitat......................................................................................108 12.6Capítol 10. Conclusions...................................................................................................................................108 13.Annex. Plantilles Utilitzades................................................................................................................................109 13.1Plantilla pels Fitxers .h....................................................................................................................................109 13.2Plantilla pels Fitxers .cpp................................................................................................................................111 PFC Pissarra Multitàctil Page 5 of 111 1. Introducció En aquest projecte, anomenat Pissarra Multitàctil, es dissenya un sistema que permet mitjançant una pantalla tàctil, simular la utilització d'una pissarra tradicional en la que s'accepten varis punts de contacte del/s usuari/s de forma simultània. Amb aquesta pissarra es pretén aprofitar les noves tecnologies multitàctils (que ja s'han vist en altres tipus de dispositius com els telèfons mòbils), per a facilitar la tasca d'ensenyament a les aules. Creiem que la configuració d'una pissarra és el suport ideal per a una pantalla d'aquest tipus, ja que és una superfície en la que poden escriure una o vàries persones al mateix temps amb els dits sense que aquesta posició sigui incòmode o estranya. La motivació d'aquest projecte és demostrar la viabilitat d'aquesta idea mitjançant la demostració del correcte funcionament de l'aplicació i la construcció d'un prototipus que sigui viable econòmicament (que és realitzarà en un projecte en paral·lel a aquest). Donat que aquest projecte ha estat realitzat per dos estudiants, s'han distingit les dues parts en què cadascun ha treballat més per a realitzar els documents de les dues memòries per separat, tot i que la separació més exacte d'hores i feines ve reflectida en el capítol Pla de Desenvolupament del Projecte. En aquesta memòria es descriu amb més en detall la part Software (i les seves funcionalitats), mentre que la part més tècnica i de construcció del prototipus s'explica amb més detall a la memòria del meu company Jorge Novoa Portocarrero. PFC Pissarra Multitàctil Page 6 of 111 2. Objectius 2.1 Descripció del Projecte Es vol dissenyar una primera versió d'una aplicació que funcioni amb una pantalla tàctil que permeti la interacció de varis punts de contacte de forma simultània. L'objectiu és potenciar el funcionament de la pissarra de guix tradicional aprofitant les possibilitats que donen les noves tecnologies multitàctils (varis usuaris al mateix temps, utilitzar varis dits de la mà) i les clàssiques tecnologies multimèdia, oferint d'aquesta forma, una manera eficient de treballar sense la necessitat de requerir dispositius addicionals (com reproductors de vídeo, televisors, etc). El projecte té una vessant Software, que inclou l'aplicació que permet actuar a partir dels gestos de l'usuari a la pissarra, i una vessant Hardware, que inclou el disseny i construcció d'un prototipus i els drivers necessaris per a permetre la interacció desitjada per a l'usuari. 2.2 Context del Projecte L'aplicació s'ha pensat per fer-se servir en l'àmbit de l'educació (primària, secundària, superior, etc.), malgrat podria utilitzar-se en un gran ventall d'àmbits. Segons això, els usuaris seran principalment professors i alumnes. És important tenir present que els professors no tenen perquè tenir coneixements i/o habilitats informàtiques. PFC Pissarra Multitàctil Page 7 of 111 2.3 Definició d'Objectius Els objectius que s'han marcat en aquest projecte són els següents: •Facilitar la tasca dels docents. ◦El dispositiu funcionarà igual que una pissarra tradicional (una vegada executada l'aplicació). ◦Es podran obrir continguts multimèdia en la superfície de la pissarra, moure'ls i redimensionar-los com es vulgui en qualsevol moment. ◦Aconseguir major eficiència en la gestió del temps (no hi haurà necessitat d'altres dispositius). ◦Evitar la necessitat de coneixements previs avançats d'informàtica. ◦Permetre la utilització d'Internet i altres tipus d'aplicacions mitjançant accions tàctils sobre la pissarra. ◦Augmentar la interactivitat professor-alumne en les classes. •Cost econòmic. ◦Estalviar en la compra de dispositius externs com podrien ser vídeos, reproductors de música, projectors, aules especials, etc. ◦Oferir una plataforma flexible que permeti la utilització d'aplicacions existents tàctils pensades per funcionar en qualsevol tipus de sistema operatiu i/o dispositiu tàctil diferent al nostre. ◦Estalviar en la formació dels usuaris del dispositiu. ◦Estalviar en el manteniment de l'aplicació. És important que el sistema sigui consistent per a que el manteniment sigui mínim, les actualitzacions hauran de fer-se de forma automàtica. •Aconseguir la independència de la tecnologia i Software existent. ◦El Software ha de ser totalment independent de la tecnologia utilitzada i del sistema operatiu amb que funcioni la màquina on s'executi. Això vol dir que l'aplicació que es dissenyarà ha de tenir la possibilitat de poder-se executar sobre qualsevol sistema existent (per exemple, una pantalla que utilitzi un llapis d'infrarojos). •Construcció del prototipus (paral·lelament a l'aplicació). ◦Estudiar la seva viabilitat. ◦Experimentar amb funcionament de la tecnologia utilitzada (FTIR - Frustrated Total Internal Reflection). ◦Comprovar la cohesió del sistema (Hardware i Software funcionant junts). •Proves amb el prototipus. ◦Mesurar el temps de resposta. ◦Mesurar el rendiment de l'aplicació segons la quantitat de punts actius a la pantalla. •Permetre extensibilitat. ◦L'aplicació a realitzar és un Software d'un prototipus, on es voldrà demostrar el potencial que podria tenir. Això implica que aquesta haurà de ser dissenyada tenint present que el producte final serà una base sobre la que treballar. PFC Pissarra Multitàctil Page 8 of 111 2.4 Abast del Projecte Aquest projecte es podria arribar a estendre molt més enllà del que es requereix per a un treball de final de carrera, així que ja des de l'inici s'ha establert quins serien els límits del projecte per a poder realitzar-lo en el temps disponible, tenint en compte que en la construcció de l'aplicació només hi participem dos persones. Com s'ha explicat en l'apartat anterior, l'elecció dels casos d'ús que implementarem s'ha realitzat pensant en demostrar el potencial que podria tenir aquest Software. L'abast d'aquest projecte es defineix per poder fer: A. Una aplicació que permet a l'usuari poder fer les següents accions sobre el dispositiu I. Escriptura. II. Esborrar escriptura mitjançant dos dits. III. Permetre a varis usuaris escriure i/o esborrar al mateix moment. IV. Obrir una imatge a la pantalla. a. Moure-la mitjançant un moviment d'arrossegament amb un dit. b. Redimensionar-la mitjançant el moviment de dos dits (separant-los o ajuntant-los). B. La construcció d'un prototipus que permeti comprovar la viabilitat del projecte. PFC Pissarra Multitàctil Page 9 of 111 3.2.1.2 Software •ActiveStudio. És un producte derivat de ActivePrimary ◦La principal característica és la de permetre a l'usuari preparar i presentar arxius mitjançant flipcharts (rotació de folis), que és un tipus de document que pot contenir una combinació de vectors i informació d'arrossegament de dades (línies, formes, text enriquit, vídeo, Flash Media, etc.) ◦Es poden fer anotacions en cada pàgina del flipchart mitjançant un llapis electrònic. ◦La versió 3 d'aquesta aplicació afegeix per primera vegada reconeixement gestual. •ActiveInspire. És una actualització del ActiveStudio en resposta al Notebook v10 de Smart (veure Apartat 3.3.2.2), les seves característiques principals són: ◦És multiplataforma (Windows, Mac i Linux) ◦S'han afegit eines avançades com figures intel·ligents i reconeixement d'escriptura a mà ◦Millor facilitat per a la creació de lliçons mitjançant plantilles temàtiques ◦Compatibilitat total amb Flash per a arxius .flv i objectes Flash ◦Es pot importar arxius de SMART i PowerPoint ◦Es pot exportar preguntes i respostes a format Excel pel seguiment ràpid del procés de l'aprenentatge. ◦Integració a la comunitat docent via Web de Promethean (Promethean Planet) •Altres. ◦ActivPrimary. És practicament idèntic al ActivStudio però pensat per classes de primària, la diferència recau en la interfície. ◦ActivStudio SE (Student Edition). Una versió amb funcionalitat reduïda. ◦ActivStudio Viewer. Només per visualitzar els flipcharts de l'ActivStudio. ◦ActivPrimary Viewer. Només per visualitzar els flipcharts de l'ActivPrimary. ◦ 3.2.1.3 Cost •Hardware. Els preus oscil·len entre els 1800$, 1400$ i 1200$ segons el tamany de la pantalla que escollim[9]. •Software. La versió més actual, ActiveInspire, es pot descarregar de forma gratuïta a la web oficial de Promethean[8]. PFC Pissarra Multitàctil Page 16 of 111 3.2.2 Smart Technologies Són els desenvolupadors de les SMART Boards, i són originaris de Calgari, Alberta, Canada. En aquest cas la pantalla és tàctil, tracta els tocs de la pantalla com si fossin esdeveniments de ratolí o de teclat. La majoria d'aquestes PDI només son capaces de treballar amb un punt cada vegada a la pantalla, però al Juny del 2009 es va introduir la capacitat de detectar-ne dos, això si, en llocs separats i definits de la superfície de la pissarra. Aquests dispositius accepten inputs a partir dels dits, un llapis digital especial o un objecte sòlid. Cada contacte amb la PDI és interpretat com un clic amb el botó dret del ratolí. La projecció sol ser frontal malgrat hi ha versions amb LCD o plasma. 3.2.2.1 Hardware •DVIT. És un Software de Detecció per Visió utilitzat per Smart Technologies (veure capítol sobre Tecnologies Utilitzades), és a dir, pertany a una altra companyia. Utilitza una càmera per a detectar i situar cada contacte realitzat sobre la superfície tàctil (sigui un dit o un dels llapis especials). •SmartBoard Pen Tray. El programari relacionat amb aquestes PDIs està preparat per a l'escriptura manual. En aquest cas els llapis i/o l'esborrador no tenen cap component electrònic, la tecnologia es troba a la safata on desem aquests elements. Cada vegada que agafem un llapis, un sensor òptic reconeix la seva absència, el Software de la SmartBoard processarà el següent contacte amb superfície de la pissarra d'acord al llapis que correspon a l'slot buit. Cada slot es pot programar amb un color diferent al nostre gust. En cas d'haver-se agafat varis llapis, sempre escollirà l'últim extret. •Tecnologia Resistiva. Les series 600, incorporen tecnologia resistiva (mirar capítol de Tecnologies Utilitzades). Figura 4: SmartBoard 685ix PFC Pissarra Multitàctil Page 17 of 111 3.2.2.2 Software Smart Notebook. Es pot fer servir en els sistemes operatius Windows, Mac i Linux i és una plataforma de visualització de continguts similar al Microsoft PowerPoint, és a dir, està dissenyada per a que els professors dissenyin les seves pròpies lliçons a partir de les eines i recursos disposats al programa. En el cas que ens toca, El Departament d'Ensenyament de la Generalitat té varis repositoris amb unitats didàctiques ja dissenyades per als professors. 3.2.2.3 Cost El cost variarà entre els preus que hem posat a continuació, segons el model escollit i característiques: •Hardware ◦SBD685ix. Versió més avançada, que és capaç de fer el seguiment de dos punts a la pantalla. Preu: 6199$ [11] ◦SB680. Smart Board més bàsica. Preu: 1999$ [11] •Software ◦Es pot descarregar gratuïtament de la web[10] , però només una versió de prova que funcionarà durant 30 dies, per desbloquejar-lo caldrà utilitzar un codi que estarà escrit en la PDI que ens obligaran a comprar. PFC Pissarra Multitàctil Page 18 of 111 3.2.3 ebeam És una PDI desenvolupada per Luidia que transforma qualsevol pissarra tradicional en una pissarra interactiva, cosa que la presenta com una de les opcions més econòmiques del mercat. El sistema ha estat incorporat a altres fabricants com: •3M. Digital Board •Hitachi. StarBoard •Legamaster. Eboard 3.2.3.1 Hardware Ebeam utilitza receptors d'infrarojos i ultrasons per fer un seguiment d'un llapis transmissor. Una unitat receptora acoblada a un dels costats de la pissarra, paret o superfície on vulguem escriure i determina la distància i la direcció d'aquest llapis utilitzant a la vegada els dos tipus d'informació que captarem (llum i so). Podem comprar els sistemes ebeam en tres modalitats: •ebeam projection: S'inclou el Hardware i Software per utilitzar en una imatge projectada de la pantalla de l'ordinador. El detector capta el que fem amb el llapis especial inclós i ho utilitza com si fos un ratolí convencional. •ebeam whiteboard: S'inclou el Hardware i Software per utilitzar amb els marcadors (guixos, rotuladors, etc.) de les pissarres convencionals. En aquest cas no hi ha cap imatge projectada (aquest sistema només se centra en la detecció de l'escriptura). El detector captarà els moviments que fem amb els marcadors mitjançant un dispositiu electrònic que posarem al seu voltant, registrant d'aquesta forma tot el que s'ha escrit a la pissarra en el nostre ordinador. •ebeam complete: Simplement els dos sistemes en el mateix pack. El detector es pot connectar al nostre ordinador utilitzant USB o Bluetooth (opció que haurem d'escollir abans de comprar-ho). Figura 5: eBeam PFC Pissarra Multitàctil Page 19 of 111 3.2.3.2 Software El Software relacionat amb aquest producte no està tan desenvolupat com en els casos anteriors, malgrat tot tenim: •Ebeam scrapbook. És el Software que ens permetrà desar la nostra feina. Ens proporciona un fons on podrem dibuixar, escriure, importa imatges i tot el que sigui necessari. Noves pàgines podran ser afegides i al final de la lliçó podrem desar-ho tot i exportar-ho a format pdf, pàgina web, bmp, jpg, tif, emf, ppt, o pps. •Software per permetre escriptura: EverNote S'ha de comprar a part, només pot escriure un usuari amb el llapis cada vegada. •Altres. Existeixen eines específiques per a: ◦Ser utilitzades amb fitxers de tipus PowerPoint. ◦Fer una captura de la pantalla per a ser desada. ◦Fer una gravació de les accions realitzades i passar-ho a format .avi (útil per a mostrar la solució a un problema). 3.2.3.3 Cost El principal avantatge d'aquest sistema és la facilitat per utilitza grans superfícies en contrast amb els sistemes que hem vist anteriorment. Amb connexió USB [15] •ebeam projection : 749.95$ •ebeam whiteboard: 749.95$ •ebeam Complete: 899.95$ Amb connexió Bluetooth [15] •ebeam projection : 949.95$ •ebeam whiteboard: 949.95$ •ebeam Complete: 1099.95$ PFC Pissarra Multitàctil Page 20 of 111 3.2.4 Mimio Mimio és la marca associada a una sèrie de productes destinats al mercat de l'educació, entre ells, els que s'encarreguen de captar els moviments que realitzen els usuaris sobre una superfície a l'hora d'escriure. Quan aquests dispositius son utilitzats junt amb un projector es pot transformar una pissarra tradicional en una pissarra digital interactiva. Els productes relacionats amb Mimio van ser originalment dissenyats per Virtual Ink, que era una companyia fundada pel MIT (Massachusetts Insitute of Technology) a l'any 1997, en resposta al concurs llençat per aquesta mateixa universitat “$50K Contest”, un concurs pensat per potenciar l'esperit empresarial dels seus estudiants. 3.2.4.1 Hardware La pissarra interactiva d'aquesta companyia utilitza una combinació d'ultrasons i rajos infrarojos per a situar els punt en el pla (cal utilitzar un llapis especial). És un sistema que utilitza la mateixa idea que l'ebeam però desenvolupat de forma totalment independent. Al igual que amb l'ebeam, podem aconseguir aquest sistema de PDI en tres modalitats: •Mimio interactive. Equivalent a “l'ebeam projection”. •Mimio capture. Equivalent a “l'ebeam whiteboard” però no s'inclou el hardware (el detector bàsicament). Una diferència amb el sistema ebeam és que podem registrar el que s'ha escrit a la pissarra a una memòria flash, sense la necessitat de tenir connectat un ordinador a la pantalla com en el cas de l'ebeam. •Mimio interactive + capture. Els dos anteriors junts. En aquest cas es pot connectar el detector via USB o Bluetooth. També podem fer-ho via wireless si comprem el mòdul de Hardware addicional. Figura 6: Mimio PFC Pissarra Multitàctil Page 21 of 111 3.2.4.2 Software En el cas de l'ebeam vam comentar que el seu Software no estava tan desenvolupat com en els casos de SMART i Promethean (que compten amb molts recursos ja implementats), en el cas de Mimio la situació teòricament encara és pitjor, segons la documentació que hem pogut consultar (està en procés de desenvolupament, és possible que s'hagin pogut llençar actualment més recursos relacionats). En el cas de Mimio tenim: •Mimio Notebook. Similar a la versió per ebeam. ◦Diferències: ▪ Visualment és més pobre, té una estructura similar a la de Windows (el fa més fàcil de fer funcionar). ▪Es pot fer una captura de només una secció de la pissarra. •Software de reconeixent d'escriptura: Recognise Ink Inclòs en el Notebook, s'ha d'escriure amb el llapis i només es pot una persona a la vegada. 3.2.4.3 Cost •Mimio Interactive. 729$ •Mimio Capture. 249$ •Mimio Interactive + Capture. 699$ Dades obtingudes a partir de www.shoolmart.com[19] PFC Pissarra Multitàctil Page 22 of 111 3.2.5 Reflexió Després de realitzar tota la investigació, no s'ha pogut trobar quin és el criteri del departament per triar el sistema de PDI a utilitzar, dóna sensació de aleatorietat. Això ha provocat que hi hagi presents en les aules nombrosos models de diferents marques, cosa que provoca que s'hagi d'utilitzar obligatòriament el seu Software i Hardware addicional, també afegeix més confusió i més hores de dedicació dels professors per a aprendre a utilitzar els dispositius amb tot el seu potencial, amb la qual cosa en alguns casos s'ha obtat per no utilitzar la PDI amb la qual cosa es perd totalment la inversió realitzada. En general les pàgines web de les empreses que proporcionen aquest material són molt específiques amb el que fan els seus productes (en quan a Hardware i Software), a causa d'això s'ha hagut de consultar nombrosos blogs per tenir una opinió crítica del producte i obtenir una descripció acurada de que és el que aporta i quines són les seves mancances. SmartBoard i Promethean tenen el Software més desenvolupat de tots els sistemes que s'han estudiat, i en contrast, es pot descarregar gratis des d'Internet. Basen els seus beneficis en la venta de dispositius electrònics (les seves PDI), cosa que contrasta amb la nostra idea de fer el Software sigui totalment independent del Hardware per a poder aprofitar qualsevol tipus de dispositiu preexistent (si és que aquests dispositius ho permeten, cosa que no està gens clara). Hi ha dos vessants clares en aquest mercat, un és el dispositiu tàctil (o interactiu) a utilitzar i l'altre és el Software, creiem que és un error voler fusionar les dos coses ja que limita molt les possibilitats. La capacitat multiusuari és molt limitada o inexistent, depenent de la marca. En primer lloc no tots els dispositius permeten detectar varis contactes amb la superfície tàctil i els que ho permeten tenen limitada la quantitat a tres tocs simultanis o l'àrea en que poden treballar cada persona. Creiem que aquí hi ha un camp molt ampli d'on treure un clar avantatge empresarial respecte tots els competidors existents. No totes les alternatives són tàctils, la major part d'elles tenen la necessitat d'utilitzar un llapis electrònic per a escriure o realitzar les accions que realitzaria una persona amb un ratolí al seu ordinador (l'opció d'escriptura manual ha estat introduïda recentment). La majoria de dispositius emulen el ratolí, és important que es pugui fer això, però al poder treballar amb varis dits a l'hora o inclús amb les dos mans per fer accions a la pantalla es poden crear noves formes d'interaccionar amb els widgets més intuïtives. Hi ha moltes empreses punteres a l'estranger investigant sobre això, però de moment encara no s'ha llençat cap versió al mercat, només prototipus experimentals. PFC Pissarra Multitàctil Page 23 of 111 4. Eines Utilitzades Si mirem la Figura 1 podem deduir fàcilment totes les eines que ens caldran per a desenvolupar la nostra aplicació: •Software per al Processament d'imatges i Detecció de 'Blobs' (Objecte brillant a la pantalla de dispositius multitàctils). Explicarem les possibilitats que teníem al nostre abast, quina hem escollit i perquè. •Protocol de Transmissió de Dades. En aquest cas no hem hagut d'escollir entre vàries opcions ja que la majoria de sistemes similars utilitza el mateix, el protocol TUIO. •Per a implementar la nostra aplicació necessitarem el següent: ◦Escollir el llenguatge de programació. ◦Escollir l'entorn de programació que utilitzarem. ◦Escollir el Software que utilitzarem per implementar la interfície gràfica per l'usuari. ◦Escollir el sistema de Reconeixement Gestual, per a interpretar el que volen fer usuaris. Imatge en brut Processament d’Images i Detecció de “Blobs” Aplicaciió PisarraMultitactil Protocol Transmissió de Dades Projector Llenguatge de programació Entorn de desenvolupament Llibreria gràfica Reconeixement gestual Figura 1: Estudi del procés realitzat al tocar la pantalla per trobar les eines necessàries. Apart de les eines ja citades també ens caldrà: •Triar un simulador TUIO que enviarà aquest tipus de missatges a la nostra aplicació simulant el comportament de la pantalla tàctil, per no dependre del dispositiu Hardware per a provar les funcionalitats que es vagin implementant (ja sigui perquè no estiguem al laboratori de treball o perquè no estigui finalitzat un prototipus funcional). •Escollir l'editor de text que s'utilitzarà per escriure la documentació. •Escollir una aplicació per a fer els diagrames de flux, d'UML, etc. PFC Pissarra Multitàctil Page 24 of 111 4.1 Software per al Processament d'Imatges i Detecció de Blobs Per a poder fer una aplicació multitàctil basada en la visió d'una càmera, necessitarem un programa que agafi aquesta senyal de vídeo i ens doni coordenades dels punts de contacte dels dits sobre la pantalla tàctil: Figura 2: Entrades i sortides del sistema. A partir de les coordenades i els seus esdeveniments corresponents (dit polsat, mogut o aixecat), la nostra aplicació interpretarà els gestos de l'usuari i farà les accions corresponents, això vol dir que es podrà utilitzar qualsevol aparell tàctil que ens aporti aquesta informació, l'aplicació és totalment independent de la tecnologia utilitzada. Arribats a aquest punt cal prendre decisions, ja que malgrat ser un camp molt verge, ja hi ha vàries opcions a triar: Triar millor Opció Processament d’Imatges i Detecció de “Blobs” BBTouch tBeta ReacTIVision TouchLib Touché Figura 3: Diagrama de decisió sobre el Software de Processament d'Imatges i Detecció de 'Blobs' En la Figura 3 hem fet un diagrama de flux amb la decisió amb la que ens hem hagut d'afrontar en aquell moment del transcurs del projecte, podem observar com hem marcat en vermell l'opció escollida, “tBeta”, o com l'anomenarem durant el transcurs de la memòria CCV (abreviació de Community Core Vision). La idea principal d'aquest apartat de la documentació és veure com hem arribat a aquesta decisió. En els propers apartats s'expliquen les característiques de cada una de les opcions i el perquè s'ha escollit finalment el “tBeta” i s'ha descartat la resta. PFC Pissarra Multitàctil Page 25 of 111 Processamentt d’Imatges i Detecció de Blobs Flux de Vídeo Coordenades i Esdeveniments 4.1.6.2.1 Configuració La pantalla de Calibratge ens mostra una xarxa de punts verds per tota la pantalla. Aquests són punts de calibratge que s'utilitzaran una vegada comenci el calibratge. Es poden afegir/treure punts de calibratge segons la mida de la pantalla, la fiabilitat del filtre infrarojos i la il·luminació de l'ambient. •Premeu "+" per afegir punts o "-" per treure'ls en l'eix X. •Mantenir premut “shift”, Premeu "+" per afegir punts o "-" per treure'ls en l'eix Y. Hi ha una caixa blanca (delimitador) que envolta els punts de calibratge. Si no coincideix amb l'àrea que volem fer servir de la pantalla, s'ha de modificar per arribar a tenir la posició que es desitja. Arribat a aquest punt, comencem el calibratge pressionant la tecla “c”. Figura 6: Calibratge Un cercle vermell es mostrarà per sobre dels punts de calibratges (un punt a la vegada). Pressionem cada punt “seguint” al punt vermell fins que tots els punts de calibratge es pressionen. Si es comet un error, premeu "r" per tornar al últim punt de calibratge. Si hi ha blobs fals, premi "b" per recuperar el fons de pantalla. Un cop finalitzada el calibratge, la pantalla tornarà a la pantalla inicial (veure Figura 4) i es pot provar seva la precisió pressionant a l'àrea de toc que s'ha escollit en el Procés de Calibratge. PFC Pissarra Multitàctil Page 32 of 111 4.2 Protocol TUIO La definició d'aquest protocol intenta donar una forma de comunicació versàtil entre un dispositiu tàctil i les capes de controlador i domini de les aplicacions que vulguem desenvolupar. Va ser dissenyat per treballar sobre superfícies multitàctils, on l'usuari es capaç de manipular un conjunt d'objectes i/o fer gestos utilitzant els dits [1]. En aquest projecte, TUIO és el pont de comunicació entre el CCV (tBeta) i l'aplicació desenvolupada. En resum, aquest protocol s'utilitza per comunicar la posició, la mida i la velocitat relativa dels blobs. Figura 7: Diagrama sobre el procés realitzat per veure com s'utilitza el protocol TUIO PFC Pissarra Multitàctil Page 33 of 111 4.2.1 Conceptes bàsics Per entendre el funcionament d'aquest protocol cal veure com es guarda la informació i quin serà el mecanisme de comunicació entre el dispositiu i l'aplicació. El diagrama de classes que utilitzarà el protocol per representar la informació és el següent: TuioPoint TuioContainer TuioCursor TuioObject Figura 8: Diagrama de classes del protocol TUIO, extret de la seva API[2] Aquestes classes seran les que continguin la informació que utilitzarem a l'aplicació: •TuioPoint: És una classe abstracta que conté les funcions comuns de les classes TuioCursor i TuioObject que són les que contenen la informació més concreta dels objectes disposats sobre la superfície tàctil. •TuioContainer: Conté els atributs comuns de les classes TuioObject i TuioCursor. •TuioObject: És la classe que conté la informació sobre objectes amb fiducials (o marques amb patrons definits) col·locats sobre la superfície tàctil, per tant tindrem atributs referits a l'angle, velocitat de rotació, etc. Figura 9: Patrons utilitzats per a fer el seguiment dels objectes amb fiducials. •TuioCursor: És la classe que conté la informació de punts col·locats sobre la superfície tàctil, la utilitzarem per obtenir la informació de les coordenades dels nostres dits quan pitgem la pantalla. S'assignarà un únic ID a cada punt i no es proveirà informació sobre la rotació com en el cas del TuioObject. PFC Pissarra Multitàctil Page 34 of 111 Les classes principals que permeten la comunicació entre el dispositiu i l'aplicació són: •TuioServer: Aquesta classe és l'encarregada de codificar i enviar els missatges TUIO, aquests, seran enviats via OSC (Open Source Control, veure Apartat 4.2.2) sobre UDP cap a l'adreça IP i ports especificats. En el nostre cas, aquest estarà definit al CCV. •TuioClient: Serà l'encarregat de descodificar el missatge enviat pel TuioServer. La instància d'aquesta classe generarà esdeveniments TUIO que seran transmesos a totes les classes que implementaran la interfície TuioListener. Aquest TuioListener s'haurà d'afegir de la següent forma: TuioClient *client = new TuioClient(); client->addTuioListener(myTuioListener); client->connect(); •TuioListener: Consisteix en una interfície de C++, pels menys experimentats en aquest llenguatge podríem dir que seria una espècie de classe abstracta que ens dóna les capçaleres de les funcions que utilitzarà el TuioClient per enviar els esdeveniments rebuts del TuioServer. Per tant, caldrà definir un arxiu .h i un .cpp que implementi la classe TuioListener com es mostra en el següent exemple: public class MyTuioListener implements TuioListener ... Si es vol tenir més detalls de la implementació del “Listener” en la nostra aplicació és recomanable consultar les següents classes al codi font del projecte. •PMTuioListener.h •PMTuioListener.cpp •main.cpp 4.2.2 OSC Sempre que parlem del protocol TUIO escoltarem a parlar del OSC (Open Source Control) [3]. Podríem definir-lo com un format de codificació binària per a poder a comunicar els nostres ordinadors amb sintetitzadores de so, i/o altres dispositius multimèdia (en el nostre cas el dispositiu tàctil). Els missatges codificats en aquest format poden ser transportats per Internet utilitzant paquets UDP. TUIO és un protocol de comunicació implementat amb aquest format de codificació, i el major avantatge que ens dóna OSC en aquest context és la seva simplicitat i velocitat de transmissió necessàries per a implementar dispositius com el que volem utilitzar. PFC Pissarra Multitàctil Page 35 of 111 4.2.3 TuioSimulator Per a poder implementar la part Software del projecte ha estat imprescindible la utilització d'aquest simulador, ja que ens permetia comprovar el correcte funcionament de l'aplicació sense la necessitat de tenir llest el prototipus. En la Figura 10 podem veure un exemple de com s'utilitza, en concret s'està comprovant el bon funcionament del moviment d'esborrar (en color vermell per poder veure els canvis per pantalla, en la versió final seria del mateix color que el fons). La finestra petita és el nostre simulador, allà simularem amb el ratolí els moviments a comprovar, evidentment no podrem moure dos punts a la vegada però això no limita que es puguin fer proves totalment vàlides de les funcionalitats que s'estan fent. En aquest cas el moviment d'esborrar es realitza amb dos dits, aquest moviment calcula un punt mitjà entre els dos punts, així que el que farem serà generar el moviment d'esborrar amb dos punts (un després de l'altre) i després només mourem un per veure que es pinta a la pantalla amb la posició mitjana de tots dos. El que fa el simulador és enviar els mateixos missatges TUIO que enviaria el nostre dispositiu. Figura 10: Exemple d'ús del simulador. En aquest cas s'està provant l'acció “esborrar”. PFC Pissarra Multitàctil Page 36 of 111 4.3 Llenguatge de programació Tots els llenguatges de programació tenen els seus punts forts i els seus punts febles, així que realment no hi ha cap millor que l'altre, malgrat tot això, seguint els objectius marcats a l'inici del nostre projecte la nostra elecció ha estat el C++ [4]: •És un llenguatge orientat a objectes. Característica imprescindible del qual només queda descartat el C (ja que gairebé tots els llenguatges de programació existents actualment suporten aquest paradigma). Necessitem que el llenguatge sigui OO per la facilitat que dóna per a la implementació al separar les funcionalitats a cada classe per separat. •Les aplicacions implementades en aquest llenguatge poden anar més ràpid. En una aplicació Software MT on tenim varis punts simultanis dels que s'ha de fer seguiment e interpretació en temps real. •És un llenguatge que treballa a més baix nivell que la majoria dels existents: ◦Ens permet fer una programació més sofisticada i flexible. ◦En teoria això fa que sigui més difícil d'utilitzar per la gent inexperta, però no suposa cap problema en el nostre cas. •Pot funcionar sobre qualsevol tipus de plataforma (Windows, Linux, etc). No volem ser depenent de cap tipus de sistema operatiu (perquè l'aplicació tingui la màxima flexibilitat en quan a la seva utilització). En aquest punt va quedar descartat el C#, ja que és un llenguatge de programació estandarditzat per Microsoft com a part de la seva plataforma .NET pensada per a operar en el sistema operatiu de Windows. •El servidor de reconeixement gestual que anàvem a utilitzar (Sparsh_UI) estava en aquest llenguatge. D'aquesta forma podríem estalviar molt de temps en entendre el contingut i funcionament d'aquest complement existent. •És un llenguatge conegut per nosaltres. L'havíem fet servir anteriorment junt amb altres llenguatges molt semblants com són el Java o C#. En aquest punt vam descartar possibilitats com per exemple el Python o el ActionScript3. PFC Pissarra Multitàctil Page 37 of 111 4.4 Entorn de desenvolupament Una vegada ja tenim decidit el llenguatge de programació que utilitzarem s'ha de decidir quin entorn de desenvolupament utilitzar per a programar la nostra aplicació. Eclipse [5] va ser la primera opció inicialment, ja que l'havíem utilitzat en anteriors ocasions amb experiències molt positives (malgrat aquestes foren utilitzant Java i no C++). De fet, Eclipse és un dels entorns de desenvolupament més populars i utilitzats en el món de Java, per poder-lo utilitzar treballant en altres llenguatges (com en el nostre cas) cal estendre la seva funcionalitat mitjançant plugins. Fins aquí cap problema, la veritable dificultat amb la que es va trobar va ser cercar i executar un compilador que generés els nostres fitxers binaris, en Linux, normalment solen estar instal·lades les comandes gcc i g++, en Windows la cosa és complica, ja que ens caldrà instal·lar aquestes comandes i per executar-les haurem d'utilitzar una espècie d'emuladors de Linux com són MinGW o Cygwin. Després de dedicar moltes hores, es va presentar l'opció d'utilitzar el Visual Studio, amb la qual cosa es va acabar descartant l'Eclipse per la dificultat que suposava fer servir aquest entorn amb el C++ juntament amb Windows. D'aquest entorn hi destaquem la facilitat d'ús en Windows per a la programació en C++ (ja que en aquest cas no cal instal·lar cap compilador, sinó que ja ve integrat), i a més, els companys del Centre de Realitat Virtual de la UPC, que són els que ens van aconsellar fer servir aquest entorn i podien ajudar en cas de tenir cap dubte. Com a estudiants de la FIB tenim llicència per a poder-nos instal·lar i utilitzar aquest programa en els nostres terminals de treball, d'aquesta forma va quedar descartada una de les principals raons per no fer servir Software de Microsoft que és l'alt cost econòmic per a utilitzar les seves aplicacions. PFC Pissarra Multitàctil Page 38 of 111 4.5 Patrons de Disseny de Software Els patrons de disseny són la base per a la cerca de solucions comunes a problemes en el desenvolupament de Software. En aquest projecte n'hem utilitzat dos tipus [6]: El Singleton , i l'Observador. En aquest apartat aprofundirem en cadascun d'ells. 4.5.1 Patró Singleton És un patró dissenyat per a restringir la creació d'objectes que pertanyin a una classe. Es proporciona una única instància gràcies a: •La pròpia classe és l'única responsable de crear una única instància. •Permet l'accés global a aquesta instància mitjançant un mètode d'aquesta classe. •Declara el constructor de classe com a privat per a que no sigui instanciable directament. Figura 11: Patró Singleton [7] 4.5.2 Patró Observador És un patró on un objecte, anomenat subjecte, manté una llista d'objectes dependents d'ell, anomenats observadors, i notifica automàticament qualsevol canvi en el seu estat a tots aquests. El que es busca és desacoblar classes que simplement estiguin a l'espera d'un canvi d'estat d'una altra, augmentat així la modularitat del llenguatge i al mateix temps evitant bucles d'actualització. Figura 12: Patró Observador [8] El patró observador ja està implementat en la majoria de llibreries de programació, aquest projecte, que fa servir Qt, utilitza el seu model de Signal i Slots. PFC Pissarra Multitàctil Page 39 of 111 4.6 Software per la Interfície Gràfica: Qt En aquest punt no ha calgut fer cap estudi previ per fer una elecció entre varies candidates, la nostra elecció ha estat clara: QT [9]. És una biblioteca multiplataforma per a desenvolupar interfícies gràfiques d'usuari i programes sense interfície gràfica com eines de consola i servidors. Funciona en totes les principals plataformes i té un ampli recolzament. L'API de la llibreria compta amb mètodes per accedir a les bases de dades mitjançant SQL, per utilitzar XML, gestió de “threads”, suport en xarxa i una API multiplataforma unificada per a la manipulació d'arxius i una multitud d'altres mètodes per al manegament de fitxers a més d'estructures tradicionals de dades. Es distribuïda sota termes de GNU Lesser General Public License i és un Software lliure i de codi obert. A nivell personal, ja havíem treballat amb aquesta llibreria cursant l'assignatura de VIG, sumat al consell de la nostra tutora, no va donar cap dubte sobre quina llibreria gràfica calia utilitzar. És important mencionar i explicar dos eines importants de Qt en aquest apartat, un és el sistema de Signals i Slots, que és la implementació en aquesta llibreria del patró Observador (veure Apartat 4.7, Patrons de Software), que ens servirà per a fer les notificacions sobre canvis d'estat en les dades. L'altre és el sistema d'esdeveniments de Qt. En els apartats següents, ambdós eines estaran explicades en profunditat. PFC Pissarra Multitàctil Page 40 of 111 4.6.1 Signals i Slots Aquest sistema és utilitzat per a la comunicació entre objectes [10]. És una de les parts més importants de les que forma Qt i probablement la més diferent respecte altres implementacions d'altres llibreries gràfiques o eines destinades al mateix fi. Un Senyal (Signal) és emès quan es produeix un cert esdeveniment. Els widgets de Qt tenen molts senyals predefinits però sempre podem fer subclasses de widgets per definir els nostres propis senyals. Un Slot és una funció que es crida en resposta a un particular senyal, i de forma anàloga al que hem explicat amb els senyals, podem fer els nostres propis slots si no volem utilitzar els que ja estan redefinits (que serà el més comú ja que la nostra aplicació generarà esdeveniments de Qt creats per nosaltres). Figura 13: Exemple de funcionament del sistema de Signals i Slots Totes les classes que heretin de QObject o alguna de les seves subclasses (per exemple QWidget) poden contenir Signals i Slots. Els senyals seran emesos per objectes quan canviï el seu estat i aquest canvi sigui interessant per a altres objectes. En la Figura 13, podem observar el funcionament d'aquest sistema de comunicació entre objectes, mitjançant la funció “connect” podem connectar senyals a tants slots com desitgem o necessitem. Inclús seria possible connectar signals a altres signals (que emetria una segona senyal immediatament després de l'emissió de la primera). PFC Pissarra Multitàctil Page 41 of 111 5.1 Planificació Durant el transcurs de la carrera hem cursat assignatures que tractaven el problema relacionat amb la forma més eficient de començar a programar sense acabar en un fracàs total, la més destacable podria ser PESBD. D'aquí ens va venir la idea d'utilitzar algunes de les pautes del RUP (Rational Unified Process) , que és una espècie de metodologia aconsellada per a la implementació d'una aplicació de Software i ho vam perfeccionar finalment amb algunes de les nocions que teníem del SCRUM. Figura 1. Fases del RUP A la Figura 1 es mostra un quadre que representa la metodologia de desenvolupament de Software RUP. Durant el transcurs d'aquest capítol s'explicaran els conceptes necessaris per entendre el contingut d'aquest quadre i entendre d'aquesta forma com funciona aquest sistema. PFC Pissarra Multitàctil Page 48 of 111 5.1.1 Qué és una iteració? Iteració: Totes aquelles activitats destinades a desenvolupar alguna part tangible i/o executable d'un projecte Software. En totes les definicions que hem trobat sobre que vol dir iterar, es referien a l'entrega (al final de cada iteració) d'una part “utilitzable” del que seria el resultat final. Això té cert sentit tenint en compte que el fet de passar per totes les fases de disseny del projecte farà sortir tots aquells problemes que poden romandre ocults durant les primeres fases de disseny, anàlisi i requeriments del projecte. Aquesta definició funciona a la perfecció excepte en les primeres fases del projecte, on és molt difícil obtenir quelcom que es pugui executar i que funcioni. En aquest cas vàrem intentar posar-nos objectius que, encara que no fossin executables i funcionals, ens servissin igualment per a avançar cap a l'objectiu principal. Un exemple és millor que mil paraules, aquests són els objectius que ens vam posar a la nostra 11a iteració: •Redactar Informe del nostre PFC. •Compilar i executar “Sparsh-UI” (una part feta que volíem integrar dins el nostre projecte). •Arreglar Software Arquitecture Document (SAD). •Fer una primera implementació del domini dissenyat sobre el paper (sense executar). •Fer revisió del document sobre el prototipus de la pantalla tàctil. Podem observar que no hi ha cap resultat tangible en aquests objectius, però si que eren uns resultats assolibles que podíem aconseguir en aquest moment del projecte. S'ha de dir que dins aquest exemple hem omès el que són les “fases” de les que consta una iteració, que és un concepte que explicarem una mica més endavant en en l'apartat 2.2 d'aquest capítol. Una pregunta important que un es pot fer després de llegir el que s'ha explicat fins ara és la següent: Què es guanya fent iteracions? •Clarament ajuda molt a veure els progressos que es van fent cada cert període de temps, ja que sobretot al principi del projecte un té la sensació que es passa moltes hores sense aconseguir cap i molt pocs progressos a canvi. Quan un tanca cada iteració s'adona realment del que s'ha aconseguit. •Tenir una millor noció de la capacitat de treball del grup. S'aconsegueix cada vegada ajustar millor els objectius de forma assolible i en el nostre cas veure com va el treball respecte el dia de la lectura del projecte. •Es pot detectar fàcilment els casos de poc progrés en el treball, i anima a la gent a treballar dur en la seva tasca, ja que en tot moment és conscient de la feina que fan els demés i a l'inrevés. •En el nostre cas, ens ha ajudat a tenir el tutor al dia de la feina que anàvem fent. Tots aquests guanys han estat segons el nostre punt de vista, i creiem que malgrat vam perdre un temps a entendre el concepte i vam anar aplicant-ho mitjançant assaig-error, els resultats finals han estat molt positius. En quan a la duració de cada iteració, el que diu el RUP és que cada iteració ha de durar fins que s'aconsegueixin objectius marcats, nosaltres en quest punt hem preferit estimar que cada iteració fos de dos setmanes tal i com és fa amb l' SCRUM (on a la iteració se l'anomena “sprint” però ve a ser el mateix concepte). De fet, seguint aquesta altra metodologia àgil, el que fèiem era informar-nos constantment de l'estat de treball de l'altre company de projecte per tal d'evitar que s'endarrerissin les tasques previstes. Tot i això a vegades sorgien imprevistos que provocaven que no s'assolissin els objectius, llavors el que vam fer va ser fer-ho constar en el document de tancament de la iteració i replantejàvem tots els objectius previstos per a la següent. PFC Pissarra Multitàctil Page 49 of 111 5.1.2 Cicle de vida del RUP En aquest apartat descriurem el tipus fases de desenvolupament de les que costa un projecte, cada iteració contindrà varis tipus d'aquestes fases segons el moment en que es trobi el projecte. Figura 2. Cicle de vida del RUP En la Figura 2 podem veure les quatre fases de les que consta cada iteració, el gràfic simbolitza la dedicació total a cada una de les fases com a mitjana (malgrat pot variar segons el tipus de projecte), si suméssim la dedicació a cada una de totes les iteracions realitzades. Abans de continuar comentant el gràfic passarem a comentar que es fa en cada fase: •Inception (Inici): Serà on es definirà el projecte pròpiament. Dins aquesta fase hem realitzat les activitats que corresponen a la motivació del projecte, sortida econòmica, i la descripció detallada de quin és l'objectiu i el cas d'estudi del projecte, etc. Activitats essencials: ◦Formular l'abast que tindrà el projecte. En aquest moment és on hem estudiat totes les possibilitats del projecte i hem decidit quines funcionalitats s'implementarien i quines no (tenint en compte la seva importància). ◦Sintetitzar un esborrador de l'arquitectura del sistema. Fer una primera aproximació ja que encara no està molt clar l'assumpte en aquest punt. ◦Preparar l'entorn del projecte. En aquest punt hem hagut de decidir les eines que hauríem d'utilitzar, per exemple: sistema operatiu, editor de programació, llenguatge de programació, etc. Tota aquesta feina de decisió es troba dins del capítol Eines Utilitzades. •Elaboration (Elaboració): El principal objectiu d'aquesta fase serà refinar el model d'arquitectura del sistema proposada a l'apartat anterior. En el que és el RUP trobarem moltes referències a estudiar l'evolució de l'arquitectura per evitar errors i d'aquesta forma pèrdues econòmiques i si es farà o no en el temps estipulat. En el nostre cas aquestes coses no tenen tanta importància, però hem de ser conscients de la feina que fem quan hem d'afegir una nova funcionalitat al nostre sistema com podria ser “obrir la imatge a la pissarra” correspondrà a aquesta fase. Serà aquí on ens trencarem la closca per fer quadrar la nova “peça” dins el nostre gran “puzzle” que serà la nostra arquitectura. També correspon a aquesta fase la feina de confeccionar les plantilles que utilitzarem en la documentació (veure Annex). •Contruction (Construcció): És la feina pròpia de desenvolupament del projecte, picar el codi i comprovar que funciona correctament. En el RUP es tenen en compte moltíssimes més coses i totes en referència al control, crític quan el temps i els diners marquen el destí del projecte, en el nostre cas per raons evidents aquests controls no faran falta (a més sent un projecte on només intervenen dues persones, sense grans equips de treball). PFC Pissarra Multitàctil Page 50 of 111 •Transition (Transició): En el nostre projecte només seran les feines de revisió de la feina feta amb el tutor, fer la última versió de l'aplicació, la confecció d'aquesta memòria i la preparació de l'aplicació. No afegim al projecte l'estudi d'usabilitat, per tant no ens caldrà obtenir les opinions dels usuaris, ho considerem, però és una tasca que estaria bé fer en un futur. Una vegada sabem que vol dir i que és fa en cada fase podem tornar a mirar el gràfic de la Figura 2 i entendre perquè normalment els projectes tenen aquesta distribució en hores de feina (on la major part del treball dur és fa a la fase de construcció). Ara bé, s'ha de dir que en el nostre cas ha estat una mica diferent, posant també gran pes d'hores en les fase d'elaboració i inici, en gran part a causa de la nostra inexperiència en la realització d'aquest tipus de projectes. 5.1.3 Reflexió Després de llegir aquest apartat un es podria fer la següent pregunta, i tot això de les fases quina utilitat té? Un tendeix a pensar inicialment que seria més fàcil començar a barallar-se amb el codi directament (bé, és el que quasi tothom fa), nosaltres tampoc teníem gaire idea de la utilitat real d'aquesta metodologia però després d'haver-ho fet servir creiem que l'experiència ha estat molt positiva. Enumerem els avantatges a continuació: •Ajuda a organitzar-se molt millor cada tipus de feina sobretot a l'inici del projecte que és quan un va més perdut. •Al marcar uns passos en ordre dins de l'operativa evita errors que significarien una gran pèrdua de temps en el futur (o sigui, que en realitat estem estalviant temps en comptes de perdre'l). •A mida que van passant les iteracions un es va adonant que cada vegada són menys les feines d'inici i elaboració i més les relacionades amb la construcció, d'aquesta forma es va essent conscient de l'estat en que es troba el projecte i s'és més capaç de predir i/o ajustar-se als terminis marcats. •Ajuda molt a planificar les feines de cada iteració. PFC Pissarra Multitàctil Page 51 of 111 5.2 C++ Coding Standards En un projecte és important marcar una pauta comuna de treballar amb el codi, és una forma de sentir que un està treballant en el mateix “camp de joc” que els seus companys. Els estàndards que hem utilitzat s'han desenvolupat a partir de les experiències en molts tipus de projectes Software, per part de moltes i diferents companyies i després de moltes setmanes de discussions entre els diferents grups de treball que els van confeccionar. Tot el codi implementat segueix un seguit de normes que ens donen una guia sobre com anomenar a les funcions, als atributs de la classe, plantilles per redactar els fitxers “.h” i “.cpp” (veure Annex), etc. Tot està explicat en detall dins de la següent direcció web: Http://possibility.com/Cpp/CppCodingStandard.hml#descriptive Intentant respondre a la pregunta sobre què ens pot aportar el seguiment d'aquests estàndards a l'hora d'implementar qualsevol aplicació, podem comentar els seus pros i contres: Avantages: •Qualsevol programador pot investigar dins el codi i entendre en poc temps que s'està fent i quina és la situació. •Es pot incorporar gent nova al projecte i agafar el ritme de treball dels més antics amb facilitat. •La gent nova en el C++ deseguida pot agafar una pauta des d'on desenvolupar el seu propi estil de programació que podrà defensar fàcilment. •La gent nova en el C++ s'estalviarà el fet de fer els mateixos errors una vegada rera una altra. •Tot l'equip de programació té un “enemic comú”, en el sentit de que tothom programa de la mateixa forma i el codi sempre estarà escrit en el mateix estil. Inconvenients: •Es redueix la creativitat. •Si la gent sap que està fent són totalment innecessaris. •La gent habitualment no els utilitza. •Pot ser un obstacle a l'hora d'utilitzar codi ja implementat que no segueix la normativa que dicta l'estàndard. Tots aquests avantatges i inconvenients estan un extrets de la pàgina web on estan definits els estàndards que hem utilitzat. Per la part que ens toca, era la primera vegada que ho fèiem servir i creiem que l'experiència ha estat molt positiva, malgrat la seva utilització no és element indispensable per l'èxit d'un projecte ajuda molt per al treball en equip, més si tenim en compte que aquest projecte està pensat com un inici cap a una aplicació molt més complexa que podríem no desenvolupar nosaltres. Creiem que gràcies a haver utilitzat aquesta metodologia podrem aportar molt més valor al projecte, en el sentit que serà molt més fàcil d'estendre en quan a les funcionalitats que ofereix i animem de forma entusiasta a que qualsevol persona que treballi sobre el nostre codi segueixi els estàndards marcats. PFC Pissarra Multitàctil Page 52 of 111 5.3 Nom dels Fitxers: En un projecte d'aquestes característiques és important mantenir una uniformitat en els noms dels fitxers, sobretot per mantenir un ordre i facilitar el treball de les persones implicades en el projecte (siguin una, dos o més). Aquest sistema l'hem “importat” del que es fa servir a l'assignatura PESBD. Els noms han d'indicar les següents característiques : •F: La fase del cicle de la iteració. •I: Número d'iteració en que ens trobem. •V: Versió del fitxer. •N: Nom del fitxer. ◦Separadors entre paraules: “_” ◦Cada paraula començant en Majúscula. El format total seria de la següent forma: •F-I-V-N Aquesta metodologia és útil perquè a mida que un va treballant i es van acumulant els arxius i és necessari tenir un accés fàcil a la informació sobre cadascun d'ells. Sobretot quan un fa servir el subversion. Al final, un no sap quina és la última versió d'un document, a quina iteració va ser on es va modificar, etc. I no només parlem de la informació que conté el nom del fitxer, sinó també el fet que sense una metodologia clara per anomenar els fitxers cada persona ho faria a la seva manera i finalment es perdria molt de temps per a trobar el que es busca. PFC Pissarra Multitàctil Page 53 of 111 5.4 Confecció del Subversion Dins del nostre repositori podem trobar les següent carpetes: •Trunk: Aquí guardarem la última versió funcional de la nostra aplicació, seria com la versió principal del projecte. S'utilitzarà com a base per treballar en les noves funcionalitats. •Tag: Aquí desarem les versions antigues del projecte per a tenir un “backup” disponible en qualsevol moment. Cada versió està marcada amb la data en que es va inserir. •Branch: Aquí serà on desarem les versions amb les que estarem treballant en cada moment (en aquest cas els dos membres del grup). El motiu de la separació es que en un cert moment cada persona del grup estarà afegint una funcionalitat diferent, si un d'ells fa un commit d'una versió que no funciona afectarà a l'altre membre del grup que no podrà avançar a causa d'un error que no té a veure amb el que està treballant en aquell moment. Al principi no ho vam fer així, però a mida que anàvem avançant en el projecte ens vam adonar de la seva necessitat, per seguretat i per comoditat, potser al principi és perd una mica de temps en comprendre com funciona aquesta disposició però després una vegada s'agafa la dinàmica no hi ha cap més problema i es fa simple. PFC Pissarra Multitàctil Page 54 of 111 6. Tecnologia Utilitzada Una vegada hem tingut clar què és el que volíem fer o dit d'un altre forma, els nostres objectius, s'ha hagut de fer un estudi exhaustiu o recerca sobre les tecnologies tàctils disponibles actualment ja que a l'inici del projecte el nostre coneixement sobre aquest camp era pràcticament nul. Escollint així després de tot aquest estudi, la tecnologia que considerem, més adequada. 6.1 Tecnologies Tàctils Tenim quatre grans grups de tecnologies tàctils diferents: •Les Superfícies Tàctils Basades en Resistència. •Les Superfícies Tàctils Basades en Capacitància. •Les Superfícies Tàctils Basades en Superfície d'Ona. •Les Superfícies Tàctils Òptiques. Les tres primeres queden totalment descartades des d'un inici ja que necessiten d'instal·lacions que permetin una fabricació de qualitat industrial i per tant no són adequades per a la construcció d'un dispositiu assequible econòmicament i de fabricació pròpia. Malgrat tot s'ha cregut important incloure-les per una millor completesa de l'estudi realitzat i per conèixer i entendre com funcionen [1]. PFC Pissarra Multitàctil Page 55 of 111 6.1.1 Superfícies Tàctils Basades en Resistència Aquest tipus de superfícies es basen en dos capes conductores recobertes amb substàncies com ara l'òxid d'estany i indi. Aquestes capes estan separades per una altra capa d'aïllament normalment feta per petits punts de silicona (veure Figura 1). La part de davant del panell usualment està recobert d'una membrana flexible i dura mentre que el panell de darrera normalment està fet de qualsevol tipus de vidre. Un controlador s'alternarà entre les dos capes, donant una quantitat específica d'electricitat a una i mesurant la càrrega elèctrica actual de l'altre. Quan un usuari toca el dispositiu, les dos capes conductores es connecten, establint un corrent elèctric que es mesura horitzontal i verticalment pel controlador per determinar la posició exacte del contacte. Figura 1. Construcció esquemàtica d'un panell tàctil basat en la tecnologia basada en resisténcia. Aquestes superfícies tenen l'avantatge de tenir un baix consum d'energia i són utilitzades en dispositius com la Nintendo DS, PDAs i càmeres digitals. Com a contra, té poca precisió i no es pot afegir protecció addicional a la superfície de contacte sense alterar al seu funcionament. PFC Pissarra Multitàctil Page 56 of 111 6.1.2 Superfícies Tàctils Basades en Capacitància En general les superfícies basades en capacitància estan subdividides en dos classes: •Capacitància de Superfície. •Capacitància de Projecció. Les dos tècniques van ser dissenyades per a una interacció d'un sol toc (un sol punt de contacte en tot moment). Un avantatge d'aquest tipus de superfícies és la seva alta precisió, cosa que fa que siguin molt adequades per a una gran quantitat de dispositius tàctils que van més enllà d'un simple touch pad. Aquestes pantalles es poden fer servir amb qualsevol tipus de dispositiu conductor i per tant, no està limitat a la interacció basada amb els dits. No obstant, els panells capacitius són relativament cars de produir malgrat tenen una durabilitat i fiabilitat. Com a conseqüència, aquests sistemes són utilitzats en entorns “agressius” tals com llocs públics i en aplicacions industrials. En teoria és possible utilitzar aquests sistemes per a dissenyar un sistema multitàctil, però normalment les empreses que fabriquen aquests dispositius limiten el nombre de “tocs” simultanis que es poden captar. La precisió disminueix en augmentar el nombre de tocs a detectar en comparació a la detecció d'un de sol. Havent descrit totes aquestes limitacions generals, cal dir que el MERL (Mitsubishi Electric Research Group) va superar moltes d'aquestes restriccions amb l'objectiu de permetre varis tocs simultanis, aquestes investigacions estan descrites en els següents apartats. Figura 2. Superfícies Basada en Capacitància: Els elèctrodes al voltant de les vores distribueixen el voltatge a través de la superfície conductora creant un camp elèctric. Tocant el panell resulta en una corrent que va a cada cantonada que és mesurada per definir la posició on hi ha hagut el contacte. 6.1.2.1 Panell Tàctil Basat en Capacitància de Superfície Aquest tipus de dispositius tàctils es basen en un recobriment conductor uniforme en una superfície de vidre. Comparat amb les superfícies resistives (Apartat 6.1.1), tenen molta més precisió i poden ser construïdes mitjançant òxid d'estany i indi com a material conductor (és transparent quan s'utilitza en capes primes). En cada costat del panell tàctil els elèctrodes mantenen un precís control dels electrons horitzontalment i verticalment cosa que crea un camp elèctric en tota la capa conductora. Els dits humans (o altres objectes conductors) també tenen dispositius elèctrics capaços de retenir càrrega elèctrica i d'emetre camps elèctrics, tocar el panell resulta en un petit transport de càrrega des del camp elèctric del panell cap al camp de l'objecte que fa contacte. La corrent generada és conduïda des de cada cantonada del panell, aquest procés és mesurat amb els sensors col·locats a aquestes cantonades i un microprocessador interpola la posició exacte on s'ha fet el toc (veure Figura 2). Aquest tipus de panells poden tenir una gran precisió. PFC Pissarra Multitàctil Page 57 of 111 7. Prototipus El prototip dissenyat per a funcionar junt amb l'aplicació Software, és el mostrat a la Figura 1 que tenim a continuació, ha fabricat de forma manual i la explicació detallada del seu funcionament i muntatge es troba explicada en la memòria del meu company Jorge Novoa Portocarrero. Figura 1. Vista del prototipus La Figura 2 mostra com interactuarà la nostra aplicació amb el prototipus dissenyat. S'utilitza el sistema FTIR (Fustrated Internal Reflection) que s'ha explicat en el capítol de Tecnologia Utilitzada, mitjançant la càmera captarem la imatge de vídeo que necessitarà el CCV (Community Core Vision) per a enviar les senyals que necessita la nostra aplicació per a fer les accions corresponents a la pantalla (aquestes senyals s'enviaran mitjançant el protocol de comunicació TUIO). La imatge processada es mostrarà de nou al prototipus mitjançant un projector. Imatge en brut CCV AplicacióTUIO Projector Figura 2. Diagrama de tot el sistema PFC Pissarra Multitàctil Page 64 of 111 8. Arquitectura del Software del Projecte Aquest capítol ofereix una espècie de “vista panoràmica” de tota l'arquitectura del sistema, utilitzant diferents punts de vista per a representar tots els aspectes del seu funcionament. L'objectiu de tot plegat, és capturar i comunicar les decisions importants que s'han fet a nivell estructural, tenint en compte a més, la seva futura expansibilitat. Continguts importants que haurà de tenir aquesta secció seran del següent tipus: •Com serà utilitzada l'aplicació •Quines seran les persones que la utilitzaran (i per tant quins seran els seus coneixements informàtics, entre d'altres coses). •Estructura del sistema de més general a més específica. •Parts externes que s'utilitzaran i com interaccionaran amb la resta de components. La comprensió del sistema serà important de cara a justificar i entendre les decisions preses i permetre a altres individus ampliar funcionalitats i/o reutilitzar components implementats. PFC Pissarra Multitàctil Page 65 of 111 8.1 Casos d'Ús Significatius En aquesta secció es descriuen els casos d'ús inclosos en el projecte, estan àmpliament definits en el capítol “Model de Casos d'Ús”, en aquest apartat ens centrarem en els que es van marcar en els objectius inicials del projecte: •Paquet “Opcions d'Edició”: ◦Escriure ◦Esborrar Escriptura Figura 1. Paquet “Opcions d'Edició” PFC Pissarra Multitàctil Page 66 of 111 Escriure Esborrar Escriptura Esborrat Total d'Escriptura Canviar de Color la Escriptura Descar Contingut de la Pissarra Recuperar Contingut de la Pissarra Activar/Desactivar Mode Edició Actors::Discs Externs Actors::Usuari •Paquet “Gestos-Objectes”: ◦Moure Objecte Visible ◦Redimensionar Objecte Visible ◦Obrir Objecte Moure Objecte Visible Redimensionar Objecte Visible Obrir Objecte Tancar Objecte Usuari Figura 2. Paquet “Gestos-Objectes” PFC Pissarra Multitàctil Page 67 of 111 8.2 Vista Lògica 8.2.1 Arquitectura del Software L'aplicació estarà implementada seguint el patró MVC (Model Vista Controlador): Controlador ModelVista Figura 3. Model MVC Nota: Les línies sòlides indiquen una associació directa, i les puntejades indirecta. Les associacions indirectes se solen implementar amb el patró observador, (veure el capítol Eines Utilitzades) Aquest patró arquitectònic separa les dades de l'aplicació i la interfície de l'usuari (entrada de dades i presentació), d'aquesta forma es permet un desenvolupament, testeig i manteniment independent de cada part. Normalment es utilitzat en aplicacions web, però donades les seves característiques s'adapta molt bé a les necessitats d'aquest projecte. •El Model. S'encarrega de gestionar el comportament i les dades del domini de l'aplicació. Dins de les seves responsabilitats entra el respondre a les sol·licituds de la Vista (per conèixer l'estat de la informació), i respondre a les instruccions del Controlador (per a canviar l'estat de la informació). En el nostre sistema també haurà de notificar a la Vista els canvis produïts a la informació per a fer les accions que convinguin. •La Vista. Converteix el model en una forma adequada per a la interacció amb els usuaris. Una de les raons per la qual és convenient tenir-la en un component per separat, és perquè pot haver diferents tipus de Vistes per a un mateix model per diferents propòsits. •El Controlador. Rep esdeveniments i inicia la resposta fent crides als objectes del Model. Un Controlador accepta les entrades de l'usuari i dóna les instruccions al Model i a la Vista sobre què fer a partir d'aquestes entrades. El funcionament d'aquest tipus de patró és el següent: 1. L'usuari interacciona amb la interfície d'alguna forma (en aquest cas, tocant la pantalla). 2. El Controlador capta l'esdeveniment creat (que en aquest projecte seran els missatges enviats mitjançant el protocol TUIO), i converteix aquest esdeveniment en la seva apropiada acció, que sigui entesa pel Model (convertirem els punts i les coordenades que ens arribin en gestos). 3. El Controlador notifica al Model l'acció realitzada per l'usuari, cosa que possiblement resultarà en un canvi en la informació continguda pel Model (per exemple l'estat de la pissarra al escriure). 4. La Vista necessita el model per a generar l'apropiada interfície d'usuari (per exemple per saber el color de fons de l'àrea d'escriptura o el color amb que s'escriurà). En definitiva, la vista obtindrà la seva informació del Model. 5. La interfície esperarà per més accions de l'usuari i tornarà al pas número 1 (iniciant de nou el cicle). PFC Pissarra Multitàctil Page 68 of 111 8.2.2 Vista En aquest apartat parlarem de la capa Vista que s'ha vist en l'apartat anterior (on es parlava del model MVC), hi haurà dos vessants a estudiar. Per una banda aquesta capa haurà de captar els esdeveniments sorgits de les accions del/s usuari/s i enviar-les al Controlador (recepció de les dades). I per l'altre s'hauran de mostrar els canvis del Model a la pantalla, així que s'hauran de rebre els esdeveniments d'aquesta capa i fer els canvis corresponents als components gràfics que es controlaran a la Vista (emissió de les dades). 8.2.2.1 La Recepció de les Dades En aplicació aquesta la recepció de les dades és farà amb un dispositiu tàctil a diferència de la resta d'aplicacions on s'utilitza el ratolí. Per comunicar-nos amb el dispositiu s'utilitzaran missatges del protocol de comunicació TUIO, aquests missatges han de ser traduïts a un llenguatge que entengui la capa controlador per a ser interpretats. +addTuioObject(entrada tobj : TuioObject) : void +updateTuioObject(entrada tobj : TuioObject) : void +removeTuioObject(entrada tobj : TuioObject) : void +addTuioCursor(entrada tcur : TuioCursor) : void +updateTuioCursor(entrada tcur : TuioCursor) : void +removeTuioCursor(entrada tcur : TuioCursor) : void +refresh(entrada frameTime : TuioTime) : void -mScreenWidth : int -mScreenHeight : int PMTuioListener +ProcessTouchPoint(entrada id : int, entrada &rLocation : Location, entrada touchState : TouchState) : void +ProcessChange(entrada idChangedPoint : int, entrada idGroup : int) : void +Run() : void +Test() : void -ProcessKnownTouchPoint(entrada touchPointId : int, entrada rLocation : Location, entrada touchState : TouchState) : void -ProcessUnknowTouchPoint(entrada idTouchPoint : int, entrada rLocation : Location) : void -JoinTouchPointWithGroup(entrada pTouchPoint : TouchPoint) : Group -UpdateGroup(entrada group : Group) : void -ProcessOneTouchPoint(entrada touchPoint : TouchPoint, entrada group : Group, entrada actionPerformed : string) : void -ProcessTwoOrMoreTouchPoints(entrada group : Group, entrada actionPerformed : string) : void -GetTouchPointFromGroup(entrada touchpointId : int) : TouchPoint -HandleHoldAndTapGesture(entrada location : Location, entrada state : TouchState, entrada group : Group, entrada actionPerformed : string) : void -DeleteGroup(entrada idGroup : int) : void -DeleteTouchPoint(entrada idTouchPoint : int) : void -GetDistance(entrada location1 : Location, entrada location2 : Location) : float -io_svc : asio::io_service Server:: GestureServer 1 1 Controller Layer Figura 4 Capa Vista, recepció de dades PFC Pissarra Multitàctil Page 69 of 111 8.2.2.1.1 PMTuioListener. Figura 5. Classe PMTuioListener Aquesta classe és la única que ens cal per rebre dades del dispositiu tàctil. És una implementació de la classe TuioListener que rebrà els missatges TUIO del dispositiu. En aquest punt connectarem amb la capa controlador, mitjançant la funció “ProcessTouchPoint” de la classe “GestureServer” de la capa Controlador. Les dades rebudes que passarem seran: •Un Identificador del punt. •Les Coordenades del punt . •L'estat del punt (naixement, en moviment, o mort del punt). Un dubte que podria sorgir en aquest punt és el de que passa quan es toca la pantalla de forma simultània per varis llocs. Simplement el programa que ens envia els missatges TUIO ens els envia en seqüència, o sigui un després de l'altre malgrat hagin sorgit en el mateix moment. PFC Pissarra Multitàctil Page 70 of 111 +addTuioObject(entrada tobj : TuioObject) : void +updateTuioObject(entrada tobj : TuioObject) : void +removeTuioObject(entrada tobj : TuioObject) : void +addTuioCursor(entrada tcur : TuioCursor) : void +updateTuioCursor(entrada tcur : TuioCursor) : void +removeTuioCursor(entrada tcur : TuioCursor) : void +refresh(entrada frameTime : TuioTime) : void -mScreenWidth : int -mScreenHeight : int PMTuioListener 8.2.2.2 L'Emissió de les Dades Per a mostrar les dades per pantalla s'utilitza la llibreria Qt. A continuació el diagrama de classes: +ProcessTouchPoint(entrada id : int, entrada &rLocation : Location, entrada touchState : TouchState) : void +ProcessChange(entrada idChangedPoint : int, entrada idGroup : int) : void +Run() : void +Test() : void -ProcessKnownTouchPoint(entrada touchPointId : int, entrada rLocation : Location, entrada touchState : TouchState) : void -ProcessUnknowTouchPoint(entrada idTouchPoint : int, entrada rLocation : Location) : void -JoinTouchPointWithGroup(entrada pTouchPoint : TouchPoint) : Group -UpdateGroup(entrada group : Group) : void -ProcessOneTouchPoint(entrada touchPoint : TouchPoint, entrada group : Group, entrada actionPerformed : string) : void -ProcessTwoOrMoreTouchPoints(entrada group : Group, entrada actionPerformed : string) : void -GetTouchPointFromGroup(entrada touchpointId : int) : TouchPoint -HandleHoldAndTapGesture(entrada location : Location, entrada state : TouchState, entrada group : Group, entrada actionPerformed : string) : void -DeleteGroup(entrada idGroup : int) : void -DeleteTouchPoint(entrada idTouchPoint : int) : void -GetDistance(entrada location1 : Location, entrada location2 : Location) : float -io_svc : asio::io_service Server:: GestureServer Controller Layer +GetLastPosition() : QPoint +SetLastPosition(entrada lastPosition : QPoint) : void +SetIsCursorMoved(entrada isCursorMoved : bool) : void -mLastPosition : QPoint -mIsCursorMoved : void ScribblingAction Signals: ObjectOpened 1 1 1 * +SetScribbleArea() : ScribbleArea +SendPaintEvent(entrada pEvent : HoldAndTapEvent) : void +OpenImage() : void +MoveObject(entrada newLocation : Location) : void +ResizeObject(entrada scaleFactor : float, entrada center : Location) : void -PMTouch : QEvent::Type -PMFileOpen : QEvent::Type -PMDrag : QEvent::Type -PMPinch : QEvent::Type GestureEventHandler #event(entrada pEvent : QEvent) : bool #paintEvent(entrada pEvent : QPaintEvent) : void #resizeEvent(entrada pEvent : QResizeEvent) : void -TouchBeginEvent(entrada pEvent : PMTouchEvent) : void -TouchUpdateEvent(entrada pEvent : PMTouchEvent) : void -TouchEndEvent(entrada pEvent : PMTouchEvent) : void -FileOpenEvent(entrada pEvent : PMFileOpenEvent) : void -DragEvent(entrada pEvent : PMDragEvent) : void -PinchEvent(entrada pEvent : PMPinchEvent) : void -Draw(entrada pEvent : PMTouchEvent, entrada pScribblingAction : ScribblingAction) : void -DrawPoint(entrada position : QPoint, entrada color : QColor, entrada size : QSize) : void -DrawLine(entrada startPoint : QPoint, entrada endPoint : QPoint, entrada color : QColor, entrada width : int) : void -ResizeImage(entrada image : QImage, entrada newSize : QSize) : void -GetScribblingAction(entrada idGroup : int) : ScribblingAction -DeleteScribbleAction() : void -mLastPoint : QPoint -spBlackboard : Singleton::Blackboard -mpProxyWidget : QGraphicsProxyWidget ScribbleArea Figura 6. Capa Vista, diagrama de classes PFC Pissarra Multitàctil Page 71 of 111 Només amb el diagrama de classes no podem saber com funciona el sistema. El següent diagrama permet entendre el funcionament d'aquesta capa: Figura 7. Funcionament de la capa Vista Funcionament de la capa Vista: 1. El Model envia senyals mitjançant el sistema de “Signals i Slots” de Qt a la Vista (veure capítol d'Eines Utilitzades). 2. Aquests senyals son rebuts pel “GestureEventHandler”. 3. El “GestureEventHandler” utilitzant el “Event System” de Qt (veure capítol d'Eines Utilitzades), envia esdeveniments a la “ScribbleArea” 4. La “ScribbleArea” és el widget sobre el que es faran les accions d'escriptura. Els widgets tenen relacions jeràrquiques entre ells, “ScribbleArea” serà el pare de tots els altres que es trobin oberts en tot moment, ja que sempre tot allò que obrim estarà a sobre d'aquest. Per aquesta raó tots els esdeveniments passaran primer per “ScribbleArea”, i sinó correspon a una acció corresponent a aquest widget els passarà als seus “fills”. 5. Si és el cas, qualsevol widget obert i visible a la pantalla rebrà l'acció enviada per la “ScribbleArea”. PFC Pissarra Multitàctil Page 72 of 111 GestureEventHandler ScribbleArea SendEvent() Widget Widget Widget ... Moure Redimensionar Altre tipus d’acció Model Signals 8.2.2.2.1 GestureEventHandler +SetScribbleArea() : ScribbleArea +SendPaintEvent(entrada pEvent : HoldAndTapEvent) : void +OpenImage() : void +MoveObject(entrada newLocation : Location) : void +ResizeObject(entrada scaleFactor : float, entrada center : Location) : void -PMTouch : QEvent::Type -PMFileOpen : QEvent::Type -PMDrag : QEvent::Type -PMPinch : QEvent::Type GestureEventHandler Figura 8. Classe “GestureEventHandler” La traducció literal seria “Manegador d'Esdeveniments Gestuals”, i s'encarrega precisament d'això, gestionar els esdeveniments a mida que van arribant. Les raons que ens van portar a separar aquestes funcions en aquesta classe van ser les següents: •Poder utilitzar el sistema d'esdeveniments de Qt (veure capítol de Eines Utilitzades). D'aquesta forma podem aprofitar més les possibilitats que ens aporta Qt sense fer que la capa Model sigui depenent d'ell, permetent d'aquesta forma poder canviar de llibreria gràfica sense provocar grans canvis en la resta de capes de l'aplicació. •Simplificar la classe “ScribbleArea”, ja que sinó ella també hagués hagut de fer aquestes funcions dins de totes les coses que ja fa. D'aquesta forma aconseguim augmentar la modularitat d'aquesta capa simplificant la feina del programador i facilitant l'extensibilitat de noves funcionalitats. •Simplificar l'extensibilitat per a la implementació de noves funcionalitats. Donar un suport que faciliti la feina per a la expansió del sistema. Per cada canvi fet en el Model ens arribarà una senyal a aquest manegador, aquestes senyals estaran connectades a Slots d'aquesta classe que generaran els esdeveniments de Qt corresponents utilitzant el sistema d'esdeveniments de Qt. 8.2.2.2.1.1 Extensibilitat Aquesta classe està pensada per a facilitar la implementació de noves funcionalitats. Ha de rebre els esdeveniments i reenviar-los a la ScribbleArea mitjançant el sistema d'esdeveniments de Qt. Del sistema d'esdeveniments de Qt actualment s'està utilitzant la funció “SendEvent()” que tracta cada esdeveniment de forma immediata, ja que per raons de temps i pels objectius del projecte és el més lògic. El més interessant seria acabar utilitzant la funció per enviar “PostEvent()”, que encua els esdeveniments de forma que si tenim varis esdeveniments del mateix tipus són comprimits en un, augmentant així l'eficiència del sistema. De la forma en com està implementada ara la capa Vista i mitjançant aquesta classe (“GestureEventHandler”) tenim el suport necessari per a poder utilitzar la potència que aporta aquest sistema que per una aplicació multitàctil que rep molts esdeveniments en molt poc espai de temps resulta molt interessant. PFC Pissarra Multitàctil Page 73 of 111 8.2.3.1.2 FIB-GestureServer Aquest és el mecanisme de reconeixement gestual definit per a aquest projecte, l'elecció del nom ha estat clara d'acord amb els objectius proposats pel projecte, entre els que està la possibilitat que altra gent (de la nostra facultat o d'altres) pugui aprofitar el nostre treball per desenvolupar les seves pròpies aplicacions multitàctils. En aquest apartat comentarem de que s'encarreguen les classes principals, donarem una petita guia sobre com ampliar la seva funcionalitat i explicarem com es fa la interpretació de les dades. +ProcessTouchPoint(entrada id : int, entrada &rLocation : Location, entrada touchState : TouchState) : void +ProcessChange(entrada idChangedPoint : int, entrada idGroup : int) : void +GetTouchPoint(entrada touchPointId : int) : TouchPoint +GetGroup(entrada groupId : int) : Group -ProcessKnownTouchPoint(entrada touchPointId : int, entrada rLocation : Location, entrada touchState : TouchState) : void -ProcessUnknowTouchPoint(entrada idTouchPoint : int, entrada rLocation : Location) : void -GetGroupIdToJoin(entrada pTouchPoint : TouchPoint) : int -SearchGroupByDistance(entrada touchPointLocation : Location) : int -SearchGroupByComponent(entrada idComponent : int) : int -ProcessOneTouchPoint(entrada touchPoint : TouchPoint, entrada group : Group, entrada actionPerformed : string) : void -ProcessTwoOrMoreTouchPoints(entrada group : Group, entrada actionPerformed : string) : void -ProcessInvalidAction(entrada touchPoint : TouchPoint, entrada pGroup : Group) : void -HandleHoldAndTapGesture(entrada location : Location, entrada state : TouchState, entrada group : Group, entrada actionPerformed : string) : void -HandleDragGesture(entrada location : Location, entrada pGroup : Group, entrada state : TouchState) : void -HandlePinchGesture(entrada distance : int, entrada pGroup : Group, entrada state : TouchState) : void -DeleteGroup(entrada idGroup : int) : void -DeleteTouchPoint(entrada idTouchPoint : int) : void -mNextGroupId : int -mDragEvent : DragEvent -mPinchEvent : PinchEvent GestureServer +GetComponentId(entrada location : Location) : int +SendHoldAndTapEvent(entrada pHoldAndTapEvent : HoldAndTapEvent) : void +SendDragEvent(entrada pDragEvent : DragEvent) : void +SendPinchEvent(entrada pPinchEvent : PinchEvent) : void ClientConnection 1 * +GetId() : int +GetLocation() : Location +GetState() : TouchState +Update(entrada location : Location, entrada state : TouchState) : void -mId : int -mLocation : Location -mTouchState : TouchState TouchPoint 1 * +AddTouchPoint(entrada touchPoint : TouchPoint) : void +DeleteTouchPoint(entrada touchPointId : int) : void +GetMidLocation() : Location +GetGroupState() : TouchState +GetId() : int +GetNumberOfTouchPoints() : int +GetTouchPointIds() : vector<Integer> +GetComponentId() : int +GetAction() : Action +SetComponentId(entrada componentId : int) : void +SetAction() : void -mId : int -mTouchPointsIds : vector<Integer> -mComponentId : int -mAction : Action Group 1 * 1 * Figura 14. Diagrama de classes del FIB-GestureServer PFC Pissarra Multitàctil Page 80 of 111 8.2.3.1.2.1 GestureServer Les funcions principals d'aquesta classe són: •Contenir i gestionar tota la informació relativa als punts actius a la pantalla tàctil i com estan agrupats (per això les relacions amb “Group” i “TouchPoint”, veure Figura 14). •Formar els grups de punts actius. En aquests moments els grups es formen de dos formes: ◦Per distància. Només en el cas que aquests es trobin en la zona escrivible. ◦Per component. Cada component (imatge, vídeo, etc.) és un grup. •Interpretació de les dades. Donat que el “GestureServer” té tota la informació sobre els punts (component on es troben, grup que formen, el seu estat, etc.) som capaços d'interpretar el que està realitzant l'usuari sobre la pantalla tàctil i per tant enviar els esdeveniments interpretats a la següent part d'aquesta capa Controlador. Actualment es poden interpretar els moviments d'escriure, esborrar, “click” sobre un botó, moure i redimensionar una imatge. •Enviar els esdeveniments a la següent part de la capa Controlador. Ho farem mitjançant la classe “ClientConnection” (veure Figura 14). Podríem connectar directament amb la següent part de la capa en comptes d'utilitzar aquesta classe, però s'ha preferit deixar-ho així en cas que algú volgués aprofitar el mòdul de Reconeixement Gestual per fer la seva pròpia aplicació, aquesta classe seria la connexió amb la resta del programa. PFC Pissarra Multitàctil Page 81 of 111 8.2.3.1.2.1.1 Interpretació La interpretació sempre es fa a partir d'un únic canvi d'estat d'un sol punt a la pantalla. Durant el transcurs de les accions de l'usuari sobre la pantalla haurem d'actualitzar l'estructura de dades clau en el camp de la interpretació per al nostre servidor gestual: els grups. Mitjançant el grup podem saber: •El nombre de punts associats al grup i els seus estats. •El component al que està associat. •L'acció al que està associat. Per formar els grups es seguiran els següents passos: 1 Es produeix un canvi en l'estat d'un sol punt 1.1 Si aquest canvi d'estat correspon a un naixement (BIRTH) és un punt desconegut pel sistema, així que crearem un nou grup amb aquest sol punt i introduirem la informació al sistema. 1.2 Qualsevol altre canvi d'estat és un punt ja reconegut pel sistema, així que el que haurem de veure és si aquest punt correspon a un grup existent o per altra banda s'ha de crear. S'han implementat dos formes per a crear grups en el sistema: 1.2.1 Creació de grups per distància. Caldrà comprovar la distància entre el nou punt i tots els punts del sistema que estiguin en estat de BIRTH, si trobem un punt a una distància més petita que la definida per aquesta finalitat, afegirem aquest punt al grup ja existent 1.2.2 Creació de grups per component. Es segueix el principi de que un component equival a un grup, això vol dir que si tenim una imatge oberta a la pissarra, tots els punts que es trobin dins d'aquesta imatge pertanyen al mateix grup. Una vegada decidit a quin grup pertany el punt es passarà a fer la interpretació: 1. En primer lloc s'haurà de mirar si l'acció del grup ha estat assignada com a invàlida. En tal cas l'únic que farem és esperar a que es morin tots els punts del grup per a eliminar-lo. 2. Mirar el component sobre el que es troba el grup. 3. Mirar el nombre de punts que conté el grup. A partir d'aquests tres passos som capaços d'interpretar el gest, qualsevol cas que no s'hagi tractat s'assignarà l'acció com a invàlida al grup. Exemples: •Un sol punt dins el grup sobre l'àrea escrivible = Escriure •Dos punts sobre una imatge = Redimensió •Un punt sobre una imatge = Canvi de posició 8.2.3.1.2.1.2 Extensibilitat De cara al futur, es s'han pensat un sol canvi en referència a la interpretació que afectaria a la formació de grups que hem explicat, en concret l'afirmació sobre la que estem treballant de forma provisional “un component, un grup”, seria preferible poder formar grups per distància dins de cada component, de forma que puguem utilitzar varis dits per mà, per a fer un moviment per arrossegament i de redimensió. És una tasca forma complexe en el camp de la interpretació ja que s'ha de mirar el nombre de grups que es troben dins d'un component i esbrinar quina acció s'està realitzant (cosa que implica veure les direccions en que es mouen entre altres coses) per assignar la acció o invalidar el moviment. PFC Pissarra Multitàctil Page 82 of 111 8.2.3.1.2.2 Group +AddTouchPoint(entrada touchPoint : TouchPoint) : void +DeleteTouchPoint(entrada touchPointId : int) : void +GetMidLocation() : Location +GetGroupState() : TouchState +GetId() : int +GetNumberOfTouchPoints() : int +GetTouchPointIds() : vector<Integer> +GetComponentId() : int +GetAction() : Action +SetComponentId(entrada componentId : int) : void +SetAction() : void -mId : int -mTouchPointsIds : vector<Integer> -mComponentId : int -mAction : Action Group Figura 15. Classe Group Aquesta classe contindrà la informació sobre els grups de punts actius sobre la pantalla, dins de les seves característiques cal destacar: •Coordenades del grup (informació obtinguda mitjançant la funció “GetMidLocation”): De tots els punts que contindrà el grup ens donarà una posició mitjana de tots ells, de moment només funciona per grups d'un i dos punts. •Estat del grup (informació obtinguda mitjançant la funció “GetGroupState”): En aquest cas el retorn d'aquesta funció serà d'acord als estats dels punts continguts pel grup de la següent forma: ◦Si tots els punts estan en estat de BIRTH (naixement) és retornarà BIRTH. ◦Només que hi hagi un punt en estat MOVE (en moviment), es retornarà MOVE. ◦Nomes que hi hagi un punt en estat de DEATH (mort del punt, o sigui, aixequem el dit), es retornarà DEATH. •Atribut “mAction”: Un grup tindrà associada una acció, això es farà una vegada s'hagi fet la feina d'interpretació, serà necessària aquesta informació per: ◦Generar els esdeveniments: Per exemple, un esdeveniment d'arrossegament pot estar associat a varies accions, moure una imatge o fer lliscar una barra d' “scroll”. L'acció associada al grup serà la que s'associï a l'esdeveniment. ◦Invalidar accions. Tenir aquesta capacitat és important, ja que una vegada s'hagi invalidat l'acció d'un grup no farem cas de les actualitzacions rebudes per part dels punts associats del grup. El que farem serà esperar a que arribin les senyals de DEATH i anar esborrant tots els punts fins a que el grup es quedi sense cap i per tant el puguem esborrar també. Per exemple, invalidarem una acció d'esborrar quan estiguem esborrant amb dos dits i aixequem un. 8.2.3.1.2.3 Extensibilitat Actualment les funcions per obtenir la posició i l'estat del grup a partir de la posició i l'estat dels seus punts només funcionen per grups que continguin un i dos punts. Per a obtenir el màxim de flexibilitat en la interpretació de grups cal funcionin per grups de fins a 5 punts (que seria la mà sencera sobre la pantalla). PFC Pissarra Multitàctil Page 83 of 111 8.2.3.1.3 Recepció i Gestió dels Esdeveniments enviats pel FIB-GestureServer Per a dissenyar aquesta capa s'ha repassat els apunts que teníem de l'assignatura “ES2”[5] (Enginyeria del Software 2), on hem aplicat el Controlador Cas d'Ús en que associem una classe de controlador a cada cas d'ús definit al sistema. Això vol dir que cadascuna d'aquestes classes rebrà l'esdeveniment corresponent creat pel Reconeixedor Gestual i després ho notificarà al Model. +Write(entrada rpEvent : Event) : QImage -spBlackBoard : Singleton::Blackboard WriteController +Erase(entrada rpEvent) : QImage -spBlackBoard : Singleton::Blackboard EraseController FIB-GestureServer +ProcesHoldAndTapEvent(entrada pEvent : HoldAndTapEvent) : void +ProcessDragEvent(entrada pDragEvent : DragEvent) : void +ProcessPinchEvent(entrada pPinchEvent : PinchEvent) : void +GetComponentId(entrada location : Location) : int +SetOpenedObject(entrada object : Object) : void +UpdateObjectLocation(entrada location : void) : void -mOpenedComponent : Object Singleton::ClientController 1 1 1 +Click(entrada pEvent : HoldAndTapEvent) : void -spToolbar : Singleton::Toolbar ClickController 1 +Drag(entrada pDragEvent : DragEvent, entrada pObject : Object) : void -mpObject : Object DragController 1 +Zoom(entrada pDragEvent : DragEvent, entrada pObject : Object) : void -mpObject : Object PinchController 1 Figura 16. Part de Recepció i Gestió d'Esdeveniments de la capa Controlador PFC Pissarra Multitàctil Page 84 of 111 8.2.3.1.3.1 ClientController +ProcesHoldAndTapEvent(entrada pEvent : HoldAndTapEvent) : void +ProcessDragEvent(entrada pDragEvent : DragEvent) : void +ProcessPinchEvent(entrada pPinchEvent : PinchEvent) : void +GetComponentId(entrada location : Location) : int +SetOpenedObject(entrada object : Object) : void +UpdateObjectLocation(entrada location : void) : void -mOpenedComponent : Object Singleton::ClientController Figura 17. Classe ClientController La classe ClientController (Figura 17) te les següents responsabilitats: •Fer la connexió amb la resta de classes que corresponen a cada cas d'ús implementat. •Contenir una llista dels components visibles oberts a la pantalla tàctil, que s'utilitzarà per a aplicar les modificacions que convingui. 8.2.3.1.4 Extensibilitat •Cada nou cas d'ús implementat haurà de tenir la seva classe de controlador corresponent. Actualment donat que tenim pocs casos d'ús implementats, sembla una mica absurd, però a mida que els casos d'ús tinguin més variants es veurà la necessitat i la utilitat d'aquest sistema. Per exemple, un moviment d'arrossegament estarà relacionat amb el “DragController” (veure Figura 16), i un moviment d'arrossegament pot estar generat per moltes causes com serien: canvi de lloc de components, per posar un vídeo en un punt de reproducció corresponent, al moure una barra d'scroll, etc. Actualment només es genera un moviment d'arrossegament al moure una imatge i pot semblar una mica absurd tenir una classe de controlador només per això. •Actualment la classe “ClientControler” no té una llista de components oberts visibles, només té una referència a un component, ja que només podem obrir una imatge. Evidentment en el moment en que vulguem obrir més coses haurem d'implementar aquesta llista. PFC Pissarra Multitàctil Page 85 of 111 8.2.4 Model Aquesta capa contindrà tot el que siguin dades del sistema, hi haurà dos parts diferenciades. Una es centrarà en la informació centrada a els esdeveniments amb els que treballarà el sistema, això fa referència a tota la informació necessària per a que la capa Vista sigui capaç de fer els canvis. I l'altre estarà centrada en la informació relativa als components oberts a la pantalla, això voldrà dir que haurem de contenir la informació relativa a la seva mida i posició, i tot el relatiu a les seves característiques individuals (que depenen del tipus de component del que parlem) També en aquesta secció farem una petita ressenya matemàtica sobre els càlculs que es fan per a fer les modificacions en la posició i mida dels “Objectes” oberts a la pantalla. Finalment comentarem les classes d'informació bàsica que no podem catalogar dins d'aquests dos aparts que hem anomenat, ja és informació utilitzada en varies capes de forma comuna, que és la informació sobre les posicions, accions i estat en que es troben els punts i esdeveniments. PFC Pissarra Multitàctil Page 86 of 111 8.2.4.1 Informació sobre els Esdeveniments del Sistema +GetGroupId() : int +GetLocation() -mLocation : Location -mGroupId : int HoldAndTapEvent +GetInitialLocation() : Location +GetActualLocation() : Location +SetActualLocation() : void -mInitialLocation : Location -mActualLocation : Location DragEvent +GetScaleFactor() : int +SetActualDistance(entrada distance : float) : void -mScaleFactor : int -mInitialDistance : Location -mActualDistance : Location PinchEvent +GetComponentId() : int +GetTouchState() : TouchState +GetAction() : Action +SetAction(entrada action : Action) : void #mComponentId : int #mTouchState : TouchState #mAction : Action Event Figura 18. Informació sobre els esdeveniments en el Model Tenim una classe pare en quan als esdeveniments, tots els que creem tindran una sèrie d'atributs comuns que seran compartits mitjançant aquesta classe abstracte “Event.h”. En el nostre Model només tenim tres tipus d'esdeveniments d'acord amb les funcionalitats que hem implementat: •HoldAndTapEvent. Son tots aquells moviments en que s'ha de fer un seguiment d'una posició d'un o varis dits sobre la pantalla tàctil, això el relaciona amb les accions d'escriptura i esborrat, així com les de simulació del ratolí (els “clicks”). •DragEvent. Relacionat amb les accions per moure o arrossegar un objecte per la pantalla (en el nostre cas, una imatge). A diferència de l'anterior moviment haurem de desar la posició inicial i la actual per fer els càlculs corresponents. •PinchEvent. Relacionats amb els moviments de redimensió, actualment només funciona separant i unint dos dits a la pantalla. Aquest sistema afavoreix la creació dels diferents tipus d'esdeveniments necessaris per a fer tota la interfície amb l'usuari (ja que només s'ha realitzat una part com a demostració), així com el perfeccionament dels esdeveniments ja creats. PFC Pissarra Multitàctil Page 87 of 111 8.2.4.2 Informació relativa als Components +Write(entrada holdAndTapEvent) : void +Erase(entrada holdAndTapEvent) : void +GetPenColor() : QColor +GetEraserColor() : QColor +GetPenWidth() : int +GetEraserWidth() : int +GetImage() : QImage +SetPenColor(entrada color : QColor) : void +SetPenWidth(entrada width : int) : void +SetImage(entrada image : QImage) : void +Signal::Writed(entrada pHoldAndTapEvent : HoldAndTapEvent) : void +Signal::Erased(entrada pHoldAndTapEvent : HoldAndTapEvent) : void -mPenWidth : int -mPenColor : QColor -mEraseWidth : int -mEraseColor : QColor -mImage : QImage Singleton::Blackboard +Drag(entrada pDragEvent : DragEvent) : void +Zoom(entrada pPinchEvent : PinchEvent) : void +GetPath() : string +GetCenter() : Location +SetPath(entrada mPath : string) : void +UpdateCenter() : void +Signal::ObjectDragged(entrada newLocation : Location) : void +Signal::ObjectZoomed(entrada scaleFactor : float, entrada center : Location) : void -mPath : string -mCenter : Location Object +OpenImageButtonClicked(entrada pHoldAndTapEvent : HoldAndTapEvent) : void +Signal::ButtonClicked() : void Singleton::Toolbar +GetId() : int +GetWidth() : int +GetHeight() : int +GetCoordinateX() : int +GetCoordinateY() : int +IsIn(entrada rLocation : Location) : bool #mId : int #mWidth : float #mHeight : float #mCoordinateX : float #mCoordinateY : float Component Figura 19. Informació sobre els components en el Model PFC Pissarra Multitàctil Page 88 of 111 8.2.4.2.1 Component Com en el cas anterior, aquí també tenim una classe “pare” amb les característiques comunes de tots els components, aquestes serien: •L'identificador del component. Necessari per distingir els components entre si, sobretot els de tipus Objecte, ja que en podrem tenir varis a la pantalla al mateix temps. •La posició del component. En relació a la pantalla, agafarem com a referència la cantonada superior esquerra (veure Figura 20). •La mida del component. En relació a la seva amplada i alçada (veure Figura 20). Component Posició Amplada Alçada Figura 20. Com fem referència a la posició i mides d'un component Especialment important en aquesta classe és la funció “IsIn” que ens dirà si un cert punt està o no dins del component corresponent. Aquesta informació s'utilitzarà per a la interpretació gestual del que està realitzant l'usuari. PFC Pissarra Multitàctil Page 89 of 111 9.1.1 Rols i Responsabiltats Rol Responsabilitat Project Manager Aconseguir els objectius proposats. Organitzar la feina durant el transcurs del projecte (per iteració) Establir la metodologia de desenvolupament per assegurar la integritat i la qualitat del projecte. Arquitecte del Software Escollir el model d'arquitectura a utilitzar. Establir l'arquitectura de cadascuna de les capes que formen l'aplicació i les interaccions entre elles. Dissenyador del Software Definir les responsabilitats, operacions, atributs i relacions per cadascuna de les classes que s'implementaran. Membre de Suport en el Disseny Softaware Des del punt de vista del programador, aportar consells, idees i suggerències al disseny inicial d'una part de l'arquitectura del Software donada. Programador del Software Una vegada s'han definit totalment les classes aquest s'encarregarà de la seva implementació. Comprovar el correcte funcionament de les parts implementades dins del conjunt del projecte. Dissenyador del Prototipus Aconseguir el objectiu proposat. Escollir la tecnologia a utilitzar i el mètode de construcció a adoptar. Aconseguir el material necessari. Constructor del Prototipus Fer el muntatge del prototipus. Tester del Prototipus Comprovar el correcte funcionament d'aquest i fer les correccions que calguin per a corregir errors que vagin sorgint. Tester del Software Comprovar el correcte comportament de cada funcionalitat implementada dins del conjunt de l'aplicació. 9.1.2 Suport Centre de Realitat Virtual (CRV) El CRV ens va oferir un lloc on treballar i material que tenien disponible http://www.crvbcn.com/ Marta Fairen Directora del projecte Edmundo Martínez Herrera Suport en el muntatge del prototipus PFC Pissarra Multitàctil Page 96 of 111 9.2 Planificació del Projecte En la planificació del projecte es mostra l'organització de la feina respecte al temps i esforç durant el desenvolupament del projecte. 9.2.1 Elements a Implementar Els següents elements hauran de ser produïts durant la realització del projecte: •Confecció de l'Arquitectura del sistema •Disseny i implementació del Servidor Gestual •Disseny i implementació de cadascuna de les capes del sistema •Disseny del Prototipus •Construcció del Prototipus •Test de funcionament i rendiment •Redacció de la Memòria •Preparació de la Presentació 9.2.2 Dates Límit i Mínims del Projecte •Entrega de la Memòria: 21 de Gener del 2011 •Lectura del Projecte: 27 de Gener del 2011 •Hores dedicades mínimes per la Enginyeria Superior: 600 hores •Hores dedicades mínimes per la Enginyeria Tècnica: 300 hores PFC Pissarra Multitàctil Page 97 of 111 9.2.3 Planificació Figura 1. Seguiment de la feina realitzada durant la implementació de l'aplicació S'han realitzat un total de 25 iteracions d'una duració de dos setmanes cadascuna (1 setmana, 20 hores), amb un total de 1000 hores dedicades. S'ha optat per aquest model flexible d'una dedicació de mitja jornada amb molta flexibilitat, donada la impossibilitat de dedicar jornada completa per part dels dos components del grup de treball. En el següent apartat veurem l'explicació detallada de la feina realitzada en cada etapa del projecte així com la dedicació invertida per cada estudiant en cadascuna d'elles. L'explicació sobre el tipus de tasques realitzades la podrem trobar en el capítol Metodologia Aplicada al Projecte. Figura 2. Seguiment de la feina realitzada durant la construcció del prototipus En aquest cas, el treball s'ha fet en paral·lel al de les tasques descrites a la Figura 1, el nombre d'hores dedicades per iteracions no és tan fixe com en el cas del Software ja que és un treball que s'ha anat fent en paral·lel i on es va donar una primera prioritat a la implementació de l'aplicació, al comparar les dos figures es pot entendre de certa forma com s'ha coordinat la feina (sobretot en l'etapa de construcció on es va aturar el procés durant unes quantes iteracions). La data d'inici del projecte (8 de Febrer del 2010) va ser escollida en previsió al major dels riscos del projecte, no acabar en les dates límits. Com s'ha pogut comprovar va ser una decisió correcte ja que hem hagut d'utilitzar tot el temps disponible. PFC Pissarra Multitàctil Page 98 of 111 9.2.3.1 Etapes de la Implementació del Software Inception Estudi de la feina a realitzar i cerca d'antecedents (tant de software com de la tecnologia pel prototipus). Treball realitzat en equip, en aquest punt no hi va haver separació de treball. Total d'hores: 100 hores (Edmon i Jorge) Elaboration Disseny de l'arquitectura del sistema, disseny de les capes i les classes que les formen. Aquesta feina es va combinar amb la feina de construcció (el Jorge només va participar en la construcció, malgrat es van fer correccions al disseny a partir de les seves aportacions). Total d'hores: 380 hores (Edmon) Construction Implementació segons les pautes marcades a la fase d'El·laboració. Al final d'aquesta etapa es van començar a fer tasques pròpies de la etapa de transició. Total d'hores: 320 hores Divisió de feina: Edmon: 180 hores Jorge: 140 hores Transition Documentació de la feina realitzada i proves de cohesió del sistema (junt amb el prototipus). Cal recordar que aquesta feina està relacionada només en la part Software, però el comptatge d'aquestes hores estarà reflectit en la documentació del Jorge en concepte de participació de la part Software. Total d'hores: 200 hores Divisió de feina: Edmon: 140 hores Jorge: 60 hores PFC Pissarra Multitàctil Page 99 of 111 9.2.3.2 Etapes de la Construcció del Prototipus Disseny En l'etapa Inception de l'apartat anterior es va fer l'estudi sobre la tecnologia, però paral·lelament es va anar començant a dissenyar el prototipus (mides, configuració, etc). La feina en aquesta etapa es va incrementar una vegada feta la divisió de la feina entre els dos membres de l'equip de treball encarant ja l'obtenció dels materials i eines necessàries. Les hores que consten de L'Edmon compten com a hores de participació en el disseny del prototipus. Total d'hores: 160 hores Divisió de feina Jorge: 100 hores Edmon: 60 hores Obtenció de Materials En aquesta etapa es correspon al temps dedicat en la obtenció i investigació dels diferents materials i eines necessàries per a la construcció del prototipus (per exemple fustes per fer el suport, metacrilat, silicona, etc.) Jorge: 20 hores Muntatge Temps dedicat a la construcció del prototipus. Jorge: 80 hores Edmon: 30 hores 9.2.4 Càlcul dels Costos Els càlculs s'han realitzant tenint en compte el rols realitzats per cadascú hem assignat els següents costos per hora segons els rols realitzats per cada estudiant (Apartat 9.1.1): •Edmon Martínez: 15 Euros/Hora •Jorge Novoa: 10 Euros/Hora 9.2.4.1 Cost de l'Aplicació Edmon Martínez 760 hores Jorge Novoa 300 hores El cost de la realització de la part software del projecte serà: “Cost_Hores_Edmon + Cost_Hores_Jorge”, és a dir 760*15 + 300*10 = 14.400 Euros PFC Pissarra Multitàctil Page 100 of 111 9.2.4.2 Cost del Prototip Jorge Novoa 290 hores Edmon Martínez 90 hores El cost total dels materials ha estat de 245 Euros sense incloure els materials aportats pel CRV, com per exemple, la webcam i el projector, el càlcul s'ha realitzat tenint en compte els següents materials: –Acrílic tallat amb làser (34cm x 46cm): 50 Euros –Superfície compatible (Silicona i Toluè): 10 Euros –LEDs infrarojos d'alta lluminositat: 35 Euros –Rosco Grey: 10 Euros –Peces de fusta pel suport: 20 Euros –Altres: 20 Euros Per tant, el cost total de la fabricació del prototipus és: “Cost_Hores_Jorge + Cost_Hores_Edmon + Cost_Material”, és a dir 290*10 + 90*15 + 245 = 4.495 Euros 9.2.4.3 Cost i Dedicació Total Edmon Martínez 850 hores Jorge Novoa 590 hores Cost_Part_Software + Cost_Part_Hardware = 14.400 Euros + 4.495 Euros = 18.895 Euros Si mirem l'Apartat 9.2.2, ens adonem que se sobrepassa àmpliament els mínims exigits, això ha estat degut a la magnitud del projecte i ja estava previst des del seu plantejament. El cost malgrat ser força elevat és un gast bastant assolible tenint en compte que és el resultat del sou de dos persones al llarg de tot el projecte i el preu que se sol moure en aquest tipus de dispositius/aplicacions que vam veure en el capítol Anàlisi d'Antecedents i Alternatives. PFC Pissarra Multitàctil Page 101 of 111 10. Conclusions 10.1 Resultats Obtinguts 10.1.1 En Quan al Sistema Totes les funcionalitats previstes en els objectius del projecte han estat implementades i s'ha pogut comprovar el seu correcte funcionament en el simulador. Malgrat això es necessita un prototipus més potent ja que amb l'actual, tot i seguir les instruccions de tota la bibliografia cercada encara té problemes amb la sensibilitat i cal pressionar fort la superfície tàctil per a detectar els blobs. Això fa que no es puguin detectar bé els arrossegaments (ja que el fet d'intentar moure el dit de lloc implica deixar de pressionar amb la mateixa força, amb el que es perd la senyal), cosa que implica que el zoom i l'arrossegament de la imatge no es puguin mostrar. En el prototipus les funcionalitats que sí s'han pogut provar són: •Escriptura en un punt. •Obrir la imatge pressionant un botó. •Varis usuaris escrivint al mateix temps. El fet que es pugui escriure des de varis punts al mateix temps és en sí un gran èxit, ja que si mirem el capítol d'Antecedents i Alternatives cap de les marques que actualment s'està utilitzant en els centres d'ensenyament de Catalunya ha implementat un sistema capaç de fer això. De totes formes amb un prototipus més avançat podríem realitzar les proves de rendiment necessàries per a veure el funcionament del programa amb vàries accions d'escriptura simultània per a veure si té problemes de rendiment. El moviment per esborrar, que implica dos dits, tampoc es pot provar amb el dispositiu, ja que aquest moviment implica detectar dos punts en estat de naixement (BIRTH) a l'hora. El problema és que la falta de sensibilitat del dispositiu fa que una vegada s'aconsegueix que apareguin els dos blobs junts, el primer ja es troba en estat de moviment i per tant no podem formar el grup (mirar l'apartat d'Interpretació del capítol de l'Arquitectura del Software i Extensibilitat). Ho detecta com si fossin dos escriptures simultànies i pinta dos punts. Amb un prototipus més sensible caldria comprovar si aquest error no passa i si passes hauríem de fer lleugeres modificacions a l'apartat d'interpretació del programa. 10.1.2 En Quan a la Metodologies de Treball En quan a les metodologies de treball, en general el resultats han estat molt positius, s'ha adquirit experiència en l'aplicació d'aquestes eines. Inicialment un pot pensar que és una pèrdua de temps, i el temps sol ser un factor crític en la implementació de qualsevol tipus d'aplicació Software, així que normalment l'aplicació d'aquest tipus de metodologies de treball és el primer que s'evita. La forma en que s'ha d'encarar la decisió sobre si aplicar aquestes eines de “bones pràctiques” és pensar que un està fent una inversió, i aquesta inversió inicial no produïra beneficis fins que passi un cert temps. A mida que el temps va passant un es dóna compte de la veritable utilitat de tot plegat, l'aplicació està més ben construïda i ordenada, Com a crítica constructiva el que faltaria fer en cada iteració seria fer la documentació del codi implementat, ja que seria una informació molt important de cada a afegir membres al grup de treball en un futur. PFC Pissarra Multitàctil Page 102 of 111 10.2 Possibles Aplicacions La utilització d'aquest sistema no només es limitaria als col·legis o instituts, podria ser igualment útil per a universitats i empreses (amb la qual cosa es requeririen noves funcionalitats especials). I la cosa no s'acaba aquí, la tecnologia tàctil és el futur, podria tenir aplicacions en: •Eliminació dels botons. La nostra experiència en aquest projecte ens diu que les superfícies tàctils poden simular els botons, això implicaria per exemple utilitzar superfícies tàctils en els comandaments a distància, electrodomèstics, etc. Tenint com a punts a favor que es podria personalitzar de la forma que desitgem, cosa que facilitaria molt la seva utilització (sobretot la gent d'avançada edat que necessita les coses el més simples possible). •Altres superfícies d'escriptura manual. Com per exemple els blocs de notes dels cambrers, la nostra aplicació es podria executar en qualsevol dels mòbils tàctils que existeixen en l'actualitat i per tant no caldria fer cap despesa addicional per fer-ho servir. Aquests són un parell d'exemples simples que se'ns han ocorregut, segurament a cada persona que participi en un projecte d'aquestes característiques se li podrien ocórrer d'altres. 10.3 Viabilitat del Projecte Segons l'anàlisi de la competència a Catalunya que s'ha realitzat en aquest projecte cap de les alternatives possibles no ha utilitza una interfície multitàctil que funcioni exactament com una pissarra tradicional, els models que s'acosten més a aquesta idea són experimentals i estan sent dissenyats a l'estranger. La dificultat recau principalment en el disseny de l'aplicació Software degut a la complexitat de la interpretació i concurrència d'esdeveniments que es produeixen. Mitjançant la feina que s'ha realitzat ens agradaria demostrar la viabilitat econòmica del projecte i veure que simplement que es pot fer. De poder desenvolupar la idea amb els recursos adequats (amb un dispositiu tàctil de més qualitat i un equip de treball) pensem que es podria fer un negoci al voltant d'aquesta idea. En els capítols sobre alternatives i planificació Software del projecte hi ha informació sobre els costos per si es desitja fer qualsevol comparativa. PFC Pissarra Multitàctil Page 103 of 111 10.4 Línia de Treball a Seguir 10.4.1 Software 10.4.1.1 Extendibilitat En el capítol on parlem sobre l'arquitectura del Software hem donat instruccions sobre com s'han pensat les coses a l'hora d'implementar noves funcionalitats, però aquests només són una possible guia per a donar una idea sobre el perquè s'han fet les coses i com es podrien estendre. Tenint en compte això, en quan a les funcionalitats més “tangibles” creiem que es podria tenir com objectiu afegir les funcionalitats per poder obrir arxius d'àudio i vídeo: •S'hauria de poder obrir qualsevol format d'arxiu. •S'hauria de dissenyar una possible barra d'eines. •S'hauria de decidir com controlar la reproducció dels vídeos. A més d'això cal tenir en compte les modificacions a fer en el camp del reconeixement gestual, per poder realitzar moviments d'arrossegament i redimensió amb varis dits a la vegada. L'extensibilitat de l 'aplicació ha estat durant tot el projecte una característica present en el nostre disseny, ja que hem de tenir en compte que l'èxit o el fracàs d'un projecte d'aquest tipus estarà definit per la possibilitat de poder estendre o no les seves funcionalitats, la flexibilitat per introduir noves accions, reconeixement gestual o qualsevol altre cosa que se'ns pugui ocórrer. 10.4.1.2 Independència Hardware La nostra aplicació hauria de ser capaç de fer-se servir en els actuals dispositius utilitzats en les aules d'ensenyament, en teoria això hauria de ser possible però s'haurà d'esbrinar si realment és així o existeix algun impediment. En el cas més positiu, es podria fer servir l'aplicació en qualsevol dels dispositius alternatius anomenats en el capítol corresponent en aquesta memòria tenint en compte les limitacions físiques que tindran depenent de les seves capacitats. Aquest és un punt bastant important ja que el nostre objectiu no és eliminar tots aquests dispositius amb el que s'ha fet un esforç econòmic tant important. 10.4.2 Hardware Per la part de Hardware s'hauria d'aconseguir o fabricar un dispositiu més acurat, en concret cal millorar enormement la sensibilitat a l'hora de detectar els blobs. Seria la millor forma de continuar desenvolupant l'aplicació per a poder realitzar millor les proves d'execució a cada iteració. Per a realitzar aquest pas hem de decidir si convé construir el nostre propi dispositiu o aconseguir un “aliat” que s'encarregués d'aquesta part del producte. Tenim dos opcions: •Construir el nostre propi producte. Per tal cosa hauríem de parlar amb el departament d'Enginyeria Electrònica de la UPC que serien els millors especialistes al nostre abast per a desenvolupar aquesta tecnologia. Ens costa que aquest departament ha desenvolupat un aparell del tipus que necessitem amb una pantalla LCD[1]. •Aconseguir un “aliat” que s'encarregués del Software. Parlar amb alguna empresa del sector interessada en desenvolupar un producte d'aquestes característiques. Ara mateix ens ve a la ment Microsoft, de la que ens consta que té la seva “Microsoft Surface”[2], potser hi podria estar interessat. PFC Pissarra Multitàctil Page 104 of 111 11. Agraïments Arribats a aquest punt voldríem agrair a les següents persones la seva participació en el projecte: •Centre de Realitat Virtual. Per donar-nos un lloc on treballar i facilitar-nos part del material que tenien disponible com el projector, el filtre, els ordinadors per treballar, etc... •Jordi Pradell. Per ajudar-nos en el disseny UML. •Edmundo Martínez Herrera (pare de Edmon Martínez Martí). Per ajudar-nos en el muntatge del prototipus. PFC Pissarra Multitàctil Page 105 of 111