Diseño de interfaces perceptuales para XO

Biblioteca PUI

2011-10-04T21:47:00.003-02:00

Finalmente se ha liberado una biblioteca PUI la cual tiene como propósito facilitar el desarrollo de interfaces de usuario perceptuales.

Las funcionalidades de la biblioteca han sido diseñadas para funcionar con bajos recursos de hardware. Es decir que es posible crear aplicaciones basadas en interfaces de usuario perceptuales que funcionen en computadoras con poco poder de cómputo y poca memoria. La XO 1.0 , con 433Mhz de frecuencia de procesador y 128Mb de memoria ram es capaz de ejecutar correctamente estas aplicaciones.

Aquí puede descargarse la documentación de la biblioteca en sus dos versiones, Python y C++.

Próximamente se publicarán las actividades creadas hasta el momento, la dirección del repositorio de desarrollo de la biblioteca PUI, documentación acerca de las principales funcionalidades de la biblioteca y otros materiales para facilitar la comprensión de la misma y estimular el desarrollo tanto de nuevas aplicaciones como de extensiones para la biblioteca.

Face detection and extraction predominant hue ranges

2010-12-16T00:10:00.007-02:00

1- Detect Face using HaarClassifiers (keep the biggest hit in the image)
2- Create an ellipse surrounding the rectangle with the detected face
3- Create a binary mask: value 1 inside ellipse, value 0 outside ellipse
4- Create and calculate an Histogram using the binary mask and the image with the region of interest (ROI) established in the rectangle area (result of face detection).
5- Threshold the Histogram in order to reduce the noise
6- Normalize the Histogram

The Histogram shows the predominant HUE ranges. The same process can be done with SATURATION and HUE,so we obtain the predominant HSV ranges and we can use them , for example, to apply color segmentation algorithms.

This process can be also done using RGB color representation.

Despite of the diferent light conditions and skin colors, the predominant hue ranges are always near reds, so we could use a color segmentation algorithm in order to make a faster face detection.

Marcadores en ARTookit

2010-03-06T01:11:00.001-02:00

ARToolkit nos brinda la posibilidad de crear nuestros propios marcadores (fiducials), aqui detallamos el proceso:

1) Se crean los marcadores que uds desean, obviamente recordando que tienen que estar dentro del cuadrado negro habitual.
Un detalle al momento de crear un marcador, es tener en cuenta que no sea ni vertical ni horizontalmente simetrico, ya que sino les pasa que ARToolkit no sabe reconocer que lado es arriba, bajo etc de la figura.
Si buscan en internet pueden encontrar el siguiente sitio: http://www.roarmot.co.nz/ar/ que ofrece la posibilidad de generar la imagen del marcador, aunque no hemos logrado utilizarlo con exito por lo que optamos por crear nuestras imagenes manualmente.

2) Una vez que tienen los marcadores tienen que imprimirlos. Una vez impresos hay que lograr generar un .patt para cada uno de ellos (son archivos enteramente numericos). ARToolkit usa esos .patt para hacer el reconcimiento real.
Tenemos dos posibles caminos, usar el mk_patt que viene en ARToolkit o usar este otro link que se puede encontrar publicado en internet (pero fue testeado por nosotros): http://flash.tarotaro.org/blog/2008/12/14/artoolkit-marker-generator-online-released/.
Tomando ambos caminos la logica es la misma, se pone el marcador impreso delante de la pantalla hasta que el borde superior izquierdo tome color rojo y el borde opuesto color verde. Detalles de este proceso estan disponibles en este link:
http://www.artoolworks.com/support/library/Creating_and_training_new_ARToolKit_markers.

Un ultimo detalle sobre este proceso, utilizando el mk_patt en Windows no tuvimos problemas, pero en Linux, debemos asegurarnos de exportar los parametros tal cual lo hacemos para ejecutar la aplicacion. En el extracto de codigo que se muestra a continuacion ejemplificamos el cambio que tuvimos que hacer en nuestro caso:

