Sistema de asistencia al entrenamiento deportivo mediante dispositivos de videojuegos

(1)

SISTEMA DE ASISTENCIA AL ENTRENAMIENTO DEPORTIVO MEDIANTE DISPOSITIVOS DE VIDEOJUEGOS

SR. DIEGO EMILIANOMARTINO

SR. SEBASTIÁNMIGUELSERRITELLA

TRABAJOFINAL - INGENIERÍA DE SISTEMAS

FACULTAD DECIENCIAS EXACTAS

UNIVERSIDAD NACIONAL DEL CENTRO DE LAPROVINCIA DE BUENOS AIRES

Director: DR. CRISTIANGARCÍABAUZA Codirector: DR. JUAND’AMATO

(2)

(3)

R

ESUMEN

E

n los últimos años se ha observado una evolución en los dispositivos utilizados para los videojuegos cambiando la forma de interacción entre el usuario y la consola. Estos dispositivos contienen sensores que capturan los movimientos que realiza el jugador. Existen bibliotecas que permiten leer los sensores y usar esos datos posteriormente. Mediante un conjunto de repeticiones del gesto es posible entrenar una herramienta.

(4)

(5)

D

EDICATORIAS Y RECONOCIMIENTOS

E

n primer lugar queremos dedicar esta tesis a nuestras familias que nos han acompañado en cada uno de los momentos de nuestras vidas, que nos han guiado por un buen camino y por sobre todo que nos han ayudado a levantarnos en nuestras caídas.

A nuestros amigos, con los cuales hemos compartido momentos desde la niñez y a los que hemos ido conociendo a lo largo de nuestras vidas.

Agradecemos a nuestros compañeros de trabajo, por su buena disposición a colaborar con el desarrollo del trabajo. En especial, a los chicos de diseño 3D, sin ellos hubiera sido más largo y complicado el proceso de llevar a cabo esta tesis.

(6)

(7)

Í

NDICE DE

C

ONTENIDOS

Página

Índice de Figuras ix

1 Introducción 1

1.1 Motivación . . . 3

1.2 Objetivo . . . 3

1.3 Organización del documento . . . 4

2 Marco Teórico 5 2.1 Nuevos enfoques de interación . . . 5

2.2 Tecnología en el deporte . . . 6

2.2.1 Raqueta de tenis de Babolat . . . 7

2.2.2 Smartball de Adidas . . . 8

2.3 Nintendo Wii . . . 9

2.3.1 Wii Remote . . . 9

2.3.2 Wiimotion Plus . . . 11

2.3.3 Reconocimiento de gestos con Wiimote . . . 12

2.4 Oculus Rift . . . 12

2.5 Motor gráfico: Ogre 3D . . . 14

2.5.1 Conceptos básicos . . . 15

2.6 Motor físico: Bullet Physics . . . 16

2.6.1 Conceptos básicos . . . 16

3 Diseño e Implementación 19 3.1 Introducción . . . 19

3.2 Vista general del sistema . . . 20

3.2.1 Módulo Devices . . . 21

3.2.1.1 DeviceManager . . . 21

(8)

ÍNDICE DE CONTENIDOS

3.2.2 Módulo Model . . . 28

3.2.2.1 ValueStroke . . . 29

3.2.2.2 Stroke . . . 30

3.2.2.3 Template . . . 31

3.2.2.4 TemplateTools . . . 31

3.2.2.5 DataManager . . . 32

3.2.2.6 Profile . . . 33

3.2.2.7 AppManager . . . 34

3.2.3 Módulo Strategies . . . 35

3.2.3.1 Strategy . . . 35

3.2.3.2 StrategyDTW . . . 36

3.2.3.3 StrategyInside . . . 38

3.2.4 ResultStrategy . . . 41

3.2.4.1 ResultStrategyDTW . . . 42

3.2.4.2 ResultStrategyInside . . . 42

3.2.5 Módulo Controllers . . . 44

3.2.5.1 Módulo Command . . . 44

3.2.5.2 Presentación de datos: Módulo ChartHandler . . . 45

3.3 Diagrama de clases del sistema . . . 47

4 Instanciación 49 4.1 Introducción . . . 49

4.2 Aplicación Editor de Perfiles . . . 49

4.2.1 Administración de Perfiles . . . 51

4.2.2 Definición de tipos de golpe . . . 52

4.2.3 Captura de un nuevo golpe . . . 54

4.2.4 Generación de un nuevo Template . . . 54

4.2.5 Estrategias de comparación . . . 57

4.2.5.1 Comparación Golpe-Template . . . 57

4.2.5.2 Mejor coincidencia Golpe-Templates . . . 61

4.2.6 Configuraciones . . . 64

4.2.6.1 Configuración de estrategias . . . 64

4.2.6.2 Configuraciones de dispositivo . . . 65

4.3 Visualizador 3D . . . 67

4.3.1 Carga de escenas 3D . . . 67

4.3.2 Configuración del escenario . . . 68

4.3.3 Integración del motor gráfico con el motor físico . . . 71

4.3.4 Instructor . . . 74

4.3.4.1 Comunicación Instructor-Servidor-Visualizador . . . 75

(9)

ÍNDICE DE CONTENIDOS

4.3.5 Ejercicios . . . 77

4.3.5.1 Configurador de ejercicios . . . 78

4.3.5.2 Ejercicio libre . . . 79

4.3.5.3 Ejercicio de potencia . . . 80

4.3.5.4 Ejercicio de precisión . . . 82

4.3.5.5 Ejecución del ejercicio . . . 86

4.3.5.6 Mostrar trayectoria de la pelota . . . 88

4.3.5.7 Ojo de halcón . . . 90

4.3.6 Visualizador en Oculus Rift . . . 91

4.3.6.1 Proceso de inicialización y configuración de la aplicación con Oculus Rift . . . 91

5 Conclusiones y trabajos futuros 93 5.1 Conclusiones . . . 93

5.2 Limitaciones del sistema . . . 94

5.3 Trabajos futuros . . . 95

A Apéndice 97 A.1 Captura de datos . . . 97

A.1.1 Saturación de sensores . . . 98

A.2 Biblioteca Wiiyourself . . . 99

A.3 Algoritmo DTW . . . 99

(10)

(11)

Í

NDICE DE

F

IGURAS

FIGURAS Página

1.1 Simuladores . . . 2

2.1 La tecnología en los deportes . . . 6

2.2 Raqueta inteligente . . . 7

2.3 Pelota inteligente de Adidas . . . 8

2.4 Consola de VideoJuegos Nintendo Wii . . . 9

2.5 Hardware del Wii Remote . . . 10

2.6 Barra del Wii Remote . . . 11

2.7 Sensor Wiimotion Plus . . . 11

2.8 Dispositivo Oculus Rift . . . 12

2.9 Sensores de rotación del Oculus Rift . . . 13

2.10 Sensores de tracking del Oculus Rift . . . 14

3.1 Vistal general del sistema . . . 20

3.2 Diagrama de flujo de los distintos módulos . . . 20

3.3 Clase Abstracta IDevice . . . 21

3.4 Clase Device Manager . . . 22

3.5 Clase Device Wiimote . . . 22

3.6 Diagrama de secuencia de conexión del dispositivo Wiimote . . . 24

3.7 Diagrama de secuencia de la captura de los gestos mediante el dispositivo Wiimote . 25 3.8 Clase DeviceWiiMotionPlus . . . 25

3.9 Clase Properties . . . 26

3.10 Módulo Model . . . 28

3.11 Clase ValueStroke . . . 29

3.12 Clase Stroke . . . 30

3.13 Clase Template . . . 31

3.14 Clase TemplateTools . . . 32

(12)

ÍNDICE DEFIGURAS

3.18 Clase Strategy . . . 35

3.19 Diferencias entre distancia euclidiana y DTW . . . 36

3.20 Clase Strategy DTW . . . 38

3.21 Esquematización del canal de aceptación y los intervalos extendidos para un margen de error del 50 % de la estrategia Inside . . . 39

3.22 Esquematización del canal de aceptación y los intervalos extendidos para un margen de error del 25 % de la estrategia Inside . . . 40

3.23 Clase Strategy Inside . . . 40

3.24 Clase ResultStrategy . . . 41

3.25 Clase ResultStrategyDTW . . . 42

3.26 Clase ResultStrategyInside . . . 42

3.27 Módulo Controller . . . 44

3.28 Clase Command . . . 45

3.29 Clase ChartHandler . . . 45

3.30 Módulo ChartHandlers . . . 46

3.31 Diagrama de clases del sistema . . . 47

4.1 Aplicación Editor de Perfiles . . . 50

4.2 Cuadro de diálogo para la creación de un perfil . . . 52

4.3 Cuadro de diálogo para la edición de tipos de golpes . . . 53

4.4 Control del asistente para la creación de un nuevo golpe . . . 55

4.5 Control del asistente para la creación de un nuevo template . . . 56

4.6 Control del asistente para la creación de un nuevo template capturando golpes dirigi-dos a la esquina izquierda del lado destino de la cancha. . . 57

4.7 Comparación entre un Golpe y un Template mediante la estrategia Inside . . . 59

4.8 Comparación entre un Golpe y un Template mediante la estrategia DTW . . . 60

4.9 Mejor coincidencia mediante estrategia Inside . . . 62

4.10 Mejor coincidencia mediante estrategia DTW . . . 63

4.11 Ventana de configuración general de las estrategias . . . 64

4.12 Ventana Configuración de estrategias . . . 65

4.13 Vista aérea del estadio . . . 67

4.14 Clase SceneManager . . . 68

4.15 Posiciones relativas de los límites de una cancha singles . . . 69

4.16 Cancha de tenis a escala . . . 70

4.17 Comunicación de datos entre un motor gráfico y un motor físico . . . 71

4.18 Visualización física de los objetos . . . 74

4.19 Diagrama de Actividades de Estados de la Aplicación . . . 75

4.20 Vista esperando Servidor . . . 76

4.21 Clase Exercise . . . 77

(13)

ÍNDICE DEFIGURAS

4.22 Pantalla de Configuración de Nuevo Ejercicio . . . 78

4.23 Pantalla de Configuración de Nuevo Ejercicio . . . 79

4.24 Pantalla de Configuración de Ejercicio Potencia . . . 80

4.25 Visualizador en ejercicio de potencia . . . 81

4.26 Acelerómetros en un golpe con potencia . . . 82

4.27 Pantalla de Configuración de Ejercicio Potencia . . . 82

4.28 Vectores de dirección de los templates complementarios . . . 83

4.29 Pantalla del ejercicio en ejecución . . . 87

4.30 Visualizador en ejercicio de precisión mostrando trayectoria de la pelota . . . 88

4.31 Visualizador en ejercicio de precisión mostrando las trayectorias de las pelotas . . . . 89

4.32 Visualizador en ejercicio de precisión mostrando el pique de la pelota, luego de ejecutar la animación del ojo de halcón . . . 90

4.33 Visualizador en Oculus Rift . . . 92

(14)

(15)

Í

NDICE DE

A

LGORITMOS

ALGORITMOS Página

3.1 Wiimote::Wiimote . . . 26

3.2 WiiMotionPlus::WiiMotionPlus . . . 27

3.3 Wiimote::CaptureStroke . . . 29

3.4 StrategyInside::Inside . . . 39

3.5 ResultStrategy::ResultStrategy . . . 41

3.6 StrategyInside::Execute . . . 43

4.1 NewProfile::Execute . . . 51

4.2 EditTypeStroke::Execute . . . 52

4.3 NewStroke::Execute . . . 54

4.4 NewTemplate::Execute . . . 55

4.5 ExecuteComparisonInside::Execute . . . 58

4.6 ExecuteComparisonDTW::Execute . . . 60

4.7 ExecuteBestAgreementInside::Execute . . . 61

4.8 ExecuteBestAgreementDTW::Execute . . . 62

4.9 CustomMotionState::SetWorldTransform . . . 72

4.10 Algoritmo para crear representación visual y física de la pelota . . . 73

4.11 TennisCourt::isContainDestinationSide . . . 79

4.12 VisualExercise::startExercise . . . 89

(16)

(17)

C

A

P

Í

T

U

L

O

1

I

NTRODUCCIÓN

E

n los últimos años se han realizado nuevos avances revolucionarios en tecnología, es-pecialmente en la interfaz básica entre el humano y los sistemas de computación [1]. Estas nuevas tecnologías permiten formas alternativas de las tradicionales técnicas de interacción (mouse y teclado), mediante capturas de gestos, uso de acelerómetros y otros sensores.

En particular, existen diversos dispositivos que permiten capturar los movimientos que el usuario realiza con el brazo que han sido desarrollados para diferentes consolas de videojuegos, tales como Wiimote [2] y el PS3Move [3]. Ambos dispositivos se conectan vía protocolo Bluetooth y brinda una nueva experiencia en el uso de estos, como se propone en [4]. Por otro lado, se han desarrollado dispositivos que permiten capturar gestos de cualquier extremidad del jugador, por ejemplo Kinect [5].

Este tipo de dispositivos cuentan con la conjugación de proveer información precisa y su valor es de muy bajo costo. En especial, los controles Wiimote y PS3Move cuentan con sensores acelerómetros, giróscopos y magnetómetros [6]. Si bien el muestreo de estos sensores es limitado, se puede recrear el movimiento realizado y proyectarlo en espacio y tiempo.

(18)

CAPÍTULO 1. INTRODUCCIÓN

(a) Detrás de escena de filmación (b) Escena renderizada

Además del nivel de detalle también se ha logrado que el usuario se sienta inmerso en el entorno tridimensional, el cual se manipula a través de dispositivos como cascos, guantes, entre otros, que capturan la posición y rotación de las diferentes partes del cuerpo humano.

(a) Simulador de vuelo de pájaro usando Oculus Rift (b) Simulador de Fórmula 1 del equipo Mc Laren

(c) Simulador de vuelo Boeing 787 (d) Cabina de un simulador de vuelo

Figura 1.1: Simuladores

En este caso, el campo que ha incorporado esta tecnología es el de los simuladores, tal como los

(19)

1.1. MOTIVACIÓN

de vuelo y los deFórmula 1entre los más destacados. Muchas otras disciplinas han incorporado simuladores para realizar sus prácticas ya que el usuario puede aprender sin poner en riesgo su vida o la de terceros, incluso poder realizar situaciones difíciles de replicar.

1.1 Motivación

Actualmente en muchas aplicaciones la interacción del usuario se está alejando del uso de mouse, teclado o lápices ópticos, y se está convirtiendo en algo mucho más físico y tangible. Nuevas tecnologías emergentes, permiten desarrollar y experimentar con nuevos métodos de interacción para proporcionar una intuitiva comunicación humano-computadora.

Existen diversos trabajos académicos, comerciales y personales centrados en la interacción del Wiimote-PC y PS3Move. Sin embargo, en el marco de la simulación de deportes como el tenis, no se registran aplicaciones correspondientes ya que las existentes pertenecen a la categoría de arcade.

En [7] se desarrolló un prototipo para captura de golpes de tenis. Si bien este sistema integraba un control Wiimote y utilizaba un entorno 3D con distintos escenarios de prueba, permitiendo reconocer distintos golpes e interactuar con objetos; el sistema es mejorable. Para ello se propone continuar la línea iniciada con dicho trabajo buscando mejoras en la precisión de captura de los movimientos y en la visualización de los escenarios. Además, realizar una plataforma en la que puedan participar distintos dispositivos para la captura de los movimientos y generar una abstracción para utilizar distintas estrategias de comparación.

1.2 Objetivo

La meta de este trabajo es diseñar una solución que mejore la detección de movimientos de la herramienta existente aplicada en golpes de tenis. Para ello se pretende capturar movimientos del brazo a través de dispositivos de captura [8], tales como Wiimote y PS3Move; recreando luego el golpe en un escenario 3D virtual [9]. Básicamente la idea es desarrollar una nueva aplicación que ofrezca más y mejores características de acuerdo a las tecnologías actuales.

Además de realizar la captura de los movimientos, la utilidad fundamental que se ofre-ce mediante la herramienta es la posibilidad de generar un historial del jugador y realizar comparaciones a lo largo del tiempo evaluando la evolución propia del jugador [10] o también comparándolo con otros jugadores de su misma categoría o incluso con jugadores profesionales de primer nivel.

(20)

CAPÍTULO 1. INTRODUCCIÓN

comparaciones de estas curvas, primero se debe remuestrear el conjunto para obtener datos uniformes.

Para ello, se estudiaron diversos algoritmos para interpretar los datos y comparar los resulta-dos obteniresulta-dos en casos de uso reales. Para realizar estas comparaciones se utiliza el algoritmo propuesto en [8] llamado DTW (Dynamic Time Warping), el cual mide las similitudes entre dos secuencias en las que el tiempo y la velocidad pueden variar. Se evaluaron otras alternativas donde la precisión tome un lugar más protagónico y comparar los resultados obtenidos con los diferentes algoritmos.

En cuanto al desarrollo del entorno tridimensional, se estudiarán distintas alternativas de motores gráficos existentes de manera detallada. Para la simulación de las interacciones físicas de la aplicación, también se estudiarán distintos motores de simulación de comportamiento físico como se cita en [12] donde se pueden apreciar distintas alternativas, ya sean privativas o Licencia Pública General (GPL).

También está la posibilidad de proveer el prototipo a las escuelas locales de tenis, con la intención de ofrecerles una alternativa para sus entrenamientos y capacitaciones. Además, por otra parte, podremos obtener resultados cuantitativos y cualitativos, para además saber si los valores obtenidos de las distintas pruebas mantienen un patrón con el cual se podrán realizar futuras comparaciones.

1.3 Organización del documento

La organización del trabajo, está dada de la siguiente manera:

El Capítulo 2 introduce todos los conceptos teóricos aplicados en el presente trabajo, para ello se presentan las tecnologías utilizadas, tanto los dispositivos como los motores físicos y gráficos. En el Capítulo 3, se detalla el diseño y la implementación de la plataforma junto con todas las decisiones de diseño que se tomaron para su desarrollo.

En el Capítulo 4, se presenta y detalla la instanciación que se realizó sobre el modelo de datos, de la que se desprenden dos aplicaciones.

Finalmente, en el Capítulo 5, se presentan las conclusiones finales del trabajo, junto con posibles extensiones.

Además, en el Apéndice se detallaron algunas explicaciones que incidieron en el diseño y en la implementación del sistema.

Por último, se listan las referencias bibliográficas consultadas durante la implementación del presente trabajo.

(21)

C

A

P

Í

T

U

L

O

2

M

ARCO

T

EÓRICO

C

omo se viene observando en los últimos años, existe en el mercado una gran cantidad de dispositivos reconocedores de gestos realizados por el ser humano. Algunos proveen la capacidad de reconocer gestos realizados con todo el cuerpo y otros permiten reconocer con mayor precisión tan sólo alguna extremidad. Estos dispositivos fueron creados especialmente para utilizarse mediante alguna consola de videojuegos, creando así una nueva era de interacción entre el usuario y la consola.

2.1 Nuevos enfoques de interación

En los últimos años han surgido diferentes enfoques que utilizan sensores y dispositivos para capturar los movimientos de los usuarios. Los dispositivos portátiles de mano, como guantes sensores han sido utilizados, aunque suelen ser caros e intrusivos para los usuarios. Otros dispositivos inalámbricos no intrusivos, como el controlador de la consola Nintendo Wii han aparecido para superar estos inconvenientes.

Adicionalmente, otros sensores libres de contacto (es decir, aquellos en los que no es necesario que el usuario los toque o los tenga en su mano) han aparecido para detectar movimientos, como el sensor Leap Motion [13] que detecta movimientos de dedos o sensores para detectar gestos corporales como el sensor Kinect [14].

(22)

CAPÍTULO 2. MARCO TEÓRICO

Además, otro dispositivo que está en fases finales de desarrollo es el Oculus Rift [16]. El Oculus es un casco de realidad virtual que cuenta con una pantalla de gran resolución que se sitúa muy cerca de los ojos. Además, contiene ciertos sensores que detectan el movimiento de la cabeza.

2.2 Tecnología en el deporte

En los últimos años, el avance tecnológico ha sido el más importante de la historia. Se crearon diversos sensores y dispositivos que están siendo utilizados por jugadores profesionales. Estos sensores captan información del profesional realizando su actividad. Esta información generalmente es analizada con especialistas del área junto al jugador para indicarle ciertas recomendaciones al momento de realizar la actividad.

(a) Ciclismo (b) Golf

(c) Running (d) Natación

Figura 2.1: La tecnología en los deportes

Los científicos han creado, por ejemplo, para los nadadores trajes que disminuyen la fuerza de rozamiento del agua. Otro caso, en el mundo del ciclismo, donde se crean distintos componentes

(23)

2.2. TECNOLOGÍA EN EL DEPORTE

que sean ultralivianos y lo suficientemente fuertes. Han trabajado también en la aerodinámica de los autos, motos y bicicletas buscando la mayor eficiencia posible.

Pero no sólo han trabajado en mejorar la performance, sino también se ha instalado la tecnología para fiscalizar los deportes, como la toma de tiempos o revisar un video en el caso del rugby.

2.2.1 Raqueta de tenis de Babolat

Es una raqueta de tenis que cuenta con sensores que detectan las vibraciones y movimientos de las cuerdas. Estos sensores están ubicados en el interior del mango y se pueden obtener los datos capturados a través de un cable USB o bluetooth.

Figura 2.2: Raqueta inteligente

Contiene sensores acelerómetros, giróscopos y un sensor piezoeléctrico. Mientras los aceleró-metros calculan la dirección de la raqueta y los giróscopos determinan qué golpe realiza, el sensor piezoeléctrico analiza la vibración de la raqueta para encontrar el punto de impacto entre las cuerdas y la pelota.

Mediante los sensores y procesamiento que realiza un microprocesador en la raqueta se puede obtener el número de golpes, dónde se produce el impacto, el nivel de efecto de la pelota y la distancia recorrida por el jugador.

(24)

2.2.2 Smartball de Adidas

Es una pelota de tamaño reglamentario N◦_{5 que tiene integrado unos sensores ubicados y} suspendidos en el centro de la pelota. Permiten analizar las fuerzas ejercidas sobre la pelota mientras se desplaza.

Figura 2.3: Pelota inteligente de Adidas

Mediante los sensores propios de la pelota y una serie de algoritmos, provee la información de la velocidad, la flexión, la posición del impacto pie-pelota y la trayectoria del disparo. Ésta se envía por bluetooth a un smartphone que tenga instalada la aplicación que provee la empresa.

Los datos generados por la pelota pueden ser obtenidos únicamente mediante la aplicación, por lo tanto, no se puede hacer ningún análisis acerca de los mismos.

(25)

2.3. NINTENDO WII

2.3 Nintendo Wii

Es una consola de videojuegos lanzada en 2006. Pertenece a la séptima generación, junto a

Play Station 3 de SonyyXbox 360 de Microsoft, las que introdujeron controles inalámbricos y detección de movimientos.

La principal virtud que contó esta consola es su dispositivo de interacción hombre-consola, el Wiimote, que cambió de manera innovadora el paradigma para los videojuegos.

En la Figura 2.4, se puede apreciar la consola Nintendo Wii con su respectivo control.

Figura 2.4: Consola de VideoJuegos Nintendo Wii

2.3.1 Wii Remote

El sensor Wiimote [17], desarrollado por Nintendo en 2006 para su consola de videojuegos Nintendo Wii, tiene como característica más destacada la capacidad de detectar movimientos en tres dimensiones y apuntar a objetos en la pantalla. Tiene la particularidad de ser un dispositivo de bajo costo.

(26)

Figura 2.5: Hardware del Wii Remote

El control puede ser tomado de dos formas: vertical (con una mano) y horizontal (con dos manos). Esta última está diseñada para usarse en juegos de conducción y vuelo, además de ser usada para algunos juegos de la consola virtual. El diseño del Wiimote es simétrico, por lo que puede tomarse tanto con la mano derecha como con la izquierda.

En la Figura 2.5 se observa la distribución de los componentes que componen al dispositivo. En la vista perteneciente al frente se destaca el sensor acelerómetro de tres ejes. En la otra, el chip bluetooth, la cámara perteneciente al tracking visual y el conector de expansión.

La cámara de tracking trabaja conjuntamente con una barra que contiene LEDs infrarrojos en los extremos. La barra no genera ningún tipo de información hacia la consola, sino que el dispositivo a través de la cámara de tracking realiza un cálculo trigonométrico, como se ve en la Figura 2.6 y provee a la consola el punto en donde se encuentra apuntando. Para que esto sea efectivo es necesario tener el Wiimote apuntando a la barra, por lo que los usuarios la sitúan debajo o encima de su televisor.

(27)

2.3. NINTENDO WII

Figura 2.6: Barra del Wii Remote

2.3.2 Wiimotion Plus

Wii Motion Plus es un accesorio que incorpora tres sensores de movimiento giroscópicos correspondientes a los ejes vertical, longitudinal y lateral, añadiendo precisión extra al Wiimote.

(28)

2.3.3 Reconocimiento de gestos con Wiimote

El dispositivo no reconoce gestos por sí solo. Su capacidad es la de capturar los movimientos del usuario mediante el control, que contiene los sensores, y proveer a la aplicación de esos valores [18] para analizarlos. Para ello, se debe utilizar una biblioteca [19] que permite capturar los valores de los sensores.

Los sensores del dispositivo se encuentran trabajando todo el tiempo. Otros dispositivos además de proveer los datos sin procesar, contienen un software que detecta el movimiento realizado. Estos movimientos detectados son básicos como por ejemplo, realizar un círculo, un movimiento lateral o vertical.

2.4 Oculus Rift

Figura 2.8: Dispositivo Oculus Rift

El Oculus Rift es un casco de realidad virtual. Contiene una serie de sensores, tales como acelerómetros, giroscopios y magnetómetros. A partir de la versión DK2, lanzada en 2015, se incluyó una cámara externa para trackear la posición de la cabeza del usuario. La información de cada uno de estos sensores se combina para determinar el movimiento de la cabeza del usuario en el mundo real y así, sincronizar la vista virtual del usuario en tiempo real.

La orientación del dispositivo se obtiene como una rotación en un sistema de coordenadas de mano derecha como se ve en la Figura 2.9. Este sistema utiliza las siguientes configuraciones de ejes:

• Y es positivo en la dirección hacia arriba.

• X es positivo en la dirección hacia la derecha.

• Z es positivo en la dirección hacia atrás.

Las rotaciones positivas son en sentido antihorario y se almacenan en un cuaternión.

(29)

2.4. OCULUS RIFT

Figura 2.9: Sensores de rotación del Oculus Rift

• Pitch: rotación alrededor del eje X. Es positivo cuando inclina la cabeza hacia arriba.

• Yaw: rotación alrededor del eje Y. Es positivo cuando gira hacia la izquierda.

• Roll: rotación alrededor del eje Z. Es positivo cuando inclina la cabeza hacia la izquierda, en el plano XZ.

La cámara es necesaria y se utiliza para el tracking de la posición. En la Figura 2.10 se muestra una cámara montada en un monitor de una PC. El frustum representa una figura geométrica, en este caso una pirámide, comprendida entre dos planos paralelos. Se usa como la representación del volumen de visualización de una cámara. Está definido por el campo de visión horizontal y vertical, conocido como FOV (field of view) y los planos de recortes cercano (near) y lejano (far). Los valores delfrustumde la cámara del Oculus son los siguientes (datos obtenidos de la documentación del SDK 0.4.4 del Oculus Rift DK2):

• Campo de visión horizontal (FOVh): 74 grados.

(30)

• Plano de recorte lejano (far) = 2.5 metros.

Figura 2.10: Sensores de tracking del Oculus Rift

La Figura 2.10 muestra también el origen de tracking por defecto y el sistema de coordenadas asociado. Aunque el eje de la cámara (y por lo tanto el tracking del frustum) se muestran inclinados ligeramente hacia abajo, el sistema de coordenadas siempre está orientado horizontalmente, de manera que los ejes X y Z son paralelos al suelo.

Por defecto, el origen del seguimiento de la posición está situado a 1 metro de la cámara en la dirección del eje óptico, es decir, en el eje Z, pero con la misma altura de la cámara. La orientación de origen por defecto es el nivel con el suelo en la dirección del eje Z negativo. En otras palabras, la orientación corresponde con el usuario mirando hacia la cámara, a una distancia de 1 metro y a la misma altura de la cámara.

2.5 Motor gráfico: Ogre 3D

OGRE (Object-oriented Graphics Rendering Engine) [20] es un motor 3D flexible y orientado a la escena escrito en C++ diseñado para hacer más fácil e intuitivo para los desarrolladores producir aplicaciones que utilicen gráficos 3D acelerados por hardware. La biblioteca de clases abstrae todos los detalles del uso de las bibliotecas de sistemas subyacentes, como DirectX y OpenGL, y provee una interfaz basada en objetos del mundo y otras clases intuitivas.

OGRE está diseñado para proveer una solución gráfica que se adapte a la mayoría de los casos; y se pueden encontrar varios frameworks o wrappers que permiten integrar rápidamente distintas bibliotecas para funcionalidad adicional como audio, interacción, etc. Provee un diseño orientado a objetos, minimizando el esfuerzo de renderizar escenas 3D, además se permite

(31)

2.5. MOTOR GRÁFICO: OGRE 3D

extender la funcionalidad a través de plugins y subclases. Ofrece soporte para el manejo de materiales y texturas, manejo de mallas 3D, luces, sombras, entre otros y permite definir el comportamiento de la parte programable de la GPU mediante la definición de shaders.

2.5.1 Conceptos básicos

Existen una serie de conceptos mínimos que se deben comprender a la hora de trabajar con OGRE:

• Root: es el objeto principal dentro de OGRE. Internamente está implementado mediante unSingletonde forma que no sea posible crear más de una instancia de ese objeto. Sirve como fachada a través de la cual realizar cualquier operación dentro de OGRE.

• Ventanas: OGRE permite crear y configurar ventanas sobre la que se renderizarán las imágenes del videojuego o aplicación de desarrollo. Para ello, es necesario la utilización de unacámara. Este objeto es imprescindible ya que representa un punto de vista desde el cual será mostrado el escenario.

• Gestor de recursos: permite leer y cargar en memoria los recursos gráficos necesarios, organizados jerárquicamente por grupos.

• Gestor de escena: se encarga de gestionar todos los objetos que intervienen dentro de la escena: entidades, luces, sombras, etc.

• Grafo de escena: es la estructura de datos que utiliza el motor de renderizado para gestionar elementos dentro de la escena. Dicha estructura está formada por nodos, cada uno de ellos representa un elemento de la escena y se encarga de gestionar las transformaciones geométricas que sufran dichos elementos. Permite hacer optimizaciones sobre el proceso de renderizado, de forma que se desestimen determinados nodos que no van a mostrarse atendiendo a un criterio dado; por ejemplo, que no estén dentro del área que enfoca la cámara (el frustum).

Un gran punto a favor del motor de renderizado OGRE es la documentación disponible ya que cuenta con una vasta cantidad de tutoriales, foros de discusión, ejemplos y una gran comunidad activa de desarrolladores y usuarios que contribuyen al crecimiento y actualización permanente del motor gráfico. Esto hace que un sistema programado sobre OGRE sobreviva en el tiempo y pueda ser extendido o modificado en el futuro.

(32)

2.6 Motor físico: Bullet Physics

Un motor físico es un software que permite resolver diferentes situaciones de simulación computacional, principalmente cuestiones como la dinámica de cuerpos rígidos (incluyendo detección de colisiones), de cuerpos blandos, e incluso de fluidos. Su principal aplicación es en videojuegos y simuladores, en cuyo caso las simulaciones deben ser resueltas con bajo costo computacional, permitiendo el tiempo real.

Un motor físico permite también aplicar impulsos, fuerzas o velocidades en los objetos, de manera tal que se puede recrear un modelo matemático de comportamiento. Es necesario el uso de un motor físico por las siguientes razones:

• Si no se controlan las colisiones entre los cuerpos, éstos se atravesarían entre sí, restando realismo.

• Parte de la mecánica de un juego o simulador puede consistir en hacer chocar unos objetos con otros. Por ejemplo, en nuestra aplicación, la pelota debe chocar contra los ladrillos, donde éstos deben derribarse en la ejecución del ejercicio de potencia.

• Puede ser necesario modelar propiedades físicas. Por ejemplo, en nuestra aplicación, es necesario configurar el coeficiente de restitución de la pelota, el cual indica una medida del grado de conservación de la energía cinética en una colisión.

Existen varios motores físicos disponibles para uso libre o comercial. Entre los más reconocidos se pueden mencionar a Newton Game Dynamics, Open Dynamics Engine, Bullet Physics Library, Havok y PhysX. Adicionalmente, Bullet Physics Library[21] es uno de los motores físicos más reconocidos y ampliamente utilizados en videojuegos comerciales, películas y aplicaciones de diseño. En el sitio web se muestran muchos casos de uso exitoso del motor.

2.6.1 Conceptos básicos

El elemento más importante en Bullet es elWorld. ElWorlddentro de Bullet tiene varias responsabilidades, entre las que se puede destacar:

• Servir como estructura de datos donde almacenar los cuerpos físicos que lo conforman y aplicar una serie de restricciones a estos cuerpos, como la fuerza de gravedad.

• Detectar y aplicar colisiones entre estos cuerpos.

• Actualizar su posición automáticamente cuando se aplique cualquier tipo de fuerza sobre estos.

Un cuerpo físico comprende dos categorías. El primero es cuerpo rígido y el segundo, cuerpo blando. Un cuerpo rígido se caracteriza por tener una forma inmutable. Si se aplica alguna fuerza

(33)

2.6. MOTOR FÍSICO: BULLET PHYSICS

sobre un cuerpo rígido, su forma no variará. En contrapunto, los cuerpos blandos se caracterizan por tener formas de colisión que pueden variar cuando se aplica una fuerza sobre éstas. Los cuerpos rígidos tienen comportamientos menos realistas que los cuerpos blandos; sin embargo, simular un cuerpo blando es computacionalmente más complejo que simular un cuerpo rígido, debido a las implicaciones que tiene la variabilidad de su forma física.

