estudio de tÉcnicas avanzadas para la interacciÓn...

Escu

ela

Polit

écn

ica S

up

eri

or

de J

aé

n

UNIVERSIDAD DE JAÉN Escuela Politécnica Superior de Jaén

Trabajo Fin de Grado

ESTUDIO DE TÉCNICAS

AVANZADAS PARA LA

INTERACCIÓN

PERSONA-ORDENADOR

APLICADAS AL MANEJO

DE NUBES DE PUNTOS

Alumno: David Martínez Montes Tutores: Prof. D. Rafael Jesús Segura Sánchez Prof. D. Carlos Javier Ogáyar Anguita Dpto: Informática

Junio, 2018

Estudio de técnicas avanzadas para la David Martínez Montes interacción persona-ordenador aplicadas al

manejo de nubes de puntos

2 Escuela Politécnica Superior de Jaén

Universidad de Jaén

Escuela Politécnica Superior de Jaén

Departamento de Informática

Don Rafael Jesús Segura Sánchez y Don Carlos Javier Ogáyar Anguita, tutores del

Proyecto Fin de Carrera titulado: Estudio de técnicas avanzadas para la interacción

persona-ordenador aplicadas al manejo de nubes de puntos, que presenta David

Martínez Montes, autorizan su presentación para defensa y evaluación en la Escuela

Politécnica Superior de Jaén.

Jaén, Junio de 2018

El alumno: Los tutores:

David Martínez Montes Rafael Segura Sánchez Carlos Ogayar Anguita




Índice 1. INTRODUCCIÓN ........................................................................................................... 6

1.1. Motivación ............................................................................................................... 6

1.2. Objetivos ................................................................................................................. 7

1.3. Resultados esperados ............................................................................................. 8

1.4. Metodología y modelo de desarrollo ........................................................................ 8

1.5. Estructura de la memoria .......................................................................................10

2. TECNOLOGÍAS USADAS .............................................................................................12

2.1. CloudCompare .......................................................................................................12

2.1.1. C++ .................................................................................................................14

2.1.2. QT ...................................................................................................................14

2.2. Unity 3D .................................................................................................................15

3. PLANIFICACIÓN ...........................................................................................................17

3.1. Metodología ...........................................................................................................17

3.2. Requisitos iniciales .................................................................................................18

3.3. Planificación estimada ............................................................................................19

3.4. Estimación de costes .............................................................................................23

3.4.1. Costes de Hardware .......................................................................................23

3.4.2. Costes de Software .........................................................................................24

3.4.3. Costes de personal .........................................................................................25

3.4.4. Costes totales .................................................................................................25

3.5. Desarrollo real ........................................................................................................26

4. PROYECTO ..................................................................................................................29

4.1. Iteración 1 – Estudio de dispositivos ......................................................................29

4.1.1. Requisitos .......................................................................................................29

4.1.2. Dispositivos .....................................................................................................29

4.1.3. Selección del dispositivo .................................................................................39

4.1.4. Reunión...........................................................................................................45

4.2. Iteración 2 – Viabilidad del dispositivo ....................................................................46

4.2.1. Requisitos .......................................................................................................46

4.2.2. Leap Motion y CloudCompare .........................................................................47

4.2.3. Interfaces Gestuales (estudio HCI) ..................................................................51

4.2.4. Diseño de un vocabulario de gestos ................................................................53




4.2.5. Prototipo de plugin con Leap Motion en CloudCompare ..................................56

4.2.6. Arquitectura de Leap Motion ...........................................................................58

4.2.7. Diseño de las herramientas del plugin. ............................................................66

4.2.8. Reunión...........................................................................................................68

4.3. Iteración 3 – Funciones básicas .................................................................................69

4.3.1. Requisitos .......................................................................................................69

4.3.2. Cambiar herramienta.......................................................................................70

4.3.3. Seleccionar en punto de la nube .....................................................................74

4.3.4. Traslación de una nube de puntos ..................................................................77

4.3.5. Rotación de una nube de puntos .....................................................................79

4.3.6. Escalado de una nube de puntos ....................................................................82

4.3.7. Centrar una nube de puntos ............................................................................85

4.3.8. Reunión...........................................................................................................88

4.4. Iteración 4 – Funciones avanzadas ........................................................................89

4.4.1. Requisitos .......................................................................................................89

4.4.2. Elección de mano preferida .............................................................................89

4.4.3. Rotación eje-ratón. ..........................................................................................91

4.4.4. Rotación directa. .............................................................................................94

4.4.5. Escalado de una nube de puntos (con 2 manos) .............................................96

4.4.6. Seleccionar un conjunto de puntos..................................................................98

4.4.7. Borrado de selección de puntos. ................................................................... 102

4.4.8. Reunión......................................................................................................... 104

4.5. Iteración 5 - Test de prueba ................................................................................. 105

4.5.1. Requisitos ..................................................................................................... 105

4.5.2. Mejoras de precisión y suavidad ................................................................... 105

4.5.3. Acciones sobre nubes de puntos individuales ............................................... 110

4.5.4. Interfaz del plugin .......................................................................................... 113

4.5.5. Test de validación para usuarios ................................................................... 115

4.5.6. Reunión......................................................................................................... 118

4.6. Iteración 6 - Estudio de resultados ....................................................................... 119

4.6.1. Requisitos ..................................................................................................... 119

4.6.2. Automatización del test ................................................................................. 119

4.6.3. Realización y recogida de datos del test ....................................................... 123

4.6.4. Análisis sobre los resultados obtenidos. ........................................................ 125

4.6.5. Reunión y trabajo futuro ................................................................................ 131

5. ANEXO ....................................................................................................................... 132




5.1. Póster CEIG ......................................................................................................... 132

Bibliografía ......................................................................................................................... 133




1. INTRODUCCIÓN

En los últimos años, el uso de escáneres 3D de medio y largo alcance se ha

generalizado en numerosos ámbitos, como topografía, cartografía, arquitectura,

ingeniería civil, planificación urbana, arqueología y conservación del patrimonio

histórico, entre otros.

Uno de los principales problemas con el que nos encontramos para el manejo

de las nubes de puntos obtenidos radica en el gran volumen de datos a procesar,

siendo los procedimientos de inspección y edición bastante básicos, principalmente

manuales y utilizando técnicas de interacción convencionales basadas en el uso de

teclado/ratón.

Es por ello por lo que existe una necesidad de investigar la utilización de

nuevas metáforas de interacción basadas en dispositivos de realidad virtual tales

como ratones 3D, tabletas 3D o dispositivos tipo HTC-VIVE o similares basados en

Head-Mounted Displays y dispositivos apuntadores. Con ello se pretende definir

nuevos métodos de manejo de este tipo de información que permitan aumentar la

productividad en los procesos de edición de nubes de puntos.

Dada la ambición que podría desprender este proyecto, este TFG se centrará

en desarrollar una primera versión de una nueva forma de interacción persona-

ordenador con algún dispositivo del tipo mencionado anteriormente. A través de

esto, podremos estudiar la viabilidad de un nuevo tipo de interacción y su posterior

desarrollo final para las distintas aplicaciones del mercado actualmente.

1.1. Motivación

En primer lugar, la motivación que me ha llevado a la elección de este

proyecto es la posibilidad existente de innovar en el mundo de la tecnología

actualmente asentado. Este propósito me acercaría a tratar con nuevos tipos de

tecnologías y dispositivos, como bien puede ser la realidad virtual, reconocedores de

gestos y otros dispositivos 3D, que pueden permitir una nueva forma de interacción

con el ordenador.




Pero esto no es solo aplicable a los campos de estudio de este TFG, sino que

se trata de la construcción de nuevos paradigmas que pueden hacer olvidar a los

clásicos ratón y teclado por algo más novedoso, cómodo y fácil de usar.

El poder aportar algo en estos nuevos avances en el mundo de la

computación e iniciarme en las tareas de investigación en la informática, en

específico, en el mundo gráfico y del 3D, es mi principal motivación para escoger

esta temática, que me proporcionará nuevos retos en mi carrera profesional, los

cuales nunca he tenido oportunidad de enfrentar.

1.2. Objetivos

El objetivo principal a cumplir para este proyecto será el de la investigación y

desarrollo de una forma de interacción, novedosa a lo normalmente ofrecido por los

actuales software de tratamiento de nubes de puntos.

Para ello se necesitará de una investigación en profundidad de los actuales

paradigmas de interacción con los computadores. Basándonos en los resultados,

podremos introducir en nuestro software el que mejor pueda adaptarse para nuestro

propósito.

Una vez elegido el mecanismo de interacción a desarrollar, se comenzará a

cumplir con el objetivo principal de este TFG, creando una nueva forma de tratar con

las nubes de puntos, desde las funcionalidades más básicas, como señalar un punto

y las transformaciones geométricas, hasta las más complejas, como el marcado de

una zona de puntos y su tratamiento posterior según su requisito.

El último objetivo a completar en este proyecto será la revisión de la nueva

forma de interacción, parte fundamental durante la producción de un software, a

partir de alguna prueba de validación con distintos usuarios, que nos permita

conocer si nuestro experimento de investigación podría tener un buen futuro en

estos ámbitos, y si es así, su posible traslado a otras áreas del mundo de la

computación.




1.3. Resultados esperados

Buscamos que el desarrollo y despliegue de toda la aplicación se realice a

coste cero (o lo menor posible), aprovechando para tal fin las herramientas y

plataformas que ofrezcan servicios gratuitos.

De la realización de este trabajo de experimentación se espera la consecución

del tan anhelado nuevo mecanismo de interacción que pueda destronar a los algo

irritantes procesos de manejo de grandes colecciones de nubes de puntos mediante

teclado y ratón.

Además, se pretende la obtención de conocimientos sobre las nuevas formas

de interacción usadas actualmente, y aunque el proyecto se centre en una sola, no

se descartaría la posibilidad de ampliación a otros nuevos paradigmas en un futuro.

1.4. Metodología y modelo de desarrollo

En la elaboración de este proyecto me he basado en un modelo de desarrollo

iterativo y creciente, en el cual se especifican un conjunto de tareas agrupadas en

pequeñas iteraciones.

El uso de este modelo está creciendo rápidamente en los proyectos

informáticos, sobre todo en aquellos donde no se sabe a ciencia cierta si puede

haber cambios de requisitos durante el desarrollo.

La idea fundamental de este modelo de desarrollo es proporcionar al

desarrollador un continuo feedback del trabajo acometido en cada iteración del

proceso. La clave está en empezar a implementar una solución simple con los

requisitos más básicos del sistema, y a partir de ahí, ir mejorando la solución

mediante iteraciones con los clientes hasta completar el sistema final. Su principal

ventaja es que es un método adaptativo, lo cual es muy ventajoso en este tipo de

desarrollos, en los que suelen surgir cambios, que seguramente no hayan podido ser

previstos de antemano.




Debido al desconocimiento de unos requisitos exactos para este proyecto, en el

que los más probable fuese que su desarrollo surgiera sobre la marcha, he optado

por la selección de este modelo de desarrollo. Aunque el sistema de Scrum incluya

un conjunto de roles en el proceso (ScrumMaster, Product Owner, Team), serán

asumidos por mí, al ser el único realizador del proyecto. En todo caso el Product

Owner podría ser interpretado por los tutores del TFG, que darán la

retroalimentación y nuevos objetivos del proceso.

Ilustración 1.1 – Comparativa de metodologías de desarrollo

Como vemos en la siguiente ilustración, sobre una comparativa de distintas

metodologías de desarrollo, Scrum se adapta mejor a los cambios.

Se ha seguido una metodología Scrum, con sprints en periodos de entre 2 y 4

semanas, como ella misma recomienda. En cada sprint, se crea un incremento del

software operativo, ya sea con la corrección de elementos establecidos en la reunión

anterior o nuevas funcionalidades. Los ítems a realizar en cada iteración se

determinan durante la reunión de planificación de la misma.




Durante esta reunión, el Product Owner informa al equipo de las tareas que

quiere que se completen. El equipo determina entonces la cantidad de tareas que

puede comprometerse a realizar durante la siguiente iteración, para mostrarlo una

vez finalizada, en la siguiente reunión.

Las reuniones que se realizan durante cada iteración son de distintos tipos:

- Scrum diario: cada día durante la iteración, tiene lugar una reunión de

estado del proyecto. A esta reunión se le domina daily.

- Reunión de planificación de iteración (sprint): se lleva a cabo al

principio del ciclo de la iteración.

- Reunión de revisión de iteración: al final del ciclo de la iteración.

- Iteración retrospectiva: al final del ciclo de la iteración.

Así, el esquema del método elegido sería el mostrado en la ilustración 1.2

Ilustración 1.2 – Esquema de la metodología Scrum

1.5. Estructura de la memoria

Una vez terminado el capítulo de introducción de esta memoria, en este

apartado haré un pequeño resumen de cada uno de los capítulos restantes.

En el segundo capítulo se realiza un análisis completo del software sugerido

con el que podemos tratar con grandes colecciones de nubes de puntos.




Durante el tercer capítulo me centro en realizar un estudio de planificación del

proyecto de investigación en torno a los costes y tiempos estimados, su desarrollo

real y la metodología a seguir en la investigación.

El cuarto capítulo de esta memoria será el principal del documento, ya que en

éste se explicará cada iteración realizada durante el proyecto, explicando los

objetivos a cumplir, el diseño y desarrollo del software y las reuniones entre la parte

cliente y desarrolladora para la especificación de nuevos requisitos.

En el quinto y último capítulo se expone algún anexo relacionado con esta

memoria y la bibliografía principal usada para la realización de dicho proyecto.




2. TECNOLOGÍAS USADAS

En este apartado se tratará acerca de los software recomendados por los

tutores para el manejo de nubes de puntos, así como sus posibles alternativas. Se

dejará de lado los aspectos del hardware considerado para el nuevo mecanismo de

interacción, debido a que será explicado posteriormente en el apartado 4, cuando se

comenta acerca del estudio realizado sobre los distintos dispositivos para la elección

de uno.

2.1. CloudCompare

CloudCompare es un software de procesamiento de nubes de puntos 3D (y

mallas triangulares). Ha sido diseñado originalmente para realizar comparaciones

entre dos nubes de puntos 3D densas (como las adquiridas con un escáner láser) o

entre una nube de puntos y una malla triangular. Se basa en una estructura de

octree específica dedicada a esta tarea. Posteriormente, se ha ampliado a un

software de procesamiento de nubes de puntos más genérico, incluyendo muchos

algoritmos avanzados (registro, remuestreo, manejo de campos

color/normal/escalar, cálculo de estadísticas, gestión de sensores, segmentación

interactiva o automática, mejora de la visualización, etc.).

Ilustración 2.1 – Interfaz de CloudCompare




La principal ventaja que nos aporta CloudCompare a la finalidad de nuestro

proyecto es la capacidad de poder desarrollar nuevos plugins y poder integrarlos sin

ningún tipo de problemas. De esta forma podríamos activar y usar la nueva

interacción siempre que el usuario quiera, teniendo disponible el antiguo paradigma

de interacción (teclado-ratón) al mismo tiempo. Se podrían distinguir entre 2 tipos de

plugins:

Estándar (algoritmos)

Ilustración 2.2 - Oclusión ambiental de una nube de puntos RAW con el plugin qPCV

Filtros OpenGL (sombreadores avanzados)

Ilustración 2.3 - Ejemplo de filtros GL en tiempo real aplicados en nubes de puntos RAW

CloudCompare puede cargar muchos formatos de nubes de puntos abiertos

(ASCII, LAS, E57, etc.) así como formatos de algunos fabricantes (DP, Riegl, FARO,

etc.). También puede cargar mallas triangulares (OBJ, PLY, STL, FBX, etc.) y

algunos formatos de polilíneas o polígonos (SHP, DXF, etc.). Algunos formatos SfM

también son compatibles (Bundler, Photoscan PSZ, etc.).




Finalmente hay que destacar los lenguajes de programación que

principalmente componen CloudCompare.

2.1.1. C++

C++ es un lenguaje de programación orientado a objetos que toma la base del

lenguaje C y le agrega la capacidad de abstraer tipos.

La intención de su creación fue el extender al exitoso lenguaje de programación

C con mecanismos que permitieran la manipulación de objetos. En ese sentido,

desde el punto de vista de los lenguajes orientados a objetos, el C++ es un lenguaje

híbrido.

Posteriormente se añadieron facilidades de programación genérica, que se

sumó a los otros dos paradigmas que ya estaban admitidos (programación

estructurada y la programación orientada a objetos). Por esto se suele decir que el

C++ es un lenguaje de programación multiparadigma.

C++ está considerado por muchos como el lenguaje más potente, debido a que

permite trabajar tanto a alto como a bajo nivel, sin embargo, es a su vez uno de los

que menos automatismos trae (obliga a hacerlo casi todo manualmente al igual que

C) lo que "dificulta" mucho su aprendizaje.

2.1.2. QT

Qt es un framework multiplataforma orientado a objetos ampliamente usado

para desarrollar programas (software) que utilicen interfaz gráfica de usuario, así

como también diferentes tipos de herramientas para la línea de comandos y

consolas para servidores que no necesitan una interfaz gráfica de usuario.

Cuenta con herramientas de desarrollo para los principales entornos software y

permite emitir ejecutables para las plataformas con mayor aceptación en el mercado,

tanto de escritorio como móviles (Windows, MacOS, Linux, iOS, Android). Cuenta

con soporte nativo para OpenGL.

QT presenta varios puntos a su favor. En primer lugar, tiene bindings para

múltiples lenguajes, lo que nos abre todo un abanico de posibilidades. De entre




todos, destaca el lenguaje original en el que se construyó el proyecto C++. Los

lenguajes compilados suelen proporcionar un buen rendimiento en las aplicaciones.

Los puntos en su contra son más dispersos. En primer lugar, el soporte para

muchas de las plataformas móviles se ha incorporado en últimas versiones, lo que

puede dar lugar a inconsistencias entre plataformas, obligándonos a disponer de

infraestructura y materiales para testear y a, potencialmente, deber de mantener

más de una versión de nuestro software, precisamente uno de los inconvenientes

que buscamos evitar. En segundo lugar, las licencias. Aunque su versión para

plataformas de escritorio es gratuita y publicada bajo una licencia abierta, a la hora

de usar la herramienta para dispositivos móviles la licencia no queda tan clara,

pudiendo llegar incluso a enfrentarnos a problemas legales.

2.2. Unity 3D

Unity es un motor de videojuegos multiplataforma creado por Unity

Technologies. Unity está disponible como plataforma de desarrollo para Microsoft

Windows, OS X, Linux.

Unity puede usarse junto con Blender, 3ds Max, Maya, Softimage, Modo,

ZBrush, Cinema 4D, Cheetah3D, Adobe Photoshop, Adobe Fireworks y Allegorithmic

Substance. Muchos de estos software son manipuladores de nubes de puntos y

mallas de triángulos, y por consiguiente Unity también lo es, siendo una opción

posible como alternativa a CloudCompare para manejar nubes de puntos.

El motor gráfico utiliza OpenGL (en Windows, Mac y Linux), Direct3D (solo en

Windows), OpenGL ES (en Android y iOS), e interfaces propietarias (Wii).

Pueden escribirse shaders en tres formas distintas: como Surface shaders,

como Vertex and Fragment shaders, o como shaders de función fija. Un shader

puede incluir múltiples variantes y una especificación declarativa de reserva, lo que

permite a Unity detectar la mejor variante para la tarjeta de vídeo actual y si no son

compatibles, recurrir a un shader alternativo que puede sacrificar características

para una mayor compatibilidad.




El scripting viene a través de Mono. El script se basa en Mono, la

implementación de código abierto de .NET Framework. Los programadores pueden

utilizar UnityScript (un lenguaje personalizado inspirado en la sintaxis ECMAScript),

C# o Boo (que tiene una sintaxis inspirada en Python). A partir de la versión 3.0

añade una versión personalizada de MonoDevelop para la depuración de scripts.

Unity también incluye Unity Asset Server - una solución de control de versiones

para todos los assets de juego y scripts, utilizando PostgreSQL como backend, un

sistema de audio construido con la biblioteca FMOD, con capacidad para reproducir

audio comprimido Ogg Vorbis, reproducción de vídeo con códec Theora, un motor

de terreno y vegetación, con árboles con soporte de billboarding, determinación de

cara oculta con Umbra, una función de iluminación lightmapping y global con Beast,

redes multijugador RakNet y una función de búsqueda de caminos en mallas de

navegación.

Todo esto, además de para lo mencionado anteriormente, puede hacer a Unity

una buena herramienta para la realización de prototipos de una forma rápida,

gracias a su sencillez de manejo.

Ilustración 2.4 – Entorno Unity3D con nube de puntos




3. PLANIFICACIÓN

3.1. Metodología

El proyecto ha sido desarrollado utilizando una metodología ágil, como ya fue

explicado en el apartado 1.4, en la que existe un conjunto inicial de requisitos que

puede variar con el tiempo (ya sea añadiendo nuevos requisitos, modificando los

existentes o eliminándolos), por lo que la solución software debe adaptarse en

función de dichos cambios.

La metodología ágil es iterativa, lo que significa que las fases de desarrollo del

software donde se incluyen planificación, análisis, diseño, desarrollo, revisión y