# if defined(AR_INPUT_GSTREAMER)
//char *vconf = "videotestsrc";
char *vconf = "v4l2src device=/dev/video0 use-fixed-fps=false ! ffmpegcolorspace ! capsfilter caps=video/x-raw-rgb,bpp=24 ! identity name=artoolkit ! fakesink";

3)Si se quiere lograr un ejemplo que maneje detecciones multiples (similar al ejemplo Multitest), se deben disponer todas las imagenes a reconocer en una hoja e imprimirlas.

4)Ahora que todos los patrones fueron reconocidos, tenemos que lograr que ARToolkit los reconzca como a la aplicacion "multitest". Entonces debemos pasar como parametro un archivo .dat con la cantidad de marcadores, tamaños y posiciones relativas.

Nota: Nos hemos enfrentado a un problema al generar archivos .dat en Windows y luego querer utilizarlos en Linux debido a la diferencia entre los saltos de linea entre ambos sistemas. Es por eso que si se genera un .dat en Windows, el ARTookit puede no procesarlo al utilizarlo en Linux.

Por ultimo, la logica que se puede usar para elegir los valores a asingar en las distancias del archivo .dat, es la de simplemente tomar el ejemplo del multitest como base de medicion (si lo miden con una regla, los valores del .dat de este ejemplo equivalena a centimetros). Con esas proporciones se llega a un muy buen resultado.
O sea, si nuestros fiducials miden 5.6 x 5.6, debemos especificar 56 en el tamaño correspondiente del .dat.
Los detalles de cada campo y para tener una idea mas general de esta ultima parte del manejo se encuentran disponibles aqui: http://www.hitl.washington.edu/artoolkit/documentation/tutorialmulti.htm

Problematica en desarrollo de prototipos con ARToolkit

2010-03-03T01:00:00.005-02:00

ARtoolkit parece ser la mejor herramienta para hacer el trabajo que queremos, esta desarrollada especialmente para reconocer figuras de manera sencilla, por lo tanto, parece lo mejor incluir esas figuras en nuestro prototipo de "mouse virtual" y que nuestro programa las interprete como quiera (flecha a la izq, derecha, arriba , abajo y click).

Viendo que Artoolkit es la herramienta que mas se estaría ajustando empezamos a hacer pruebas. Obtuvimos un resultado muy bueno bajo windows y a su vez un resultado muy malo en linux. En windows la performance del ejemplo "multiTest" (ejemplo contenido en el SDK estandar de ARToolkit) es muy buena y alentadora para poder ejecutarla en el hardware de la XO, la carga de la CPU ronda entre 10 - 20%. Por otro lado en linux la situación es muy diferente, la carga de la CPU al ejecutar "multiTest" es de 100%.

Ya que se usa el mismo hardware en ambas pruebas decidimos comenzar a investigar cual puede ser la causante del problema.

1- Driver de la tarjeta de video. En windows y en linux el driver de video no es el mismo evidentemente, quizás esta pueda ser una causante del problema. Lamentablemente esta hipótesis no tiene demasiada solución ya que se esta usando el driver del fabricante (nvidia) y siempre suele ser el mas performante por motivos obvios. Lo que se nos ocurre para mitigar este riesgo es probar en linux pero usando otro hardware que en particular tenga una tarjeta de video de otro fabricante (ATI sería lo mejor, ya que la

especificación del driver de video es libre y existen implementaciones de código abierto muy buenas).

2- Implementación de opengl. Investigando acerca del problema de la carga de CPU con Artoolkit nos encontramos con que alguien tenia el mismo problema. Resulta que esta persona armo unos ejemplo usando Artoolkit. Lo probo en windows usando glut32 (implementación oficial del utility kit para desarrollar en opengl) y freeglut (implementación libre de opengl que estamos usando en linux actualmente). El resultado era que usando glut32 la aplicación tenia un carga de CPU muy baja y usando freeglut una

