1. Art and Diseño

Universidad de Costa Rica
Facultad de Ingeniería
Escuela de Ingeniería Eléctrica
DESARROLLO DE UNA HERRAMIENTA PARA
CAPTURA DEL MOVIMIENTO HUMANO
PARA EL ANÁLISIS BIOMÉTRICO
Por:
Marco Chacón Taylor
Esteban Ortiz Cubero
Ciudad Universitaria Rodrigo Facio
Diciembre de 2013
DESARROLLO DE UNA HERRAMIENTA PARA
CAPTURA DEL MOVIMIENTO HUMANO
PARA EL ANÁLISIS BIOMÉTRICO
Por:
Marco Chacón Taylor
Esteban Ortiz Cubero
Sometido a la Escuela de Ingeniería Eléctrica
de la Facultad de Ingeniería
de la Universidad de Costa Rica
como requisito parcial para optar por el grado de:
LICENCIADO EN INGENIERÍA ELÉCTRICA
Aprobado por el Tribunal:
_________________________________
Ing. Randolph Steinvorth, PhD.
Director, Escuela de Ingeniería Eléctrica
_________________________________
Ing. Lochi Yu Lo, PhD
Director, Comité Asesor
_________________________________
Ing. Pietro Scaglioni, MSc.
Miembro, Comité Asesor
_________________________________
Ing. Enrique Coen, MSc.
Miembro, Comité Asesor
_________________________________
Ing. Mercedes Chacón, Licda.
Miembro del Tribunal
ii
DEDICATORIA
A Cristina, Clarissa y mi familia
Esteban Ortiz
iii
RECONOCIMIENTOS
Los autores de este trabajo desean reconocer a los Profesores Dr. Lochi Yu y MSc. Pietro
Scaglioni por su ayuda, guía técnica y comprensión durante el desarrollo de este proyecto.
iv
ÍNDICE GENERAL
ÍNDICE DE FIGURAS ....................................................................................................... vii
ÍNDICE DE TABLAS ...........................................................................................................ix
RESUMEN ............................................................................................................................. x
CAPÍTULO 1: Introducción ................................................................................................... 1
1.1
Objetivo general ....................................................................................................... 3
1.1.1
1.2
Objetivos específicos ........................................................................................ 3
Metodología ............................................................................................................. 3
CAPÍTULO 2: Desarrollo teórico........................................................................................... 5
2.1
Sensores inerciales: acelerómetros y giróscopos ..................................................... 5
2.2
El Wiimote como instrumento de medición inercial ................................................ 7
2.2.1
Características del acelerómetro del Wiimote .................................................... 10
2.2.2
Características de los giróscopos del Wiimote ................................................... 11
2.2.3
Comunicación Bluetooth® del Wiimote ............................................................ 14
CAPÍTULO 3: Sistema de captura para el cálculo de la estabilidad dinámica .................... 18
3.1 Consideraciones iniciales ............................................................................................ 18
3.2 Librería de conexión con el controlador Wii® ........................................................... 18
3.3 Interfaz de programación de aplicación de wiic ......................................................... 19
3.4 Arquitectura del sistema de captura ............................................................................ 20
3.5 Estructuras de datos .................................................................................................... 25
3.5.1 Clase vector_s ...................................................................................................... 25
3.5.2 Clase dataPoint_s ................................................................................................. 26
3.5.3 Clase fftdataPoint_s ............................................................................................. 26
3.5.4 Clase results_s...................................................................................................... 26
3.5.5 Clase ratios_s ....................................................................................................... 27
3.5.6 Clase dataSeries_s................................................................................................ 27
3.6 Post-procesamiento de datos ....................................................................................... 27
v
3.6.1 Corrección de los vectores de aceleración y velocidad angular .......................... 28
3.6.2 Cálculo la media cuadrática (RMS) ..................................................................... 28
3.6.3 Cálculo de las variables espacio-temporales ....................................................... 29
3.6.4 Cálculo de armónicas ........................................................................................... 31
3.7 Resultados y discusión ................................................................................................ 33
3.7.1 Discusión ............................................................................................................. 36
3.8 Comparación de la captura de datos mediante el uso de wiimotes y sensores
inerciales comerciales. ...................................................................................................... 38
CAPÍTULO 4: Estimación de la posición y orientación de las extremidades humanas a
partir de sensores inerciales. ................................................................................................. 44
4.1 Arquitectura propuesta para el sistema de captura de datos. ...................................... 45
4.2 Propuesta inicial de Software ..................................................................................... 46
4.3 Captura de datos provenientes de los sensores inerciales. .......................................... 47
4.3.1
Utilización de OSC para el tráfico de información entre el wiimote y Blender.
50
4.4 Determinación de la orientación mediante sensores inerciales. ................................. 53
4.5 Representación de movimiento en Blender utilizado la máquina de juegos .............. 58
4.5.1 Representación de la escena en Blender .............................................................. 59
4.5.2 Programación de la lógica del objeto ................................................................... 59
4.5.3 Script para la ejecución del movimiento.............................................................. 61
CAPÍTULO 5: Conclusiones y recomendaciones ................................................................ 64
BIBLIOGRAFÍA .................................................................................................................. 66
vi
ÍNDICE DE FIGURAS
Figura 2.1 Orientación de los ángulos de Euler utilizados en los giróscopos ........... 6
Figura 2.2 Orientación de los ejes para el acelerómetro del Wiimote ...................... 11
Figura 2.3 Funcionamiento de un giróscopo MEMS de tipo diapasón .................... 12
Figura 2.4 Orientación de los ejes para los giróscopos del Wiimote ........................ 14
Figura 3.1: Máquina de estados del sistema de captura ............................................ 21
Figura 3.2: diagrama de bloques del sistema de captura. ......................................... 23
Figura 3.3: Patrón característico de la componente vertical de la aceleración durante
la caminata. ............................................................................................................... 30
Figura 3.4 Transformada Rápida de Fourier de un patrón de movimiento de período
constante predominante en el eje vertical. ................................................................ 32
Figura 3.5: Aceleraciones lineales durante la caminata. ........................................... 33
Figura 3.6: Velocidades angulares durante la caminata. ........................................... 34
Figura 3.7: Transformada Rápida de Fourier de aceleración vertical en el intervalo
completo de 0 a 50 Hz. ............................................................................................. 34
Figura 3.8: Transformada Rápida de Fourier de aceleración en el intervalo de 0 a 16
Hz. ............................................................................................................................. 35
Figura 3.9 Captura de datos del eje X ....................................................................... 40
Figura 3.10 Captura de datos del eje Y ..................................................................... 40
Figura 3.11 Captura de los datos del eje Z................................................................ 41
Figura 3.12 Resultados del experimento de caracterización del filtro interno
Wiimote..................................................................................................................... 42
Figura 4.1 El monigote propuesto para la visualización de movimiento.................. 44
Figura 4.2 Arquitectura general del sistema propuesto............................................. 45
Figura 4.3 Diagrama de transferencia de datos del sistema ...................................... 47
Figura 4.4 Captura de pantalla del modelo en Blender............................................. 53
Figura 4.5 Posición de los ejes de los sensores inerciales en relación al Wiimote.... 54
Figura 4.6 El vector de gravedad representado en un eje tridimensional estático .... 54
Figura 4.7 Proyección del vector de gravedad en el plano XY ................................ 55
vii
Figura 4.8 Diagrama de bloques estándar de un filtro de Kalman ........................... 57
Figura 4.9 Ventana de propiedades de objeto ........................................................... 59
Figura 4.10 Selección del Editor Lógico .................................................................. 60
Figura 4.11 El panel del editor lógico luego de agregar la programación necesaria 61
viii
ÍNDICE DE TABLAS
Tabla 1.1 Métodos de investigación asociados a cada objetivo específico según
Hernández, Fernández y Baptista ............................................................................... 4
Tabla 2.1 Resumen de especificaciones del acelerómetro ADXL330 ...................... 10
Tabla 2.2 Resumen de especificaciones del giróscopo IDG-600 de Invensense ...... 13
Tabla 2.3 Resumen de especificaciones del giróscopo XV-3500CB de Epson
Toyocom ................................................................................................................... 13
Tabla 2.4 Reportes HID utilizados por el Wiimote ................................................... 15
Tabla 2.5 Reporte 0x31 HID para botones y acelerómetro ....................................... 16
Tabla 2.6 Datos de acelerómetro combinado con datos de botones en reporte 0x31
HID ........................................................................................................................... 16
Tabla 3.1 Especificaciones de los sensores del IMU Technaid................................. 38
ix
RESUMEN
La presente investigación tiene como objetivo principal la realización
de una herramienta para la captura y análisis de variables de estabilidad dinámica. En el mismo se investiga acerca de dichas variables y
se desarrolla la plataforma para la toma de datos, obteniéndose buenos
resultados con la captura de los datos, pero estos resultados de estabilidad distan de los obtenidos por otros autores que estudian la estabilidad dinámica. Se concluye que el uso de sensores Wii Remote™ no
provee una suficiente confiabilidad para la toma de datos y se recomienda explorar nuevas alternativas para el análisis de estabilidad dinámica.
x
CAPÍTULO 1: Introducción
La observación de la postura y de la marcha del cuerpo humano brinda muchas variables importantes que pueden ayudar a indicar la salud física de un paciente. Sea por el envejecimiento u otras discapacidades por trauma o enfermedad (accidentes vasculo-cerebrales),
la estabilidad estática y dinámica del cuerpo puede indicar estado de salud actual o valorar el
nivel de recuperación.
Tradicionalmente, es el médico examinador, fisioterapeuta u otro profesional de la salud que valora visualmente estas variables, y determina un diagnóstico. Esta metodología no
permite una fácil comparación entre sujetos, o entre diferentes momentos del tratamiento en
el mismo paciente, por lo cual se han desarrollado herramientas de medición de diferentes
niveles de complejidad.
Típicamente, para obtener valores de estabilidad postural en pruebas de laboratorio se
mide el desplazamiento de algún punto del cuerpo o del centro de masa (usando equipo biomecánico de video), o se utilizan medidas derivadas de los datos de una plataforma de fuerza,
que por medio de 4 sensores independientes, logra ubicar el centro de presión y brindar información con respecto a la estabilidad postural estática, por ejemplo, el desplazamiento y/o
la velocidad del centro de presión, y la desviación estándar de la fuerza vertical, entre otros
(Karlsson y Frykberg, 2000, Piirtola y Era, 2006, Judge et al. 1993).
Por otro lado, desde un punto de vista mecánico, el concepto de estabilidad está muy
relacionado al de equilibrio y se puede definir como la resistencia a la aceleración lineal y
angular (Hamill y Knutzen, 2002). Es por eso que también se han utilizado acelerómetros y
giroscopios para obtener datos válidos y confiables que han permitido cuantificar el equilibrio de pie o en la marcha (Moe-Nilssen R., 1998) y para detectar déficit de balance en personas que caen frecuentemente (Cho y Kamen, 1998, Culhane et al., 2005).
Los valores de estabilidad postural se han obtenido por medio de diversos equipos,
entre ellos, los sistemas optoelectrónicos o de video (Granata et al. 2008), o sistemas portátiles de registro, llamados unidades inerciales (Inertial Measurement Unit, IMU) que integran
1
2
acelerómetros y giróscopos en tres ejes ortogonales, de manera que cada eje tiene un acelerómetro y un giróscopo que brindan valores de aceleración lineal y velocidad angular (Mayagoitia et al., 2002; Izquierdo et al. 2008, Bruijn et al . 2009) que permiten calcular la estabilidad local y la orbital. Bruijn et al. (2010) demostraron que los sensores inerciales son una
alternativa válida para obtener la estabilidad de personas durante la marcha. Ellos compararon las mediciones de un sensor inercial a nivel de la espalda sobre la vértebra T8, con el
“estándar de oro”, un sistema optoelectrónico, mientras los sujetos caminaban en una banda
sin fin y obtuvieron correlaciones altas en las medidas de estabilidad postural obtenida con
ambos equipos.
Así, numerosas pruebas clínicas, de laboratorio y de campo se han desarrollado para
medir el control y la estabilidad postural, tanto de forma estática como dinámica, sin embargo, se han criticado los test de laboratorio por tener poca aplicación clínica debido a su
acceso limitado. Por otro lado, a los test clínicos se les critica que tienen poca sensibilidad
(Bogle, Thorbahn y Newton, 1996).
Se requiere entonces de un sistema de captura de datos del movimiento corporal, y se
puede hacer por medio de diversos tipos de entrada: acelerómetros y giroscopios, cámaras,
equipo de ejercicio, alfombras, y otros equipos especializados.
En este trabajo se propone utilizar sensores que detecten directamente el movimiento,
más que utilizar equipo especializado o cámaras. La complejidad del desarrollo de la herramienta requerida incluye el diseño y construcción de este sistema incrustado con procesadores, sensores, y transmisores a la computadora. Por este motivo, se escoge un sistema ya
integrado y disponible, el Wii Remote™, que incluye 3 acelerómetros, y 3 giroscopios en los
3 ejes, un procesador y un transmisor Bluetooth® para comunicación con la computadora.
El hecho de utilizar este sistema tiene un atractivo adicional: le brinda a la comunidad
científica internacional una forma fácil de recrear el sistema y validarlo contra sus sujetos
experimentales, además de que es relativamente de bajo costo (menos de $50) y disponible
ampliamente, a diferencia de las unidades inerciales, cuyo costo es superior a los dos mil
dólares.
3
1.1 Objetivo general
Desarrollar una herramienta certera para la medición de la estabilidad estática y
dinámica de personas.
1.1.1 Objetivos específicos
-
Obtener mediciones de los giroscopios y acelerómetros de un wiimote adherido a una
parte del cuerpo de una persona.
-
Calcular los parámetros de estabilidad dinámica usando un wiimote.
-
Comparar los datos de estabilidad dinámica entre IMU y wiimote.
-
Recrear posición, orientación, etc a partir de las mediciones del wiimote.
1.2 Metodología
Debido a la naturaleza del proyecto, se utilizó mayoritariamente la investigación
aplicada, la cual se basa en resolver un problema práctico, con un margen de generalización
muy limitado, y por lo tanto desde un punto de vista teórico, su aporte es limitado
(Hernández, Fernández, Baptista, 2006).
Se inicia mediante la investigación de las fuentes bibliográficas relacionadas al tema de
la estabilidad dinámica, con el fin de comprender los métodos y técnicas actuales para la
medición de la misma. Se busca un estudio correlacional entre las distintas variables
asociadas y medibles mediante sensores inerciales.
Además se estudian las relaciones matemáticas que unen los eventos físicos de la
estabilidad dinámica con los datos experimentales obtenibles por sensores inerciales, con el
4
fin de encontrar posibles limitaciones.
Una vez conocido el estado del arte en este campo, se pasa a la investigación
bibliográfica del funcionamiento interno del controlador Wii™, sus componentes y
protocolos de comunicación, así como el uso de los sensores inerciales contenidos en el
controlador. Hasta este punto el proyecto se mantiene meramente teórico e investigativo.
Finalmente se procede a la aplicación del conocimiento teórico adquirido en la creación
de una solución a los problemas planteados, mediante programación de software, utilizando
distintas técnicas de desarrollo.
Cada objetivo específico de la investigación tiene un método primario de investigación
asociado, el cual es un recurso primario para lograr el objetivo planteado, mientras que
también posee un método investigativo secundario que ayuda en ciertos aspectos del
desarrollo del objetivo. A continuación se detalla el método primario y segundario de
investigación para cada objetivo del proyecto.
Tabla 1.1 Métodos de investigación asociados a cada objetivo específico según Hernández, Fernández y Baptista
Objetivo
Método Primario
Método Segundario
I
Investigación fundamental
Investigación aplicada
II
Investigación aplicada
Investigación experimental
III
Investigación experimental
Investigación bibliográfica
CAPÍTULO 2: Desarrollo teórico
2.1 Sensores inerciales: acelerómetros y giróscopos
Dos de los instrumentos que se utilizan típicamente para la medición de movimiento y
estimación de la posición son los acelerómetros y los giróscopos.
Los acelerómetros son dispositivos que pueden medir tanto la aceleración estática
(como por ejemplo, la gravedad), como la dinámica (vibraciones, cambios de dirección) en
uno o varios ejes coordinados. Típicamente, se implementan como pequeñas barras móviles
suspendidas sobre resortes que proveen cierta resistencia en contra de la aceleración, y de
esta forma, la deflexión de tal barra puede utilizarse como medida de tal magnitud. Sin
embargo, hoy en día, aparte de los acelerómetros mecánicos, es posible encontrar otras
variaciones tales como los acelerómetros piezoeléctricos, de efecto Hall, capacitivos, o de
tipo MEMS (sistemas micro-electromagnéticos).
Es importante mencionar que al estar ubicado dentro de un marco de referencia que no
está aislado, sino que se encuentra sujeto a la fuerza gravitacional de la Tierra, siempre se
contará con una componente de aceleración fija en el eje –Z, la cual debe tomarse en cuenta
y compensarse adecuadamente cuando se quieren obtener valores absolutos de aceleración
en los distintos ejes, especialmente cuando el objeto está en rotación. De hecho, es usual que
los acelerómetros den sus medidas en unidades de g (1g ≈ 9.8 m/s2).
En teoría, los acelerómetros pueden también ser utilizados para hacer una medición o
estimación del movimiento, dado que la posición de un objeto puede ser obtenida como la
doble integral de la aceleración respecto al tiempo, esto es:
𝑑2 𝑋
𝑋 = ∬𝑇 ( 𝑑𝑡 ) 𝑑𝑡𝑑𝑡
(2.1-1)
Sin embargo, lo anterior resulta práctico para períodos cortos de tiempo, puesto que el
5
6
error de integración se acumula con el cuadrado del tiempo, por lo que cualquier desviación
o ruido en la medición producirá errores intolerables en cuestión de minutos u horas.
Los giróscopos, por su parte, se utilizan para medir la orientación de un objeto, basado
en los principios de momento angular.
Tradicionalmente, los giróscopos mecánicos
consistían en una rueda giratoria montada en un soporte de tal manera de que su eje podía
girar libremente en cualquier dirección, aunque en la actualidad han sido reemplazados por
dispositivos MEMS, que por lo general consisten en masas diminutas que utilizan
vibraciones para medir la magnitud de los giros.
La medición de los giroscopios usualmente se da en velocidad angular, en unidades de
grados por segundo. Estas medidas se hacen con respecto a los ángulos de Euler, los cuales
ayudan a describir la orientación de un cuerpo rígido. Estos ángulos se conocen, según la
notación de Tait-Bryan como guiñada (yaw), cabeceo (pitch) y alabeo (roll), y son de uso
común en la navegación, principalmente en aeroplanos. La siguiente figura ilustra la manera
en que son definidos:
Figura 2.1 Orientación de los ángulos de Euler utilizados en los giróscopos 1
Ambos dispositivos, acelerómetros y giróscopos, suelen combinarse dentro de las
1
http://scifiles.larc.nasa.gov
7
llamadas Unidades de Medición Inercial (IMU por sus siglas en inglés), las cuales son útiles
para medir la velocidad, orientación y fuerzas gravitacionales que experimenta un objeto, tal
y como satélites, aviones, e incluso transbordadores espaciales. Para efectos de precisión,
los IMU suelen también ser complementados con aparatos tales como magnetómetros, GPS
o cámaras que les permiten contrarrestar problemas intrínsecos del IMU tales como errores
de integración acumulados, o falta de precisión para determinar la posición absoluta de un
objeto.
Desde la década de los 1950, se comenzó a proponer el uso de acelerómetros como una
alternativa para evaluar el movimiento del cuerpo humano. Sin embargo, el hecho de que
fueran pesados, costosos y poco confiables hacían que su uso fuera de gran dificultad
(Culhane, O’Connor, D. Lyons, G. Lyons, 2005). No es sino hasta años recientes, con el
desarrollo de la microelectrónica, los MEMS, y la integración de acelerómetros y giróscopos
dentro de unidades de IMU compactas y precisas, que vuelve a tomar fuerza la utilización de
estos dispositivos para tal fin. El único parámetro que se había mantenido como desventaja
era el del costo, con unidades del rango de varios miles de dólares.
Con el avance tecnológico en los últimos años de teléfonos móviles y consolas de
videojuegos que integran acelerómetros y giróscopos de bajo costo, y de precisión aceptable,
surge la idea de poder utilizar tales dispositivos en mediciones de movimiento y estabilidad,
tal y como se plantea en el presente proyecto.
En específico, resulta de interés utilizar el controlador del Nintendo® Wii™, conocido
como Wiimote, debido a su bajo costo, y a su gran disponibilidad en el mercado, así como
en muchos hogares, clínicas e incluso en hogares de ancianos alrededor del mundo.
2.2 El Wiimote como instrumento de medición inercial
En el año 2006, Nintendo® introdujo al mercado la consola de juegos Wii™, con la
novedad de tener una mayor interacción con el jugador al contar con un control (llamado Wii
8
Remote ™) que era capaz de detectar el movimiento en tres dimensiones.
Para realizar la detección de movimiento el Wiimote, en su versión original, contaba
con un acelerómetro montado en la parte superior de su circuito impreso, además de
complementarse con una cámara infrarroja en la parte frontal del mismo, la cual capturaba la
señal de una barra de LEDs infrarrojos que se coloca cerca del televisor y permitía determinar
la ubicación del control en un momento dado.
Además de las características anteriores, el Wiimote contaba con botones y palancas
como los de un control convencional, un micro-controlador Broadcom BCM2042 para
procesar los datos y realizar la comunicación Bluetooth® con la consola, una memoria
EEPROM de 16 kB para almacenar parte del código del controlador, o una sección de lectura
y escritura para el usuario, además de registros de control y puertos específicos para otros
dispositivos periféricos.
Debido a la popularidad que alcanzó la consola por la innovación de sus controles, y a
que estos se comportaban como un dispositivo de Bluetooth® tradicional, comenzaron a
surgir gran cantidad proyectos a nivel mundial, especialmente en ámbitos académicos, que
intentaban explotar la capacidad del Wiimote más allá de su uso regular, utilizando
aplicaciones realizadas por “terceros”, e incluso conectándolo a una computadora personal
(PC). Ejemplos de ellos pueden encontrarse en el proyecto del Wii Homebrew, donde varios
colaboradores se dedicaron a elaborar un Wiki (http://www.wiibrew.org) destinado, entre
otras cosas, a describir con lujo de detalles el funcionamiento del Wiimote, su protocolo de
comunicación, características de los acelerómetros y otros datos.
A pesar de que los acelerómetros del control del Wii se comportaban bastante bien en
la mayoría de las situaciones, existían algunos casos (como por ejemplo, giros sobre alguno
de los ejes) donde la respuesta no era la esperada, debido a la naturaleza intrínseca del
acelerómetro. Por esto, en el año 2009 Nintendo® lanza al mercado el accesorio Wii Motion
Plus™, el cual incorpora un sistema de giróscopos en los 3 ejes, y que permite una captura
más fiel de los movimientos realizados por el jugador.
9
Gracias a todas las características anteriores es que resulta de interés utilizar el Wiimote
como un instrumento de medición inercial para ser utilizado en experimentos para determinar
la estabilidad dinámica y postural de distintos pacientes, utilizando la información extraída
de sus acelerómetros y giróscopos, y aprovechando el hecho de que este accesorio,
sincronizado con una computadora, puede utilizarse como una unidad inercial de bajo costo.
Sin embargo, resulta importante conocer los detalles de los dispositivos de medición para
estar consciente de sus alcances y limitaciones.
10
2.2.1 Características del acelerómetro del Wiimote
Según la información que revela el grupo del Wii Homebrew, el control del Wii está
equipado con un circuito integrado ADXL330 de Analog Devices, el cual contiene un
acelerómetro lineal de tres ejes de baja potencia, que es capaz de medir tanto la aceleración
estática debido a la gravedad, como aceleración dinámica que resulta de golpes, vibraciones
o movimiento.
El sensor es en realidad una estructura MEMS con superficie de poli-silicio colocada
sobre una base de silicio, que utiliza resortes miniatura de poli-silicio que suspenden la
estructura sobre la base y que proveen resistencia contra la aceleración. La deflexión de la
estructura se mide entonces utilizando un capacitor diferencial, que se desbalancea y provee
una lectura del sensor cuya amplitud es proporcional a la aceleración2.
Como se utiliza una sola estructura para medir los tres ejes, las direcciones de medición
son sumamente ortogonales entre sí y por lo tanto impiden errores debido al cruce de varios
ejes.
A continuación se brinda un resumen de sus especificaciones más relevantes, pero los
detalles completos se pueden encontrar en la hoja de datos en la sección de Anexos.
Tabla 2.1 Resumen de especificaciones del acelerómetro ADXL330
Parámetro
Valor típico
Voltaje de Operación
2.0 V
Rango de medición (por eje)
±2 g
±4 g
270 mV/g
300 mV/g
Sensibilidad en X,Y,Z (@ Vs
= 3V)
Ancho de Banda X,Y
2
Valor mínimo
Valor máximo
3.6 V
1600 Hz
https://www.sparkfun.com/datasheets/Components/ADXL330_0.pdf
330 mV/g
11
550 Hz
Ancho de Banda Z
170 µg/√Hz rms (X,Y)
Densidad de Ruido
350 µg/√Hz rms (X,Y)
En cuanto a su ubicación, el micro-chip está colocado de tal forma dentro del Wiimote,
que la orientación de los ejes de medición es la siguiente:
Figura 2.2 Orientación de los ejes para el acelerómetro del Wiimote3
Como puede observarse, si el control está en reposo en posición neutra entonces
reportará un aceleración igual a la gravedad (1 g ≈ 9.8 m/s2) en el sentido del eje -Z.
2.2.2 Características de los giróscopos del Wiimote
Para la implementación de los giroscopios para el control del Wii, Nintendo® decidió
hacer una combinación de soluciones al utilizar el modelo IDG-600 de Invensense como un
giróscopo integrado de eje-dual (X,Y) y el Epson Toyocom X3500W para el eje Z.
El IDG-600 utiliza dos sensores implementados como giroscopios de tipo “diapasón”,
3
www.wiibrew.org
12
los cuales contienen un par de masas vibratorias que oscilan en igual magnitud, pero en
direcciones opuestas dentro del plano del diapasón. Cuando se rota el dispositivo, las fuerzas
de Coriolis crean una vibración ortogonal que es proporcional a la razón de rotación, y utiliza
entonces técnicas de sensores capacitivas entre la estructura oscilante y un marco estático
que lo rodea para así medir la velocidad angular (Ω) de la masa (Nasiri, Sachs, Maia, 2008).
Este funcionamiento es ilustrado por medio de la siguiente figura, donde las dos piezas
más oscuras representan las masas vibratorias las cuales están unidas entre sí por tres placas
de torsión montadas sobre micro-resortes.
Figura 2.3 Funcionamiento de un giróscopo MEMS de tipo diapasón
Algunas de las características mecánicas y eléctricas más representativas del
Invensense IDG-600 son las siguientes:
13
Tabla 2.2 Resumen de especificaciones del giróscopo IDG-600 de Invensense
Parámetro
Voltaje de Operación
Rango de medición (por eje)
Valor mínimo
Valor típico
2.7 V
3V
±500 º/seg
Valor máximo
3.3 V
2000 º/seg
140 Hz
Respuesta en frecuencia
Medición en Ejes
X, Y
Sensibilidad entre ejes
< 1%
Desafortunadamente, no hay mucha información disponible acerca del X3500W, sin
embargo, es posible obtener una hoja de datos del XV-3500CB4, el cual es igualmente un
giróscopo de vibración que presenta características muy similares al otro modelo, según
discusiones en múltiples foros de proyectos con el Wiimote.
Tabla 2.3 Resumen de especificaciones del giróscopo XV-3500CB de Epson Toyocom
Parámetro
Voltaje de Operación
Rango de medición (por eje)
Factor de escala
Respuesta en frecuencia
Medición en Ejes
Sensibilidad entre ejes
4
Valor mínimo
Valor típico
2.7 V
3V
-100 º/seg
Valor máximo
3.3 V
100 º/seg
0.67 º/seg
200 Hz
Z
±5%
http://www.epsontoyocom.co.jp/english/product/Sensor/set01/xv3500cb/index.html
14
En cuanto a la orientación del control, los giróscopos están colocados de tal forma que
el giro en cada uno de los ejes dará magnitudes positivas cuando se mueva en dirección a las
flechas que indica la siguiente figura.
Yaw
(Guiñada)
Roll (Alabeo)
Pitch
(Cabeceo)
Figura 2.4 Orientación de los ejes para los giróscopos del Wiimote
Al final, para obtener correctamente el movimiento del control generado por el usuario,
el Wii® utiliza una combinación de las lecturas de todos sus acelerómetros y de sus
giróscopos, además de utilizar la combinación del sensor-cámara infrarroja para determinar
con precisión la posición y orientación actual del Wiimote.
2.2.3 Comunicación Bluetooth® del Wiimote
Como se había mencionado anteriormente, el Wiimote es un dispositivo inalámbrico
que utiliza el chip BCM2042 de Broadcom como micro-controlador, el cual es comúnmente
utilizado para fabricar teclados y ratones de computadora que se conectan con su unidad
central por medio de Bluetooth®.
El control de Wii® por lo tanto utiliza un protocolo de Bluetooth® de tipo HID
(dispositivo de interfaz humana), el cual a su vez está basado en el protocolo HID de USB.
15
Sin embargo, según los datos del grupo del Wii Homebrew, el Wiimote no utiliza
estrictamente los tipos de dato estándar y los descriptores de HID, sino que sólo describe su
longitud de reporte de datos dejando los contenidos indefinidos5, lo cual impide utilizar
drivers de HID estándar, y requiere por lo tanto drivers especiales cuando se quiera utilizar
el control con una computadora en lugar de una consola de Wii®.
En la realidad, el Wiimote realiza una serie compleja de operaciones, y transmite los
datos a través del protocolo HID, utilizando paquetes de datos de longitud variada. Por
suerte, es posible encontrar la descripción de la mayoría de los paquetes utilizados en
documentación de grupos como el Wii Homebrew, lo cual facilita el desarrollo de
aplicaciones y drivers de forma abierta.
Antes de poder utilizar la comunicación por Bluetooth® con la computadora, es
necesario realizar una etapa de sincronización (pairing) entre los dos dispositivos. Para lograr
esto, es necesario presionar los botones (1) y (2) del Wiimote para que este sea “descubierto”
y por lo tanto, detectable desde la PC. Una vez detectado, se realiza un enlace que no requiere
introducir ninguna clave (PIN).
En la comunicación HID, el Wiimote utiliza reportes unidireccionales (de entrada o de
salida) que tienen un descriptor indicando la dirección y el tamaño de la carga (payload) para
cada puerto. El reporte de entrada se entiende como uno que se envía desde el control hasta
su unidad central (consola o PC) y el de salida en dirección contraria. La tabla siguiente
presenta algunos reportes HID comúnmente utilizados:
Tabla 2.4 Reportes HID utilizados por el Wiimote
I/O
5
Identificación
Tamaño (bytes)
Función
O
0x11
1
LEDs de jugador
O
0x12
2
Modo de reporte de datos
http://wiibrew.org/wiki/wiimote
16
O
0x15
1
Solicitud de información de estado
O
0x16
21
Escribir memoria y registros
O
0x17
6
Leer memoria y registros
I
0x20
6
Información de Estado
I
0x21
21
Datos de lectura de memoria y registros
I
[0x30-0x3F]
[2-21]
Reportes de datos
Dentro de los reportes de datos, se incluyen datos de acelerómetros, los cuales se
combinan con datos de los botones del control. Un ejemplo de ello es el reporte 0x31,
“Botones principales y Acelerómetro”, los cuales devuelven la información combinada de
estas dos fuentes de la siguiente manera:
Tabla 2.5 Reporte 0x31 HID para botones y acelerómetro
Byte
0
1
2
3
4
5
6
Dato
(a1) 31 BB BB XX YY ZZ
El byte 0 corresponde al comando de Bluetooth® HID, seguido por el número de
reporte (bytes 1), ya luego los bytes 4,5,6 llevarán los datos de los acelerómetros indicados
de cada eje, según la letra indicada, y los bytes 2 y 3 los valores de los botones. Sin embargo,
dentro de los bytes correspondientes a los botones también se incluyen los bits menos
significativos de la medida de los acelerómetros, de la siguiente forma:
Tabla 2.6 Datos de acelerómetro combinado con datos de botones en reporte 0x31 HID
Bit
Byte 0
Byte 1
7
6
5
X [1:0]
Z[1]
Y[1]
4
3
2
1
0
17
Se observa que, para este caso X tiene 10 bits de precisión mientras que Z y Y tienen
9. Por consistencia, se extiende todos a 10 bits, usando un 0 en el bit menos significativo.
De una manera similar se reportan también los datos de los giróscopos, de la cámara
infrarroja, de registros, entre otros.
Esto es esencial conocerlo para poder realizar
aplicaciones, librerías, o drivers que puedan leer e interpretar desde una computadora los
datos que provienen desde un Wiimote.
CAPÍTULO 3: Sistema de captura para el cálculo de la
estabilidad dinámica
3.1 Consideraciones iniciales
El diseño del sistema de captura de datos para el cálculo de la estabilidad dinámica
debe considerar una metodología similar a la documentada por Menz, Lord y Fitzpatrick. Los
sensores utilizados están integrados en los controladores de Wii® o wiimotes, a colocarse
uno sobre la columna vertebral a la altura de la cintura y el otro en la parte posterior o sobre
la cabeza del sujeto bajo estudio. La metodología difiere en cuanto no es necesario que el
individuo bajo estudio lleve consigo un computador portátil, si no que éste puede colocarse
a una distancia no mayor al alcance del enlace bluetooth6 que enlaza los wiimotes con el
computador. El operador del sistema de captura inicia los procesos de calibración y toma de
datos desde el computador sin necesidad de interferir con el movimiento del individuo bajo
estudio.
3.2 Librería de conexión con el controlador Wii®
Existen diferentes implementaciones que proporcionan una API para enlazar el
controlador Wii® a un computador bajo el sistema operativo Linux. La librería que se utilizó
debía cumplir los siguientes requisitos:

Estar codificada en C/C++, para ser utilizada bajo esos lenguajes de programación.

Debe permitir el enlace de al menos cuatro7 controladores Wii®.

La librería a utilizar debe estar liberada bajo una licencia GNU8 o similar que
permita posibles modificaciones al código fuente, que permita la utilización
con fines investigativos y que permita una posterior redistribución.
6
Protocolo de Red Inalámbrica de Área Personal que utiliza un enlace por radiofrecuencia para la transmisión y recepción de control y datos entre dispositivos.
7
A pesar de que el proceso de captura para la estimación de la estabilidad dinámica requiere solo dos controladores, las siguientes partes del proyecto requieren al menos cuatro controladores conectados al
computador.
8
http://www.gnu.org/licenses/licenses.es.html
18
19

Debe ser suficientemente estable de modo que sea posible la captura de datos
continua con una frecuencia de muestreo constante durante el tiempo que
tarde cada prueba. La captura de datos constante durante un minuto puede
considerarse suficiente.
Dadas las anteriores restricciones, se encontraron las siguientes candidatas:

wiiuse9

wiic10

Cwiid11
Se eligió wiic debido a que cumple con todos los requisitos anteriores y además su
mantenimiento se ha mantenido activo hasta la fecha, a diferencia de cwiid. Wiic es además
utilizada por el laboratorio de robótica de la Universidad de Sapienza, Italia.
3.3 Interfaz de programación de aplicación de wiic
La API12 o interfaz de programación de aplicación proporcionada por wiic está descrita
en la web del proyecto WiiC. En términos básicos, wiic provee dos clases para el acceso y
manipulación de los wiimotes:

CWii: Esta clase proporciona las funciones que no son específicas a un controlador, tal como CWii::Find() y CWii::Connect(), las cuales son utilizadas
para buscar controladores y establecer la conexión con los que estén disponibles.
9
http://sourceforge.net/projects/wiiuse/
http://wiic.sourceforge.net/
11
http://abstrakraft.org/cwiid/
12
La documentación de la API de WiiC se encuentra en http://wiic.sourceforge.net/docsy/index.html
10
20

CWiimote: Proporciona los métodos necesarios para ejecutar acciones específicas a cada controlador, por lo tanto, debe instanciarse un objeto CWiimote
para cada controlador disponible.
La comunicación entre el computador y cada controlador Wii® es de tipo maestroesclavo, es decir, en todo caso la comunicación entre los dispositivos es iniciada por el
computador. Para obtener datos del controlador, el computador debe hacerle polling, a lo cual
el controlador responde con una lista de eventos pendientes de ser atendidos. Un evento
puede corresponder a un botón que se ha oprimido o un sensor que ha generado nuevos datos.
3.4 Arquitectura del sistema de captura
El sistema de captura de datos implementado está basado en una máquina de estados
que puede visualizarse en la siguiente figura:
21
Figura 3.1: Máquina de estados del sistema de captura
La capa de control del sistema de captura está basada en “sesiones”, que corresponden
a las acciones necesarias para capturar los datos generados por los sensores de los wiimotes
transportados por el sujeto bajo estudio mientras recorre una distancia predeterminada. La
máquina de estados controla las diferentes etapas de cada sesión, dirigiendo la ejecución de
las diferentes secciones del programa según sea indicado por el usuario. Fue implementada
en el archivo main.cpp13. Tal como se observa en la figura 3.1, los estados de la máquina son
los siguientes:
13
http://code.google.com/p/careco-in-motion/source/browse/main.cpp
22

Inactivo (IDLE): El sistema se encuentra inactivo, a la espera de que el usuario le indique empezar una nueva sesión de captura.

Buscando (FIND): El usuario ha indicado iniciar una nueva sesión, el sistema
debe buscar y conectarse a los wiimotes.

Espera usuario (WAIT_USER_CALIBRATE): El sistema se ha conectado exitosamente a los wiimotes y está a la espera de que el usuario le indique que
puede calibrar los wiimotes.

Calibrando (CALIBRATING): El sistema recolecta una pequeña cantidad de
datos (aproximadamente 300 muestras en 3 segundos) de modo que se pueda
saber cuál es la posición en reposo de los wiimotes para posteriormente contrarrestar el efecto de la gravedad sobre los acelerómetros y también aproximar los sensores a un mismo sistema de referencia.

Espera usuario (WAIT_USER_CAPTURE): Una vez que se recolectó exitosamente la información de calibración, el sistema se encuentra a la espera de
que el usuario le indique iniciar la captura de datos.

Capturando (CAPTURING_DATA): El usuario ha indicado iniciar la captura
de datos. El sujeto bajo estudio debe iniciar igualmente la caminata. El usuario debe indicar al sistema cuándo detener la captura.

Salir (QUIT): El usuario ha indicado terminar el programa y retornar el control al sistema operativo (shell).
En el siguiente diagrama se puede observar cómo se integran las capas de control y
de datos.
23
Figura 3.2: diagrama de bloques del sistema de captura.
La capa de control está implementada en los archivos main.cpp, wmCtrl.h y
wmCtrl.cpp, con una orientación a objetos. Es decir, cada vez que se inicia una nueva sesión
de captura, el sistema instancia un nuevo objeto de la clase wmCtrl_c, descrita en wmCtrl.h.
La clase contiene los miembros necesarios para controlar y describir una sesión de captura,
incluyendo todos los datos capturados durante ella mientras que los diferentes métodos que
actúan sobre los miembros son ejecutados por la máquina de estados al ir pasando de un
estado a otro al avanzar la sesión de captura.
A continuación de describen los métodos de wmCtrl_c:

wmCtrl_c::initSession(): Este método se ejecuta cuando la máquina de estados entra en los estados CALIBRATING y CAPTURING_DATA. Inicializa
las variables para el control de la frecuencia de muestreo y si el estado es
CAPTURING_DATA, los archivos de texto en los que posteriormente se escribirán los datos obtenidos de los sensores y los resultados del post-procesamiento.
24

wmCtrl_c::endSession(): Al salir del estado CAPTURING, se deben cerrar
los archivos de texto.

wmCtrl_c::wmInitDevices(): Este método es ejecutado cuando la máquina
llega al estado FIND. El método utiliza la API de wiic para iniciar la comunicación con los wiimotes que estén disponibles en estado visible. Adicionalmente, el método configura el umbral de sensibilidad de los acelerómetros
(ACC_THRESHOLD, definido en wmConfig.h) y habilita los sensores de
aceleración y velocidad angular (giróscopos). Es importante mencionar que
inicialmente se deben habilitar solo los acelerómetros y leer datos antes de
habilitar los giróscopos. Si se habilitan los giróscopos al mismo tiempo, al
leerlos se obtendrán datos inválidos o ceros. El procedimiento anterior se realiza en la función wmCtrl_c::wmSensorsON.

wmCtrl_c::wmTestDevices(): Este método simplemente genera una acción
de vibración perceptible por el usuario, de manera que pueda asegurarse que
cada wiimote ha sido debidamente inicializado.

wmCtrl_c::wmDisconectDevices(): Durante el estado CAPTURING_DATA,
luego de que el usuario ha indicado el fin de la captura de datos, la máquina
ejecuta este método, el cual termina la comunicación con los wiimotes.

wmCtrl_c::wmCapture(): Este método es ejecutado en los estados CALIBRATING y CAPTURING_DATA, su labor es inicializar las estructuras de
datos necesarias para almacenar los datos provenientes de los sensores durante la toma de datos e iniciar un bucle de polling a los wiimotes. El bucle
contiene un retardo variable que utiliza la función usleep() de modo que la
frecuencia de muestreo se mantenga alrededor de los 100 Hz. Utiliza las funciones de la API de wiic GetGravityVector() y GetRates() para obtener lecturas de los acelerómetros y los giróscopos respectivamente. En el caso que sea
25
llamado desde el estado CALIBRATING, el método ignora los datos obtenidos de los sensores durante WM_DEADTIME segundos debido a que éstos
tienden a ser inestables por lo que son indeseables para efectos de calibración.

wmCtrl_c::wmProcessCalibrationData(): Una vez que se han obtenido datos
de calibración durante WM_CALIBRATION_TIME segundos, la máquina
de estados ejecuta este método, el cual promedia los valores de los acelerómetros y los giróscopos para generar los vectores de calibración.

wmCtrl_c::wmProcessCapturedData(): Similarmente, una vez que se ha concluido la sesión de captura de datos, la máquina de estados ejecuta este método, el cual conduce todo el post-procesamiento de los datos para generar
los resultados para la estimación de la estabilidad dinámica.

wmCtrl_c::printdataPoint():

wmCtrl_c::wmPrintCalibrationData():
3.5 Estructuras de datos
La sección del sistema de captura concerniente a la organización interna de las
estructuras de datos y las operaciones matemáticas necesarias para el post-procesamiento se
implementó en los archivos wmData.cpp y wmData.h. Se esta manera, se ha logrado aislar
las dos capas (control y datos) de tal forma que es posible hacer ajustes en los algoritmos y
operaciones matemáticas sin necesidad de afectar las rutinas de control explicadas en la
sección 3.4.
3.5.1 Clase vector_s
Se decidió utilizar un vector de tres dimensiones como unidad básica de información,
representada mediante la clase vector_s. Dicha clase contiene métodos para la manipulación
básica de vectores, como suma, substracción y escalamiento de vectores. Se implementó
también un método que reemplaza cada componente del vector con su recíproco y otro
método que realiza una operación similar, reemplazando cada componente con su respectiva
26
raíz cuadrada.
3.5.2 Clase dataPoint_s
En orden de complejidad, la siguiente unidad de datos se definió de manera que pudiese
contener todos los datos correspondientes a una muestra. De esa forma, un objeto de la clase
dataPoint_s está integrado por los dos vectores obtenidos de los acelerómetros y los
giróscopos respectivamente, el tiempo al que corresponden dichas lecturas y un número de
identificación para distinguir de cual wiimote provienen los datos. La clase contiene los
siguientes métodos:

dataPoint_s::initAll(): Este método se usa para inicializar los datos al momento de leer los sensores durante la ejecución del bucle de muestreo en
wmCtrl_c::wmCapture(). Toma como argumentos dos vectores provenientes
de los acelerómetros y giróscopos, el tiempo y el número de wiimote del cual
provienen los datos.
3.5.3 Clase fftdataPoint_s
Durante la rutina de post-procesamiento a ser descrita en detalle en la sección 3.6, debe
calcularse la transformada rápida de Fourier de los datos de aceleración y velocidad angular.
Cada elemento de la serie que resulta de la transformada corresponde a un objeto de la clase
fftdataPoint_s, cuyos elementos son un vector que contiene los valores absolutos de la
transformada y un valor punto flotante que contiene la frecuencia a la cual corresponden los
valores del vector. La clase solo tiene un método para inicializar los valores de los elementos.
3.5.4 Clase results_s
Los resultados del post-procesamiento de los datos provenientes de cada wiimote se
almacenan en un objeto de la clase results_s. El objeto contiene los elementos
correspondientes a los parámetros espacio-temporales y a las variables de aceleración.
También contiene variables intermedias que se utilizan durante la rutina de postprocesamiento, a ser descrita en la sección 3.6. El método de inicialización solo escribe la
27
variable wmInstance, la cual indica a qué wiimote corresponden los datos. Los demás
elementos son asignados directamente por los métodos de post-procesamiento. La clase
contiene además un método que permite la impresión de los resultados en un archivo de texto.
3.5.5 Clase ratios_s
De la misma forma que results_s, ratios_s se utiliza para almacenar resultados del postprocesamiento. Ratios_s sin embargo, se utiliza para las razones armónicas que resultan de
combinar los datos provenientes de dos wiimotes, a ser colocados en la cabeza y la cintura
del sujeto bajo estudio. El método ratios_s::calculateRatios() toma dos objetos de la clase
results_s correspondientes a los wiimotes colocados en la cabeza y cintura como argumentos
y calcula las razones armónicas. Al igual que results_s, ratios_s tiene un método para
imprimir las razones armónicas en un archivo de texto.
3.5.6 Clase dataSeries_s
Durante la toma de datos que se realiza por medio de wmCtrl_c::wmCapture(), cada
objeto de tipo dataPoint_s correspondiente a cada muestra se acumula en un objeto de clase
dataSeries_s. Existe un objeto dataSeries_s para cada wiimote activo durante la sesión de
captura. De esta manera, dataSeries_s sólo contiene dos elementos: un entero wmInstance
que indica a cual wiimote corresponde el objeto y un vector de objetos de la clase dataPoint_s,
implementado usando la librería estándar std::vector.
Los métodos de dataSeries_s son utilizados durante el post-proceso y serán descritos
en la sección 3.6.
3.6 Post-procesamiento de datos
Una vez obtenidas las lecturas de aceleración y velocidad angular, la máquina de
estados ejecuta una serie de métodos que calculan los diferentes parámetros necesarios para
estimar la estabilidad dinámica. Estos métodos son ejecutados durante el estado
CAPTURING_DATA y están agrupados en la rutina wmCtrl_c::wmProcessCapturedData().
28
Los métodos de post-procesamiento pertenecen en su mayoría a la clase dataSeries_s,
y se describen a continuación.
3.6.1 Corrección de los vectores de aceleración y velocidad angular
Las lecturas de los acelerómetros incluyen, como es esperado, la componente de la
gravedad. Debido a que ésta es constante, se puede eliminar fácilmente con solo restar el
vector g a cada una de las muestras. Sin embargo, es necesario calcular de antemano cual es
el vector g según la orientación del wiimote durante la toma de datos. La rutina de calibración
está destinada a obtener el vector de calibración para cada wiimote disponible durante la
inicialización.
En el caso de los giróscopos, se encontró que en general los sensores proporcionan
valores de velocidad angular con un offset constante que de la misma forma que los
acelerómetros, se elimina restando el valor promedio obtenido durante el proceso de
calibración.
Es importante hacer notar que el proceso de calibración debe realizarse con los wiimotes
en la posición en la cual se realizará la captura de datos, es decir, colocados en la cabeza y
cintura del sujeto bajo estudio.
Los métodos que corrigen los datos de aceleración y velocidad angular son los
siguientes:

dataSeries_s::correctAccelData(): Substrae a cada muestra de aceleración en
un objeto de tipo dataSeries_s el vector de calibración obtenido como argumento.

dataSeries_s::correctGyroData(): Substrae a cada muestra de velocidad angular en un objeto de tipo dataSeries_s el vector de calibración obtenido como
argumento.
3.6.2 Cálculo la media cuadrática (RMS)
Una vez corregidos los datos de aceleración y velocidad angular, puede iniciarse los
cálculos de los parámetros de aceleración. La media cuadrática es calculada
29
independientemente para todas las componentes de aceleración siguiendo la fórmula:
1
2
𝑎𝑅𝑀𝑆 = √𝑁 ∑𝑁−1
𝑖=0 𝑥𝑖
(3.6.2-1)
Donde N es el número de elementos dataPoint_s acumulados en el objeto data de clase
dataSeries_s. El método dataSeries_s::calculateRMSSeries calcula la media cuadrática de las
componentes de aceleración y almacena los resultados en el objeto de clase results_s que
obtiene como argumento. Este método es ejecutado por wmCtrl_c::wmProcessCaptureData()
sobre todos los objetos dataSeries_s disponibles.
3.6.3 Cálculo de las variables espacio-temporales
El cálculo de las variables espacio-temporales requiere discernir, a partir de los datos
de aceleración lineal y/o velocidad angular, los pasos del sujeto bajo estudio. Es decir, se
debe detectar alguno de los eventos distintivos que suceden durante la caminata, siendo más
evidente el momento de contacto piso-talón debido al característico pico de la componente
vertical de la aceleración.
El método dataSeries_s::findCadenceSeries() se encarga de analizar la componente
vertical de la aceleración. Utiliza un algoritmo de búsqueda de máximos locales basado en
una “ventana” móvil que abarca una cantidad fija de muestras. Para cada ventana, el
algoritmo busca la muestra cuyo valor es el máximo y almacena el valor y el índice
correspondiente. Cuando la ventana móvil ha recorrido toda la serie de datos, el algoritmo
busca los índices que se han repetido una cantidad de veces mayor al tamaño de la ventana.
Si el valor que corresponde a cada uno de esos índices es mayor al valor RMS de la
aceleración vertical, se considera que en ese punto existe un máximo local, es decir,
corresponde a un evento de contacto piso-talón.
30
Figura 3.3: Patrón característico de la componente vertical de la aceleración durante
la caminata.
A partir de los resultados del anterior algoritmo, se calculan los diferentes
parámetros:

Cadencia: Definida como número de pasos por segundo, la cadencia se obtiene dividiendo el tiempo total en el que el sujeto bajo estudio caminó (no el
tiempo total en el que se capturaron datos, ya que se introduciría un error) por
el número de pasos dados. El tiempo total de la caminata se definió como el
tiempo en el que ocurrió el último paso menos el tiempo en el que ocurrió el
primer paso dado. También se calcula la desviación estándar de la cadencia,
utilizando el valor medio cuyo cálculo se describió anteriormente y los tiempos transcurridos entre cada instante de contacto piso-talón.

Longitud de paso: Debido a que se parte de la suposición de que el sujeto
bajo estudio recorre una distancia predeterminada (definida como
WM_WALKINGDISTANCE en wmConfig.h), la longitud de paso se obtiene
simplemente dividiendo dicha distancia por el número de pasos detectados.
31

Velocidad de marcha: Similarmente, la velocidad se calcula dividiendo la distancia por el tiempo total de caminata.
3.6.4 Cálculo de armónicas
La obtención de armónicas a partir de los datos de aceleración, realizada por el método
dataSeries_s::fftwSeries(), requiere aplicar una Transformada Discreta de Fourier. Para ello
se utilizó la librería de C fftw14 en conjunto con un wrapper llamado fftwpp15 que simplifica
su uso proporcionando una API más sencilla y adaptada a C++.
El cálculo realizado por la Transformada Rápida de Fourier implementado en la librería
fftw obedece a la siguiente fórmula16:
−2𝜋𝑖𝑗𝑘𝑁
𝑌𝑘 = ∑𝑁−1
𝑖=0 𝑌𝑘 𝑒
(3.6.4-1)
Donde N es el número total de muestras en la serie a la que se aplica la transformada.
La serie Yk posee simetría hermítica, es decir:
∗
𝑌𝑘 = 𝑌𝑁−𝑘
(3.6.4-2)
Por lo que fftw solo calcula la Yk para los primeros N/2 elementos. La serie resultante
Yk contiene números complejos, por lo que antes de almacenar los resultados de la
transformada en un objeto de clase results_s, fftwSeries() calcula el valor absoluto de cada
elemento. Además, el método calcula la frecuencia a la cual corresponde cada valor mediante
la siguiente fórmula:
𝑣
𝑓𝑘 = 𝑁 𝑘
(3.6.4-3)
Donde v es la frecuencia de muestreo y k va desde 1 hasta N/2. El primer elemento (f0)
es ignorado junto con Y0 por corresponder a la “componente DC”17 de la serie. La serie
compuesta por pares (Yk, fk) es almacenada por fftwSeries() en un objeto de la clase results_s
para ser analizada por el método dataSeries_s::findPeakFreqSeries(), el cual busca las
frecuencias pico o armónicas utilizando el mismo algoritmo para la búsqueda de los máximos
14
http://www.fftw.org/
http://fftwpp.sourceforge.net/
16
http://www.fftw.org/fftw3_doc/The-1d-Real_002ddata-DFT.html#The-1d-Real_002ddata-DFT
17
Se refiere al valor de la componente constante de la señal.
15
32
locales descrito en la sección 3.6.3. Los resultados son almacenados en el mismo objeto
results_s obtenido como argumento.
Figura 3.4 Transformada Rápida de Fourier de un patrón de movimiento de período
constante predominante en el eje vertical.
Una vez concluidos todos los cálculos de la fase de post-procesamiento, el método
wmCtrl_c::wmProcessCapturedData() ejecuta las últimas tareas que consisten en imprimir
los datos de los sensores de aceleración y velocidad angular corregidos, los resultados de la
Transformada Rápida de Fourier y los demás parámetros en diferentes archivos de texto.
Todos los nombres de archivo tienen un sufijo único derivado de la fecha y hora en la que se
ejecutó la captura de datos. De esa forma se pueden hacer múltiples tomas de datos sin sobreescribir los datos de la sesión anterior.

Archivo wmdata_[fechayhora].log: contiene los datos corregidos obtenidos
de los acelerómetros y giróscopos durante la sesión de captura.

Archivo ftdata_[fechayhora].log: contiene los resultados de la Transformada
Rápida de Fourier.
33

Archivo rsults_[fechayhora].log: contiene el resto de los resultados del postprocesamiento para cada wiimote disponible durante la sesión de captura.
3.7 Resultados y discusión
Se empleó el sistema de captura descrito para recolectar datos de un individuo en
caminata bajo condiciones normales, sin obstáculos, a nivel sobre una superficie alfombrada,
con una extensión de 10 metros. A continuación se presentan los resultados gráficos
obtenidos de los acelerómetros y giróscopos, además de los resultados de la Transformada
Rápida de Fourier y del post-procesamiento. Los datos corresponden a un solo sensor,
colocado sobre la columna vertebral a la altura de la cintura.
Figura 3.5: Aceleraciones lineales durante la caminata.
34
Figura 3.6: Velocidades angulares durante la caminata.
Figura 3.7: Transformada Rápida de Fourier de aceleración vertical en el intervalo
completo de 0 a 50 Hz.
35
Figura 3.8: Transformada Rápida de Fourier de aceleración en el intervalo de 0 a 16
Hz.
Resultados del post-procesamiento:
Results corresponding to wiimote 0
Accelerometer RMS (g) : 0.10 0.10 0.15
Gyroscope RMS (deg/s): 89.48 18.62 36.23
Peak Frequencies (Hz):
fAz1= 2.07
fAz2= 4.24
fAz3= 6.20
fAz4= 8.38
fAz5= 10.45
fAz6= 21.00
fAz7= 23.07
fAz8= 24.81
fAz9= 40.04
36
fAz10= 41.89
Peak acceleration instants (s):
tAzMax= 2.26
tAzMax= 2.81
tAzMax= 3.43
tAzMax= 3.93
tAzMax= 4.40
tAzMax= 4.89
tAzMax= 5.36
tAzMax= 5.85
tAzMax= 6.32
tAzMax= 6.80
tAzMax= 7.26
tAzMax= 7.75
tAzMax= 8.24
tAzMax= 8.75
Time-space parameters:
Walking time: 6.49 s
Number of steps: 14
Cadence: 2.1572 steps/sec
Cadence stdDev: 3.2871 steps/sec
Stride: 0.77 m
Velocity: 1.54 m/s
Acceleration RMS ratios: 1.00 1.00 1.00
Angular velocity RMS ratios: 1.00 1.00 1.00
3.7.1 Discusión
Se observó que aunque los patrones en el tiempo de la caminata son bastante claros (ver
figuras 3.5 y 3.6), el hecho de que a lo largo de los 10 metros de caminata, el individuo solo
da unos 14 pasos hace que estos patrones no se reflejen con suficiente claridad a la hora de
visualizarlos en el dominio de la frecuencia (ver figuras 3.7 y 3.8). Aun así, el algoritmo de
búsqueda de máximos locales es suficientemente robusto para localizar las frecuencias
37
armónicas, identificadas como fAz1, fAz2, fAz3, fAz4 y fAz5. Sin embargo, realizar un
cálculo de razones armónicas con estos datos sería arriesgado, ya que la gran dispersión de
los resultados de la Transformada impide una estimación suficientemente precisa de la
magnitud que tienen estas armónicas.
Debido a que el enlace de radio bluetooth® utilizado por los controladores wii®
fallaría, o al menos sería inestable más allá de una distancia un poco mayor a 10 metros, es
recomendable considerar la utilización de una cinta ergométrica o caminadora de banda que
permita un enlace continuo y confiable mientras el individuo bajo estudio camina distancias
mayores, que permitan una mejor definición de los patrones de caminata y por consiguiente,
una estimación más precisa de los parámetros de estabilidad dinámica.
Respecto los demás parámetros espacio-temporales, se puede observar que son bastante
precisos y no requieren una corrección de los métodos para su cálculo.
Por otro lado, se hizo evidente también que la metodología de post-procesamiento
embebida en el sistema de captura no es la ideal para la experimentación. Esto por el hecho
que los datos se post-procesan inmediatamente después de ser capturados y a pesar de que
los datos fuente no se desechan, lo anterior tiene dos desventajas relacionadas entre sí:

Si se requieren hacer cambios o arreglos en los métodos de post-procesamiento y se desea repetir los cálculos basados en datos provenientes de la
misma sesión de captura, habría que introducir en el sistema de captura la
capacidad de poder leer los datos fuente (archivo wmdata_[fechayhora].log)
para reprocesarlos. Esto implicaría agregar un modo de uso distinto lo que
involucra gran cantidad de modificaciones al software.

Para el cálculo de los parámetros de estabilidad más sofisticados como los
coeficientes de Floquet y los exponentes de Lyapunov, es necesario un tratamiento matemático complejo. Es posible escribir el código en C++ que los
realice, sin embargo es más razonable utilizar algún tipo de software matemático como scilab, de modo que el sistema de captura se utilice solamente
38
para obtener los datos de los sensores y toda la parte del post-procesamiento
se haga “fuera de línea”.
3.8 Comparación de la captura de datos mediante el uso de wiimotes y
sensores inerciales comerciales.
Con el fin de poder evaluar la aptitud de la solución propuesta, su exactitud y utilidad,
se procedió a realizar una comparación de las capturas de datos provenientes del Wiimote,
contra mediciones provenientes de una solución IMU comercial.
La solución comercial disponible fue una serie de sensores inerciales de la marca
Technaid, proveídos por la Escuela de Ingeniería Mecánica. Estos sensores IMU son bastante
avanzados, incorporando giróscopo, acelerómetro y magnetómetro en un solo sensor.
Además de proveer al usuario con filtros de Kalman especialmente ajustados para cada
sensor. Algunas de las especificaciones técnicas se muestran a continuación:
Tabla 3.1 Especificaciones de los sensores del IMU Technaid.
Sensor
Giróscopos
Parámetro
Rango de medida
Sensibilidad
Acelerómetros
Rango de medida
Sensibilidad
Magnetómetros
Rango de medida
Sensibilidad
Valor
Unidades
± 500
± 8.727
°/s
rad/s
2,0
mV/o/S
± 3,6
± 35.32
g
m/s2
300
mV/g
± 2
± 200
gauss
µT
0,5
V/gauss
Para una correcta evaluación de las lecturas de los sensores, resulta imposible comparar
dos sesiones separadas de datos, es decir, es requisito indispensable que las dos capturas sean
realizadas exactamente en el mismo momento. Para lograr esto, en el experimento fue
necesario idear una forma de que el sujeto al cual se le realizó la prueba tuviera sobre sí los
39
dos sensores.
Se debe de tomar en cuenta que los dos tipos de sensores, aunque tienen funciones
similares, son completamente distintos en su forma física, siendo los IMU comerciales
sumamente pequeños, pero requieren estar conectados a una unidad de recolección de datos
que es en cierta manera grande e incómoda. Los wiimotes por otro lado, son de forma
irregular y bastante difícil de adherir al cuerpo del individuo. Fue necesario crear una especie
de casco y cinturón sobre el cual se montaron los wiimotes para las mediciones.
Posteriormente, los IMU fueron adheridos con cinta a estos aparatos. Esta solución resultó
ser funcional para mantener los dos sensores juntos, pero introduce una serie de
incertidumbres que podrían afectar las mediciones su comparación, las cuales se discutirán
más adelante.
El experimento como tal, consistió en colocar todos los sistemas de medición a un
hombre adulto sano, e indicarle que realizara una serie de tres caminatas en una distancia de
diez metros, ida y vuelta.
Los dos sistemas comenzaron la captura del movimiento en el mismo momento,
recolectando los datos con sus respectivos sistemas, en el caso del IMU, se guardaron los
datos en una tarjeta de memoria, mientras que en la solución con wiimotes se almacenaron
los datos directamente en la computadora utilizada para hacer las mediciones.
A continuación se muestran los resultados obtenidos para una de las pruebas realizadas
de caminata, para cada uno de los ejes de los acelerómetros.
40
Figura 3.9 Captura de datos del eje longitudinal
Figura 3.10 Captura de datos del eje antero-posterior
41
Figura 3.11 Captura de los datos del eje transversal
En las Figuras 3.9-3.11 se puede apreciar que aunque la tendencia de los datos es
similar, existen diferencias inclusive cuando los dos dispositivos se encuentran unidos
físicamente y son sometidos a las mismas fuerzas externas.
En todos los casos se puede apreciar que la magnitud de las aceleraciones registradas
por los IMU son en general mayores a las de los wiimotes. La Figura 3.11 muestra el caso
más extremo de esta situación, donde el IMU registra valores mayores a los 4G mientras que
el wiimote no pasa de 2G. Esto se explica en parte debido al mayor rango de medición de los
IMU, lo que causa que sea posible medir valores más grandes, cuando el wiimote se satura.
La segunda diferencia significativa en las mediciones es la divergencia de los datos a
partir de cierto punto en las mediciones, presente en mayor medida en el eje Y. Se aprecia
que luego de 14 segundos de medición, los datos comienzan a separarse. Hay que recordar
que los acelerómetros son, al fin, elementos mecánicos, que se someten a fuerzas externas.
En este caso, la divergencia comienza cuando el sujeto de prueba se detiene, gira, y comienza
a caminar de nuevo. Este movimiento de rotación, podría estar provocando un cambio en
42
cómo los dos dispositivos están colocados en el sujeto de prueba, causando esta divergencia.
Otra diferencia adicional en las mediciones, es más fácilmente observada en la gráfica
de la Figura 3.9, dónde aparece una especie de compresión de los datos del wiimote, a pesar
de estar capturando datos por periodos similares de tiempo, lo que da un efecto de escala en
las gráficas.
Este factor de escala podría generar una gran divergencia en los valores capturados de
estabilidad dinámica, que dependen de la frecuencia de la zancada. Después de estudiar este
comportamiento, se determinó que una de las variables que podría estar causando esta
diferencia era el filtro integrado del wiimote, del cual no existe documentación. Debido a
esto, se implementó un experimento, en el cual un wiimote se deja caer desde una altura
predeterminada en múltiples ocasiones, variando el valor del filtro de salida del wiimote, con
el fin de estudiar su comportamiento. Los resultados de dicho experimento se observan en la
Figura 3.12:
Figura 3.12 Resultados del experimento de caracterización del filtro interno Wiimote
En la parte superior izquierda de la figura, se puede apreciar cómo, al variar el
43
parámetro de entrada para el filtro del wiimote, aparecen más o menos oscilaciones en la
gráfica, de lo cual se puede inferir que el parámetro está influyendo en el nivel de
amortiguamiento de la curva, y por lo tanto, en el tiempo de respuesta del wiimote ante
cambios bruscos. En la parte superior derecha, las gráficas del eje Y muestran cómo el cambio
del parámetro en la cantidad de oscilaciones capturadas de manera significativa.
Adicionalmente, es necesario mencionar que la naturaleza adaptativa del algoritmo de
captura de datos en el wiimote, en comparación con los datos puros de IMU, generan
diferencias en la temporización de los datos, con el fin de garantizar un tiempo entre muestras
constante.
Estas diferencias, junto con las mencionadas anteriormente, explican en gran medida
las diferencias encontradas entre las mediciones del IMU y los wiimotes, llegando a
cuestionar la viabilidad de su utilización como reemplazo de bajo costo para los IMU
comerciales. Es necesario recordar que dichas diferencias, aunque pequeñas, generan un error
acumulado bastante grande en los resultados finales de estabilidad dinámica.
44
CAPÍTULO 4: Estimación de la posición y orientación de las
extremidades humanas a partir de sensores inerciales.
Con el fin de visualizar de forma certera la información acerca del movimiento humano
recolectada a través de los sensores inerciales, se planteó la necesidad de crear una interfaz
de captura de datos capaz de aplicar las aceleraciones lineales y angulares a una figura digital
antropomórfica (monigote), compuesta de cuatro extremidades, una cabeza y un torso.
Para crear dicha figura, se utilizaría la aplicación de Software Libre Blender, un poderoso conjunto de herramientas para la creación de animaciones digitales. Una posible apariencia para la figura se definió desde el comienzo, similar a los muñecos utilizados como
referencia para la pintura y escultura, como se observa en la siguiente figura.
Figura 4.1 El monigote propuesto para la visualización de movimiento
El monigote digital debería ser capaz de reproducir con un cierto grado de fidelidad los
movimientos que realiza un usuario, que tiene asegurados a sus extremidades cuatro sensores
Wiimote mediante un mecanismo de sujeción.
Este sistema es similar en esencia a los mecanismos de captura de movimiento utilizados en la producción de películas o animaciones digitales que utilizan marcadores luminosos,
parecidos a pelotas de tenis de mesa, pero sin la necesidad de la filmación constante del sujeto
45
de estudio, eliminando la gran cantidad de espacio de almacenamiento necesaria para archivar largas sesiones de estudio.
El costo de aparatos de captura de movimiento comerciales similares asciende a varios
miles de dólares, por lo que su uso en este proyecto resultó imposible. Un requisito indispensable del sistema era la utilización de herramientas de software libres y gratuitas, con el fin
de poder modificarlas según las necesidades del proyecto, y además para mantener los costos
a un mínimo.
4.1 Arquitectura propuesta para el sistema de captura de datos.
La arquitectura propuesta para el sistema de captura de movimiento consiste en el uso
de cuatro controladores de videojuego Wiimote, encargados de enviar los valores de las capturas de los sensores inerciales contenidos en cada controlador, conectados a una computadora mediante un enlace inalámbrico Bluetooth, que se encargaría de procesador los datos
e interpolar el movimiento del monigote. Todo esto a una velocidad cercana al tiempo real.
La topología de este sistema se encuentra esquematizada en la siguiente figura.
Figura 4.2 Arquitectura general del sistema propuesto.
Luego de la captura y procesamiento de los datos, sería necesaria la interpretación de
estos en movimientos humanos. Para ello se utilizaría el sistema de solución de cinemática
inversa de Blender, la cual interpola información de movimiento de un punto ligado a una
46
extremidad, para determinar la trayectoria de movimiento de todas las partes que componen
dicha extremidad.
4.2 Propuesta inicial de Software
Debido a que la captura, procesamiento y despliegue de la información proveniente de
los sensores inerciales requiere de un tratamiento muy cercano al tiempo real, fue necesario
plantear un esquema de software en el cual múltiples tareas son llevadas a cabo concurrentemente.
Inicialmente se definieron tres etapas, relacionadas a cada una de las partes del sistema:
captura de datos, procesamiento e interpretación y finalmente despliegue de información. Las
etapas fueron definidas a manera de pipeline, en el cual cada etapa crea un paquete de información que es enviado directamente a la siguiente etapa, y continúa procesando el siguiente
paquete de datos.
La primera etapa se encargaría de interactuar directamente con los sensores inerciales
del Wiimote para extraer la información de estado referente a las aceleraciones lineales y
angulares del dispositivo. Este paquete de información es transferido a la etapa de procesamiento que se encarga del filtrado de los datos para finalmente estimar movimiento y la
orientación del dispositivo. Estos datos, en forma de matrices de rotación y traslación serían
enviados a Blender para su representación en la escena. La Figura 4.3 contiene el diagrama
de transferencias de datos entre las distintas etapas de software.
47
Captura
Aceleración
Acc + Girós
Giróscopo
IN
OUT
Procesamiento
Matriz
Orientación
Acc + Girós
Matriz
Translación
IN
OUT
Despliegue
Matriz
Orientación
Matriz
Translación
IN
OUT
Figura 4.3 Diagrama de transferencia de datos del sistema
Para la captura de datos del Wiimote, se eligió la librería WiiC de código libre, que
expone al programador métodos sencillos para leer los registros del dispositivo. Esta librería
contiene implementaciones tanto en C como en C++ y es multiplataforma (Linux y MacOS).
Para el filtrado de los datos se eligió inicialmente utilizar código en C++ puro, pero eventualmente se evaluaron plantillas estándar (STL).
La representación mediante Blender poseía una complicación adicional. Debido a que
en Blender, la interfaz para programar el motor de juego (BGE) está hecha completamente
en Python 3.2, por lo cual sería necesaria la creación de código envolvente que aislara la
implementación en C++ de la implementación en Python. Por este motivo se elige utilizar un
lenguaje de creación de interfaz como SWIG (de código libre).
Definidos el esquema de hardware y software iniciales, se procedió a crear una a una
las etapas de software, pero debido a múltiples problemas encontrados en distintas etapas del
proyecto, la arquitectura fue modificada sustancialmente con el fin de sobreponerse a estas
limitaciones. Las siguientes secciones discuten en forma detallada el desarrollo de cada etapa
y los problemas encontrados, así como las soluciones propuestas.
4.3 Captura de datos provenientes de los sensores inerciales.
La extracción de información de los sensores se llevó a cabo mediante el uso de la
librería WiiC. Inicialmente se planteó la posibilidad de crear una interfaz en C++ para exponer los métodos de la librería a Blender, y extraer los datos directamente del Wiimote utilizando el intérprete nativo de python que es parte del paquete de diseño.
48
Con este fin se estudió el programa SWIG (Simplified Wrapper and Interface Generator). La premisa de este software es reducir al mínimo el esfuerzo de migración de código
entre diferentes lenguajes de programación, creando interfaces en el idioma destino, y compilando librerías binarias a partir del código original. Dichas interfaces son luego accedidas
desde un programa nativo. En este caso, se definió que los funciones mínimas requeridas en
Blender eran las siguientes:
–
Conectar y establecer comunicación con los diferentes Wiimotes.
–
Configurar el Wiimote para extraer la información de la forma adecuada.
–
Extraer la información de las aceleraciones lineales y angulares.
Con el fin de simplificar el uso de dichas funciones, se decidió crear una clase WiiMote,
que contuviera todas las funciones requeridas. Así, en el programa de Blender sería posible
crear múltiples instancias de dicho objeto, una para cada extremidad. La definición de la clase
fue la siguiente:
class WiiMote{
public:
CWii wii; // Defaults to 4 remotes
int connect(void);
void disconnect(void);
int poll(void);
private:
int HandleEvent(CWiimote &);
};
49
Al momento de la instancia inicial en Blender, el código llama a la función Connect
con para establecer la comunicación. El mismo programa en Blender sería encargado de mantener la temporización y cada 100ms de llamar la función Poll que extrae los datos de los
sensores para su consumo en el paquete de animación.
Luego se creó el archivo de interfaz para SWIG, que describe todos los métodos disponibles. Debido a que se todos los métodos serían expuestos, la configuración es bastante
sencilla:
/*Filename: foo2.i */
%module example
%{
/* Includes the header in the wrapper code */
#include "foo_swig.h"
%}
/* Parse the header file to generate wrappers */
%include "foo_swig.h"
Posteriormente se creó el archivo de Blender para probar la interfaz con el archivo en
C++. Este archivo contiene un simple cubo en espacio tridimensional que gira dependiendo
de la tecla del controlador que se presione.
Los resultados de dichas pruebas no fueron satisfactorios, esto porque existía un retardo
constante de aproximadamente 3 segundos desde el momento que se presionaba el botón de
controlador hasta el momento en que dicha acción se veía reflejada en Blender. Este retardo
es inaceptable debido a la naturaleza de tiempo real que se perseguía. Para determinar el
origen de dicho retardo, se creó un archivo de prueba en python externo a el paquete de
animación, para realizar pruebas más rápidamente. Los resultados mostraron un retardo cercano a cero, prácticamente imperceptible. Con esto, fue posible determinar que la fuente del
retardo no provenía de la implementación en C++, sino de la misma capa de ejecución de la
50
máquina de juegos. Debido a la imposibilidad de realizar modificaciones a Blender para utilizar profiling con el fin de buscar la fuente exacta del retardo, se decidió abandonar esta ruta
y buscar alternativas.
Luego de una extensa investigación, se encontró el trabajo de Julian Oliver del colectivo artístico SelectParks quien implementó una interfaz sencilla para el wiimote en Blender
utilizando OSC (Open Sound Control), un protocolo de transmisión de datos utilizado normalmente para el control de sonido. La solución incluye la división de la comunicación en
dos partes, un cliente de OSC que se encarga de enviar los paquetes y un servidor de OSC
quién recibe los paquetes y los decodifica, para tomar acciones dependiendo del contenido
del mensaje recibido. Para este caso, el cliente se conectaría mediante C++ al wiimote, y
utlizando un librería de OSC para python, Blender escucharía los mensajes y ejecutaría los
comandos necesarios para mover el monigote en pantalla dependiendo de la acción que se
requería.
Inicialmente se pensó que éste acercamiento no solucionaría los problemas de retardo,
puesto que esta solución implicaba el tráfico de información mediante el protocolo IP, pero
debido a que la capa de comunicación IP se maneja externamente al Blender, los paquetes
experimentan latencias muy pequeñas, casi imperceptibles.
4.3.1 Utilización de OSC para el tráfico de información entre el wiimote y Blender.
El OSC es un protocolo unidireccional de comunicación UDP que elimina el chequeo
y la corrección de errores, y por lo tanto simplifica el envío de datos, minimizando el tiempo
llegada de los paquetes de información.
Para el uso de OSC primero fue necesario crear un cliente de OSC, que se encarga de
enviar los paquetes al servidor. Cada cliente se crea indicando el número de puerto al que se
quiere enviar el mensaje y además el puerto a utilizar:
OSCaddr = lo_address_new(OSCaddress, OSCPort); //Create the client
51
Una vez creado el cliente, cuando se requiere enviar un paquete de datos, se indica la
dirección del cliente, el tipo de datos y el dato mismo a ser enviado, por ejemplo:
lo_send(OSCaddr,"/foo/bar","ffff",Q.s,Q.v[0],Q.v[1],Q.v[2]);
En el ejemplo anterior, el primer argumento es la dirección del servidor que procesará
la información, /foo/bar se refiere al destino en el servidor que debe atender el paquete enviado, esta información se agrega al paquete al momento de ser enviado para que el servidor
la decodifique, posteriormente se especifica el número y el tipo de datos, en este caso “ffff”,
que indica que se enviarán cuatro número float.
El servidor OSC para este proyecto se definió en el Game Engine de Blender, para así
convertir la información del wiimote en movimiento del modelo poligonal en 3D. Primero es
necesario iniciar el servidor de OSC y configurarlo:
server = liblo.Server(4950)
server.add_method("/foo/bar",'fff',foo_bar_callback)
server.add_method("/foo/bar",'ffff',quaternion_callback)
server.recv(100)
server.free()
Seguidamente se especifica que debe recibir los paquetes del puerto 4950, que es el
mismo que se configuró el cliente. Luego se crean los “destinos” o métodos de OSC. El
primero recibe tres números en punto flotante que sean destinados a /foo/bar, el segundo toma
cuatro números de punto flotante. Es importante notar que dependiendo del tipo de dato que
se recibe, se llaman funciones diferentes, aunque la dirección foo/bar se repita. Los métodos
a los cuales se direcciona el paquete se encargarán de tomar las acciones necesarias, en este
caso los dos destinos trabajan con coordenadas de Euler o con Quaterniones. Seguidamente
se le dice al servidor que escuche cada 100ms por un paquete en el puerto, y luego se le dice
52
que se desconecte. Aunque la desconexión constante del servidor podría parecer una pérdida
de recursos, esta fue la única forma que logró eliminar los retardos.
Posteriormente es necesario definir las funciones que tomarán los datos de OSC para
convertirlos en movimiento en Blender, se discute el caso cuando se reciben quaterniones:
def quaternion_callback(path, args):
cont = bge.logic.getCurrentController()
scene = bge.logic.getCurrentScene()
wiimote = scene.objects["wiimote"]
i = args
w = float(i[0])
x = float(i[1])
y = float(i[2])
z = float(i[3])
wiimote.localOrientation=reorient2(w,x,y,z)
return
La función recibe como parámetros el destino del mensaje y los argumentos enviados
por el cliente, en éste caso las coordenadas x,y,z,w de una rotación mediante quaterniones.
Primero se deben obtener las características y actores de la escena actual, así como todos los
controladores existentes en la escena. Luego, se le asigna a la variable wiimote un puntero
que apunta el objeto “wiimote” en la escena, que es en este caso una barra rectangular:
53
Figura 4.4 Captura de pantalla del modelo en Blender
Luego se asigna cada una de las variables x,y,z,w un valor proveniente del paquete de
OSC. Finalmente se utiliza una función para cambiar la orientación del objeto en el espacio.
En la siguiente sección se discute el proceso para determinar la nueva orientación del wiimote
en el espacio de la escena.
4.4 Determinación de la orientación mediante sensores inerciales.
Luego de superarse el problema de la transmisión de los datos desde la etapa de captura
de los datos hasta el Blender, se procedió a trabajar en el procesamiento de los datos, con el
fin de determinar la orientación del control remoto del Wii, usando los datos de los sensores
inerciales.
Conocer la forma en que están colocados los sensores en el wiimote fue indispensable
para poder realizar los cálculos. Se utilizó la información del sitio web WiiBrew
18
para co-
nocer las distintas orientaciones de los ejes del wii, como se muestra en la figura siguiente:
www.wiibrew.com
18
54
Figura 4.5 Posición de los ejes de los sensores inerciales en relación al Wiimote
Debido a que los acelerómetros miden la componente de fuerza que ejerce g sobre cada
uno de los vectores, utilizando trigonometría es posible encontrar el ángulo de ésa fuerza.
El vector de gravedad g siempre va a apuntar perpendicularmente al plano horizontal,
pero los sensores inerciales del wiimote van a rotar constantemente, cambiando sus mediciones de la gravedad. Para facilitar los cálculos, el marco de referencia se invierte, y ahora se
asume que el wiimote se mantiene estático en el tiempo, y lo que cambia es el vector de
gravedad, como lo muestra la siguiente figura:
G
Figura 4.6 El vector de gravedad representado en un eje tridimensional estático
55
Ahora se proyecta el vector de gravedad en cada uno de los distintos planos XY, XZ,
ZY para calcular el ángulo que exhibe g con el plano:
Y
X
G
Figura 4.7 Proyección del vector de gravedad en el plano XY
Teniendo esta proyección, se sabe que el ángulo α está dado por el inverso de la tangente entre dos aceleraciones, como dichas aceleraciones son conocidas, el ángulo de Euler
respectivo es determinado.
Este método resulta muy útil para el cálculo del pitch y el roll, puesto que usualmente
el control va a estar sujetado de tal forma que g es paralelo al eje Z del acelerómetro, con
esto el ángulo proyectado sobre el eje XZ o YZ se puede calcular fácilmente. Pero para el
cálculo del yaw, se presenta un problema importante, dado que la aceleración es perpendicular al plano XY, los componentes de aceleración en X y Y son usualmente cercanos a cero
(en posición de reposo), lo que indetermina la función inversa de la tangente, haciendo imposible el cálculo del yaw.
Pero este problema no se presenta solamente cuando g está paralela al eje Z, sino que
también aparece cuando debido a la rotación del control remoto, g se vuelve paralelo o casi
paralelo a cualquiera de los otros ejes.
Este problema se conoce como la pérdida de un
56
grado de libertad, puesto que los datos de uno de los sensores no pueden ser utilizados para
determinar la posición.
En el caso de este proyecto, los acelerómetros poseen 3 grados de libertad, uno por
cada eje. Para sobreponerse al problema, se utilizan distintas técnicas, entre ellas la fusión de
sensores, que utiliza información de diferentes tipos de sensores para atenuar los problemas
que cada uno posee.
Los acelerómetros poseen el problema de la pérdida de grados de libertad y además
tienen problemas de offset, esto es, no siempre van a desplegar un valor de cero aún cuando
no se les aplique una aceleración.
Como el sensor del wiimote también posee tres giróscopos, se dice que tiene 6 grados
de libertad. Estos sensores, que miden la razón de cambio angular del movimiento, no sufren
de un problema de offset, sino de un problema conocido como drift, que significa que un
valor de cero en el tiempo inicial no necesariamente es el mismo valor de cero en un tiempo
posterior.
Para usar la información de los 6 sensores, se decidió utilizar una técnica de fusión de
sensores conocida ampliamente en el control de procesos. El Filtro de Kalman utiliza la información de los acelerómetros y giróscopos y dependiendo del grado de confiabilidad de las
medidas predice el próximo valor esperado.
Este tipo de filtro produce estimados de los valores reales de una medida y otros valores
asociados, prediciendo un valor, estimando la incertidumbre de ésa predicción y calculando
un promedio ponderado de los valores calculados y reales. El peso más grande se le asigna a
la medida con la menor incertidumbre, al pasar el tiempo la estimación se volverá más y más
acertada (si se mantienen las condiciones de incertidumbre y error a través del tiempo.
57
Figura 4.8 Diagrama de bloques estándar de un filtro de Kalman
Durante la investigación para este proyecto el Profesor Lochi Yu sugirió el uso de un
filtro de Kalman creado por Patric Olsson, utilizado para la implementación de un robot que
se balancea (Figura 4.8). Al estudiar el código a fondo, se descubrió que sólo se requería de
cambiar los parámetros del filtro para que se adaptara a la aplicación propuesta. Estos parámetros definen la incertidumbre en la medición de los acelerómetros y los giróscopos, que
puede ser tomada de las hojas de datos del fabricante.
Se obtuvieron resultados muy buenos con el filtro, haciendo las mediciones considerablemente más exactas, aunque se agrega un retardo inherente a la los filtros digitales que
disminuye en cierta forma la respuesta del sistema en pantalla.
Sin embargo, el agregar el filtro de Kalman, a pesar de que ayuda a estabilizar el sistema, no elimina el problema de la pérdida de un grado de libertad. Con el filtro incluido, el
sistema continúa teniendo problemas en los ángulos extremos, esto es, el yaw se puede calcular, pero se calcula como un cambio en la posición angular del sistema, a partir del último
punto de referencia. Esto quiere decir que con el sistema completamente estático, el Blender
despliega en pantalla una lenta rotación alrededor del eje Z (yaw), debida al drift de los giróscopos.
Debido a esto se inicia el estudio de otros métodos con el fin de sobreponerse a estas
limitantes. Es común encontrar en teléfonos celulares comerciales aplicaciones que utilizan
acelerómetros y giróscopos como controles, o el mismo sistema Wii, por lo tanto se asumió
que debía existir algo que no se estaba tomando en cuenta en el código desarrollado.
58
Pero luego una intensa investigación se encuentra que existe un componente adicional
requerido para eliminar el problema de la pérdida de grados de libertad. En aplicaciones como
el Wii, se utiliza una barra emisora de infrarrojo que se coloca sobre un televisor, y una cámara infrarroja en el control capta esa luz emitida. Ésa luz emitida sirve como una forma de
“faro” para el sistema, indicando siempre dónde está el punto de interés del control remoto.
En el caso de los teléfonos móviles, se agrega un tercer sensor, un magnetómetro de tres ejes,
que mide la posición en grados en comparación con el polo norte magnético.
Es entonces que se encuentra el problema fundamental en la solución propuesta, para
poder eliminar por completo la pérdida de grados de libertad, es necesario contar con tres
sensores por cada eje a medir: un acelerómetro, un giróscopo y un magnetómetro, con lo cual
se necesitarían sensores de 9 grados de libertad.
Con esta noción se vuelve evidente que el objetivo de capturar el movimiento mediante
sensores inerciales no es posible mientras no se tengan mejores sensores.
4.5 Representación de movimiento en Blender utilizado la máquina de
juegos
La máquina de juegos de Blender es una herramienta utilizada normalmente para la
creación de contenido interactivo, como juegos de video y presentaciones tridimensionales
de proyectos arquitectónicos, y permite la visualización de modelos creados en la herramienta
en un ambiente controlable por el usuario, por ejemplo, es posible recorrer los pasillos de
construcciones virtuales utilizando las teclas direccionales del teclado.
En el caso particular de este proyecto, se buscaba la representación de los datos de
movimiento provenientes del controlador Wiimote, asociados a aceleraciones y posiciones en
el espacio, mediante modelos tridimensionales humanos. Como se discutió anteriormente,
primero fue necesario hallar el modo de enviar dicha información de movimiento. Una vez
resuelto ése obstáculo como se discutió en secciones anteriores, se procedió a desarrollar la
representación en Blender.
59
4.5.1 Representación de la escena en Blender
La escena de prueba que se utilizó durante la realización del proyecto es bastante sencilla, y se compone únicamente de un bloque sólido de color gris, que representa al controlador Wii (Figura 4.4, atrás). Este bloque se creó utilizando las herramientas estándar de
Blender, alterando la menor cantidad de parámetros del mismo. Futuras implementaciones
podrían buscar utilizar modelos más fieles del controlador.
Como este bloque será posteriormente manipulado a través del script de python que
proporciona los datos de movimiento, es necesario nombrar este bloque, en este caso, wiimote. Este cambio se realiza en la ventana de propiedades de objeto del blender.
Figura 4.9 Ventana de propiedades de objeto
Para esta escena, no fue necesario la creación de cámaras adicionales a las que por
defecto el software inicializa, por lo tanto no se detallan los pasos para creación de cámaras
adicionales.
4.5.2 Programación de la lógica del objeto
Blender utiliza una serie de eventos lógicos para la reproducción de acciones en pantalla, cada objeto dentro de la escena puede tener sus propios eventos asociados, así como
eventos asociados a la escena en sí, como por ejemplo cuando se inicializa la máquina de
juegos.
Los eventos pueden ser programados en el Editor lógico, uno de los paneles de herramientas disponibles en el programa.
60
Figura 4.10 Selección del Editor Lógico
Al seleccionar el editor lógico, se presentan tres columnas, llamadas sensores, controladores y actuadores, que permiten insertar el elemento que indica su nombre. Toda acción
lógica en Blender se compone de estos tres elementos.
Los bloques “sensor”, son los que se encargan de determinar cuándo un evento debe
de dispararse. Por ejemplo, un bloque de sensor Keyboard, disparará una acción cada vez que
se presione una tecla determinada. Estos bloques son similares a un IF dentro de un lenguaje
de programación.
Los bloques de controladores se encargan de determinar qué hacer cuando se dispara
un sensor, existen distintos tipos de controladores, pero en nuestro caso específico sólo se
utilizará un controlador Python, que dispara la ejecución de un script de python que se describe posteriormente.
Finalmente, están los actuadores, bloques que se encargan de realizar las acciones asociadas a cada evento, existen muchos tipos, y pueden variar desde cambiar el valor de una
variable del programa, hasta mover y rotar objetos.
61
Una vez que se insertan cada uno de los bloques que se requieren, es necesario conectarlos, con el fin de finalizar la acción lógica. En el caso particular de éste proyecto, el panel
del Editor Lógico se ve así:
Figura 4.11 El panel del editor lógico luego de agregar la programación necesaria
El sensor Always indica que debemos disparar el controlador Python en todos los ciclos
de reloj de la máquina de juegos. Los sensores Keyboard que se aprecian en la imagen son
sólo para debug.
El controlador Python está configurado para ejecutar un módulo llamado hello, que se
encuentra dentro del archivo Text.py que se describe posteriormente. Para finalizar, se crearon dos actuadores de movimiento, con el fin de depurar el programa, pero no cumplen con
ninguna función específica. Todos los actuadores que se utilizan, están descritos en Text.py.
4.5.3 Script para la ejecución del movimiento
Como se mencionó en la sección anterior, el controlador Python que se definió, ejecuta
un script de python que se encarga de transformar los datos provenientes del wiimote en
acciones dentro de Blender.
Hay que recordar que el controlador está ligado a un bloque Always, que disparará al
controlador en cada ciclo de reloj de la máquina de juegos.
Primeramente se importan una serie de módulos necesarios para las distintas operaciones, por ejemplo, las librerías necesarias para decodificar mensajes de pyOSC.
import bge
#Importa el BGE
62
import liblo
# Importa pyOSC
import math
# Define los quaterniones
import bpy
# Funciones básicas
import mathutils # Operadores matemáticos
Luego se define la función reorient, que se encarga de convertir las coordenadas provenientes del mensaje OSC, en un quaternion.
def reorient(w,x,y,z):
Q = mathutils.Quaternion([w,x,y,z]);
return Q
La siguiente función es llamada cada vez que se recibe un mensaje correcto de pyOSC
y es la clave para el movimiento de controlador en el espacio de Blender. Aquí se toma de la
escena el objeto cuyo nombre es wiimote, esto provee una serie de funciones que se pueden
usar para modificar el objeto. En este caso, se cambia la orientación local del objeto, utilizando el quaternion que se convirtió en la función anterior, que a su vez proviene de un
mensaje OSC.
def quaternion_callback(path, args):
cont = bge.logic.getCurrentController()
scene = bge.logic.getCurrentScene()
wiimote = scene.objects["wiimote"]
i = args #Argumentos de pyOSC
#Decoficar el mensaje
w = float(i[0])
x = float(i[1])
y = float(i[2])
z = float(i[3])
#Reorientar
wiimote.localOrientation=reorient(w,x,y,z)
return
La última parte consiste en la definición del servidor OSC que recibe todos los mensajes del cliente, en este caso, un wiimote, y cada vez que recibe un mensaje correcto con los
argumentos adecuados, procede a realizar las acciones antes descritas.
63
def hello():
server = liblo.Server(4950)
server.add_method("/foo/bar",'ffff',quaternion_callback)
server.recv(100)
server.free()
return
Como se observa, el script de python utilizado es en realidad sencillo, y puede ser
extendido según el número de wiimotes que se utilicen.
CAPÍTULO 5: Conclusiones y recomendaciones
Como se ha discutido durante la realización de este proyecto, el análisis de la estabilidad dinámica en adultos mayores es un tema que provee un amplio espacio para la innovación
mediante la incorporación de nuevas tecnologías y técnicas de visualización de datos. El
proyecto planteaba la utilización de un controlador Wii Remote™ para la realización del
análisis y una serie de herramientas de código abierto para la visualización del movimiento,
objetivos que sólo se han podido concretar parcialmente, debido a ciertas limitaciones técnicas que ya se han discutido.
Al finalizar este proyecto, existen una serie de conclusiones importantes que pueden
ayudar a avanzar el estado actual de este tipo de análisis, y sentar las bases para futuros
proyectos.
Primeramente es necesario reiterar que sí es posible realizar un análisis de estabilidad
dinámica utilizando los sensores del Wii®, más no resulta práctico en su estado actual. El
bajo coste de los dispositivos trae consigo algunas complicaciones como la poca resolución
de los sensores, y la falta de unidades de medición inercial con 9 grados de libertad que
incorporen magnetómetros.
Adicionalmente, la forma física de los controles plantea dificultades a la hora de la toma
de datos, por la alta sensibilidad a los cambios de posición a la hora de realizar mediciones,
lo que conlleva a un excesivo proceso de calibración para la captura de datos en el campo.
Estos cambios de posición, inducen diferencias significativas entre mediciones, inclusive
para un mismo individuo.
Los algoritmos de procesamiento de datos utilizados en este proyecto, pueden ser fácilmente extendidos a otras plataformas y así lograr abstraerlos del sistema de medición propuesto, lo que facilitaría la comparación entre diferentes técnicas de análisis, y además podrían ser utilizados con otros métodos de medición. Es importante mencionar que dichos
algoritmos automatizan una gran cantidad de pasos que anteriormente se hacían manualmente, como la detección de pasos y máximos locales.
64
65
Así mismo, la utilización de controladores bluetooth® provee una relativa facilidad de
desplazamiento para los individuos en estudio, lo cual es una ventaja significativa por encima
de los IMU comerciales, y provee oportunidades interesantes para la visualización de los
datos en tiempo real utilizando aplicaciones como Processing® o Matlab™.
Con estas conclusiones, es posible plantear una serie de recomendaciones para investigaciones futuras en el campo de la estabilidad dinámica, para evitar caer en las mismas
dificultades que este proyecto enfrentó. Se enumeran a continuación estas recomendaciones.
-
Es necesario abandonar los controladores Wii Remote™ como medio para la captura
de datos, existiendo ahora otras alternativas de hardware de bajo costo y naturaleza
abierta. Es posible crear un sistema utilizando sistemas Arduino™ y sensores de bajo
costo, teniendo la misma funcionalidad por un costo aún relativamente bajo.
-
De seguir utilizando los controladores Wii®, es necesario evaluar la posibilidad de
modificar la forma de los mismos, eliminando la coraza externa y re-distribuyendo
los componentes internos para que se adapten mejor a la aplicación. Además, es indispensable continuar con la caracterización de los sensores para optimizar los valores de los distintos filtros y algoritmos, con el fin de acercarse lo más posible a las
aplicaciones comerciales.
-
Con el fin de mejorar la usabilidad del sistema de captura de datos, se sugiere separar
las etapas de análisis de datos y la captura en aplicaciones separadas. Además es posible agregar un sistema de base de datos para el manejo de los datos capturados y los
datos de los diferentes sujetos de prueba.
-
Se recomienda el estudio de técnicas de captura de movimiento a través de video, de
las cuales en los últimos años han aparecido sistemas más baratos y portátiles, como
el Kinect™ de Microsoft®. Estos sistemas ya poseen librerías de código abierto que
podrían facilitar el desarrollo de aplicaciones novedosas.
BIBLIOGRAFÍA
Alan Wolf et al. (1985) Determining Lyapunov exponents from a time series. Physica D:
Nonlinear Phenomena Journal.
Bogle, L..; Thorbahn I. Y Newton, R.A. (1996) Use of the Berg Balance Test to Predict Falls
in Elderly Persons Physical Therapy 76: 6
Bruijn S.M., van Dieën J.H., Meijer, O.G., Beek, P.J. (2009) Statistical precision and
sensitivity of measures of dynamic gait stability. J. of Neuroscience Methods 178
327–333
Bruijn S.M. et al (2010) Estimating Dynamic Gait Stability Using Data from Non-aligned
Inertial Sensor. Annals of Biomedical Engineering. Volumen 38(8).
Cho CY y Kamen G. (1998) Detecting balance deficits in frequent fallers using clinical and
quantitative evaluation tools. J Am Geriatr Soc. 46:426-430 (Abstract)
Chung Lee, Johnny (2008). Hacking the Nintendo® Wii Remote. IEEE Pervasive Computing
Journal.
Culhane, KM., O’Connor, M., Lyons, D., Lyons, GM. (2005). Accelerometers in
rehabilitation medicine for older adults. Age and Ageing. British Geriatrics Society.
England, Scott (2005). Quantifying Dynamic Stability of Muscoloskeletal Systems using
Lyapunov Exponents. Tesis de Maestría. Politécnico de Virginia, E.E.U.U.A.
Granata, K et al (2008) Dynamic stability differences in fall-prone and healthy adults.
Journal of Electromyography and Kinesiology. Volumen 18(2)
Hamill J and Knutzen KM, (2003) Biomechanical basis of human movement Lippincott
Williams & Wilkins, 2nd Ed.
Hernández, R., Fernández, C. et al. (2003) Metodología de la Investigación. Editorial
McGraw-Hill.
Izquierdo M., Martínez-Ramírez A., Larrión J.L., Irujo-Espinosa M., Gómez M. (2008).
Valoración de la capacidad funcional en el ámbito domiciliario y en la clínica.
Nuevas posibilidades de aplicación de la acelerometría para lavaloración de la
marcha, equilibrio y potencia muscular en personas mayores An. Sist. Sanit. Navar.
2008, Vol. 31, Nº 2, 159-170
Judge, J.O., Carleen, L., Underwood, M., Winsemlus, D. (1993). Balance Improvements in
Older Women: Effects of Exercise Training. Phys Ther 73(4) 254-62
66
67
Karlson, A., Frykberg, G. (2000). Correlations between force plate measures for assessment
of balance. Clinical Biomecanics.
Mayagoitia, Ruth E. and Nene, Anand V. and Veltink, Peter H. (2002) Accelerometer and rate
gyroscope measurement of kinematics: an inexpensive alternative to optical
motion analysis systems. Journal of Biomechanics, 35 (4). pp. 537-542.
Menz, B., Lord, S., Fitzpatrick, R. (2003) Age-related differences in walking stability. Age
and Ageing. British Geriatrics Society.
Menz, B., Lord, S., Fitzpatrick, R. (2003) Acceleration patterns of the head and pelvis when
walking on level and irregular surfaces. Gait & Posture Journal.
Moe-Nilssen, R. (1998) Test-retest reliability of trunk accelerometry during standing and
walking. Arch Phys Med Rehabil; 79: 1377-1385 (abstract)
Pastor Herrán, Carlos (2010). Prototipado rápido de aplicaciones Opensource para
rehabilitación usando dispositivos inalámbricos. Tesis de Maestría. Universidad
Carlos III de Madrid.
Piirtola M, Era P. (2006) Force platform measurements as predictors of falls among older
people - a review. Gerontology; 52(1):1-16.
Rosenstein, M. Collins, J. De Luca, Carlo. (1993) A practical method for calculating largest
Lyapunov exponents from small data sets. Physica D: Nonlinear Phenomena
Journal.
Sjoerd M. Bruijn et al. (2010) Estimating Dynamic Gait Stability Using Data from Nonaligned Inertial Sensors. Annals of Biomedical engineering.