Los cuerpos físicos cuentan con una forma de colisión. Típicamente, una forma de colisión suele ser un cuerpo convexo con unas determinadas propiedades en función de su forma geométrica, un coeficiente de fricción, de restitución, una inercia, etc. Bullet ofrece unas cuantas formas primitivas de colisión, que pueden ser simples o complejas. Entre las primitivas simples se encuentran cajas, planos, cilindros y esferas.

A su vez, ofrece formas de colisión más complejas, pudiendo combinar múltiples formas convexas en una única. El costo de detección de colisiones para primitivas complejas es mucho más complejo que para primitivas simples, aunque el grado de realismo alcanzado es mucho mejor. El usuario es el responsable de establecer la correspondencia entre los objetos 3D y sus representaciones físicas. Cada objeto visual tendrá su correspondencia en el mundo físico, o no, según sea necesario para la lógica de la aplicación.

Bullet interpreta que un cuerpo con una masa de 0 kg es un cuerpo que no interacciona con ninguna fuerza, es decir, permanecerá inamovible en su posición y orientación inicial, por lo que será un cuerpo estático. De lo contrario, un cuerpo con masa mayor a 0, será un cuerpo dinámico.

(34)

(35)

C

A

P

Í

T

U

L

O

3

D

ISEÑO E

I

MPLEMENTACIÓN

3.1 Introducción

M

ediante las tecnologías mencionadas en el Capítulo 2, se creó una plataforma que a través de dispositivos creados para usarse en consolas de videojuegos, brinda asistencia al entrenamiento deportivo.

La plataforma tiene la capacidad de realizar la conexión de dispositivos preparados para reconocer gestos realizados por el usuario. Se desarrolló una capa de abstracción ideada para que sea fácil poder incorporar nuevos dispositivos a esta plataforma ya que en este caso fue instanciada con el dispositivo Wiimote y Wii Motion Plus.

La idea de este trabajo es poder evaluar los datos generados por los dispositivos y posterior-mente compararlos. Para ello, se tuvo en cuenta la posibilidad de tener diferentes estrategias para comparar los gestos realizados por el usuario.

(36)

CAPÍTULO 3. DISEÑO E IMPLEMENTACIÓN

3.2 Vista general del sistema

Para el diseño e implementación del sistema se ha realizado la división en módulos para reducir la complejidad y prevenir cambios.

A grandes rasgos se han identificado los siguientes módulos:

• Devices: En éste se implementó una clase que administra los dispositivos conectados, las clases de los distintos dispositivos con los respectivos métodos para realizar la conexión/-desconexión con la PC y la captura de los datos.

• Model: En este módulo se implementaron las clases correspondientes para organizar los datos capturados.

• Strategies: Aquí se implementan los distintos algoritmos para realizar las comparaciones de los golpes.

Figura 3.1: Vistal general del sistema

Cada uno de estos módulos se explicarán a lo largo del capítulo. A continuación se muestra en la Figura 3.2, un diagrama de flujo de los diferentes módulos.

Figura 3.2: Diagrama de flujo de los distintos módulos

(37)

3.2. VISTA GENERAL DEL SISTEMA

Tal como se muestra en la Figura, el sistema comienza por elMódulo Devicescon la conexión de los dispositivos con la PC. Una vez establecido el enlace se procede a la captura de los datos que genera el usuario y se almacenan siguiendo la estructura implementada en elMódulo Model.

Por último, se utiliza elMódulo Strategiespara realizar la comparación entre los golpes.

3.2.1 Módulo Devices

Es importante que la plataforma sea capaz de poder utilizar nuevos dispositivos que asistan al entrenamiento deportivo, aún cuando éstos puedan ser mejores, peores o diferentes a los ya utilizados. Lo importante en este módulo es la capacidad de agregar un nuevo dispositivo al sistema con el menor esfuerzo.

Entonces para realizar la administración de los dispositivos se diseñó e implementó elMódulo Devices, basándonos en el atributo de calidadExtensibilidad[22]. Como se puede observar en la Figura 3.3 se implementó una clase abstracta llamadaIDeviceque provee la extensibilidad de agregar nuevos dispositivos a la aplicación.

Figura 3.3: Clase Abstracta IDevice

Los métodosConnect,Disconnect,IsConnected,IsCaptureStartyCaptureStrokeson abstractos, por lo tanto son implementados por las clases que se extiendan deIDevice.

El métodoCaptureStroketiene la característica de retornar un tipoStrokeque será explicado en el transcurso del capítulo.

Dada la situación que se quiera agregar un nuevo dispositivo a la plataforma se debe extender de la clase IDevice e implementar los métodos abstractos que se ven en la imagen. Principalmente estos métodos son los encargados de administrar la conexión y la captura de los gestos.

3.2.1.1 DeviceManager

(38)

nos confirma un punto de acceso global a la única instancia de esa clase y por tanto a toda su funcionalidad.

Figura 3.4: Clase Device Manager

Como mencionamos anteriormente, se puede obtener la instancia del objetoDeviceManager

a través del métodoGetSingleton. Por otra parte, los métodosSetDeviceInUsese utilizan para establecer cuál es el dispositivo que está en uso. Se puede obtener la lista de dispositivos conectados medianteGetListConnectDevices.

3.2.1.2 DeviceWiimote

Se creó la claseDeviceWiimotepara que la plataforma soporte el dispositivoWiimote. Esta clase implementa los métodos que fueron declarados como abstractos enIDevice. Como el disposi-tivo en cuestión tiene características y comportamientos propios, como es el caso de los sensores, se tomó la decisión de crear un módulo aparte, llamadoMódulo Wiimote, para administrar de manera más ordenada y eficiente el dispositivo.

Figura 3.5: Clase Device Wiimote

A continuación, en el Algoritmo 1 se puede observar un pseudo-código de cómo se realizó la

(39)

implementación del método correspondiente a la conexión del dispositivo.

initialization;

ifNo esta conectadothen

Crear nuevo hilo para realizar la conexión;

end

Algorithm 1:DeviceWiimote::Connect

Se puede apreciar en el Algoritmo 1 que se crea un nuevo hilo que realiza la ejecución del sistema. Cuando el usuario solicita conectar el dispositivo, el hilo entra a este método donde ahí mismo crea un nuevo hilo que se encarga de realizar la conexión del dispositivo con el sistema.

Funcionamiento basado en hilos

La utilización de estos hilos se debe principalmente a cuestiones de diseño de interfaz gráfica. Se sabe que una interfaz gráfica se ejecuta sobre el hilo principal de la aplicación, y que cualquier procedimiento que se ejecute lo hará sobre ese mismo hilo, haciendo que quede bloqueado durante ese lapso de tiempo. En los casos en que esos procedimientos requieran un mayor procesamiento, o en su defecto un mayor tiempo, es necesario que ese procedimiento se realice en un hilo aparte. De esta forma, se deja la responsabilidad de ese proceso en un hilo secundario y cuando el proceso finaliza debe comunicarle al hilo principal de tal hecho.

También es importante mencionar las prioridades asignadas en los hilos. Este manejo de configuración sirve en un entorno donde el hardware es capaz de manejar múltiples hilos o múltiples procesos. Entonces, como el procesador ejecutará el hilo durante un tiempo determinado según la técnica de planificación de CPU que implemente (Round Robin, FCFS, SJF[23] entre otras), al tener definida una prioridad alta hace que le dé mayor tiempo para ejecutarse o que vuelva a estar en ejecución más pronto que otros procesos.

Para nuestro caso, la prioridad asignada al hilo secundario creado es normal. Esta asignación es el resultado de diferentes pruebas debido al nivel de atención necesario para poder capturar los datos y sabiendo que no es demasiado procesamiento como para asignarle una prioridad más alta.

Secuencia de conexión del dispositivo Wiimote

A continuación, en la Figura 3.6 se puede observar la secuencia de ejecución de estos hilos y la interacción entre las distintas clases mediante la conexión del dispositivo Wiimote.

(40)

de ser así, finaliza el método encendiendo las luces led del dispositivo Wiimote. Sino, vuelve a intentarlo.

Figura 3.6: Diagrama de secuencia de conexión del dispositivo Wiimote

Secuencia de captura de datos del dispositivo Wiimote

A partir de que la conexión del dispositivo está establecida, los sensores se encuentran funcionando todo el tiempo; por ende, están capturando valores. Entonces, se necesita que cuando el usuario desee cargar un nuevo golpe se genere un evento donde se identifique el comienzo, y luego también un evento donde indique la finalización correspondiente.

Para la implementación de la captura de los gestos se ha realizado de una manera similar a la conexión de los dispositivos. Dicha implementación se ha realizado utilizando la funcionalidad orientada a eventos. En la Figura 3.7, se muestra particularmente cómo se capturan los gestos mediante el dispositivoWiimote.

La captura del gesto comienza mediante un evento, llamadoStartAsyncCaptureStroke, que se invoca desde la interfaz visual al objetoIDevice. Este método es ejecutado dentro de un hilot1, que crea un nuevo hilot2.

Luego, mediante una pre-configuración se selecciona la cantidad de gestos a capturar. Enton-ces, según esta configuración se invoca esa cantidad de veces al métodoCaptureStrokepropio del dispositivo que se encuentre conectado, DeviceWiimoteen este caso, como se refleja en el diagrama.

El proceso de captura del gesto comienza y termina mediante un evento que se definió con el botón B del Wiimote. Éste se inicia cuando se oprime y termina cuando se suelta. Mientras el botón se encuentre presionado, el dispositivo capturará los valores de cada uno de los sensores. Cuando se suelta el botón se devuelve un objetoStrokeque contiene los valores capturados de esa muestra.

(41)

Figura 3.7: Diagrama de secuencia de la captura de los gestos mediante el dispositivo Wiimote

3.2.1.3 Device WiiMotionPlus

También como hemos hecho en la claseDevice Wiimote, se implementaron los métodos que se encontraban abstractos en la interfazIDevice. Si bien es una extensión del dispositivoWiimote

posee ciertas diferencias como, por ejemplo, la conexión del dispositivo con la PC.

Figura 3.8: Clase DeviceWiiMotionPlus

(42)

El métodoIsConnectedrequiere que tanto el dispositivo como su extensión estén conectados, si al menos alguno de ellos pierde la conexión entonces la función indicará que no está conectado.

3.2.1.4 Properties

Luego de haber implementado el móduloDevicesse pueden utilizar diferentes dispositivos que difieren en cuanto a conexiones y capturas de los sensores. Sabiendo que cada dispositivo está compuesto por sensores diferentes y a su vez que éstos juntos forman un conjunto especial. Es necesario tener un diseño que pueda soportar definir cada uno de los sensores y la manera en que se agrupan.

Figura 3.9: Clase Properties

Se creó la clasePropertiespara definir las propiedades de los dispositivos. Esta clase contiene el nombre del dispositivo, la configuración y la cantidad de sensores que lo componen. A cada uno de los sensores se le debe definir el rango de valores que es capaz de reconocer.

1 Wiimote : : Wiimote ( v o i d ) : IDevice (" wiimote ") {

2 [. . .]

3 v e c t o r * s e n s o r s = new v e c t o r ( 3 ) ;

4 sensors−>at ( 0 ) = new P r o p e r t i e s : : Sensor (" A c e l e r a c i o n en X", −6.0 , 6 . 0 ) ;

5 sensors−>at ( 1 ) = new P r o p e r t i e s : : Sensor (" A c e l e r a c i o n en Y", −6.0 , 6 . 0 ) ;

6 sensors−>at ( 2 ) = new P r o p e r t i e s : : Sensor (" A c e l e r a c i o n en Z ", −6.0 , 6 . 0 ) ;

7 P r o p e r t i e s : : GroupSensors _* groupAccel = new P r o p e r t i e s : : GroupSensors ( ) ; 8 groupAccel−>groupName = " Acelerometros ";

9 groupAccel−>indexs . push_back ( 0 ) ;

12 groupAccel−>ponderation = 1 . 0 ;

13

14 v e c t o r _* groups = new v e c t o r ( 1 ) ;

15 groups−>at ( 0 ) = groupAccel ;

16 S e t P r o p i e r t e s ( new P r o p e r t i e s (" Wiimote ", sensors , groups ) ) ;

17 }

Algoritmo 3.1: Wiimote::Wiimote

(43)

También es posible agruparlos por tipo de sensor, por ejemplo, los sensores acelerómetros estarán dentro del mismo conjunto y los sensores giróscopos en su grupo correspondiente.

En el Algoritmo 3.1 se puede ver cómo se realiza la configuración de las propiedades para el dispositivoWiimote. Primero, se crea cada sensor, se define el nombre correspondiente y el rango de aceptación para sus valores. Luego, se puede ver cómo se define un grupo llamado

Acelerómetrosal que se le asignan los sensores anteriormente declarados.

Por último, se puede observar que al grupo de los acelerómetros se le configura una pondera-ción en 1 porque es el único grupo que existe. Esta ponderapondera-ción será utilizada luego para realizar las comparaciones en elMódulo Strategies.

A continuación, se observa el Algoritmo 3.2 para configurar las propiedades del dispositivo

WiiMotionPlus. A diferencia del algoritmo anterior, en este caso se cuenta con dos grupos de sensores. Por un lado, están los acelererómetros y por otro, los giróscopos.

En el Algoritmo 3.2 se puede ver antes de la línea 5 se realiza la configuración del dispositivo

Wiimote. Luego, a partir de esa línea se definen los sensores correspondientes al grupo de los giróscopos, como se hizo el grupo de acelerómetros. Por último, se realiza la ponderación para cada grupo en0.5. Por lo tanto, cada grupo tendrá el mismo peso cuando se realicen las comparaciones.

1 WiiMotionPlus ( v o i d ) : IDevice (" wiimotionplus ") {

2 [. . .]

3 v e c t o r _* s e n s o r s = new v e c t o r ( 6 ) ;

4 [. . .]

5 sensors−>at ( 3 ) = new P r o p e r t i e s : : Sensor ("Yaw", −2050.0 , 2 0 5 0 . 0 ) ;

6 sensors−>at ( 4 ) = new P r o p e r t i e s : : Sensor (" P i t c h ", −2050.0 , 2 0 5 0 . 0 ) ;

7 sensors−>at ( 5 ) = new P r o p e r t i e s : : Sensor (" R o l l ", −2050.0 , 2 0 5 0 . 0 ) ;

8

9 P r o p e r t i e s : : GroupSensors _* groupGyros = new P r o p e r t i e s : : GroupSensors ( ) ;

10 groupGyros−>groupName = " G i r o s c o p i o s ";

11 groupGyros−>indexs . push_back ( 3 ) ;

14 groupGyros−>ponderation = 0 . 5 ;

15

16 v e c t o r * groups = new v e c t o r ( 2 ) ;

17 groups−>at ( 0 ) = groupAccel ;

18 groups−>at ( 1 ) = groupGyros ;

19

20 S e t P r o p i e r t e s ( new P r o p e r t i e s (" WiiMotionPlus ", sensors , groups ) ) ;

21 }

(44)

3.2.2 Módulo Model

Para poder administrar los datos que reconocen los dispositivos es necesario encapsularlos de manera adecuada para que estén ordenados. Se debe considerar la idea que el dispositivo está compuesto por una cierta cantidad de sensores y que éstos están continuamente captando valores sin la capacidad de diferenciar el comienzo y el fin de un gesto.

Como se dijo anteriormente, los sensores se encuentran obteniendo valores continuamente; sin embargo, se quiere capturar desde que el usuario inicia su golpe hasta que lo termina. Por ello es que la captura del golpe comienza cuando el usuario oprime un botón y cuando lo suelta, finaliza la captura.

Figura 3.10: Módulo Model

Dependiendo de cuán rápido o lento lo realice la cantidad de muestras censadas variará. Supongamos que desde que oprimió el botón hasta que lo soltó transcurrió 1 segundo, sabiendo que cada sensor tiene la capacidad de tomar 100 muestras y que el dispositivo tiene 3 sensores, tendremos que almacenar de alguna manera 300 muestras del golpe. Entonces es conveniente que cada muestra a la que se llamaráValueStrokecontenga las muestras obtenidas por los sensores en un instante de tiempo.

Luego, el conjunto de muestras capturadas conformarán al golpe representado por la clase

Stroke. Cabe destacar que el golpe estará compuesto por más información que será explicada en detalle en la sección 3.2.2.2.

Se implementó la claseTemplatepara generar patrones a partir de golpes similares que haya cargado el usuario. Ese patrón generado lo usamos luego como el golpe ideal por parte de ese usuario.

Como este sistema tiene la finalidad que sea utilizado por diferentes jugadores y poder

(45)

analizarlos se creó la claseProfile, que contendrá susTemplates, la información personal y la información física.

3.2.2.1 ValueStroke

La clase ValueStroke está compuesta principalmente por un vector de valores decimales, donde cada ítem del vector representa un valor correspondiente a un sensor. De esta manera, es capaz de almacenar los valores capturados independientemente de la cantidad de sensores que el dispositivo tenga.

Figura 3.11: Clase ValueStroke

Como podemos ver en la Figura 3.11 en el método constructor se debe poner el valor correspon-diente a la cantidad de sensores del dispositivo. Además, tenemos un método para modificar cada uno de los valores delValueStrokellamadoSetValuey otro, para obtenerlos medianteGetValue. También podemos saber de qué tamaño es la estructura a través del métodoGetAmount.

En el siguiente Algoritmo 3.3 se puede observar cómo la claseWiimotese encarga de realizar la captura del golpe. Este método se encarga de capturar todos los valores correspondientes al golpe mientras el usuario lo desee, por ejemplo, para el caso del dispositivoWiimotemientras mantenga apretado el botón B. Mientras tanto, creará un objetoValueStrokeque le asignará los valores correspondientes de cada sensor en ese momento.

1 Stroke* CaptureStroke ( ) {

2 Stroke * s t r o k e = new Stroke ( ) ;

3 while ( mWiimoteManager−>IsPressedButton ("BUTTON_B") ) {

4 ValueStroke * value = new ValueStroke ( 3 ) ;

5 value−>SetValue ( 0 , mWiimoteManager−>W i i A c c e l e r a t i o n . x ) ;

6 value−>SetValue ( 1 , mWiimoteManager−>W i i A c c e l e r a t i o n . y ) ;

7 value−>SetValue ( 2 , mWiimoteManager−>W i i A c c e l e r a t i o n . z ) ;

8 stroke−>AddStrokeValue ( value ) ;

9 }

10 return s t r o k e ;

(46)

Luego de que el ValueStroke es creado es añadido a una estructura que lo mantenga y administre; en este caso, se agrega aStroke.

3.2.2.2 Stroke

Una vez que se haya capturado el golpe, compuesto por una cantidad de muestras, a las que llamamos anteriormenteValueStroke, se debe almacenar dentro de una estructura que lo soporte. Esta estructura es una clase a la que llamamosStroke.

Si bien puede creerse que lo más importante del golpe son sus muestras ya que sin ellas no existe golpe; también, es importante darle un contexto. Para ello se debe definir un nombre, saber a partir de qué dispositivo fue capturado, o también decir de qué tipo es.

Figura 3.12: Clase Stroke

Por las razones que se explicaron anteriormente se implementó esta funcionalidad dentro de esta clase.

Cabe destacar que particularmente en el tenis, de un golpe a otro puede variar tanto su velocidad como su trayectoria. Por ejemplo, comparemos el golpe conocido comosmashcon un golpe llamadoglobo. El primero es un golpe que se inicia colocando la raqueta por encima de la cabeza de manera vertical para impactar a la pelota y que golpee directamente en el piso de forma rápida y potente generando una trayectoria lo más recta posible. En cambio, elglobo

comienza con la raqueta por debajo de la cintura impactando desde abajo hacia arriba y con una potencia mucho menor que la delsmash.

Otro ejemplo, es comparar undrive con unrevés. Entonces los valores obtenidos por los sensores serán muy distintos entre sí. Por eso es que se debe dar más contexto al golpe que se realiza.

Como mencionamos anteriormente nuestro objeto Stroke contiene una lista en la que se guardan las diferentes muestras que fueron capturadas para el golpe. El golpe debe tener

(47)

un nombre, una variable donde se diga la cantidad de muestras que debería tener y con qué dispositivo fue capturado.

3.2.2.3 Template

A partir del desarrollo que se fue contando hasta el momento, se puede capturar los golpes con sus respectivas muestras. El objetivo principal de estos golpes capturados es compararlos.

Para ello es que creamos una clase llamadaTemplateque guardará los golpes capturados por el usuario. Esta clase sirve para generar un patrón a patir de los gestos que componen el Template; en este caso, como la aplicación se centró en el deporte tenis estos gestos van a ser golpes propios del deporte.

Además, esta forma de generar templates permite al usuario cargar una cantidad de golpes significativa, realizados de la misma manera, y si por cierta razón uno de ellos no es efectuado de forma similar no afectará a la posterior comparación.

Figura 3.13: Clase Template

Como vemos en la Figura 3.13, también es necesario describir con qué dispositivo se va a realizar la captura de los diferentes golpes que comprenden elTemplate. Además, es importante que el Templatetenga su nombre y que éste sea descriptivo para facilitarle al usuario una búsqueda más rápida. También elTemplatetiene asignado un perfil, explicado posteriormente.

3.2.2.4 TemplateTools

(48)

Figura 3.14: Clase TemplateTools

dido. En caso de que el golpe tenga más muestras que el valor sugerido se procede, mediante el criterio propuesto, a eliminar algunas hasta alcanzar ese valor. Caso contrario, se deben agregar muestras. Tanto quitar como agregar muestras hace que el golpe no sea exactamente el mismo, por eso es que se realiza una interpolación lineal para generar una independencia de la cantidad de muestras, y que quitar o agregar no termine modificando la esencia del golpe. También se ha implementado el métodoResamplingTemplate, que realiza la misma normalización anteriormente descripta pero aplica a todos los golpes que contiene elTemplate.

Todas estas funcionalidades descriptas se van a utilizar luego en las diferentes estrategias de comparación.

3.2.2.5 DataManager

A partir de la generación de diferentesTemplatesyStrokes, decidimos que sería una buena decisión proveerle al usuario la posibilidad de poder almacenarlos físicamente mediante archivos. Esta solución hace que los golpes y templates permanezcan no sólo en la ejecución de la aplicación sino también poder utilizarlos en otra ejecución, o en otro momento o también, si se copian esos archivos, hasta en otra computadora.

Mediante archivos de tipoCSV, que se utilizan en diversas áreas para la representación de tablas de manera sencilla, ya que los separa por fila y para separarlos por columna agrega un separador que puede ser una coma, o punto y coma.

Entonces, si podemos guardar esos archivos de manera ordenada también podemos leerlos. Pero, además de guardar los datos que fueron capturados por el dispositivo tenemos que guardar información del Templateo del Golpe, como su nombre, su tipo y demás descripciones que comentamos en cada una de las secciones correspondientes.

(49)

Figura 3.15: Clase DataManager

3.2.2.6 Profile

Frente a la posibilidad de plantear un sistema que sea usado en un grupo de estudiantes de tenis, ya sea amateur o profesional, se presenta la idea de poder almacenar el registro de cada jugador por separado. Tengamos en cuenta que los jugadores pueden tener innumerables diferencias, por ello es que es necesario detallar al menos las más significativas.

Figura 3.16: Clase Profile

(50)

3.2.2.7 AppManager

Ahora que se ha diseñado e implementado todo el modelo de datos y la administración de los dispositivos, donde el primero nos provee de facilidades para el almacenamiento y procesamiento de la información, y el segundo es el que captura esa información, necesitamos llevar el control de estas capacidades. Por ello, se creó la claseAppManager, que se encarga de llevar a cabo cada una de capacidades de los módulos anteriormente descriptos.

Figura 3.17: Clase AppManager

Esta clase está implementada utilizando el patrónSingletonya que sólo existirá una ins-tancia durante toda la ejecución. Además, debe ser accesible desde diversos procedimientos pertenecientes a otros objetos.

La clase cargará las distintas configuraciones iniciales que usará la aplicación y se encargará la administración de los perfiles. Además, proveerá la funcionalidad de obtener los perfiles que existan dentro del directorio de trabajo como así también agregará y guardará nuevos perfiles. Además, facilita la administración de los golpes, desde la captura de uno nuevo, el guardado y la carga de uno anteriormente capturado.

(51)

Comparación de gestos

3.2.3 Módulo Strategies

Para poder evaluar a los jugadores es necesario poder comparar sus golpes. Frente a esta necesidad se introducen las estrategias de comparación entre golpes y templates.

En este módulo se centralizan las distintas estrategias comparativas. Diseñado e implemen-tado pensando en la posibilidad de agregar nuevas estrategias a lo largo del desarrollo y en un futuro también, se realizó una interfaz de la que se extiendan las nuevas estrategias.

La comparación se realiza comparando dos curvas. Estas curvas pueden proceder desde distintos golpes; donde cada golpe estará representado por curvas generadas por los sensores del dispositivo de captura. También es posible que una de las curvas, o ambas, procedan a partir de templates. Como los golpes capturados difieren en la cantidad de muestras según cuánto tiempo duró la captura, es necesario para realizar la comparación que ambas curvas tengan la misma cantidad de muestras y estén comprendidas en el mismo espacio temporal, por lo que es necesario realizar una normalización de alguna de ellas con respecto a la otra.

Las diferentes estrategias implementadas son las siguientes:

• Estrategia DTW

• Estrategia Inside

3.2.3.1 Strategy

Al plantear el uso de, al menos, dos estrategias es necesario proveer una clase abstracta, el cual tenga métodos pasibles de redefinirlos de acuerdo a las necesidades. Esta clase contiene atributos que son comunes a las estrategias y existe al menos la implementación de uno de sus métodos.

Figura 3.18: Clase Strategy

(52)

También podemos observar que se han declarado unas variables. Éstas pertenecen a valores que se usan dentro del método deGetAverage, pero que tienen un valor válido cuando se carga un nuevo template.

3.2.3.2 StrategyDTW

Como comentamos anteriormente, la idea es crear diferentes alternativas para realizar comparaciones entre golpes y templates. La primer estrategia de comparación que presentamos es el algoritmo deAlineamiento Temporal Dinámico, más conocido comoDTW .

Si tenemos dos series de tiempoX=(X1,X2...Xn) yY=(Y1,Y2...Yn) una manera natural de

medir la similaridad entre ambas es a través de la distancia euclídea:

d(X,Y)₌

s _n X

i=1

(Xi−Yi)2

Un primer inconveniente, radica en la imposibilidad de comparar dos series de tiempo de distinto tamaño. Pero incluso, en el caso de series de igual largo, una dificultad que presenta la distancia euclídea radica en que es muy sensible a distorsiones en el eje del tiempo, aun cuando éstas sean pequeñas. Por ejemplo, si dos señales son iguales, salvo por un desplazamiento en el tiempo, la distancia euclidiana las reconocería como distintas por su característica de alineamiento punto a punto. En este sentido, se introdujo el algoritmo DTW explicado en A.3.

Figura 3.19: Diferencias entre distancia euclidiana y DTW

Lo anterior se puede apreciar gráficamente en la Figura 3.19, donde se representan dos series con la misma forma general. En la parte superior se muestra el alineamiento que produce la distancia euclidiana, el punto i-ésimo de la primera con el i-ésimo de la segunda. En la parte

(53)

inferior se muesta un alineamiento no lineal, que permite una medida de similaridad más sofisticada [24].

El algoritmo DTW (Dynamic Time Warping) se utiliza en nuestro sistema para medir la similitud de los gestos realizados por el usuario, que pueden diferir en tiempo y espacio. Esta comparación puede ser mediante un gesto que realice (gesto de test) contra otro previamente almacenado o contra un conjunto de golpes que definimos como template (gesto de referencia).

Para realizar la comparación mediante DTW se analiza cada serie de datos generada por los sensores del dispositivo. Por ejemplo, para la comparación de un gesto de test contra un gesto de referencia, ambos capturados con el dispositivo Wiimote, se analizan las curvas que describen las aceleraciones en el eje X, luego en el eje Y y finalmente en el eje Z. Se utiliza como criterio cuantitativo para la comparación entre cada par de curvas, la suma de las distancias del camino óptimo que recorre la matriz de distancias acumuladas de más bajo costo, obtenido al finalizar el algoritmo DTW implementado en A.1. En resumen, en cada comparación se ejecuta el algoritmo DTW tantas veces como número de sensores tiene el dispositivo de captura de los gestos.

En la comparación de un golpe (gesto de test) contra un template utilizando DTW, se utiliza el golpe promedio del template como gesto de referencia. La ejecución del algoritmo retornará la distancia entre los gestos alineados en el tiempo. Luego para determinar si el gesto de test es "similar" al gesto de referencia, cada uno de los valores DTW obtenidos deberá estar por debajo de un valor límite. Ese valor puede ser obtenido de las siguientes maneras:

• A partir de las curvas mínimas y máximas del template, y para las curvas generadas por cada sensor del dispositivo de captura, se calcula el valor límite utilizando distancia euclídea o DTW.

• A partir de los desvíos superior e inferior del template, y para las curvas generadas por cada sensor del dispositivo de captura, se calcula el valor límite utilizando distancia euclídea o DTW.

Por lo tanto, existe la posibilidad de realizar la comparación entre un golpe y un template mediante diferentes combinaciones. La cantidad total de estas combinaciones es de 4(cuatro). Si bien sabemos que las configuraciones de la estrategia son similares, una pequeña diferencia en el resultado puede ser significativa.

Como podemos observar en la Figura 3.20 se implementó el método Execute de la clase heredada de acuerdo a las propiedades y características correspondientes de la estrategia.

(54)

Figura 3.20: Clase Strategy DTW

el tipo de curva límite que se usará en la búsqueda del valor límite, ya sea desvío superior y desvío inferior o máximos y mínimos.

3.2.3.3 StrategyInside

La técnica utilizada en esta ocasión es más sencilla que la anterior en cuanto a su imple-mentación. Se trata de un algoritmo que fue diseñado e implementado desde cero contemplando nuevas estrategias y puntos de vista para realizar la comparación.

Se basa en la generación de dos curvas, una a la que llamaremosInferiory la otraSuperior. La curvaInferiorse construye a partir del conjunto de muestras que tiene el template. Para cada instante de la curva, a partir del subconjunto obtenido de las muestras según un instante de tiempo, se selecciona el menor de ellos. Para la generación de la curvaSuperiorse mantiene la misma lógica con la variación de que se busca el mayor valor.

Luego, con estas dos curvas ya calculadas se genera un canal de aceptación, es decir, para cada instante de la curva existe un intervalo que se encuentra entre la curvaSuperioreInferior. El algoritmo comprobará, para cada instante de tiempo, si el valor de la muestra se encuentra dentro del canal de aceptación. En este sentido, el porcentaje de similitud estará dado por la cantidad de muestras incluidas dentro del canal de aceptación, dividido por la cantidad total.

No obstante, también es posible considerar el valor de la muestra como contenido dentro de estas curvas sin que realmente sea así. Esto es posible dado que existe unmargen de errorque hace que este punto sea aún considerado. El margen de error extiende el intervalo de aceptación. Si el valor de la muestra no se encuentra dentro del canal, entonces mediante la extensión del valor límite se calculará un porcentaje de alejanía entre la muestra y el límite, teniendo en cuenta el margen de error establecido. El Algoritmo 3.4 implementa esta lógica.

(55)

1 double S t r a t e g y I n s i d e : : I n s i d e ( double value , double lower, double upper) {

2 i f (lower <= value && value <= upper) {

3 return 1 . 0 ;

4 }

5

6 / / Calculo l a e x t e n s i o n d e l i n t e r v a l o

7 double margin = (upper − lower) * mMarginOfError ;

8

9 i f ( value < lower) {

10 i f ( value >= lower − margin ) {

11 return abs( 1 − (lower − value ) / margin ) ;

12 }

13 }

14 e l s e i f ( value > upper) {

15 i f ( value <= upper + margin ) {

16 return abs( 1 − ( value − upper) / margin ) ;

17 }

18 }

19 return 0 . 0 ;

20 }

Algoritmo 3.4: StrategyInside::Inside

Supongamos un intervalo de aceptación entre los valores 3 y 9, con un margen de error del 50 %, para un cierto instante de tiempot. La Figura 3.21 esquematiza esta configuración. El rectángulo central corresponde al canal de aceptación, donde el rango del intervalo es de 6 unidades. Los rectángulos laterales corresponden a los intervalos extendidos por el margen de error. Como el margen de error es del 50 %, entonces el rango de los intervalos laterales serán de 3 unidades.

Figura 3.21: Esquematización del canal de aceptación y los intervalos extendidos para un margen de error del 50 % de la estrategia Inside

(56)

se encontrará dentro del intervalo de error izquierdo, de acuerdo a la Figura 3.21. El porcentaje de alejanía es del 66,66 %, por ende el coeficiente de inclusión será 0,33.

Si se modifica el margen de error al 25 %, entonces los rangos de los intervalos laterales del canal de aceptación serán de 1,5 unidades (Figura 3.22). El valor 1 de la muestra no estará dentro del intervalo de error izquierdo, a diferencia de la configuración con un margen de error de 50 %. En tal caso, el coeficiente de inclusión será 0.

Figura 3.22: Esquematización del canal de aceptación y los intervalos extendidos para un margen de error del 25 % de la estrategia Inside

De esta manera, el porcentaje de similitud estará dado por la suma de los coeficientes de inclusión de los valores de las muestras en cada instante de tiempo, dividido por la cantidad de muestras total.

Figura 3.23: Clase Strategy Inside

Como se ve en la Figura 3.23, el métodoSetMarginOfErrordefine el valor correspondiente al margen de error anteriormente comentado. En cuanto al métodoSetUseLimitCurve, permite establecer el tipo de curva límite que se usará en la estrategia, que pueden ser desvíos superiores e inferiores o máximos y mínimos del conjunto de golpes del template.