carga muy alta. Vista esta situación decidimos compilar ArtoolKit en windows 2 veces, una usando glut32 (que es la distribución de ArtoolKIT estándar que ya probamos en nuestras maquinas) y otra usando freeglut. Una vez compilados los ejemplos corrimos "multiTest" y para nuestro asombro no hubo diferencia, funcionaba igual de bien con glut32 que con freeglut. Aquí nos quedo la interrogante de que podría estar pasando...

a- Las operaciones que hacen funcionar mal el ejemplo en freeglut no son usadas en multiTest, en este caso a nosotros no nos importa, porque lo que queremos desarrollar se basa en multiTest y no en el ejemplo encontrado en la web.

b- La implementación de las operaciones que usa multiTest en la implementación freeglut en windows es diferente a la implementación en linux, y freeglut es realmente nuestro problema.

c - El problema no es la implementación de glut y todavía no descubrimos cual es.

d - Otra posibilidad es que el codec de video que estamos usando en linux no esta funcionado bien. Al configurar Artoolkit en linux nos da la opción de usar GSstreamer o de usar Video4Linux. Este último no lo hemos podido hacer funcionar aun y quizás funcione mejor que Gstreamer, no lo sabemos aun, aunque en todos lados recomiendan más usar Gstreamer.

Luego de probar todas las posibilidades nos dimos cuenta de que el problema no se correspondía con ninguna de estas hipótesis, sino que la función que devuelve los frames capturados por la cámara funciona mal bajo linux y se estaban procesando alrededor de 170 frames por segundo, por eso es que la performance

era tan mala. Para resolverlo basto con agregar un sleep hasta encontrar el punto en el que la aplicación procesa 10 fps aprox.

Decidimos usar Artoolkit para hacer el seguimiento de los marcadores y una vez que un marcador no es detectado entonces se convierte la imagen a un formato manejable por OpenCV y se aplica un algoritmo sobre el marcador no reconocido para poder determinar si hay un objeto conocido (llámese mano) tapando el marcador o si no hay nada. En caso de que se detecte una mano tapando el marcador se toma como que el usuario esta presionando el marcador, de lo contrario se ignora.

En este momento estamos trabajando en el algoritmo usando OpenCV para determinar si hay una mano sobre el marcador o no. Creeemos que usar colores brillantes es una buena idea y es performante, difícilmente se confundan ya que toda nuestra escena es una hoja blanca con marcadores en blanco y negro.

Muchos temas interesantes a resolver...

Escuela Nº 200

2009-11-23T00:26:00.001-02:00

Después de bastante retomamos el blog. No queríamos dejar pasar la oportunidad de compartir una de las mejores experiencias personales que hemos tenido en el transcurso de este proyecto.

Nos contactamos con la Escuela Nº 200 de Montevideo gracias a la ayuda de nuestros tutores, las características particulares de esta escuela nos alentaron a interiorizarnos más en cuanto a su metodología de trabajo y las necesidades de los chicos que a ella concurren.

Aquí una breve reseña sobre la escuela:

.:Escuela Nº 200:.

La escuela funciona desde 1978, su objetivo es rehabilitar y/o habilitar al alumno mediante un conjunto dinámico y coordinado de estrategias que desarrollen al máximo sus potencialidades para favorecer su inclusión social. Brinda apoyo a familias e instituciones inclusoras, a través del asesoramiento técnico-docente, recursos didácticos y de implementación para que la inclusión de niños y jóvenes sea exitosa.

Al local concurren 100 niños aproximadamente y sus edades oscilan entre 2 y 20 años. Por ser la única escuela pública especial para niños con problemas motrices, asisten chicos de todo el departamento de Montevideo.

Además de los chicos, integran la escuela la directora, 10 maestros, docentes, fisioterapeutas, psicólogos, asistentes sociales, músicoterapeutas, auxiliares, cocinera y chofer.

Al centro ingresan chicos con diferentes tipo de discapacidad motriz: un 90% tienen Parálisis Cerebral, 8% Espina Bífida (diversos síndromes) y un 2% otras patologías.

Los perfiles de ingreso son los siguientes:

- Niños con patología motriz y con sobreagregación de déficit que por su severidad no pueden incluirse en el currículo común.

- Niños con patología motriz leve que deberán realizar una habilitación perceptivo-motriz antes de ser integrados o reubicados en las instituciones educativas que corresponden.

- Niños con patología motriz y con doble escolaridad, que estando incluidos en escuelas comunes reciben apoyo pedagógico en contrahorario.

El ingreso se produce luego de ser evaluado el niño a partir de una entrevista y habiendo cupo en el grupo al cual le corresponde asistir. El proceso de egreso se produce cuando el niño culmina la rehabilitación o habilitación y se busca la institución adecuada en donde se pueda inscribir. La idea es lograr que los niños salgan lo mas tempranamente posible de la escuela, de manera de que una vez que se ha preparado al niño y a la familia para la inclusión, el niño esta pronto para ser incluido en otra institución. Los tiempos son marcados por los niños y no por la escuela.

Por el momento los chicos pasan 3 horas en la escuela, salvo unos pocos grupos que están haciendo 6 horas. Se está intentando que cada vez más grupos cumplan el horario de 6 horas. En ese tiempo realizan actividades académicas y recreativas.

La escuela trata de buscar apoyos de la comunidad, además del aporte que tienen de Primara y de la Intendencia, reciben apoyo económico de ONGs, y del Ejército para la limpieza y asistencia en las actividades didácticas, como lo son los paseos. Por el lado académico, se han enviado solicitudes a todas las Facultades buscando colaboración de estudiantes que puedan realizar pasantías pero no se ha tenido ninguna respuesta. En particular la Facultad de Ingeniería nunca a mostrado interés en brindar apoyo a esta institución, el proyecto de grado “Diseño de interfaces perceptuales para el Plan Ceibal” sería el primer trabajo que lograría algo en conjunto.

Por otro lado, la institución tiene varios proyectos de trabajo en donde se reciben visitas con muchas colaboraciones, el objetivo de los proyectos, es fomentar la comunicación brindando herramientas para la integración de los chicos en la sociedad.

Como actividades extracurriculares los chicos asisten a Teletón. Es un centro muy vinculado a la niños que asisten a la escuela 200, les brinda a los padres la posibilidad de llevar a los niños y entrar con determinados programas, pueden ser integrales o específicos para determinadas áreas de intervención como fisioterapia o terapia ocupacional, pueden ser de un mes, de quince días, depende de la evaluación que le hacen al niño al ingresar. Pero resulta importante destacar que deben ser los padres los que tienen que llevar a los chicos a Teletón, la escuela no se ocupa de los ingresos a ese centro.

El contexto social de la mayoría de los chicos que asisten a la escuela es complejo. Los padres visitan la escuela, pero se quiere tener mayor presencia de la familia para intervenir en forma conjunta más intensamente, debido a la extensión de la zona que abarca la escuela a veces es difícil lograrlo.

En este link se encuentra la ubicacion de la escuela a traves de Google Maps:

http://maps.google.com/maps?f=q&source=s_q&hl=it&geocode=&q=ernesto+herrera,+montevideo&sll=-34.850615,-56.199789&sspn=0.015848,0.027637&ie=UTF8&ll=-34.846969,-56.201291&spn=0.007924,0.013819&z=16&iwloc=A

ARToolkit

2009-08-08T00:55:00.001-03:00

¿Cómo funciona ARToolKit?

Principios básicos

Las aplicaciones construidas con ARToolKit permiten superponer imágenes virtuales sobre vídeos del mundo real, en tiempo real. Aunque esto parece mágico no lo es. El secreto está en los bordes negros que se utilizan como marcadores. El reconocimiento de ARToolKit funciona de la siguiente manera:

1. La cámara realiza una captura de vídeo del mundo real y lo envía a la computadora.
2. El software en la computadora realiza una búsqueda de cada cuadro de vídeo buscando cualquier forma cuadrada.
3. Si se encuentra un cuadrado, el software utiliza un cálculo matemático para calcular la posición de la cámara en relación al cuadrado negro.
4. Una vez que la posición de la cámara es reconocida, un modelo gráfico es dibujado desde esa misma posición.
5. Este modelo se dibuja sobre el vídeo del mundo real y así aparece pegado al marcador cuadrado reconocido anteriormente.
6. El resultado final se muestra de nuevo en la pantalla, así cuando el usuario mira la pantalla se muestran gráficos superpuestos en el mundo real.

Conociendo la XO

2009-04-28T20:45:00.008-03:00

Dado que nuestro proyecto será montado en el hardware de las computaroras portátiles XO, nos parece conveniente familiarizarnos con ella. Por este motivo a continuación presentamos un video filmado con la XO, la resolución realmente es mala y desalentadora... Todo parece indicar que la
mejor opción es usar una camara web conectada a la XO en lugar de la cámara que trae la máquina.

A continuación un video similar filmado con una cámara web de una laptop convencional.

Aquí esta la salida del comando "lspci" ejecutado desde la XO:

00:01.0 Host bridge: Advanced Micro Devices [AMD] Unknown device 0028 (rev 21)
00:01.1 VGA compatible controller: Advanced Micro Devices [AMD] Geode LX Video
00:01.2 Entertainment encryption device: Advanced Micro Devices [AMD] Geode LX AES Security Block
00:0c.0 FLASH memory: Marvell Technology Group Ltd. Unknown device 4100 (rev 10)
00:0c.1 SD Host controller: Marvell Technology Group Ltd. Unknown device 4101 (rev 10)
00:0c.2 Multimedia video controller: Marvell Technology Group Ltd. Unknown device 4102 (rev 10)
00:0f.0 ISA bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA (rev 03)
00:0f.3 Multimedia audio controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio (rev 01)
00:0f.4 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] OHC (rev 02)
00:0f.5 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] EHC (rev 02)

Aquí se encuentran las especificaciónes de hardware de la XO.

Construyendo un prototipo con openframeworks

2009-04-28T19:25:00.012-03:00

Comenzamos con la construcción de un prototipo básico. Por el momento lo que logramos hacer es tomar como entrada la camara web y reconocer contornos y orientaciones de los objetos presentados.

También se tienen algunas propiedades de los objetos, como por ejemplo el área de los mismos (por el momento no consideramos objetos en 3 dimensiones sino que trabajamos con dibujos en 2d) y estamos trabajando para reconocer figuras tales como cuadriláteros, triángulos, círculos, etc.

Encontramos un paper de Desarrollo de interfaces naturales para aplicaciónes dirigidas a niños en el cual se plantea la siguiente estrategia de reconocimiento.

Se detalla en este apartado el proceso de reconocimiento y las técnicas empleadas en cada
una de las fases. El sistema es capaz, por el momento, de reconocer forma, color y orientación
de cartulinas repartidas sobre el escritorio (fondo blanco uniforme); para llevarlo a cabo se han implementado algoritmos estándar básicos de reconocimiento visual.

El proceso es el que se explica a continuación (ver Figura 1).

1. Captura. Como se ha comentado, el hardware de captura visual consiste en una webcam
conectada al PC mediante puerto USB. Una llamada a la librería “VideoForWindows” de
Windows, devuelve un array de píxeles de dimensión 320 x 200, en la cual cada píxel es
representado por sus componentes de color RGB (Rojo, Verde y Azul) de 8 bits de resolución
en cada componente.

2. Umbralización de la imagen. Se genera un valor de umbral automático que representa un
valor de luminancia (entre 0 y 255) que separa el escritorio de los elementos tangibles. Se
genera un array binario. Para eliminar ruidos de señal de vídeo se aplica un filtrado de
mediana.

3. Visión retinal. Esta fase se encarga de la detección de movimiento. El objetivo es no mostrar
en pantalla resultados “falsos” y esperar hasta que el usuario haya terminado de realizar su
disposición de elemento tangibles.

Figura 1. Flujo del proceso de reconocimiento visual

4. Segmentación de la imagen. Con la imagen estática, y a partir del array binario, se cuenta
y localiza cuántos elementos tangibles hay sobre el escritorio. A continuación se aplica el
algoritmo estándar de etiquetado de blobs (los blobs son puntos o regiones en una imagen que pueden ser tanto mas claras o mas oscuras que sus alrededores).

5. Parametrización de los blobs. Una vez individualizados y etiquetados los blobs, se
parametrizan: se obtienen los valores que caracterizan las propiedades físicas de los
elementos tangibles que se han detectado en el proceso de segmentación: Área, contorno,
orientación, color.

2009-04-27T03:24:00.042-03:00

Perceptual User Interface (PUI)

Por un largo tiempo, las interfaces de usuario gráficas (su abreviación en ingles GUI: Graphical User Interface), han sido la plataforma dominante para la interacción persona computadora. Sin embargo, por la forma en que utilizamos la informática y por el modo en que se ha generalizado y se hace cada vez mas presente en nuestras vidas, las interfaces de usuario gráficas no soportaran fácilmente la gama de interacciones necesarias para satisfacer las necesidades de los usuarios. Para dar lugar a una mas amplia gama de escenarios, tareas, usuarios y preferencias, necesitamos avanzar y migrar hacia interfaces naturales, intuitivas, flexibles y discretas. Un nuevo enfoque para lograr lo antes mencionado, son las interfaces de usuario de perceptuales ( su sigla en ingles y como las llamaremos de ahora en adelante: PUI Perceptual User Interfaces ), y su objetivo es hacer la interacción persona computadora lo mas parecida a como la gente interactúa entre si y con el resto del mundo [1].

Era	Paradigma	Implementación
1950s	Ninguno	Switches, cables, tarjetas perforadas
1970s	Máquina de escribir	Interface de línea de comandos
1980s	Escritorio	GUI / WIMP
2000s	Interacción Natural	PUI (entrada y salida multimodal)

Tabla 1 [1]

Las PUI deben aprovechar las capacidades perceptuales humanas y presentar la información y el contexto en forma natural y significativa. Esto significa que debemos ser capaces de entender la visión humana, la percepción auditiva, formas de conversación convencionales, capacidades táctiles, etc. De la misma manera, las PUI deben aprovechar los avances en la visión artificial, reconocimiento de voz y sonido, sistemas de aprendizaje y comprensión del lenguaje natural [1].

La visión es claramente un elemento importante a la hora de la comunicación entre los seres humanos. Es verdad que la comunicación entre seres humanos puede concretarse sin la visión, pero también es cierto que la visión proporciona una riqueza a la comunicación que no puede ser remplazada mediante el uso de la voz o el texto.Por ejemplo el lenguaje corporal, los gestos faciales, etc. Las interfaces basadas en la vision (su sigla en ingles VBI: Visual Based Interfaces) intentan poder introducir estos gestos a la comunicación entre las personas y las computadoras. Las VBI son una subclase de las PUI y se concentran en desarrollar un conocimiento visual de las personas que usan un sistema. [1]

Visual Based Interfaces (VBI):

Se pueden clasificar en 2 aspectos: Control y conocimiento visual.

1- Control: Es la comunicación explicita con el sistema, por ejemplo poner un objeto en un lugar.

2- Conocimiento visual: Recoger información sobre lo que esta sucediendo sin una iintención explicita de comunicarla. Esto le brinda una contexto a la aplicación, y a partir de este contexto puede decidir tomar acciones o no, pero lo importante es resaltar que no fue necesario dar una orden explicita para que el sistema cambie su comportamiento, el sistema es capaz de detectar un cambio en el contexto.

Por ejemplo, se podría realizar un seguimiento de una persona y si abandona la escena cambiar el comportamiento.Una persona esta mirando un video, y si se levanta y se va entonces podemos pausar el video tanto para evitar que se pierda partes del mismo o que se malgasten recursos que no están siendo aprovechados. [1]

3. Tipos de interfaces y conformación de las PUI:

Imagen 1

Perceptive UI:

Como se puede ver en la figura, las perceptive UI y las demás interfaces que se explican a continuación, están incluidas dentro de las interfaces de usuario perceptuales.

La principal característica de las perceptual UI es que agregan capacidades de tipo humanas a las computadoras. Por ejemplo hacer consiente a la computadora de lo que el usuario esta diciendo o de los gestos que sus manos o su cara están haciendo. Estas interfaces proveen una entrada a la computadora tomando conocimiento del entorno, es decir, permiten a la computadora percibir aquellas vías de comunicación características de los seres humanos las cuales son ignoradas por las GUI a las cuales estamos acostumbrados hoy en día.[1]

Multimodal UI:

Las multimodal UI tienen en común los aspectos de entrada con las perceptual UI. Estas se basan en el uso de múltiples modalidades, por ejemplo la entrada de la computadora puede ser provista por voz junto con gestos, o la utilización de las 2 manos a la vez. También se basan en entradas sensoriales, pero lo que las distingue es que se tiene en cuenta mas de una entrada a la vez, no 2 entradas que provean información redundante sino 2 entradas diferentes que provean información diferente a la computadora. [2]

Así como se usan distintas modalidades para la entrada, también se utilizan distintas modalidades para la salida, como por ejemplo gráfico, voz o salida táctil. El fin de este tipo de salida es incorporar las capacidades de percepción, cognitivas y habilidades de comunicación del usuario para comprender de mejor manera lo que está siendo presentado por el sistema. [1]

Estas interfaces permiten aumentar el ancho de banda de la comunicación entre el usuario y la computadora. Por ejemplo, el usuario podría dar una orden con la voz y otra orden con la mano al mismo tiempo, por lo tanto en una sola acción del usuario se le dio 2 ordenes distintas al computador ,mientras que en las interfaces que permiten un solo modo por vez no hubiera sido posible, primero tendría que haberse dado la orden con la voz y luego con las manos o en el orden contrario. [2]

Multimedia UI:

Las interfaces multimedia son un subconjunto de la salida de las multimodal UI. Aprovechan las habilidades perceptuales y cognitivas del usuario para interpretar lo que el sistema esta presentando. Las vías típicas utilizadas son el texto, el audio y el video. Las interfaces multimedia se concentran en los canales de comunicación, mientras las multimodal UI se concentran en los canales de percepción humanos, es por esto que son un subconjunto de las multimodal UI.

Percepual UI:

Las interfaces perceptuales de usuario integran las perceptive UI, multimodal UI y multimedia UI para que nuestras capacidades humanas influyan de manera de poder crear interfaces mas naturales e intuitivas. Habilitan múltiples estilos de interacción, como por ejemplo solamente voz, voz y texto, texto y tacto, visión y sonido. Estas vías de interacción son usadas apropiadamente en diferentes circunstancias, siempre con el objetivo de hacer la interacción mas natural e intuitiva.

Las PUI son multimodal UI altamente interactivas, modeladas a partir de la interacción humano-humano. El objetivo de las mismas es lograr una interacción con la tecnología de una manera similar de la que tenemos los humanos entre nosotros y con el mundo físico.

Imagen 2

Referencias: [1] Matthew Turk, Perceptual User Interfaces
[2] George G. Robertson, Leveraging Human Capabilities in Perceptual Interfaces