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”

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

Calibración de Kinect

En esta entrada os comentaba sobre la calibración de la Kinect, y en esta otra algunas mejoras del componente de RoboComp que gestiona la kinect, kinectComp.

Os hablé de las matrices de Rotación y Traslación y de los parámetros intrínsecos de la cámara, los cuales son otra matriz. Los parámetros intrínsecos son los mismos para cualquier Kinect, pero tenemos que tenerlos en cuenta a la hora de interpretar los datos que captura la cámara para poder relacionar estos datos con el mundo real.

En la página de Nicolas Burrus podemos encontrar los parámetros intrínsecos, así como las matrices de Rotación y Traslación para una Kinect concreta. Pero gracias a Nicolas Burrus y los desarrolladores de la comunidad OpenKinect podemos calcular estas matrices calibrando nuestra propia Kinect. Para ello simplemente usaremos la aplicación RGBDemo, la cual basa la calibración en el método de OpenCV para calibrar cámaras estéreo.

Os dejo algunas capturas de las calibraciones de prueba que he hecho con las Kinects de RoboLab:

Sigue leyendo

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

Novedades en KinectComp

En Robolab seguimos trasteando con la Kinect, con su calibración y con el cómo pasar los datos de imagen y profundidad a coordenadas en 3D. La semana pasada se hicieron algunos cambios en las interfaces (archivos .ice) kinect y rgbd. Lo que me lleva a modificar mi código para trabajar con estas nuevas interfaces. Estos cambios son debidos a la calibración de la kinect y al ajuste que se aplica para hacer coincidir los datos de profundidad sobre la imagen RGB o bien la imagen sobre la profundidad.

De momento, estos métodos son getDataRGBZinIR() y getDataRGBZinRGB(), ambos métodos nos devuelven la Z en lugar de la DEPTH (profundidad), ya que es más útil porque podríamos pasar esa información a un sistema cartesiano con coordenadas XYZ, además para mi caso concreto, también es más útil pues los movimientos que haremos sobre la cámara serán movimientos planos en lugar de movimientos esféricos con centro en la Kinect.

Diferencias entre el concepto de Depth y Z.

Diferencias entre el concepto de Depth y Z.

Respecto a los métodos de conseguir los datos de imagen, es debido a que la cámara IR y la cámara RGB están desplazadas en el eje X (suponiendo un sistema cartesiano de tres dimensiones XYZ), y por tanto es importante usar como referencia una cámara u otra.

Estos cambios han hecho que me interese más aún por el componente que gestiona la Kinect en RoboComp y por el mismo driver de OpenKinect. He realizado algunas modificaciones en KinectComp de forma que sea más versátil y potencialmente más capaz. Por ejemplo, es interesante que en la interfaz de KinectComp (archivos .ice) estén definidos métodos con todas las posibilidades de la Kinect, pues aunque no se puedan implementar en este momento, es posible dejar esos métodos vacios y desarrollarlos más adelante sin interferir con los programas o componentes que se conectan a KinectComp.

Por este motivo he estado pensando en varios métodos, además de los existentes. Un método casi obligado sería el de calibrar la Kinect. Ya que sería conveniente poder calibrar cada Kinect antes de obtener los datos de imagen y profundidad, hasta ahora KinectComp calibraba la Kinect con unos valores de calibración genéricos proporcionados por Nicolas Burrus en su wiki. He modificado el código para que use variables en esa calibración, ya que cada Kinect tiene unos valores específicos asociados, de forma que con un método del tipo setCalibration(vectorCalibration[]) podamos pasar los valores específicos de nuestra Kinect en caso de que los conozcamos.

Otros métodos son asociados al LED de la Kinect de forma que podamos cambiar y leer su estado, esto puede ser útil para nuestra aplicación como un método de comunicación entre el programa y el usuario. Por ejemplo, si el usuario está demasiado cerca de la kinect, ponemos el LED en rojo, y si está a una distancia óptima se pone a verde.

Tambien sería ideal tener métodos para el audio o el acerelómetro de la Kinect, aunque en este momento no se le vaya a dar uso, porque aún no está bien implementado en el driver.

Como apunte final respecto a los métodos, creo que es conveniente evitar los parámetro en funciones siempre que se pueda, por ejemplo, se podría usar el siguiente método para la modificación del color del LED:

void setLEDcolor(int color);

Sin embargo, veo mucho más interesante crear la misma funcionalidad con un serie de métodos, pues el tener varios métodos no es algo necesariamente negativo:

void setLEDred();

void setLEDgreen();

void setLEDorange();

28 marzo 2011 Posted by | all | , , , | 1 comentario

Por qué calibrar la Kinect

Hace tiempo publiqué una entrada en la que hablaba del último cambio de rumbo del proyecto, cambio que entre otras cosas me llevaba a usar la kinect. En la siguiente, os contaba sobre la kinect, y los primeros problemas que tenía para hacerla funcionar, pero que finalmente solucioné.

Trabajando con ella conseguí pintar encima de la imagen de la cámara de vídeo en función de la profundidad que detectaba el sistema de infrarojos, y conseguí pintar en otro color, los objetos a determinada distancia y determinado margen de error, todo controlado con unos sliders (barras desplazadoras) de QT4. En otra entrada comentaré lo que he aprendido sobre la GUI con QT4 y el tema de los sliders.

Al observar la imagen resultante por la pantalla se apreciaba claramente un nuevo problema, y era que la imagen de la cámara RGB y la información de profundidad que nos da el sistema infrarojo no coincidían. Se puede apreciar claramente en la siguiente imagen. El error se incrementaba con la distancia, pero una barra vertical derecha sin información de profundidad permanecía constante.

Entonces, tenía que buscar una explicación al problema, y una vez entendido, intentar solucionarlo.

La explicación de la barra vertical derecha puede observarse en la siguiente imagen, se trata de la diferencia del ángulo de visión de ambas cámaras (IR y RGB) y la distancia ente ellas:

En cuanto al otro error es algo más complejo. Por una parte tenemos que entender que existe una traslación entre la imagen de la cámara RGB y de la imagen captada por la cámara IR debido a la separación que hay entre ambas. Por otro lado hay que tener en cuenta que la lámpara IR está desplazada hacia la derecha respecto a la cámara IR, lo que generará una “sombra IR” a la izquierda de cualquier objeto.

En este caso, la cámara infraroja sólo podría ver la cara b.

La traslación entre los ejes focales de las dos cámaras (IR y RGB), se puede calcular a groso modo midiendo la distancia entre las dos cámaras, que nos la podría dar el fabricante. Sin embargo, hay que tenen en cuenta que la precision en la fase de construcción de la Kinect no es perfecta, y por este motivo cada Kinect tiene una traslación específica. Es más, estamos suponiendo que existe una traslación entre los dos ejes focales, pero que estos se mantienen paralelos entre sí, cuando en realidad, por el mismo motivo anterior, cada kinect tiene una desviación característica entre esos dos ejes.

De ahí la necesidad de calibrar cada kinect con la que queramos trabajar.

Hasta ahora he encontrado 2 formas de calibrar las kinects, una que desarrollan desde la gente de ROS(un sistema operativo para robots), y otra que se está desarrollando en el entorno de OpenKinect.

La gente de ROS ha calculado los valores de las matrices de Traslación y Rotación genéricos que podemos encontrarlos aquí.

Por su parte, Nicolas Burrus junto con la comunidad OpenKinect desarrollan un programa llamado RGBDemo para que cada uno calibre su kinect, calculando los valores de las matrices basándose en el método de la calibración de cámaras estéreo de OpenCV. Además están trabajando en añadir características al programa como estabilizador de imagen de profundidad, relleno de huecos predecibles, detección de objetos, tracking humano, etc.

3 marzo 2011 Posted by | all | , , , , | 3 comentarios

Kinect, freenect, OpenKinect, y OpenNI

Ahora que voy a usar una kinect, necesitaré comunicarme con un componente llamado kinectComp, este componente dispone de una interfaz desde la cual podemos conseguir los datos de imagen y profundidad para poder trabajar con ellos en nuestro componente.

En realidad kinectComp se encarga de controlar la kinect, haciendo de intermediario entre el driver (controlador) de la kinect y los demás componentes de Robocomp.

Logo-OpenKinect

El driver se está desarrollando desde OpenKinect, coordinando a un gran grupo de personas que trabajan con este nuevo periférico. El driver se llama Freenect, y hasta el momento es capaz de capturar la imagen de la cámara con una resolución VGA (640×480), así como los datos de profundidad, y controlar el pequeño motor en su base. Sin embargo, con kinectComp sólo podemos acceder a los datos de profundidad e imagen.

Una versión experimental de Freenect consigue capturar el audio de sus micrófonos y cambiar el estado del LED frontal.  Y trabajan en un sistema llamado Fakenect con el cual puedas grabar una sesión con una kinect, para trabajar posteriormente con esa sesión sin necesidad de tenerla conectada al PC.

Logo-OpenNI

Por otro lado tenemos a PrimeSense, los diseñadores del chip PS1080 que lleva incorporado la kinect.  PrimeSense junto con WillowGarage (desarrolladores de OpenCV), están creando unas librerías llamadas OpenNI (Open Natural Interaction) que en principio no tiene nada que ver con el proyecto OpenKinect, y se encargan de facilitar el tracking de personas, el control por gestos, etc. De hecho, son las librerías que utilizan en NITE (framework de código cerrado) los desarrolladores de videojuegos para la XBOX360.

Hasta ahora, si queremos usar kinectComp necesitamos tener conectada la kinect, e instalar una versión del driver adecuada. La versión debe ser la adecuada porque Freenect está en constante cambio, recordemos que se empezó a trabajar con esto tan sólo hace 4 meses (Noviembre 2010), y el nombre con el que se accede a sus datos puede ser distinto en cada versión.

En mi caso, la primera vez que instalé freenect, lo hice con el método más cómodo, añadiendo el PPA a Ubuntu e instalando desde synaptic o aptitude, sin embargo la versión que se me instalaba con este método era un poco antigua (11 Diciembre 2010) y consumía RAM de forma incremental, hasta el punto de bloquear el ordenador si mantenía la kinect encendida más de 5 minutos.

Para solucionar esto, instalé la versión master desde el repositorio de GitHub, la cual me funcionaba perfectamente desde la demo de Freenect (glview), pero que no podía comunicarse con kinectComp. La solución vino de la mano de Luiky (miembro de Robolab) que modificó el archivo CMakeLists.txt de kinectComp. ¡Gracias Luiky!

 

 

18 febrero 2011 Posted by | all | , , , , | 1 comentario

   

A %d blogueros les gusta esto: