Biblioteca PUI

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

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

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

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

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

¿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

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.