ANIMuS

ANIMuS

a Natural-Interactive Multitouch Surface 

Banco de gestos (II)

Gestos propios


Si bien los gestos ya proporcionados por los distintos frameworks son de utilidad, no llegan a completar el espectro necesario, por ejemplo, no engloban gestos del tipo 2D (multi-táctiles) y por ende tampoco la combinación entre estos y gestos 3D (espaciales). Es por ello que, vemos la necesidad de definir un banco de gestos propio que contemple un mayor espectro.


Cuando nos planteamos la definición de un banco de gestos propio lo primero que tratamos de tener en cuenta es cuán “intuitivos” pueden llegar a ser los gestos definidos y qué tanto se asemejan éstos a como interactuamos en la vida cotidiana.


Lograr interfaces los más “sencillas”, “intuitivas” y fluidas posibles es el objetivo, para tratar así de que los usuarios no se vean frustrados por no saber usar alguna aplicación en particular y que por lo tanto, les sea natural interactuar con ella.


Sin embargo, cuando estamos hablando de interacción mediante gestos manipulando cierta tecnología hay un conjunto de restricciones que no permiten que la forma de interactuar sea tan intuitiva y que se asemeje tanto a como se interactúa con el resto del entorno. Es por esta razón que no se debe considerar que cada nueva forma de interactuar debe ser completamente “intuitiva”. Varias de las formas que hoy se consideran intuitivas fueron aprendidas a través de un manual décadas atrás. Por ejemplo, décadas atrás existía tutoriales de como usar un mouse, como se puede ver en el Vídeo 1, cosa sumamente “intuitiva” de usar hoy en día. Con esto, estamos diciendo que cada forma de interacción es de hecho aprendida, porque el ser humano es sujeto que aprende y se adapta al entorno de una. Cuando hablamos de intuitivo, lo que buscamos es que sea “lo más facil” de aprender y adaptarse.


Vídeo 1: Tutorial de cómo utilizar un mouse


Entonces, que una interfaz no requiera una interacción históricamente utilizada no puede ser un impedimento como para que sea aplicable; en sí si la misma puede llegar a ser enseñada, los usuarios luego recordarán y se adaptarán a cómo interactuar con la misma.

Es por esto que, teniendo estos puntos en mente la idea es conformar un banco de gestos lo más intuitivo fluido y ágil posible pero que no por llegar a querer ser “obvio” deje de lado la innovación. Posiblemente varios de los gestos definidos tengan que conllevar una explicación y un entendimiento por parte del usuario, pero como mencionamos antes, mientras sea aprendible es aplicable.


Siguiendo con estos lineamientos, al momento de conformar el banco de gestos nos basamos en las especificaciones ya existentes para gestos del tipo 2D especificados en “Touch Gesture Reference Guide” de  Luke Wroblewski y para los 3D se tuvo en cuenta las especificaciones de los gestos proporcionados por Leap y NITE. Para el caso de los gestos “híbridos” nos basamos en usar de forma combinada las especificaciones anteriores, exceptuando algunos casos en que nos escapamos un poco de lo estandarizado, significando esto que el usuario debería ser capaz de aprender el gesto.


Considerar pautas claras investigadas con anterioridad (marco teórico: interacción natural, guías de diseño de gestos) también fue vital para lograrlo. Buscar que el usuario no tenga que realizar gestos burdos o ridículos; tener presente el espacio donde el usuario se puede manejar de forma sencilla, sin mayores exigencias físicas, teniendo en cuenta su anatomía; definir gestos lo suficientemente sencillos como para que al usuario no le moleste realizarlos, pero lo suficientemente distintos como para que no se confundan con gestos naturales involuntarios; que la semántica de cada gesto esté relacionado con el gesto en sí mismo, es decir, que tenga un buen affordance; que gestos similares denoten acciones similares, y acciones bien distintas sean representadas por gestos bien distintos; son algunos de los muchos puntos que se tuvieron en cuenta para elaborar este banco de gestos.


Especificamos entonces nuestro banco de gestos donde los mismos serán clasificados como del tipo “2D”, “3D” o “híbridos” en las tablas Tabla 3, Tabla 4 y Tabla 5 respectivamente. En dichas tablas se especifica el nombre del gesto, mientras que en el Video 2 se muestran cómo se llevan a cabo dichos gestos conjunto a una selección de gestos a reconocer sólo por diversión :).


Gestos clasificados como del tipo “2D”

Nombre

Tap type

Slide

Spread

Pinch

Long press

Pan

Rotate



Gestos clasificados como del tipo “3D”

Nombre

Circle (Leap & Openni)

Slide (Leap & Openni)

Key Tap

Screen Tap

Push

Pull

Click

Swipe

Psi pose

Hover

Circle

Wave

Raise hand

Squeeze

Spread

Two-hand Rotate

Pan



Gestos clasificados como del tipo “Híbrido”

Nombre

(Hover or Long press) & Point

(Hover or Long press or Point) & Circle

Two-finger Long press & (Push or Pull)

(Hover or Point) & (Spread or Pinch)

Two-finger Long Press & Slide

Fingers Circle

((Long press or Hover) & Swipe up) or ((Point or Hover) & Swipe down)

Fist

(Long Press or Hover) & Focus Hover

(Long Press or Hover or Point) & Finger scissors

(Long Press or Hover or Point) & Finger snapshot

Two-handed five-fingers press & (Pull or Push)

Two-handed & (Push or Pull)

 

 

 

 

 

 

 

Vídeo 2: Galería de banco de gestos



 

¿Has implementado algún reconocedor de gestos? ¿qué gestos has reconocido? ¿qué gestos crees conveniente que deberíamos detectar?

¡Esperamos tus comentarios!



 

Referencias


[1] Sitio fastcodesign http://www.fastcodesign.com/1672172/why-intuitive-interface-is-a-myth

Último acceso: 03 de Abril de 2013

[2] Sitio Leap Motion: https://www.leapmotion.com/

Último acceso: 26 de Abril de 2013

[3] Sitio LukeW: http://www.lukew.com/ff/entry.asp?1071

Último acceso: 26 de Abril de 2013

 

Banco de gestos (I)

Introducción


Es central para nuestro proyecto el desarrollo de un framework que sea capaz de detectar gestos ya sean del tipo 2D (multi-táctiles) como 3D (espaciales) y/o una combinación de los mismos. Para ello, debemos analizar y especificar un banco de gestos útiles que sean de fácil aprendizaje y uso.


Si bien en nuestro proyecto estamos abocados al entorno de una oficina del futuro, en particular en lo referente a la interacción con una superficie que oficie de escritorio o mesa de reuniones y una pared que oficie de pizarrón, este banco de gestos reconocible debe ser posible de usar para cualquier propósito.




 

Gestos


Con las tecnologías que hemos mencionado en post anteriores, existen un conjunto de gestos predefinidos que ya tenemos a disposición para poder utilizar; veremos entonces a continuación cuáles gestos son los que nos proporciona cada una de estas tecnologías.


Gestos proporcionados por NITE

Por un lado, el framework NITE proporciona un conjunto de gestos predefinidos básicamente de tipo 3D (espaciales), los cuales se detallan en la Tabla 1.




Nombre

Figura representativa

Push

Pull

Click

Swipe

Psi pose

Steady

Circle

Wave

Raise hand


Tabla 1: Gestos proporcionados por NITE


 

 

Gestos proporcionados por Leap Motion

Por otro lado, Leap Motion también trae un conjunto de gestos reconocibles, los cuales se detallan en la Tabla 2.



Nombre

Figura representativa

Circle

Swipe

Key Tap

Screen Tap


Tabla 2: Gestos proporcionados por Leap

 

 

(continua en Banco de gestos (II) )

Integración de dispositivos Leap y Kinect

Introducción


Como mencionábamos en post anteriores ANIMuS pretende sacar provecho de las mejores cualidades de los dispositivos Leap y Kinect.

Para ello, resulta vital que podamos llevar a un mismo sistema de referencia lo que cada uno de estos dispositivos capta de forma de enriquecer lo que uno de estos dispositivos “ve” mediante lo que el otro también “ve”. A modo de ejemplo, podríamos detectar la presencia de un usuario en la oficina del futuro mediante el dispositivo Kinect, identificar también con éste sus distintas articulaciones (“joints”) y por el otro lado, mediante Leap detectar los dedos de un usuario. Llevando esta información a un único sistema de referencia podemos entonces asociar los dedos detectados por Leap a un usuario determinado detectado con Kinect logrando de esta forma obtener más información que la proporcionada de forma aislada por cada uno de los dispositivos.




Sistemas de referencia


Recordaremos a continuación cada uno de los sistemas de referencia propios de los dispositivos Leap y Kinect.


Leap


 

Figura 1: Sistema de referencia de Leap




Leap utiliza un sistema de referencia cartesiano diestro. Los valores reportados por el dispositivo son medidos en milímetros. El origen del centro de referencia es el centro del dispositivo como se muestra en la Figura 1. El eje X y el eje Z conforma un plano horizontal donde el eje X se encuentra paralelo al lado más largo del dispositivo. Por otro lado el eje Y es vertical, considerando los valores positivos a aquellos que se encuentren por encima del dispositivo mientras que el eje Z toma valores positivos a aquellos por delante del dispositivo.

 

 

Kinect


Figura 2: Sistema de referencia de Kinect



Kinect al utilizar OpenNI utiliza un sistema de referencia cartesiano zurdo. Los valores reportados por el dispositivo son medidos en milímetros igual que Leap. El origen del centro de referencia es el centro de la cámara del dispositivo como se muestra en la Figura 2. El eje X y el eje Z conforma un plano horizontal donde el eje X se encuentra paralelo al lado más largo del dispositivo. Por otro lado el eje Y es vertical, considerando los valores positivos a aquellos que se encuentren por debajo del dispositivo mientras que el eje Z toma valores positivos a aquellos por delante del dispositivo exactamente como el Leap.



Prueba de concepto


 

La prueba de concepto para llevar a cabo lo explicitado anteriormente consistió en tomar como sistema de referencia único al sistema de referencia propio del Kinect, esto es, que lo captado por Kinect ya va a estar con coordenadas correctas pero lo captado por Leap no. Para que lo captado por Leap sea llevado al sistema de referencia de Kinect debe ocurrir una transformación. Para aplicar esta transformación se debe hacer uso de operaciones matemáticas en el espacio, en concreto, aplicar matrices de transformación.


 

Planteamos un caso sencillo en el cual enfrentamos ambos dispositivos como se muestra en la Figura 3 y Figura 4, por otro lado a OpenNI se le indica que espeje lo captado seteando la propiedad “mirror” en true, de esta forma se dan vuelta los ejes X e Y. En este caso, es fácil observar que para llevar lo captado por Leap al sistema de referencia de Kinect se debe aplicar una transformación en el eje Z y en el eje Y, ya que hay una diferencia de altura en Y y una separación en Z; específicamente es necesario hacer una traslación en dichos ejes.

 

Para trabajar con matrices de transformación usaremos una librería llamada Eigen, la cual permite un conjunto de facilidades de operación matemática.



Figura 3: Ubicación Leap y Kinect

Figura 4: Ubicación Leap y Kinect



Específicamente los dispositivos se encuentran separados una distancia de 60 cm en el eje Z y una distancia de 8 cm en el eje Y. Al momento de establecer las distancias se debe tener en cuenta que para que Kinect detecte movimiento se debe de tener con respecto al usuario una distancia mínima de 40 cm, un ejemplo de posición entonces es el presentado anteriormente. De esta forma construimos un vector de traslación (0,8,60) y construiremos mediante Eigen una matriz de transformación. Como vimos en post anteriores, específicamente el de diseño conceptual, estas relaciones de distancia ya las hemos contemplado.


Para llevar a cabo la comparación tomamos como punto referente el centro de la mano, de esta forma, podemos obtener dicho centro con Leap, aplicarle la matriz de transformación y luego comprar el valor obtenido con el centro de la mano detectado por Kinect.


Los resultados obtenidos fueron buenos, como se puede ver en la Figura 5, exceptuando por pequeños márgenes de error predecibles, está dentro de lo esperado.



Figura 5: Resultado obtenidos


 

Conclusiones


Mediante una prueba de concepto sencilla, logramos demostrar que es relativamente fácil lograr llevar lo captado por distintos dispositivos a un único sistema de referencia para poder operar en conjunto los datos obtenidos. Observamos que creando de forma correcta una matriz de transformación cualquier posición, salvando las distancias mencionadas más arriba, es “mapeable” a un único sistema de referencia. A su vez este sistema de referencia no tiene porque ser el de un dispositivo en concreto, puede estar por ejemplo en el medio de la distancia entre los dos o en cualquier lugar de interés sólo basta definir una matriz correcta de transformación.



¿Has utilizado en conjunto estos dispositivos? ¿qué sistema de referencia has utilizado?

¡Esperamos tus comentarios!

 

Referencias


[1] Sitio Leap Motion: https://www.leapmotion.com/

Último acceso: 21 de Abril de 2013

 

 

Leap Motion Controller

 

 

Como mencionamos en post anteriores además de usar el dispositivo Kinect de Microsoft como parte de la solución a desarrollar estaremos incluyendo también otro dispositivo que ha surgido hace corto tiempo; este es el Leap Motion Controller. En este post detallaremos cuales son las propiedades de este dispositivo y por qué consideramos ventajosa su utilización en el contexto de ANIMuS.

Figura 1: Leap Motion Controller

 

 

Introducción


Leap Motion controller es un pequeño dispositivo periférico que está diseñado para ser colocado sobre un escritorio físico, idealmente mirando hacia arriba. Posee dos cámaras y tres LEDs infrarrojos y está básicamente orientado a permitir la detección de manos, dedos, herramientas de ciertas características y gestos realizados con estas de forma muy precisa. El alcance espacial es de aproximadamente 0,01 mm, con un FOV (field of view) de 115° centrado en el dispositivo, el cual forma una pirámide invertida.


"We want there to be world-changing applications that fundamentally transform how people interact with their operating system or browse the Web. The goal is to fundamentally transform how people interact with computers and to do so in the same way that the mouse did, which means that the transformation affects everyone, both from the most basic use case all the way up to the most advanced use cases you can imagine for computing technology."

-- Leap Motion CEO, Michael Buckwald



El el Vídeo 1 se puede observar a este dispositivo en funcionamiento.


 

Vídeo 1: Funcionamiento de Leap Motion Controller

 



Leap ha distribuido de forma gratuita múltiples unidades alrededor del mundo para los desarrolladores interesados en hacer uso del mismo. Las mismas son denominadas developer units y poseen algunas restricciones con respecto a las versiones comerciales del mismo. Las unidades comercializadas actualmente tienen un precio de US$ 79.99.


El equipo de ANIMuS cuenta con dos unidades de tipo developer, por lo que se analizó qué provecho se le puede sacar a este dispositivo que ha adquirido gran renombre en estos meses en el contexto de este proyecto.

En primer lugar, destacamos que el espacio de observación que abarca Leap es más pequeño pero a la vez de mucho mayor resolución que el propiciado por Kinect, el cual es adecuado para el seguimiento de todo el cuerpo en un espacio del tamaño de, por ejemplo, una sala estándar. Teniendo en cuenta estas diferencias es que se entiende oportuno considerar la idea de poder tener una solución que tome las ventajas de cada uno de estos dispositivos de forma inteligente para ANIMuS. Kinect que nos proporciona un espectro amplio de reconocimiento, un trackeo de usuarios con un conjunto de joints pero sin incluir reconocimiento a nivel de dedos de las manos de los usuarios; es aquí entonces donde entra en juego Leap, proporcionando lo que Kinect no nos brinda, es decir, el reconocimiento de los dedos de las manos y con ello mayor precisión para los gestos efectuados con ellas.


Así, básicamente lo que se propone para ANIMuS es contar con dispositivos Leap para poder lograr precisión con los gestos de los usuarios realizados con las manos y el dispositivo Kinect para los demás componentes de interacción (interacción multitáctil, reconocimiento y tracking de usuarios, gestos que no requieran demasiada precisión, etc). Es por ello que una buena ubicación dentro de una oficina del futuro sería empotrar el dispositivo Leap Motion Controller en la mesa, frente a donde cada participante estaría ubicado.


Por otro lado, Leap cuenta actualmente con una comunidad muy activa, donde varios desarrolladores se han mostrado muy interesados en desarrollar aplicaciones que saquen jugo de este dispositivo. El equipo de Leap Motion ha proporcionado SDKs para una gran variedad de plataformas y lenguajes de programación, entre ellos para C/C++, el cual cuenta con portabilidad para Mac así como también para Windows; aún resta portabilidad para Linux pero es un punto en el cual se encuentran trabajando. El desarrollo del SDK de Leap se viene expandiendo mediante la liberación de nuevas versiones de forma ágil. Por ejemplo, recientemente se liberó una nueva versión que incluye reconocimiento de gestos básicos, lo cual indica que el SDK va en crecimiento en cuanto a la funcionalidad brindada.


El siguiente vídeo muestra uno de los muchos usos interesantes del dispositivo Leap.


 

Vídeo 2: Aplicación con Leap Motion Controller

 

 

En lo que resta del post detallaremos las características de Leap Motion Controller a un nivel más técnico.


 

Sistema de Coordenadas


Leap Motion Controller maneja un sistema de coordenadas cartesiano centrado en el dispositivo y los valores reportados por el mismo son en milímetros. Los ejes se pueden ver en la Figura 2, donde el eje X y Z conforman un plano horizontal siendo el eje X paralelo al lado más largo del dispositivo. Por otro lado, el eje Y es perpendicular al dispositivo considerando los valores positivos como aquellos por encima del mismo, mientras que los valores en Z positivos son aquellos por delante del dispositivo.



Figura 2: Sistema de coordenadas de Leap Motion Controller


 

Tracking Data


Leap sensa la  información capturada detectando dedos, manos, herramientas con ciertas características y gestos a los cuales les asocia un identificador único mientras sigan siendo visibles en el FOV del dispositivo.  Si alguno de estos objetos detectados deja de ser visible y luego vuelve a ser detectado, se le asignará un nuevo identificador, no permitiendo así asociar el mismo identificador que tenía antes. Si bien tener un reconocimiento único a lo largo del tiempo no es posible con la versión actual del SDK de Leap Motion Controller, es algo que los desarrolladores tienen pensando permitir.



Hand Model


Leap proporciona información de posición, características, movimiento y una lista de dedos y herramientas asociadas a las manos. Leap Motion Controller permite la detección de varias manos siempre y cuando las mismas estén en el FOV del dispositivo. Igualmente se sugiere que no se supere un máximo de dos manos para maximizar la calidad de la detección.


Leap proporciona un conjunto de atributos que contiene información relevante sobre las manos detectadas. Los mismo son los siguientes:

Hand attributes

 

  • Palm Position: proporciona la posición del centro de la mano en milímetros.

  • PalmVelocity: proporciona la velocidad de la mano medida en milímetros por segundos.

  • PalmNormal: proporciona el vector perpendicular a la palma de la mano, el cual apunta hacia abajo en dirección hacia afuera de la misma.

  • Direction: proporciona un vector desde el centro de la mano en dirección hacia los dedos.

  • SphereCenter: proporciona el centro de una esfera que representa la curvatura de la mano.

  • SphereRadius: proporciona el radio de una esfera que representa la curvatura de la mano. Este valor se actualiza cuando la curvatura de la mano cambia, incrementando o decrementando así el tamaño de la esfera.



En la Figura 3 se pueden observar los vectores que representan a PalNomal (perpendicular hacia abajo) y Direction (horizontal). Por otro lado, en la Figura 4 se puede observar la esfera que representa la curvatura de la mano.

 



Figura 3: Palm Normal y Direction Figura 4: Palm Normal y Direction


 

Hand motion

Leap proporciona también información referente al movimiento de las manos que puede detectar en su FOV, analizando el movimiento de las manos así como también de los dedos y/o herramientas, proporcionado información de traslación, rotación o escalado. Leap logra brindar esta información comparando el estado actual de las manos con el estado de las mismas en frames anteriores. La información proporcionada con respecto al movimiento es representada mediante los siguientes atributos:



  • rotationAxis: vector que representa el eje de rotación.

  • rotationAngle: ángulo de rotación en sentido horario con respecto al eje de rotación.

  • rotationMatrix: matriz de transformación representando la rotación.

  • scaleFactor: factor que representa la expansión o la contracción.

  • translation: vector que representa el movimiento linear.


 

Finger and Tools models


Leap distingue las herramientas de los dedos por su forma, considerando que las herramientas son aquellas cuya forma es más larga, recta y fina que la forma de los dedos. Igualmente tanto herramientas como dedos son abstraídos por Leap ambos como objetos apuntadores, los cuales poseen los siguientes atributos:



  • length: el largo del apuntador.

  • width: el ancho del apuntador.

  • direction: vector que representa la dirección del apuntador.

  • tipPosition: la posición de la punta del apuntador medida en milímetros.

  • tipVelocity: la velocidad de la punta del apuntador medida en milímetros por segundo.


Figura 5: Direction y TipPosition



 

Gestos


El dispositivo Leap reconoce un conjunto predefinido de gestos que pueden haberse llevado a cabo por parte del usuarios. Los gestos reconocibles son los siguientes:



  • Circle: círculo realizado con un dedo.

  • Swipe: movimiento linear realizado con una mano.

  • Key Tap: movimiento correspondiente a presionar una tecla realizado por un dedo.

  • Screen Tap: movimiento correspondiente a tocar una pantalla con un dedo.


Circulo

Es un movimiento continuo que puede ser llevado a cabo por cualquier dedo o herramienta.


Figura 6: Gesto Circle


Swipe

Es reconocido por Leap como un movimiento lineal. Es también un movimiento continuo que puede ser llevado a cabo por cualquier dedo o herramienta en cualquier dirección.


Figura 7: Gesto Swipe


 

Taps

Leap reconoce dos tipos de taps, uno vertical y otro horizontal, también denominados key tap y screen tap respectivamente. Los mismos se pueden apreciar en las siguientes figuras.

 Figura 8: Key tap gesture Figura9: Screen tap gesture







¿Conocías este dispositivo? ¿Has desarrollado aplicaciones con Leap? ¿Qué experiencia has tenido? ¡Esperamos tus comentarios!



Referencias


[1] Sitio Leap Motion: https://www.leapmotion.com/

Último acceso: 19 de Marzo de 2013

 

 

Diagrama conceptual y alcance

 

En este post presentaremos un primer diagrama conceptual para el contexto en el cual se utilizará el framework ANIMuS, presentando los diferentes elementos que conformarán la solución y cómo estos interactuarán entre si. El diagrama se puede ver en la Figura 1.

 

 

Figura 1: Diagrama conceptual de la solución propuesta


Cabe comentar que el diagrama anterior presenta únicamente una primera definición de la organización y el alcance de la solución propuesta, ya que puede sufrir algunas modificaciones con el avance del proyecto.


La solución planteada se compone por los siguientes elementos:


- Servidor

- Leap Motion Controller

- Kinect

- Proyector

- Mesa

- Pared


Superficies de interacción: mesa y pared


La mesa y la pared son las superficies con las cuales se podrá interactuar mediante gestos 2D y/o 3D. En próximos posts presentaremos los diferentes gestos que se podrán realizar para interactuar con estas superficies. Sobre las mismas se expondrá una interfaz visual apropiada para cada aplicativo que haga uso del framework.


Interfaz gráfica e información visual: proyector


Debido a que tanto pared como la mesa no son dispositivos capacitados para la exposición de datos visuales se utilizan los proyectores para proyectar la información visual al usuario en base a la información procesada. La cantidad de proyectores requeridos será igual a la cantidad de superficies de interacción diferentes, por lo que para este primer acercamiento se necesitarán dos proyectores, uno para la pared y otro para la mesa, suponiendo que el área de proyección está limitada al área máxima que abarca cada proyector.


Dispositivos de interacción: Kinect y Leap


En cuanto a la interacción con los usuarios, la forma que se utilizará en el contexto de un aplicativo que utilice ANIMuS es mediante gestos 2D y 3D sobre las superficies antes mencionadas. Para ello son requeridos los dispositivos Kinect y Leap.


El sensor Kinect ofrecerá una visión amplia de toda la zona de interacción, ubicándose de forma de abarcar toda la escena, o al menos lo máximo posible. Con estos dispositivos se podrán identificar tanto las zonas de interacción (mesa y pared) como los usuarios presentes en la escena, llevando un histórico de su actividad a lo largo del tiempo.


Además, mediante el procesamiento de las nubes de puntos obtenidas por los dispositivos Kinect se resolverá la detección de aquellos gestos de usuario a nivel de brazo/mano, es decir, aquellos que puedan ser reconocidos únicamente con información de las posiciones de el(los) brazo(s) y mano(s) de los usuarios, no utilizándose para detectar gestos más precisos como son los gestos a nivel de dedos. Con la nube de puntos obtenida por los dispositivos Kinect se resolverá también la interacción 2D con las superficies, esto es, la característica multitáctil y los gestos multitouch realizados sobre la superficie.


Se cuenta con tres de estos dispositivos, por lo cual una posible configuración será colocar uno de ellos mirando hacia la mesa para poder abarcarla en su totalidad (identificando así gestos 2D sobre la misma) y los restantes mirando hacia donde se ubicarán los usuarios para obtener información de la escena e identificar a los usuarios presentes.


Resolver el trackeo esqueletal de la mano de forma sencilla y performante es un debe de Kinect para la versión que estamos utilizando. En este punto entra en juego el controlador Leap Motion, el cual resuelve esta problemática de forma nativa. Se abordará más sobre este tema en próximos posts, en los cuales presentaremos el dispositivo Leap y las características que brinda.


Así, cada dispositivo Leap posibilitará la detección de gestos 3D (a nivel de dedos) en la zona por delante donde se encuentra sentado el usuario (como se muestra la figura) y con un alcance determinado por una pirámide invertida con centro en el dispositivo y una altura de aproximadamente 40cm. Si bien esta es una restricción técnica del dispositivo Leap, creemos que en nuestro caso no afecta en mayor medida ya es natural que los gestos muy minuciosos se realicen en este espacio, dado que sería incómodo realizarlos a una distancia mayor.


Otra restricción que agrega la utilización de Leap para este fin es que cada usuario deberá contar con uno de estos dispositivos para que pueda realizar cierto tipo de gestos. De cualquier forma, pretendemos que esta sea una restricción opcional, es decir, que si no se cuenta con la cantidad suficiente de dispositivos Leap, se podrán utilizar tantos como se tengan, pero como consecuencia la cantidad de usuarios con capacidad de realizar ciertos gestos se verá disminuida, siendo igual a la cantidad de dispositivos Leap que hayan en el contexto (ya sea uno por usuario o bien ninguno).


En cuanto a la ubicación y cantidad de dispositivos, en principio disponemos de únicamente dos Leaps y los mismos serán colocados al nivel de la mesa, sensando sobre ella como muestra la figura, de modo de no molestar al usuario en su interacción con la habitación. Para que la solución sea aún más cómoda para el usuario se puede incluso colocar los dispositivos Leap “embebidos” directamente dentro de la mesa, en pequeños huecos cubiertos por vidrio u otro material que permita el pasaje de los rayos IR sin interferencias, evitando así que se deban evadir los dispositivos sobre la superficie y mejorando la experiencia de usuario.


Procesamiento de información: servidor


Finalmente, el servidor es un computador encargado del procesamiento de la información recolectada por los diferentes dispositivos que conforman la solución. A este computador, en una primera instancia, estarán conectados los controladores Leap Motion, los Kinects y los proyectores.




 

En resumen, creemos que este primer diagrama conceptual, ampara apropiadamente los objetivos establecidos. Es un esquema fácilmente extensible en cuanto a cantidad de usuarios y superficies de interacción así como en tamaño de la sala. Además, supone la utilización de las mejores capacidades de cada uno de los dispositivos, utilizando e interrelacionando los datos para obtener un mejor producto y paliar las carencias de unos con los otros. Por otra parte, en cuanto a las restricciones impuestas, con este esquema simplemente obteniendo más hardware sería sencillo eliminar la mayoría de ellas.

 

ANIMuS y procesos cognitivos (IV)

 

Principios  para el diseño de buenas interfaces (cont.)

 

Principios psicológicos generales en el diseño

 

Principios de Norman (1988)


  • Visibilidad: "Con solo mirar, el usuario puede decir cuál es el estado del dispositivo y las opciones de la acción".  
  • Un buen modelo conceptual: El diseñador proporciona al usuario un buen modelo conceptual, coherente en la exposición de las operaciones y los resultados y con una imagen del sistema coherente y pertinente.
  • Buena topografía: Que sea "posible determinar las relaciones entre los actos y los resultados, entre los mandos y sus efectos, y entre el estado del sistema y lo que es visible".
  • Retroalimentación: El usuario recibe una retroalimentación completa y constante acerca de los resultados de sus actos.

Una guía ofrecida por Norman (1992) es la siguiente:



  • Simplificar la estructura de las tareas.
  • Hacer que las cosas estén visibles, incluyendo el modelo conceptual del sistema, las acciones alternativas y los resultados de las acciones.
  • Hacer que sea fácil determinar qué acciones son posibles en cada momento.
  • Hacer que sea fácil evaluar el estado actual del sistema.
  • Explotar el poder de los límites (por ejemplo, Ud. sólo puede hacerlo en una forma -la forma correcta-).
  • Diseñar para permitir que sea fácil recuperar el error.
  • Cuando todo falle, estandarizar.  

Según Norman (1992), para conseguir que un sistema sea fácil de usar, en general:



  • El diseñador debe emparejar el número de controles con el número de funciones.
  • Organizar los paneles de control/displays de acuerdo con la función.
  • Los controles o displays que no se necesiten para la tarea deben ocultarse para reducir la apariencia de complejidad del sistema.

 

En el diseño de controles

Los controles hacen énfasis en los sistemas de respuesta. Se ha estudiado ampliamente la ergonomía cognitiva de los controles.  Wickens, Gordon y Liu (1998) destacan cinco variables en torno a ello:


  • Complejidad de la decisión de respuesta: posibles acciones alternativas.
  • Expectativa de respuesta.
  • Compatibilidad entre estímulo y respuesta, o entre la localización del control o el movimiento de la respuesta de un  control y la localización o movimiento del indicador con el que se relaciona.
  • Balance velocidad- precisión: correlación positiva entre tiempo o velocidad de respuesta y tasa de error.
  • Retroalimentación o feedback que indica la respuesta del sistema al input del control (por ejemplo, en un coche el velocímetro ofrece feedback visual para el control del acelerador.




¿Has analizado los procesos cognitivos para tu aplicación? ¿qué has tenido en cuenta? ¡Esperamos tus comentarios!


 

 

 

Referencias


  • Hacia la Realización de una Interacción Natural. Javier Calle, Paloma Martínez, David del Valle
  • Notes on Natural Interaction. Alessandro Valli, PhD
  • The Design of Natural Interaction. Alessandro Valli, PhD
  • From Multimodal to Natural Interactions. Kuansan Wang, Natural Interaction Service Division, Microsoft Corporation

http://www.w3.org/2004/02/mmi-workshop/wang-microsoft

Último acceso: 24 de noviembre de 2012


  • En busca del Diseño Centrado en el Usuario (DCU): definiciones, técnicas y una propuesta.

http://www.nosolousabilidad.com/articulos/dcu.htm

Último acceso: 24 de noviembre de 2012


  • Código ético de la investigación en usabilidad e Interacción Persona-Ordenador Pruebas con usuarios

http://usuarios.multimania.es/savonasacj/codigo_etico_AIPO.pdf

Último acceso: 24 de noviembre de 2012


  • Seguimiento y reconocimiento de los gestos de una mano mediante visión por computador. Álvaro Melero Gil, Isaac García Incertis.

http://www.ceautomatica.es/old/actividades/jornadas/XXVIII/documentos/1341-Ratoncam.pdf

Último acceso: 24 de noviembre de 2012


  • Notas sobre interacción natural.

http://andreacastanomoreno.blogspot.com/2008/06/notas-sobre-la-interaccin-natural.html

Último acceso: 24 de noviembre de 2012


  • Interfaz de lenguaje natural usando Kinect. Sergio Herman Peralta Benhumea.

http://www.cs.cinvestav.mx/TesisGraduados/2012/tesisSergioPeralta.pdf

Último acceso: 24 de noviembre de 2012


  • HCI (human computer interaction): concepto y desarrollo. Mari-Carmen Marcos

http://www.elprofesionaldelainformacion.com/contenidos/2001/junio/1.pdf

Último acceso: 24 de noviembre de 2012


  • Evolución y tendencias en la interacción persona–ordenador. Mireia Ribera Turró

http://www.elprofesionaldelainformacion.com/contenidos/2005/noviembre/3.pdf

Último acceso: 24 de noviembre de 2012


  • El gesto como mecanismo de interacción corporizada con computadoras: posibilidades y desafíos. Andrés Rodríguez. Lifia, Facultad de Informática, Universidad Nacional de la Plata.

http://www.saccom.org.ar/2010_reunion9/actas/19.Rodriuez.pdf

Último acceso: 24 de noviembre de 2012


  • Justificación desde la teoría: Interacción en el Proyecto TILiiN.

http://andresoadigital.blogspot.com/2010/11/justificacion-desde-la-teoria.html

Último acceso: 24 de noviembre de 2012


  • Interacción persona ordenador.

http://webdiis.unizar.es/asignaturas/IPO/wp-content/uploads/2011/12/1.-IPO_Intro.pdf

Último acceso: 24 de noviembre de 2012


  • Ergonomía cognitiva y usabilidad.

http://www.um.es/docencia/agustinr/Tema6-0607a.pdf

Último acceso: 24 de noviembre de 2012


  • Interacción Persona computadora.

http://edu.enredo.org/IMG/pdf/Interaccion_persona-computadora.pdf

Último acceso: 24 de noviembre de 2012


  • Introducción a la interacción persona-ordenador. Jesús Lorés.
  • Ergonomía Cognitiva, Aspectos Psicológicos de la interacción de las personas con la tecnología de la información. Cañás, Waerns.
  • Interacción hombre ordenador. Miriam Tarrazó Cases, Merche Esteban Martín.

http://web.ua.es/es/gvc/documentos/trabajos-ergonomia-visual/interaccion-hombre-ordenador.pdf

Último acceso: 24 de noviembre de 2012


  • MPIu+a. Una metodología que integra la ingeniería del software, la interacción persona ordenador y la accesibilidad en el contexto de equipos de desarrollo multidisciplinares. Departament de Llenguatges i Sistemes Informàtics, Universitat de Lleida

http://www.tdx.cat/bitstream/handle/10803/8120/Tgsa2de5.pdf;jsessionid=7BE96A072864D2DEE483C21ED1CF4334.tdx2?sequence=2

Último acceso: 24 de noviembre de 2012

 

 

ANIMuS y procesos cognitivos (III)

 

Principios  para el diseño de buenas interfaces


 

Principios generales

Las principales especificaciones o recomendaciones de diseño de la interfaz de productos y entornos provienen del estudio de las capacidades y limitaciones cognitivas de las personas.


Se pueden mencionar tres principios o dimensiones principales del sistema:


  1. Principios de procesamiento: Percibir, retener y recuperar la información gracias a un conjunto de estructuras (perceptivas, de memoria, etc.) y procesos que reelaboran la información.

  2. Principios de representación: Lo percibido se representa (se almacena organizadamente) en la memoria a largo plazo que sirve como experiencia y recuerdos para actividad cognitiva futura.

  3. Principios de limitación de capacidad de procesamiento: El sistema cognitivo tiene capacidad limitada para procesar información y necesita distribuir los recursos simultáneamente. Habrá eficacia o sobre carga mental (mental workload) según sea la dificultad de la tarea y el nivel de conocimientos, experiencia y/o práctica.


1- Principios de procesamiento

Percibir, retener y recuperar la información gracias a un conjunto de estructuras (perceptivas, de memoria, etc.) y procesos que reelaboran la información.

 

Principales modelos de procesamiento de la información en su aplicación a la interacción con las interfaces

 

Los procesos mentales intervienen a mayor o menor nivel en toda la conducta y son los producidos por el sistema cognitivo del organismo, de modo que si éste es capaz de adquirir, retener y recuperar la información es gracias a que posee una serie de estructuras (por ejemplo, perceptivas -que intervienen sobre todo en la adquisición de información-, de memoria -sensorial, a corto plazo, a largo plazo- etc.) a través de las cuales operan una serie de procesos o elementos activos encargados de lo que se detalla a continuación:


  • Adquirir o percibir información (que entra por los sentidos o que es activada a partir de la memoria permanente o a largo plazo) mediante su reelaboración a través de una serie de transformaciones y estrategias tales como los procesos de codificación.

  • Retener la información mediante estrategias de retención, tales como la repetición o repaso en la memoria a corto plazo, selección de información mediante procesos atencionales que también "administran" la capacidad limitada de procesamiento del sistema, etc.

  • Por último, la información será recuperada para su uso mediante otros procesos.


El siguiente modelo mostrando en la Figura 5, adaptado de Wickens y Hollands ilustra el procesamiento de información que, por ejemplo realiza el sistema cognitivo ante un indicador visual.



Figura 5: Diagrama de procesamiento de información de la interfaz en el sistema cognitivo


En este proceso, según Cañas, Salmerón y Gómez (2001), hacen falta recursos mentales que son controlados y distribuidos entre los demás procesos por los procesos atencionales.


Finalmente, existen unos procesos de decisión que seleccionan la respuesta apropiada y que dan órdenes a los procesos motores.  La interacción con una interfaz es física y también mental. La interacción mental, con los procesos cognitivos antes mencionados, pone en juego las siguientes siete variables propuestas por Norman (1983) y representadas gráficamente en interacción con una interfaz de ordenador, mostrada en la Figura 6, las cuales son las siguientes:


1) Establecer un objetivo.

2) Formar una intención.

3) Especificar las secuencias de acciones.

4) Ejecutar la acción.

5) Percibir el estado del sistema.

6) Interpretar el estado.

7) Evaluar el estado del sistema con respecto a los objetivos y a las intenciones.




Figura 6: Interacción actividad mental – actividad física con una interfaz de usuario según Norman (1983; adapt. por Cañas et al., 2001)



Las primeras etapas de procesamiento: procesos y principios perceptivos

Las primeras etapas en el procesamiento son las que marcan los sistemas sensoriales y perceptivos. La organización perceptual consiste en una representación interna a partir de la información proporcionada por los sentidos y sigue una serie de principios sólidamente determinados por los psicólogos de la percepción. Es muy importante para la usabilidad de la interfaz que la distribución de objetos y estímulos por ella sigan los siguientes principios:



  • Detección de bordes: se perciben como regiones conectadas aquellas áreas uniformes con respecto a una propiedad de la imagen (luminancia, color, textura, movimiento y disparidad).
  • Diferenciación figura-fondo: las personas tienden a percibir tan sólo uno de los lados como un objeto con significado. El otro (fondo) ni tan siquiera es recordado. La figura se distingue del fondo porque: (1) tiene significado, (2) está más próxima al observador, (3) está limitada por un contorno y (4) posee una forma definida por el contorno.

Por su parte, los principios de agrupación, en la Figura 5, dan como resultado que varios elementos de la escena se perciban conjuntamente como se detalla a continuación:


1) Proximidad: si dos objetos están cerca el uno del otro y alejados de los otros, tienden a ser percibidos conjuntamente.

2) Similitud: los objetos que comparten alguna característica perceptual (color, tamaño, orientación, textura, etc.) tienden a ser percibidos conjuntamente.

3) Destino común: los elementos que se mueven en la misma dirección se percibirán agrupados.

4) Buena continuación: los elementos que pueden ser vistos como buenas continuaciones del otro tienden a ser percibidos conjuntamente.

5) Cierre: los elementos formando una figura cerrada tienden a ser percibidos como agrupados.

6) Sincronía: los elementos visuales que ocurren al mismo tiempo tienden a ser vistos como un conjunto.

7) Región común: los objetos colocados dentro de una misma región cerrada se percibirán agrupados.

8) Conexión entre elementos: objetos que están conectados por otros elementos tienden a ser agrupados conjuntamente.



Figura 7: Izq: Ejemplo de compatibilidad e incompatibilidad de la organización perceptual y la tarea del usuario. Der: Principios de agrupación perceptual

 


2- Principios de representación. Los modelos mentales

Lo percibido y/o aprendido se representa (se almacena organizadamente) en la memoria a largo plazo y  sirve como experiencia y recuerdos para la actividad cognitiva futura.


La cuestión de la representación se refiere a la organización de la información en la memoria. Es una propiedad esencial del sistema cognitivo, por la cual se puede recuperar la información e incluso construir o crear conocimiento.


Los modelos y teorías sobre la representación del conocimiento nos ilustran acerca del modo en que la información es almacenada de forma estable en la memoria a largo plazo y sobre los mecanismos de recuperación de la misma. La información se almacena en la memoria mediante procesos de codificación y así se convierte en conocimiento o contenido de la memoria a largo plazo.


Uno de los sistemas de representación más eficaces para el procesamiento cognitivo de las interfaces y soportes de información es el modelo mental.


Los usuarios desarrollan conocimiento y comprensión de un sistema aprendiendo, experimentando y usándolo, este conocimiento se refiere a:

 

1) cómo usar el sistema en cada momento.

2) qué hacer con sistemas no familiares o situaciones inesperadas.


Las personas usan estas construcciones internas o “teorías” implícitas de algún aspecto del mundo exterior que les permite hacer inferencias o predicciones para cada tarea o interacción con cada interfaz o producto.


Muchas personas tienen modelos mentales erróneos o parciales o inexactos del funcionamiento de un sistema. Los modelos mentales son pues una representación (del sistema o tarea) que:


  • Es incompleta.

  • Es ejecutable mentalmente, el usuario puede mentalmente simular su funcionamiento.

  • Es inestable, el usuario olvida los detalles.

  • No tiene unos límites claros, se confunde con los modelos mentales de sistemas físicos similares.

  • Es acientífica e incluye supersticiones y creencias erróneas sobre la conducta del sistema.

  • Es parsimoniosa porque los usuarios prefieren reducir su complejidad.


Un ejemplo de desajustes entre modelos mentales lo tenemos en el diseño de productos. Se produce habitualmente un desajuste entre dos modelos mentales, el del diseñador del producto y el que tiene el usuario como se ejemplifica en la Figura 8.



Figura 8: Modelo de desajuste entre los modelos mentales del sistema que tienen el diseñador y el usuario

 

3- Principios de limitación de capacidad de procesamiento

El sistema cognitivo tiene capacidad limitada para procesar información y necesita distribuir los recursos simultáneamente. Habrá eficacia o sobre carga mental, “mental workload”, según sean alguno de estos casos:


  • La dificultad de la tarea.

  • El nivel de conocimientos, experiencia y/o práctica.


El sistema cognitivo tiene una capacidad limitada para procesar información debido a limitaciones estructurales (por ejemplo, de los almacenes de memoria o de los sistemas sensoriales, etc.) que impiden o dificultan el procesamiento de estimulación excesiva.


La percepción, como decíamos antes, es un proceso cognitivo de interpretación o análisis mental de la información (Cañas y Waerns, 2001). Para procesar la información el sistema cognitivo utiliza una serie de recursos simultáneamente y dependiendo de la complejidad de la tarea y/o del nivel de aprendizaje o experiencia previa, el sujeto los podrá utilizar con eficacia o se producirá un exceso de carga mental que producirá deficiencias en la ejecución.


Wickens (1992) ha propuesto un modelo de distribución de recursos que se reproduce en la Figura 9.


Figura 9: Modelo de Wickens (1992) referente a la asignación de recursos cognitivos


Los recursos mentales se asignan según las características de la tarea. Con arreglo a eso, se asignarán más recursos al sistema perceptivo (por ejemplo, en indicadores), al procesador central o al sistema de respuesta (por ejemplo, en controles), requerirán códigos espaciales (por ejemplo, iconos) o verbales (por ejemplo, señales verbales de aviso, Stop, ¡fuego!, etc.) en modalidad visual o auditiva y requerirán tipos de respuesta manual o verbal.


 

ANIMuS y procesos cognitivos (II)

 

Interacción Natural: ¿dónde estamos parados?


 

Objetivos

La interacción natural es influenciada por la persona que interactúa con ella, dicha interacción busca sorprender, divertir o resolver preguntas del usuario, la interfaz natural activa las dinámicas cognitivas que la gente común experimenta, lo que aumenta el nivel de atención en el contenido y reduce la carga en pos de entender el funcionamiento de dispositivos como controles de videojuegos, donde la persona debe aprender además de, para qué sirve cada botón, las combinaciones de botones para activar una acción en el juego.


La tecnología no define la naturaleza del sistema, es más una herramienta para crear un espacio comunicativo, en comparación con las interfaces comunes. Según Valli las interfaces deben ir en dirección de una mayor coherencia con las características perceptivas de los humanos.


Fundamentos

Las personas utilizan gestos, expresiones, movimientos de forma natural para poder comunicarse entre ellas. De hecho, se ha demostrado que los niños se logran comunicar mediante gestos antes de que aprendan a hablar. A menudo se utilizan gestos acompañados o no mediante comunicación del tipo verbal. Si llevamos esto al terreno de la comunicación con las diferentes aplicaciones podríamos comunicarnos con ellas sin la necesidad de ningún tipo de dispositivo. De esta forma, el uso de gestos y movimientos naturales e intuitivos del cuerpo, podrían ser utilizados como comandos o interfaz de comunicación para operar distintos dispositivos inteligentes utilizados en las actividades diarias en la cuales nos encontremos. Además, mediante esta forma de interacción podemos comunicarnos en un ambiente como así también recabar información del mismo.


La estructura y mecanismos de las interfaces gestuales están compuestas básicamente por tres partes: un sensor que detecta el movimiento, un comparador que computa los cambios detectados y un actuador que realiza las acciones como respuesta. Las interfaces gestuales son de aplicación cuando se requiere alguna libertad de movimiento o una sensación de inmersión (como en el caso de ambientes de realidad virtual).


Conceptos básicos sobre los cuales se funda la interacción natural son los siguientes:


  • NATURAL: Son naturales las actividades cotidianas de las personas. Estímulos simples conllevan a interacciones más simples.

  • CONTEXTO: Ayuda a interpretar las acciones, por esto, la cantidad de información que procesan los usuarios tiene que ser reducida.

  • PERIFERIA: Es un flujo constante de información sin sobrecarga. Para que la información sea eficaz, es cifrada (color, forma, sonido, tamaño, etc.).

  • MEDIO: El objetivo es quitar cualquier nivel de mediación entre la persona y la máquina; el medio se hace un elemento activo.

  • ESPACIO FÍSICO: No sólo el elemento se comunica con la persona, es el ambiente total que lo abarca.

  • MOVIMIENTO: Es la señal de cambio, por eso es un elemento tan importante en la interacción.

  • INTERACCIÓN: Acción mutua o recíproca entre objetos inanimados o personas. En las personas, es la suma de las actividades, como conversar, gesticular, oír  o mirar.

  • COGNICIÓN: Consiste en representar la información por estímulos elementales sensoriales, que no requieran una gran cantidad de actividad mental.

  • ATENCIÓN: Puede ser definida como una capacidad de enfocar y mantener interés a un objeto dado. La interfaz debería ser tan invisible como sea posible, reduciendo la distracción.

  • COMPETICIÓN Y COLABORACIÓN: La interacción de una sola persona no está bien aceptado por la audiencia, pero es difícil aumentarlas.

  • ESTÉTICA Y EMOCIÓN: La estética influye en la calidad del contenido. Las emociones en interfaces juegan un papel importante: el asombro, el miedo, la admiración influyen en el ser humano.

  • LIBERTAD: Las personas pueden moverse libremente dentro o alrededor del espacio interactivo, sin restricciones evidentes. La interacción no debe ser mecánica.

  • INTEGRACIÓN: Un sistema natural se compone de múltiples elementos y  todos ellos se deben integrar eficientemente.



ANIMuS y procesos cognitivos (I)

Introducción


Es natural en el ser humano la interacción, ya sea con otro ser humano o con el entorno en el que está inmerso. Junto con el gran avance tecnológico y los nuevos medios, esta interacción se va convirtiendo en algo más complejo y extraño para muchos, pues la interacción está mediada por una máquina y en este punto la interacción deja de ser natural.


