Proyecto Fin de Carrera

Robótica, software y telecomunicaciones.

Lanzamiento de KinectSDK para Windows 7

Quizás llego tarde para anunciar que mañana Microsoft lanza de manera oficial su Kinect SDK para Windows 7, y para ello convocan a desarrolladores interesados en este dispositivo en sus oficinas en Washington DC.

Se abordarán las ventajas y novedades del SDK que según entiendo yo dejará de ser beta, y además te invitan a que lleves tu Kinect y tu equipo con Windows 7, ya que te ayudan con los problemas que tengas.

Además se organiza un concurso de aplicaciones y seguramente sea una fiesta de márketing para crear una comunidad de desarrolladores sólida detrás de Kinect.

Aunque yo en mi proyecto uso OpenKinect, sé que mucha gente llega al blog buscando información en general sobre Kinect.

Os dejo unos enlaces:

http://events.linkedin.com/Kinect-SDK-DC-Launch-CapArea-Silverlight/pub/705988

http://kinectsdklaunchdc.eventbrite.com/

http://caparea.net/Default.aspx?alias=caparea.net/silverlight

Anuncios

22 junio 2011 Posted by | all | , , , | 2 comentarios

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

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

Realidad Aumentada — World Builder

Hace bastante tiempo vi un vídeo en Youtube que me llamó la atención, en aquel entonces aprendía tímidamente a usar Blender y a crear mapas (escenarios 3D para mods de juegos) con Radiant.

Siempre había visto ese vídeo como un corto de ciencia ficción, pero según voy aprendiendo sobre la realidad aumentada y la visión por computador, me doy cuenta que la idea no es tan imposible. Ahora, quisiera compartirlo con los lectores del blog.

Hablando con Pablo Bustos sobre la interacción hombre-máquina y la broma del April’s Fool de Google (Gmail Motion) coincidíamos en que tener que hacer gestos y movimientos para tareas cotidianas y repetitivas, puede llegar a ser agotador y poco productivo.

Pero por otro lado, seguramente lo mismo pensó la gente de Nintendo, cuando uno de ellos propuso el WiiMote y que los jugadores de la nueva consola tuvieran que levantarse del sofá para jugar. Sin embargo fué un éxito y el que las otras consolas como XBOX360 o PlayStation3 hayan intentado copiar y mejorar el modelo con la Kinect o el Move respectivamente.

Sin embargo no es lo mismo jugar que trabajar, y seguramente las empresas que decidan apostar fuerte por llevar estas tecnologías al terreno profesional estén arriesgando mucho. Mientras tanto la investigación va dando pequeños pasitos para eliminar las restricciones de la tecnología.

Cada vez son más las herramientas que tenemos a nuestra disposición y cada vez funcionan mejor, sin embargo tener una buena idea para aplicarlas a un entorno productivo no es tan secillo, y hay veces que aunque la idea sea bueno, lo complicado es llevarla a cabo.

A continuación listo una serie de tecnologías interesantes que se pueden aplicar en el mundo real a través de la Realidad Aumentada:

  • Reconocimiento y transcripción de voz. Reconocimiento e identificación de fragmentos musicales.
  • Síntesis de voz.
  • Reconocimiento y tracking facial, Reconocimiento de retina.
  • Tracking  e identificación de objetos.
  • RFID. Identificadores mediante circuitos (microchips) sensibles a radiofrecuenta.
  • Bluetooth y redes Zigbee. Redes de acceso WiFi. Transmisión de vídeo por conexión inalámbrica WHDI.
  • Detección de marcas y códigos QR o códigos de barras.
  • GPS y otros sistemas de detección de posición por triangulación.
  • Sónar y Láser para medir distancias.
  • Gafas para la proyección de mundos virtuales o mundos de realidad aumentada.
  • Cámaras estéreo o sensores tipo Kinect para obtener vídeos imagen-espacio.
  • Pantallas con proyección 3D con gafas activas o pasivas, o sin gafas.
  • Cámaras esteroscópicas.
  • Proyección tridimensional sobre humo y otras técnicas para crear hologramas.
  • Pantallas LCD flexibles.

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

WAVI Xtion — La Kinect de ASUS

Como cabía esperar, ya ha aparecido un nuevo dispositivo similar a la Kinect de Microsoft, en este caso de la mano de ASUS.

Y si bien la Kinect aparecía como un accesorio de la videoconsola XBOX360, la WAVI Xtion surge como accesorio para los televisores de ASUS. En realidad tanto Kinect como WAVI Xtion llevan chip de PrimeSense.

Por tanto la Kinect se plantea como un “mando” para la XBOX360 y la WAVI Xtion es un elemento clave para los televisores de ASUS que pretenden volverse más interactivos con su portal Xtion.

Realmente creo que ASUS ha elegido muy mal el nombre para su dispositivo porque por un lado está WAVI, por otro Xtion Portal y por otro lado la Xtion (que la comercializan como WAVI Xtion).

WAVI es un dispositivo de conexión inalámbrica de alta capacidad que utiliza el protocolo WHDI, el cual permite la transmisión inalámbrica de vídeo en Alta Definición, además de otros datos.

Xtion Portal es la interfaz que te permite conectar el televisor a ASUS@vibe a través del ordenador. ¿Pero qué es ASUS@vibe? Pues otra tienda de juegos y aplicaciones, del estilo que la APP Store de Apple, la Ovi Store de Nokia o el Android Market de Google. Está claro que aquí hay negocio, incluso Telefónica está montando la suya.

Además ASUS ha lanzado la plataforma de desarrollo para Xtion conocida como Xtion PRO Developer Kit, la cual es completamente compatible con OpenNI.

Por lo demás parece que Xtion lleva el mismo chip que la Kinect, el PS1080. Sin embargo tiene menos extras que la Kinect, como el cuello motor o el acelerómetro.

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

Mi componente de RoboComp

Hace unos días grabé un vídeo usando mi componente tras solucionar el refresco de la imagen al cambiar de fuente. Los principales problemas llegaban por la imagen de infrarrojos que al ser de distinto tipo (Blanco y Negro) y de distinto tamaño (8 píxeles más alta).

El problema ahora son los FPS (frames por segundo) que son demasiado bajos al pedir constantemente a la Kinect la imagen de infrarrojos y la RGB. Toca solucionarlo.

 

8 abril 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

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.

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

A %d blogueros les gusta esto: