resumen memoria pfc: tangible: sistema de bajo coste para localización y detección de gestos 3d en...

TANGIBLE: Sistema de bajo coste

para localización y detección de gestos 3D en entornos inmersivos

Grupo de Informática Gráfica Avanzada

Departamento de Informática e Ingeniería de Sistemas

Centro Politécnico Superior

Curso académico: 2009-2010 Fecha: Noviembre de 2009

Autor: Álvaro Fernández Tuesta

Director: Francisco José Serón Arbeloa

Codirector: Jorge López Moreno

UNIVERSIDAD DE ZARAGOZA

Proyecto de Fin de Carrera de Ingeniería Informática

2

Agradecimientos:

A Noelia, por apoyarme, comprenderme y conseguir sacarme de los momentos más duros.

A Fernando y Gloria, mis padres, por darme más de lo que un hijo puede necesitar.

A Jorge y a Paco, mis directores, por darme la idea, la oportunidad, su tiempo y sus sabios consejos.

3

TANGIBLE: Sistema de bajo coste

para localización y detección de gestos 3D en entornos inmersivos

RESUMEN

El presente proyecto consiste en el desarrollo de una biblioteca sobre .Net capaz de calcular la posición espacial y de reconocer gestos basados en patrones de uno o varios emisores de luz infrarroja captados por las cámaras que tienen integradas los mandos de la consola Wii de Nintendo, que se pueden comunicar con el PC a través del protocolo Bluetooth.

Esta biblioteca proporciona un conjunto de funciones suficiente para que cualquier desarrollador del entorno .Net pueda integrar fácilmente en su aplicación esta nueva interfaz de bajo coste. Además, se ha escrito un programa de demostración para que el usuario que tenga el material necesario (antena Bluetooth, dos mandos de la consola Wii y uno o varios emisores de luz infrarroja) pueda comprobar el funcionamiento del sistema sin necesidad de conocimientos de programación.

Para el desarrollo de esta biblioteca ha sido necesario el estudio y aplicación de muchos conceptos de la Geometría de varias vistas, así como la familiarización con diferentes paquetes de herramientas: de cálculo numérico, visión y representación por computador, comunicación con los mandos de la Wii o simulación de teclado y ratón para su completa integración en nuestra biblioteca .Net.

En cuanto al reconocimiento de gestos, la biblioteca es capaz de reconocer una variedad de treinta gestos 3D cuyo reconocimiento se puede tratar tanto síncrona como asíncronamente.

El presente proyecto constituirá un módulo que se integrará en diversos sistemas de visualización, según el propósito (arqueología virtual, interacción con avatares, biomedicina,...).

Índice

5

ÍNDICE

RESUMEN DE LA MEMORIA

1 Introducción 7

1.1 Estructura del documento 8 1.2 Ámbito y contexto 10 1.3 Medios 11 1.4 Motivación y objetivos 12 1.5 Alcance 14 1.6 Fases del proyecto 15 1.7 Descomposición del trabajo por hitos 17

2 Primera fase: Objetivos y preparación del entorno de trabajo 18

2.1 Objetivos 19 2.2 Estudio previo 19 2.3 Preparación del entorno físico de trabajo 20 2.4 Configuración del entorno software 21

3 Segunda fase: Localización espacial 23

3.1 Planteamiento y estudio del problema 24 3.2 Calibración del sistema 25 3.3 Localización 3D 27

4 Tercera fase: gestos 3D: reconocimiento e interactividad 30

4.1 Reconocimiento de gestos 2D 31 4.2 Reconocimiento de gestos 3D 32 4.3 Capacidades de interacción 33

5 Descripción del sistema 35

5.1 Esquema de comunicación 36 5.2 Sistema físico 37 5.3 Biblioteca 38

6 Resultados y conclusiones 43

6.1 Conclusiones personales 44 6.2 Resultados: aplicaciones 46

7 Bibliografía 52

7.1 Libros 53 7.2 Artículos 55 7.3 Enlaces Web 56

Índice

6

ANEXOS

A. Puesta en marcha del sistema: tutorial 59 A.1 Conexión con Wiimotes 60 A.2 Montaje de un puntero de infrarrojos 64 A.3 Instalación de bibliotecas necesarias 66

B. Programa de demostración 68

C. Geometría 71 C.1 Geometría Proyectiva 72

C.1.1 Modelo pin-hole 73 C.1.2 Elementos impropios 74 C.1.3 Coordenadas homogéneas 75 C.1.4 Representación del punto en coordenadas homogéneas 76 C.1.5 Representación de la recta en coordenadas homogéneas 77 C.1.6 Homografía 78

C.2 Geometría Epipolar 80 C.2.1 Restricción Epipolar 80

C.2.2 Epipolos 81 C.2.3 Matriz Fundamental F 81 C.2.4 Parámetros de las cámaras 82

D. Métodos de calibración y localización 3D 84 D.1 Calibración epipolar 86

D.1.1 Cámaras en posición libre. Método 1: Obtención de la matriz Fundamental y epipolos con el método de los seis puntos 87

D.1.2 Cámaras en posición libre. Método 2: Obtención de la matriz Fundamental con 97 el método robusto R.A.N.S.A.C.

D.1.2 Cálculo de matrices canónicas de cámaras a partir 100 de la matriz Fundamental y el segundo epipolo

D.2 Localización 3D 101 D.2.1 Configuración 1: Posición libre de las cámaras 101

D.2.2 Configuración 2: Cámaras alineadas 103

E. Estado del arte 106 E.1 Proyectos relacionados 107 E.2 Interacción 3D 114

Índice

7

F. Descripción de materiales 116 F.1 Wiimotes 117 F.2 Cámara del Wiimote 118 F.3 Antena Bluetooth 119 F.4 Punteros de luz infrarroja 120 F.5 Trípode 121

G. Restricciones físicas 122 G.1 Montaje 123 G.2 Direccionalidad 124 G.3 Interferencias 125 G.4 Longitud de onda 125 G.5 Angular de las cámaras 127

H. Biblioteca: 128 H.1 Clase Geometría 129 H.2 Clase Geometría Epipolar 132 H.3 Clase Gestos 137 H.4 Clase Dibujar 141 H.5 Clase Mapeo 144

I. Funciones y atributos externos utilizados 145 I.1 WiimoteLib 146 I.2 OpenGl 149 I.3 OpenCV 150 I.4 DotNetMatrix 153 I.5 AutoItLib 156

J. Glosario 157

1

INTRODUCCIÓN

1.1 Estructura del documento

1.2 Ámbito y contexto

1.3 Medios

1.4 Motivación y objetivos

1.5 Alcance

1.6 Fases del proyecto

1.7 Descomposición del trabajo por hitos

Este capítulo describe el objetivo, ámbito y resultado del proyecto, las técnicas, herramientas y conocimientos utilizados, así como el contenido de los diferentes capítulos que conforman la presente memoria y de sus anexos.

Cap. 1: Introducción

9

ESTRUCTURA DEL DOCUMENTO

Memoria

La presente memoria se divide en los siguientes capítulos:

1. Introducción

Capítulo dedicado a ofrecer una visión general del proyecto y su documentación.

2. Primera fase: Objetivos y preparación del entorno de trabajo

Expone los requisitos definidos y la fase preparatoria previa al propio desarrollo del proyecto.

3. Segunda fase: Localización espacial

Resume el proceso de trabajo llevado a cabo en las tareas de investigación y aplicación de conceptos geométricos.

4. Tercera fase: Gestos: Reconocimiento y asociación de acciones. Exploración de aplicaciones.

Sintetiza el desarrollo del motor de detección de gestos así como la exploración de aplicaciones prácticas del resultado.

5. Descripción del sistema

Explica el sistema, tanto desde el punto de vista físico como desde el punto de vista de funcionamiento y de su arquitectura.

6. Resultados y conclusiones

Valoración del trabajo realizado, cumplimiento de objetivos, posibilidades de continuación, aprendizaje, problemas encontrados, aplicaciones…

7. Referencias

Listado de los recursos bibliográficos, documentales o relativos a la programación citados en este documento.


10

Anexos

Como información necesaria para la comprensión del proyecto se han incluido los siguientes anexos:

A. Puesta en marcha del sistema: tutorial

Guía práctica para hacer funcionar el sistema.

B. Programa de demostración

Describe la interfaz y la utilización de este programa para la demostración del correcto funcionamiento del sistema.

C. Geometría

Se explican con más detalle los conceptos geométricos aplicados.

D. Métodos de calibración y localización 3D

Explicación teórica y práctica de los métodos geométricos de visión 3D aplicados.

E. Métodos numéricos