Cuando los seres humanos y las computadoras interactúan lo hacen a través de un medio o interfaz. Una interfaz se le llama a una superficie de contacto que refleja las propiedades físicas de los que interactúan, las funciones a realizar y el balance de poder y control.


En el caso de la Interacción Persona Computadora, la interfaz es el punto en el que seres humanos y las computadoras se ponen en contacto, transmitiéndose mutuamente tanto información, órdenes y datos como sensaciones, intuiciones y nuevas formas de ver las cosas. Por otro lado, la interfaz es también un límite a la comunicación en muchos casos, ya que aquello que no sea posible expresar a través de ella permanecerá fuera de nuestra relación mutua. Ahora bien, mientras que a veces esos límites derivan del estado actual de nuestros conocimientos acerca de cualquiera de las partes implicadas, en muchos casos la interfaz se convierte en una barrera debido a un pobre diseño y una escasa atención a los detalles de la tarea a realizar.


Actualmente existe un creciente interés en el estudio de la interacción orientada a los usuarios no entrenados tecnológicamente, en este caso, es necesario utilizar técnicas de interacción que no presuman ningún conocimiento previo del usuario, ni le atribuya ninguna otra habilidad interactiva que no sea la que le permite relacionarse con otras personas. Se persigue que las interacciones entre el hombre y las máquinas imiten a las existentes entre seres humanos con el fin de hacer más agradable e intuitivo el uso de las mismas. Esta forma de interacción se la denomina Interacción Natural y la disciplina que lo pretende recibe el nombre de HCI, Human Computer Interaction (Interacción Persona Computadora).


Interacción Persona Computadora (HCI)


 

Disciplina

La ACM, Association for Computer Machinery, tiene un grupo especial de trabajo en temas de HCI denominado SIGCHI, Special Interest Group in Computer Human Interaction, el cual propuso la siguiente definición de Interacción Persona Computadora:


“Es la disciplina relacionada con el diseño, evaluación e implementación de sistemas informáticos interactivos para el uso de seres humanos, y con el estudio de los fenómenos más importantes con los que está relacionado.”


El tema principal de esta disciplina está en la interacción entre unos o más seres humanos y una o más computadoras. Aunque la situación clásica sería una persona usando un programa sentado en su puesto de trabajo, alrededor de las palabras interacción, persona y computadora hay un amplio conjunto de opciones posibles. Por ejemplo, los computadores pueden formar parte de un avión, monitores de ruta en coches, teléfonos móviles, blocs de notas, libros electrónicos, sistemas de realidad virtual, etc. Por otro lado, los usuarios pueden formar parte de grupos u organizaciones y por tanto necesitaremos de interfaces para sistemas distribuidos o trabajo cooperativo. O también, el sujeto puede querer utilizar su computador mientras camina hacia una reunión para consultar su agenda, las llamadas telefónicas pendientes y las últimas cotizaciones en bolsa. También, el usuario puede tener la visión o la movilidad disminuida y utiliza un software de lectura de pantalla o de reconocimiento de la voz para manejar su computador. Todas estas situaciones podrían ser manejadas por esta disciplina que llamamos Interacción Persona Computadora.

 

Objetivos

Los objetivos de HCI según Diaper D. en “The discipline of human-computer interaction” son desarrollar o mejorar la seguridad, utilidad, efectividad, eficiencia y usabilidad de sistemas que incluyen computadoras. Cuando decimos sistemas no nos referimos tan solo al hardware y al software sino también a todo el entorno.


Para hacer sistemas interactivos hace falta considerar los siguientes puntos:


  • Comprender los factores psicológicos, ergonómicos, organizativos y sociales, que determinan cómo la gente trabaja y hace uso de las computadoras.

  • Trasladar esta comprensión para desarrollar herramientas y técnicas que ayuden a los diseñadores a conseguir que los sistemas informáticos sean los idóneos según las actividades a las cuales se quiera aplicar.

  • En base a lo anterior, conseguir una interacción eficiente, efectiva y segura, tanto a nivel individual como de grupo.


Es muy importante comprender que los usuarios no han de cambiar radicalmente su manera de ser, sino que los sistemas han de ser diseñados para satisfacer los requisitos del usuario.

 

Interdisciplinariedad

Existen diversos factores que hay que considerar en HCI y que además están interrelacionados entre sí como lo indica en los siguientes puntos:

  • Factores psicológicos de los usuarios: procesos cognitivos, capacidad personal, nivel de experiencia, estudio de la memoria, motivación.

  • Factores organizativos: entrenamiento, diseño del local de trabajo, política, cargos, organización del trabajo.

  • Factores del entorno: ruidos, ventilación/calefacción, iluminación.

  • Factores de salud y seguridad: estrés, dolores de cabeza, molestias visuales, desórdenes musculares.

  • Factores de confort: silla, diseño del equipamiento.

  • Interfaz de usuario: dispositivos de entrada, pantallas de salida, diseño de los diálogos, uso del color, iconos, órdenes, materiales de soporte al usuario (ayudas).


Las referencias científicas relacionadas con la Ingeniería del Software en general y con la Interacción Persona Computadora en particular constantemente mencionan, sugieren y recomiendan la formación de equipos de desarrollo de sistemas interactivos compuestos por personas procedentes de disciplinas diversas o equipos multidisciplinares. Tales equipos juegan un papel determinante en el desarrollo de software actual y futuro, pues complementan el papel del ingeniero software y del programador para producir sistemas que verdaderamente recojan las necesidades de los usuarios y su contexto para ofrecerles sistemas más agradables, más eficientes y, en definitiva, más fáciles de usar.

Las diferentes disciplinas se agrupan en áreas comunes de conocimiento cuya intervención en el diseño de sistemas interactivos esquemáticamente se enmarcan de la Figura 1.



Figura 1: Áreas de conocimiento y su papel dentro de un sistema interactivo. El usuario es estudiado por las ciencias en humanidades y la ergonomía, la interacción por las diferentes formas de representación y parte técnica del sistema por la ingeniería de software y hardware.



La parte “humana” de la interacción es analizada por las ciencias de las humanidades y por la ergonomía. Las humanidades, en términos generales, son interpretaciones intelectuales de distintos aspectos de la experiencia humana que tradicionalmente engloban disciplinas como la historia, la filosofía, las ciencias sociales, la psicología o la antropología (entre otras), siendo estas últimas las que mayoritariamente suelen estar presentes en los equipos de HCI.


Mientras que la ergonomía hace referencia a aspectos de la adaptación y el encaje entre las características (principalmente físicas) de las personas con las de los equipos técnicos en la “interacción”, como el punto de contacto entre las entidades “persona” y “computadora”, precisa de disciplinas como el diseño gráfico, la arquitectura de la información y la documentación para trasladar las necesidades de la primera entidad en acciones de la segunda. Y finalmente, la “computadora” o sistema interactivo en general precisa de la intervención altamente cualificada de los técnicos encargados de la codificación para que el sistema presente en forma de elementos interactivos las funcionalidades a sus usuarios.


Figura 2: Principales disciplinas involucradas con la Interacción Persona Computadora



 

De los objetivos: usabilidad y accesibilidad

Para que un sistema interactivo cumpla sus objetivos tiene que ser usable y, además, debido a la generalización del uso de los ordenadores, accesible a la mayor parte de la población humana.

 

La utilidad de un sistema como medio para conseguir un objetivo, tiene una componente de funcionalidad (la llamada utilidad funcional) y otra basada en el modo en que los usuarios pueden usar dicha funcionalidad; es esta última la que nos interesa ahora.


Podemos definir la usabilidad como la medida en la que un producto se puede usar por determinados usuarios para conseguir objetivos específicos con efectividad, eficiencia y satisfacción en un contexto de uso especificado.

 

¿Una aplicación usable es accesible?, ¿una aplicación accesible es usable? Aunque son conceptos que por su importancia deberían ser tratados conjuntamente y con alta prioridad en el desarrollo de aplicaciones de software, los conceptos de usabilidad y de accesibilidad disponen de significado y características bien diferenciadas. Veamos estas diferencias a partir de los cuatro casos que pueden darse en una aplicación:


  1. Ni usable ni accesible: Desafortunadamente este es el caso más habitual en las aplicaciones interactivas. Este caso recoge aquellas aplicaciones que aún siendo accesibles para un subconjunto de la población carecen de la usabilidad necesaria para utilizarlas satisfactoriamente.

  2. Usable y no accesible: En este caso será sólo usable para quienes puedan acceder a sus funcionalidades, o mejor dicho será usable para la población para la cual ha estado implementada la aplicación. Este caso es aquel en el que para el desarrollo de la aplicación se han tenido en cuenta y aplicado las técnicas de la usabilidad.

  3. Accesible sin ser usable. Se puede comparar con el primero, en el que una parte de la población podía acceder a las funcionalidades y se encontraría con problemas de usabilidad, pero en este caso lo que cambia es que el abanico de población que notará esta falta de usabilidad será mayor puesto que al ser accesible el número de personas que podrá acceder a sus servicios y/o funcionalidades es mayor.

  4. Usable y accesible. Este es el caso ideal, aunque el más escaso. Representa la idea básica del diseño universal, donde además de favorecer el acceso a todo el mundo lo hace de manera usable.


Así, respondemos negativamente a las dos preguntas planteadas al inicio, aunque la respuesta sería afirmativa si la pregunta hubiese sido ¿Una aplicación accesible es más usable?, puesto que puede ser usada por un número mayor de personas.



 

Proceso de diseño centrado en el usuario

La filosofía de este tipo de diseño tiene por objetivo la creación de productos que resuelvan necesidades concretas de sus usuarios finales, consiguiendo la mayor satisfacción y mejor experiencia de uso posible.


El diseño de sistemas interactivos implica realizar un diseño pensando en el usuario, centrando nuestro sistema de desarrollo en él e implicarlo tanto como sea posible, hasta pensar en incluir usuarios en el equipo de diseño. Cada decisión tomada debe estar basada en las necesidades, objetivos, expectativas, motivaciones y capacidades de los usuarios.


La mayoría de los procesos que hacen diseño centrado en el usuario siguen el siguiente esquema:


  • Conocimiento a fondo a los usuarios finales.

  • Diseño de un producto que resuelva sus necesidades y se ajuste a sus capacidades, expectativas y motivaciones.

  • Puesta a prueba de lo diseñado.



Figura 3: Esquema del proceso de creación de interfaces en ingeniería de la usabilidad basándose en diseño centrado en el usuario


Las pruebas  son  una  herramienta  esencial  para  la  investigación  de  la  interacción persona-computadora,  y  también  dentro  del  campo "usabilidad". La AIPO (Asociación Interacción Persona-Ordenador) elaboró en este contexto un código  ético  el cual consiste en proponer  unos  principios  de aplicación  universal  a  lo  que  se  conoce  como  "pruebas  de  usuario". Siempre  que  dichas  pruebas  se  realicen  con  personas, normalmente  pero  no necesariamente usuarios ajenos al desarrollo de productos de tecnología, debemos cumplir con unas normas que van más allá de las tradicionales de cortesía, puesto que estamos pidiendo a los usuarios tareas que les requieren cierto esfuerzo, y además de querer recoger con la máxima validez sus opiniones y emociones, un objetivo esencial es que los participantes tengan la mejor experiencia posible de las pruebas para que en el futuro deseen volver a participar en las mismas.  


El campo de aplicación de este código ético está directamente relacionado con las pruebas de usuario, y no tanto con otras prácticas de usabilidad en la que no existe esta interacción con personas.


Como resumen, en este reglamento se detallan puntos como:


  • Privacidad y confidencialidad.

  • Consentimiento informado previo a la investigación.

  • Proporcionar  y  discutir  con  los  participantes  los  resultados  de  la investigación.

  • Abandono o renuncia a participar en la investigación.

  • Tratamiento de la decepción del usuario.


Esto resalta la idea de cuan importante es el usuario en nuestros sistemas, y a su vez, cuan necesario es cuidarlo a la hora de diseñar, implementar y testear.

 

Historia

En la evolución de la disciplina han influido diversos factores:


  • La creatividad humana: especialmente en los inicios de la ciencia informática diversos visionarios realizaron proyecciones imaginarias sobre lo que podrían llegar a ser las computadoras.

  • El estado del arte de la tecnología: a menudo actuando como límite al diseño.

  • El mercado de los computadores: directamente relacionado con el coste de los aparatos y que incide directamente tanto en el tipo de usuario como en el uso que hacen éstos.



Figura 4: Evolución de los paradigmas de interacción persona computadora


La historia del diseño de la interfaz y la interacción es un camino de complejidad a la simplicidad, a partir de máquinas diseñadas para fines científicos que se podrían utilizar sólo algunos pocos técnicos, a los dispositivos ubicuos, que se supone son fáciles de usar para todos en la vida cotidiana.


La computación personal se desarrolló entre otros, con el modelo de ventanas, punteros y ratones como paradigma dominante para la interacción con las aplicaciones de escritorio. Las posibilidades tecnológicas de las últimas tres décadas han permitido llevar la computación de información a casi todos los artefactos de la vida cotidiana, dando pie al campo conocido como computación ubicua o pervasiva. El programa original de este conjunto heterogéneo de iniciativas, conocido como “computación para la calma” (Weiser et al, 1997) ha sido desafiado por los planteos de la interacción gestual. La interacción gestual que se plantea como “la creación, manipulación y distribución de significado mediante una interacción activa con los artefactos” (Dourish, 2001) resulta un marco conceptual ineludible a la hora de afrontar el desarrollo de sistemas con interacción basada en gestos sin reducir el enfoque al  trasladar el paradigma de ventanas, punteros y ratones “fuera de la pantalla”.


En esta línea, el proceso evolutivo, se destaca enfocándose en establecer parámetros que no le implican un esfuerzo cognitivo sustancial al usuario.

 

OpenCV (II)


Tipo de datos



OpenCV maneja un conjunto de datatypes predefinidos con los que se puede operar. Cada uno de los tipos de las variables utilizadas deben ser algunos de los siguientes:


- 8-bit unsigned integer (uchar)

- 8-bit signed integer (schar)

- 16-bit unsigned integer (ushort)

- 16-bit signed integer (short)

- 32-bit signed integer (int)

- 32-bit floating-point number (float)

- 64-bit floating-point number (double)


Para estos tipos de datos se define el siguiente enumerado:


enum { CV_8U=0, CV_8S=1, CV_16U=2, CV_16S=3, CV_32S=4, CV_32F=5, CV_64F=6 };


A cada tipo de los mencionados arriba se le puede definir canales que son representados de la siguiente forma:



  • CV_8UC1 ... CV_64FC4 para canales del 1 al 4.

  • CV_8UC(n) ... CV_64FC(n) o CV_MAKETYPE(CV_8U, n) ... CV_MAKETYPE(CV_64F, n) cuando el número de canales es superior a 4 (n) o cuando no se conoce en tiempo de compilación.


Las siguientes definiciones de canales son análogas:


CV_32FC1 == CV_32F, CV_32FC2 == CV_32FC(2) == CV_MAKETYPE(CV_32F, 2).



GPU



Como ya mencionábamos, OpenCV es un framework de visión asistida por computadora utilizado por miles de desarrolladores para programar aplicaciones de alta carga computacional, las cuales en su mayoría necesitan un rendimiento elevado y estable en tiempo real. Es por esto que el consumo de CPU para las aplicaciones que utilizan este framework puede llegar a ser muy elevado y en muchos casos la performance de la aplicación se ve degradada. Por este motivo, OpenCV permite utilizar la GPU como medio de procesamiento de los algoritmos más pesados. La posibilidad de acelerar OpenCV en la GPU permite a los programadores ejecutar algoritmos más complejos en tiempo real y con imágenes de mayor resolución, lo cual posibilita la creación de numerosas aplicaciones de visión computarizada que requieren alta performance y gran potencia de cómputo. El nuevo motor de cálculo de profundidad de OpenCV se ejecuta entre 5 y 10 veces más rápido con la GPU que con las implementaciones equivalentes basadas exclusivamente en la CPU.


Las aceleradoras GPU se han vuelto cada vez más poderosas y capaces de procesar algoritmos computacionales de propósito general. Independientemente de la dificultad inherente en re-implementar algoritmos para ser corridos sobre un GPU, varias personas lo han intentado con el objetivo de estudiar las ventajas en lo que refiere a la performance resultante. Para dar soporte a dichos esfuerzos han surgido varias herramientas como CUDA, OpenCL, C++ AMP, entre otras. Gran parte de la visión por computadora está relacionada al procesamiento de imágenes y esta área es justamente para la cual fueron diseñadas tarjetas aceleradoras.


OpenCV incluye un módulo que da soporte al desarrollo sobre GPU respaldado por NVIDIA. Comenzado este soporte en el 2010 y hasta el primer release del 2011, incluye soporte para GPU en gran parte de los algoritmos del framework. Este desarrollo continúa en proceso adaptándose a las nuevas tecnologías y arquitecturas de las GPU actuales.

 

Figura 4: Comparación de performance de GPU vs CPU


El módulo de OpenCV para GPU está desarrollado utilizando CUDA, beneficiándose así de sus beneficios y por lo tanto da soporte únicamente para NVIDIA GPU. Por otro lado, posee una larga comunidad y un gran arsenal de herramientas y librerías como NVIDIA NPP, CUFFT, Thrust, entre otras. El mismo es diseñado de forma “host-level API”, lo cual quiere decir que si se poseen los binarios pre-compilados de OpenCV GPU, no es necesario poseer el toolkit de CUDA instalado o escribir código extra para que se haga uso de la GPU. Por otro lado, está diseñado de forma que su uso sea sencillo y no requiere de conocimientos de CUDA. De esta forma es una herramienta efectiva y rápida para la implementación con aceleración por GPU de algoritmos de computer vision.


El módulo de GPU contiene la clase cv::gpu::GpuMat, el cual es el primer contenedor de información para mantener en la GPU. Esta clase es muy similar a cv::Mat, la contraparte en CPU. Todas las funciones provista para GPU tiene como entrada y salida argumentos del tipo GpuMat. En definitiva, el módulo trata de mantener las interfaces lo más parecidas a las interfaces de CPU de forma que le sea familiar a aquellos desarrolladores que se encuentran ya familiarizados con OpenCV en CPU.


Un pequeño ejemplo, donde se carga una imagen y se aplica la función “thresholded” para luego mostrarla haciendo uso de la GPU es la siguiente:

 

#include <iostream>
#include "opencv2/opencv.hpp"
#include "opencv2/gpu/gpu.hpp"


int main (int argc, char* argv[])
{
   try
   {
       cv::Mat src_host = cv::imread("file.png", CV_LOAD_IMAGE_GRAYSCALE);
       cv::gpu::GpuMat dst, src;
       src.upload(src_host);

       cv::gpu::threshold(src, dst, 128.0, 255.0, CV_THRESH_BINARY);

       cv::Mat result_host = dst;
       cv::imshow("Result", result_host);
       cv::waitKey();
   }
   catch(const cv::Exception& ex)
   {
       std::cout << "Error: " << ex.what() << std::endl;
   }
   return 0;

}

Código 2: Ejemplo básico uso de GPU



Para habilitar el soporte basado en CUDA hay que configurar el CMake de OpenCV con la bandera WITH_CUDA=ON. Con esta bandera encendida y si CUDA se encuentra instalado todo el módulo de OpenCV GPU es construido. De otra forma, el módulo es construido en modo runtime por lo que todas las operaciones arrojarán una excepción de tipo withCV_GpuNotSupported, exceptuando gpu::getCudaEnabledDeviceCount() la cual retorna cero como contador de GPU.


Construir OpenCV sin el soporte de CUDA no implica problemas de compilación por lo que no se necesita tener instalado el toolkit de CUDA. Por lo tanto haciendo uso de gpu::getCudaEnabledDeviceCount() se puede implementar un algoritmo que detecte la presencia de una GPU en runtime y por lo tanto escoja una implementación acorde, sea CPU o GPU.


Para el caso de algoritmos de alto nivel hacer uso de múltiples GPUs es una buena ventaja, aunque se debe tener en cuenta el overhead generado por el pasaje de información, básicamente lecturas y escrituras intermedias. Para el caso de algoritmos de alto nivel esto puede ser insignificante pero para funciones primitivas e imágenes pequeñas puede ser muy notorio. De todas formas, para la versión actual de OpenCV cada uno de los algoritmos sobre OpenCV GPU puede hacer uso de una única GPU, por lo que para hacer uso de múltiples GPU debería llevarse a cabo de forma manual distribuyendo el trabajo entre las mismas.


El compilador de NVIDIA permite la generación de código binario (cubin y fatbin) y código intermedio (PTX). Este código binario por lo general implica una GPU específica por lo que la compatibilidad con otras GPUs no está garantizada.


Este punto referente a poder hacer uso de la GPU para ciertas operaciones y algoritmos de procesamiento de imágenes es considerado un punto importante a tener en cuenta para nuestro proyecto, ya que la performance obtenida podría mejorarse considerablemente.



Android




Desde el año 2012 OpenCV provee soporte para el entorno Android, permitiendo de esta forma llevar el potencial de OpenCV a las aplicaciones para dispositivos móviles.



iOS

 


 

Actualmente el grupo de desarrollo de OpenCV se encuentra trabajando en la extensión de OpenCV para el soporte a iOS. Se pretende que a fines de 2012 se abarque la totalidad de la integración. En el este link se puede obtener información acerca del estado actual de dicho desarrollo.   



OpenCV & OpenFrameworks



Como mencionábamos en post anteriores, OpenFrameworks es un framework basado en la integración de diversas herramientas y librerías con el objetivo de brindar a los programadores facilidades asociadas a lo artístico y a los artistas facilidades asociadas a lo programático. Así como las ya nombradas librerías integradas como parte de este framework, se puede incluir a OpenFrameworks un wrapper de OpenCV por medio de un addon. Este addon es ofxOpenCv y logra incluir parte de las funcionalidades provistas por OpenCV. Las inclusiones que se logran son las siguientes:


ofxCvShortImage

ofxCvImage

ofxCvFloatImage

ofxCvBlob

ofxCvHaarFinder

ofxCvContourFinder

ofxCvColorImage

ofxCvGrayscaleImage


De todos modos, debido a que nos interesa, en un principio, no restringir ningún potencial que podamos adquirir a partir de estos frameworks que venimos analizando, decidimos utilizar OpenCV por fuera de OpenFrameworks (el cual ya pudimos configurar correctamente para su uso en VS 2010 como detallamos en post anteriores).




¿Has utilizado algún framework de Computer Vision? ¿Y en particular OpenCV? ¿Qué te pareció? ¡Esperamos tus comentarios!





Referencias



[1] Sitio OpenCV: http://opencv.org/
Último acceso: 17 de Octubre de 2012
[2] Documentación OpenCV: http://docs.opencv.org/
Último acceso: 20 de Octubre de 2012
[3] Documentación OpenFrameworks: http://www.openframeworks.cc/documentation/
Último acceso: 20 de Octubre de 2012
[4] NVIDIA: http://www.nvidia.es/object/nvidia-for-opencv-press-20100923-es.html
Último acceso: 20 de Octubre de 2012
[5] NVIDIA developers: http://developer.download.nvidia.com/GTC/PDF/1085_Fung.pdf
Último acceso: 20 de Octubre de 2012

OpenCV (I)

 

Introducción


En post anteriores ya hemos presentado algunos frameworks como OpenNI y OpenFrameworks, pero como mencionábamos también algunos post atrás nos quedaba pendiente analizar otro framework, del cual comentamos sólo su configuración en Microsoft Studio 2010, el mismo es OpenCV.


Veremos entonces qué es lo que este framework nos ofrece y qué argumentos consideramos como positivos a favor de incluirlo dentro de nuestro proyecto.





 

¿Qué es OpenCV?



OpenCV (Open Source Computer Vision Library) es un framework que se encuentra bajo licencia BSD y que incluye cientos de algoritmos de computer vision el cual fue diseñado con un fuerte enfoque en las aplicaciones en tiempo real. Al poseer una licencia del tipo BSD este framework es gratuito para uso tanto académico como comercial, factor importante para poder usarlo en nuestro proyecto. Por otro lado, dispone de interfaces para C++, C, Python y Java, y es compatible con sistemas tipo Windows, Linux, Android y Mac OS, lo cual lo hace totalmente multiplataforma, otro punto clave a tener en cuenta para utilizarlo en nuestro proyecto.


Como se observa en la Figura 1, las primeras versiones de OpenCV datan del año 1999, y desde ese entonces no se ha discontinuado su desarrollo año tras año. La versión más reciente al día de hoy es la 2.4, contando con mejoras radicales en lo referente a módulos para la utilización de la GPU, algoritmos paralelizados, compatibilidad con sistemas operativos, con respecto a versiones anteriores.

 

 

Figura 1: Línea del tiempo de desarrollo de OpenCV



OpenCV pretende proporcionar un entorno de desarrollo fácil de utilizar y altamente eficiente, lo cual se ha logrado realizando su programación en código C y C++ optimizados, aprovechando además las capacidades que proveen los procesadores multi núcleo. OpenCV puede a su vez hacer uso del sistema de primitivas de rendimiento integradas de Intel, las cuales son un conjunto de rutinas de bajo nivel específicas para procesadores Intel (IPP).

 

 

Figura 2: Utilidades de OpenCV


 

OpenCV contiene más de 500 algoritmos optimizados que abarcan una gran gama de áreas en el proceso de visión y de la algoritmia de propósito general. Como se observa en la Figura 2, a pesar de contar con primitivas como binarization (transformación de una imagen RGB a una imagen en blanco y negro), filtrado, y primitivas referentes a la obtención de gran cantidad de estadísticas de una imagen, OpenCV es principalmente un framework que implementa algoritmos para calibración de cámaras, detección y reconocimiento de rostros, reconocimiento, segmentación y rastreo de objetos, análisis de geometría, análisis del movimiento, clasificación de las acciones humanas en videos mediante algoritmos de aprendizaje automático, seguimiento de objetos en movimiento, extracción de modelos 3D a partir de objetos, producción de nubes de puntos tridimensionales, combinación de imágenes para producir una más alta resolución de una escena dada, búsqueda de imágenes similares a partir de una base de datos de imágenes, eliminación de ojos rojos en imágenes tomadas con flash, seguimiento del movimientos de los ojos, reconocimiento de paisajes, y una gran cantidad de funcionalidades adicionales relacionadas con el análisis de imágenes.


Las utilidades descritas arriba se pueden agrupar dentro de las categorías listadas a continuación, junto con algunas de las operaciones que provee OpenCV para cada una de ellas:


- Manipulación de imágenes: asignar/desasignar memoria, copia, configuración, conversión.

I/O de imagen y vídeo: archivos entrada y salida de imagen y vídeo.

- Matriz, vector y rutinas de álgebra lineal: productos, valores propios, SVD, etc.

- Estructuras de datos dinámicas: listas, colas, conjuntos, árboles, grafos.

- Procesamiento de imágenes: filtrado, detección de bordes, detección de esquinas, muestreo e interpolación, conversión de color, operaciones morfológicas, histogramas, pirámides de imagen.

- Análisis estructural: componentes conectadas, contorno de procesamiento, transformación distancia, transformada de Hough, aproximación poligonal, conexión de la línea, ajuste de elipse, triangulación de Delaunay.

- Calibración de cámaras: búsqueda y seguimiento de patrones de calibración, calibración,   estimación de la matriz fundamental, estimación homografía, correspondencia estéreo.

- Análisis de movimiento: flujo óptico, segmentación de movimiento, seguimiento.

- Reconocimiento de objetos: Método de Eirgen, HMM.

- GUI básica: visualización de imagen y vídeo, manejo de teclado y mouse, scroll-bars.

- Etiquetado de imágenes: etiquetado de imágenes (líneas, conos, polígonos, etc).

 

 

Figura 3: Categorías de OpenCV




Usuarios



OpenCV tiene más de 47 mil personas en la comunidad de usuarios y el número estimado de descargas del mismo llega a ser superior a los 5 millones. Varias empresas de renombre como Google, Yahoo, Microsoft, Intel, IBM, Sony, Honda, Toyota hacen uso intensivo de OpenCV al igual que algunas startups reconocidas como Applied Minds, VideoSurf y Zeitera. Esta gran comunidad activa también es un punto muy favorable que pesa al momento de considerarlo como parte de nuestro proyecto. Los usos de OpenCV en estos ámbitos van desde sistemas de seguridad con detección de movimiento hasta aplicativos de control de procesos donde se requiere reconocimiento de objetos.



Estructura



OpenCV posee una estructura modular, esto es, está compuesto de diferentes módulos, dentro de los cuales se destacan los siguientes:


- core: en este módulo se encuentra las estructuras básicas de OpenCV como son Mat (estructura para representar matrices) y funciones básicas que utilizan el resto de los módulos.

- imgproc: este módulo se encarga del procesamiento de imágenes mediante alguna de las operaciones que ya mencionamos (filtrado, transformaciones geométricas, conversiones de color, histogramas etc.).

- highgui: este módulo se encarga de la gestión de entrada y salida y lo referente a la interfaz de usuario. A su vez, provee codecs para imagen y vídeo.

- calib3d: este módulo posee múltiples algoritmos de visión geometría, calibración de sonido y cámara, estimación de posición de objetos, algoritmos de correspondencia estéreo, reconstrucción 3D.

- features2d: este módulo posee detectores de características sobresalientes, descriptores y comparadores descriptores.

- video: módulo para el análisis de vídeos que incluye estimación de movimiento, sustracción de fondo y seguimiento de objetos.

- objdetect: módulo de detección de objetos e instancias de los tipos predefinidos como por ejemplo caras, ojos, tazas, personas, autos, entre otros.

- ml : módulo de aprendizaje automático.

- gpu: módulo de aceleración por GPU para los algoritmos de los demás módulos.



Memoria




OpenCV maneja la memoria de forma automática, así, por ejemplo para estructuras del tipo st::vector, Mat, entre otras, OpenCV posee destructores que liberan los buffers de memoria asignados cuando sea necesario como así también maneja de forma automática la reserva de memoria para alojar dichas estructuras. Esto significa que los destructores no siempre liberan la memoria ya que toman en cuenta aquella que es compartida, esto es, referenciada desde varios puntos. Lo que realizan estos destructores es llevar la cuenta de cuántas referencias posee por ejemplo el buffer de memoria asociada a una matriz. El buffer es liberado sólo si ese contador posee cero referencias, esto es cuando otra estructura no referencia al mismo buffer. De forma similar cuando una matriz es copiada, no es exactamente copiada la información sino que es incrementado el contador de referencia a modo de recordar que hay otro “dueño” de esa información. Así, por ejemplo para el caso de las matrices, para crear una copia independiente alojada en otro espacio de memoria se utiliza el método clone.


Por otro lado, OpenCV determina tamaños no definidos de estructuras. Por ejemplo, si una función tiene algunas matrices de entrada y de salidas, además de asignar la memoria para la estructura de salida determina su tamaño a partir de las estructuras de entrada.


Dado el ejemplo ilustrado en el Código 1, a la estructura frame se le asigna automáticamente memoria tras asignarle un elemento de tipo captura de video con el operador >>.

 

#include "cv.h"
#include "highgui.h"

using namespace cv;

int main(int, char**)
{
   VideoCapture cap(0);
   if(!cap.isOpened()) return -1;

   Mat frame, edges;
   namedWindow("edges",1);
   for(;;)
   {
       cap >> frame;
       cvtColor(frame, edges, CV_BGR2GRAY);
       GaussianBlur(edges, edges, Size(7,7), 1.5, 1.5);
       Canny(edges, edges, 0, 30, 3);
       imshow("edges", edges);
       if(waitKey(30) >= 0) break;
   }
   return 0;
}

Código 1: Manejo de estructuras


Luego la estructura edges también es asignada automáticamente tras ejecutar cvtColor, y adquiere el tamaño heredado por la estructura de entrada, que en este caso es frame. Debido a que se utiliza CV_BGR2GRAY (especificando que se debe pasar a escala de grises el mapa RGB) se está haciendo uso de un único canal.


Tanto frames como edges son asignados una única vez tras ejecutar el primer ciclo ya que los tamaños heredados no sufren modificaciones. En caso contrario, si el vídeo captado, por ejemplo, cambiara de resolución, el valor heredado cambiaría y por lo tanto debería de ocurrir una nueva asignación de memoria.



La segunda parte del post aquí.

 

Pruebas de concepto y prototipos (II)

Iteración 7 - Definición de la arquitectura del framework

El objetivo de esta iteración es lograr definir una arquitectura de servicios acorde para el framework que conforma ANIMuS, basados en las observaciones y definiciones realizadas como parte de las iteraciones anteriores. A nivel macro, en este caso los hitos se corresponden con la definición de cada uno de los grupos de servicios que ofrecerá el framework, y son los siguientes:

 

  • Hito_Diseño_7_1: Definición de servicios para manipulación de gestos.
  • Hito_Diseño_7_2: Definición de servicios para reconocimiento de objetos.
  • Hito_Diseño_7_3: Definición de servicios para configuración de cámaras.
  • Hito_Diseño_7_4: Definición de servicios para intercomunicación entre dispositivos.
  • Hito_Diseño_7_5: Definición de servicios para identificación de varios los usuarios.
  • Hito_Diseño_7_6: Definición de servicios para persistencia de datos (persistir lo que se esté mostrando en el espacio de trabajo, etc).

 

Iteración 8 - Implementación de la arquitectura del framework (Fase 1)

El objetivo de esta iteración es implementar una arquitectura correcta para el framework que conforma ANIMuS, basados en las definiciones realizadas como parte de las iteraciones anteriores, principalmente en la Iteración 7 correspondiente a la definición de los servicios que brinda el framework. A nivel macro, en este caso los hitos se corresponden con la implementación de cada uno de los grupos de servicios que ofrecerá el framework, los cuales se describen a continuación. Cabe comentar que como resultado de esta fase se implementan los servicios básicos prioritarios del framework, postergando la implementación de los restantes (menos prioritarios y extras) para próximas iteraciones.

 

  • Hito_Implementación_8_1: Implementación de los servicios para manipulación de gestos.
  • Hito_Implementación_8_2: Implementación de los servicios para configuración de cámaras.
  • Hito_Implementación_8_3: Implementación de los servicios servicios para persistencia de datos (persistir lo que se esté mostrando en el espacio de trabajo, etc)

 

Iteración 9 - Detección de dispositivos

El objetivo de este prototipo será reconocer cuándo un dispositivo computador es apoyado sobre la superficie de interacción. Para esto, las pruebas de concepto a realizar son las siguientes:

 

  • Prueba_Concepto_9_1: Detección de la llegada de un dispositivo computador por su forma.
  • Prueba_Concepto_9_2: Detección de la salida de un dispositivo computador por su forma.
  • Prueba_Concepto_9_3: Detección de la llegada de un dispositivo computador por conexión a la red local.
  • Prueba_Concepto_9_4: Detección de la salida de un dispositivo computador por conexión a la red local.

 

Iteración 10 - Compartir archivos

El objetivo de este prototipo es poder realizar la copia de cualquier tipo de archivo entre el servidor donde estará corriendo ANIMuS y los distintos dispositivos colocados sobre la superficie. Las pruebas de concepto a realizar son las siguientes:

 

  • Prueba_Concepto_10_1: Copiar un archivo desde el servidor a una determinada laptop que se encuentre en la misma red.
  • Prueba_Concepto_10_2: Copiar un archivo desde una determinada laptop, que se encuentra en la misma red, al servidor.
  • Prueba_Concepto_10_3: Copiar un archivo desde una determinada laptop a otra considerando que están en una misma red.
  • Prueba_Concepto_10_4: Copiar un archivo desde el servidor a “broadcast”, es decir, a todos los dispositivos de la oficina que fueron detectados y están conectados a la misma red que el servidor.
  • Prueba_Concepto_10_5: Copiar un archivo desde una determinada laptop a “broadcast”, es decir a todos los dispositivos de la oficina que fueron detectados y están conectados en la misma red que dicha laptop.

 

Iteración 11 - Implementación de la arquitectura del framework (Fase 2)

El objetivo de esta iteración es extender la arquitectura ya desarrollada para el framework agregando la detección de dispositivos computadores. Los hitos en este caso son los siguientes:

 

  • Hito_Implementación_11_1: Implementación de los servicios para reconocimiento de objetos computadores por forma.
  • Hito_Implementación_11_2: Implementación de los servicios para reconocimiento de objetos computadores por conexión a la red local.
  • Hito_Implementación_11_3: Implementación de los servicios referentes a la intercomunicación entre dispositivos, capaces de establecer comunicaciones entre los objetos detectados y el servidor en todos los sentidos, esto es, servidor→dispositivo, dispositivo→dispositivo, dispositivo→servidor, dispositivo→broadcast y servidor→broadcast.

 

Iteración 12 - Implementación de la arquitectura del framework (Fase 3)

El objetivo de esta iteración es extender la arquitectura ya desarrollada para el framework agregando la detección de diferentes usuarios. Los hitos en este caso son los siguientes:

 

  • Hito_Implementación_12_1: Implementación de los servicios para la identificación de la llegada de usuarios.
  • Hito_Implementación_12_2: Implementación de los servicios para la identificación de la salida de usuarios.

 

Iteraciones extra (opcionales)

 

Iteración 13 - Definición de la arquitectura del framework (extensión)

El objetivo de esta iteración es extender la definición ya definida de los servicios provistos por el framework para incorporar algunos servicios adicionales que si bien no son obligatorios para cumplir los objetivos son útiles e interesantes. A nivel macro, en este caso los hitos se corresponden con la definición de cada uno de los grupos de servicios extra que ofrecerá el framework, y son los siguientes:

 

  • Hito_Diseño_1: Definición de servicios para comandos por voz.
  • Hito_Diseño_2: Definición de servicios para distintas vistas, entendiendo por “distintas vistas” el hecho de que se pueda proyectar e interactuar no solo con la superficie sobre la cual están apoyados los dispositivos sino también en otras superficies cercanas como paredes o superficies vecinas.

 

Iteración 14 - Implementación de la arquitectura del framework (Fase 4)

El objetivo de esta iteración es implementar una arquitectura correcta para el framework que conforma ANIMuS, basados en las definiciones realizadas como parte de Iteración 13 correspondiente a la definición de los servicios extra que brinda el framework. A nivel macro, en este caso los hitos se corresponden con la implementación de cada uno de los grupos de servicios adicionales que ofrece el framework:

 

  • Hito_Implementación_1: Implementación de los servicios correspondientes al manejo por comandos de voz.
  • Hito_Implementación_2: Implementación de los servicios para configuración de distintas vistas, entendiendo por “distintas vistas” el hecho de que se pueda proyectar e interactuar no solo con la superficie sobre la cual están apoyados los dispositivos sino también en otras superficies cercanas como paredes o superficies vecinas.

 

Iteración 15 - Detección de otros dispositivos

El objetivo de este prototipo será reconocer cuándo un dispositivo genérico (computador, móvil, tableta, etc) es apoyado o quitado de la superficie de interacción. Para esto, las pruebas de concepto a realizar son las siguientes:

 

  • Prueba_Concepto_15_1: Detección de la llegada de un dispositivo cualquiera por su forma.
  • Prueba_Concepto_15_2: Detección de la salida de un dispositivo cualquiera por su forma.
  • Prueba_Concepto_15_3: Detección de la llegada de un dispositivo cualquiera por conexión a la red local.
  • Prueba_Concepto_15_4: Detección de la salida de un dispositivo cualquiera por conexión a la red local.

 

Iteraciones referentes a la aplicación de ejemplo que utiliza el framework ANIMuS


 

Iteración 16 - Generación de post-it

El objetivo de este prototipo es leer un fichero de texto y armar del lado del servidor un post-it con el contenido del fichero, el cual quedará disponible para compartir en el espacio de trabajo como si fuera una imagen más.

 

Iteración 17 - Efectos

El objetivo de este prototipo es el agregado de ciertos efectos en la presentación o UI, como por ejemplo el efecto carrusel para navegar entre carpetas, el resaltado de la selección de un ítem de menú o destacar de cierta forma los dispositivos reconocidos (marco iluminado o similar).

 

Iteraciones extra (opcionales)

 

Iteración 18 - Teclado proyectado

El objetivo de este prototipo es incluir a la aplicación un teclado a ser proyectado junto al menú contextual para cada usuario. Se debe incluir un un botón que permitirá ocultar o mostrar el teclado. Mediante este teclado se podrá ingresar el texto de los post-it sin la necesidad de tener un fichero de texto en la carpeta compartida del usuario, lo cual evita la comunicación entre el servidor y los dispositivos del usuario para la generación de estas imágenes (se hace todo del lado del servidor).

Pruebas de concepto y prototipos (I)

Introducción


 

Habiendo definido el objetivo de ANIMuS: a Natural-Interactive Multitouch Surface, el siguiente paso es definir un proceso a llevar adelante de forma que permita mitigar posibles riesgos técnicos y conceptuales que puedan surgir durante el desarrollo a llevar a cabo.  Dichos riesgos son los que consideramos puntos críticos a resolver de forma temprana para poder avanzar con cierta seguridad durante el desarrollo del proyecto.


Para ello, se optó por definir un proceso conformado por cierta cantidad de iteraciones, cada una de las cuales encapsulará un prototipo diferente, resultado de la integración de las distintas pruebas de concepto que se llevarán a cabo durante esa iteración particular. Estas pruebas de concepto serán muy puntuales y lo más sencillas posible, a modo de atacar un posible problema de forma ágil y directa. Luego estas pequeñas pruebas de concepto nos darán paso a la conformación de un prototipo más complejo y completo que las integre en una solución mayor. Finalmente, la integración de estos prototipos irán conformando lo que será el resultado final del proyecto, el framework ANIMuS, que proveerá a las aplicaciones de servicios relacionados con la integración de técnicas de interacción multitáctil y técnicas de interacción gestual, detección e interacción con dispositivos colocados en una superficie, entre otros.

 

 

En resumen, el proceso estará conformado por un conjunto de iteraciones, cada una de las cuales definirá un prototipo a obtener como resultado, entendiendo por prototipo una aplicación que permita mitigar ciertos riesgos de la solución final a desarrollar. A su vez, cada una de estas iteraciones estará conformada por un conjunto de pruebas de concepto, las cuales una vez llevadas a cabo se podrán integrar para conformar un prototipo particular. A medida que se vayan desarrollando prototipos se irá construyendo el framework final a desarrollar como objetivo último del proyecto.


 

Definición de iteraciones



Detallamos a continuación las iteraciones definidas a llevar a cabo en orden de prioridad, y para cada una de ellas las pruebas de concepto a realizar para poder desarrollar el prototipo especificado como resultado de la iteración.

 

 

Las iteraciones se clasifican básicamente en dos categorías:

 

  1. La primera categoría está compuesta por iteraciones que resultan en prototipos que serán luego parte del framework a desarrollar como producto final.
  2. La segunda categoría está compuesta por iteraciones que definen prototipos o funcionalidades deseables a incluir en una de las aplicaciones concretas a desarrollar sobre el framework generado (definida en el post anterior).

 

Cabe comentar que aquellas iteraciones correspondientes a la primer categoría y cuyo prototipo resultante formará parte directa del framework a desarrollar son identificadas como fases, existiendo cuatro de estas fases a lo largo de todo el proyecto, en las cuales se irá construyendo incrementalmente el framework final en base a prototipos resultantes de iteraciones anteriores.


Adicionalmente, algunas de las iteraciones no producen prototipos funcionales en sí mismos sino documentos u otro tipo de salida; en este caso la iteración estará constituida por un conjunto de hitos, los cuales en conjunto permitirán obtener el resultado deseado.

 


Iteraciones referentes al framework ANIMuS


 

Iteración 1: Single-touch

El objetivo de esta iteración es la creación de un prototipo que sea capaz de detectar el punto de contacto de un dedo con la superficie mediante el uso de Kinect. Para esto, las pruebas de concepto a realizar son las siguientes:

 

  • Prueba_Concepto_1_1: Detección de un punto de contacto (cualquiera sea el “objeto” de contacto) sobre la superficie haciendo uso de un Kinect.
  • Prueba_Concepto_1_2: Tracking de un punto de contacto previamente detectado sobre la superficie.
  • Prueba_Concepto_1_3: Detección y tracking de un dedo.

 

Iteración 2: Multi-touch

El objetivo de esta iteración es la creación de un prototipo que sea capaz de extender al resultante de la Iteración 1, logrando identificar el punto de contacto no sólo de un dedo sino de varios, así como también de varias manos. Para esto, las pruebas de concepto a realizar son las siguientes:

 

  • Prueba_Concepto_2_1: Detección de varios puntos de contacto (cualquiera sean los “objetos” de contacto) sobre la superficie haciendo uso de un Kinect.
  • Prueba_Concepto_2_2: Tracking de varios puntos de contacto previamente detectados sobre la superficie.
  • Prueba_Concepto_2_3: Detección y tracking completo de una mano, incluyendo la palma y sus respectivos dedos.
  • Prueba_Concepto_2_4: Detección y tracking completo de varias manos, incluyendo la palma y sus respectivos dedos.

 

Iteración 3 - Definición banco de gestos

El objetivo de esta iteración es la definición de un banco de gestos útiles para el contexto de la oficina del futuro en el que se utilizará el framework a desarrollar. Para esto también es de utilidad tener en cuenta las aplicaciones previamente detalladas en posts anteriores. En este caso los hitos de esta iteración son los siguientes:

 

  • Hito_Diseño_1: Definición de los gestos de tipo 2D necesarios.
  • Hito_Diseño_2: Definición de los gestos de tipo 3D necesarios.
  • Hito_Diseño_3: Definición de combinaciones útiles de los anteriores a incluir.

 

Iteración 4 - Implementación banco de gestos

El objetivo de esta iteración es implementar un conjunto inicial de gestos para el contexto de la oficina del futuro en base a las definiciones resultantes de la iteración anterior. Se seleccionará un gesto para cada tipo a implementar, idealmente el más “complejo” para abarcar el peor caso. Las pruebas de concepto a realizar son las siguientes:

 

  • Prueba_Concepto_4_1: Reconocimiento de un gesto 2D.
  • Prueba_Concepto_4_2: Reconocimiento de un gesto 3D.
  • Prueba_Concepto_4_3: Reconocimiento de un gesto híbrido (multi-touch 2D en combinación con gestual 3D).

 

Iteración 5 - Manipulación de imagen

El objetivo de esta iteración es la creación de un prototipo que sea capaz de manipular un objeto de tipo imagen con los gestos implementados como parte de la Iteración 4. En este caso, las pruebas de concepto a realizar son las siguientes:

 

  • Prueba_Concepto_5_1: Proyectar una imagen obtenida desde el servidor. Tener en cuenta que se debe proyectar únicamente la imagen en caso de que se tenga levantada una aplicación con GUI, es decir, no se quiere proyectar el fondo de la GUI, la ventana, etc.
  • Prueba_Concepto_5_2: Alterar el objeto mediante el uso de cualquier gesto, entendiendo por “alterar el objeto” como cualquier forma de modificación realizada sobre el mismo, ya sea cambiar su tamaño, dibujar sobre él, etc.
  • Prueba_Concepto_5_3: Alterar el objeto reiteradas veces mediante el uso de cualquier gesto. En esta prueba, el sistema debe ser capaz de recordar que el objeto ya fue previamente modificado para cuando ocurra la siguiente alteración.

 

Iteración 6 - Utilización de varias Kinects

El objetivo de esta iteración es mejorar la precisión (disminuir el ruido de las detecciones y aumentar el ángulo de visión) de lo logrado hasta el momento mediante la utilización de varios Kinects dispuestos en diferentes lugares según cierta configuración previamente establecida. Como resultado se desea obtener prototipos similares a los ya obtenidos para las iteraciones 1, 2, y 4 pero en este caso haciendo uso no solo de uno sino de varios dispositivos Kinect.  Las pruebas de concepto a realizar son las siguientes:

 

  • Prueba_Concepto_6_1: Detección de un punto de contacto sobre la mesa haciendo uso de la información obtenida desde varios Kinects.
  • Prueba_Concepto_6_2: Tracking del punto de contacto sobre la superficie haciendo uso de la información obtenida desde varios Kinects.
  • Prueba_Concepto_6_3: Detección y tracking de un dedo haciendo uso de la información obtenida desde varios Kinects.
  • Prueba_Concepto_6_4: Detección de varios puntos de contacto sobre la superficie haciendo uso de la información obtenida desde varios Kinects.
  • Prueba_Concepto_6_5: Tracking de varios puntos de contacto sobre la superficie haciendo uso de la información obtenida desde varios Kinects.
  • Prueba_Concepto_6_6: Detección y tracking completo de una mano, incluyendo la palma y sus respectivos dedos haciendo uso de la información obtenida desde varios Kinects.
  • Prueba_Concepto_6_7: Detección y tracking completo de varias manos, incluyendo la palma y sus respectivos dedos haciendo uso de la información obtenida desde varios Kinects.
  • Prueba_Concepto_6_8: Reconocimiento de un gesto haciendo uso de la información obtenida desde varios Kinects.

 

 

La segunda parte del post aquí.

Interacciones en la oficina del futuro (II)

Lo relevante a ANIMuS


 

Luego de haber planteado el concepto de la ‘oficina del futuro’ y todo lo que sucede dentro de la misma, consideramos que ANIMuS se centrará en la interacción del usuario con distintos  dispositivos que se encuentren en ella, tanto de forma táctil como gestual. En este sentido, ANIMuS tomará el rol del ‘core’, siendo el corazón, de la oficina del futuro en tanto será responsable de la prestación de servicios de interacción dentro de la misma.


ANIMuS no representa en sí misma una aplicación de usuario, sino más bien un ‘framework’ para la creación de diversas aplicaciones. Para ilustrar la capacidad y utilidad de ANIMuS, en nuestro proyecto de grado desarrollaremos distintos prototipos que hagan uso de sus servicios. Dado que nuestro proyecto se encuentra enmarcado en la ‘oficina del futuro’, como mencionábamos anteriormente, es deseable que los prototipos a desarrollar también se encuentren en consonancia con dicha oficina.


Con ANIMuS se podrá interactuar con datos del tipo multimedia, es decir, imágenes, vídeos, música y permitirá además soportar la composición de diagramas colaborativos. Estos diagramas serán utilizados para la generación de la técnica conocida como ‘brainstorming con post-it’, la cual es una forma de brainstorming que ayuda a adecuar la velocidad de generación de ideas mientras se desarrolla la reunión, donde cada miembro escribe una idea por post-it y la expone a los demás para luego ser agrupadas según semejanza y así avanzar en el diagrama. Esta aplicación permitirá al usuario interactuar con la superficie apoyando un dispositivo computador en la misma. De ser posible, se extenderá la aplicación para tener en cuenta otros dispositivos como smartphones, entre otros.

 

El flujo de interacción será el siguiente:

 

  1. El usuario llega y apoya su laptop en la mesa multitáctil y el mismo es reconocido por la oficina proyectando un círculo alrededor de él. Luego de dicho reconocimiento se proyecta al lado del dispositivo un menú contextual que mostrará las carpetas referente a música, imágenes, vídeos y diagramas (posiblemente también post-it).

  2. Seleccionando cada uno de ellos accedemos a los distintos tipos de datos multimedia.

    1. Suponiendo que elegimos el menú referente a música o video mediante técnicas multitáctiles, se desencadena el siguiente flujo:

      • Se proyectan las carpetas conteniendo las diferentes canciones o vídeos.

      • Mediante técnicas gestuales haciendo scroll se puede pasar entre los diferentes álbumes.

      • Mediante otro gesto se puede seleccionar la carpeta y dentro de ella con técnicas multitáctiles seleccionar la canción o vídeo deseado.

      • Luego mediante comandos por voz o táctiles se puede reproducir, pausar, adelantar o rebobinar el video/canción.

      • Haciendo uso de otro gesto se puede rotar el vídeo o reproductor musical.

      • Arrastrando el contenido multimedia en la mesa se puede trasladar a lo largo de ella, pasándolo entre los diferentes usuarios.

      • Mediante otros gestos se puede agrandar o reducir el tamaño del contenedor del video o el reproductor de música.

      • Haciendo un gesto sobre cierto contenido multimedia en dirección a otro dispositivo apoyado sobre la mesa se hará la transferencia del recurso hacia el dispositivo, mostrando una guía iluminada con el estado del proceso de transferencia.

    2. Suponiendo que elegimos el menú referente a diagramas mediante técnicas multitáctiles, se desencadena el siguiente flujo:

      • Se proyectan los diferentes diagramas.

      • Mediante técnicas gestuales haciendo scroll se puede pasar entre los diferentes diagramas.

      • Mediante técnicas gestuales se podrá seleccionar un diagrama de los existentes o crear uno nuevo.

      • Los diagramas están basados en dibujos tipo flechas, círculos, etc. dibujados mediante interacción multitáctil para armar un flujo de ideas, y/o mediante diferentes post-it agregados.

      • Cada post-it es creado en la máquina de los usuarios y arrastrado mediante un gesto a la mesa.

      • Haciendo uso de otro gesto se puede rotar el diagrama.

      • Arrastrando el diagrama en la mesa se puede trasladar a lo largo de ella, pasándolo entre los diferentes usuarios.

      • Mediante otros gestos se puede agrandar o reducir el tamaño del diagrama.

      • Haciendo un gesto sobre cierto diagrama en dirección a otro dispositivo apoyado sobre la mesa se hará la transferencia del recurso hacia el dispositivo, mostrando una guía iluminada con los datos del proceso de transferencia.

 

Prototipado



Se detalló entonces el prototipo a implementar y cómo sería un flujo de interacción típica. En base a este planteamiento se aplicará la técnica de Storyboarding para plasmar las tareas y escenarios de interacción que tendremos en cuenta en nuestra aplicación.

 

Storyboarding

 

Imagen 1: Storyboard parcial de interacción

 

Paper Prototyping

 

Por otro lado, se realiza una primera versión de prototipo inicial haciendo uso de la técnica “Paper Prototyping” para prototipado rápido, con el objetivo de tener un primer acercamiento a cómo sería la interacción real y eventualmente encontrar problemas de usabilidad que obliguen a quitar, agregar o modificar algún punto de la idea original.

Adicionalmente, se aplica de forma conjunta la técnica de “Video Prototyping” con el objetivo de construir un video que permita visualizar el flujo de interacción en base al prototipo en papel generado, el cual será luego evaluado por los potenciales usuarios de la oficina del futuro.


En el siguiente vídeo entonces, se muestran dichas técnicas para una de las dos ideas presentadas para ANIMuS a modo de primer versión.

 

Vídeo 1:  Paper Prototyping y Video Prototyping

 

Implementación y diseño


 

Luego se pasará al desarrollo de los detalles más técnicos de implementación de la propuesta así como también de conceptos específicos, a definir para poder mitigar de forma temprana posibles riesgos técnicos y conceptuales que eventualmente podrían darse.


Para ello, presentaremos en próximos posts las diferentes iteraciones que planteamos, incluyendo un conjunto de pruebas de concepto, para que al final de cada iteración se obtenga un prototipo correspondiente al riesgo que se desea mitigar. Por lo tanto, a partir de estas iteraciones se irá elaborando un diseño más concreto de ANIMuS en cuanto a funcionalidad (servicios ofrecidos) y arquitectura, partiendo de los requerimientos mínimos ya detectados y agregándole cuestiones específicas que surjan como consecuencia del prototipo elaborado en dichas iteraciones.

 

 

 

¿Cómo te imaginas la interacción en la oficina del futuro? ¿Has utilizado técnicas de prototipado para el diseño de interacción? ¡Esperamos tus comentarios!

Interacciones en la oficina del futuro (I)

Contextualización


 

Nuestro proyecto, denominado ANIMuS (A Natural Interactive Multitouch Surface), se enmarca en un proyecto de mayor alcance denominado CUIN (Computación Ubicua e Interacción Natural), el cual consiste en la conformación e implementación de una oficina del futuro en la cual se pueda interactuar de forma natural con la mayoría de los elementos que la conforman. Si bien sabemos que el objetivo de ANIMuS es estudiar la integración de técnicas de interacción natural y multitáctil, debemos evaluar a priori cuál será su rol dentro de la oficina del futuro. Para poder pensar en ello, comenzamos a imaginarnos cómo sería idealmente esta denominada oficina del futuro para luego poner foco en lo referente a la interacción natural con superficies que es donde se centrará nuestro proyecto.

 

¿Qué es la oficina del futuro?


 

La oficina del futuro será un espacio de reuniones provista de diversas tecnologías que harán más intuitiva, flexible y sencilla la interacción entre los distintos participantes de la misma. A tales efectos, brindará facilidades no sólo para la interacción entre personas, sino también entre usuarios y distintos dispositivos así como también entre diferentes dispositivos.


El objetivo es que todos los involucrados encuentren en la oficina una motivación especial para realizar allí sus encuentros o llevar a cabo sus jornadas laborales, sacando el mejor provecho de la misma y facilitando las tareas diarias.

 

 

Aspectos de la interacción a tener en cuenta


 

Dentro de la oficina podrían darse varias forma de interacción según diferentes situaciones que puedan ocurrir dentro de la misma. Algunos aspectos y decisiones a tomar teniendo en cuenta desde el momento previo a que el usuario ingresa a la oficina hasta que la abandona podrían ser los siguientes:

 

Estado anterior a la llegada de usuarios

 

  1. ¿La oficina se encuentra en modo ahorro de energía?
  2. ¿Ocurre un encendido automático de dispositivos según planificación?
  3. ¿Existe posibilidad de encendido remoto de dispositivos mediante aplicación en el celular?

 

Llegada del primer usuario

 

  1. ¿Qué sucede con la iluminación?

  2. ¿Qué sucede con la calefacción?

  3. ¿Cómo encender los dispositivos?

  4. Tiempo de espera de llegada de los demás usuarios:

    • ¿Información referente a la actualidad (noticias) que le sea de interés al usuario mientras no estén todos los participantes de la reunión?
    • ¿Mostrar agenda de la próxima reunión?

    • ¿Mostrar calendario de reservas de la oficina? ¿Notificaciones por alarmas?

  5. ¿Información por comando de voz del estado de la oficina, luces encendidas, temperatura ambiente etc.?

 

Llegada de otros usuarios

 

  1. ¿Informar quién llegó y quién falta?
  2. ¿Informar cuando estén todos los miembros de la reunión?

 

Referente a todos los usuarios

 

  1. ¿Saludo al ingreso de cada miembro de la reunión por reconocimiento facial?
  2. ¿Identificación del usuario antes de entrar a la oficina?

 

Actividades en la oficina

 

  1. ¿Posibilitar llamadas por teléfono?

  2. ¿Permitir la realización de conference calls?

  3. ¿Edición en común de documentos y otros contenidos multimedia?

  4. ¿Mecanismo de intercambio de datos personales?

  5. ¿Agendar próxima reunión?

  6. ¿Elaboración de un proyecto y asignación de tareas?

  7. ¿Elaborar notas y apuntes durante la reunión?

  8. ¿Elaborar esquemas colaborativos?

  9. Visualización de elementos durante la presentación

    • ¿Visualizar en la pared o en escritorio?

    • ¿Visualización de videos, imágenes o diapositivas?

    • ¿Cómo solucionar que unos vean las cosas al derecho y otros al revés?

  10. ¿Transferencia de datos multimedia? ¿Reproducción de música? ¿Reproducción de vídeos?

 

¿Cuál es el flujo de interacción en la oficina?


 

Previo a que el usuario entre a la oficina, la misma estará en estado de ahorro de energía, es decir, que si habían dispositivos encendidos pero que ya no se estén siendo utilizados se pondrán en estado de hibernación. Además, el usuario puede haber planificado el encendido de los dispositivos de la oficina previamente para cierta hora, o bien encenderlos remotamente a demanda mediante una aplicación instalada en su celular que rastree en todo momento los dispositivos reconocidos en la oficina y pueda interactuar con ellos de forma remota.


En el momento en que llega el usuario a la oficina debe autenticarse mediante la lectura de su huella digital para poder entrar a la misma. Una vez autenticado, el usuario ingresa a la oficina y mediante reconocimiento facial la asistente virtual le da la bienvenida.


La oficina tiene la capacidad de detectar la necesidad del encendido de las luces en base a la cantidad actual de luz ambiente. De esta forma la oficina encenderá automáticamente las luces al entrar el usuario en caso de ser necesario. De forma análoga, según la temperatura ambiente y la época del año se graduará automáticamente la calefacción.


El usuario enciende los dispositivos deseados en caso de no estar encendidos, ya sea manualmente o mediante comandos por voz. Mientras tanto, se le muestran las reuniones agendadas para la oficina y las alarmas establecidas de fin de reunión. Los dispositivos u objetos con los cuál se puede interactuar que conforman la oficina serían una pared y una mesa proyectables con las cuales el usuario puede establecer interacción mediante gestos y/o contacto directo con la superficie.


En caso de no estar todos los miembros previstos para la reunión, se proyectará sobre la mesa las noticias relevantes del día que sean de interés para el usuario. Una vez que estén todos los previstos para la reunión dicha información se cerrará para dar comienzo a la reunión establecida.


Por otro lado, esta mesa puede interactuar con el celular o la computadora del usuario. Para esto el usuario apoya su dispositivo sobre la mesa y el mismo es detectado dibujando un círculo de color a su alrededor. Una vez detectado, se despliega un menú con las funcionalidades que brinda el dispositivo compatibles con la oficina. El usuario selecciona una de ellas y luego puede transferir información del mismo a la mesa para así poder compartirla con los otros miembros de la reunión. De esta forma, podría escoger la opción de transferir documentos editables y así ser visualizados así como también modificados por todos los presentes. Luego de concluida la reunión cada participante se podrá llevar una copia del elemento/recurso alterado o generado colaborativamente. Para transferir un archivo compartido, cada usuario realiza un gesto simulando arrastrar el documento hacia su dispositivo para quedarse con una copia del mismo.


Por otro lado, si un usuario comparte un documento que sea una presentación, podría mediante un gesto arrojarlo a la pared para una mejor visualización por parte de todos los miembros y realizar la presentación pasando las diapositivas mediante gestos o comandos por voz.


También mediante la interacción con el celular y en caso de escoger la opción de ver los contactos del teléfono, los mismos se proyectarán en la mesa, pudiendo hacer scroll en la lista de contactos y/o seleccionar uno de ellos mediante interacción multitáctil. Una vez escogido el mismo, se puede establecer una conference call entre dicho contacto y los presentes en la reunión. A su vez, cada miembro de la reunión apoyando su dispositivo y seleccionando la opción de compartir tarjeta personal, podrá transferirla a los demás participantes de la misma forma que se transfiere cualquier elemento mostrado en la mesa, es decir, haciendo un gesto en dirección del dispositivo destino. La información transferida contendrá toda la información de contacto, esto es, número de teléfono, nombre, apellido, dirección de correo electrónico, entre otros datos personales que se hayan configurado previamente como “compartibles”.


Mediante la agenda presente en la sala, arrastrándose para ser proyectada sobre el centro de la mesa de forma que sea visualizada por todos los participantes, se podrá acordar fecha y hora para una nueva reunión, reservando además la oficina para tales efectos. A su vez, cada uno podrá hacerse de una copia de ese evento en la agenda privada de su dispositivo, ya sea celular u ordenador.


Por otro lado, los usuarios podrán compartir imágenes, vídeos y canciones que poseen en sus ordenadores. Para ello elegirán la opción del menú contextual correspondiente, imágenes, vídeos o música. Allí se les desplegarán las carpetas conteniendo dicha información la cual podrán recorrer mediante scroll basados en gestos y seleccionar una de dichas carpetas mediante otro gesto. Las imágenes, como así también, los vídeos podrán ser rotados, extendidos o comprimidos en tamaño mediante gestos específicos y los vídeos como canciones podrán ser reproducidos mediante comandos por voz o gestuales. Adicionalmente, los usuarios podrán realizar marcas sobre los recursos de tipo imagen, pudiendo por ejemplo resaltar partes de una imagen o crear diagramas generales de forma colaborativa mediante multitáctil.


Por otro lado, cada usuario puede escribir post-it notes durante un proceso de brainstorming dejando plasmadas sus ideas sobre la mesa y/o contribuir a la realización de esquemas conceptuales durante la discusión de cierto tema. Además, como ya comentábamos, mediante técnicas multitáctiles los usuarios podrán crear y modificar estos diagramas dibujando círculos, flechas, resaltando secciones y otros elementos de diagramación. Cada usuario participante luego podrá llevarse una copia del diagrama generado, mediante los gestos ya detallados para el copiado de archivos a los diferentes dispositivos. A su vez, se puede especificar nombres en cada post-it que hagan referencia al encargado de la realización de ciertas tareas y así llevar una asignación de las distintas tareas planificadas.

 

 

La segunda parte del post aquí.

Configuración del entorno de desarrollo

Como ya hemos mencionado en el post anterior, para la realización de la primer prueba de concepto en el contexto de nuestro proyecto utilizamos las tecnologías OpenNI/NITE y OpenFrameworks. Como forma de documentar los procesos de configuración llevados a cabo, en este post describimos el conjunto de pasos que seguimos para utilizar estos frameworks dentro del entorno de desarrollo Visual Studio 2010. Adicionalmente, describiremos también los pasos para la configuración de OpenCV (Open Computer Vision) en este mismo IDE, ya que es otra de las tecnologías que utilizaremos durante el desarrollo.

 

 

Lo más sencillo para dejar configurado el compilador y linker en Visual Studio es utilizar lo que se denominan hojas de propiedades, las cuales permiten crear paquetes de reglas para los diferentes modos de compilación, sea Debug o Release, que definen las dependencias y otros elementos referentes a la configuración del proyecto. La ventaja de este mecanismo es que luego estas hojas de propiedades se pueden referenciar y reutilizar desde otros proyectos para dejar así configuradas las dependencias y todos los demás elementos que hayamos incluído, habiendo configurado todo una única vez, siempre y cuando se tengan en cuenta algunas consideraciones, como por ejemplo la de no utilizar rutas relativas en las definiciones sino utilizar siempre variables de entorno previamente definidas, entre otras que detallaremos a lo largo de este post.

 

Las definiciones de hojas de propiedades se realizan en la pestaña “Property Manager” de Visual Studio. En esta pestaña se listan los diferentes conjuntos de reglas que existen actualmente para cada uno de los modos de compilación, Debug y Release. Así, cada vez que se desee configurar en un nuevo proyecto un framework o librería compleja (muchas dependencias) previamente configurada, simplemente se debe agregar la hoja de propiedades correspondiente al conjunto de hojas de propiedades para e(los)l modo(s) de compilación a utilizar. Esto se realiza con la opción “Add Existing Property Sheet” del Property Manager y permite agregar al nuevo proyecto un paquetes de reglas que hayamos definido previamente. Debido a esto, es recomendable tener un respaldo de estos paquetes de reglas en algún lugar a medida que los vayamos definiendo, ya que una vez se definen quedan creados dentro de la carpeta donde está alojado el proyecto Visual Studio en el que fueron definidos (ficheros con extensión .props) y por lo tanto ligados a ese proyecto específico, lo cual implica que si se elimina el proyecto también se eliminarán las diferentes hojas de propiedades creadas.

 

En el documento que se puede descargar desde aquí, se detallan las configuraciones necesarias para cada uno de los frameworks y librerías que mencionábamos al principio del post, teniendo en cuenta que las configuraciones se realizarán en base al uso de hojas de propiedades. Cada una de las secciones incluidas en el documento describe el proceso de instalación del framework en el sistema así como también el de su configuración en MS Visual Studio, resultando en una hoja de propiedades lo suficientemente genérica como para que pueda ser incluída en otros proyectos sin ningún tipo de problemas.

 

 

Si durante todos los pasos que detallamos en las diferentes secciones no hubieron problemas, ¡ya está todo listo para comenzar a desarrollar haciendo uso de los frameworks OpenNI/NITE, OpenFrameworks y OpenCV utilizando Visual Studio como entorno de desarrollo!

 

 

¿Has tenido que configurar estos frameworks?, ¿tuviste alguna dificultad en el proceso?, ¿cómo lo hiciste? ¡Esperamos tus comentarios!

 

Primer prueba de concepto - Integración de tecnologías OpenNI, Kinect y OpenFrameworks (parte II)

Problemas encontrados

 

  • Como ya mencionábamos, algunos de los componentes anteriores los utilizamos de forma más abstracta mediante el addon de OpenFrameworks ofxOpenNI que permite abstraer el manejo de OpenNI/NITE y el dispositivo Kinect. Este es el caso del contexto OpenNI antes mencionado, al igual que los generadores DepthGenerador e ImageGenerator utilizados para obtener el mapa de profundidad y el mapa RGB respectivamente. La razón por la cual utilizamos ofxOpenNI en estos casos fue principalmente debido a que permite visualizar de forma sencilla estos mapas en pantalla mediante la invocación a un único método draw() que implementan los distintos generadores provistos por ofxOpenNI. Esta función, dado el conjunto de pixeles de los mapas, los dibuja en cierta posición de la ventana con cierto tamaño previamente especificado, evitando que el programador deba manipular los pixeles a bajo nivel para mostrarlos correctamente en pantalla. Para los demás generadores a utilizar, GestureGenerator y HandGenerator, en principio se intentó incorporar también los provistos por ofxOpenNI simplemente para unificar el manejo de generadores en dicho addon, pero de esta forma no se logró llevar a cabo de forma satisfactoria ni el reconocimiento de la mano ni el posterior hand tracking.
  • Otro problema que nos ayudó a resolver de forma sencilla el uso del addon ofxOpenNI fue el hecho de que una vez que obtenemos la posición de la mano que está siendo trackeada, debemos convertir esos datos obtenidos en coordenadas de mundo (o más bien coordenadas de sensor) a coordenadas de pantalla para su correcta visualización; en este caso para trasladar la bola seleccionada a la nueva posición en base al tracking de la mano del usuario. La operación que se encarga de esto, permitiendo ahorrarnos todos los cálculos necesarios para realizar la proyección, es ConvertRealWorldToProjective() que se incluye como parte de los generadores de ofxOpenNI. Si no hacemos esta conversión los movimientos realizados con la mano no se mapean correctamente con los movimientos de la bola en pantalla.
  • Algunos problemas que debimos resolver fueron los referente a los callbacks de OpenNI (funciones que implementan la lógica a ejecutar al dispararse cierto evento, por ejemplo el reconocimiento de un nuevo usuario), más específicamente sobre cómo y dónde definirlos para que todo funcione como es esperado. Los mismos deben estar idealmente definidos e implementados de forma global a cualquier clase, en el mismo fichero en el que se realiza el registro de los mismos para los diferentes nodos. Un problema concreto con el que nos topamos relacionado con los callbacks fue que algunos callbacks requerían interactuar con un generador que no estaba en su alcance, y esto no es posible por cómo se deben definir los callbacks (como ya comentábamos, de forma global, no pertenecientes a ninguna clase particular) y debido a que los generadores no fueron definidos globalmente sino como parte de una clase como se puede ver en el diagrama presentado en la Figura 2. Por ejemplo, el callback correspondiente al reconcimiento de un gesto, Gesture_Recognized, debe lanzar el tracking de la mano invocando al método StartTracking() del HandGenerator, indicando que ya se reconoció el gesto y es está en condiciones de comenzar a trackear. El problema puntual, como mencionábamos, se da debido a que al no ser globales los objetos que representan ambos generators, no son visibles en los callbacks según cómo fueron declarados. Se buscaron otras formas de declarar los callbacks para solucionar este problema pero no se tuvo éxito. Así, la solución por la que optamos fue incluir a la solución una nueva clase que se encargue de manejar todo lo referente al hand tracking, e incluya como atributos tanto el HandGenerator como el GestureGenerator. De esta forma, al registrar los callbacks para los diferentes eventos se pasa en el parámetro pCookie la instancia de la clase HandTrackingManager, haciendo que desde los callbacks se tenga acceso a todos los atributos de la misma, incluyendo los necesarios HandGenerator y GestureGenerator. A pesar de que el parámetro pCookie no parece estar para eso, este fue el workaround adoptado para que los callbacks tengan visibilidad tal que abarque nodos a los cuales no están “asociados”, en este caso para que desde callbacks referentes al GestureGenerator se pueda utilizar el HandGenerator y visceversa como es necesario.
  • Otro punto a comentar es que en principio se suponía que para hacer el tracking de una mano bastaba con utilizar en HandGenerator, pero esto no resultó ser así, sino que se debe utilizar el anterior combinado con el GestureGenerator tal como veníamos comentando. Una vez se reconoce un gesto, sí se está en condiciones de enviar la orden de comenzar el tracking de la mano a partir de la posición en la que se detectó, pero no sin haber detectado cierto gesto previamente. Suponemos que esta dependencia entre los generadores se debe a que el hecho de reconocer cierto gesto (por ejemplo, el gesto wave) es quien dispara el proceso de calibración para optimizar el tracking de los movimientos de ese usuario particular. Sólo luego que se tienen las proporciones y medidas de la figura del usuario se está en condiciones de comenzar el tracking.

 

Conclusión


 

Como se puede observar luego de la descripción presentada, la aplicación es muy sencilla y su funcionalidad es bastante limitada. De todos modos, nos fue útil como forma de comprobar que las tecnologías utilizadas pueden interactuar sin problemas, además de tener un primer acercamiento al desarrollo de aplicaciones basadas en NUI (Natural User Interaction) y buscar primeras soluciones a los problemas que pueden surgir con el uso de estas tecnologías.

La idea es utilizar esta aplicación como base para implementar prototipos que nos servirán para mitigar ciertos riesgos, los cuales detallaremos en siguientes posts, expandiendo las funcionalidades de la misma con las nuevas funcionalidades que se deseen probar conceptualmente. A modo de adelanto, algunas de estas funcionalidades son la implementación de multitouch utilizando dispositivos Kinect, el reconocimiento de un dispositivo tipo notebook apoyado sobre un escritorio/mesa o la creación de dibujos/diagramas sobre una superficie de forma colaborativa en base a multitouch y gestos.


 

 

 

¿Has desarrollado alguna aplicación utilizando estas tecnologías (o similares) en conjunto? ¿Te has encontrado con alguno de los problemas que mencionamos? ¡Esperamos que compartas tu experiencia!

Primer prueba de concepto - Integración de tecnologías OpenNI, Kinect y OpenFrameworks (parte I)

Descripción


 

En posts anteriores hemos venido presentado algunas de las tecnologías tanto de hardware como de software que estaremos utilizando para el desarrollo de nuestro proyecto. En este post, describiremos la primer aplicación desarrollada a modo de prueba de concepto con el objetivo de integrar las tecnologías OpenNI/NITE, Kinect y OpenFrameworks.


La aplicación en general es sencilla, y consiste básicamente en interactuar de distintas formas con un conjunto de bolas que se muestran en pantalla. Como veremos, las interacciones podrán ser de dos tipos, o más bien, mediante dos tipos de entradas diferentes; por un lado, interacción básica proveyendo a la aplicación con entrada mediante teclado y mouse (“GUI interaction”), y por otro lado, haciendo uso del sensor Kinect para el reconocimiento de gestos y “hand tracking” (“NUI (Natural User Interface) interaction”). Las bolas actuarán en consecuencia según la entrada provista por el usuario.


Mientras no se interactúe con la aplicación, la misma estará en un estado inicial en el cual simplemente se visualizarán cada uno de los diferentes tipos de bolas. Las mismas se clasifican básicamente en cuatro tipos dependiendo de su comportamiento (Figura 1):

 

  1. Little Ball: pequeña bola de color azul que parece estar cargada eléctricamente, presentando un movimiento de "temblor" constante.
  2. Static Ball: bola de color rosa que presenta la característica de permanecer quieta a menos que se mueva explícitamente.
  3. Annoying Ball: pequeña bola de color rojo que se caracteriza por seguir el puntero del mouse constantemente.
  4. Walking Ball: bola de color amarillo que se traslada constantemente de un extremo al extremo opuesto de la pantalla en forma horizontal.

 

Figura 1: Tipos de bolas en la aplicación de prueba

 

Habiendo presentado los distintos tipos de elementos con los cuales podemos interactuar en la aplicación, pasemos a detallar cómo podemos interactuar con ellos. En lo que respecta a la interacción básica mediante teclado y/o mouse, la aplicación provee las siguientes funcionalidades:

 

  1. Click sobre cualquiera de las bolas hace que la misma se expanda cierta proporción.
  2. Selección de una bola mediante teclado para tomar control de la misma. Las bolas estarán etiquetadas con números y podrán ser seleccionadas individualmente digitando el número correspondiente en el teclado.
  3. Una vez se tiene seleccionada una bola según lo indicado en el paso anterior, la misma se podrá trasladar a una nueva posición utilizando las teclas de dirección W-S-A-D del teclado, haciendo que la misma se mueva hacia arriba, abajo, izquierda y derecha respectivamente.
  4. Deseleccionar una bola previamente seleccionada digitando nuevamente el número correspondiente en el teclado para liberar el control de la misma.

 

Por otra lado, en cuanto a la interacción gestual mediante el sensor Kinect, las funcionalidades provistas por la aplicación son las siguientes:

 

  1. Reconocimiento de un usuario mediante el gesto “Wave”, debiendo realizar un saludo con cualquiera de las manos en alto de cara al sensor.
  2. Una vez reconocido un usuario en la escena, éste tendrá control sobre la bola seleccionada, es decir que, en caso de existir una bola seleccionada se moverá en base a los movimientos de la mano del usuario hasta que sea deseleccionada.


Para ilustrar los puntos que comentábamos antes, en el Vídeo 1 se puede apreciar la aplicación en funcionamiento.

 

Vídeo 1: Vídeo de prueba de concepto

 

Detalles técnicos


 

En esta sección describiremos algunos detalles técnicos de la aplicación desarrollada y ciertos problemas que surgieron durante su desarrollo junto a la solución encontrada.


A grandes rasgos, la estructura general de la aplicación se puede observar en la Figura 2, la cual permite visualizar los diferentes componentes que conforman la aplicación y a los cuales nos referiremos en lo que resta del post:

 

Figura 2: Diagrama de clases de la aplicación


 

Por otro lado, recordemos del post anterior en el cual hablábamos de OpenFrameworks, que cualquier aplicación que utilice este framework tiene una estructura bien definida dada por los métodos setup(), update() y draw() que se ejecutan en ese orden (setup() una única vez, mientras que los restantes ejecutan secuencialmente en un loop). Pasemos entonces a detallar a grandes rasgos cuál es la lógica que se ejecuta para este caso en cada uno de los métodos anteriores.


En el método setup() se realizan varias acciones importantes:

 

  • Se instancian los diferentes tipos de bolas que conformarán la escena, inicializando ciertos parámetros obligatorios como tamaño, posición inicial y color.
  • Se inicializa el contexto OpenNI, componente principal que se encarga de mantener en todo momento el estado completo de la aplicación OpenNI, entendiendo por estado todos los módulos (sensores y componentes middleware) registrados en el framework y los “Production Nodes” utilizados por la aplicación (generadores de mapas de profundidad, mapas RGB, etc). El contexto debe ser incializado una única vez antes de poder utilizar cualquier componente del framework. Cuando se inicializa, todos los módulos registrados son cargados y analizados para su posterior uso.
  • Se setea la propiedad “Mirror” del contexto en verdadero para hacer que los frames se espejen una vez obtenidos. Esto es útil cuando el sensor se coloca enfrente al usuario, ya que hace que la mano derecha del usuario se visualice a la derecha en los mapas obtenidos mediante OpenNI, la mano izquierda a la izquierda, etc.
  • Se inicializan los nodos OpenNI a utilizar. Para esta aplicación los nodos utilizados son básicamente cuatro: DepthGenerator para la obtención del mapa de profundidad de la escena, ImageGenerator para la obtención del mapa RGB de la escena, GestureGenerator para el reconocimiento de gestos y HandsGenerator para el reconocimiento y tracking de una mano. En este punto, todos los generadores ya quedan configurados y generando datos a ser luego consumidos por la aplicación en cada nuevo frame. Cabe comentar que los primeros dos generadores se utilizaron encapsulados mediante el addon ofxOpenNI por ciertas razones que detallaremos más adelante, mientras que los restantes son los nativos de OpenNI y son utilizados como tales, aunque su inicialización y uso está encapsulado en la clase HandTrackingManager incluida en el diagrama de la Figura 2, la cual se encarga de gestionar todo lo referente al “hand tracking” (trackeo de la mano).

 

Luego, en el método update() que se ejecuta previo a dibujar cada frame, se realizan las siguientes tareas:

 

  • Se verifica si se está trackeando una mano mediante el método isBeingTracked() del objeto que representa la mano del usuario y en caso afirmativo se actualiza la posición de la bola actualmente seleccionada (si es que existe) según la posición actual de la mano.
  • Para las demás bolas simplemente se actualiza la posición según el método move() para implementar el movimiento de ese tipo de bola particular.
  • Se actualiza el contexto y los generadores para obtener nuevos datos a procesar en el siguiente frame.

 

Finalmente, en el método draw(), ejecutado para dibujar cada frame, se llevan a cabo las acciones siguientes:

 

  • Se dibuja cada una de las bolas según los datos de estado que posea en ese momento (posición, color, etc.) mediante el método draw() implementado por la bola.
  • Se dibuja el mapa de profundidad y el mapa RGB simplemente invocando la operación draw() del componente ofxOpenNI que los representa, especificando previamente una posición en la cual dibujarlos y un tamaño para cada uno de ellos.

 

 

Se puede acceder a la continuación de este post desde aquí.

Kinect Guidelines: consejos para el diseño (III)

Pistas en la interacción: tener una buena retroalimentación

Como se ha mencionado anteriormente, proporcionar una buena retroalimentación es fundamental en este estilo de interacción para que los usuarios puedan sentir que tienen el control y además ayudarles a entender lo que realmente está sucediendo, sobre todo si están de pie y a cierta distancia de la interfaz. Por lo tanto, es importante tener especial cuidado en mostrar las acciones que se van emitiendo a la aplicación y las reacciones de la misma.

 

Retroalimentación del seguimiento esqueletal

Partiendo de lo más básico, un gesto sólo es eficaz y fiable cuando el usuario está en el rango correcto de visibilidad del sensor. Es importante además que el usuario sepa con certeza si Kinect está efectivamente viéndolo o no. Por esta razón, es importante brindar la retroalimentación adecuada para ayudar a contestar las siguientes preguntas:

 

  • ¿El sensor Kinect está listo?
  • ¿Cuánto es capaz de ver Kinect?
  • ¿Qué parte del usuario puede ver?
  • ¿Dónde está el campo de vista de Kinect?
  • ¿A cuántas personas puede ver?
  • ¿Cómo sé que me está viendo a mí y no a otra persona?
  • ¿Estoy con el control? ¿Puedo saludar ahora?
  • ¿Cuándo y dónde puedo realizar un gesto?

 

 

Figura 10: Técnicas de retroalimentación para el seguimiento esqueletal.

 

Algunas técnicas para brindar retroalimentación de este tipo son las ilustradas en la Figura 10.

 

  • Cuadrante I: La aplicación muestra dónde pararse para que el seguimiento sea óptimo.
  • Cuadrante II: Realizar movimientos suaves para evitar aquellos nerviosos que no se asemejan a los movimientos naturales de las personas.
  • Cuadrante III: Retroalimentación de tipo espejo. Asegurarse que las acciones se realicen en tiempo real, si no el usuario supondrá que no tiene el control.
  • Cuadrante IV: Predicar con el ejemplo. Si se quiere que el usuario copie un movimiento o acción se puede mostrar un avatar o una animación ya sea antes o durante el tiempo que se espera que el usuario realice dicho movimiento. En caso de mostrarse durante, es apropiado encontrar alguna forma visual de indicar en tiempo real si lo están haciendo bien o no.
  • Cuadrante V: Mostrar una pequeña ventana de profundidad donde visualizar qué es lo que realmente Kinect puede ver en un momento dado. Esto puede ayudar a entender cómo mantenerse en el rango correcto y por qué las cosas no funcionan cuando se está fuera del mismo.

 

Otras formas básicas de retroalimentación visual

 

1. Dejar en claro qué es procesable y como accionarlo

Utilizar iconografía, colores o tutoriales para mostrar a los usuarios cómo diferenciar entre los controles que pueden accionar, los textos y contenidos editables. También se pueden utilizar elementos de este tipo para mostrar los métodos de entrada disponibles para el usuario y qué gestos están disponibles en un momento dado. Otra práctica útil es, si se esta trackeando la mano, mostrar siempre un cursor que permita visualizar el seguimiento.

 

2. Mostrar qué se está “sobrevolando” y qué está seleccionado

Utilizar el color, la inclinación, los cambios de orientación, tamaño o contenido en sobrevuelo (cuando el usuario tiene control de la interacción, por ejemplo su mano está siendo trackeada, pero no está interactuando con ningún elemento particular de la aplicación, pero si posicionándose encima) y selección para proporcionar información al usuario acerca de qué elementos son seleccionables y en qué estado se encuentran.

 

Figura 11: Ejemplo de retroalimentación para el sobrevuelo y selección de un objeto.


3. Manipulación directa de objetos

Si se permite a un usuario controlar ciertos elementos con manipulación directa sería recomendable mostrar el progreso de manera que se traduzca en el movimiento del usuario. Por ejemplo, si el usuario pasa la página de un libro con un gesto, mostrar la página tirando hacia arriba y dándose vuelta cuando el usuario mueve su mano en sentido horizontal.

 

Figura 12: Ejemplo de retroalimentación para la manipulación directa de un objeto: girar una página.

 

4. Progreso

También puede ser útil mostrar el grado de progreso para realizar la selección de un elemento, sobre todo para evitar que la aplicación parezca estar detenida. Es importante elegir tiempos que no frustren al usuario debido a una acción demasiado larga o cansadora. Si para mostrar el grado de progreso se está utilizando un contador de tiempo o una cuenta atrás, es necesario utilizar elementos visuales claros para demostrar la progresión real.

 

5. Animación

La animación es una gran manera de ayudar a los usuarios a mantenerse en su contexto. Una animación puede ayudar, por ejemplo, a mostrar donde se reubica un contenido que se estaba viendo en cierto lugar cuando hay un cambio de diseño (debido a un gesto o por el mismo flujo de la aplicación). También es útil utilizar la animación para ayudar al usuario a entender el diseño en caso de que el usuario se encuentra navegando.

 

 Figura 13: Ejemplo de retroalimentación tipo animación. Arriba: reubicación de un contenido durante un cambio de diseño. Abajo: animación durante transición de objetos.

 

Retroalimentación auditiva

 

1. Conseguir la atención del usuario

El audio puede ser una buena manera de llamar la atención de los usuarios si tienen que ser notificados de algo. Los patrones de sonido o señales, como pueden ser alertas o advertencias, se pueden utilizar como una forma de comunicar un mensaje simple o enseñar a los usuarios cuándo es necesario que presten mayor atención.

 

2. Estados de sobrevuelo o selección

Los sonidos pueden ser una buena manera de indicar a un usuario de que algún elemento ha cambiado o pasó a otro estado. El uso de los sonidos que responden a la acción que el usuario está tomando pueden ser útiles entonces para hacer valer su sensación de control y la familiaridad. Por ejemplo, reproducir el sonido de las teclas al introducir texto.

 

3. Comentarios de audio basados en la orientación del usuario

Si el usuario no está frente a la pantalla, o está muy lejos, se podría considerar el uso de audio como una forma de comunicarse con ellos. Por ejemplo, las opciones disponibles para ellos, las direcciones o instrucciones, alertas, etc.

 

Aplicaciones con múltiples usuarios

Otra característica que Kinect ofrece es la posibilidad de realizar un seguimiento de varios usuarios. Esto abre una puerta para algunas interacciones interesantes que involucran colaboración entre los usuarios, así como algunos nuevos desafíos en torno al control y los recursos.

 

1. Capacidad de seguimiento para varios usuarios

Kinect puede reconocer hasta seis personas, y se puede realizar un seguimiento de dos de ellos de forma simultánea. Para los dos esqueletos para los cuales se realiza el seguimiento, Kinect devuelve información completa de sus articulaciones, mientras que para los restantes esqueletos, Kinect devuelve sólo cierta información útil especificando el perfil del jugador, y una posición de centro. La aplicación puede elegir a cuál de los seis jugadores  se debe realizar el seguimiento del esqueleto completo.

 

 

Figura 14: Detección de múltiples usuarios por Kinect.


2. Varios usuarios y distancia

Se debe tener en cuenta cómo la distancia afecta la cantidad de personas que puede estar físicamente en el rango de visión. Los números recomendados para interactuar cómodamente con la aplicación o al menos ser detectado por la misma, se corresponden a lo siguiente según la distancia del usuario al sensor:

 

  • Modo táctil (de 0 a 0,4 metros): detección de 0 personas
  • Modo cerca (de 0,8 a 2 metros): detección de 1 o 2 personas
  • Modo lejos (de 2 a 4 metros): detección de 1 a 6 personas
  • Fuera de rango (más de 4 metros): detección de 0 personas

 

3. Varios usuarios y colaboración

Tener una aplicación que soporte varios usuarios significa que se pueden tener muchas combinaciones de los usuarios a diferentes distancias. Dependiendo del modelo de colaboración, hay algunas consideraciones importantes que deben ser realizadas para la buena gestión de todos los usuarios en la escena.

 

  • Las interacciones de colaboración: En las interacciones de colaboración, los usuarios están interactuando con el mismo espacio de pantalla y dispositivos. Esto significa que cualquier acción tomada por un usuario afectará el estado de la solicitud de todos los usuarios. Hay dos opciones para el control de equilibrio en este caso:

 

  • Modelo de controlador único: este modelo asigna a uno de los usuarios como el "conductor" en un momento dado y sólo registra las medidas adoptadas por ese usuario. El papel de conductor puede seleccionarse o transferirse de varias formas, por ejemplo mediante la elección manual del usuario a tomar este rol o mediante la selección automática del conductor en base al usuario que esté más cerca del sensor. Esta es una manera de evitar conflictos entre entradas. Este modelo se suele indicar por imágenes que muestran qué persona está siendo rastreada y por un único cursor en la pantalla en cualquier momento.

 

  • Modelo de igualdad de participación: este modelo registra los aportes de todos los usuarios, a menudo simplemente en el orden que se les da. Este puede ser un modelo muy complejo para navegar o para realizar interacciones básicas, pero funciona muy bien para situaciones en las que cada usuario tiene una experiencia única de conducir, como en los juegos.

 

Figura 15: Modelos de participación para interacciones colaborativas

 

  • Las interacciones de “no colaboración”: Las interacciones de “no colaboración” dan a cada usuario su propia experiencia dentro de la interfaz, lo cual puede ser manejado por ejemplo con pantalla subdividida. En general, esta experiencia se comporta más como una experiencia de usuario única, sin embargo, algunos retos adicionales que se presentan son la correcta detección del habla del usuario y las acciones de la interfaz correspondiente. Los comandos de voz pueden resultar un desafío, y los gestos y el movimiento deben tener una retroalimentación visual de cada usuario por separado.

 

Figura 16: Modelo de participación para interacciones no-colaborativas: partir pantalla



 

 

¿Has utilizado alguno de estos consejos en tus aplicaciones? ¡Nos encantaría que compartas tu experiencia!

 

 

 

Referencias


[1] Kinect for Windows - Human Interface Guideline: http://go.microsoft.com/fwlink/?LinkID=247735

Último acceso: 16 de Agosto de 2012

Kinect Guidelines: consejos para el diseño (II)

6. Diseñar para que la aplicación sea fiable

 

La fiabilidad, es decir, que la tasa de error (entender un gesto por otro o saltarse gestos realizados por el usuario) sea baja, debe ser la prioridad número uno. Sin ella, la aplicación se tornará difícil de usar haciendo que los usuarios se sientan frustrados. Además, si la fiabilidad es pobre probablemente sucederá que los usuarios busquen utilizar otros tipos de mecanismos de entrada/interacción.

 

Por esto, tratar de encontrar el equilibrio de una buena fiabilidad es clave y esto se verá afectado por el diseño del gesto. El justo equilibrio considera la frecuencia y el costo de las activaciones falsas.

 

Si el gesto es demasiado rígido, no habrá activaciones falsas, pero puede ser difícil de realizar y los usuarios tienden a rechazarlo. Por otro lado, si el gesto es demasiado flexible, será fácil de realizar, pero puede tener demasiadas falsas alarmas y/o conflictos con otros gestos.

Cabe comentar además, que si los usuarios entienden cómo realizar efectivamente un gesto, pueden enseñar a otros como realizarlo y sabrán utilizarlo en contextos similares a través de la interfaz.

 

7. Diseñar conjuntos fuertes de gestos

 

Se recomienda que se mantenga un número pequeño de gestos utilizados en la aplicación, tanto para que sea fácil de aprender y recordar por los usuarios como para que sean lo suficientemente distintos entre sí para evitar colisiones entre los mismos. Además, es deseable que haya coherencia con otras aplicaciones, ya que esto ayudará a que los usuarios se sientan familiarizados y se reduzca la cantidad de gestos que tienen que aprender y la formación que se tiene que ofrecer.

Algunas características de importancia a tener en cuenta al definir un conjunto de gestos son las siguientes:

 

  • Asegurarse de que los gestos similares utilicen la misma semántica. Por ejemplo, si un golpe fuerte a la izquierda lleva a una dirección, es deseable que un golpe fuerte a la derecha lleve a la otra.
  • Cuando se deseen realizar gestos muy diferentes, es recomendable que las diferencias sean evidentes, bien marcadas, como forma de reducir los falsos reconocimientos y evitar la duplicación. Algunos casos concretos se pueden observar en la Figura 5.
  • No sobrecargar el usuario con gestos para recordar. La investigación ha demostrado que los usuarios sólo pueden recordar hasta 6 gestos promedio de forma satisfactoria.
  • Observar y utilizar los gestos ya existentes que se han establecido en otras aplicaciones haciendo uso de Kinect.
  • Testear a fondo para evitar lo más posible falsas activaciones positivas entre los gestos.
  • Tener en cuenta el escenario completo, esto es, plantearse respuestas a preguntas como: ¿qué deberá hacer el usuario después de completar un gesto?, ¿puede que se vea como el inicio de otro gesto involuntario?.
  • También se puede agregar “tiempo muerto”, donde se ignoran todas las entradas inmediatamente luego de un gesto para permitir al usuario restablecerse a una posición neutral antes de iniciar la siguiente acción.
  • Cada gesto en el conjunto de gestos de una aplicación debe sentirse relacionado y coherente.

 

Figura 5: Se recomienda diferenciar drásticamente los diferentes gestos. Algunas mejores y peores opciones: a la izquierda de cada cuadrante lo recomendable y a la derecha situaciones no deseables. Arriba izq: cambio de dirección. Arriba der: progresión del gesto. Abajo izq: diferenciar puntos de comienzo y fin. Abajo der: tiempos de completitud

 

8. Manejar elegantemente los gestos que se repiten.

 

En ocasiones los usuarios quieren o necesitan llevar a cabo un cierto gesto repetidas veces, por ejemplo, múltiples golpes para ir rápidamente a través de varias páginas o diapositivas de contenido. En este sentido, no siempre diseñar la interacción permitiendo realizar gestos repetidos la hace ineficaz. Otras características a considerar son las siguientes:

 

  • Diseñar el gesto opuesto, que se asemeja a la "vuelta" del primer gesto.
  • Los gestos que se repiten deben ser diseñados de manera fluida, sin arranques ni detenciones bruscas.

 

9. Evitar los gestos para una mano específica

 

Este tipo de gestos, los que se pueden realizar únicamente con una mano específica (derecha o izquierda), poseen una pobre accesibilidad y son difíciles de detectar. Por esto, la recomendación es diseñar los gestos para que puedan ser realizados con cualquiera de las dos manos de forma indistinta. Esto ayuda a evitar la fatiga del usuario, que tiende a intercambiar la mano, evitar que el usuario deba memorizar con qué mano realizar un determinado gesto y además resulta más apropiado tanto para usuarios diestros como zurdos. Esta recomendación también es útil ya que.

 

