Estaba yo pensando… ¿será posible hacer algo parecido?
El otro día estuve volviendo a ver Prometheus, una película de la saga de Alien que describe el origen del protagonista. Quería recordar las escenas en las que unos pequeños dispositivos voladores trazan un mapa en tres dimensiones de las cuevas que dan acceso a la nave escondida en una construcción piramidal.
Cuando vi la película por primera vez, debió ser en 2012, pensé: “Esto sería fantástico, seguro que hay gente y dinero detrás pero, al fin y al cabo, esto es una peli de ciencia ficción”
Más adelante, comienzos de 2014, en una visita a mis amigos de la Carlos III, me enseñaron el trabajo que estaba haciendo una estudiante con un sensor Kinect de Microsoft y pensé que era más real de lo que yo había imaginado.
Me pareció muy interesante, tenía que investigar un poquito más sobre el asunto. Se trataba de la primera generación del sensor Kinect de Microsoft. Estaba orientado a la interacción “natural” de un humano con una máquina. La máquina identificaría gestos del usuario y actuaría en consecuencia. Las primeras aplicaciones fueron juegos para la Xbox.
El Kinect es un sensor de profundidad basado en la técnica de luz estructurada (structured light). Se basa en la proyección de una matriz de puntos de luz infrarroja sobre la escena, que es observada por una cámara de infrarrojo. La distorsión en la posición de los puntos sobre la escena respecto a su posición teórica sobre una escena plana se convierte en información de profundidad en un SoC que genera información de posición de 320×240 puntos sobre un sistema de coordenadas de tres ejes. Como también dispone de una cámara RGB, incluye información de color para cada punto.
Estaba basado en un sensor desarrollado por PrimeSense, una empresa de Israel, que, en colaboración con Microsoft, desarrolló el dispositivo. Curiosamente, esta empresa fue comprada por Apple en Noviembre de 2013 y ahí se acabó la cooperación con Microsoft. La segunda generación del Kinect está desarrollada internamente por Microsoft y se basa en otra técnica distinta llamada “Time of Flight”.
El sensor desarrollado por PrimeSense, además de en el Kinect, también fue montado en otras dos familias de dispositivos. Fueron los PrimeSense Carmine, que prácticamente eran tarjetas de evaluación de la tecnología de PrimeSense, y los ASUS Xtion, que eran sus primos hermanos.
Para hacer pruebas tenía que decidirme por uno de ellos. Tras las siguientes consideraciones:
- Los PrimeSense Carmine y los ASUS Xtion eran prácticamente el mismo dispositivo, tanto desde el punto de vista hardware como software.
- Mientras que los ASUS se podían comprar online fácilmente, encontrar los PrimeSense Carmine era bastante complicado, por no decir imposible. Además, tras la compra de PrimeSense por parte de Apple había desaparecido de la web prácticamente toda la información sobre estos dispositivos.
- Los ASUS son más ligeros y compactos que los Kinect. Los ASUS se alimentan por el mismo cable USB que se usa para la comunicación de los datos, lo cual me pareció ventajoso. Los Kinect disponen de una alimentación separada. Los Kinect incluyen un pequeño motorcito que les permite hacer movimiento de tilt en un rango reducido. Esto no me pareció una ventaja, sino más bien un inconveniente como explicaré más adelante.
- Desde el punto de vista software, los Kinect disponen de un lujosísimo SDK (Software Development Kit) fantásticamente documentado pero, claro, sólo se puede usar en Windows y no incluye los fuentes.
- Sin embargo, los ASUS y los PrimeSense se controlan mediante una librería de código abierto llamada OpenNI que se puede compilar y usar tanto en Windows como en Linux.
Me decidí por comprar un ASUS Xtion Pro Live en Amazon como el que muestro al lado. Este dispositivo incorpora, además del sensor de profundidad, una cámara RGB y un array de dos micrófonos dispuestos en los extremos.
Como he dicho antes, la comunicación con el dispositivo de ASUS y la obtención de la información que genera se hace a través de la librería OpenNI (OpenNI2 en su versión actual). Este software era mantenido por PrimeSense. Tras su compra por Apple la librería es mantenida por Occipital Inc (https://occipital.com) como parte del SDK para su sensor “Structure Sensor” (http://structure.io).
Es especialmente interesante la historia de Occipital y su sensor Structure. Actualmente, acaban de presentar el sensor “Structure Core” diseñado para ser fácilmente integrable en robots, drones o cualquier otro aparato que se mueva.
Ya tengo el sensor y estoy en condiciones de probarlo. Voy a marcarme un objetivo. Antes de empezar escribo lo que espero conseguir.
Como no tengo a mano una cueva como la de la peli de Alien, me gustaría hacer una representación en tres dimensiones de una habitación en sus 360º. Es decir, una habitación vista aproximadamente desde su centro alrededor de 360º.
Al contrario que en la peli, aún no me siento capaz, el sensor no se va a mover. Bueno, mejor dicho, no se va a trasladar pero tendrá que moverse para tomar medidas alrededor de los 360º.
Para ponerlo en marcha tendré que trabajar en distintos aspectos del proyecto:
- Adquisición de los datos del sensor. Se trata de obtener la información de profundidad y de color del escenario. Será necesario poner en marcha la librería OpenNI.
- Tratamiento de los datos adquiridos. Para el tratamiento de la información de profundidad voy a usar la librería PCL (Point Cloud Library. http://pointclouds.org/). De los streams de video RGB y de profundidad se capturan sendos frames que se representan como una nube de puntos en una estructura de la librería PCL. Con esta librería se puede filtrar, segmentar, reconstruir, componer o representar esta información.
- Representación de los datos. Será necesario disponer de una herramienta que me permita representar en la pantalla de un ordenador las nubes de puntos obtenidas. Una buena herramienta de visualización reducirá el trabajo de desarrollo ya que me permitirá comprobar con facilidad los resultados de los tratamientos efectuados sobre las nubes de puntos adquiridas.
- Gestión de la plataforma de pan&tilt. Para generar el movimiento del sensor y poder enfocar la escena a lo largo de 360º en horizontal y en vertical será necesario disponer de una plataforma móvil que permita el movimiento en estos dos sentidos. Además, debe estar controlada por el procesador que adquiere la información del sensor para poder sincronizar la posición del sensor con la imagen obtenida.
- Composición del escenario. Se trata de componer la escena completa en sus 360º a partir de los distintos frames capturados desde distintas posiciones del sensor. Para ésto será necesario tener en cuenta que han sido tomados desde distintos puntos de vista.
- Integración de los distintos ensayos. Inicialmente se van a hacer distintas pruebas de concepto. No van a ser soluciones definitivas, sino distintos experimentos que me van a permitir verificar si es posible, y en qué grado, hacer lo que he descrito en los puntos anteriores a éste. En este punto le daré una vuelta a cómo se podría integrar todo esto en un equipo único y compacto.
Pues hasta aquí el primer post de esta serie. En los siguientes trataré de describir el trabajo que he ido haciendo para poner en marcha estos distintos componentes del proyecto que acabo de describir.
