Conferencia sobre Motores Gráficos: OpenSceneGraph

Los próximos días 17 y 18 de Mayo representantes de los grupos de investigación de la Universidad de Jaén y de la Universidad de Málaga visitarán las instalaciones de Robolab.

Durante esos días Pablo Bustos impartirá un par de sesiones sobre iniciación a RoboComp DSL. Pero además podremos disfrutar de una conferencia por parte de Juan Pedro Bandera sobre Motores Gráficos: OpenScenenGraph, el próximo Viernes 17 de Mayo a las 10:00 en el Salón de Grados de la Escuela Politécnica de Cáceres.

Juan Pedro Bandera es profesor de la Universidad de Málaga y ya ha colaborado con Robolab anteriormente, de hecho es el principal responsable de InnerModel, el modelo 3D que usábamos en URSUS.

OpenSceneGraph es el motor que usé para la aplicación ARmole y ya hemos hablado varias veces de él en este blog.

¡Nos vemos el viernes! =)

Elipse AD — Computed Vision in smartphone

Anteriormente he hablado de distintas tecnologías en el campo de la imagen y también he comentado algunas de sus múltiples aplicaciones en la sociedad.

En esta ocasión quiero hablaros acerca de una empresa que se dedica a llevar la Visión por Computador y la Realidad Aumentada a los teléfonos móviles, Elipse AD. Cuenta con un fuerte apoyo financiero de origen israelí, contratos con grandes entidades como COFARES o Toyota, y desarrollan su propio SDK para aplicaciones que hagan uso de Realidad Aumentada.

En unos días  mis compañeros en RoboLab, Pablo Manzano y Alejando Hidalgo, emprenden una marcha hacia Toledo para fomar parte de la plantilla de esta empresa. Desde aquí les deseo toda la suerte del mundo en este nuevo rumbo profesional, y esta entrada está dedicada a ellos: por su amistad, su trabajo bien hecho, y esas lecciones que me han dado sobre punteros, memoria y programación en general.

Si tienes algún tipo de experiencia en este incipiente sector y buscas trabajo entonces estás de suerte, aún están formando el equipo pero date prisa en contactar con ellos.

Mejoras en moleComp

Hace unos días publicaba unas imágenes donde se podían apreciar mejoras en mi componente moleComp, pero en estos días moleComp sigue avanzando, y bastante.

Antes de seguir, me gustaría abrir un paréntesis para explicar qué es moleComp:

moleComp es un componente integrado en el framework RoboComp desarrollado por RoboLab (laboratorio de robótica de la Escuela Politécnica de Cáceres — Universidad de Extremadura). Su propósito es ayudar a las personas con discapacidad física a realizar los ejercicios de rehabilitación de forma más amena, disfrazándolos de videojuego.

Para conseguir ese objetivo el componente requiere dos puntos de vista en cuanto a exigencias: por un lado desde el punto de vista del paciente moleComp pretende ser ameno, entrañable y divertido; en cambio desde la visión del médico moleComp debe ser flexible, fácil de configurar y versátil.

De forma más concreta, moleComp pretende llevar el típico juego de ferias Whack-a-mole a la realidad aumentada. El juego consiste en unos topos que se esconden en su madriguera y a los cuales el jugador debe golpearles con un martillo cuando salen. Al final de la entrada añado un vídeo del juego en la realidad, para el que no lo conozca.

Por último moleComp podría integrarse a corto plazo en el proyecto URSUS, uniéndose a una lista de juegos/ejercicios que comenzó con sevillaComp, y continuará con futuros PFC.

En el aspecto técnico, me gustaría hacer un resumen de cómo funciona a grandes rasgos moleComp, qué he mejorado los últimos días y qué espero mejorar:

En primer lugar, dentro de RoboComp, moleComp tiene dos proxies que le permiten comunicarse con cameraComp y con kinectComp para obtener la imagen de vídeo de alguna fuente, desde la interfaz del componente podemos cambiar de una fuente vídeo a otra instantáneamente sin necesidad de reiniciar el componente.

moleComp usa varias librerías para distintas funciones:

• OpenSceneGraph(OSG): Con esta librería creamos el árbol de figuras, cargamos los modelos 3D, programamos las animaciones, etc.
• ARToolKit: Con esta librería de Realidad Aumentada, podemos realizar el tracking de marcas de manera sencilla. En moleComp también usamos algunas funciones de esta librería para calcular las distancias entre las figuras 3D de OSG.
• OSGART: Es una librería muy sencilla, pero es necesaria para que podamos controlar las figuras geométricas de OSG con el tracking de ARToolKit. En RoboComp se trabaja para sustituir OSGART por una clase propia que haga lo mismo, de forma que no eliminamos una dependencia externa, y con más motivo cuando OSGART ha sido discontinuada.
• IPP: Se usan las primitivas de Intel para desarrollar algunas tareas de forma más eficiente.
• OpenAL: En estos días me estoy planteando usar esta librería de Audio para darle un toque de gracia a moleComp.

Las características de moleComp hasta el momento,  son las siguientes:

• Cálculo de distancias entre figuras geométricas de OSG.
• Carga de modelos 3D con semianimación.
• Interacción con los elementos 3D.
• Estado aleatorio de los modelos 3D.
• Puntuación de la interacción.
• Modificación del entorno, es posible mover los modelos, y hacer zoom en la puntuación.
• Modificación de los umbrales de interacción.

Las características en las que estoy trabajando ahora son las siguientes:

• Añadir sonido a la interacción.
• Mejorar el sistema de puntuaciones.
• Mejorar los modelos de los topos.
• Reemplazo del martillo por un modelo.
• Hacer modificable la velocidad de los topos.
• Añadir niveles.

Por último añado un vídeo con el que se pueden ver algunas de las características mencionadas:

Y un vídeo del juego en la realidad, por si queréis comparar:

Subir un componente al repositorio de RoboComp

Hasta ahora en este blog sólo había hablado de bajar componentes desde el servidor de RoboComp, hoy trataré el tema de subir nuestro nuevo componente.

En principio uno podría temer subir cambios al repositorio y estropear algo sin querer, pero en realidad esto no es un gran problema gracias a la gestión de versiones de Subversion, ya que se pueden revertir los cambios en cualquier momento, a pesar de todo, siempre es bueno poner atención cuando subimos estos cambios.

Lo primero que necesitamos es tener una cuenta en SourceForge, ya que RoboComp está alojado en dicha forja de software. El registro en SourceForge es gratuito y nos ofrece una serie de servicios que ya comenté anteriormente.

El siguiente paso es obtener permisos de escritura en el servidor con nuestra cuenta de usuario, algo tan sencillo como contactar con los responsables de RoboLab y solicitar dicho permiso.

En principio lo ideal sería añadir nuestro componente tras crearlo con la herramienta componentGenerator, para ello nos desplazamos hasta el directorio robocomp/Components/RoboLab/Experimental y ejecutamos el siguiente comando:

svn add ./miComponenteComp/

Nos pedirá la clave de nuestro usuario del sistema, tras añadirla nos pedirá el usuario y contraseña de nuestra cuenta en SourceForge, y nos saldrá un mensaje en el que nos indica que los nuevos archivosahora son versionados, esto es, gestionados por el control de versiones de Subversion.

¿Y qué pasa si no hemos añadido nuestro componente desde un principio? Pues en ese caso debemos eliminar algunos archivos y directorios temporales antes de ejecutar el comando svn add, esos archivos temporales son los siguientes:

• miComponenteComp/CMakeCache.txt ->Como ya anoté en una entrada anterior es necesario eliminar ese archivo antes de hacer » cmake .» tras modificar el CMakeLists.txt.
• *.moc -> Ya hablé de los archivos moc, esos meta-objetos que pueden darnos un quebradero de cabeza.
• Los binarios en miComponenteComp/bin/ -> no es necesario borrar los bash scripts *.sh, sólo los binarios. Normalmente los binarios binarios de robocomp no tienen extensión y sólo es uno con el nombre miComponente.
• Los directorios miComponenteComp/__ -> son directorios temporales, aún no sé muy bien su utilidad o función durante la compilación.
• Los archivos CMakeFiles de los directorios miComponenteComp/ y miComponenteComp/src/ -> al igual que con los directorios anteriores, aún no sé mucho sobre ellos, pero la recomendación que me han hecho es eliminarlos antes de añadir para que no queden versionados, y yo os transmito la recomencación.