10. Elegir entre gestos de una mano o de ambas manos

 

Los gestos con una sola mano son altamente preferibles por el hecho de mejorar la eficiencia y accesibilidad. Por esto, es importante que lo gestos realizados con las dos manos no sean gestos ni frecuentes ni utilizados para tareas críticas. En caso de ser necesarios, los mismos deben ser simétricos ya que son más fáciles de realizar y recordar.

 

11. Evitar la fatiga del usuario

 

Si el usuario se cansa, probablemente bajará su rendimiento y se sentirá frustrado implicando que tenderá a cerrar la aplicación debido a la mala experiencia.

Existen algunos gestos que es sabido aporta a la fatiga del usuario, como por ejemplo la repetición excesiva de un solo gesto, el scroll de una página a través de una larga lista, mantener el brazo arriba o abajo para desplazarse a través de una lista vertical, entre otros. Es interesante entonces ofrecer alternativas, por ejemplo listas de navegación (pasos pequeños/grandes), hacer zoom in/out, la reducción de la lista o filtros sobre la misma.

 

12. Tener en cuenta la postura del usuario y los rangos de movimiento

 

Con el fin de considerar dónde y cómo los usuarios van a utilizar la aplicación, es necesario considerar su postura para el diseño de un gesto. No es lo mismo una posición sentada, en cuanto a las limitantes que impone en los movimientos del usuario, que una posición de pie. Hay que tener en cuenta los rangos normales y por sobre todo cómodos de interacción para el cuerpo humano en las distintas posiciones.

 

Otra consideración importante es ser conscientes de que no es lo mismo que el usuario se encuentre de frente o esté de lado al sensor, ya que los distintos puntos de vista alteran el seguimiento del esqueleto.

 

13. Enseñanza y descubrimiento de los gestos

 

Para cada gesto disponible como una forma de interactuar con el sistema, es preciso encontrar la manera de comunicarlo al usuario. Algunas formas de realizar esto pueden ser un tutorial rápido para nuevos usuarios, una imagen estática, una animación o una señal visual cuando el usuario entra en contacto por primera vez o durante toda la interacción.

 

Es importante usar un método adecuado según el gesto que se está intentando que el usuario aprenda. En caso que el gesto sea estático, es preferible utilizar una imagen estática, mientras que si el gesto es dinámico, probablemente sea más apropiado utilizar o bien un movimiento o una animación para ilustrarlo.

 

Figura 7: Ejemplo de cómo enseñar un gesto estáticos o dinámicos


14. Ser conscientes de los obstáculos técnicos

 

Si para definir los gestos se hace uso de los datos del esqueleto del usuario, hay que tener en cuenta sus limitaciones y cuando los mismos han de ser menos fiables. En la Figura 8 se puede visualizar distintos tipos de obstáculos a tener en cuenta y los mismos son los siguientes:

 

  • Cuadrante I: Los movimientos de brazos a los lados del cuerpo son más fáciles de seguir mientras que los movimientos en la parte frontal pierden fiabilidad.
  • Cuadrante II: A menos que el campo de visión de Kinect esté configurado para detectar por encima de la cabeza, los gestos de este tipo probablemente no sean reconocidos.
  • Cuadrante III: Hay 20 articulaciones que se pueden seguir para el modo por defecto (parado) y 10 para el modo sentado, ninguna de las cuales incluye los dedos de las manos.
  • Cuadrante IV: El tracking esqueletal es más estable cuando el usuario se encuentra de cara al sensor.
  • Cuadrante V: Para gestos muy rápidos debe considerarse la velocidad de rastreo y fotogramas por segundo.

 

Figura 8: Posibles dificultades técnicas a tener en cuenta

 

15. Mantener al púbico objetivo en mente

 

Independientemente de cómo se definen los gestos, se debe mantener al público objetivo en mente de modo que los gestos se adecuen para los rangos de altura requerida y las habilidades cognitivas de los usuarios. Pensar en toda la gama de distancias en que los usuarios puedan estar, los ángulos que los usuarios pueden plantear, y los rangos de altura de los grupos de usuarios.

 

Por ejemplo, si la aplicación va a ser utilizada por adultos y niños, se deberá soportar varias alturas y longitudes de las extremidades. Los niños suelen hacen movimientos muy diferentes a los adultos para la una misma acción debido a las diferencias en su destreza y control, y tienden a hacer los movimientos más rápidos y “exagerados” en comparación con los adultos.

 

Figura 9: Consideraciones de rangos de movimiento dependiendo si son usuarios adultos o niños


16. Parametrizar e iterar

 

Es importante diseñar los gestos de forma iterativa y paramétrica, a los efectos de poder realizar ajustes y testeo con usuarios de forma más sencilla y así obtener resultados más apropiados.

Kinect Guidelines: consejos para el diseño (I)

Las interacciones e interfaces construidas con Kinect pueden generar experiencias “mágicas” para sus usuarios. La “magia” y el deleite de Kinect aparecen cuando el usuario sabe cómo utilizar la interfaz y se siente cómodo al hacerlo. El desarrollo de una interfaz de usuario táctil natural con Kinect es el comienzo de una revolución que da forma a la manera de  experimentar e interactuar con las aplicaciones de software.

Para esto, Microsoft en su liberación 1.5 del kit “Kinect for Windows”, proporciona un documento con pautas y consejos a la hora de diseñar interacciones e interfaces para aplicaciones utilizando este dispositivo, respondiendo a las lecciones aprendidas de Microsoft de modo que los nuevos desarrolladores tengan la posibilidad de evitar una serie de problemas y malas decisiones.


En lo que a ANIMuS respecta, nosotros hemos de utilizar este dispositivo, y por tanto, todo conocimiento existente, y más aún siendo de la propia fuente, es tenido en cuenta y bien valorado.


A continuación realizaremos una síntesis del documento “Human Interface Guidelines” prestando especial atención a cuestiones aplicables a nuestro proyecto.

 

Principios de diseño


 

Antes de comenzar a examinar los tips para el diseño de interfaces que involucran la utilización de Kinect, se plantean en el documento los siguientes principios catalogados como básicos, para que los desarrolladores pisen terreno firme.

 

  • Las mejores experiencias de los usuarios son conscientes del contexto

    Por lo tanto, los diseños también deben tener en cuenta el contexto. En este sentido, la interfaz debe adaptarse a la distancia entre los usuarios y el Kinect. La misa debe responder también al número de usuarios y a la participación de ellos con el sistema. A su vez, la colocación de los controles debe ser diseñado en base a los movimientos del usuario o las acciones previstas

 

  • Los usuarios seguros de sí mismos son usuarios felices

    Es importante mantener las interacciones simples y fáciles de aprender y dominar. Para aumentar la confianza del usuario, es aconsejable utilizar combinaciones de entrada, tales como son por voz y gestos. Se debe intentar en los posible no malinterpretar la intención del usuario. Por otro lado, se debe dar una retroalimentación constante para que los usuarios siempre sepan qué es lo que está pasando y qué pueden esperar que suceda

 

  • Cada método de entrada tiene sus ventajas y sus desventajas

    Los usuarios normalmente podrán elegir qué entrada utilizar, lo que se traduce en el esfuerzo, por lo general, para un escenario determinado. Los usuarios tienden a adherirse a una sola entrada cuando no se ha dado una razón lo suficientemente importante como para cambiar. Es por esto que, los diseños deben ser confiables, consistentes y convenientes, ya que de lo contrario los usuarios buscarán opciones alternativas. Si existen varios tipos de entrada, los cambios de una a la otra deben ocurrir de forma natural, o en los puntos naturales de transición en el escenario

 

  • Los diseños más fuertes vienen después de las pruebas de usuario

    Kinect permite una gran cantidad de nuevas interacciones, pero también nuevos retos. Es especialmente difícil adivinar lo que funcionará y lo que no antes de tiempo. A veces, pequeños ajustes a lo largo del proceso de diseño pueden hacer una gran diferencia. Ayuda a conseguir un buen producto entonces, realizar pruebas de usuario con frecuencia y de forma temprana, y planear tiempo para múltiples ajustes al diseño original.

Mejores prácticas para el diseño de gestos


 

Una extensa sección de este documento se encarga de brindar una introducción a los tipos de gestos existentes y proporcionar una serie de consejos a tener en cuenta a la hora de diseñar nuevos tipos de gestos para una interacción de este estilo.

 

Un acercamiento a los gestos

 

  • Dinámicos, continuos, estáticos: Como se muestra en la Figura 1, los gestos se pueden categorizar en tres clases distintas.

 

Figura 1: Arriba izq: gesto estático. Arriba der: gesto continuo. Abajo: gesto dinámico

 

  1. Gestos estáticos: son aquellos para los cuales el usuario debe mantener una posición hasta que ésta sea reconocida. En este tipo de gestos, hay que prestar especial atención en cuáles son las posturas elegidas y a qué público apunta, debido a que un mismo gesto puede tener diferentes significados en distintas culturas.
  2. Gestos dinámicos: son los que brindan retroalimentación al usuario antes, durante o después de realizar un movimiento definido.
  3. Gestos continuos: son aquellos que trackean al usuario a medida que se mueven frente al sensor.

 

  • Innatos y aprendidos: Los gestos también pueden clasificarse según sean del tipo innatos o aprendidos.

 

  1. Gestos innatos: son los que el usuario sabe intuitivamente, tienen su base en como es la comprensión del mundo a través del usuario.

  2. Gestos aprendidos: son los que, con el fin de saber cómo usarlos para interactuar con el sistema, el usuario debe ser enseñado.


Figura 2: Izq: gesto innato. Der: gesto aprendido

 

Los gestos y el diseño de interacción

 

El diseño de las interacciones gestuales es un problema relativamente nuevo que Kinect ha permitido experimentar y comenzar a entender. A continuación, se presentan algunas de las conclusiones y consideraciones clave que Microsoft ha detectado para hacer de sus diseños de gestos una componente de interacción “mágica”.

 

1. Seguir los principios de los gestos

 

Los usuarios deben estar de acuerdo con las siguientes afirmaciones, ya que utilizan el componente gestual en sus aplicaciones:

 

  • Soy capaz de aprender rápidamente todos los controles básicos.
  • Una vez que me entero de un gesto, puedo realizarlo rápidamente y con precisión.
  • Me encuentro ergonómicamente cómodo con los gestos.
  • Cuando realizo un gesto, el sistema es sensible y proporciona retroalimentación continua.

 

2. Diseño adecuado para la mentalidad del usuario

 

Las personas suelen asociar a menudo Kinect con juegos, pero cuando se está diseñando para aplicaciones de propósito general hay que recordar que la “mentalidad del juego” no es la misma “mentalidad que la de la interfaz de usuario”. Si un usuario con mentalidad de interfaz de usuario no puede realizar un gesto, entonces se sentirá frustrado y tendrá una baja tolerancia para cualquier curva de aprendizaje.

Además, en la mentalidad de interfaz de usuario un gesto calificado como “tonto” llega a ser considerado como torpe o no profesional, mientras que, en mentalidad de juego es una acción considerada hasta divertida.

 

3. Diseñar interacciones naturales

 

Tratar de no forzar la forma de entrada (gestual) en otra forma de entrada de una interfaz de usuario ya existente, siguiendo uno de los principios de diseño antes mencionado. Por ejemplo, suponiendo una interfaz táctil, simplemente asignar gestos para cada uno de los tipos de entrada táctil.

Los gestos pueden proporcionar un método novedoso de interactuar con la aplicación, pero se debe tener en cuenta que su uso debe tener un propósito definido. Hay que recordar especialmente los siguientes puntos:

 

  • La situación requiere que los usuarios interactúen a cierta distancia.
  • Los gestos permiten una interacción que otros dispositivos de entrada no pueden lograr.
  • Es bueno centrar parte o incluso la totalidad de la interacción en los gestos innatos, ya que son más naturales para el usuario y se suelen sentir más "mágicos".

 

Figura 3: Buenas y malas prácticas:

Arriba izquierda: No forzar una entrada de gestos en otra de una interfaz ya existente.

Arriba derecha: buscar la mejor y más natural manera de que varios usuarios interaccionen. Abajo izquierda: tener en cuenta la distancia a la que el usuario se encuentra naturalmente. Abajo derecha: buscar gestos innatos, no transformar el escenario en uno touch.

 

4. Determinar la intención y participación del usuario

 

La determinación de la intención del usuario es el desafío más importante, y es un problema muy difícil de resolver. A diferencia de otros dispositivos de entrada, el usuario está siempre activo.

 

Parte del hecho de determinar la intención del usuario es tratar de reconocer cuándo los usuarios desean interactuar con el sistema. Para algunos escenarios puede ser deseable que el sistema esté siempre escuchando y observando, permitiendo a los mismos indicar de forma explícita cuándo quieren comenzar a interactuar con gestos y/o voz. Esto ayudará a evitar reconocimientos de gestos innecesarios, denominados comunmente falsos positivos. Si el usuario activa el sistema, debe darse lugar a la interacción, la cual debe ser claramente visible o haber sido demostrada en algún momento de la experiencia de usuario frente al sistema.

 

Pedir que el usuario realice el gesto de saludo, que como vimos en post anteriores es el  gesto “Wave”, es un método que Microsoft ha utilizado y probado ampliamente, encontrándose como una forma positiva de determinar la intención a interactuar del usuario. Para que este gesto sea reconocido, los usuarios están obligados a agitar su mano hacia la izquierda y hacia la derecha por lo menos tres veces rotando en el codo (no es un gesto innato, sino un gesto natural que no es a menudo malinterpretado).

 

Figura 4: Gesto de saludar “wave”

 

Otras maneras de reconocer la intención de interactuar son por la distancia del usuario al sensor, la dirección con la cual el usuario se enfrenta, el número de personas visibles o mediante la detección de cierta pose.

También se puede optar por reconocer cuando un usuario se desconecta con una forma explícita en lugar de tener un método pasivo de tiempo de espera o de otro tipo. Por ejemplo, cuando un usuario da la espalda a la pantalla se puede considerar como una señal de que ya no está queriendo interactuar con el sistema.

En definitiva,  para poder determinar de la mejor manera la intención y participación del usuario se deberían seguir los siguientes lineamientos:

 

  • Que los usuarios dispongan de una forma clara y simple de comenzar y terminar de interactuar con el sistema.
  • Que los gestos o interacciones reconocidos sean un movimiento único y con un propósito definido.
  • Que los movimientos naturales del cuerpo, que para el usuario es dificultoso evitar, no sean reconocidos como gestos, o sea, no esperar que el usuario altere su comportamiento natural para evitar una interacción.
  • Que no se pierdan interacciones y sucedan falsos de activación, es decir, que si el usuario realiza un gesto, éste sea reconocido, y que los movimientos naturales no sean mal interpretados como gestos.

 

5. Diseñar para entradas variables

 

Las experiencias y las expectativas de los usuarios pueden llevar a diferentes efectos del sistema en sus interacciones. Hay que tener en cuenta que la interpretación de un gesto por parte de un usuario puede ser completamente diferente de la interpretación de otro usuario para el mismo gesto. La predicción de la intención es un reto considerable, ya que no existe un medio físico para la detección de la intención como una pantalla táctil o el ratón. Una vez que el usuario ha iniciado una interacción con el sensor, el sistema está siempre activo en busca de patrones que coincidan con un gesto.

 

Un ejemplo de ambigüedad en los gestos es pedir al usuario que realice una onda. Si bien la mayoría de las personas saben lo que es una onda, la onda de cada persona es muy variable y por lo tanto no se garantiza que se genere el mismo movimiento. Algunas personas pueden realizar la onda con su muñeca, otras con su codo, y otras con el brazo entero. Algunas pueden utilizan la mano abierta que se mueve de izquierda a derecha mientras que otras mueven sus dedos juntos hacia arriba y hacia abajo.

 

Es muy importante además distinguir las interacciones intencionales e ignorar otros movimientos, como por ejemplo el realizado al tocarse la cara, el ajustarse de lentes, beber, entre otros. Para aumentar la confianza, es bueno proporcionar siempre al usuario la mayor cantidad de retroalimentación posible.

Gestualidad 3D, 2D y NLI (parte III)

Compartir objetos (cont.)

 

  • Compartir de forma temporal: Para compartir algo de forma temporal con un dispositivo de tipo smart phone, el usuario lo debe colocar de cara a la pantalla compartida con el brazo extendido, de forma que el dispositivo quede perpendicular al piso. De esta manera el contenido será compartido de forma temporal hasta que el usuario baje al mismo. En cambio para tablets y laptops, lo mencionado anteriormente no se realiza sosteniendo dicho dispositivos ya que los mismos son más pesados y resultaría incómodo. Para estos casos lo que realizan es un gesto con brazo extendido y la mano perpendicular al piso, mientras la otra mantiene contacto con la pantalla del dispositivo. En caso de que la transferencia se quiera hacer de forma permanente el usuario que oficia de presentador puede realizar un gesto tocando el objeto compartido y luego arrastrándolo para que se agregue a una burbuja.

 

Figura 17: Compartir objetos de forma temporal

 

  • Compartir entre usuarios: De forma análoga a lo planteado anteriormente se puede transferir información entre los participantes de la reunión, aunque no es tan socialmente aceptado el hecho de apuntarse entre los usuarios, puede que sea considerado “rudo”. Se plantea el hecho de que se puede enviar información a otros usuarios, pero copiar información de otro usuario no sería posible por aspectos referentes a la privacidad.

  • Permisos para compartir: En un comienzo se planteó como necesario el hecho de poder indicar permisos para poder compartir objetos en la pantalla compartida, pero, esta situación puede llegar a ser un poco problemática cuando una reunión es llevada a cabo entre muchas personas y que a su vez, recién se conocen. Para evitar esto, se agrega el concepto de “package metaphor”. Cuando “package metaphor” es habilitada el usuario transfiere un objeto a la pantalla compartida y un icono con forma de paquete es visualizado. De esta forma, si el usuario envía varios objetos de forma secuencial, todos serán agrupados en bajo el mismo paquete. Para visualizar el contenido el presentador puede posicionar su dedo por encima del paquete mientras que para abrir debe realizar un “tap” sobre el paquete.

 

Figura 18: package metaphor

 

  • Compartir desde el presentador: El presentador también puede compartir burbujas con un solo usuario de la audiencia o a con todos los presentes. Para enviarlo a una única persona, el presentador apunta hacia ella con los gestos mencionados anteriormente, un mensaje con “swipe up” es mostrado en la pantalla. Para compartir con todos los asistentes, el presentador apunta en dirección a la audiencia pero en este caso hacia el piso, el mismo mensaje es mostrado para indicar el modo y las posibles acciones y a su vez, información de que será copiado a todos los presentes.

 

Modos de interacción

 

Usando cámaras de profundidad y tracking esqueletal el sistema es capaz de determinar cuántas personas están presentes en la pantalla y cuales conforman parte de la audiencia. El sistema usa esta información para hacer que la interacción sea lo más sencilla posible y eliminar problemas de usabilidad. En términos generales, se intenta que el software sea lo más sencillo, robusto y predecible que se pueda. De esta forma, se plantean 5 modos de interacción, los cuales listamos a continuación:

 

  • Ambient display mode: No se encuentran ni presentadores ni audiencia. Este modo cambia luego de pasados dos minutos desde que un usuario entra a la sala o interactúa con la pantalla. El sistema muestra el calendario de reuniones cuyo items pueden copiarse a los dispositivos de los usuarios y un listado de bugs.

  • Single speaking presenter: Cuando el presentador se encuentra de cara a la audiencia, distante de la pantalla, se ocultan los elementos de ayuda al presentador, como ser paletas y mensajes, ya que el mismo no las está mirando y oscurecen la visibilidad del contenido de la pantalla a la audiencia.

  • Single working presenter: Cuando hay un presentador de cara a la pantalla la UI de ayuda al presentador es visualizada.
  • Two or more working presenters: Debido a que los usuarios puedan desplazar y hacer zoom en la pantalla compartida, esto crea un potencial problema cuando dos o más presentadores trabajan simultáneamente en la misma. Para ello, la pantalla es dividida automáticamente cuando más de un presentador se encuentra en ella, con un sector aparte para cada uno con el mismo contenido y las mismas posibilidades de acciones a ejecutar.

  • Audience only (working meeting): En esta situación “package metaphor” carece de sentido, ya que no habrá presentador para abrir los paquetes compartidos. En este caso, todos los paquetes serán abiertos de forma automática.

 

Espacio extra

 

Las paredes pueden oficiar de un espacio útil para copiar burbujas fuera de la pantalla compartida. Si bien la altura puede ser incómoda para algunos ya que no alcanzarían a aplicar técnicas multi táctiles, Code Space brinda la posibilidad de realizar señalización en el aire, “swipe up” y “swipe down” para poder interactuar con esa zona. De esta forma Code Space también hace uso de espacios proyectados por fuera de la pantalla multi táctil.

 

Figura 19: Mover burbujas fuera de la pantalla multi táctil

 

Paletas


 

Las paletas de herramientas fijadas en cierto lugar pueden llegar a ser ineficientes en contexto de pantallas muy grandes, ya que esto requeriría que el usuario se desplazara hasta donde se encuentra dicha paleta. Por otro lado, se podría pensar en el hecho de abrir un menú contextual tocando en el fondo de la pantalla con un dedo pero, esta se podría mezclar con el fondo en casos donde la pantalla está llena de elementos.

 

Figura 20: Representación de paletas de herramientas

 

Lo que se propone aquí como solución es poder abrir un menú contextual reconociendo el gesto de una palma en paralelo a la pantalla con los dedos extendidos. El gesto es reconocido cambiando el color en el área debajo de la palma y mientras el gesto siga siendo reconocido la paleta seguirá abierta. De esta forma, el usuario tiene la posibilidad de abrir la paleta en el momento que quiera, donde quiera, y sin la necesidad de tocar la pantalla. Por otro lado, si el usuario quiere fijar la paleta puede hacerlo tocando el fondo de la pantalla con uno de los dedos que abrieron la paleta. De esa forma también podría usar dicha mano para interactuar con el menú. Mediante este criterio, se sigue estableciendo que las posturas establecen modos mientras que los gestos touch establecen las acciones.

 

Gestos de tipo lápiz



Figura 21: Gesto para dibujar

 

Un problema conocido a nivel de gestos de tipo lápiz es saber cuando el usuario se encuentra en este modo. Para determinar esto se podría tocar un botón pero estaríamos ante problemas similares a los planteados en el punto anterior. Es por eso que aquí se plantea el hecho de reconocer el mismo gesto planteado anteriormente (la palma) y luego tocar la pantalla con un dedo de la otra mano o hacer un gesto de tipo lápiz (dibujar como si la superficie fuera una pizarra). De esta forma, el usuario no debe aprender otro gesto, sino que utiliza el mismo y se diferencian en que para realizar dibujos debe tocar la pantalla con un dedo de la otra mano, mientras que para abrir un menú contextual no. Luego de que se hace contacto con el dedo el modo es reconocido y no se tiene por qué mantener el gesto de la palma de la mano, el modo permanecerá hasta que el dedo que dibuja deje de estar en contacto con la superficie.
 

Mejoras técnicas


 

  • Identificación y tracking del usuario: Para la identificación del usuario se plantea el uso del SDK de Kinect para el reconocimiento facial del mismo. Sin embargo esto no acarrea buenos resultados por el hecho de que el usuario debe estar de cara a las cámaras y de lo contrario el sistema puede no ser capaz de reconocerlo. Para evitar lo anterior se plantea agregar más cámaras.

  • Identificación de los dispositivos: En este proyecto de estudio las direcciones de red de los dispositivos están “hard coded”, esto es, están fijas y no son descubiertas a medida que nuevos dispositivos son agregados a la red, que es lo que idealmente se debería de hacer. Para esto, una opción que se plantea aquí en base a trabajos realizados anteriormente es el hecho de combinar mecanismos de “computer vision” para identificar los dispositivos con conexiones de corto alcance Bluetooth.

 



Varios de los conceptos analizados por estos proyectos son de gran utilidad para lo que va a conformar ANIMuS, sobre todo lo estudiado en Code Space, ya que se analizan puntos claves semejantes.

 

¿Has desarrollado alguna aplicación utilizando estas técnicas?

