Voy a hacer la primera prueba. Con el sensor viene un CD etiquetado como \u201cPrimeSense Software Package 20.4.2.20\u201d pero sorprendentemente no se puede leer. \u00a1Qu\u00e9 desastre! Rebuscando por el sitio de ASUS encuentro una imagen iso identificada como \u201cV1164_1202.iso\u201d, me la bajo, me hago un disco y con este tengo m\u00e1s suerte. Encuentro un ejecutable Windows para instalar un SDK. Lo ejecuto y me instala el driver USB del sensor y la librer\u00eda OpenNi. Veo que con la librer\u00eda vienen una serie de aplicaciones ejemplo de c\u00f3mo usarla. Est\u00e1n compiladas. Enchufo el conector USB del sensor en mi port\u00e1til. Veo c\u00f3mo aparecen dos nuevos dispositivos USB en Windows. Empieza a subirme la adrenalina. Pincho compulsivamente dos veces en el fichero NIViewer.exe y \u2026 \u00a1vaya, parece que funciona!<\/p>\n
Estoy viendo la representaci\u00f3n de dos streams de video en tiempo real. A la derecha de la pantalla de mi port\u00e1til se ve mi habitaci\u00f3n, en color, como si se estuviera viendo con una c\u00e1mara USB. A la izquierda de la pantalla se ve una imagen de video coloreada con distintos tonos de amarillo. Al cabo de un rato mir\u00e1ndola me doy cuenta de que es la misma escena que se ve en color a la derecha pero coloreada con distintos tonos de amarillo en funci\u00f3n de la distancia de los objetos de la escena al sensor. Bueeeno, la imagen en amarillo es bastante fea pero es una manera de representar la informaci\u00f3n de profundidad que adquiere el sensor.<\/p>\n
Es un buen comienzo. Merece la pena seguir. Pero no me gusta la imagen en amarillo, quiero ver una nube de puntos.<\/p>\n A partir de aqu\u00ed voy a trabajar con Linux. Windows me ha servido para ver algo deprisa, es muy c\u00f3modo, uno est\u00e1 acostumbrado al entorno y me manejo con soltura con carpetas, ficheros, editores, etc. En Windows instalas el paquete mediante un ejecutable, se instalan los recursos necesarios, el ejemplo viene compilado, se ejecuta y, generalmente, funciona. Pero para ir m\u00e1s lejos me parece mejor usar Linux. Mi intenci\u00f3n es generar una aplicaci\u00f3n sobre OpenNI que permita manipular las im\u00e1genes obtenidas. Si hay que compilar, depurar o bucear por el c\u00f3digo fuente, me parece mejor hacerlo en Linux. Adem\u00e1s, de momento, voy a desarrollar en mi ordenador port\u00e1til pero considero que es un requerimiento clave que este trabajo se pueda trasladar a un equipo embebido.<\/p>\n Uso la \u00faltima versi\u00f3n LTS de Ubuntu. Me descargo la \u00faltima versi\u00f3n de OpenNI2 para x86. Es un bz2 que se descomprime en home. Tiene un script de instalaci\u00f3n que ejecuto y se instala. Tambi\u00e9n vienen los ejemplos compilados pero antes de probar a ejecutarlos hay que instalar un par de paquetes: freeglut3-dev y libusb-1.0-0-dev. Los instalo, enchufo el sensor, ejecuto NiViewer y \u00a1funciona!<\/p>\n Mi objetivo es poder compilar y depurar de una manera c\u00f3moda. Voy a usar Eclipse, pero la compilaci\u00f3n del paquete (librer\u00edas y aplicaciones de ejemplo) la hago con make en la l\u00ednea de comandos. Van saliendo errores: el compilador no encuentra alg\u00fan .h. Corresponden a paquetes que usa la librer\u00eda y que tengo que ir instalando para que vaya compilando. He instalado, adem\u00e1s de los que ya hab\u00eda instalado antes, doxigen, graphviz, libudev-dev y openjdk-6-jdk. Finalmente compila, pruebo NiViewer y funciona. Voy avanzando.<\/p>\n Ahora voy a compilar con Eclipse el ejemplo NiViewer. Ya se ha compilado con make pero quiero usar Eclipse para compilar en Release y Debug y poder depurar c\u00f3modamente. Me genero un Workspace y un proyecto del tipo \u201cMakefile Project with existing code\u201d con objetivo de clean, release y debug. Tengo que compilar el paquete completo en modo debug para que est\u00e9n disponibles tambi\u00e9n las librer\u00edas en modo debug. Finalmente, tras ajustar la configuraci\u00f3n t\u00edpica de Eclipse de paths y dem\u00e1s, consigo que compile y funcione el ejecutable, pero no puedo depurar: gbd no encuentra las librer\u00edas din\u00e1micas. Esto se arregla configurando la variable de entorno LD_LIBRARY_PATH con el valor apropiado.<\/p>\n Bueno, ya estoy en condiciones de generar aplicaciones c\u00f3modamente sobre OpenNI. Puedo compilar, linkar y depurar. Voy a rebuscar en qu\u00e9 formato vienen los datos en esos streams de video que he visto con la aplicaci\u00f3n de ejemplo NiViewer.<\/p>\n Para familiarizarse con la librer\u00eda OpenNI uno puede: bajarse del sitio de Occipital y leerse el \u201cOpenNI Programers Guide\u201d, s\u00f3lo te da una idea del alcance de la librer\u00eda\u00a0y\u00a0qu\u00e9 es lo que se puede hacer con cada clase; comprar y leerse por encima par\u00e1ndose en alg\u00fan ejemplo el libro \u201cOpenNI Cookbook\u201d de Soroush Falahati; y bucear por el c\u00f3digo fuente de la librer\u00eda y de los ejemplos de aplicaciones que incluye. Sin duda esta \u00faltima es la m\u00e1s efectiva pero las dos primeras tambi\u00e9n son muy \u00fatiles.<\/p>\n La librer\u00eda est\u00e1 desarrollada en C++.<\/p>\n El sensor se gestiona mediante una instancia de la clase Device. Las dos im\u00e1genes de video que se representan con el ejemplo NiViewer se corresponden con dos streams que genera el sensor. Uno de ellos env\u00eda la informaci\u00f3n de profundidad y el otro la informaci\u00f3n de color. Estos dos streams se gestionan mediante instancias de la clase VideoStream.<\/p>\n Para ponerlo en marcha, el sensor se \u201cabre\u201d con el m\u00e9todo open de la clase Device y se arranca con el m\u00e9todo start. Tras \u00e9sto, se pueden arrancar los streams. Se generan con el m\u00e9todo create. Con este m\u00e9todo se identifica el sensor del que procede y su tipo, es decir si se trata del stream de profundidad o del stream de color. Se ponen en marcha con el m\u00e9todo start.<\/p>\n Una vez arrancados los streams, si queremos informaci\u00f3n coherente de profundidad y de color, es necesario sincronizarlos. La sincronizaci\u00f3n se habilita con el m\u00e9todo setDepthColorSyncEnabled de la clase Device y se elige el modo de la sincronizaci\u00f3n con el m\u00e9todo setImageRegistrationMode.<\/p>\n Los streams van llegando frame a frame. Los frames se gestionan con una instancia de la clase VideoFrameRef.<\/p>\n Mediante la funci\u00f3n OpenNI::waitForAnyStream() se espera con un timeout a que llegue un nuevo frame de alguno de los dos streams. Como los streams est\u00e1n sincronizados, con esta funcion recibiremos secuencialmente los streams de profundidad y de color que van marcados con el mismo indice. Este \u00edndice numera cada frame desde un origen com\u00fan a los dos streams. Ser\u00e1 necesario verificar que el \u00edndice coincide en los dos frames, de profundidad y de color, que van a tratarse juntos.<\/p>\n \u00bfEn qu\u00e9 formato tenemos la informaci\u00f3n en los frames?<\/p>\n Un frame de profundidad est\u00e1 compuesto por un mapa de pixels representado por un array de 320\u00d7240 estructuras de tipo DepthPixel que no es m\u00e1s que un unsigned int de 16 bits. De esta manera, a cada pixel se le asigna un valor de profundidad que representa la distancia desde un plano que pasa por el objetivo de la c\u00e1mara hasta el objeto de la escena representado por ese pixel. Las coordenados X e Y son simplemente las posiciones en el mapa de pixels donde el origen es la esquina superior izquierda de la imagen.<\/p>\n Un frame de color est\u00e1 compuesto por un mapa de pixels representado por un array de 320\u00d7240 estructuras de tipo RGB888Pixel. Esta estructura tiene tres componentes, cada uno de ellos es un unsigned int de 8 bits y representa cada una de las componentes RGB de color del pixel. Esto es lo que habitualmente se conoce por un pixel RGB de 24 bits.<\/p>\n Las coordenadas X Y del frame de color coinciden con las del frame de profundidad por lo que en el frame de color esta la informaci\u00f3n del color con el que la camara RGB ve el punto representado en el frame de profundidad por las mismas coordenadas XY.<\/p>\n Ahora se entiende mejor qu\u00e9 es lo que representa el video pintado de amarillo. Son los mismos pixels del frame de video RGB pero pintados en distintos tonos de amarillo en funci\u00f3n de su distancia a la c\u00e1mara. Los pixels m\u00e1s brillantes est\u00e1n m\u00e1s cerca de la c\u00e1mara y los m\u00e1s oscuros est\u00e1n m\u00e1s lejos.<\/p>\n<\/body>","protected":false},"excerpt":{"rendered":" Estaba yo pensando\u2026 \u00bfSer\u00e1 un juguete o ser\u00e1 realmente \u00fatil? Cuando compr\u00e9 el ASUS Xtion Pro Live en Amazon por 143,71\u20ac ya imaginaba que no ser\u00eda lo mismo que los sensores de Prometheus, que escaneaban la cueva con una agilidad … Continue reading ![\"Imagen](\"http:\/\/www.rtbasics.com\/WP_2\/wp-content\/uploads\/2016\/04\/Adquisicion_depth-300x177.bmp\")
<\/a>![\"Imagen](\"http:\/\/www.rtbasics.com\/WP_2\/wp-content\/uploads\/2016\/04\/Adquisicion_color-300x186.bmp\")
<\/a><\/p>\n