ARgos

La Universidad de Castilla-La Mancha ha presentado este jueves en Ciudad Real el proyecto ARgos dentro de la Cátedra Indra-Fundación Adecco de Investigación en Tecnologías Accesibles.

En el acto han estado presentes el director de la Cátedra, Juan Carlos López; el coordinador de Fundación Adecco, Héctor Clemente; la responsable de Acción Social de Indra, Alicia Fernández del Viso; y el director del Software Lab de Indra en Ciudad Real, Carlos Alger.

Han sido numerosos los medios de comunicación que se han hecho eco de la noticia:

Informativos Telecinco EuropaPress El Economista El Día Digital La Tribuna de Ciudad Real MiCiudadReal Diario Crítico SendaSenior Te Interesa.es Periodistas en Español Notinet Discapnet Aprender.se La Cerca Gabinente de Prensa de la UCLM Gabinete de Prensa de Indra Sistemas

En este acto tambien ha sido presentado el proyecto Sainet, desarrollado en el grupo de investigacion VISILAB, que consiste en una aplicación de procesamiento de imagen a través del móvil que proporciona a una persona invidente información auditiva sobre el número de personas presentes frente a él, la posición de éstas (ángulo y distancia estimada) y los grupos que se forman.

El prototipo construido utiliza una cámara de bajo coste y un cañón de proyección portátil para mostrar información visual, directamente alineada sobre el documento del mundo físico.

Figura 1: Hardware de ARgos

Responde a las peticiones que el usuario realiza sobre el espacio físico, ampliando información relacionada que sea relevante a la acción que quiera realizar. El documento se puede mover dentro de una región del escritorio y la amplificación queda perfectamente alineada en el espacio físico. Como soporte hardware, se ha utilizado un computador en placa Raspberry Pi con arquitectura ARM.

Las principales carácteristicas del sistema son:

• Captura y preprocesado de imágenes. El sistema dispone de un módulo para obtener las imágenes y aplicarle el procesado previo necesario, como puede ser escalado, umbralización, detección de bordes o detección de características. Otra tarea que realiza, es calcular la distorsión debida a la proyección en perspectiva mediante los parámetros extrínsecos e intrínsecos de la cámara.

• Sistema de identificación de documentos. ARgos cuenta con un sistema de identificación rápida empleando algoritmos de recuperación de imágenes y comparando el documento que está siendo analizado, con una base de datos de documentos conocidos por el sistema.

• Implementación de técnicas de tracking y registro. Para el correcto alineado de la información mostrada, el módulo de tracking y registro cuenta con funciones de cálculo de pose (rotación y translación del objeto en el espacio 3D) en tiempo real y algoritmos para la estimación y descripción del movimiento como Optical Flow.

• Utilización de paradigmas de interacción natural con el usuario (NUI). El usuario puede interactuar directamente en el espacio físico sin utilizar sistemas de mando o dispositivos de entrada tradicionales como un ratón, teclado, etc. siendo sustituidos por funciones más naturales como el uso de movimientos gestuales con las manos.

• Facilita la gestión documental a personas con necesidades especiales. Cuenta con diferentes modos de amplificación de la información del mundo real. Por un lado, la información visual se amplifica empleando el cañón de proyección, que muestra información relevante al contexto directamente sobre el espacio del papel, así como la reproducción de audio, text-to-speech y alertas sonoras.

• Se basa en componentes de bajo coste. Para facilitar la implantación real en el entorno de trabajo, el sistema funciona con componentes de bajo coste, incorporando mecanismos de corrección de distorsión y registro 3D totalmente software.

• Dispositivo multiplataforma (hardware y software). El desarrollo de ARgos se ha realizado siguiendo estándares, tecnologías y bibliotecas libres multiplataforma, con el objetivo de que pueda ser utilizado en el mayor número de plataformas posibles tanto hardware (x86, x86-64 y ARM) como software (GNU/Linux, Windows o Mac).

Figura 2: Usuario utilizando ARgos

El proceso de calibrado del sistema se ha creado como una utilidad independiente del sistema principal de ARgos. Una vez calibrado, la aplicación proporciona los ficheros YAML, con los parámetros intrínsecos y extrínsecos, que necesita ARgos para el calculo del registro.

El proceso está separado en una aplicación cliente (calibrationToolBox_client) que está alojada en la Raspberry Pi, y otra aplicación servidor (calibrationToolBox_server) que se podría ejecutar en cualquier otro equipo.

En un principio se diseñó como un único programa que ejecutaba en la Raspberry Pi, pero si se tomaban muchas capturas para conseguir una calibración más precisa, el sistema se ralentizaba, y el tiempo de calibrado crecía excesivamente.

Se ha empleado esencialmente el enfoque de Zhang [1] para calibrado de cámaras. Se utiliza un patrón tipo tablero de ajedrez, en la que se alternan cuadrados blancos y negros, de dimensiones conocidas. El patrón se imprime y se pega sobre una superficie plana rígida.

Patrón tipo tablero de ajedrez

Se debe dejar una zona despejada a continuación del tablero de ajedrez, ya que en esta zona se proyectará el patrón que utiliza el proyector para su calibrado. Se debe prestar atención en que orientación es pegado, ya que si se colocase al revés, la proyección dinámica se realizaría fuera del panel.

Configuración

Antes de iniciar el proceso de calibrado, debemos definir los parámetros de configuración. Tomamos la medida del lado de un cuadrado para proporcionarla al programa de calibrado, de esta forma las unidades de medida del sistema de referencia se corresponden a medidas reales.

Además del tamaño del lado debemos indicar el número de esquinas en vertical y horizontal que tiene el patrón que estamos utilizando. Gracias a esto, no estamos atados a realizar el calibrado con un patrón particular, que tenga unas medidas concretas. Basta indicar las características del patrón que vamos a utilizar para realizar un calibrado correcto.

Los otros dos parámetros de la configuración, corresponden al desplazamiento (en los ejes X e Y) de la proyección del patrón de círculos asimétrico. El objetivo es ajustar la visualización de la proyección para que el patrón proyectado aparezca junto al patrón impreso.

Los últimos parámetros son las dimensiones de las imágenes, tanto de la cámara como del proyector. Se pueden utilizar resoluciones distintas, pero en ARgos, se he optado por utilizar la misma en ambos dispositivos.

Calibrado de la cámara

A continuación, colocamos la superficie bajo la cámara, en distintas orientaciones y distancias, para obtener una serie de imágenes en los que se encuentre visible el patrón.

Cuando el proceso disponga de al menos 20 imágenes válidas, realizará los cálculos para obtener los parámetros intrínsecos de cámara y los grabará en el fichero calibrationCamera.yml

Se considera una captura válida aquella que al aplicar los cálculos de calibrado, devuelve un error de reproyección menor de 0.25.

Calibrado del proyector

El siguiente paso consiste en calibrar el proyector. Al comienzo de este estado, se proyecta un patrón de círculos asimétrico, en una posición fija.

Patrón de círculos asimétricos

Colocar la superficie, de tal forma, que el patrón proyectado quede junto al del tablero de ajedrez. Volver a mover el patrón el espacio de la proyección hasta que el sistema adquiera 5 imágenes más. Para la aceptación de estas 5 imágenes, el error de reproyección cometido no debe ser mayor de 0.35.

Calibrado estereo (camara-proyector)

En ese momento, la calibración pasa al modo dinámico, y los puntos proyectados se generan en función de la posición que se encuentre el tablero de ajedrez.

Tras capturar 15 imágenes con los puntos dinámicos, se refinan los cálculos correspondientes a los parámetros intrínsecos del proyector, y finalmente, se calculan los parámetros extrínsecos (matrices de rotación y traslación) entre la cámara y el proyector.

Los parámetros de calibrado se almacenan en los ficheros calibrationProjector.yml y cameraProjectorExtrinsics.yml.

Test de verificación del calibrado

Una vez realizada la calibración se iniciará un test para comprobar que se ha hecho correctamente. El test consiste en proyectar un círculo sobre las cuatro esquinas exteriores del patrón de tablero de ajedrez. Al mover el patrón los puntos proyectados deben siempre permanecer alineados con las esquinas.

Conclusiones

Tanto el número de imágenes que se deben detectar antes de pasar a la siguiente fase, como los errores de reproyección máximos permitidos por la cámara y el proyector, son también configurables. Tras realizar numerosas pruebas variando estos parámetros, los mejores resultados manteniendo el compromiso precisión-tiempo-consumo, se llega a la conclusión que los valores antes descritos son los que mejor se ajustan.

Tal y como se describe, el proceso completo de calibrado se puede realizar en varios minutos. Asimismo, mientras que la cámara y el proyector mantengan su posición y rotación entre ellos, no es necesario realizar una nueva calibración y es posible desplazar todo el sistema.

[1] Zhang, Zhengyou. Flexible camera calibration by viewing a plane from unknown orientations. Proceedings of the Seventh IEEE International Conference on Pattern Analysis and Machine Intelligence, 1999. Páginas 666-673

En una de las primeras etapas del proyecto y para probar la arquitectura de red, se decidió realizar un modelo virtual de todo el sistema ARgos, que únicamente mostrara las matrices de transformación calculadas por el sistema.

Este modelo del sistema cumplía con las siguientes características:

• Visualización directa del entorno del sistema.
• Envío de fotogramas a través de red mediante sockets.
• Envío de matrices de modelo, vista y proyección del documento a través de la red.
• Visualización en tiempo real de los fotogramas y matrices recibidas en el servidor.
• Interacción del usuario con diversos elementos del entorno mediante teclado y ratón.

En este post únicamente se comentarán las partes relevantes del prototipo que tengan que ver con la retransmisión de las imágenes, entre otras cosas.

El sistema se ayuda de una primitiva versión cliente de la clase TaskDelegation de BelfegAR, la cual inicia un bucle de envío de información constante al servidor. La información enviada se compone de las matrices de modelo, vista y proyección, y del fotograma capturado por la cámara en ese momento. La información es copiada en un buffer como una secuencia de bytes y transmitida al servidor para su procesado. Cabe destacar, que los sockets UDP por estándar no permiten el envío de paquetes que ocupen más de 65536 bytes, por lo que la imagen se comprimía en JPEG manteniendo un 80% de la calidad original. A continuación se muestran los métodos empleados para construir el buffer de datos que se enviarán al servidor.

void TaskDelegation::addMatrix(const float* matrix) { int size = 16 * sizeof(float); unsigned char sMatrix[size]; memcpy(sMatrix, matrix, size); _buff.insert(_buff.end(), &sMatrix[0], &sMatrix[size]); } void TaskDelegation::addCvMat(const cv::Mat& mat) { std::vector<unsigned char> mat_buff; std::vector<int> params; // Compress the image, since UDP packet <= 65536 bytes params.push_back(CV_IMWRITE_JPEG_QUALITY); params.push_back(80); cv::imencode(".jpg", mat, mat_buff, params); int length = mat_buff.size(); unsigned char packet_size[sizeof(int)]; memcpy(packet_size, &length, sizeof(int)); _buff.insert(_buff.end(), &packet_size[0], &packet_size[sizeof(int)]); _buff.insert(_buff.end(), mat_buff.begin(), mat_buff.end()); }

Se muestra también a continuación el bucle de envió de datos que ocupa a la aplicación:

... // Initializing stuff cv::Mat currentFrame; TaskDelegation* td = NULL; if(argc > 1) { td = new TaskDelegation(); td->setEndpoint(argv[1], argv[2]); // [1] -> ip | [2] -> port } while(1) { ... // Gets camera frame and store it in the currentFrame object if(td) { td->addMatrix(projection_matrix); // Adds a matrix (float[16]) td->addMatrix(modelview_matrix); // Adds another matrix td->addCvMat(currentFrame); // Adds a cv::Mat td->send(); // Sends the built buffer through the socket } ... } ...

Una vez enviada la información, se procede a su procesado en el servidor, mediante un script Python ejecutado por la aplicación construida en Blender.

A continuación se muestra el código del servidor que permanece a la espera de recibir la información del cliente y el código de las funciones que procesan las matrices y fotogramas recibidos.

def listen(cont): global sock obj = cont.owner while 1: data, addr = sock.recvfrom(32768) ... raw_matrix = data[0:64] buff.append("\n> Projection Matrix:\n") buff.append(getPrintableMatrix(parseMatrix(raw_matrix))) raw_matrix = data[64:128] buff.append("\n> ModelView Matrix:\n") buff.append(getPrintableMatrix(parseMatrix(raw_matrix))) cv_mat_length = data[128:132] mat_length, = struct.unpack("<i", cv_mat_length) raw_cv_mat = data[132:len(data)] parseCvMat(raw_cv_mat) ... def parseMatrix(raw_matrix): m = struct.unpack("<16f", raw_matrix) # Unpack matrix from C memcpy m = ["{:.2f}".format(i) for i in m] # 2 decimals per element m = [[m[0], m[4], m[8], m[12]], # Set to row-major order [m[1], m[5], m[9], m[13]], [m[2], m[6], m[10], m[14]], [m[3], m[7], m[11], m[15]]] return m def parseCvMat(raw_cv_mat): f = open("frame.jpg",'wb') f.write(raw_cv_mat) # Writes the received image to disk f.close() # in order to display it after

Una vez recibida y procesada la información, solo queda mostrarla mediante Blender y permitir la interacción del usuario, la cual se realiza mediante las teclas de movimiento WASD y el botón izquierdo del ratón.

A continuación se muestran algunas capturas de la aplicación desarrollada.

Aquí podemos ver una vista general del prototipo. Existen varios elementos interaccionables en la escena, como el portátil, el cual es el elemento principal del prototipo y sobre el cual se encuentra integrada toda la lógica.

Cuando interactuamos con el portátil se arranca un servidor que permanece a la escucha después de iniciar un socket UDP.

Cuando ARgos envía información al prototipo, el portátil empieza a mostrar información sobre las matrices de transformación de los documentos detectados.

Aquí podemos ver el fotograma recibido en tiempo real capturado por ARgos.

Explicadas las iteraciones que se llevaron a cabo para el desarrollo del servidor, se presentan a continuación las iteraciones de cliente.

Iteración 1

En esta primera iteración, se empezó implementando el sistema de superficies aceleradas por hardware mediante EGL para conseguir un contexto de OpenGL ES funcional y estable. Se implementó además la carga, compilación, enlazado y activación de programas OpenGL basados en shaders.

Se creó también el primer componente gráfico; RectangleComponent. Éste solo se dibujaba de forma fija en el escenario, y la posición llegó a controlarse modificando directamente los vértices de la figura en lugar de aplicar matrices de transformación.

Pese a que todo acabó funcionando correctamente, surgieron varios problemas al emplear la versión empotrada de OpenGL, ya que al emplear un cauce programable, la dificultad aumentaba al eliminar el uso de las matrices MODELVIEW y PROJECTION, y las correspondientes operaciones con los métodos glPushMatrix y glPopMatrix para operar sobre ellas. También se eliminó de esta versión los métodos de construcción de objetos 3D, como glBegin, glVertex y glEnd, pasándose a utilizar listas de vértices con el shader correspondiente para su renderizado. El nuevo modo de funcionamiento supuso a OpenGL el soporte de paralelismo en su cauce de renderizado, además de aumentar el rendimiento general de las operaciones, al no dejar toda la carga al procesador, en el que se requería al menos la invocación de una función por vértice.

La meta que se propuso para esta primera iteración fue conseguir un contexto de OpenGL ES sobre el que poder trabajar, la instalación de dependencias del proyecto y la generación de los Makefiles necesarios para su construcción.

Iteración 2

Una vez obtenido un entorno de despliegue gráfico funcional con un primer componente gráfico, se procedió a mejorar dicho componente para que se le pudieran aplicar varias transformaciones 3D. La primera transformación que se probó fue la de translación, para comprobar si funcionaba correctamente. Una vez implementada, se implementaron operaciones para escalar y rotar la figura.

Se creó además un nuevo componente gráfico; LineComponent. A partir de este, se comprendió mejor el uso de las listas de vértices. Manipulando los colores de las líneas e instanciando tres de ellas, se consiguió crear un eje de coordenadas.

También se investigó el tema de la compilación cruzada, ya que la construcción del sistema usando directamente la Raspberry Pi podía durar varios minutos.

En esta iteración, se afianzaron los conocimientos sobre OpenGL ES 2.0 y se ideó un nuevo componente gráfico. También se aplicaron las primeras transformaciones que permitían mover, escalar y rotar un objeto. Por último se empezó a hacer uso de un entorno de compilación cruzada para construir el sistema.

Iteración 3

En esta iteración GrayAR ya podía detectar documentos y proporcionar sus matrices de modelo y vista, además de la matriz de proyección del entorno. Gracias a esto, se pudieron aplicar dichas matrices a los componentes gráficos para posicionarlos sobre los documentos.

Surgieron ciertas confusiones al principio relacionadas con las unidades del mundo de OpenGL y las definidas como centímetros en la realidad.

Se realizó un refactorizado completo a los dos componentes gráficos existentes, extrayendo comportamiento y atributos comunes y se creó la clase abstracta GraphicComponent, de la cual heredarían el resto de componentes gráficos en el futuro.

Se creó además el componente gráfico ImageComponent, el cual suponía el reto de cargar imágenes desde disco. Se estudiaron por tanto algunas bibliotecas que aportaran dicha funcionalidad, deduciendo que era la mejor opción, por ser una biblioteca pequeña y que solo realiza la función que queríamos: cargar imágenes.

También se creó en esta iteración el componente de texto o TextComponent, necesario para renderizar texto, usado en primera instancia para mostrar el número de fotogramas por segundo que alcanzaba el sistema.

Esta iteración concluyó de esta forma con un sistema de componentes gráficos ya afianzado, y fácilmente escalable y mantenible, que se adaptaban correctamente al documento.

Iteración 4

GrayAR requería una forma de mostrar un patrón de círculos configurable para su herramienta de calibración. Por ello, se ideó un nuevo componente gráfico que permitiera dibujar círculos de forma sencilla; CircleComponent. La lógica de creación del círculo fue realizada en el propio shader para aliviar la carga de la unidad. Esto supuso el estudio más en profundidad del lenguaje .

También se creó un componente gráfico que permitiera cargar vídeos desde el disco; VideoComponent. Debido a limitaciones de tiempo, se decidió realizar la decodificación del vídeo por software mediante OpenCV.

Debido al bajo rendimiento que ofrecía la plataforma, se ideó una arquitectura de red que permitiera ejecutar las tareas de visión por computador en una máquina de mayor potencia. Se esbozó pues una primera versión del subsistema de delegación de tareas, que permitía el envío de matrices serializadas por red, mediante sockets .

Los resultados de esta iteración pues, fueron el desarrollo de dos nuevos componentes gráficos y un primer esbozo del subsistema de delegación de tareas.

Iteración 5

En esta iteración, se consolidó el subsistema de delegación de tareas, permitiendo enviar más tipos de datos por red y estructurando el sistema de tal forma que hiciera un uso obligatorio de la delegación de tareas.

Se implementó también la arquitectura del subsistema de comunicaciones para poder migrar GrayAR al servidor. Con la arquitectura de red montada, se estableció el contrato de comunicación que debían seguir tanto el cliente como el servidor para la transmisión de la información.

A estas alturas del desarrollo, el sistema ya contaba con la arquitectura necesaria y escalable para añadir nuevos componentes gráficos y tipos de datos en la comunicación cliente-servidor.

Iteración 6

Una vez establecida una arquitectura cliente-servidor funcional, se pretendió cubrir en esta iteración el sistema de soporte al usuario mediante videollamadas con la creación del VideoStreamComponent. Para ello, se tuvo que cambiar la arquitectura del servidor para soportar una nueva comunicación a través de otro puerto. Se implementó una comunicación mediante sockets paralela a la comunicación principal de los subsistemas de delegación de tareas y comunicación para el envío de vídeo desde el servidor.

También se implementó cierta interacción primitiva con el usuario, de tal forma que el cliente decidía que componentes gráficos mostrar en función del documento analizado. Esta primera aproximación permitía darle la vuelta al documento para iniciar una videollamada, de tal forma que el documento por detrás conformaba otro identificador distinto a la otra cara, y cancelarla al volver a darle la vuelta.

Esta iteración concluyó con la implementación funcional del componente de videollamadas y una primera aproximación a lo que sería la interacción del usuario con el sistema.

Iteración 7

En vistas a crear componentes gráficos más complejos a partir de otros ya existentes, y como si de un programa de dibujado se tratará, se creó el RenderToTextureComponent. Se ideó en primera instancia para crear mensajes de ayuda que indicaran al usuario las posibles acciones a realizar con el documento.

El estudio del uso de la técnica de «render a textura», requirió cierto tiempo por introducir una gran variedad de nuevos conceptos como framebuffers compuestos de renderbuffers y texturas, además del uso de una matriz de proyección ortogonal única para este componente.

Finalmente, se creó un método ayudante para construir dichas ayudas al documento mediante parámetros como el tamaño de la imagen de ayuda, su color y los mensajes que contendría.

Esta iteración concluyó con la creación de un componente gráfico que permitía formar nuevos componentes más complejos, y un método para crear uno de esos componentes específicos.

Iteración 8

Debido a la cantidad de componentes gráficos existentes a estas alturas del proyecto, se creo un gestor que se ocupara de administrar su creación, actualización, dibujado y destrucción, es decir, su ciclo de vida completo. Estamos hablando de la clase GraphicComponentsManager.

También se creó un contenedor de componentes gráficos o GCCollection que permitiera la gestión conjunta de componentes que compartieran cierto propósito. Desde este momento, el gestor de componentes gráficos se encargaba de administrar estos contenedores.

El gestor también proporcionaba métodos creacionales de componentes gráficos complejos como botones y paneles de texto empleando componentes de «render a textura», y videollamadas sobre superficies de imagen mediante colecciones de componentes individuales.

El objetivo de esta iteración se vio reflejado en el afianzamiento del subsistema de representación gráfica.

Iteración 9

Con el subsistema de representación gráfica finalizado, se inició y completó el desarrollo del subsistema de audio en esta iteración.

Se adquirió una placa con altavoz integrado que se conectó a la Raspberry Pi para proporcionarle posibilidades de audio, ya que por defecto ésta no incluye características de sonido.

Se empleó una frecuencia de 16.000 Hz para la reproducción de sonidos, la cual proporcionaba una calidad adecuada al altavoz utilizado.

También se realizaron algunas mejoras en el código fuente, y se corrigieron algunos bugs. Después se realizó un refactorizado global para eliminar funciones y partes de código obsoletas.

Esta iteración supuso el funcionamiento de la mayor parte del sistema. Solo quedaba especificar las acciones a realizar por cada documento analizado.

Iteración 10

En la iteración final, se estudió una manera de facilitar al usuario la especificación de diferentes acciones a realizar para ciertos documentos. Se ideó pues el subsistema de scripts, que permitía definir archivos interpretables por el servidor para su procesado y posterior envío de resultados al cliente.

El desarrollo del subsistema de scripts se basó en una implementación ya realizada para el del «Curso de Experto en Desarrollo de Videojuegos (3ra. edición 2013/2014)», The Secret of Liches [1]. La nueva implementación supuso una mejor estructura del código y un mayor uso del polimorfismo para la invocación de funciones scripteables desde C++.

Durante esta iteración, también se escribió parte de la documentación del proyecto y el manual de usuario del sistema, entre otros documentos como el manual de compilación cruzada, que en un principio se encontraba externo a este documento.

[1]: Vídeo del videojuego disponible en https://www.youtube.com/watch?v=J5ap3Gi4Dq8

En esta sección se listan y detallan los recursos software y hardware empleados en la construcción de la plataforma.

Hardware

• Raspberry Pi - Se trata de la unidad de detección y despliegue del sistema. Se ha utilizado el modelo B con 512 MB de memoria RAM.

• Raspberry Pi Camera Board - Se trata de una minicámara de 5MP con un sensor Omnivision 5647, que se conecta directamente a la Raspbery Pi a través de un conector CSI.

• Proyector portátil - Se trata del medio principal que permite el despliegue de gráficos del sistema. El proyector empleado es un Optoma PK320 que soporta una resolución panorámica máxima de 854x480.

• Amplificador de Audio - Se trata de un circuito integrado LM386 montado en una placa de test con un altavoz de 1W para proporcionar audio al sistema.

• Tarjeta de memoria - Se emplea una MicroSDHC Trascend de 32GB clase 10, como unidad de almacenamiento de la Raspberry Pi. Proporciona una velocidad de lectura y escritura de 20 MB/s y 17 MB/s respectivamente.

• Equipo informático - Para el desarrollo del proyecto ha sido necesario hacer uso de un computador conectado por red a la plataforma Raspberry Pi, para poder acceder remotamente a ella y de esta forma ejecutar las pruebas. El equipo es un Intel Core i7-2600K 3.4 GHz 4 núcleos y dos hilos por núcleo 16 GB de RAM y Nvidia GeForce GTX 560 Ti.

Software

A continuación se enumeran las diversas herramientas software empleadas y diferenciadas por categorías:

Lenguajes de programación

• C++ - El lenguaje empleado para el desarrollo del proyecto ha sido C++, debido a la eficiencia y velocidad de ejecución que proporciona a la hora trabajar en aplicaciones y sistemas en tiempo real. También por ser el estándar referente en bibliotecas gráficas y de visión artificial.

• GLSL - El lenguaje de programación de shaders para OpenGL. Para la elaboración de los distintos componentes gráficos se hace uso de distintos shaders que sirvan para dibujar círculos, aplicar texturas o simplemente transformar los vértices de los componentes.

Sistemas Operativos

• Debian - Es una distribución de GNU/Linux desarrollada y mantenida por una comunidad de voluntarios. Es una de las famosas y un gran número de distribuciones están basadas en ella. Para el desarrollo del proyecto se ha utilizado la versión unstable.

• Raspbian - Es una distribución de GNU/Linux basada en Debian Wheeze especialmente diseñada y optimizada para la ejecución en la placa Raspberry Pi con CPU ARMv6

Aplicaciones de desarrollo GNU

• GNU Emacs - Editor y entorno de desarrollo. Se ha utilizado la generación del código fuente y la escritura de la documentación. Se han empleado, además, algunos plugins como ECB, que añade al editor funcionalidades propias de un entorno de desarrollo completo.

• GNU Make - Herramienta para la compilación incremental, con soporte multiproceso.

• GNU GCC - La colección de compiladores GNU. En concreto se ha utilizado el compilador de C++ (g++).

• GNU GDB - Se trata del depurador por excelencia de los sistemas GNU/Linux.

Bibliotecas

• OpenCV - Biblioteca libre que proporciona funciones dirigidas principalmente para el desarrollo de aplicaciones de visión por computador en tiempo real. La versión utilizada es la 2.4.9

• OpenGL ES 2.0 - Se ha empleado OpenGL por soportar aceleración gráfica en la unidad de detección y despliegue.

• RapidXML - Se trata de un intérprete o parser para archivos XML.

• RaspiCam - Es una biblioteca para la utilización de la cámara Raspberry Pi Board desarrollada en C++ por el grupo de investigación «Aplicaciones de la Visión Artificial» de la Universidad de Córdoba.

• SDL Mixer - Por su facilidad de uso y potencia se ha empleado esta biblioteca para la reproducción de audio del sistema.

• freetypeGlesRpi - Como se comentó anteriormente, son escasas las bibliotecas de carga y despliegue de textos basados en fuentes true-type. Esta biblioteca ofrece una solución a tal problema.

• GLM - Se trata de una biblioteca matemática que abstrae al desarrollador de las operaciones algebraicas empleadas a la hora de realizar transformaciones 3D.

• Simple OpenGL Image Library (SOIL) - Se trata de una pequeña biblioteca escrita en C usada principalmente para cargar imágenes como texturas en OpenGL. Soporta una gran cantidad de formatos, como PNG, JPEG y BMP, entre otros.

• Boost.Asio - C++ no especifica nada relativo a redes o sockets en su estándar. Por esto mismo se ha empleado la biblioteca Asio de Boost para gestionar la comunicación por red.

Control de Versiones

• Git - Sistema de control de versiones distribuido. Como repositorio central se ha utilizado la plataforma GitHub.

Con la idea general del proyecto definida, se adquieren un par de Raspberry Pi y se realiza una búsqueda de pico-proyectores candidatos para utilizar. El proyector debe tener un precio ajustado, ser lo más reducido posible, y además, tener una luminosidad suficiente para que las proyecciones sean visibles en estancias iluminadas.

Una vez recibida la Raspberry Pi, se procede a la configuración del entorno de trabajo. Este proceso incluye la instalación del sistema operativo Raspbian, la biblioteca OpenCV, compiladores, editores y la configuración del servicio de SSH para poder controlar la Raspberry desde el puesto de trabajo.

Finalmente, se mantuvo una reunión con los miembros de la Asociación ASPRONA para explicarles los objetivos del proyecto y obtener de ellos, un escenario de casos de uso basados en la experiencia que tienen en la inserción laboral de personas con discapacidad. Estos casos de uso, se transformó en una especificación de requisitos para nuestro sistema.

Iteración 1

Las limitadas capacidades de la Raspberry Pi y la experiencia que otros programadores han tenido a la hora de trabajar en sistemas de visión por computador en este dispositivo, nos pone en alerta de que es posible, llegado un momento, la alta carga de computo que tienen los procesos de visión por computador afecten al rendimiento y perdamos la sensación de tiempo real. Las consecuencias de esto, es que sea necesario que los procesos más costosos deban ser ejecutados en otro dispositivo o computador con mejores prestaciones.

Partiendo de las premisas anteriores, no queda otra opción que realizar una arquitectura completamente modular y con todos los subsistemas desacoplados. Una clase core será la encargada de inicializar todos los subsistemas, establecer las comunicaciones entre ellos, y ejecutar la lógica de usuario soportada dentro de un bucle infinito.

El objetivo de esta primera iteración es obtener una arquitectura básica, que iremos completando y refinando en cada una de las sucesivas iteraciones. Se decide que el sprint abarque la construcción y pruebas de las siguientes historias:

• Captura de imágenes. La Raspberry tiene la opción de conectar cámaras USB. Se construye un módulo de captura de vídeo, utilizando las funciones de la clase VideoCapture de OpenCV, que proporciona los distintos frames necesarios para dar soporte al resto de módulos del sistema.

  Para la medida de rendimiento, se implementa el cálculo de los FPS que da el sistema a la salida y que nos va a determinar si se obtienen resultados aceptables para un sistema de tiempo real. Los primeros resultados son mucho peores de lo esperado. A una resolución de 320x240 píxeles y sólo realizando el proceso de captura y visualización de los frames capturados en pantalla, se observa un lag de 2 segundos y una tasa de 2 FPS.

  Si estos valores son inadmisibles en un sistema en tiempo real con una arquitectura tan básica, y sin realizar ningún tipo de procesado en la imagen, cuando se deba realizar algún tratamiento a la imagen o computo adicional, el sistema no será usable, con una sensación de bloqueo del sistema para el usuario.

  Se vuelven a realizar las pruebas con otra cámara USB más moderna (Logitech S720) y afortunadamente los resultados mejoran sensiblemente, a 6 FPS y hasta 10 FPS para imágenes obtenidas en blanco y negro.

• Detección de una hoja de papel. Mediante segmentación de la imagen obtenida, se detecta una hoja de papel y se obtiene la posición de sus 4 esquinas en píxeles de pantalla. Esta funcionalidad se encapsula dentro de la clase PaperDetector Durante las primera fase de pruebas nos pone en situación de los numerosos factores que influyen en este tipo de sistemas. El primero de ellos es la iluminación. El tipo de luz (natural, fluorescente, incandescente,...), intensidad de la luz natural (luz por la mañana, al mediodia o por la tarde), dirección de la luz (crea sombras en uno u otro sentido), los reflejos producidos por las superficies se convierten en interferencias en forma de grandes manchas en la imagen. Incluso se han detectado variaciones en la detección al encontrase varias personas entre el sistema y una ventana.

Iteración 2

Los objetivos de esta iteración venian condicionados por los malos resultados obtenidos en el sprint anterior. Hay que conseguir mejorar enormente los resultados anteriores o la viabilidad del proyecto se verá seriamente afectada.

• Optimización de la captura de imágenes. Durante las pruebas de la iteración anterior, con sólo cambiar la cámara USB se obtuvieron grandes mejoras, por lo que la elección de la cámara era un elemento importante. Tras consultar en diversos foros especializados, se decide que la mejor opción es utilizar la Raspberry Pi Camera Board. Esta cámara está especialmente diseñada para utilizarse en la Raspberry, y se conecta directamente al conector CSI de la placa mediante un cable plano flexible de 15 pines. Dispone de un sensor de 5MP de resolución y puede llegar a grabar vídeo a 1080p a 30 fps.

  El gran inconveniente de es que la cámara no incluye drivers video4linux, por lo que cualquier biblioteca para lectura de cámaras web estándar, OpenCV incluido, no es capaz de obtener los frames producidos. Se investiga la manera que tienen las aplicaciones para acceder a la información de la cámara, y se encuentran unos drivers en desarrollo, basados en la API MMAL, que ha liberado la Universidad de Córdoba.

  Tras utilizar en el módulo de captura los nuevos drivers para la Raspberry Camera Board, se realizan de nuevo los test de rendimiento, y obtenemos casi 30 PFS, que es un buen resultado para aplicaciones en tiempo real.

• Calibrado de la cámara. Se construye un programa externo para el calibrado de la cámara basado en un patrón de tablero de ajedrez. Esta primera versión, devuelve un fichero XML con los parámetros intrínsecos de la cámara y los coeficientes de distorsión obtenidos, pero no tiene en cuenta el error de reproyección.

• Sistema básico de cálculo de homografías. En esta primera fase, los cálculos son los necesarios para realizar el registro y visualizarlo en la pantalla del ordenador. Dentro del proyecto, se crea la clase CameraModel encargada de leer los ficheros de calibración y almacenar los parámetros propios de la cámara que serán utilizados para el cálculo de los parámetros extrínsecos.

  Para el cálculo y almacenamiento de la posición de los folios respecto a la cámara se construye la clase Paper.

  Las pruebas realizadas al módulo de cálculo de la posición y rotación del papel, son satisfactorias, y se puede comprobar que el dibujado de ejes de coordenadas, o distintos poliedros en el espacio 3D es correcto y perfectamente alineado con el papel.

• Dibujado mediante OpenCV. En la iteración anterior se realizaron una serie de funciones auxiliares para dibujado de contornos, puntos y polígonos mediante OpenCV que sirviesen de soporte para el «modo debug». Para la iteración actual, estas funciones se ha aumentado con dibujado de ejes de coordenadas, cubos y ortoedros para validar los cálculos de la posición y rotación de los folios. También permite recibir una ventana con la imagen por medio de SSH. Con todas estas funciones se ha creado la clase estática DrawCV.

Iteración 3

El siguiente paso es incorporar el proyector al sistema. Acoplando la Raspberry Pi sobre el proyector y colocando la raspiCam junto a la lente obtenemos un conjunto compacto y reducido. El sistema se monta sobre un trípode y se coloca en dirección a la mesa.

Los objetivos son, por tanto, obtener un sistema de calibrado. Debido a la complejidad de la tarea, se establece como la única tarea a realizar en este sprint.

• Calibrado del sistema cámara-proyector. Un proyector se calibra usando los mismos algoritmos que una cámara ya que puede considerarse como una «cámara invertida». Sin embargo como el proyector no ve, y el método no es tan directo como en el caso de una cámara. Además es necesario realizar los cálculos para la transformación entre el sistema de referencia de la cámara y el sistema de referencia del proyector.

  El estudio de distintas técnicas de calibrado nos llevó a considerar dos procedimientos. El primero, siguiendo el enfoque de Zhang, en el se utilizan patrones planos, y el propuesto por Daniel Moreno y Gabriel Taubin, basado luz estructurada.

  Aunque según los papers consultados, el método basado en luz estructurada, es más preciso que otras técnicas de calibrado, el procedimiento es más costoso de realizar. El método de Zhang, permite un procedimiento más flexible, no necesita una preparación exhaustiva de la escena y tiene una precisión aceptable para los objetivos de nuestro proyecto.

  Con el código para el calibrado de cámaras de la iteración anterior, realizamos una ampliación para añadir la funcionalidad del calibrado del proyector.

  Para calibrar el proyector, es necesario obtener un conjunto de coordenadas 3D-2D correspondientes. Las coordenadas se determinan utilizando la cámara situada en una posición con una vista similar a la que tendría el proyector. El método consiste en realizar una proyección de un plano de calibrado y establecer la correspondencia entre lo proyectado y lo que ve la cámara.

  Ahora dispondremos de los puntos 3D en el sistema de referencia global (el patrón), y también su proyección (puntos 2D en la imagen) en el sistema de referencia de la cámara y en el sistema de referencia del proyector.

  Finalmente, aplicando un procedimiento de calibrado estéreo como el que proporciona OpenCV obtenemos la transformación entre la cámara y el proyector.

  El resultado, con los parámetros intrínsecos y extrínsecos, se escribe en ficheros YAML para cargarlos en el sistema. Mientras que la cámara y el proyector mantengan su posición y rotación entre ellos, no es necesario realizar una nueva calibración y es posible mover todo el sistema.

  Entre las decisiones tomadas en este sprint, fue realizar el calibrado como una aplicación externa al sistema. Esto nos permite la reutilización del módulo para otros sistemas estéreo.

  Otras decisión fue la resolución de imagen con la que trabajaría el sistema. El proyector tiene una resolución nativa de 854x480 en formato 16:9, pero la Raspberry Pi no la soporta. Se eligió una resolución de 1280x720, pero con este tamaño de imagen, el rendimiento disminuía significativamente. También se utilizó 800x600 en formato 16:9, pero la distorsión que realizaba el proyector para mostrar la imagen en formato panorámico no podíamos medirla para realizar una corrección, y los puntos calculados no correspondían con los objetos situados sobre la mesa.

  La resolución que se estableció finalmente fue de 800x600 en formato 4:3. Se perdía algo de superficie de proyección, pero con aumentar un poco la distancia entre el proyector y la mesa se compensaba esta área, y además, el rendimiento del sistema con esta resolución era adecuado y entraba dentro de los parámetros para un sistema de tiempo real.

Iteración 4

Desde la iteración 2, se arrastraba un pequeño bug en el cálculo de los parámetros extrínsecos del papel. Entre los objetivos planificados en esta iteración se decidió que también se corrigiese este bug, quedando finalmente el sprint backlog con los siguientes elementos:

• Corrección de la orientación del papel. En el cálculo de los parámetros extrínsecos del papel, dependiendo de la posición del papel, el sistema confundía la orientación y consideraba que el papel se encontraba apaisado cuando realmente no era así.

  La corrección del bug fue relativamente sencilla. Tras una serie de pruebas rotando la hoja de papel para comprobar en que casos se producía el error, se observó que el problema era debido a como OpenCV enumera las esquinas del papel.

• Detector de documentos mediante descriptores de imágenes. Se eligió utilizar SURF como detector y descriptor de características debido que es más rápido y robusto que otros algoritmos. Aun así, la implementación de esté modulo se realizó utilizando los wrappers que proporciona OpenCV para la construcción de detectores y descriptores, y que tiene como ventaja, cambiar el algoritmo aplicado sin necesidad de modificar la implementación, únicamente modificando en el constructor un string con el método que queramos utilizar (BRISK, ORB, SURF,...).

• Optical Flow. Para la estimación y descripción del movimiento, se implementó Optical Flow (Lucas-Kanade) que proporciona herramientas para detección, segmentación y segumiento de la hoja de papel en la escena a partir de un conjunto de imágenes. En etapas posteriores, debido a la oclusión que se realiza sobre el papel, se decidió que no cumplía las expectativas como metodo de tracking y se rechazó.

Iteración 5

A estas alturas del desarrollo del proyecto, la carga de trabajo que debe soportar la Raspberry Pi es muy significativa. Se aprecia que el rendimiento se ve afectado al incluir la detección de documentos, ya que es una tarea costosa para el sistema, y aun queda por implementar el módulo de interacción natural, que se trata también de una tarea con gran carga de trabajo.

• Implementación de Arquitectura cliente/servidor Como ya se venía observando, en cada iteración el rendimiento general del sistema en la Raspberry era cada vez menor. La solución fue crear una arquitectura cliente-servidor que permitiese la delegación de tareas entre la Raspberry Pi y un servidor. Este servidor, seria el encargado de realizar la ejecución de los módulos más costosos del sistema y descargar a la Raspberry Pi, para realizar las tareas de captura y representación más holgadamente.

  Gracias a que se tuvo en cuenta que este caso pudiese ocurrir, y la decisión temprana construir un sistema modular y desacoplado, la migración al servidor y la conexión mediante la unidad de delegación de tareas fue prácticamente transparente y sin realizar modificaciones en los módulos creados.

  Aprovechando esta arquitectura, también se separó el programa de calibración, lo que supuso una reducción considerable del tiempo empleado para realizar el calibrado del sistema cámara-proyector.

• Implementación de un histórico de percepciones Al igual que en ARToolKit, se desarrolla una función de tratamiento del histórico de percepciones para estabilizar el tracking. Este histórico se implementa almacenando las últimas 4 percepciones similares y realizando una media ponderada, en la que las percepciones recientes tienen más peso que las antiguas.

  Para determinar si son percepciones próximas se establece un umbral. Mediante el uso de esta técnica eliminamos gran parte del efecto tembloroso en la proyección.

• Optimización del proceso de detección de rectángulos La función para detectar hojas de papel implementada en la iteración 1 es muy básica. No permite que exista ninguna oclusión y es muy sensible a la iluminación. Tras un estudio de técnicas alternativas, se opta por implementar el cálculo de la envoltura convexa del contorno. Además de ser un algoritmo más reducido, la mayor ventaja que aporta este método es que tolera ciertos solapamientos en los bordes del papel.

  Para optimizar más la función, se sustituye el método de binarización de la imagen. Se cambia la umbralización adaptativa por el método de Canny. Con este cambio, se obtiene un algoritmo más robusto, más tolerante a la iluminación y que devuelve bordes más finos, con lo que también aumenta la precisión del sistema.

Iteración 6

Esta iteración supone la construcción del sistema de interacción natural de usuario. Al finalizar esta iteración, se podrá realizar acciones sobre los botones que se están desarrollando en la parte cliente, y que permitirán ofrecer una experiencia de usuario muy enriquecida al mostrar información opcional a petición del usuario.

• Segmentación de manos Para extraer el contorno de la mano de la imagen se decide utilizar un filtrado por el color de la piel. Existen numerosos artículos sobre este tema, y todos concluyen que los mejores resultados se obtienen realizando la búsqueda en el espacio de color HSV (Hue, Saturation, Value). Para convertir las imágenes a este espacio de color, es necesario que la captura se realice en color. Hasta esta iteración, la adquisición de imágenes se estaba efectuando en escala de grises, ya que consumía menos recursos, y el color no era una propiedad que necesitásemos.

  Teniendo en cuenta que los procesos de cálculo están en el servidor, obtener las imágenes a color no supuso una pérdida de rendimiento en el sistema. Además, con sólo realizar la conversión a escala de grises de la imagen, los métodos ya implementados y que no necesitan la imagen a color, no tienen que ser modificados.

  La segmentación implementada, se basa en la selección del los píxeles de la imagen que pertenezcan al rango habitual del color de la piel. Para aumentar la tolerancia del algoritmo, se le aplica a la imagen una serie de filtros, y finalmente se obtiene una máscara con la región de la mano en la imagen.

• Cálculo de la posición del dedo Una vez obtenida el contorno de la mano, se debe buscar su posición. En un principio se pensó en implementar el reconocimiento de todos los dedos de la mano, pero se optó por sólo reconocer el índice. Esta decisión, vino determinada por la funcionalidad de interacción que se iba a implementar, que era la pulsación de un botón, por lo que examinar la posición del resto de los dedos es, en principio, innecesaria.

Iteración 7

Con el sistema de interacción de usuario funcionando, se advierte que el módulo de detección de papeles funciona correctamente cuando no hay solapamientos o si la oclusión se encuentra muy próxima a los bordes. En la reunión del sprint se considera que se debe implementar una nueva mejora de la detección de papeles.

• Detección de papeles con solapamiento. Analizando los solapamientos que se realizan sobre el papel en función de las posiciones de la mano, se observa que normalmente quedan visibles partes de los lados del papel. Se decide realizar la búsqueda de segmentos rectos mediante la transformada de Hough y generar las posibles combinaciones de 4 segmentos del conjunto de rectas detectadas. Aquellos que cumplan las restricciones de formar una hoja de papel, serán los posibles candidatos.

  Este segundo método de detección es más costoso que el anterior, por lo que se determinó que de forma predeterminada, el sistema utilizase la detección basada en la envoltura convexa cuando no existiesen solapamientos, y en caso de fallo, se aplicase esta nueva función. Los resultados de las pruebas fueron muy satisfactorias. Esta nuevo algoritmo detectaba el papel aún existiendo grandes solapamientos, tanto en bordes como en esquinas del documento.

Iteración 8

Recibimos de la Asociación ASPRONA una serie de formularios y partes de trabajo para que se implementase un caso real mediante los documentos que ellos utilizaban habitualmente. Las tareas que se realizan son la preparación y entrenamiento del sistema para adecuarlo a la documentación recibida.

Para facilitar el cambio de configuración y no tener que recompilar constantemente, se implementa un gestor de configuración. Este gestor nos permite la modificación de los distintos parámetros del sistema sin la necesidad de recompilar nuevamente el proyecto cada vez que se realiza un cambio. También, de cara a la versión final, se ajustan el sistema para que no sea necesario utilizar una base de fondo negro, que se estuvo utilizando para mejorar el contraste entre papel y mesa.

Se concertó una reunión final con la Asociación ASPRONA, donde tras la demostración, expresaron interés por el sistema y el potencial que tiene para la adaptación y ayuda a personas con discapacidad en el puesto de trabajo.

El objetivo de este proyecto es construir un sistema de ayuda a la gestión de documental que permita el tratamiento directo sobre documentos físicos impresos mediante el uso de técnicas de visión por computador, síntesis visual y auditiva y técnicas de realidad aumentada.

Características de los usuarios

Aunque el usuario final del sistema, será cualquier persona que necesite soporte en la gestión documental de documentos impresos, el fin de esté proyecto es construir un sistema que permita la integración laboral a personas con discapacidad.

El tipo de usuarios a los que estará dirigido son, en primer lugar, personas que pueden presentar un amplio espectro de discapacidades. El sistema debe proporcionar soporte a usuarios con discapacidades sensoriales (visuales y auditivas) e intelectuales.

Restricciones

Debido a los objetivos del sistema, se deben tener en cuenta las siguiente restricciones:

• Funcional en dispositivos móviles. El prototipo final se construirá sobre un dispositivos con arquitectura ARM con limitaciones de tanto en capacidad de computo como memoria. El sistema deberá estar optimizado para este tipo de dispositivos, obteniendo una respuesta fluida y en tiempo real.

• Se debe basar en componentes de bajo coste. Para facilitar la implantación real en el entorno de trabajo, deberá funcionar con componentes de bajo coste, incorporando mecanismos de corrección de distorsión y registro 3D totalmente software.

Interfaces Hardware

• La implementación del sistema se realizará sobre una Raspberry Pi Modelo B de 512MB de RAM y arquitectura ARM.

• La visualización será a través de un pico-proyector mediante conexión HDMI.

• El acceso al sistema y conexión a internet se establece por medio de cable ethernet durante el desarrollo y pruebas, siendo la conexión WiFi el tipo de conectividad final.

Requisitos funcionales

• RF-001: Adquisición de imágenes mediante cámara USB.
• RF-002: Adquisición de imágenes mediante raspiCam.
• RF-003: Sistema de calibrado de cámaras y proyectores.
• RF-004: Implementación de una interfaz natural de usuario.
• RF-005: Control gestual.
• RF-006: Identificación rápida de documentos.
• RF-007: Sistema de cálculo de homografías.
• RF-008: Realización de videoconferencias.
• RF-009: Soporte para completar formularios.
• RF-010: Guiado para clasificación y archivado de facturas.
• RF-011: Entorno configurable por el usuario.

Requisitos no funcionales

• Rendimiento: El sistema debe funcionar de manera fluida y en tiempo real en dispositivos móviles basados en arquitectura ARM. Sólo existirá un único usuario del sistema simultáneamente y los documentos a tratar también se tratarán de uno en uno.

• Seguridad: A parte de la información que se proporcione al usuario directamente, se mantendrá un log donde se registrará toda la actividad realizada en el sistema. Debido al carácter experimental del proyecto, no se tendrán en cuenta la aplicación, por lo menos en la primera fases de desarrollo, de técnicas criptográficas para ficheros, bases de datos o comunicaciones.

• Fiabilidad: Todo tipo de incidente producido en el sistema debe ser controlado y tratado.

• Disponibilidad: La disponibilidad del sistema debe ser de al menos un 99 % del tiempo que esté en ejecución. En caso de caída del sistema se deben proporcionar mecanismos automáticos para que la maquina y el sistema se reinicien y sean nuevamente operativos sin la necesidad de intervención directa del usuario.

• Mantenibilidad: El desarrollo en un dispositivo tan reciente implica que se liberen con relativa frecuencia bibliotecas o controladores, en los que se corrigen bugs y/o mejoran su rendimiento. Seria recomendable hacer una revisión de los módulos actualizados antes de la instalación del sistema para valorar si es relevante el beneficio que aportan y no comprometer el la estabilidad del sistema.

• Portabilidad: El desarrollo se realizará siguiendo estándares, tecnologías y bibliotecas libres multiplataforma, con el objetivo de que pueda ser utilizado en el mayor número de plataformas posibles tanto software como hardware.

Otros requisitos

La distribución del proyecto se realizará mediante la licencia libre GPLv3, para ello se utilizarán bibliotecas compatibles con dicha licencia.