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:

Novedades en moleComp: OSG + ARToolKit

Hace bastante tiempo que no publico nada, pero eso no quiere decir que no haya avanzado en el PFC, de hecho he avanzado bastante.

El principal problema es la falta de tiempo para escribir debido a mi viaje a Coimbra, estaré aquí trabajando con entornos 3D (ya comentaré en otra entrada mi trabajo en Coimbra con más detalle), a la vez que continúo con mi PFC.

De momento he conseguido obtener la distancia entre marcas, en milímetros. En realidad estoy usando unos valores genéricos de calibración de la cámara por lo que los resultados aún pueden mejorar si aplico mi propia calibración a la cámara que estoy usando.

Os dejo unas capturas de pantalla con mis avances…

Instalar OSGBullet en Ubuntu 10.10

Me está llevando demasiado tiempo conseguir la colisión entre figuras de OSG, y he pensado que una buena solución sería añadir un motor de física, ya que de este modo puede servir para futuros trabajos y componentes en RoboComp.

El motor de física que querría utilizar es Bullet, principalmente porque hay un middleware que integra Bullet y OSG llamado OSGBullet. A continuación os muestro un vídeo donde se aprecia el potencial de Bullet.

OSGBullet tiene varias dependencias, como es lógico depende de OSG y de Bullet, pero también de OSGWorks.

En principio damos por hecho que OSG ya está instalado y funcionando correctamente en tu sistema.

Vamos con Bullet:

• La última versión de OSGBullet (v1.1 Sep 2010) tiene soporte de determinadas versiones de las dependencias, en el caso de Bullet, la última versión completamente soportada es la v2.75 que podemos obtener aquí.
• Los pasos para instalarla en una sistema GNU/Linux la podéis encontrar en el archivo INSTALL una vez descomprimimos el archivo descargado.
  ** Linux Compilation **- Download/install CMake from http://www.cmake.org or package manager
  CMake is like autoconf in that it will create build scripts which are then
  used for the actual compilation- There are some options for cmake builds:
  BUILD_SHARED_LIBS: default ‘OFF’, set to ‘ON’ to build .so libraries
  BUILD_EXTRAS: default ‘ON’, compiles additional libraries in ‘Extras’
  BUILD_DEMOS: default ‘ON’, compiles applications found in ‘Demos’
  CMAKE_INSTALL_PREFIX: default ‘/usr/local’, the installation path.
  CMAKE_INSTALL_RPATH: if you install outside a standard ld search path,
  then you should set this to the installation lib path.
  CMAKE_BUILD_TYPE: default ‘Release’, can include debug symbols with
  either ‘Debug’ or ‘RelWithDebInfo’.
  Other options may be discovered by ‘cmake –help-variable-list’ and
  ‘cmake –help-variable OPTION’

  – Run ‘cmake’ with desired options of the form -DOPTION=VALUE
  By default this will create the usual Makefile build system, but CMake can
  also produce Eclipse or KDevelop project files.  See ‘cmake –help’ to see
  what «generators» are available in your environment, selected via ‘-G’.
  For example:
  cmake -DBUILD_SHARED_LIBS=ON -DCMAKE_BUILD_TYPE=RelWithDebugInfo

  – Assuming using the default Makefile output from cmake, run ‘make’ to
  build, and then ‘make install’ if you wish to install.

• Sin embargo yo he probado el método que solemos usar (cmake . && make && sudo make install) y parece que todo funciona sin problemas.

Ahora toca instalar OSGWorks:

• Nos descargamos el paquete de la web de OSGWorks o de la página del proyecto. La zona de descargas es esta.
• Al igual que con el paquete anterior, hacemos cmake . && make && sudo make install

Por último descargamos e instalamos OSGBullet:

• Descargamos los paquetes desde la página de OSGBullet.
• Y en principio deberíamos de poder instalarla como las otras dos, sin embargo, a mí me da problemas en el linkado a la hora de hacer cmake . pero en cuando lo solucione actualizaré esta entrada.

Trasteando con OSGArt

Me hubiera gustado escribir una entrada clarificadora acerca de OSGArt, y con más motivo por la poca información que hay en castellano sobre la unión de estas potentes librerías: OSG y ARToolKit.

Sin embargo, después de una semana trasteando junto con dos compañeros (Pablo y Alejandro) que también hacen su PFC en SalaBeta, no hemos conseguido el objetivo deseado: tener un control práctico sobre las figuras que dibujamos con OSG.

A pesar de todo hemos hecho algunos avances interesantes, como conseguir mover, transformar, colorear o destruir las figuras, aunque sin terminar de tener muy claro si lo hacemos de la forma correcta.

A continuación os dejo unas capturas de pantalla del nuevo componente:

Cómo integrar OSRGart en RoboComp

Anteriormente os había hablado sobre OSGArt y algunos truquillos que nos costó mucho esfuerzo dar con ellos. Por ahora tengo el componente moleComp para estudiarlo e integrar OSGArt en Camimic.

Damos por hecho que tememos OSGArt correctamente instalado en nuestro sistema, si no fuera el caso lo explico en esta entrada.

Necesitamos, para no partir de cero, lo siguiente:

• La clase de OSGArt creada por Luiky (que se llama precisamente OSGArt) que se compone de los archivos osgArt.h y osgArt.cpp
• Los patrones de las marcas, para que ARToolKit pueda comparar la imagen a procesar con los patrones, y localizar y hacer tracking de las marcas. Estos patrones tienen el formato patt.* donde el asterisco es el nombre de la marca(patt.hiro, patt.play…), por decirlo de aún modo, estos archivos tienen la extensión patt. a la izquierda del nombre de archivo. Todos estos archivos deben ir en una carpeta de nombre Data en la carpeta de los ejecutables de tu componente …micomponenteComp/bin/ junto al binario micomponenteComp.
• Modificar el CMakeLists.txt para indicarle que use los archivos osgArt.cpp y osgArt.h durante la compilación.
• Declararnos un objeto de tipo OSGArt en nuestro worker.h, inicializar el objeto en el constructor de worker.cpp, y dentro del compute() de worker.cpp llamar a la función mienbro updateArt(image) del objeto creado.
• Las marcas impresas y en soporte rígido para interactuar con la parte de OSGArt de nuestro compoente.

En el final de la entrada adjunto mi CMakeLists.txt para que veáis las modificaciones necesarias en ese archivo. Aunque en realidad podéis mirar cualquier CMakeLists.txt de los componentes que usan OSGArt como pueden ser sevillaComp o armtrackerComp.

El código necesario para declarar el objeto en el worker.h es el siguiente:

    OsgArt *myOsgArtObject;

La línea para inicializar dicho componente en el contructor (Worker::Worker(…){}) del worker.cpp es esta:

    myOsgArtObject = new OsgArt(myQframeToShow);

*ATENCIÓN: La línea anterior es necesario escribirla entre el setupUi(this) y el show(), como se explica en esta entrada.

Por último, necesitamos escribir lo siguiente en el método compute(){} del worker.cpp, donde img es una imagen de tipo RoboComp (imgType) :

    myOsgArtObject->updateART(img);

Ahora, para dibujar a nuestro antojo sólo tendríamos que editar osgArt.h y osgArt.cpp, pero eso lo explicaremos en otra entrada.

CMakeLists con OSGArt en RoboComp

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.