Qué Viaje!

Proyecto Nexo 2012

Nicolás Bava

Rodrigo Pérez Fulloni


Índice

Índice

Planteo del Problema

Objetivo general

Objetivos específicos

Público objetivo

Descripción del proceso de desarrollo

Equipo de trabajo

Proceso de desarrollo

Cronograma general

Descripción del Producto Final

Software

Hardware

Diagrama de Clases*

Implementación del producto

SugarBar

QueViaje

Entorno de Desarrollo

Estructura de directorios

Repositorio

Restricciones

Módulos

Lugar

QueViaje

Valoración del producto

Conclusiones


Planteo del Problema

Objetivo general

El objetivo de la propuesta es desarrollar un juego que permita la ejercitación de ciertos

dominios cognitivos relacionados con hábitos elementales del niño, a través de objetos reales

con códigos QR previamente diseñados a tales efectos. El proyecto será realizado en el marco del Proyecto Nexo[1].

Objetivos específicos

1. El desarrollo o adaptación de una biblioteca que permita desarrollar actividades para

Sugar con la capacidad de interpretar códigos de barras uni y bidimensionales, en

especial Códigos QR.

2. Desarrollar un juego que colabore con la construcción de hábitos, ejercitando

especialmente la planificación y lo visoespacial.

3. Evaluar el impacto del software en el desarrollo cognitivo del niño

conseguir con lo que están haciendo. Ejemplo: Diseñar una aplicación para la XO

basada en narrativa interactiva).

Público objetivo

El proyecto está dirigido a niños pertenecientes a la Escuela pública N° 200 “Ricardo Caritat”,

de la República Oriental del Uruguay. Dentro de este universo poblacional, el software apuntará

a ciertos niños con parálisis cerebral leve o moderada, y a niños con T.E.C (traumatismo

encéfalo craneal).


Descripción del proceso de desarrollo

Equipo de trabajo

El proyecto fue estudiado y llevado a cabo por un equipo de dos personas:

La división funcional de tareas dentro del equipo de trabajo se realizó en base a la  especialidad de los integrantes. En este sentido, Rodrigo Pérez fue el encargado de realizar el desarrollo de la aplicación a nivel técnico, y de ir mejorandola permanentemente, haciéndola cada vez más apta a las necesidades que se fueron planteando. Nicolás Bava fue el encargado de desarrollar aspectos conceptuales del juego, mediante los cuales se pudiera lograr una aplicación que desarrollara en alguna medida la estimulación cognitiva y motriz. Esta división funcionó de esta manera en un plano formal, ya que en la práctica se dió un intercambio de saberes y opiniones que enriqueció el trabajo y a sus integrantes, eliminando una división estricta e inflexible de tareas y roles.

Proceso de desarrollo

El primer paso que realizó el equipo fue la visita a la escuela 200 en dos oportunidades, con el objetivo de conocer a la población con la que se iba a trabajar, así como también comenzar a tener contacto con sus características y necesidades. Una vez conocida la población objetivo, comenzó la etapa de búsqueda de implementación de una aplicación que resultara atractiva para los niños, y que a su vez colaborara en la construcción de hábitos fundamentales como vestirse o alimentarse. Se optó por desarrollar una aplicación que permitiera a los niños planificar un viaje a determinado lugar, debiendo elegir la ropa adecuada al clima correspondiente.

La etapa siguiente consistió en la creación de tres paisajes (playa, ciudad, nieve), los cuales fueron presentados en la escuela para evaluar su impacto en los niños. Dicho relevamiento permitió comprobar que los paisajes elegidos eran adecuados y no generaban mayores dificultades a la mayoría de la población objetivo. El inconveniente más importante que se pudo constatar a nivel general, fue la dificultad en el reconocimiento de la gestalt en el corto plazo.

Con la certeza en la utilización de los paisajes y la idea general del juego, se pasó a desarrollar la aplicación, proceso que abarcó un mes de trabajo, el cual incluyó la prueba en varias ocasiones de los avances realizados, en la escuela.

Algo que acompañó el desarrollo de la aplicación fue la búsqueda del método para que los usuarios mostraran a la cámara los QR. Originalmente la idea fue trabajar con ropa de verdad con QR adheridos a la misma. Esta idea resultó descartada debido a la cantidad de objetos que representaría y a la difícil manipulación de los mismos.

Luego se pensó en utilizar carteles, a modo de pancartas, mostrando cada uno una imágen de la prenda a elegir junto con el código QR correspondiente. Esta idea fue probada y resultaba práctica para la mayoría de los usuarios con los que se probó. Sin embargo, nuevamente fue descartada por la gran cantidad de objetos que necesitaría manipular el usuario.

