Proyecto Fin de Carrera

Robótica, software y telecomunicaciones.

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! =)

16 mayo 2012 Posted by | all | , , , , | 5 comentarios

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:

13 julio 2011 Posted by | all | , , , , , , , , | Deja un comentario

Instalar ARToolKit en Ubuntu y usar en RoboComp

En el blog Simocap de José Alberto Gandullo se explica perfectamente cómo instalar ARToolKit en Ubuntu, sin embargo me gustaría añadir algunas notas que me comentó Luiky.

El método de instalación que se menciona en Simocap es para la versión de 32bits de Ubuntu, aunque en realidad podría servir para varias distribuciones GNU/Linux basadas en Ubuntu o en Debian.

Para las distribuciones GNU/Linux de 64bits es preferible modificar el script Configure antes de ejecutarlo, podemos hacerlo con los siguientes comandos:

cd ARToolKit
gedit Configure

Dentro del archivo configure tenemos que añadir -fPIC a la línea 111 sustituyendo la línea que tiene  —  por la que tiene ++ al principio de las líneas que indico:

-- CFLAG="-O $GST_INCLUDE -I/usr/X11R6/include"
++ CFLAG="-O $GST_INCLUDE -fPIC -I/usr/X11R6/include"

A continuación lo ejecutamos:

./Configure

y compilamos:

make

Añadimos la variable de entorno:

export ARTOOLKIT_CONFIG="v4l2src device=/dev/video0 use-fixed-fps=false ! ffmpegcolorspace ! capsfilter caps=video/x-raw-rgb,bpp=24 ! identity name=artoolkit ! fakesink"

y probamos que funciona correctamente ejecutanto el test dsde la carpeta bin:

cd  ARToolKit/bin
./simpleTest

Sin embargo, si queremos integrar ARToolKit en nuestro proyecto, necesitamos modificar nuestro CMakeLists.txt, de forma que los #include no nos den problemas.

23 junio 2011 Posted by | all | , , , , , , | Deja un comentario

Instalar OSG en Ubuntu para usar en RoboComp

Gracias a un script en Python que tenemos en RoboComp, instalar OSG en Ubuntu es tan sencillo como ejecutar dicho script, que nos deja listo el sistema para comenzar a programar con OSG en Ubuntu, ya sea la versión de 32 bits o la de 64 bits. Además se ha probado para la versión 10.04 LTS y para la versión 10.10.

Nos desplazamos a la carpeta que contiene el script y lo ejecutamos:

cd robocomp/ThirdParty/
python osg2.8.3.py

Meter la contraseña de usuario cuando nos lo pida, y listo.

23 junio 2011 Posted by | all | , , , | 8 comentarios

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

14 mayo 2011 Posted by | all | , , , | Deja un comentario

RoboComp con KDevelop 4

Ayer mismo subí 2 vídeos los cuales espero que sirvan de ayuda para cualquiera que empiece a desarrollar en RoboComp (aunque también puede servir para cualquier programación) pueda trabajar cómodamente con KDevelop 4.

Me hubiera gustado doblar o subtitular los vídeos explicando lo que se hace en cada momento, pero como eso me llevaría su tiempo, veo la necesidad de publicarlos para que puedan ser de utilidad desde ahora. Sabéis que si tenéis cualquier duda, dejar un comentario en el blog es una buena opción, pues intentaré solucionarla lo más rápido posible.

11 mayo 2011 Posted by | all | , | Deja un comentario

Usando OSGArt en RoboComp

Ayer Luiky me creó un componente “en blanco” llamado moleComp el cual sería el punto de partida para integrar OSGArt en Camimic.

OSGArt es una integración de Open Scene Graph (OSG) con ARToolKit (la librería más popular para Realidad Aumentada), de forma que ARToolKit detecta y sigue las marcas de Realidad Aumentada, así como sus tranformaciones en el espacio, y OSG toma estos valores como referencia para construir todo un mundo en tres dimensiones sobre la marca.

La idea es usar OSGArt para crear un juego que se base en el tracking de una marca pero que cuando tenga el tracking del color/dedos pueda sustituir a la marca sin mucha complicación, lo más importante es que OSG necesita una referencia.

Ayer fue un día duro en el que después de muchas horas, todos los problemas se solucionaron en unos 30 minutos. En parte tengo la suerte de que el ordenador que uso en Sala Beta ya tenía OSGArt instalado correctamente, aunque la parte negativa es que no puedo contar como se instala OSGArt porque no lo he hecho.

Resumo las soluciones que tanto nos costó encontrar ayer en 2 notas importantes:

Nota Importante 1:  en nuestro caso (con RoboComp) es importante configurar OSGArt para que capture el vídeo por GStreamer en lugar de con V4L, sino podremos obtener un invalid pilex format que nos consuma toda la tarde.

Nota Importante 2:  inicializar los objetos de OSGArt entre el setupUi y el show, como en las siguientes líneas.

 setupUi(this);
 osgArt = new OsgArt(frameOsgArt );
 show();

Gracias a Luiky por toda su ayuda.

10 mayo 2011 Posted by | all | , , , , , , | 1 comentario

Documentación en la API de RoboComp

En una entrada anterior mostraba un esquema con las relaciones entre las funciones del worker de mi componente, y os contaba cómo escribiendo doxygen Doxyfile se nos generaba automáticamente toda la documentación y se nos guardaba en un nuevo directorio doc.

Pero lo ideal es que esa documentación esté integrada en la API de RoboComp junto a la información de los demás componentes. Es una lástima que Doxygen no soporte ICE de forma que  mostrase los proxies, puertos e interfaces. Pero al menos la gente de RoboComp tiene un scrip que genera los archivos *.cpp y *.h a partir de los *.ICE para que Doxygen pueda enterarse de algo.

Realmente subir la documentación a la API lo hace ese script que se genera en el servidor, por lo cual se necesita que algún administrador dé de alta tu componente, después de esto, todo es automático. El script está programado para ejecutarse una vez a la semana, mientras que nosostros simplemente tenemos que escribir comentarios en nuestro código con el formato de Doxygen.

De momento la documentación de mi componente ya está publicada, ahora queda comentar bien para que sea útil.

¡Ah! Se me olvidaba, por si no ha quedado claro, no seais tan bestias de subir la documentación con un svn ci porque eso sólo te serviría como copia de seguridad, pero son demasiados archivos y cada vez que alguien haga un svn up de tu componente se los tendría que bajar, cuando es más rápido generarlos desde el propio código. Hacer doxygen Doxyfile te puede venir bien para comprobar cómo sería si se generase en el servidor, o para llevártela a otro ordenador, imprimirla, etc.

19 abril 2011 Posted by | all | , , , | Deja un comentario

El Worker de Camimic

Estos días he estado trasteando con Doxygen y la verdad es que me gustaría aprender más, pues me parece una herramienta muy útil.

De momento he generado la información gracias a que RoboComp ya viene con Doxygen, y es tan sencillo como desplazarte a la carpeta de tu componente (…/micomponenteComp) y ejecutar el siguiente comando:

doxygen Doxyfile

Y de manera automática se nos creará una carpeta llamada doc con otra llamada html llena de los archivos necesarios.

Os dejo una imagen que he creado trasteando con Doxygen:

16 abril 2011 Posted by | all | , | 1 comentario

Avahi — maquinafoo.local

Ya he comentado alguna vez que el mayor potencial de RoboComp es la utilización de hardware simultáneamente por varios equipos. En nuestro caso podemos usar la Kinect desde varios ordenadores de RoboLab gracias a que RoboComp utiliza ICE, sin embargo hasta el momento, yo siempre había usado la Kinect desde mi ordenador y habían sido los compañeros quienes se conectaban a ella desde la red local.

Hoy me ha tocado a mí conectarme a la Kinect mientras esta estaba conectada en otro ordenador, y lo único que tenía que modificar era el archivo config que se encuentra en …/micomponenteComp/etc/ y cambiar localhost por la IP de la máquina donde corre la Kinect.

Gracias a Avahi no es necesario tratar con IP’s mientras éstas estén en la misma red local, simplemente podemos poner maquinafoo.local y Avahi se encargará de buscar la máquina con el nombre maquinafoo, obtener su IP real y sustituir maquinafoo.local por la misma.

Avahi es un demonio (similar a un servicio en Windows), que se encarga de obtener las IP’s de una red local y asociarlas a los respectivos nombres de máquina. Es similar al Bonjour de Apple, y a este tipo de servicio también se les suele llamar descubridores de servicios de red o se los puede comparar a un servicio de DNS a nivel local.

15 abril 2011 Posted by | all | , , , , | Deja un comentario

A %d blogueros les gusta esto: