DESARROLLO DE UNA APLICACIÓN DE SENSADO Y MONITOREO DE LAS CAÍDAS Y MARCHA HUMANA PARA TELÉFONOS INTELIGENTES. CRISTIAN CAMILO BENAVIDES RAMON DIRECTOR (A) NUBIA RINCÓN Proyecto de Grado en modalidad de Monografía para optar al título de Ingeniero Electrónico UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA PROYECTO CURRICULAR DE INGENIERÍA ELECTRÓNICA BOGOTA D.C. 2016
91
Embed
DESARROLLO DE UNA APLICACIÓN DE SENSADO Y MONITOREO …
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
DESARROLLO DE UNA APLICACIÓN DE SENSADO Y MONITOREO DE LAS CAÍDAS Y MARCHA HUMANA PARA TELÉFONOS INTELIGENTES.
CRISTIAN CAMILO BENAVIDES RAMON
DIRECTOR (A)
NUBIA RINCÓN
Proyecto de Grado en modalidad de Monografía para optar al título de
Ingeniero Electrónico
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR DE INGENIERÍA ELECTRÓNICA
BOGOTA D.C.
2016
DESARROLLO DE UNA APLICACIÓN DE SENSADO Y MONITOREO DE LAS CAÍDAS Y MARCHA HUMANA PARA TELÉFONOS INTELIGENTES.
CRISTIAN CAMILO BENAVIDES RAMON
Código: 20061005010
Proyecto de Trabajo de Grado
Director(a) Nubia Rincón
Profesora Facultad de Ingeniería Licenciada en ingeniería electrónica
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERIA
PROYECTO CURRICULAR DE INGENIERÍA ELECTRÓNICA BOGOTA D.C.
2016
Comisión de evaluación.
Esta tesis titulada “DESARROLLO DE UNA APLICACIÓN DE SENSADO Y MONITOREO DE LAS CAÍDAS
Y MARCHA HUMANA PARA TELÉFONOS INTELIGENTES”, escrita por Cristian Camilo Benavides
Ramón, ha sido aprobada en cuanto a estilo y contenido intelectual. Hemos leído esta tesis y la
realizar una aplicación móvil capaz resolver los problemas anteriormente expuestos.
4. OBJETIVOS
4.1. Objetivo general.
Diseñar un sistema de adquisición, procesamiento y análisis de la dinámica de la marcha humana en una aplicación para teléfonos móviles inteligentes en OS Android, como herramienta preventiva y diagnostica de detección de caídas.
4.2. Objetivos específicos.
Desarrollar un programa no invasivo y de bajo costo de adquisición, almacenamiento y procesamiento, de los datos tomados por los sensores del teléfono de la dinámica de la marcha humana.
Almacenar de la manera más adecuada los datos obtenidos para su posterior análisis
Implementar los algoritmos necesarios para la detección y análisis de la dinámica de la marcha humana a partir de los datos obtenidos por los sensores, que permitan clasificar los diferentes tipos de eventos como caídas, anomalías, enfermedades y patrones de marcha.
Diseñar un aplicativo de alerta graduada, de acuerdo a la dimensión o gravedad de eventos particulares ocurridos a usuarios del programa.
5. ESTADO DEL ARTE
Estos son algunas de las publicaciones y trabajos que se encontraron en la actualidad relacionadas
directamente con el proyecto, tanto en el ámbito académico como industrial.
En (Bai et al., 2012), se desarrolló un dispositivo portátil que analiza el flujo de datos procedentes
de un acelerómetro triaxial, para medir y evaluar caídas. Analiza los datos obtenidos del
dispositivo (en forma de canguro), y determina si se presentó alguna caída e informa del
acontecimiento. Los resultados fueron un sensor capaz de analizar los datos de manera local que
envía únicamente los resultados del análisis de los datos obtenidos, con el objetivo de ahorrar
energía. Su sistema de análisis evita las falsas alarmas al integrar algoritmos y umbrales
adecuados. Se concluyó que en una nueva versión era necesario adicionar giroscopios, para una
media más precisa.
En (Doukas & Maglogiannis, 2008), se informa de un estudio para determinar un umbral del
algoritmo asociado a las caídas. Basado en cuatro acelerómetros colocados en diferentes lugares
del cuerpo (tronco, muslos, cintura y muñeca); Los sensores se utilizaron para analizar y medir
diferentes tipos de caídas. Los resultados de este estudio determinaron que en el tronco y la
cintura, se encontraban los datos más relevantes para un posterior análisis.
En (Miura, Ohtaki, & Inooka, 2001), se analizaron las características cinéticas de la marcha humana
y su viabilidad en la implementación en la cinética de la robótica moderna. Como resultado se
encontraron los factores cinéticos esenciales, como el rango de movimiento del ángulo de la
articulación, velocidad angular media y la posición del centro de gravedad.
En (Song et al., 2015), se presenta el estado del arte de varios sensores y dispositivos para la salud.
Se clasificaron los resultados existentes por parte de sus objetivos de aplicación. En particular, los
dispositivos, sistemas y algoritmos se dividieron en: i) detección de caídas, ii) análisis de la marcha,
iii) cuantificación de la actividad física, iv) ritmo cardiaco v) sesiones de sueño. En este artículo se
pudo determinar los sensores y algoritmos más efectivos para cada uno de los casos.
En (Cao et al., 2012), utilizan un teléfono inteligente basado en Android con un acelerómetro
triaxial. Para evaluar los datos del acelerómetro, con varios algoritmos de detección de caídas, en
este proyecto se desarrolló un aplicativo que detecta caídas y al no obtener respuesta del usuario,
envía una notificación a través de SMS. El dispositivo es de respuesta inmediata, por lo que no
permite un análisis posterior, ni realimentación.
En (Perc, 2005), se implementó un sensor en forma de plantilla ortopédica, ubicado en el interior
de un zapato. Éste permitía medir la fuerza, la presión y la marcha del paciente, para determinar
anomalías en la marcha y las posibles causas. Se logró detectar varias anomalías y obtener una
clasificación de estas.
En (Chen & Itoh, 2010), se realizó una plataforma que permitía a los usuarios de teléfonos
inteligentes aprovechar el poder de la nube para liberarse de los límites de la potencia de
procesamiento de sus celulares. Con esto se pueden realizar cálculos de gran procesamiento en
dispositivos remotos, que son cálculos avanzados difíciles de procesar con las limitaciones de un
Smartphone.
En (Tolkiehn et al., 2011), se desarrolló un sensor de caídas usando un acelerómetro de tres ejes y
un sensor de presión barométrica. Estos valores eran enviados por medio de bluetooth a un
dispositivo móvil basado en Android 3.2, el cual se encargaba de analizar y procesar los datos, así
como de enviar señales de aviso. El celular en si solo aportaba la capacidad de procesamiento y
envío de mensajes, pues el dispositivo requería hardware adicional. Los resultados que se
obtuvieron con este dispositivo dieron una precisión de más del 90%.
En (Bai et al., 2012), se realizó una aplicación en Android que usaba los datos del acelerómetro del
dispositivo y los comparaba con las actividades típicas de una persona, detectando con una gran
precisión, cuándo se presentaba una caída. El dispositivo daba respuestas inmediatas pero no
permitía un registro ni un análisis posterior de la información. La comparación de los datos se
hacía previamente y se definían los umbrales, sin posibilidad de realimentación.
En (Yoneyama et al., 2014), se creó un algoritmo de análisis de marcha auto-adaptativo. Permite
discriminar la marcha patológica de la marcha normal sobre la base de los picos extraídos. El
dispositivo funciona con una red de sensores que recopilan la información necesaria; luego se
procesan los datos desde un pc usando la herramienta Matlab.
En (Harbert et al., 2013), desarrollaron una Aplicación para Android que recibe y procesa los datos
del dispositivo MiMiC a través de Bluetooth. Los sensores son correas en forma de manillas, que se
pueden conectar en varias partes del cuerpo, para determinar la marcha y ritmo de viaje de las
personas. Con esto obtuvieron un dispositivo de procesamiento de una red de señales cinéticas.
En (Chan et al., 2012), se realizó un estudio donde se compara los acelerómetros incorporados en
los Smartphone contra los acelerómetros independientes, de uso industrial y académico. Estos
dispositivos pueden proporcionar datos significativos de los movimientos del usuario y pueden ser
útiles para el análisis, evaluación y seguimiento de la marcha. El resultado muestra un 95% de
precisión en la medición de zancadas, entre los dispositivos evaluados.
En (Zhang et al., 2013), se propone un sistema de detección de caídas en tiempo real, para
distinguir varias caídas durante las actividades diarias. Las caídas se detectan en dos pasos:
primero, un algoritmo jerárquico se utiliza para clasificar las posturas de movimiento; a
continuación, analiza si las posturas actuales son normales o anormales. El algoritmo de detección
de caídas fue desarrollado y evaluado dentro de un HTC (basado en Android) en tiempo real. El
dispositivo está basado en los datos adquiridos desde el acelerómetro del teléfono y los sensores
de orientación. El algoritmo no es adaptativo y no permite almacenar datos adquiridos ni los datos
de las marchas.
En (Nickel et al., 2011), se parte de la idea de que cada persona tiene una marcha única como una
huella digital cinética y proponen crear un aplicativo que permita desbloquear un dispositivo
móvil, al detectar previamente los patrones de marcha del usuario. El dispositivo fue exitoso para
poco menos del 30% de los casos, pero lograron grandes avances en el análisis de patrones de
marcha por celulares inteligentes.
6. JUSTIFICACIÓN
Aprovechando el avance tecnológico de los nuevos dispositivos móviles, de sus sensores cada vez
más precisos y económicos, de sus potentes procesadores, del aumento de su velocidad y
capacidad de procesamiento; se realizara una aplicación capaz de reunir y aplicar varias de las
tareas y funciones de un analizador de marcha médico y un dispositivo capaz de censar y detectar
caídas y golpes, en un solo dispositivo; sin recurrir a elementos anexos que contraigan costos
adicionales.
Como se puede observar en el estado del arte del presente trabajo, hay un gran avance en
dispositivos encargados de resolver de manera parcial este inconveniente. Los dispositivos que se
encuentran tanto en la parte comercial como en la parte académica, son variados tanto en su
funcionamiento (ya sea invasivo, recurriendo a un celular, por procesamiento de imágenes, etc.),
como en su costo; teniendo herramientas de celular de costo cero, hasta mecanismos de redes de
cámaras o sensores de un costo bastante elevado.
Además, el objetivo o resultado final para la mayoría de las aplicaciones, se limita simplemente a
generar una señal de alerta; señal que puede fácilmente ser ocultada u omitida por el usuario,
esto debido a que las aplicaciones no tienen la posibilidad de almacenar (mucho menos de
analizar) los antecedentes y los posibles causales. La información del acontecimiento y su
posterior análisis médico, se reduce a la poca información que el usuario recuerde o quiera
proporcionar. Las aplicaciones actuales desechan valores e información útil para un análisis
posterior y profundo del suceso. Estas aplicaciones carecen de reportes que permitirían la
realización de informes, para un posterior análisis o seguimiento. Tampoco dentro de la
investigación se encontró una herramienta capaz de censar la marcha del usuario, herramienta
que al estar al alcance de cualquier usuario, podrá prevenir enfermedades o daños desde la
comodidad del hogar y a coste cero.
Para tratar de dar solución a todas estas problemáticas, la aplicación tiene las siguientes
capacidades:
Capacidad de censar: Por medio del acelerómetro, el sensor de posición y el giroscopio, la
aplicación será capaz de captar los datos suficientes para determinar cuándo, cómo y si en verdad
hubo una caída, choque o un cambio brusco de posición del usuario.
Capacidad de procesar: Los algoritmos de detección de caídas ya desarrollados y el algoritmo de
detección posición que se desarrollará en este trabajo, son de baja complejidad y no presentaran
ningún inconveniente al ser procesados por un Smartphone.
Capacidad de informar: El dispositivo será capaz de avisar en tiempo real cualquier anomalía
severa en la marcha (como una caída), dando detalles del acontecimiento y de su ubicación. Utiliza
las herramientas de comunicación integradas al celular para dar información detallada del
acontecimiento (hora, tipo de acontecimiento, lugar del suceso, localización actual, etc.), ya sea a
un usuario predeterminado, o directamente a un centro de salud especializado dependiendo de la
magnitud del acontecimiento.
Capacidad de almacenar y organizar información: El dispositivo será capaz de almacenar los datos
tomados por sus sensores para su posterior análisis. Hasta ahora las herramientas móviles que se
encuentran en el mercado y en las investigaciones académicas, no cuenta con esta capacidad,
pues se limitan al procesamiento inmediato. Con estos datos obtenidos, clasificados y
almacenados, se pretende determinar si el paciente tiene tendencia a sufrir alguna de las
enfermedades detectables por su marcha (en el caso de la marcha, el proyecto llega únicamente
hasta la obtención, filtrado y almacenamiento; el análisis de estos datos serian parte de otro
proyecto o una continuación del actual, como se verá más detalladamente en los alcances y
limitaciones). (Yamada et al., 2012) (Antonio Luque Estepa, 2014).
Capacidad de analizar: El dispositivo será capaz de analizar los datos previamente obtenidos y
clasificados, para encontrar patrones y causales; así como la capacidad de alertar ante la
posibilidad de una enfermedad de mayor gravedad (esto se implementó únicamente para el
análisis de las caídas). Añadir las causales intrínsecas y extinticas de las caídas, el cómo sucedieron,
su ubicación y entorno; ayudaría a realizar cambios y correctivos, para el bien del paciente.
Estas nuevas herramientas, así como la capacidad de análisis posterior de los valores, permite
tener una base de datos almacenada que pretende evitar que el usuario oculte información, de los
acontecimientos, de su frecuencia y hasta de su gravedad; ya que muchas de las caídas o golpes
dañinos son ocultadas a los doctores o al especialista del caso; evitándole y limitándolo a poder
actuar o prevenir un daño aún mayor. Esto hace parte de una de las consecuencias psicológicas
post caída que afectan al paciente, generándole miedos bien sea, de futuras caídas, de algún tipo
de represarías, de perdida de libertades, de burlas o de casos de sobreprotección (Chan et al.,
2012); que le obligan a ocultar este tipo de acontecimientos.
El proyecto se desarrollara para su posterior uso en cualquier dispositivo móvil que funcione con
Android 4.2 o superior, lo que hará el proyecto económicamente viable, tanto en su desarrollo
como en su uso. Sera en pocas palabras fácil de usar, de programar y personalizar.
7. MARCO TEÓRICO.
7.1. Sensores
Un sensor se puede definir como un dispositivo que está en capacidad de detectar acciones o
estímulos externos y responder en consecuencia. En pocas palabras, un sensor es capaz de medir
un agente externo y transformarlo en una señal eléctrica. Las unidades de medición inerciales son
instrumentos electrónicos que miden la velocidad, orientación y fuerza gravitacional aplicada en
un objeto; por medio de acelerómetros y giroscopios. (Jogan & Olsson, 2005) (Ripka & Tipek,
2010).
7.2. Acelerómetro.
Los acelerómetros son dispositivos electromecánicos que detectan las fuerzas de aceleración, ya
sea estática o dinámica. Las fuerzas estáticas incluyen la gravedad, mientras que las fuerzas
dinámicas pueden incluir vibraciones y movimiento (“ABC del acelerometro,” n.d.).
7.2.1. Teoría de los acelerómetros.
Estos dispositivos convierten la aceleración de la gravedad o de movimiento en una señal eléctrica
analógica proporcional a la fuerza aplicada al sistema, o mecanismo sometido a vibración o
aceleración. (Yang et al., 2010).
El principio básico de funcionamiento de los acelerómetros, es la detección de la fuerza ejercida en
una masa con limitación elástica, como se puede ver en la figura 1. Consideremos un sistema
mecánico simple, que consiste en una masa fija m, con un muelle con una rigidez k (constante). Si
la masa se desplaza una distancia x, la aceleración debido a la fuerza restauradora del muelle es
𝑓 = 𝑘 ∗ 𝑥. Sustituyendo en la ecuación de Newton, y derivándola obtenemos desplazamiento x de
la masa fija. Este principio fundamental se utiliza hasta en el más sofisticado y caro acelerómetro
electromecánico, e incluso en modernos acelerómetros micro-mecanizados. (Tarashansky,
Vathsangam, & Sukhatme, 2014) (Yang et al., 2010).
Figura 1. Esquema básico del acelerómetro
7.2.2. Modelo del acelerómetro.
Existe un modelo general para representar un acelerómetro. Ver Figura 2
Figura 2. Modelo del principio de un acelerómetro.
El modelo general de un acelerómetro consiste en una masa colgada por un resorte, capaz de
medir la fuerza ejercida para su deformación. La fuerza que se mide puede ser relacionada de
manera directa con la masa del objeto, y de esta manera obtener el valor de la aceleración
(Antonio Luque Estepa, 2014).
7.2.3. Tipos de acelerómetros
Existen diversos modelos de acelerómetros. A continuación se mencionan algunos cuantos y sus
características principales. La siguiente información fue tomada de (Antonio Luque Estepa, 2014).
Acelerómetros mecánicos
Emplean una masa inerte y resortes elásticos. Los cambios se miden con galgas extensiométricos
(matriz de bobinas o cable muy fino que varían sus resistencias linealmente en función de la carga
aplicada al dispositivo), incluyendo sistemas de amortiguación que evitan la propia oscilación
(Antonio Luque Estepa, 2014).
Acelerómetros capacitivos
Estos dispositivos varían la posición relativa de las placas de un microcondensador cuando se
encuentra sometido a aceleraciones. Están integrados en chips de silicio, que les proporcionan,
grandes ventajas como resistencia en cuestiones de humedad, temperatura, capacidades
parásitas, número total de terminales, etc.).
Figura 3. Variedad de estructuras de condensadores usados para medir posición.
Los sensores interdigitales, son los más recurridos en la electrónica moderna. Estos se encuentran
formados por un conjunto de electrodos fijos (anclados al circuito) y una serie de placas unidas a la
masa de prueba, que sólo están sujetas al sustrato por sus extremos de forma que tengan cierta
libertad de movimiento. Al aplicar una fuerza externa, la masa central se moverá, desplazándose
también los electrodos adheridos a ella.
Figura 4. Esquema y deformación de un sensor capacitivo.
Acelerómetros piezo-resistivos
Su funcionamiento se basa en la propiedad de las resistencias eléctricas de cambiar su valor
cuando el material se deforma mecánicamente. En lugar de tener un cristal piezoeléctrico, como
los anteriores sensores, tienen sustrato formando parte de un circuito que mide la intensidad de
corriente mediante un puente de Wheatstone.
Figura 5. Acelerómetro piezo-resistivo.
Acelerómetros piezoeléctricos
Funcionan por una conversión directa de energía mecánica a energía eléctrica. Un cristal
compuesto de dipolos eléctricos es puesto entre la carcasa y una masa sísmica en un mismo eje de
medición. Cuando el acelerómetro es movido en este eje, la fuerza ejercida por este movimiento
de la masa está aplicada al cristal; y dicha fuerza es proporcional a la aceleración de la masa
sísmica. (Yang et al., 2010).
Figura 6. Acelerómetro piezoeléctrico.
Acelerómetros de placas calientes
A grandes rasgos, estos funcionan por medio de una masa suspendida y posicionada cerca de un
disipador de calor. Esta masa luego es calentada a una temperatura específica donde, en caso de
que no haya aceleraciones aplicadas, existirá un balance de temperaturas entre el disipador y la
masa.
Acelerómetros micromecanizados (MEMS)
Se denomina MEMS (MicroElectroMechanichal Systems) o microsistemas electromecánicos, a una
tecnología de base que se utiliza para crear dispositivos diminutos. Este tamaño puede oscilar en
pocas micras pudiendo llegar hasta un milímetro de diámetro. Por lo general, estos mecanismos
tienen un tamaño mayor al micrómetro (millonésima de metro) y menor al milímetro.
Acelerómetros 3D
El sensor de aceleración 3D es un monitor de movimiento completo de 3 ejes capaz de detectar la
caída libre en todas las direcciones con la misma intensidad. Esta capacidad de supervisión, filtra
con exactitud los pequeños movimientos de inclinación y detecta las vibraciones repentinas (Cao
et al., 2012)
Figura 7. Acelerómetro 3D.
7.2.4. Aplicaciones de los acelerómetros.
La aceleración es una magnitud física fundamental, manifestada de muchas maneras (gravedad,
vibración, actividad sísmica). La medición de la aceleración de forma continua, exacta y a bajo
coste, abre numerosas aplicaciones para los acelerómetros. Un acelerómetro puede detectar
movimientos y contrarrestar los choques; análogo a esto, se podrían tener en el transporte de
paquetes frágiles y delicados, en los que cualquier moviendo o golpe externo puede romper el
contenido.
Por lo general, un acelerómetro siempre está vinculado a un giroscopio y se usan en su mayoría,
para obtener la información de la velocidad y la posición de un objeto. Entre una de las
aplicaciones más comunes están los sistemas inerciales de navegación; tales como el sistema de
navegación “Gimbaled”, o el sistema de navegación “Strapdown”, los cuales son generalmente
sistemas donde se usan los acelerómetros para medir velocidad y posición del objeto (Yang et al.,
2010).
7.2.5. Criterios para la elección del acelerómetro adecuado
En el mercado existen muchas posibilidades de sensores para medir la aceleración. La elección de
uno de ellos depende de las características del sensor: los márgenes de valores de la aceleración
que admite, capacidad para medir en continua o sólo en alterna, la máxima frecuencia a la que
puede trabajar, los parámetros característicos del sensor tales como márgenes de temperatura,
sensibilidad, consumo, peso y precio (Antonio Luque Estepa, 2014).
7.3. Giroscopios Como se ha mencionado anteriormente, los giroscopios se utilizan en gran medida junto a los
acelerómetros. Su uso ha sido de gran servicio en la navegación, especialmente en la navegación
aérea debido a que pueden indicar la inclinación que tiene el avión. Un giroscopio puede medir la
rotación alrededor de cada eje de diferentes maneras. Por lo general, un giroscopio mide esta
velocidad radial de una manera relativamente similar a la de un acelerómetro. La diferencia
consiste en que las fuerzas aplicadas, al ser radiales, se toman en cuenta como torques. En pocas
palabras, el giroscopio es el análogo al acelerómetro, en el sentido de que el giroscopio mide
velocidad giratoria y el acelerómetro mide aceleración lineal. Este sensor se basa en un fenómeno
físico mejor conocido como el principio de conservación del momento angular (Ripka & Tipek,
2010).
Figura 8. Principio de conservación del momento angular.
7.3.1. Tipos de Giroscopios
Giroscopios rotatorios
Mejor conocidos como giroscopios mecánicos, estos han sido usados en aviación por muchos
años. Una de las principales limitantes que tienen es que no son muy confiables. Este giroscopio
está constituido por un disco el cual puede girar sobre un eje libremente, el cual está confinado
dentro de otro.
Giroscopios vibratorios
Estos giroscopios utilizan una masa suspendida por resortes como se muestra en la figura 9. En vez
de girar como un giroscopio normal, la masa vibra en un movimiento traslacional. Estos se basan
en el principio de la generación y detección de la aceleración Coriolis (Chan et al., 2012) (Chen &
Itoh, 2010).Una vez en funcionamiento, la masa es sensible a variaciones angulares inducidas
sobre el eje z perpendicular al sustrato (Nickel et al., 2011).
Figura 9. Giroscopio vibratorio.
7.3.2. Aplicaciones de los giroscopios.
Algunas de las aplicaciones más comunes son: control de trayectoria, orientación autómata,
estabilización de antenas y plataformas, sistemas de navegación, instrumentación, robótica y
vehículos, agricultura de precisión, automatización de la fabricación, médico/ortopédico, etc.
7.4. Enfermedades detectadas por la anomalía en la marcha.
7.4.1. Enfermedad Parkinson
Las personas diagnosticadas con algún tipo de trastorno cognitivo, como la enfermedad de
Parkinson, pueden sentir cierta pérdida de independencia debido a los problemas de movilidad
asociados. Se ha propuesto un modelo matemático que examina múltiples factores relacionados
con la marcha, tanto en sujetos sanos como en afectados. De forma inmediata y mediante una
prueba de marcha simple, se puede conocer si una persona mayor presenta algún tipo de
anomalía en este campo.
Las señales del acelerómetro se utilizaron para examinar tres aspectos del movimiento: los
movimientos hacia delante y hacia atrás, de lado a lado y de arriba a abajo. Con esta información,
los investigadores llevaron a cabo una serie de cálculos matemáticos. Estas medidas fueron
capaces de discriminar diferencias en estos tres aspectos entre la población sana y la población
clínica (“Revista Medica Ortopedia,” 2015).
7.4.2. El trastorno de la marcha en la enfermedad de Parkinson (EP)
Es frecuente y es una de las principales causas de incapacidad. Aunque semiológicamente puede
mostrarse de diferentes formas, cuando se analizan las variables de la marcha de forma
cuantitativa, generalmente el patrón de la marcha en la EP se caracteriza por una disminución de
la velocidad y de la longitud de zancada y un aumento del tiempo de doble apoyo. La cadencia es
normal o incluso está algo aumentada para tratar de alcanzar una velocidad de marcha normal.
Existe también una mayor variabilidad de la longitud de zancada. Los movimientos articulares
están reducidos, las caderas y rodillas se encuentran ligeramente flexionadas durante todo el ciclo
de la marcha (CORREIRA Claudia, 2009).
Existen también estudios que muestran la influencia de la levodopa en la marcha de estos
pacientes. Varios trabajos han demostrado aumentos significativos tanto de la velocidad de
marcha, como de la longitud de zancada y diversos efectos sobre la cadencia y el tiempo de doble
apoyo.
7.4.3. Parálisis cerebral
Algunos pacientes con parálisis cerebral espástica presentan escasa movilidad de la rodilla o
«rodilla rígida». Una causa de ello es la espasticidad del recto anterior que se contrae
simultáneamente con los isquiotibiales (coes-pasticidad), impidiendo la flexión adecuada de la
rodilla. Esta extremidad puede arrastrar el pie durante la fase de balanceo o, como compensación,
realizar circunducción de la extremidad. Se produce así una marcha inadecuada, cuya velocidad
está disminuida, con una mayor excursión del centro de gravedad y un mayor consumo de energía
(“Revista Medica Ortopedia,” 2015).
7.5. La artritis reumatoide (AR) Es una enfermedad inflamatoria crónica, de naturaleza autoinmune, caracterizada por
manifestaciones en las articulaciones (como dolor, tumefacción y rigidez) y la presencia de
síntomas generales (como cansancio, sensación de malestar, fiebre ligera, inapetencia y pérdida
de peso corporal). Además, con el paso del tiempo es común la aparición de algunas
manifestaciones extraarticulares, es decir, que afectan a sectores del organismo no relacionados
con las articulaciones (como la piel, los vasos sanguíneos, el corazón, los pulmones, los ojos y la
sangre).
Evolución de la AR.
Está ligada a la inflamación articular y es muy variable. En algunas personas, cesa de forma
espontánea. Sin embargo, en la mayoría de los casos evoluciona durante muchos años, incluso de
por vida, Sin el tratamiento oportuno, los brotes sintomáticos tienden a ser más frecuentes y
duraderos, hasta provocar una progresiva limitación de la movilidad articular y la aparición de
Delimitan los elementos de un documento XML. La sintaxis de la etiqueta de comienzo de
elemento es: <nombreElemento>; y la sintaxis de la etiqueta de fin de elemento:
</nombreElemento>. El nombre del elemento es nombreElemento
Elementos.
Un elemento es un conjunto de datos del documento delimitado por etiquetas de comienzo, "<>",
y fin de elemento, "</>". Cada elemento representa un componente lógico del documento y
puede contener otros elementos. Normalmente contendrá datos de tipo carácter como texto,
tablas, etc.
Comentarios.
Los comentarios en XML tienen la misma funcionalidad que los comentarios en los lenguajes de
programación. No forman parte del contenido del documento que será analizado, es decir, no
serán procesados por el analizador.
Un comentario es un texto que se escribe entre los símbolos de apertura de comentario "<!--" y de
cierre de comentario "-->".
Sección CDATA.
Se utiliza para expresar bloques de texto que contienen caracteres que de otra manera, serían
reconocidos como etiquetas por el analizador. Se podrá mostrar su contenido, pero las
anotaciones que contenga no serán analizadas. Su sintaxis es la siguiente:
<![CDATA[ texto que no se quiere analizar ]] >
Entidades.
Una entidad permite asignar un nombre (referencia) a un subconjunto de datos (texto) y utilizar
ese nombre para referirnos a dicho subconjunto. Las entidades pueden aparecer en dos contextos:
el documento y la DTD.
La sintaxis de una entidad consta de la marca de comienzo de una referencia a una entidad "&" y
la del final ";".
XML especifica 5 entidades predefinidas que permiten representar 5 caracteres especiales, de
modo que se interpreten por el analizador o el procesador con el significado que tienen por
defecto en XML:
• & para el carácter "&".
• < para el carácter "<".
• > para el carácter ">".
• ' para el carácter "’".
• " para el carácter """.
Instrucciones de procesamiento
Se utilizan para proporcionar información a la aplicación o programa que va a procesar el
documento XML. Su sintaxis es: <? Instrucción procesamiento ? >.
Los analizadores XML no hacen nada con las instrucciones de procesamiento: Las pasan a la
aplicación para que ésta decida qué hacer. El objetivo es similar al de los comentarios, pero éstos
van destinados a los usuarios, mientras que las instrucciones de procesamiento van destinadas a
los programas. Por último, están prohibidas las instrucciones de procesamiento que comiencen
por XML, salvo la del prólogo.
8.6. Tipos de layout en Android
Un Layout es un fichero XML y se encarga de establecer el diseño de la interfaz de usuario (en
inglés user interfaz (UI)). En la paleta de elementos que nos ofrece Android Studio se encuentran
los elementos disponibles para insertar en nuestra aplicación. Para insertar estos elementos en
nuestro dispositivo basta con arrastrarlos. El primer desplegable que nos ofrece la paleta de
elementos son los Layouts, estos Layouts se pueden definir como un contenedor padre y según el
tipo de Layout que empleemos los elementos que insertemos se comportaran de una manera u
otra. (Bascuñana Saiz, n.d.) (Alcalde, 2011)
En la Tabla 3 se muestran los layouts más utilizados con sus características
Layout Característica
FrameLayout Este Layout suele usarse para mostrar un único elemento en la UI (Interfaz de usuario). Android Stuido nos permite posicionar hasta 9 elementos. Coloca a sus objetos hijos en la parte superior izquierda de la pantalla.
LinearLayout
Coloca sus objetos hijos unos detrás de otros de manera lineal, o bien de forma vertical o bien de forma horizontal.
Tanto el Layout vertical como el horizontal pueden ser padres e hijos unos de otros. El elemento padre es capaz de contener uno o más hijos, es decir tenemos un LinearLayout(Vertical) y dentro de éste un LinearLayout(Horizontal), es decir, el primero es el padre y el segundo es el hijo, porque el padre contiene al hijo.
TableLayout
Dentro de este Layout podemos definir filas y columnas para situar los elementos. En Android Studio, directamente al arrastrar un elemento nos aparecerá una cuadricula en la que podremos ir situando los distintos elementos. Básicamente, es una matriz de elementos.
TableRow Debe ser usado como hijo de un TableLayout. Básicamente éste Layout es una tabla de columnas.
GridLayout Nos permite colocar cada elemento de forma relativa a cualquier elemento dentro del propio RelativeLayout.
RelativeLayout
Este Layout permite que coloquemos los elementos en un lugar con respecto a la posición de otro, es decir, colocar un botón a la derecha de un texto, o centrarlo en la pantalla, o por ejemplo, colocar un texto encima de tal elemento y a la derecha de este otro.
Para conseguir esto, RelativeLayout proporciona propiedades como android:layout_toRightOf o android:layout_alignLeft, que toman como valores los identificadores de los objetos, o valores booleanos.
Tabla 3. Layouts comunes en android (Fuente: Autor, 2016).
8.7. Uso de multilenguaje en android Cuando se realiza una aplicación android, se espera que pueda ser utilizada en cualquier lugar del
mundo y, por ende, maneje varios idiomas para su comprensión por parte de cualquier usuario.
Para ello, no es necesaria la creación de muchas aplicaciones, cada una con un idioma distinto;
basta con crear una sola aplicación y recurrir al uso del archivo strings.xml. Este se utiliza para
almacenar todas las constantes de cadenas de caracteres que se necesitan en un programa (por
ejemplo las etiquetas de los objetos Button, los textos fijos de los controles TextView y todos los
controles que muestran un texto fijo en el dispositivo). Su localización se dá en la carpeta values,
alojada a su vez en la carpeta res. (“47 - Archivo strings.xml,” n.d.)
8.8. Estilos en android studio Los estilos son un conjunto de reglas que determinan la apariencia y formato de un View o Layout.
Las propiedades que muestran los views a la hora de usar la vista de diseño en Android Studio, nos
dán una idea de los cambios que se pueden realizar tales como el color de fondo, cambiar el
tamaño del texto, definir el alto y ancho, etc. Estas son características que hacen parte de los
estilos.
Aunque las propiedades se pueden especificar en el mismo layout, es posible independizarlos del
diseño a través de un archivo de recurso de estilos. Este concepto es muy similar a cuando se
desarrolla websites, separando los archivos html de los estilos css, por ejemplo.
Al igual que los strings, layouts y drawables, también hay una sintaxis para generar un estilo en un
archivo de recurso que nos permita reusar código. Para ello debemos crear un nuevo archivo XML
que se albergue en la carpeta de recursos res/values/. Donde usaremos el nodo padre para los
recursos <resource>.
Ahora, para definir un estilo se usa el elemento <style> y se le asigna un nombre único a través de
su atributo name. Para definir las reglas que lo componen se crean elementos <item> en su
interior, detallando el nombre del atributo a modificar y su respectivo valor. (“Diseñar Temas y
Estilos para tus Aplicaciones Android,” n.d.)
8.9. Androidmanifiest
AndroidManifest.xml, es un archivo de configuración generado automáticamente donde se aplican
las configuraciones básicas de una app. Su configuración o modificación puede realizarse a través
de una interfaz gráfica, pero es recomendable conocer la sintaxis ya que en muchas ocasiones será
más fácil y rápido hacerlo desde el propio xml. El android manifest está situado en la raíz de cada
aplicación. Dentro de las tareas más importantes de este archivo se encuentran:
Utiliza el nombre de paquete Java como identificador único de la aplicación.
Describe los componentes de la aplicación: actividades, servicios, proveedores de
contenido... Para ello utiliza el nombre de las clases que implementan cada uno de estos
componentes y publica sus capacidades. Esto permite al sistema operativo conocer que
componentes tiene y bajo qué condiciones pueden ser lanzados.
Especifica que permisos tiene la aplicación para acceder a partes protegidas del API que
proporciona el sistema Android.
Declara la mínima versión del sistema operativo en el que funcionará la aplicación.
Indica las librerías que utiliza el proyecto y por lo tanto tienen que ser empaquetadas al
crear la aplicación.
Permite declarar una clase 'Instrumentation' que sirve para monitorizar la interacción de
la aplicación con el sistema. Esta declaración solo estará presente mientras se desarrolla y
prueba la aplicación. Ya que será borrada antes de que la aplicación se vaya a publicar.
(Posilio, 2013)
8.9.1. Descripción de elementos básicos de Androidmanifiest
Etiqueta manifest.
Este el elemento raíz del manifiesto y sus dos atributos principales y obligatorios son:
xmlns:android: Define el espacio de nombres de Android y siempre debe de ser el mismo
package: El nombre del paquete define la aplicación y actúa como identificador único de la
misma. Si se ha publicado una aplicación con un nombre y luego se cambia, los usuarios de
la primera versión no podrán actualizar a la siguiente.
Etiqueta uses-sdk
Éste es un elemento (etiqueta) de segundo nivel obligatorio que determina la compatibilidad de la
aplicación con una o más versiones del sistema operativo. Esta compatibilidad viene expresada en
base al nivel de API del sistema Android que soporta. Sus dos atributos principales son:
android:minSdkVersion (obligatorio): Determina el mínimo nivel de API que debe de tener
el sistema operativo Android que pretenda ejecutar la aplicación. El sistema evitará que la
aplicación se instale en un sistema que tenga un nivel de API inferior del especificado.
android:targetSdkVersion (opcional): Si no se especifica se toma el valor de
minSdkVersion. Determina el nivel del API con el que fue construida la aplicación. Por lo
que se espera que tome ventajas del nivel de API especificado, pero es totalmente retro-
compatible con versiones antiguas hasta la indicada mediante minSdkVersion.
Etiqueta uses-permission
Etiqueta opcional de segundo nivel que sirve para indicar un permiso necesario que requiere la
aplicación para acceder a alguna parte protegida del API que proporciona el sistema Android. Esta
declaración alertará a los usuarios que la aplicación utilizará ciertos permisos. Evidentemente
crearemos tantas etiquetas como permisos necesitemos. El único atributo disponible y obligatorio
es android:name, el cual indica un permiso que necesita la aplicación.
Etiqueta application
Etiqueta de segundo nivel que contendrá otras etiquetas que declararán cada uno de los
componentes de la aplicación. Además permite atributos que pueden afectar a todos los citados
componentes de la aplicación. Solo se puede declarar una vez este elemento en el manifiesto.
Etiqueta activity
Etiqueta de tercer nivel y que es uno de los sub-elementos de la etiqueta application. Una
actividad es el controlador que va a interactuar con una pantalla de la interfaz gráfica y por lo
tanto, debemos de especificar cada actividad del proyecto con su etiqueta activity
correspondiente. Si una actividad no está especificada en el manifiesto, esta no podrá lanzarse,
con el consiguiente error en la aplicación.
Etiqueta action
Una acción que el 'intent-filter' soporta. Las acciones son cadenas de texto estándar que describen
lo que la actividad puede hacer. El único y obligatorio atributo es android:name, en el cual se
indica el nombre de la acción.
Etiqueta category
Básicamente indica si la actividad va a ser lanzada desde el lanzador de aplicaciones, o desde el
menú de otra aplicación, directamente desde otra actividad.
8.10. Componentes de una aplicación android En android, se cuenta con un conjunto de componentes de software que hacen posible la
funcionalidad de la aplicación, mediante la interacción de los mismos. A continuación, se
describen estos componentes.
Activities
Las actividades (activities) representan el componente principal de la interfaz gráfica de una
aplicación Android. Se puede pensar en una actividad como el elemento análogo a una ventana o
pantalla en cualquier otro lenguaje visual.
View
Las vistas (view) son los componentes básicos con los que se construye la interfaz gráfica de la
aplicación, análoga, por ejemplo a los controles de Java o .NET. De inicio, Android pone a nuestra
disposición una gran cantidad de controles básicos, como cuadros de texto, botones, listas
desplegables o imágenes, aunque también existe la posibilidad de extender la funcionalidad de
estos controles básicos o crear nuestros propios controles personalizados
Intents
Un intent es el elemento básico de comunicación entre los distintos componentes Android. Se
pueden entender como los mensajes o peticiones que son enviados entre los distintos
componentes de una aplicación o entre distintas aplicaciones. Mediante un intent se puede
mostrar una actividad desde cualquier otra, iniciar un servicio, enviar un mensaje broadcast,
iniciar otra aplicación, etc.
Servicios
Los servicios (service) son componentes sin interfaz gráfica que se ejecutan en segundo plano. En
concepto, son similares a los servicios presentes en cualquier otro sistema operativo. Los servicios
pueden realizar cualquier tipo de acciones, por ejemplo actualizar datos, lanzar notificaciones, o
incluso mostrar elementos visuales (por ejemplo actividades), si se necesita en algún momento la
interacción con el usuario.
Content prividers
Un proveedor de contenidos (content provider) es el mecanismo que se ha definido en Android
para compartir datos entre aplicaciones. Mediante estos componentes, es posible compartir
determinados datos de nuestra aplicación, sin mostrar detalles sobre su almacenamiento interno,
su estructura, o su implementación. De la misma forma, la aplicación podrá acceder a los datos de
otra a través de los content provider que se hayan definido.
Broadcast receivers
Un broadcast receiver es un componente destinado a detectar y reaccionar ante determinados
mensajes o eventos globales generados por el sistema (por ejemplo: “Batería baja”, “SMS
recibido”, “Tarjeta SD insertada”) o por otras aplicaciones (cualquier aplicación puede generar
mensajes (intents, en terminología Android) broadcast, es decir, no dirigidos a una aplicación
concreta sino a cualquiera que quiera escucharlo). (“Componentes de una aplicación Android,”
2010)
Fragmentos (fracments)
Un fragment está formado por la unión de varias vistas para crear un bloque funcional de la
interfaz de usuario, pensado para su adaptación a diferentes tamaños de pantallas en los
dispositivos. Una vez creados los fragments, se pueden combinar uno o varios fragments dentro
de una actividad, según el tamaño de pantalla disponible. (Tomas, 2011)
8.11. Servicio google maps Google Maps es un servidor de aplicaciones de mapas en la web que pertenece a Alphabet Inc.
Ofrece imágenes de mapas desplazables, así como fotografías por satélite del mundo e incluso la
ruta entre diferentes ubicaciones o imágenes a pie de calle con Google Street View. (“Google
Maps,” 2016)
9. DISEÑO DE LA APLICACIÓN
9.1. Inicio y presentación de la aplicación.
En el escritorio del Smartphone se puede encontrar el acceso directo a la aplicación con el nombre
e icono que la identifican (Figura 10.).
Figura 10. Icono lanzador de la aplicación.
Figura 11. Pantalla de inicio de la aplicación.
Una vez se ingrese a la aplicación el usuario encontrar la pantalla de inicio (Figura 11.), con una
pequeña presentación del aplicativo. En esta pantalla encontrar el botón “continúe” para acceder
a la aplicación y el botón “Exit”, para finalizar y salir del aplicativo.
El botón “continúe” dirige al usuario a una pantalla de instrucciones generales, esta pantalla
representa a la vez la actividad principal; esta activity principal es la encargada de manejar y dirigir
a cada una de las funcionalidades y procesos de la aplicación. Para mejorar la usabilidad de la
aplicación, se decidió añadir las instrucciones de uso de la pantalla y de su menú lateral o
Navigation Drawer (Figura 12).
9.2. Menú principal de “FallRegister”.
El menú lateral o Navigation Drawer, se despliega ya sea pulsando sobre la pestaña blanca que se
encuentra en la parte superior izquierda, o deslizando de izquierda a derecha la pantalla. En este
menú lateral se encuentra un encabezado con el nombre e icono de la aplicación y la información
básica del desarrollador; bajo este encabezado se encuentran los vínculos de todas las activitys y
fragmentos que componen las funcionalidades de la aplicación (Figura 13). Tanto el menú lateral
como todas las pantallas del aplicativo, tienen un scroll que permite ajustar el contenido a
cualquier tipo de pantalla de menor o mayor resolución. Las opciones del menú deberían ser
activadas en el orden en que el menú sugiere, sin embargo, si se salta un paso o proceso, la
aplicación bloqueara las funcionalidades que necesiten de un dato o paso previo para su correcto
funcionamiento.
Figura 12. Instrucciones de navegabilidad de la aplicación.
Figura 13. Menú lateral del programa.
9.3. Ingreso e identificación del usuario
El primer elemento que el menú despliega en orden, es la pantalla de registro e identificación del
usuario (Figura 14); este proceso es importante para poder realizar una correcta individualización
del usuario y para que los datos del paciente se guarden de una forma segura, evitando que un
intruso pueda obtener información personal. La contraseña será utilizada cada vez que se
pretenda realizar un cambio en las opciones o configuraciones del aplicativo.
Figura 14. Pantalla de login.
Figura 15. Confirmación de datos obligatorios.
Para la ventana y el proceso de login, se dispone de dos campos en donde se deberá ingresar el
usuario previamente registrado y la correspondiente contraseña. Esta ventana posee campos de
validación, que le muestran al usuario si hay campos obligatorios sin diligenciar. En caso de
ingresar un usuario o contraseña invalida, se mostrara una notificación informando de la invalidez
de los datos y dejando la aplicación en el fragmento de logeo; esto le permitirá al usuario intentar
de nuevo las veces que desee sin ningún tipo de restricción respecto al número de intentos.
9.4. Registro usuario nuevo
En caso de que el usuario aun no disponga de una cuenta de login, podrá crear una seleccionando
en la parte inferior el texto “si no tiene usuario regístrese”, esto hará que se abra una ventana con
un estilo y tamaño particular y diferenciable, en donde solicitará los datos del nuevo usuario con
su respectiva contraseña. Estos datos tienen que cumplir con algunas restricciones; el usuario no
puede tener menos de cinco caracteres y la contraseña menos de 3; la contraseña debe de ser de
tipo numérico y debe iniciar por un número diferente de cero. Si los datos ingresados cumplen con
las restricciones, el usuario se creara y se notificará por medio del Toast; en caso contrario, el
programa notificara del error para que el usuario pueda realizar las respectivas modificaciones.
Estas restricciones se tomaron para que el usuario no sobrescriba los datos al momento de crear
un nuevo usuario, ni le permita añadir un usuario o una contraseña demasiado débil. La restricción
de no incluir un número que inicie con el número cero, corresponde completamente a decisiones
de diseño, con el propósito de evitar errores de validación.
Figura 16. Registro de usuario nuevo.
Figura 17. Limitaciones para el usuario y la clave nueva .
El objetivo de contar con unos valores de validación y de acreditación, son de vital importancia.
Esta contraseña será solicitada en cualquier momento en que el usuario intente invalidarla o
desactivarla. En una versión posterior de la aplicación se utilizaran dos contraseñas diferentes,
para diferenciar el usuario “paciente” del usuario “Administrador”. La implementación de estas
claves distintas evitara que el paciente elimine controles de seguridad que harán que la aplicación
deje de informar de una posible caída, o deje de monitorear o almacenar los datos de los sensores.
Si bien la mayoría de pacientes acepta y ve con buenos ojos, la posibilidad de contar con un
sistema de notificación de accidentes, el sistema de doble clave se implementa para aquellos que
aún se resisten a este tipo de herramientas.
Figura 18. Creación del nuevo usuario.
Figura 19. Confirmación del usuario creado.
Al momento de ingresar el usuario y la contraseña correcta, se lanzará una ventana emergente
que confirmará la validez de los datos, e invitara al usuario a continuar con los pasos siguientes en
el menú lateral. A partir de ese momento y una vez que este identificado el usuario, cuando
ingrese a la sección “login”, saldrá la ventana emergente informando que el usuario ya está
identificado; además se podrá visualizar en la parte inferior, el nombre del usuario
ingresado(Figura 20). Esta información es relevante ya que la aplicación permite ser empleada por
múltiples usuarios, con múltiples cuentas. La sesión del usuario persistirá en el programa, hasta
que la aplicación sea reiniciada. Si el usuario regresa de manera involuntaria a la página inicial, los
datos de acreditación se mantendrán. Si el usuario está registrado saldrá en color verde la cadena
de texto “usuario: (nombre de usuario)”; en caso de que no se hubiera realizado previamente este
proceso de identificación, la cadena será de un color rojo, a manera de advertencia y mostrará el
texto: “Usuario no valido”.
Figura 20. Pestaña de usuario autentificado.
Figura 21. Página de login, con usuario autentificado.
9.5. Configuración “Datos del usuario”.
Una vez el usuario se encuentre identificado, puede proceder a la siguiente ventana, la ventana de
“Datos de usuario” (Figura 22), esta ventana contiene los datos básicos del usuario “paciente”,
datos que pueden colaborar en caso de tener la necesidad de identificar a quien pertenece el
dispositivo y de quien se está realizando el correspondiente censado; estos datos pueden ser útiles
en caso de que la persona que se encuentra o auxilia al paciente, no pueda utilizar o simplemente
no conozca la aplicación y tenga que acceder a los datos de emergencia de la manera tradicional.
Si bien la mayoría de los datos de ese formulario son de carácter informativo, la aplicación emplea
el peso y la edad del paciente, para ajustar los valores de precisión y sensibilidad del detector de
caídas, siendo la sensibilidad directamente proporcional a la edad y al peso del paciente; de
manera análoga la estatura se emplea para conocer el índice de masa corporal de individuo, ya
que si éste posee sobre peso, una caída puede resultar mucho más nociva y puede presentar
consecuencias de mayor gravedad.
Figura 22. Pantalla "datos de usuario".
Figura 23. Datos diligenciados de la pantalla "datos de usuario".
Los datos que el usuario llene en este formulario persistirán en el dispositivo, a menos que sea
desinstalada la aplicación. Cuando el usuario ya está registrado y previamente ha diligenciado
todos los campos, estos se llenaran de manera automática y se mostrara la notificación de la
validación con la pantalla completa.
El formulario no acepta información parcial, esto quiere decir que tiene que estar completamente
diligenciado para que se pueda almacenar o editar alguno de los datos o campos. Como el
formulario se llena automáticamente (cuando los datos se almacenaron con anterioridad), la
realización de una edición particular de un campo, se limita a realizar la modificación específica;
escribir la contraseña y seleccionar el botón “Editar”. En caso de que el formulario no se encuentre
diligenciado en su totalidad, o que la contraseña no sea escrita o sea incorrecta, la aplicación
mostrara la correspondiente ventana de notificación, informando que el proceso no se completó
de manera satisfactoria (Figura 24).
Figura 24. Solicitud de contraseña para la realización de algún cambio o modificación.
Figura 25. Confirmación del almacenamiento de los datos de usuario.
Si todos los datos del formulario están diligenciados con sus respectivos formatos válidos y la
contraseña ingresada corresponde a la contraseña del usuario, los datos se actualizarán, y se
notificara al usuario de la posibilidad de continuar con los pasos correspondientes a la
configuración y calibración del sensor (Figura 25).
9.6. Configuraciones del programa
El siguiente paso corresponde al fragmento de “configuración del programa”, en este fragmento,
el usuario podrá editar y explorar todas las opciones de funcionalidad que tiene la aplicación. En
primer lugar se encuentra la selección de la sensibilidad del detector de caídas (Figura 26), si bien
este valor ya viene predefinido con los datos de la edad, el peso y la estatura del paciente, en este
paso se puede afinar un poco más este nivel y aumentar o disminuir los valores con los que el
dispositivo detectará un golpe o una caída. Si bien el programa permite la configuración manual
del nivel de precisión del sensor, la aplicación sugiere que se empleen los valores definidos por el
programa basados en los datos del usuario previamente diligenciados.
Figura 26. Pantalla de configuración del programa. Elección de la sensibilidad
En esta ventana de configuraciones del programa, se deberán seleccionar los contactos que la
aplicación usara para realizar el envío de notificaciones, ya sea de tipo de texto (SMS), o realizando
la notificación por medio de una llamada. Si los campos de contacto no están diligenciados de una
manera correcta al momento de lanzar el servicio detector de caídas, la aplicación notificara el
error y mostrara una advertencia, informando que no se han diligenciado los datos necesarios
para el correcto funcionamiento de la aplicación y por consiguiente no permitirá ejecutar el
proceso. Esto debido a que una de las funcionalidades principales del aplicativo es la notificación
de los eventos de emergencia, funcionalidad que no se puede ejecutar con la ausencia de estos
datos.
Para poder diligenciar los contactos de una manera fácil y sencilla, se implementó el proveedor de
contenido (Content Providers) de la lista de llamada y agenda del usuario; de esta manera, el
usuario no tendrá que apuntar los teléfonos de contacto uno a uno, ya que podrá acceder a la
agenda tradicional que tienen el dispositivo (Figura 28), y buscar y seleccionar uno de los
contactos almacenados en su dispositivo móvil. Al dar click en la icono en forma de lupa que se
encuentra a la izquierda del campo de texto, aparecerá la agenda de contactos que tiene por
defecto Andoid, una vez encontrado el contacto deseado, el usuario deberá seleccionarlo y de
manera automática, aparecerá en el campo de texto “contacto de emergencia” (Figuras 27 y 28).
Figura 27. Selección de los contactos de emergencia.
Figura 28. Configuraciones de llamadas.
Después de seleccionar los teléfonos de contacto, el usuario tendrá la posibilidad de seleccionar
los medios que empleará el programa para contactar con él o los contactos de emergencia. El
usuario podrá seleccionar si en caso de una caída se procederá a llamar a algún contacto en
particular, o si se enviara un mensaje de texto con información relevante del suceso.
Al igual que la ventana de configuraciones del usuario, la ventana de configuraciones del programa
valida que todos los datos hayan sido diligenciados y que la información suministrada sea válida;
en caso de que la información no estuviera completa o fuese invalida, se mostrara una
advertencia y regresara a la pantalla para que el usuario pueda modificar los datos incorrectos
(Figura 29).
Figura 29. Advertencia de datos incompletos.
Figura 30. Configuraciones del programa.
Si todos los datos del formulario están diligenciados con sus respectivos formatos válidos y la
contraseña ingresada corresponde a la contraseña del usuario, los datos se actualizarán, y se
notificara al usuario de la posibilidad de continuar con los pasos correspondientes a la
configuración y calibración del sensor (Figura 30).
9.7. Configuraciones del Acelerómetro.
La configuración del sensor (Figura 31) es una opción que permite tomar el valor del sensor actual
en reposo, para poder realizar una comparación y una normalización de los valores. Esto permite
que las medidas se ajusten a los valores y posibles defectos que posea el sensor.
Este paso no es estrictamente necesario, pero garantiza una precisión mayor a la hora de ejecutar
el algoritmo detector de caída. En caso de que este paso sea omitido, se toma como valor base el
valor por defecto de la aceleración.
Para esta configuración, el dispositivo toma una cantidad significativa de muestras en un lapso de
10 segundos y halla el valor promedio de estas. Para realizar la calibración se lanza una actividad
nueva en forma de ventana emergente, en la que muestran los valores que el sensor lee en
tiempo real (Figura 31).
Figura 31. Proceso de calibración del sensor.
Para poder obtener un valor valido, es necesario que el smartphone se encuentre en posición
horizontal (acostado con la pantalla hacia arriba) y permanezca así el tiempo que dure la
calibración. La calibración puede ser interrumpida con el botón cancelar, regresando la aplicación
a la ventana de instrucciones de calibración, e informando la invalidez de la muestra.
Figura 32. Error de calibración de los sensores.
Figura 33. Acelerómetro calibrado de manera satisfactoria.
Si el proceso de calibración es interrumpido o el valor obtenido del proceso es un valor no valido,
el dispositivo queda en estado “no calibrado” y mostrará el mensaje “Error de calibración” (Figura
32). De manera contraria, si el proceso termina de manera satisfactoria y el valor de calibración es
un valor dentro del rango de valores validos de calibración, el programa mostrará en pantalla el
valor calculado y a su vez, cambia el estado del programa mostrando el mensaje “Programa
calibrado: SI” (Figura 33).
Este valor será fijado como el valor base y se utilizara como el valor inicial del algoritmo de
detección de caídas.
9.8. Ubicación geográfica y mapas del aplicativo
El dispositivo cuenta con una opción especial de ubicación y posicionamiento geográfico. Para esta
opción, es necesario que el dispositivo posea un sistema de posicionamiento global (GPS) y que a
su vez éste esté activo. Los mapas que utiliza la aplicación corresponden al servicio suministrado
por Google maps y para su visualización, es necesaria una conexión a internet, de lo contrario el
usuario debe haber descargado previamente la zona desea a visualizar, desde la opción de mapas
guardados en la aplicación Google maps.
El usuario tendrá la posibilidad de escoger tres posiciones distintas que se pueden seleccionar con
los botones ubicados en la parte inferior, estos botones centraran el mapa, en las posiciones
almacenadas por el usuario. Las posiciones disponibles son: la posición de la casa o lugar de
contacto, la posición del centro médico o centro de servicio y la posición actual del dispositivo.
Cualquier mapa seleccionado por el usuario se visualizara en con el formato satelital provisto por
Google maps.
Al acceder al mapa de posición actual (Figura 34), éste cambia en tiempo real, mostrando cual es
la posición actual del dispositivo. A su vez, el dispositivo va almacenando las coordenadas
geográficas de este punto, para utilizarlas al momento de tener que informar o enviar a otros
dispositivos la ubicación exacta del accidente.
Figura 34. Ubicación geográfica posición actual.
Figura 35. Ubicación geográfica del hospital o centro médico.
Al acceder al mapa de ubicación del centro médico u hospital habitual del paciente (Figura 35),
éste muestra la ubicación de este centro médico para que el paciente pueda ser asistido y
remitido en caso de ser auxiliado por una persona que no lo conoce. El manejo y la asignación de
estos puntos son opcionales y el usuario determinara si considera o no conveniente la marcación
de estas ubicaciones.
La ubicación de la residencia del paciente o contacto de emergencia (Figuras 36 y 37), es
netamente informativa y opcional. La agregación o no de esta, no afecta en absoluto el
funcionamiento normal del algoritmo y de la aplicación en general; simplemente muestran un
punto de referencia en donde el paciente puede ser remitido y en donde pueda encontrar algún
tipo de auxilio en caso de encontrarse en un estado estable de salud.
Al utilizar el Proveedor de contenidos de Google maps, la pantalla proporciona todas las
funcionalidades soportadas por la herramienta tales como: formas de llegar, rutas disponibles,
distancia y tráfico, etc.
Figura 36. Marcación de la ubicación del hogar o ubicación del contacto.
Figura 37. Ampliación ubicación del hogar o ubicación del contacto.
9.9. Pruebas de los sensores
Pruebas de los sensores es una actividad diseñada para que el usuario pueda confirmar si el
dispositivo actual de donde está utilizando la aplicación, cuenta con los sensores necesarios para
el correcto funcionamiento del programa.
Los sensores que utilizan el algoritmo de detención de caídas son el acelerómetro y el giroscopio.
La pantalla muestra los dos sensores con los valores que están obteniendo en tiempo real (Figura
38). En caso de que el dispositivo no cuente con los dos sensores, o no estén activados como
puede ser el caso de la versión 6.0 de Android, el icono tendrá sobre puesto un signo indicando su
ausencia, y mostrara el texto “no value” en lugar de sus respectivas medidas de sensado. Al dar
click en la imagen del sensor, la aplicación se dirigirá a una actividad en donde mostrará en tiempo
real la gráfica de la norma del sensor seleccionado (Figura 39).
Figura 38. Valores actuales de los sensores que posee el dispositivo del usuario.
Figura 39. Grafica en tiempo real de la norma del sensor acelerómetro.
9.10. Llamada y solicitud de emergencia.
Llamada y solicitud de emergencia, es otra de las pantallas de la aplicación que presentan una
funcionalidad extra y opcional de la misma. Con esta actividad se puede realizar los llamados de
emergencia de manera manual, así el usuario podrá realizar la notificación de una caída o de algún
otro tipo de emergencia. Las opciones con las que cuenta esta funcionalidad son: llamada al
contacto de emergencia 1, el cual corresponde al contacto del familiar o acudiente del paciente, la
llamada a doctor o personal encargado, que hace referencia al contacto de emergencia 2, la
llamada de emergencia, que realiza una llamada directamente a un hospital o a una ambulancia y
la opción enviar mensaje, que genera un mensaje de notificación de accidente o caída, junto con
las coordenadas de la ubicación actual del paciente (Figura 40).
Para la llamada y los mensajes a los contactos de emergencia, la aplicación procede a realizarlos
inmediatamente si se selecciona la opción, sin embargo, para la llamada de emergencia a la
ambulancia, se despliega una ventana de confirmación, advirtiendo de lo serio que resulta realizar
esta acción y pidiéndole al usuario una confirmación, si está seguro o no de proceder con la acción
solicitada (Figura 41).
Figura 40. Ventana de contactos "manual".
Figura 41. Advertencia de confirmación llamado emergencia.
9.11. Notificaciones en la barra de estados.
La aplicación genera notificaciones en la barra de estado del celular, para alertar al usuario de
algún tipo de evento de suma importancia. Esta barra tiene la propiedad de persistir aun cuando la
aplicación este cerrada o aparentemente desactivada y al seleccionarla puede redirigir al usuario a
la funcionalidad que necesita de su atención. Los dos eventos importantes que se lanzan en esta
barra corresponden al inicio del servicio y la detección de una caída.
Con el inicio del servicio, la aplicación empieza a ejecutar el algoritmo de detección de caídas, en
este momento, la aplicación podría ser cerrada y la funcionalidad de almacenamiento de datos y
detección de eventos seguiría trabajando por abajo del sistema. La notificación permite al usuario
informar de éste estado de activación y seleccionarlo en el momento en que se desee detener el
servicio (Figura 42).
La segunda notificación se presenta cuando la aplicación detecta una caída. La aplicación lanza la
notificación como el inicio de una cadena de eventos que ocurren cuando el dispositivo se
encuentra en un estado de emergencia (Figura 43).
Figura 42. Notificación del lanzamiento del servicio.
Figura 43. Notificación de la detección de una caída.
9.12. Persistencia de los registros del detector de caídas.
Una vez la aplicación lanza el servicio de detección de caídas y el algoritmo entra en
funcionamiento, de manera paralela la aplicación persiste los datos registrados de cada uno de los
ejes del acelerómetro; Cada vez que el sensor registra una actualización de datos, se realiza un
llamado al método encargado escribir en un archivo txt la información detallada de los eventos,
con la hora exacta en la que ocurrieron.
El programa genera un archivo txt por cada día en el que el servicio de detección de caídas es
activado (Figura 44), el archivo es almacenado en la memoria externa del dispositivo y el nombre
con el que se almacena corresponde al día en el que el servicio fue iniciado.
El objetivo de generar este archivo de almacenamiento, es brindar la información necesaria para
permitir el análisis posterior de los datos obtenidos de manera precisa. Esto con el objetivo de
poder encontrar patrones o de prevenir accidentes futuros. Esta funcionalidad permite también
que los datos de análisis no sean ocultados u omitidos y que se pueda tener un control completo
de las actividades y eventos del paciente.
Figura 44. Archivos de texto almacenados.
Figura 45. Almacenamiento de los datos del sensor.
El documento que genera el programa es un archivo txt, ya que este tipo de archivos son ligeros y
permiten ser analizados e importados por cualquier software de análisis y traficación de datos. El
formato con que se guarda cada línea del documento contiene la información de cada eje del
sensor acelerómetro, la norma (con la cual se determina si hay algún tipo de impacto), la hora, la
posición exacta del dispositivo y una banderilla final para la lectura del cambio de muestra (Figura
45). Si en cualquier momento de la medición el algoritmo detecta una caída, se imprime una línea
adicional informando del suceso, eso con el fin de poder identificar la sección precisa del
acontecimiento.
9.13. Lanzamiento del servicio integrado a la aplicación.
Ya que es prescindible que la aplicación funcione en todo momento y que ésta no debe detenerse
al momento de cerrarse ni al momento de minimizar la pantalla, se decidió crear un servicio
propio encargado de analizar y almacenar los datos del sensor. Este servicio funciona de manera
interna, por debajo de las aplicaciones que se encuentran en primer plano; se encarga del
monitoreo, el análisis, las notificaciones y el proceso de persistencia de los sensores.
Figura 46. Proceso del servicio activo.
Para garantizar que la aplicación ya está corriendo, se puede confirmar su ejecución de dos
manera, la primera en la barra de estado superior de Android, en donde se encuentra la
notificación de la ejecución del servicio (Figura 42), o dirigiéndose directamente a la sección de
“aplicaciones en uso” del menú de configuración del sistema, en donde encontrará la información
completa del servicio empleado por la aplicación, con el tiempo de ejecución y la cantidad de
memoria que emplea (Figura 46).
9.14. Mensajes y llamadas de alerta.
Una vez el usuario acepta la realización de la llamada o el envío del mensaje de aviso a un
contacto de manera manual empleando la actividad “llamada y solicitud de emergencia” (Figura
40), o en el momento en que la aplicación por medio de su algoritmo ha detectado una caída o un
evento que indica un potencial riesgo físico, el dispositivo procede de manera automática a
contactar los teléfonos de emergencia previamente añadidos por el usuario.
La aplicación procede a ejecutar los métodos encargados de comunicarse con los contactos de
emergencia. Las acciones que emplea la aplicación son determinadas por las opciones que el
usuario habilito en la pantalla “configuración del programa” (Figura 28). Si la selección fue la
llamada al contacto de emergencia, el aplicativo procede a realizar la marcación al contacto
previamente seleccionado; si el usuario habilito las dos opciones referentes a llamada (llamada
contacto emergencia 1 y llamada contacto de emergencia 2), se realiza la primer llamada al
contacto de emergencia 1 y pasados 5 minutos se ejecuta la segunda llamada al contacto de
emergencia 2 (Figura 47).
Figura 47. Llama de emergencia al seleccionar el contacto o al detectar una
caída.
Figura 48. Formato del mensaje a enviar con la posición actual del paciente.
Si el usuario adicionalmente añadió la opción de envió de mensaje de emergencia, el dispositivo
creara un mensaje de texto informando al contacto seleccionado para este procedimiento del
acontecimiento, con la ubicación actual del paciente (Figura 48).
9.15. Persistencia de las opciones y configuraciones del usuario.
La información que el usuario emplee para la configuración de la aplicación, se almacena y se
persiste en la memoria interna del celular; así en el momento en que el usuario ingrese sus
credenciales de identificación, se cargaran de manera automática los valores almacenados en cada
uno de los respetivos formularios.
La aplicación permite crear la cantidad de usuarios que se desee limitando este número
únicamente por la capacidad de almacenamiento del dispositivo. Por cada usuario creado se
añadirá un documento xml (Figura 49), que contendrá todos los datos almacenados con antelación
(Figura 50).
Figura 49. Archivos preference con los datos de configuración.
Figura 50. Almacenamiento de los datos del usuario.
10. ALGORITMO DE DETECCIÓN DE CAÍDAS.
Inicialmente el algoritmo se centra en la recolección de los datos del acelerómetro y del
giroscopio. Estos datos son almacenados de manera provisional en una matriz, que se utiliza para
conocer los eventos previos y posteriores de una presunta caída. El análisis de los datos previos y
sobre todo los posteriores, son prescindibles para determinar si hubo o no una verdadera caída,
permitiendo eliminar un gran número de falsos positivos.
Lo primero que el algoritmo busca, es un evento de fuerte aceleración o de impacto, o en el cual y
sin importar la dirección, indica que el usuario pudo haber sido expuesto a un golpe o un cambio
brusco de posición; este primer filtro nos garantiza que el paciente no realizó un cambio de
posición voluntaria y que es posible que haya tenido una caída. En caso que el algoritmo no haya
detectado el aumento brusco de aceleración, retornara a estado de “análisis de datos” y
comenzara el proceso de nuevo (Figura 51).
Figura 51. Pasos para la detección de caídas
Ya que el dispositivo móvil se puede encontrar en cualquier dirección, la posición inicial con la que
se hacen las comparaciones y se toman los valores de referencia, varía y se ajusta a los
movimientos naturales del usuario; por esta razón es recomendable realizar una previa calibración
de los sensores (Figura 31) para obtener un análisis más preciso y exacto.
Una vez el algoritmo en su proceso de análisis encuentra un impacto o un cambio de aceleración,
el algoritmo comienza a analizar los datos previos y posteriores al punto de impacto t=0. En este
proceso se comienza un análisis de cada uno de los valores de la matriz temporal de aceleraciones,
asignando unos pesos dependiendo de la posición del dato, dándole más prioridad a los valores
cercanos al origen y por consiguiente más recientes al impacto.
Una de las cosas que se analiza en el estado “Análisis datos post caídas”, es el cambio de posición
del dispositivo, ya que si el usuario recibió un impacto y su posición corporal se mantuvo, se puede
descartar en gran medida la presencia de una caída.
El cambio de posición del dispositivo se puede determinar con el análisis de los vectores de
aceleración de cada uno de los ejes. Si el dispositivo no detecta el cambio de posición en un
tiempo prudente posterior al impacto, determina que no se presentó ningún tipo de caída,
retornando nuevamente al estado inicial de análisis y reiniciando los datos y valores de los eventos
previos (Figura 51, Figura 52).
Figura 52. Diagrama de flujo del servicio de detección de caídas.
El algoritmo de detección de caídas está implementado en el servicio “FallRegister”, este servicio
es iniciado cuando el usuario arranca la actividad “Inicio detección” y es llamado por su método de
arranque tradicional. El proceso de detección y el algoritmo de análisis, estarán en un continuo
sensado y almacenamiento desde el instante en que el método ha sido ejecutado, hasta el
momento en que el usuario determine detenerlo por medio de la opción integrada a la aplicación.
Así el usuario cierre la aplicación o la ubique en segundo plano, el proceso continuara activo
(Figura 52).
Para evitar y controlar en número falsos positivos, el usuario dispondrá de 30 segundos para
cancelar de forma manual el proceso de notificación y envió de alertas. Sin embargo, esta acción
únicamente cancela las notificaciones, pero la presunta caída o el falso positivo será almacenado y
registrado en la persistencia de la aplicación, en donde se podrá realizar un correcto seguimiento e
investigación del suceso. De esta manera, así el paciente decida cancelar la notificación
instantánea, la persona que lleva el control y seguimiento, seguirá al tanto de todo lo ocurrido
(Figura 53).
Figura 53.Diagrama de flujo Eliminación manual de falsos positivo.
Ya que el usuario dispone de más de una forma de notificación y todas estas no se pueden realizar
de una manera simultánea, la aplicación posee un algoritmo que determina el orden y los tiempos
de ejecución de cada una de las alertas. De esta manera, se garantiza que se realicen las
respectivas notificaciones a todas las personas seleccionadas (Figura 54).
Para el proceso de la ubicación y el uso del servicio de Google Maps, la aplicación procede a
verificar si el dispositivo tiene activo el GPS. En caso de que GPS se encuentre activo, la aplicación
procede a obtener los datos de la ubicación actual del paciente para dibujarla junto con las
posiciones de contacto previamente almacenadas por el usuario (Figura 55).
Figura 54.Diagrama de flujo orden y ejecución de notificaciones.
Figura 55.Diagrama de flujo funcionalidad ubicaciones geográficas.
11. RESULTADOS
11.1. Saltos
En esta prueba el usuario realiza un salto procurando caer en el la misma posición de inicio.
Prueba n° 1 2 3 4 5 6 7 8 9 10
Acierto SI SI SI SI SI SI SI SI SI SI
Prueba n° 11 12 13 14 15 16 17 18 19 20
Acierto SI SI SI SI SI SI SI SI SI SI
Prueba n° 21 22 23 24 25 26 27 28 29 30
Acierto SI SI SI SI SI SI SI SI SI SI
Tabla 4. Prueba de saltos.
11.2. Detención forzada
El usuario avanza a gran velocidad y realiza una detección instantánea.
Prueba n° 1 2 3 4 5 6 7 8 9 10
Acierto SI SI SI SI SI SI SI SI SI SI
Prueba n° 11 12 13 14 15 16 17 18 19 20
Acierto SI SI SI SI SI SI SI SI SI SI
Prueba n° 21 22 23 24 25 26 27 28 29 30
Acierto SI SI SI SI SI SI SI SI SI SI
Tabla 5. Prueba de detención forzada.
11.3. Sentada
El usuario se sienta, de la manera tradicional, con diferentes velocidades.
Prueba n° 1 2 3 4 5 6 7 8 9 10
Acierto SI SI SI SI SI SI SI SI SI SI
Prueba n° 11 12 13 14 15 16 17 18 19 20
Acierto SI SI SI SI SI SI SI SI SI SI
Prueba n° 21 22 23 24 25 26 27 28 29 30
Acierto SI SI SI SI SI SI SI SI SI SI
Tabla 6. Prueba donde el usuario se sienta.
Figura 56. Grafica de aciertos pruebas de salto, sentada y detección forzada.
11.4. Acostarse
El usuario se acuesta sobre la cama, evitando la brusquedad.
Prueba n° 1 2 3 4 5 6 7 8 9 10
Acierto SI SI NO SI SI SI NO SI SI SI
Prueba n° 11 12 13 14 15 16 17 18 19 20
Acierto SI NO SI NO SI SI SI NO NO SI
Prueba n° 21 22 23 24 25 26 27 28 29 30
Acierto SI SI NO SI SI SI SI NO SI SI
Tabla 7. Prueba donde el usuario se acuesta.
Figura 57. Grafica de aciertos prueba" acostada".
0
100%
Prueba de saltos, detención forzada y sentada
Incorrecto Correcto
27%
73%
Prueba acostada
Incorrecto Correcto
11.5. Caída del usuario
El usuario simula una caída, arrojándose sobre una cama o superficie plana, de una manera
brusca.
Prueba n° 1 2 3 4 5 6 7 8 9 10
Acierto SI SI SI SI NO SI SI SI SI NO
Prueba n° 11 12 13 14 15 16 17 18 19 20
Acierto SI SI SI SI SI SI SI SI SI SI
Prueba n° 21 22 23 24 25 26 27 28 29 30
Acierto SI NO NO SI SI SI SI SI SI SI
Tabla 8. Prueba de simulación de caída del usuario.
Figura 58. Grafica de aciertos simulación de caída.
11.6. Caída del teléfono inteligente.
Se arroja el dispositivo ya sea de su posición actual o de una superficie elevada.
Prueba n° 1 2 3 4 5 6 7 8 9 10
Acierto SI NO NO SI SI SI NO SI NO SI
Prueba n° 11 12 13 14 15 16 17 18 19 20
Acierto SI SI NO SI NO SI SI NO NO SI
Prueba n° 21 22 23 24 25 26 27 28 29 30
Acierto NO SI NO NO SI NO SI SI SI NO
Tabla 9. Prueba de caída del teléfono inteligente.
13%
87%
Prueba Simulación de caída
Incorrecto Correcto
Figura 59. Grafica de aciertos, al arrojar el celular.
Para poder resumir el acierto de la aplicación se utilizara dos métodos de estimación estadística
para conocer el verdadero; la sensibilidad y la especificidad. Estas fórmulas se calcularon con los
valores de las pruebas de arrojar celular y de simulación caída, siendo estas las pruebas mas
críticas.
La sensibilidad nos indica la capacidad de nuestro estimador para dar como casos positivos
los casos realmente enfermos; proporción de enfermos correctamente identificados. Es
decir, la sensibilidad caracteriza la capacidad de la prueba para detectar la enfermedad en
sujetos enfermos.
La especificidad nos indica la capacidad de nuestro estimador para dar como casos
negativos los casos realmente sanos; proporción de sanos correctamente identificados. Es
decir, la especificidad caracteriza la capacidad de la prueba para detectar la ausencia de la
enfermedad en sujetos sanos.
La sensibilidad se define como:
Donde VP es verdaderos positivos y FN falsos negativos.
La especificidad de una prueba representa la probabilidad de que un sujeto sano tenga un
resultado negativo en la prueba. La especificidad se define como:
43%
57%
Prueba lanzar celular.
Incorrecto Correcto
Donde VN, serían los verdaderos negativos; y FP, los falsos positivos. (“Sensibilidad y
especificidad (estadística).,” 2015)
Prueba de acostada.
o Falsos positivos: 8.
o Verdaderos negativos: 22.
Prueba de acostada.
o Falsos negativos: 8.
o Verdaderos positivos: 22.
Prueba Caída teléfono.
o Falsos positivos: 13.
o Verdaderos negativos: 17.
Sensibilidad: 73%
Especificidad: 65%
Si a estos valores añadimos las pruebas de detención forzada y salto, los valores obtenidos son:
o Falsos positivos: 22.
o Verdaderos negativos: 69.
o Falsos negativos: 8.
o Verdaderos positivos: 52.
Sensibilidad: 86.6%
Especificidad: 76.6%
12. CONCLUSIONES Y TRABAJOS FUTUROS.
Después de analizar, comparar y validar los diferentes resultados arrojados por la aplicación y
realizar una comparativa, se puede encontrar que la aplicación tiene una precisión de más de 80%
en los casos estudiados. Si bien estos valores pueden ser afinados y mejorados con el mecanismo
de auto aprendizaje, el porcentaje actual es un número bastante valido y aceptable para iniciar
con el lanzamiento de la aplicación.
La sensibilidad del dispositivo es de 86.6% y la especificidad es del 76.6%, mostrando que la
aplicación es una herramienta bastante fiable, y confiable a la hora de detectar las caídas de
los usuarios. Con la aplicación final se encontraron 22 falsos positivos, 69 verdaderos
negativos, 8 falsos negativos y 52 verdaderos positivos, en total se contó con una acierto y
precisión del 81%.
Al no utilizar el sensor de giro en el algoritmo, la aplicación resulta menos precisa. Con el sensor de
giro, los resultados alcanzarían una precisión mayor a la precisión actual hasta en 7 puntos
porcentuales. Es evidente que en cuanto los dispositivos de baja y media gama empiecen a
integrarlo, el mundo de posibilidades se ampliara para esta y muchas más aplicaciones enfocadas
en la salud.
La persistencia de los datos y de los valores de los sensores, permite al usuario poder validar y
monitorear los resultados del aplicativo de manera posterior; esto permite analizar información
que puede ser ignorada en un inmediato y superficial primer análisis. Esta funcionalidad les da al
paciente y al médico, una herramienta más completa para realizar un análisis exhaustivo y preciso
de las caídas del paciente.
Al ser una aplicativo móvil tiene la ventaja de poder ser versionado y de añadir nuevas
funcionalidades con el pasar del tiempo. Además de esto, las herramientas de calificación
convierten la versión preliminar en un excelente test de pruebas, en donde los usuarios pueden
opinar y comentar de los fallos o deseos de mejora de la aplicación.
Varios de los trabajo futuros fueron contemplados en la versión actual del aplicativo, pero se
decidió terminar la versión actual de una manera escalable para completar las demás
funcionalidades después de conocer la aceptación o no del programa en el público en general.
Uno de los trabajos que se pretende realizar en una futura versión, consiste en adicionar el análisis
de la posición absoluta del paciente, para esta mejora se necesitan módulos de posicionamiento
dentro del hogar del paciente para así poder triangular la posición, determinando la ubicación
exacta en donde el usuario puede presentar dificultad de acceso o recurrencia en las zonas en las
que puede experimentar caídas.
También se ha pensado en que la aplicación pueda emigrar a un reloj inteligente, de esta manera,
se elimina la molestia de cargar el celular en todo momento. Para esto, es necesario modificar el
algoritmo e implementar uno nuevo, que tenga en cuenta las propiedades y movimiento naturales
de las manos.
A futuro se puede pensar en modificar la aplicación para poder analizar la marcha de un paciente.
Se ha demostrado en pasadas investigaciones, que la marcha de una persona, puede proporcionar
información importante del estado de salud de un paciente y que incluso, pueden encontrarse
algunas enfermedades como la artritis y el Parkinson. Esta modificación está pensada para ser
apoyada con datos médicos y pacientes reales.
13. REFERENCIAS.
47 - Archivo strings.xml. (n.d.).
ABC del acelerometro. (n.d.). Retrieved from ”http://5hertz.com/tutoriales/?p=228
Alcalde, A. (2011). Programación Android: Interfaz gráfica - Layouts.
Analisis de la marcha. (n.d.). Retrieved from http://parkinsonpulsaon.com/index.php?option=com_content&view=article&id=512%3Aanalisis-de-la-marcha-en-la-enfermedad-de-parkinson&Itemid=98
Antonio Luque Estepa. (2014). ESTUDIO DE MODELOS MATEMÁTICOS DE ACELERÓMETROS COMERCIALES. universidad de Sevilla.
Bai, Y. W., Wu, S. C., & Tsai, C. L. (2012). Design and implementation of a fall monitor system by using a 3-axis accelerometer in a smart phone. IEEE Transactions on Consumer Electronics, 58(4), 1269–1275. http://doi.org/10.1109/TCE.2012.6414995
Bascuñana Saiz, P. (n.d.). Los diferentes Layouts en Android.
Bash, E. (2015). Caídas en el anciano. PhD Proposal, 1(4), 1–10. http://doi.org/10.1017/CBO9781107415324.004
Cao, Y., Yang, Y., & Liu, W. H. (2012). E-FallD: A fall detection system using android-based smartphone. Proceedings - 2012 9th International Conference on Fuzzy Systems and Knowledge Discovery, FSKD 2012, (Fskd), 1509–1513. http://doi.org/10.1109/FSKD.2012.6234271
Chan, H., Zheng, H., Wang, H., & Sterritt, R. (2012). Evaluating and overcoming the challenges in utilizing smart mobile phones and standalone accelerometer for gait analysis.
Chen, E. Y., & Itoh, M. (2010). Virtual smartphone over IP. 2010 IEEE International Symposium on “A World of Wireless, Mobile and Multimedia Networks”, WoWMoM 2010 - Digital Proceedings. http://doi.org/10.1109/WOWMOM.2010.5534992
Componentes de una aplicación Android. (2010).
CORREIRA Claudia, E. M. C. (2009). Tratamiento de la artritis reumatoidea. Revista De Posgrado De La Via De Catedra De Medicina, 173(3213), 7–9. Retrieved from artritis reumatoidea, tratamiento, calidad de vida.
Diseñar Temas y Estilos para tus Aplicaciones Android. (n.d.).
Doukas, C., & Maglogiannis, I. (2008). Advanced patient or elder fall detection based on movement and sound data. Proceedings of the 2nd International Conference on Pervasive Computing Technologies for Healthcare 2008, PervasiveHealth, 103–107. http://doi.org/10.1109/PCTHEALTH.2008.4571042
Durán, F., Gutíerrez, F., & Pimentel, E. (2007). Programación orientada a objetos con Java (1ra ed). España: Thomson.
Feng, G., & Lin, Q. (2010). Design of elder alarm system based on body posture reorganization. In Proceedings - 2010 International Conference on Anti-Counterfeiting, Security and Identification, 2010 ASID (pp. 249–252).
García Llinás, L. F. (2010). Programación orienta a objetos en Java. Ediciones Uninorte.
González Sánchez, R., Rodríguez Fernández, M., Ferro Alfonso, M., & García Milián, J. (1999a). Actualidad Caídas En El Anciano. Consideraciones Generales Y Prevención. Rev Cubana Med Gen Integr, 15(1), 98–102.
González Sánchez, R., Rodríguez Fernández, M., Ferro Alfonso, M., & García Milián, J. (1999b). Caídas En El Anciano. Consideraciones Generales Y Prevención. Rev Cubana Med Gen Integr, 15(1), 98–102.
Google Maps. (2016).
Gortázar, F., Martínez, R., & Fernández, V. (2016). Lenguajes de programación y procesadores. Editorial Centro de Estudios Ramon Areces SA.
Harbert, S. D., Jaiswal, T., Harley, L. R., Vaughn, T. W., & Baranak, A. S. (2013). Mobile Motion Capture - MiMiC. Proceedings of the Annual International Conference of the IEEE Engineering in Medicine and Biology Society, EMBS, 3435–3438. http://doi.org/10.1109/EMBC.2013.6610280
Java (lenguaje de programación). (n.d.).
Jogan, L. nn, & Olsson, J. (2005). Zigbee for wirless networking. Linkӧ pings University.
Khan, Z. A., & Sohn, W. (2011). Abnormal human activity recognition system based on R-transform and kernel discriminant technique for elderly home care. IEEE Transactions on Consumer Electronics, 57(4), 1843–1850.
Kwon, S., Jamal, M., Zamba, G. K. D., Stumbo, P., & Samuel, I. (2010). Validation of a novel physical activity assessment device in morbidly obese females. Journal of Obesity, 2010. http://doi.org/10.1155/2010/856376
Lázaro del Nogal; Montserrat. (2008). Caídas en el anciano: diagnóstico y tratamiento. Elservier Doyma, 1–4. http://doi.org/10.1016/Co
López Carro, R. (n.d.). Codermasters: Iniciación a Java.
Mayté Vera Sánchez, R. C. M. (2003). Evaluación de la marcha y el equilibrio como factor de riesgo en las caídas del anciano. Revista Cubana de Medicina General Integral, 19(5), 1–6.
Miura, K., Ohtaki, Y., & Inooka, H. (2001). Impression analysis of various humanlike gait patterns. Proceedings - IEEE International Workshop on Robot and Human Interactive Communication, 568–573. http://doi.org/10.1109/ROMAN.2001.981965
Nickel, C., Derawi, M. O., Bours, P., & Busch, C. (2011). Scenario test of accelerometer-based biometric gait recognition. Proceedings of the 3rd International Workshop on Security and Communication Networks, IWSCN 2011, 15–21. http://doi.org/10.1109/IWSCN.2011.6827712
Ohshima, H. (n.d.). Mobile display technologies: Past, present and future. In Solid-State Circuits Conference (A-SSCC), 2014 IEEE Asian (pp. 10–12).
Perc, M. M. (2005). The dynamics of human gait. European Journal of Physics, 26(3), 525–534. http://doi.org/10.1088/0143-0807/26/3/017
Posilio, I. (2013). El archivo AndroidManifest.xml.
Programación orientada a objetos. (n.d.).
Revista Medica Ortopedia. (2015). Retrieved from http://www.encolombia.com/medicina/revistas-medicas/ortopedia/vo-121/orto12198efecto/#sthash.XCyYZtbH.dpuf
Ripka, P., & Tipek, A. (2010). Modern Sensors Handbook. Modern Sensors Handbook. Wiley-ISTE.
Robinson, G., & Weir, G. R. S. (2015). Understanding android security. In Communications in Computer and Information Science (Vol. 534, pp. 189–199). Springer Verlag.
Rodríguez, A. (n.d.). Conceptos de objetos y clases en Java. Definición de instancia. Ejemplos básicos y prácticos. (CU00619B).
Ruderman Erick, T. S. (2012). Artritis Reumatoidea. Especialiasta En Cuidado De Artritis, 1(30319), 1–6. http://doi.org/10.1136/ard.15.1.80-c
Sandoval, L., Capuñay, J., & Varela, L. (1996). Caídas en el adulto mayor: estudio de una serie de pacientes de consultorio externo de medicina del Hospital Nacional Cayetano Heredia. Rev. Méd. Hered, 7(3), 119–24.
Sensibilidad y especificidad (estadística). (2015). Retrieved from https://es.wikipedia.org/wiki/Sensibilidad_y_especificidad_(estad%C3%ADstica)
Song, L., Wang, Y., Yang, J. J., & Li, J. (2015). Health sensing by wearable sensors and mobile phones: A survey. 2014 IEEE 16th International Conference on E-Health Networking, Applications and Services, Healthcom 2014, 453–459. http://doi.org/10.1109/HealthCom.2014.7001885
Tarashansky, A., Vathsangam, H., & Sukhatme, G. S. (2014). A study of position independent algorithms for phone-based gait frequency detection. Conference Proceedings : ... Annual International Conference of the IEEE Engineering in Medicine and Biology Society. IEEE Engineering in Medicine and Biology Society. Annual Conference, 2014, 5984–5987. http://doi.org/10.1109/EMBC.2014.6944992
Tolkiehn, M., Atallah, L., Lo, B., & Yang, G.-Z. (2011). Direction sensitive fall detection using a triaxial accelerometer and a barometric pressure sensor. 2011 Annual International Conference of the IEEE Engineering in Medicine and Biology Society, 369–372. http://doi.org/10.1109/IEMBS.2011.6090120
Tomas, J. (2011). Componentes de una aplicación.
Torjada, J. J. (2014). Cómo construir documentos XML: DTD y Esquema XML.
Yamada, M., Aoyama, T., Mori, S., Nishiguchi, S., Okamoto, K., Ito, T., … Ito, H. (2012). Objective assessment of abnormal gait in patients with rheumatoid arthritis using a smartphone. Rheumatology International, 32(12), 3869–3874. http://doi.org/10.1007/s00296-011-2283-2
Yang, M., Zheng, H., Wang, H., McClean, S., Hall, J., & Harris, N. (2010). Assessing Accelerometer Based Gait Features to Support Gait Analysis for People with Complex Regional Pain Syndrome. Proceedings of the 3rd International Conference on PErvasive Technologies Related to Assistive Environments, 48:1--48:7. Retrieved from http://doi.acm.org/10.1145/1839294.1839352
Yoneyama, M., Kurihara, Y., Watanabe, K., & Mitoma, H. (2014). Accelerometry-based gait analysis and its application to Parkinson’s disease assessment-Part 1: Detection of stride event. IEEE Transactions on Neural Systems and Rehabilitation Engineering, 22(3), 613–622. http://doi.org/10.1109/TNSRE.2013.2260561
Zhang, S., Li, H., McCullagh, P., Nugent, C., & Zheng, H. (2013). A real-time falls detection system for elderly. 2013 5th Computer Science and Electronic Engineering Conference, CEEC 2013 - Conference Proceedings, 51–56. http://doi.org/10.1109/CEEC.2013.6659444