Por último surgió la idea que se implementó en la versión final, que fue la utilización de cubos, los cuales en cada cara tuvieran imágenes de los objetos junto con su QR. Esta posibilidad solucionaba el problema de la cantidad de objetos, ya que cada uno podría contener hasta seis prendas y añadía nuevas ventajas detalladas más adelante en el informe.

A continuación se detalla el cronograma seguido, que fue retrasado únicamente en noviembre debido a dificultades en la implementación del reconocimiento de códigos QR, parte fundamental del proyecto.

Cronograma general

17 al 30 de setiembre: Implementación de la biblioteca y diseño de los códigos QR

1° al 29 de octubre: Diseño de los distintos niveles del juego.

15 al 29 de octubre: Realización de pruebas preliminares del juego con los niños y otros

usuarios, procurando evaluar la viabilidad del juego, la jugabilidad del mismo y la detección de

errores.

29 de octubre al 13 de noviembre: Realización de pruebas con el público objetivo

13 al 20 de noviembre: Diseño o adaptación de un sistema de evaluación que permita dar

cuenta del impacto del software en el desarrollo cognitivo del niño.

20 de noviembre al 3 de diciembre: Realizar las evaluaciones con el instrumento creado o

adaptado a ese fín.

3 al 10 de diciembre: Evaluación de resultados y conclusiones.


Descripción del Producto Final

Software

Se logró una Actividad para Sugar completa y funcional. Puede ser instalada en la XO mediante el procedimiento habitual[2] utilizando el paquete .XO[3].

Al iniciar el juego se muestra el primero de los Lugares elegidos y se muestra la visualización de lo que ve la cámara para facilitar el uso y con fines lúdicos. El usuario debe mostrar a la cámara los QR de los objetos que cree que puede llevar al lugar que se muestra y el juego reaccionará según sean estos correctamente elegidos o no. Luego de tres aciertos se pasa al siguiente lugar, repitiéndose la dinámica del juego.

Al finalizar el juego el usuario recibe una felicitación mediante imagen y sonido.

Durante el juego pueden accederse las siguientes opciones presionando botones del teclado:

Hardware

Los cubos fueron construidos de 8cm de lado utilizando placas de PVC, el cual fue forrado con papel afiche de colores. En cada cara se pegó una imagen de las prendas que pueden elegirse junto con el QR correspondiente que indica su nombre[4].


Diseño del producto

Diagrama de Clases

 

Implementación del producto

El proyecto se dividió en dos grandes partes: el desarrollo del componente SugarBar y el desarrollo del juego en sí mismo, utilizando SugarBar.

SugarBar

SugarBar es un wrapper para python de la biblioteca ZBar[5], para la decodificación de códigos de barra uni y bi-dimensionales. A los efectos del proyecto ZBar fue compilado para XO y funciona importando en python sus funciones mediante el uso de ctypes.

Pese a que ZBar es un proyecto funcional y podía encargarse de todo el Ciclo de Lectura de un código QR[6] (captura de video, procesado de la imagen, identificación de los QR, decodificación de los QR), aún se encuentra en estado preliminar, la documentación es pobre y las configuraciones por defecto no se adaptan a los recursos de la XO. Muchas de estas configuraciones no pueden ser modificadas mediante el uso de las funciones provistas por la librería. Por estos motivos es que se relegó         a ZBar únicamente a cumplir las funciones de identificación y decodificación.

SugarBar se encarga de capturar la imagen, haciéndolo de la forma sugerida por los colaboradores del proyecto pygame[7]; y someter a un simple pre-procesado a la imagen utilizando la librería numpy[8], incluida en todas las versiones de Sugar. Luego envía la imagen pre-procesada en el formato aceptado por ZBar[9] (Y800[10]), quien se encarga de localizar y decodificar los códigos QR.

Tanto el módulo pygame.Camera como el pygame.SurfArray fueron intruducidos en PyGame 1.9, mientras que las distribuciones de Sugar utilizadas por el Plan Ceibal únicamente cuentan con PyGame 1.8. Ambos módulos son requeridos para el funcionamiento de SugarBar, por lo que junto con SugarBar se adjunta una versión reducida de PyGame 1.9, conteniendo estos módulos ya compilados para XO.

SugarBar, buscando simplificar al máximo su uso, expone dos funciones:

Nombre

getAndAnalize

Parámetros

Retorno

python List - Lista conteniendo las cadenas de texto que se encontraron en los códigos QR. Lista vacía si no se encontró nada.

Descirpción

Genera un ciclo de lectura de un código QR

Nombre

blitCameraImage

Parámetros

display - objeto pygame.Display donde se quiere mostrar la imagen

posicion - tupla (x, y) con las coordenadas de Display donde quiere mostrarse la foto

Retorno

Descirpción

Imprime en el display de pygame la imagen capturada por la cámara. Realiza la función pygame.surface.blit; no realiza flip ni update.

Sugarbar únicamente procesa si está disponible una nueva imagen desde la cámara web, evitando así la necesidad de sincronía en los llamados a la función getAndAnalize.

QueViaje

Que viaje utiliza SugarBar para identificar códigos QR presentados a la cámara de la XO y así identificar los objetos que el usuario desea elegir. Mediante el uso de las librerías de pygame se dota a la aplicación de imagen y sonido, que responden de acuerdo a las acciones del usuario.

Entorno de Desarrollo

El desarrollo fue llevado a cabo utilizando NetBeans 6.9[11] con el plugin para Python. El desarrollo inicial del juego se realizó en Ubuntu con Python 1.7 y Pygame 1.9. Las librerías compiladas se compilaron en una máquina virtual con Fedora 12. Las pruebas se llevaron a cabo en una XO 1.0.

Los archivos de proyecto de NetBeans se adjuntan junto al código fuente.

 Estructura de directorios

 Repositorio

El código fuente puede encontrarse en el repositorio SVN de facultad https://www.fing.edu.uy/inco/svn/repos/medialab/nexo/trunk/2012 o en el repositorio GIT de sugarlabs en http://git.sugarlabs.org/que-viaje

Restricciones

ZBar se distribuye junto con esta aplicación en estado de biblioteca dinámica compilada para Fedora 12. La versión más reciente de Sugar que distribuye el Plan Ceibal[12], Sugar 0.94.1 Dextrose 3 Uy, utiliza Fedora 14 como base[13], por lo que también fue cambiado el kernel de linux utilizado por las XO flasheadas recientemente. La librería ZBar tal como está compilada no funcionará en esta nueva versión de Sugar. Es necesario volver a compilar, ahora para este kernel de Linux e incluir esta nueva versión en la distribución de Que Viaje para lograr mayor compatibilidad. Por problemas de cronogramas no se alcanzó este objetivo aún.

Módulos

Lugar

Es la clase abstracta base para crear nuevos lugares. Implementa además funciones de autoconfiguración de los lugares. Al iniciar el lugar automáticamente se dibuja el fondo en el pygame.display que se pasa por parámetro al constructor.

Además se exponen las siguientes tres funciones:

Nombre

repaint

Parámetros

Retorno

Descirpción

Dibuja nuevamente el fondo sobre el pygame.display pasado al constructor al momento de crear el lugar. Realiza la función pygame.surface.blit; no realiza flip ni update.

Nombre

cargarDatos

Parámetros

Retorno

Descirpción

Abstracta. Debe ser implementada en los lugares concretos. Debe cargar en una variable self.nombre el nombre del lugar y en una variable self.cosasPermitidas una lista conteniendo tuplas de la forma (nombre del objeto permitido:string, orden en que debe ponerse la prenda : int)[14]

Nombre

chequear

Parámetros

objeto - string con el objeto a chequear

Retorno

boolean

Descirpción

Chequea si el objeto está permitido en este lugar. Devuelve True en caso afirmativo o False en caso contrario.

Para la creación de un lugar nuevo debe crearse una clase llamada según el nombre del lugar, ej. “Nombre” dentro del paquete “Data” y que herede de “Lugar”. Debe sobreescribir la función cargarDatos donde se cargarán el nombre “Nombre” y los objetos acertados.

QueViaje

Que viaje implementa un loop infinito que termina a la finalización de la aplicación o a la presión del botón correspondiente a Escape en la XO.

Dentro del loop se chequea el estado del teclado a la espera de la intervención del usuario para llevar a cabo distintas acciones del juego[15], mostrar pistas, mostrar información, salir, etc.

Luego de verificadas las teclas se procede a la utilización de SugarBar para comprobar si la cámara detecta un código QR. En caso negativo vuelve a repetirse el ciclo. Si se detecta un QR se comprueba si es válido para el lugar y se disparan los refuerzos auditivos y visuales correspondientes a cada caso.

Luego de logrados tres aciertos se pasa al siguiente lugar creando una nueva instancia del objeto correspondiente al mismo y cargando sus datos, luego se continúa con el ciclo.


Valoración del producto

Se logró un producto atractivo y que cumple satisfactoriamente con los objetivos propuestos inicialmente. Los paisajes elegidos resultaron agradables y entendibles para la mayoría de los usuarios, así como las prendas a elegir. La herramienta del cubo con las prendas impresas resultó una solución para el problema de la coordinación motriz con la cámara.

El tiempo de demora de reconocimiento de los códigos QR por parte de la XO fue reducido sensiblemente con el avance del proyecto, lo que facilita el manejo de la herramienta por parte de los usuarios, por lo que el juego se hace más dinámico y entretenido. La información agregada a cada paisaje, brinda un plus de conocimiento básico que puede resultar bastante útil a los niños. El sistema de pistas implementado constituye un acompañamiento a aquellos usuarios que les resulte más dificultosa la tarea, así como un instrumento que ayuda a pensar y a resolver problemas cotidianos. También puede servir como guía a docentes o tutores.

La aplicación no es accesible a toda la población de la escuela, lo cual era un aspecto previsible en un comienzo. De todas formas, permanecen interrogantes acerca de cual será la jugabilidad  que tendrá en la población con un nivel intermedio en el plano cognitivo y también motriz.

En este sentido, se considera como el debe más importante de este proceso el hecho de no haber podido evaluar el impacto del software en el desarrollo cognitivo de los niños. De esta forma, queda pendiente corroborar la amplitud de la accesibilidad del producto, lo cual constituye un aspecto importante para este equipo de trabajo.

En términos generales, se considera interesante el producto generado, teniendo en cuenta el tiempo real con el que se contó para su realización e implementación. Una característica importante de la aplicación es que está pensada para ser mejorada y/o ampliada, pudiéndose generar distintos paisajes nuevos, así como también estimular la planificación de otras actividades básicas como la alimentación o el transporte. Esto se puede ir adaptando de acuerdo a las necesidades de los niños y a lo que las maestras de la escuela consideren pertinente para cada nivel. Asimismo pueden ser creadas nuevos métodos de entrada, ya que el único requisito son los códigos QR, pudiendo estos adherirse en cualquier clase de objeto.

Además SugarBar quedó abierto para la utilización de detección y decodificación de QRs en otras actividades Sugar.


Conclusiones

El proceso de trabajo en estos meses resultó sumamente atractivo y enriquecedor para los integrantes de este equipo. En primer lugar, el diálogo entre dos disciplinas tan “distantes” como ingeniería y psicología generó un trabajo muy novedoso. Esto se vio potenciado por la naturalidad y la comodidad con la que trabajó este equipo, para el cual la escasez de tiempo disponible constituyó su principal dificultad. El contacto fluido y periódico con los niños de la escuela, así como la comunicación y el intercambio con el personal que allí desempeña sus funciones, constituyó una herramienta de inestimable valor a la hora de lograr resultados satisfactorios en el producto y en el desarrollo del proceso en general. El saldo es totalmente positivo, si se toma en cuenta el elevado aprendizaje en el breve lapso transcurrido. Poder apreciar y compartir los brillantes productos realizados por el resto de los equipos de trabajo genera además una sensación de grata satisfacción, y de ganas de continuar involucrado en la

temática. Por supuesto quedan cuentas pendientes, siendo lamáss importante, como ya se mencionó, el poder evaluar el impacto de la aplicación más exhaustivamente con la población objetivo, así como trabajar para lograr productos cada vez más accesibles para todos, lo cual no es una tarea sencilla según la experiencia recogida.

En definitiva, queda la sensación de haber cumplido y de intentar seguir intercambiando saberes y desafíos, que permitan la creación de herramientas generadoras de calidad de vida y de inclusión.


[1] ¿Qué es Nexo? - http://www.fing.edu.uy/nexo/%C2%BFqu%C3%A9-es-nexo

[2] Instalando Actividades en sugar - http://laptop.org/8.2.0/manual/Sugar_InstallingActivities.html

[3] El paquete .XO se encuentra en la carpeta “dist” dentro de los repositorios de la aplicación.

[4] Generador de códigos QR online  - http://zxing.appspot.com/generator/

[5] http://zbar.sourceforge.net/

[6] Ciclo de Captura de un código QR - http://zbar.sourceforge.net/img/zbar_pipe.png

[7] Pygame Tutorials, Camera Module Introduction by Nirav Patel - http://www.pygame.org/docs/tut/camera/CameraIntro.html

[8]Numpy -  http://www.numpy.org/

[9] Formatos de imagen aceptados por ZBar - http://bit.ly/WfmnSM

[10] Y800 - http://www.fourcc.org/yuv.php#Y800

[11] NetBeans 6.9 - http://netbeans.org/downloads/6.9.1/index.html

[12] Imagen de Sugar Dextrose más reciente del Plan Ceibal - http://bit.ly/UvMsaL

[13] Sugar 0.94.1 utiliza Fedora 14 - http://bit.ly/R2tafz

[14] El dato “Orden en que debe ponerse la prenda” no es utilizado en la actual implementación.

[15] Clase Key de PyGame - http://www.pygame.org/docs/ref/key.html