Desarrollo de un sistema de detección de caídas basado en acelerómetros
Abstract
Este proyecto tiene como finalidad el desarrollo de un sistema de detección de caídas para personas de edad avanzada basado en el uso de acelerómetros. El 30 % de los mayores se cae una vez al año y estas caídas causan el 70 % de los accidentes mortales en el colectivo de personas mayores de 75 años. Por esta razón, se pretende realizar un sistema fiable y que ofrezca una respuesta de emergencia efectiva, así como un sistema poco intrusivo y fácil de usar. Inicialmente, se realizó un análisis de los sistemas de este tipo propuestos o existentes en el mercado, con el objetivo de detectar las carencias de los mismos, así como identificar los requisitos a implementar en el sistema. La monitorización de las actividades y caídas tanto en el Virtual Living Lab AIDE como en el despliegue real del sistema permitió diseñar el algoritmo de detección. Este algoritmo se integra en un sistema compuesto por un dispositivo detector portable desarrollado sobre el microordenador Beaglebone Green. El dispositivo, poseedor de la autonomía y conectividad requeridos, está pensado para ser llevado sujeto a la cintura. Como parte de la respuesta de emergencia, se crearon dos aplicaciones Android. Una de ellas ideada para usuarios que vivan solos y la otra para los que estén acompañados de una persona encargada de su cuidado. El sistema persigue favorecer la autonomía de una persona que cuida a otra, pero también la de la persona cuidada. Mediante la monitorización no intrusiva, se consigue que la persona cuidada se sienta menos dependiente y tenga menos miedo, pues, si se cae, el sistema avisará a quien tenga que hacerlo. En el diseño de este sistema ha sido relevante contemplar ciertos aspectos particulares sobre el tipo de usuario final al que iba dirigido, que era, principalmente, personas mayores. Esto ha condicionado el aspecto de la interfaz y el diseño físico del aparato. Sobre todo, ha condicionado la interacción, siendo el objetivo requerir el menor número de acciones posible. El sistema se probó con los tipos de caída más frecuentes que son las frontales, traseras y laterales, lográndose un índice de acierto aproximado del 90’78 %, constituyendo un primer resultado prometedor. Aparte de mejorar el ratio de aciertos, se pueden llegar a alcanzar otros hitos como un diseño más ergonómico o el refinamiento del algoritmo de detección de caídas. Se espera que este proyecto contribuya de manera notable al ámbito de la detección automática de caídas, ya sea mediante la publicación del sistema o por la recopilación de información.
Full text
Desarrollo de un sistema de detección de caídas basado en acelerómetros Raquel González Vega Raúl Hernández Bretones Beatriz Jiménez del Olmo Dirigido por: Jorge Jesús Gómez Sanz Trabajo de fin de grado del Grado en Ingeniería Informática y Grado en Ingeniería del Software Facultad de Informática Universidad Complutense de Madrid Curso 2015-2016 13 de junio de 2016
2
AUTORIZACIÓN PARA LA DIFUSIÓN DEL TRABAJO FIN DE GRADO Y SU DEPÓSITO EN EL REPOSITORIO INSTITUCIONAL E-PRINTS COMPLUTENSE Los abajo firmantes, alumnos y tutor del Trabajo Fin de Grado (TFG) en el Grado en Ingeniería Informática y Grado en Ingeniería del Software de la Facultad de Informática, autorizan a la Universidad Complutense de Madrid (UCM) a difundir y utilizar con fines académicos, no comerciales y mencionando expresamente a su autor el Trabajo Fin de Grado (TFG) cuyos datos se detallan a continuación. Así mismo autorizan a la Universidad Complutense de Madrid a que sea depositado en acceso abierto en el repositorio institucional con el objeto de incrementar la difusión, uso e impacto del TFG en Internet y garantizar su preservación y acceso a largo plazo. Título del TFG: Desarrollo de un sistema de detección de caídas basado en acelerómetros Curso académico: 2015/2016 Nombre de Alumnos: Raquel González Vega Raúl Hernández Bretones Beatriz Jiménez del Olmo Tutor del TFG y departamento al que pertenece: Jorge J.Gómez Sanz Ingeniería del Software e Inteligencia Artificial Firma de alumnos Firma del tutor
Este trabajo ha sido posible gracias a los medios y resultados científicos de los proyectos “SOCIAL AMBIENT ASSISTING LIVING - METHODS (SociAAL)” TIN2011-28335-C02-01, “Collaborative Ambient Assisted Living Design (ColoSAAL)” TIN2014-57028-R financiados por el Ministerio de Economía y Competitividad del gobierno de España; y MOSI-AGIL-CM (S2013/ICE3019) co-financiado por el gobierno de la Comunidad de Madrid y Fondos Estructurales Europeos FSE, and FEDER. Raquel, Raúl y Beatriz A mis padres Ángel y Ana Isabel, a mi hermana Sara y a mi pareja Coro por estar siempre conmigo y ayudarme en los momentos más difíciles. Raquel A mi familia por el apoyo, y por estar detrás de mi acabando con la pereza. A mis amigos por las infinitas cervezas que me han ayudado a sobrevivir durante cuatro largos años. Y a mi querida petarda por una felicidad que no se paga con dinero. Raúl A toda la gente que siempre ha confiado en mi y especialmente a mis padres Marta y Pepe y a mi gran apoyo Nuria. Bea A todos los que creyeron en nosotros, a nuestros amigos por los buenos momentos durante todos estos años. Raquel, Raúl y Beatriz 5
Resumen Este proyecto tiene como finalidad el desarrollo de un sistema de detección de caídas para personas de edad avanzada basado en el uso de acelerómetros. El 30% de los mayores se cae una vez al año y estas caídas causan el 70 % de los accidentes mortales en el colectivo de personas mayores de 75 años. Por esta razón, se pretende realizar un sistema fiable y que ofrezca una respuesta de emergencia efectiva, así como un sistema poco intrusivo y fácil de usar. Inicialmente, se realizó un análisis de los sistemas de este tipo propuestos o existentes en el mercado, con el objetivo de detectar las carencias de los mismos, así como identificar los requisitos a implementar en el sistema. La monitorización de las actividades y caídas tanto en el Virtual Living Lab AIDE como en el despliegue real del sistema permitió diseñar el algoritmo de detección. Este algoritmo se integra en un sistema compuesto por un dispositivo detector portable desarrollado sobre el microordenador Beaglebone Green. El dispositivo, poseedor de la autonomía y conectividad requeridos, está pensado para ser llevado sujeto a la cintura.Como parte de la respuesta de emergencia, se crearon dos aplicaciones Android. Una de ellas ideada para usuarios que vivan solos y la otra para los que estén acompañados de una persona encargada de su cuidado. El sistema persigue favorecer la autonomía de una persona que cuida a otra, pero también la de la persona cuidada. Mediante la monitorización no intrusiva, se consigue que la persona cuidada se sienta menos dependiente y tenga menos miedo, pues, si se cae, el sistema avisará a quien tenga que hacerlo. En el diseño de este sistema ha sido relevante contemplar ciertos aspectos particulares sobre el tipo de usuario final al que iba dirigido, que era, principalmente, personas mayores. Esto ha condicionado el aspecto de la interfaz y el diseño físico del aparato. Sobre todo, ha condicionado la interacción, siendo el objetivo requerir el menor número de acciones posible. El sistema se probó con los tipos de caída más frecuentes que son las frontales, traseras y laterales, lográndose un índice de acierto aproximado del 90’78%, constituyendo un primer resultado prometedor. Aparte de mejorar el ratio de aciertos, se pueden llegar a alcanzar otros hitos como un diseño más ergonómico o el refinamiento del algoritmo de detección de caídas. Se espera que este proyecto contribuya de manera notable al ámbito de la detección automática de caídas, ya sea mediante la publicación del sistema o por la recopilación de información. Palabras clave: Detección de caídas, Alertas, Acelerómetro, Aplicación Android, Ingeniería de Sistemas, Internet de las cosas, Inteligencia Ambiental. 7
Abstract The purpose of this project is the development of an accelerometer based fall detection system, targeting as users the elderly population. Almost the 30% of the elder fall once a year at least, and these accidents cause the 70% of fatal accidents among people older than 75. Because of this, it is intended to create a reliable system that offers an effective emergency response, as well as a non-intrusive and user-friendly system. Initially, a research into similar systems that were proposed or commercialized was made, detecting their lacks and our system’s requirements as it’s goal. Virtual monitoring of Activity Daily Living and fall stats into AIDE Virtual Living Lab as well as data retrieved from real-life deployment allowed us to design the basis of the fall detection algorithm. This algorithm runs into a system composed by a detection device developed over BeagleBone Green micro-computer. This self-sufficient device that has the required connection protocol, is designed to be attached to the user’s waist. As a part of the emergency response, two Android applications were created. One of them targets people that live on it’s own. The other application targets people in company of a caretaker. The system goal is to improve a caretaking person’s autonomy, also the person he is taking care of’s. Using non-intrusive monitoring, patient’s feel of being dependant is reduced, also his fear of falling, because if it happens, the system itself will warn everyone that has to be. It has been relevant to have acknowledge of certain particular aspects about the final user chosen, elderly people, in order to design this system. This has conditioned the created user interface and the apparatus’ physical design. Most important, it has conditioned user’s interaction, having as a goal to minimize the user’s actions needed. This system was tested with the most frequent kinds of falling, like frontal, backwards and lateral falls, achieving an approximate success rate of 90’78 %, which is a promising result. Apart from improving the hit ratio, as future work it is intended to improve the ergonomy of the system and to refine the fall detection algorithm. It is expected that this project contributes to fall detection scope significantly, as if the system is published or just having the information compilated. Keywords: Fall detection, Alerts, Accelerometer, Android applications, System Engineering, Internet of Things, Ambient Intelligence 9
6.12. Diagrama de flujo del algoritmo propuesto. . . . . . . . . . . 131 9.1. Pantalla principal de MIDS Assistant. . . . . . . . . . . . . . 145 9.2. Sincronización de MIDS Assistant con el dispositivo detector. 146 9.3. Reconexiones en MIDS Assistant. . . . . . . . . . . . . . . . . 147 9.4. Aviso recibido por MIDS Assistant cuando no está habilitado elWi-Fi...............................147 9.5. Pantalla contactos en MIDS Assistant. . . . . . . . . . . . . . 148 9.6. Pantalla de añadir contactos en MIDS Assistant. . . . . . . . 148 9.7. Mensajes de error en MIDS Assistant añadiendo contactos . . 149 9.8. Añadiendo contactos en MIDS Assistant. . . . . . . . . . . . . 150 9.9. Lista de opciones disponibles en MIDS Assistant. . . . . . . . 151 9.10. Respuesta de emergencia en MIDS Assistant. . . . . . . . . . 152 9.11. Aplicación MIDS Assistant en modo Alta accesibilidad. . . . 153 9.12. Aplicación MIDS Caretaker . . . . . . . . . . . . . . . . . . . 154 9.13.SDAySCL.............................155 9.14. Master-Slave. . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 16
Indice de tablas 3.1. Clasificación según situación de los sensores y actuadores. . . 29 3.2. Ventajas e inconvenientes de los sistemas basados en monitorización del entorno. . . . . . . . . . . . . . . . . . . . . . . . 31 3.3. Ventajas e inconvenientes del sistema desarrollado por Tunstall. 33 3.4. Ventajas e inconvenientes del sistema Kinect. . . . . . . . . . 35 3.5. Ventajas e inconvenientes del sistema propuesto por la Universidad de Toronto. . . . . . . . . . . . . . . . . . . . . . . . 37 3.6. Ventajas e inconvenientes del sistema Vigi’Fall. . . . . . . . . 39 3.7. Ventajas e inconvenientes de los sistemas basados en dispositivosportátiles........................... 40 3.8. Ventajas e inconvenientes del sistema Wagyromag. . . . . . . 42 3.9. Ventajas e inconvenientes del sistema red GSM. . . . . . . . . 44 3.10. Ventajas e inconvenientes del sistema Angel4. . . . . . . . . . 46 3.11. Ventajas e inconvenientes del sistema Wiimote. . . . . . . . . 48 3.12. Ventajas e inconvenientes del sistema Speedy. . . . . . . . . . 50 3.13. Valoración del nivel de cumplimiento de los requisitos mencionados en los sistemas investigados. . . . . . . . . . . . . . . 61 3.14. Comparación de las distintas placas ARM existentes en el mercado................................. 63 6.1. Rangos de valores en los tres ejes de las simulaciones realizadas.123 6.2. Rangos de valores en los tres ejes de los experimentos realizados en entorno real. . . . . . . . . . . . . . . . . . . . . . . . . 128 6.3. Máximas variaciones en valores consecutivos durante los experimentos realizados en entorno real. . . . . . . . . . . . . . 129 6.4. Tabla de valores establecidos para el algoritmo. . . . . . . . . 130 6.5. Tabla de resultados de las pruebas del sistema en ADL. . . . 132 6.6. Tabla de resultados de las pruebas del sistema en caídas. . . . 133 6.7. Paciente acompañado con únicamente el detector. . . . . . . . 134 6.8. Paciente acompañado con la aplicación MIDS Assistant sincronizada..............................135 6.9. Paciente acompañado con la aplicación MIDS Caretaker sincronizada..............................136 17
6.10. Paciente acompañado con las aplicaciones MIDS Assistant y MIDS Caretaker sincronizadas, sin detectar la caída. . . . . . 137 6.11. Paciente acompañado con las aplicaciones MIDS Assistant y MIDS Caretaker sincronizadas, detectando la caída. . . . . . . 138 6.12. Paciente únicamente con el dispositivo detector, consigue levantarse tras la caída. . . . . . . . . . . . . . . . . . . . . . . 139 18
Capítulo 1 Introducción Uno de los mayores riesgos a los que se enfrenta la población más frágil como mayores y enfermos son las caídas. Según el artículo "Detector automático de caídas y monitorización de actividad para personas mayores" de la Revista española de geriatría y gerontología [14], el 30 % de las personas mayores se cae al menos una vez al año, lo que representa el 75 % de las víctimas de caídas. También [14] indica que las caídas causan además el 70 % de los accidentes mortales en el colectivo de personas mayores de 75 años, y del incremento del miedo, la ansiedad o la depresión, lo que conduce a la reducción de la actividad diaria de ese colectivo. Estos hechos son la razón del desarrollo de varias soluciones de detección automática de caídas o de prevención, para asegurar una respuesta rápida en caso de que tal evento ocurra. Sin embargo, hoy día se utilizan pocos sistemas comerciales, debido a problemas de fiabilidad, facilidad de instalación y uso, o bien porque las personas no aceptan el dispositivo, por diversos motivos, como rechazo tecnológico o simplemente por su coste. Como resultado de estas reflexiones, la motivación principal de este proyecto será estudiar las soluciones existentes, diseñar e implementar un sistema basado en la monitorización mediante acelerómetros que detecte caídas simuladas en entornos similares a uno doméstico y posteriormente realizar un prototipo del dispositivo real. 1.1. Objetivo El objetivo principal de este trabajo consiste en crear un sistema detector de caídas basado en acelerómetros, capaz de detectar los tipos de caídas más comunes en personas mayores, intentando lograr una precisión aceptable. Por esta razón, se decidió llamar al sistema MIDS: Mobility Issues Detector 19
System. Como objetivos secundarios se plantea: experimentar con plataformas de sensores basados en microordenadores para valorar su idoneidad como elemento de prototipado rápido y comprobar la problemática de integración de tecnologías Android con Debian en un contexto de desarrollo de sistemas asistivos. 1.2. Método Para abordar estos objetivos, se enfocará el trabajo de manera progresiva en las siguientes etapas: Estudio del estado del arte: Se analizarán los distintos métodos y sistemas que existen actualmente para la detección de caídas, comparando las propiedades que presentan bajo diversas condiciones y eligiendo, finalmente, una de las aproximaciones para desarrollar la propia implementación. El análisis incluye también una valoración de tecnologías comerciales existentes. Análisis el método seleccionado: Una vez seleccionada la técnica de detección de caídas que se considere más conveniente tanto por sus resultados como por su posibilidad en el desarrollo, se analizará en detalle dicho método y posibles mejoras al mismo. Desarrollo del sistema: •Algoritmo: Definición de un algoritmo que mediante la monitorización de los valores de un acelerómetro permita distinguir situaciones cotidianas de caídas sufridas por el sujeto. •Hardware: Diseño y montaje de un dispositivo sobre el que se ejecutará el algoritmo detector de caídas. •Aplicación móvil: Implementación de una aplicación móvil sobre Android que reciba las alertas del dispositivo detector de caídas y permite notificar de estos eventos a los familiares del usuario. Evaluación de resultados: Se pretende medir la calidad del sistema generado, tanto en un entorno simulado mediante la herramienta PHAT como en un posible entorno real, analizando los resultados obtenidos para evaluar el rendimiento del sistema, aportando varios enfoques y comparándolos entre ellos. De este modo, se concluye que el objetivo fundamental de este trabajo es reproducir los resultados obtenidos en el método seleccionado, incluyendo nuevas opciones no contempladas en su diseño original. 20
1.3. Estructura del documento Inicialmente, en el capítulo Introducción se procede a definir el problema que se desea resolver, explicando su motivación y objetivos planteados a alcanzar, así como la metodología empleada para realizar todo el proceso. Seguidamente, se incluye en el capítulo Estado del Arte un análisis de lo existente en el ámbito de los sistemas detectores de caídas así como los microordenadores de prototipado rápido más destacados, recalcando las dificultades encontradas en lo ya desarrollado y formalizando las diferenciaciones que plantea nuestra propuesta. En el siguiente capítulo, llamado Diseño del sistema, se definen los casos de uso, el funcionamiento del sistema implementado así como la arquitectura del mismo. A continuación, en el capítulo Método de desarrollo, se incluye información sobre cómo se realizó la aproximación al problema, tanto en un entorno simulado como en un entorno real, definiendo los entornos empleados para la experimentación y las pruebas. Después, el capítulo Experimentación incluye los resultados obtenidos tanto de la experimentación inicial, que nos permitió hacer nuestra propuesta de solución del problema, así como los valores estadísticos tras realizar diversas pruebas, sometiendo al sistema a los casos de uso definidos en la sección Diseño del sistema. Finalmente, en el capítulo Conclusiones y trabajo futuro, se realiza un análisis de los resultados obtenidos, resumiendo qué se ha hecho en este trabajo, el grado de aproximación a los objetivos iniciales y los puntos que han quedado pendientes de resolver, realizando una evaluación crítica del desarrollo una vez terminado. Los dos apéndices mencionados consisten en una profundización sobre las tecnologías hardware utilizadas, así como un manual de uso sobre las aplicaciones móviles incluídas en el sistema. 21
Capítulo 2 Introduction Falls are one of the most common risks that elder people have to face. According to the article "Detector automático de caídas y monitorización de actividad para personas mayores" from the journal Revista española de geriatría y gerontología [14], 30 % of seniors falls at least once a year, representing 75% victims of falls. According to this source, falls cause further 70 % of fatal accidents in the group of people over 75 years and the increased fear, anxiety or depression, which leads to the reduction of the daily activity of this group. These facts are the reason why several solutions for automatic fall detection or prevention are being developed, to ensure rapid response in case such event occurs. However, today few commercial systems are used, due to problems of reliability, ease of installation and use, or because people do not accept the device, being too invasive or expensive. As a result of these considerations, the main motivation of this project is to study existing solutions, to design and to implement a monitoring system based on using accelerometers to detect simulated falls on a domestic environment and then make a prototype of a real device. 2.1. Objective The main objective of this work is to create a fall detector system based on accelerometers that can detect the most common types of falls in elder people, trying to achieve an acceptable accuracy. Because of that, the system has been named MIDS: Mobility Issues Detector System. Secondary objectives are: to experiment with sensor platforms by microcomputers, to evaluate its suitability as an element of rapid prototyping, as well 22
as to check the problem of integrating technologies like Android and Debian in a context of development of assistive systems. 2.2. Method To achieve these objectives, the following stages will be carried out: Study of the state of the art: the different methods and systems that currently exist for detecting falls will be analysed, comparing the properties presented under various conditions and choosing, finally, one of the approaches to develop the implementation. Analysis of the selected method: Once the system is deemed more convenient both for its results and its ability to being developed selected, the method and possible improvements to it will be discussed in detail. Development of the system: •Algorithm: Definition of an algorithm that is able to distinguish between everyday situations and falls suffered by the subject just by monitoring values of an accelerometer. •Hardware: Design and assembly of a device on which the fall detection algorithm is executed. •Mobile Application: Implementing a mobile application on Android that receives alerts from the fall-detector device and allows these events to notify the relatives of the user. Results evaluation: It is intended to measure the quality of the generated system, both in a simulated environment by PHAT tool and a possible real environment , analyzing the results to evaluate system performance, providing various approaches and comparing between them. Thus, we conclude that the fundamental objective of this work is to reproduce the results of the selected method, including new options not included in the original design. 2.3. Document Structure Initially, the Introduction chapter proceeds to define the problem to be solved, explaining their motivation and objectives to be achieved, as well as 23
the methodology used to perform the entire process. Next,an analysis of what exists in the field of detection systems falls is included in the chapter State of the Art, as well as leading rapid prototyping microcomputers, emphasizing found difficulties in the already developed systems and formalizing differentiations on our proposal. In the next chapter, called System Design, the use cases are defined as well as how the implemented system works and its architecture. Then in chapter Development Method, information on how to approach the problem was held in both simulated and real environments is included, defining the environments used for experimentation and testing. The Experimentation chapter includes both the results of the initial experimentarion, whick allowed us to make our proposal for solving the problem, as well as statistical values after performing various tests, subjecting the system to the use cases defined in the System Design chapter. Finally, in chapter Conclusions and future work, an analysis of the results has been done. This analysis summarizes what has been done in this work as well as the level of approximation to the initial objectives and points that remain unresolved, making a critical assessment development once completed. The marked appendices consist on a more technical explanation of hardware technologies used as well as a User’s Guide of mobile applications included in the system. 24
Capítulo 3 Estado del arte En este estado del arte se revisan los sistemas existentes en este ámbito, detectando sus carencias y sirviendo estas de justificación para las herramientas finalmente utilizadas en nuestra propuesta de solución. De esta manera, se revisan las diferentes técnicas de detección de caídas, como por ejemplo la monitorización del entorno o vía dispositivos portátiles llevados por el paciente. Este estudio servirá para realizar la propuesta de solución. 3.1. El problema de la detección de caídas La Organización Mundial de la Salud (OMS) define las caídas como “acontecimientos involuntarios que hacen perder el equilibrio y dar con el cuerpo en tierra u otra superficie firme que lo detenga”. [15] Las caídas son un importante problema mundial de salud pública. Según los datos de la OMS se calcula que anualmente se producen 424.000 caídas mortales, convirtiendo las caídas en la segunda causa mundial de muerte por lesiones no intencionales, solo superado traumatismos causados por el tránsito. También indican que más del 80 % de las muertes relacionadas con caídas se registran en países de bajos y medianos ingresos, y más de dos terceras partes de esas muertes se producen en las Regiones del Pacífico Occidental y Asia Sudoriental. De igual manera, los mayores de 60 años presentan las mayores tasas de mortalidad por caídas en todas las regiones del mundo. [15] Junto con la inestabilidad, constituye uno de los grandes síndromes geriátricos. Es una patología muy frecuente en la población anciana, con consecuencias muy importantes y, sin embargo, a menudo se trata de una entidad que pasa inadvertida a los profesionales de la salud. Las razones por las que a menudo no se estudian son: el paciente no suele mencionar que se ha caído, no se pregunta acerca de caídas en la historia clínica, no se producen lesiones directas tras la caída y por qué se atribuye la caída al proceso normal de 25
[2], este detector establece la conexión con el centro de seguridad Tunstall (la empresa que lo fabrica) con simplemente encenderlo. Una vez activado, tiene tres configuraciones para asegurar que en la casa no se produce ninguna caída: Detección de actividad: El PIR puede establecer que se detecte movimiento en cualquier momento del día o en un período concreto (por ejemplo, de madrugada). Si alguien cae en la casa, se activa una alarma avisando a un cuidador de la compañía. Detección de inactividad: También puede detectar que en toda la casa no se produzca ningún movimiento. Si es así, se activa una alarma. Detección combinada: Para una mayor efectividad se pueden activar los dos tipos de detección anteriormente explicados. Disminuyendo así el número de falsas alarmas. En la página web de los autores no viene explícito cómo está construido el aparato ni qué datos registra exactamente. Sin embargo, explica que hay una opción para mascotas en el apartado de detección de actividad. Esta opción sube el umbral de detección a un nivel concreto por encima del suelo para que las mascotas puedan caminar libremente. Por lo tanto, se puede deducir que este sensor funciona haciendo un barrido de la habitación completa y detectando figuras en movimiento. Figura 3.4: Sistema detector de caídas PIR de Tunstall [2]. 3.3.1.2. Sistema basado en sensores Kinect Este sistema utiliza la cámara Kinect de Microsoft, que aparte de imagen y sonido, emite rayos infrarrojos para reconocer de forma fiable la estancia. Los creadores de este sistema, como indican en el artículo "Fall detection system using Kinect’s infrared sensors"[3], diseñaron una forma de recoger 32
Ventajas Inconvenientes Conexión automática con la central de alertas. Envío de ayuda rápidamente. Es el usuario quién tiene que cambiar el modo detección. La detección se basa solo en el movimiento. Podría no detectarse varios tipos caídas o detectar falsos positivos. Tabla 3.3: Ventajas e inconvenientes del sistema desarrollado por Tunstall. Figura 3.5: Componentes de Kinect. la figura del paciente. Esta figura es utilizada para realizar los cálculos necesarios y poder estimar si se ha producido una caída o no. Esto lo consiguen mediante una “caja de unión 3D” (Bounding box), una especie de malla virtual que reconoce el cuerpo del paciente al entrar en la sala donde esté dispuesto el sistema. Una vez reconocida la figura del paciente, Según las contracciones y expansiones de esa caja 3D se realizan los cálculos de velocidad y posición. El proceso de detección de caídas de este sistema tiene 3 pasos: 1. El sistema reconoce al paciente y detecta un cambio brusco en la velocidad y una posición cercana al suelo. 2. El sistema sigue registrando datos de la Bounding box para comprobar si el paciente no se mueve. 3. Si ha reconocido esa inactividad, detecta la caída y se activa la alarma. Este sistema, tal y como vemos en las figuras 3.6 y 3.7 es capaz de observar actividades como sentarse de forma brusca en el sofá, y tal y como viene explicado en su manifiesto y vídeo de ejemplo, tumbarse en el suelo o dejarse caer en una silla. Presenta, por tanto, alta fiabilidad en potencia. 33
Figura 3.6: Ejemplo de pasos de detección de caída en el sistema Kinect [3]. Figura 3.7: El sistema Kinect no detecta el falso positivo de sentarse de forma brusca [3]. Este sistema presenta una serie de ventajas e inconvenientes, resumidos en la tabla 3.4. 34
Ventajas Inconvenientes La detección a partir de la silueta y del entorno permite discriminar bien los distintos tipos de caída. Riesgo para la privacidad. No envía señal de alerta, solo detecta la caída. Coste muy elevado. Tabla 3.4: Ventajas e inconvenientes del sistema Kinect. 3.3.2. Basados en cámaras Se trata de sistemas que utilizan cámaras para recopilar la información necesaria para la detección de la caída. Estos datos son, en concreto, puntos que delimitan la figura del paciente. Según la información recopilada, tratan el problema de diversas maneras. En las secciones 3.3.2.1 y 3.3.2.2 se analizarán dos sistemas de este tipo. 3.3.2.1. Sistema inteligente de detección de caídas basado en visión de la universidad de Toronto Como se indica en el artículo Ïntelligent vision-based fall detection system"[4], este sistema automático utiliza un modelado visual del entorno, el cual separa la silueta del paciente de cualquier otras regiones de la estancia. Al analizar las regiones, se obtienen datos de velocidad, área y momento. Un algoritmo de aprendizaje automático clasifica estos datos para detectar si el sujeto ha sufrido una caída o no. Figura 3.8: Diagrama de flujo del sistema propuesto por la Universidad de Toronto [4]. 35
Según se indica [4], el sistema se probó durante una semana, y todas las caídas simuladas se detectaron. Aunque también se reconocieron 5.4 falsas alarmas al día. Desarrollado en C++ y OpenCV (un framework de visión virtual), utiliza una cámara de resolución 320x240 para capturar las imágenes. Los fotogramas se procesan al instante y ninguno queda almacenado o es difundido. El proceso es: 1. Se extrae la silueta y se segmenta: Cada píxel se entiende como una distribución Gaussiana única centrada en la intensidad estimada del píxel. Resumiendo: ayuda a separar los tonos oscuros de los claros y ayuda a diferenciar entre la figura y el entorno. 2. Se analiza la silueta para obtener los datos: Por cada fotograma, se extraen una serie de datos geométricos y temporales: velocidad, área y momento. Estos datos se suavizan cada 16 fotogramas para reducir el ruido. 3. Se activa el sistema detector de caídas: utilizando redes neuronales, el sistema aprende a clasificar entre caída y no caída. Tras un entrenamiento con imágenes de simulaciones de caídas, se registró un rango de acierto del 97% con un 5% de falsos positivos. 4. Se registran zonas de inactividad para disminuir el número de falsos positivos: Se establecen zonas como sillas o sofás, donde el sujeto permanece inactivo y es poco probable que sufra una caída. Así, se restringe al sistema de actuar en dichas zonas. Figura 3.9: Extracción de silueta en el sistema de la Universidad de Toronto [4]. Una vez detectada una caída, se activa un terminal y un sistema de reconocimiento de voz, permitiendo que el usuario impida que se active una falsa alarma. Si no se realiza ninguna acción que anule la alarma, el sistema también permite al paciente que llame a un familiar, amigo o a emergencias. 36
Ventajas Inconvenientes Alto porcentaje de acierto en ciertos tipos de caídas. Permite que el propio paciente avise a algún familiar o a emergencias. Permite que el paciente desactive la alarma en caso de falsos positivos. Riesgo para la privacidad. No contempla el caso de que el paciente se quede inconsciente. No puede avisar a emergencias en este caso. Tabla 3.5: Ventajas e inconvenientes del sistema propuesto por la Universidad de Toronto. 3.3.2.2. Sistema de detección de caídas visual basado en el reconocimiento de posturas Este es un sistema novel creado por 5 alumnos de la universidad de Loughborough, en Reino Unido. Como se indica en el artículo consultado [18], es utilizado para monitorizar las actividades en el hogar de una persona anciana. Usando prácticamente el mismo sistema de antes, diferencia entre entorno y sujeto para un proceso posterior. El sistema construye gráficas e histogramas con los datos recogidos y se distinguen distintas posturas del paciente. Estos datos se guardan en un grafo dirigido no cíclico para realizar correctamente la clasificación de las posturas. Estos datos combinados con información recogida del suelo son los que marcan si se ha producido o no una caída. Según sus estadísticas, tiene un porcentaje de detección de caídas del 97.08 % con un 0.8% de falsos positivos en un entorno simulado. 37
3.3.3. Otros sistemas basados en monitorización del entorno Existe otro tipo de detectores de caídas que no puede ser englobado en ninguna de las categorías anteriores ya que , para la detección de la caída, utilizan sistemas portátiles y sistemas de monitorización del entorno. 3.3.3.1. Vigi’Fall Tal y como nos informa su página web [5], la solución propuesta por este sistema se basa en un pequeño parche biosensor que el usuario lleva adherido a la piel y una serie de sensores conectados inalámbricamente situados en la vivienda del paciente. Figura 3.10: Sistema detector Vigi’Fall [5]. La caída es detectada mediante los datos cruzados del sensor que lleva el usuario, que detecta movimientos bruscos mediante un acelerómetro, la postura del paciente, la horizontalidad y el nivel de actividad (alerta ante periodos prolongados de inmovilidad), así como por los sensores del entorno, que reaccionan ante la ausencia de movimiento. Estos dos factores hacen que se active la alerta del sistema, enviando una notificación a la central de control, el aparato principal del sistema, situado también en la vivienda. 38
Este dispositivo es el encargado de conectar automáticamente con el centro de ayuda o una enfermera. Para confirmar el estado de alerta, se llamará al usuario por teléfono, y en caso de no responder, se enviará ayuda presencial a la vivienda. Se analiza además la naturaleza de las caídas y la postura final del usuario, para distinguir los falsos positivos que pueden darse durante las ADLs. Ventajas Inconvenientes Recogida de gran cantidad de datos diferentes. Permite detectar varios tipos de caídas y sus causas. Conexión directa con la central de ayuda. Comunicación con el paciente para descartar falsos positivos. Sistema complejo, varios sensores. Podría provocar rechazo del paciente. Necesario que exista colaboración entre los sensores fijos y el portátil. Crítico en caso de que el paciente se olvide de colocar el sensor. Coste elevado. Tabla 3.6: Ventajas e inconvenientes del sistema Vigi’Fall. 39
3.4. Sistemas de detección basados en dispositivos portátiles Dentro de los sistemas portátiles, se engloban todos aquellos en los que el usuario lleva encima el dispositivo de detección. Se ha hecho una distinción en dos grandes grupos: los que usan exclusivamente acelerómetros y en los que hay implicados además otro tipo de sensores. Ambos grupos comparten varias características: Ventajas Inconvenientes Generalmente, utilizan un único dispositivo.[6] [10] [7] Monitorización constante. [8] [10] Menor coste que los de monitorización del entorno. [9] [6] [7] Los obstáculos del entorno no influyen tanto en la detección como en el grupo anterior. [10] [6] [8] Es necesario el uso de una fuente de alimentación: batería, pilas... [8] [7] [9] Es el usuario quien tiene que colocarse el dispositivo. [8] [6] [10] Es más probable que el dispositivo sufra daños cuando se produzca una caída. [6] [9] Tabla 3.7: Ventajas e inconvenientes de los sistemas basados en dispositivos portátiles. Esta distinción simplifica el esquema a la par que nos centra en los sistemas que más hemos investigado, los de uso exclusivo de acelerómetros. 3.4.1. Sistemas basados en acelerómetros y otros tipos de sensores 3.4.1.1. Red inalámbrica de sensores inerciales para el registro y procesamiento de movimientos corporales Una propuesta interesante de este tipo de sistemas es el Wagyromag (Wireless Accelerometer, Gyroscope and Magnetometer), un dispositivo desarrollado en la Universidad de Granada por un grupo de ingenieros informáticos y de telecomunicaciones. Este dispositivo no ha sido desarrollado exclusivamente para la detección de caídas sino que, entre sus aplicaciones, también se incluyen telerehabilitación, análisis del movimiento en el deporte y detección 40
de crisis nocturnas de epilepsia. El sistema utiliza un microcontrolador PIC 24FJ64B004 encargado de procesar los datos obtenidos a través de la conexión inalámbrica de los acelerómetros, giroscopios y magnetómetros. Su funcionamiento se basa en la detección de las variaciones de inclinación detectadas en los tres tipos de sensores. Es un sistema de monitorización, no envía ningún tipo de señal de alerta cuando se produce una caída. Además incluye un sensor de temperatura que permite decidir el ajuste de configuración más óptimo del sistema evitando posibles variaciones debidas a la subida de temperatura. También incluye una memoria interna y un botón pulsador. Este último permite seleccionar dos modos de funcionamiento, en el primero los datos son enviados en tiempo real y en el segundo son almacenados en la memoria del dispositivo. Dispone además de una batería recargable que puede ser sustituida por una de mayor capacidad cuando el sistema lo requiera [6]. Figura 3.11: Prototipo del sistema Wagyromag diseñado por la Universidad de Granada [6]. 41
Figura 3.16: Algoritmo de detección de caídas usado en el sistema Wiimote [9]. Muy similar a esta propuesta, es la realizada por Tunstall Group en 1999, con un algoritmo de dos etapas de activación, una de detección de impacto y otra de detección de cambio de la orientación del cuerpo, mediante el uso de este tipo de sensores. Ventajas Inconvenientes Envío de alerta si se produce una caída. Detección de dos fases de la caída (impacto y posición horizontal) para evitar falsos positivos. Coste bajo. Tamaño del mando Wii. Baja autonomía. Tabla 3.11: Ventajas e inconvenientes del sistema Wiimote. 48
3.4.2.3. Speedy Se trata de una propuesta innovadora, consistente en un sistema detector que se basa en integrar en un reloj de muñeca toda la tecnología necesaria para alertar de posibles caídas. Trata de hacer lo menos engorroso para el paciente llevar el detector, de manera que pueda sencillamente olvidar que lo lleva puesto. Figura 3.17: Prototipo Speedy [10]. El camino hacia la detección de la caída pasa por la integración en este reloj de dos acelerómetros ADXL202, que miden la aceleración en los tres ejes y aplican un algoritmo multietapa para su identificación. Mediante la obtención del valor de la normal de la aceleración y el valor de la velocidad durante la caída al suelo mediante dos aproximaciones, detectan al superar estos valores unos umbrales que se ha producido una caída libre hacia el suelo. Después de detectar esto, mediante el valor de la normal de la aceleración detectan el impacto contra el suelo y si, tras un periodo de 40 segundos, no se ha percibido actividad, se activa la alarma sonora del dispositivo. El portador podrá desactivar esta alarma presionando un botón, pero tras un margen, si no se ha pulsado, la alarma se transmite inalámbricamente a la estación base, que alertará al centro de ayuda. El sistema, sin embargo, resultó tener una tasa de aciertos relativamente baja, detectando con precisión únicamente las caídas hacia delante, como se muestra en la figura 3.18. Este problema puede deberse a algo que mencionan los propios desarrolladores, ya que la segunda aproximación que realizan sobre la velocidad de caída es buena siempre y cuando el dispositivo no sea girado durante la caída, resultando un gran error en caso de producirse esta rotación. 49
Figura 3.18: Estadísticas detección de caídas Speedy. Caídas en diferentes direcciones [10]. Ventajas Inconvenientes Comodidad para el paciente. Todo el sistema en un reloj. Permite al usuario descartar falsos positivos pulsando un botón. Envío de alerta en caso de no desactivar la alarma sonora. Detecta con precisión únicamente las caídas hacia delante. Tabla 3.12: Ventajas e inconvenientes del sistema Speedy. 50
3.5. Algoritmos para la detección de caídas mediante el uso de acelerómetros Como se ha visto en los dispositivos anteriores, dentro de los sistemas basados en acelerómetros existen diferentes enfoques a la hora de detectar la caída que propone la literatura son: Detección del pico de aceleración Los parámetros a tener en cuenta son: 1. Magnitud máxima del vector de aceleración, calculada mediante la ecuación indicada, considerando vectores mutuamente ortogonales entre sí en los ejes X, Y y Z. Todo movimiento brusco, entre ellos las caídas, producen cambios transitorios de magnitud pronunciada del orden de doce veces la aceleración de la gravedad (12g) que pueden ser detectadas, justamente, con la magnitud pico del vector de aceleración. |a|=qax2+ay2+az2(3.1) El umbral de la aceleración pico puede ser configurado basado en datos empíricos. El valor de aceleración más pequeño medido en una caída es de alrededor de 3g, pero usualmente es varios g superior. Las actividades de la vida diaria usualmente no exceden los 3g, pero ocasionalmente puede ser mayor durante algunos movimientos bruscos como saltar, correr y sentarse rápidamente. Ya que existe algún solapamiento para los rangos de aceleración de caídas y ADLs, se requiere otra forma de distinguir las caídas de las actividades dela vida diaria para conseguir un algoritmo más robusto. 2. Dado que los eventos de caída son breves, la duración del pico de aceleración también es un parámetro determinante para distinguir una caída de otros eventos. Según Jia (2009) la duración de un pico de aceleración en una caída es del orden de los 30 milisegundos. Detección de la colisión Se puede implementar un sistema de detección de caídas basándose en la colisión, midiendo el valor relativo del incremento de aceleración. Si 51
en un cierto intervalo de tiempo la aceleración aumenta más de una cantidad, se considera colisión. Estos algoritmos lo que hacen es: para los últimos valores (los 20 últimos por ejemplo) comprueba si el incremento de aceleración es mayor que cierto valor, considerado el umbral de incremento de aceleración. Detección de las etapas de la caída Toma en cuenta los distintos estados de la persona antes, durante y luego de una caída.[11] Figura 3.19: Etapas de la caída y cambios en la aceleración propuestas por Nia [11]. Estos estados son los siguientes, representados en la figura 3.19 1. Caída Libre: Se le ha nombrado caída libre a esta etapa a pesar de que el paciente no tiene un movimiento idéntico al de un cuerpo en caída libre, debido a su dinámica justo antes de caerse o a la resistencia que pueda presentarse contra paredes o suelo durante la caída. Esta etapa hace referencia al momento inicial de toda caída, donde el cuerpo se dirige hacia el suelo experimentando una aceleración vertical semejante a la gravedad. En esta etapa la suma vectorial de las aceleraciones disminuye de 1g hasta 0 g. 2. Impacto: Después de la etapa de Caída Libre, el cuerpo choca con el suelo u otros objetos, dando como respuesta un elevado pico entre 2g y 12g en la suma de los tres ejes debido a la elevada desaceleración del cuerpo. 52
3. Reposo: Tras un impacto, un cuerpo se mantiene en reposo durante un tiempo. Este tiempo puede ser muy elevado si el paciente se encuentra inconsciente, pero normalmente es menor a 10s. 4. Posición Horizontal: Tras una caída, el cuerpo queda en una posición diferente a la inicial. Figura 3.20: Algoritmo propuesto por Ning Jia en “Detecting Human Falls with a 3-Axis Digital Accelerometer” para la detección de caídas mediante la detección de las diferentes etapas.[11] 53
3.6. Patentes Para finalizar el estudio de dispositivos de detección de caídas existentes o en creación, se revisarán las invenciones patentadas (o solicitadas) relacionadas con la detección automática de caídas. Tras buscar utilizando Google Patents, el buscador de la Oficina Española de Patentes y Marcas (OEPM), y ciertos artículos concretos de Google Scholar, se han encontrado éstos como los más relevantes: Método y Dispositivo para monitorizar la posición del cuerpo y detectar caídas usando radar (UWB RADAR) La patente de Josef Osterweil fue solicitada en Abril de 2007 y finalmente concedida en Julio de 2009. Como se indica en Google Patents, este ingenioso sistema utiliza un radar para generar señales que reboten contra figuras en movimiento, y analizando las señales de retorno, determinar si los datos se correlacionan con una caída. Figura 3.21: Ejemplo de detección de caída usando dos radares de zona ancha de la patente de Josef Osterweil [12]. Observando la figura 3.21, se puede deducir que el sistema funciona mediante una serie de emisores de radar repartidos por la casa, emitiendo constantemente señales de radar. Llegando a un apartado técnico, su propio inventor describe su obra como “un detector de caídas basado en un análisis espacial cuantitativo de un sujeto en un volumen supervisado [...] y el procesamiento de la imagen capturada para determinar las características físicas y otras características de un individuo supervisado”. 54
Este sistema se vale de una forma de procesamiento Doppler que detecta el latido del corazón y el movimiento de los pulmones al respirar para diferenciar entre seres vivos y objetos inanimados. Esta forma de procesar esta información concreta también permite detectar una caída sin necesidad de ver el cambio de posición, ya que los pulmones y el corazón tiene ritmos concretos. Aún así, el registro de la velocidad, la posición, y los datos Doppler se pueden procesar simultáneamente, ya que se registran en segmentos y anchos de banda diferentes. Esto permite una detección de caídas más eficaz. Figura 3.22: El radar no detectaría las señales Doppler del corazón y los pulmones por encima del umbral 330. En adición, habría detectado el cambio de velocidad brusco. Se produjo una caída [12]. Si se detecta una caída, este sistema emite una alarma audible y contacta con un servicio de ayuda externo (no explícito en la hoja de la patente). Existe la posibilidad añadida de desactivar la alarma si se da el inconcebible caso de un falso positivo. 55
Método y Dispositivo electrónico para detectar caídas usando múltiples acelerómetros La patente fue solicitada por los inventores Michelle A. Clifford, Rodrigo L. Borras, Leticia Gómez y Akihiro Ueda el 1 de Diciembre de 2004. Fue finalmente concedida el 13 de Marzo de 2007 y actualmente sigue en activo. Esta invención proporciona un sistema y un método para la detección de caídas basado en múltiples acelerómetros. Para detectar la caída, un procesador recibe las lecturas de los acelerómetros y las compara con ciertos rangos de valores continuamente. Figura 3.23: Diagrama de flujo del sistema multi-acelerómetro propuesto por la patente [13]. Gracias a la utilización de múltiples acelerómetros, este sistema puede detectar de manera fiable caídas no lineales (caídas con rotación o iniciadas por fuerzas externas). Para que esta detección sea realmente fiable, compara combinaciones de los datos recogidos por los acelerómetros con respecto a unos rangos y determina la suavidad de esas combinaciones. Si se dan esas circunstancias (rangos sobrepasados y 56
combinaciones suaves), una caída no lineal se ha producido. Figura 3.24: Valores de x, y, z, así como el valor del s-factor(suavidad) recogidos en una caída típica. [13] Si se detecta que el paciente está cayendo (de manera lineal o no), el procesador envía una señal concreta al dispositivo. Según el tipo de señal enviada, el aparato puede suspender el funcionamiento y/o realizar una copia de seguridad de datos sensibles. En adición, el sistema puede registrar la altura de la caída (cálculo desde que comienza la caída hasta el impacto). Así, se registran distintos valores, el sistema aprende, y pasa a ser más robusto. Esta invención se puede utilizar en muchos dispositivos electrónicos diferentes. Por ejemplo: en reproductores, teléfonos, buscas, cámaras de fotos, vídeo... Todos se pueden adaptar para detectar una caída y proporcionar una señal de aviso al dispositivo. Este sistema utiliza como mínimo tres acelerómetros. Los rangos de detección de caída son de +/- 4g. 57
Una vez analizadas las distintas alternativas, contemplamos las siguientes plataformas hardware para el desarrollo del sistemas ambientales. Beaglebone La primera de nuestras alternativas se trata de BeagleBoard, una placa computadora de hardware libre desarrollada por Texas Instruments, que cuenta con un procesador ARM. Se trata de una placa de dimensiones reducidas y bajo coste, unos 36 D, por lo que ha resultado muy adecuada para el despliegue del sistema propuesto. Figura 3.26: Logo BeagleBoard. En concreto se ha investigado la placa BeagleBone Green, un modelo diseñado específicamente para proyectos centrados en sensorización desarrollado con la colaboración de Seeed Studio. La diferencia con su placa hermana, la BeagleBone Black, reside en la integración de dos conectores Grove (I2C y UART) en la placa a cambio de la eliminación del conector HDMI. Estos conectores facilitan la utilización de los sensores del mismo nombre, los sensores Grove. También es posible la conexión mediante GPIO de distintos dispositivos de entrada o salida. Además de las ventajas respecto a sensorización, la BeagleBone Green es compatible con un gran número de sistemas operativos, desde un sistema residente Debian precargado en una memoria EEPROM, hasta Ubuntu, ArchLinux e incluso Android cargados mediante una memoria SD externa. Además es posible el desarrollo de software en varios lenguajes utilizando el entorno Cloud9 IDE sobre Node.js con la “BoneScript library”. Esto, junto con el conector Ethernet sobre USB integrado en la placa, elimina la desventaja de la supresión del HDMI en esta versión de la placa.[22] [23] 64
Figura 3.27: Placa Beaglebone Green de SeeedStudio. Raspberry La segunda opción que se valoró para la integración en este proyecto es la Raspberry Pi. Esta placa ha sido desarrollada por la Fundación Raspberry Pi y, al igual que en el caso de BeagleBone, existen varias versiones en el mercado. En concreto se ha investigado el modelo Raspberry Pi Zero, una placa diseñada para la integración en sistemas portátiles y empotrados. Las potencia computacional es similar a BeagleBone Green y a la de sus hermanas ( Raspberry Pi A+ o B+). Cuenta con un procesador ARM a 1 GHz de un solo núcleo y 512 Mb de memoria RAM. Figura 3.28: Logo Raspberry. En cuanto a la alimentación de la placa, es similar a BBG. Cuenta con dos puertos USB, uno de ellos para la alimentación, un puerto mini HDMI y una ranura para una tarjeta micro SD. A diferencia de la BBG, no viene con ningún sistema operativo precargado, es necesario 65
instalar alguna de las opciones disponibles en la tarjeta SD. Una gran ventaja de todos los modelos de Raspberry es la disponibilidad de software compatible con estas placas. Si hablamos en concreto de sistemas operativos, no es difícil darse cuenta de que sin duda es la placa que más versatilidad proporciona en este aspecto. Dispone de varias versiones Linux (Debian, Kali, Raspbian, Ubuntu, Pidora, ArchLinux, etc), Chromium de Google, Android e incluso de una versión de Windows 10. Otro ventaja de esta placa es su bajo coste, se puede encontrar en el mercado por unos 5$. Actualmente es la placa con mejor relación rendimiento/precio. Además, sus dimensiones son muy reducidas lo que hace que sea adecuada para el despliegue de sistemas portátiles y empotrados, eso sí, a cambio de eliminar el conector RJ45 y 2 de los puertos USB de los que otros modelos sí que disponen. Otro factor importante de Raspbery Pi Zero es la conexión con los sensores y actuadores. Dispone de una serie de pines para GPIO y la conexión tiene que hacerse a través de una Breadboard. Es necesario montar los circuitos necesarios para el correcto funcionamiento con los sensores. Esto aumenta bastante el tamaño del sistema una vez montado.[26] [27] Figura 3.29: Raspberry Pi Zero de Raspberry Pi Foundation. 66
Capítulo 4 Diseño del sistema Se pretende estudiar la resolución del problema desde el enfoque de los sistemas de detección portátiles. En concreto mediante la monitorización de la orientación y el movimiento del paciente, haciendo uso de un acelerómetro de tres ejes que registra estos valores en el microcomputador. Se ha presentado como una de las opciones más sencillas para implementar con los medios de los que disponemos, así como una manera de profundizar en la problemática existente a la hora de diferenciar lo que es una caída de lo que no lo es, y constituye una actividad corriente de la vida del usuario. Mediante el procesado de los datos recogidos, se pretende detectar las caídas de manera inmediata, como anomalías en las ADL del paciente que activarán el sistema de alerta. Esto consistirá inicialmente en una señal sonora a un volumen elevado, que alerte a posibles acompañantes del paciente en la vivienda de la situación. Esto se conseguirá mediante un dispositivo detector portable, colocado en un lugar accesible para el paciente y a la vez que proporcione una buena sujección. Por todo ello, se ha decidido incluir el detector en el cinturón, sujeto con un clip. El dispositivo será pequeño, de manera que pueda ir oculto debajo de la ropa, como debajo del jersey. Este dispositivo dispondrá de un botón para poder cancelar el estado de alerta en caso de ser necesario, como puede ser por una detección de un falso positivo, devolviendo al sistema a la normalidad. Este es el elemento indispensable para la detección de la caída del paciente, pero se han implementado dos aplicaciones móviles que permiten al usuario interactuar con el sistema de diferentes maneras, así como personalizar ciertos aspectos del funcionamiento del mismo. 67
Por una parte, se ha desarrollado la aplicación MIDSAssistant, pensada para las personas que no dispongan de un cuidador y/o se encuentren solas en su vivienda. Esta aplicación nos permite de manera sencilla configurar una serie de contactos a los que notificar por llamada o SMS cuando se produzca alguna caída. De manera complementaria, se implementó una segunda aplicación llamada MIDSCaretaker, orientada al uso por parte de un posible cuidador o pareja del paciente, de modo que reciben de manera directa a través de la aplicación las notificaciones pertinentes. Figura 4.1: Boceto del sistema general 68
4.1. Casos de uso Se han delimitado los casos a resolver, centrándose en unos tipos de caídas concretos, que permitieran conseguir una tasa de efectividad aceptable. Quedan divididos en dos grandes grupos, según el nivel de consciencia resultante de la caída, lo que condiciona la respuesta del sistema. 4.1.1. Caídas con pérdida de consciencia Caída del paciente cuando se encuentra solo en su vivienda. Escenario 1. El paciente se encuentra en su vivienda, caminando por una habitación. 2. El paciente se desplaza, tropieza y sufre una caída, quedando inconsciente. 3. El sistema detecta el estado de alerta, activando un dispositivo sonoro, el cual alerta a posibles personas presentes en la vivienda de su caída. 4. El sistema activa un temporizador, durante este periodo se puede desactivar el estado de alerta pulsando un botón situado de manera accesible para el paciente. 5. Al encontrarse en un estado de inconsciencia, el paciente no puede interactuar con el sistema y se trata de un estado de alerta en el que se precisa de ayuda externa. 6. Tras un periodo determinado, al no recibir respuesta por parte del paciente ni ser desactivado por el acompañante, se activará el envío de un aviso al teléfono móvil de la persona encargada del cuidado del paciente, para alertarle del estado de emergencia. Datos recogidos Variación en la posición. Variación en la aceleración (gravedad). Actores involucrados El paciente se encuentra solo en su domicilio, por lo que no hay otros actores implicados. 69
Acciones a ejecutar 1. Detección de la caída por parte del dispositivo: para ello, se registran las variaciones de posición y aceleración. 2. El sistema producirá un sonido agudo a un volumen elevado. 3. De manera complementaria, para poder descartar situaciones resueltas rápidamente o falsos positivos, dispondremos de un botón en el sistema que devolverá al sistema a una situación normal. Fracasos posibles 1. Detección de un falso positivo. Plan de acción: El sistema dispone del botón de cancelación del estado de alerta, que se sitúa en una posición accesible para él. Será pulsado por el propio paciente o por la persona que se encuentre acompañándolo. En caso de no ser posible la desactivación usando el botón, la monitorización de si el paciente está levantado o no, eliminaría dicho falso positivo. 2. No detección de la caída. Plan de acción: Situación crítica para el sistema. Esta situación no está resuelta. 70
Caída del paciente cuando se encuentra acompañado. Escenario 1. El paciente se encuentra en su vivienda, caminando por una habitación. 2. El paciente se desplaza, tropieza y sufre una caída, quedando inconsciente. 3. El sistema detecta el estado de alerta, activando un dispositivo sonoro, el cual alerta a posibles personas presentes en la vivienda de su caída. 4. El sistema activa un temporizador, durante este periodo se puede desactivar el estado de alerta pulsando un botón situado de manera accesible para el paciente. 5. La pareja del paciente se encuentra en otra habitación y acude en ayuda del paciente al escuchar la alerta sonora. 6. La pareja desactiva el estado de alerta mediante el pulsador y avisa a emergencias. Datos recogidos Variación en la posición. Variación en la aceleración (gravedad). Actores involucrados El paciente se encuentra acompañado por un pariente o por su cuidador. Acciones a ejecutar 1. Detección de la caída por parte del dispositivo: para ello, se registran las variaciones de posición, aceleración y picos de sonido detectados. 2. El sistema producirá un sonido agudo a un volumen elevado, lo cual alerta a posibles acompañantes del paciente de la situación de alerta. 3. De manera complementaria, para poder descartar situaciones resueltas rápidamente o falsos positivos, dispondremos de un botón en el sistema que devolverá al sistema a una situación normal. 71
Fracasos posibles 1. Detección de un falso positivo. Plan de acción: El sistema dispone del botón de cancelación del estado de alerta, que se sitúa en una posición accesible para él. Será pulsado por el propio paciente o por la persona que se encuentre acompañándolo. En caso de no ser posible la desactivación usando el botón, la monitorización de si el paciente está levantado o no, eliminaría dicho falso positivo. 2. No detección de la caída. Plan de acción: Situación crítica para el sistema. Esta situación no está resuelta. 72
4.1.2. Caídas sin pérdida de consciencia Caída del paciente cuando se encuentra solo en su vivienda. Escenario 1. El paciente se encuentra descansando en el sofá de su vivienda. 2. Al levantarse, se tropieza y se cae al suelo. 3. El sistema detecta el estado de alerta, activando un dispositivo sonoro, el cual alerta a posibles personas presentes en la vivienda de su caída. 4. El sistema activa un temporizador, durante este periodo se puede desactivar el estado de alerta pulsando un botón situado de manera accesible para el paciente. 5. Al encontrarse en un estado de consciencia, el paciente podría interactuar con el sistema, pero pueden darse dos situaciones: a) Es capaz de accionar el botón, desactivando el estado de alerta en caso de ser necesario. b) No es capaz de accionar el botón, posiblemente por la posición en la que queda tras la caída. 6. Tras un periodo determinado, si no se recibe respuesta por parte del paciente, se activará el envío de un aviso al teléfono móvil de la persona encargada del cuidado del paciente, para alertarle del estado de emergencia. Datos recogidos Variación en la posición. Variación en la aceleración (gravedad). Actores involucrados El paciente se encuentra solo en su domicilio, por lo que no hay otros actores implicados. Acciones a ejecutar 1. Detección de la caída por parte del dispositivo: para ello, se registran las variaciones de posición, aceleración y picos de sonido detectados. 2. El sistema producirá un sonido agudo a un volumen elevado, lo cual alerta a posibles acompañantes del paciente de la situación de alerta. 73
Como se muestra en la figura 4.4, una vez encendida y conectada a la aplicación al detector, este comienza a registrar los valores del acelerómetro. Si el algoritmo detecta que se ha producido una caída, se activa el estado de alerta. Este diagrama muestra en concreto que, al pulsar el botón de no-alerta o al conseguir levantarse y mantenerse erguido durante más de 10 segundos, el zumbador para y se desactiva el sistema de alerta. sin notificar a ninguna aplicación. Figura 4.5: Comportamiento del sistema ante una caída. Respuesta de emergencia finalizada por llamada respondida. El diagrama de la figura 4.5 muestra la respuesta del sistema cuando se produce una alarma y no se pulsa el botón de no-alerta en 30 segundos o no se detecta que el paciente haya conseguido levantarse. Tras ese intervalo, el dispositivo detector envía una alerta a la aplicación MIDSAssistant y esta comienza a llamar a los contactos designados, informando vía SMS de la caída de manera complementaria al 80
contacto que responda a la llamada o al más prioritario si no hay respuesta por parte de ninguno si se tiene activada esta opción. Figura 4.6: Comportamiento del sistema ante una caída. Respuesta de emergencia completa. La figura 4.6 muestra el comportamiento del sistema cuando se produce una alerta y no se pulsa el botón de no-alerta ni se detecta que el paciente se haya levantado. El dispositivo detector envía una alerta a la aplicación móvil, la cual empieza a llamar a la lista de contactos añadidos. Si no se ha conseguido contactar con nadie de forma inmediata, el último recurso de la aplicación es enviar un SMS al contacto más prioritario. Una vez hecho esto, el estado de alerta finaliza. 81
2. Solo se encuentra instalada la aplicación MIDSCaretaker: el teléfono del cuidador comenzará a vibrar y a sonar, avisándole, si no hubiese podido oír la señal auditiva del zumbador del paciente, de que la persona a la que está cuidando se ha caído. Este sistema más sencillo permite evitar llamadas innecesarias. Figura 4.7: Comportamiento del sistema ante una caída. Respuesta de un sistema con MIDSCaretaker. La figura 4.7 muestra cómo reaccionaría MIDSCaretaker ante la caída de un paciente. Se puede observar que en cuanto se ha detectado la caída y no se ha reaccionado ante el zumbador, la aplicación del cuidador realiza una notificación para que éste acuda en ayuda del paciente inmediatamente. 82
3. El paciente tiene instalada MIDSAssistant y el cuidador MIDSCaretaker: MIDSAssistant alberga una configuración que activa o desactiva la respuesta de emergencia según haya o no una aplicación MIDSCaretaker conectada al dispositivo detector. Figura 4.8: Comportamiento del sistema ante una caída. Respuesta de un sistema con MIDSCaretaker. 83
Como se muestra en la figura 4.8, si esta opción está activada, quiere decir que existe una aplicación MIDSCaretaker conectada. Al haber alguien pendiente y que pueda ofrecer una ayuda inmediata, no es necesario que MIDSAssistant realice llamadas ni envíe SMS, así que la única respuesta de emergencia será un aviso auditivo del smartphone que tenga instalada MIDSCaretaker. Sin embargo, si la opción está desactivada, se indica que MIDSAssistant ignora que exista alguna aplicación MIDSCaretaker. Por lo tanto, la respuesta de emergencia será la original: si recibe una alerta, comenzará a llamar a la lista de contactos previamente creada. Si la llamada es respondida, se mandará un SMS a ese contacto concreto. Si no se responde ninguna llamada, se enviará un SMS al contacto más prioritario si se tiene activada esta opción. 84
4.3. Arquitectura El sistema MIDS está constituido por dos elementos interconectados, el dispositivo detector y la aplicación de alertas MIDSAssistant instalada en el teléfono móvil del usuario, o bien la aplicación para enviar alertas MIDS Caretaker, instalada en el móvil de la persona encargada del cuidado. Figura 4.9: Diagrama de despliegue de los nodos del sistema MIDS. Tal y como se puede ver en la figura 4.9, el despliegue físico necesario para que el sistema funcione conlleva la presencia de tres dispositivos: el aparato detector de caídas desplegado sobre Beaglebone Green con el ejecutable Bodyfall, un smartphone con la aplicación Android MIDS Assistant instalada y otro smartphone con la aplicación MIDS Caretaker. Cabe destacar que según la respuesta de emergencia deseada, la utilización de los smartphones puede llegar a ser opcional. El diagrama explica cómo se debería desplegar el sistema para la respuesta completa integrando todos los componentes. La idea principal es que se pueda usar cualquier red, interconectando los dispositivos, pero durante el desarrollo se conectan mediante un router personal. 85
Figura 4.10: Diagrama de componentes del sistema MIDS. El diagrama de la figura 4.10 explica cómo se despliegan los diferentes componentes del sistema. Se puede observar cómo el código que se encarga de la detección de caídas también ofrece un servidor en el que se pueden registrar sendas aplicaciones. Tras el registro de las aplicaciones, se establece una conexión vía socket entre Bodyfall y AlertService, el servicio de la aplicación encargado de recibir las alertas del dispositivo detector. El dispositivo detectará la caída mediante la monitorización de los sensores y activará el sistema de alerta. Inicialmente emitirá una notificación sonora y, tras un tiempo determinado, enviará una notificación a través de la comunicación previamente establecida con AlertService. Este servicio activará el sistema de llamadas, avisando a las personas deseadas de la caída del paciente o recibirá alertas directamente, en caso de ser la aplicación del teléfono del cuidador. 86
4.3.1. Dispositivo detector de caídas 4.3.1.1. Hardware Tras analizar los requisitos del proyecto y comparar los distintos dispositivos del mercado, se ha decidido utilizar los siguientes componentes hardware. BeagleBone Green De entre las distintas placas descritas en el estado del arte, se ha decidido utilizar la BeagleBone Green. Los principales motivos para esta elección son los siguientes: Facilidad de conexión con los sensores: la BBG está diseñada para ser utilizada con los sensores Grove de SeeedStudio. No necesita BreadBoard, se conectan directamente en los puertos I2C y UART incorporados en la placa. Capacidad de expansión: permite ampliar los puertos disponibles con solo conectar una o varias capas de expansión. Sistema operativo cargado en memoria EEPROM: la velocidad en el arranque y ejecución de los programas es superior a otras placas. Capa de expansión Adicionalmente, se ha usado una capa de expansión llamada Grove Cape , que permite aumentar los dos conectores ya incorporados en la propia placa hasta un total de 8 conectores. De esta manera se dispone de un total de 3 conectores I2C, 3 conectores UART y 2 conectores ADC. Figura 4.11: Capa de expansión para la BeagleBoard. 87
Sensores y actuadores Los sensores y actuadores utilizados pertenecen a la familia Grove. Se ha decidido emplear estos sensores por dos motivos importantes: Son sensores de bajo consumo, no consumen gran cantidad de batería para su correcto funcionamiento. Se conectan fácilmente a la placa. Incorporan un conector I2C. Tamaño reducido. Bajo coste. Sensores para la detección de la caída: Acelerómetro ADXL345 Es uno de los elementos principales de MIDS. Sobre él recae el peso de la detección de la caída. Se trata de un acelerómetro de tres ejes, de bajo consumo, ligero y de pequeño tamaño lo cual lo convierte en el mejor candidato para integrar en MIDS. Está conectado a la placa a través de un puerto I2C. Es un acelerómetro de alta sensibilidad que funciona desde 12.5Hz hasta un máximo de 400Hz en su modo de alto rendimiento, capaz de medir aceleraciones en un rango de 16g lo cual facilita la detección de todo tipo de caídas, desde las más suaves hasta caídas extremadamente bruscas. Con un rango operativo de temperatura de -40 a 85oC y una resolución de salida seleccionable entre 10 o 13 bits, es una buena opción para el sistema propuesto. Figura 4.12: Acelerómetro ADXL345. 88
Figura 4.13: Respuesta del ADXL345 en su orientación respecto a la gravedad. Actuadores: 1. Buzzer La función del Buzzer es alertar al usuario de que el estado de alerta se ha activado. El componente principal del Buzzer-Grove es un buzzer piezoeléctrico que, cuando se activa, produce un pitido fuerte. Se conecta a la placa a través del puerto UART y mediante el uso de GPIO. Figura 4.14: Buzzer Grove v1.2. 2. Touch Sensor Para introducir la funcionalidad de botón supresor del estado de alerta, se ha introducido un sensor táctil. Este sensor de Grove detecta los cambios de capacidad producidos cuando se pulsa con un dedo. Al igual que el buzzer, el touch sensor tambień se conecta a través de UART y hace uso de GPIO. 89
4.3.2. Smartphone con la aplicación de alerta 4.3.2.1. Hardware La aplicación está desarrollada para una API 19 o superior. No es necesario que disponga de un procesador potente ya que los únicos recursos requeridos por la aplicación son la conexión Wi-Fi y la realización de las llamadas. 4.3.2.2. Software Descripción general de MIDS Assistant MIDS Assistant es la aplicación que conecta un teléfono móvil con la placa BBG equipada con sensores (sistema MIDS). Se encarga de recibir una alerta del detector de caídas, y llamar a una serie de contactos añadidos por el usuario. Es una aplicación pensada para que sea sencilla su utilización. Con solo apretar un botón, la conexión se establece y en unos pocos pasos es posible añadir los contactos a la agenda de llamadas, así como eliminar los mismos. Arquitectura de MIDS Assistant MIDS Assistant está construida sobre una API mínima 19, pudiendo ser utilizada por un 72,7 % de los usuarios de Android. Además del gran número de usuarios que puedan acceder a ella, al estar construida en esa API, es posible utilizarla dentro del living lab virtual PHAT. Su diagrama de clases se incluye en la figura 4.22 y presenta las actividades y servicios detallados a continuación. Actividades: MainActivity: Crea el servicio que permite que MIDSApp trabaje en segundo plano y permite acceder al menú de contactos. También informa, si se ha recibido una alerta, de si las llamadas de CallActivity han sido respondidas o no. ContactsActivity: Despliega los contactos añadidos (hasta un máximo de 6), incorpora la opción de borrar un contacto concreto y permite acceder al menú de creación de contactos. AddContactActivity: Un formulario con los campos necesarios para crear un nuevo contacto. 96
CallActivity: Esta actividad es la más importante de la aplicación. Una vez recibida una alerta, CallActivity comienza a llamar de manera circular a la lista de contactos. Si una de las llamadas es respondida, cierra el bucle de llamadas. Es una forma de asegurarse de que el paciente ha sido atendido. Servicios: AlertService: este servicio, ejecutado siempre en segundo plano tras pulsar el botón que sincroniza con el detector, es el encargado de realizar la conexión con el dispositivo detector, del cual recibe información sobre el estado del paciente. En caso de recibir el mensaje de “alerta por caída”, es el encargado de activar la actividad de llamadas. 97
Figura 4.22: Diagrama de clases de la aplicación móvil MIDSAsssistant. 98
Funcionamiento de MIDS Assistant Figura 4.23: Diagrama de actividad de la aplicación móvil MIDSAssistant. 99
El diagrama de la figura 4.23 explica el funcionamiento general de nuestra aplicación. Al iniciarla, se lanzaría MainActivity. Esta actividad principal permitirá el acceso a creación y borrado de contactos, así como a establecer la conexión con el dispositivo detector. Una vez establecida esa conexión, si se detectase cualquier alerta, la app comenzaría a llamar y/o a mandar SMS. Se podría decir que esta aplicación tiene dos grandes apartados: gestión de contactos y respuesta de emergencia. Cabe destacar que, tal y como indica la nota de la parte inferior izquierda de la imagen, la aplicación cuenta con unas opciones que permiten configurar los siguientes apartados a gusto del usuario: El número de veces que se llamará a la lista de contactos creada, si se produce una caída. Decidir si enviar o no un SMS si no se ha respondido ninguna llamada. Activar o desactivar una alerta sonora si se ha producido un error en la aplicación. Indicar si existe un cuidador con aplicación. Si está marcado sí, MIDSAssistant no realizará ninguna tarea. Si no hay cuidador, esta aplicación funcionará siguiendo el proceso normal. Activar o desactivar la el reintento de establecimiento de conexión a la red si se ha producido un problema y se ha desconectado. Esto ahorraría al usuario la necesidad de recordar pulsar el botón sincronizar si ha habido algún incidente en la conexión. A continuación, se expondrán diagramas de secuencia mostrando las acciones concretas que lleva a cabo la aplicación: Gestión de contactos Como se indica en la el diagrama 4.24 tras pulsar en la actividad principal el botón contactos, y a continuación el botón añadir contacto en la siguiente ventana que aparezca, aparecerá un formulario. Este formulario cuenta con campos para nombre, número (de teléfono) y prioridad. Una vez relleno, pulsando el botón de aceptar creamos el nuevo contacto. Este formulario controla que los datos introducidos tengan el formato adecuado. Soporta números de teléfono fijo de toda la península (9* *** ** **), y teléfonos móviles incluyendo los más recientes (6** ** ** ** o bien 7** ** ** **). 100
Figura 4.24: Diagrama de secuencia de la aplicación móvil MIDSAssistant. Añadir contacto. Respecto a la prioridad, se busca que esté entre 1 y 10, siendo el número 1 el más prioritario y 10 el menos prioritario. Si al crear un nuevo contacto se le asigna un número de prioridad ya existente, el usuario puede decidir si sustituirlo degradando al antiguo contacto o bien buscar otro número de prioridad no ocupado. El diagrama de la figura 4.25 explica cómo borrar un contacto. Al abrir la actividad Contactos, se despliega una lista con cada uno de los contactos registrados. Todos con un botón “borrar” a la derecha. Al pulsar en uno de esos botones y posteriormente confirmar, ese contacto quedará eliminado. 101
Figura 4.25: Diagrama de secuencia de la aplicación móvil MIDSAssistant. Borrar contacto. Respuesta de emergencia El diagrama de la figura 4.26 explica la reacción de la aplicación al recibir una alerta, procedente del dispositivo detector si tras producirse una caída no se ha pulsado el botón de no-alerta o no se ha detectado que el paciente se haya levantado. Tiene dos formas de reaccionar, en cascada: primero llama a todos los contactos registrados y si alguien responde, termina el proceso de respuesta ante la alerta enviando un SMS a esta persona informando de la caída. En el caso de que nadie responda, envía un SMS avisando de que la persona necesita asistencia al contacto más prioritario si esta opción está marcada en las opciones de la aplicación. 102
Figura 4.26: Diagrama de secuencia de la aplicación móvil MIDSAssistant. Respuesta ante una alerta. Descripción general de MIDS Caretaker MIDS Caretaker es una aplicación derivada de MIDS Assistant cuya función consiste en notificar de una posible caída a una persona encargada del cuidado del paciente. El sistema puede funcionar correctamente con el uso exclusivo de MIDS Caretaker, o bien en combinación de ésta y MIDS Assistant. 103
Arquitectura de MIDS Caretaker Figura 4.27: Diagrama de clases de la aplicación móvil MIDSCaretaker. Se puede observar que la estructura es equivalente a la de MIDSAssistant, prescindiendo de la lista de contactos, y del código que realizaba las llamadas. 104
Funcionamiento de MIDS Caretaker Figura 4.28: Diagrama de actividad de MIDSCaretaker. El funcionamiento de esta aplicación es también similar al de MIDSAssistant. La diferencia radica en la respuesta ante la alerta. La única función de Caretaker es emitir un sonido y recibir notificaciones emergentes para alertar al cuidador sobre la caída del paciente. Esta aplicación también alberga opciones, pero más limitadas que MIDSAssistant. Únicamente son necesarias: Activar o desactivar la alerta auditiva si se ha producido un error. Activar o desactivar la reconexión automática 20 segundos después de que se pierda la conexión con el dispositivo detector. 105
5.1.2. Caso de uso de ejemplo Paco es un paciente simulado de 77 años que vive con su mujer Juana. Entre sus ADL se encuentran tareas como ir a la cocina, sentarse, comer o dirigirse al salón. Mientras camina hacia el salón, sufre una caída, quedando en el suelo. El sistema detectará la situación, activando el estado de alerta y la señal sonora. Juana escuchará este pitido y acudirá a asistirle. Figura 5.7: El paciente realiza sus ADL sin incidentes en el entorno simulado. Se implementó una versión de prueba utilizando un smartphone integrado en la simulación que permitiera probar la detección, respuesta sonora y envío de la alerta antes del despliegue del dispositivo real, como se observa en las figuras 5.7, 5.9 y 5.8. 112
Figura 5.8: Reacción del sistema ante una caída en el entorno simulado. Figura 5.9: Reacción del sistema ante una caída en el entorno simulado, interconexión de dispositivos. 113
5.2. Sistema real Para el desarrollo del sistema, se monitorizaron los valores registrados por el acelerómetro ADXL345 de los movimientos diarios de un voluntario al que se informó de la finalidad de la recogida de los datos. El objetivo de la recogida y análisis de estos datos era profundizar en el estudio de la evolución de estos valores y tomar decisiones respecto al enfoque de resolución del problema. En este proceso no se recogieron datos de caídas, por lo que no se vió comprometida en ningún momento la seguridad del voluntario. Por otra parte, también se informó de que en ningún momento se vincularía su identidad con los datos recogidos de manera que no se vería comprometida su privacidad. Las actividades que se pidió al sujeto que realizase para las pruebas son las siguientes: 1. Caminar 10 metros. 2. Sentarse y levantarse de un sillón. 3. Sentarse y levantarse de una silla de la cocina. 4. Sentarse y levantarse de un taburete bajo. 5. Sentarse y levantarse de la cama. 6. Acostarse y levantarse de la cama. Se realizaron de 5 repeticiones de cada actividad, que permitieron encontrar los rangos de normalidad de estas actividades, pudiendo establecer los valores medios. Por otro lado, ya bajo las medidas de seguridad oportunas indicadas más adelante, se comenzaron a recoger los valores registrados durante caídas simuladas. En este caso, los sujetos de experimentación fueron los integrantes de este proyecto. Se realizaron las siguientes simulaciones de caídas: 1. Caída hacia delante. 2. Caída hacia atrás. 3. Caída de lado hacia la derecha. 4. Caída de lado hacia la izquierda. 114
Para su realización, se empleó un prototipo diseñado por nosotros, de manera que fuera lo más sencillo posible y permitiera realizar las pruebas rápidamente. En concreto se hizo una caja de cartón para el dispositivo, en la cual se incluían tanto la placa Beaglebone como la batería portable y el Dongle Wifi. Figura 5.10: Prototipos empleados en la monitorización y las pruebas. Para su sujección, intentando que fuese lo más parecido al diseño final, se utilizó velcro para unir la caja a un cinturón, de manera que quedase bien sujeto a la cintura. Figura 5.11: Sujeción del prototipo empleado en la monitorización y las pruebas. 115
Posteriormente, se realizaron varias iteraciones para desarrollar un prototipo impreso mediante una impresora 3D. La figura 5.12 muestran dos de las iteraciones realizadas antes de definir el modelo final. (a) Primera iteración. (b) Segunda iteración. Figura 5.12: Prototipos para el sistema detector. Las medidas de seguridad para la monitorización de las caídas fueron el uso de rodilleras y muñequeras para evitar posibles lesiones, así como realizar las caídas sobre una superficie acolchada, no directamente al suelo. Figura 5.13: Medidas de seguridad para las caídas. 116
Figura 5.14: Ejemplo de caída simulada durante las pruebas. 117
Capítulo 6 Experimentación 6.1. Experimentación de ADL y caídas en simulado El uso del entorno de simulación PHAT facilitó la tarea de acotar los intervalos de los valores de normalidad recogidos por el acelerómetro considerando distintos ADLs. Para ello, siguiendo el método de trabajo mencionado en la sección 5.1, implementó una aplicación Android que almacenaba los valores registrados en un fichero de texto, y se simulaban las distintas situaciones mencionadas en la sección 6.1.1. Posteriormente, un programa implementado en Java nos permitió representar de manera gráfica los valores, para su análisis de manera más rápida y sencilla. 6.1.1. Escenarios 6.1.1.1. Caminar Figura 6.1: Valores del acelerómetro al caminar en el simulador. 118
Como podemos observar en la figura 6.1, la variación de la aceleración medida en los distintos ejes durante una simulación en la que Paco solo se desplazaba caminando por la casa fue la descrita en la gráfica anterior. No se observaron cambios bruscos en ninguno de los tres ejes. La variación máxima en esta situación fue en torno a los 0.1 - 0.2 g aunque posteriormente, tras la experimentación en real, se vio que la variación de la aceleración en real es considerablemente más brusca que en el entorno simulado. 6.1.1.2. Sentarse y levantarse Figura 6.2: Valores del acelerómetro al sentarse y levantarse en el simulador. En esta ocasión se utilizó para el registro de los valores una simulación en la que Paco se sentaba y levantaba de una silla de su cocina. Como era de esperar, en la figura 6.2 observamos que se registra una pequeña variación en el eje de la Y que se corresponde con el movimiento de descenso para acercarse a la silla. También se produce una pequeña variación en el eje de la Z y otra algo más brusca en el eje de la X, ambas correspondientes a una inclinación tanto frontal como lateral respectivamente para lograr el movimiento. Dichas variaciones no son relevantes en el caso de los ejes Z e Y, no superando los 0.2 g. En el caso de la X se registra una variación de la aceleración de 0.4 - 0.5 g. 119
6.1.1.3. Tumbarse y levantarse Figura 6.3: Valores del acelerómetro al tumbarse e incorporarse en el simulador. Para el estudio de las variaciones sobre esta actividad, se utilizó una simulación en la que Paco se tumbaba y levantaba de su cama. Según muestra la figura 6.3, la variación en el eje X en esta ocasión no sobrepasa los valores de normalidad. En el eje de la Y se observa, análogamente a sentarse sentarse en una silla, una variación correspondiente al movimiento de descenso para tumbarse. Pasa de valer 1g a unos 0.6g. En el caso del eje Z, se produce el efecto contrario. En valores de normalidad, el valor de la aceleración sobre este eje se sitúa en torno a los -0.3g y al tumbarse pasa a valer unos 0.5g. El efecto al levantarse es el contrario al anterior, se produce una disminución del valor sobre el eje Z y un aumento del valor registrado sobre el eje Y. 120
6.1.1.4. Caída hacia atrás Figura 6.4: Valores del acelerómetro al sufrir una caída hacia atrás en el simulador. En la simulación de la caída hacia atrás, en la que el sujeto queda tumbado de espaldas, la gráfica resultante del análisis de los valores del acelerómetro no responde a ninguno de los patrones vistos anteriormente sino que refleja grandes variaciones bruscas en los tres ejes. En este caso , y para determinar que la caída ha sido hacia atrás, es preciso resaltar la variación sobre el eje Z teniendo este eje una primera variación que va desde -0.3g a 0.5g y que se corresponde con la caída como tal. A continuación se produce una segunda variación sobre los tres ejes que se corresponde con el momento en el que el paciente se incorpora para levantarse. Al final de la simulación, y con el paciente ya incorporado, los valores de la aceleración retornan a la normalidad. 121
Figura 6.11: Valores ADXL345 en caída hacia la derecha. En los experimentos de caídas laterales, como en de la figura 6.11 muestran picos invertidos muy grandes en el eje X en caso de caer hacia el lado derecho, mientras que el pico es normal en este eje al caer hacia la izquierda. 6.2.2. Resultados y funcionamiento en el deslpiegue real Tras este análisis, se han obtenido los siguientes rangos para cada una de las actividades, resumidos en la siguiente tabla: Rango eje X Rango eje Y Rango eje Z Caminar [-0’125, 0’344] [0’500, 1’344] [-0’125, 0’562] Sentarse [-0’437, 0’469] [0’469, 1’125] [-0’469, 0’969] Tumbarse [-0’531, 0’625] [0, 1’0944] [-1’062, 0’656] Caída frontal [-0’937, 6’656] [-6’125, 3’156] [-0’625, 5’094] Caída hacia atrás [-2’437, 2’125] [-1’906, 6’094] [-3’625, 1’156] Caída lateral derecha [-5’375, 2’187] [-1’25, 3’094] [-1’625, 3’594] Caída lateral izquierda [-1’094, 3’875] [-2’125, 2’875] [-2’062, 2’375] Tabla 6.2: Rangos de valores en los tres ejes de los experimentos realizados en entorno real. Por otra parte, se analizó también la variación máxima entre valores consecutivos en cada actividad. 128
Máxima variación X Máxima variación Y Máxima variación Z Caminar 0’125 0’21875 0’21875 Sentarse 0’15625 0’09375 0’0625 Tumbarse 0’21875 0’125 0’15625 Caída frontal 6’53125 4’59375 3’1875 Caída hacia atrás 1’875 2’78125 1’9375 Caída lateral derecha 2’5625 1’59375 3’4375 Caída lateral izquierda 1’5625 1’125 2’125 Tabla 6.3: Máximas variaciones en valores consecutivos durante los experimentos realizados en entorno real. 129
6.2.3. Algoritmo de detección propuesto A la luz de los resultados obtenidos, la estrategia de detección de caídas ha sido detectar las caídas como variaciones de los valores normales de la aceleración durante las ADL. Tras la detección de una situación susceptible de ser una caída, como será el registro de valores del acelerómetro fuera de los rangos de normalidad, se complementará con la obtención de variaciones muy grandes entre valores consecutivos. Si se dan estas dos circunstancias, capaces de ser identificadas gracias a la monitorización experimental mediante el sensor, se comprobará la posición final del paciente. En caso de encontrarse en una posición horizontal, se procederá a activar el sistema de alerta por caídas. En este momento, se activará el buzzer, produciendo la alerta sonora a posibles acompañantes del paciente presentes en la vivienda. Desde entonces, se ha establecido un intervalo de un minuto en el cual todavía no se alerta a las aplicaciones MIDSAssistant y/o MIDSCaretaker, en el cual se puede desactivar el sistema de alerta en caso de que realmente no se haya producido una caída y se trate de un falso positivo, o la caída no tenga un nivel de severidad que implique proceder a esta notificación. De manera complementaria, se monitoriza la actividad del paciente, de manera que si consigue erguirse durante un intervalo estimado en 10 segundos, se considera que la situación de alerta ha sido solventada y se desactiva automáticamente el estado de alerta. Los valores de los umbrales establecidos para el algoritmo son los siguientes: X Y Z Rango de normalidad (-0’6, 1) (-0’5, 2’5) (1’5, Infinito) Variación máxima 0’5 0’5 0’5 Tabla 6.4: Tabla de valores establecidos para el algoritmo. 130
Figura 6.12: Diagrama de flujo del algoritmo propuesto. 131
6.3. Pruebas del sistema 6.3.1. Detección de caídas Este algoritmo se probó inicialmente repitiendo las ADL mencionadas anteriormente, para confirmar que no se activa el sistema de alerta en ninguna situación inadecuada, eliminando así los máximos falsos positivos posibles. Posteriormente, se repitieron las pruebas de caída simuladas, clasificadas en los cuatro grandes grupos según la posición final y orientación final del cuerpo tras la caída. Esto permitió ajustar los umbrales para obtener el mayor porcentaje de efectividad del sistema posible. Los resultados durante la monitorización de ADL se muestran en la tabla 6.5. Acción Experimentos Detecciones correctas Porcentaje de acierto Caminar 10 metros 5 5 100 % Sentarse y levantarse del sillón 10 10 100% Sentarse y levantarse de la silla de cocina 5 5 100 % Sentarse y levantarse del inodoro 5 5 100 % Sentarse y levantarse de un taburete 10 10 100% Sentarse y levantarse de la cama 10 10 100% Tumbarse y levantarse de la cama 10 10 100% Tabla 6.5: Tabla de resultados de las pruebas del sistema en ADL. Los resultados de las pruebas en caídas simuladas se adjuntan en la tabla 6.6. 132
Acción Experimentos Detecciones correctas Porcentaje de acierto Caída frontal 21 21 100% Caída hacia atrás 21 18 85% Caída lateral derecha 23 20 86.95% Caída lateral izquierda 21 19 90% Tabla 6.6: Tabla de resultados de las pruebas del sistema en caídas. Durante las pruebas se detectaron un total de 2 falsos positivos al levantarse del suelo de manera brusca. Finalmente, obtuvimos los porcentajes de acierto en la detección de los distintos tipos de caídas mostrados en la tabla anterior, con un porcentaje total de acierto aproximado del 90.78 %. 133
6.3.2. Respuesta del sistema completo ante una caída Se han reproducido una serie de casos para probar el funcionamiento del sistema. Estos permitieron probar los casos de uso definidos en la sección 4.1, comprobando además las distintas configuraciones posibles del sistema MIDS. En las siguientes tablas se resume la respuesta global del sistema obtenida en cada uno de ellos así como las carencias detectadas en el transcurso de los mismos. Actores implicados Paciente y acompañante. Escenario El paciente sufre una caída mientras camina por su vivienda. Lleva el dispositivo detector encendido. Aplicaciones instaladas Ninguna. Respuesta del sistema 1. El dispositivo detecta la caída. 2. Se activa la alerta sonora. 3. El acompañante escucha la alerta y acude en su ayuda. 4. No sufre una caída con consecuencias graves, por lo que el acompañante desactiva la alerta pulsando el botón y asiste al paciente. Fallos detectados Carencia del sistema: problema en este modo de funcionamiento si el acompañante no escucha la alerta sonora. Tabla 6.7: Paciente acompañado con únicamente el detector. 134
Actores implicados Paciente solo en su vivienda. Escenario El paciente sufre una caída mientras camina por su vivienda. Lleva el dispositivo detector encendido y la aplicación está sincronizada con el dispositivo. Aplicaciones sincronizadas MIDS Assistant con dos contactos añadidos. Respuesta del sistema 1. El dispositivo detecta la caída. 2. Se activa la alerta sonora pero no hay nadie más en la vivienda. 3. Tras un periodo de tiempo establecido, se envía la alerta a la aplicación MIDS Assistant la cual comienza a llamar a la lista de contactos. 4. En este caso, el primero de los contactos responde y MIDS Assistant le envía un mensaje SMS informando de la situación de alerta. Fallos detectados En este caso la alerta se recibe correctamente y no se detecta ningún fallo. Esta situación resulta ser la más crítica ya que no hay nadie en la vivienda y es muy importante que no se pierda la conexión. Tabla 6.8: Paciente acompañado con la aplicación MIDS Assistant sincronizada. 135
Actores implicados Paciente y acompañante. Escenario El paciente sufre una caída mientras camina por la terraza de su vivienda. El acompañante se encuentra en otra habitación, alejada de la terraza. Aplicaciones sincronizadas MIDS Caretaker Respuesta del sistema 1. El dispositivo detecta la caída. 2. Se activa la alerta sonora pero en este caso el acompañante no la escucha debido al ruido que hay en la terraza. 3. El dispositivo envía una alerta a MIDS Caretaker. 4. El acompañante recibe en su teléfono la notificación y acude en ayuda del paciente. Fallos detectados En este caso la alerta sonora no cumplió su función pero gracias a MIDS Caretaker, el cuidador pudo acudir en ayuda del paciente. Esta situación podría ser crítica en el caso en que la aplicación MIDS Caretaker se desconectara. Tabla 6.9: Paciente acompañado con la aplicación MIDS Caretaker sincronizada. 136
Actores implicados Paciente y acompañante. Escenario El paciente sufre una caída mientras se levanta del sofá y queda sentado. Aplicaciones sincronizadas MIDS Caretaker y MIDS Assistant con la opción de cuidador habilitada. Respuesta del sistema 1. El dispositivo no es capaz de detectar la caída. Fallos detectados El algoritmo de detección no contempla los casos en lo que el paciente no quede en posición horizontal. Se propone la implementación de un algoritmo más sofisticado que contemple este tipo de caídas. Tabla 6.10: Paciente acompañado con las aplicaciones MIDS Assistant y MIDS Caretaker sincronizadas, sin detectar la caída. 137
Capítulo 9 Anexos 9.1. MIDS Assistant: Manual de usuario 144
9.1.1. Instalación ¡Bienvenido a MIDSAssistant! Este breve manual te explicará los pasos a seguir para configurar la aplicación en tu teléfono móvil para que estés protegido (tú o alguno de tus seres queridos) en un santiamén. Lo primero es lo primero. Necesitamos descargar la aplicación desde Google Play, o bien desde nuestra web www.midsassistant.com. Si ha elegido la primera opción, la app se instalará automáticamente. En caso contrario, debe ejecutar el archivo .apk descargado. Si es necesario, debe dar permisos para instalar aplicaciones de fuentes desconocidas. ¡Tranquilo! Somos de fiar. Una vez instalada, abra la aplicación y aparecerá ante usted esta ventana: Figura 9.1: Pantalla principal de MIDS Assistant. 145
9.1.2. Conexión con MIDS Como pueden observar, en el menú principal hay tres grandes botones: Uno arriba a la derecha, que accede al menú de opciones, y dos centrales. En este apartado, haremos referencia al botón Sincronizar. Este es el que conecta la Aplicación que está usted manejando con el aparato detector de caídas. Al pulsar Sincronizar, aparecerá un pequeño aviso notificando de que se está intentando establecer la conexión, como muestra la figura de la izquierda. Si se logra establecer la conexión, la pantalla principal pasará a ser la de la derecha. (a) Estableciendo conexión. (b) Conexión establecida. Figura 9.2: Sincronización de MIDS Assistant con el dispositivo detector. Ahora su móvil está listo para reaccionar si usted sufre una caída, avisando a sus contactos. Como añadido, MIDSAssistant posee la característica (si usted como usuario decide activarla) de reconectarse con el dispositivo detector automáticamente si por algún error ajeno a usted la aplicación se desconectase. Las pantallas que vería serían estas: 146
(a) Notificación recibida al desconectarse. (b) Reconexión en 20 segundos. Figura 9.3: Reconexiones en MIDS Assistant. Figura 9.4: Aviso recibido por MIDS Assistant cuando no está habilitado el Wi-Fi. Tal y como puede observar, la propia aplicación se reconectará automáticamente en un tiempo determinado sin que usted se tenga que preocupar por nada. El único requisito fundamental para que haya una correcta conexión con el aparato detector de caídas es que tanto el móvil como el dispositivo estén conectados a la misma red. Para su comodidad, MIDSAssistant le informará si está conectado a la red: 147
9.1.3. Creación de contactos Pasemos al segundo botón de los centrales, Contactos. Al pulsar este botón, entrarás en este menú: Figura 9.5: Pantalla contactos en MIDS Assistant. Esta pantalla le permite acceder a la lista de contactos que tiene usted creada. Originalmente, estará vacía. Se irá llenando a medida que agregue usted nuevos contactos. Esto nos lleva a la siguiente función: Añadir un nuevo contacto. Figura 9.6: Pantalla de añadir contactos en MIDS Assistant. 148
Aunque parezca autoexplicativo, para su comodidad describiremos cada uno de los apartados de este sencillo formulario: Nombre del nuevo usuario: Aquí iría el nombre del contacto que desea usted añadir. Número del nuevo usuario: En este campo se introduciría el teléfono del contacto. La aplicación admite fijos y móviles. Prioridad de llamada (de 1 a 10): Este es el valor que ordena su lista de contactos. Si se sufre una caída llamará a los contactos agregados en ese orden siendo 1 la mayor prioridad y 10 la menor. Pueden surgirle una serie de problemas a la hora de introducir los datos: (a) Contacto repetido. (b) Prioridad ya existente. (c) Número incorrecto. Figura 9.7: Mensajes de error en MIDS Assistant añadiendo contactos En la pantalla de la izquierda comprobamos que el usuario ha introducido un número ya existente en la lista de contactos. Es una mera formalidad para evitar errores al tratar la respuesta de emergencia de MIDSAssistant. En la pantalla del centro, nos explican que la prioridad asignada ya existe. Puede usted decidir si elegir otro nivel de prioridad para ese nuevo contacto o reordenar la lista ya creada. En la pantalla de la derecha, podemos ver que no se ha introducido correctamente el número de teléfono. Puede que le haya faltado una cifra o haya 149
escrito de más. Los formatos soportados son: 6** ** ** ** ->móvil 7** ** ** ** ->móvil (nuevo) 9* *** ** ** ->Teléfono fijo Si se han introducido correctamente los datos y pulsa aceptar, un nuevo contacto habrá sido creado satisfactoriamente y podrá ver las siguientes pantallas: (a) Mensaje de confirmación al añadir un contacto. (b) Lista de contactos Figura 9.8: Añadiendo contactos en MIDS Assistant. 9.1.4. Opciones En esta sección explicaremos lo referente a los aspectos configurables de la aplicación. Este es el menú al que se accede tras pulsar en el botón del Engranaje y una vez dentro, pulsando general: 150
Figura 9.9: Lista de opciones disponibles en MIDS Assistant. Este menú de opciones le permitirá configurar diferentes aspectos: Notificar al cuidador: existe una aplicación paralela a MIDSAssistant llamada MIDSCaretaker (hablaremos sobre ella en la sección 6). Esta opción indica a nuestra aplicación cómo debe reaccionar ante una alerta de caída. Si está marcado sí, será MIDSCaretaker quien recibirá las alertas y se encargará de ejecutar correctamente la respuesta de emergencia. Si está marcado no, MIDSAssistant funcionará tal y como explicaremos en la sección 5. Enviar SMS: tal y como viene explicado en la imagen anterior, esta opción habilita o deshabilita el envío de un SMS a su contacto más prioritario si nadie ha respondido a las llamadas de aviso realizadas en la respuesta de emergencia de MIDSAssistant. Número de veces a recorrer su lista de contactos: esta opción establece cuántas veces se llamará a cada uno de sus contactos si se activa la respuesta de emergencia. Pueden fijarse ser de 1 a 3 veces. Emitir sonido: esta opción permite, si está activada, que el teléfono emita un sonido avisando de que se ha producido un error de conexión del sistema. 151
Intentar reconectar: esta opción habilita la reconexión automática del sistema tras 20 segundos si, por cualquier causa, hubiese un error. Alta accesibilidad: Habilita una interfaz adaptada a personas muy mayores o con problemas de visibilidad, tal y como se indica en la sección Accesibilidad. 9.1.5. Respuesta de emergencia En la penúltima sección del manual explicaremos cómo su aplicación reacciona ante un aviso de caída: (a) Notificación recibida al producirse una caída. (b) Mensaje recibido al enviarse un SMS Figura 9.10: Respuesta de emergencia en MIDS Assistant. En la pantalla de la izquierda comprobamos cómo su smartphone recibe una notificación en el momento en el que el dispositivo detector de caídas envía una alerta. Entonces, comenzará la respuesta de emergencia. MIDSAssistant comenzará a llamar a cada uno de los contactos que haya registrado previamente. Pueden darse dos situaciones: 152
Una de las llamadas ha sido contestada: en este caso, para asegurar que su contacto quede informado correctamente sobre la situación, se enviará un SMS. Ninguna de las llamadas ha sido respondida: en este caso, si la opción está habilirada, se enviará un SMS a su contacto más prioritario, para intentar que se produzca la más inmediata respuesta. 9.1.6. Accesibilidad Las personas a las que van destinadas estas aplicaciones son un público muy especial. Por ello, hemos decidido habilitar una opción para los ancianos de mayor edad o con problemas de visión que vayan a utilizar nuestro sistema, intentando diseñar una interfaz más adecuada, con elementos más grandes y colores que contrasten. (a) Pantalla principal. (b) Lista de contactos. (c) Añadir contactos. Figura 9.11: Aplicación MIDS Assistant en modo Alta accesibilidad. 9.1.7. MIDS Caretaker Llegamos al final del manual. MIDSCaretaker es una aplicación paralela a MIDSApp, con un comportamiento similar. Esta aplicación está ideada para gente que tenga una persona a su cuidado de manera regular. Una vez instalado MIDSCaretaker en el smartphone de la persona que se encargue de usted, en lugar de realizar llamadas y/o enviar un SMS, emite un aviso sonoro para que acuda en su ayuda de manera inmediata. 153