Repositorio Institucional de Documentos

Proyecto Final de Carrera Ingeniería en Informática Curso 2012/2013 Visión por computador en dispositivos móviles para realidad aumentada Alfonso Escriche Martínez Septiembre de 2013 Directora: Ana Cristina Murillo Arnal Departamento de Informática e Ingeniería de Sistemas Escuela de Ingeniería y Arquitectura Universidad de Zaragoza RESUMEN Las técnicas de visión por computador se están extendiendo a los dispositivos móviles, gracias a la creciente mejoría de las especicaciones técnicas de los nuevos smartphones , que incrementan su capacidad computacional permitiendo aplicar algoritmos cada vez más complejos y costosos. Su aplicación estrella es la realidad aumentada, que se reere a la combinación visual de elementos reales con virtuales. Uno de los primeros ejemplos comerciales es Wikitude , que sale a la venta en 2008, y permite inicialmente insertar texto otante superpuesto a la imagen capturada por la cámara, cuando el usuario se encuentra en unas coordenadas determinadas y apuntando la cámara en una dirección concreta. Otro paso lo dan empresas como Layar o Qualcomm , quienes introducen la realidad aumentada basada en marcadores. Sus productos son capaces de reconocer ciertas imágenes impresas en carteles, y superponer un modelo virtual sobre ellas. La última evolución llega al poder sustituir esos marcadores por imágenes reales. De esta forma es posible reconocer elementos del mundo real, y las aplicaciones pasan de depender de un marcador impreso a un elemento físico concreto. Sin embargo, solo se ha enmascarado la limitación del cartel impreso. Las aplicaciones siguen siendo dependientes de que el usuario apunte su cámara hacia algo concreto. La mejora que este proyecto propone es detectar en tiempo real supercies planas en la escena, y proyectar sobre esta un modelo de realidad aumentada de una forma visualmente realista. Para ello se utilizan métodos de visión por computador que tratan de localizar este plano en la escena. Una vez determinada la supercie donde se puede mostrar la realidad aumentada, es necesario hacer un seguimiento de esta según se mueva la cámara. Es decir, si la cámara se mueve en una dirección, el modelo virtual debe también moverse acorde con el resto de la escena para mantener la sensación de realismo. Dado que ya existen diversas soluciones comerciales que permite realizar este seguimiento y proyectar un modelo virtual, el principal objetivo de este proyecto es aplicar y comparar distintos métodos de visión por computador para realizar la detección de la supercie plana en tiempo real, y después inicializar el seguimiento aplicando alguna de estas soluciones comerciales. Para demostrar esto se ha implementado un prototipo funcional para Android que ha sido probado en dispositivos actuales de gama media, un tablet , un smartphone y diversos dispositivos simulados o ADV, Android Virtual Device , con especicaciones técnicas propias de un dispositivo de gama media que el usuario medio posee. Se ha comprobado que es posible realizar lo que este proyecto propone, aunque debido a ciertas limitaciones de las soluciones comerciales de realidad aumentada, no se ha podido alcanzar un resultado listo para un producto comercial todavía. i Agradecimientos A mi hermana Cristina, infatigable betatester , o más concretamente, infatigable acompañante en las calurosas mañanas de recolección de vídeos e imágenes como material de pruebas. A mis amigos y socios Carlos y Mateo, pues fueron nuestras tardes de brainstorming las que me dieron las primeras ideas para hacer este proyecto; y es nuestro proyecto empresarial juntos el que me ha motivado a llevarlo a cabo con máxima ilusión. También a mis amigos Ricardo, quien a veces parecía tener más interés en ver nalizado este proyecto que yo mismo, y Julio, a pesar de que aun estoy esperando el modelo tridimensional de la catedral de León que me prometió. Por último, aunque por ello más importante , Ana Cris, guía más que directora de este proyecto. No solo por enseñarme y repetirme n veces hasta los más simples conceptos de visión, sino por reencaminarme las múltiples veces que perdía el norte. iii Índice general 1. Introducción 1 1.1. Contextoymotivación............................. 2 1.2. Objetivosyalcance............................... 3 1.3. Metodología y entorno de trabajo . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Trabajo previo relacionado . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Organización de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Detección de supercies planas 9 2.1. Análisisgeneral................................. 10 2.2. Detección usando una secuencia . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3. Detección usando dos frames distantes . . . . . . . . . . . . . . . . . . . . 13 2.4. Comparativa y pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.5. Conclusiones................................... 21 3. Tracking y proyección 23 3.1. Análisisgeneral................................. 24 3.2. Integración de una solución comercial: Vuforia . . . . . . . . . . . . . . . . 26 3.3. Solución provisional: Optical Flow . . . . . . . . . . . . . . . . . . . . . . . 29 3.4. Conclusiones................................... 31 4. Prototipos 33 5. Conclusiones 37 5.1. Valoraciónpersonal............................... 38 5.2. Trabajofuturo ................................. 38 A. API del framework desarrollado 43 B. Prototipo RA 47 C. Pruebas módulo 1 51 D. Pruebas módulo 2 65 v Capítulo 1 Introducción Figura 1.1: Diagrama general del proceso Debido a la creciente capacidad computacional de los dispositivos móviles, están aumentando las opciones de utilizar técnicas de visión por computador para múiltiples aplicaciones. La realidad aumentada es un ejemplo que proporciona nuevas funcionalidades y atractivos a las aplicaciones móviles. La visión por computador es la herramienta clave para incluir elementos articiales en imágenes o vídeos capturados desde la cámara de estos dispositivos de manera realista. Sin embargo, muchos métodos actuales de realidad aumentada utilizan marcadores articiales, cuyo funcionamiento se detalla más adelante, o no integran los elementos virtuales de acuerdo a la geometría de la escena, creando un resultado poco realista. Este proyecto propone, por un lado, estudiar y evaluar las opciones de distintas técnicas de visión por computador (que analizan la geometría de la escena capturada por la cámara) para determinar dónde y cómo debe proyectarse un elemento gráco de realidad aumentada. Por otro lado, implementar un prototipo realista de realidad aumentada que se pueda integrar en aplicaciones para móviles. El desarrollo del proyecto se ha dividido en dos módulos principales. El primero de ellos trata de la detección de supercies planas de la escena en imágenes obtenidas a través de la cámara del dispositivo, ya que queremos aprovechar estas supercies planas para proyectar en ellas la información aumentada de la escena. El segundo módulo se ocupa de la proyección del modelo virtual en los sucesivos frames. 1 Capítulo 2 Módulo de detección de supercies planas en la escena Figura 2.1: Módulo de detección de supercies planas Como se ha visto en el diagrama general de la gura 1.1, el primer paso para llevar a cabo el objetivo del proyecto es la detección de una supercie plana en la escena sobre la que poder proyectar el modelo virtual. Para esto se han probado distintas técnicas de visión por computador que más adelante se describen, usando las APIs de OpenCV[18] y FastCV[19]. Es decir, este primer módulo recibe como entrada dos imágenes, o en el caso del prototipo desarrollado, frames capturados con la cámara, y los procesa ejecutando ciertos algoritmos de visión por computador. Su salida es una posición dentro de la escena 9 2.1 Análisis general 2. Detección de supercies planas en la que se puede proyectar un objeto virtual, en el caso de que se haya encontrado una supercie plana adecuada para ello. 2.1. Análisis general Para la detección de una supercie plana en la escena se ha optado por utilizar la aproximación que se describe en 2.2. Figura 2.2: Diagrama general del proceso de detección usando dos frames Se obtienen dos imágenes o, en el caso del prototipo desarrollado, dos frames cargados de la memoria interna del dispositivo o de una tarjeta microSD que estuviese insertada. Estos frames deben estar separados entre sí (una distancia mínima mayor o menor en función del método utilizado) y debe haber una rotación entre ambos. Se obtienen los puntos de interés o keypoints de ambas imágenes, y se extraen los descriptores de estos. Después se procede a buscar emparejamientos entre puntos de ambas imágenes, y con ellos se calcula una homografía. Lo que se ha probado con este módulo han sido diferentes métodos para obtener puntos de interés, descriptores y emparejamientos para terminar calculando una homografía. Estos métodos se comparan teniendo en cuenta su tiempo de ejecución y el resultado obtenido con ellos. La clave para detectar supercies planas en la escena es el cálculo de una homografía usando los puntos de interés de ambas imágenes, pues una homografía relaciona los puntos de dos imágenes que se encuentran en la misma supercie plana. Por tanto, si somos capaces de calcular una homografía entre los puntos de interés en dos imágenes separadas de la misma escena, presumíblemente habremos obtenidos un conjunto de puntos 10 2. Detección de supercies planas 2.1 Análisis general coplanares. Calculando una homografía entre los emparejamientos de puntos obtenidos en las imágenes, podremos de discernir cuáles de esos puntos corresponden a un mismo plano dominante en la escena: aquellos puntos que hayan votado por la homografía serán coplanares. Hablamos de plano dominante puesto que la homografía tenderá a obtener los puntos de la supercie mayor, en la que se habrán extraído mayor cantidad de puntos. Figura 2.3: Puntos de interés obtenidos en dos frames de una secuencia de vídeo Figura 2.4: Emparejamientos En la imágen 2.3 vemos los puntos de interés que se han obtenido. Se marcan los puntos en los que hay una diferencia de gradiente, es decir, los cambios bruscos de color. Vemos además que se han obtenido puntos sobre la tarjeta que está en primer plano, sobre la que está medio oculta, pero también fuera, en las esquinas del monedero. Después de calcular la homografía se han representado en la gura 2.4 los puntos que han validado la homografía, esto es, los puntos que son coplanares. Se ve que se ha obtenido la supercie 11 2.2 Detección usando una secuencia 2. Detección de supercies planas dominante, es decir, la que estaba en primer plano, y los puntos fuera de esta han quedado descartados. 2.2. Detección usando una secuencia En primer lugar se ha probado un método basado en múltiples frames de una misma secuencia. En tiempo real el usuario de la aplicación va a estar obteniendo frames de vídeo con la cámara de su dispositivo móvil, por lo que este parece un buen punto de comienzo. Para este método se ha utilizado el algoritmo de ujo óptipo de Bruce D. Lucas y Takeo Kanade , en su implementación optimizada de FastCV . El ujo óptico es el patrón del movimiento aparente de los objetos, supercies y bordes de una escena causado por el movimiento relativo entre el observador, en nuestro caso la cámara del dispositivo móvil, y la escena. Introducido inicialmente en la década de 1940 por el psicólogo estadounidense James J. Gibson, actualmente es utilizado en visión por computador para la percepción de movimiento, estimación de forma o distancia de un objeto respecto del observador.[20] En todas las estrategias de estimación de ujo óptico se parte de la hipótesis de que los niveles de gris permanecen constantes ante movimiento espaciales en un tiempo dado. Dicha hipótesis da lugar a la ecuación general de ujo óptico (1), donde I(x,y,t) corresponde a la intensisdad en niveles de gris del píxel (x,y) de la imagen I en el tiempo t . I(x,y,t) = I(x+dx,y+dy,t+dt) (1) Expandiendo (1) en series de Taylor sobre el punto (x,y,t) I(x,y,t) = I(x,y,t)+dx ∂I ∂x +dy ∂I ∂y +dt ∂I ∂t + ε donde ε contiene la información de las derivada de orden superior. Si se asume ε despreciable, la ecuación de ujo óptico puede reescribirse como Ix u + Iy v + It = 0 (2) donde (u,v) , con u = dx/dt y v = dy/dt , corresponde al vector de ujo óptico y, Ix y Iy son las derivadas parciales horizontal y vertical de la imagen, respectivamente. Para cada píxel x,y de la imagen, en el tiempo t , puede plantearse la ecuación (2), sin embargo, no existe una única solución para esta ecuación. Diferentes restricciones pueden emplearse para estimar el ujo óptico en la imagen. Lucas y Kanade se basan en gradientes espacio-temporales y asumen que el ujo óptico es constante sobre una región[12]. De esta forma, al ser constante en un vecindario cercano al píxel que se está analizando, se pueden 12 2. Detección de supercies planas 2.3 Detección usando dos frames distantes resulver las ecuaciones básicas del ujo óptico para todos los píxeles de ese vecindario por el criterio de los mínimos cuadrados. Se ha utilizado la implementación del algoritmo piramidal de ujo óptico de LucasKanade de FastCV , que se aplica de forma iterativa sobre sucesivos frames de una secuencia para realizar el seguimiento de los puntos de interés calculados en el frame inicial con un método de extracción de puntos de interés (en este caso puntos fast ). Terminada la secuencia se calcula una homografía entre los puntos que han sido trackeados con éxito desde el primer frame al último, como se muestra en la gura 2.5. Es decir, se utilizan como emparejamientos para calcular una homografía los puntos del primer frame con los del último frame que han sido trackeados. Figura 2.5: Diagrama del método 2.3. Detección usando dos frames distantes En este caso el método utilizado se basa en dos imágenes de la misma escena separadas sucientemente. La idea es obtener dos imágenes en las que haya rotación del punto de vista, es decir, de la cámara del dispositivo, y obtener sus puntos de interés. A través de un método de matching se intenta hacer emparejamientos entre los puntos obtenidos en ambas imágenes para después obtener una homografía de la que poder deducir los puntos coplanares. En este caso, por tanto, es necesario que haya esta separación mínima entre las dos imágenes para evitar que dos puntos no coplanares puedan considerarse en el mismo plano por no haber cambiado la perspectiva. Para realizar los emparejamientos se han probado dos algoritmos: la implementación de FLANN de OpenCV y la búsqueda de vecinos cercanos usando un KDTree de FastCV . FLANN, Fast Library for Approximate Nearest Neighbors , es una biblioteca que contiene una colección de algoritmos optimizados para la búsqueda de vecinos cercanos en grandes 13 2.3 Detección usando dos frames distantes 2. Detección de supercies planas Figura 2.6: En este caso no hay apenas separación entre los dos frames, y podría dar lugar a error al considerarse todos los puntos coplanares Figura 2.7: Entre los dos frames ha habido rotación, por tanto, no hay posibilidad de fallo en la homografía y los puntos de la barandilla no serán considerados coplanares con los del respaldo de la silla conjuntos de datos. El método de FastCV consiste en crear un KDTree que se utiliza como base de datos en la que realizar consultas para encontrar los vecinos cercanos. En la base de datos se introducen tanto los valores correspondientes al descriptor de cada punto, como la inversa del cuadrado de la normal del vector que contiene esos valores. De esta forma, al hacer una consulta se busca primero utilizando este valor y después se rena el resultado comparando todos los valores del descriptor (un vector de 36 valores enteros de 8 bits cada uno) de los posibles aciertos. La principal diferencia entre estos dos métodos es la misma que nos encontramos en 14 2. Detección de supercies planas 2.3 Detección usando dos frames distantes practicamente todas las implementaciones de OpenCV frente a FastCV . La primera es más robusta y está encapsulada de forma que se realizada un método complejo que hace diversas acciones, no todas utilizadas o requeridas en ese momento, con una sola sola llamada a función, mientras que FastCV proporciona el núcleo del método y corre por cuenta del desarrollador programar el algoritmo. De esta forma es más complejo y costoso, pero se puede implementar tan solo lo estrictamente necesario para realizar la función deseada. Los resultados obtenidos son una media aproximada de 100ms utilizando OpenCV frente a 45ms con FastCV . Se utiliza por tanto este último para la implementación del proyecto. Para la extracción tanto de puntos de interés como de descriptores también se han comparado diferentes implementaciones de métodos de OpenCV y FastCV que a continuación se explican (en el capítulo de Pruebas se muestran los resultados). Para decidir qué métodos probar se ha partido de los resultados de estudios comparativos previos, como el realizado por Ievgen Khvedchenia[21], del que extraemos un resumen de los tiempos de ejecución de distintos algoritmos en la gura 2.8. Figura 2.8: Tiempos de ejecución de distintos métodos de detección OpenCV - FAST Se trata de la implementación del algoritmo presentado en 2005 por Edward Rosten y Tom Drummond [8][9][10]. Este se basa en comparar un anillo de píxeles alrededor del punto en cuestión, como se ve en la imagen 2.9. 15 2.3 Detección usando dos frames distantes 2. Detección de supercies planas Figura 2.9: Path utilizado por FAST FastCV - FAST La implementación de FastCV permite personalizar algo más la ejecución del método. Mientras que OpenCV solo toma como parámetro el threshold a utilizar, es decir, el valor a partir del cual se considera un cambio válido de gradiente; esta permite especicar el número de píxeles que deben ser descartados en los bordes superior, inferior, izquierdo y derecho de la imagen, y el paso en píxeles entre las columnas de la imagen. Además proporciona un método de parada indicando el número máximo de puntos que se deben encontrar. Este método de parada ha resultado efectivo en nuestro caso para evitar problemas de memoria en imágenes con, por ejemplo, mucha textura y mucha luz. En estos casos, alcanzado un determinado número de puntos de los que luego se extraían sus descriptores y se trataban de emparejar con un número similar de puntos de otra imagen, se alcanzaba el límite de memoria del dispositivo de pruebas, provocando una excepción manejada por el SO que causa la detención y reinicio de la aplicación prototipo. OpenCV - Oriented BRIEF Abreviado ORB , este método desarrollado en la incubadora californiana de empresas Willow Garage es resistente al ruido y al menos dos órdenes de magnitud más rápido que SIFT , mientras que su resultado es igual de bueno en la mayoría de las situaciones[13]. Se ha probado solo su implementación de OpenCV al no estar disponible en FastCV 16 2. Detección de supercies planas 2.4 Comparativa y pruebas Otros También se han probado, con peores resultados, el método BRISK desarrollado por Autonomous Systems Lab [14], y las implementaciones de OpenCV de SURF , SIFT , BRIEF y FREAK [18]. Se han probado también en combinación con el adaptador grid . La imagen se divide en una cuadrícula y se aplica el método de detección de puntos de interés a cada celda de forma independiente. 2.4. Comparativa y pruebas Para comparar los distintos métodos se han implementado en un prototipo, descrito en el capítulo 4, que carga las imágenes de la tarjeta SD o la memoria del dispositivo. Se aplica un método de extracción de puntos y descriptores, hace los emparejamientos y calcula una homografía. Finalmente muestra los resultados e indica el número de puntos de interés extraídos, el número de emparejamientos totales y los que han votado por la homografía, asi como el tiempo de ejecución de cada parte del algoritmo. Tras múltiples pruebas con imágenes aleatorias obtenidas con la cámara del dispositivo, se ha utilizado para las comparaciones una selección signicativa de 11 escenarios con distintos grados de dicultad y particularidades representativas de los casos que se podrán encontrar en el uso real. A continuación se describen estos escenarios, cuyos nombres identican cada banco de pruebas, que puede encontrarse en el anexo C y en el directorio correspondiente de la documentación digital adjunta. 1. Estatua_justicia. Dicultad alta . El monumento no tiene textura, al ser de un gris piedra casi uniforme, mientras que en el resto de la escena hay mucha textura tanto en los árboles como en los edicios con ventanas. 2. Cartel_aragon. Dicultad alta . El plano dominante se encuentra tras un cristal que, debido al cambio en el reejo del sol según el distinto grado de incidencia en las distintas perspectivas, diculta los emparejamientos entre puntos de interés. 3. Portal_reja. Dicultad alta . Ejemplo de patrones repetidos, lo que complica la obtención de emparejamienetos válidos. 4. Cartel_corte_ingles. Dicultad alta . Ejemplo de escena en donde no hay un plano dominante, debido a la distancia del plano que se quería usar respecto de la cámara. 5. Cartel_ibercaja. Dicultad alta . En este escenario el supuesto plano dominante no tiene la textura suciente debido al reejo del sol. Además, hay diversos patrones repetidos que dicultan los emparejamientos. 17 3.1 Análisis general 3. Tracking y proyección Esta es la funcionalidad del siguiente módulo del proyecto, que se describe en la gura 3.1. 3.1. Análisis general Para este módulo se ha elegido el SDK de realidad aumentada de Qualcomm , Vuforia [22]. Se ha optado por esta plataforma y no otra en primer lugar porque el primer módulo ha sido desarrollado en parte usando FastCV , también propiedad de Qualcomm , por lo que la integración entre ambas plataformas es más sencilla. En segundo lugar, Vuforia cuenta con una comunidad de más de 60000 desarrolladores registrados[23]; y además se trata de una plataforma muy optimizada para su despliegue en móviles, con soporte tanto para Android como iOS , y también para el motor de videojuegos Unity [24]. Según su propia descripción, una aplicación de realidad aumentada basada en el SDK de Vuforia usa la pantalla del dispositivo móvil como unas "lentes mágicas". La aplicación renderiza la imagen previsualizada en la cárama y se superponen objetos virtuales 3D[25]. La gura 3.2 ilustra el proceso. Figura 3.2: Uso de Vuforia El desarrollador debe disponer préviamente de las imágenes que quiere reconocer con su aplicación. Estas deben ser subidas al Web Management System de Vuforia y, o bien se crea una base de datos de imágenes alojada en la nube que se consultará en tiempo de ejecución, o bien se descarga dicha base de datos y se incluye en la aplicación. Durante la ejecución de la aplicación, esta interacciona con el motor de Vuforia para reconocer 24 3. Tracking y proyección 3.1 Análisis general las imágenes almacenadas en la base de datos. Cuando el motor de Vuforia detecta una imagen en la escena, se puede proyectar el contenido virtual creado por el desarrollador. Figura 3.3: Diagrama de ujo de datos en una aplicación de ejemplo La gura 3.3 muestra el diagrama de ujo de datos en una aplicación de ejemplo que usa el SDK de Vuforia . La cámara del dispositivo obtiene un frame que se convierte al formato requerido y se pasa al tracker , que puede tener distintas conguraciones. Este proyecto se ha basado en el tracker ImageTargets , es decir, reconoce un solo target o marcador en el frame. Esto es así porque la supercie plana se considera como un marcador-imagen, y suponemos que en la escena solo vamos a tener una única supercie plana dominante, por tanto no tendrá sentido poder reconocer dos marcadores, es decir, dos supercies planas distintas sobre las que proyectar nuestro modelo. El tracker obtiene la lista de marcadores que tiene que buscar de la base de datos alojada en la nube, o integrada en la aplicación, o se han podido crear los marcadores en tiempo de ejecución a partir de frames obtenidos por la cámara del dispositivo móvil. Esta última opción es la que se ha desarrollado en el proyecto. Finalmente, el tracker indica dónde debe renderizarse el modelo, y el nuevo frame se proyecta en la pantalla. 25 3.2 Integración de una solución comercial: Vuforia 3. Tracking y proyección Basándonos en este diagrama, queremos modicar el proceso para obtener los marcadores no de una base de datos creada a través del Web Management System de Vuforia , sino obtenerlos del módulo de detección de supercies planas. Es decir, queremos utilizar como entrada del tracker la salida del módulo desarrollado anteriormente en este proyecto. Figura 3.4: Modicación que se pretende llevar a cabo 3.2. Integración de una solución comercial: Vuforia Como se ha explicado anteriormente, para la implementación del prototipo se ha utilizado el SDK de Vuforia . El punto de partida han sido dos de las aplicaciones de ejemplo proporcionadas a la comunidad de desarrolladores 1 . La primera de ellas, Image Targets , reconoce como marcador una imagen de pequeñas piedras amontonadas que puede ser imprimida por el usuario, y proyecta una tetera tridimensional sobre esta. La segunda, User-dened Targets , permite al usuario seleccionar en tiempo de ejecución un frame de la cámara como marcador que será reconocido a partir de ese momento. A partir de este último se ha extraído el diagrama de estados general en que se pretende basar este módulo, mostrado en la gura 3.5. Se omite la parte irrelevante para el proyecto, como la preparación de estructuras y cargado de interfaz, texturas del modelo, etc. El diagrama 1 https://developer.vuforia.com/resources/sample-apps 26 3. Tracking y proyección 3.2 Integración de una solución comercial: Vuforia comienza en el momento en que la cámara ha sido activada y se ha iniciado el análisis de las imágenes con una instancia del objeto QCAR::Tracker . Figura 3.5: Diagrama de estados de la parte relevante de la aplicación de ejemplo UserDenedTargets Esta instancia del tracker es un detector de puntos de interés que analiza cada uno de los frames de la cámara en busca de features . Si en un frame se obtienen sucientes puntos, se considera válido para proyectar realidad aumentada sobre este y al usuario se le señaliza marcando un cuadro verde en la interfaz. En ese momento el usuario puede elegir pulsar el botón para aceptarlo como imagen de referencia. Se crea un objeto Trackable con la información del frame actual. Este será el objeto que será buscado a partir de ahora. Se entra en un bucle en el que se analizan todos los frames de la cámara y si se encuentra el objeto Trackable , se proyecta el modelo virtual. Hay que destacar que este objeto Trackable no tiene que ser un objeto físico concreto o un plano real. Cualquier imagen en la que haya sucientes puntos de interés puede ser tomada como válida. A efectos prácticos, el frame con el que se construye el objeto se considera un plano, y el modelo virtual se proyecta apoyado sobre este, y de tamaño proporcional a la distancia de este. Por tanto, la parte que debemos modicar es esta inicialización del tracker . Se quiere que en lugar de utilizar cualquier frame de cámara con sucientes puntos, se utilice la supercie plana que previamente hemos encontrado en la escena con el módulo anterior de este proyecto. La gura 3.7 muestra el diagrama de secuencia de creación de este objeto Trackable . El módulo que se quiere construir en este apartado debe tener un compor27 3.2 Integración de una solución comercial: Vuforia 3. Tracking y proyección Figura 3.6: Features encontrados en una imagen cargada en el Target Manager Web System . Se muestra la puntuación de la imagen y las recomendaciones que debe seguir una buena imagen. Este análisis es similar al que se realiza en tiempo de ejecución en las aplicaciones con el objeto QCAR::Tracker tamiento similar a la aplicación de ejemplo User-dened Targets , pero se debe eliminar por completo el análisis inicial de frames de Vuforia para sustituirlo por el módulo desarrollado en el anterior capítulo. Adicionalmente, se debe construir un objeto Trackable utilizando la salida de dicho módulo, en lugar de obtenerlo con el ImageTracker . Problema encontrado Esta solución no se ha podido aplicar al proyecto debido a la limitación existente de la API proporcionada. No hay que olvidar que Vuforia ofrece un servicio de pago de reconocimiento de imágenes en la nube, y a pesar de que ha liberado gran parte de la API con su SDK, de alguna forma tiene que proteger dicho servicio. Actualmente es imposible crear un objeto Trackable de una forma distinta a la mostrada en la gura 3.7, a partir de un archivo de base de datos descargado e incluido en el código fuente de la aplicación creado con el Target Manager Web System , o utilizando su servicio de Cloud Recognition que permite mantener esta base de datos de trackables en su nube. Citando a AlessandoB , desarrollador y moderador de Vuforia , a fecha de Junio 27, 2013, en su respuesta a la pregunta de si era posible de alguna forma crear un objeto trackable a partir de una imagen, o crear de alguna forma el archivo de base de datos: Hi, such solution does not exist, you need to pass through the Target Manager. [26] y ante la pregunta de si se contempla habilitar la posibilidad de crear trackables de otra forma en futuras versiones, la respuesta es: 28 3. Tracking y proyección 3.3 Solución provisional: Optical Flow Figura 3.7: Diagrama de secuencia de la creación del objeto Trackable Hi, at the moment I cannot tell whether this may change in the future. I can invite you however to post in our Forum Wish-List, as this might be taken into consideration for the future: https://developer.vuforia.com/forum/general-discussion/ wish-list [26] 3.3. Solución provisional: Optical Flow Al ser imposible implementar actualmente el módulo utilizando la solución comercial de Vuforia , pero con la posibilidad de que en un futuro sí que se libere esta funcionalidad, se ha buscado una solución provisional alternativa. La opción elegida ha sido aplicar el algoritmo de ujo óptico de Bruce D. Lucas y Takeo Kanade estudiado en el capítulo 2. Este algoritmo permite emparejar una serie de puntos de interés de dos imágenes siempre y cuando ambas estén separadas una distancia pequeña, del orden de unos pocos pixeles. Por tanto es ideal para realizar el seguimiento a un objeto en distintos frames consecutivos de una imagen de cámara. Por tanto, para la implementación de este módulo se ha tomado como entrada el último frame obtenido para encontrar la supercie plana en la escena y sus puntos de interés que serán trackeados en los sucesivos frames. De esa forma se calcula la nueva ubicación del plano en cada nuevo frame, y usando los sensores del dispositivo móvil se obtiene la matriz de rotación, los ángulos y la orientación que permiten calcular de qué forma debe proyectarse el modelo virtual. Para calcular la posición en que debe centrarse 29 3.3 Solución provisional: Optical Flow 3. Tracking y proyección el modelo, se estima el punto medio del plano a partir de las coordenadas de la nube de puntos de interés del mismo. En la gura 3.8 se muestra a alto nivel el funcionamiento del módulo. Se trata de un bucle que busca el plano, calcula la posición en que debe proyectarse el modelo virtual y renderiza. Los frames utilizados en el Optical Flow son siempre el actual y el anterior, donde ya se han calculado los puntos de interés y se ha localizado la supercie plana. Por tanto, en la primera iteración se le pasa como parámetro el último frame donde se detectó el plano en el módulo primero. Figura 3.8: Diagrama de ujo de datos del módulo de tracking y proyección 30 3. Tracking y proyección 3.4 Conclusiones 3.4. Conclusiones Como se ha explicado anteriormente, no ha sido posible impementar el módulo enteramente utilizando el SDK de Vuforia debido a una limitación que impedía crear un marcador en tiempo real a partir del resultado obtenido en el módulo primero. Por tanto, se ha tenido que optar por sustituir el tracker por otra solución desarrollada desde cero. Podemos decir, sin embargo, que la principal conclusión del estudio de este módulo es que sí es técnicametne posible la proyección de realidad aumentada sin utilizar un marcador predenido, sino una supercie plana encontrada directamente en la escena capturada con la cámara del dispositivo móvil. Aunque el prototipo desarrollado no es tan robusto como podría haber sido utilizando el SDK de Vuforia , sí que permite comprobar que es posible realizarlo. Y sabemos que dedicándole todo el tiempo y trabajo de desarrollo necesario, sería posible implementar desde cero una solución similar al tracker de Vuforia . Sin embargo, no es desarrollar un nuevo SDK de realidad aumentada el objetivo del presente proyecto. Las imágenes 3.9 y 3.10 muestran dos ejemplos de visualización del modelo virtual, por defecto la habitual tetera tridimensional, sobre supercies planas. Estas son imágenes tomadas como pantallazos de la aplicación en tiempo real. Se pueden ver más pruebas en el anexo D Figura 3.9: Visualización del modelo virtual renderizado sobre la supercie de un cartel publicitario. 31 3.4 Conclusiones 3. Tracking y proyección Figura 3.10: Visualización del modelo virtual renderizado sobre un folleto. Como puede verse, la proyección es visualmente atractiva y realista. Queda apoyada sobre la supercie plana, y su tamaño se ajusta proporcionalmente al de dicha supercie. Además, la orientación es también proporcional a la orientación del plano y a la posición de la cámara. En la imagen 3.9, el plano es vertical respecto al suelo, y la cámara está situada por debajo del plano, es decir, se está viendo con una inclinación de unos 30 o . El modelo virtual aparece proyectado acorde a estos valores, se muestra inclinado en contraposición a la inclinación de la cámara. Lo mismo sucede en la imagen 3.10. En este caso la cámara se encuentra por encima del plano donde se proyecta el modelo virtual, así que la inclinación de este se ajusta para mantener la impresión de estar apoyado. 32 Capítulo 4 Prototipos Se han implementado dos prototipos, uno como aplicación de prueba donde testar los distintos algoritmos de visión por computador y servir de framework para el módulo de detección de supercies planas, y un prototipo nal donde se integra el primer módulo ya terminado con el segundo de tracking y proyección del modelo virtual. En la documentación adjunta se puede encontrar el código fuente de ambos prototipos así como sendos archivos .apk ya compilados y listos para ser instalados en un dispositivo Android . Prototipo de prueba de algoritmos de visión por computador Este prototipo consiste en una interfaz trivial que permite al usuario cargar dos imágenes de memoria interna o de una tarjeta SD introducida en el dispositivo, y aplicar los algoritmos en cuestión que se quieran probar sobre ellas. No se trata de una aplicación de usuario ni tiene ninguna funcionalidad concreta, es tan solo un framework en el que insertar el código del método que se desee testar. En la gura 4.1 se muestra el diagrama de ujo de datos del prototipo. El prototipo está diseñado como un framework de forma que los métodos de obtención de puntos de interés, descriptores, emparejamientos y homografía puedan sobreescribirse e insertar el código que se desee testar. De esta forma, en el código fuente del prototipo, que se puede consultar en los anexos, se pueden ver en la interfaz nativa /Prototipo1/jni/protectoCV.h las siguientes funciones: ndPoints(n, method) : busca los puntos de interés de la imagen número n cargada previamente. Guarda estos puntos en la estructura correspondiente dentro de los parámetros del objeto, y devuelve el número de puntos encontrado. ndDescriptors(n, method) : busca los descriptores de los puntos de interés anteriormente calculados. ndMatches(method) : busca emparejamientos entre dos frames. homography() : calcula una homografía. 33 BIBLIOGRAFÍA BIBLIOGRAFÍA [14] BRISK: Binary Robust Invariant Scalable Keypoints , Stefan Leutenegger et al. Autonomous System Lab, ETH Zürich, 2011 [15] Desarrollo de una aplicación de realidad aumentada mediante la arquitectura Vuforia para la obtención de información de cuadros , César Iñarrea Sagüés. Escuela Técnica Superior de Ingenieros Industriales y de Telecomunicación, Navarra, España, 2012 [16] Herramientas de desarrollo libres para aplicaciones de realidad aumentada con Android. Análisis comparativo entre ellas , Ana Serrano Mamolar. Universidad Politéctina de Valencia, España, 2012 [17] Harness the Rise of the machines: FastCV, Accelerating Mobile Computer Vision , Michael Mangan, UPLINQ 2012 Conference [18] API de OpenCV: http://docs.opencv.org/modules/features2d/doc/common_ interfaces_of_feature_detectors.html , Common Interfaces of Feature Detectors [19] API de FastCV: https://developer.qualcomm.com/docs/fastcv/api/modules. html [20] Wikipedia: https://en.wikipedia.org/wiki/Optical_flow , Optical Flow [21] Comparison of the OpenCV's feature detection algorithms , Ievgen Khvedchenia, 2011. Disponible: http://computer-vision-talks.com [22] API de Vuforia: https://developer.vuforia.com/resources/api [23] Sitio web de Vuforia: https://www.vuforia.com/ , Vuforia's Growing Ecosystem [24] Sitio web de Unity: http://unity3d.com/ [25] Guía de desarrollo de Vuforia: https://developer.vuforia.com/resources/ dev-guide/getting-started , Developing with Vuforia [26] Foro de desarrolladores de Vuforia: https://developer.vuforia.com/forum/ [27] Lucas-Kanade 20 Years On: A Unifying Framework , Simon Baker et al. The Robotics Institute, Carnegie Mellon University, Pittsburgh, PA 15213, USA [28] Computer Vision Working Group Proposal, 1st December 2011 , disponible: http://www.khronos.org/assets/uploads/developers/library/ Computer-Vision-Working-Group-Proposal-Dec11.pdf 40 Apéndices 41 Apéndice A API del framework de visión por computador desarrollado en C++ int loadImage (JNIEnv *env, jobject obj, jstring root, jint n); @brief Lee una imagen y la guarda para su posterior tratamiento @param root: ruta de la imagen n: número de imagen @return 0 si hay algún error void saveMatches (JNIEnv *env, jobject obj, jstring root); @brief Guarda la imagen de los matches encontrados. Se supone que previamente se habrá llamado a la función showMatches() @param root: ruta donde se guardará la imagen 43 A. API del framework desarrollado void showImage (JNIEnv *env, jobject obj, jint n); @brief Renderiza la imagen @param n: número de imagen void showCorners (JNIEnv *env, jobject obj, jint n); @brief Renderiza la imagen indicada por n con los puntos de interés que previamente se han calculado @param n: número de imagen void showMatches (JNIEnv *env, jobject obj, jint method); @brief Muestra una composicón de la imagen inicial y nal de la secuencia, mostrando los matches que ya se han calculado @param method: 0 para OpenCV FLANN o 1 para FastCV KDTree jint ndPoints (JNIEnv *env, jobject obj, jint n, jint method, jint threshold); @brief Aplica el algoritmo indicado por method, con el valor de threshold indicado a la imagen número n, para calcular sus puntos de interés @param n: número de imagen method: 0, 1 y 4 ->FAST 2 ->FastCV 3 ->GridORB 5 ->ORB compuesto 6 ->ORB 44 A. API del framework desarrollado 7 ->BRISK 8 ->GridBRISK threshold: variación de tono a partir de la cual se considera punto de interés jint ndDescriptors (JNIEnv *env, jobject obj, jint n jint method); @brief Aplica el algoritmo indicado por method para la extracción de descriptores @param n: número de imagen method: 0, 1 y 4 ->FAST 2 ->FastCV 3 ->GridORB 5 ->ORB compuesto 6 ->ORB 7 ->BRISK 8 ->GridBRISK @return número de descriptores indicados textitjint ndMatches (JNIEnv *env, jobject obj, jint method); @brief Aplica el algoritmo indicado por method para la búsqueda de emparejamientos @param n: número de imagen method: 0 para OpenCV FLANN o 1 para FastCV KDTree @return número de emparejamientos encontrados 45 A. API del framework desarrollado jint homography (JNIEnv *env, jobject obj, jint method); @brief Calcula una homografía @param method: método con el que se han calculado previamente los matches @return 1 si se ha calculado jint checkHomography(JNIEnv *env, jobject obj, jint method); @brief Muestra los emparejamientos que han votado por la homografía, es decir, que han sido considerados inliers @param method: método con el que se han calculado previamente los matches @return número de matches válidos para la homografía 46 Apéndice B Prototipo nal A continuación se describe el funcionamiento del prototipo nal de proyección de realidad aumentada sobre una supercie plana a través de diagramas de estados que explican toda la ejecución de la aplicación. Figura B.1: El usuario inicia la aplicación y se le muestra una pantalla de carga y el funcionamiento. 47 B. Prototipo RA Figura B.2: Se cargan las texturas del modelo virtual y se inicializan todas las estructuras necesarias. 48 B. Prototipo RA Figura B.3: Se muestra la interfaz principal, imagen 4.2. Al pulsar en la cámara se captura el frame actual y se obtienen sus puntos de interés y descriptores. Se hace lo mismo con un segundo frame y se trata de buscar una supercie plana en la escena. 49 C. Pruebas módulo 1 56 C. Pruebas módulo 1 57 C. Pruebas módulo 1 58 C. Pruebas módulo 1 59 C. Pruebas módulo 1 60 C. Pruebas módulo 1 61 C. Pruebas módulo 1 62 C. Pruebas módulo 1 63 C. Pruebas módulo 1 64 Apéndice D Pruebas del módulo de realidad aumentada En este anexo se detallan los resultados obtenidos en los distintos escenarios en los que se ha testado el prototipo 2. Se muestran después capturas de pantalla del módulo de proyección de realidad aumentada. En ellas se ven proyecciones del modelo virtual sobre distintas supercies, obtenidas durante la ejecución de las pruebas del prototipo 2. 65