Se desarrollan los métodos de cálculo numérico aplicados.

F. Estado del arte

Explora la situación actual de líneas similares de investigación.

G. Descripción de materiales

Analiza las características técnicas de los materiales necesitados.

H. Restricciones físicas

Análisis de las limitaciones de los medios físicos.

I. Biblioteca: Descripción de clases

Explicación de las clases, sus funciones y funcionamiento.

J. Funciones y atributos externos utilizados

Breve revisión del material ajeno utilizado.

K. Glosario

Recoge definiciones de los tecnicismos utilizados en la documentación, o conceptos que probablemente resulten desconocidos al lector y no han sido explicados en el texto.


11

ÁMBITO Y CONTEXTO

Este proyecto de fin de carrera ha sido desarrollado como parte de la labor investigadora del Grupo de Informática Gráfica Avanzada (GIGA), perteneciente al Departamento de Informática e Ingeniería de Sistemas (DIIS) de la Universidad de Zaragoza.

Concretamente, forma parte del importante proyecto de investigación de ámbito estatal financiado por el Ministerio de Ciencia y Tecnología “TANGIBLE: Humanos Virtuales realistas e interacción natural y tangible”, en cuya descripción se expone como uno de sus objetivos: “La interacción con el usuario, utilizando el paradigma de los interfaces naturales y multimodales, incluidos los tangibles. Las aplicaciones más inmediatas de sus resultados se enmarcan en los entornos de la formación y el entretenimiento, aunque prevemos un campo de aplicación más extenso a medio y largo plazo.”

Fue concedido en la convocatoria de Programas Nacionales del Plan Nacional de Investigación Científica, Desarrollo e Innovación Tecnológica 2004-2007 del Ministerio de Educación y Ciencia. En el proyecto participan investigadores de la Universidad de Zaragoza, de la Universidad de las Islas Baleares y de la Universidad Pública de Navarra. El proyecto une tres grandes campos (informática gráfica, personajes 3D inteligentes e interfaces naturales) en una propuesta coherente cuyo objetivo global es la generación de humanos virtuales realistas, tanto desde el punto de vista visual como de comportamiento, que soporten la interacción natural y emocional con el usuario.

El presente proyecto se enmarca en el área que explora la inmersividad e interactividad natural con entornos virtuales.

Se pretende ofrecer una solución de bajo coste capaz de proporcionar simultáneamente medios de interacción naturales en entornos 3D, así como la capacidad de aumentar la sensación de inmersividad con la detección de la localización espacial de puntos clave del usuario: manos, para la interacción; y ojos, para la inmersividad.


12

MEDIOS

Los Wiimotes (abreviatura de Wii remote, mando de la Consola Wii) (Fig. 1) se comunican con la consola Wii a través del protocolo de comunicación inalámbrica Bluetooth. A pesar de que Nintendo no ha liberado el significado de los paquetes de datos que se intercambian, varios programadores han capturado y deducido el significado de gran parte de la información transmitida. A partir de este proceso de ingeniería inversa se han desarrollado (y siguen en constante actualización) varias bibliotecas sobre diferentes entornos y plataformas que proporcionan un cómodo análisis de la información. La biblioteca que motivó este proyecto fue WiimoteLib, de Brian Peek.

El nacimiento de las primeras versiones de estas bibliotecas, en primavera de 2007, creó una atractiva línea de exploración de las posibilidades de interacción que proporciona un periférico tan versátil como éste. En la actualidad hay multitud de proyectos en curso y supone un campo en continua evolución.

Fig. 1: Wiimote y Sensor bar

La característica del control Wiimote que se explota en este proyecto es su capacidad de captar puntos infrarrojos: en su cara frontal se encuentra una sencilla cámara que capta hasta cuatro focos de luz que sirve para deducir su orientación respecto a la mal llamada Sensor bar, ya que no tiene sensores, sino emisores de luz infrarroja en las zonas oscuras de sus extremos frontales.


13

MOTIVACIÓN Y OBJETIVOS

La idea de la base del proyecto surgió de un trabajo de Johnny Chung Lee [A8], que tuvo cierta relevancia en Internet, en el que se demostraba la detección de los reflejos de luz infrarroja por parte de las cámaras de los mandos de la consola Wii de Nintendo (Fig. 2).

Fig. 2: Johnny Chung Lee demuestra el funcionamiento de su "Head tracker"

Uno de estos proyectos, el llamado Head Tracking for Desktop VR Displays using the Wii Remote (Localización de cabeza para visualizadores domésticos de realidad virtual con el mando de la Wii) exploraba ciertas capacidades de localización espacial, que podían ser ampliadas cambiando ligeramente el enfoque: Para la localización se utilizaba un solo mando y necesitaba dos emisores infrarrojos. Basándose en sus posiciones y su distancia relativa, estimaba la distancia entre los emisores y los mandos. Esto divide por dos el máximo de cuatro puntos detectados por el sistema; limitación que se puede evitar utilizando dos cámaras en vez de una. El presente proyecto explora esa vía.

Con este nuevo enfoque se pueden utilizar, por ejemplo: un cursor en cada mano (uno para el cursor 3D y otro para ejecutar gestos predefinidos que ejecuten acciones), y dos en las gafas de visión 3D; o bien uno en las gafas, otro en una mano para cursor 3D y otros dos en la otra mano para reconocer gestos más complicados. Este proyecto demuestra las posibilidades de la primera opción, pero deja disponibles las herramientas necesarias para la utilización directa de otras configuraciones.

La aplicación imaginada por los directores del proyecto era la consecución de una interfaz inmersiva completa y de bajo coste compuesta por un sistema de


14

localización espacial para la ubicación automática del punto de vista del usuario y de los cursores destinados a la interacción, además de un sistema de reconocimiento de gestos básicos. La localización del punto de vista del usuario se utilizaría para actualizar la imagen congruentemente con la posición de la cabeza del usuario y crear mayor realismo. Como primera aplicación, se pensaba utilizarlo para navegar sobre entornos 3D virtuales creados en el propio GIGA.

Este objetivo, por su amplitud y gran complejidad, fue dividido en varios proyectos para desarrollar en paralelo y tras la finalización de los actuales. El presente es el encargado, como ya se ha dicho, de la localización espacial, así como la detección de gestos básicos que otorguen capacidades interactivas de diversa índole. Enfocado a que debe ser lo suficientemente modular, flexible, completo y claro para ser utilizado como base y como herramienta para proyectos relacionados.

Para lograr una mayor flexibilidad en la configuración del sistema, se estableció como objetivo la libre disposición y orientación de los mandos para la captación de los puntos; si bien posteriormente se añadió la configuración de cámaras alineadas para la simplificación del sistema, así como la reducción de cálculos y de tiempo en la calibración del sistema, para los casos en los que esta configuración sea la más apropiada.


15

ALCANCE

Resultado

Esta biblioteca proporciona un conjunto de funciones suficiente para que cualquier desarrollador del entorno .Net pueda integrar fácilmente en su aplicación esta nueva interfaz de bajo coste. Además, se ha escrito un programa de demostración para que el usuario que tenga el material necesario -antena Bluetooth, dos mandos de la consola Wii y uno o varios emisores de luz infrarroja- pueda comprobar el funcionamiento del sistema sin necesidad de conocimientos de programación.

En cuanto al reconocimiento de gestos, la biblioteca es capaz de reconocer una variedad de treintaisiete gestos 3D, cuyo reconocimiento se puede tratar tanto síncrona como asíncronamente.

Esfuerzo

Para el desarrollo de esta biblioteca ha sido necesario el estudio e implementación de gran cantidad de conceptos de la Geometría de varias vistas, así como la familiarización con diferentes paquetes de herramientas: de cálculo numérico, visión y representación por computador, comunicación con los mandos de la Wii o simulación de entrada de teclado y ratón para su completa integración en nuestra biblioteca .Net.

Futuro

El presente proyecto establecerá un módulo que se integrará en diversos sistemas de visualización tridimensional, según el propósito (arqueología virtual, interacción con avatares, biomedicina,...) y servirá como herramienta de base para la utilización de la tecnología de aplicada en diferentes objetivos.

Además de como base para investigaciones en diversas áreas que requieren interacción avanzada hombre-máquina, constituye en sí mismo un avance en dispositivos de interacción avanzados de bajo coste.

Actualmente, estamos escribiendo un artículo que describe el sistema.


16

FASES DEL PROYECTO

Tras establecer los objetivos globales del trabajo a realizar, se debía descomponer en diferentes fases para comenzar adquiriendo los conocimientos necesarios y afrontar el desarrollo posterior desde el enfoque adecuado para cada objetivo parcial. Las etapas de las que consta el desarrollo se pueden distinguir cronológicamente, como se explica en el siguiente capítulo, o conceptualmente según la siguiente clasificación:

1. Estudio de las bases teóricas necesarias, aprendizaje y familiarización con el entorno y lenguajes de programación.

Para poder abordar la solución de los objetivos con criterio, ha sido necesario el estudio de las áreas de la Geometría relacionada con la visión estéreo y con las transformaciones espaciales para poder incluir todos los conceptos necesarios para calcular la posición espacial, cambiar el sistema de referencia, calcular relaciones de transformación, detectar direcciones de trayectorias…

Ha sido necesario el estudio de diferentes lenguajes de programación y bibliotecas disponibles: Como entorno de programación del lenguaje C# se ha utilizado el potente entorno de desarrollo Microsoft Visual C# Express Studio [W1], en el que se han integrado las herramientas externas utilizadas.

2. Comprensión, análisis selección e integración de recursos.

La utilización de un entorno de programación mayoritario permite, con mayor o menor dificultad, la integración de recursos externos que simplifiquen la tarea de codificación del sistema.

El desarrollo de un sistema que comprende varios y complejos campos de estudio supone analizar las herramientas disponibles para incorporar funcionalidades ya desarrolladas: Para la interacción con los Wiimotes se ha utilizado y modificado la biblioteca WiimoteLib; para la resolución de sistemas de ecuaciones se ha utilizado la biblioteca .Net DotNetMatrix [W5]; para la muestra de resultados de puntos 3D capturados, la tecnología abierta OpenGl [W3] y para la calibración robusta de cámaras se han utilizado funciones de la biblioteca multiplataforma OpenCV [W7], orientada a la visión por computador.


17

3. Configuración del sistema: físico y software.

Para el correcto funcionamiento del sistema ha sido necesario probar y desestimar diferentes opciones para la emisión de la luz a detectar. El resultado final es muy barato y sencillo de construir, pero antes de llegar a él ha sido necesario desestimar varias opciones, lo que ha supuesto trabajo adicional de adaptación, montaje y acopio de materiales.

4. Desarrollo incremental: implementación y pruebas.

El proyecto se ha construido de forma incremental (Fig. 3); es decir, para llegar a cumplir los objetivos finales era necesario ir cumpliendo objetivos parciales. Además, como es habitual en proyectos de investigación, en cada fase nacían objetivos no contemplados en las fases anteriores. Las corrección de cada método desarrollado era comprobada y revisada tras ser escrita, ya que en la mayoría de los casos era necesario el aseguramiento de su corrección para poder ser utilizados en posteriores fases. En resumen, antes de dar por finalizada una fase y abordar la posterior, se ha comprobado y corregido en su correcto funcionamiento. Para ello se han sometido a diferentes pruebas: comprobación con el programa matemático Matlab [W30] de los métodos matemáticos desarrollados y de la validez de las matrices calculadas, trazado de las trayectorias de los gestos reconocidos, representación gráfica de los datos geométricos de resultados parciales de los métodos, mediciones sobre cuadrículas…

Fig. 3: Esquema del modelo iterativo incremental

Cronológicamente, las cuatros fases no han seguido estrictamente este orden desde una visión global, puesto que para cada objetivo intermedio a cumplir suponía recorrer todas o varias de las cuatro fases con un enfoque específico.


18

DESCOMPOSICIÓN DEL TRABAJO POR HITOS

Para una visión global del trabajo realizado, se descompone a continuación el trabajo invertido desde un punto de vista cronológico.

1. Instalación y configuración del sistema.

2. Primer prototipo: captación y muestra de puntos infrarrojos 2D captados simultáneamente por ambas cámaras.

3. Segundo prototipo: reconocimiento correcto de posiciones 3D

4. Tercer prototipo: reconocimiento de posición 3D y determinación de sistema de referencia.

5. Cuarto prototipo: reconocimiento de posición 3D por método epipolar y trigonométrico y reconocimiento de gestos 3D.

6. Quinto prototipo: reconocimientos de gestos que ejecutan acciones.

7. Fin del proyecto: recopilación, estructura y orden de la documentación.

En los capítulos 2º, 3º y 4º se sigue este orden para la explicación del trabajo desarrollado.

2 PRIMERA FASE:

OBJETIVOS Y PREPARACIÓN DEL

ENTORNO DE TRABAJO

2.1 Objetivos

2.2 Estudio previo

• Elección del lenguaje • Estudio del lenguaje

2.3 Preparación del entorno físico de trabajo

• Detección de necesidades del entorno físico • Montaje de trípode • Montaje de puntero

2.4 Configuración del entorno software

• Análisis y estudio de código de WiimoteLib y aplicaciones de demostración • Adaptación de código para trabajar con dos mandos simultáneamente • Elección de motor gráfico • Integración de OpenGl

Expone los requisitos definidos y la fase preparatoria previa al propio desarrollo del proyecto.

Cap.2. 1ª fase: Objetivos y preparación del entorno de trabajo

20

OBJETIVOS

La primera fase del proyecto requirió, en un primer momento, el establecimiento de los requisitos que se debían cumplir y una visión global de los pasos a seguir para llegar a estos requisitos.

Se establecieron los siguientes requisitos y objetivos globales:

• Usando las respectivas cámaras de dos Wiimotes, se debe calcular la posición espacial de los puntos de interés.

• El sistema debe ser capaz de reconocer un pequeño abanico de gestos para dotar al sistema de mayor versatilidad interactiva.

• Estos datos (gestos y posición) deben proporcionar una interacción fluida, con lo que deben ser calculados y reconocidos en tiempo real.

• Debe estar preparado para añadir mejoras o integrarse en otros proyectos. • Se desarrollará en lenguaje C#.

ESTUDIO PREVIO

Elección del lenguaje de programación C#

La elección de este lenguaje se produjo por diversos motivos, siendo los principales que la plataforma de destino inicial es basada en Windows y que ofrece una buena interacción con librerías C y C++. Adicionalmente permite simplificar el proceso de desarrollo y mantenimiento de código al liberar al programador de la gestión de memoria al igual que ocurre con otros lenguajes interpretados como JAVA. El hecho de que el presente módulo no se encarga del cálculo mas intensivo (gráficos, inteligencia artificial,…) junto con el uso de compilación just-in-time nos permite el uso de un lenguaje interpretado con escasa incidencia en el rendimiento final de la aplicación. Adicionalmente, frente al uso de JAVA, algunas de las bibliotecas que simplifican el desarrollo de nuestro sistema se encontraban únicamente en lenguajes C, C++ y/o C#.

Estudio del lenguaje

Para poder afrontar con posibilidades el proyecto era necesario un estudio de las capacidades de este lenguaje y de la interfaz de desarrollo con la que se iba a trabajar. Para ello, como primer paso, se leyó el libro C# Manual de referencia [L1] de la editorial Mc Graw-Hill.


21

Durante la lectura, se instaló en las estaciones de trabajo el entorno de programación para hacer pequeños ejercicios.

PREPARACIÓN DEL ENTORNO FÍSICO DE TRABAJO

Detección de necesidades del entorno físico

Una vez estudiado el manual de referencia, el siguiente paso consistió en probar el correcto funcionamiento del sistema -tanto físico como software- sobre el cual se iba a trabajar.

Para ello, la primera acción fue la adquisición y/o montaje de los materiales necesarios para las primeras pruebas, que son:

• Dos Wiimotes • Antena Bluetooth USB • Un emisor de luz infrarroja con interruptor • Trípode compatible

Los dos primeros materiales son sencillos de encontrar en tiendas cercanas. Para el emisor de luz infrarroja, es sencillo encontrar linternas LED [-] a muy bajo precio, a los que se puede sustituir el LED de serie por uno de luz infrarroja, que se comercializa en tiendas componentes electrónicos.

Una vez establecida la conexión entre Wiimotes y ordenador (tutorial propio en Anexo A.1), ya se estaba en disposición de probar las pequeñas aplicaciones de prueba que utilizaban la biblioteca Wiimotelib [W2] para la interacción con los Wiimotes.

Trípode

Para el libre posicionamiento y sujeción de las cámaras, era conveniente un trípode para cada una o algo que hiciera su función.

Para lograr un trípode compatible: se le separó a una vieja cámara analógica la zona en la que se introduce la rosca del trípode, para luego adherirla a la parte inferior del Wiimote con un potente pegamento. Para el otro mando, se utilizó un pie de micrófono. (Fotos en Anexo F.5).


22

Puntero

Los punteros a utilizar conllevaron pequeñas complicaciones, como se comenta en el Anexo G.1.

CONFIGURACIÓN DEL ENTORNO SOFTWARE

Análisis y estudio de código de WiimoteLib y aplicaciones de demostración

Para comenzar a desarrollar el sistema, fue necesario el estudio de la biblioteca WiimoteLib, que traduce gran parte de los mensajes enviados por el Wiimote a estructuras de datos comprensibles. Para ello era necesaria la comprensión del sistema de captura de eventos de cambio de estado y el estudio de las aplicaciones que utilizaban esta biblioteca.

Adaptación de código para trabajar con dos mandos simultáneamente

Las aplicaciones de prueba sólo trabajaban con la conexión de un mando. Uno de los objetivos de nuestro proyecto era el trabajo con los datos enviados por varios mandos para poder ser tratados simultáneamente.

Tras escribir un pequeño programa que se conectaba correctamente con un mando y mostraba las coordenadas 2D del primer punto capturado, había que conseguir la conexión simultánea con un segundo mando.

Para ello, la solución tomada fue la creación de un hilo de ejecución para cada mando conectado. Este hilo creaba un objeto Wiimote, al que se le añadió como atributo un identificador para diferenciar cada mando. De esta manera, con sólo evaluar este identificador, se podía reconocer de qué mando se trataba. Elección de motor gráfico

Para la representación gráfica de los puntos captados, así como de las posiciones 3D que se iban a calcular en posteriores fases era recomendable hacer uso de una API (interfaz de programación de aplicaciones) que simplifique la muestra gráfica de resultados.

Las dos APIs contempladas fueron DirectX (propiedad de Microsoft) y OpenGl. Se decidió utilizar la segunda (de código abierto y multiplataforma) para que nuestra biblioteca se pudiera utilizar en sistemas operativos ajenos a Microsoft (siempre


23

que puedan ejecutar una máquina virtual .NET) y por ser la biblioteca usada por defecto en la mayoría de subproyectos pertenecientes al proyecto TANGIBLE. [W27]

Integración de OpenGl

OpenGl es una API multiplataforma para la representación gráfica 2D y 3D. Para ser integrada en nuestro proyecto, que trabaja sobre .Net, existen varios wrappers que permiten el uso de sus funciones. El que más se utiliza y el utilizado en este proyecto es el llamado Tao.OpenGl [W4]. Para poder utilizarlo, basta con añadir a la lista de bibliotecas reconocidas por Visual Studio las dos dlls necesarias para funcionar y crear un objeto de tipo SimpleOpenGlControl, que maneja en una ventana o contenedor de nuestra aplicación todas las funciones contenidas en OpenGl.

3 SEGUNDA FASE:

LOCALIZACIÓN ESPACIAL

3.1 Planteamiento y estudio del problema

• Planteamiento del problema • Estudio de Geometría Epipolar

3.2 Calibración del sistema

• Planteamiento del problema • Algoritmo de los seis puntos • Captación de puntos • Búsqueda de herramientas para la resolución de sistemas • Implementación del algoritmo de los seis puntos • Primeras pruebas del algoritmo • Obtención de las matrices de cámara a partir de la matriz Fundamental

3.3 Localización 3D

• Planteamiento del problema • Cálculo 3D a partir de correspondencias 2D y matrices de cámara • Evaluación del método de los seis puntos • Estimación robusta de la matriz Fundamental: método R.A.N.S.A.C. • Elección de OpenCV • Verificación del método • Transformación del sistema de referencia • Cálculo de la matriz de calibración

Resume el proceso de trabajo llevado a cabo en las tareas de investigación y aplicación de conceptos geométricos.

Cap.3. 2ª fase: Localización espacial

25

Esta fase supuso la mayor parte de inversión de esfuerzo, tiempo y energía.

Como propuesta del autor, se estableció como objetivo, a pesar de que no estaba contemplado en los objetivos iniciales, que el sistema fuera funcional independientemente de la posición de las cámaras, con la inevitable restricción de que los puntos a captar han de estar dentro del ángulo de visión de las dos cámaras. Esta decisión supuso la aparición de obstáculos imprevistos y que la complejidad técnica del sistema se multiplicara; lo que hizo necesario el estudio con cierta profundidad de áreas de la Geometría con las que no se había tenido contacto previamente.

PLANTEAMIENTO Y ESTUDIO DEL PROBLEMA

Planteamiento del problema

El sistema podía haberse limitado a conceptos de trigonometría y de semejanza de triángulos para obtener las tres coordenadas a partir de los datos obtenidos por dos cámaras alineadas, pero decidimos adentrarnos en estudio de la Geometría Epipolar para poder aplicar sus conceptos y así permitir al usuario situar las cámaras sin ninguna restricción de posición ni de orientación.

Estudio de Geometría Epipolar

La Geometría Epipolar es una rama de la Geometría Proyectiva que nació hace pocos años y establece las relaciones y propiedades geométricas entre elementos del espacio desde el punto de vista de dos espacios proyectivos. Surgió como necesidad de investigar las relaciones matemáticas que intervienen en los sistemas de adquisición de datos con dos cámaras.

Fig. 4: Esquema de la Geometría Epipolar [A13]


26

Se basa las relaciones geométricas de los epipolos, que tienen dos propiedades: representan las intersecciones de la recta que une los centros de cada cámara con los dos planos de proyección y además son el lugar en el que se intersecan todas las líneas epipolares de cada plano. Las líneas epipolares son las proyecciones del rayo de proyección de un punto sobre la otra cámara (Fig. 4).

La matriz Fundamental F contiene la información que describe el sistema desde este enfoque. Se explica más a fondo en el Anexo C.2.3.

El estudio de esta área de la Geometría era fundamental para identificar los parámetros necesarios para una correcta reconstrucción 3D, lo que implicaba elaborar diferentes métodos para obtener dichas reconstrucciones así como los datos de calibración necesarios para una correcta reconstrucción 3D.

CALIBRACIÓN DEL SISTEMA

El mayor problema de la Geometría Epipolar desde el punto de vista del programador es que los parámetros a obtener son en su mayoría matrices, cuya corrección es difícil de comprobar.

Estos parámetros son los coeficientes de las matrices de proyección de cada cámara, que se pueden obtener, salvo escala, de la matriz Fundamental. Para el cálculo de la matriz Fundamental, existen muchos métodos, en su mayoría orientados al procesado de multitud de correspondencias de un par de imágenes obtenidas con cámaras fotográficas reales.

Algoritmo de los seis puntos

Se eligió la implementación de este algoritmo por dos razones: era un método que sólo requería seis puntos, con lo que el proceso de calibración era el más rápido y la corrección de los resultados de su paso intermedio (el cálculo de la matriz homografía H era verificable fácilmente. El algoritmo y su implementación se detallan en Anexo D.1.1. Requiere captar cuatro puntos coplanares (no alineados) y otros dos puntos que no pertenezcan a dicho plano.

Captación de puntos

Para captar estos seis puntos clave, se debía evitar la interacción con otros periféricos como el ratón o el teclado, ya que esto limita por una parte la movilidad del usuario y por otra parte puede conllevar que éste se desplace, pierda las referencias y no marque correctamente las posiciones de los puntos clave.


27

Para ello, una vez activada la calibración, la meta era que el usuario active la luz en el primer punto, la desactive y vuelva a repetir el proceso para los otros tres puntos. Este proceso se hace con una máquina de estados y la captación de cada punto se relaciona con un estado diferente.

Para lograrlo, se han escrito dos funciones específicas para nuestra aplicación y una que las combina: LeePuntos comprueba que el punto es visible por las dos cámaras y captura los dos pares de coordenadas; SueltaPuntos incrementa el valor de la variable que indica el estado en el momento en el que se dejan de recibir señales lumínicas y SueltaPuntosYSigue combina las dos tareas.

Como nuestra biblioteca 3D es de uso general y funciona independientemente del medio de captación de los datos de las coordenadas, estas funciones auxiliares no se han incluido y forman parte del programa de demostración, a pesar de que tienen utilidad en aplicaciones similares.

Búsqueda de herramientas para la resolución de sistemas

La aplicación del algoritmo de los seis puntos requería de la resolución de un complejo sistema de ecuaciones para calcular la matriz homografía a partir de las proyecciones de cuatro puntos coplanares, como se plantea en Anexo C.1.1. Se pretendía evitar el desarrollo manual completo del cálculo de las incógnitas. Para ello, está disponible la biblioteca de métodos de transformación de matrices DotNetMatrix, que fue integrada en la solución del proyecto añadiendo directamente sus archivos de código fuente.

El cálculo de la matriz homografía se hizo con el método de eliminación de Gauss que proporciona DotNetMatrix.

Implementación del algoritmo de los seis puntos

Una vez calculada la homografía con nuestra función CalculaHomografía, el siguiente paso necesario es el cálculo del punto homogéneo normalizado que utiliza la matriz homografía con nuestra función CalculaHomogéneo, para poder hallar la intersección de las rectas que definen los puntos y sus homólogos para el cálculo del epipolo, como indica el algoritmo, con nuestra función Intersección.

Primeras pruebas del algoritmo

Para calcular la corrección del cálculo de la homografía, se interrumpía el proceso de captación de puntos tras ser adquirido el cuarto punto. Inmediatamente se mostraban con OpenGl la posición del punto desde el punto de vista de cada cámara y el punto homogéneo calculado a partir de la proyección de la primera cámara. Si se mantenía la luz sobre el plano definido por los cuatro puntos recién introducidos para la calibración, el punto de la segunda cámara y el homogéneo de la primera siempre coincidían. Lo que demostraba su correcto funcionamiento.


28

La corrección de la segunda parte del algoritmo se comprobó una vez descompuesta la matriz fundamental en matrices de cámara.

Para la comprobación de la validez del sistema aplicado, se mostró en pantalla, con funciones OpenGl, la posición del punto 3D calculado.

Obtención de las matrices de cámara a partir de la matriz fundamental

Nuestro método CalculaCámaras es el encargado de almacenar, a partir del epipolo y la homografía, las matrices de las cámaras en forma canónica como atributos internos de la clase GeometríaEpipolar. Para ello se calcula primero la matriz fundamental y la descompone como se describe en el algoritmo.

LOCALIZACIÓN ESPACIAL

Cálculo 3D a partir de correspondencias 2D y matrices de cámara

Para calcular la posición 3D con los datos obtenidos, es necesario a cada movimiento del cursor aplicar el algoritmo explicado en Anexo D.2.1. Este método está aplicado en la función Calcula3D. Como alternativa se ha escrito la función Calcula3D2, que en vez de hacer la descomposición SVD para la resolución del sistema, aplica la factorización QR.

Evaluación del método de los seis puntos

Una vez calculadas las dos matrices de cámara, estábamos en disposición de comprobar la posición 3D sin tener en cuenta la escala. Habitualmente, los resultados mostrados se mostraban a una escala mucho menor que las proyecciones, con lo que era difícil percibir visualmente su corrección. Para aplicarle un factor de escala constante en la evaluación, se añadió como método de la clase Punto3D el operador * multiplicación.

Los resultados obtenidos se acercaban mucho a la realidad, pero si se situaban las cámaras con una dirección similar, con frecuencia calculaba mal la profundidad, no así las otras dos coordenadas.

Para la comprobación de los resultados, en vez de los dos últimos puntos, se tomaron doce. Se calcularon, aplicando explosión combinatoria todas las intersecciones de las rectas y se mostraron gráficamente los resultados, que eran muy dispares, pero sobre una misma recta.

Para encontrar la causa de este defecto, se almacenó el quinto punto y la posición actual del cursor se trataba como si fuera el sexto punto del método. Con estos datos se mostraba gráficamente, a cada movimiento de cursor, las rectas cuya


29

intersección es el epipolo y tanto gráfica como numéricamente la posición de dicha intersección.

Esta representación mostraba que las rectas a intersecarse eran casi paralelas, con lo que mínimas desviaciones en las medidas de las cámaras implicaban desviaciones muy grandes de la posición calculada de los epipolos.

La gran direccionalidad de los punteros LED conllevaba que la configuración más apropiada era precisamente en la que más fallos tiene este método, con lo que se consideró necesaria una alternativa más robusta.

Estimación robusta de la matriz fundamental: método R.A.N.S.A.C.

El método R.A.N.S.A.C. [A3] para el algoritmo de los ocho puntos [A12] es el más utilizado para el cálculo de la matriz fundamental. Es un método robusto y tolerante a datos espurios (Fig. 5), lo que indica que es un método apropiado para nuestro sistema [A2]. Se explica en Anexo D.1.2.

Fig. 5: Ejemplo del método R.A.N.S.AC. para la estimación de una recta

Elección de OpenCV

Este algoritmo es costoso de implementar, con lo que se buscó un Tool-kit (paquete de herramientas) que proporcionara este método. El método de la matriz fundamental a partir de una serie de parejas de puntos se encontró en el paquete OpenCV y los parámetros se detallan en Anexo I.3. Se logró utilizar OpenCV en nuestro proyecto, instalando el entorno y añadiendo sus dlls a la solución. OpenCV trabaja con tipos de datos propios, pero estudiando código de ejemplo se aprendió lo suficiente como para traducir nuestros datos en ambas direcciones y almacenar en nuestro formato las matrices de cámara en forma canónica derivadas de la matriz fundamental. Estos cálculos se encuentran en nuestra función RANSAC. Para la calibración del sistema basta con introducir 12 puntos cualquiera (lo menos parecidos posible).


30

Verificación del método

Se comenzó probando la validez del método con doce puntos captados (mínimo recomendado), pero la precisión del sistema aumentaba con más puntos introducidos, con lo que con la observación de los resultados se estimó como buena medida 20 parejas de puntos.

Con la representación gráfica de los puntos calculados, se verifica la corrección del método en diferentes configuraciones de posiciones de las cámaras.

Transformación del Sistema de Referencia

Una vez calculada la posición 3D que nos proporciona la forma canónica, lo que significa que el origen de los ejes se sitúa en el foco de la primera cámara, puede ser conveniente establecer un sistema de referencia que sea más apropiado para la aplicación. Esta transformación se define con una matriz que contiene los parámetros que definen la rotación de los ejes y la traslación del origen del sistema de coordenadas. Es importante recalcar que el orden relativo de traslación y rotación afecta al resultado.

Para el cálculo de esta matriz se hace uso de nuestras funciones Rotación y Traslación, que requieren el cálculo del ángulo sobre el eje de giro, que es el producto vectorial de ambos vectores. Para ello se hace uso de nuestras funciones ProductoVectorial, Normaliza y CalculaÁngulo, cuyo funcionamiento se explica en el Anexo H.2.

Cálculo de la matriz de calibración

La matriz de calibración contiene los coeficientes de escalado en cada eje. Para su cálculo con nuestra función Calibración, basta con introducir como parámetros las coordenadas de nuestro punto de origen y las del punto (1,1,1).

4

TERCERA FASE:

GESTOS 3D:

RECONOCIMIENTO E

INTERACTIVIDAD

4.1 Reconocimiento de gestos 2D

• Análisis de requisitos para la detección de gestos • Idea • Funcionamiento • Reconocimiento de gestos simples 2D • Desarrollo de método simplificado de cálculo 3D

4.2 Reconocimiento de gestos 3D

• Reconocimiento de gestos simples 3D • Reconocimiento de gestos compuestos 3D • Problemas físicos en la detección de gestos

4.3 Capacidades de interacción

• Objetivos de interacción • Selección de medios • Asociación con XML de acciones a gestos

Sintetiza el desarrollo del motor de detección de gestos así como la exploración de aplicaciones prácticas del resultado.

Cap.5: Descripción del sistema

32

RECONOCIMIENTO DE GESTOS 2D

Análisis de requisitos para la detección de gestos

El sistema debía ser capaz de reconocer una pequeña colección de gestos que permitan una completa interacción con el ordenador. A partir de ahí, se analizó el funcionamiento de sistemas de reconocimiento de gestos para sistemas con diferentes orígenes, como ratón o pantallas táctiles.

Idea

Un posible enfoque que no requería de una excesiva complejidad era la de que el sistema sea capaz de descomponer los movimientos en trayectorias. En función de las direcciones reconocidas y su orden, se reconocen distintos gestos. [A10]

Funcionamiento

El motor de gestos debe conocer cuándo comienza un gesto, almacena sus coordenadas 3D y con cada movimiento del cursor compara su distancia. Si es lo suficientemente grande para considerarse un gesto consciente, reconoce su dirección. Cuando se dé por finalizado un gesto, se comprueban las direcciones guardadas y se intentan relacionar con un gesto predefinido.

Los pasos son: filtrado de entrada (Fig. 6), detección de direcciones (Fig. 7), factorización (Fig. 8) y reconocimiento [A4].

Fig. 6: Filtrado de trayectoria de gesto

Fig. 7: Detección de direcciones de trayectoria

Fig. 8: Factorización de direcciones


33

Reconocimiento de gestos simples 2D

Para evitarnos la continua re-calibración de los parámetros 3D de nuestra configuración, como paso intermedio se escribió un motor de gestos 2D para el cual sólo era necesario el uso de una cámara. El reconocimiento de direcciones utilizaba funciones trigonométricas para hallar la dirección en función de sus coordenadas y distancia euclídea.

Esta primera versión del motor funcionaba correctamente para detectar trayectorias simples (de una sola dirección).

RECONOCIMIENTO DE GESTOS 3D

Desarrollo de método simplificado de cálculo 3D

El método de calibrado para la geometría epipolar es muy incómodo para el desarrollo del módulo de captación de gestos, ya que para cada prueba del correcto funcionamiento se necesita calibrar y definir el sistema de coordenadas.

Para agilizar el desarrollo, se implementó una configuración simplificada, en la que sólo se requería marcar tres puntos. Esta configuración requiere que las cámaras de los Wiimotes estén alineadas. Sus fundamentos geométricos, basados en semejanza de triángulos se detallan en Anexo D.2.2.

Reconocimiento de gestos simples 3D

Con esta nueva configuración del sistema, no fue muy complejo añadir la tercera dimensión a las funciones de reconocimiento de gestos. Con pequeñas modificaciones en la detección de direcciones con la aplicación funciones trigonométricas en dos planos, el sistema era capaz de reconocer las direcciones en el eje Z. En el programa se dibujaba la línea 3D que representaba la trayectoria del gesto para su comprobación visual.

Reconocimiento de gestos compuestos 3D

Las direcciones reconocidas hasta ahora eran las seis direcciones básicas del espacio: izquierda, derecha, arriba, abajo, delante y detrás. Si añadíamos la capacidad de reconocer combinaciones de dos direcciones, el total de gestos reconocidos ascendía a 36. Cantidad que se considera más que suficiente para el control de la mayoría de aplicaciones. El algoritmo se explica en Anexo H.3. Posteriormente se añadió el gesto “punto”: encender y apagar sin apenas mover.


34

Problemas físicos en la detección de gestos

Las comprobaciones del funcionamiento del motor de gestos se llevaban a cabo muy cerca de las cámaras y con punteros con cuatro LEDs, para evitar problemas de visibilidad. Esta situación produjo el problema de que a veces el sistema captaba más de un punto por cursor. Con lo que se producían incoherencias, pero éstas nunca eran continuas. Otro nuevo problema que surgió fue que se producía un efecto rebote: la cámara, que tiene una respuesta de 100 hertzios, al encender o al apagar la luz del puntero interpretaba que se había encendido y apagado varias veces, con lo que lo relacionaba con el gesto “punto”. La medida que se tomó y que resolvió ambos problemas fue la incorporación de una serie de variables que indicaban si en el instante inmediatamente anterior y los precedentes se habían detectado puntos por ambas cámaras. El sistema se estabilizó si se evaluaban los últimos seis puntos. Es decir, sólo se activaba o desactivaba el mecanismo si en seis tomas de datos seguidas (0,06 segundos) la visibilidad del punto no variaba.

CAPACIDADES DE INTERACCIÓN

Esta fase del proyecto se puede considerar un experimento con algunas de las posibilidades de interacción. El objetivo de esta fase era lograr que nuestra nueva interfaz fuera fácilmente integrable, desde el punto de vista del usuario, en la mayor cantidad de aplicaciones.

Objetivos de interacción

Nuestro sistema es integrable en todo tipo de aplicaciones que se estén desarrollando sobre .Net, pero en esta fase del proyecto se pretendía la facilidad de integración desde el punto de vista del usuario, para que sin tener que volver a compilar el proyecto se pueda fácilmente modificar el modo de interacción.

Este modo de interacción debía poder integrarse en la mayor gama de aplicaciones posible.

Selección de medios

Para que la aplicación fuera lo más directa posible, se estuvo estudiando cómo sustituir los periféricos más comunes de adquisición de datos: teclado y ratón, con nuestra interfaz. Las bibliotecas que se proporcionan en MSDN Library [W19] permitían esta simulación, pero únicamente dentro de la propia aplicación.


35

Finalmente, se dio con la solución: AutoIt es un programa que se utiliza para monitorizar y programar acciones asociadas a la GUI de Windows. Además, existe para el desarrollador una dll llamada AutoItLib [W6], que contiene las llamadas al sistema necesarias para enviar tanto eventos de pulsación de teclado y ratón como de la posición del ratón.

Asociación con XML de acciones a gestos

Como aproximación configurable, se escribió la pequeña clase Ejecuta, que lee un archivo XML [W21] que contiene parejas gesto-evento que asocia eventos reconocidos con el envío de eventos de teclado. Si se deja nuestra aplicación en segundo plano, cada gesto reconocido podrá enviar mensajes de teclado a la aplicación que esté activa.


36

5

DESCRIPCIÓN DEL SISTEMA

5.1 Esquema de comunicación

5.2 Sistema físico

5.3 Descripción de la biblioteca

5.3.1 Esquema de comunicación

5.3.2 Sistema físico

5.3.3 Descripción de la biblioteca

• Clase Geometría • Clase Geometría Epipolar • Clase Gestos

Se explica el sistema a vuela pluma, tanto desde el punto de vista físico como desde el punto de vista de funcionamiento y de su arquitectura.


37

ESQUEMA DE COMUNICACIÓN

El siguiente diagrama pretende esquematizar el funcionamiento de la aplicación. Los rectángulos son los componentes del sistema (físicos y software) y las elipses representan los datos intercambiados.

Fig. 9: Esquema de comunicación del sistema


38

SISTEMA FÍSICO

Nuestro sistema básico de interacción 3D está compuesto por:

• 2 Wiimotes.

• Una antena Bluetooth USB.

• De 1 a 4 punteros de luz infrarroja (se puede sustituir por un emisor potente de luz infrarroja y cinta reflectante).

• Opcional: trípode(s) o similar que cumpla su función.

• Un PC con Windows.

Una descripción de las características técnicas de los componentes propios de este sistema se expone en el Anexo F.


39

BIBLIOTECA

A continuación se exponen las funciones y atributos de las clases más importantes de nuestro proyecto. Explicación sobre su funcionamiento y uso en el Anexo I.

CLASE GEOMETRÍA: RESUMEN

La clase Geometría contiene los tipos, métodos y atributos necesarios para abstraer y poder utilizar los conceptos básicos de calibración y localización espacial independientes de la geometría epipolar.

clase estática Geometría

TIPOS:

clase Punto2D: números reales x,y;

clase Punto3D: números reales x,y,z;

clase Correspondencia: Punto2D pA,pB;

MÉTODOS:

real CalculaDistanciaBasal (Punto2D p(100)izq,p(100)dch,p(000)izq,p(000)dch) real CalculaDistanciaFocal (Punto2D p(000)izq, p(000)dch, p(001)izq, p(001)dch) Punto3D Calcula3D (Punto2D pA, pB; real DistanciaBasal, DistanciaFocal)


40

CLASE GEOMETRÍA EPIPOLAR: RESUMEN

Esta clase contiene los atributos del sistema, métodos y funciones auxiliares referidos a la geometría epipolar del sistema.

Esta clase proporciona todo lo necesario para la calibración y cálculo de posición espacial: es posible calibrar el sistema de dos cámaras, definir el sistema de coordenadas, calcular la posición 3D y aplicar transformaciones homográficas útiles para trabajar sobre un plano.

ATRIBUTOS DE CLASE:

3x3Matriz Homografía;

3x3Matriz Fundamental;

3x4Matriz Cámara1;

3x4Matriz Cámara2;

Punto3D Origen;

MÉTODOS:

Punto2D CalculaHomogéneo (Punto2D p)

Punto2D Intersección (Punto2D r1_a, r1_b, r2_a, r2_b)

CalculaCámaras (Punto2D epipolo)

real CalculaÁngulo (Punto3D r1_a, r1_b, r2_a, r2_b)

Punto3D ProductoVectorial (Punto3D dir1, dir2)

Punto3D Normaliza (Punto3D vector1)

Punto3D CalculaTraslación (Punto2D pto_origen_a, pto_origen_b)

CalculaRotación (Punto3D Dir1, Dir2)


41

Punto3D Calcula3D (Punto2D Proy1, Proy2)

Punto3D Calcula3D2 (Punto2D Proy1, Proy2)

CLASE GESTOS: RESUMEN

Con la ayuda de esta clase, es posible reconocer gestos formados por trayectorias de una o dos direcciones.

TIPOS PÚBLICOS

tipo Gesto

A continuación se ilustran los valores posibles de una variable de tipo gesto (Fig. 10).

Gestos simples:

Fig. 10: Gestos simples reconocibles


42

Gestos compuestos (Fig. 11).:

Fig. 11: gestos compuestos reconocibles

MÉTODOS PÚBLICOS

ComienzaGesto (Punto3D Posición)

ContinúaGesto (Punto3D Posición)

Gesto TerminaGesto (Punto3D Posición)


43

EVENTOS PÚBLICOS

ArgsEventosGesto

( Gesto3D Gesto;

Punto3D PuntoInicial)

6

RESULTADOS Y CONCLUSIONES

6.1 Conclusiones personales

• Dificultades • Inquietudes despertadas • Comparación entre Wiimote y cámaras • Enfoque

6.2 Resultados: aplicaciones

• Realidad virtual y realidad aumentada • Diseño 3D • Navegación virtual • Pizarra electrónica • Juegos

Valoración del trabajo realizado, cumplimiento de objetivos, posibilidades de continuación, aprendizaje, problemas encontrados, aplicaciones…

Cap.6: Resultados y conclusiones

45

CONCLUSIONES PERSONALES

Beneficios: aprendizaje y motivación

El desarrollo del presente proyecto ha conllevado para el autor un acercamiento a la metodología profesional de desarrollo de software.

Participar en un proyecto con un resultado claramente práctico, alejado de la programación orientada a la propia formación, ha resultado reconfortante y motivador para emprender nuevos retos.

La elección del lenguaje C# (y del entorno .Net) fue una muy buena decisión, ya que ha supuesto un primer acercamiento a una filosofía de programación no vista anteriormente en la carrera, con la utilización de herramientas de desarrollo a muy alto nivel de abstracción. Ha supuesto un acercamiento y una preparación suficiente para la utilización de estas tecnologías en el mundo laboral.

Dar forma a un proyecto de esta envergadura y con fuerte componente de investigación ha supuesto para el autor un gran reto.

Dificultades

La parte del proyecto relativa a la Geometría ha entrañado muchas horas de lectura y estudio de infinidad de artículos y libros. La profundización en las ramas de la Geometría Proyectiva y Epipolar no estaba contemplada al comienzo del proyecto:

Lo que en un principio se suponía un trabajo en el que predominaba el estudio de usuario, desarrollo de gestos y su idoneidad para aplicaciones 3D, se vio relegado en el tiempo por la demora en la consecución de reconstrucción 3D.

La Geometría Epipolar, el área que más interés ha despertado al autor en el transcurso del proyecto, es una rama todavía nueva y muy relacionada con las cámaras reales, lo que supone que gran parte de la literatura sobre el tema no se pueda aplicar a nuestro sistema. Esto ha supuesto una costosa labor de selección.

La elección de la aplicación de las bases de la Geometría Epipolar ha supuesto un reto, pero en este sistema ha implicado gran carga trabajo en relación a los resultados obtenidos con el enfoque lineal simplificado. No ha resultado fácil la verificación de los resultados intermedios. De todas formas, es un aspecto del sistema que lo diferencia de otros proyectos similares y proporciona una flexibilidad a explotar.


46

Inquietudes despertadas

En cuanto a los intereses surgidos: al autor le gustaría aplicar los conocimientos adquiridos sobre otras aplicaciones relacionadas con el tratamiento y generación de imágenes.

Hay recursos muy completos disponibles para una mayor experimentación en este el campo de la visión estéreo (OpenCV), pero suelen estar enfocados al tratamiento de imágenes reales de cámaras.

Comparación entre Wiimote y cámaras

El sistema de captura de los Wiimotes tiene la virtud de que para la localización de puntos no es necesario el procesado la imagen (el propio Wiimote hace de filtro), con lo que son necesarios muchos menos recursos de CPU. Esto hace que sea una opción recomendable para la interacción en tiempo real y que suponga una carga adicional mínima en entornos exigentes en recursos como la Realidad Virtual; por contra, tiene la limitación de la detección de un máximo de cuatro puntos simultáneos.

Esta misma restricción ha motivado que el trabajo contenga un contenido teórico muy importante. Lo que ha supuesto la adquisición de unas bases que permitirían afrontar con mayor facilidad proyectos relacionados.

Enfoque

La metodología inicial para afrontar el proyecto no era la más apropiada. El autor intentaba construir todo el proyecto “artesanalmente”: codificó métodos teóricos de los cuales no constaba demostración documentada de su correcta aplicación práctica e invirtió mucho esfuerzo en codificarlos y entender el porqué de los inesperados resultados.

El alcance del proyecto hubiera sido probablemente mucho mayor si se hubiera retrasado la fase implementación, prolongando el estudio previo y si se hubiera apoyado más en recursos disponibles desde un primer momento.


47

RESULTADOS: APLICACIONES

Los objetivos iniciales fueron cumplidos en su totalidad, en incluso superados, con lo que se ha abierto un nuevo mundo de posibilidades para su aplicación o desarrollo.

REALIDAD VIRTUAL Y REALIDAD AUMENTADA

La localización del punto de vista del usuario y las capacidades de interacción permitirán introducirse en mundos virtuales como reconstrucciones de ciudades del pasado o mundos creados y moverse por ellos de una forma natural (Fig. 12).

Entre estos campos, se encuentra la biomedicina, la simulación o la arqueología virtual.

Fig. 12: Entorno inmersivo EON Reality ICube [W29]


48

DISEÑO 3D

El uso de la tercera dimensión, puede facilitar y hacer mucho más natural la labor de modelado tridimensional.

Si a la detección 3D del cursor esto le sumamos la posibilidad de el punto de vista de la cámara se actualice en función de la posición de nuestros ojos y la posibilidad de trabajar con proyectores o pantallas 3D logramos un sistema de modelado que supera con creces los más comunes, ya que el usuario sentiría que toca las formas, las podría deformar a su gusto y moviendo la cabeza cambiaría el punto de vista para localizar caras, puntos o aristas ocultos (Fig. 13).

Fig. 13: Modelado 3D inmersivo

La configuración, por ejemplo en Blender [W31] es bastante sencilla: Basta con añadir dos cámaras a la escena que estén emparentadas con un objeto que controlará su rotación y posición. Para ello, este objeto padre tendrá una restricción de tipo “Track To” con un objeto “Empty” (Fig. 14). El render habrá que realizarlo con cada una de las cámaras, componiendo el resultado de las dos cámaras en una misma imagen o fotograma del video resultado. [L7]

Fig. 14: Configuración de cámaras estereoscópicas en Blender


49

NAVEGACIÓN VIRTUAL

Se han probado las posibilidades de navegación sobre el programa Google Earth [W32]. La interacción resulta cómoda y natural.

Además, se han aplicado con éxito versiones de prueba de drivers 3D que logran la percepción 3D por diversos medios estereoscópicos: entrelazado, anaglifos (Figs. 16-18), dos salidas de vídeo para polarización... El GIGA tiene en sus laboratorios un equipo de proyección 3D con luz polarizada (Fig. 15).

Fig. 15: Esquema de funcionamiento de un proyector 3D de luz polarizada

Ndivia tiene un driver para sus tarjetas. Otro que funciona bien en las demás tarjetas es el driver iZ3d. [W25]

La aplicación Stereo GE Browser [W26] también cumple con este cometido dentro de Google Earth. Carga dos vistas ligeramente desplazadas y crea sensación de profundidad.

Los accidentes geográficos se representan en 3D, así como los edificios que hayan sido modelados.

Fig. 16: Gafas rojo/cian para visión de anaglifos


50

Como ejemplos: anaglifos de la Basílica del Pilar y del Aneto para mirar con gafas rojo/cian (Fig. 17 y Fig. 18).

Fig. 17: Anaglifo de la Basílica del Pilar de Zaragoza en Google Earth

Fig. 18: Anaglifo del pico Aneto en Google Earth


51

PIZARRA ELECTRÓNICA

Esta aplicación ya se ha explorado, pero con las limitaciones que implica un solo cursor. Las dos aplicaciones que lo utilizan son Whiteboard (Fig. 19) [W13] y Smoothboard [W14].

Fig. 19: Esquema de pizarra electrónica con Wiimote

El uso de un cursor con luz constante y un segundo para clicks de ratón o combinaciones de teclas mejoraría el sistema. Resultaría sencillo usando las funciones relacionadas con la homografía (transformación proyectiva).


52

JUEGOS

Nuestro sistema multiplica las capacidades de interacción en cualquier entorno no plano.

Se han probado algunas de las posibilidades de nuestro sistema en juegos de primera persona del estilo de Doom o Quake y resulta muy intuitivo y divertido. La misma filosofía de interacción es apropiada para juegos de interacción social, como Los Sims o Second Life. Cabría explorar la aplicación en otros juegos, como los de boxeo o los de pistolas de máquinas recreativas,

También sería indicado para juegos en los que se requieren usar muchas teclas ya que los gestos pueden ser más intuitivos que la pulsación de teclas.

El driver 3d, comentado anteriormente, también funciona para interceptar los gráficos que utilicen el motor DirectX (Fig. 20), con lo que podemos percibir gran variedad de juegos en 3D. La salida puede ser cualquier sistema estéreo.

Fig. 20: Ejemplo de traducción DirectX a anaglifo

Un listado con una evaluación de su compatibilidad se encuentra en la propia página de Nvidia [W28].

7

BIBLIOGRAFÍA

Listado de los recursos bibliográficos, documentales o programacionales a los que se refiere el texto, además de libros fundamentales consultados.

Cap.7: Bibliografía

54

LIBROS

[L1] C# Manual de referencia, Schild, Herbert, 2003

[L2] A. Multiple View Geometry in Computer Vision Second Edition, Hartley, R. and Zisserman, 2004

[L3] OpenCV Reference Manual, Intel Corporation, 2001

[L4] OpenGL Game Development, Chris Seddon, 2005

[L5] Learning OpenCV, Gary Bradski y Adrian Kaebler, 2008

[L6] Matrix Computations, Gene H. Golub, Charles F. Van Loan, 2007


55

[L7] Tecnologías Libres para Síntesis de Imagen Digital Tridimensional, IV Jornadas Blendiberia, Varios autores, 2006

[L8] Aprenda Matlab 7.0. como si estuviera en primero, J. García de Jalón, J. I. Rodríguez, J. Vidal, 2005


56

ARTÍCULOS

[A1] White Paper: Camera Calibration and Stereo Vision, Peter Hillman, 2005

[A2] Automatic Fundamental Matrix Estimation, Pedro Davalos, 2008

[A3] Random Sample Consensus (RANSAC), H. Cantzler, 2005

[A4] Recognizing Mouse Gestures, Johan Thelin, 2006

[A5] Tangible 3D: Hand Gesture Interaction for Immersive 3D Modeling, H. Kim, G. Albuquerque, S. Havemann, D. W. Fellner, 2005

[A6] Planes, Homographies and Augmented Reality, Björn Liljequist, 2003

[A7] Automatic Camera Calibration for Images of Soccer Match, Qihe Li, Yupin Luo, 2005

[A8] Interaction Techniques Using The Wii Remote (and other HCI projects), Johnny Chung Lee, 2008

[A9] Optical Tracking Using Commodity Hardware, Simon Hay, Joseph Newman, Robert Harle, 2008

[A10] Analysing Mouse and Pen Flick Gestures Michael Moyle, Andy Cockburn, 2002

[A11] 2D Projective Space : A Short, Geometrical, Intuitive and certainly absolutely incomplete Introduction, Darko Zikic, 2004

[A12] Visual 3D Modeling from Images, Marc Pollefeys, 2002

[A13] Geometrical Image Analysis: Epipolar Geometry and the Fundamental Matrix, Niclas Börlin, 2008


57

[A14] Estimación Robusta RANSAC, Luis Miguel Jiménez, José María Sebastián

[A15] Virtual 3D drawing tool for stage performances, L. B´elanger, S. Roy, 2009

[A16] Wiimote Virtual Reality Desktop, Timo Flesh, 2009

[A17] Presenting using Two-Handed Interaction in Open Space, Luc Vlaming, Jasper Smit, Tobias Isenberg, 2008

[A18] Stereo Vision: Triangulation Luca Iocchi, 1998

[A19] Homograf, un programa para la resolución de homografías 2D en Autocad V.:2002. F. Irles 1, L. M. Jiménez 2, M. A. Oliva 3, E. Velasco, 2005

ENLACES WEB

[W1] Microsoft Visual C# Express Studio http://www.microsoft.com/express/vcsharp/

[W2] WiimoteLib http://www.codeplex.com/WiimoteLib http://www.brianpeek.com/

[W3] OpenGL http://www.opengl.org/

[W4] Tao Framework

http://taoframework.com/

[W5] DotNetMatrix http://www.codeproject.com/KB/recipes/psdotnetmatrix.aspx

[W6] AutoItLib http://www.autoitscript.com/autoit3/

http://www.microsoft.com/express/vcsharp/�

http://www.codeplex.com/WiimoteLib�

http://www.brianpeek.com/�

http://www.opengl.org/�

http://taoframework.com/�

http://www.codeproject.com/KB/recipes/psdotnetmatrix.aspx�

http://www.autoitscript.com/�

http://www.autoitscript.com/autoit3/�


58

[W7] OpenCV: Open Computer Vision Library http://sourceforge.net/projects/opencvlibrary/

[W8] CvLib

http://www.codeproject.com/KB/cs/Intel_OpenCV.aspx

[W9] WiiLi: A GNU/Linux port for the Nintendo Wii. http://www.wiili.org/

[W10] Wiimote Project Portal: http://www.wiimoteproject.com/

[W11] WiiBrew http://wiibrew.org/wiki/Wiimote

[W12] WiiYourself: Native C++ Wiimote Library http://wiiyourself.gl.tter.org/

[W13] Wiimote Whiteboard

http://www.uweschmidt.org/wiimote-whiteboard

[W14] SmoothBoard http://www.smoothboard.net/

[W15] Johnny Chung Lee's Wii Projects

http://johnnylee.net/projects/wii/

[W16] Wiimote 3D Library http://w3dlib.codeplex.com/

[W17] Curso: Estimación de la Geometría en Visión por Computador (Universidad de la República de Uruguay) http://iie.fing.edu.uy/investigacion/grupos/gti/cursos/egvc/

[W18] Science Encyclopedia http://science.jrank.org/pages/5510/Projective-Geometry-Coordinate-projective-geometry.html

[W19] MSDN Library

http://msdn.microsoft.com/es-es/library/

[W20] Camera Calibration and 3D Reconstruction Reference (OpenCV) http://www710.univ-lyon1.fr/~bouakaz/OpenCV-0.9.5/docs/ref/OpenCVRef_3dReconstruction.htm

http://sourceforge.net/projects/opencvlibrary/�

http://www.wiimoteproject.com/�

http://wiibrew.org/wiki/Wiimote�

http://wiiyourself.gl.tter.org/�

http://www.uweschmidt.org/wiimote-whiteboard�

http://www.smoothboard.net/�

http://johnnylee.net/projects/wii/�

http://science.jrank.org/pages/5510/Projective-Geometry-Coordinate-projective-geometry.html�

http://science.jrank.org/pages/5510/Projective-Geometry-Coordinate-projective-geometry.html�

http://msdn.microsoft.com/es-es/library/�

http://www710.univ-lyon1.fr/~bouakaz/OpenCV-0.9.5/docs/ref/OpenCVRef_3dReconstruction.htm�

http://www710.univ-lyon1.fr/~bouakaz/OpenCV-0.9.5/docs/ref/OpenCVRef_3dReconstruction.htm�


59

[W21] Extensible Markup Language (XML) http://www.w3.org/XML/

[W22] Encyclopeida Britannica http://www.britannica.com/

[W23] R.A.E. http://www.rae.es/

[W24] Wikipedia http://es.wikipedia.org/

[W25] iZ3D Display Driver http://www.iz3d.com/driver

[W26] Stereo GE Browser http://stereo.jpn.org/eng/stge/stbrhelp.html

[W27] Proyecto TANGIBLE http://giga.cps.unizar.es/proyectos/91

[W28] Nvidia 3D Vision Game Support

http://www.nvidia.com/object/3D_Vision_3D_Games.html

[W29] EON Reality ICube http://www.eonreality.com/products_icube.html

[W30] Matlab

http://www.mathworks.com/

[W31] Blender http://www.blender.org/

[W32] Google Earth

http://earth.google.es/

[W33] Vishay TSAL6400 Diode Datasheet http://www.datasheetcatalog.org/datasheet/vishay/81011.pdf

[W34] 3DConnection http://www.3dconnexion.com/

http://www.w3.org/XML/�

http://www.britannica.com/�

http://www.rae.es/�

http://www.iz3d.com/driver�

http://stereo.jpn.org/eng/stge/stbrhelp.html�

http://giga.cps.unizar.es/proyectos/91�

http://www.nvidia.com/object/3D_Vision_3D_Games.html�

http://www.eonreality.com/products_icube.html�

http://www.mathworks.com/�

http://www.blender.org/�

http://earth.google.es/�

http://www.datasheetcatalog.org/datasheet/vishay/81011.pdf�

http://www.3dconnexion.com/�

resumen memoria pfc: tangible: sistema de bajo coste para localización y detección de gestos 3d en...

Documents