¡Nos encantaría que compartas tu experiencia!

 

 

 

 

Referencias


 

[1] Ux-Magazine- http://uxmag.com/articles/new-design-practices-for-touch-free-interactions

Último acceso: 22 de Julio de 2012

[2] Interactions in the Air:
Adding Further Depth to Interactive Tabletops-http://research.microsoft.com/en-us/um/people/awilson/publications/hilligesuist2009/hilligesuist2009.html
Último acceso: 26 de Julio de 2012
[3] Ten Usability Heuristics-http://www.useit.com/papers/heuristic/heuristic_list.html
Último acceso: 30 de Julio de 2012
[4] Billverplank Lecture-http://www.billverplank.com/Lecture/
Último acceso: 30 de Julio de 2012
[5] Bill Verplank-http://www.billverplank.com/
Último acceso: 30 de Julio de 2012
[6] Lukew reference guide-http://www.lukew.com/ff/entry.asp?1071
Último acceso: 30 de Julio de 2012
[7] iPhone-http://www.apple.com/iphone/features/siri.html
Último acceso: 30 de Julio de 2012
[8] Code Space-http://research.microsoft.com/en-us/um/people/merrie/papers/codespace.pdf
Último acceso: 08 de Agosto de 2012

Gestualidad 3D, 2D y NLI (parte II)

Feedback a partir de las sombras

Por otro lado se plantea que usar una técnica de sombras permite al usuario conectar su mano en el mundo real con el objeto virtual que está moviendo, de esta forma se trata de aumentar la percepción por parte del usuario para brindar la sensación de que está interactuando de forma directa con los objetos de la escena. Generar estas sombras posiblemente requiera un sensado e iluminación adicional.


Para poder representar la sombra se utiliza la información de la imagen obtenida por las cámaras de profundidad como hablábamos en post anteriores así es procesada y dibujada en la escena. Una alternativa planteada aquí consiste en generar un mapa de sombras para todos los objetos presentes en la escena y luego combinarlo con el generado a través de las imágenes provenientes de las cámaras de profundidad, el valor más grande de profundidad es el valor almacenado en el mapa final.

A medida que la mano se aleja de la mesa, la sombra mostrada es menor, esto es un poco contradictorio a lo que realmente sucede en el mundo real, pero a medida que la mano se aleja menor es la información que sería necesaria, siendo esto una hipótesis que se plantea ligada al proyecto.

 


Figura 9: Sombras en la interacción

 

Code Space: Touch + Air Gesture Hybrid Interactions for Supporting Developer Meetings


 

Code Space es otro proyecto llevado a cabo por Microsoft Research, el cual, al igual que el proyecto anterior, relaciona gestos 2D y 3D para posibilitar en este caso una reunión de desarrolladores presentes físicamente en una misma sala, donde se democratiza el acceso, el control y el intercambio de información a través de múltiples dispositivos personales y otros de carácter público, haciendo uso de dispositivos como son pantallas multi táctiles, smartphones y sensores Kinect.

 

Figura 10: Sala de reunión de Code Space

 

En el Vídeo 2 se puede observar lo que se presenta en este proyecto.

 

Vídeo 2: Code Space: Touch + Air Gesture Hybrid Interactions for Supporting Developer Meetings

 

La sala de reuniones presentada por Code Space se puede visualizar en la Figura 10 donde la misma incluye una pantalla multi táctil la cual es compartida (pública) entre todos los intervinientes. Este sistema hace uso de dos Kinects para poder detectar los gestos y las posiciones de los usuarios. Uno de los Kinects es colocado por encima de la pantalla multi táctil, apuntando hacia aquellos usuarios que estén haciendo uso de dicha pantalla y por lo tanto ocupan el rol de presentadores, mientras que el otro se encuentra direccionado a los usuarios que tendrían el rol de audiencia.


Code Space estaría posibilitando la interacción entre distintos dispositivos presentes en esta sala y para ello hace uso de gestos tanto “2D” como “3D” de forma combinada haciendo hincapié, en este contexto, en que los gestos utilizados sean socialmente aceptados.

 

Requerimientos y necesidades en una reunión de desarrolladores


 

Ejemplos de reuniones que llevan a cabo los grupos de trabajo de desarrolladores son las reuniones del tipo “scrum” donde se trabaja en conjunto y por lo general se llevan actividades donde se ordena, filtra, categorizan y editan un conjunto de objetos en formato digital.

Este tipo de reuniones hoy en día se llevan a cabo en salas donde por lo general se conecta un proyector conectado a un único dispositivo. De esta forma, no se puede tener acceso por todos los usuario de forma democrática a lo que se está visualizando y se tiende a elegir un miembro de la reunión para que oficie de “control remoto” y presentador/moderador de la reunión.

Por otro lado, los usuarios por lo general llevan información relevante en sus dispositivos personales que raramente alternan al proyector para poderla compartir. De lo contrario, realizar este tipo de intercambio de dispositivos genera “overhead” interrumpiendo el flujo de la reunión, distrayendo así a los participantes.  

Si bien Code Space se centra en reuniones como las mencionadas anteriormente, muchos problemas presentes aquí se suelen encontrar también en reuniones de otros tipos.

Ejemplos de interacciones en Code Space serían que un usuario interactuará de forma remota mediante su celular táctil a modo de control remoto apuntando con él a la pantalla multi táctil compartida. Mediante uno de los Kinect presentes se podría seguir la trayectoria para representar un cursor en dicha pantalla. El usuario podría entonces, interactuar con los elementos a través de la pantalla táctil de su celular por ejemplo compartiendo elementos, seleccionando elementos existentes para moverlos, compartirlos o borrarlos. De esta forma se combina señalización “en el aire” como modo de operación y entrada mediante el  dispositivo celular a modo de control remoto cuando el mismo es sostenido indicando así el modo “compartir” y gestos sobre el celular táctil para confirmar y completar las acciones, el cual es un dispositivo aparte de la pantalla compartida. Esto se puede extender de forma colaborativa cuando otro usuario que esté manipulando la pantalla compartida acepta el objeto transferido seleccionandolo en dicha pantalla.

 

Objetivos de diseño


 

El objetivo que se plantea en este proyecto es lograr fluidez y compartir de forma “democrática” información sobre una pantalla común. Para ello se plantean 6 nociones básicas de diseño a cumplir, las cuales son las siguientes:

 

  1. Todos pueden interactuar con la pantalla compartida, desde cualquier sector de la sala y con cualquier dispositivo que posea.
  2. Las interacciones deben ser socialmente aceptadas, y las mismas no pueden causar movimientos embarazosos o que perturben la fluidez de la reunión.
  3. Cada modalidad debe tener un uso separable.
  4. Las interacciones deben posibilitar gestualidad entre dispositivos.
  5. Las interacciones deben manifestarse a los participantes para crear conciencia de las acciones a realizar.
  6. Las formas de interactuar entre los dispositivos deben ser sencillas a modo de evitar un aprendizaje engorroso y la introducción de errores.

 

Las interfaces basadas en el tracking esqueletal pueden estar basadas solamente en el tracking del cuerpo o hacer una combinación con la voz. Este tipo de técnicas tienen un gran conjunto de ventajas. Sin embargo, para el contexto de una reunión, se plantea la existencia de un conjunto de desventajas:

 

  1. Un extenso uso del movimientos de manos y brazos que puede no ser aceptado socialmente.
  2. Una cierta tasa de reconocimientos erróneos.
  3. Falta de información sobre las acciones disponibles.

 

Estos tres puntos planteados deben ser resueltos en la medida que se quiera hacer uso de este tipo de características a la hora de interactuar.

Se establece que, los gestos que involucren a los participantes realizar largas acciones son los más rechazados, así como también gestos inusuales, gestos incómodos y aquellos que puedan interferir con la comunicación también son descartados. Por otro lado, en lo que concierne a comandos por voz, en el contexto de una reunión, se plantea un rechazo al uso de la misma ya que potencia la distracción en la reunión y puede llegar a generarse ambigüedades debido a la cantidad de personas en la misma.

A modo de sacar más estadísticas sobre la aceptabilidad de los distintos mecanismos de interacción, en este proyecto se realizó una encuesta donde:

 

  • El 98% de los encuestados indica que se sentiría cómodo en hacer uso de una pantalla multi táctil en reuniones.
  • El 93% indica que se sentiría cómodo en interaccionar con dicha pantalla apuntando desde el lado de la audiencia.
  • El 80% indica que se sentiría cómodo realizando pequeños gestos con las manos a modo de comandos.
  • Sólo el 29% indica que estaría cómodo en hacer largos gestos con los brazos, el resto considera el hecho como “embarazoso”, “tonto” y que distrae el cometido de la reunión.
  • El 95% indica que se sentiría cómodo en usar dispositivos táctiles como tablets o laptops touc para interactuar con la pantalla compartida.
  • El 80% indica que se sentiría cómodo usando smartphones.

 

En esta sala de reuniones donde varios usuarios estarían interactuando a distancia, es importante manifestar quién es el que se encuentra ejecutando determinada acción, ya que, por ejemplo, en el caso que alguien esté moviendo un objeto de forma remota no se sabría quien está llevando a cabo dicha acción y se vería mover el objeto “sólo” de un lado hacia otro. Si bien al utilizar dispositivos táctiles para interactuar con la pantalla compartida logramos una interacción directa y precisa, la misma oculta quién es que está realizando dicha acción y a su vez interfiere con los habilidades humanas comunes para manipular objetos en una pantalla táctil.

Para resolver esto, se plantea combinar gestos multi táctiles, señalización en el aire y posturas a modo de proporcionar una interacción híbrida. Específicamente, se plantea usar tracking esqueletal para identificar modos y operandos en base a movimientos familiares y simples como apuntar (señalizar) y confirmar y completar las acciones mediante gestos del tipo touch los cuales son más socialmente aceptados y precisos.

 

Diseño



  • Code Bubbles: La información a mostrar en la pantalla multi táctil es representada a través de “bubbles” (burbujas), donde cada una de ellas desplegará diferente información. A estas burbujas se las puede manipular mediante comandos multi táctiles que posibilitan moverlas mediante “touch-dragging” (tocar y arrastrar), cambiar el tamaño a través de “pinching” (pellizcar) y mover el fondo “pan” con las burbujas mediante “touch-dragging” en el fondo de la escena.

 

Figura 11: Representación de objetos digitales mediante “bubbles”

 

  • Interacción a distancia: Lo que se plantea aquí es el hecho de que se tenga un acceso democratizado a la pantalla multi táctil con lo que posea el usuario, esto es, con smartphones o laptops multi táctiles o simplemente sus brazos. Para ello, la implementación de Code Bubbles es una extensión de Visual Studio donde la misma corre en la pantalla compartida como así también en dispositivos multi táctiles del tipo laptop o tablets. Para los smartphones se creó una aplicación que permite conectarse a Code Space permitiendo ver cierta cantidad de estas burbujas y tanto en esta aplicación como en las que corren en la pantalla y en las laptops se permite realizar acciones de debugging y edición sobre las mismas.

 

  • Señalando con el brazo: Permite que cuando un usuario apunta a la pantalla se detecta dicho gesto mediante tracking esqueletal y se dibuja un cursor en la misma.

 

Figura 12: Señalización y manipulación con brazos y mano


  • Manipulando con brazo: El usuario puede manipular las burbujas realizando un gesto en el cual la palma de la mano apunte a la pantalla compartida y los dedos se encuentren juntos. Cuando el sistema detecta este gesto cambia al modo “drag” (arrastrar) notificado con el cambio de forma del cursor, hasta que se deje de reconocer dicho gesto.

  • Señalando y manipulando con brazo y smartphone: Una alternativa a lo anterior es que el usuario pueda apuntar a la pantalla mediante su smart phone. Basándose también en tracking esqueletal para reconocer el gesto del brazo estirado, como mencionado en el caso anterior, un cursor aparece en la pantalla. Para mover un objeto el usuario debe apuntar a él, tocar sobre una superficie del smart phone vacía y comenzar a mover el dispositivo hasta que deja de tocar la pantalla del mismo para terminar la acción. Esta técnica aplica las dos modalidades, si el usuario no levanta su celular y no presiona sobre la pantalla nada ocurre. De esta forma se logra interacción entre dos dispositivos smart phone-pantalla.

 

 

Figura 13: Señalización y manipulación con brazos y dispositivo


  • Anotaciones temporales: Se establece para potenciar el uso de la señalización con el hecho de hacer marcas temporales a modo de dibujos. Las mismas se realizan a través de la selección de un icono en la aplicación del smartphone y mientras el mismo se mantenga presionado con gestos en el aire se pueden llevar a cabo marcas temporales. Cuando el usuario deja de presionar el icono en el dispositivo las marcas desaparecen.

  • Gestos de la audiencia: Es de mencionar que los gestos realizados en el aire tienen ciertos problemas, como por ejemplo los siguientes:

 

  1. Activación accidental: como el sistema captura todos los movimientos del usuario el mismo podría llegar a interpretar gestos que no fueron llevados a cabo de forma intencional.
  2. Segmentación ambigua: los gestos son por naturaleza continuos por lo cual son de por sí difíciles de segmentar.
  3. Respuesta táctil: gestos puramente hechos en el aire no poseen respuesta de tipo táctil, sin embargo cuando un dedo y el pulgar se presionan juntos hay información táctil que pasa desapercibida.

 

Figura 14: Interacción entre dispositivos

 

Para enfrentar estos problemas se diseña una forma de interacción que en lugar de hacer gestos en el aire (posturas) a modo de comandos de entrada se usa el tracking esqueletal para activar modos en los dispositivos de los usuarios los cuales son indicados por mensajes en los mismos, luego de un período de reposo, ilustrando a su vez, las posibles acciones que se pueden realizar. De esta forma se remueve eventuales comandos a activarse de forma accidental si fuesen permitidos de realizar de forma directa por gestos en el aire. Se propone entonces, que los diferentes modos que posibilita el sistema se activen mediante gestos en el aire, pero que las acciones se ejecuten desde el dispositivo mediante gestos touch.


Por ejemplo, en la Figura 14 el usuario apunta hacia la pantalla con su celular (figura de la izquierda), de esta forma se entra en un modo y se despliega la información sobre qué gestos se pueden realizar. Luego realiza un “flick-right”,(mover a la derecha), (figura del centro) y la pantalla se mueve hacia la derecha (figura de la derecha).

 

Compartir objetos


 

  • Señalización y gestos 2D: El usuario puede copiar burbujas desde la pantalla compartida hacia su dispositivo o copiar hacia la pantalla burbujas que tenga en su dispositivo. Para lo primero, el usuario debe apuntar con el dispositivo a la burbuja a copiar y hacer un gesto de “flick down” (mover hacia abajo) sobre dicho dispositivo. De esta forma, la burbuja compartida cambiará a un tamaño menor ya que el display de los dispositivos es notoriamente inferior al de la pantalla compartida. De forma análoga realizando un gesto de “flick up” (moviendo hacia arriba) sobre el dispositivo y apuntando a una sección de la pantalla se pueden copiar objetos hacia la pantalla compartida.

Figura 15: Compartir objetos mediante dispositivo smart phone

 

Figura 16: Compartir objetos mediante dispositivo laptop o tablet

 

Para los casos que se quiera compartir desde una laptop o tablet lo que se plantea es apuntar con un brazo extendido hacia el lugar donde se quiere copiar en la pantalla, de esta forma se entra en un modo mostrando un mensaje en el dispositivo, se reconoce el gesto y se brinda información de las acciones posibles de realizar. Luego mediante el uso de la mano del otro brazo el gesto “flick up” la burbuja es copiada hacia dicho lugar. En cambio si se quiere traer una burbuja se debe realizar algo semejante, se apunta la burbuja a copiar con una mano y luego con gesto “flick down” la burbuja es copiada al dispositivo donde se apuntó al realizar el gesto.

Gestualidad 3D, 2D y NLI (parte I)

Introducción


 

La interacción basada en gestualidad táctil, también denominada “2D” ha revolucionado la forma de interacción con que los usuarios interaccionan con los dispositivos. Hoy en día, esto ha avanzado de forma exponencial no sólo incluyendo esta vía de interacción sino también mediante gestualidad “3D” denominada también como “touch free gesture” (gestos libres) y mediante “Natural Language Interaction (NLI)” (Interacción mediante Lenguaje Natural). Estas técnicas permiten que las personas se relacionen más con los dispositivos de una manera más “humana” e intuitiva.

 

Figura 1: Izquierda: gesto 2D. Derecha: gesto 3D

 

Touch-free gestures


 

Microsoft con el dispositivo Kinect fue uno de los primeros en incursionar en este tipo de interacción abocada al área de videojuegos como mencionábamos en post anteriores. Hoy en día, mediante la implementación de “Kinect for Windows” y de televisores inteligentes se está migrando este tipo de interacción más allá de los videojuegos.

Un elemento interesante y clave relacionado a este tipo de interacción es el hecho de la reducción de la necesidad de elementos para la interacción. De esta forma se logra interaccionar con elementos digitales de forma semejante a la interacción llevada a cabo con los elementos físicos del mundo real, esto es, no se necesita de un elemento externo para poder lograr interacción.

Por otro lado, este tipo de interacción se vuelve muy útil para los casos en que acciones del tipo multi táctiles se vuelven prácticamente impracticables.

 

Natural Language Interaction (NLI)


 

NLI juega un rol muy importante a nivel de interacción, si bien no es algo nuevo, recién con la aparición de Iphone’s Siri ha acaparado más la atención, ya que plantea la idea de comunicarse con los dispositivos de manera natural, natural en el sentido de que NLI imita la forma en que los humanos se comunican entre ellos que es algo que se aprende desde muy temprana edad.

De esta forma, no sólo NLI hace posible la interacción con los dispositivos de forma que se “sienta” más natural sino que logra también antropomorfizar a los mismos.

 

Fundamentos de interacción


 

Si bien la tecnología de hoy en día promueve nuevas formas de interacción, las mismas se encuentran limitadas por las restricciones humanas existentes.

 

Figura 2: Factores humanos relevantes en la interacción

 

Bill Verplank propone un modelo de interacción persona-computadora donde describe a las interacciones de los usuarios con un sistema como una función que depende de tres factores humanos los cuales son los siguientes:

 

  • Input efficacy: Cómo y qué tan bien percibimos lo que el sistema nos está comunicando.
  • Processing model: Cómo y qué tan bien entendemos y pensamos sobre esta comunicación.
  • Output efficacy: Cómo y qué tan bien nosotros nos comunicamos en respuesta con el sistema.

Figura 3: Modelo de interacción persona computadora de Bill Verplanks

 

Haciendo uso de estos elementos referentes a la experiencia de usuario la interacción se hace más enriquecedora, a su vez, estos factores humanos sirven como marco de pensamiento útil para la concepción de nuevas heurísticas, diseños y patrones de comunicación.

 

Heurísticas


 

Existen un conjunto de diez heurísticas ya establecidas para el diseño a nivel de interfaz de usuario, aquí podemos encontrarlas. Aparte de ellas, con el uso de interacciones basadas en gestos “3D” y con el uso de NLI surgen otras consideraciones a tener presente como las siguientes:

 

  • Los gestos deben ser de granularidad alta (output efficacy): Los gestos realizados sobre las superficies no son extremadamente precisos, mucho menos lo son los gestos realizados “en el aire”. Es por esto que, no se debe esperar mucha precisión, esperar lo contrario acarrearía muchos errores. Por lo antedicho se debe manejar un margen de error aceptable al momento de reconocer estos gestos.

  • La personalidad de un sistema debe ser adecuada a su función (processing efficacy): Cuando se establece por ejemplo una comunicación mediante comando por voz, los usuarios tienden a personalizar aquello con lo que están interactuando. A su vez, si el usuario recibe respuesta del sistema, la personificación se asienta más en la mente del mismo, es por esto que, la misma debe ser acorde a su función. Ciertos programas, como por ejemplo Excel o Numbers, si agregaran el uso de comandos por voz de forma amigable y entendible haría que el usuario no sea tan reacios a los mismos. Siri de Apple realiza tareas comunes como agendar un evento tornándose divertida ya que Apple le brindó sentido de humor, de esta forma el usuario tiene una afinidad mayor con el sistema.
     
  • El sistema no debería requerir a los usuarios que realicen gestos de forma repetida o que los mismo se prolonguen demasiado en el tiempo (output efficacy): Gestos repetitivos o prolongados hacen que el usuario se agote, a su vez, los músculos se contraen y hace que la precisión decremente afectando de esta forma la performance del sistema. Esto aplica a menos que se quiera que el usuario se ejercite de alguna forma.
     
  • Tantos los gestos como los comandos por voz deben ser apropiados para el ambiente en el cual se encuentra inmerso el usuario (input and output efficacy): El usuario no va a adoptar un sistema que lo haga sentir ridículo en público. Por ejemplo, un sistema que sea para un contexto de oficina, no debería requerir que el mismo realice largos y tontos gestos o tener que pronunciar en voz alta extraños comandos. Por otro lado, incluir gestos y comandos “tontos” en una aplicación orientando al entretenimiento infantil puede llegar a ser más acertado. Es por esto que, los comandos deben ser adecuados según el contexto en el cuál van a ser aplicados.
     
  • Posibles usos deben ser claros y las interacciones deben ser coherentes (processing efficacy): La interfaz mediante gestos y voz es más poderosa pero menos “visible” que elementos clickeables, por lo cual posibles usos claros y una coherente interacción son elementos críticos a considerar.

 

Patrones


 

A medida que estos tipos de interacciones “2D” y “3D” han crecido, aparecieron librerías que ayudan al diseñador a definir buenas interfaces, conformando ciertos patrones.


Un ejemplo es lukew, quien presenta aquí una guía completa de los tipos de interacciones multi táctiles existentes. Algunas de ellas se pueden observar en la Figura 4.

 

Figura 4: Interacciones de tipo 2D

 

No limitados los gestos a los planos X e Y los diseñadores pueden hacer uso de la profundidad. A su vez, esto combinado con la interacción de comando por voz llega a conformar interfaces muy ricas, de forma que por ejemplo, la mano del usuario puede controlar cierto aspecto mientras que por voz se puede controlar otro.


Un ejemplo de librería para gestos 3D es la proporcionada por think moto, quienes aquí presentan los gestos más comunes utilizados para este tipo de interacción. Se pueden observar algunos de ellos en la Figura 5.

 

Figura 5: Interacciones de tipo “3D”

 

Por otro lado, en cuanto a la interacción por voz, la complejidad de los lenguajes hace que no sea tan sencillo el hecho de crear patrones basados en NLI como lo es para los gestos “2D” o “3D”. Sin embargo, hay estructuras establecidas en los propios lenguajes que pueden servir de base para definir ciertos patrones. Por ejemplo, básicamente se pueden definir dos tipos de interacción de comandos por voz, esto es, dos tipos de entradas de usuario basadas en su voz; una es en formato pregunta que el usuario realiza y la otra en comandos que el usuario emite. Profundizando, cada sentencia puede ser dividida en frases, cada una representando un componente semántico diferente, pero de todas formas sigue siendo muy complejo categorizar en patrones.

A su vez, los usuarios pueden expresar el mismo comando con diferentes palabras, acentos o entonaciones haciendo la categorización aún más compleja.

 

Información adicional


 

Aparte de los patrones que se pueden detectar en el momento en que un usuario está interactuando con el sistema, es posible detectar otro tipo de información como por ejemplo su estado emocional. Por ejemplo, si la magnitud del gesto detectado aumenta, el sistema puede llegar a interpretar que el usuario se encuentra entusiasmado y el sistema responder acordemente. Por otro lado, esa excitación puede terminar en cierta frustración y el sistema podría tratar de relajar al mismo.

Por otro lado, si el sistema detecta que los gestos del usuario se tornan perezosos y menos precisos, el sistema puede llegar a interpretar que el usuario se siente cansado y podría sugerirle un descanso.

Por otro lado, podría hacer uso de la posición del usuario, como por ejemplo si el mismo se encuentra sentado o parado para poder habilitar o deshabilitar reconocimientos de ciertos tipos de gestos.

 

Proyectos


 

Dos proyectos que han explorado el hecho de combinar estas formas de interacción son los proyectos “Interactions in the Air: Ad