PROPUESTA DE UNA PLATAFORMA QUE INTEGRA …
52
PROPUESTA DE UNA PLATAFORMA QUE INTEGRA APLICACIONES INTERACTIVAS CON INTERACCIÓN BASADA EN GESTOS Autor: Luis Ricardo Ruiz Rodríguez Tesis de grado para optar por el título de: Maestría en Ingeniería de Sistemas y Computación Asesores: PhD. José Tiberio Hernández PhD. Mario Fernando de la Rosa UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN BOGOTÁ D.C., COLOMBIA 2012
Transcript of PROPUESTA DE UNA PLATAFORMA QUE INTEGRA …
PROPUESTA DE UNA PLATAFORMA QUE INTEGRA APLICACIONES INTERACTIVAS CON INTERACCIÓN BASADA
EN GESTOS
Autor: Luis Ricardo Ruiz Rodríguez
Tesis de grado para optar por el título de: Maestría en Ingeniería de Sistemas y Computación
Asesores: PhD. José Tiberio Hernández
PhD. Mario Fernando de la Rosa
UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN BOGOTÁ D.C., COLOMBIA
2012
1
2
CONTENIDO
LISTA DE TABLAS ......................................................................................................................... 4
LISTA DE FIGURAS ........................................................................................................................ 4
RESUMEN .................................................................................................................................... 5
1. INTRODUCCIÓN .................................................................................................................... 6
2. CONTEXTO ............................................................................................................................ 8
2.1. PROBLEMÁTICA ..................................................................................................................... 8
2.2. OBJETIVOS ............................................................................................................................ 9
2.3. ANTECEDENTES .................................................................................................................... 10
2.4. DEFINICIÓN DE LA APLICACIÓN INTERACTIVA .............................................................................. 12
2.4.1. APLICACIÓN INTERACTIVA .......................................................................................................... 12
3. MODELO DE INTERACCIÓN BASADA EN GESTOS .................................................................. 18
3.1. DESCRIPCIÓN DEL MODELO .................................................................................................... 18
3.1.1. GESTUALIDAD .......................................................................................................................... 18
3.1.2. INTERPRETACIÓN ...................................................................................................................... 18
3.1.3. PROCESAMIENTO ...................................................................................................................... 19
3.2. DESCRIPCIÓN DEL MODELO DE LA ARQUITECTURA ....................................................................... 19
3.2.1. GESTUALIDAD .......................................................................................................................... 20
3.2.2. INTERPRETACIÓN ...................................................................................................................... 20
3.2.3. PROCESAMIENTO ...................................................................................................................... 21
3.2.4. COMUNICACIÓN ....................................................................................................................... 21
4. DISEÑO E IMPLEMENTACIÓN .............................................................................................. 22
4.1. PLANTEAMIENTO DEL SOFTWARE SOLUCIÓN .............................................................................. 22
4.2. PLATAFORMAS DE DESARROLLO ............................................................................................... 22
4.2.1. OPENNI .................................................................................................................................. 22
4.2.2. VRPN ..................................................................................................................................... 24
4.3. DESCRIPCIÓN DE LOS COMPONENTES ........................................................................................ 25
4.3.1. COMPONENTE DE INTERACCIÓN .................................................................................................. 25
4.3.2. COMPONENTE DE APLICACIÓN .................................................................................................... 27
4.4. PROCESO DE ADAPTACIÓN ..................................................................................................... 27
5. APLICACIÓN DE EJEMPLO .................................................................................................... 29
5.1. CONTEXTO APLICATIVO ................................................................................................................. 29
5.2. CONTEXTO FÍSICO ........................................................................................................................ 30
3
6. EVALUACIÓN ...................................................................................................................... 33
6.1. CRITERIOS DE EVALUACIÓN .................................................................................................... 33
6.2. RESULTADOS DE LA EVALUACIÓN ............................................................................................. 33
6.2.1. RENDIMIENTO .......................................................................................................................... 33
6.2.2. ADAPTABILIDAD ........................................................................................................................ 36
6.2.3. USABILIDAD ............................................................................................................................. 37
7. CONCLUSIONES Y TRABAJO FUTURO ................................................................................... 38
8. BIBLIOGRAFÍA ..................................................................................................................... 41
ANEXO A (EJEMPLOS DE METÁFORAS DE INTERACCIÓN) ........................................................... 43
ANEXO B (MODELOS UML DE LOS MÓDULOS Y COMPONENTES DE LA PLATAFORMA) ............... 44
MÓDULO DE DISPOSITIVOS VRPN ............................................................................................................ 44
MÓDULO DE DETECCIÓN DE GESTOS ......................................................................................................... 45
MÓDULO DE COMUNICACIÓN .................................................................................................................. 46
ANEXO C (PROTOCOLO DE COMUNICACIÓN ENTRE COMPONENTES) ......................................... 47
4
LISTA DE TABLAS TABLA 1. RESULTADOS DE TIEMPOS DE EJECUCIÓN DE LAS TAREAS DE UNA APLICACIÓN DENTRO DE UNA LAN ....... 34 TABLA 2. RESULTADOS DE TIEMPOS DE EJECUCIÓN DE LAS TAREAS DE UNA APLICACIÓN DENTRO DE DOS
COMPUTADORES EN INTERNET ......................................................................................................... 35 TABLA 3. RESULTADOS DE LOS TIEMPOS DE LAS PRUEBAS DE USUARIOS DE CONOCIMIENTO BÁSICO .................... 36 TABLA 4. RESULTADOS DE LOS TIEMPOS DE LAS PRUEBAS DE USUARIOS DE CONOCIMIENTO AVANZADO ............... 36
LISTA DE FIGURAS FIGURA 1. TAXONOMÍA DE GESTOS PROPUESTA EN [REF.15] .............................................................. 11 FIGURA 2. CONFORMIDAD DE LA ARQUITECTURA DE UNA APLICACIÓN INTERACTIVA A MVC. .................... 13 FIGURA 3. METÁFORA DE INTERACCIÓN ......................................................................................... 15 FIGURA 4. MODELO DE LAS RELACIONES DE LOS CONCEPTOS DE LA METÁFORA DE INTERACCIÓN (REVISAR) 19 FIGURA 5. ARQUITECTURA INTERNA DEL COMPONENTE DE INTERACCIÓN .............................................. 20 FIGURA 6. LA ARQUITECTURA PROPUESTA EN OPENNI [REQ.REF.] .................................................... 23 FIGURA 7. ADAPTACIÓN DEL MODELO OPENNI AL MODELO DE INTERACCIÓN BASADA EN GESTOS ........... 24 FIGURA 8. VISTA DE LA APLICACIÓN DEL GOBERNADOR ..................................................................... 29
5
RESUMEN
Actualmente, en el desarrollo de aplicaciones interactivas, la ejecución de tareas siempre
depende de lo que desea hacer el usuario, y estas ordenes son expresadas en un lenguaje
común para el usuario. Este lenguaje puede ser proporcionado por la aplicación o puede
ser un medio de comunicación intuitivo como son los gestos. En este último caso, la
aplicación debe interpretar las acciones y gestos que el usuario está realizando con los
dispositivos que hacen parte de la infraestructura dispuesta por el sistema. Sin embargo,
la definición de como se deben agrupar y darle significado a cada uno de los valores que
provienen de los dispositivos, para que sean tomados como un gesto, requiere de un
diseño de la aplicación para que puedan ser expresados por el usuario con diferentes
dispositivos físicos adaptándose a preferencias del usuario en distintos contextos de
trabajo. En este documento, se propone una plataforma que soporta la integración de
interacción gestual con aplicaciones interactivas existentes, tomando como base un
modelo que describe el proceso de la interacción gestual. Este proceso está comprendido
como el flujo de la información proveniente de los dispositivos y su transformación hasta
la acción que es interpretada por la aplicación.
1. INTRODUCCIÓN Una aplicación interactiva, es aquella donde el usuario interviene y modifica el estado de
la misma. La intervención por parte del usuario puede ser por medio de ordenes explicitas
en el teclado y el mouse o por medio de dispositivos no convencionales. Con el paso del
tiempo, estos dispositivos han aumentado su capacidad y hacen que lo que quiera
expresar el usuario se acerque más a un lenguaje de comunicación natural al ser humano:
La gestualidad.
Dentro de lo que implica que la interacción sea natural, dos criterios se tienen en cuenta:
Que el tiempo de respuesta sea mínimo y la interpretación de los movimientos del usuario
sea confiable respecto a las intenciones que tiene para que una acción tenga su respectiva
reacción. La recepción de los gestos que hace el usuario se hace a partir de dispositivos
electrónicos, que son interpretados por parte del computador como entradas de tipos
básicos. Y a su vez, esta interpretación de la acción que debe hacer el computador se
puede dividir en un conjunto de tareas simples que la aplicación debe procesar para
obtener la respuesta deseada por el usuario.
El significado de los gestos depende del lenguaje en el que el mismo usuario se expresa, y
al mismo tiempo, que la terminal o computador que está recibiendo la información sepa
lo que le están tratando de decir. Este proceso implica una transformación por parte del
computador, usando como intermediario el programador, desde el lenguaje con el que se
expresan los dispositivos, hasta las ordenes sobre las tareas que debe ejecutar el sistema
para mostrar los resultados esperados dentro de la aplicación.
Para un diseñador y programador de aplicaciones interactivas es pertinente lograr una
cercanía entre lo que quiere hacer el usuario y como es que debe ser interpretado por la
máquina, para definir fácilmente como se puede realizar una tarea dentro de la aplicación.
Este proyecto se encarga de hacer una separación de los conceptos de las tareas de la
aplicación con el componente encargado de la interacción, y a partir de eso, se propone
un modelo, embarcando los conceptos que hacen parte de una metáfora de interacción,
que se encarga de hacer una transformación desde las intenciones del usuario hasta el
modo de hacer la retroalimentación de la acción que fue recibida por el sistema.
Este proyecto propone un modelo con base del proceso de interpretación de una
representación mental de la interacción gestual, se puede aplicar a una plataforma y
adaptar a aplicaciones ya existentes. El proceso de interpretación contiene pasos que se
usan conceptos para dividir las tareas de interacción de las tareas de la aplicación. El
avance de esta investigación contribuye en proveer un nuevo esquema donde la
7
interacción usando gestos se separa de la lógica, facilitando al diseñador de la aplicación
intervenir en cada uno de estos dos elementos de manera independiente.
Este documento presenta el proceso de investigación, implementación y pruebas del
modelo y de la plataforma que lo valida. En el capítulo 2 se presenta el contexto se explica
la problemática y la descripción del entorno en el que se desarrolla. En ese mismo capítulo
se presentan los objetivos de la solución y los antecedentes se muestran aplicaciones que
buscan objetivos similares y los conceptos que rodean la interacción gestual.
Con la información de fondo de este tipo de aplicaciones y de lo que implica la interacción
gestual, se presenta en el capítulo 3 el modelo teórico de la propuesta. Se hace una
descripción de los conceptos de la aplicación y un análisis de la intervención del proceso
descrito por la representación mental de la interacción basada en gestos. Al final se
plantea una propuesta de la arquitectura de la aplicación que usa el modelo como base
para definir el flujo de la información.
En el capítulo de diseño e implementación corresponde a describir el desarrollo de la
plataforma con la arquitectura planteada en la sección anterior. Se justifica el uso de
librerías y plataformas de soporte, y se describe el proceso de adaptación de una
aplicación existente para que funcione dentro de la plataforma y tenga interacción
gestual. La sección de aplicación de ejemplo, aplica este proceso para una aplicación ya
existente.
El capítulo muestra los resultados de las validaciones del modelo y del proceso de
adaptación. En esta sección se prueba que el modelo mejora la intervención de
aplicaciones y su integración con la interacción gestual. El análisis de los resultados, las
fallas y las oportunidades del modelo y su implementación se desarrollan en el capítulo de
las conclusiones y trabajo futuro.
8
2. CONTEXTO El constante desarrollo de aplicaciones interactivas para distintos ambientes de trabajo,
hace que la intervención del desarrollador en el código se incremente, debido a que hay
que reinterpretar los datos que intervienen en el proceso de interacción. En cada uno de
los ambientes de trabajo existen distintas condiciones de visualización y de dispositivos,
cambios que implican formas nuevas de interacción por parte del usuario. En algunos de
esos ambientes de trabajo se tienen datos directos de los dispositivos, en otros casos, se
debe detectar un gesto e interpretar los datos que lo componen.
El uso de este tipo de aplicaciones no se restringe solo a desarrolladores, en la actualidad
existe gran cantidad de diseñadores de aplicaciones o usuarios que desean tener esa
flexibilidad en sus respectivos trabajos. No todos estos usuarios, tienen un conocimiento
en el uso de un lenguaje de programación, y esto restringe el uso de estas aplicaciones
reduciendo su uso a un mercado específico. Y en muchos casos estos cambios implican el
desarrollo completo de una nueva aplicación.
El desarrollo de nuevos dispositivos más capaces de tener información detallada de un
movimiento por parte del usuario, hace que la interacción sea más natural. La interacción
natural comprende la expresión básica por parte de un usuario, utilizar un lenguaje
corporal intuitivo, lo que se llaman gestos. Un gesto, es una pose o un movimiento que
tiene un significado específico, y puede comprender una o varias partes del cuerpo.
Debido a su complejidad, la interpretación puede variar entre aplicaciones, pero
generalmente según el contexto, el usuario realiza las mismas acciones para dar a
entender el mismo significado sin importar la aplicación.
2.1. PROBLEMÁTICA En el desarrollo de una aplicación interactiva, el camino que toman los datos de un
dispositivo para ser transformados en los que requiere la aplicación para dar un resultado,
siempre son definidos por el programador e implican, en una etapa inicial, una gran
cantidad de tiempo porque de cierta forma se está comenzando desde ceros.
La interacción con las aplicaciones debe ser con un lenguaje intuitivo a la persona que
interviene en el espacio de trabajo. Los gestos son el sistema lingüístico que facilita esta
comunicación con las aplicaciones, pero es un sistema que presenta dificultades en
distintos aspectos. La interpretación de gestos se reduce al uso de dispositivos específicos
que no son accesibles por todo el público o al uso de software que tiene algún tipo de
restricciones.
9
Existen gestos cuya forma es similar aunque se cambie de dispositivos o de aplicación. En
aplicaciones que su interacción es por gestos, la implementación cambia entre
dispositivos a pesar de que tengan la misma tarea de la aplicación y la forma de su gesto
sea igual. Este tipo de asignación de gesto a aplicación ofrece la posibilidad de reutilizar lo
hecho en cada una de las partes.
Adicionalmente, si se desea que una aplicación se pueda ejecutar en distintos ambientes
físicos, es necesaria la intervención en el código para que las entradas generadas por los
dispositivos del nuevo ambiente, realicen las tareas que ya se podían hacer en el entorno
anterior.
2.2. OBJETIVOS Se propone una plataforma que integre aplicaciones interactivas existentes con la
interacción basada en gestos. Para ello, se establecen los siguientes objetivos:
Proponer un modelo que abarque los conceptos que hacen parte de la interacción con
gestos realizados por el usuario, con una aplicación que tiene visualización en 3D. Los
conceptos del modelo deben demostrar que se puede tener independencia entre la
interacción y la lógica de la aplicación. También, el modelo debe representar el flujo de la
información desde el dispositivo hasta la aplicación, resaltando cada una de las etapas
significativas del proceso.
Desarrollar una plataforma que sea conforme a los elementos identificados al modelo, e
ilustrar las ventajas que provee esta herramienta. La plataforma debe soportar la
capacidad de recibir información de distintos dispositivos, hacer detección de gestos e
interpretar esta información y comunicarla a la aplicación. Debe ser modular, por lo tanto
se pueden integrar distintos módulos que cumplan las mismas funciones sin necesidad de
intervenir en la aplicación en cada uno de estos cambios.
Demostrar la interoperabilidad de un componente de interacción con múltiples
aplicaciones. Se debe establecer un proceso en el cuál, previamente a este paso, se debe
adaptar una aplicación interactiva común a la plataforma compatible con gestos. Este
proceso debe permitir el transporte de la aplicación entre distintos ambientes de trabajo e
intervenir con distintos dispositivos, que cumplan con un conjunto de reglas para poder
ser interpretados dentro de la plataforma.
10
2.3. ANTECEDENTES Las aplicaciones cuya interacción es por medio de gestos, están orientadas al uso de
ciertos dispositivos específicos para cada uno de esos gestos. Actualmente, el uso
cotidiano de pantallas táctiles está impulsando el uso de lenguajes para ese dispositivo.
En(1) se describe la interacción como una interpretación de gestos definidos por parte del
usuario de un dispositivo específico, restringiendo su intención a tareas específicas de la
aplicación. Para cada uno de los pasos se define un conjunto de reglas de mapeo, las
cuales se encargan de hacer una traducción de un gesto a una tarea de la aplicación. Un
claro ejemplo de gestos destinados para el funcionamiento en un dispositivo, es el usado
por distintos sistemas operativos interpretando los movimientos del mouse, de un lápiz
óptico o de la pantalla táctil.
La comunicación del usuario con una persona o con una máquina puede ser de distintas
maneras. La forma en la que se detecta lo que el usuario está haciendo se llama
modalidad. Jaimes (2) hace un análisis donde revisa aspectos donde la integración de
varias modalidades que intervienen en la definición de un gesto, él identifica los distintos
tipos de modalidades como sensoriales y no-sensoriales. Las modalidades sensoriales son
las que la expresión del usuario se identifica por medio de los dispositivos que emulan
sentidos del ser humano, y los no sensoriales son aquellas donde las expresiones se
realizan por medio de dispositivos simples como el teclado o el mouse, en los que su
funcionamiento no se asemeja a algún sentido. Hay que tener en cuenta que este análisis
se especifica que los gestos son expresiones de la modalidad visual, por lo tanto su
identificación se hace por medio de cámaras y dispositivos similares. Actualmente, existen
otro tipo de dispositivos no visuales que ayudan a nutrir o sustituir la información que se
puede obtener por estos dispositivos de visualización. Por lo tanto un gesto se puede
definir como una expresión corporal con múltiples modalidades, y en el contexto de
identificación y reconocimiento un gesto se establece como una expresión multi-
dispositivo.
Los gestos han sido clasificados con distintos criterios, la mayoría, teniendo en cuenta el
concepto psicomotor. En (3) se hace la comparación de taxonomías de gestos, basándose
en el significado de cada uno de los gestos y cómo se puede interpretar por medio de una
máquina. De forma similar en (4) se presenta la taxonomía de los gestos para sistemas
computacionales, como se ve en la Fig. 1, que tiene en cuenta tres criterios de
clasificación: Dominio de la aplicación, Tecnológica y Estilo del gesto. El dominio de la
aplicación se enfoca en el uso del gesto según la aplicación, en el tecnológico se enfoca en
las modalidades en las representaciones con un dispositivo de un gesto y el estilo de gesto
se basa en la interpretación que se hace del gesto.
11
FIGURA 1. TAXONOMÍA DE GESTOS PROPUESTA EN (4)
Basados en el criterio de clasificación del estilo de gesto presentado en la taxonomía
anterior, autores como Zigelbaum (5) se basan en hacer una extensión de estas
condiciones para la definición de gestos de mayor complejidad. Por ejemplo, un sistema
operativo avanzado desarrollado en parte del grupo MIT Media Lab, llamado oblong(6),
que dentro de su lenguaje propio (5), llamado g-stalt, extiende los tipos de gestos a
combinaciones de los tipos ya existentes. Pero, en todos los casos anteriormente
mencionados, el significado de la acción que representa cada gesto está enlazado con la
aplicación en la que se realiza. Un ejemplo claro de aplicación para ambientes inmersivos,
cuya interacción es basada en la interpretación de gestos y de comunicación verbal, es la
desarrollada por Latoschik (7) donde también propone una arquitectura en la que
intervienen múltiples modalidades. Este último es un claro ejemplo de interacción multi-
modal, en un contexto aplicativo específico.
Pero un gesto puede ser entendido como una sola expresión, o como un conjunto de
movimientos de distintas partes del cuerpo. En (8) el proceso de reconocimiento de un
movimiento del cuerpo humano, se restringe a dos tipos: El estático y el dinámico. La
diferencia recalca en el tiempo para el muestreo del gesto, en el caso estático se tiene en
12
cuenta los datos obtenidos en un único momento, en cambio cuando el proceso de
detección es dinámico, implica la obtención de datos a través de un tiempo determinado
por parte de varios dispositivos. Bangalore (9) interpreta y explica como el proceso de
integración de un proceso de interacción multimodal y gestual, se puede integrar dentro
de una herramienta. También expresa el proceso de construcción de un lenguaje y una
gramática a partir de una secuencia finita de acciones realizadas por el usuario, por medio
de interacción con múltiples modalidades, para que se comprenda un proceso por parte
de la máquina.
Estructuralmente también es necesaria la definición de lenguajes que describen una
aplicación interactiva, desde el proceso de interpretación del dispositivo hasta la
comunicación con las tareas que realiza una aplicación. Para nombrar solo un par de
ejemplos de lenguajes estructurales para una aplicación, están ICO (10) e IntML (11). Este
último tiene un lenguaje gráfico propio que describe el proceso de la aplicación por medio
de filtros. Cada uno de los filtros puede representar un elemento dentro del flujo de
información desde los valores generados por las entradas de un dispositivo, una operación
sobre esos valores, y cómo deben ser interpretados cada uno de esos valores con las
acciones que están definidas para esa aplicación. La desventaja presente, es el uso de
elementos de bajo nivel, como la interpretación simple de los datos básicos que provienen
del dispositivo.
No necesariamente una aplicación debe estar en la misma máquina en donde la
interacción está sucediendo, o donde se hace el respectivo procesamiento de la
información de los dispositivos. Se han buscado nuevas alternativas de integrar por medio
de sistemas distribuidos un lenguaje sencillo para el usuario que integre la interacción con
la aplicación. Un ejemplo es presentado por (12) donde se presenta una interfaz gráfica
para especificar el acceso a las tareas de la aplicación por medio de WebServices.
2.4. DEFINICIÓN DE LA APLICACIÓN INTERACTIVA El contexto problemático presenta características específicas que se van a tener en cuenta
en el desarrollo de la solución. En este caso, los conceptos que hacen parte del contexto
se obtienen a partir de la descripción de una aplicación interactiva que recibe información
generada por los gestos realizados por el usuario.
2.4.1. APLICACIÓN INTERACTIVA Para el desarrollo de la interacción se enfrenta por dos aspectos importantes: la aplicativa
que es la lógica y estructura de la aplicación, y la conceptual que es la definición de los
elementos que componen el proceso de intervención por parte del usuario para realizar
una interacción.
13
2.4.1.1. Aspecto Aplicativo Una aplicación gráfica, está basada en el patrón de arquitectura MVC (13) (Modelo-Vista-
Controlador), donde el modelo contiene los elementos gráficos que componen una
escena, la vista se encarga de la visualización de los resultados, y el controlador es el
encargado de coordinar la información entrante y procesarla para modificar el modelo.
Con esta concepción, el funcionamiento de una aplicación interactiva se puede entender
en tres componentes básicos: El componente de visualización que es el encargado de
manejar el modelo de la escena y de su proyección en una pantalla, el componente de
aplicación se encarga de hacer el procesamiento de las entradas y modifica el estado del
modelo de la escena y el componente de interacción que se encarga de la interpretación
de las entradas del dispositivo y las convierte en ordenes para el componente de
aplicación.
El trabajo de estos componentes se desenvuelve en un entorno común para todas las
aplicaciones interactivas. La lógica del programa y como debe hacer la retro-alimentación,
lo que corresponde a los componentes de aplicación y visualización, trabaja con un
conjunto de datos y define las acciones o comportamientos que deben ocurrir en caso de
que ciertos eventos programados ocurran.
Componente de Interacción
Componente de aplicación
VistaVistaControladorControlador
ModeloModelo
Componente de Visualización(Grafo de Escena)
Componente de Visualización
(Sistema de Proyección)
FIGURA 2. CONFORMIDAD DE LA ARQUITECTURA DE UNA APLICACIÓN INTERACTIVA A MVC.
Componente de Visualización Con el surgimiento de nuevos usos para aplicaciones de la realidad virtual, y el apogeo de
los videojuegos, la implementación se estableció dentro de un conjunto de lenguajes de
alto nivel o uso de librerías que simplifican el proceso de programación. La mayoría de las
aplicaciones interactivas sean de simulación, modelaje, o entretenimiento funcionan con
frameworks que se enfocan en un modelo genérico de datos llamado grafo de escena.
14
Un grafo de escena es una construcción jerárquica donde se almacena en un nodo la
información de la geometría de los objetos de una escena en un nodo y la información de
las modificaciones geométricas, denominadas transformaciones geométricas. Una
transformación geométrica, es la modificación de posición, escala o rotación que se hace
sobre los elementos subordinados de ese nodo. El cambio de los valores, sea de las
geometrías o de las transformaciones, se ven reflejadas en la forma como se hace la
proyección y visualización de cada elemento en el escenario. Esos cambios se pueden
hacer en un proceso automatizado o con intervención humana.
El componente de visualización se encarga de la administración del grafo de escena y su
proyección en el sistema de visualización configurado para el entorno. Las funciones
principales del componente de visualización son de agregar, eliminar y modificar la
información interna de las geometrías que hacen parte del grafo de escena. Así mismo, se
hace la proyección y la configuración de la proyección.
Componente de Aplicación Las funcionalidades de una aplicación son determinadas por los objetivos para lo que es
creada. Esto da espacio para una variedad de elementos que intervienen y modifican los
datos existentes en el modelo. Por lo que es necesario un organizador y orquestador de
las acciones predeterminadas, de las acciones realizadas por parte del usuario y de los
efectos de estas acciones sobre el modelo de datos.
En este contexto, el componente de la aplicación se encarga de cargar y modificar la
información de los estados de la ejecución de la aplicación. Una aplicación puede estar
compuesta por varios estados, en donde las tareas que se ofrecen en cada uno de los
estados es distinta. Por ejemplo, en un videojuego simple se definen dos estados, el de
menú y del juego. Una tarea que se ofrece en el estado juego es ir a la siguiente opción
mientras que esa opción en el estado juego no se presenta. De la misma manera, si se
analizan tareas del estado juego, se puede decir que no están definidas en el estado de
menú.
El comportamiento del componente de aplicación basado en una máquina de estados es
importante cuando las acciones por parte del usuario son las mismas en estados
específicos y su resultado es diferente. Son criterios que el componente de interacción
debe tener en cuenta al momento de comunicarse con el componente de la aplicación.
Componente de Interacción La intervención del usuario con distintos dispositivos y elementos que sean parte del
entorno virtual tienen un significado. Este proceso de comunicación entre el ser humano y
una aplicación, se llama interacción. La interpretación de los valores que provienen de las
15
entradas dispuestas por el dispositivo y lo que necesita el componente de aplicación para
realizar una tarea que depende del usuario, es realizada por parte del componente de
interacción.
2.4.1.2. Aspecto Conceptual El proceso de transformación de la información, desde la concepción por parte del usuario
de realizar una acción hasta la interpretación por parte de la aplicación se llama Metáfora
de interacción. Este es el concepto base para la interpretación de los elementos y etapas
que hacen parte de la interacción basada en gestos.
Una metáfora en el nivel estricto de la palabra es una figura literaria que representa una
analogía entre dos elementos. En la década de los 80’s el significado de metáfora se ha
extendido como el proceso de mapear un conjunto de correspondencias de un dominio de
origen a un dominio de destino (14). En el contexto de la interacción en una aplicación, el
dominio de origen son los conceptos de acciones que tiene el usuario sobre la aplicación,
el dominio de destino es la interpretación que hace el computador para mostrar el
resultado de la idea del usuario.
FIGURA 3. METÁFORA DE INTERACCIÓN
El proceso de la metáfora de interacción, descrito en la Fig. 3 comprende por las
siguientes etapas: descripción de la intención, la construcción y detección de la
16
gestualidad, la interpretación de los datos del gesto y el procesamiento de estos datos
para la aplicación.
Intención Se establece como el objetivo, descrito mentalmente por el usuario, de la acción que se
quiere hacer dentro del contexto de una aplicación. Es el concepto más abstracto que
hace parte de todo el proceso de interacción, y el objetivo principal de toda la metáfora es
deducir la intención del usuario. Por ser una construcción mental, la complejidad de su
lectura en este modelo se reduce a la detección de los gestos que la expresan.
Gestos Es la expresión corporal con la que el usuario comunica una acción o una orden de lo que
quiere hacer dentro de la aplicación, bajo este contexto, se puede también interpretar
como la expresión física de la intención del usuario. Los gestos pueden ser expresados por
una o varias partes del cuerpo, y cada uno de las partes que intervienen puede tener
también un significado.
Los gestos pueden ser expresados por medio de un conjunto de movimientos de distintas
partes del cuerpo, o simplemente pueden ser la posición fija de una parte del cuerpo. Los
primeros son denominados como gestos estáticos, y los siguientes son gestos dinámicos.
Teniendo en cuenta la parte física, en (8) se hace la distinción entre los siguientes tres
tipos de gestos según las partes que lo expresan: Manos y brazos, cabeza y cara y los que
se pueden hacer con las otras partes del cuerpo. Tomando como base la taxonomía
descrita en (4), estas definiciones intervienen dentro del criterio interpretativo.
Dependiendo del tipo de gesto, puede contener una trayectoria, o solamente una posición
en especial. La trayectoria es un conjunto de puntos de dos o tres dimensiones en un
espacio de tiempo. Cualquier acción por parte del usuario que sea similar y cumpla con las
restricciones de tiempo de esa trayectoria, es identificado como ese gesto.
Un gesto como se enunció anteriormente depende de un contexto físico y un contexto
aplicativo. El contexto físico es la descripción del ambiente de trabajo, los dispositivos de
entrada y de salida que intervienen en la interacción. En cambio el contexto aplicativo es
el que describe la funcionalidad de la aplicación y cuales son las tareas que debe cumplir.
Dispositivos Un dispositivo es un arreglo de sensores que ayudan en la detección de movimientos del
cuerpo humano. Cada uno de los sensores determinan los valores de una entrada, y estos
valores pueden ser discretos binarios, analógicos reales o de posición. Dependiendo del
17
criterio que se use para cada una de las entradas, se puede determinar el recorrido o
patrón que corresponde a un fragmento de gesto.
Un gesto se representa con uno o varios dispositivos, y se define con una secuencia
ordenada de datos proveniente de los dispositivos que intervienen en la interacción.
Tareas de la aplicación Son las tareas básicas que se pueden hacer con los elementos que hacen parte de la
aplicación. Una secuencia de estas tareas definen los pasos que se deben seguir para
completar el resultado que espera el usuario por la acción que realiza y por cada una de
estas tareas se presenta una retroalimentación por medio de los dispositivos de salida.
Cada una es independiente del gesto y del dispositivo que se esté usando en el entorno.
Las tareas más simples de una aplicación de ambientes virtuales son denominadas
técnicas de interacción.
18
3. MODELO DE INTERACCIÓN BASADA EN GESTOS Se plantea un modelo que cumple con la estructura conceptual de una metáfora de
interacción para aplicaciones interactivas que sean construidas acorde a una arquitectura
específica. Por lo tanto, para un conjunto de acciones que son expresadas por medio de
gestos, se pueden definir una secuencia de tareas de una aplicación sin la necesidad de
hacer una implementación completa del componente de interacción para distintos
dispositivos.
Dentro de la estructura del modelo, también se define la arquitectura de un componente
de interacción. En la arquitectura se establece un flujo de datos conforme al modelo,
donde el proceso de la metáfora de interacción se refleja en el funcionamiento de la
interacción de una aplicación.
3.1. DESCRIPCIÓN DEL MODELO A partir de los conceptos que hacen parte de la metáfora de interacción, se establece un
modelo formal con las relaciones entre los elementos que la conforman. Cada una de las
secciones del modelo hacen una correspondencia directa con las etapas descritas en el
proceso de mapeo de la intención del usuario hasta las tareas de la aplicación.
En el Anexo A se pueden ver dos ejemplos de metáforas de interacción que se han
adaptado al modelo, donde son usados en aplicaciones cotidianes.
3.1.1. GESTUALIDAD Hace una descripción detallada de la estructura de los gestos. Determina la distinción que
existe entre los dos tipos de gestos: gesto estático y gesto dinámico. Cada gesto tiene
asociados varios dispositivos de los que dependen los valores de las entradas de las
posiciones que componen el gesto estático o la trayectoria del gesto dinámico. Cada gesto
tiene propiedades que lo caracterizan y lo describen según los criterios establecidos en la
taxonomía.
3.1.2. INTERPRETACIÓN Se divide en dos secciones: El operacional y el responsable del flujo de información. En la
sección operacional, se hace la definición de las operaciones encargadas de la
transformación de los valores. En cambio, en la sección del flujo de información, la función
principal es tomar los valores de salida del gesto (Concepto Inicial), transportarlos por
medio de las operaciones (Concepto Intermedio) transformando los valores y asignar los
valores de las entradas para las tareas de la aplicación (Concepto Final).
19
3.1.3. PROCESAMIENTO Tiene la definición de las tareas de la aplicación con sus correspondientes parámetros.
Cada parámetro tiene un nombre y un tipo. El valor del parámetro viene asignado por los
resultados obtenidos de la etapa de interpretación.
FIGURA 4. MODELO DE LOS CONCEPTOS DE LA METÁFORA DE INTERACCIÓN
3.2. DESCRIPCIÓN DEL MODELO DE LA ARQUITECTURA El componente de interacción divide el flujo de datos en tres campos: Gestualidad,
interpretación y procesamiento de datos. Cada una de estas etapas representa cada
concepto que interviene en la metáfora de interacción. En el campo de la gestualidad se
hace la detección de los gestos y su relación con las entradas provenientes de los
dispositivos del ambiente inmersivo, el campo de interpretación se encarga de la
transformación de la información de los gestos (y de los valores de las entradas generadas
por los dispositivos), y por último el campo de procesamiento se encarga de encadenar los
valores del campo de interpretación con las tareas de la aplicación, en este caso con las
técnicas de interacción de la aplicación de ambientes inmersivos.
20
FIGURA 5. ARQUITECTURA INTERNA DEL COMPONENTE DE INTERACCIÓN
3.2.1. GESTUALIDAD La etapa de gestualidad se divide en dos pasos: Interpretación y administración de los
dispositivos y la identificación de los gestos. Para cada uno de los pasos de esta etapa se
tiene un módulo con funciones específicas.
Módulo de administración de dispositivos: Es el módulo encargado de la administración de
los dispositivos, también es el módulo que hace la interpretación de los dispositivos donde
convierte la información proveniente de las entradas de los dispositivos en valores que
sean entendibles en el módulo encargado de la identificación de gestos.
Módulo de detección e identificación de gestos: es el módulo encargado de identificar, por
medio de los valores generados en el módulo de administración de dispositivos por un
conjunto de dispositivos, cuál es el gesto que el usuario está intentando realizar. Este
componente para poder reconocer un gesto debe almacenarlos y administrarlos, por lo
tanto contiene dos módulos que cumplen la tarea de registrar los nuevos gestos y una
librería de gestos donde se pueden eliminar, modificar y seleccionar gestos para una
aplicación.
3.2.2. INTERPRETACIÓN Para el proceso de la metáfora de interacción, se representa como la caja negra que se
encarga de hacer una secuencia de transformaciones de los valores del gesto y devuelve
una respuesta que sea comprendida por parte de la aplicación. Se puede definir
21
internamente como el conjunto de funciones, también representadas como cajas negras,
que se encargan de recibir valores de entrada y después de un procesamiento devuelven
un arreglo de salidas, que también pueden ser entradas para otras funciones.
3.2.3. PROCESAMIENTO Es el puerto de salidas de los datos provenientes del procesamiento de la información de
los gestos. Establece la comunicación entre el componente de interacción y el
componente de aplicación. Cada uno de los mensajes que envía el componente de
interacción corresponde a la información asociada a una tarea: la información descriptiva
de la tarea y los parámetros requeridos.
Para poder cumplir con la descripción y la asignación de los parámetros, se debe tener una
definición previa de las tareas de la aplicación, algo que implica una librería de las tareas
para esa aplicación. La obtención de esta información implica que la comunicación debe
ser bidireccional, y el componente de aplicación debe tener un componente que sea
integrable a este tipo de comunicación.
3.2.4. COMUNICACIÓN La integración de los dos componentes de interacción y de aplicación se debe tener en
cuenta los estados de la aplicación. Dado que esta etapa tiene comunicación bidireccional,
en el módulo de procesamiento se debe tener en cuenta la disponibilidad de las tareas
según el estado actual de la aplicación. El componente de aplicación debe proveer una
interfaz que ofrezca los servicios de consulta de los estados de la aplicación, el estado
actual y las tareas que corresponden al estado.
22
4. DISEÑO E IMPLEMENTACIÓN Para comprobar el funcionamiento del modelo, se desarrolló una plataforma que cumple
con las condiciones de la propuesta. Se evaluaron herramientas y frameworks existentes
que se acomodaran a la propuesta y los resultados se presentaran dentro del tiempo
establecido. Se excluyeron puntos importantes en el desarrollo por este último motivo.
Situaciones que se enunciaran más adelante.
4.1. PLANTEAMIENTO DEL SOFTWARE SOLUCIÓN La plataforma debe cumplir con el proceso especificado dentro de la metáfora de
interacción. Se tiene como principal base la propuesta de la arquitectura que también es
basada en el modelo propuesto para aplicaciones interactivas.
La implementación de la solución se enfoca en el uso de librerías y plataformas ya
existentes para mostrar que el modelo puede ser aplicable a software ya existente. En
este caso, el API general del desarrollo de uno de los componentes se enfoca
principalmente en OpenNI, y para poder abarcar una mayor cantidad de dispositivos en un
proceso de implementación menos dispendioso, también se determino el uso de VRPN.
4.2. PLATAFORMAS DE DESARROLLO Son las plataformas que se evaluaron y se usaron para el desarrollo de la solución de la
propuesta. Los criterios con los que se evaluaron estas plataformas, fueron las siguientes:
En caso de trabajar por módulos, que el nivel de acople entre los distintos módulos
no fuera alta. Es decir, que se pudieran conectar y desconectar distintos módulos
sin problemas.
Permita añadir nuevos dispositivos que no estén soportados inicialmente por la
plataforma.
Se hayan establecido como un estándar o al menos su uso sea amplio por gran
parte de la comunidad que se enfoca en el desarrollo de aplicaciones interactivas.
Provean las funcionalidades que se buscan dentro de la propuesta del modelo.
4.2.1. OPENNI OpenNI (Open Natural Interaction, por sus siglas en Inglés) (15) es una nueva propuesta
de estándar para la integración de Interacción Natural, uso de gestos y comunicación
verbal, en las aplicaciones. OpenNI consiste en un conjunto de interfaces que permiten la
interoperabilidad entre distintos módulos que llaman nodos de producción. Existen dos
tipos de nodos de producción: Sensoriales que se encargan de representar los dispositivos
y los Middleware que son los que se encargan de hacer el procesamiento de la
información que sean salidas de otros nodos de producción.
23
FIGURA 6. LA ARQUITECTURA PROPUESTA EN OPENNI (16)
Un concepto importante dentro de OpenNI son las cadenas de producción. Son el
encadenamiento de los nodos de producción desde un generador de datos, como los
nodos de sensores hasta la información que debe recibir y manejar la aplicación. Proceso
que se asemeja al que está descrito en la metáfora de interacción y en el modelo.
El flujo de la información dentro de OpenNI siempre inicia con un evento realizado por
alguno de los generadores de información. Por lo tanto, esta plataforma se puede
determinar que cumple con una arquitectura basada en eventos. Esto permite que el uso
de recursos dentro de la cadena de transformación sea mínimo.
Una de las limitaciones que se observaron en esta plataforma, fue que estaba orientada a
trabajar directamente con Microsoft Kinect (17) y el uso de dispositivos visuales. Eso
implicaba la implementación de un nuevo nodo de producción sensorial que funcionara
con los dispositivos con los que se espera interactuar.
En la adaptación de OpenNI para el modelo fue necesario determinar un conjunto de
restricciones que permitiera tener una cadena de producción que fuera conforme al
modelo propuesto. También se evaluó que los elementos adicionales que se pudieran
implementar pudieran cumplir con las restricciones propias, que implica la creación de un
nodo de producción de OpenNI.
24
FIGURA 7. ADAPTACIÓN DEL MODELO OPENNI AL MODELO DE INTERACCIÓN BASADA EN GESTOS
En la adaptación del modelo se incluye un módulo de Interpretación de movimientos, que
son las definiciones por defecto de detección de movimientos y gestos que tiene OpenNI
para trabajar directamente con el Kinect. Se determina una asociación con el módulo de
Interpretación de gestos, debido a que se debe tener una definición común para seguir un
estándar en el proceso de la cadena de producción. El módulo de comunicación es el
encargado de transmitir los datos obtenidos de las cadenas de producción y recibir la
información referente a la aplicación que es desarrollada por fuera de OpenNI.
4.2.2. VRPN VRPN (Virtual Reality Peripheral Network, por sus siglas en inglés) (18), es una plataforma
distribuida para dispositivos dispuestos en red. Hace una generalización de los datos de
salida de los dispositivos, esos tipos de datos son los siguientes: Análogos que representa
todas las salidas reales del dispositivo, botones que identifica la salida de un botón del
dispositivo y los datos de posición que representan la información generada por un
dispositivo de seguimiento.
VRPN transmite la información de los dispositivos por medio de un servidor que es
configurado con los dispositivos correspondientes. Para acceder a la información de un
dispositivo solo es necesaria acceder por medio de un cliente propio que pueda
interpretar los datos de VRPN.
Esta plataforma permite obtener información de cualquier dispositivo que esté soportada,
o en el peor de los casos, se puede crear un driver para ese dispositivo, sin tener que
intervenir en el código del cliente que recibe esta información. En cambio otros
dispositivos ya disponen de su propio servidor VRPN como medio de difusión de los datos
generados.
25
Una de las ventajas que ofrece esta plataforma es la difusión de la información de muchos
dispositivos y la generalización con la que se manejan los dispositivos. También, se puede
recibir información de varios dispositivos de distintos lugares, por lo que facilita el proceso
de detección de gestos que sean multi-dispositivos. Es una herramienta muy usada dentro
de la comunidad, y tiene buen soporte en caso de que se quiera crear un servidor con
características específicas.
4.3. DESCRIPCIÓN DE LOS COMPONENTES La plataforma completa provee una administración de la interacción, y establece
comunicación con una capa intermedia que representa la aplicación, como se mostró
anteriormente en la Fig. 5. Cada una de estas grandes tareas deben ser administradas por
un componente distinto: El componente de interacción y el componente de aplicación.
En el Anexo B se encuentra la descripción del diseño en el modelo UML que corresponde a
cada módulo y componente.
4.3.1. COMPONENTE DE INTERACCIÓN Es el componente encargado de procesar la información de los dispositivos y convertirla
en datos que son interpretadas por la aplicación. Este componente se divide en cuatro
módulos principales que cumplen funciones específicas en el proceso de interpretación: El
módulo de dispositivos VRPN, el módulo de detección de gesto, el modulo de
interpretación y el módulo de comunicación con la aplicación. Todos estos módulos
implementan la interfaces ofrecidas por OpenNI para mayor modularidad en caso de que
se quiera mejorar o reemplazar por otro nodo de producción que cumpla similares
funciones.
Comparando con el modelo de la arquitectura, los módulos de dispositivos y de detección
de gestos pertenecen a la sección de gestualidad, el módulo de interpretación
corresponde a la sección de interpretación y el de comunicación con la aplicación a la
sección de procesamiento.
Módulo de Dispositivos VRPN Es el encargado de administrar las conexiones a los dispositivos que se acceden por VRPN.
Su funcionamiento se basa en tener varios clientes VRPN, cada uno para cada dispositivo.
Se hace el manejo de los eventos generados por los dispositivos que están conectados.
Módulo de Detección de Gestos Su función principal es detectar los gestos a partir de los eventos generados por los
dispositivos. Para ello ofrece una estructura de datos que representa el dispositivo y una
26
interfaz que ofrece los servicios de registro y consulta de gestos, y hace el procesamiento
de un evento de un dispositivo para la detección de gestos.
Internamente ofrece interfaces y estructuras básicas que ayudan en la definición de
gestos. Tiene una estructura para definir los gestos dinámicos y otra estructura para
definir los gestos estáticos. Cada una de estas definiciones tienen en cuenta que un gesto
es representado por una máquina de estados que evaluan los datos que provienen en
cada uno de los eventos generados.
El mecanismo detecta un gesto, cuando todos los estados que corresponden a la máquina
de estados han sido evaluados.
Varios dispositivos para realizar una tarea dentro de la aplicación, pueden desarrollar
acciones similares que pueden determinarse por la misma máquina de estados de un
gesto. Para ello se ofrece también la funcionalidad de hacer un registro adicional de
gestos duplicados pero para cada uno de los dispositivos que lo necesiten.
Debido a que se emplea un sistema de detección generalizado, sin importar el dispositivo,
se aplica una normalización de los datos previamente a hacer la evaluación en las
máquinas de estado de los gestos registrados. Al finalizar el proceso se puede configurar
los rangos de salida de las coordenadas que se establecieron para el gesto detectado para
un dispositivo.
Módulo de Interpretación Se encarga de la transformación de la información de los gestos a los valores que se
requieren en la aplicación. Este módulo contiene un conjunto de cajas negras que recibe
un conjunto de entradas y obtiene un resultado. Este módulo no se implementó por
completo, debido a que el módulo de comunicación y el módulo de detección de gestos
asumieron esta función.
Está compuesto por un conjunto de operaciones que procesan la información de uno o
varios gestos, obteniendo el resultado que se necesita para la tarea de la aplicación
correspondiente.
Módulo de Comunicación con la Aplicación Es el módulo que se encarga de contactar con el componente de aplicación y especificar
los datos provenientes de un gesto como corresponden a los parámetros de ejecución de
una tarea de la aplicación. Este módulo provee la estructura de datos que se usa para la
definición de un gesto, teniendo en cuenta los dos tipos: Dinámicos y estáticos. Y a partir
27
de eso, hace el procesamiento de asignaciones y validaciones, a que tarea de la aplicación
corresponde el evento gestual recibido.
Debido a que el componente de aplicación también está modelado como una máquina de
estados, en la cuál cada estado contiene un conjunto de tareas. Este módulo se encarga
de hacer la respectiva coordinación entre el estado, el gesto y la tarea que corresponde a
este gesto en el correspondiente estado. Esto también significa que no necesariamente un
estado detectado corresponde a una tarea o tenga algún tipo de retroalimentación en la
aplicación.
Una de los elementos que se tuvo en cuenta al diseñar este componente, es que las
aplicaciones no necesariamente se desarrollan bajo la misma API, y mucho menos sobre el
mismo lenguaje de programación. Por lo tanto, teniendo como base proyectos realizados
anteriormente (19) se desarrollo un sistema de comunicación en red entre el módulo y el
componente de aplicación. Esto implicó también el diseño de un protocolo de
comunicación propio para la transmisión de información de los estados y de comandos
para la ejecución de tareas en el lado del componente de aplicación.
4.3.2. COMPONENTE DE APLICACIÓN Es el componente encargado de transmitir los estados de la aplicación y procesar los
mensajes y los parámetros que corresponden a cada una de las tareas de la aplicación.
Una de las características necesarias para que este componente fuese funcional, es que
debía ser adaptable a cualquier aplicación, pero que de esa misma manera cumpliera con
los requerimientos para su integración con el componente de interacción.
Las tareas de la aplicación deben proveer una descripción de los objetivos que cumple
dentro de la aplicación. Esto se debe a que por definición se deben saber cuales son los
valores que son necesarios en el procesamiento posterior a la detección de un gesto y
como deben ser los valores de los parámetros que la tarea necesita para tener una
ejecución correcta.
Para el caso de ejemplo, se diseño una librería en Java que obtiene los servicios que sean
ofrecidos por la aplicación, y mantiene la comunicación con el componente de interacción
que le solicite conexiones.
El protocolo de comunicación entre los dos componentes se encuentra presente en el
Anexo C de este documento.
4.4. PROCESO DE ADAPTACIÓN La plataforma presentada anteriormente, debido a ser un sistema solo de soporte,
necesita tener una configuración y una aplicación especial para ver su funcionamiento.
28
Para ello se debe hacer una adaptación de una aplicación interactiva y un conjunto de
gestos en un ambientes de trabajo. La funcionalidad de la plataforma en su totalidad
demuestra que el modelo que se está proponiendo se puede producir y aplicar en
aplicaciones ya existentes.
Esta aplicabilidad y adaptación de un ambiente de trabajo para una aplicación se debe
hacer con un conjunto de reglas y restricciones. A esta guía con sus respectivos pasos se le
va a determinar como el proceso de adaptación de una aplicación interactiva a la
plataforma.
Cada tarea de aplicación en sus respectivos estados corresponde a una metáfora de
interacción. En este proceso se deben identificar los gestos a usar y tener en cuenta como
se deben detectar y el significado que le corresponde en los dos contextos
correspondientes:
Contexto Aplicativo. El contexto aplicativo es la descripción de las tareas y las funciones
que realiza la aplicación. En este se deben especificar los estados de la aplicación y las
tareas que se realizan en cada uno de ellos. Esta información es importante para cuando
se haga la configuración del componente de aplicación y el módulo de comunicación en el
componente de interacción.
Contexto Físico. El contexto físico es la descripción del espacio y los dispositivos con los
que se interactúa en el espacio. Ya teniendo en cuenta los dispositivos, se pueden definir
los gestos que representan cada una de las tareas en cada uno de los estados de la
aplicación. Esta información se requiere para la asignación de los dispositivos y su
correspondiente gesto en el módulo de detección de gestos y la asignación de los mismos
a las tareas de aplicación en el módulo de comunicación, todo lo anterior para el
componente de interacción.
29
5. APLICACIÓN DE EJEMPLO Para poner en práctica el proceso anteriormente explicado se debe aplicar en una
aplicación ya existente. Este proceso implica desarrollar el componente de aplicación con
la librería definida para ello, y establecer la configuración correspondiente para cada uno
de los gestos que intervienen en las distintas metáforas de interacción.
5.1. CONTEXTO APLICATIVO
Descripción de la aplicación Es una aplicación desarrollada para mostrar el crecimiento de la ciudad de Bogotá en los
siguientes años en tres escenarios distintos. Además de tener una navegación temporal
entre estos tres escenarios distintos se permite la navegación espacial similar a la de un
helicóptero. El único estado es el de navegación espacial ya que la navegación temporal se
hace por comandos que únicamente cambian los datos que se visualizan, pero se
mantiene las tareas de navegación espacial.
FIGURA 8. VISTA DE LA APLICACIÓN DEL GOBERNADOR
La aplicación tiene una visualización en 3D de la ciudad. La imagen de la Fig. 9 es el
resultado de la navegación en el escenario.
Tareas de la aplicación En la navegación espacial presenta los siguientes tipos de movimientos:
Movimiento al frente y atrás de la cámara
Movimiento hacia los lados de la cámara
30
Movimiento arriba y abajo respecto al escenario
Rotación de la cámara sobre el eje vertical (Rotar la cabeza hacia los lados)
Rotación de la cámara sobre el eje horizontal (Inclinar la cabeza hacia arriba y
abajo)
5.2. CONTEXTO FÍSICO El espacio en el que va a funcionar inicialmente la aplicación es en la mesa de visualización
con el OptiTrack.
Espacio y dispositivos El OptiTrack (20) es un dispositivo de seguimiento que se compone por un conjunto de
cámaras sincronizadas que obtienen la posición de pequeñas piezas con material
reflectivo que sirve para ubicarse en un espacio 3D. En el laboratorio de visualización,
estas cámaras están dispuestas sobre una estructura que emula una mesa, y que en su
superficie se proyecta la aplicación.
FIGURA 9. LA MESA INTERACTIVA USANDO LAS CÁMARAS OPTI-TRACK PARA EL SEGUIMIENTO DE LOS
TRACKERS QUE ESTÁN DISPUESTOS SOBRE LA MESA
El OptiTrack puede hacer seguimiento de varios trackers, como se ve en la Fig. 9, y esto se
puede aprovechar para tener varias partes del cuerpo interviniendo en el ambiente. En
este caso, solo se usaran las dos manos.
31
Gestos identificados Con los marcadores que se usan dentro del espacio del optitrack, se asume que cada uno
de ellos representan las manos del usuario. Los primeros tres gestos se enfocan en la
navegación basada en la translación de la cámara. Estos se hacen sobre los ejes principales
de la cámara. El movimiento sobre el eje vertical se usó también el gesto definido en la
Figura 11, pero con otro marcador que representa otra mano.
Gesto Dinámico:Nombre: Mover la mano izquierda hacia un lado horizontalmente.Aplicativo: Navegación en dos dimensiones.Interpretativo: ManipulaciónTrayectoria:
Traker1->PosInicial (x, y, z),Tracker1->PosFinal(x, y, z)
Dispositivo:Mesa con cámaras infrarrojas.Tracker1: Posición mano derecha.
Tracker2: Selector del estado de la aplicación.
FIGURA 10. GESTO DEL MOVIMIENTO HORIZONTAL IZQUIERDA-DERECHA Y DE DERECHA-IZQUIERDA
Gesto Dinámico:Nombre: Mover la mano izquierda en sentido vertical.Aplicativo: Navegación en dos dimensiones.Interpretativo: ManipulaciónTrayectoria:
Traker1->PosInicial (x, y, z),Tracker1->PosFinal(x, y, z)
Dispositivo:Mesa con cámaras infrarrojas.Tracker1: Posición mano derecha.
Tracker2: Selector del estado de la aplicación.
FIGURA 11. GESTO DEL MOVIMIENTO DE AVANCE Y RETROCESO
32
Los siguientes gestos definen el cambio de rotación de la cámara sobre el eje vertical
(rotación de la vista de izquierda a derecha), y la inclinación de la cámara sobre el eje
horizontal (rotación de la vista de arriba a abajo).
Gesto Dinámico:Nombre: Mover la mano derecha hacia un lado horizontalmente.Aplicativo: Navegación en dos dimensiones.Interpretativo: ManipulaciónTrayectoria:
Traker1->PosInicial (x, y, z),Tracker1->PosFinal(x, y, z)
Dispositivo:Mesa con cámaras infrarrojas.Tracker1: Posición mano derecha.
Tracker2: Selector del estado de la aplicación.
FIGURA 12. GESTO DE ROTACIÓN DE LA CÁMARA DE IZQUIERDA A DERECHA
Gesto Dinámico:Nombre: Mover la mano derecha en sentido vertical.Aplicativo: Navegación en dos dimensiones.Interpretativo: ManipulaciónTrayectoria:
Traker1->PosInicial (x, y, z),Tracker1->PosFinal(x, y, z)
Dispositivo:Mesa con cámaras infrarrojas.Tracker1: Posición mano derecha.
Tracker2: Selector del estado de la aplicación.
FIGURA 13. GESTO DE INCLINACIÓN DE LA CÁMARA HACIA DELANTE Y ATRÁS
33
6. EVALUACIÓN En la etapa de evaluación se quiere corroborar que este modelo es un nuevo aporte en el
desarrollo de aplicaciones interactivas para el uso de cualquier persona.
Por eso se plantean criterios de evaluación y de comparación con herramientas existentes
en el mercado, para demostrar un avance en el desarrollo de una nueva plataforma
flexible, y que simplifica el proceso de implementación y desarrollo de una aplicación
interactiva. Estos criterios se enfocan en eficiencia y usabilidad. Estos dos últimos criterios
se basan en una evaluación hecha a usuarios y desarrolladores de aplicaciones
interactivas.
6.1. CRITERIOS DE EVALUACIÓN La evaluación se hizo sobre la ejecución de la plataforma, en ambientes en condiciones
específicas. Se hicieron las siguientes tres pruebas:
Rendimiento. Se prueba el tiempo de respuesta en que se demora en procesar un evento
generado por un dispositivo hasta que se termina de recibir la respuesta por parte de la
aplicación. En estas pruebas se tienen en cuenta las variables de tipo de conexión entre
los componentes de interacción y de aplicación, el protocolo de validación para la
ejecución de la tarea (Anexo C).
Adaptabilidad. Se prueba la capacidad de la plataforma para que una persona pueda
entenderlo, adaptar una aplicación y hacer el manejo de los dispositivos.
Usabilidad. En este aspecto se realizó una prueba de usuario y una encuesta con las
posibles mejoras en el uso.
6.2. RESULTADOS DE LA EVALUACIÓN Estos fueron los resultados que se presentaron en la evaluación con los respectivos
escenarios de pruebas.
6.2.1. RENDIMIENTO Para las pruebas de rendimiento se establecieron dos escenarios distintos, uno donde se
trabaja la aplicación sobre la misma WLAN y en un segundo caso donde los dos
componentes se encuentran en subredes LAN.
En este caso se debe tener en cuenta que la implementación de módulo de comunicación
funciona secuencialmente. Quiere decir que el módulo no sigue ejecutando tareas hasta
que no haya recibido una respuesta por parte del componente de aplicación. Además que
consta de un timeout de dos segundos en caso de no recibir alguna respuesta.
34
Sobre la WLAN
Velocidad de Transferencia local estimada: 54Mbps
Componente de Interacción:
Macbook Pro 13”
o Procesador: Intel Core i5 2.3 GHz
o RAM: 4GB 1333 MHz DDR3
o Wi-Fi: BCM43xx
Componente de Aplicación:
Dell XPS 15
o Procesador: Intel Core i5 2.3 GHz
o RAM: 6GB 1333 MHz DDR3
o Wi-FI: BCM43xx
TABLA 1. RESULTADOS DE TIEMPOS DE EJECUCIÓN DE LAS TAREAS DE UNA APLICACIÓN DENTRO DE
UNA RED LOCAL
Número de la tarea
Tarea de ejecución Tiempo promedio
(ms.)
Desviación Estándar (ms.)
1 Mover Vertical 26,9 4,28 2 Mover Horizontal 25,2 4,69 3 Mover Frente 24,3 4,31 4 Inclinar Cabeza 24,5 5,71 5 Rotar Cabeza 25 5,46
Total 25,18 5,03
Con estos datos se puede establecer que el tiempo promedio de respuesta en una WLAN
(un caso menos optimista que una LAN), tiene en promedio 25,18 milisegundos. Esto
estima que se tiene un tiempo de refresco menor al que se hace en el re muestreo de una
secuencia de video.
El retraso que se puede reflejar entre el cambio de instrucciones por cada uno de los
gestos, es muy pequeño a lo que puede detectar el ojo humano. Estos datos solo son para
los gestos que fueron procesados, en el caso de los datos no procesados existe un timeout
de 50 milisegundos. Este tiempo de espera, con máximo dos instrucciones seguidas sin ser
procesadas por la aplicación, permite tener un tiempo de respuesta aceptable para el ojo
humano.
35
Sobre subredes LAN
Velocidad de Transferencia local estimada: 100Mbps
Componente de Interacción:
- Macbook Pro 13”
o Procesador: Intel Core i5 2.3 GHz
o RAM: 4GB 1333 MHz DDR3
o Wi-Fi: BCM43xx
Componente de Aplicación:
- Dell XPS 15
o Procesador: Intel Core i5 2.3 GHz
o RAM: 6GB 1333 MHz DDR3
o Wi-FI: BCM43xx
TABLA 2. RESULTADOS DE TIEMPOS DE EJECUCIÓN DE LAS TAREAS DE UNA APLICACIÓN DENTRO DE
DOS COMPUTADORES EN INTERNET
Número de la tarea
Tarea de Ejecución
Tiempo promedio
(ms.)
Desviación Estándar
(ms.) 1 Mover Vertical 88,1 13,83 2 Mover Horizontal 91,4 10,25 3 Mover Frente 89,6 12,34 4 Inclinar Cabeza 91,6 11,33 5 Rotar Cabeza 86,4 13,15
Total 89,42 12,38
Con estos datos se puede establecer que el tiempo promedio de respuesta sobre subredes
LAN. Un caso de ejemplo, se realizó dentro de la universidad, teniendo un computador
conectado a la red de cable y otro en la red inalámbrica. En general el promedio de los
resultados el promedio de los tiempos es de 89,42 milisegundos, con una desviación
promedio de 12,38 segundos. Esto estima que se tiene una tasa de refresco aproximada
de 60Hz, que es una velocidad suficiente en la ejecución de aplicaciones gráficas.
En el proceso de toma de datos también existe el mismo retraso de las pruebas
anteriores. El tiempo de retraso se debe a motivos similares y al retraso mismo de las
conexiones entre los computadores.
36
6.2.2. ADAPTABILIDAD En las pruebas de adaptabilidad se hicieron dos grupos de cuatro personas, cada uno con
un nivel de conocimiento en aplicaciones. Los resultados se tabularon teniendo en cuenta
el tiempo de respuesta para cada una de las siguientes pruebas: Comprensión del
funcionamiento de la plataforma, adaptación de una aplicación usando la librería del
componente de aplicación y la modificación de los parámetros de funcionamiento de los
dispositivos.
Para la aplicación de prueba se tomo una ya existente de navegación similar y se explicó
como es que debe ser el uso de la librería para el componente de aplicación.
Se define un usuario con conocimiento básico, a aquellos que han trabajado en el
desarrollo de algún tipo de aplicaciones. Pero no han profundizado en el uso de
herramientas para el manejo de dispositivos o visualización. Y un usuario con
conocimiento avanzado, es aquella persona que ha implementado aplicaciones
interactivas y además de eso ha desarrollado sobre plataformas de interacción y
visualización.
TABLA 3. RESULTADOS DE LOS TIEMPOS DE LAS PRUEBAS DE USUARIOS DE CONOCIMIENTO BÁSICO
Usuario Tiempo de comprensión
(min.)
Tiempo de Adaptación
(min.)
Tiempo de Modificación
(min.)
Tiempo Total (min.)
1 5:26 9:15 6:42 21:23
2 3:13 6:43 5:26 15:22
3 4:08 10:28 7:01 21:37
4 3:55 7:51 6:12 17:58
Promedio 4:10.5 8:34.25 6:20.25 19:05
TABLA 4. RESULTADOS DE LOS TIEMPOS DE LAS PRUEBAS DE USUARIOS DE CONOCIMIENTO
AVANZADO Usuario Tiempo de
comprensión (min.)
Tiempo de Adaptación
(min.)
Tiempo de Modificación
(min.)
Tiempo Total (min.)
1 3:15 7:28 5:18 16:01
2 4:02 8:41 4:54 17:37
3 2:58 7:58 5:35 16:31
4 3:38 9:13 3:18 16:09
Promedio 2:28,25 8:20 4:46.25 16:34.5
37
Las diferencias entre los dos grupos de usuarios radican en el tiempo de entendimiento
del modelo. Esto se debe a que no están familiarizados con los conceptos de la
plataforma, pero en las etapas prácticas los tiempos de adaptación de la aplicación a la
librería y de modificación de los parámetros del componente de interacción. Esto se debe
a que estas etapas ya se intervienen con conocimientos comunes para los usuarios de
ambos grupos.
6.2.3. USABILIDAD
En la segunda parte de las pruebas se hizo la comparación de los usuarios con dos
dispositivos: el joystick y la mesa de interacción. Se le preguntó al usuario cuál era la
mejor configuración para llegar a una posición específica en el mapa, usando la aplicación
del gobernador. Los gestos son los mismos identificados para esa aplicación.
TABLA 5. RESULTADOS DE LOS TIEMPOS DE PRUEBA DE INTERACCIÓN
Usuario Tiempo Joystick
Tiempo Mesa
Observación
1 1:48 2:18 Es preferible tener un seguidor para subir y mover horizontalmente.
2 1:35 3:05 La velocidad de desplazamiento es muy difícil de definir.
3 1:52 2:05 Ninguna.
4 1:26 2:56 Al intentar girar la velocidad es muy alta.
Promedio 1:39.75 2:38.5
Las observaciones de los usuarios sobre los dispositivos se refirieron a la manejabilidad de
los dispositivos y a la confiabilidad de respuesta en la interacción. Las conclusiones por
parte de los usuarios se refieren más a la forma de interactuar, y no al funcionamiento del
componente o tiempo de respuesta en la aplicación.
38
7. CONCLUSIONES Y TRABAJO FUTURO La meta principal de este proyecto se enfocan en la presentación e implementación de
una plataforma que implementa un modelo que describe la interacción gestual en
aplicaciones interactivas. El paso inicial del proyecto se enfocó en definir la estructura de
la metáfora de interacción, que es el eje principal de la propuesta y que define el flujo de
la información de los gestos realizados por el usuario. Esta definición que ya era enunciada
por otros autores, se consolido y se restructuró hasta la propuesta actual. Pero la
propuesta del concepto principal del modelo no es suficiente para concluir el proceso. Se
debe conocer el dominio en el que están los conceptos que son parte del modelo.
La interacción gestual en especial los gestos son parte importante de la comunicación no
verbal del ser humano, e intentar incluirlo en un entorno distinto al que comúnmente se
desenvuelve, obliga a delimitar un conjunto de reglas y restricciones que definen los
conceptos que pueden incluirse en este dominio. De igual forma, al tener conceptos de
alto nivel que estructuran la interacción y el flujo de información, se le deben asociar
conceptos de nivel de infraestructura los cuales soportan la factibilidad de su desarrollo.
Un dominio enfocado en la interacción en aplicaciones encierra conceptos de nivel de
infraestructura que son la representación de los medios físicos de los medios de
intervención del usuario y conceptos abstractos que explican de la intervención dentro de
la aplicación. A pesar de sus diferencias, se debe tener un modelo que describa el
software que va a utilizar los conceptos del modelo inicial.
El uso de conceptos de una estructura de la aplicación o el componente desde conceptos
de alto nivel, permite un desarrollo independiente de la plataforma y de restricciones
tecnológicas. Un modelo no debe implicar el uso exclusivo de una plataforma, por el
contrario, debe ser un conjunto de condiciones que se deben tener en cuenta para la
selección de la tecnología en el que se va a desarrollar los sistemas que son conformes al
modelo planteado.
Otro objetivo que se planteo para el proyecto, se propuso el desarrollo del sistema que
representaba el funcionamiento del modelo. La generación del modelo de la arquitectura
se basó en el flujo de datos desde los dispositivos hasta la aplicación, influyo en la
designación de una plataforma de base que tuviera el mismo procesamiento de la
información.
El tener un conjunto de conceptos que constituyen un dominio, permite la construcción
en base a ellos, de una semántica propia dentro de una plataforma definida. Una muestra
clara en esta propuesta, es la definición de los ejemplos de metáforas de interacción. Para
39
cada una de las etapas del proceso y desde una visión general se tiene su propia
semántica.
A pesar de la facilidad que se ofrece comunicativamente, a nivel de implementación se
pueden presentar dificultades. En la plataforma presentada, y con la aplicación de
ejemplo, no se alcanzó a desarrollar una semántica natural para el proceso. Con el modelo
planteado, se puede crear un lenguaje que ayude a describir con mayor facilidad la
metáfora de interacción dentro de la plataforma. El uso de un lenguaje de alto nivel
permite que la curva de aprendizaje del uso de la herramienta sea menor, y evite
intervención en el código fuente de la plataforma. Para una futura presentación de la
propuesta es deseable tener una herramienta que usa en lenguaje natural como acceso a
la plataforma a usuarios no experimentados en el desarrollo de interacciones gestuales y
su integración con alguna aplicación.
Este tipo de colaboración al usuario para desarrollar interacción de manera sencilla
implica algún tipo de intervención en los módulos que hacen parte de la plataforma. Un
ejemplo es generar extensiones para el módulo de interpretación. Este módulo es el que
hace la transformación de gestos a los valores de entrada de las tareas de la aplicación.
Las extensiones del módulo se representan como una caja negra que procesa la
información. Este módulo es importante ya que cada gesto en un estado de la aplicación
puede representar una tarea distinta, por lo tanto las salidas de los gestos no siempre van
a corresponder a los mismos parámetros en la aplicación.
Una de las debilidades actuales en la plataforma del modelo es la implementación de los
gestos y de la máquina de estados que corresponde a cada uno de los gestos. Por ello,
para que esto sea conforme al lenguaje que pueda describir la metáfora de interacción, se
debe proveer una librería de gestos que permita la carga y persistencia de nuevos gestos
que se representan con las estructuras de datos que se describen en el modelo. Esto
también implica fortalecer la capacidad de la plataforma para detectar gestos y como en
cualquier lenguaje existen ambigüedades y expresiones de mayor complejidad.
En la actualidad las plataformas, sean de hardware o de software, convergen en la
búsqueda de interfaces intuitivas para la realización de tareas específicas. El proceso de la
metáfora de interacción provee las facilidades de hacer una relación directa entre las
acciones del usuario y de las tareas en la aplicación, y establece restricciones en cómo
debe comportarse cada gesto y su relación con su finalidad, qué es la ejecución de tareas
del lado de la aplicación.
El componente de aplicación actualmente funciona como la librería para aplicaciones
desarrolladas en un lenguaje de programación. Se debe desarrollar librerías y aplicaciones
40
de soporte para los desarrollos que se quieran conectar con el componente de
interacción. Una de las restricciones que se presenta en la plataforma actual solo soporta
intervención por parte de un usuario. Se debe soportar el funcionamiento para
aplicaciones que sean diseñadas para el uso por más de un usuario. Todo el proceso de
identificación y de asignación de tareas se realiza de manera individual y no existe una
identificación de quién es el que hace la respectiva intervención.
El significado de los gestos se puede complementar con la información de dispositivos que
no pertenecen a la modalidad visual. La capacidad de la plataforma de soportar
información auditiva o de elementos que hagan parte del entorno puede nutrir la
experiencia del usuario. El modelo debe soportar estas nuevas experiencias y
complementarla con las ya existentes.
El último objetivo planteado era proponer la familiaridad de la plataforma para los
usuarios. La configuración de la plataforma se desarrollo en archivos de texto con una
construcción semántica que evita la implementación por parte de los que trabajan con la
aplicación. Pero el trabajo de la adaptación de la aplicación y de la persistencia de los
gestos se hace por medio de programación. La integración del lenguaje específico del
dominio como una herramienta que describe la metáfora de interacción dentro de la
plataforma y soluciona parte de las debilidades de la implementación actual.
41
8. BIBLIOGRAFÍA
1. A gestural interaction design model for multi-touch displays. Lao, Songyang, y otros. s.l. : British
Computer Society, 2009. págs. 440-446.
2. Multimodal human-computer interaction: A survey. Jaimes, Alejandro y Sebe, Nicu. s.l. : Elsevier
Science Inc., 2007, Comput. Vis. Image Underst., Vol. 108, págs. 116-134.
3. Research Challenges in Gesture: Open Issues and Unsolved Problems. Wexelblat, Alan. s.l. :
Springer-Verlag, 1998. págs. 1-11.
4. Karam, Maria y schraefel, m. c. A Taxonomy of Gestures in Human Computer Interactions. A
Taxonomy of Gestures in Human Computer Interactions. 2005.
5. g-stalt: a chirocentric, spatiotemporal, and telekinetic gestural interface. Zigelbaum, Jamie, y
otros. s.l. : ACM, 2010. págs. 261-264.
6. Oblong Industries, inc. Oblong Industries, inc.
7. A user interface framework for multimodal VR interactions. Latoschik, Marc Erich. s.l. : ACM,
2005. págs. 76-83.
8. Gesture Recognition: A Survey. Mitra, S. y Acharya, T. 3, 2007, Systems, Man, and Cybernetics,
Part C: Applications and Reviews, IEEE Transactions on, Vol. 37, págs. 311-324.
9. Robust understanding in multimodal interfaces. Bangalore, Srinivas y Johnston, Michael. s.l. :
MIT Press, 2009, Comput. Linguist., Vol. 35, págs. 345-397.
10. ICOs: A model-based user interface description technique dedicated to interactive systems
addressing usability, reliability and scalability. Navarre, David, y otros. s.l. : ACM, 2009, ACM
Trans. Comput.-Hum. Interact., Vol. 16, págs. 18:1--18:56.
11. Intml: A dataflow oriented development system for virtual reality applications. Figueroa, Pablo,
y otros. s.l. : MIT Press, 2008, Presence: Teleoper. Virtual Environ., Vol. 17, págs. 492-511.
12. Feldmann, M, y otros. Overview of an end-user enabled model-driven development approach
for interactive applications based on annotated services. [aut. libro] WEWST '09. Proceedings of
the 4th Workshop on Emerging Web Services Technology. Eindhoven, The Netherlands : ACM,
2009.
13. Web-application development using the Model/View/Controller design pattern. Leff, A. y
Rayfield, J.T. 2001. págs. 118-127.
42
14. Saffer, D. The Role of Metaphor in Interaction Design. Carnegie Mellon University. 2005.
15. Inc., PrimeSense. OpenNI. [En línea] 7 de 12 de 2011. http://www.openni.org.
16. PrimeSense. OpenNI. OpenNI. [En línea] 7 de 12 de 2011. http://www.openni.org.
17. XBOX, Microsoft. Kinect - Xbox.com. [En línea] 2011. [Citado el: 15 de 12 de 2011.]
http://www.xbox.com/en-US/kinect.
18. Ciende, UNC - Department Computer. VRPN. [En línea] [Citado el: 8 de 12 de 2011.]
www.cs.unc.edu/Research/vrpn/.
19. Ruiz, Andres. Arquitectura Distribuida de Aplicaciones 3D integrando Visualización e
Interacción. Arquitectura Distribuida de Aplicaciones 3D integrando Visualización e Interacción.
2010.
20. OptiTrack. Optitrak . [En línea] [Citado el: 8 de 12 de 2011.]
http://www.naturalpoint.com/optitrack/.
21. What are virtual environments? Ellis, Stephen R. s.l. : IEEE Computer Society Press, 1994, IEEE
Comput. Graph. Appl., Vol. 14, págs. 17-22.
22. Toward a vision based hand gesture interface for robotic grasping. Gopalan, R. y Dariush, B.
2009. págs. 1452-1459.
23. Nintento Wii. Nintento Will.
24. Modeling Multimodal Human-Computer Interaction. Obrenovic, Zeljko y Starcevic, Dusan. s.l. :
IEEE Computer Society Press, 2004, Computer, Vol. 37, págs. 65-72.
25. Levels of realism: from virtual reality to real virtuality. Chalmers, Alan y Ferko, Andrej. s.l. :
ACM, 2010. págs. 19-25.
26. Kipp, Michael. From Human Gesture to Synthetic Action. From Human Gesture to Synthetic
Action. 2001.
27. Gil, Santiago. Ambiente visual de desarrollo de aplicaciones de realidad mixta basado en IntML,
Eclipse, GMF y OAW. Universidad de los Andes. 2009.
28. A Survey of Computer Vision-Based Human Motion Capture. Moeslund, Thomas B. y Granum,
Erik. 3, 2001, Computer Vision and Image Understanding, Vol. 81, págs. 231-268.
29. Bowman, Doug A., y otros. {3D} User Interfaces, Theory and Practice. s.l. : Addison-Wesley,
2005.
43
ANEXO A (EJEMPLOS DE METÁFORAS DE INTERACCIÓN)
44
ANEXO B (MODELOS UML DE LOS MÓDULOS Y COMPONENTES
DE LA PLATAFORMA)
MÓDULO DE DISPOSITIVOS VRPN
Módulo Dispositivos VRPN
-channel : int-value : double-time : long
vrpn_analog_data
-deviceName : char-size : int
vrpn_analog_device_event
1
-data*
-deviceName : char-numButton : int-value : int-time : long
vrpn_button_device_event
-x : double-y : double-z : double
vrpn_tracker_position
-x : double-y : double-z : double-angle : double
vrpn_tracker_quat
-deviceName : char-numSensor : int-time : long
vrpn_tracker_device_event
1
-position1
1
-quat1
+VRPNDeviceRemote(entrada deviceModule, entrada deviceName : char)+~VRPNDeviceRemote()+Start()+Stop()
-deviceName : char
VRPNDeviceRemote
+VRPNDeviceModule()+~VRPNDeviceModule()+addDevice(entrada device : char)+Start()+Stop()
VRPNDeviceModule <<OpenNI::ModuleDevice>>
1
-devices
*1
-deviceModule
*
«uses» «uses» «uses»
VRPNDevice <<OpenNI::Device>>
1
-module*
45
MÓDULO DE DETECCIÓN DE GESTOS
Módulo Detección de Gestos
+InputData(entrada type : string)+~InputData()
+inputExpression : string+type : string+value : double+time : long
InputData
+deviceName : string
InputDeviceData
1
-values*
+InputDeviceEvent(entrada device : string, entrada data : InputDeviceData)+~InputDeviceEvent()+getDeviceName() : string+getData() : InputDeviceData
-deviceName : string
InputDeviceEvent
1
-data*
+GestureDetectionManager()+~GestureDetectionManager()+getRegisteredDevices() : string+getDetectedGestures() : Gesture+registerGesture(entrada gesture : Gesture)+registerDeviceRules(entrada device : DeviceOutputRule)+loadFile() : char+getDeviceMapping(entrada sourceDevice : string) : DeviceOutputRule+dispatchEvent(entrada event : InputDeviceEvent)+gestureEventDetected(entrada detectedGesture : Gesture)
-detectedGestures : string
GestureDetectionManager
+Gesture(entrada manager : GestureDetectionManager, entrada name : string, entrada type : string)+~Gesture()+getName() : string+getType() : string+setMinValue(entrada position : int, entrada value : double)+setMaxValue(entrada position : int, entrada value : double)+getFormalizedValue(entrada position : int, entrada value : double) : double+getDetectionState() : string+getResultExpression(entrada deviceName : string, entrada expression : string) : string+onReceiveData(entrada event : InputDeviceEvent)
-name : string-type : string-minValue : double-maxValue : double-inputExpression : string-currentStateId : int-detectionState : string
Gesture
+DeviceOutputRule(entrada sourceDevice : string, entrada deviceName : string)+~DeviceOutputRule()+getDeviceName() : string+getSourceDevice() : string+insertOutputRule(entrada type : string, entrada position : int, entrada rule : OutputRule)+getOutputRule() : OutputRule
-sourceDevice : string-deviceName : string
DeviceOutputRule
1-manager
*
1
-registeredGestures
*
1
-detectedSendedGestures
*
+GestureStateInput(entrada numberDevice : int, entrada nameInput : string)+~GestureStateInput()
+numberDevice : int+nameInput : string+value : double
GestureStateInput
+GestureState(entrada gesture : Gesture)+~GestureState()+resetInputValues()+validateInputs(entrada event : InputDeviceEvent)
GestureState
1
-inputs*
1
-states*1
-gesture *
1
-devices*
+OutputRule(entrada minValue : double, entrada maxValue : double)+~OutputRule()+getNormalizedValue(entrada value : double) : double
-minValue : double-maxValue : double
OutputRule
1
-outputRules*
+GestureDetectionModule()+~GestureDetectionModule()+SetDeviceEvent(entrada event : InputDeviceEvent) : Gesture+GetRegisteredDevices() : string+StartGestureDetection() : string
GestureDetectionModule <<ProductionNode>>
1
-manager*
46
MÓDULO DE COMUNICACIÓN
+GestureCommunicationManager(entrada path : string, entrada ip : string, entrada port : int)+~GestureCommunicationManager()+registerMapping(entrada mapping : GestureTaskMapping)+getMappingRule(entrada gestureName : string, entrada state : string) : GestureTaskMapping+mappingGesture(entrada gesture : GestureStructure)
-configPath : string
GestureCommunicationManager
+GestureTaskMapping(entrada mappingName : string, entrada state : string, entrada gestureName : string, entrada taskName : string)+~GestureTaskMapping()+getState() : string+getMappingName() : string+getGestureName() : string+getTaskName() : string+registerRule(entrada rule : MappingRule)
-state : string-mappingName : string-gestureName : string-taskName : string
GestureTaskMapping
1
-mappingGesturesAndStates*
+MappingRule(entrada taskParameterName : string, entrada expression : string)+~MappingRule()+getTaskParameterName() : string+getExpression() : string
-taskParameterName : string-expression : string
MappingRule
1
-rules*
GestureStructure«uses»
SimpleGestureStructureComplexGestureStructure
UDPConnectionSocket
+AppConnection(entrada server : string, entrada ip : int)+~AppConnection()+requestAllStates() : string+requestCurrentState() : string+requestTasksByCurrentState() : ValuedTask+requestTaskExecution(entrada task : ValuedTask) : <sin especificar>+processMessage() : string
-server : string-port : int-currentState : string-appStates : string
AppConnection
+ValuedTask(entrada name : string)+getName() : string+getParameterNames() : string+addParameter(entrada parameterName : string, entrada type : string)
-name : string
ValuedTask
1
-appConnection1
«uses»
-name : string-type : string-value
ValuedParameter
1 -parameters*
«uses»
47
ANEXO C (PROTOCOLO DE COMUNICACIÓN ENTRE
COMPONENTES)
execTask[state=currentState,task=task1[]]
{task1[], task2[]...taskn[]}
requestTasksByState[state=currentState]
Componente de Aplicación
[currentState]
Componente de Interacción
requestCurrentState[]
[response]
48
Anexo D (Esquema de Evaluación De Usabilidad)
Este es un conjunto de preguntas que permiten evaluar la comprensión del modelo
propuesto por parte de usuarios potenciales de la plataforma.
Para cada una de las etapas se tomara el tiempo que se demore respondiendo. No es una
competencia, por lo tanto responda con calma.
1. Comprensión del modelo de interacción a. Respecto al modelo que se encuentra a continuación, identifique que archivos
representan cada uno de los elementos que componen el modelo. b. ¿Qué elementos cree que faltan para complementar el modelo?
2. Adaptación de una aplicación a. ¿Cuáles son los estados identificados en la aplicación que piensa adaptar? b. En esos estados, ¿Cuáles son las tareas básicas?
3. Modificación de los datos y prueba de la aplicación a. Con la información obtenida, intente configurar las tareas para un estado de la
aplicación.