Pero todo esto es únicamente necesario para añadirlo la primera vez, una vez que nuestro componente esté en el repositorio simplemente tenemos que subir los nuevos cambios ejecutando el siguiente comando desde el directorio de nuestro componente:

svn ci

Robolab — Robótica en Extremadura

Acabo de descubrir un canal en YouTube con vídeos de RoboLab y me gustaría compartirlo con mis lectores. A la vez, aprovecho para contaros un poco la intención a largo plazo de nuevos proyectos que se gestan en RoboLab.

Ya os había hablado de Ursus anteriormente, pues bien, se sigue progresando con este simpático robot, y es que en RoboLab están trabajando para dotarle de una boca que se mueva cuando Ursus habla. Además se está fabricando un segundo Ursus, con un torso más natural, y con piernas que aunque no se muevan, mejorarán bastante el aspecto exterior.

Como se puede ver en algunos videos se trabaja en un robot que transporta palés en miniatura, en principio puede chocar esta aplicación porque si ves los videos de buenas a primeras, seguramente no entiendas porqué nuestros robots van tan mal comparándolo con robots industriales que ya transportan palés desde hace varios años. La diferencia está en que esos robots industriales que funcionan tan bien, están fuertemente condicionados por su entonrno, mediante guías, raíles o movimientos programados muy concretos, donde en realidad se ha tenido que modificar el entorno para adaptarse al robot, esto supone un coste económico y logístico cuando por ejemplo, en una fábrica es necesario que el robot realice algo nuevo por un cambio de la disposición de los palés, lo que llevaría a adaptar nuevamente el entorno para el robot. De este modo los robots condicionan el modo de trabajo a las empresas que se ven en la necesidad de usarlos, generando un coste incial muy elevado para las empresas que quieren aplicar la robótica a su negocio, ya que además del precio del robot, tienen que invertir en la adaptación del entorno para el robot. Los robots de RoboLab buscan la mayor independencia con el entorno, de forma que sean ellos los que se adaptan a las situaciones y no al revés. Esto no es nada fácil, por eso podemos observar en los vídeos como se va progresando poco a poco con este robot.

Quizás el más impresionante es el SMART, que es un robot todoterreno con el objetivo de proporcionar ayuda como en situaciones posteriores a catástrofes naturales buscando heridos, por ejemplo. De momento aún queda mucho por hacer porque hasta ahora no deja de ser una especie de minicarro eléctrico controlado remotamente, pero la idea es que finalmente pueda ser más o menos independiente. Para lograr este propósito en RoboLab están pensando en adquirir un Drone (también conocido como Quadcóptero) de forma que el SMART haga de base nodriza, recargue las baterías del Drone, y transporte material sanitario, agua o víveres. Mientras que el Drone sea los ojos del SMART y analice la periferia, de forma que SMART pueda calcular la mejor ruta hasta el objetivo. Todo esto siendo un único robot a pesar de ser físicamente dos componentes distintos.

Por otro lado se está trabajando en un robot que reconstruye un mundo virtual a través de lo que va captando del mundo real, de forma que una vez reconstruido su mundo, puede navegar por él. También podemos apreciar en algunos de los videos a Muecas, un robot que pretende simular expresiones faciales. También hay algún proyecto sobre robot-juguete, y otros tantos de los que aún no me he enterado.

Sin lugar a dudas queda mucho trabajo por hacer, pero es muy emocionante estar haciendo mi Proyecto Fin de Carrera aquí, con la tecnología puntera y la investigación tan cerca, y sobretodo rodeado de estos cracks que forman el equipo de RoboLab.

Mi hueco en la Sala Beta

Hace mucho tiempo dí una descripción general de la Sala Beta, donde acudo para trabajar con la kinect.

Llevaba ya varios días queriendo hacer fotos, pero siempre se me olvidaba la cámara. Hoy que me he llevado la cámara no estaba Ursus, pero de todos modos he aprovechado para sacar un par de fotos a la sala.

Ursus, Kinect y Robocomp

En los últimos días mi proyecto se ha vuelto aún más interesante, principalmente gracias a los progresos de la gente que trabaja en Robolab, que han ido ampliando y mejorando a Robocomp, y además creando nuevos robots sobre los cuales se planean interesantes aplicaciones.

Respecto a las mejoras de Robocomp podemos echar un vistazo a la página del proyecto en SourceForge para ver que se envían un mínimo de 5 «code commits» al día. Sin duda es un proyecto muy activo.

En cuanto a los nuevos robots me gustaría destacar a URSUS, cuyo objetivo inicial es ayudar a los niños con problemas físicos a seguir los ejercicios de rehabilitación. Con URSUS los niños realizarían los ejercícios como si de un juego se tratase, a la vez que ayuda a los médicos a monitorizar los ejercicios. Se puede encontrar más información sobre esto en varios medios de comunicación que han intentado dar difusión a este proyecto tan interesante: [1][2][3][4][5][6][7][8].

Pero como he dicho antes, Robocomp no sólo mejora, sino que se amplía con más componentes, en concreto Robocomp ahora dispone de un componente llamado kinectComp, desarrollado por Luis Manso, que nos permite acceder a los datos que captura la kinect, pero es posible que llegado a este punto te preguntes… ¿qué es la kinect?

La kinect es un accesorio para la videoconsola de Microsoft XBOX360, se trata de una cámara en 3 dimensiones que permite jugar sin mandos, sólo con los movimientos de nuestro cuerpo. En Noviembre de 2010, el español Héctor Martín consiguió crear un controlador de código abierto que funciona sobre GNU/Linux para acceder a los datos de imagen y profundidad de la kinect, y ahora nosotros podemos usarla con Robocomp gracias a kinectComp. El precio de este aparato ronda los 150€, un precio aceptable para la calidad que consigue, la cual no deja de ser curiosa, pues consiste en una webcam VGA que nos da la imagen plana 2D, y una lámpara de infrarojos que emite un patrón concreto que junto con una cámara de infrarojos nos da información de la distancia.  Más sobre kinect.

Gracias a todas estas novedades, en mi proyecto trabajaré con una kinect en lugar de una webcam, y el resultado será aplicado a URSUS de forma que ampliemos sus aplicaciones.

Peleándome con Robocomp

La verdad es que el proyecto Robocomp es bastante activo y en la lista de correo se suelen ver varios commits al día, esta actividad supone algunos problemas, sobre todo respecto al tema de direcctorios que en algunas ocasiones los componentes usan rutas del directorio personal del administrador de dicho componente.

Otro de los problemas que me surgen es que aún no estoy falimiarizado con todos los componentes, lo que hacen, donde están, qué dependencias tienen, etc. Aunque de momento tengo esto claro:

• No necesito muchos de los componentes que integra robocomp, y tampoco las dependencias de algunos de estos componentes.
• El componente principal que necesito es el cameraComp, que se encuentra en $ROBOCOMP/Components/HAL/cameraComp/ ; hay otro cameraComp en $ROBOCOMP/Components/Robolab/Experimental/cameraComp que está en desarrollo y por lo tanto no lo utilizaré porque me da errores de compilación.
• Partiré del componente data2carmenComp que lleva Pedro y se encuentra en el directorio $ROBOCOMP/Components/Robolab/Experimental/data2carmenComp/

Después de varios errores he conseguido ejecutar cameraComp que se encarga de capturar frames por la webcam.

Por otra parte he conseguido compilar y hacer funcionar el data2carmenComp, sin embargo al ejecutar el data2carmenComp después del cameraComp me da el siguiente error que estoy tratando de solucionar:

:~/robocomp/Components/RoboLab/Experimental/data2carmenComp/src$ ./data2carmenComp --Ice.Config=../etc/config
[data2carmen]: Loading [camera:tcp -h localhost -p 10001] proxy at (CameraProxy)...
CameraProxy initialized Ok!
[data2carmen]: Loading [differentialrobot:tcp -h localhost -p 10004] proxy at (DifferentialRobotProxy)...
DifferentialRobotProxy initialized Ok!
[data2carmen]: Loading [laser:tcp -h localhost -p 10003] proxy at (LaserProxy)...
LaserProxy initialized Ok!
InnerModelReader: reading /home/leandro/robocomp/Classes/innermodel/innermodel/pulguita.xml 
Document opened 
virtualCamera(3, 3)
[
 300.000000 0.000000 160.000000 ;
 0.000000 -300.000000 120.000000 ;
 0.000000 0.000000 1.000000 ;
]
leftCamera(3, 3)
[
 300.000000 0.000000 160.000000 ;
 0.000000 -300.000000 120.000000 ;
 0.000000 0.000000 1.000000 ;
]
rightCamera(3, 3)
[
 300.000000 0.000000 160.000000 ;
 0.000000 -300.000000 120.000000 ;
 0.000000 0.000000 1.000000 ;
]
Sample Buffers Off in QGLWidget
Sample Buffers Off in QGLWidget
data2carmen - No connection to LaserComp... 
RoboCompdata2carmen::data2carmen started
a 
Fallo de segmentación
:

Robolab Robocomp Robex

Robolab es el laboratorio de robótica de la Universidad de Extremadura, se encuentra en la Facultad de Informática y dispone de 2 salas, una de ellas, conocida como Sala Beta, es donde se trabaja directamente para probar los robots. En la sala hay varias mesas distribuidas en forma de U, mientras que en el hueco interno es donde se desplaza el robot.

Robocomp es el framework para la creación de componentes de software, así como una recopilación de estos componentes. Algunos de ellos están en fase Experimental y otros en fase Estable.

Desde aquí se puede consultar toda la API.

Robex es una serie de robots creados en Robolab, y usan Robocomp para funcionar. Hasta el momento se van creando mejoras y accesorios para estos robots. Desde esta página podemos acceder a diversa documentación, como las características de estos robots.

Instalar Robocomp

Como ya comenté en la entrada anterior, a partir de ahora usaré Robocomp, un framework para generar componentes de software para robots.

Robocomp es capaz de funcionar en varios sistemas operativos y en un amplio hardware, sin embargo la mayoría de los desarrolladores y testers utilizan Debian o Ubuntu para trabajar, de hecho tienen un script para una instalación más sencilla de Robocomp en estos sitemas.

Casi todo el software desarrollado en Robocomp está escrito en C++ o Python, aunque usa el framework de comunicación de componentes ICE que le permite reutilizar componentes independientemente del lenguaje en el que esté escrito.

Los componentes de Robocomp es software para el control y funcionalidad de los robots, como pueden ser control de servomotores, cálculo de distancias con cámaras estéreo, posicionamiento con ayuda de láser, reconocimiento de objetos e imágenes, sistemas de sonido y reconocimiento de órdenes…

Aunque en la wiki del proyecto dan claras instrucciones para su instalación, voy a contaros aquí un poco los pasos que he dado para instalar Robocomp en Ubuntu Lucid 10.04:

• Primero descargarse las librerías IPP de Intel. Estas librerías es software propietario y por lo tanto sólo lo puede distribuir Intel, además deberás dejar tu correo electrónico para que te manden una clave de activación. Son unos 400MB por lo que tardarán bastante en descargarse, dependiendo de tu conexión, y para instalarse también tardara un poco.

Una vez descargado tendremos que descomprimirlo, navegar con la consola hasta la carpeta descomprimida y ejecutar:

sudo /bin/bash ./install.sh
 

Nos pedirá que aceptemos la licencia, y luego nos dará a elegir entre instalar en periodo de prueba o activar, a mi personalmente me tardaba demasiado con la activación así que tuve que instalar el periodo de 30 días, ya la activaré después. El directorio de instalación es: /opt/intel/ipp/6.1.2.051/ia32

• El siguiente paso es instalar las dependencias, en principio el script te instala todas las dependencias, pero creo que es mejor tenerlas instaladas primero, son las siguientes:

sudo apt-get install subversion openssh-server build-essential cmake g++ pyqt4-dev-tools python-qt4-dev python-qt4 

sudo apt-get install libfwbase1-dev libfwbase1 libcwiid1 libcwiid1-dev libdevil1c2 libdevil-dev libglew1.5-dev
sudo apt-get install libqt4-dev qt4-dev-tools libslice33 libzeroc-ice33 libzeroc-ice33-dev python-zeroc-ice libdc1394-22-dev


Ahora descargaremos el script, y lo ejecutamos desde la consola con el siguiente comando:

python robocompInstaller.py

El script detectará tu sistema operativo y después intenta satisfacer las dependencias, (suele tardar bastante), después tiene que descargar todos los datos de Robocomp y finalmente debes pasarle las rutas que introducirá como variables del sistema, como la ruta donde se instalará Robocomp, la ruta donde está instalada IPP, etc.
Finalmente, tendremos que reiniciar para que se guarden las variables del sistema.