documentación, se realizan en cortos periodos de tiempo denominados iteraciones.

Para este proyecto, en concreto, cada iteración tenía lugar en un periodo de tiempo

de 4 semanas aproximadamente. Esto es así, debido a que el desarrollo del TFG fue

coordinado con la realización de una beca de investigación, en la que se deberían

invertir unas 3 horas diarias a la misma, no existiendo una dedicación completa del

tiempo al proyecto, y por lo cual, el tiempo de iteración se vería aumentado.

Las principales comunicaciones entre ambas partes, cliente y desarrollador, se

ejecutaron mediante correo electrónico o en persona, a través de los tutores durante

las iteraciones mostrando los distintos avances, como desarrollos o posibles ideas

de mejora para el proyecto de investigación, así como las posibles consultas que

surgieran.

Finalmente, a la finalización de cada iteración se realizaban reuniones con los

tutores y otras personas dentro del grupo de investigación de esta temática. Las

reuniones duran aproximadamente una hora, en las cuales se presentaba en directo

los objetivos cumplidos y desarrollados, además de posibles cuestiones sobre el

avance futuro. La parte cliente transmitía, tras esto, su valoración del progreso y se

pactaron las posibles modificaciones de los requisitos del proyecto, dando la

retroalimentación necesaria para la parte desarrolladora del proyecto.




3.2. Requisitos iniciales

Para la definición y establecimiento de los objetivos del proyecto, se realizó una

primera reunión entre la parte cliente (tutores) y la desarrolladora. En ella se explicó

el propósito de este proyecto de investigación, poniendo en contexto la existente

necesidad de investigación de vías alternativas de interacción en programas

manejadores de nubes de puntos. Finalmente, se constituyeron las metas que se

intentaban lograr mediante este proyecto.

Para su desarrollo, se fijó el software que trataría con las nubes de puntos

(CloudCompare, explicado en el apartado 2), posibilitando un traspaso de software a

Unity, en caso de ser inviable el desarrollo mediante el software anterior o como

complemento para un desarrollo de prototipado rápido de las posibles herramientas

de interacción disponible.

De manera global, se intuyen lo siguiente como objetivos básicos del proyecto:

Estudio acerca de las posibles herramientas disponibles por el grupo

de investigación, para su inclusión en la generación de un nuevo

paradigma de interacción con software de tratamiento de nubes de

puntos. Tras ello, se seleccionará el dispositivo o los dispositivos

definitivos con lo que se trabajará.

Una vez obtenida la herramienta, se investigará acerca de la viabilidad

de utilización en el software recomendado (CloudCompare), así como

las alternativas disponibles (cambio de software o herramienta) si esto

no llegara a ser posible.

Desarrollo de un plugin o herramienta con funciones básicas sobre el

tratamiento de nubes de puntos, como pueden ser las

transformaciones geométricas básicas de escalado, traslación y

rotación.

Desarrollo de funciones más complejas para nuestra herramienta,

comprobando así la posibilidad de agilización o simplificación de tareas

con nubes de puntos, como podrían ser, la selección de una serie de

puntos (o marcado) para su posterior tratamiento, por ejemplo,




borrándolos o creando 2 nubes de puntos distintas a partir de la

primera.

Estudio de verificación de la herramienta creada, mediante la

realización de una serie de tests, en los que se realizarán ejercicios de

simulación de acciones típicas en profesiones que utilicen este tipo de

software. A partir de los resultados, se considerará si se ha conseguido

una buena alternativa al trabajo tradicional, mediante teclado y ratón,

así como la posibilidad de abrir un abanico de interacción con otras

herramientas o la inmersión en el perfeccionamiento del dispositivo

elegido, si los resultados fueran muy favorables.

3.3. Planificación estimada

La planificación en la metodología ágil se realiza dando una puntuación a los

requisitos, en base a su dificultad de realización del mismo, y estimando el número

de puntos que van a ser completados en una iteración, llamando a esto último,

velocidad.

Para calcular el número de iteraciones que van a ser necesarias en nuestro

proyecto, debemos de sumar la puntuación de cada uno de los objetivos a realizar y

dividirlos posteriormente entre la velocidad que va a tomar nuestra investigación.

Posteriormente, debemos agregar a este valor un 10% más de tiempo, para

asegurar que el desarrollo se realizara en su tiempo, a causa de una posible

estimación a la baja, por parte del equipo de desarrollo, que necesitará más tiempo

para sus tareas. Finalmente tendríamos que agregar otro 10% adicional, debido a

que, al tratarse de una investigación de formato experimental, sin estar definida

completamente y estar abierta casi en su totalidad a cambios, es muy probable que

estos ocurran y sean necesarios la modificación u obtención de nuevos requisitos en

el proyecto.

Para la puntuación de los requisitos se utilizará el método Planning Poker, el

cual utiliza la secuencia de Fibonacci como valores para los requisitos. Esta

secuencia se caracteriza por el cálculo de cada término, siendo la suma de los dos

anteriores. Cada objetivo, obtendría una puntuación del tipo: 0, 1, 2, 3, 5, 8, etc.




Si un requisito supera el valor 8 se convertirá en demasiado complejo para

planificar y tendrá que ser dividido en varios requisitos más pequeños. Para puntuar

un requisito se ha tenido en cuenta el estudio bibliográfico previo asociado a este

(aprendizaje del software CloudCompare, por ejemplo), dificultad del diseño y

dificultad del desarrollo.

Podemos ver el resultado de este proceso en la tabla 3.1

Tabla 3.1

Nuestro Planning Poker nos dio un número total de 56 puntos, por lo cual, ya

que establecimos una velocidad inicial de 10 puntos por iteración, el proyecto de

investigación sería finalizado en 6 iteraciones. A esta estimación se añadirá un

margen del 20% (10% para retrasos y 10% para cambios en los requisitos).

Si cada iteración dura 4 semanas, la investigación debería quedar terminada en

un periodo de 6 meses aproximadamente. Esta estimación se basa en la premisa de

que las iteraciones empezarán sin retraso una tras otra y en que el proyecto no

recibirá cambios demasiado costosos.

Objetivo General Requisito Coste

Estudio dispositivos Búsqueda de dispositivos de interacción 3

Estudio dispositivos Eleccion si es novedoso en el campo (Busqueda asociada) 3

Estudio dispositivos Estudio dispositivos seleccionados 3

Viabilidad dispositivo Elección de software compatible con el dispositivo 3

Viabilidad dispositivo Conseguir software asociado al dispositivo 1

Viabilidad dispositivo Prototipo rápido usando el dispositivo en el software 5

Funciones básicas Cambiar de herramienta 2

Funciones básicas Seleccionar punto en nube de puntos 2

Funciones básicas Trasladar nube de puntos 2

Funciones básicas Rotar nube de puntos 2

Funciones básicas Escalar nube de puntos 2

Funciones avanzadas Selección de un conjunto de puntos 2

Funciones avanzadas Marcar puntos mediante selección de tamaño variable 5

Funciones avanzadas Tratamiento de puntos marcados (Por ejemplo: borrar) 3

Test de prueba Preparación de un test de prueba para usuarios 5

Test de prueba Realización y recogida de datos del test de prueba 5

Estudio de resultados Ordenación de datos y realización de estadísticas de uso 3

Estudio de resultados Análisis sobre los resultados obtenidos 3

Estudio de resultados Determinar si profundizar en la herramienta o probar otras 2

Coste Total 56




Es posible plantear una planificación real del tiempo de dedicación a cada una

de estas tareas descritas anteriormente, a través de la siguiente ilustración (cabe

destacar que el proyecto empezaría el día 1 de noviembre de 2017):

Ilustración 3.1 – Planificación de tareas del proyecto

A continuación, se muestra el diagrama de Gantt del proyecto para poder ver

gráficamente el desarrollo de las tareas del proyecto, así como los solapamientos

entre estas y las tareas críticas en el caso de existir.

Ilustración 3.2 – Diagrama de Gantt del proyecto de investigación

3.4. Estimación de costes

3.4.1. Costes de Hardware

Para este proyecto serán necesarios diferentes recursos que serán

categorizados en hardware, software y personal. A continuación, se lista el hardware

que se utilizará durante este proyecto:

Ordenador personal: este hardware deberá tener al menos un

procesador i7 o superior, además de una tarjeta gráfica NVIDIA GeForce

GTX 1060 o superior para un manejo fluido del software de tratamiento

de grandes colecciones de nubes de punto en 3D. Se utilizará para

implementar la aplicación; con un coste de 1300€.

Leap Motion: este hardware será usado como posible herramienta de

interacción; con un coste de 79.99€.

Ratón 3D: este hardware será usado como posible herramienta de

interacción; con un coste de 129€.

Tableta Digitalizadora Wacom Intuos Pro L - South: este hardware será

usado como posible herramienta de interacción; con un coste de

458.30€.

Algunos de ellos ya están en propiedad de antemano, por lo que

amortizaremos su coste para la duración del proyecto. El ordenamiento con respecto

a la amortización de bienes viene regulado por la Ley 27/2014 del 27 de noviembre

sobre el Impuesto sobre Sociedades, publicada en el Boletín Oficial del Estado a

fecha 28 de noviembre de 2014 (Gobierno de España, 2014).

Dicha ley estipula que el periodo de amortización para software es de 6 años,

2190 días, mientras que para los equipos para procesos de información (hardware)

es de 8 años, 2920 días. Dicho esto, amortizaremos todos los recursos utilizados

durante un periodo de 6 meses (1 noviembre – 30 abril, plazo de 6 meses estimado),

equivalentes a 181 días.




Así, obtendríamos la siguiente tabla acerca de la amortización de los productos

de categoría hardware:

Tabla 3.2

3.4.2. Costes de Software

Aquí se presenta la lista del software que será necesario para el desarrollo del

proyecto.

Visual Studio 2017: esta herramienta se utilizará como entorno de

desarrollo para el plugin a agregar al software. Tiene un coste de 0€ al

usar la licencia gratuita proporcionada por la Universidad de Jaén.

Windows 2010 pro: Sistema operativo funcional para el software

utilizado en el desarrollo del proyecto. Licencia: 259€

CloudCompare: software utilizado en el desarrollo del nuevo paradigma

de interacción, de libre uso, por lo cual el coste es 0€.

QT Open Source: software utilizado junto a CloudCompare, al que le

proporciona una interfaz. Al usar la versión Open Source, su costo es

0€.

Unity Personal: software utilizado para el prototipado rápido de

soluciones con distintos dispositivos de interacción. Al ser la versión

“Personal”, su costo es 0€.

C-Make: herramienta open source, necesaria para la realización del

nuevo plugin, convirtiendo el software original, en un proyecto valido

para el IDE Visual Studio. Coste 0€.

Hardware Coste Total

Periodo de amortización

Amortizado/día Amortizado/181 días (6 meses)

Ordenador Desarrollo

1300.00€ 2920 0.45€ 81.45€

Leap Motion 79.99€ 2920 0.03€ 5.43€

Ratón 3D 130.00€ 2920 0.04€ 7.24€

Tableta Digitalizadora

458.30€ 2920 0.16€ 28.96€

Coste Total 1968.29€ Total amortizado

123.08€




Visual Paradigm Community Edition: software empleado a la hora de

diseñar soluciones software válidas para nuestro proyecto. Esta versión

tiene coste 0€.

Así, obtendríamos la siguiente tabla acerca de la amortización de los productos

de categoría software:

Tabla 3.3

3.4.3. Costes de personal

Nos quedaría considerar el salario del único trabajador que realizará las

funciones de un analista programador, el cual, según el convenio colectivo en vigor

para las TIC, del año 2009, tendría un salario mensual total (Salario base + plus

convenio) de: 1642.41€

Tabla 3.4

3.4.4. Costes totales

Finalmente tendríamos los gastos totales invertidos en el desarrollo del

proyecto mediante la siguiente tabla:

Tabla 3.5

Hardware Coste Total

Periodo de amortización

Amortizado/día Amortizado/181 días (6 meses)

Visual Studio 2017 0.00€ 2190 0.00€ 0.00€

Windows 10 Pro 259.00€ 2190 0.12€ 21.72€

CloudCompare 0.00€ 2190 0.00€ 0.00€

Qt Open Source 0.00€ 2190 0.00€ 0.00€

Unity Personal 0.00€ 2190 0.00€ 0.00€

C-Make 0.00€ 2190 0.00€ 0.00€

Visual Paradigm Comunity Edition

0.00€ 2190 0.00€ 0.00€

Coste Total 259.00€ Total amortizado

21.72€

Personal Salario mensual Tiempo de trabajo Coste Total

Analista programador 1642.41€ 6 meses 9854.46€

Recurso Coste Total Amortizado Coste Final

Hardware 1968.29€ 123.08€ 1845.21€

Software 259.00 € 21.72€ 237.28 €

Humano 9854.46€ 0.00€ 9854.46€

Coste Total 12081.75€ 144.80€ 11936.95€




3.5. Desarrollo real

El desarrollo real del proyecto pudo comenzar tras la reunión inicial,

mencionada anteriormente, en la es que se especificaron los objetivos a conseguir

mediante la investigación. A continuación, podemos ver la tabla 3.6, en la que se

muestra la fecha de inicio y fin de cada iteración, así como la velocidad real que se

ha tomado en cada una de ellas.

Tabla 3.6

Cabe decir que las fechas de la tabla están descritas de forma teórica,

manteniendo una reunión al mes, que no tenía por qué tener lugar justo a la fecha

de inicio, variando debido a imposibilidades de acudir o que simplemente fuera un

periodo festivo, como en el comienzo de la iteración 3.

En lo que respecta a la velocidad de avance en el proyecto, se observa un

claro crecimiento progresivo, aunque teóricamente esta debería ser más o menos

estable.

El comienzo de la investigación fue lento, debido a muchos motivos, como la

adecuación a la búsqueda y estudio de artículos (tarea nunca antes realizada),

adaptación a las nuevas tecnologías estudiadas, así como al software a utilizar en el

manejo de nubes de puntos, cuya comprensión acerca de su funcionamiento es un

poco tediosa.

A partir de la 3 iteración, entrando en un periodo más de programación, sobre

la cual poseo una mayor afición, y aprovechando el cambio de cuatrimestre

(reduciendo la carga de trabajo aportada por las asignaturas), se consiguió aumentar

la velocidad de avance, consiguiendo, además, poder incluir y adaptarse a los

nuevos requisitos en los periodos de tiempo previamente establecidos.

Iteración Fecha de inicio Fecha de fin Velocidad real

1 1 de noviembre 30 de noviembre 9

2 1 de diciembre 31 de diciembre 9

3 1 de enero 31 de enero 13

4 1 de febrero 28 de febrero 14

5 1 de marzo 31 de marzo 18

6 1 de abril 30 de abril 14




Como ya se predijo, durante el desarrollo del proyecto aparecieron nuevos

requisitos que hubo que añadir a los ya existentes. Todos ellos quedan recogidos en

la siguiente tabla, determinando el propio requisito, la iteración a la que pertenecía y

el coste estimado de su desarrollo.

Tabla 3.7

Toda esta información anterior se puede resumir utilizando un solo gráfico

llamado Burndown Chart. Aquí podemos encontrar el número de puntos totales del

proyecto, incluyendo los agregados posteriormente. Podemos ver una comparativa

entre los puntos reales estimados que iban quedando con cada iteración con los

puntos teóricos. Además, se nos muestra la velocidad de avance con cada iteración

y su progresión.

Ilustración 3.3 – Comparativa avance de puntos (Estimación-Realidad-Velocidad)

0 1 2 3 4 5 6

Pu

nto

s

Iteraciones

Puntos Estimados Puntos Reales Velocidad

Iteración Requisito Coste

2 Búsqueda estándares HCI (Human Computer Interaction) sobre la forma de interacción del dispositivo elegido.

3

3 Preparar varias formas de interaccion para una acción 3

3 Posibilitar funcionamiento con mano izquierda o derecha (a eleccion por el usuario)

1

4 Realizar acciones sobre nubes de puntos de forma individual o con varias de forma conjunta

3

4 Mejorar la precisión y suavidad de la herramienta 3

4 Integración de tutoriales en el plugin que informen acerca de cómo usar la herramienta

2

5 Automatización de los resultados de los tests de interacción 5

5 Creación de un lenguaje XML que mejore el tratamiento de datos 1




Este gráfico tiene en cuenta los nuevos requisitos, así como su coste, en el

momento en el que estos fueron introducidos. Por ejemplo, si al empezar la iteración

2 tenemos un total de 44 puntos por realizar, al final de la iteración tendremos ese

número menos el número de puntos avanzado por iteración (10 + 20% por cambios

y errores de cálculo = 12 puntos / iteración), es decir, nos quedarían 32 puntos a

realizar. A este número debemos sumarle el coste de las nuevas tareas, que en este

caso serían 3, quedándose finalmente el número de puntos estimados al final de la

iteración 2 en 35. Igual pasaría con el número de puntos reales.

Observando el gráfico, se muestra claramente que el número de cambios

realizados va a afectar significativamente al desarrollo de la investigación, quedando

teóricamente un total de 5 puntos por realizar al final de los 6 meses previstos para

el proyecto. Esto significaría el aumento de la duración en medio mes, provocando

de la misma forma la subida de los costes.

Sin embargo, aunque se comenzó con una velocidad baja y parecía que podría

tardar más tiempo en completarse el proyecto, la velocidad aumentó bastante,

dando lugar a la finalización del mismo en los tiempos planificados y ahorrándonos

este sobrecoste mencionado anteriormente.




4. PROYECTO

4.1. Iteración 1 – Estudio de dispositivos

4.1.1. Requisitos

La iteración 1 se centra en un periodo de estudio e investigación acerca de la

nueva forma de interacción, la cual pretende sustituir o ayudar a facilitar las tareas

(tediosas) sobre colecciones de nubes de puntos, manejadas mediante los

dispositivos tradicionales teclado y ratón.

Para dicha tarea, se han implantado una serie de objetivos básicos a realizar,

que ayudarán a dar una orientación a la investigación y encaminarla hacia buen

puerto. Estos objetivos serían los siguientes:

Búsqueda de dispositivos de interacción.

Estudio acerca de la novedad que suponen los dispositivos en los

campos de estudio.

Estudio en profundidad de los dispositivos seleccionados, para la

elección final de aquellos que formarán parte del nuevo paradigma de

interacción.

Finalmente, podemos prever que esta primera iteración en el proceso de

realización de este TFG se desarrollará de una manera más teórica, iniciándose en

una búsqueda bibliográfica acerca de los objetivos mencionados y acercando al

alumno en cuestión, al mundo de la investigación, en el que primeramente debe

estudiar el estado del arte del problema a resolver, así como la búsqueda de un

abanico de soluciones posibles, su validez y verificación de las mismas.

4.1.2. Dispositivos

Al principio, se me proporcionó una serie de dispositivos pertenecientes al

grupo de investigación, al que pertenezco para la realización de este proyecto, que

podrían serme de utilidad en base a los requisitos buscados. Dichos dispositivos

serían los siguientes:




Ratón 3D (Space Navigator). Un ratón 3D es un dispositivo de

apuntamiento y control especializado en el movimiento en entornos 3D

virtuales (tridimensionales).

Los ratones 3D tienen varios grados de libertad de movimiento. Permiten

al usuario ampliar, desplazar y rotar imágenes 3D simultáneamente, sin

necesidad de utilizar atajos de teclado ni ninguna interfaz de software.

Además, el usuario no está obligado a alternar las manos al navegar.

Los dispositivos de ratón 3D han utilizado una serie de medios diferentes

para controlar el movimiento 3D, así como el apuntamiento 2D,

incluyendo sensores multieje, acelerómetros, luces IR y sensores IR.

Una serie de dispositivos señaladores de ordenador y controladores de

juegos podrían considerarse ratones 3D. El mando de Wii y Playstation

Move son dos versiones conocidas de la consola. Para el PC, un ratón

3D podría ser un ratón estándar con un botón para cambiar el eje al que

se traduce el movimiento del ratón.

Uno de los dispositivos más exitosos en sectores profesionales como

arquitectura, CAD, diseño 3D y modelado 3D es el 3DConnexion

SpaceNavigator, el cual procederemos a analizar, ya que es la versión

que está en nuestra posesión para este proyecto.

El dispositivo SpaceNavigator cuenta con un cilindro de elevación,

descenso y rotación sobre una base diseñada para facilitar el

movimiento ambiental y la manipulación del modelo. Los dispositivos

originales y muchos otros similares siguen siendo fabricados por

3Dconnect, donde todavía sirven a este nicho de mercado ahora con

versiones inalámbricas que incluyen más botones programables.

El ratón 3D no ha tenido tanto éxito en el mercado de PC como en el de

las consolas de videojuegos, probablemente porque un ratón estándar

generalmente funciona bastante bien para navegar en un entorno 3D.

Aunque algunos dispositivos pueden proporcionar ganancias reales de




productividad, hay una curva de aprendizaje para acostumbrarse a ellos.

Los proveedores no han podido diseñar una alternativa que supere

sistemáticamente al viejo ratón probado y verdadero.

Ilustración 4.1 – Ratón 3D (Space Navigator)

En este primer análisis, de forma más teórica, hemos podido conocer

que este dispositivo se trata de una herramienta con cierta antigüedad,

desde su invención a principios de los años 90, que no ha logrado

triunfar en muchos de los sectores de la tecnología.

Sin embargo, sí que se destaca su éxito en entornos de desarrollo CAD,

diseño y modelado 3D. Esto permite no desistir en su uso, ya que este

proyecto de investigación se centra en la interacción con modelos de

nubes de puntos en 3D, siendo posible el aprovechamiento de sus

principales funciones de traslación y rotación, mediante 6 grados de

libertad de movimiento. Además, como se describe anteriormente, el

dispositivo posee una serie de botones auxiliares y programables,

facilitándonos la incorporación de nuevas tareas o funciones para el

ratón 3D que nos sean de utilidad en nuestro propósito.




Tableta Digitalizadora (Wacom Intuos Pro L – South). Una tableta

digitalizadora o tablet gráfica es un periférico que permite al usuario

introducir gráficos o dibujos a mano, tal como lo haría con lápiz y papel.

También permite apuntar y señalar los objetos que se encuentran en la

pantalla. Consiste en una superficie plana sobre la que el usuario puede

dibujar una imagen utilizando el stylus (lápiz) que viene junto a la tablet.

La imagen no aparece en la tableta, sino que se muestra en la pantalla

de la computadora. Algunas tabletas digitalizadoras están diseñadas

para ser utilizadas reemplazando al ratón como el dispositivo apuntador

principal.

La primera tableta gráfica parecida a la tableta contemporánea y usada

para el reconocimiento de escritura a mano por un ordenador fue la

Stylator en 1957. Más conocida (y a veces confundida como la primera

tableta digitalizadora) fue la tableta RAND, también conocida como la

Grafacon (por Graphic Converter), introducida en 1964. La tableta RAND

tenía una cuadrícula de cables por debajo del pad que codificaban

coordenadas horizontales y verticales en una pequeña señal magnética.

Eventualmente, las tabletas fueron evolucionando y muchas compañías

se apuntaron a la formación del mercado actual encargado de su

producción. Hoy en día, las tabletas digitalizadoras quedan divididas en

2 grandes categorías:

o Pasivas. Las tabletas pasivas, fabricadas por Wacom, hacen uso

de inducción electromagnética, donde la malla de alambres

horizontal y vertical de la tableta operan tanto transmitiendo la

señal como recibiéndola. Este cambio se efectúa

aproximadamente cada 20 microsegundos. Usando la señal

electromagnética, la tableta puede localizar la posición del estilete

sin que éste llegue a tocar la superficie. El lapicero no se alimenta

con pilas, sino que la energía se la suministra la rejilla de la

tableta por el acoplamiento de la resonancia. Esta tecnología está




patentada por la empresa Wacom, que no permite que los

competidores la utilicen.

o Activas. Las tabletas activas se diferencian de las anteriores en

que el estilete contiene una batería o pila en su interior que

genera y transmite la señal a la tableta. Por lo tanto, son más

grandes y pesan más que los anteriores. Por otra parte,

eliminando la necesidad de alimentar al lápiz, la tableta puede

escuchar la señal del lápiz constantemente, sin tener que alternar

entre modo de recepción y transmisión constantemente, lo que

conlleva un menor jitter o retraso.

Las tabletas digitalizadoras, debido a su interfaz basada en un lápiz y la

habilidad de detectar presión, ángulo y su interacción con la tableta, son

utilizados ampliamente para crear gráficos por computadora,

especialmente gráficos en dos dimensiones. De hecho, muchos

paquetes de gráficos (GIMP, Photoshop y otros) son capaces de hacer

uso de la presión, ángulo y la rotación modificando el tamaño del pincel,

la forma, opacidad, color, u otros atributos basados en datos recibidos

de la tableta digitalizadora.

Ilustración 4.2 – Tableta digitalizadora (Wacom Intuos Pro L)




Aunque su uso este enfocado principalmente para el dibujado en 2D,

ya hemos visto que posee gran cantidad de actitudes y elementos que

podrían funcionar bien en 3D, para trabajar con modelos de nubes de

puntos. Tenemos una amplia gama de funciones con las que podemos

jugar, desde los ángulos que forma el stylus con la tableta, la presión

con la misma, el uso del borrador, hasta los botones auxiliares

programables al igual que pasaba con el ratón 3D. Debido a estas

características, su uso en nuestro experimento parece justificado e

interesante de cara al resultado final que se podría obtener con este

dispositivo.

Dispositivos HMD (HTC-Vive). Un visor o HMD (del inglés head-

mounted display), es un dispositivo de visualización similar a un casco,

que permite reproducir imágenes creadas por ordenador sobre una

pantalla muy cercana a los ojos o proyectando la imagen directamente

sobre la retina de los ojos. En este segundo caso el casco de realidad

virtual recibe el nombre de monitor virtual de retina.

Debido a su proximidad con los ojos, el casco de realidad virtual

consigue que las imágenes visualizadas resulten mucho mayores que

las percibidas por pantallas normales, y permiten incluso englobar todo

el campo de visión del usuario. Gracias a que el casco se encuentra

sujeto a la cabeza, éste puede seguir los movimientos del usuario,

consiguiendo así que éste se sienta integrado en los ambientes creados

por ordenador.

Según reproduzcan las imágenes sobre un ojo o sobre los dos, los HMD

pueden ser:

o Monocular: las imágenes sólo se reproducen sobre un ojo.

Técnicamente es un HMD, pero no es para realidad virtual. Es el

caso de las Google Glass.

o Binocular: las imágenes se reproducen sobre los dos ojos,

obteniendo así una imagen estereoscópica.




Por otro lado, cabe distinguir también:

o Cascos o gafas de realidad virtual: ocupan el campo de visión del

usuario de modo que no tiene percepción del entorno que lo

rodea, permitiendo así la completa inmersión de éste en una

realidad virtual, ya que sólo percibirá las imágenes creadas por

ordenador y reproducidas sobre la pantalla.

o Cascos o gafas de realidad aumentada o realidad mixta:

conocidos también como HMD óptico (u OHMD) permiten al

usuario ver todo el entorno que lo rodea e introducen en éste

objetos virtuales o información, produciendo así lo que se conoce

como realidad aumentada o realidad mixta.

Por último, según su operatividad, se pueden distinguir:

o Gafas de realidad virtual móvil: realmente son carcasas, que no

tienen pantalla propia ni procesador, sino que están preparadas

para albergar un teléfono móvil, en el cual se reproducirán las

imágenes. Ejemplos: Gear VR de Samsung, Cardboard de

Google, y muchas otras de distintos fabricantes.

o Gafas de realidad virtual sin procesador: incluyen pantalla propia

y sensores, pero se conectan a un aparato externo (típicamente

un ordenador personal) para recibir las imágenes. Ejemplos:

Oculus Rift, PlayStation VR, HTC Vive, etc.

o Gafas de realidad virtual autónomas: son las que incluyen todos

los componentes necesarios, como la carcasa, pantalla, sensores

y procesador. Ejemplo: Microsoft Hololens y otras en desarrollo

como las Project Alloy de Intel, las Daydream Standalone de

Qualcomm y Google, o las Exynos VR de Samsung.

Se ha podido comprobar que el campo de los dispositivos basado en

HMD abarca una cantidad enorme de dispositivos, formatos y

aplicaciones. Por lo cual, debido a que el grupo de investigación solo

tiene disponible el dispositivo HTC Vive como herramienta de




interacción, nos centraremos en sus características propias y como

estas encajarían en el proyecto.

Ilustración 4.3 – Head Mounted Display (HTC Vive)

Vive son unas gafas de realidad virtual fabricadas por HTC y Valve. El

dispositivo está diseñado para utilizar el espacio en una habitación y

sumergirse en un mundo virtual en el que se permite al usuario caminar

y utilizar controladores para interactuar con objetos virtuales.

HTC Vive tiene una frecuencia de actualización de 90 Hz. El dispositivo

utiliza dos pantallas, una para cada ojo, cada una con una resolución

de 1080x1200. Utiliza más de 70 sensores, incluyendo un giroscopio

MEMS, acelerómetros y sensores láser, y está hecho para funcionar en

un área de seguimiento de 4.6 metros por 4.6 metros, teniendo una

precisión de menos de un milímetro.

El sistema de seguimiento, llamado Lighthouse, fue diseñado por Alan

Yates y utiliza fotosensores para el seguimiento de los objetos. Para

evitar problemas de oclusión combina dos Lighthouse que barren todo

un espacio con láseres de luz estructurada.

La cámara frontal permite detectar cualquier objeto, estático o en

movimiento, en un área; Está función sirve también como sistema de

seguridad, mostrando el mundo real para evitar que los usuarios

choquen con objetos.




No cabe duda de la eficacia de este dispositivo para trabajar con

objetos en 3D (nuestras nubes de puntos), es una herramienta a la

orden del día, con gran capacidad de expansión y desarrollo. Existe

soporte para SteamVR, permitiendo a los desarrolladores crear

proyectos con Unreal Engine 4 para el HTC Vive con código nativo.

Resaltar, además, que los mandos de este dispositivo poseen

numerosos elementos de interacción (botones, un gatillo y hasta un

touchpad), facilitando la posibilidad de realización de un elevado

número de acciones distintas sobre las nubes de puntos.

Sin embargo, esta tecnología posee un precio elevado

(aproximadamente 600€) y nos obligaría a usar un software distinto al

pensado inicialmente (CloudCompare), con lo que habría que

reflexionar sobre su uso o no en el sistema a desarrollar.

Leap Motion. El controlador Leap Motion es un pequeño dispositivo

periférico USB, con funciones de sensor que toma los movimientos de

las manos y los dedos como entrada, de forma análoga a un ratón, pero

que no requiere contacto con las manos. Está diseñado para colocarse

en un escritorio físico, mirando hacia arriba.

Utilizando dos cámaras infrarrojas monocromáticas y tres LEDs

infrarrojos, el dispositivo observa un área aproximadamente hemisférica,

a una distancia de aproximadamente 1 metro. Los LEDs generan luz

infrarroja sin patrón y las cámaras generan casi 200 fotogramas por

segundo de datos reflejados. Esto se envía a través de un cable USB al

ordenador central, donde es analizado por el software Leap Motion

utilizando "matemáticas complejas" de una forma que no ha sido

revelada por la empresa, sintetizando de alguna manera los datos de

posición 3D mediante la comparación de las imágenes 2D generadas

por las dos cámaras. En un estudio realizado en 2013, la precisión

media general del controlador fue de 0,7 milímetros.




El área de observación más pequeña y la mayor resolución del

dispositivo diferencian el producto del Kinect, que es más adecuado para

el seguimiento de todo el cuerpo en un espacio del tamaño de una sala

de estar. En una demostración a CNET, se le mostró al controlador que

realizaba tareas como navegar por un sitio web, usar gestos de pellizco

a zoom en mapas, dibujar con alta precisión y manipular complejas

visualizaciones de datos 3D.

Ilustración 4.4 – Leap Motion

Este dispositivo es considerado aun joven por su reciente salida al

mercado, lo cual le proporciona una parte novedosa e innovadora en el

campo que vamos a trabajar. Su capacidad de “lectura de manos” deja

un sinfín de posibles gestos a realizar para controlar las nubes de puntos

a través de una nueva interfaz gestual, lo cual lo dota de un gran interés

en la investigación

Cabe destacar que existe una comunidad de desarrolladores detrás del

Leap Motion, que desde su página web ofrece una gran cantidad de

librerías para su desarrollo, escritas en todo tipo de lenguajes (C++,

Java, Python, Objective-C, etc). Esta capacidad de adaptación lo hace

muy atractivo para cualquier proyecto y además es posible desarrollar




con él mediante Unity o Unreal Engine, incluyendo SDK de desarrollo

hasta para Realidad Virtual.

No hay que olvidar que todo esto no es gratis, pero tampoco es un lujo,

siendo su precio otra de las características más llamativas que tiene, ya

que se puede adquirir desde unos 70€, creando la oportunidad de

obtenerlo para cualquier persona y dándole ventajas sobre sus

competidores en esta investigación.

4.1.3. Selección del dispositivo

Para la elección sobre el dispositivo con el que se trabajará, se creó un

pequeño informe (bajo criterio propio) en el que se tratan las principales

características de cada dispositivo, en relación a facilitar dicha tarea posteriormente

en la reunión. El informe en cuestión sería el siguiente:

Ratón 3D

o Ventajas:

Precio asequible (130€).

Gran precisión en movimientos de traslación y rotación.

Botones adicionales y programables.

o Desventajas:

Tecnología ya implantada en el campo.

Poco novedoso, posee cierta antigüedad.

A pesar de tener botones adicionales, pueden no ser

intuitivos.

Tableta digitalizadora

o Ventajas:

Precisión de posicionamiento y movimiento.

Amplia gama de utilidades (apuntar, borrar, dibujar,

orientaciones, presión, etc).

Botones adicionales y programables.

Sustitución intuitiva del ratón tradicional.

o Desventajas:

Precio elevado (458€).




Tecnología con cierta antigüedad.

Casco HMD

o Ventajas:

Tecnología actual, innovadora en el campo

Visión 3D, realizando un manejo realista de las nubes de

puntos (con las propias manos)

Mandos con un elevado número de mecanismos de

interacción (gatillo, botones, panel táctil).

Posibilidad de trabajar tanto sentado como de pie

moviéndose en una habitación.

o Desventajas:

Precio Elevado (600€).

Posibles mareos o náuseas.

El cableado puede ser molesto.

Leap Motion

o Ventajas:

Precio asequible (70€).

Tecnología actual, innovadora en el campo.

Amplio rango de un vocabulario gestual (interacción

intuitiva, adoptando gran cantidad de acciones posibles).

Capacidad de trabajo con cualquier software (librerías en

muchos lenguajes de programación disponibles).

o Desventajas:

Producto joven, en desarrollo actualmente.

Falta de precisión, mejorable por la compañía con el paso

del tiempo.

Mediante este esquema, me resultará más fácil la elección acerca de la

tecnología a proponer para usar en nuestra investigación.

En primer lugar, sería de utilidad reducir el número de dispositivos disponibles,

por lo cual nos disponemos a descartar alguno. Uno de los principios en los que se

basaba este proyecto, era en usar principalmente software libre, que evitará al

usuario invertir una gran cantidad de dinero para facilitar sus tareas. Esto centra




nuestra atención tanto el dispositivo HMD (HTC Vive) como en la tableta

digitalizadora (Wacom Intuos Pro L), de un precio bastante elevado.

Ambos dispositivos ofertan una gran cantidad de mecanismos de interacción

para nuestros modelos de nubes, sin embargo, es más probable que los ofrecidos

para tableta (señalar puntos, dibujar líneas de puntos, borrar puntos, etc) sean más

intuitivos para las tareas llevadas a cabo por un usuario normal, comparados con los

ofrecidos por las gafas de realidad virtual (presionar botones o un gatillo). En este

sentido la tableta tendría un punto a su favor.

Por otro lado, si hablamos de precio, según lo comentado anteriormente, la

tableta sería más asequible que el casco HMD; existiendo distintos gamas y

modelos de tabletas (siendo la nuestra una de precio elevado) que quizás sean igual

de adaptativas y a un menor precio. Las HTC Vive, sin embargo, sí que son una de

las gamas de gafas de realidad virtual de menor precio, por lo que sumaría otro

punto en contra.

Aunque si hablamos de la tecnología asociada a cada elemento, se puede ver

que la realidad virtual está a la orden del día, y la posibilidad de ver y trabajar con

elementos en 3 dimensiones ofrece una información más completa al usuario, en

contraste con la tableta, diseñada con el fin de trabajar en 2D.

El ultimo a punto a considerar, sería el software recomendado para trabajar en

conjunto con la herramienta (CloudCompare). La tableta digitalizadora no es algo

nuevo y con solo conectarla al ordenador ya podrás trabajar directamente con ella

en cualquier software, además de las librerías consolidadas que puede ofrecernos.

Sin embargo, en cuanto a realidad virtual, CloudCompare ofrece soporte para

tecnologías específicas, como es Oculus. Esto significaría tener que desarrollar otro

plugin que nos ayude a poder trabajar con HTC Vive, o directamente cambiar el

software usado por el recomendado, lo cual significaría un gran gasto de tiempo en

adaptación a CloudCompare o al nuevo software escogido (sumando el tiempo

empleado en la búsqueda asociada para la determinación de un software compatible

y que cumpla con nuestras expectativas).




Habiendo considerado todos estos puntos, la balanza se decanta claramente

por la opción de la tableta digitalizadora, teniendo que descartar el dispositivo HMD.

Sin embargo, no es una eliminación definitiva, ya que nos puede ofrecer un gran

paradigma de interacción novedoso, que, complementado con cualquiera de los

dispositivos anteriores, podría causar una gran revolución en el campo. Pero

simplemente no encajaría en este proyecto propuesto, siendo oportuno esperar a

que se consoliden tanto la tecnología propia, como el software de tratamiento de

nubes de puntos (CloudCompare) y otros dispositivos, como el Leap Motion, ambos

en desarrollo actualmente.

Pasando a la tecnología asequible, nos encontramos con el ratón 3D y el

dispositivo Leap Motion. Nos encontramos de nuevo, ante un enfrentamiento entre la

tecnología más actual (Leap Motion) y la más “tradicional” (ratón 3D).

Analizando un poco ambos dispositivos descubrimos que tienen muchas cosas

en común. Ambos son buenos candidatos a ser un complemento eficiente a la

elección anterior de la tableta digitalizadora, cosechando buenos resultados

trabajando en conjunto. Debido a esto, se tratarían de elementos pensados para ser

utilizados como la mano secundaria del usuario, sirviendo de complemento al

dispositivo actual. Además, pueden ofrecer una interfaz intuitiva para las tareas del

usuario, sumando también, su precio asequible.

En cuanto a las diferencias, mantienen un balance más o menos igualado, de

forma homogénea a lo anterior. La tecnología moderna que nos ofrece el Leap

Motion, nos abre un abanico de posibilidades en lo referente a una interfaz gestual,

pudiendo crear diversos gestos y hasta siendo una buena aplicación para ello un

traductor de lenguaje de signos. Sin embargo, en su punto actual, su punto débil

estaría en lo referente a la precisión, un campo en el que necesita mejorar y que

casualmente es el gran punto fuerte de su competidor, el ratón 3D, más consolidado

actualmente.

Esta igualdad, no consiguió hacerme decantar hacia ningún lado, por lo que se

optó por realizar un prototipado rápido en Unity 3D, para saber cuan problemática

podría ser la falta de precisión del dispositivo Leap Motion. Para ellos creamos un

escenario, que tiene integrado una carretera. Nuestra misión aquí será la de seguir




el camino, el cual contiene tanto rectas como curvas, por lo que deberemos

desplazarnos y girar para recorrerlo sin salirnos del mismo. Usaremos una

interacción mediante el ratón 3D y de igual forma, nos desplazaremos mediante

gestos reconocidos por el dispositivo Leap Motion.

Ilustración 4.5 – Camino a recorrer en el escenario de Unity

Una vez desarrolladas las pruebas con ambos dispositivos sacamos las

siguientes conclusiones:

Ratón 3D. Cabe destacar la gran precisión que posee, señalando, sin

embargo, que podría ser hasta negativa, ya que para poder controlarlo

adecuadamente sería necesario una gran experiencia con el mismo, ya

que al mínimo movimiento puede trasladarse o rotar en un sentido no

deseado, llegando incluso a convertir la tarea en algo muy tedioso, casi

dificultándola.

Leap Motion. Para su uso simplemente nos ha sido necesario la

utilización de un gesto, tan simple como señalar con el dedo índice hacia

dónde quieres ir en la escena. El dispositivo reconoce el gesto, así como

la dirección hacia donde apunta el dedo, girando el vector dirección de la

cámara hacia donde apunta, con un grado de rapidez dependiente del

ángulo que formen el vector dirección forward de la cámara y el vector

dirección del dedo índice. Al mismo tiempo avanzará hacia adelante,




siempre y cuando el gesto sea reconocido. Como primera prueba y al

tratarse de un gesto bastante fácil, se han obtenido unos resultados

bastantes favorables, dándonos a entender, que según todos los datos

que nos ofrecen a través de la librería de Leap Motion, podemos crear

un sinfín de gestos distintos, que nos posibilitarán la realización de un

gran número de acciones. Más adelante se entrará en detalle acerca de

estos datos que podemos obtener.

Ilustración 4.6 – Interacción entre Leap Motion y prototipo en Unity 3D

Finalmente, se decidió apostar por la nueva tecnología, intentando que el

proyecto sea innovador y obtuviera unos resultados significantes en los campos de

estudio a través del nuevo paradigma de interacción, descartando de una manera

definitiva al ratón 3D.




4.1.4. Reunión

En ella se expuso de forma clara y ordenada los dispositivos considerados y

estudiados para su uso en el proyecto, mostrando sus ventajas y desventajas.

Concluyendo con la transmisión de mi opinión acerca del potencial que podrían

demostrar tanto la tableta digitalizadora como el dispositivo Leap Motion en estos

campos.

Como apoyo a mi criterio, se les mostró el prototipo realizado comparando el

ratón 3D y el Leap Motion, quedando ellos gratamente sorprendido por la capacidad

que mostraba este último dispositivo.

Finalmente se optó por seguir con el desarrollo mediante la herramienta Leap

Motion. La herramienta sería manejada con la mano secundaria del usuario a través

de una interfaz gestual, por lo que se agregó una tarea de búsqueda de información

acerca de las normativas de HCI (Human-Computer-Interaction) actualmente

establecidas para una interfaz gestual.

Además, se concluyó con la posibilidad, en caso de quedar tiempo disponible,

de desarrollar otra herramienta mediante la tableta digitalizadora, de forma que

fueran acopladas al mismo tiempo y posibilitando el cambio de los tradicionales

teclado-ratón, de forma definitiva, por una interfaz más amigable, cómoda e intuitiva.

Se incluyó igualmente, como proyecto futuro, integrar la herramienta Leap Motion

con el casco HMD, sustituyendo uno de los mandos por los gestos captados por el

dispositivo, juntando las mejores características de cada dispositivo, siempre y

cuando estas 3 tecnologías (Leap Motion, casco HMD, CloudCompare) fueran

avanzando y creciendo, resolviendo sus problemáticas actuales.




4.2. Iteración 2 – Viabilidad del dispositivo

4.2.1. Requisitos

La iteración 2 se centra en un periodo de adaptación de la herramienta

escogida, en este caso Leap Motion, al software con el que trabajará (en un principio

CloudCompare).

Para ello se necesita la comprobación de la posibilidad de convivencia entre

ambos recursos, obteniendo los software asociados a cada elemento. En caso de no

poder trabajar juntos, obtendríamos un periodo en el que se podría dar media vuelta

y elegir un nuevo dispositivo o tratar de buscar un nuevo software que se adapte al

Leap Motion y tenga cierta popularidad dentro de las herramientas manejadoras de

nubes de puntos. Una detección temprana de incompatibilidad, y, por ende, un

cambio de enfoque en la investigación no producirá demasiada demora en el

desarrollo de la misma, por lo que esta fase del proyecto es importante realizarla

antes de entrar en otros objetivos como la búsqueda acerca del HCI asociado a la

herramienta Leap Motion.

Para seguir encaminando de forma adecuada la investigación, se determinaron

una serie de requisitos a cumplir en la misma:

Elección de un software compatible con el dispositivo.

Conseguir el software asociado al dispositivo y a la herramienta

manejadora de puntos.

Prototipo rápido usando el dispositivo en el software elegido,

consiguiendo unas nociones del resultado a obtener.

Búsqueda de estándares HCI (Human Computer Interaction) sobre la

forma de interacción del dispositivo elegido.

Finalmente podemos intuir que esta segunda iteración en el proceso de

realización de este TFG también tendrá una carga bastante teórica, más centrada en

el dispositivo seleccionado (Leap Motion) y como éste funciona, así como la

obtención de un software manejador de nubes de puntos compatible con el mismo.

Aunque se debe destacar la incorporación de una parte algo más práctica mediante




la implementación de un pequeño prototipo que nos pueda aportar una idea de cómo

quedará el resultado final del proyecto.

4.2.2. Leap Motion y CloudCompare

Habiendo tomado la decisión de realizar nuestro proyecto a través del

dispositivo Leap Motion, debemos escoger un software adecuado, tanto para el

manejo de nubes de puntos, como para la integración de una interfaz gestual

gestionada a través del Leap Motion.

A pesar de poseer experiencia desarrollando con Leap Motion junto a Unity 3D,

debido al primer prototipo que nos acercó a la elección del dispositivo, el primer

software a estudiar será el recomendado por la parte cliente. Dicho software es

capaz de realizar gran cantidad de operaciones diferentes con nubes de puntos, a

pesar de su juventud, como ya se explicó detalladamente en el apartado 2 de este

documento. Hablamos del software CloudCompare, el cual será tomado en

consideración en nuestro estudio con el fin de establecer qué facilidades nos aporta

en la integración de nuevas herramientas en su propio software.

CloudCompare es un proyecto de software abierto, indicando en su página web

un enlace hacia un proyecto del dominio de GitHub, donde se encuentra publicado

todo el código perteneciente al software. Por lo cual es deducible la posición que

adopta el creador (único) de CloudCompare acerca de nuevas aportaciones de

cualquier usuario de la web.

Poseemos total libertad para aportar algo nuevo al software, con ciertas

condiciones, como no cambiar nada del código central que rige el producto. Además,

existe un foro dedicado al software en el que se puede aportar o requerir cualquier

información, como sería el caso de cambiar el propio código central. De hecho, en

cierta parte del proyecto se le sugirió al creador de CloudCompare realizar un

cambio en el código central para facilitar la integración de nuestra herramienta u

otras posibles y el mismo autor accedió a nuestra petición cambiando el software

para su mejor evolución.

La inexistencia de obstáculos por parte del autor a colaborar con su proyecto y

su total apoyo determinan en gran medida la posible integración entre las dos




herramientas. Sin embargo, debemos informarnos de cómo colaborar, ya que según

se ha mencionado existen una serie de requisitos en las aportaciones a realizar para

el proyecto.

Investigando la herramienta en GitHub podemos descubrir que la integración

en CloudCompare se realiza a través de plugins, los cuales representan una serie de

herramientas, algoritmos u otros elementos (en nuestro caso una interfaz) que no

vienen activados de serie como herramienta propia del software, sino que, si se

requiere de ellos, deben ser buscados en el apartado de plugins del programa y

seleccionar que plugins se desea utilizar.

Ilustración 4.7 – Selección y activación de un plugin en CloudCompare

Proceder de una forma correcta en el desarrollo de contenido adicional en

CloudCompare es sencillo, gracias a la localización de un apartado en el proyecto de

GitHub, el cual hace referencia a todas las pautas que se deben seguir para la

creación de un nuevo plugin en el software, si se desea que sea incluido en futuras

actualizaciones formando parte del mismo. Además de estas normas de estilo para

plugins, también debe aportar una funcionalidad coherente con el software, robusta y

válida, siendo revisada por el autor de CloudCompare.

Un último requisito sería necesario para la validación de ambas herramientas

(Leap Motion y CloudCompare) como las definitivas para nuestro proyecto y poder

comenzar con toda la parte de desarrollo de la herramienta que nos generará el




nuevo paradigma de interacción a partir de una interfaz gestual: conseguir el

software asociado a cada herramienta.

Leap Motion. Se trata de la parte más fácil de esta tarea, debido a que

únicamente es necesario navegar hacia la página web del dispositivo y

acceder a su sección de “Developers” (desarrolladores). Desde ahí

podemos descargar 2 tipos de SDK (Software Development Kit), uno

especializado en aplicaciones de realidad virtual y otro relacionado con

aplicaciones sin requisitos especiales, que incluye una gran variedad de

librerías en distintos lenguajes para su desarrollo.

Ilustración 4.8 – Librerías desarrolladas para Leap Motion

Obtendremos un archivo comprimido tipo ZIP, que contendrá todo lo

necesario para poder desarrollar en el lenguaje que necesitamos, en este

caso, ya que CloudCompare está desarrollado en C++, necesitaremos de

dicha librería. Además, será necesaria la instalación de drivers para el

sistema operativo que se esté utilizando, a partir de un archivo ejecutable

contenido también en la carpeta.

CloudCompare. Aunque obtener el código que conforma a CloudCompare

es fácil (solo tenemos que dirigirnos a su proyecto en GitHub y descargar

todo el proyecto), su preparación para trabajar con él puede llegar a ser

bastante compleja.

En primer lugar, para obtener una versión funcional y básica de

CloudCompare, debemos obtener otro software dependiente del mismo,

como lo es Qt. Qt puede ser descargado fácilmente en su propia web,




mediante la versión Open Source, eligiendo únicamente los paquetes que

nos interesen. Al utilizar Visual Studio en nuestro proyecto como IDE

(Integrated Development Environment), requeriremos de una versión de Qt

compatible con nuestra versión de Visual Studio, además de con nuestra

arquitectura de nuestro ordenador. En nuestro caso, descargaremos lo

necesario para Microsoft Visual Studio 17, con arquitectura de 64 bits.

El último paso a realizar será generar un proyecto valido para nuestro

entorno de desarrollo a partir del código de CloudCompare, el cual está

preparado para que a partir de un software ajeno (C-Make), se pueda

generar un proyecto valido para Visual Studio. Mediante C-Make podemos

obtener distintas versiones de CloudCompare, dependiendo de las

características o plugins que se requieran agregar. Únicamente se

instalará el plugin “QDUMMY_PLUGIN”, el cual es un ejemplo de cómo

realizar un plugin válido en CloudCompare y nos resultará de ayuda en un

futuro cuando se comience a desarrollar nuestro plugin que sirva de

interfaz gestual.

Ilustración 4.9 – Generación del proyecto CloudCompare a través de C-Make

Para facilitar esta tarea se nos proporciona otra página de ayuda en

GitHub describiendo como realizar este proceso, que puede llegar a ser

bastante tedioso.




4.2.3. Interfaces Gestuales (estudio HCI)

La obtención de una buena interfaz basada gestos, requiere de un estudio de la

situación actual en cuanto a las normativas de HCI en este campo. Tras una extensa

búsqueda acerca de la interacción mediante gestos en campos 3D o incluso en

realidad virtual, se determina la inexistencia de una gran cantidad de información

que nos pudiese ayudar, probablemente debido a que es un mecanismo que ha sido

poco explotado y actualmente está más en desarrollo.

Sin embargo, la mayoría de los artículos de investigación hablan sobre el

principal problema que pueden tener las interfaces basadas en gestos, y se trata de

la fatiga causada por los gestos a realizar, por su dificultad o por la realización de

posturas incorrectas.

La investigación sufre así una vuelta de tuerca hacia la búsqueda de gestos

diseñados por los expertos en estos campos, que podremos implantar y que nos

ayudarán a tomar ideas sobre cómo deben ser para, además, poder incluir otros

propios gestos de nuestra invención, que ayuden a que las tareas a realizar con

nubes de puntos sean lo más intuitivas posibles.

Ilustración 4.10 – Clasificación de gestos por fatiga generada en el usuario

(Rempel, D., Camilleri, M., & Lee, D, (2015)




El estudio sirvió de gran ayuda, al encontrar una de las principales claves en el

diseño de gestos para nuestros propósitos. Se encontraron varios vocabularios de

gestos realizados por expertos, que servirán como inspiración y que se detallan en

las siguientes ilustraciones:

Ilustración 4.11 – Vocabulario de los gestos principales en un programa

(Nielsen, M., Störring, M., Moeslund, T., & Granum, E, 2014)

Ilustración 4.12 – Otros vocabularios de gestos diseñados por expertos.

(Steinicke, F., Ropinski, T., & Hinrichs, a. K.)




4.2.4. Diseño de un vocabulario de gestos

Cuando hablamos de gestos intuitivos, intuitivo es un término peligroso. El

hardware NUI (Natural User Interface), como el Leap Motion Controller, a menudo

promete interacciones "intuitivas"; pero a la hora de la verdad, pocos desarrolladores

o diseñadores pueden articular lo que significa ser intuitivo. Cualquiera que haya

utilizado una interfaz de control de movimiento mal diseñada puede decir que el

simple uso de los movimientos del cuerpo para controlar el software no produce una

experiencia "intuitiva" o "natural". Es mejor desglosar el término y definir lo que

realmente significa ser intuitivo.

Cuando se describe una experiencia intuitiva, a menudo se piensa en que

alguien puede "simplemente sentarse y empezar a usarla". Estas interfaces se

pueden aprender. Tienen las instrucciones, los tutoriales, los medios visuales y la

retroalimentación correctos para ayudar a determinar cómo usarlos. Para ser

intuitiva, una interacción debe ser aprendible.

Una vez que a alguien se le ha dicho, mostrado o descubierto cómo funciona

algo, debe entender por qué funciona de la manera en que funciona. La interfaz

ayuda a construir un modelo mental de cómo las acciones encajan en el sistema.

Debería ser fácil explicárselo a alguien más. La comprensibilidad es crítica para una

experiencia intuitiva.

Lo que realmente estamos describiendo aquí es un hábito. Formamos hábitos

con el tiempo, aprendiendo y entendiendo cómo funciona algo, y haciéndolo parte de

nuestra rutina. Cuando aprendemos a conducir por primera vez, se requiere

esfuerzo, pero es aprendible y comprensible, y finalmente se convierte en hábito.

Para la mayoría de los conductores diarios, el acto de conducir, y los controles de un

coche, son intuitivos; conducir se convierte en algo casi instintivo.

Cabe señalar que lo que es ‘intuitivo’ para una persona puede ser totalmente

extraño para otra. Un adolescente nacido en el año 2000 probablemente no ha

usado un Compact Disc, ni siquiera ha oído hablar de un Disquete. Estas metáforas

no van a ser intuitivas para ellos, ya que esas mismas metáforas son una segunda

naturaleza para una audiencia mayor. Cuando se diseña para una interacción




intuitiva, hay que conocer para quién estás diseñando; de lo contrario, tu habilidad

para crear una experiencia intuitiva se reducirá a pura suerte.

Para ser intuitivas, nuestras interfaces deben ser aprendibles, comprensibles y

habituales. Más allá de la intuición, hay una serie de factores que impactarán

drásticamente en la experiencia de uso de la aplicación. Cosas como la ergonomía,

el diseño de la información y la detección fiable de gestos pueden hacerlo o no.

Una de las primeras cosas que hay que preguntarse es en qué entorno se va a

utilizar. A las personas no nos gusta mantener los brazos en alto por largos períodos

de tiempo; y aunque somos muy hábiles en el uso de las manos, no podemos

mantenerlas perfectamente inmóviles, o hacer traducciones geométricas perfectas.

Tendemos a movernos y a hacer gestos de diferentes maneras. A menudo

cambiamos la eficiencia por comodidad, o viceversa, dependiendo de nuestra

situación; y rara vez nos tomamos el tiempo para optimizar activamente nuestros

espacios físicos. En otras palabras, usualmente tomamos el camino de menor

resistencia.

La API Leap Motion viene con unos pocos gestos incorporados, que se pueden

utilizar eficazmente en las situaciones adecuadas. Aun así, probablemente habrá

que personalizar un conjunto propio de interacciones mezclándolas y combinándolas

con algunos de los gestos de la API incorporados, quizás de formas que no estaban

pensadas originalmente. En el proceso de construcción de aplicaciones y varios

experimentos de UX en Leap Motion, se han creado un conjunto útil de heurísticas

para evaluar críticamente nuestros diseños de gestos e interacciones.

Consistencia del seguimiento. Algunos movimientos y poses son

seguidos más consistentemente que otros. Además de observar el

movimiento en el visualizador de diagnóstico, la API de Leap Motion

expone un nivel de "confianza en el seguimiento" para mostrar cuán

preciso cree que es el seguimiento en ese momento.

Facilidad de detección. Algunos movimientos están muy bien definidos,

otros son mucho más borrosos. Desde el punto de vista de la producción,

¿cuán difícil es detectar este movimiento con un alto grado de precisión

tanto en términos de falsos positivos como de falsos negativos?




Oclusión. Dadas las limitaciones del dispositivo, ¿esta interacción tiene

una alta probabilidad de causar oclusión? Por ejemplo, una interacción en

la que alguien puede alcanzar una mano a través del campo de visión del

dispositivo tiene una alta probabilidad de causar que el brazo o la manga

de la camisa ocluyan la mayor parte de la mano, o una mano sobre la otra

puede causar que el controlador pierda el hilo de la mano superior. El

seguimiento está mejorando muchos de estos problemas, pero sigue

siendo algo a considerar en este desarrollo de aplicaciones.

Ergonomía. Dadas las limitaciones del cuerpo humano, el caso de uso

previsto y el entorno para la interacción, ¿cuáles son las preocupaciones

ergonómicas? ¿Puede alguien realizar esta interacción mientras está

relajado, o crea una tensión innecesaria? ¿El uso repetido se vuelve

estresante? ¿Requiere la interacción un movimiento antinatural?

Transiciones. Dada la interacción completa establecida en una aplicación,

¿cómo pasa esta interacción a otras? ¿Las transiciones son claras y

fáciles de aprender? ¿Son fáciles de detectar?

Retroalimentación. ¿Esta interacción se presta bien para tener una

buena retroalimentación de la interfaz de usuario? La retroalimentación

puede tomar muchas formas; la retroalimentación visual, auditiva o háptica

es la más común. La falta de una retroalimentación adecuada en la

interfaz de usuario puede hundir una interacción que de otro modo estaría

bien diseñada.

Las probabilidades de que algo vaya a salir mal dependen directamente de la

cantidad de gestos distintos que tenga que reconocer el dispositivo para las distintas

acciones. Si tiene disponible demasiadas opciones simultáneas, es probable que

alguien que utilice la aplicación se confunda y tenga una buena posibilidad de

cometer un error.

Se puede recurrir al diseño móvil para que nos ayude con esto. Debido a las

limitaciones de la plataforma móvil, cada pantalla ofrece algunas opciones. Significa

que una pantalla puede tener unas pocas acciones y una menor probabilidad de que

alguien se equivoque. La idea de esto es reducir la posibilidad de hacer una acción

equivocada a expensas de reducir la funcionalidad detrás de múltiples acciones.




4.2.5. Prototipo de plugin con Leap Motion en CloudCompare

La realización de un prototipo de plugin en CloudCompare mediante el uso de

Leap Motion era una tarea obligada para poder mostrar a los tutores como podría

ser el resultado final de esta investigación.

Según lo comentado anteriormente, la convivencia de una gran cantidad de

gestos reconocibles al mismo tiempo por el dispositivo Leap Motion nos llevaría a

situaciones de desastre en las que se cometerían más errores que aciertos a la hora

de trabajar con él. Es por ello por lo que surge la idea de dividir nuestro plugin en

distintas herramientas, simulando una máquina de estados, en las que se transitará

de un estado a otro mediante la realización de un gesto, y solo se podrá realizar las

acciones disponibles en dicho estado.

Una vez situados en un estado concreto, siempre y cuando el dispositivo nos

reconozca el gesto, cambiaríamos de estado, proporcionándonos el sistema una

respuesta de retroalimentación, mediante la realización de la acción asociada al

gesto. Finalmente se volvería al estado original.

Cabe destacar, que se podrían crear y utilizar acciones que puedan llevarse a

cabo en cualquier estado, estando siempre disponibles. Así, cada estado realmente

tendría una lista limitada de gestos que pueden realizarse y a los que el dispositivo

prestará especial atención para su reconocimiento.

Finalmente, obtendríamos un diagrama de estados parecido al que se mostrará

a continuación, el cual representa un plugin genérico de Leap Motion, delimitado con

4 herramientas, que podrían reducirse o ampliarse en número, en el momento de

desarrollo, según las acciones que se hayan acordado para realizar mediante el uso

de gestos. En este prototipo se desarrollará dicho gesto que nos permita pasar de un

estado a otro como se indica en el diagrama.

Ilustración 4.13 – Máquina de estados del plugin de Leap Motion en Cloud Compare

En cuanto al diseño de la interfaz propia del plugin, tomaremos como ejemplo

alguno de los plugins ya desarrollados que nos pueda servir en este proyecto,

dividiéndose en distintas herramientas (o estados) que podrán ser accesibles

mediante gestos para poder ser utilizados, según los requisitos mencionados

anteriormente.

Ilustración 4.14 – Prototipo de interfaz dividida en herramientas

4.2.6. Arquitectura de Leap Motion

El dispositivo utiliza el sistema de coordenadas cartesianas, en donde, desde la

posición del usuario, el eje Y tiene valores positivos hacia arriba, el X hacia la

derecha y el Z hacia el usuario.

Ilustración 4.15 – Sistemas de coordenadas del dispositivo Leap Motion




La API mide magnitudes físicas con las siguientes unidades:

Distancia – Milímetros (mm)

Tiempo – Microsegundos (µs)

Velocidad – Milímetros / segundo (mm / s)

Ángulos – Radianes

A continuación, se procede a analizar los componentes principales de esta

versión. Para ello iremos viendo los objetos principales que el dispositivo puede

rastrear, junto con el modelo anatómico que se usa para identificar cada uno, y

también analizaremos las clases principales que se describen en la API.

El principal objeto es Controller, que se encarga de hacer de interfaz entre la

aplicación que desarrollemos y el dispositivo. A continuación, podemos ver los

métodos que contiene:

Ilustración 4.16 – Clase Controller del API de Leap Motion

El que más nos interesa de esta clase es el método frame (), a través del cual

podemos acceder al objeto Frame que deseemos; por defecto, al último que ha

llegado desde el dispositivo. Además, como se puede observar en uno de los

métodos constructores, se puede asociar un objeto de tipo Listener al objeto

Controller para poder estar pendientes de los eventos que se produzcan en dicho

Controller.




En la siguiente imagen vemos cuáles son los eventos que se producen en el

Controller y pueden ser atendidos por el objeto Listener:

Ilustración 4.17 – Clase Listener del API de Leap Motion

Otro método interesante —al igual que en el caso de Controller— es el

onFrame (), evento que se produce cada vez que el dispositivo captura una imagen.

Este es el evento principal, ya que dentro de este se pueden implementar todas las

acciones que queremos hacer sobre los objetos que más adelante veremos (manos,

dedos, gestos, etc.).

Así pues, hay dos modos de acceder a un objeto Frame:

Desde el objeto Controller, a través del método frame ().

Desde el objeto Listener, a través de los eventos que se van disparando.

Usar un modo u otro dependerá de si queremos analizar o no todos los frames

que lleguen desde Controller. Si queremos analizarlos todos, accederemos a la

información del objeto Frame a través de Listener; pero si, por el contrario,

queremos analizar un objeto Frame cada cierto tiempo, se accederíamos desde el

objeto Controller.

A continuación, podemos ver un diagrama de la relación entre el objeto Frame

y los que se puede acceder a través de él:




Ilustración 4.18 – Objetos disponibles desde la clase Frame del API de Leap Motion

Como vemos, el objeto Frame es la raíz de todos los datos de los objetos que

analiza Leap Motion. Frame nos da la posibilidad de acceder a todas las clases List,

a partir de las cuales se puede acceder a una lista de objetos del mismo tipo y que

aparecen en cada Frame.

Dentro del objeto Hand, podemos acceder a una lista de objetos Finger para

cada Hand, en la que podemos acceder a información de cada objeto Finger que

aparece en el frame y que forma parte del objeto Hand. A su vez, cada objeto de tipo

Finger contiene objetos de tipo Bone. Además, como podemos observar, los objetos

Finger y Bone son de tipo Pointable.

A continuación, podemos ver un esquema de las partes que componen el

objeto Hand con su representación anatómica:

Ilustración 4.19 – Representación de los elementos de una mano según el API de Leap Motion




Podemos ver la información principal que se puede extraer de cada objeto que

depende de Hand en las siguientes listas:

Información principal incluida en el objeto Hand:

o Posición y velocidad de la palma.

o Dirección y vectores normales.

o Base ortonormal.

Información incluida en el objeto Finger.

o Posición y velocidad de la punta.

o Vector de dirección.

o Base ortonormal.

o Anchura y longitud.

Información incluida en el objeto Bone:

o Posición de la articulación.

o Base ortonormal.


Información incluida en el objeto Arm:

o Posiciones de muñeca y codo.


o Base ortonormal.


Información incluida en el objeto Pointable Tool:

o Posición y velocidad de la punta.


o Base ortonormal.


La siguiente clase a analizar es HandList, que es la encargada de almacenar

los objetos Hand:




Ilustración 4.20 – Clase HandList del API de Leap Motion

Como se puede observar, a través de esta clase se puede extraer un objeto de

tipo Hand mediante el método get (). Además, se puede saber cuál es el objeto

Hand que está más cerca del dispositivo, más a la izquierda o más a la derecha.

Como ya se ha dicho, HandList provee una lista de objetos Hand que aparecen

en el Frame que se está analizando. Vamos a ver el objeto Hand:

Ilustración 4.21 – Clase Hand del API de Leap Motion




Como podemos ver, a través de esta clase se puede extraer muchísima

información referente al objeto Hand. También se puede acceder a los objetos

Finger y Arm que dependen de cada objeto Hand en concreto. Es decir, podemos

extraer objetos de tipo dedo y antebrazo de cada mano que aparece en la imagen.

Para obtener los dedos, se hace uso del objeto Finger, objeto que hay que

extraer de la clase FingerList:

Ilustración 4.22 – Clase FingerList del API de Leap Motion

Como vemos, esta clase es muy parecida a HandList, ya que es una clase que

contiene objetos de tipo Finger. Además, también se puede extraer información del

objeto Finger más cercano al dispositivo, ya sea a la derecha o a la izquierda. Por lo

tanto, dentro de la clase FingerList aparecen los objetos Finger:

Ilustración 4.23 – Clase Finger del API de Leap Motion

Como se puede ver, también se pueden extraer de cada objeto Finger

diferentes objetos Bone. Estos objetos representan los puntos que definen al dedo

en el modelo y que, en la anatomía definida en la API, estarían representados de la

siguiente manera:




Ilustración 4.24 – Distribución de los huesos de la mano según la API de Leap Motion

A continuación, podemos ver el objeto Bone:

Ilustración 4.25 – Clase Bone del API de Leap Motion

Como se puede observar en el diagrama de la clase, se puede extraer bastante

información de cada objeto de tipo Bone. Gracias a este nuevo modelo matemático,

se puede determinar mejor la posición de cada objeto y las direcciones, y esto dio

lugar a la aparición de un nuevo objeto, el objeto Arm:

Ilustración 4.26 – Clase Arm del API de Leap Motion

Además, la API también nos provee de una serie de objetos que ayudan a

poder extraer los datos que necesitemos, como por ejemplo el objeto Vector.




Como vemos, el dispositivo Leap Motion cuenta con una API muy extensa y

optimizada para la extracción de datos característicos de las partes que forman una

mano. Por lo tanto, es un dispositivo óptimo para nuestro proyecto, en el que vamos

a analizar el comportamiento de las manos al realizar diferentes signos.

4.2.7. Diseño de las herramientas del plugin.

Para el diseño de las clases que representan herramientas, está claro la

utilización de una relación de herencia con polimorfismo. Se ha construido un

diagrama UML que recoja las características principales de las herramientas, que

pasaran a ser explicadas a continuación.

Ilustración 4.27 – Diagrama UML que representa a las herramientas del plugin.

Leap::Listener. Clase que “escucha” al dispositivo Leap Motion,

mediante la función “addListener”, permitiéndole transmitir las funciones

asociadas al dispositivo a su propietario. Del mismo modo, puede

eliminar mediante “removeListener”.




LeapMotionTool. Representa una clase genérica de una herramienta

perteneciente al plugin, que hereda de la clase Listener y posee un

controlador (Leap::Controller), a partir de los cuales se les notifica de

cada función emitida por el dispositivo, por ejemplo, las utilizadas en

nuestro proyecto, “onFrame” y “onConnect”

ccTool. Representa una clase genérica de una herramienta para

CloudCompare, la cual tiene acceso a las clases principales del

software, ccGLWindow, que controla la ventana de visualización del

software y ccMainAppInterface, que controla la aplicación principal.

Además, es avisada por la clase principal de cuando es activada o

desactivada mediante los métodos “toolActivated” y “toolDisactivated”

Herramienta. Representa una herramienta específica del plugin, la cual

será avisada cuando es creada, pudiendo registra un Listener que le

proporcione información de cada frame, gracias a sus relaciones de

herencia.

ccLeapMotion. Clase principal del plugin, el cual se encargará de avisar

a todas sus herramientas asociadas, de cuando son activadas y

desactivadas para controlar sus funcionalidades.

Tendríamos a grandes rasgos, la representación interna de nuestro plugin, así

como de cada herramienta asociada al mismo.

Para este prototipo, se desarrolló la función de “cambiar de herramientas”, que

en sí es una clase del tipo Herramienta y que serviría para el cambio de estados

mencionados anteriormente. No se entrará ahora en detalles de la implementación

del gesto, ya que se explicará posteriormente en una sección dedicada a ello.

Tomando en cuenta las consideraciones explicadas, se debe de proporcionar

una retroalimentación al usuario cada vez que realice el gesto de manera adecuada.

Esto se tratará de forma visual en la interfaz que hemos construido, iluminando la

herramienta activada y apagando la herramienta anterior, tras la realización del

gesto.




Ilustración 4.28 – Retroalimentación al cambiar de herramienta

4.2.8. Reunión

En ella se expuso el prototipo desarrollado de plugin para el software

CloudCompare mediante el dispositivo Leap Motion. Además, se explicó todo el

proceso de investigación, así como todas las decisiones tomadas a partir de ella.

Los tutores dieron el visto bueno a todo el trabajo realizado, aceptando tanto el

dispositivo, como el software y el tipo de plugin desarrollado, sin necesidad de

aportar nuevas sugerencias para su desarrollo, por lo que se procederá a comenzar

con la tercera iteración desarrollando las funcionalidades básicas para el manejo de

nubes de puntos.




4.3. Iteración 3 – Funciones básicas

4.3.1. Requisitos

Durante la iteración 3 se procederá a un desarrollo más práctico en el proyecto,

realizando las primeras interacciones con nubes de puntos mediante el dispositivo

Leap Motion, a través de gestos y consiguiendo realizar algunas acciones básicas

sobre ellas.

Al querer probar la eficacia del dispositivo, demostrando un buen

funcionamiento en el campo a la vez que se va aprendiendo a manejarse con él, no

es necesario la implementación de funciones que pueden llegar a ser bastante

complejas en el entorno de las nubes de puntos, sino que se empezará a trabajar

con las transformaciones geométricas básicas que pueden realizarse con cualquier

objeto 3D, como lo son nuestras nubes de puntos.

Los objetivos básicos a realizar en esta etapa del proceso de investigación

serán:

Cambiar de herramienta. No es una transformación básica de objetos

3D, pero sí que va a ser una función muy necesaria según lo establecido

en el diseño del plugin.

Seleccionar un punto en la nube de puntos. Tampoco se trata de una

transformación, pero sí que es una función muy elemental a la hora de

trabajar con nubes de puntos.

Trasladar una nube de puntos.

Rotar una nube de puntos

Escalar una nube de puntos

Como se puede observar, en esta parte del proyecto, se completa la transición

iniciada en la iteración anterior de un desarrollo teórico a uno práctico, siendo las

funciones principales la búsqueda de gestos que se puedan adaptar de forma

adecuada a la tarea a realizar, el reconocimiento de los mismos mediante el

dispositivo Leap Motion y finalmente, la realización de la acción ejecutada dentro de

CloudCompare, con la correcta retroalimentación generada de forma visual en la

ventana de visión del software.




4.3.2. Cambiar herramienta

En este apartado, al ser el primer gesto que se diseñará para ejecutar una

acción en CloudCompare, se explicará de forma genérica qué pasos deben de

realizarse para poder desarrollarse de forma adecuada, sirviendo de ejemplo para

todos los demás gestos que serán creados posteriormente. Podemos dividir este

proceso en una serie de etapas:

Diseño del gesto. Debemos tener muy presente qué acción va a

realizarse a la hora de ejecutar nuestro gesto. En base a ella, hay que

ser capaz de crear un gesto (o utilizar uno prediseñado) que resulte

“intuitivo” de realizar. Sin embargo, este es uno de los varios requisitos a

tener en cuenta como ya se vio. Se debe respetar la fatiga generada al

usuario en la realización de un gesto, intentando que sea la mínima

posible. A partir de esto, para nuestra utilidad, la cual será realizar un

cambio de herramienta o de elemento seleccionado en un menú, y

revisando las políticas de HCI anteriores, podríamos pensar que un buen

gesto adecuado a la tarea podría ser el siguiente:

Ilustración 4.29 – Gesto “cambiar de herramienta” con movimiento de arco

En principio, parece una buena acción, en el que solo tienes que abrir

la mano y desplazarte sobre el eje X, formando un pequeño arco,

debido a la tendencia del ser humano de desplazarse realizando arcos

en sus movimientos. Aunque el gesto parezca perfecto, se necesita

considerar un factor más, ¿qué facilidad tendrá el dispositivo Leap




Motion para reconocer dicho gesto, según su arquitectura interna? Esta

es una pregunta que se debe hacer siempre que se diseñe un gesto, ya

que como en este caso, al dispositivo le costaría de más esfuerzo

reconocer un movimiento curvo, incrementando las posibilidades de

conseguir un error a la hora de realizarlo. Una alternativa mejor para

Leap Motion, sería el cambio de la trayectoria curva por una trayectoria

recta, en el eje horizontal del dispositivo, lo cual favorecerá el

reconocimiento del gesto, a pesar (quizás) del aumento de la fatiga.

Ilustración 4.30 – Gesto “cambiar de herramienta” con movimiento recto.

Se debe buscar un compromiso entre las facilidades del usuario y del

dispositivo para la creación de un gesto lo más eficiente posible para

ambos.

Detección del gesto. Una vez obtenido el gesto a realizar, debemos

codificar el reconocimiento de éste, mediante la librería que nos

proporciona Leap Motion. Siempre que se desee un movimiento lo más

suave y preciso posible, es de recomendación analizar cada frame

enviado por el dispositivo, por lo que se usará la función “onFrame”, ya

mencionada anteriormente, que nos proporcionara cada imagen

capturada por el Leap Motion. Para el análisis de estos frames, lo más

usual es seguir una serie de pasos, definidos en el siguiente diagrama

de actividad:




Ilustración 4.31 – Diagrama de actividad sobre el análisis de un frame de Leap Motion.

Como se puede observar, lo primero que se debe realizar es el registro

de un “Listener” que nos proporcionará la llamada a la función anterior y

con ella, la obtención de cada frame.

Una vez tenemos la imagen, debemos comprobar que se ha detectado

la mano deseada para la realización del gesto (en nuestro caso

normalmente será la secundaria).




A partir de esta mano comprobaremos que no se está realizando otro

gesto con el que pudiera surgir un conflicto (al poder ser parecidos) y

que además tenga prioridad sobre el mismo.

Si nada de esto ocurre, solo nos quedaría comprobar que el gesto se

está realizando de forma correcta (mediante las comprobaciones

necesarias), realizando la función que sea necesaria en el programa

CloudCompare o no haciendo nada (o proporcionando un feedback) si el

gesto se estuviese realizando de forma incorrecta.

En el caso concreto del gesto de cambiar herramienta, comprobaremos

frame a frame que la mano este totalmente extendida, comprobando que

todos los dedos estén extendidos (a excepción del pulgar, que todavía

en esta versión no tiene un buen reconocimiento, probablemente por

problemas de oclusión con los otros dedos) y que la normal de la mano

apunte hacia el eje X.

Siempre que esto pase tomaremos la posición absoluta de la mano en el

eje X y a partir de su posición anterior, calcularemos una media de

desplazamiento, si esta se mantiene superior a un umbral durante varios

frames, se dará el gesto como reconocido y se pasará a realizar la

función en CloudCompare.

Ilustración 4.32 – Reconocimiento del gesto “cambiar herramienta”

Acción en CloudCompare. El último paso por realizar sería la ejecución

de la propia acción dentro del software para que se produzcan los

cambios referidos al gesto, debiéndose crear una retroalimentación (del

estilo visual normalmente) que ayude al usuario a percibir que está




realizando el gesto y el sistema funciona de forma correcta. En el caso

del cambio de herramienta ya se pudo apreciar la retroalimentación en la

iteración anterior, en concreto en la ilustración 4.28.

En lo referido a CloudCompare, el plugin está conformado por una serie

de herramientas con un índice, que iluminarán su botón si su índice

coincide con el seleccionado en el momento actual. Para producirse el

cambio de herramienta simplemente avanzaría o retrocedería el índice

una posición (de forma circular, pasando del ultimo al primero y

viceversa).

4.3.3. Seleccionar en punto de la nube

Esta tarea en sí no aporta gran información en el tratamiento de nubes de

puntos, sin embargo, puede servir como base para la realización de tareas más

complejas, por lo que su utilización está justificada. Al igual que antes seguiremos su

proceso de creación en las 3 fases:

Diseño del gesto. La búsqueda de un gesto que pueda representar esta

acción presenta una baja dificultad, ya que simplemente bastaría con

señalizar con un dedo, en este caso será el índice hacia donde se desea

apuntar.

Ilustración 4.33 – Gesto “marcar punto en nube”

Este gesto representará un “ratón virtual” de forma que la posición del

dedo índice será la que le indique la posición al cursor del ratón, que se

desplazará según se vaya moviendo la mano. En el recorrido, el cursor




irá seleccionando los puntos de la nube más cercanos a su posición

actual, resaltando el punto seleccionado y mostrando una etiqueta con

sus coordenadas absolutas. Hay que tener en cuenta que para hacer

todo esto posible, el gesto deberá mantenerse mientras se desplaza la

mano.

Destacar que este gesto, capaz de controlar el ratón mediante la mano

“señalando”, puede dar mucho de sí, pudiendo adquirir gran

importancia en el software ya que se podría usar como el ratón

propiamente dicho, acompañado de otros gestos para realizar clic,

selección u otras funcionalidades.

Detección del gesto. La detección del gesto tampoco es muy compleja,

simplemente tenemos que verificar que el dedo índice este extendido,

mientras los demás no lo estén (sin contar el pulgar) y que además la

normal de la palma de la mano apunte hacia el eje Y negativo, dándole

una dirección al gesto para que no existan colisiones con futuros gestos

a desarrollar.

Ilustración 4.34 – Reconocimiento del gesto “marcar punto en nube”

Acción en CloudCompare. En cuanto al software se refiere, para poder

hacer que nuestro dedo haga de ratón, debemos darle unas

coordenadas que nos sitúen en la pantalla.

El centro del sistema de coordenadas a utilizar se posicionará en el (0,

alturaBrazoEstándar, 0), apuntando al centro de la pantalla cuando se

realice el gesto de forma natural (con el apoyo del codo en la mesa).




Para considerar los desplazamientos, se tomarán como referencia las

coordenadas (x, y) del dedo índice (respecto del centro del sistema

situado anteriormente), cuyo valor se multiplicará por 2 para su

desplazamiento de un modo más rápido y natural para el usuario.

Finalmente, se llamará a una función del núcleo de CloudCompare que

te devuelve qué punto se ha clicado según la posición del ratón, y a

partir de él, crearemos una nota que nos de sus coordenadas absolutas

de mundo.

Ilustración 4.35 – Acción en CloudCompare asociada al gesto “marcar punto en nube”

Una vez realizado el gesto, nos quedaría la siguiente situación en la

ventana de CloudCompare (retroalimentación para el usuario):

Ilustración 4.36 - Feedback asociado al gesto “marcar punto en nube”




4.3.4. Traslación de una nube de puntos

Empezamos en esta sección a tratar con las transformaciones geométricas

básicas, en concreto con la traslación, que ya si no pueden resultar de más utilidad

en el tratamiento de nubes de puntos.

Diseño del gesto. Basándose en los vocabularios expuestos

anteriormente, así como en las clasificaciones de gestos por fatiga, un

gesto apropiado e intuitivo para la acción de mover una nube de puntos

podría tratarse del siguiente.

Ilustración 4.37 – Gesto “trasladar nube de puntos”

Se trata de un gesto sencillo, simplemente consiste en expandir la mano

para poder ser detectado y moverla por el espacio de los ejes X e Y para

que la misma nube se mueva en coordinación con la mano. Se descarta

el eje Z, ya que según el código central de CloudCompare, esta acción

sería bastante costosa de implementar, pudiendo llegar a ser bastante

tedioso de resolver.

Además, como punto a favor al gesto asociado, es muy común ver en

series, películas y demás formatos de video con temáticas actuales o de

ciencia ficción, el manejo de ventanas en realidad aumentada en las que

se realizan gestos iguales o parecidos a este, por lo que el usuario

común puede sentirse cómodo realizándolo, ya que probablemente sea

un gesto ya asumido al visualizar algún formato de este tipo.




Detección del gesto. En la detección del gesto se debe de revisar que

todos los dedos (a excepción del pulgar) estén extendidos y que la

normal de la palma de la mano apunte en dirección a la pantalla (eje Z

negativo). Si ocurre esto, se realizará la acción asociada a dicho gesto.

Ilustración 4.38 – Reconocimiento del gesto “trasladar nube de puntos”

Acción en CloudCompare. Finalmente, en cuanto a la realización de

dicha acción en CloudCompare, necesitamos calcular el desplazamiento

en el eje X e Y de la posición de la mano respecto de su posición la

última vez que realizó dicho gesto.

Este desplazamiento se verá multiplicado por un factor dependiendo de

la proyección que utilicemos (ortográfica y perspectiva), para que

podamos observar un movimiento de la nube de puntos más o menos

cómodo para el usuario.

Por último, para simular el desplazamiento de la nube de puntos, lo que

se realizará será una llamada a una función de CloudCompare que

desplaza la posición de la cámara. Así, parece que la nube de puntos ha

sido movida en el software, aunque realmente lo que se movió fue la

cámara utilizada.




Ilustración 4.39 – Acción en CloudCompare asociada al gesto “trasladar nube de puntos”

A continuación, se muestra en la imagen una interacción propia

asociada a este gesto:

Ilustración 4.40 - Feedback asociado al gesto “trasladar nube de puntos”

4.3.5. Rotación de una nube de puntos

El siguiente punto a tratar será la acción de rotación sobre cada uno de los ejes

de coordenadas, dentro de las transformaciones geométricas básicas.

Diseño del gesto. En la función de rotación sobre una nube de puntos,

es fácilmente apreciable que un gesto intuitivo y cómodo para realizar

puede ser el siguiente:




Ilustración 4.41 – Gesto “rotar nube de puntos” en eje X y Z

Como se aprecia en la imagen, este gesto consistiría en girar nuestro

puño (cerrado) sobre el eje X o el Z, decidiendo cambiar el gesto de

rotación para el eje Y ya que podría sobreponerse erróneamente unas

rotaciones sobre otras y por la limitada capacidad de girar sobre el eje Y

de nuestro puño. Debido a esto, la realización del giro en el eje Y sería

con nuestra mano abierta y extendida, girando sobre dicho eje como se

muestra en la imagen siguiente:

Ilustración 4.42 – Gesto “rotar nube de puntos” en eje Y

Detección del gesto. La detección del gesto se dividiría en 2 partes,

tratando de detectar la rotación en el eje X o Z, y la detección del giro en

el eje Y.

Para el primero, tendremos que comprobar que ningún dedo este

estirado. Una vez tengamos esto mediremos la normal de la palma de la




mano y giraremos siempre que la componente en x o en z sea mayor a

0.5. Si todo esto ocurre, cogeremos el componente de mayor valor y

giraremos en torno al eje contrario (ej: si la componente x fuera mayor a

la z, giraríamos en torno al eje Z).

En el segundo caso, comprobaríamos que todos los dedos (a excepción

del pulgar) estén estirados, que la normal de la mano apunte hacia el eje

Y negativo y que la dirección (todos los vectores sobre los que se tratan

se consideran normalizados) a la que apunta la mano supere el valor

0,5.

Ilustración 4.43 – Reconocimiento del gesto “rotar nube de puntos”

Este tipo de rotación sería del tipo interruptor, en la cual, cuando se

alcance el gesto, la nube de puntos comenzará a girar sin necesidad de

que nuestro puño siga girando (por las limitaciones evidentes de giro de

nuestra muñeca). Si se desea que la nube pare de girar, solo hay que

deshacer el gesto realizado (simplemente la mano deberá adoptar

cualquier posición menos la que debe reconocer el dispositivo Leap

Motion).

Por último, incidir en la necesidad de limitar lo máximo posible el

reconocimiento de gestos con distintos parámetros (no demasiado

prohibitivos) para evitar la detección de varios gestos al mismo tiempo

por superposición entre ellos, realizando acciones no deseadas.




Acción en CloudCompare. En cuanto a la implementación en

CloudCompare no posee ninguna dificultad, ya que simplemente

tendríamos que llamar a una función del núcleo del software, encargada

de girar la cámara mediante los parámetros que representan un ángulo

(preestablecidos por nosotros y siendo el mismo cada vez que se gire) y

un eje sobre el que rotar (dependiendo del gesto detectado).

Al igual que en el gesto anterior, en vez de rotar propiamente la nube de

puntos entera, rotaríamos solo la cámara, produciendo el visualmente el

mismo efecto.



Ilustración 4.44 - Feedback asociado al gesto “rotar nube de puntos”

4.3.6. Escalado de una nube de puntos

La última acción que queda por determinar en esta iteración será el escalado

de una nube de puntos.




Diseño del gesto. Cuando hablamos acerca de realizar una acción de

escalado o zoom sobre algo con una sola mano, la primera metáfora que

se nos viene a la mente es la utilizada en dispositivos móviles, el

movimiento de pinza.

Dicho gesto fue ampliamente considerado para tomar esta acción, sin

embargo, tras la realización de ciertas pruebas de precisión, determiné

que en este momento no debería ser una opción posible, no por el gesto

en sí, sino más bien por el dispositivo Leap Motion, el cual, a mi parecer,

debe de mejorar la detección sobre el dedo pulgar, ya que suele tener

bastantes errores. Es por esto que en muchos gestos anteriores no es

considerado a la hora de realizarlos.

Como alternativa, recurriremos al usual gesto utilizado para indicar a

personas que se acerquen, el cual se puede realizar de manera cómoda,

por lo que sería indicado en esta ocasión. El gesto en cuestión seria el

siguiente:

Ilustración 4.45 – Gesto “escalar nube de puntos”

El funcionamiento del gesto es muy sencillo, solo hay que abrir la mano,

tal como muestra la imagen, y mientras se cierra ira acercando o

ampliando la nube de puntos. Para obtener la acción contraria (alejar el

objeto), solo debemos hacer igual, solo que la posición inicial seria con

el puño cerrado mirando hacia abajo y cuando se abriera se alejaría el

modelo




Detección del gesto. La detección del gesto debe ser dividida en 2

partes para determinar si se trata de un zoom positivo o negativo.

Primero se calcula la distancia del dedo índice a la palma de la mano

(considerando solo el eje Z) y se obtiene el incremente o decremento

con respecto a la distancia en el frame anterior.

Si esta nueva diferencia es positiva y la normal de la palma de la mano

apunta hacia el eje positivo de la Y, se realiza un zoom positivo.

En caso de que la diferencia sea negativa y la normal de la palma de la

mano también apunte hacia la parte negativa del eje Y se realizará un

zoom negativo.

Ilustración 4.46 – Reconocimiento del gesto “escalar nube de puntos”

Acción en CloudCompare. En cuanto a CloudCompare, en este caso,

se resolverá de una forma trivial, ya que se posee una función a la que

podemos llamar que simula el movimiento de la rueda del ratón y por

consiguiente realiza un zoom positivo o negativo en función del valor del

desplazamiento pasado como parámetro.






Ilustración 4.47 - Feedback asociado al gesto “escalar nube de puntos”

4.3.7. Centrar una nube de puntos

Con el desarrollo de los gestos en los periodos de verificación en la corrección

de acciones, se descubrió la necesidad de volver a llevar las nubes de puntos al

centro del eje de coordenadas con su tamaño original, ya que debido a un mal

funcionamiento de las acciones (todavía en desarrollo) podrían surgir problemas

como nubes de puntos demasiado alejadas, fuera de pantalla de visión o con

demasiadas rotaciones como para volver a su estado original de forma fácil.

Se motivó de esta forma este nuevo punto en la interacción en el que se

deberá crear un gesto acorde a dicha acción.

Diseño del gesto. La toma de decisión sobre un gesto que represente

la acción fue bastante difícil, ya que ninguno resultaba lo bastante

acorde o intuitivo a la acción. Tras mucho pensar y a riesgo de escoger

un gesto que pudiera ser poco intuitivo o difícil de reconocer, me decidí

por usar “el chasquido”.

Para esta decisión pongámonos en situación de una escena en la que

las nubes de puntos están esparcidas por todos los lugares, con

distintos tamaños y rotadas en todos los ejes posibles. Sería necesario




el uso de un “chasquido mágico” que fuera capaz de arreglarlo todo,

descubriendo que no podría haber una metáfora mejor para la

realización de esa acción, en mi opinión, por lo que me decidí a utilizarlo,

aunque posteriormente habría que verificar mediante los tests si de

verdad sería una buena metáfora.

Detección del gesto. El gesto es claro para cualquier persona, pero

contiene una gran dificultad a la hora de describir el proceso de

realización, parte fundamental para poder ser reconocido posteriormente

por el dispositivo Leap Motion.

Finalmente desglosamos el gesto en la realización de 2 gestos

consecutivos en los que la normal a la palma de la mano debe apuntar

hacia el eje X.

El primero consistirá en mantener cerrados los dedos meñique y anular,

mientras que los demás apuntarán hacia el eje X (obviando el pulgar).

El segundo gesto mantendrá los mismos dedos cerrados y solo debe

cambiar el índice, que ahora debe apuntar hacia el eje Z (obviando

ahora la posición del dedo corazón y pulgar).

Ilustración 4.48 – Gesto “centrar nube de puntos”

Aunque de forma teórica pueda resultar hasta complicado realizarlo,

suele funcionar bien cuando el gesto se realiza de forma natural al estilo

de cada usuario.




Ilustración 4.49 – Reconocimiento del gesto “centrar nube de puntos”

Acción en CloudCompare. Como ha pasado en los gestos anteriores,

para esta acción en sí, solo debemos llamar a la función que resetea la

cámara (ya implementada en CloudCompare), debido a que solo hemos

cambiado parámetros de la cámara (posición, rotación, zoom) en estas

primeras acciones básicas.



Ilustración 4.50 - Feedback asociado al gesto “centrar nube de puntos”




4.3.8. Reunión

En la reunión de la iteración 3 se mostró a la parte cliente (tutores) el plugin

hasta el momento desarrollado, con un ejemplo práctico en el que les mostraba en

directo la realización de todas las acciones sobre nubes de puntos mediante la

realización de los gestos realizados.

Los tutores dieron el visto bueno al avance desarrollado, quedando

gratamente impresionados por la originalidad del gesto “centrar nubes de puntos”, ya

que lo que parecía un gesto complejo a priori, ha sido capaz de leerlo sin problemas

aparentes el dispositivo Leap Motion, realizando su función asociada.

Como sugerencias y nuevos objetivos a realizar, antes de comenzar con los ya

preestablecidos para la siguiente iteración, comentaron la necesidad de hacer el

plugin funcional tanto para gente diestra, como zurda, ya que en un principio se

había desarrollado solo para gente zurda (al ser mi mano secundaria), lo cual

significaba una pérdida de posibles usuarios.

Además, como último objetivo adicional se propuso la búsqueda de nuevos

gestos para algunas de las acciones ya realizadas, para tener un vocabulario amplio

de gestos y poder decidir entre unos u otros de forma definitiva tras la realización de

distintos test de prueba de la herramienta al final de la investigación.




4.4. Iteración 4 – Funciones avanzadas

4.4.1. Requisitos

Continuando a partir del desarrollo producido en la iteración anterior,

seguiremos con una parte más práctica, incluyendo nuevas funciones al plugin y

probando la eficacia del dispositivo Leap Motion.

En esta parte, nos centraremos en funciones más complejas, que al igual que

paso con la “acción de centrar una nube de puntos”, habrá que descomponer en

varias partes para que su tratamiento posterior sea más simple, facilitando el

reconocimiento de la acción

En concreto, los objetivos básicos para cumplir en esta iteración (incluyendo las

propuestas de la pasada reunión) serán:

Posibilitar funcionamiento con mano izquierda o derecha (a elección por

el usuario).

Preparar varias formas de interacción para una acción.

Selección de un conjunto de puntos.

Marcar puntos mediante selección de tamaño variable.

Tratamiento de puntos marcados.

Como se observó en el apartado 3 del documento, a partir de esta y siguientes

iteraciones se irán incrementando el número y la dificultad de tareas, aunque

mantienen una parte más práctica, lo que le dota de un mayor interés por mi parte,

dedicándole más tiempo, aumentando la velocidad y posibilitando su finalización en

el tiempo requerido.

4.4.2. Elección de mano preferida

La resolución del problema que se nos indica en este apartado, tiene una

solución relativamente sencilla, gracias también, a que se incorporará al principio del

proyecto y no en sus fases finales.

Para poder realizar gestos con ambas manos, nos basaremos en las

posibilidades que nos ofrece Leap Motion, el cual puede reconocer sin problema




aparente si ha detectado en el frame una mano diestra o zurda, por lo que en esa

parte no habría inconvenientes.

Para adoptar nuestra solución a este requisito, modificaremos la clase

“LeapMotionTool” (explicada en el apartado 4.2.7), a la que agregaremos un nuevo

atributo de la clase booleano que indique si la mano elegida por el usuario para la

realización de gestos es la derecha o no.

En base a este nuevo atributo, necesitamos modificadores del mismo en la

clase, que serán llamados por la clase principal (ccLeapMotion) cada vez que se

cambie la mano a utilizar, ya que será esta la clase que sea informada por la interfaz

del plugin cuando cambie el atributo.

Una vez que cada herramienta creada conoce si el usuario prefiere el uso de

una mano u otra, deberá cambiar su forma de reconocimiento de la mano. Antes

simplemente comprobaba si existía alguna mano izquierda y se quedaba con ella,

ahora cada vez que obtenga una mano deberá comprobar además si es la preferida,

para quedarse con ella si lo es o descartarla en caso contrario.

Obtendríamos una función parecida a la siguiente:

Ilustración 4.51 – Reconocimiento de mano preferida por el usuario

Finalmente quedaría pensar en los gestos diseñados, ya que podrían cambiar

entre la mano derecha e izquierda. Por ejemplo, al cambiar de herramienta usando

la mano izquierda, la palma de la mano apuntaría al eje X positivo y usando la

derecha se apuntaría hacia el eje X negativo.

Sin embargo, se tuvieron precauciones en el diseño de gestos, pensando en la

posible incorporación de este requisito, por lo que, en el ejemplo anterior, a la hora




de detectar la normal de la palma de la mano usamos el valor absoluto de la

dirección X, siendo así posible la detección del gesto con ambas manos. Todos los

gestos estaban adaptados para ser utilizados en ambas manos por lo que no

surgieron problemas adicionales en la realización del objetivo.

Cabe destacar la importancia y necesidad de conseguir este objetivo, ya que la

accesibilidad para todo tipo de usuario es un requisito fundamental en cualquier

proyecto. Según su configuración anterior se descartaba el uso de toda la población

zurda para su propósito original de usar el dispositivo con la mano secundaria.

Además, una vez pueda elegir el usuario que mano utilizar en la interacción, se

sentirá libre de elegir una u otra, pudiendo usar su mano principal para el uso si se

siente más cómodo.

4.4.3. Rotación eje-ratón.

Siguiendo con las recomendaciones de los tutores, comencé a incluir nuevas

metáforas que sirvieran para la realización de acciones mediante CloudCompare,

aunque estas fueran repetidas.

Esto dará libertad en la evaluación posterior del sistema para la elección del

mejor gesto asociado a una acción o puede posibilitar la convivencia de los distintos

gestos y que el usuario elija el que le es más natural y fácil de hacer según su

criterio.

Diseño del gesto. Comenzamos con un gesto sugerido para la acción

de rotación, el cual consiste en posicionar las manos apuntando hacia

un eje de coordenadas mientras movemos al mismo tiempo el ratón.

Esto simboliza una rotación, en el que el eje sobre el que se realiza será

el indicado por la mano y la cantidad de grados vendrá dada por el

desplazamiento del ratón.

Aunque parece contrario este gesto con la finalidad del proyecto de

sustituir el uso de teclado-ratón por otro mecanismo, también es

prioridad agilizar o facilitar las acciones tradicionales, cosa que podemos




conseguir mediante este gesto combinando las mejores características

de cada dispositivo

Ilustración 4.52 – Gesto “rotación eje-ratón”

Detección del gesto. En cuanto a la detección del gesto simplemente

tenemos que comprobar que todos los dedos estén extendidos

(obviando el pulgar) y, una vez cumplido esto, ver hacia a donde apunta

uno de ellos, por ejemplo, el índice.

Si el índice apunta en dirección del eje X, Y o Z se girará sobre ese ese

eje. En cuanto a la cantidad de ángulo a rotar, para el eje X se

considerará la diferencia de la posición del ratón en el eje Y con

respecto a su posición anterior. Para los otros dos ejes se utilizará la

diferencia en la posición del ratón, pero esta vez sobre el eje X,

dotándole así de una mayor naturalidad al movimiento a la hora de girar.

Se realizó de esta forma ya que sería raro que, si se quiere girar sobre el

eje X, por ejemplo, se tuviera que desplazar sobre el mismo también,

posibilitando el fallo en el proceso de asociación del gesto y la acción, y

fracasando como metáfora.




Ilustración 4.53 – Reconocimiento del gesto “rotación eje-ratón”

Acción en CloudCompare. En cuanto a CloudCompare, y al igual que

pasaba en la rotación del tipo anterior, simplemente hay que llamar a

una función ya implementada del software que gire una cantidad de

grados sobre un eje.



Ilustración 4.54 - Feedback asociado al gesto “rotación eje-ratón”




4.4.4. Rotación directa.

Se procede a implementar un tercer tipo de rotación denominado “directa”,

también a sugerencia de los tutores, en la que se simularía el “coger” la nube de

puntos dentro del puño y lo rotarías, girando la nube de puntos del mismo modo que

el puño, de una forma directa.

Diseño del gesto. El gesto perteneciente a esta acción será muy

sencillo, basado en la idea comentada anteriormente.

Para “coger” la nube de puntos necesitas cerrar el puño y para girarla

simplemente tienes que girar el puño también de forma libre, sin ningún

tipo de requisito especial. La nube de puntos girará de la misma forma

en la que gire el puño.

Ilustración 4.55 – Gesto “rotación directa”

Detección del gesto. En la parte del dispositivo Leap Motion para la

detección de dicho gesto, únicamente tendremos que detectar que

ningún dedo esté extendido. Tras esto, ya se podría realizar la acción, la

cual se desarrollará posteriormente para mostrar cómo se realizará la

rotación (ángulo y eje sobre el que se realiza)

Ilustración 4.56 – Reconocimiento del gesto “rotación directa”




Acción en CloudCompare. Para la realización de la rotación

necesitamos de nuevo rotar la cámara que implementa CloudCompare,

proporcionándole un ángulo y un eje sobre el que girar.

Podemos obtener estos valores a partir del producto cruzado y el

producto vectorial entre las normales de la palma de la mano de 2

frames consecutivos.

Usaremos el producto vectorial para determinar el vector ortonormal a

los 2 vectores normales de la mano, sobre el que girará el primer vector

un ángulo determinado para alcanzar la posición del segundo vector.

Para conocer el ángulo de giro simplemente bastara con hacer el

producto escalar entre los vectores, del que obtendremos el valor del

coseno de dicho ángulo, determinado posteriormente mediante el

arcoseno de dicho valor.

Ilustración 4.57 – Acción en CloudCompare asociada al gesto “rotación directa”






Ilustración 4.58 - Feedback asociado al gesto “rotación directa”

4.4.5. Escalado de una nube de puntos (con 2 manos)

Finalmente, la última acción que vamos a replicar será la del escalado de

nubes de puntos, esta vez agregando algo innovador hasta lo desarrollado en este

punto: el uso de las dos manos en la realización de un gesto.

Hasta ahora siempre se ha utilizado una mano para la realización de gestos ya

que la utilización del plugin está pensada para ser manejado con sólo una mano. Sin

embargo, vamos a ofrecer un nuevo gesto con 2 manos, siendo oportuno realizarlo

en algún momento por el usuario (siempre que pueda), por un mayor control o

facilidad, antes que el gesto con una sola mano.

Diseño del gesto. Retomando la idea abandonada del gesto de pinza

usados en los móviles, y a partir de los vocabularios gestuales de

artículos de gente experta en el campo (mencionados en la iteración 2),

usaremos el siguiente gesto para representar la acción de escalado de

una nube de puntos:




Ilustración 4.59 – Gesto “escalar nube de puntos” (2 manos)

El gesto en sí es muy sencillo e intuitivo. Se deben colocar los índices de

forma extendida apuntando en el eje Z y a partir de aquí, si aumenta la

distancia entre ellos aumentará el zoom de forma proporcional. Lo

contrario pasara cuando la distancia entre ellos se acorte, al estilo del

gesto de pinza del móvil.

Detección del gesto. Como se ha mencionado en el apartado anterior,

para su detección ambos índices deben estar estirados (los demás

dedos no deben estarlo) y apuntando hacia el eje Z negativo.

En función de la distancia entre la componente X de la posición de los

índices se escalará positiva o negativamente la nube de puntos.

Ilustración 4.60 – Reconocimiento del gesto “escalar nube de puntos” (2 manos)

Acción en CloudCompare. Como en el primer caso de la acción,

llamaríamos a la función que simula el movimiento de la rueda del ratón




aumentando o disminuyendo el zoom de la cámara del escenario en

CloudCompare.



Ilustración 4.61 - Feedback asociado al gesto “escalar nube de puntos” (2 manos)

4.4.6. Seleccionar un conjunto de puntos

La siguiente tarea consiste en la selección de varios puntos distintos (al mismo

tiempo) de la nube de puntos, para ser posteriormente marcados de algún modo y

ejecutar sobre ellos algún tipo de acción.

Si optamos por continuar a partir de nuestra tarea básica, la cual seleccionaba

un único punto de la nube, rápidamente descubriremos que no nos servirá para esta

tarea, ya que no será eficiente.

Pero, antes de esto, debemos determinar cómo seleccionar un rango de puntos

de la nube. Podría construirse un cuadrado alrededor de donde se sitúe el cursor

para así seleccionar todos los puntos de este cuadrado. Además, su tamaño,

debería de ser variable para seleccionar un rango mayor o menor, según la tarea y

nube de puntos con la que tratemos. Se entrará en detalle posteriormente en la

implementación del propio plugin a través de Qt.




Situándonos de nuevo en nuestra primera función, sabemos la posición del

cursor actualmente y tenemos un cuadrado a su alrededor que representa la zona a

seleccionar. Basta con discretizar este espacio, según un rango determinado (puede

ser también variable), en distintas posiciones donde situar el cursor, simulando un

click y obteniendo el punto asociado a ese click en cada punto según nuestra

función.

El problema de este método reside principalmente en la eficiencia de dicha

función del núcleo de CloudCompare, que nos devuelve un punto a partir de la zona

donde se sitúa el ratón. Si es utilizada para un solo punto, la velocidad de la misma

es razonable, pero si cada frame debemos repetir esta función múltiples veces para

el rango deseado, hará que el proceso sea muy lento, perdiendo toda la fluidez y

llegando incluso a tener que finalizar el proceso.

Por otro lado, existen otros pequeños problemas en este método como lo

pueden ser la propia función y la discretización. A la hora de discretizar, si no

queremos sobrecargar demasiado la función y dejamos un espacio “amplio” entre las

posiciones a obtener puntos, podemos dejar entremedias bastantes puntos que no

serían seleccionados en una zona en la que se acumulen bastantes puntos en poco

espacio. En cuanto a la función en sí, si se usa en una zona en la que los puntos

estén muy próximos entre ellos, puede ser que al seleccionar sobre varias

posiciones siempre te devuelva el mismo punto, evitando otros por pequeños

errores, de redondeo por ejemplo, a la hora de seleccionar.

Todos estos inconvenientes vienen a decirnos que debemos evitar el uso de

esta primera función implementada por otra que puede adaptarse mejor al problema

a resolver.

Para encontrar una nueva solución, antes de intentar ponerse a resolverla a

través de un sistema propio a desarrollar, suele ser buena idea investigar el propio

software de CloudCompare, así como todas las operaciones que posee para nubes

de puntos, porque es probable que exista alguna que nos pueda servir de ayuda y

ahorrarnos bastante tiempo de desarrollo.




De entre todas sus herramientas, encontramos una que nos puede ser de gran

utilidad para nuestro propósito, la llamada “Cross Section”.

Ilustración 4.62 – Herramienta “Cross Section” de CloudCompare.

Como se puede intuir en la imagen, al utilizar esta herramienta en nuestra nube

de puntos, nos aparecen distintos elementos como lo son la caja envolvente de la

nube de puntos y una serie de flechas en cada plano de la caja.

A partir de estas flechas podemos acortar o alargar las dimensiones de la caja,

con la característica de que cuando se acorta la carta, va segmentando cada punto

que encuentra, es decir, de nuestra nube de puntos original solo mantendrá los

puntos que estén dentro de la propia caja.

Ilustración 4.63 – Extracción de puntos de una nube mediante la herramienta “Cross Section”




Todo este proceso lo hace de forma fluida y constante, siendo con gran

probabilidad la herramienta deseada para nuestra función. Comentar también, que

puede extraer la nube de puntos resultante de acortar la caja, lo cual nos dará los

puntos seleccionados.

Como muchas veces suele ocurrir en el campo de la algoritmia, los métodos

que mejor funcionan son los híbridos y en este caso haremos igual, realizando

nuestra acción a partir de nuestra función básica y de esta nueva.

Primero debemos saber dónde situarnos por lo que llamaremos una única vez

a la función básica que nos devolverá el punto sobre el que se sitúa el cursor.

A partir de este punto, construiremos una caja envolvente (con centro el punto)

del tamaño deseado para la acción. En este momento entra la nueva función de

CloudCompare que a partir de una caja envolvente nos devolverá los índices de la

nube de puntos que están contenidos en dicha caja.

Esta nueva función sustituirá a la implementada anteriormente (sin una función

útil realmente), utilizando el mismo gesto y sistema de reconocimiento, cambiando

solo la acción de CloudCompare:

Ilustración 4.64 – Selección de un rango de puntos de una nube de puntos




4.4.7. Borrado de selección de puntos.

Como se debía de implementar una función con los puntos seleccionados para

probar su funcionamiento, me decidí por la implantación del borrado de los puntos

seleccionados, ya que un problema muy común cuando se realizan escaneados de

zonas mediante nubes de puntos es la aparición de distintos objetos que no aportan

nada al objetivo deseado y deben ser borrados, siendo esta función útil para estos

casos.

Diseño del gesto. El gesto será uno sencillo, no necesariamente el

definitivo para la acción, ya que solo servirá como prueba para la

herramienta de marcado de puntos. Es por esto, que me decidí por un

gesto tan simple como abrir la mano (extender todos los dedos) cuando

se acaba de seleccionar una zona de puntos para su borrado de la nube

de puntos.

Ilustración 4.65 – Gesto “borrar puntos seleccionados”

Detección del gesto. Para la detección del gesto a través del

dispositivo Leap Motion sólo tenemos que comprobar que todos los

dedos estén extendidos (obviando el pulgar) y se realizara la acción de

borrado sobre los puntos seleccionados en la nube de puntos




Ilustración 4.66 – Reconocimiento del gesto “borrar puntos seleccionados”

Acción en CloudCompare. En la parte de CloudCompare, para el

borrado de puntos, debemos de iterar sobre los puntos seleccionarlos y

marcarlos con el atributo de “No Visible”. Gracias a una función de

CloudCompare, se puede crear una nube de puntos a partir de los

puntos “Visibles” de una nube que se pase como parámetro.

Ilustración 4.67 – Acción en CloudCompare asociada al gesto “borrar puntos seleccionados”

A continuación, se muestra en la imagen una interacción propia asociada a

este gesto:

Ilustración 4.68 - Feedback asociado al gesto “borrar puntos seleccionados”




4.4.8. Reunión

En la reunión de la cuarta iteración al igual que en la pasada, de nuevo se les

mostró un el plugin a la parte cliente mediante el propio uso en directo de la interfaz

y la gestualización.

Los tutores aceptaron los nuevos gestos introducidos, destacando la necesidad

de intentar mejorar, de ser posible, la precisión y suavidad de los distintos gestos, ya

que el propio gesto de rotación directa era difícil de controlar, sin ir demasiado

sincronizado con la imagen en CloudCompare.

Por otra parte, se valoró de forma muy positiva al marcado de puntos en la

nube ya que es una tarea muy importante dentro de este campo y podría dar mucho

juego en la utilización del plugin como interfaz.

También dieron una observación acerca de que los gestos solo servirían para

manejar todas las nubes de puntos de la escena, es decir, no se podría tratar de

forma individual con cada nube de puntos. Por ejemplo, a la hora de desplazar

nubes, como lo que se mueve es la cámara, se “desplazarían” todas las nubes, lo

cual habría que replantearlo para poder manejar nubes de forma individual, teniendo

que adaptar los gestos desarrollados al manejo tanto de forma global como de forma

individual.

Finalmente, se concluye con la necesidad de realizar un apartado en el plugin

que sirviera como tutorial, mostrando cuales son los gestos y cómo usarlos, para

que cualquier usuario del plugin puede utilizarlo sin problemas.

Agregando estos objetivos para la próxima iteración, la reunión dio por

finalizada.




4.5. Iteración 5 - Test de prueba

4.5.1. Requisitos

En esta quinta iteración se resolverán en un principio los objetivos adicionales

propuestos por los tutores para que una vez finalizados, junto con el plugin básico a

utilizar en este proyecto, se proceda a la realización de una serie de tests que nos

sirvan para validar la nueva herramienta creada.

Para dicha tarea, se han implantado los siguientes objetivos para ser

realizados:

Mejorar la precisión y suavidad de la herramienta.

Realizar acciones sobre nubes de puntos de forma individual o de forma

conjunta con todas las nubes de puntos de la escena.

Integración de tutoriales en el plugin que informen acerca de cómo usar

la herramienta.

Preparación de un test de prueba para usuarios.

Realización y recogida de datos del test de prueba.

Nos situamos ya en las fases finales de la investigación, en las que se pulirán

los últimos detalles del desarrollo a la vez que se probará la eficacia de la

herramienta conseguida, decidiendo sobre la posible continuación de desarrollo

futuro con la herramienta o el descarte y elección de una nueva en busca de una

mayor eficiencia.

4.5.2. Mejoras de precisión y suavidad

La obtención de una buena precisión y suavidad a la hora de manejar las

acciones disponibles con nubes de puntos es una parte esencial en este proyecto,

ya que movimientos bruscos pueden hacer muy irritantes las tareas al usuario, el

cual no suele estar acostumbrado a este tipo de interfaces.

Mediante movimientos más lentos y suaves, el usuario obtendrá una

retroalimentación correcta que le ayudará a realizar tareas de forma muy precisa al

mismo tiempo que puede ir aprendiendo a utilizar la interfaz gestual, dominando




poco a poco el uso de gestos para la realización de las distintas acciones

programadas.

Esta tarea de mejora puede ser trivial en la mayoría de los gestos

desarrollados, ya que un simple ajuste de parámetros bastaría para su mejora. Por

ejemplo, en las rotaciones bastaría con disminuir el número de grados desplazados

y a la hora de escalar, cambiar nuestro factor de escala a uno más pequeño, que

nos permita una interacción más fluida para el usuario.

Sin embargo, existen 3 problemas principales de ajuste de precisión que

supondrán una mayor dificultad:

En la rotación “interruptor”, es común que se solapen las rotaciones con

pequeñas variaciones del gesto, haciendo difícil la tarea de rotación.

La rotación “directa” es propensa a sufrir un error grave si en algún

frame la mano es detectada de forma errónea. Además, es difícil su

manejo.

A la hora de marcar puntos, puede seleccionar o de la cara trasera o de

la delantera indistintamente. Habría que agregar algún criterio de mejora

para seleccionar los puntos de la cara que se está visualizando.

Obtenemos de esta forma un primer vistazo acerca de los problemas con una

solución más compleja de resolver, pasando a resolverlos de forma individual a

continuación:

Rotación interruptor. Para evitar la superposición de rotaciones en los

distintos ejes, definiremos una serie de estados para la herramienta:

No_Rotando, Rotando_X, Rotando_Y, Rotando_Z.

Estos estados nos indicarán qué se está realizando en un momento

determinado y para la realización de una transición entre 2 estados

será necesario la adopción de una postura base.

Tomamos el ejemplo de las rotaciones sobre el eje X y Z que suelen

superponerse. Ahora, si rotamos en torno al eje X por ejemplo,

pasaremos al estado “Rotando_X” y solo podrá realizarse ese tipo de




rotación, descartando otras que hayan sido detectadas. Para poder

rotar en el eje Z se deberá volver a la posición base (puño cerrado con

normal de la mano apuntando al eje Y negativo), obteniendo el estado

“No_Rotando”, lo que implica la posibilidad de obtención de un nuevo

estado, como es la rotación en el eje Z.

Esta acción vendría determinada por el siguiente diagrama de estados:

Ilustración 4.69 – Diagrama de estados de la herramienta “rotación interruptor”.

En cuanto a la parte de desarrollo de dicha acción, basándonos en el

primer esquema de la herramienta y utilizando estos nuevos estados, el

reconocimiento del gesto y realización de la acción vendría

determinada de la siguiente forma:




Ilustración 4.70 - Reconocimiento del gesto “rotar nube de puntos” mejorado.

Rotación directa. En este caso la solución no será tan sencilla como

en el anterior. Para intentar solventar los problemas de captación de

frames con representaciones de nuestra mano de forma errónea y a

sugerencia de los tutores, se realizó un análisis obteniendo varios

frames (pocos para no dar demasiada brusquedad a los movimientos).

A partir de ellos obtendríamos las normales de la palma de la mano,

necesarias para este gesto y obteniendo una media a partir de las

mismas, lo que nos ayudará a reducir el error generado por una mala

captación, consiguiendo la posición final de la mano con la que calcular

la rotación producida.

Ilustración 4.71 - Reconocimiento del gesto “rotación directa” mejorado.




A pesar de esto, y aunque mejoró algo la precisión de las rotaciones,

aún seguía siendo algo inestable y difícil de manejar, posiblemente

también por errores de precisión del dispositivo, que debería de

mejorar en desarrollos futuros. Para evitar una pérdida de tiempo

considerable en la búsqueda de una mejor forma para realizar la

rotación y ya que se tenían 2 soluciones válidas para su uso, este

gesto se descartó a la hora de la validación del plugin, manteniéndolo

en el mismo todavía para un posible desarrollo futuro.

Marcado de puntos. Para la selección sobre las caras visibles de los

objetos en la pantalla, era necesario el uso de algún parámetro

adicional sobre el algoritmo que nos ayudara en la tarea.

Como una opción válida, se pensó en considerar la distancia de la

cámara a los puntos candidatos en la selección. Recordando nuestro

algoritmo, llamábamos a una función del núcleo de CloudCompare para

obtener el punto sobre el que situaba nuestro cursor, por lo que la idea

será agregar como un factor a tener en cuenta dentro de ese algoritmo,

la distancia a la cámara a la hora de seleccionar el punto.

El problema reside en que esta función pertenece al núcleo de

CloudCompare, inalterable para la creación de nuevos plugins. Debido

a esto, se optó por la replicación y adaptación de dicha función dentro

de nuestra herramienta, gracias a lo cual, podríamos usar dicha función

sin problemas aparentes, modificándola a nuestro gusto.

Analizando el algoritmo utilizado, se intuye que el criterio en la elección

del punto sobre el cursor es la distancia al rayo proyectado en la

escena desde la posición de la cámara, escogiendo el punto con menor

distancia, lo cual nos generaba los errores posibles de elección de

caras traseras.

Para el descarte de las caras traseras, solo deberíamos sumar la

distancia de la cámara, con un factor que reduzca su peso en la

elección, siendo capaz de eliminar los puntos de caras traseras, pero




no teniendo toda la relevancia en la elección del punto en las caras

delanteras.

Así, el algoritmo de elección de un punto situado sobre nuestro cursor

quedaría de la siguiente forma:

Ilustración 4.72 – Algoritmo para selección de puntos mediante cursor.

4.5.3. Acciones sobre nubes de puntos individuales

El principal problema con el que nos encontrábamos, según se había

desarrollado la herramienta, era la imposibilidad de trabajar con nubes de puntos de

forma aislada, ya que las transformaciones se realizaban sobre la cámara, dando

ilusión de que todas las nubes de puntos recibían dichas transformaciones.

Sin embargo, existe una necesidad clara de trabajar de forma individual o

mediante grupos de nubes de puntos, por lo que la implementación de una solución

que pueda hacerlo es imprescindible en el futuro del proyecto.

No es necesario cambiar todo lo desarrollado, simplemente añadir una

casuística que considere si se han seleccionado nubes de puntos, ya que los

métodos anteriores dotan a nuestra herramienta de gran eficiencia, por la

simplicidad de la misma en la realización de acciones.

Por lo cual nuestro esquema, de forma genérica, sobre el reconocimiento de

gestos quedaría de la siguiente forma:




Ilustración 4.73 – Reconocimiento de gestos y acciones sobres nubes individuales o conjuntas

Pasamos a explicar la última parte de la ilustración anterior. Para la realización

de transformaciones geométricas sobre modelos 3D está clara la utilización de

matrices que determinarán el estado actual de la nube de puntos.

CloudCompare mantiene 2 estados de las nubes de puntos, guardando o no

las transformaciones geométricas. Si realizamos transformaciones geométricas sin

guardar estos nuevos cambios y queremos guardar un modelo, CloudCompare no

considerará las nuevas transformaciones y obtendrá el modelo únicamente con las

transformaciones que han sido guardadas anteriormente.

Sin embargo, esta tarea es lo suficientemente costosa, como para perder la

fluidez del programa si en cada frame que obtiene el Leap Motion y en el que se

hace una transformación sobre el modelo, se guardan dichas transformaciones,

siendo un problema.

Su solución, de forma básica, consistirá, como viene indicado, en apuntar

cuando se realice una transformación y cada un cierto número de frames, guardar

las transformaciones realizadas (siempre que haya), para evitar la pérdida de fluidez

total del programa.

En cuanto a las funciones básicas de nuestro plugin (traslado, rotación y

escalado) simplemente tendremos que obtener la matriz asociada a la




transformación, a partir de los parámetros que ya obteníamos en las funciones,

siendo necesario, quizás, el ajuste de algún parámetro o factor.

Ilustración 4.74 – Matrices de transformaciones geométricas 3D básicas.

En rotaciones y escalados, debemos recordar además trasladar las nubes de

puntos al centro del eje de coordenadas (para realizar transformaciones de forma

local), quedando la acción a realizar en CloudCompare de la siguiente forma:

Ilustración 4.75 – Transformaciones geométricas 3D básicas sobre nubes de puntos

A la hora de centralizar las nubes de puntos, podemos resolverlo simplemente

con la multiplicación de la matriz de cada nube de puntos por su inversa, obteniendo

la matriz identidad, y por ende, el modelo original. La matriz inversa se puede

calcular a través de funciones de CloudCompare, por lo que no existe dificultad

aparente.

Finalmente nos quedaría tratar con la selección de puntos, en la que sí

encontramos un problema, llevando a la finalización del programa principal cuando




se llama a la función que localiza el punto de la nube sobre el que se sitúa el cursor,

existiendo nubes de puntos seleccionadas.

Al demorar demasiado tiempo la revisión del codigo central de CloudCompare

para evitar este error, se dejó la selección para su realización en forma global de

momento, archivando la tarea como trabajo futuro a desarrollar y evitando el

marcado si hay alguna nube seleccionada.

A pesar de esto, nuestro plugin es bastante funcional, con una amplia gama de

acciones para realizar de forma conjunta e individual, que nos sirve como prototipo a

validar, al mismo tiempo que el éxito o fracaso de la investigación.

4.5.4. Interfaz del plugin

A pesar de haber desarrollado el plugin completamente, nunca se ha hablado

acerca de cómo está compuesto y su funcionamiento, aprovechando este apartado

para hacerlo.

Nuestra herramienta, como se explicó anteriormente, es una máquina de

estados en la que en cada estado se detectarán gestos propios del estado, así como

gestos comunes que siempre puedan ser utilizados.

De esta forma nos encontramos con que nuestro plugin tiene 4 estados en los

que se realizan los siguientes gestos de forma respectiva: marcar puntos, rotar

(interruptor y eje), rotar (directa) y zoom (con 1 mano).

Por otro lado, consideramos una serie de acciones que siempre pueden

llevarse a cabo, como lo serían: cambiar de herramienta, trasladar nubes de puntos,

zoom (con 2 manos) y centralizar los modelos.

Cada estado se representa mediante un botón en nuestra interfaz, incluyendo

un slider que nos indicará el tamaño en la selección de nubes de puntos. Además,

incluye 2 botones adicionales, uno para desactivar la herramienta y otro, a petición

de los tutores, en los que se nos indicará como realizar los gestos asociados a las

acciones, a modo de tutorial.




Ilustración 4.76 – Interfaz del plugin de Leap Motion sobre CloudCompare

Para la representación de los tutoriales, al pulsar sobre el botón de tutorial, se

nos abrirá una nueva ventana dividida en tantas pestañas como estado existen.

Adicionalmente, se agrega una nueva pestaña con todos los gestos comunes

que pueden realizarse en cualquier momento.

Cabe resaltar que cada pestaña contendrá un GIF indicando como realizar el

gesto referido a dicha acción.

lustración 4.77 – Interfaz del plugin de Leap Motion sobre CloudCompare (tutoriales)




4.5.5. Test de validación para usuarios

La creación de un test que valide nuestra herramienta exige una búsqueda

asociada de información acerca de las métricas a utilizar en interfaces gestuales.

Tras una exhaustiva búsqueda sobre artículos, webs y libros que traten acerca

de nuestro tema, al igual que ocurrió en el principio de la investigación, se encontró

poca información y muy dispersa.

Se decidió realizar un test para usuarios divido en 2 claras perspectivas:

Validación del vocabulario de gestos creados. El “benchmark” de

nuestro vocabulario de gestos lo realizaremos en base a un artículo

encontrado, que recomienda la realización mediante 3 tests:

(Nielsen, M., Störring, M., Moeslund, T., & Granum, E, 2014)

o Interpretación semántica – Test 1

o Generalización – Test 1

o Intuitividad – Test 1, 2

o Memoria, velocidad de aprendizaje – Test 2

o Tensión – Test 3

Pasamos a explicar cómo debe realizarse cada uno de los test de

validación:

o Test 1: Adivinar la función. Se le proporcionará al usuario una

lista de funciones que pueden ser realizadas en CloudCompare

con nubes de puntos.

A continuación, se presentarán los gestos y se le pedirá a la

persona que adivine la función de cada gesto. Los gestos que

dependen del contexto deben presentarse en contexto.

Puntuación = errores divididos por el número de gestos distintos

o Test 2: Memoria. Se le proporciona el vocabulario de gestos al

usuario, quien los probará para asegurarse de que se entienden.




Se realizará una presentación de diapositivas con los nombres

de las funciones a un ritmo rápido, 2 segundos por cada acción.

El usuario debe realizar los gestos correctamente mientras se

muestra el nombre.

Se debe reiniciar la presentación de diapositivas en cada error y

mostrar el vocabulario de gestos al usuario entre cada reintento.

El test finalizará cuando se realicen de forma correcta todos los

gestos asociados a las distintas acciones.

Puntuación = número de reinicios.

o Test 3: Fatiga. El artículo recomendaba realizar una secuencia

de acciones y repetirlas un número determinado de veces para

que el usuario pueda comprobar la fatiga generada tras su uso.

Sin embargo, esta parte del test se desarrollará en la otra

perspectiva, dejando este test para una primera interacción del

usuario con CloudCompare y el plugin desarrollado, viendo

todos los gestos que puede realizar e interaccionando de forma

libre con ellos (aprendiendo tanto el software como la interfaz)

durante 5 minutos.

Se pedirá al usuario el uso de todos los gestos varias veces

para posteriormente hacer una primera valoración acerca de la

fatiga generada por cada gesto, valorada de la siguiente forma:

1) Imposible 2) Irritante 3) Cansado

4) Un poco cansado 5) Sin problema

Interacción con el plugin (usabilidad, precisión, suavidad, fatiga,

etc). Para la realización de esta parte usaremos la recomendación

dada en el test 3, debiendo realizar el usuario 2 tareas con nubes de

puntos, a las cuales se les impondrán unas restricciones de uso.




Dichas tareas serán las siguientes:

o Marcar el contorno de la nube de puntos (cabeza) por la cara

delantera y posteriormente por la cara trasera. Tras esto, hacer

zoom sobre una oreja y marcar el contorno. Finalmente

restaurar.

Restricciones:

Cambiar de herramienta mediante gestos

Para rotar usar la rotación mediante “interruptor”

Para hacer zoom usar 1 mano

o Existen 4 nubes de puntos que representan 4 cabezas. Mueve

cada cabeza a una esquina de la pantalla. Cada vez que hagas

esto realiza una de las siguientes tareas sobre la cabeza:

Gira en el eje X 90º aproximadamente

Gira en el eje Z 90º aproximadamente

Haz zoom de aumento

Haz zoom de disminución.

Finalmente restaura todas las nubes a su posición original.

Restricciones:

Para rotar usar la rotación mediante “eje + ratón”

Para hacer zoom usa 2 manos

Tras la realización de ambas tareas el usuario podrá valorar la fatiga

generadas en el hombro, el brazo, la muñeca y los dedos con la misma

escala asociada a la fatiga mostrada en el test 3.

Además, podrá valorar la suavidad y precisión en la realización de las

tareas, mediante una escala de 1-5, en la que el 1 representa un grado

muy bajo y el 5 un grado muy alto.




Destacar que, en esta parte, la parte examinadora deberá estar atenta

a la realización de gestos de usuarios, ya que tiene que observar y

anotar cada vez que el usuario realiza un gesto de forma correcta e

incorrecta para poder valorar la precisión de la herramienta o dificultad

en la realización de gestos, por ejemplo.

Finalmente, se le pedirá la opinión al usuario acerca de los distintos gestos

realizados, si deben ser cambiados, están bien, producen fatiga, etc. Se le

mostrarán al usuario distintos vocabularios de gestos encontrados en artículos que

puedan servir de inspiración en la sugerencia de un gesto más adecuado que se

asocie a la realización de una acción.

4.5.6. Reunión

Se consideró oportuno adelantar esta reunión, post-poniendo para después de

esta la realización del test y la recogida de datos, ya que sería conveniente que

antes diera el visto bueno la parte cliente al test creado.

Antes de hablar acerca del test, se trataron las mejoras producidas con

respecto el plugin, mostrando el estado definitivo de éste y su funcionamiento en

directo a los tutores. Los mismos dieron el visto bueno al plugin considerando

acabado su desarrollo en esta investigación, cerrando la etapa y abriendo la nueva

de validación de herramienta.

Se mostró una muestra impresa del test a los tutores, que aceptaron las

pruebas a realizar sin poner oposiciones a la parte del usuario. Sin embargo,

rechazaron la idea de un examinador que se fijara en la realización de gestos, ya

que sería una opinión muy subjetiva y presentaría una gran dificultad para captar

todos los gestos y recoger la información de un modo adecuado.

Como solución propuesta por los tutores, se comentó la posibilidad de

automatizar el test y que fuera la propia herramienta la que se encargará de detectar

los gestos y que éstos fueran los correctos. Para la recolección de estos datos, se

planteó la recogida en un documento mediante lenguaje XML, que almacenara una

serie de elementos (gestos), así como sus propiedades (tiempo de realización,

corrección), para una posterior automatización en el análisis de resultados.




4.6. Iteración 6 - Estudio de resultados

4.6.1. Requisitos

Se procede finalmente a la realización de la última iteración que formará parte

de este proyecto de investigación.

Este último periodo se caracterizará por la realización de los tests ya

preparados, la recogida de los datos de los usuarios que los realicen y el análisis de

los mismos para la toma de decisiones futuras.

Se convierte así en una etapa que decidirá el rumbo de la investigación, si ha

resultado positiva y se puede seguir investigando en la misma o similares líneas, o

por el contrario, si se debería posponer la idea de dejar obsoletos al ratón y el

teclado en la interacción con colecciones de nubes de puntos.

Los objetivos que nos quedarían por resolver en esta etapa son los listados a

continuación:

Automatización de los resultados de los tests de interacción.

Creación de un lenguaje XML que mejore el tratamiento de datos.

Realización y recogida de datos del test de prueba.

Ordenación de datos y realización de estadísticas de uso.

Análisis sobre los resultados obtenidos.

Desarrollo futuro.

Antes de realizar el objetivo pendiente de la iteración anterior (realización de

los tests) se trabajará en la automatización de la herramienta que nos ayude en la

recogida de datos para poder proceder con ellos de una forma más sencilla

posteriormente.

4.6.2. Automatización del test

Es necesario la realización de un nuevo plugin a partir del nuestro para poder

utilizar un plugin en la realización de tests y el otro en el trabajo normal con la

herramienta.




Para la automatización en la recogida de resultado del tests, debemos de

eliminar la máquina de estados anteriormente diseñada, para obtener un único

estado que sea capaz de detectar cada uno de los gestos que se puedan realizar,

mostrando así tanto los errores como los aciertos en el proceso.

Esta es una tarea compleja, ya que para detectar cada uno de los gestos, es

necesario estar muy seguro de que realmente se está realizando dicho gesto. Esto

se traduce en invertir un mayor número de frames para la detección de los gestos,

aumentando la brusquedad de la solución que pasara a realizar movimientos cada

más tiempo y con un mayor grado.

Por otro lado, sería necesaria la división previa de la tarea original en una

secuencia de acciones (realizados por gestos) a completar para considerar

finalizada la tarea global.

Un ejemplo de tarea y su división podría ser:

Tarea: “Marcar puntos y rotar la figura”

División: Cambiar herramienta -> Marcar -> Cambiar Herramienta -> Rotar

Sería necesario la identificación de cada gesto con un numero entero, por

ejemplo, para facilitar las tareas de reconocimiento de gestos.

El funcionamiento de este test se basaría en realizar una secuencia de gestos,

en el que en cada momento solo se podría realizar el gesto actual (en la secuencia)

y el siguiente, para poder avanzar de forma adecuada. En el ejemplo anterior, si

acabamos de realizar el gesto de marcar, este sería nuestro gesto actual, pudiendo

marcar tanto tiempo como queramos o cambiar de herramienta (gesto siguiente), no

permitiendo la realización de otro gesto (pero sí se tomarán registros de ellos).

En resumidas cuentas, cada herramienta, cada un cierto número de frames

que permita reconocer con seguridad la realización del gesto, realizará una acción

siempre y cuando el gesto cumpla las condiciones anteriores y además, avisará a la

clase principal de su realización, para que esta tome registro de ello.




Ilustración 4.78 – Reconocimiento de gestos en el test.

Especificar que si el gesto no es detectado en ese periodo se le informará de

manera pertinente a la clase principal para el reconocimiento de periodos de

inactividad.

Todas las herramientas cuando pasa el periodo de tiempo deberán mandar si

su gesto asociado ha sido reconocido o no. Si ningún gesto ha sido reconocido se

tomará nota de un periodo de inactividad que durará hasta que se reconozca algún

tipo de gesto.

Cuando se reconoce un gesto, se apunta su identificador, así como el tiempo

en el que se reconoció (para calcular duración de gestos). Si se trataba de un gesto

erróneo, éste será considerado como realizado cuando correspondía realizar otro.

En el caso de que el gesto sea correcto (y además el siguiente a realizar),

avanzarán los identificadores de los gestos que se pueden realizar y se comprobará

si se trataba del gesto final de la secuencia, en cuyo caso se volcarán los datos

anotados en un documento de texto que los recoja.




Ilustración 4.79 – Procesamiento de gesto reconocidos y sin reconocer.

Finalmente, para una posterior automatización de los datos recogidos, se

optará por registrarlos mediante el lenguaje XML a través de funcionalidades

implementadas en QT.

Serán necesarios una serie de elementos en lenguaje XML que representen a

cada uno de los gestos posibles a realizar, al tiempo transcurrido realizando dicho

gesto, así como el tiempo total en la realización de un gesto y la actividad a la que

pertenece.

Nuestro documento tomará una estructura jerarquizada, en la que nos

encontramos en primer lugar con el elemento padre, representado por la actividad

principal. Este elemento se subdividirá en estructuras de menor tamaño que

almacenan los gestos que conforman la tarea y todo lo relacionado con ellos.

Para cada gesto se guardan los gestos erróneos realizados hasta llegar al

correcto y los periodos de inactividad, además del tiempo de duración de cada uno.

Al final, a modo de resumen se indicará el tiempo total necesario para la realización

del gesto completo.

Este etiquetado resultará de gran utilidad en el procesamiento de los datos

recogidos en la realización de los tests, para la posterior toma de decisiones a partir

de los mismos.




Ilustración 4.80 – Estructura del documento XML de recogida de datos

4.6.3. Realización y recogida de datos del test

Una vez finalizado el test, se procederá a su realización sobre una población de

usuarios, los cuales deberán tener una cierta experiencia en el manejo de nubes de

puntos para poder apreciar de forma más cercana las ventajas y desventajas del

nuevo plugin seleccionado.

Debido a que el plugin fue diseñado tanto para personas diestras como zurdas,

siendo verificado el funcionamiento adecuado de todos los gestos con ambas manos

anteriormente, no será una prioridad en la búsqueda de la población la presencia de

personas zurdas o diestras.

Por otro lado, sí que será un aspecto a tener en cuenta en los usuarios su

propio género, seleccionando tanto hombres como mujeres para la realización del

test.

Finalmente, 11 usuarios llevaron el test a cabo, con una duración de unos 15

minutos cada test y con la recogida de datos tanto por parte del usuario de una

forma más subjetiva (precisión, fatiga, etc) como por parte del propio plugin que




detectará de forma objetiva la realización y el tiempo de cada gesto realizado por el

usuario.

En cuanto a la recolección de los datos, los proporcionados por los usuarios se

agruparán en un fichero que tome todos los datos y los elementos estadísticos

necesarios.

Por otra parte, los datos generados de forma automática por el plugin, fueron

recogidos mediante la creación de un propio programa especialmente dedicado para

ello, gracias a la estructura de los datos en el lenguaje XML, que facilitó este

procesamiento. Este programa recogerá los datos asociados a cada uno de los

gestos, a partir de todos los ficheros generados en los test, fijándose solamente en

los datos referente al gesto buscado.

Los datos recogidos para cada gesto realizado serán los siguientes:

Numero de errores. Número total de errores cometidos (realización de

otros gestos) a la hora de ejecutar un gesto.

Tiempo total del gesto. Periodo de tiempo necesario para llevar a cabo el

gesto (sumando los tiempos de errores, periodos de inactividad, etc).

Tiempo de duración del gesto. Periodo de tiempo en el que se estuvo

realizando el gesto correcto.

Tiempo hasta realizar el gesto. Periodo de tiempo usado antes de

realizar el gesto correcto. (Tiempo desde que se realizó el último gesto

correcto hasta que se realiza el siguiente).

Tiempo de inactividad. Periodo de tiempo en la ejecución de un gesto

que no se estuvo realizando ningún gesto (fallos de captación del

dispositivo o que realmente el usuario no estaba haciendo nada).

Cada vez que una actividad requiera la utilización de un gesto, en nuestro

documento asociado al mismo, se recogerá una línea con todos los datos

mencionados. Una vez obtenidos todos los datos, se obtendrán los datos medios de

cada propiedad.

Nuestro fichero, tendría entonces una apariencia como la siguiente:




Ilustración 4.81 – Resultados del test asociados a un gesto.

4.6.4. Análisis sobre los resultados obtenidos.

El análisis de los datos podemos dividirlo en 3 partes de la siguiente forma:

Benchmark del vocabulario de gestos. Como se indicó en un

principio, esta parte se dividía en 3 tests, los cuales pasamos a observar

los resultados obtenidos:

o Test 1: Adivinar la función. Los usuarios debían tratar de

predecir la acción a partir del gesto mostrado.

Ilustración 4.82 – Resultados del test 1 del benchmark.

0102030405060708090

100

Porcentaje Acierto




Está claro que la mayoría de los gestos fueron acertados por gran

parte de la población, teniendo que considerar seriamente un

posible cambio sobre los gestos de cambiar herramienta o

restaurar.

En lo referente al cambio de herramienta habría que indicar que

casi ningún usuario sabía que los gestos también interaccionarían

con la interfaz, por lo cual no consideraron dicha posibilidad.

o Test 2: Memoria. En esta ocasión se mostraba una presentación

con los nombres de las acciones y los usuarios debían de realizar

el gesto, reiniciando la presentación en caso de que el

participante errara el gesto.

Para la correcta compresión de la gráfica, recordad que los test

se realizaron sobre 11 usuarios.


Podemos sacar en claro que los gestos fueron bien diseñados en

lo que a memoria se refiere, ya que solo 3 personas erraron una

única vez en la realización de los gestos.

o Test 3: Fatiga. Cada usuario medía a través de una escala la

fatiga generada tras la realización de cada gesto definido en el

vocabulario en varias ocasiones.

0

2

4

6

8

10

0 1 2 3 4 o mas

Personas





Observando la gráfica, la mayoría de gestos se realizan sin

causar fatiga alguna o muy poca. Sin embargo, de nuevo tanto el

gesto de “cambiar herramienta” como el de “restaurar” obtienen

peores resultados, siendo claros candidatos a ser sustituidos por

otro gesto en desarrollos futuros.

Realización de tareas. En este apartado recogeremos las opiniones

personales de los encuestados acerca del nuevo paradigma de

interacción a través del plugin desarrollado mediante Leap Motion en

CloudCompare.

Ilustración 4.85 – Resultados del test de fatiga tras realizar las actividades

0

2

4

6

8

10

12

Fatiga asociada a los gestos

Imposible Irritante Cansado Un poco cansado Sin problema

0

2

4

6

8

10

12

14

16

Imposible Irritante Cansado Un poco cansado Sin problema

Fatiga Generada

Fatiga general Fatiga hombro Fatiga brazo Fatiga muñeca Fatiga dedos




Retomando el tema anterior de la fatiga, la anterior tabla recoge la fatiga

generada en las distintas partes de la extremidad tras realizar las tareas

del test.

Los resultados indican la casi inexistencia de fatiga generada con

nuestro vocabulario de gestos, observando que la generada

principalmente recae en la muñeca y el brazo, por lo que serán aspectos

primordiales a tener en cuenta en un futuro diseño de nuevos gestos.

En cuanto al tema de la precisión y suavidad de la herramienta, los

usuarios se muestran contentos con los resultados obtenidos en sus

interacciones, según indican las siguientes estadísticas:

Ilustración 4.86 – Resultados del test de precisión y suavidad tras realizar las actividades

Finalmente se preguntó a los usuarios acerca de la preferencia de uso

de nuevas tecnologías frente a las actuales desarrolladas mediante

teclado y ratón, siendo los resultados aplastantes a favor de los nuevos

dispositivos:




Ilustración 4.87 – Resultados del test sobre la preferencia ante sistemas tradicionales

Resultados reales de la interacción. Los datos más relevantes que

podemos obtener de este apartado, es la tasa de acierto en la

realización de cada gesto.

Ilustración 4.88 – Resultados de precisión en la realización de gestos del test.

Como vemos, la tasa de acierto se sitúa en torno al 70-80% de media

para los gestos, indicando una buena compresión y memorización por

parte de los usuarios, que normalmente evitan la confusión con otros

gestos del vocabulario.

Por otro lado, también tendrá mucho interés la obtención de la

precisión con la que cuenta Leap Motion a la hora de reconocer gestos.

Estos datos son difíciles de obtener de forma real, ya que, aunque el

plugin asociado al test reconozca todos los gestos hechos, esto no nos

indica si un usuario ha intentado realizar varias veces un gesto,

0

2

4

6

8

10

SI NO NS/NC

Preferencia Sobre Sistema Tradicional

0102030405060708090

100

Porcentaje Acierto




realizándolo hasta de forma correcta, pero el dispositivo ha sido

incapaz de reconocerlo.

En un acercamiento, podemos tratar con los datos del tiempo

transcurrido antes de la realización del gesto, vigilando los tiempos de

realización de otros gestos (errores) y los periodos de inactividad (fallos

del dispositivo o inactividad verdadera).

Ilustración 4.89 – Distribución del tiempo antes de realizar el gesto correcto

En la gran parte de los gestos, el tiempo dedicado a la inactividad suele

ser mayor al dedicado a otros gestos (realizados por error). Es difícil de

obtener resultados precisos a través de estos datos, pero cabe

destacar que es raro que los usuarios estén inactivos durante esos

largos periodos de tiempo (como media de los resultados) y que muy

probablemente, estos periodos se deban a fallos en la captación de

gestos, ya sea por parte del usuario que no lo entendió del todo bien el

gesto a realizar o por parte del dispositivo que sea incapaz de

reconocerlo, necesitando de mejoras en este campo.

Sería necesario un estudio más en profundidad para el análisis de

estos tiempos, pero se escapa de la finalidad de este proyecto, que,

tras estos análisis y a falta de la última reunión, quedaría concluido.

0

2

4

6

8

10

12

Tiempo antes de realizar gestos

Tiempo hasta realizar gesto Tiempo inactividad Tiempo otros gestos




4.6.5. Reunión y trabajo futuro

En la última reunión se mostró todo el proyecto finalizado a los tutores,

incidiendo sobre las novedades en la automatización del test, que podría servir para

futuros test en caso de continuar con el desarrollo de la herramienta, así como todas

las herramientas de procesamiento creadas para su tratamiento más sencillo y

automatizado.

A partir de esta recogida de datos automáticas a través del lenguaje XML,

surge como proyecto de futuro, por la parte de los tutores, una posible construcción

de un sistema remoto, en el que se pudiera colaborar entre varias personas al

mismo tiempo, ya que las acciones asociadas a gestos se podían representar

mediante el lenguaje creado, el cual es fácil y rápido de transmitir al ser unas

simples palabras.

Por otro lado, en cuanto a los resultados del test, determinaron la necesidad de

buscar y sustituir algunos de los gestos que peores resultaron obtuvieron, así como

la posibilidad de esperar un tiempo ante desarrollos futuros, en busca de una mejora

de precisión del dispositivo Leap Motion.

El proyecto, al no haber más sugerencias de cambios por parte de los tutores,

quedó de esta forma como finalizado.

En general, la parte cliente se mostró contenta con el rumbo que había tomado

el proyecto de investigación, viéndole muchas posibilidades de desarrollos futuros,

tanto de forma individual, como en compenetración con otros dispositivos estudiados

(HTC Vive o tableta digitalizadora), que posibiliten la sustitución del antiguo

paradigma teclado-ratón por uno más actual.

En este momento, y a la espera de posibles mejoras en el Leap Motion,

resultaba conveniente difundir esta investigación lo máximo posible para que pueda

llegar la información a todo el mundo y se posibilite la transición marcada como

objetivo en esta línea de investigación.




5. ANEXO

5.1. Póster CEIG

A continuación, y en relación a lo comentado al final del apartado anterior

acerca de la difusión del proyecto de investigación, este trabajo se envió como

póster para la exposición en el CEIG (Congreso Español de Informática Gráfica),

siendo aceptado.

Ilustración 5.1 – Póster para el CEIG 18




Bibliografía Belda, J. (s.f.). Api de Leap Motion. Obtenido de http://blog.showleap.com/2015/05/leap-

motion-api/

Bowman, D. A. (1999). Interaction techniques for common tasks in immersive virtual

enviroments.

CloudCompare. (s.f.). Obtenido de http://www.cloudcompare.org/

Dong, H., Ali, D., Figueroa, N., & El Saddik, A. (2015). An Elicitation Study on Gesture

Preferences and Memorability Toward a Practical Hand-Gesture Vocabulary for

Smart Televisions.

Föhrenbach, S. (2009). Hand Gesture Interaction for Large High-Resolution Displays.

Jerald, J., La Viola, J., & Marks, R. (2017). VR interactions.

Kundu, M., Mitra, S., & Mazumdar, D. (2012). Perception and Machine Intelligence.

Leap Motion. (s.f.). Obtenido de https://www.leapmotion.com/

Lee, J., Kim, B., Suh, B., & Koh, E. (s.f.). Exploring the Front Touch Interface for Virtual

Reality Headsets.

Mark, M., Brooks, F., & Sequin, C. (1997). Moving objects in space: exploiting proprioception

in virtual-environment interaction.

Mulder, A. (1996). Hand Gestures for HCI.

Naik, G., Kant Kumar, D., Pan Singh, V., & Palaniswami, M. (s.f.). Hand gestures for HCI

using ICA of EMG.

Nielsen, M., Störring, M., Moeslund, T., & Granum, E. (2014). A procedure for developing

intuitive and ergonomic.

Pereira, A., Wachs, J., & Park, K. (2014). A User-Developed 3-D Hand Gesture Set for

Human–Computer Interaction.

Plemmons, D., & Mandel, P. (s.f.). Introduction to Motion Control. Obtenido de

https://developer-archive.leapmotion.com/articles/intro-to-motion-control

Rempel, D., Camilleri, M., & Lee, D. (2015). The Design of Hand Gestures for Human-

Computer Interaction: Lessons from Sign Language Interpreters.

Steinicke, F., Ropinski, T., & Hinrichs, a. K. (s.f.). Object selection in virtual environments

with an improved virtual pointer metaphor.

Steinicke, F., Ropinski, T., & Hinrichs, K. (s.f.). VR and Laser-Based Interaction in Virtual

Environments using a Dual-Purpose Interaction Metaphor.

estudio de tÉcnicas avanzadas para la interacciÓn...

Documents