universidad de chile facultad de ciencias fÍsicas y...

UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN

DISEÑO E IMPLEMENTACIÓN DE UNA APLICACIÓN DE SOFTWARE PARA NEURORREHABILITACIÓN BASADA EN DETECCIÓN DE MOVIMIENTO

MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO CIVIL EN COMPUTACIÓN

IVÁN PABLO BUSTAMANTE FILOZA

[email protected]

PROFESOR GUÍA: JOSÉ A. PINO URTUBIA

MIEMBROS DE LA COMISIÓN: JAIME H. SÁNCHEZ ILABACA

JEREMY F. BARBAY

SANTIAGO DE CHILE, DICIEMBRE 2011

Resumen

El presente tema de memoria se enmarca en el contexto de la neurorrehabilitación. El

objetivo fue desarrollar una aplicación que permita a usuarios en rehabilitación realizar

ejercicios de terapia física. Para esto, se investigó y empleó tecnología de detección de

movimiento.

Actualmente, la tecnología cada vez logra mayor acercamiento con el área de la

neurorrehabilitación. Además, los costos decrecientes en el hardware, y la constante innovación

tecnológica, permiten que aplicaciones de neurorrehabilitación sean cada vez más accesibles al

usuario final. Esto abre la posibilidad de que los usuarios complementen sus terapias en el

hogar.

Se expone las consideraciones para diseñar una aplicación prototipo, compuesta de dos

dinámicas, basadas en ejercicios de neurorrehabilitación existentes. Se determinó el uso de la

cámara web como fuente de input para detección de movimiento, debido a su bajo costo, y la

existencia de algoritmos de detección de movimiento basados en la videocaptura.

Luego se hizo un diseño de la arquitectura, basado en arquitectura de videojuegos.

Posteriormente, se diseñó la estructura del software. Para este paso se hizo uso del paradigma

de programación orientada a objetos. Se usó patrones de diseño, a fin de que la aplicación fuese

extensible.

Luego del diseño, se procedió a la implementación de la aplicación. En esta etapa se

investigó e implementó distintos algoritmos de detección de movimiento. Se partió por

algoritmos sencillos, basados en diferencia de fotogramas, que entregan mapas binarios de

movimiento o grupos de contornos en movimiento. Sin embargo, no se empleó algoritmos de

este tipo para la implementación de las dinámicas, debido a que algoritmos investigados

posteriormente resultaron ser más aptos.

Mayor investigación condujo al conocimiento de algoritmos basados en flujo óptico,

capaces de entregar información de velocidad de movimiento para puntos de la imagen.

Algunos de estos algoritmos permiten hacer seguimiento de puntos específicos, característica

de la cual se hizo uso en las dinámicas implementadas. Se experimentó con la posibilidad de

skeletal tracking, basado en algoritmos de flujo óptico, sin éxito. Existen también algoritmos de

detección de objetos, mediante filtros Haar y clasificadores en cascada. Se utilizó

implementaciones de estos últimos, de forma complementaria a los algoritmos de flujo óptico,

para realizar seguimiento facial.

Para la implementación de la primera dinámica se utilizó una combinación de

seguimiento de características mediante flujo óptico y detección facial mediante clasificadores

Haar. Para la segunda dinámica, se empleó solamente algoritmos de flujo óptico. Ambas

dinámicas implementadas fueron utilizadas de forma exitosa por usuarios finales, además de

haber sido probadas previamente con usuarios no finales.

El resultado obtenido, fue una aplicación extensible, que implementa dos dinámicas de

neurorrehabilitación, usando tecnología de bajo costo. Esta aplicación permite al usuario

ejecutar ambas dinámicas implementadas. Podrá servir de prototipo de una solución que

permitirá al usuario reforzar la terapia, en su propio hogar.

Agradecimientos

A Pedro, Blanca y Gabriel, por su apoyo, presencia e inconmensurable amor y

comprensión, a lo largo de toda mi vida.

A Lissette por ser mi fuerza y motor, por no dejarme nunca bajar los brazos y estar

presente en todo momento, en especial en los malos.

A la gente de CETRAM, Hospital de Neurocirugía y Departamento de Ciencias de la

Computación, en especial a mi profesor guía, José Pino. Sin ustedes, este trabajo no

habría sido posible.

A todos aquellos que siempre me han apoyado, les pido disculpas por no poner sus

nombres aquí, mas espero que sepan que los llevo siempre en mi corazón.

Tabla de Contenidos

1 Introducción ................................................................................................................................................... 1

1.1 Aspectos generales ............................................................................................................................. 1

1.2 Justificación y motivación ................................................................................................................ 2

1.3 Objetivos ................................................................................................................................................ 3

1.3.1 Objetivo general ............................................................................................................................. 3

1.3.2 Objetivos específicos .................................................................................................................... 3

1.4 Alcances .................................................................................................................................................. 4

1.5 Contenidos ............................................................................................................................................. 4

2 Antecedentes .................................................................................................................................................. 6

2.1 Conceptos de detección de movimiento .................................................................................... 6

2.1.1 Tecnologías comúnmente usadas para detectar movimiento ...................................... 6

2.1.2 Algoritmos de detección de movimiento humano ............................................................ 7

2.2 Conceptos de ingeniería de software .......................................................................................... 8

2.2.1 Patrones de diseño relevantes .................................................................................................. 8

2.3 Conceptos de neurorrehabilitación y kinesiología ................................................................ 9

2.4 Especificación de problemas existentes ................................................................................. 10

2.4.1 Refuerzo de la Terapia en el Hogar ...................................................................................... 11

2.4.2 Costo de Equipos para Rehabilitación ................................................................................ 12

2.4.3 Usabilidad y Versatilidad de Equipos Empleados en Rehabilitación ...................... 13

2.5 Trabajos relacionados .................................................................................................................... 13

2.5.1 Feasibility, Motivation and Selective Motor Control: Virtual Reality Compared to

Conventional Home Exercise in Children with Cerebral Palsy. [1] ........................................ 14

2.5.2 Low-cost Virtual Rehabilitation of the Hand for Patients Post-Stroke. [2] .......... 15

2.5.3 Post-stroke arm motor telerehabilitation web-based. [3] .......................................... 16

2.5.4 A low-tech virtual reality application for training of upper extremity motor

function in neurorehabilitation. [4] ................................................................................................... 17

3 Diseño ............................................................................................................................................................ 18

3.1 Evaluación de opciones tecnológicas ....................................................................................... 18

3.1.1 Opciones disponibles ................................................................................................................. 18

3.1.1.1 Microsoft® Kinect® ......................................................................................................... 18

3.1.1.2 Nintendo® Wiimote® ..................................................................................................... 19

3.1.1.3 Cámara Web ........................................................................................................................ 19

3.1.2 Análisis de opciones ................................................................................................................... 20

3.2 Diseño de las dinámicas a implementar ................................................................................. 21

3.2.1 Sentarse y Levantarse de una Silla ....................................................................................... 21

3.2.2 Elevación de un Pie a Baja/Mediana Altura ...................................................................... 22

3.3 Diseño de la aplicación .................................................................................................................. 23

3.3.1 Arquitectura de la aplicación.................................................................................................. 23

3.3.1.1 Entrada .................................................................................................................................. 24

3.3.1.2 Datos del Juego ................................................................................................................... 25

3.3.1.3 Lógica del juego .................................................................................................................. 25

3.3.1.4 Salida ...................................................................................................................................... 25

3.3.2 Estructura de la aplicación ...................................................................................................... 26

3.3.2.1 Adapter sobre conector de cámara web ................................................................... 26

3.3.2.2 Mediator para manejo de pantallas ............................................................................ 26

3.3.2.3 Strategy para elección de algoritmo de detección de movimiento ................ 28

3.3.2.4 Template Method para pantallas de juego .............................................................. 28

3.3.2.5 Menúes de opciones ......................................................................................................... 29

3.3.2.6 Carga y almacenamiento de parámetros de configuración ............................... 30

4 Implementación ......................................................................................................................................... 31

4.1 Elección de plataforma objetivo................................................................................................. 31

4.1.1 Elección de sistema operativo ............................................................................................... 31

4.1.2 Elección del lenguaje de programación .............................................................................. 31

4.2 Ambiente de desarrollo ................................................................................................................. 33

4.2.1 XNA ................................................................................................................................................... 33

4.2.2 AForge ............................................................................................................................................. 33

4.2.3 EmguCV ........................................................................................................................................... 34

4.3 Aplicación de prueba ...................................................................................................................... 34

4.4 Almacenamiento de configuración ........................................................................................... 35

4.5 Algoritmos implementados ......................................................................................................... 36

4.5.1 Algoritmos basados en sustracción de imágenes ........................................................... 36

4.5.1.1 Sustracción de fondo fijo ................................................................................................ 36

4.5.1.2 Substracción de fondo dinámico ................................................................................. 37

4.5.1.3 Otros algoritmos investigados...................................................................................... 37

4.5.2 Algoritmos basados en flujo óptico ...................................................................................... 38

4.5.2.1 Skeletal tracking con Lucas-Kanade piramidal ...................................................... 38

4.6 Implementación de las dinámicas ............................................................................................. 41

4.6.1 Dinámica de pararse y sentarse ............................................................................................ 41

4.6.1.1 Clasificadores Haar para detección facial ............................................................... 41

4.6.1.2 Good features to track ..................................................................................................... 42

4.6.1.3 Implementación ................................................................................................................. 43

4.6.1.4 Interfaz de usuario ............................................................................................................ 44

4.6.1.5 Observaciones durante pruebas con usuarios finales......................................... 44

4.6.2 Dinámica de equilibrio .............................................................................................................. 45

4.6.2.1 Lucas-Kanade vs Horn-Schunck .................................................................................. 46

4.6.2.2 Implementación ................................................................................................................. 47

4.6.2.3 Interfaz de usuario ............................................................................................................ 47

4.6.2.4 Observaciones durante pruebas con usuarios finales......................................... 48

5 Conclusiones ............................................................................................................................................... 50

5.1 Conclusiones generales ................................................................................................................. 50

5.2 Cumplimiento de objetivos .......................................................................................................... 51

5.2.1 Detectar el movimiento de un usuario ............................................................................... 51

5.2.2 Implementar dinámicas basadas en rutinas de ejercicios usados en

rehabilitación .............................................................................................................................................. 51

5.2.3 Generar indicadores que ayuden a cuantificar el progreso de un usuario ........... 51

5.2.4 Diseñar una solución extensible ........................................................................................... 51

5.2.5 Mantener en cuenta el futuro uso doméstico de la aplicación .................................. 52

5.3 Trabajo futuro ................................................................................................................................... 52

6 Referencias .................................................................................................................................................. 54

7 Anexos ........................................................................................................................................................... 56

Tabla de Ilustraciones

Figura 1: Posicionamiento de la cámara en ejercicio de pararse y sentarse. .............................. 22

Figura 2: Posicionamiento de pantalla y cámara para ejercicio de equilibrio. ........................... 23

Figura 3: Arquitectura de juego básica ....................................................................................................... 24

Figura 4: El game loop básico. ........................................................................................................................ 24

Figura 5: Adapter sobre clase de captura de video. ............................................................................... 26

Figura 6: Mediator entre pantallas de la aplicación y sus recursos compartidos...................... 27

Figura 7 Uso de patrón Strategy para algortimos de detección de movimiento ........................ 28

Figura 8: Template method para pantallas de juego............................................................................. 29

Figura 9: Composición recursiva en pantallas de menú, para lograr estructura de árbol ..... 29

Figura 10: Uso de patrón “prívate class data”, para parámetros de configuración .................. 30

Figura 11: Izq.: imagen en tiempo real. Der.: mapa binario generado por diferencia de

fotogramas consecutivos. ................................................................................................................................ 35

Figura 12: Aplicación de prueba en ejecución ......................................................................................... 35

Figura 13: Sombra detectada como movimiento en sustracción de fondo fijo. .......................... 36

Figura 14: Posición inicial del modelo para tracking esqueletal ...................................................... 39

Figura 15: Skeletal tracking durante el movimiento del usuario. .................................................... 39

Figura 16: Puntos extraviados en el skeletal tracking. ......................................................................... 40

Figura 17: Ejemplo de características para detección de caras. Extraído de [25]. .................... 42

Figura 18: Diagrama de estados de clasificador en cascada. Extraído de [25]. .......................... 42

Figura 19: Iconos empleados para dinámica de pararse y sentarse. .............................................. 44

Figura 20: Estados del huevo virtual, para dinámica de equilibrio ................................................. 48

Figura 21: Usuario en terapia de rehabilitación, haciendo uso de la aplicación ........................ 49

Tabla de Anexos

A. Diagrama de clases de la aplicación .......................................................................................... 56

B. Gameloop del framework XNA ............................................................................................... 57

C. Diagrama de proyección de un esqueleto al plano bidimensional ........................................... 58

D. DInámica sentarse y pararse - Usuario sentado ....................................................................... 58

E. Dinámica sentarse y pararse - Usuario de pie ........................................................................... 59

F. Dinámica de equilibrio - Incialización ........................................................................................ 59

G. DInámica de equilibrio - Durante interacción ........................................................................... 60

H. Dinámica de equilibrio - Fin de interacción .............................................................................. 60

1

1 Introducción

1.1 Aspectos generales

El proyecto llevado a cabo se enmarcó en el ámbito de la neurorrehabilitación y la

kinesiología. El avance de las ciencias de la computación ha hecho que tecnologías avanzadas

sean cada vez más asequibles. Sumado a los costos decrecientes del hardware involucrado, esto

ha permitido que se incorpore cada vez más tecnología en las terapias de rehabilitación. Esto ha

generado una serie de beneficios en esta área, tanto para los tratantes, como para los usuarios

en terapia.

La rehabilitación, en términos generales, es una especialidad del área de las ciencias

médicas. Su fin es que un individuo alcance el máximo potencial que le sea posible, dentro de su

condición, mejorando o manteniendo su calidad de vida. La rehabilitación abarca distintos

ámbitos, como por ejemplo: social, psicológico, fisiológico, etc. En ella participan no sólo el

rehabilitado, sino que también la familia de éste y un equipo de especialistas en el área.

Llevada al ámbito de la kinesiología, profesión que estudia el movimiento del cuerpo

humano, la rehabilitación se enfoca en lograr que un individuo mejore su capacidad de

desplazamiento y movimiento físico. Dentro de la gama de herramientas empleadas en la

kinesioterapia, se incluye ejercicios físicos para el usuario. Estos ejercicios no sólo son llevados a

cabo durante sesiones con especialistas del área (kinesiólogos, fisioterapeutas, terapeutas

ocupacionales, entre otros), sino que también en el hogar. Generalmente estos últimos no

requieren supervisión profesional.

Como ya fue mencionado, cada vez se emplea más tecnología en la rehabilitación. Entre

las tecnologías empleadas, se ha usado la detección de movimiento con resultados positivos,

desde el punto de vista de la terapia [1] [2] [3] [4]. Esta simbiosis interdisciplinaria ha permitido

generar herramientas de asistencia a la terapia. Estas herramientas han contribuido con mayor

información relevante al proceso, además de otros efectos positivos, tanto recreativos, como

distractivos.

2

Para realizar la detección de movimiento, actualmente se usan varias tecnologías. Una de

ellas es la videocaptura, empleando algoritmos de distinto tipo. También se emplean artefactos

con acelerómetros, capaces de detectar rotaciones en las tres dimensiones. También se puede

encontrar artefactos que emplean sensores infrarrojos. Finalmente, las pantallas táctiles

también pueden considerarse como detectores de movimiento. Todas estas tecnologías

permiten una interacción humano – computador basada en los movimientos corporales.

En el presente trabajo se detalla la investigación, diseño e implementación de una

aplicación para asistir a la rehabilitación. Esta aplicación emplea la videocaptura mediante

cámara web para realizar detección de movimiento de los usuarios. Los usuarios interactúan

con la aplicación, la cual los guía a través de ejercicios kinesiológicos útiles para su

rehabilitación.

1.2 Justificación y motivación

La principal motivación para la realización del proyecto radicó en el potencial aporte

para la sociedad. Desarrollar herramientas tecnológicas para asistir la terapia kinesiológica

aporta calidad de vida, autonomía y ayuda a aumentar el potencial de los individuos tratados.

Personas más autónomas y con mayor potencial, pueden a su vez aportar de mejor manera a su

entorno.

Además, tecnologías de detección del movimiento actualmente han sido integradas en

varias plataformas de videojuegos, lo cual da a entender que su inclusión contribuye a una

mayor entretención. Basándonos en esto, la inclusión de estas tecnologías puede ayudar a que

la experiencia de la terapia sea más placentera para el usuario. Una terapia más entretenida

genera mayor proactividad del usuario en su rehabilitación.

El uso de la tecnología también facilita la obtención de métricas. La extracción de

información de forma automatizada, permite medir de forma más objetiva variables como el

progreso de una terapia. Facilitar la obtención de información que permita medir el progreso de

un usuario también motivó el desarrollo del proyecto.

3

Adicionalmente a lo anteriormente expuesto, el rol del ingeniero en la sociedad también

motivó llevar a cabo este proyecto. El asistir áreas del conocimiento como la medicina, se

condice con la labor del ingeniero en computación. El ingeniero se debe integrar con

profesionales de múltiples disciplinas, y no tan sólo entenderse con colegas de su misma área.

Finalmente, no cabe duda alguna de lo complejo que resulta implementar soluciones

utilizando las tecnologías descritas. Desarrollar usando la detección de movimiento para realizar

interacción humano – computador fue un desafío motivante. Debido la masificación reciente

de esta tecnología, resultó complejo encontrar soluciones a los problemas que iban surgiendo.

Estos problemas resultaron ser dignos de la labor de un ingeniero en computación.

1.3 Objetivos

1.3.1 Objetivo general

El objetivo general es diseñar e implementar una aplicación que asista al terapeuta

durante una sesión de rehabilitación, incentivando al usuario a realizar ejercicios de terapia

física.

1.3.2 Objetivos específicos

• Detectar el movimiento de un usuario.

• Implementar dinámicas basadas en rutinas de ejercicios usados en rehabilitación.

• Generar indicadores que ayuden a cuantificar el progreso de un usuario.

• Diseñar una solución extensible, a la cual sea posible agregar distintos algoritmos y

tecnologías de detección de movimiento. También debe ser posible agregar nuevos

ejercicios o dinámicas.

• Desarrollar para uso en un ambiente controlado, manteniendo en cuenta el futuro uso

doméstico de la solución.

4

1.4 Alcances

El presente trabajo abarca la investigación sobre tecnologías de detección de movimiento,

el diseño de dinámicas de neurorrehabilitación y una aplicación de software que las utilice.

También abarca su respectiva implementación, y validación con usuarios en rehabilitación, en

un ambiente controlado, en presencia de terapeutas. Los usuarios objetivos son personas que

se encuentran en neurorrehabilitación, sin considerar una condición específica, en un rango

etario amplio (jóvenes, adultos, adultos mayores). Es por esto que las dinámicas desarrolladas

son muy generales.

El presente trabajo no abarca un diseño avanzado de las interfaces de usuario. Tampoco

abarca la validación de la aplicación desarrollada en un contexto hogareño. Debido a esto el

resultado final es un prototipo plenamente funcional.

1.5 Contenidos

1. Introducción: Se presenta una introducción al tema, en sus aspectos generales. También

se da justificación para la elección y ejecución del proyecto. Se enuncian también los

objetivos del proyecto.

2. Antecedentes: Se presentan conceptos necesarios para la comprensión del trabajo

realizado, explicados en forma detallada. Se presenta también revisión de trabajos

relacionados.

3. Diseño: Se presenta detalles del diseño del software de la aplicación desarrollada

durante el proyecto. Se justifican decisiones de diseño, y se explicita su propósito.

4. Implementación: Se detalla el proceso de implementación del proyecto. Se explican los

desafíos de implementación enfrentados, y se justifica las decisiones de

implementación. También se muestran resultados obtenidos.

5. Conclusiones: Se analiza los resultados obtenidos y se presentan las conclusiones del

trabajo realizado. Se analiza posibles avances futuros, y se propone mejoras a la

aplicación desarrollada.

6. Referencias: Se lista las referencias y bibliografía estudiada durante el desarrollo de la

memoria.

5

7. Anexos: Se presenta información adicional, no relevante para el entendimiento del

trabajo realizado, pero de potencial interés.

6

2 Antecedentes

En esta sección se describen conceptos necesarios para entender el trabajo realizado.

También se muestra información sobre trabajos relacionados.

2.1 Conceptos de detección de movimiento

2.1.1 Tecnologías comúnmente usadas para detectar movimiento

En la actualidad existen diversas formas de realizar detección de movimiento. Una de estas

formas, es mediante receptores infrarrojos. Un receptor infrarrojo, puede hacer seguimiento de

una o varias luces infrarrojas. Por ende si colocamos luces infrarrojas sobre el cuerpo humano,

podemos hacer seguimiento de sus movimientos. También se puede emplear a la inversa, y

poner luces infrarrojas fijas, y detectar el movimiento del sensor.

Otra forma, es mediante el uso de acelerómetros, que permiten detección de rotaciones en

tres dimensiones. Un acelerómetro permitiría conocer la inclinación de algún objeto controlado

por o adherido al cuerpo humano.

Existen también dispositivos que emplean potenciómetros, para medir rotaciones en una

dimensión. Generalmente se usan varios potenciómetros en un artefacto, para medir la

rotación de brazos móviles. Por ejemplo, en guantes virtuales, pueden detectar la rotación de

las articulaciones de los dedos.

Por último, existe la detección de movimiento mediante videocaptura. La videocaptura no

se limita tan sólo a los espectros de luz visibles, sino que también se puede detectar movimiento

en el infrarrojo. La detección de movimiento en el video involucra el análisis de uno o más de los

fotogramas que componen el flujo de video. Para esto existen varios tipos de algoritmos, que se

describirán a continuación.

7

2.1.2 Algoritmos de detección de movimiento humano

Existe gran cantidad de algoritmos para detección de movimiento basados en la

videocaptura, también denominados de visión computacional. Existen algunas taxonomías en la

literatura [5] [6], que proponen distintas formas de clasificar los algoritmos de visión

computacional empleados en detección de movimiento humano. Entre los criterios

considerados se encuentran: tipo de suposiciones realizadas, uso o no de modelo humano,

cámara de posición fija o móvil, uso de información temporal o espacial, representación de los

objetos, reconocimiento estático o dinámico de posturas.

En general, los algoritmos estudiados e implementados son para cámara de posición fija.

También, en general, suponen la existencia de una sola persona delante de la cámara, la cual no

abandona el campo visual de la cámara en ningún momento, durante el período de detección.

En cuanto a representación de los objetos, los algoritmos estudiados difieren. Entre los

algoritmos investigados, se cuentan algoritmos sin representación de objetos (detección a nivel

de pixel), algoritmos que representan objetos mediante bordes, representación mediante

rectángulos y mediante blobs (grupos de pixeles de igual forma y tamaño).

Sin embargo, una de las diferencias que se considera más relevantes para clasificar los

algoritmos estudiados es según el tipo de información empleada. De acuerdo con Moeslund et

al. [6], existen algoritmos que emplean información temporal y otros que emplean información

espacial.

Los que emplean información temporal en general utilizan dos o más fotogramas para

extraer información, es decir, comparan información en distintos instantes. En los algoritmos

temporales, podemos diferenciar entre aquellos que utilizan substracción y flujo óptico.

Aquellos que realizan substracción, restan los valores de cada pixel de los fotogramas con otro

fotograma o una imagen de fondo (real o calculada). Así, se obtiene un mapa de diferencias en

el cual se pueden clasificar los puntos como con movimiento, donde la diferencia es mayor, y

puntos sin movimiento, donde la diferencia es menor. Los que se basan en flujo óptico, en

cambio, calculan la posición de cierto punto o característica, en cada nuevo fotograma.

8

Los que emplean información espacial, en cambio, extraen información del fotograma

actual, sin comparar con fotogramas anteriores. En "A Survey of Computer Vision-Based Human

Motion Capture" [6] se menciona aquellos que usan métodos estadísticos con información

espacial para calcular imágenes de fondo para emplear substracción. Sin embargo, estos

métodos no son puramente espaciales, sino más bien híbridos. Algoritmos que serían

puramente espaciales, serían, por ejemplo, aquellos que rastrean objetos con un color

determinado. Estos serían aquellos que emplean “thresholding”, es decir, sólo aceptan un rango

de color, y lo aíslan del resto. También están incluidos aquí los algoritmos que usan

reconocimiento de patrones. Estos caben en la categoría de estadísticos, según la clasificación

hecha en [6].

2.2 Conceptos de ingeniería de software

Para resguardar la calidad, mantenibilidad y extensibilidad de la implementación, se hizo

uso de la orientación a objetos y patrones de diseño. La orientación a objetos es un paradigma

de programación, que se basa en una representación del programa a desarrollar, como objetos

e interacciones entre estos. La orientación a objetos agrupa un conjunto de prácticas y

herramientas que ayudan a generar código extensible y reutilizable. Los patrones de diseño son

un conjunto de soluciones genéricas reutilizables y adaptables. En programación orientada a

objetos, los patrones de diseño se expresan como plantillas de objetos e interacciones que

resuelven un problema particular. Estas plantillas pueden ser aplicadas y reutilizadas en otros

programas, con poca o nula adaptación.

2.2.1 Patrones de diseño relevantes

A continuación, se describen los patrones de diseño relevantes para la aplicación

desarrollada en el proyecto:

• Adapter [7]: Proporciona una interfaz nueva para un objeto preexistente, legado o

proveniente de terceros. Permite utilizar las funcionalidades de un objeto,

adaptándolo a los requerimientos de la nueva aplicación.

9

• Composite [7]: Hace uso de la composición recursiva, para crear estructuras de

árbol. Permite manipular de forma uniforme los objetos compuestos (nodos) y

simples (hojas).

• Private Class Data [8]: Separa los atributos considerados como datos de una clase,

en una clase separada. En esta nueva clase, los atributos son privados y sólo son

accesados mediante métodos (i.e.: getters y setters). Esto permite encapsular la

inicialización de los datos, y controlar la forma en que se manipulan (i.e. acceso de

lectura y escritura).

• Mediator [7]: Define un objeto que encapsula las interacciones de un conjunto de

objetos. Luego, estos objetos interactúan empleando el nuevo objeto como

mediador. Permite disminuir el acoplamiento entre objetos que, de otro modo,

tejerían una red compleja de interacciones.

• Strategy [7]: Define una interfaz para una familia de algoritmos. Esto permite

implementar cada algoritmo en una clase separada, e intercambiarlos fácilmente.

• Template Method [7]: Se define el esqueleto de un algoritmo en una clase,

mediante distintos métodos a ejecutar durante el algoritmo. Luego, se redefinen

los métodos en las subclases. Esto permite relegar la implementación del

algoritmo, sin cambiar la estructura.

2.3 Conceptos de neurorrehabilitación y kinesiología

Como ya se mencionó, la rehabilitación es una especialidad del área médica, cuyo objetivo

es que un usuario incremente su potencial y calidad de vida. El término rehabilitar tiene la

connotación de recuperar funciones o potencial perdido, pero hoy en día se entiende que no

necesariamente es volver a una condición anterior. [9]

En particular, es de interés para el presente trabajo el área rehabilitación que se

especializa en enfermedades y condiciones del sistema nervioso, la neurorrehabilitación. Esto,

dado que los usuarios objetivos de la aplicación desarrollada son personas con enfermedades

como parkinson y parálisis cerebral, entre otras. Es importante notar que estas enfermedades

provocan que las personas no tengan los mismos parámetros que quienes no las padecen [9]. En

10

muchos casos la postura se ve afectada, presentan dificultad para caminar, sentarse y pararse,

tienen equilibrio disminuido o presentan temblores.

El rol de la kinesiología en la neurorrehabilitación, en general es mejorar la postura y

patrones de movimiento de los usuarios [9]. Esto lo logra mediante distintos tipos de ejercicios

físicos, dinámicas y masajes.

2.4 Especificación de problemas existentes

Al momento de realizar la investigación para el proyecto, se buscó los principales

problemas que se podía atacar en el proceso de rehabilitación. Para esto, se entrevistó a

kinesiólogos, terapeutas ocupacionales, médicos y otros profesionales relacionados con el área.

También se consultó bibliografía, parte de la cual fue sugerida por los entrevistados. Los

principales problemas detectados se detallarán en esta sección.

El primer problema detectado tiene que ver con la necesidad de reforzar la terapia de

rehabilitación en el hogar. No siempre resulta fácil para el usuario reforzar en su hogar. Sin

embargo, el realizar ejercicios en la casa es de gran ayuda para su progreso en el proceso de

rehabilitación. [10]

El segundo problema detectado radica en el costo de los equipos empleados para la

rehabilitación. A veces los equipos que pueden ayudar en la rehabilitación tienen un precio que

no permite su uso masivo. También este mismo alto costo hace más difícil el reforzar de forma

doméstica, dada la imposibilidad del usuario para adquirir uno para uso personal.

El tercer problema detectado está relacionado con la usabilidad y versatilidad de los

equipos usados para rehabilitación. A veces estos equipos no fueron diseñados para usuarios en

rehabilitación. Por ende, a veces resultan difíciles de manipular de forma no asistida para el

usuario.

11

2.4.1 Refuerzo de la Terapia en el Hogar

Actualmente, el trabajo de rehabilitación se lleva a cabo mayormente en los centros

médicos. Las sesiones de terapia generalmente duran una o dos horas, y se realizan dos o tres

veces a la semana. Sin embargo, la rehabilitación es un proceso que debiese ser continuo, e

involucrar a todo el entorno del rehabilitado. Es por esto que el refuerzo en la casa es necesario

para hacer más efectivo el proceso de rehabilitación. Sin embargo, a veces en la casa no siempre

es fácil para el usuario seguir los ejercicios. Además, no es posible para el terapeuta saber

cuánto trabajó y progresó el usuario.

Durante una sesión de terapia, siempre se encuentra presente un profesional (un

kinesiólogo, o un terapeuta ocupacional, por ejemplo). Este profesional conoce a la perfección

las tareas que el usuario debe llevar a cabo. Este profesional puede dar instrucciones al usuario

de cómo realizar el ejercicio o tarea, a fin de que realmente cumpla su propósito. También

puede supervisar durante la realización de este ejercicio. Generalmente durante estos

ejercicios, la postura del usuario es importante. Una mala postura puede hacer que el ejercicio

no sea provechoso, o que incluso pueda llegar a ser perjudicial.

Los terapeutas también pueden obtener información a partir de cómo un usuario realiza

un ejercicio. El tiempo que demora o qué tan bien realiza la tarea, son algunas de las cosas que

el terapeuta puede observar. Estas observaciones permiten realizar una evaluación del progreso

del usuario en su proceso de rehabilitación.

Sin embargo es necesario reforzar también los ejercicios en la casa. Pero, en la casa,

generalmente no se cuenta con la asistencia de un profesional. Por ende, no siempre resulta

fácil realizar ejercicios en la casa. A veces, el usuario olvida los ejercicios o la rutina que fue

recomendada por el terapeuta. También a veces no realizan de forma correcta los ejercicios.

Cuando los usuarios son de la tercera edad se le pide a alguien más que asista al usuario para

llevar a cabo los ejercicios, pero aquí ocurren los mismos problemas.

Además no se puede saber cuál es el progreso del usuario en su propia casa. Esta

información puede ser útil para el terapeuta. Por ejemplo, puede ayudar a focalizar en algo

12

particular la siguiente sesión. También puede ayudar a tener una idea más clara de cuanto

realmente sirve el realizar ejercicios de forma doméstica.

2.4.2 Costo de Equipos para Rehabilitación

Los equipos que se emplean actualmente para rehabilitación, son a veces muy costosos.

Con el avance de la tecnología se ha creado equipos más adecuados para la rehabilitación y a un

costo cada vez menor. Sin embargo, si bien estos equipos son cada vez más asequibles para los

centros médicos, no siempre lo son para el usuario final. Esto se transforma en una barrera para

reforzar la terapia en el hogar, mencionado en el punto anterior.

En la rehabilitación se emplea una gran gama de equipos. Algunos son tremendamente

simples, como objetos plásticos o balones. Pero también hay otros, mucho más complejos,

como hardware, software y estructuras especiales. Estos equipos complejos permiten recolectar

mayor información o brindar una mejor experiencia de rehabilitación. Sin embargo, a veces

pueden ser muy costosos, lo cual se traduce en un acceso limitado para los usuarios en

rehabilitación.

A medida que la investigación sobre rehabilitación y sobre tecnologías avanza, estos

equipos son más asequibles para los centros médicos. Y no solamente se hacen menos costosos,

sino que también más efectivos. Por ejemplo, la consola de juegos Wii® de Nintendo® se está

empleando mucho para rehabilitación [11]. Esto dado que tiene gran cantidad de prestaciones

debido a la detección de movimiento que su controlador permite. Una consola como esta tiene

un costo aproximado de $200.000 - $300.000, lo cual resulta bastante asequible para un centro

médico.

Sin embargo, equipos como estos no siempre son asequibles para el usuario, debido a su

precio. Sobre todo considerando que los usuarios generalmente tienen gastos adicionales

relacionados con su rehabilitación. Por ende, el usuario se ve restringido a emplear equipos que

estén al alcance de su presupuesto. Esto limita la calidad de la experiencia de rehabilitación en

el hogar, mencionada en el punto anterior.

13

2.4.3 Usabilidad y Versatilidad de Equipos Empleados en Rehabilitación

La usabilidad y versatilidad de los equipos y software es un tema importante para los

terapeutas. No siempre los equipos empleados para rehabilitación fueron diseñados

originalmente para este propósito. Es por esto que a veces su usabilidad no es la óptima para un

usuario en rehabilitación. A veces los equipos tampoco permiten gran flexibilidad, lo cual limita

la cantidad de usuarios que pueden beneficiarse de este equipo. Si bien esto no impide que

estos equipos sean empleados, siempre es un tema a considerar al momento de emplear

equipos para rehabilitación.

Cuando se habla de la versatilidad de los equipos empleados en rehabilitación, se hace

referencia a la posibilidad de configurarlos de forma distinta, para acomodar a distintos

usuarios. Una mayor versatilidad es generalmente deseable, dado que implica una mayor

cobertura, en cuanto a cantidad de usuarios. Por ejemplo, a veces un usuario tiene un rango de

movimiento reducido en una extremidad con respecto a la otra, pero el software no fue

diseñado para trabajar en este contexto.

Con usabilidad nos referimos a qué tan fácil resulta utilizar los equipos para el usuario. A

veces el software empleado en rehabilitación no tiene una interfaz lo suficientemente simple

como para que el usuario lo manipule por sí mismo.

La versatilidad y usabilidad por sí mismas son importantes en los equipos y software

orientados a rehabilitación. Más importante aún, es cuando se considera equipos y software

para reforzar la rehabilitación de forma doméstica. Es por esto que es difícil encontrar equipos

que reúnan las características mencionadas, para asistir la rehabilitación en la casa del usuario.

2.5 Trabajos relacionados

Como parte de la etapa de estudio del proyecto, se revisó bibliografía relacionada con el

uso de tecnologías en la rehabilitación. Se seleccionó aquellos que se consideró más cercanos a

lo que se deseaba implementar. En general, describen situaciones de uso de la detección de

movimiento en la rehabilitación, uso de tecnologías de bajo costo para rehabilitación y

14

reforzamiento de la terapia en el hogar mediante software. Su relevancia está relacionada con

la factibilidad del proyecto, además de servir de inspiración previa al diseño del software y

dinámicas.

2.5.1 Feasibility, Motivation and Selective Motor Control: Virtual Reality Compared

to Conventional Home Exercise in Children with Cerebral Palsy. [1]

Este paper describe una experiencia realizada con niños con parálisis cerebral. La

parálisis cerebral afecta al control de la actividad muscular. Comúnmente, los niños efectúan

ejercicios, uno de los cuales consta de una serie de dorsiflexiones (flexiones del tobillo).

Para apoyar el ejercicio descrito, se desarrolló dos juegos. Estos juegos detectan el

movimiento del tobillo, y a partir del movimiento ejecutan una acción determinada. De acuerdo

con esto, el jugador obtiene un puntaje, que varía según la amplitud del movimiento y la

cantidad de tiempo que se haya sostenido en su punto máximo. Es decir, el juego entrega

mayor puntaje si el movimiento es más amplio y si el jugador mantiene el tobillo flectado más

tiempo.

El juego se probó en niños con y sin parálisis cerebral. Luego, se pidió a los niños y a sus

padres que evaluaran el nivel de entretención de la terapia. También se hizo lo mismo con niños

que realizaron la terapia de forma tradicional. Se midió en ambos casos el movimiento del

tobillo de los niños, mediante un electrogoniómetro. Posterior a esto, se analizó y comparó los

resultados obtenidos.

Estos resultados mostraron que la inclusión de los juegos en la terapia la hizo más

entretenida. Además, mostró una diferencia en efectividad de la terapia. Los niños que usaron

el juego mostraron mayor grado y tiempo de dorsiflexión. Esto contribuye a la idea de que se

puede lograr mejoras mediante la inclusión de juegos y otro software de apoyo a la terapia.

15

2.5.2 Low-cost Virtual Rehabilitation of the Hand for Patients Post-Stroke. [2]

En este paper, se muestra el desarrollo de un sistema de rehabilitación de la mano para

pacientes afectados por un accidente cerebrovascular. Muestra como se puede obtener un

software similar a un sistema existente, a un costo menor (aproximadamente un 3% del costo

del sistema existente).

El sistema original, empleaba un PC como plataforma. Usaba también un guante

CyberGlove para detectar los movimientos de la mano del paciente. Finalmente, empleaba las

librerías de software del WorldToolKit para el desarrollo de las aplicaciones. En reemplazo, el

sistema desarrollado empleó una Xbox, a la cual se le instaló Xebian Linux. En reemplazo del

guante CyberGlove, empleó un guante similar, de menor precisión y sin force-feedback.

Finalmente, utilizó las librerías de Java3D para el desarrollo de las aplicaciones.

Las aplicaciones que se desarrollaron fueron dos, las cuales buscan que el usuario haga

un mayor movimiento de los dedos de la mano. La primera consistía en revelar una imagen

mediante el movimiento de los dedos al pasar virtualmente sobre una zona donde la imagen se

encontraba oculta o tapada. La segunda aplicación consistía en ahuyentar una mariposa posada

sobre la mano virtual del paciente, mediante el movimiento de los dedos.

El resultado fue que se pudo desarrollar un sistema de bastante menor costo, con

características casi idénticas. Existían ciertas diferencias, como una menor precisión del sistema

más económico, pero estas eran sólo levemente significativas.

Este resultado nos muestra que el avance de la tecnología hace cada vez más asequible y

económico el desarrollo de herramientas para, por ejemplo, la rehabilitación. Es importante

notar que herramientas más económicas permiten una mayor cobertura. Además, herramientas

lo suficientemente económicas pueden permitir al paciente adquirirlas y reforzar la terapia en el

hogar.

16

2.5.3 Post-stroke arm motor telerehabilitation web-based. [3]

Este paper describe una experiencia realizada con pacientes afectados por un accidente

cerebrovascular. Consistió en realizar terapia para movimiento del brazo de forma remota, es

decir, mediante tele-rehabilitación. En la tele-rehabilitación, el paciente y el terapeuta se

comunican mediante el uso de internet y software de uso específico.

En el hogar del individuo a ser tratado, se instaló una conexión ADSL, un computador con

una cámara web y un dispositivo electromagnético. El dispositivo electromagnético permitió

detectar los movimientos del brazo del usuario, mediante un objeto que el usuario debía

trasladar. También se instaló un software que presentaba al usuario las tareas a realizar durante

la terapia. Estas tareas consistían de trayectorias que el usuario debía seguir, moviendo el

dispositivo anteriormente mencionado.

Al momento de realizar la terapia, el terapeuta y el sujeto se conectaban a internet.

Tenían acceso a comunicación mediante audio y video. Además el feedback del dispositivo

también era enviado al terapeuta. El terapeuta podía orientar e instruir al usuario de esta

forma, y tenía completo control sobre los comandos del software empleado.

En paralelo, también se trató a otros pacientes en el hogar, pero sin emplear la tele-

rehabilitación (i.e. mediante visita médica). Luego se evaluó la condición de todos los individuos,

empleando escalas tradicionales para este propósito. Los resultados indicaron que los pacientes

que emplearon tele-rehabilitación lograron mejores valores en las escalas usadas para medir su

condición, que aquellos que fueron tratados de forma tradicional en su hogar.

Este resultado permite pensar que la información que se puede extraer mediante el uso

de tecnologías es sumamente importante. Tanto así, que en la experiencia descrita en el paper

no era necesaria la presencia física del terapeuta.

17

2.5.4 A low-tech virtual reality application for training of upper extremity motor

function in neurorehabilitation. [4]

Este paper describe el uso de juegos con detección de movimiento en la

neurorrehabilitación. Para lograr la detección de movimiento, emplea una cámara web

convencional.

En la experiencia descrita en el paper, se desarrolla un juego para neurorrehabilitación.

El juego está orientado al entrenamiento de las extremidades superiores, para movimientos

verticales. Es decir, está orientado a lograr movimientos en los cuales se debe levantar los

brazos. El juego detecta los movimientos del usuario a través de la webcam. El juego fue

programado en Adobe Flash.

Se adaptó el juego también para ser usado de forma horizontal. Para esto, se empleó un

monitor plano a modo de mesa, y se colocó la cámara web encima de la mesa y el usuario. Esto

permitió abarcar movimientos de tipo horizontal, en que los brazos se estiran hacia adelante.

Los resultados del estudio mostraron que la terapia empleando este juego fue efectiva.

Se logró mejoras en las condiciones de los usuarios.

18

3 Diseño

3.1 Evaluación de opciones tecnológicas

A continuación se describirá la evaluación que se llevó a cabo para elegir las tecnologías

que se utilizaron en el proyecto. Cabe notar que en este campo de la computación se está

progresando a paso muy rápido actualmente, por lo que hay factores considerados en la

evaluación que cambiaron mientras se diseñaba e implementaba la solución.

3.1.1 Opciones disponibles

Se evaluó tres opciones tecnológicas para realizar la detección de movimiento. Existen,

evidentemente, otras opciones, pero se privilegió aquellas que permitieran mayores

prestaciones y que fueran menos invasivas. Las opciones evaluadas fueron: Microsoft® Kinect®,

Nintendo® Wiimote®, una webcam genérica. Al momento de realizar la evaluación, aún no

había sido lanzado Playstation® Move de Sony®, razón por la cual no fue considerado.

3.1.1.1 Microsoft® Kinect®

Kinect® es un dispositivo de detección de movimiento corporal creado por Microsoft®,

para su consola, Xbox 360. Este se integra como un dispositivo de entrada de la consola,

enchufado mediante USB. Debido a su interfaz USB, es posible conectarlo a un computador

común y corriente.

La Kinect® funciona empleando una combinación de tecnologías. Proyecta una malla de

puntos de luz infrarroja, los cuales detecta con un sensor infrarrojo. También emplea una

cámara de video a colores. En conjunto, puede detectar movimiento mediante análisis de

imágenes, y también tener noción de profundidad. El costo aproximado de uno de estos

dispositivos es de USD$150.

Al momento de realizar la evaluación, existía una librería no oficial para desarrollar

aplicaciones usando Kinect®. Esta librería es OpenKinect (renombrada libfreenect) [12], sin

embargo, había sido desarrollada y liberada muy recientemente.

19

3.1.1.2 Nintendo® Wiimote®

El Wiimote® es el dispositivo de entrada de la consola Wii® de Nintendo®. Funciona

como un joypad común, pero además utiliza tecnologías de detección de movimiento. Posee un

acelerómetro y un receptor infrarrojo, que permite emplearlo como puntero. El control remoto

se conecta inalámbricamente, vía bluetooth, a la consola. El costo del dispositivo es cercano a

los USD$20.

Es también posible conectar el Wiimote® a un PC común y corriente. Esto se debe a que

interactúa mediante bluetooth. De este modo, el Wiimote® puede ser empleado como

dispositivo de entrada en un computador.

Las prestaciones del dispositivo son múltiples. Se puede hacer uso de él, en reemplazo

de un mouse, como dispositivo apuntador. También posee un acelerómetro, lo que permite

obtener como entrada la posición en que se encuentra el control remoto en un momento

determinado. Alternativamente, se puede dejar fijo en una posición, y detectar el movimiento

de varias luces infrarrojas.

Al momento de realizar la evaluación ya existían librerías para varios lenguajes de

programación. Por ejemplo, WiimoteLib para C#, motej para Java, pywiiuse para Python, etc.

3.1.1.3 Cámara Web

Las cámaras de video se han utilizado comúnmente para detección de movimiento,

sobre todo en el ámbito de la seguridad. Pese a esto, generalmente es difícil encontrar buenas

implementaciones de detección de movimiento, que no sean orientadas a aplicaciones de

seguridad.

Existe gran variedad de marcas y modelos de cámara web. Asimismo, existe gran rango

de precios, siendo posible encontrar una webcam desde USD$6. Además, existen librerías para

recibir input de cámara para prácticamente todos los lenguajes de programación. También

20

existe gran cantidad de librerías de procesamiento de imagen, que facilitan la tarea de

implementar algoritmos para detección de movimiento.

3.1.2 Análisis de opciones

Se realizó un análisis de las tres opciones presentadas. La opción de emplear Kinect® se

determinó infactible al momento del análisis, debido a la poca madurez de la librería disponible.

Por ende, fue necesario decidir entre las dos opciones restantes. Finalmente, se optó por la

detección de movimiento mediante webcam.

Desarrollar empleando Kinect®, sin embargo, aparecía como la opción más atractiva.

Esto, dado lo innovador de esta tecnología, y también debido a que hubiese resuelto el tema de

la detección corporal de forma muy poco invasiva. De este modo, el desafío se habría reducido a

implementar las dinámicas de los ejercicios y la interfaz de usuario. Se esperaba que para el

momento del análisis, Microsoft® ya hubiese puesto a disposición librerías para emplear Kinect®

(posiblemente para el framework XNA). Sin embargo, esto no fue así, y se investigó sobre

librerías de código abierto. De esta forma se supo sobre la existencia de OpenKinect, que

desgraciadamente al momento del análisis no se encontraba lo suficientemente madura como

para considerar desarrollar empleándola. Esto, dado que no se sabía si seguiría existiendo

soporte para ella en el futuro, ni se tenía garantías de la estabilidad del software.

La segunda opción, que involucra el Wiimote®, aparecía muy flexible. Sin embargo,

requiere que el usuario haga uso del control o bien de una luz infrarroja. De haber elegido esta

alternativa, hubiese quedado descartado el poder detectar únicamente el movimiento corporal,

sin implementos adicionales. Además se hubiese acotado el universo de posibles usuarios, dado

que no todos los usuarios en rehabilitación podrían manipular el Wiimote® de forma efectiva.

De todos modos, hubiese sido posible desarrollar ejercicios para kinesiología empleando luces

infrarrojas en los usuarios, u orientando los ejercicios a aquellas personas que pudiesen

manipular el dispositivo.

La detección mediante webcam requería resolver el problema de la detección del

movimiento, mediante el desarrollo o adaptación de un algoritmo para el efecto. Esto tiene, por

21

cierto, algún grado de complejidad. Sin embargo, permitiría al usuario interactuar utilizando

únicamente sus movimientos corporales. Esta forma de interactuar es sin duda la menos

invasiva de todas y además resulta muy intuitiva. Además, se realizó una pequeña prueba para

probar la factibilidad de esta opción, la cual se detalla más adelante.

Finalmente se optó por emplear la cámara web. La razón principal fue que permitía

interacción sin que el usuario requiriese manipular artefactos. De esta forma, se evitaba reducir

el universo de usuarios posibles. Sin embargo, emplear el Wiimote® hubiese implicado menos

dificultades de implementación. Además, ambas opciones tenían costos muy bajos, lo cual se

traducía en cierta indiferencia en cuanto a lo económico.

3.2 Diseño de las dinámicas a implementar

Las dinámicas fueron diseñadas en base a ejercicios utilizados en neurorrehabilitación.

Fueron elegidas por su amplio uso, simplicidad y factibilidad. Se contó con el asesoramiento de

profesionales del área de la kinesiología para la elección y diseño de las dinámicas.

3.2.1 Sentarse y Levantarse de una Silla

El sentarse y levantarse de una silla es uno de los ejercicios más básicos. Es un

movimiento cotidiano que se repite muchas veces a lo largo del día. Usuarios en proceso de

rehabilitación pueden presentar dificultad en realizar este ejercicio. El objetivo de este ejercicio

es disminuir la dificultad para sentarse y levantarse de una silla de forma autónoma.

Dado lo básico de este ejercicio y debido a la cantidad de veces que una persona debe

pararse y sentarse a lo largo de un día, es uno de los puntos de partida de las terapias. Los

usuarios que presentan dificultades en realizar esta actividad, muchas veces presentan una

postura que dificulta aún más la tarea. Por ejemplo, encorvan en exceso la espalda, o se colocan

demasiado cerca del respaldo al intentar levantarse.

El ejercicio implementado, por ende, tenía que ser capaz de detectar cuando un usuario:

• Está sentado

• Está poniéndose de pie

• Está de pie

• Está sentándose

Se determinó entonces, que sería posible detectar estos estados mediante

Para esto fue necesario colocar la cámara

Figura 1: Posicionamiento de la cámara en ejercicio de pararse y sentarse.

3.2.2 Elevación de un Pie a Baja/Mediana Altura

Es un ejercicio también básico, pero más difícil que levantarse de una silla. Consiste en

mantener un pie elevado a una altura determinada del suelo. Generalmente

elemento inestable o frágil bajo el pie, para que el us

objetivo es mantener esta posición la mayor cantidad de tiempo posible. Este ejercicio busca

mejorar el equilibrio del usuario.

Durante las sesiones de terapia, generalmente se utiliza un elemento de apoyo bajo

pie. La razón de esto, es para que se note claramente que el usuario está tocando el objeto, a fin

de mantener una altura máxima. Además, la idea es que el objeto de apoyo sea inestable o

frágil. De esta forma, si el usuario pisa demasiado fuerte el obj

mueve. Por ejemplo, se puede usar una pelota pequeña, la cual si no es pisada, no se mantiene

en su posición. Pero, si se pisa demasiado fuerte, suena o rueda alejándose del pie.

22

Está poniéndose de pie

Está sentándose

Se determinó entonces, que sería posible detectar estos estados mediante

necesario colocar la cámara de forma frontal, como descrito en la

: Posicionamiento de la cámara en ejercicio de pararse y sentarse.

Pie a Baja/Mediana Altura


mantener un pie elevado a una altura determinada del suelo. Generalmente

elemento inestable o frágil bajo el pie, para que el usuario mantenga el pie a una altura fija. El


mejorar el equilibrio del usuario.

Durante las sesiones de terapia, generalmente se utiliza un elemento de apoyo bajo



frágil. De esta forma, si el usuario pisa demasiado fuerte el objeto, este suena, se rompe, o se



Se determinó entonces, que sería posible detectar estos estados mediante seguimiento facial.

, como descrito en la Figura 1.

: Posicionamiento de la cámara en ejercicio de pararse y sentarse.


mantener un pie elevado a una altura determinada del suelo. Generalmente, se usa un

uario mantenga el pie a una altura fija. El


Durante las sesiones de terapia, generalmente se utiliza un elemento de apoyo bajo el



eto, este suena, se rompe, o se



Para implementar este ejercicio, también se

la Figura 2. De este modo, el usuario

hacia adelante. Luego, fue posible colocar un objeto virtual en reemplazo del

empleado.

Figura 2: Posicionamiento de pantalla y cámara para ejercicio de equilibrio.

3.3 Diseño de la aplicación

En esta sección se describe

explica en detalle la motivación y principios detrás de las decisiones de diseño.

3.3.1 Arquitectura de la aplicación

En general, las dinámicas que se deseaba implementar son m

por esto que se utilizó como inspiración la arquitectura básica del videojuego.

grandes rasgos, de componentes de entrada, lógica del juego, datos del juego y componentes

de salida.

23

a implementar este ejercicio, también se colocó la cámara de forma frontal, como en

, el usuario se puede visualizar a modo de espejo, con

hacia adelante. Luego, fue posible colocar un objeto virtual en reemplazo del

: Posicionamiento de pantalla y cámara para ejercicio de equilibrio.

de la aplicación

describe la arquitectura y estructura de la aplicación. También se

en detalle la motivación y principios detrás de las decisiones de diseño.

de la aplicación

En general, las dinámicas que se deseaba implementar son muy similares a videojuegos. Es

por esto que se utilizó como inspiración la arquitectura básica del videojuego.


colocó la cámara de forma frontal, como en

se puede visualizar a modo de espejo, con la vista recta

hacia adelante. Luego, fue posible colocar un objeto virtual en reemplazo del objeto de apoyo

: Posicionamiento de pantalla y cámara para ejercicio de equilibrio.

estructura de la aplicación. También se

en detalle la motivación y principios detrás de las decisiones de diseño.

uy similares a videojuegos. Es

por esto que se utilizó como inspiración la arquitectura básica del videojuego. Esta consiste, a


24

Figura 3: Arquitectura de juego básica

Si bien es una arquitectura simplificada, escala fácilmente, puesto que sus partes pueden

ser subdivididas según sea necesario. Por ejemplo, el output podría ser subdividido en sonido y

rendering, si la complejidad lo ameritara. Si se deseara añadir conectividad (i.e. conexión a

internet u otras redes), se podría anexar un módulo de conectividad. Sin embargo, la

arquitectura descrita es suficiente para ejecutar de forma satisfactoria el game loop (ciclo del

juego) básico [13], como descrito en la Figura 4.

Figura 4: El game loop básico.

3.3.1.1 Entrada

Aquí se pueden encontrar los componentes de software que se encargan de procesar la

información entregada por los dispositivos de entrada. Entre estos encontraremos las clases

encargadas de extraer y convertir las imágenes provenientes de la videocámara, en input

procesable. Es decir, todo aquello relacionado con la detección de movimiento.

25

La existencia de este módulo permite considerar la inclusión de otros dispositivos de

entrada en el futuro. Esto otorga flexibilidad y extensibilidad a la aplicación.

3.3.1.2 Datos del Juego

Este módulo se encarga del almacenamiento y carga de los datos del juego. Los datos del

juego pueden corresponder a parámetros de configuración del juego, como también a

estadísticas del desempeño del usuario en las dinámicas. Los recursos del juego (imágenes,

modelos 3d, etc) también se consideran datos del juego.

3.3.1.3 Lógica del juego

Aquí se encuentran los componentes de software que procesan y generan las interacciones

que conforman las dinámicas implementadas. Corresponde, en cierto modo, al núcleo de la

aplicación.

Este núcleo está encargado de realizar los cálculos relacionados con las reglas del juego o

dinámica. También se encarga de actualizar las variables de los objetos virtuales automatizados,

generalmente conocido como IA (inteligencia artificial) en el ámbito de los videojuegos. No

necesariamente involucra algoritmos de la rama de inteligencia artificial de las ciencias de la

computación. Entre sus labores también se encuentra cálculos de física de la dinámica y la

simulación.

3.3.1.4 Salida

En este módulo se pueden encontrar las clases encargadas de controlar los dispositivos de

salida. Como, por ejemplo, librerías de sonido y de rendering. También si se incluyesen

dispositivos que entreguen feedback háptico, las librerías que los controlan serían parte de este

módulo.

26

3.3.2 Estructura de la aplicación

En esta sección se describen los patrones empleados y decisiones relevantes, en el

diseño de la estructura de la aplicación. También se detallan las intenciones que motivaron cada

elección de diseño.

3.3.2.1 Adapter sobre conector de cámara web

Dado que se sabía que se utilizaría una clase para captura de video desde cámara web de

terceros, se utilizó un “Adapter” para esta clase externa. Esto se debe a que se deseaba una

interfaz que facilitara su inserción en el ciclo de la aplicación (game loop). Esta interfaz está

definida en la clase “WebcamWrapper”, la cual usa a la clase “WebcamConnector”, que

representa a la clase externa.

Figura 5: Adapter sobre clase de captura de video.

3.3.2.2 Mediator para manejo de pantallas

En la aplicación existen distintas “pantallas”, las cuales pueden definirse como contextos

independientes que se presentan al usuario, a lo largo de la ejecución del programa. Por

ejemplo, al iniciar la aplicación existe una pantalla para elegir la dinámica a seguir. A su vez,

27

cada dinámica consta de una pantalla. Estas pantallas son representadas por la clase

“GameScreen”.

Durante la ejecución de la aplicación, las pantallas van cediendo paso a otras pantallas.

Sin embargo, existen recursos compartidos entre estas pantallas, de las que todas (o casi todas)

hacen uso. El primero de estos es “InputState”, que representa un estado temporal del input del

usuario. A veces, pueden encontrarse sobrepuestas dos o más pantallas, pero solamente una

pantalla a la vez debe procesar el input. Es por esto que es necesario saber cuál de estas

pantallas es la que tiene acceso al input.

“GameSettings” representa los parámetros de configuración de la aplicación. Existen

pantallas que muestran y modifican estos parámetros. También las pantallas requieren acceso a

las imágenes capturadas por el “WebcamWrapper”. A su vez, WebcamWrapper necesita saber

datos de configuración existentes en GameSettings.

Debido a la red de interacción entre estos objetos, se opta por emplear un administrador

de pantallas, representado por “ScreenManager”. Este administrador no sólo controla la

interacción entre pantallas, sino que además sirve de “Mediator” entre las clases. De esta

forma, se disminuye el acoplamiento entre las clases, como se muestra en la Figura 6.

Figura 6: Mediator entre pantallas de la aplicación y sus recursos compartidos

28

3.3.2.3 Strategy para elección de algoritmo de detección de movimiento

Dado que no todas las dinámicas emplean el mismo algoritmo de detección de

movimiento, se empleó el patrón Strategy. Este patrón de diseño, permite elegir el algoritmo de

detección de movimiento de forma dinámica, en tiempo de ejecución.

Figura 7 Uso de patrón Strategy para algortimos de detección de movimiento

3.3.2.4 Template Method para pantallas de juego

Dado que en cada pantalla se debe implementar el game loop (ver Figura 4), se definió

una interfaz acorde al cumplimiento del game loop, empleando el patrón Template Method. De

este modo, cada pantalla, o GameScreen, puede sobreescribir los métodos para implementar su

propia lógica. Al cargar la pantalla, se ejecuta LoadContent(). Luego, se inicia el loop, y cada

pantalla ejecuta HandleInput(), Update() y Draw() en cada iteración. HandleInput() sólo se

ejecuta si la pantalla es actualmente la encargada de controlar el input de usuario. Antes de

finalizar la aplicación, o al cambiar de pantalla, se ejecuta UnloadContent() en la pantalla a

punto de ser desactivada.

29

Figura 8: Template method para pantallas de juego

3.3.2.5 Menúes de opciones

A fin de poder realizar configuración, o seleccionar entre alternativas, se optó por

incorporar pantallas con menú. Muchas veces, un menú puede llevar a otro menú, por lo que

para navegar entre ellos, es necesario generar una estructura de árbol. Es por esto que se

empleó la composición recursiva, de forma similar a como se usa en el patrón Composite. Así,

una pantalla de menú mantiene una referencia a su “padre”, lo que permite regresar al menú

anterior. Cuando ya no tiene otro padre, se puede mantener una referencia nula.

Figura 9: Composición recursiva en pantallas de menú, para lograr estructura de árbol

30

3.3.2.6 Carga y almacenamiento de parámetros de configuración

Para almacenar y cargar los parámetros de configuración de la aplicación, se creó una

clase aparte, “GameSettings”. Estos parámetros son utilizados por varias clases, mediadas por

“ScreenManager”. Dado que es necesario que los valores de los parámetros persistan entre

cada ejecución, estos se deben guardar en un archivo, y cargar al principio de cada ejecución.

Estas variables podrían haber sido incluidas en el ScreenManager, sin embargo, se empleó el

concepto del patrón de diseño “Private Class Data”, el cual involucra extraer variables a una

clase aparte. De este modo, se desacopla el almacenamiento y carga de los parámetros.

Figura 10: Uso de patrón “prívate class data”, para parámetros de configuración

31

4 Implementación

En esta sección se describe el proceso de implementar la aplicación diseñada. Se parte por

la elección de las herramientas y ambiente de desarrollo. Luego se describe el desarrollo de la

aplicación, implementando las dinámicas anteriormente descritas.

4.1 Elección de plataforma objetivo

Para la elección de la plataforma objetivo, se analizó distintas opciones de sistema

operativo, lenguaje de programación y frameworks de desarrollo. En cuanto a sistema

operativo, se consideró Windows, Linux y Mac OS. En cuanto a lenguajes de programación, se

consideró lenguajes de alto nivel, orientados a objetos, que contaran con bindings a librerías

para procesamiento de gráficos. Entre estos lenguajes, se consideró C++, C#, Java y ActionScript.

Los frameworks disponibles son generalmente distintos para cada lenguaje, por lo que se eligió

entre frameworks disponibles de forma posterior a la elección del lenguaje.

4.1.1 Elección de sistema operativo

En la elección de sistema operativo, influyó mucho que los usuarios objetivos no fueran

usuarios especializados en computación. Esto, debido que la mayoría de los usuarios no

especializados, posee o tiene acceso ya a computadores con Windows. Linux, pese a ser gratis,

no es familiar para la mayoría de los usuarios finales. En cuanto a Mac OS, también se descartó

debido a que es mucho menos masivo que Windows, requiriendo además hardware Mac para

correr, que es en general más costoso.

4.1.2 Elección del lenguaje de programación

La elección del lenguaje de programación radicó en un conjunto de factores. A considerar

entre ellos, que tan fácil resulta su uso, su performance y la disponibilidad de librerías y

ambientes de desarrollo. Se consideró los lenguajes Java, C++, C#, Python y ActionScript.

Java es un lenguaje de alto nivel, y orientado a objetos. Posee gran cantidad de librerías, y

además bindings para OpenGL. Sin embargo, al correr en una máquina virtual, no tiene tan buen

32

performance como C# o C++. Existen varios ambientes de desarrollo integrados (más conocidos

por sus siglas en inglés: IDE) para trabajar en Java, como Eclipse y NetBeans. Sin embargo, su

integración con webcams requiere de la instalación de programas adicionales, dado que no

tiene acceso nativo a ella. Pero, cuenta a su favor el ser portable a distintos sistemas operativos.

C++ es un lenguaje de mediano nivel – más alto nivel que C, pero más bajo que Java.

Permite también el uso de la orientación a objetos. Posee, al igual que Java, bindings para

OpenGL. Además posee bindings para Direct3D. Posee mejor performance que Java, al ser

compilado y correr directamente en el sistema operativo, sin necesidad de virtualización. Posee

también varios IDE, entre ellos Visual Studio. Dado que la plataforma objetivo es Windows, es

importante mencionar que C++ puede hacer uso de las librerías del framework .NET de

Microsoft®. Sin embargo, a veces resulta difícil implementar utilizando C++, debido a la

necesidad de manejar de forma manual la memoria, y la manipulación explícita de punteros y

referencias.

C# es un lenguaje de alto nivel, muy similar a Java. Se podría considerar menos portable

que C++ o Java, dado que en general se emplea sólo en Windows, utilizando el framework .NET.

Es conocido que C# posee mejor performance que Java, pero peor performance que C++ en

general. Sin embargo, posee un balance entre facilidad de uso y performance. Además, posee

gran cantidad de librerías de procesamiento de imágenes, e integra con facilidad captura de

imágenes desde una cámara web. También existe la posibilidad de usar las librerías de XNA,

framework de Microsoft® orientado al desarrollo de juegos.

ActionScript es un lenguaje orientado a objetos. Es también compilado, a partir de su

tercera versión. Nace como parte de Adobe® Flash®, por lo cual permite usar las herramientas

gráficas de Flash® para sus interfaces de usuario. Se integra de manera muy simple con la

cámara web, dado que posee librerías nativas para interactuar con ellas. Desgraciadamente no

posee tantas librerías como C#. Tampoco su performance es muy bueno, dado que está

enfocado a correr embebido en browsers.

33

Finalmente se optó por desarrollar utilizando C#, debido a su performance aceptable, gran

cantidad de librerías disponibles y facilidad de uso. Además que permite hacer uso .NET y XNA,

que facilitan el desarrollo de una interfaz de usuario y manipulación de objetos gráficos

bidimensionales y tridimensionales.

4.2 Ambiente de desarrollo

Tras la elección de plataforma objetivo y lenguaje de programación, se eligió el ambiente de

desarrollo. Dado que la plataforma escogida fue Windows® y el lenguaje escogido fue C#, se

optó por usar VisualStudio® 2008 como IDE. Esto permitiría la integración simple con las

librerías de .NET, y XNA. Las librerías más relevantes utilizadas serán descritas a continuación.

4.2.1 XNA

XNA es un framework de Microsoft®, orientado al desarrollo de juegos para Windows® y

Xbox® [14]. Agrupa librerías que permiten manejar de manera más fácil gráficos y dispositivos

de entrada, que DirectX®. Está basado en DirectX®, por lo que se tiene acceso también a las

funciones de más bajo nivel en caso de ser necesario, pero presenta una capa de abstracción,

automatizando y simplificando ciertas funciones típicamente presentes en el desarrollo de

juegos.

Se utilizó este framework como base del desarrollo, dado que facilitó la implementación

de la interfaz gráfica. Además permitió manejar elementos gráficos con mayor facilidad.

4.2.2 AForge

AForge es un framework de C#, que contiene librerías de utilidad para manipulación de

imágenes y video [15]. Permitió implementar algunos algoritmos de detección de movimiento

en un principio. Sin embargo, más adelante se supo de la existencia de EmguCV, que agrupaba

librerías similares y además poseía funciones de detección de movimiento implementadas.

34

4.2.3 EmguCV

EmguCV es un wrapper de OpenCV para el framework .NET [16]. Agrupa funciones de

manipulación de imágenes, así como de detección de movimiento. Poseía algoritmos ya

implementados, como Lucas-Kanade [17], Lukas-Kanade piramidal [18], y Horn-Schunck [19].

Además poseía reconocimiento de patrones, mediante clasificadores tipo Haar.

4.3 Aplicación de prueba

Previo a la implementación de las dinámicas descritas, se realizó una aplicación de prueba.

El objetivo de esta aplicación de prueba, era probar las capacidades de un algoritmo básico de

detección de movimiento. Además, permitió acostumbrarse al entorno y herramientas de

desarrollo.

La aplicación desarrollada consistió en lo siguiente:

• Emplear y adaptar una librería de videocaptura mediante webcam.

• Implementar un algoritmo de detección de movimiento básico.

• Emplear la detección de movimiento para interactuar con un objeto virtual.

El código utilizado para videocaptura fue adaptado de un ejemplo que utilizaba la librería

DirectShow .NET [20], para videocaptura en el framework XNA [21]. Se utilizó debido a que

realizaba la videocaptura de forma muy cercana a como se deseaba implementar, y a que

permitía versatilidad en el manejo de las imágenes obtenidas.

El algoritmo empleado fue un sencillo mapa binario, en que existían pixeles con

movimiento y pixeles sin movimiento. Este se generó mediante una diferencia entre fotogramas

consecutivos, lo que genera un mapa de valores entre 0 y 255. Aplicándole un threshold al mapa

de valores, se obtiene el mapa binario.

35

Figura 11: Izq.: imagen en tiempo real. Der.: mapa binario generado por diferencia de fotogramas consecutivos.

Para la interacción, se creó un objeto virtual ubicado inicialmente en el centro de la

pantalla. Este objeto constantemente consultaba el segmento del mapa de bits sobre el que se

encontraba. Si existía movimiento al interior del objeto, este cambiaba de color. Luego,

mediante un cálculo simple, se determinaba hacia cual sector debía moverse el objeto, para

centrarse en el movimiento. De este modo, el objeto seguía el movimiento, con cierta tendencia

a moverse a lo largo de los bordes. Esto, debido a que el movimiento por diferencia de

imágenes consecutivas genera mapas como los de la Figura 11.

Figura 12: Aplicación de prueba en ejecución

4.4 Almacenamiento de configuración

Para realizar el almacenamiento de la configuración, se empleó serialización de la clase

GameSettings. Al finalizar la aplicación, se crea un archivo que contiene los atributos de una

instancia esta clase, serializados. Al iniciar la aplicación, se deserializa el archivo y se inicializa

una instancia de esta clase, con los valores almacenados. En caso de no existir el archivo, se

inicializa con valores por defecto.

36

4.5 Algoritmos implementados

Dado que el algoritmo inicial no permite implementar las dinámicas con facilidad, se

buscó alternativas. Se partió por implementar los métodos más comunes de detección de

movimiento. Luego, se buscó alternativas más complejas.

4.5.1 Algoritmos basados en sustracción de imágenes

4.5.1.1 Sustracción de fondo fijo

Este algoritmo consiste en sustraer siempre el fotograma más reciente, con un

fotograma de fondo previamente elegido. Esto permite, a diferencia de la sustracción de los dos

fotogramas más recientes, obtener no tan sólo contornos, sino que objetos con relleno sólido.

Sin embargo, al implementar el algoritmo, se pudo apreciar que es muy susceptible a los

cambios en iluminación. Dado que las cámaras web comunes tienen cambios bruscos en las

condiciones de iluminación, la imagen elegida como fondo queda inutilizada después de un

periodo muy breve. También ocurre que las sombras proyectadas sobre el fondo son detectadas

como objetos en movimiento.

Figura 13: Sombra detectada como movimiento en sustracción de fondo fijo.

Además es necesario que primero el usuario se encuentre fuera del rango de visión de la

cámara, hasta que esta elija un fotograma de fondo. Si bien no es un impedimento, agrega una

limitante más al uso de la aplicación. Debido a todo lo anterior, se determinó que este método

no es apto para el fin que se desea dar a la aplicación.

37

4.5.1.2 Substracción de fondo dinámico

Una mejora al algoritmo anterior, consiste en ir variando de forma progresiva la imagen

de fondo. Existen varias formas de hacer esto, pero se optó por una de las más sencillas. Esta

consiste en ponderar el fotograma actual en cierta proporción con la imagen de fondo, a fin de

conseguir una nueva imagen fondo.

Al experimentar con este método, se obtuvo resultados obtenidos muy similares al del

primer método. Se implementó con distintas ponderaciones, resultando la más satisfactoria una

ponderación del fondo de 99% y ponderación del fotograma actual del 1%. Al aumentar la

ponderación del fondo, se obtienen resultados más similares al de la sustracción de fondo fijo.

Si, por el contrario, se aumenta la ponderación del último fotograma, se asemeja más a la

diferencia de los dos últimos fotogramas.

La ventaja respecto a la sustracción de fondo fijo, es que se adapta bien a los cambios en

iluminación. Sin embargo, tiene un leve efecto de “fantasmas”, que se manifiesta como puntos

en que ya no se encuentran objetos ajenos al fondo, pero se detecta movimiento (falso-

positivo). También presenta la desventaja de que los objetos que no presentan movimiento,

pasan a formar parte del fondo después de cierto tiempo. Por todo lo anteriormente descrito,

también se descartó usar este algoritmo.

4.5.1.3 Otros algoritmos investigados

Se investigó sobre otros algoritmos basados en la sustracción de imágenes, que no se

llegó a implementar. La razón por la cual no se llegaron a implementar, es debido a que se

prefirió investigar los algoritmos basados en flujo óptico, los cuales presentaban mayor

potencial para los objetivos propuestos.

Los algoritmos estudiados, fueron principalmente dos. Ambos aprovechaban la detección

de bordes de Canny [22], para generar polígonos o polilíneas que representen objetos en

movimiento. El primero, “An Edge-Based Approach to Motion Detection” [23], utiliza una

cantidad variable de los últimos fotogramas para extraer contornos de objetos en movimiento,

38

mediante sucesivas sustracciones, adiciones y detección de bordes. El segundo, “Reference

Independent Moving Object Detection: An Edge Segment Based Approach” [24], emplea los tres

últimos fotogramas. A partir de estos, genera dos mapas de bordes, usando sustracción y

detección de bordes. A partir de los mapas de bordes, genera representaciones en base a

segementos de bordes para cada mapa. Finalmente, genera un mapa de distancias a partir de

un conjunto de segmentos, y luego realiza un matching con el otro conjunto.

4.5.2 Algoritmos basados en flujo óptico

Eventualmente se optó por investigar sobre algoritmos basados en flujo óptico. Varios

de estos algoritmos poseían implementaciones en la librería OpenCV, por lo que se decidió

adoptar el uso de EmguCV [16], wrapper en C# .NET, para OpenCV. Los algoritmos que se

encontraban implementados son: Lucas-Kanade [17], Horn-Schunck [19] y Lucas-Kanade

piramidal [18].

4.5.2.1 Skeletal tracking con Lucas-Kanade piramidal

La implementación piramidal de Lucas-Kanade, consiste, a grandes rasgos, en aplicar el

algoritmo de Lucas Kanade de forma iterativa, sobre segmentos de imagen más pequeños en

cada nivel. Es decir, se aplica el algoritmo sobre la imagen completa para cada punto, luego

sobre un segmento más pequeño, y así suscesivamente. Esto permite rastrear la posición de un

punto, de un fotograma a otro. De este modo, podemos elegir cierta cantidad de puntos, y

rastrear su movimiento aplicando Lucas-Kanade piramidal.

Surgió la idea, entonces, de implementar skeletal tracking, empleando este algoritmo.

Skeletal tracking consiste en elegir cierta cantidad de puntos para modelar un esqueleto

articulado humano, para luego rastrear su movimiento a lo largo del tiempo. De este modo, es

posible conocer la pose de un sujeto, proyectada al plano 2D.

Se escogió un modelo de esqueleto básico, basado en proporciones reales humanas, a fin

de realizar una implementación de prueba. Posteriormente, se debió resolver como inicializar el

tracking, dado que este debe corresponder a la posición real del sujeto. Se optó, con fines

39

prácticos, por hacer que el sujeto primero se colocara en una posición preestablecida, para

posteriormente inicializar el tracking. Evidentemente, en una situación con usuarios reales, esto

sería incómodo y no siempre sería posible. Sin embargo, se consideró más importante la

simplicidad de la implementación, a fin de probar la factibilidad del tracking.

Figura 14: Posición inicial del modelo para tracking esqueletal

Para la implementación del algoritmo de Lucas-Kanade piramidal, se empleó la librería

EmguCV. Esta librería ya poseía una implementación de feature tracking que utilizaba Lucas-

Kanade piramidal, por ende sólo fue necesario implementar el modelo esqueletal, la

inicialización del tracking y configurar los parámetros necesarios.

Figura 15: Skeletal tracking durante el movimiento del usuario.

Los resultados, sin embargo, no fueron los esperados. Fue posible realizar el tracking

esqueletal, pero este no resultó ser lo suficientemente robusto. Los problemas encontrados

40

fueron múltiples, algunos de los cuales se debieron al algoritmo mismo usado para el tracking

de los puntos. Los problemas encontrados fueron los siguientes:

• Después de un tiempo, algunos puntos ya no seguían el movimiento del sujeto, y

se quedaban rastreando puntos correspondientes al fondo.

• Cualquier tipo de oclusión hacía fallar el tracking esqueletal. Por ejemplo, la

sobreposición de alguno de los puntos rastreados, la rotación del sujeto, etc.

• Movimientos muy rápidos del usuario hacían que el tracking fallara.

El primer problema del tracking se debe a que los puntos escogidos no siempre

correspondían a sectores fáciles de distinguir para el algoritmo. Esto provocaba que

eventualmente ese punto fuera confundido con otro punto similar, por ende haciendo fallar el

tracking.

Figura 16: Puntos extraviados en el skeletal tracking.

El segundo problema, la oclusión, corresponde a un problema habitual del tracking

esqueletal. Algunos autores han planteado modelos avanzados de esqueleto humano, y

algoritmos predictivos para estimar la posición de los puntos ocultos [25].

El tercer problema es propio del algoritmo empleado. Este no funciona para

desplazamientos muy grandes dentro de la imagen. Además, movimientos muy rápidos en una

41

cámara web convencional provocan la aparición de áreas borrosas. Esto último también dificulta

el tracking de los puntos.

Finalmente, el skeletal tracking no fue empleado para implementar las dinámicas

propuestas. A pesar de que hubiese sido posible resolver los problemas encontrados, hubiese

sido probable que el tiempo empleado en solucionarlos escapara el tiempo destinado a la

realización de la memoria.

4.6 Implementación de las dinámicas

A continuación se detalla el proceso de implementación de las dinámicas. Para cada

dinámica se explica las decisiones de implementación tomadas. También se describe

brevemente los algoritmos utilizados. Finalmente, se describen los problemas encontrados para

la implementación de cada dinámica, y la solución dada para aquellos que fueron resueltos.

4.6.1 Dinámica de pararse y sentarse

En esta sección se describe el proceso de implementación de la dinámica descrita en

3.2.1. Esta dinámica consiste en detectar cuando un usuario se encuentra de pie, cuando se

sienta, y cuanto demora en hacerlo. Para este propósito, se consideró utilizar algoritmos de

detección facial y de flujo óptico.

4.6.1.1 Clasificadores Haar para detección facial

Para realizar la implementación de esta dinámica, fue necesario emplear clasificadores

en cascada con filtros de base Haar, también conocidos tan solo como clasificadores Haar. Estos

clasificadores permitieron realizar detección facial.

La librería EmguCV ya poseía una implementación de clasificadores Haar, basada en [26].

Básicamente, se elige un conjunto de características distintivas del objeto a detectar,

generalmente zonas donde el contraste es alto. Estas características pueden ser muchas. Luego,

se entrena al algoritmo clasificador con imágenes del objeto que se desea detectar (e.g. caras).

42

Figura 17: Ejemplo de características para detección de caras. Extraído de [26].

El clasificador entrenado, consiste de una cascada de clasificadores que pueden rechazar

la “ventana”, o segmento de imagen, o bien traspasarla al siguiente clasificador. Además, el

clasificador entrenado sólo emplea un subconjunto del total de características, generalmente

bastante acotado.

Figura 18: Diagrama de estados de clasificador en cascada. Extraído de [26].

Debido a que EmguCV ya proveía clasificadores entrenados para detección facial, no fue

necesario generar un conjunto de imágenes de entrenamiento. Esto involucró un ahorro

significativo de tiempo, dado que recolectar una cantidad de imágenes, tal que sea útil (entre

mil y cinco mil) requiere de una cantidad de tiempo no despreciable. Además, preparar las

imágenes y realizar el entrenamiento demora alrededor de una semana.

4.6.1.2 Good features to track

El algoritmo de Shi y Tomasi [27], propone una forma de elegir buenas características

para tracking. Los puntos, elegidos por “good features to track”, tienden a ser mejor

diferenciados por los algoritmos de tracking, como Lucas-Kanade piramidal.

43

EmguCV ya posee una implementación basada en este algoritmo. A grandes rasgos, la

implementación calcula los valores propios de la matriz de covarianza para cada pixel. Luego

realiza supresión no máxima, para finalmente filtrar y entregar los puntos cuyos valores propios

sean menores que cierto nivel (i.e. cuya calidad sea mayor a cierto valor).

4.6.1.3 Implementación

Para la implementación de la dinámica, se optó por hacer seguimiento de la posición de

la cabeza del usuario. De este modo, se podría determinar si el usuario se encuentra sentado,

de pie, poniéndose de pie o sentándose; mediante la posición y velocidad de la cabeza.

Para la inicialización de la detección de movimiento, se considera que el usuario se

encontrará sentado. Esto debido a que como sólo se detecta la cara, no es posible saber de

manera automatizada si se encuentra de pie o sentado.

Ya sentado el usuario, se parte por detectar su cara, utilizando detección facial mediante

clasificadores Haar. Luego, una vez detectada su cara, se recorta el rectángulo facial. Al interior

de este rectángulo, se aplica el algoritmo de Tomasi, a fin de obtener un conjunto de puntos

que sirvan para hacer tracking mediante Lucas-Kanade piramidal. Luego, se puede saber la

velocidad y posición de la cabeza del usuario, a través del conjunto de puntos. Actualmente, se

calcula la velocidad mediante un promedio simple de la velocidad de todos los puntos. Sin

embargo, se podría hacer optimizaciones, como, por ejemplo, excluir puntos que dejen de

rastrear el movimiento de la cara.

La razón de emplear Lucas-Kanade piramidal en vez de los clasificadores Haar para hacer

seguimiento facial, se debe a la baja tolerancia de los clasificadores a la rotación o inclinación de

la cara. Es decir, que al utilizar solamente clasificadores de Haar para el seguimiento facial,

algunas veces la cara dejaba de ser detectada. Esto provocaba que el seguimiento facial fuera

intermitente. Por ende, la combinación de ambos algoritmos otorga robustez al seguimiento

facial.

44

4.6.1.4 Interfaz de usuario

Se elaboró una interfaz sencilla, que permitiera al usuario poder interactuar

adecuadamente, a fin de ejecutar correctamente la dinámica. No se elaboró una interfaz más

compleja, a fin de acotar el desarrollo a la detección de los movimientos del usuario y ejecución

de la dinámica.

Esta interfaz consiste principalmente de la imagen en tiempo real, proveniente de la

cámara web. Esta ocupa todo el fondo de la ventana, y se presenta invertida, a modo de espejo,

a fin de que resulte intuitivo para el usuario observar sus movimientos.

En la esquina superior izquierda se posicionó un ícono que permite al usuario saber que

la aplicación está interpretando correctamente sus movimientos. Este indica si el usuario se

encuentra de pie, en acción de sentarse, sentado o en acción de ponerse de pie. La iconografía

se puede apreciar en la Figura 19.

Figura 19: Iconos empleados para dinámica de pararse y sentarse.

A la derecha, se muestran los tiempos que el usuario ha empleado en pararse y sentarse

en cada iteración. Al final de la lista se muestra el tiempo que el usuario está demorando en

sentarse o pararse, en la iteración actual, a modo de cronómetro.

4.6.1.5 Observaciones durante pruebas con usuarios finales

Primeramente, la dinámica implementada fue probada con gente que no se encontraba

en terapia de rehabilitación, a fin de eliminar problemas evidentes y establecer parámetros

adecuados. Tras la corrección de estos primeros errores, fue probada con un grupo de gente en

45

rehabilitación, usuarios finales de la aplicación, a fin de encontrar errores y recabar sugerencias

para su mejora.

Un problema encontrado al realizar las primeras pruebas con usuarios finales, estaba

relacionado con la inicialización de la detección. En un principio se había planteado partir con un

usuario de pie. Sin embargo, la mayoría de los usuarios, al sentarse por primera vez, miraban

hacia el asiento. El acto de estar de pie y girar la cabeza para mirar el asiento, provocaba que a

veces se viera afectado el seguimiento facial, debido a que los puntos rastreados se

concentraban en un solo lado de la cara, o se trasladaban al fondo de la imagen. Esto no ocurría

cuando ellos partían la dinámica sentados, en la mayoría de los casos. Al partir sentados, tras

pararse volvían a sentarse, sin mirar el asiento. Por esto mismo, se cambió la posición inicial del

usuario a estar sentado, lo que resultó en una detección más robusta.

Una observación hecha por los terapeutas durante las pruebas, fue sobre la posibilidad

de detectar malas posturas, al ejecutar la dinámica. Es importante que el usuario realice el

ejercicio con una postura adecuada, a fin de que el reforzamiento sea más provechoso. Sin

embargo, resulta difícil detectar problemas en la postura del usuario, utilizando una

implementación piramidal de Lukas-Kanade. Se sugirió también incorporar guías visuales (e.g.

líneas verticales) para ayudar al usuario a mantener una postura erguida.

En general, la implementación permitió una correcta ejecución de la dinámica descrita.

Los usuarios interactuaron con la aplicación, siguiendo las instrucciones de forma adecuada.

Existieron algunas ocasiones en que falló el seguimiento de los movimientos del usuario, por lo

que fue necesario detener la dinámica y volver a calibrar. Pero, fueron ocasiones aisladas y no

interrumpieron de forma significativa la realización del ejercicio.

4.6.2 Dinámica de equilibrio

En esta sección se describe el proceso de implementación de la dinámica descrita en

3.2.2. Esta dinámica consiste en presentar a un usuario un objeto virtual “frágil”, a fin de que el

usuario ponga su pie encima, pero sin aplastarlo. Para este propósito, se consideró utilizar un

46

algoritmo de flujo óptico, para detectar el flujo encima del objeto. Finalmente, se utilizó un

algoritmo de flujo óptico para feature tracking, en vez de uno para generar un mapa de flujo.

4.6.2.1 Lucas-Kanade vs Horn-Schunck

Debido a que EmguCV ya poseía implementaciones para dos algoritmos de flujo óptico,

Lucas-Kanade y Horn-Schunck, fue posible experimentar con ambos. Se explicará de forma

resumida como funciona cada algoritmo, para poder compararlos. Sin embargo, puede referirse

a los papers en que fueron publicados los algoritmos de Lucas-Kanade [17] y Horn-Schunck [19]

para más detalle.

Lucas-Kanade permite obtener el flujo de una zona rectangular de pixeles. Se puede,

entonces, dividir una imagen en partes iguales y aplicar el algoritmo sobre cada zona, a fin de

obtener un gradiente de flujo. Debido a esto, es que se clasifica este algoritmo como local, ya

que calcula el flujo solamente considerando restricciones de las zonas donde se aplica.

Horn-Schunck, en cambio, permite obtener un valor para cada pixel, manteniendo la

suavidad de toda la imagen como restricción. Es por esto que se clasifica como un algoritmo

global.

En general, los algoritmos de flujo óptico locales presentan mejor desempeño en

secuencias de imágenes con presencia de ruido. Mientras que algoritmos globales presentan

mejor desempeño en ausencia de ruido. [28]

Se experimentó entonces, para determinar cual algoritmo presentaba un desempeño

más adecuado para el propósito de implementar la dinámica. La cámara web utilizada para el

experimento presentaba imágenes con cierta cantidad de ruido. Esto se consideró

representativo de una cámara web común. El resultado fue poco concluyente, resultando el

algoritmo de Lucas-Kanade levemente mejor. Por ende, se concluyó que era poco relevante el

algoritmo escogido, y se optó por Lucas-Kanade debido a la leve diferencia y a que

teróricamente debiese tener mejor desempeño en imágenes con ruido.

47

4.6.2.2 Implementación

Para la implementación, se presentó al usuario un objeto virtual, que en este caso

resultó ser de forma ovoide. Si el usuario pisa el objeto virtual, este se aplasta. De esta forma, el

objeto entrega feedback visual, en respuesta a los movimientos del pie del usuario.

En la implementación inicial, se utilizó el algoritmo de Lucas-Kanade. Se calculó el flujo

óptico cerca del borde superior del objeto. Si la velocidad en dirección vertical inferior supera

cierto valor, entonces se “aplasta” el objeto. Si la velocidad en dirección vertical superior supera

cierto valor, entonces se realiza la acción contraria. Cuando el aplastamiento alcanza el límite,

entonces se termina la dinámica.

Por desgracia, esta solución no pudo ser implementada con la suficiente robustez como

para ser probada con usuarios finales. Es por esto que se cambió de estrategia de detección de

movimiento.

Finalmente se adaptó la solución implementada, para utilizar feature-tracking, mediante

Lucas-Kanade piramidal. De esta forma, primero el usuario debe permanecer con ambos pies en

el suelo. Luego, se eligen los puntos a rastrear, mediante el algoritmo de Tomasi, en la zona

donde el usuario pone los pies. Debido a que se pueden elegir puntos que no pertenezcan al pie

del usuario, el usuario debe primeramente levantar el pie con el cual realizará la dinámica. De

esta forma, se puede descartar los puntos que no presentaron un movimiento ascendente.

Luego, se detecta cuando el pie está a su máxima altura, que es cuando su velocidad baja de

cierto umbral. Luego de esto, se coloca el objeto debajo del pie del usuario.

4.6.2.3 Interfaz de usuario

Al igual que para la dinámica anterior, se desarrolló una interfaz simple. El objetivo era

permitir la interacción adecuada del usuario, y la entrega del feedback necesario.

Al igual que la dinámica anterior, se presenta en el fondo la imagen en tiempo real

provista por la cámara, a modo de espejo. Encima de esto, se presentan las instrucciones para la

ejecución de la aplicación, en forma de texto. Luego se sobrepone un objeto con aspecto de

huevo, el cual posee distinta representación, dependiendo de cuan aplastado se encuentre (ver

Figura 20). Además, se deforma acorde al movimiento del pie del usuario.

Figura 20

Cuando el usuario deforma el huevo más allá del límite, este se rompe.

presenta al usuario el tiempo que logró mantener el equilibrio, mediante texto.

4.6.2.4 Observaciones durante pruebas con usuarios finales

Al igual que la dinámica anterior, esta fue probada de forma preliminar con usuarios no

finales. Posterior a la primera fase de corrección de errores, se probó con usuarios finales, y se

recabó las observaciones de los terapeutas.

La detección de movimiento resultó poco robusta, cuando se realizaba la dinámica sobre

superficies muy texturizadas. Por ejemplo, sobr

de estilo “aleopardado”, o texturas similares, la detección de movimiento fallaba muy rápido.

También en condiciones de baja iluminación fallaba la detección de movimiento.

Afortunadamente, estos dos problemas

manta de color uniforme en el piso e iluminar mejor la zona.

Una de las mejoras sugeridas por los terapeutas fue el mostrar guías verticales (i.e. líneas

dibujadas de forma vertical) que ayudaran al us

También sugirieron desplegar los tiempos registrados para el usuario en iteraciones anteriores,

en vez de tan solo el tiempo en la iteración actual. Se argumentó que esto produciría un efecto

positivo en el usuario, ya que podría observar su progreso.

48



). Además, se deforma acorde al movimiento del pie del usuario.

20: Estados del huevo virtual, para dinámica de equilibrio

Cuando el usuario deforma el huevo más allá del límite, este se rompe.


Observaciones durante pruebas con usuarios finales


a primera fase de corrección de errores, se probó con usuarios finales, y se

recabó las observaciones de los terapeutas.


superficies muy texturizadas. Por ejemplo, sobre alfombras con diseños que presentan manchas



Afortunadamente, estos dos problemas son fácilmente solucionables, ya que basta colocar una

manta de color uniforme en el piso e iluminar mejor la zona.


dibujadas de forma vertical) que ayudaran al usuario a alinearse para mantener el equilibrio.



uario, ya que podría observar su progreso.



Cuando el usuario deforma el huevo más allá del límite, este se rompe. Tras esto, se



a primera fase de corrección de errores, se probó con usuarios finales, y se


e alfombras con diseños que presentan manchas



son fácilmente solucionables, ya que basta colocar una


uario a alinearse para mantener el equilibrio.



49

Se obtuvo varias observaciones positivas respecto a la implementación de la dinámica:

• El objetivo de la dinámica es fácil de entender, y la interacción es intuitiva. Esto permitió

que incluso usuarios de la tercera edad, generalmente poco acostumbrados al uso de

nuevas tecnologías, participaran sin complicaciones.

• La dinámica adquiere un carácter lúdico, al presentar al usuario con un huevo animado.

De este modo, el ejercicio divierte y motiva al usuario.

• La interfaz, pese a ser simple, permitía interactuar de forma adecuada.

En general, existen detalles que pueden ser perfeccionados. Sin embargo, la

implementación permite ejecutar adecuadamente la dinámica.

Figura 21: Usuario en terapia de rehabilitación, haciendo uso de la aplicación

50

5 Conclusiones

5.1 Conclusiones generales

Durante el proyecto de memoria, se desarrolló una aplicación que permite al usuario

realizar dos dinámicas kinesiológicas de refuerzo a la terapia de neurorrehabilitación. En esta

aplicación, el usuario puede interactuar mediante el uso de movimientos corporales. Estos

movimientos son detectados mediante procesamiento de imágenes capturadas a través de una

cámara web genérica.

La aplicación se diseñó utilizando un paradigma de programación orientada a objetos, y

una arquitectura típica de videojuego. Además, se empleó patrones de diseño, con la finalidad

de hacer una aplicación extensible y mantenible. Estas consideraciones permitirán desarrollos

futuros sobre la aplicación, para su optimización e integración con otras tecnologías de interés.

Para su implementación se hizo uso de librerías ampliamente utilizadas, documentadas y

de código abierto. También se emplearon algoritmos de detección de movimiento publicados.

Esto también permite flexibilidad para la futura extensión y comprensión de la aplicación

desarrollada.

La aplicación desarrollada es un prototipo plenamente funcional. Es decir, permite al

usuario realizar las dinámicas de forma satisfactoria, pero requiere mejoras a fin de poder ser

distribuido como producto. Su desarrollo muestra que es posible desarrollar soluciones

tecnológicas de bajo costo para neurorrehabilitación. Si bien, la detección de movimiento

mediante cámara web presenta limitantes en comparación con soluciones de costo mayor, su

bajo costo facilita el acceso al usuario a reforzamiento de la terapia en el hogar, lo cual daría

mayor continuidad al proceso de rehabilitación.

51

5.2 Cumplimiento de objetivos

Se cumplió el objetivo general de elaborar una aplicación que asista al terapeuta durante

una sesión de rehabilitación. La aplicación desarrollada consta de dos dinámicas, que incentivan

al usuario a realizar ejercicios de terapia física.

5.2.1 Detectar el movimiento de un usuario

Se investigó e implementó una diversidad de algoritmos de detección de movimiento. Estos

se emplearon de forma exitosa con el fin de detectar el movimiento de un usuario

5.2.2 Implementar dinámicas basadas en rutinas de ejercicios usados en

rehabilitación

Se diseñó dinámicas basadas en rutinas de ejercicios existentes en rehabilitación. Se

implementó de forma exitosa estas dinámicas, permitiendo al usuario realizarlas mediante la

interacción con la aplicación desarrollada.

5.2.3 Generar indicadores que ayuden a cuantificar el progreso de un usuario

Cumplimiento parcial. En ambas dinámicas se utilizó el tiempo como métrica de la ejecución

del ejercicio. Además del tiempo, sería posible crear indicadores que permitan medir la calidad

de la ejecución de la dinámica. En la sección 5.3 se explica cómo se podría utilizar estas

métricas, a fin de ayudar al reforzamiento de la terapia en el hogar.

5.2.4 Diseñar una solución extensible

El uso de la orientación a objetos y patrones de diseño permitió desarrollar una aplicación

extensible. Es posible agregar fácilmente nuevas dinámicas, algoritmos de detección de

movimiento y distintas tecnologías.

52

5.2.5 Mantener en cuenta el futuro uso doméstico de la aplicación

Se desarrolló una aplicación para uso en ambiente controlado. Se tuvo en cuenta el futuro

uso doméstico de la aplicación, mediante la elección de tecnologías fáciles de obtener en el

hogar. Se eligió una cámara web de bajo costo. Se eligió como plataforma objetivo un

computador personal con sistema operativo Windows, que en la actualidad se puede encontrar

en la mayoría de los hogares.

También se tuvo en cuenta para el desarrollo de las interfaces. Si bien las interfaces son

simples y requieren mayor desarrollo para asegurar su usabilidad, son claras y permiten

interactuar de forma intuitiva con la aplicación.

5.3 Trabajo futuro

Existen varias formas en que se puede mejorar la aplicación desarrollada. Entre ellas,

optimizaciones y diseño de interfaces usables para el usuario objetivo. También es posible

mejorar la aplicación desarrollada mediante inclusión de nuevas tecnologías y algoritmos.

Algunos de estos caminos se consideraron de antemano, pero fue necesario acotar el alcance de

la aplicación a desarrollar, a fin de poder desarrollar la solución en el tiempo considerado para

el proyecto de memoria.

Se puede considerar las siguientes mejoras:

• Integración con Wiimote®: Si bien para este proyecto se descartó realizar ejercicios

que empleen el control remoto de la Wii®, es posible desarrollar ejercicios que lo

usen. El costo de la tecnología necesaria es igualmente bajo, comparable con una

cámara web genérica. También se podría considerar el integrarlo tan sólo como un

dispositivo de entrada más intuitivo y práctico, que el teclado y mouse. Los

beneficios provenientes de la integración del Wiimote® con la aplicación actual son

altos, en comparación con el costo adicional.

• Integración con Kinect®: En un principio, el objetivo fue desarrollar la aplicación

empleando el dispositivo Kinect®. Sin embargo, aún no existía una API oficial al

53

momento de evaluar las alternativas, razón por la cual se descartó para el proyecto

actual. Cerca del final del proyecto fue lanzada una API oficial, pero no existía

suficiente tiempo para integrar el dispositivo al proyecto. La integración de la API

oficial de Kinect® con el código actual no debiese ser una tarea compleja. Esto

permitiría desarrollar dinámicas de mayor complejidad, que involucren detección de

posturas o gestos, dado que Kinect® tiene incorporado skeletal tracking y mapas de

profundidad. También permitiría recopilar mayor información sobre la ejecución de

la dinámica, para las métricas. El costo, sin embargo, es aproximadamente 10 veces

mayor que el de una cámara web. Igualmente, es una adición de bajo costo para un

centro médico, con un potencial muchísimo mayor.

• Uso de GPU para cálculo de flujo óptico denso: Dado que el cálculo del flujo óptico

denso requiere de operaciones de matrices, es difícil obtener un mapa de flujo

óptico denso, es decir, con un valor de flujo para cada pixel. Sin embargo, estas

operaciones se pueden calcular más rápido mediante el uso de procesadores

gráficos. Dado que hoy en día las tarjetas de video programables son bastante

accesibles (e.g. Nvidia y su línea de tarjetas de video programables por CUDA), esto

sería una mejora de bajo costo, con un potencial altísimo.

• Diseño de interfaces usables: Es necesario mejorar la interfaz del prototipo actual, a

fin de que pueda ser utilizado en el hogar por usuarios finales.

• Sistema de información con progreso de usuarios: Sería posible elaborar un sistema

de información en línea, que permita a los terapeutas visualizar el progreso de los

usuarios de la aplicación. Para esto sería necesario desarrollar una aplicación web, y

añadir a la aplicación actual la posibilidad de enviar sus resultados al servidor. Estos

resultados de la realización de las dinámicas, corresponderían a métricas de tiempo,

cantidad y calidad de ejecución.

54

6 Referencias

[1]. "Feasibility, motivation, and selective motor control: Virtual reality compared to conventional home exercise in

children with cerebral palsy". Bryanton, C., y otros. 2, 2006, Cyberpsychology & Behavior, Vol. 9, págs. 123-128.

[2]. "Low-cost virtual rehabilitation of the hand for patients post-stroke". Morrow, K., y otros. New York, USA : s.n.,

2006. International Workshop on Virtual Rehabilitation. págs. 6-10.

[3]. "Post-stroke arm motor telerehabilitation web-based". Piron, L., y otros. New York, USA : s.n., 2006.

International Workshop on Virtual Rehabilitation. págs. 145–148.

[4]. "A low-tech virtual reality application for training of upper extremity motor function in neurorehabilitation".

Prange, G., y otros. Vancouver, Canada : s.n., 2008. International Workshop on Virtual Rehabilitation. págs. 25-27.

[5]. "Vision-based human motion analysis: An overview". Poppe, Ronald. 108, 2007, Computer Vision and Image

Understanding, págs. 4-18.

[6]. "A Survey of Computer Vision-Based Human Motion Capture". Moeslund, Thomas B. y Granum, Erik. 81, 2001,

Computer Vision and Image Understanding, págs. 231–268.

[7]. Gamma, Erich, y otros. Design Patterns: Elements of Reusable Object-Oriented Software. s.l. : Addison-Wesley,

1994.

[8]. SourceMaking - Private Class Data Pattern. [En línea]

http://sourcemaking.com/design_patterns/private_class_data.

[9]. Hoffman, S. J. Introduction to Kinesiology. s.l. : Shirl J. Hoffman. ed, 2008.

[10]. "Self-management Rehabilitation and Health-Related Quality of Life in Parkinson’s Disease: A Randomized

Controlled Trial". Tickle-Degnen, Linda, y otros. 2, 2010, Movement Disorders, Vol. 25, págs. 194–204.

[11]. "Use of a Low-Cost, Commercially Available Gaming Console (Wii) forRehabilitation of an Adolescent With

Cerebral Palsy". Deutsch, Judith E., y otros. 10, 2008, Physical Therapy, Vol. 88, págs. 1196–1207.

[12]. OpenKinect Official Website. [En línea] http://www.openkinect.org.

[13]. Valente, Luis, Conci, Aura y Feijo, Bruno. Real Time Game Loop Models for Single-Player Computer Games.

Universidade Federal Fluminense – Instituto de Computação; ICAD/IGames/VisionLab, Departamento de

Informática – PUC-Rio. 2005.

[14]. XNA GameStudio Website. [En línea] http://msdn.microsoft.com/en-

us/library/bb200104(v=XNAGameStudio.31).aspx.

[15]. AForge .NET Framework Project Website. [En línea] http://code.google.com/p/aforge/.

[16]. EmguCV - OpenCV for .NET. [En línea] http://www.emgu.com/wiki/index.php/Main_Page.

55

[17]. "An Iterative Image Registration Technique with an Application to Stereo Vision". Lucas, Bruce D. y Kanade,

Tadeo. 1981. Proceedings of Imaging Understanding Workshop. págs. 121-130.

[18]. Bouguet, Jean-Yves. "Pyramidal Implementation of the Lucas Kanade Feature Tracker: Description of the

algorithm". Intel Corporation. 2000.

[19]. Horn, Berthold K. P. y Schunck, Brian G. Determining Optical Flow. Massachussets Institute of Technology.

1980.

[20]. DirectShow .NET library. [En línea] http://directshownet.sourceforge.net/.

[21]. VideoTexture Class and Webcam Application for XNA. [En línea]

http://www.codeproject.com/KB/game/VidTextureClassWebcamApp.aspx.

[22]. Canny, J.F. A Computational Approach to Edge Detection. IEEE Trans. on Pattern Analysis and Machine

Intelligence. 1986. Vol. 6, págs. 679-698.

[23]. Sappa, Angel D y Dornaika, Fadi. An Edge-Based Approach to Motion Detection. ICCS 2006. 2006. Vol. I, LNCS

3991, págs. 563-570.

[24]. Akber Dewan, M. Ali, Hossain, M. Julius y Chae, Oksam. Reference Independent Moving Object Detection: An

Edge Segment Based Approach. KES 2007/WIRN 2007. 2007. Vol. I, LNAI 4692, págs. 501-509.

[25]. Video Motion Capture Using Feature Tracking and Skeleton Reconstruction. Zhuang, Yueting, Liu, Xiaoming y

Pan, Yunhe. Kobe, Japan : s.n., 1999. International Conference on Image Processing ICIP.

[26]. Rapid Object Detection using a Boosted Cascade of Simple Features. Viola, Paul y Jones, Michael. 2001.

Conference on Computer Vision and Pattern Recognition.

[27]. Good Features to Track. Shi, Jianbo y Tomasi, Carlo. Seattle : s.n., 1994. IEEE Conference on Computer Vision

and Pattern Recognition.

[28]. Lucas/Kanade Meets Horn/Schunck: Combining Local and Global Optic Flow Methods. Bruhn, Andrés y

Weickert, Joachim. 61, 2005, International Journal of Computer Vision, Vol. 3, págs. 211–231.

7 Anexos

A. Diagrama de clases de la aplicación

56

Diagrama de clases de la aplicación

57

B. Gameloop del framework XNA

C. Diagrama de proyección de un esqueleto al plano bidimensional

D. Dinámica sentarse y pararse: Usuario sentado

58

Diagrama de proyección de un esqueleto al plano bidimensional

Dinámica sentarse y pararse: Usuario sentado

59

E. Dinámica sentarse y pararse: Usuario de pie

F. Dinámica de equilibrio: Incialización

60

G. Dinámica de equilibrio: Durante interacción

H. Dinámica de equilibrio: Fin de interacción

universidad de chile facultad de ciencias fÍsicas y...

Documents