Proyecto Fin de Carrera

Robótica, software y telecomunicaciones.

Instalar OpenNI y NITE en Windows, Ubuntu y Gentoo

Acabo de encontrar en internet una excelente guía paso a paso de cómo instalar OpenNI con NITE en Ubuntu, Windows y Gentoo elaborada por  el profesor Marcos Zúñiga Barraza y su ayudante Felipe López P. del Departamento de Electrónica de la Universidad Técnica Federico Santa María (UTFSM) en Chile.

Aunque en mi caso decidí usar el driver libfreenect de la comunidad OpenKinect por varios motivos, me parece muy interesante esta guía de primeros pasos con capturas de pantalla incluídas y un análisis del rendimiento al final del documento.

Documentación Kinect “Primeros Pasos”

Anuncios

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

Point Cloud Library

Point Cloud Library (PCL) es un framework para trabajar con nube de puntos, ¿pero qué es una nube de puntos?

Se considera una nube de puntos a una serie de datos en un espacio de cualquier número de dimensiones que se encuentran dispersos. Típicamente hablamos de nube de puntos en espacios 2D/3D cuando nos referimos a los datos (profundidad, color, textura, forma…) que obtenemos mediante sensores (cámaras, láseres, sónares…).

Esto es muy común porque normalmente los datos capturados en el espacio 3D son representados en un plano 2D, de este modo si queremos pasar del plano 2D al espacio 3D, nos encontramos con que hay muchos puntos del espacio 3D para los que no temenos información de forma que en el espacio 3D sólo tenemos información de algunos puntos salteados, en ese caso, esos puntos forman una nueba de puntos.

PCL pone a nuestra disposición una serie de algoritmo para filtrar esa nube de puntos e intentar la reconstrucción o reconocimiento de objetos a partir de dicha nube.

Hace ya tiempo que Luis J. Manso me recomendó PCL para trabajar con la Kinect, aunque aún lo tengo en mi lista de tareas pendientes, espero que con esta entrada me anime a echarle un vistazo con más profundidad.

Si tú has usado PCL o tienes algo que anotar no dudes en escribirme un comentario, si por el contrario estás interesado en saber más de PCL a continuación dejo el enlace a la API y otro con Documentación y tutoriales sobre PCL:

http://docs.pointclouds.org/trunk/

http://www.pointclouds.org/documentation/tutorials/

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

Crear una marca para ARToolKit

ARToolKit es una serie de herramientas para trabajar con realidad aumentada, principalmente haciendo uso de marcas. Gracias a estas marcas una simple webcam puede montar un entorno 3D simplemente comparando la marca en una imagen con la marca patrón, con las deformaciones de la marca en la imagen, ARToolKit puede proporcionarnos la información de traslación y rotación de dicha marca en las coordenadas X, Y, Z.

Además soporta marcas múltiples de forma que con una marca formada por varias marcas es posible que ARToolKit la siga reconociendo aunque no pueda ver alguna de las marcas que componen la multimarca.

En la wiki de ARToolWorks nos explican cómo construir las marcas: http://www.artoolworks.com

En los siguientes enlaces tenemos un par de aplicaciones flash que nos permiten crear nuestras propias marcas y obtener los archivos PATT que ARToolKit necesita para identificarlas posteriormente:

http://flash.tarotaro.org/blog/2009/07/12/mgo2/

http://www.roarmot.co.nz/ar/

También os adjunto una marca tipo Hiro en pdf lista para imprimir, esta es una de las marcas más comunes:

pattHiro

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

Error al arrancar KDevelop 4

Ayer se me quedó el ordenador bloqueado mientras programaba y no sé si se debe al propio disco duro o a la inestabilidad de algún programa, quizás mi propio programa (espero que no sea esto). Pero lo que quería comentar es que al reiniciar e intentar arrancar KDevelop, me sale un diálogo de alerta que dice lo siguiente:

Failed to lock the session , probably it is already active in another running instance

y no me deja abrir KDevelop a no ser que reiniciemos de nuevo.

El motivo es que KDevelop crear un archivo  de bloqueo para que el sistema se dé cuenta que ya lo tenemos arrancado y no intentemos abrir muchas instancias, ya que no es necesario con KDevelop 4, pues con una misma instancia podemos trabajar desde varios “workspaces”.

Si os ocurre esto alguna vez, una solución es reiniciar, pero otra solución más rápida es eliminar el archivo ~/.kde/share/apps/kdevelop/sessions/*/lock, donde ~ es la ruta de tu usuario, del tipo /home/myuser/ como ya expliqué en una entrada anterior.

Ejecutamos el siguiente comando:

sudo rm ~/.kde/share/apps/kdevelop/sessions/*/lock

27 mayo 2011 Posted by | all | | 2 comentarios

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:

Sigue leyendo

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

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

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

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

Instalar un plugin en KDevelop 4

Una de las ventajas de KDevelop es que su propia concepción está basada en una serie de plugins, simplemente no se aprecian porque están muy bien integrados y normalmente nos vienen instalados por defecto todos los plugins que están estables y bien  probados, esto nos da la ventaja de que no tendremos que ir a buscar los plugins a una página para ir descargándolos e instalándolos pero también es cierto que el número de ellos no es demasiado elevado, comparándolo con otros programas como podría ser Firefox.

En KDevelop 4.2 tenemos unos 32 plugins cargados, pero hay algunos en los que que el equipo de desarrollo trabaja y podría interesarnos probar, o bien crear nuestro propio plugin.

Tenemos 2 remositorios principales donde buscar este tipo de plugins, el Extragear y el Playground, y hasta donde yo entiendo, el Playground es más novedoso e inestable y el Extragear es más estable y probado. Dichos repositorios son los siguientes:

Uno de los plugins que tengo ganas de probar es el Control Flow Graph que permite ver diagramas de flujo de cada función seleccionada con el ratón en KDevelop. Este plugin está alojado en el siguiente repositorio:

Bien lo primero que debemos hacer es bajarnos el plugin con el comando:

git clone git://anongit.kde.org/kdev-control-flow-graph

Antes de continuar tenemos que tener satisfechas las dependencias, en este caso, este plugin tiene dependencia del paquete GraphViz que debe estar instalado en el sistema para que la compilación sea correcta. Las dependencias las podemos ver en los archivos Readme que suele incluir normalmente cualquier software. Si de un paquete no sabemos sus depencencias tampoco importa mucho, en el sentido de que al hacer cmake obtendremos un error diciendo que nos falta tal o cual paquete de software en el sistema.

Para instalar GraphViz en Ubuntu 10.10 podemos instalarlo desde Synaptic o desde consola con apt-get o aptitude, el paquete necesario es graphviz-dev (a la hora de probarlo también pide el paquete kgraphviewer con el mensaje “Could not find the KGraphViewer factory”, no es un problema porque también se encuentra disponible en repositorios de Ubuntu):

sudo aptitude install graphviz-dev
sudo aptitude install kgraphviewer

Nos movemos al directorio que se acaba de crear con el comando:

cd kdev-control-flow-graph/

Y compilamos como lo solemos hacer con cmake . y make:

cmake .
make
sudo make install

Cerramos KDevelop y cuando lo abramos ya tendremos el plugin instalado y funcionando.

Si por algún motivo necesitamos desinstalar el plugin, desde el directorio del plugin ejecutamos el siguiente comando:

make uninstall

Nota*: Aleix Pol, uno de los desarrolladores de KDevelop 4, nos recomienda que al compilar hagamos “cmake -DCMAKE_INSTALL_PREFIX=/usr” en lugar del “cmake .” para que se instale en /usr que normalmente es mejor. Y nos recuerda que la manera correcta de compilar con cmake es:

 mkdir build
 cd build
 cmake ..
 make
 sudo make install

La forma que yo he expuesto inicialmente es el método de compilación personalizada que usamos para construir componentes de RoboComp, aunque en principio también es válido en este caso.

Es posible que KDevelop explote (se cierra repentinamente) ocasionalmente mientras usamos el plugin Control Flow Graph, si te ocurre esto una vez, las próximas veces que habras KDevelop 4 y cargues el plugin también te explotará. La solución en este caso, es iniciar KDevelop y cerrarlo sin intentar cargar el plugin, la próxima vez que vuelvas a iniciar KDevelop volvarás a poder usar Control Flow Graph sin problemas.

Hasta donde lo he probado, KDevelop explota cuando pinchas en el gráfico para que te lleve el cursor a la línea de código correspondiente. Pero aún no estoy seguro de que esto sea muy común o se debe a que estoy con varios workspaces.

Os dejo un video (no es mío) con Control Flow Graph funcionando:

Gracias a todos los desarrolladores de KDevelop por seguir adelante con este fantástico IDE, y en especial a Aleix Pol por su ayuda y a Sandro Andrade, el autor principal del plugin Control Flow Graph.

10 mayo 2011 Posted by | all | , , , | 1 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

A %d blogueros les gusta esto: