SiMoA: Sistema de Monitorización del Asma

Transcripción

1 UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA GRADO EN INGENIERÍA INFORMÁTICA TECNOLOGÍA ESPECÍFICA DE TECNOLOGÍAS DE LA INFORMACIÓN TRABAJO FIN DE GRADO SiMoA: Sistema de Monitorización del Asma Cristian Carretón Ruiz Diciembre, 2014

2

3 SIMOA: SISTEMA DE MONITORIZACIÓN DEL ASMA

4

5 UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA Tecnologías y Sistemas de Información TECNOLOGÍA ESPECÍFICA DE TECNOLOGÍAS DE LA INFORMACIÓN TRABAJO FIN DE GRADO SiMoA: Sistema de Monitorización del Asma Autor: Cristian Carretón Ruiz Director: José Bravo Rodríguez Director: Iván González Díaz Diciembre, 2014

6

7 Cristian Carretón Ruiz Ciudad Real Spain Teléfono: c 2014 Cristian Carretón Ruiz Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". Se permite la copia, distribución y/o modificación de este documento bajo los términos de la Licencia de Documentación Libre GNU, versión 1.3 o cualquier versión posterior publicada por la Free Software Foundation; sin secciones invariantes. Una copia de esta licencia esta incluida en el apéndice titulado «GNU Free Documentation License». Muchos de los nombres usados por las compañías para diferenciar sus productos y servicios son reclamados como marcas registradas. Allí donde estos nombres aparezcan en este documento, y cuando el autor haya sido informado de esas marcas registradas, los nombres estarán escritos en mayúsculas o como nombres propios. i

8

9 TRIBUNAL: Presidente: Vocal: Secretario: FECHA DE DEFENSA: CALIFICACIÓN: PRESIDENTE VOCAL SECRETARIO Fdo.: Fdo.: Fdo.: iii

10

11 Resumen A día de hoy la tecnología que más rápido esta evolucionando en cuanto a potencia y expansión mundial son los smartphones. Normalmente el uso que se le da al teléfono es el que siempre ha tenido que es el de mantener a personas en contactos y en los últimos tiempos con el "boom"de las aplicaciones móviles también como principal dispositivo de ocio. En este Trabajo Fin de Grado (TFG) se quiere ir más allá del entretenimiento y la comunicación, se crea una aplicación dentro del marco m-health que consiste en hacer de los smartphone un dispositivo sanitario más, ya sea para el control de alguna enfermedad, telemedicina o las múltiples disciplinas que engloba m-health. La enfermedad que va a ser controlada con esta aplicación es el asma que afecta a millones de personas en todo el mundo y cuyo mejor seguimiento es realizar espirometrías con la mayor frecuencia posible y ver como varía la función pulmonar. Para realizar este seguimiento se ha desarrollado una aplicación que es capaz de determinar el estado respiratorio del paciente sin necesidad de hacer una espirometría forzada que en muchas ocasiones causa crisis asmáticas en enfermos crónicos. Otro aspecto a destacar es la usabilidad ya que los usuarios solamente deben grabarse hablando con el teléfono móvil como si estuvieran realizando una llamada y la herramienta se encargará de facilitar al usuario una estimación de su estado respiratorio. V

12

13 Abstract Today the technology that is evolving fastest in terms of power and global expansion is mobiles. Normally the use given to the phone is to keep people in contact and in recent times with the boom in apps smartphone has become the main mobile entertainment device. This TFG want to go beyond entertainment and communication, SiMoA is created within the m-health framework which consists of making the smartphone a medical device plus either control disease, telemedicine or multiple disciplines covered m-health. The disease which is going to be controlled with this application is asthma that affects millions of people around the world and whose better monitoring is spirometry as often as possible and see how change pulmonary function. To perform this monitoring an application has been developed that is able to determinate the respiratory status of the patient without the need for spirometry that often cause asthma attacks in chronically ill. Another aspect is usability because users only need to be recorded talking with mobile phone as if they were on a call and the tool will provide the user his status. VII

14

15 Agradecimientos Cuantas vivencias desde la primera vez que entré por la puerta de la ESI, que lejos se veía este momento en aquellos entonces. Han sido años de mucho trabajo y sobre todo de conocer a mucha gente, algunos de los cuales se han convertido en amigos para toda la vida. Cada práctica o cada entrega siempre ha sido una historia, miles de anécdotas que recordaré siempre esos momentos en los que la impotencia era tal que lo único que nos quedaba era ponernos a sordear y así por lo menos se descongestionaba un poco la cabeza y ayudaba a verlo después de otra forma. Agradecer a mi círculo más íntimo de amigos por todo lo que me han dado. César que fue el primero en aparecer y ficharme para sus grupos de física y como pareja en programación, Javi con sus constantes bromas y su perseverancia que nunca da nada por perdido, Jesús que tanto nos ha enseñado y entregas ha salvado como nociones tecnológicas ha dado, Eulalio que siempre estaba disponible pero desde su cuartel general en Las Casas, David con el que sufrí los últimos embistes de la carrera y Rubén con su fiel pijama. Mencionar también a los tortugos que siempre han estado ahí con sus trabajos a última hora y sus fiestas. Eva, tu te mereces un libro para ti solita, podría pasarme la tarde agradeciendote todo lo que has hecho y haces por mi pero me centrare en tu paciencia que cuando la mía se gastaba siempre aportabas de la tuya para salvar cualquier problema que tuviera. Gracias por estar ahí siempre y darme esa calma necesaria para enfrentarse a las cosas que peor se me dan, y sobre todo por soportarme que no es tarea fácil. Mención especial a Iván, sin él todo lo que se redacta a continuación habría sido totalmente imposible de llevarlo a cabo. Te estaré muy agradecido siempre por todo lo que me has ayudado desde que esto echó a andar y por supuesto los mesecitos que te he pegado bombardeandote a correos a todas horas. Por último agradecer su apoyo a toda mi familia y en especial a mis padres que confiaron en mi cuando peor estaba la cosa y lo más fácil hubiera sido traerme de vuelta a casa. A todos los mencionados y a los que queden en el tintero... MUCHAS GRACIAS Cristian IX

16

17 En cada lucha aquel que va a muerte es el que gana ese terreno xi

18

19 Índice general Resumen V Abstract VII Agradecimientos IX Índice general XIII Índice de cuadros XVII Índice de figuras XIX Índice de listados XXIII Listado de acrónimos XXV 1. Introducción Contexto del Trabajo Fin de Grado Asma Extensión del Smartphone y mhealth Problema y solución propuesta Descripción del problema Descripción de la solución Estructura del documento Objetivos Hipótesis de trabajo Objetivo general Objetivos específicos Relativos a la detección de eventos respiratorios Relativos a la valoración del estado respiratorio XIII

20 Relativos a la aplicación Android Herramientas y medios de trabajo Lenguajes de programación y sistema operativo Medios Hardware Medios Software Antecedentes Aproximación de los valores espirométricos Por medio del smartphone sin dispositivos adicionales Por medio de un hardware específico Por medio de una aplicación de escritorio y un micrófono Reconocimiento de acciones respiratorias Monitorización de los valores espirométricos Concienciación a niños con asma Seguimiento vía Short Message Service (SMS) Diferenciación entre respiraciones sanas y respiraciones con alguna patología Extracción de características en la voz de asmáticos utilizando MFCCs Clasificación de sonidos respiratorios utilizando análisis cepstral y GMM Conceptos específicos del dominio Algoritmo 1: detección de eventos respiratorios en habla continua MFCC: Mel Filter Cepstral Coefficents Construcción del template Primer filtrado de la señal Delimitación de eventos respiratorios Segundo filtrado de la señal Algoritmo 2: Valoración del estado respiratorio del usuario Método de trabajo Metodologías ágiles Prototipado evolutivo Desarrollo Inicio Módulo I: Captura señal de audio Módulo II: Espirometría forzada y reconocimiento de eventos respiratorios xiv

21 Módulo IIa: Espirometría forzada Módulo IIb: Obtención de los vectores de características de los Frames Módulo III: Similitud template - muestra Módulo IV: Valoración del estado respiratorio del usuario Módulo V: Diseño e implementación de la aplicación móvil Diagramas UML Diagrama de casos de uso Diagrama de clases Diagramas de secuencia Resultados Detección de respiraciones Determinación estado respiratorio Usuarios que presentan asma crónica Usuarios que presentan asma estacional Usuarios que no presentan asma Conclusiones y propuestas Limitaciones encontradas Objetivos alcanzados Propuestas de trabajo futuro Publicaciones Conclusión personal Referencias 79 Recogida muestras comparativas: smartphone - espirómetro Recogida correspondiente al trabajo en el módulo IIa Recogida correspondiente al trabajo en el módulo IV Distribución de la carga de trabajo del proyecto 89 Elección conjunto de entrenamiento y cálculo Bm/2 93 xv

22

23 Índice de cuadros 4.1. Criterios para escoger los límites del evento respiratorio Diferencias entre metodologías ágiles y tradicionales Relación colores-frecuencias Descriptores estadísticos Voz Descriptores estadísticos Respiración Resultados arrojados por el primer algoritmo Pruebas finales determinación estado respiratorio Desglose (en meses) del desarrollo del proyecto XVII

24

25 Índice de figuras 1.1. Efecto que causa un ataque de asma Puntos en los que colocar el estetoscopio para realizar la auscultación Ejemplo de una espirometría en un hospital Medidor glucosa AgaMatrix Tensiometro Withings Esquema de la solución propuesta Miembros de la Open Handset Alliance Arquitectura de Android Dispositivo Android empleado en el desarrollo Espirómetro digital portátil SP SDK Manager Captura de la herramienta Trello con sus tres tableros Procedimiento de extracción de características Componentes que forman mobilespiro Diferenciación de silencio inicial - evento respiratorio - silencio final Vista del entorno web de CHESS Los 20 primeros coeficientes correspondientes a las personas sanas Los 20 primeros coeficientes correspondientes a las personas asmáticas Ejemplo de gaussianas Obtención del vector de características en base a un sonido Aplicación método pre-énfasis, donde se enfatizan las frecuencias altas Gráfico división de la señal en subframes con solapamiento Ejemplo banco de filtros Mel Proceso de multiplicación de filtros y periodograma Gráfico formación del cepstrograma a partir coeficientes MFC Procedimientos que se aplicarán sobre la señal en este filtro XIX

26 4.8. Diagrama sobre la delimitación de eventos respiratorios Ejemplo gráfico de peak y deep Procedimientos a aplicar en el segundo filtrado sobre los candidatos Mezcla de tres funciones gaussianas Esquema funcionamiento EM Distribución datos entrenamiento modelo enfermos Esquema del funcionamiento del prototipado evolutivo Arquitectura de los módulos que forman la aplicación Submódulos y resultado del Módulo I: Captura señal de audio Espectrograma inicial Filtro Filtro Representación gráfica del espectrograma resultante Submódulos y resultado del Módulo IIb: Obtención de los vectores de características de los Frames Ejemplo de muestra recogida por la aplicación: altura, edad, sexo, fecha toma, [asmático/alérgico/sano], estado Submódulos y resultado del Módulo III: similitud template - muestra División en fragmentos respiratorios/voces Aplicación de filtro de medias de 3 puntos sobre el componente b Submódulos y resultado del Módulo IV: Valoración del estado respiratorio del usuario Activity inicial de la aplicación e instrucciones de uso Introducir nombre y comenzar grabación Aspecto de la aplicación durante la grabación Aspecto de la aplicación tras finalizar la grabación Puntero azul y muestra del segundo que se esta reproduciendo Spinner que aparece durante el procesamiento Esta activiy muestra los eventos respiratorios detectados Spinner que aparece mientras se ejecuta el algoritmo Activity final en la que se muestra el estado del paciente Diagrama de casos de uso SiMoA Diagrama de clases algoritmo detección de eventos respiratorios Diagrama de clases algoritmo determinación del estado respiratorio Diagrama de secuencia aplicación filtro Diagrama de secuencia wav-array float xx

27 6.1. Porcentaje de aciertos en la detección de respiraciones Respiraciones detectadas en pepe.wav Ejemplo grabación iphone 4S Ejemplo grabación Nexus Datos aportados por los sujetos Autorización empleada para obtener el consentimiento de las personas que han colaborado División del trabajo por meses Divisón del trabajo por módulos Selección de evento respiratorio dentro de un audio Conjunto de entrenamiento seleccionado xxi

28

29 Índice de listados 5.1. Representación array con GraphView Métodos calcenergy y calczcr Ejemplo de la detección de un posible evento respiratorio entre los segundos 2 y Script cálculo de descriptores estadísticos Filtro medias 3 puntos en Java Cálculo similitud con el modelo de los asmáticos Determinar el estado de obstrucción del paciente Serialización de un objeto BreathTrainingSet Recuperación del objeto serializado XXIII

30

31 Listado de acrónimos OMS TFG FVC VC FEV1 PEF VAD SMS CHESS MFCC DCT CM OMS FFT Organización Mundial de la Salud Trabajo Fin de Grado Capacidad vital forzada Capacidad vital Volumen máximo de aire espirado en el primer segundo Peak flow Voice-Activity-Detection Short Message Service Comprehensive Health Enhancement Support System Mel Filter Cepstral Coefficents Discrete Cosine Transform Case Management Organización Mundial de la Salud Fast Fourier Transform XXV

32

33 Capítulo 1 Introducción EN este capítulo introductorio se da una idea del contexto en el que se desarrolla el proyecto, así como del problema a tratar y una descripción general de la solución propuesta para dicho problema, que será especificada en siguientes capítulos. 1.1 Contexto del Trabajo Fin de Grado En estos tiempos, las tecnologías móviles están cada vez más presentes en la vida cotidiana de todo tipo de personas. Rara es la persona que no convive con un teléfono móvil, o más concretamente un smartphone, al que está pegada buena parte del día incluso mientras duerme no se aleja mucho más de un metro de él. Los smartphones se han hecho un hueco en la vida de todas las personas estando presentes en múltiples aspectos de la vida diaria. Permiten la monitorización de la actividad física, sea cual sea gracias a sus múltiples sensores (acelerómetro, giróscopo, gps,... ); estar en contacto con los seres queridos en tiempo real, estar informados de todo lo que pasa en el mundo con un simple gesto, leer libros, escuchar música,... un sinfín de posibilidades. Pese a todo el rendimiento que se piensa que se está sacando a estos dispositivos, podrían ofrecer muchas más funcionalidades, y lo que es más importante: convertirse en la herramienta más adecuada para tareas de monitorización continua, durante la vida diaria reduciendo la interacción con ellos a lo más mínimo. Se puede aprovechar la enorme capacidad de cómputo con que cuentan estos terminales, su portabilidad y sus sensores para realizar una correcta monitorización de ciertas enfermedades. En este caso, la enfermedad a controlar es el asma, ya sea crítica o estacionaria, que por razones de las que se hablará en siguientes secciones no es correctamente monitorizada en la mayoría de los casos,lo cuál es crucial a la hora de tratar la enfermedad y de prevenir posibles ataques de asma Asma El asma es una enfermedad respiratoria que afecta a unos 235 millones de personas a lo largo de todo el mundo según el último estudio de la Organización Mundial de la Salud (OMS) [WHOb]. Dicha enfermedad se caracteriza por ataques recurrentes de disnea (falta de aire) y sibilancias que varían en función de la severidad del caso. Los ataques de asma provo- 1

34 Figura 1.1: Efecto que causa un ataque de asma can la inflamación del revestimiento de los bronquios, lo cual estrecha las vías respiratorias disminuyendo el flujo de aire que entra y sale del pulmón (Figura 1.1 ). En función de la frecuencia o las épocas del año en que se produzcan dichos ataques el asma puede ser crónico o estacionario, debido a algún tipo de alérgeno. Los efectos que estos ataques provocan en las vidas de los que lo padecen son múltiples como pueden ser: dificultad o imposibilidad de la práctica deportiva, dificultad a la hora de realizar cualquier tipo de tarea cotidiana e incluso insomnio ya que los ataques suelen darse durante la noche. Pese a tratarse de una enfermedad crónica no tiene una tasa de mortalidad tan alta como pueden tenerlo otras.según datos de la OMS en 2005 murieron por asma en el mundo alrededor de personas. Cabe destacar que la gran mayoría de las muertes producidas a causa del asma, más del 80 %, tienen lugar en países pobres en los que no se combate adecuadamente ni tienen acceso a la misma tecnología ni medicinas que en países más ricos [WHOa]. El asma no puede curarse, pero si tomar las medidas adecuadas para que una persona que padezca esta enfermedad pueda llevar una vida sin complicaciones a causa de ella. Existen dos tipos de medicamentos para paliar o reducir los ataques de asma [Gun]: De alivio rápido: se deben tomar en caso de ataque de asma y su efecto es inmediato, durando el alivio entre 4 y 6 horas. Relajan los músculos alrededor de las vías respiratorias para así abrirlas y facilitar la respiración. Albuterol. A largo plazo: administrados diariamente para controlar los síntomas críticos. Disminuyen la hinchazón y mucosidades de las vías respiratorias, y previenen los ataques. Inhaladores corticosteroides, broncodilatadores de larga duración. Además de los medicamentos que sirven para paliar los efectos, para realizar un seguimiento de la evolución del asma y ver si los medicamentos que se le han recetado al paciente 2

35 son los adecuados, se realizan diferentes pruebas para detectar la severidad de la enfermedad mediante algunos de los factores que indican la presencia de asma: 1. Detección de sibilancias: las sibilancias son un sonido silbante y chillón durante la respiración, se da cuando las vías respiratorios muestran alguna estrechez impidiendo el paso normal del flujo respiratorio. Estos sonidos son un signo de que una persona presenta problemas respiratorios. Estos síntomas se suelen identificar mediante auscultación por medio de un estetoscopio por lo que el diagnóstico estará influido por la experiencia, oido y juicio de cada doctor [JZZ09]. Por ello se está investigando en el desarrollo de su detección automática para disminuir la subjetividad de la técnica de auscultación con estetoscopio. En la Figura 1.2 se muestra en los diferentes puntos del cuerpo tanto por delante como por detrás en los que se debe colocar el estetoscopio para realizar la auscultación. Sirviendo también al lector como una pequeña muestra de como se lleva a cabo el procedimiento y con qué material. Figura 1.2: Puntos en los que colocar el estetoscopio para realizar la auscultación 2. Función pulmonar: la espirometría mide algunos de los valores pulmonares del paciente mediante la expulsión forzada del aire. Los valores que arroja una espirometría al uso son: Capacidad vital forzada (FVC) es el volumen de aire expulsado durante la maniobra de espiración forzada. Indica la capacidad pulmonar y se expresa en litros. Capacidad vital (VC) es el volumen inspirado desde una situación de espiración máxima previa hasta la máxima inspiración. 3

36 Figura 1.3: Ejemplo de una espirometría en un hospital Volumen máximo de aire espirado en el primer segundo (FEV1) es el flujo espirado en un segundo, el primero en concreto. Peak flow (PEF) es el flujo máximo conseguido durante la espiración forzada Extensión del Smartphone y mhealth En estos tiempos donde la tecnología avanza día tras día, la medicina se aprovecha de ello para hacer un mejor seguimiento y diagnóstico de sus pacientes. Todas estas prácticas son incluidas en el término m-health [Bra14], que deriva de e-health donde se aplican las tecnologías de la información en diferentes escenarios médicos, pero en este caso centrándonos en los dispositivos móviles. Esta práctica, mhealth, ofrece muchas posibilidades como pueden ser: seguimiento de pacientes, recolección de datos clínicos, gestión de historiales o la telemedicina (médico y paciente se comunican, dando el primero un diagnóstico sin ser necesario su presencia en el mismo emplazamiento). Dentro de este TFG se empleará mhealth centrado en la monitorización de variables fisiológicas, existen muchas aplicaciones que incluso han sido aprobadas por doctores como medios para monitorizar multitud de estados fisiológicos. Existen aplicaciones que utilizan periféricos que se conectan al smartphone para controlar estas variables y otras que utilizan directamente los sensores que incluye el teléfono como pueden ser la cámara, el micrófono, el acelerómetro, el giróscopo y otros sensores. Aplicaciones con hardware adicional AgaMatrix + ibgstar: esta combinación de hardware y app se encarga de medir la glucosa en sangre, consiste en un hardware compatible con iphone 4/4S que se conecta por el puerto inferior y tiene una ranura en la que incluir la tira con la sangre extraída del paciente. Envía la toma a la aplicación que se encarga de registrar el resultado e ir guardando el historial del paciente. Withings Wireless Blood Pressure Monitor: bracalete conectado por Bluetooth com- 4

37 Figura 1.4: Medidor glucosa AgaMatrix Figura 1.5: Tensiometro Withings patible con ios y Android que permite tomar la tensión del paciente junto con una aplicación que marca de distintos colores el estado de su tensión arterial llevando así un seguimiento de su evolución Aplicaciones sin hardware adicional Cardiograph: aplicación que utilizando unicamente la cámara de un iphone es capaz de determinar las pulsaciones escaneando los cambios de color que se producen en la huella del dedo para determinar la velocidad a la que late el corazón. SpiroSmart: es una aplicación compatible con el sistema operativo ios, que permite el cálculo de la función pulmonar sin ayuda de ningún hardware especial, mediante un soplido (expiración forzada)sobre el micrófono integrado en los dispositivos. Todas las aplicaciones obedecen al principio de intrusión mínima fijado dentro del marco mhealth. En el caso concreto de este TFG se tratará de conseguir detectar alguna de las irregularidades respiratorias propias del asma en personas utilizando únicamente la entrada de micrófono de un smartphone y el análisis del habla continua para la demarcación exacta de los eventos respiratorios. Con tan solo el uso del micrófono se pueden calcular,o al menos aproximar, los dos indicativos que se explicaban en la sección anterior, espirometría y sibilancias, pero en este caso, el trabajo se centrará en la clasificación de la respiración del paciente en normal, sana o con algún tipo de obstrucción respiratoria. Sumando a esto la impresionante extensión del smartphone en nuestro país, según datos del informe 2013Spain Digital Future in Focus en Junio de ese mismo año [com], había más de 55 millones de líneas telefónicas contratadas (de los cuales un 66 % son smartphones). También las ventas de tablets en nuestro país se han disparado por lo que una aplicación compatible con móviles y/o tablets podría ser utilizada por un mayor número de personas. La mayor parte de estos dispositivos cuentan con conexión a internet en todo momento mediante 3G o 4G permitiendo mandar y recibir datos a través de la red. Respecto a sistemas operativos, en España Android es el más usado, razón por la cuál es el que se utilizará en este TFG para poder alcanzar el mayor número de dispositivos móviles posible. 5

38 1.2 Problema y solución propuesta En esta sección se explicará el problema que se pretende resolver con la elaboración de este TFG y la descripción de la solución propuesta Descripción del problema Como se ha comentado en la sección anterior acerca de los métodos que existen para detectar el asma o el grado en que esta enfermedad afecta a un paciente destacan el cálculo de la función pulmonar (espirometría) o la detección de sibilancias, entre otros. El problema que trata de solucionar este TFG se desglosa en dos, por un lado la falta de monitorización continua de la enfermedad en gran parte de los enfermos de asma y la ocurrencia de ataques de asma en los enfermos más crónicos mientras realizan el estudio de la función pulmonar. Falta de monitorización continua La mayoría de los enfermos de asma por desgracia no tienen la oportunidad de contar con una monitorización continua de su enfermedad para seguir la evolución de la misma y proporcionar informaicón útil al médico especilista para poder paliarla de la mejor manera posible viendo de que forma afectan unos tratamientos u otros. La causa por la que su enfermedad no es correctamente monitorizada es por la saturación en las listas de espera para ser atendidos por los especialistas, que les llevan a sólo poder hacerse una o dos pruebas a lo largo de todo el año siendo los resultados obtenidos totalmente dependientes del estado del paciente en ese día. No tiene por que ser la tónica habitual en su día a día por lo que el médico le puede dar un tratamiento menos agresivo en caso de tener ese día unos buenos resultados, siendo insuficente para el resto de días o también podría ocurrir todo lo contrario. El paciente podría realizarse esta prueba en casa con cierta frecuencia sirviendose de algún espirómetro doméstico de los múltiples que existen pero no todos arrojan resultados parecidos a los profesionales, así como los prohibitivos precios de algunos de estos aparatos. Crisis asmáticas durante la espirometria El cálculo de la función pulmonar o espirometria donde se obtienen los valores que se han indicado en la sección anterior, es una prueba de esfuerzo en la que se exprimen los pulmones del paciente al máximo. Incluso a personas sin aparentes problemas respiratorios llega a costarles dar todo en esa prueba, los pacientes crónicos pueden padecer ataques de asma durante el transcurso de estas pruebas Descripción de la solución La solución que se propone en este TFG es hacer de un elemento tan cotidiano como lo es el teléfono móvil, una herramienta capaz de determinar el estado respiratorio de una persona utilizando solamente una grabación de voz para que los asmáticos (y no asmáticos) lleven siempre consigo el dispositivo y puedan hacer pruebas diarias. 6

39 Figura 1.6: Esquema de la solución propuesta Esta aplicación ofrecería al paciente una monitorización continua de su enfermedad pudiendo mostrar al neumólogo el estado respiratorio del paciente a lo largo de su utilización. Con estos datos el profesional podría tomar decisiones para prevenir futuros ataques de asma o cambiar de medicación para que ésta resulte más efectiva. Al igual que se ha comentado anteriormente, el producto final de este proyecto sería un aplicación para todo tipo de dispositivos Android (smartphone o tablet) que empleando únicamente el micrófono del terminal y una serie de algoritmos que permitirán la distinción entre fonemas y eventos de respiración asi como la valoración del estado respiratorio del paciente. En la Figura 1.6 se muestra gráficamente el funcionamiento deseado de la solución. 1.3 Estructura del documento Esta sección indica los diferentes capítulos de los que consta el presente documento, así como un pequeño resumen de lo que contiene cada uno de ellos. Capítulo 1: Introducción Es el capítulo en el que se encuentra en este momento, está formado por el contexto del TFG, el problema que se pretende solucionar, la solución que se propone y por último la descripción de la estructura del documento. Capítulo 2: Objetivos Este capítulo contiene la hipótesis de la que se parte en este proyecto, el objetivo general que se desea conseguir y los objetivos específicos. Además de la hipótesis y los objetivos, se explica el lenguaje de programación que se va a emplear y los medios software y hardware que han sido necesarios para conseguir dichos objetivos. Capítulo 3: Antecedentes En el capítulo de Antecedentes se muestran varios trabajos que tienen relación con el asma, ya sean de seguimiento de la enfermedad o relacionados con la aproximación de 7

40 valores espirométricos. Se explica el método empleado por cada uno y los resultados obtenidos en caso de que se trate de estudios. Capítulo 4: Conceptos específicos del dominio En este capítulo se da una visión general y teórica de los conceptos que se van a aplicar en este proyecto, cuya implementación será explicada con detalle en el Capítulo 5 Capítulo 5: Método de trabajo El capítulo 5 se explica la elección del método de trabajo y se desglosa el proyecto en módulos y submódulos, así como su implementación y desarrollo. Capítulo 6: Resultados En este capítulo se muestra la apariencia final de la aplicación Android y los resultados obtenidos tanto de la aplicación del algoritmo de detección de respiraciones como del segundo algoritmo que determina si existe o no obstrucción respiratoria en los eventos obtenidos en el primer algoritmo. Capítulo 7: Conclusiones y propuestas El capítulo de Conclusiones y Propuestas incluye los problemas que se han encontrado para conseguir los objetivos, qué objetivos se han conseguido y los aspectos que se podrían mejorar de la herramienta resultante. 8

41 Capítulo 2 Objetivos En este capítulo se expone la hipótesis, objetivos y medios empleados para solucionar el problema mostrado en el capítulo anterior con la solución sugerida. 2.1 Hipótesis de trabajo La posibilidad de monitorizar el estado respiratorio de una persona mediante la única ayuda de un smartphone. 2.2 Objetivo general El objetivo general de SiMoA es diseñar y construir una aplicación para smartphones Android, la cuál sea capaz de clasificar un fragmento de voz continua con eventos respiratorios, dentro de uno de los tres grupos existentes, en función de su estado respiratorio. 2.3 Objetivos específicos El objetivo principal del proyecto es la detección de desordenes respiratorios en el paciente, como se ha expuesto en la sección anterior. Para conseguirlo se han marcado los siguientes objetivos específicos: Relativos a la detección de eventos respiratorios DET-01: Estudio de trabajos previos relativos a la detección de respiraciones en el habla continua. DET-02: Creación de un conjunto de entrenamiento formado por grabaciones respiratorias que servirán en la fase de entrenamiento del algoritmo de template matching a implementar. DET-03: Obtención de los Mel Filter Cepstral Coefficents (MFCC) que permiten caracterizar cada frame de la muestra de voz continua analizada, a lo que se sumarán otras características en el dominio del tiempo como pueden ser la energía en tiempo corto (short-time energy) y la tasa de cruces por cero de cada frame. Este conjunto de características permitirá hacer el matching con el conjunto de entrenamiento y distinguir eventos respiratorios del resto de fonemas. 9

42 DET-04: Diferenciación de los diferentes fonemas que formarán la muestra a estudiar, incluyendo la clasificación de cada uno de los fonemas en sonoros, no sonoros o eventos respiratorios Relativos a la valoración del estado respiratorio CLA-01: Búsqueda y estudio de trabajos previos en la diferenciación entre personas sanas y asmáticas mediante la voz. CLA-02: Elección de alguna característica de los audios con la cual sean diferenciables las respiraciones normales o sanas de las anormales o con algún tipo de patología respiratoria. CLA-03: Elección de un algoritmo que mediante inteligencia artificial sea capaz de clasificar en sano o asmático un eventos respiratorio ayudandose del conjunto de entrenamiento. CLA-04: Creación de dos conjuntos de entrenamiento bien definidos, uno formado por eventos respiratorios de personas sanas y otro formado por eventos respiratorios de personas que presenten algún tipo de patología respiratoria Relativos a la aplicación Android AND-01: Recogida de muestras de audio con el smartphone en un formato fácil de manejar y luego tratar con la señal recibida, sin pérdida de calidad en la señal. AND-02: Desarrollo de una aplicación Android que implemente ambos algoritmos, detección de respiraciones y valoración del estado respiratorio en tres grupos, y además muestre al usuario el resultado de su estudio de forma clara y concisa. 2.4 Herramientas y medios de trabajo Lenguajes de programación y sistema operativo El sistema operativo elegido para este TFG ha sido Android [And], como ya se ha explicado en la sección Android Inc. era una pequeña empresa que en 2005 compró Google y puso a sus antiguos empleados a trabajar sobre ella desarrollando una plataforma para dispositivos móviles basada en un kernel Linux que fue llamada Android. El objetivo de Google era crear un sistema flexible y actualizable a diferencia de los dispositivos móviles y sistemas operativos que existían hasta la fecha. En 2007 se crea la Open Handset Alliance (Figura 2.1), un consorcio de empresas relacionadas con la tecnología cuyo objetivo es desarrollar estandard libres/abiertos para dispositivos móviles. Este consorcio dará a conocer Android, al ser un sistema abierto, y hará que sea su sistema operativo por bandera obligando a sus miembros a que cada dispositivo que desarrollen sea compatible con Android. Entrando a un apartado más técnico, la plataforma se compone de varias capas (Figura 2.2): 10

43 Figura 2.1: Miembros de la Open Handset Alliance Capa del kernel: formada por el kernel, la gestión de memoria, los ajustes de seguridad y los drivers. Capa de librerías y Android Runtime: formada por las librerías, las librerías del núcleo de Java y la máquina virtual (Dalvik Virtual Machine) sobre la cual corren las aplicaciones. A partir de la versión Android 4.4 dicha máquina virtual se puede cambiar a ART. Capa del framework de aplicación: aquí se encuentran las aplicaciones para el manejo básico del dispositivo como la localización de archivos, aplicaciones del teléfono o cambiar de aplicaciones. Capa de aplicación: en esta capa se encuentra la interfaz del usuario, donde puede abrir aplicaciones, realizar llamadas y esos tipos de operaciones. A la hora de elegir un lenguaje de programación para crear la aplicación que correrá sobre la plataforma Android, existen múltiples opciones. La opción oficial, por así decirlo, es programar en Java contando incluso con numerosa documentación en el portal para desarrolladores de Android. Aún así hay otras alternativas que permiten generar aplicaciones Android en otros lenguajes: Basic4Android: es una plataforma que permite crear aplicaciones Android en Visual- Basic. Mono: es un complemento para VisualStudio que permite crear aplicaciones utilizando C# y.net. AppInventor: permite programar de forma gráfica arrastrando bloques sin necesidad de conocer ningún lenguaje de programación. 11

44 Figura 2.2: Arquitectura de Android PhoneGap: es una plataforma de desarrollo que permite crear aplicaciones utilizando HTML, CSS y Javascript, para luego exportarla a cualquier tipo de sistema operativo móvil (ios, Android, Windows Phone). La elección en este TFG ha sido Java [GBGG05], este lenguaje de programación de alto nivel fue publicado en 1995 por la compañía Sun Microsystems. Java basa su sintaxis en C y C++ pero tiene muchas menos opciones a bajo nivel. El código Java se compila a bytecode, generando código neutro que puede ser ejecutado en cualquier máquina que cuente con JVM (Java Virtual Machine) sin ningún tipo de problemas de portabilidad. Sólo es necesaria una compilación, si se cambia de máquina no se tiene que recompilar. Java es un lenguaje orientado a objetos, que permite la herencia de una sola clase padre lo que permite múltiples posibilidades a la hora de programar Medios Hardware En cuanto a medios hardware, se pueden distinguir tres dispositivos en este proyecto: un ordenador portátil, dos teléfonos móviles y un espirómetro digital portátil. La totalidad del desarrollo del software y redacción de la documentación se ha realizado sobre un ordenador portátil Sony VAIO con las siguientes características: Modelo: Sony VAIO VGN-NS21M Procesador: Intel R Pentium(R) Dual CPU 2.16GHz x 2 12

45 Figura 2.3: Dispositivo Android empleado en el desarrollo Memoria RAM: 4 GB Capacidad Disco Duro: 320 GB Sistema Operativo: una partición con Ubuntu LTS y otra con Windows 7, ambos de 64 bits La necesidad de un dispositivo Android, para probar y depurar la aplicación se ha cubierto con un dispositivo LG Google Nexus 4 (Figura 2.3): Modelo: LG Google Nexus 4 Procesador: Snapdragon S4 Pro a 1.5GHz Memoria RAM: 2 GB Memoria interna: 16 GB Pantalla: WXGA True HD IPS Plus de 4.7 pulgadas Versión Android: Android KitKat En la fase de pruebas del algoritmo además de las grabaciones obtenidas con el dispositivo Android también se ha empleado un dispositivo ios solamente para grabar archivos de sonido y luego probarlos con este algoritmo. El dispositivo ha sido un iphone 4S. Modelo: Apple Iphone 4S 13

46 Procesador: Procesador dual-core Apple A5 1GHz Memoria interna: 16 GB Pantalla: TFT IPS con luz LED de fondo touchscreen capacitivo (3,5 pulgadas) Versión ios: ios 7 Por último un espirómetro digital SP10(Figura 2.4), para comprobar el estado de los voluntarios con los que se ha ido probando y pidiendo colaboración en el proyecto en ciertos momentos del desarrollo. Figura 2.4: Espirómetro digital portátil SP Medios Software El sistema que se pretende desarrollar y la documentación pertinente se llevarán a cabo utilizando las siguientes herramientas software que en la medida de lo posible se ha intentado que sean compatibles con GNU/Linux Ubuntu. Se describirán dichas herramientas dividiéndose en desarrollo de la aplicación por un lado y documentación por otro. Desarrollo y codificación Android Studio: basado en el IDE IntelliJ IDEA, es el entorno de desarrollo creado por Google para crear aplicaciones Android. Ofrece un sistema de generación basado en Gradle que da una mayor flexibilidad al proceso de construcción de la aplicación. Permite ver los cambios en el diseño de la aplicación a medida que se va creando el archivo XML que define cada una de las pantallas de la aplicación (llamadas Activities), así como ver el resultado en distintos dispositivos. Al haber sido desarrollado por Google cuenta con soporte para su plataforma Cloud que facilita la integración con Google App Engine. Por estas y algunas otras ventajas frente al plugin ADT de Eclipse se ha optado por este IDE para este desarrollo. Descargable en [stu]. 14

47 Figura 2.5: SDK Manager Android SDK: es fundamental para la creación de aplicaciones Android, de la herramienta anterior se puede prescindir pero de esta no. El SDK proporciona las APIs de las diferentes versiones del sistema operativo y las herramientas necesarias para crear aplicaciones, probarlas y depurarlas. Tiene un gestor (Figura 2.5) cuyo servicio es mostrar todos las herramientas de las que se dispone y la versión de cada una de ellas para bajar las que sean necesarias en función a la aplicación que se esté creando. También incluye emuladores con Android para probar las aplicaciones, pero en el caso de este TFG es preferible hacer las pruebas sobre un terminal ya que se necesita acceder a un sensor (el micrófono). Descargable en [sdk] Audacity: es un software libre multiplataforma que permite la grabación y edición de múltiples formatos de audio. Además permite la grabación de varios canales de manera simultánea así como la grabación de muestras de hasta 192,000 Hz llegando a los 384,000 Hz en algunos dispositivos de alta resolución sobre Mac o Linux. Esta herramienta trabaja sobre sus propios proyectos pero da la posibilidad de exportarlos a los formatos tradicionales (wav, aiff, au, flac). En este proyecto se ha empleado Audacity para grabar las primeras muestras de sonido antes de tener dichas funcionalidades implementadas en el sistema así como estudiar las señales gráficamente y localizar coincidencias con los valores que arrojaba el algoritmo de demarcación de eventos respiratorios. Descargable en [aud]. Weka: es un software de libre distribución desarrollado en Java en la Universidad de Waikato que permite analizar datos mediante diversas técnicas de aprendizaje automático. Esta herramienta se ha utilizado para hacer el agrupamiento de las muestras y ver si las entrantes son mas similares a las sanas o a las que corresponden a asmáticos. Utiliza un formato especial de archivo con extensión ARFF (Attribute-Relation File Format) con tres secciones como son el nombre de la relacion (@RELATION), 15

48 Figura 2.6: Captura de la herramienta Trello con sus tres tableros los diferentes atributos a comparar (@ATTRIBUTE) y los datos que dan valor a esos atributos (@ddata). Praat: es un software gratuito creado en la Universidad de Amsterdam con el fin de analizar el habla. Esta herramienta permite grabar sonidos y además obtener los espectrogramas generados, analizar la entonación, la intensidad y muchas otras características del habla. El uso que se le ha dado, ha sido el de comparar los valores obtenidos del análisis del habla por el algoritmo del sistema con los valores de este programa. Descargable en [BW]. RStudio: es un IDE que permite la programación y desarrollo de scripts en el lenguaje R. Este lenguaje es uno de los principales utilizados para cálculos estadísticos. En concreto se ha utilizado la versión para GNU/Linux en el cuál se ha creado un script que permite calcular una serie de descriptores estadísticos de varias muestras de datos para poder fijar diferentes umbrales que serán explicados en los siguientes capítulos. Descargable en [rst]. Trello: es una herramienta web que permite la gestión de proyectos, se trata de una aplicación colaborativa que cuenta con tres tableros formados por cartas. Los tableros son: TO DO (por hacer), DOING (haciendo) y DONE (hecho), donde se van poniendo y viendo las tareas y todos los miembros que estén trabajando en el proyecto pueden crear nuevas tareas o arrastrar las existentes al tablero adecuado en caso de que vayan progresando. En este caso sólo hay un miembro trabajando en el proyecto y esta herramienta ha servido para ir planificando los días. Se puede acceder a esta herramienta en [tre]. Meld: consiste en una herramienta para la comparación de documentos línea a línea al estilo del comando diff, pero éste cuenta con interfaz gráfica que facilita su uso coloreando las diferencias. El uso que se le ha dado ha sido en la fase inicial del proyecto durante las pruebas con el módulo I para comparar las cabeceras de los wav y también para las salidas que se obtenían del programa en la fase de pruebas para comparar si los resultados eran iguales. 16

49 Git: es un software de control de versiones que ha sido empleado a lo largo de todo el desarrollo tanto en la fase de pruebas de los algoritmos en Eclipse con el plugin (egit) como en el proyecto final ya que AndroidStudio lo tiene incluido y es muy sencillo su manejo para el usuario. Memoria y documentación Kile: editor de L A TEXmultiplataforma con licencia GPL, algunas de sus características son: autocompletado de comandos L A TEX, coloreado de sintaxis, compilación y conversión en un sólo click, plantillas para facilitar la construcción y vista previa de partes del documento. Se ha utilizado para la completa elaboración de la memoria. Descargable en [kil]. Gimp: herramienta de diseño gráfico con licencia GNU que permite la edición y creación de imágenes digitales. Ha sido utilizada para recortar algunas imágenes que se han incluido tanto en la memoria como en la aplicación, reducir la resolución de algunas otras imágenes, y también para la creación de algunas de las imágenes. Descargable en [gim]. Libre Office Impress: se trata de una herramienta para la creación de presentaciones multimedia, cuenta también con muchas plantillas predefinidas para facilitar el trabajo y algunos efectos para la transición entre diapositivas. En el caso de este proyecto se ha utilizado para crear algunos de los esquemas que aparecerán en forma de imagen a lo largo de la documentación. Descargable en [lib]. Inkscape: herramienta de dibujo vectorial que ha sido utilizada para pasar las imágenes de la memoria al formato.eps y que su calidad fuera mayor para poder hacer zoom en el documento sin perder calidad. Dia: aplicación gráfica de propósito general para la creación de todo tipo de diagramas, en este caso ha sido empleada para la creación de los diagramas de casos de uso, de secuencia y de clases que se muestran en el capítulo 5. Librerías Java Weka-for-Android: es una librería que realiza las mismas funciones que weka pero tiene compatibilidad con Android a diferencia de la librería al uso de Weka. Ofrece resultados casi idénticos a los de la aplicación y esta librería es la que se ha empleado dentro del algoritmo en la aplicación móvil. 17

50

51 Capítulo 3 Antecedentes ESTE capítulo incluye algunas nociones sobre el estado del arte de los diversos campos que se tratan en este proyecto. Se han dividido en cuatro secciones: una de aproximación de valores espirométricos, una para la detección de eventos respiratorios, otra de monitorización del asma y por último la que incluye trabajos relativos a la comparación entre eventos respiratorios sanos y eventos respiratorios en personas con algún grado de obstrucción en sus vías respiratorias. En todas las secciones se incluyen casos de estudio para una mejor ilustración. 3.1 Aproximación de los valores espirométricos En esta sección se pasará a explicar diversos casos de estudio en los que se calculan ciertos valores espirométricos. En uno de los casos de estudio soplando directamente sobre el smartphone, en otra conectando el smartphone via Bluetooth a un hardware adicional y por último, solamente respirando sobre un micrófono Por medio del smartphone sin dispositivos adicionales SpiroSmart [LGB + 12], es un proyecto de la Universidad de Washington en el que crearon un espirómetro para dispositivos con el sistema operativo ios. Para ello reunieron a 52 personas para que realizaran grabaciones de sus soplidos sobre el smartphone y además soplar también sobre un espirometro con conexión USB para volcar los datos a un ordenador. Los tres objetivos a aplicar a esas muestras sin calibrar eran: compensar la pérdida de flujo entre la boca y el micrófono, convertir la presión a flujo y quitar el ruido aplicando diversos filtros. El proceso que siguieron para extraer las características de las muestras se puede ver en la Figura 3.1. Una vez ya tenían la señal limpia, mediante machine learning crearon dos modelos de regresión, uno que aproximaba los valores espirométricos y otro que servía para caracterizar la curva resultante de la espirometría. Lograron aproximar los siguientes valores: FVC, FEV1, PEF, FEV1/FVC; comparándolos con los de un espirómetro convencional, nspire KoKo Legend, demostraron que la media de error con SpiroSmart sólo era de un 5 %. 19

52 Figura 3.1: Procedimiento de extracción de características Por medio de un hardware específico MobileSpiro [GPNS11], trata de dotar a los enfermos de asma de una herramienta que les permita controlar su enfermedad sin necesidad de salir de casa. El proyecto consiste en un dispositivo hardware que se conecta a una aplicación de un smartphone (Android) por medio del Bluetooth, este dispositivo es un tubo que se conecta a una caja negra que ejerce de espirómetro y será quien envíe la señal al smartphone(figura 3.2). Se utiliza un tubo para aislar la muestra de cualquier ruido externo y tener un soplido unidireccional. Además de servir para la monitorización propia de cada paciente, este proyecto tiene una parte didáctica ya que detecta maniobras erróneas al realizar la espirometría y avisa al paciente de ello. Los comportamientos erróneos que han logrado detectar sus algoritmos son: Tos Inicio lento: el paciente no comienza la maniobra soplando todo lo fuerte que puede Final temprano: si la maniobra después de alcanzar el PEF llega a cero antes de 6 segundos Además de ello proporciona un feedback positivo al paciente porque según se realiza la maniobra se va representando gráficamente el PEF y el FVC. Al final de la maniobra muestra los valores, la gráfica, unos checkbox para facilitar la expresión de su estado, y en caso de haber cometido algún error también se mostraría y se ayudaría a solucionarlo con un consejo Por medio de una aplicación de escritorio y un micrófono En el artículo de [AF14] lo que se persigue es facilitar la espirometría para personas con dificultades reduciendo la interacción al mínimo, solamente respirando delante de un micrófono sin necesidad de soplar. Su principal propósito era controlar la capacidad pulmonar de las personas que padecen cáncer de pulmón, pero es aplicable a cualquier enfermedad pul- 20

53 Figura 3.2: Componentes que forman mobilespiro monar. Consiste en estimar la capacidad pulmonar mediante Voice-Activity-Detection (VAD) para detectar los momentos en que el paciente inhala o exhala el aire. Para calcular los valores pulmonares emplean la media de la duración de cada evento respiratorio así como la energía de dichos eventos, después de segmentar la señal en señales más pequeñas para facilitar su estudio. Cuando ya tienen la energía y duración media de los eventos respiratorios aproximan los valores con algunas ecuaciones obtenidas mediante regresión lineal, como por ejemplo: F V C m = 15e (0,1524h 0,0214a 4,65)t (3.1) 100 donde e es la energía de la señal, h es la altura de la persona en pulgadas, a es la edad de la persona en años y t es la media de la duración de las inhalaciones y exhalaciones. Los resultados de este artículo exponen que tiene una alta precisión en sus estimaciones, superando el 85 %. 3.2 Reconocimiento de acciones respiratorias Con el fin de poder calcular los valores relativos a la espirometría y detectarlos en el habla, lo primero que se necesita es distinguir los eventos respiratorios del resto de fonemas. Este trabajo lo realizan en su artículo [RL07] dos miembros del IEEE, cuyo objetivo final era eliminar de las canciones los momentos donde los cantantes inspiran y expiran puesto que a veces resulta antiestético. Se aleja mucho del fin que persigue este proyecto pero el fundamento para detectar los eventos respiratorios es completamente utilizable. Lo primero que hacen es crear un conjunto de ejemplos reconocidos de eventos respiratorios y luego mediante un algoritmo de template matching comparar los ejemplos reconocidos o plantilla, con las muestras recogidas por el micrófono. Utilizan para construir la plantilla, como característica principal, los coeficientes cepstrales de frecuencias en la escala de mel, calculados a partir de las frecuencias en hercios originales que se tienen en un principio. En la Figura 3.3 se muestra gráficamente lo que pretendían detectar con la elaboración de éste proyecto y además de detectarlo eliminarlo. 3.3 Monitorización de los valores espirométricos A diferencia de los trabajos anteriores, se han llevado a cabo investigaciones en las cuales el objetivo era mantener un seguimiento adecuado de la enfermedad de los pacientes. 21

54 Figura 3.3: Diferenciación de silencio inicial - evento respiratorio - silencio final Figura 3.4: Vista del entorno web de CHESS El producto han sido herramientas tanto para móviles, como páginas web donde los usuarios debían introducir sus valores y/o síntomas respecto a la enfermedad. A continuación se citarán dos trabajos de este tipo Concienciación a niños con asma El trabajo de Gustafson et al. [GMA + 12] forma parte de una completa plataforma de ehealth llamada Comprehensive Health Enhancement Support System (CHESS) a lo que se añade un módulo Case Management (CM). Está dirigido a padres y a niños que no llevan un control adecuado de su enfermedad. Consiste en una página web donde el usuario se registra y dentro de ella puede tener contacto con personas especializadas en el asma, un entrenador personal sobre temas del asma, líneas guía de como tratar el asma y una correcta retroalimentación para que los niños sepan si van en el camino adecuado. Cada mes una enfermera llama a los padres para comentar la evolución del niño, preguntar por la adherencia a los medicamentos recetados al niño y el comportamiento de éste. Para los niños cuenta con juegos y material audiovisual con información sobre su enfermedad para que ellos puedan comprenderla de manera fácil. En la Figura 3.4 se puede apreciar una vista general de la web que vería un usuario de ésta plataforma. 22

55 3.3.2 Seguimiento vía SMS Con Managing Asthma with Mobile Phones: A Feasibility Study [BP09] se fijó como objetivo mejorar el seguimiento de los enfermos de asma, en este caso la herramienta no tiene incluido ningún tipo de espirómetro ya que es necesario contar con uno convencional. Los pacientes miden su PEF una vez al día y mandan un SMS con el valor obtenido que será recibido por un servidor web. En caso de que el enfermo no hiciera esta medición antes de las 11 de la mañana la aplicación contaba con una alarma para advertirle que debía hacerlo. Estos datos son muy valiosos para los doctores y pacientes a la vez, ya que pueden ver la evolución de la enfermedad y en que fechas son más propensos a tener valores respiratorios negativos. 3.4 Diferenciación entre respiraciones sanas y respiraciones con alguna patología Al ser uno de los objetivos de este trabajo la diferenciación entre respiraciones sanas y respiraciones que presentan algún tipo de patología, se ha investigado en este campo obteniendo como factor común la extracción de características del audio en coeficientes cepstrales o lo que es lo mismo MFCC Extracción de características en la voz de asmáticos utilizando MFCCs En este estudio [Rac] llevado a cabo en el DCTM (Delhi College of Technology Management), se pretendía demostrar que los fonemas sonoros podrían ser un factor que diferenciara a un enfermo de asma de una persona sin ningún tipo de problema respiratorio partiendo de la hipótesis de que el uso de corticoides en los asmáticos provoca ciertos defectos y patalogías en los pliegues vocales, que permiten distinguir una voz asmática de una que no lo es. Para caracterizar los fonemas emplearon técnica muy concreta como es la extracción de coeficientes MFCC. Estos coeficientes caracterizan el audio y son muy utilizados en reconocimiento del habla. Los coeficientes MFCC con los que hicieron el estudio, correspondian a la pronunciación de las cinco vocales del español (a,e,i,o,u) tanto de voluntarios sanos como asmáticos, dado que son fonemas sonoros que hacen vibrar los pliegues vocales. Para extraer las características emplearon el software de pruebas con audio mostrado en el capítulo anterior, Praat y después representaron los datos obtenidos con MATLAB. En las Figuras 5.5 y 5.6 se aprecia claramente desde los primeros coeficientes MFCC hay diferencia entre las grabaciones sanas y asmáticas Clasificación de sonidos respiratorios utilizando análisis cepstral y GMM M. Bahoura y C. Pelletier [BP04] desarrollaron un algoritmo capaz de clasificar los eventos respiratorios en sanos o asmáticos, para diferenciar a los asmáticos se basaron en los wheezings o sibilancias que se producen en la mayoría de ellos al respirar, como distinción. Estos wheezings o sibilancias son sonidos continuos en determinadas bandas de frecuencia 23

56 Figura 3.5: Los 20 primeros coeficientes correspondientes a las personas sanas Figura 3.6: Los 20 primeros coeficientes correspondientes a las personas asmáticas que se producen en los asmáticos al estar las vías respiratorias obstruidas.para detectarlas los médicos emplean auscultación con estetoscopio, pero el diagnóstico depende mucho de la experiencia del médico y de su propio criterio. Por ello desarrollaron este algoritmo que después de dividir una señal de audio en segmentos y obtener los coeficientes MFCC que lo caracterizan, las clasifican en sano o asmático en función de si hay presencia de sibilancias o no. Para clasificar los eventos respiratorios, utilizan modelos de mezclas gaussianas (GMM, Gaussian Mixture Model) los cuales forman un método estadístico de clasificación basado en matrices de medias y covarianza. Se crean dos modelos, uno de respiraciones sanas y otro de respiraciones no sanas para determinar si el audio entrante se clasifica como una respiración normal o por el contrario como una no sana. En la Figura 3.7 se pueden apreciar dos gaussianas, una que representa una respiracion normal (línea sólida) y otra una con sibilancias (línea discontinua). Figura 3.7: Ejemplo de gaussianas En cuanto a los resultados que arroja este algoritmo, utilizaron 12 muestras tanto sanas como con presencia de sibilancias y el algoritmo clasifico todas y cada una en su grupo adecuado. 24

57 Capítulo 4 Conceptos específicos del dominio EN este capítulo correspondiente a los Conceptos específicos del dominio, se explican los diferentes procedimientos a los que se va a someter el audio grabado que van a permitir el estudio de la señal y el descubrimiento de las características necesarias para solucionar el problema. En el capítulo posterior al presente se expondrán las fases del proyecto y que concepto de los mostrados a continuación se implementan en cada una de las fases. 4.1 Algoritmo 1: detección de eventos respiratorios en habla continua MFCC: Mel Filter Cepstral Coefficents MFCC es un método de extracción de parámetros a una muestra de audio para su mejor representación y estudio. Se basa en el límite de la percepción humana a frecuencias superiores a 1kHz [Rac]. El tratamiento que sigue una señal de audio para obtener su vector de características se encuentra representado en la Figura 4.1. Figura 4.1: Obtención del vector de características en base a un sonido 25

58 1. Pre-énfasis: es un método cuyo objetivo es aumentar la energía de la señal correspondiente a las frecuencias altas y atenuar la señal correspondiente a las frecuencias bajas, ya que en éstas se encuentran sonidos que carecen de importancia para el reconocimiento de voz. En la Figura 4.2 se puede observar la aplicación de éste filtro a una señal. Figura 4.2: Aplicación método pre-énfasis, donde se enfatizan las frecuencias altas 2. División de la señal en frames: en esta etapa se coge la entrada de audio y se divide en pequeños frames, de entre 10 y 20 ms, con un solapamiento de alrededor de 5 ms (Figura 4.3). Es decir, suponiendo que se empieza desde cero: a) Frame 1: 0-9 b) Frame 2: 4-14 Figura 4.3: Gráfico división de la señal en subframes con solapamiento Cada uno de estos frames estará formado por un conjunto de muestras (samples) en 26

59 función de la frecuencia de muestreo a la que se haya grabado la entrada. Para calcular el número de muestras de cada frame se multiplica el tiempo en segundos que dura por la frecuencia de muestreo a la que se ha grabado. Esta etapa es necesaria debido a que la señal de audio, especialmente la voz humana, es una señal cuasiperiódica que guarda la periodicidad sólo en fragmentos de tiempo pequeños. Debido a ello se calculan dichos componentes ventana a ventana, con un solapamiento como se ha indicado para relacionar una ventana con la que le precede y la que le sucede. 3. Ventana de Hamming: a cada uno de los frames anteriormente mencionados, se les aplica una ventana de Hamming, que recorrerá todo el frame al que se aplicará la siguiente fórmula donde N corresponde al número de muestras por frame. La aplicación de ésta ventana de Hamming ayuda a filtrar las frecuencias falsas originadas al efectuar cortes bruscos sobre la señal original en la anterior etapa de división. W (n) = 0,54 0,46cos( 2Πn N 1 ) 0 n N 1 (4.1) 4. Transformada Rápida de Fourier: se aplica con el objetivo de pasar la muestra de estar en función del tiempo a estar en función de la frecuencia. Dicha operación se realiza con cada uno de los frames, obteniendo una parte real y otra imaginaria de las cuales se calculará su magnitud dando lugar a su periodograma. Se calculará sobre 512 contenedores en los cuales se alojarán las magnitudes calculadas. Magnitud = 1 nfft (fft.real)2 + (fft.imag) 2 (4.2) 5. Procesamiento del filtro Mel: los filtros Mel forman un banco de filtros que es un conjunto de filtros triangulares que se aplican al periodograma obtenido en la fase anterior. La aplicación de estos filtros ayuda a obtener información de una banda de frecuencia en concreto. La forma en que se distribuyen estos filtros entre las frecuencias está basada en como lo interpreta el oído humano. Como se puede observar en la Figura 4.4, a mayores frecuencias menor altura del filtro. En las frecuencias bajas hay mayor densidad de filtros triangulares que en las frecuencias altas, las cuales cuentan con menor cantidad de filtros pero más anchos. Normalmente se consiguen entre 20 y 26 filtros, pero sólo se utilizan los 12 o 13 primeros para calcular los coeficientes, resultando más filtros que coeficientes. De esos valores el primero se elimina porque refleja la componente DC de corriente continua de la señal que no aporta nada útil al análisis. Para calcular la energía de cada uno de los filtros, se multiplica cada filtro por el periodograma de la muestra (Figura 4.5) obteniendo un valor por cada filtro que en la siguiente etapa pasará a ser un coeficiente cepstral, actualmente son valores espectrales. 27

60 Figura 4.4: Ejemplo banco de filtros Mel Figura 4.5: Proceso de multiplicación de filtros y periodograma 6. Log: a cada uno de los valores de energía obtenidos de cada banco, se modifica su escala a una logarítmica para facilitar el manejo de estos valores. Una vez se ha cambiado la escala, los coeficientes espectrales pasan a ser cepstrales. 7. Transformada Discreta del coseno: en esta etapa el espectro Mel se transforma a un dominio temporal mediante el Discrete Cosine Transform (DCT), resultando los MFCCs, también llamados vector acústico que caracterizará cada uno de los frames Construcción del template Como se ha indicado en el capítulo de introducción, se va a emplear un algoritmo de template matching. Para la creación de dicho template (o plantilla) se siguen una serie de pasos que se van a explicar a continuación: 1. Obtención de los vectores MFCC: lo primero que se hace es calcular los coeficientes MFCC de todos los elementos de cada subframe del conjunto de ejemplo. Se seguirá el procedimiento que se ha expuesto en la sección anterior, donde se explica todo el procedimiento MFCC. 2. Creación del cepstrograma de cada frame: a este paso se llega con un vector de MFCCs por cada uno de los subframes del conjunto de ejemplo. En este caso se han elegido 28

61 12 coeficientes MFCC por cada uno de los subframes (10ms) que forman un frame (100ms) con solapamiento incluido. Con todos estos vectores se crea el cepstrograma (Figura 4.6), cada columna del cepstrograma es uno de esos vectores. Por lo tanto el cepstrograma contará con 12 filas y tantas columnas como subframes tenga el frame de 100ms. Figura 4.6: Gráfico formación del cepstrograma a partir coeficientes MFC 3. Cálculo de la media y varianza (elemento a elemento): una vez se tienen los cepstrogramas de todos los frames del conjunto de ejemplo se calcula su media y su varianza, pero no entre matrices sino entre la serie de elementos encontrados en la misma posición de la matriz. Para poder hacer este tipo de operaciones todos los frames y subframes deben tener el mismo tamaño. Media = = 2+7+ n 3+9+ n 8+4+ n 4+3+ n 5+8+ n 1+6+ n 5+1+ n 7+5+ n 3+2+ n (4.3) donde n es el número de cepstrogramas procedentes del conjunto de ejemplo Varianza = = (2 avg) 2 +(7 avg) 2 + n (3 avg) 2 +(9 avg) 2 + n (8 avg) 2 +(4 avg) 2 + (4 avg) 2 +(3 avg) 2 + n (5 avg) 2 +(8 avg) 2 + n (1 avg) 2 +(6 avg) 2 + (5 avg) 2 +(1 avg) 2 + n (7 avg) 2 +(5 avg) 2 + n (3 avg) 2 +(2 avg) 2 + n n n 29

62 donde n es el número de cepstrogramas procedentes del conjunto de ejemplo y avg es la media correspondiente a esa posición en la matriz. Una vez se han obtenido los cepstrogramas, su media y su varianza ya se puede pasar al procedimiento para calcular la similitud entre la muestra del micrófono y el conjunto de entrenamiento o ejemplo Primer filtrado de la señal La entrada que recibe el algoritmo es una señal de audio grabada a una determinada frecuencia de muestreo, que será representada por un array de números en coma flotante con signo (floats en Java). Se dividirá en frames, los cuales se dividirán en subframes con un solapamiento correspondiente a la mitad del tamaño de subframe al igual que se ha explicado en la sección Tras dividir la señal en frames se calcula el cepstrograma de cada uno de sus frames para después comparar dichos cepstrogramas con el cepstrograma del conjunto de entrenamiento. Cuando ya se tiene el cepstrograma de cada uno de estos "superframes"se procede a aplicar este primer filtro. Este primer filtro afecta a dos dominios de la señal: 1. Dominio del tiempo, en este dominio se encuentra tanto la energía de corto plazo (short-time energy) como la tasa de cruces por cero (ZCR),se explicarán dentro de los apartados Energía de corto plazo y ZCR. 2. Relacionadas por el cepstrograma, correspondiente al coeficiente Cn que indica la semejanza de la muestra con el conjunto de entrenamiento o plantilla. En la Figura 4.7 se muestra un diagrama con los diferentes procedimientos a los que se someterá la señal y debe superar para que un frame sea considerado como precandidato a respiratorio. Coeficiente de similitud Cp El coeficiente de similitud Cp, ya no corresponde al filtrado relativo al dominio del tiempo de la señal sino que este va enfocado a la comparación de los cepstrogramas que se han calculado previamente. A continuación se describe paso a paso el proceso seguido para calcular éste coeficiente. 1. En primer lugar, se normalizan las diferencias entre el template y el cepstrograma del frame que se está estudiando, con el objetivo de compensar las diferencias en la distribución de los diferentes coeficientes cepstrales. En este paso se emplean la media y la varianza calculadas en la sección Construcción del template, y el cepstrograma obtenido en la sección Fase de detección. Este cálculo al igual que la media y la varianza se hará elemento a elemento, no como se realizan normalmente las operaciones entre 30

63 Figura 4.7: Procedimientos que se aplicarán sobre la señal en este filtro matrices. La ecuación para obtener la matriz D es: D = M T V (4.4) donde M es el cepstrograma del frame que se esta analizando, T la media del cepstrograma del template y V la varianza del cepstrograma del template. 2. Después se multiplica cada columna de la matriz D, por una media ventana de Hamming que enfatiza los coeficientes cepstrales más pequeños. Este procedimiento permite una mejor diferenciación de los sonidos respiratorios de los que no lo son [RBH93]. 3. Ahora ya se puede calcular la medida de similitud, Cp, que se calcula tomando la inversa de la suma de cuadrados de todos los elementos de la matriz D. C p = 1 ni=1 Nc (4.5) j=1 D ij 2 donde n es el número de subframes y Nc es el número de coeficientes MFCC calculados para cada frame. Si el valor del Cp es alto indica que el grado de similitud entre el cepstrograma del template y la matriz D son muy parecidos, en cambio si el valor es bajo indica poco grado de similitud entre el cepstrograma del template y la matriz D. Para diferenciar eventos respiratorios de los que no lo son se fijará un umbral para el coeficiente Cp, el cálculo de dicho umbral se explica en el Anexo.2. 31

64 Energía de corto plazo Cada uno de los frames cuenta con un valor de energía (o short-time energy) que caracteriza a dicho frame, dependiendo del valor de ella se puede considerar a un determinado frame como precandidato a evento respiratorio o no. Para calcular la energía de cada frame se aplica la siguiente fórmula a lo largo de toda la señal: E = 1 N 0 +(N+1) N n=n 0 x 2 [n] (4.6) donde x[n] corresponde a la señal de audio en la posición n, N es la longitud del frame y No corresponde a la posición inicial del frame del cual se está calculando su energía. Una vez se ha calculado la energía se pasa a una escala logarítmica aplicando la fórmula: E, db = 10 log 10 (E) (4.7) Tasa de cruces por cero o Zero Crossing Rate (ZCR) ZCR corresponde al número de veces que la onda de la seña del audio cambia de signo (positiva a negativa, y viceversa). Al igual que la energía también cuenta con una fórmula para su cálculo a lo largo de un frame. ZCR = 1 N 0 +N 1 N n=n ,5 sgn(x[n]) sgn(x[n 1]) (4.8) El umbral que se utilizará para discriminar entre precandidatos a eventos respiratorios se determinará mediante el proceso mostrado a continuación. Esta clasificación puede no arrojar resultados tan positivos como se esperan, por lo que tiene que pasar por un segundo clasificador que detecta los falsos positivos utilizando los valores del dominio del tiempo que se han mencionado y la duración de los eventos. Proceso de selección de los umbrales sobre las características: Short-time Energy y ZCR, para discriminar entre frames de respiración y frames de voz Con el objetivo de calcular estos umbrales se emplean diferentes cálculos estadísticos sobre una muestra inicial que contengan tanto fragmentos respiratorios como fragmentos de voz. En primer lugar se divide la señal de voz en varios archivos.wav que contengan o bien eventos de voz o bien eventos respiratorios. Para ello se analiza la muestra oyéndola y cortando cada uno de los fragmentos manualmente, además de que gráficamente se puede observar que fragmento corresponde a cada evento (aunque cabel a posibilidad de que las respiraciones sean confundidas con silencios). 32

65 Para corroborar que las respiraciones elegidas son correctas se aprovecha el primer coeficiente de similitud (entre el conjunto de entrenamiento y la muestra) Cp con valores superiores a Bm/2. Esto puede dar lugar a falsos positivos que se irán eliminando en fases posteriores del proyecto. Además para saber el momento del audio en que se encuentra el evento respiratorio se utiliza la posición dentro del vector inicial y la tasa de muestreo, obteniendo el segundo en que tiene lugar. Una vez se tienen los diferentes archivos.wav tanto de respiraciones como de fonemas se procede a su fragmentación en frames de la misma forma que se ha hecho anteriormente con la entrada de audio inicial. Se calcula el short-time energy y el coeficiente ZCR de cada uno de los frames. Después se juntan todos los datos de energía y ZCR para calcular dichos descriptores estadísticos y ya seleccionar los umbrales más característicos para cada tipo de Frame (fonemas de voz o eventos respiratorios). En el capítulo 5 se explica detalladamente las herramientas e implementaciones necesarias para conseguir los umbrales que se desean Delimitación de eventos respiratorios El resultado obtenido de la sección anterior se correspondería con varias sucesiones de subframes considerados precandidatos a evento respiratorio, en esta sección el objetivo es delimitar el inicio y fin de esos eventos empleando los mínimos locales de energía dentro de la muestra. Al igual que en la sección de filtrado anterior, se acompaña de un diagrama que ayuda a su comprensión (Figura 4.8). Filtro de medias de 3 puntos La aplicación del primer filtro de medias consigue suavizar la energía de los subframes, al depender cada subframe de los valores de sus adyacentes tanto a derecha como izquierda. Sólo se aplica al valor de la energía de los subframes, el siguiente filtro afectará a otro atributo diferente. La fórmula que se ha empleado ha sido la siguiente: Energa[i] = Energa[i 1] + Energa[i] + Energa[i + 1] 3 (4.9) Picos (o peaks) y mínimos (o deeps) Lo primero es indicar a que corresponden estos conceptos y sobre que atributo se aplican. Un pico (o como será referido a lo largo de la memoria, peak ) es un subframe cuyo valor de su energía es mayor que sus valores vecinos tanto a la izquierda como por la derecha. Por el contrario un mínimo (o como será referido a lo largo de la memoria, deep) es un 33

66 Figura 4.8: Diagrama sobre la delimitación de eventos respiratorios 34

67 subframe cuyo valor de su energía encuentra entre dos peaks, o lo que es lo mismo sus vecinos inmediatos tanto a la derecha como a la izquierda poseen una energía superior a la suya. En la Figura 4.9 se muestra un ejemplo de un deep entre dos peaks. En el capítulo siguiente se explicará como se ha llevado a cabo la búsqueda tanto de deeps como de peaks. Eliminación de deeps insignificativos Los deeps referidos en la subsección anterior delimitaran tanto el inicio como el fin de los eventos respiratorios, pero no todos los deeps obtenidos se deberán considerar puesto que deben cumplir una condición para ser considerados deeps significativos. Un frame X k se considera deep significativo si max{e(x L ) E(X K ), E(X R ) E(X K )} > (E max E min )/4 (4.10) donde X L y X K son los picos más cercanos tanto a derecha como a izquierda, E max y E min son el máximo y el mínimo de la energía en la vecindad de los picos (no sólo los vecinos inmediatos sino un pocos más lejos a ambos lados). Filtro de medianas de 9 puntos El filtro de medianas considera el hecho de que un subframe se marque como respiración o no (1/0) en función de los cuatro subframe que lo preceden y los cuatro que lo suceden. Es decir, un subframe se marcará como respiratorio o no si el cálculo de la mediana entre él y sus ocho vecinos da como resultado 0 o 1, por lo tanto tiene en cuenta la influencia de los frames vecinos. Tras la aplicación de este filtro es cuando ya se marcan las sucesiones de 1s consecutivos como secciones candidatas y las sucesiones de 0s se marcan como eventos no respiratorios. De momento candidatas porque después se calcularán los bordes de dichas respiraciones y quizás puede que ocupen más espacio del que ocupan actualmente, al refinar dichos bordes, pudiendo concatenarse secciones candidatas próximas. Figura 4.9: Ejemplo gráfico de peak y deep 35

68 Búsqueda de deeps en candidatos y delimitación de candidatos Una vez se tienen determinadas las secuencias de frames respiratorios consecutivos y se han calculado los deeps significantes que existen en la muestra se debe buscar qué deeps están incluidos en cada una de esas secuencias. Esta búsqueda ayudará a definir el inicio y final de las respiraciones sirviendose de un cuadro (Cuadro 4.1) que define unos límites u otros en función del número de deeps que contenga cada una de éstas secciones delimitadas por su inicio y su fin [Xini,Xfin]. Número deeps en el intervalo Ningún deep 1 deep 2 o más deep Decisión El algoritmo busca los deeps más cercanos fuera del intervalo por ambos lados y los marca como límites de la respiración Si tiene un deep se marca este como límite izquierdo de la respiración y se busca a la derecha el deep más cercano fuera del intervalo. En caso de que alguno de los subframes a la derecha del deep incumplan alguno de los umbrales de energía o ZCR, se fijará el deep interior como límite derecho y se buscará el primer deep hacia la izquierda para marcarlo como deep inferior. Se marca como límite izquierdo el deep más cercano al inicio del intervalo y como límite derecho el más cercano al final del intervalo, ambos valores dentro del intervalo Cuadro 4.1: Criterios para escoger los límites del evento respiratorio Segundo filtrado de la señal Este segundo filtrado se aplicará única y exclusivamente a las secciones candidatas, es decir aquellas sucesiones de unos consecutivas que son referidas como objetos BreathEvent. A diferencia del primer filtrado no va a tener en cuenta ni los cepstrogramas ni el coeficiente Cp, sólo se va a basar en el dominio del tiempo en cuanto a energía, ZCR y duración del evento respiratorio. En la sección anterior se ha explicado en que consiste la energía y ZCR, sólo falta explicar el por qué de un umbral en cuanto a la duración de los eventos candidatos. Se fijan umbrales tanto mínimos como máximos porque se puede dar el caso de que el algoritmo detecte como respiración algunos eventos excesivamente largos (fuera de lo normal) o eventos que son tan pequeños que no es posible que una persona pueda coger aire en fracciones de tiempo tan pequeñas. Los candidatos a respiración que logren pasar este filtro serán finalmente seleccionados como eventos respiratorios, los que no se volverán a marcar como fonemas o eventos no respiratorios. Al elegir los umbrales para este segundo y último filtro para la diferenciación de respiraciones se será especialmente estricto para que los resultados sean lo más robustos 36

69 posibles, es preferible que detecte menos respiraciones de las que hay con pocos o ningunos falsos positivos a que detecte todas las respiraciones existentes en la grabación pero con una mayor existencia de falsos positivos. Esta parte es muy delicada porque no es sólo la salida de este algoritmo sino también la entrada del siguiente, cuanto mejor delimite este algoritmo mejores resultados se obtendrán del segundo. A continuación se muestra un gráfico (Figura 4.10) con los diferentes procedimientos que debe superar cada uno de los breathevents para poder se considerados respiración. Figura 4.10: Procedimientos a aplicar en el segundo filtrado sobre los candidatos 4.2 Algoritmo 2: Valoración del estado respiratorio del usuario Este segundo algoritmo se encargará de determinar el estado respiratorio del usuario en base a los eventos que fueron detectados y delimitados por el primero de los algoritmos. Como se ha comentado en la sección anterior, es crucial garantizar la robustez en la detección y demarcación de los eventos respiratorios que proporciona el primer algoritmo, puesto que dichos eventos constituirán la entrada del segundo algoritmo. En este sentido, hay que evitar la aparición de falsos positivos entre los eventos respiratorios detectados, es decir, es preferible perder agudeza en la detección de los eventos (creciendo el número de "falsos negativos"), haciendo más restrictiva la configuración del primer algoritmo, de modo que, aunque su salida no proporcione todos las respiraciones que ocurrieron durante el habla continua, sí que se detecten aquellas en las que se tiene una mayor certeza de que no serán eventos de voz u otro tipo, distinto de los de respiración. Así se evita, en cierta medida, que fonemas de voz mal identificados como respiraciones alimenten la entrada del algoritmo de 37

70 valoración del estado respiratorio. El vector de características elegido para discriminar entre los estado respiratorios: bueno, normal y con dificultad respiratoria se construye a partir de los coeficientes MFCC de los frames que componen los eventos respiratorios, que ya han sido calculados por el algoritmo anterior. El hecho de haber elegido los coeficientes MFCC es porque se han estudiado varios artículos en los que se demuestra diferencias claras entre respiraciones normales y anormales, siendo el más representativo [Rac]. Se ha optado por utilizar modelos de mezclas gaussianas (GMM) para caracterizar tanto un modelo de respiraciones normales como un modelo de respiraciones anormales (asma, bronquitis,... alguna enfermedad pulmonar) al igual que lo realizan en el artículo [BP04]. Los modelos de mezclas gaussianas (GMM, gaussian mixture model) [JC08] nos permiten la clasificación de rasgos acústicos reflejando las características de la locución de forma estadística. Para ello realizan una suma ponderada (mezcla) de funciones de densidad de probabilidad gaussianas, lo permite representar alguna característica de la locución humana con alta fidelidad. En este caso se ha optado por la caracterización mediante coeficientes MFCC. Este método también se emplea para el reconocimiento del locutor en una audición [RQD00] debido a su gran resolución. En la Figura 4.11 se muestra un ejemplo de como se ha modelado una curva de función de densidad de probabilidad mediante una mezcla de tres funciones gaussianas. Figura 4.11: Mezcla de tres funciones gaussianas Para entrenar cada una de las distribuciones tanto de respiraciones buenas como anormales, se han creado dos modelos independientes. Se utiliza el algoritmo de entrenamiento EM (Expectation Maximization) con un conjunto de datos recopilado de personas con alguna enfermedad pulmonar para un modelo; y con personas sanas para el otro de los modelos. Este algoritmo EM se encarga de adaptar los parámetros estadísticos (media y varianza) que 38

71 definen cada gaussiana al conjunto de entrenamiento para lograr el mejor ajuste entre los datos en bruto y el modelo. Su nombre viene dado porque es un algoritmo iterativo dividido en dos pasos, Expectation y Maximization, lo que tiene lugar en cada uno de los pasos se puede apreciar en la Figura Figura 4.12: Esquema funcionamiento EM En la Figura 4.13 se puede observar como se distribuyen los datos correspondientes al conjunto de entrenamiento del modelo de respiraciones con alguna enfermedad. Figura 4.13: Distribución datos entrenamiento modelo enfermos Una característica del modelo de gaussianas que va a determinar tanto la calidad de los resultados como el tiempo de cómputo necesario para obtenerlos será el número de gaussianas a emplear. Debe elegirse la cantidad adecuada ya que si se escogen muchas gaussianas se sobreajustaría la distribución y en caso de que las gaussianas elegidas fueran pocas no sería lo suficientemente flexible como para describir la distribución de los datos. Es decir cuantas más compenentes gaussianas mejor, pero llega a un punto en que son excesivas y los resultados no son los deseados. Para el caso particular que aquí nos ocupa, tras algunas pruebas empíricas, los mejores modelos de mezclas gaussianas (en términos de la relación entre precisión de la estimación y tiempo necesario para su entrenamiento) tanto para respiraciones normales y respiraciones anormales, se han obtenido empleando 16 gaussianas. Una vez entrenada y caracterizada cada distribución GMM, el objetivo será fijar un coeficiente de similitud que nos indique el grado de similitud de un conjunto de eventos respiratorios de prueba (proveniente de la aplicación del primer algoritmo de demarcación de 39

72 eventos respiratorios durante habla continua), con respecto de cada una de las distribuciones modeladas. En otras palabras el coeficiente nos proporciona una medida de cómo de bien se ajustan los eventos respiratorios identificados y delimitados por el primer algoritmo con uno y otro modelo de gaussianas. El índice de similitud estimado por Weka (Log likely-hood) para las muestras de test con respecto del modelo de respiraciones normales y con respecto del modelo de respiraciones anormales que sea más próximo a 0 determinará el estado respiratorio del usuario en ese momento. Entrando un poco más en detalle, en como se construye el coeficiente de similitud final, el proceso consiste en dividir el mayor de los valores de ajuste obtenidos entre el menor de los valores de ajuste del otro modelo y si el resultado está en [1, 1.05] se define como un estado respiratorio normal. En el caso de que el mayor de los valores sea el que exprese la similitud con las respiraciones normales y el coeficiente sea mayor a 1.05 se define como estado respiratorio bueno, y por último en caso de que el mayor de los valores sea el que exprese la similitud con las respiraciones anormales y el coeficiente sea mayor a 1.05 se define como estado con dificultad respiratoria. A pesar de las medidas tomadas para garantizar la robustez de los eventos respiratorios identificados y demarcados por el primer algoritmo que sirven de entrada al algoritmo de valoración del estado respiratorio, es posible que se lleguen a calcular los coeficientes de similitud sobre un falso evento respiratorio, respecto de los dos GMM ( respiraciones normales y respiraciones anormales ), para evitar su mala influencia sobre el resultado de valoración del estado respiratorio se cogerá la mediana de los coeficientes de similitud calculados sobre cada una de las muestras que componen el conjunto de test. No se emplea la media porque se ve más afectada por los valores atípicos que puede causar algún falso evento respiratorio. 40

73 Capítulo 5 Método de trabajo EN este capítulo correspondiente al método de trabajo se dan las razones acerca de porque ha sido escogido uno en concreto, las ventajas que aporta y que procesos ha incluido cada una de las iteraciones. 5.1 Metodologías ágiles El término ágil como tipo de metodología de desarrollo software se acuñó en 2001, en una reunión celebrada en Utah donde se concentraron 17 expertos del software. El objetivo principal de esta nueva metodología era dar la posibilidad de desarrollar software rápidamente y permitiendo aplicar cambios que surgieran a medida que avanzaba el proyecto. En contraposición las metodologías anteriores eran muy rígidas ya que todo estaba fijado en un contrato y la inserción de cambios era bastante complicada. Tras la citada reunión se creó una asociación (The Agile Alliance) que se dedica a promover y ayudar a las organizaciones a emplear este tipo de metodologías. Con el objetivo de dejar constancia de los principios que envuelven a las metodologías ágiles se creo el Manifiesto Ágil ([PL03]). A continuación se muestra una tabla con las ventajas de las metodologías ágiles con respecto a las tradicionales Prototipado evolutivo El aspecto principal que define este método de trabajo es que el concepto de sistema de desarrolla a medida que avanza el proyecto. El equipo de desarrolladores crea diseña y construye un prototipo, que muestra al cliente y este da su opinión; la ventaja es que el equipo recibe la retroalimentación del cliente para bien corregir errores y volver a mostrárselo o directamente incluirlo en el sistema final (Figura 5.1). Cada vez que se llega a una entrevista con el cliente, si el prototipo es suficientemente bueno para el cliente, dicho prototipo pasa a ser parte del producto final e incluso es operativo para ponerse en funcionamiento con información real. Este tipo de prototipado se utiliza especialmente cuando los requisitos cambian con rapidez, el usuario no se muestra voluntarioso para facilitar todos los requisitos del sistema completo, o cuando ni el desarrollador ni el usuario tienen muy claro el área que abarcará el sistema. La razón principal por la que en 41

74 Metodologías ágiles Basadas en heurísticas provenientes de prácticas de producción de código Especialmente preparados para cambios durante el proyecto Impuesta por el equipo de desarrollo Proceso menos controlado, pocos principios Ausencia de contrato y en caso de existir muy flexible El cliente es parte del equipo de desarrollo Grupos pequeños que trabajan en el mismo sitio Pocos artefactos Pocos roles Menos énfasis en la arquitectura del software Metodologías Tradicionales Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo Cierta resistencia a los cambios Impuestas externamente Proceso mucho más controlado, sigue normas y políticas Existe un contrato prefijado El cliente sólo se comunica con el equipo mediante reuniones Grupos grandes y distribuidos Más artefactos Más roles La arquitectura del software es esencial y se expresa mediante modelos Cuadro 5.1: Diferencias entre metodologías ágiles y tradicionales Figura 5.1: Esquema del funcionamiento del prototipado evolutivo 42

75 Figura 5.2: Arquitectura de los módulos que forman la aplicación este proyecto se ha optado por el prototipado evolutivo es cuando no se está muy seguro de la arquitectura o cuando hay dudas acerca de los algoritmos a implementar. Con esta técnica si la opción de un algoritmo resulta no ser la deseada, se desecha para en la siguiente iteración o prototipo entre una una opción. 5.3 Desarrollo Inicio El inicio del presente proyecto tuvo lugar en Octubre de 2013, esta etapa incluye la búsqueda información acerca de las diferentes posibilidades que existían para crear un espirómetro en una plataforma móvil. Después de buscar información se llevo a cabo un estudio sobre ella y se decidió hacer sobre el sistema operativo Android y siguiendo como patrón el artículo SpiroSmart [LGB + 12]. En las siguientes subsecciones se expondrá el desarrollo de los diferentes módulos del proyecto (Figura 5.2), compuestos de varios submódulos en función de la complejidad del mismo Módulo I: Captura señal de audio Como primer paso para el desarrollo de este TFG se necesitaba partir de una señal la cual analizar y de ahí extraer los parámetros que caracterizaban el soplido del usuario. Este módulo se ha dividido en dos submódulos explicados en los puntos sucesivos. La descomposición en submódulos se puede ver gráficamente en la Figura

76 Figura 5.3: Submódulos y resultado del Módulo I: Captura señal de audio Submódulo A: Captura y almacenamiento de señal en formato WAV El inicio de todo es poder acceder al micrófono para guardar los datos que reciba por parte del usuario. Para ello se ha hecho uso de la clase AudioRecord de Android que permite capturar los sonidos del micrófono pudiendo configurar diferentes parámetros como son: Origen de la muestra: en este caso se ha elegido el micrófono, pero hay varias opciones (micrófono en la misma orientación que la cámara, llamada de voz, comunicaciones sobre voip) Tasa de muestreo: se indica el número de muestras por segundo que se quieren tomar. Canales: se indica si se quiere un canal (mono) o varios (stereo) Formato representación del audio: se puede elegir entre PCM a 8 bits o a 16 bits. Tamaño del buffer: aquí se indica el tamaño del buffer sobre el que se quiere grabar la muestra. Una vez se ha grabado la muestra en el archivo, se le añade la cabecera correspondiente al formato WAV, que ofrece diferentes ventajas a la hora de analizar la muestra sin pérdida de calidad del sonido. El Activity prinicipal de grabación crea una instancia de la clase EnviromentRecorder que será la encargada de transformar el flujo de datos procedente del usuario en un archivo de audio wav. Submódulo B: Manejo de un audio wav como array de floats La relación de éste submódulo con el anterior es que la salida del anterior (archivo WAV) se utiliza como entrada para éste. El submódulo B se encarga de pasar el archivo WAV a un array de floats que representarán la señal del audio. De ello se encarga la clase Wave- Tools.java, que lee la ruta de un archivo WAV que se le pasa como parámetro y lo convierte en un array números en coma flotante con signo (tipo float en Java). Primero lee la cabecera para saber la tasa de muestreo, del tipo de archivo que se trata y los canales que tiene, una vez tiene esa información recoge porción a porción todo el audio. Como resultado final se tiene un arreglo de floats con signo, indicando las amplitudes de todos los componentes de la muestra. 44

77 Figura 5.4: Espectrograma inicial Módulo II: Espirometría forzada y reconocimiento de eventos respiratorios El Módulo II se encargará de tratar la señal recibida del Módulo I para poder extraer los eventos respiratorios necesarios. Al igual que el primer módulo se divide en varios módulos cuyas entradas y salidas corresponden, es decir, la entrada de un submódulo B es la salida del submódulo A Módulo IIa: Espirometría forzada Submódulo A: Generación espectrograma Se recibe una señal en el dominio del tiempo de la cual se tiene que calcular su espectrograma. El citado espectrograma es el resultado de calcular el espectro de tramas enventanadas de una señal, resultando una gráfica tridimensional que representa la energía del contenido frecuencial de la señal según va variando a lo largo del tiempo. El objetivo del uso del espectrograma es calcular el espectro de la señal en diferentes fragmentos de tiempos consecutivos para caracterizar la señal. Para poder calcular el espectrograma lo primero que se ha realizado ha sido fragmentar la señal en pequeños segmentos solapados y enventanar cada uno utilizando la ventana de Hamming. Tras ello aplicar la Transformada Rápida de Fourier a cada muestra, que transforma el dominio de la señal, pasando de ser el tiempo a ser un dominio de frecuencias. Después de calcular la Fast Fourier Transform (FFT) a cada muestra se obtiene un número complejo, al cual hay que extraer su espectro elevando al cuadrado tanto la parte real como la imaginaria. Una vez se ha obtenido el espectro se calcula el logaritmo en base 10 al resultado de la operación anterior y se coloca en su intervalo de frecuencias correspondiente (al aplicar la FFT generalmente se divide el espacio de frecuencias en 256 o 512 intervalos). Si se representa la magnitud de los espectros poniendo cada uno consecutivo del otro en el tiempo (eje X), en el eje Y los rangos de frecuencias y en el eje Z las magnitudes obtenidas para cada frecuencia se obtiene el espectrograma (Figura 5.4). Los colores de cada uno de los puntos que existen en el gráfico son la amplitud de cada frecuencia ordenados así, Cuadro

78 Color Rango Valores descartados o filtrados Magnitudes entre 0 y 10 Magnitudes entre 10 y 20 Magnitudes entre 20 y 30 Magnitudes >30 Cuadro 5.2: Relación colores-frecuencias A simple vista se puede apreciar que hay muchos valores negros y verdes, los cuales representan los rangos de frecuencia con magnitudes muy bajas. Para eliminar todo este ruido y sólo dar cabida en el espectrograma a los valores significativos se desarrolla el segundo submódulo que incluye varios filtros. Submódulo B: Aplicación filtros al espectrograma En este submódulo lo que se pretende es eliminar esos rangos de frecuencia con poca energía localizada. Se han empleado dos filtros: 1. Filtrado por columnas: consiste en recorrer cada una de las columnas del espectrograma, e ir eliminando los valores inferiores al 30 % del valor máximo de la columna. El resultado con respecto al espectrograma que se muestra en el apartado anterior, se puede ver en la Figura Filtrado bandas de energía: este filtro de lo que se encarga es de recorrer el espectrograma por cada rango de frecuencia (fila) y descartar los valores de magnitud aislados que no conformen una ráfaga continua de energía de al menos 300 ms con valores de magnitud significativos en un determinado rango de frecuencias. Una vez se ha aplicado el primer filtro el resultado del espectrograma inicial se corresponde con la Figura 5.5, después se aplica el segundo filtro teniendo como resultado la Figura

79 Figura 5.5: Filtro 1 Figura 5.6: Filtro 2 Figura 5.7: Representación gráfica del espectrograma resultante Submódulo C: Representación gráfica muestra El último paso dentro de este submódulo consiste en la creación de una gráfica basada en el espectrograma final, tras aplicarle los dos filtros de los que se ha hablado en el submódulo anterior. Para ello el procedimiento que se ha seguido ha sido recorrer todo el espectrograma y calculando en cada columna de tiempo una media ponderada en función de la magnitud de la frecuencia en cada uno de los puntos, ésta frecuencia abarca desde 0 hasta el número de filas de la matriz. columna[i] fila[j] media[j] = columna[i] Finalmente se obtiene un array unidimensional de floats que contiene la media ponderada de cada columna listos para su representación gráfica. La realización de la gráfica en base al array obtenido se ha llevado a cabo gracias a una librería de Android llamada GraphView (enlace), esta librería permite la generación de múltiples tipos de gráficos de manera sencilla incluso permitiendo que éstos gráficos sean dinámicos (se puede hacer zoom en ellos). La gráfica resultante del ejemplo con el que se viene desarrollando este módulo es la Figura 3. En el Listado 5.1 se muestra el código necesario para la representación. GraphViewData [] data = new GraphViewData [ mediaspon. length ]; for ( int i =0;i< data. length ;i ++) { data [i]= new GraphViewData (i, mediaspon [i]); } GraphView graphview = new LineGraphView ( this, " E s p i r o m e t r a " ); graphview. addseries ( new GraphViewSeries ( data )); // data graphview. setmanualyaxisbounds (350, 0); 47

80 LinearLayout layout = ( LinearLayout ) findviewbyid ( R. id. graph1 ) ; layout. addview ( graphview ); Listado 5.1: Representación array con GraphView Una vez que ya se había logrado toda esta representación se añadió a la aplicación una pequeña base de datos SQLite en la que se añadían varios datos de cada muestra que se hola mamitomaba. Todo esto era necesario para iniciar una recolección de muestras e ir comprobando como se comporta la aplicación. En la toma de muestras se realizaba una muestra sobre el smartphone por espirometría forzada y otra muestra sobre el espirómetro indicado en el capítulo 2. Tras haber realizado dichas muestras se llegó a la conclusión que los datos que se recibían en uno y otro no eran equiparables como para poder arrojar valores espirométricos fiables. Debido a ello se continuó con la investigación para ver de que forma se podían aproximar esos valores utilizando el smartphone Módulo IIb: Obtención de los vectores de características de los Frames En este módulo se explican las decisiones tomadas tras descartar el módulo IIa y el por qué se procede de dicha manera, además de exponer los submódulos que formarán el nuevo módulo. La descomposición en submódulos se puede ver gráficamente en la Figura 5.8. Figura 5.8: Submódulos y resultado del Módulo IIb: Obtención de los vectores de características de los Frames Submódulo A: Cambio de dirección El resultado fue la nueva idea de detectar los eventos respiratorios en el habla, con técnicas que se explicarán a continuación y una vez se tuvieran dichos eventos su duración y energía aproximar los valores con ecuaciones ya existentes que relacionan los parámetros 48

81 Figura 5.9: Ejemplo de muestra recogida por la aplicación: altura, edad, sexo, fecha toma, [asmático/alérgico/sano], estado mencionados. Inicialmente se tomó la decisión de detectar los eventos respiratorios en el habla mediante el entrenamiento de un algoritmo con muchas muestras de diferentes sujetos variando sexo, edad, altura, peso, etc (Figura 5.9). Para ello se desarrolló una aplicación Android que lo único que hacía era que el usuario grabara un par de oraciones con alto contenido de vocales, y una vez grabadas se mandaba a una base de datos dentro del servidor de MAmI. La aplicación se puso en la tienda de Android, Google Play, con el nombre de Asma-Alergia-Voz, y se notificó a varias asociaciones de asmáticos y alérgicos de España y Chile resultando la toma de muestras muy participativa. Sin embargo de todas las 304 muestras que se encuentran en la base de datos muchas de ellas no son muestras correctas: son silencios, dicen otras frases, las dicen muy bajo, y diversas causas. Por tanto se investiga acerca de como puede realizarse el reconocimiento de los valores espirométricos con algún algoritmo que requiera menos muestras, llegando con ello al artículo [RL07] que con tan sólo unas pocas muestras, entre 5 y 10, es capaz de detectar eventos respiratorios con bastante exactitud. En este punto se desecha todo lo conseguido en el módulo IIa pero el módulo I se queda intacto, ya que para el nuevo enfoque sigue haciendo falta capturar la señal del micrófono y transformarla en un array de floats. De nuevo se vuelve ese array sin ningún tipo de procesamiento que se debe tratar para conseguir los valores que se desean. Todo el tratamiento se dividirá en submódulos y se pasará a explicar a continuación. 49

82 Submódulo B: Ventaneo de la señal Este submódulo cubre las necesidades que se exponen en el capítulo 4 sobre la división de la señal en frames y subframes con un solapamiento, que se muestra en la sección del cálculo de los coeficientes MFC (ver 4.1.1). El objetivo de este submódulo es dividir la señal de audio formada por un array de floats que se recibe como resultado del desarrollo y ejecución del Módulo I: Captura señal de audio. Para cumplir dicho objetivo se ha desarrollado una clase llamada Frame para facilitar la abstracción y manejo de todos los que forman el array. Su constructor recibe como parámetros el array de floats y la frecuencia de muestreo a la que se ha grabado para poder dividir la señal. Toda la división de la señal la realiza un método llamado doframing() que recibe el tamaño del que se desean hacer sus partes (subframes) y el solapamiento entre subframes (subframehopsize). Se recorre todo el array sacando nuevos subframes que también serán objetos Frame e irán destinados a una lista de subframes que además incluye su inicio y final dentro del frame mayor. Como resultado del desarrollo de este submódulo resultan objetos Frame que contienen una muestra menor a la original que recibe el constructor para después calcular los valores necesarios. Submódulo C: Hamming + FFT El submódulo anterior se ha desarrollado con el objetivo de poder calcular los coeficientes MFC de cada uno de los frames de la señal de audio recogida por el micrófono. Antes de calcular dichos coeficientes es necesario filtrar frecuencias falsas debidas al corte de la señal y pasar la señal de estar en función del tiempo a estar en función de la frecuencia. Por ello, se han creado dos clases, una se encarga de calcular los coeficientes MFC (MFCC.java) y otra para aplicar la transformada rápida de fourier (FFT.java) sobre las señales obtenidas del primer submódulo. En un principio MFCC.java sólo contaba con 4 métodos que llegaban al punto de la división de la señal sobre los 512 contenedores tras aplicar la FFT. Estos tres métodos eran: calcmfcc(): este método se encarga de llamar a todos los métodos necesarios para el cálculo de los arrays de características de la señal. Hasta este punto, acaba una vez clasificaba la señal en los 512 contenedores tras aplicar la FFT. windowingframesignal(): aplica la ventana de Hamming a la señal para posteriormente aplicar la FFT. (ver 4.1) magnitudespectrum(): llama a la clase FFT.java, que se explicará a continuación, recibiendo el resultado de aplicar la FFT y se calcula el espectro de cada elemento elevando al cuadrado su parte real e imaginaria. powerspectrum(): recibe el array con los espectros y aplica una fórmula para asignarle 50

83 el contenedor FFT más cercano. La clase FFT.java no recibe ningún tipo de parámetro en su constructor y se llama a su método computefft con un frame como parámetro. Este método crea dos arrays de floats del mismo tamaño que el frame, en uno se alojará la parte imaginaria y en otro la parte real que se indicaba en la explicación. Después llama al método fft() que es el que recorrerá todo el frame asignando los valores correspondientes a los arrays anteriormente creados (real e imag). Se obtendrá así un periodograma basado en los espectros calculados que será utilizado en el siguiente submódulo para el cómputo de los coeficientes MFC. Submódulo D: Obtención coeficientes cepstrales En este submódulo se implementan el resto de métodos de la clase MFCC.java y la clase DCT.java. Lo primero que se hace es añadir a calcmfcc() el método filterbanks() que crea los bancos triangulares de los que se habla en el capítulo previo que cuenta los fundamentos teóricos. Este método pasa los frecuencias mínimas y máximas de hertzios a Mel para poder crear estos filtros y clasificar la señal, como resultado se obtiene una matriz cuyas filas son los filtros de los que se habla. Tras ello, el método fbenergies recibe el periodograma calculado luego de la FFT y la matriz que representa los filtros Mel. Ahí recorrerá los filtros Mel asignando cada uno de los valores del periodograma a su filtro correspondiente y pasando el valor de la energía a una escala logarítmica. Por último la clase DCT.java implementa un método para calcular la transformada discreta del coseno a los valores de los filtros Mel para así transformarlos a un dominio temporal, obteniendo los valores que caracterizaran a ese frame (coeficientes MFC). Submódulo E: Creación cepstrograma El submódulo anterior tiene como salida los coeficientes cepstrales de cada uno de los subframes (fragmentos 10ms) que forman el frame (fragmento 100ms) que caracterizan la señal. Después hay que crear un cepstrograma en base a los vectores de características de los subframes que en conjunto caracterizarán al frame. Esta parte de la implementación se incluye en la clase Cepstrogram.java cuyo atributo es una matriz de floats que será el cepstrograma en sí. Cuando se crea un objeto Cepstrogram se reciben como atributos las dimensiones de éste, tendrá tantas filas como coeficientes cepstrales se hayan obtenido para cada subframe y tantas columnas como subframes dividan al frame. Cuenta con un método add que recibe como parámetros la columna a la que corresponde y el vector de coeficientes cepstrales, el método incluye cada vector dentro de la columna que corresponda. 51

84 Ya que se tienen los valores deseados que caracterizan cada frame se pasa a desarrollar un nuevo módulo, que aproximará la relación entre el conjunto de ejemplo y la muestra que se está analizando Módulo III: Similitud template - muestra Este módulo engloba las medidas de similitud que se han calculado para marcar la relación o no del audio grabado con un evento respiratorio, que corresponde al conjunto de ejemplo. Con respecto al capítulo de conceptos específicos del dominio en este módulo se cubre parte de la construcción del template (ver 4.1.2), el cálculo de la función de similitud Cp (ver 4.1.3), y por último la relación entre la energía y la tasa de cruces por cero con eventos respiratorios o no respiratorios. La descomposición en submódulos se puede ver gráficamente en la Figura Figura 5.10: Submódulos y resultado del Módulo III: similitud template - muestra Submódulo A: Creación del conjunto de entrenamiento Se le aplica el mismo procedimiento que se redacta en el Módulo IIb con los mismos tamaños tanto de frame como de subframe. El conjunto de entrenamiento se encuentra creado en la clase BreathTrainingSet.java cuyo único atributo es una lista de matrices bidimensionales de floats que corresponden a los cepstrogramas de cada audio del conjunto de ejemplo. Tiene un método addexample que recibe la ruta del audio que se va a emplear como parte del entrenamiento como único parámetro. El método se encarga de fragmentar el audio en frames y subframes, calcular los coeficientes cepstrales de la parte central de la muestra y crear el cepstrograma que se incluirá en la lista caracterizando al audio. 52

85 Submódulo B: Función similitud Cp Para poder calcular el coeficiente de similitud Cp, se ha creado una clase llamada SimilarityCoefficients.java que recibe como parámetro una lista de matrices que son el conjunto de entrenamiento, incluido en un objeto BreathTrainingSet como atributo. Esta clase calcula la media y la varianza elemento a elemento del conjunto de ejemplo (average() y variance()), y después se calcula la matriz D de la que se habla en el capítulo previo mediante el método calcdifferencenormmatrixd() que será la que se empleará para medir la similitud. Para enfatizar los coeficientes cepstrales mas pequeños se utiliza el método liftering que utiliza una media ventana de Hamming sobre la matriz D. Por último, se calcula el coeficiente Cp con la fórmula 4.5 que en el código se encuentra implementado en el método computecpcoefficient(). Submódulo C: Cálculo de energía y tasa de cruces por cero (ZCR) El cálculo de la short-time energy y del ZCR se lleva a cabo en dos de los métodos que contiene la clase Frame.java, donde emplea para cada una de ellas las fórmulas que se citan en el capítulo anterior (Fórmula 4.8 y Fórmula 4.6). Esos métodos son calcenergy() y calczcr que se pueden ver en el Listado 5.2. public void calcenergy () { float sumatorio = 0; for ( int i = 0; i < framesignal. length ; i ++) { sumatorio += Math. pow ( framesignal [i], 2); } // En decibelios : ( INF si todos los samples del frame son 0) setenergy (10 ( float ) Math. log10 ( sumatorio / framesignal. length )); } public void calczcr () { // (0 si todos los samples del frame son 0) float sumatorio = 0; for ( int i = 1; i < framesignal. length ; i ++) { sumatorio += 0.5 f Math. abs ( Math. signum ( framesignal [i ]) Math. signum ( framesignal [i 1]) ); } setzcr ( sumatorio / framesignal. length ); } Listado 5.2: Métodos calcenergy y calczcr 53

86 Submódulo D: Selección de umbrales en relación a Short-time Energy y ZCR Como bien se ha explicado en el capítulo anterior, lo primero que se tiene que hacer es fragmentar la señal en archivos wav tanto de eventos respiratorios como de eventos de voz. Se ha empleado el software Audacity que permite ver como cambia la señal del audio e ir clasificando cada muestra en respiratoria o de voz. En la Figura 5.11 se puede comprobar la división en resp.wav y voz.wav de la muestra muestraiphone.wav. Figura 5.11: División en fragmentos respiratorios/voces Se obtiene así una lista de archivos wav con fragmentos o de voz o de respiración. Para situarlos en el tiempo se ha empleado el atributo start que indica la posición del primer elemento del frame dentro de la muestra inicial. Si se divide ese atributo por la tasa de muestreo se obtiene el segundo en que tiene lugar el evento (Listado 5.3). Hasta el momento sólo se utiliza el primer coeficiente de similitud Cp, considerando eventos respiratorios los frames cuyo coeficiente es mayor a Non Breath Non Breath Non Breath XX Seg :2 Energia ZCR XX Seg :2 Energia ZCR XX Seg :3 Energia ZCR XX Seg :3 Energia ZCR XX Seg :3 Energia ZCR XX Seg :3 Energia ZCR XX Seg :3 Energia ZCR Listado 5.3: Ejemplo de la detección de un posible evento respiratorio entre los segundos 2 y 3 Tras ello se pasan todos los wav por el programa aplicando el método doframing con las mismas medidas que el conjunto de entrenamiento para que los resultados sean coherentes. Se calcula la energía y la ZCR de cada uno de estos frames dividiéndolos como se ha dicho anteriormente en respiratorios o de voz. Estos resultados de voz y respiración en cuanto ZCR y energía se han incluido cada uno de los tipos en un archivo csv para después poder hacer los cálculos pertinentes desde la herramienta RStudio. En RStudio se ha creado un script.r que contiene todas las operaciones necesarias a aplicar a ambos conjuntos de muestras para conseguir los descriptores 54

87 estadísticos (Listado 5.4). Respiraciones< read. csv ("/ home / cristian / Documentos / Respiraciones. csv ") # en caso de ser las Voces o fonemas sonoros # Respiraciones< read. csv ("/ home / cristian / Documentos / Voces. csv ") n< dim ( Respiraciones ) [1] # Media avgzcr< sum ( Respiraciones $ ZCR )/n avgener< sum ( Respiraciones $ Energia )/ n # Mediana median ( Respiraciones $ Energia ) median ( Respiraciones $ ZCR ) # Varianza sum (( Respiraciones $ Energia avgener ) ^2) /n sum (( Respiraciones $ZCR avgzcr ) ^2) /n # Cuartiles # ZCR quantile ( Respiraciones $ZCR,0.25) quantile ( Respiraciones $ZCR,0.5) quantile ( Respiraciones $ZCR,0.75) # Energia quantile ( Respiraciones $ Energia, 0. 25) quantile ( Respiraciones $ Energia, 0. 5) quantile ( Respiraciones $ Energia, 0. 75) Listado 5.4: Script cálculo de descriptores estadísticos Los valores que se consiguen de ejecutar el script sobre las dos muestras son: Media aritmética de ZCR y energía Mediana de ZCR y energía Varianza de ZCR y energía Cuartiles de ZCR y energía A continuación se muestran dos cuadros (Cuadro 5.3 y Cuadro 5.4) con los resultados obtenidos de la aplicación del script R anterior sobre los dos conjuntos de muestras. Submódulo E: Marcado de bordes y eliminación de falsos deeps Desaparece el concepto de superframe y ya solo se trabaja sobre una gran lista de objetos Frame correspondientes a los que anteriormente se llamaban subframes. Filtro de medias de 3 puntos: en la Figura 5.12 se muestra un ejemplo gráfico de lo que consiste un filtro de medias en este caso de 3 puntos. Para aplicar este filtro con los valores de las energías de los subframes contenidos en una lista y actualizar el valor 55

88 Voz Energia ZCR Media Mediana Varianza Cuartil(0.25) Cuartil(0.5) Cuartil(0.75) Cuadro 5.3: Descriptores estadísticos Voz Respiración Energia ZCR Media Mediana Varianza Cuartil(0.25) Cuartil(0.5) Cuartil(0.75) Cuadro 5.4: Descriptores estadísticos Respiración de estas energías en cada uno de los objetos Frame se ha empleado el siguiente código (Listado 5.5). private List < Frame > averagefilter ( List < Frame > demarcationframesaux ){ List < Frame > filtromedias = new ArrayList < Frame >() ; int i = 0; final int POINTS = 3; while ( i < demarcationframesaux. size () POINTS + 1) { Frame [] aux = demarcationframesaux. sublist ( i, i + POINTS ). toarray ( new Frame [ POINTS ]); Frame copy = new Frame ( demarcationframesaux. get ( i + POINTS / 2)); float sum =0f; for ( int j =0;j< POINTS ;j ++) { sum += aux [j]. getenergy (); } copy. setenergy ( sum / POINTS ); filtromedias. add ( copy ); sum =0; i ++; } return filtromedias ; } Listado 5.5: Filtro medias 3 puntos en Java Identificar picos y deeps: sobre la lista de tipo Frame resultante de aplicar el filtro de 56

89 Figura 5.12: Aplicación de filtro de medias de 3 puntos sobre el componente b medias, se identifican sus picos con el método peakmarking que compara la energía de cada uno de los miembros de la lista con la de los frames anterior y posterior. En caso de que el anterior y el posterior sean menores que el del centro, indica que el Frame central corresponde a un pico (o peak). Para identificar los deeps se hace lo mismo pero a cada uno de sus lados la energía debe ser mayor que la suya, esta función la realiza el método deepsmarking. Si se trata de un deep se pasa por un filtro que asegura que no se coge cualquier deep sino que los picos que lo rodean cumplen con un mínimo. El método issignificantdeep es el que determina si un determinado deep es significativo o no. Delimitar eventos respiratorios y aplicación de las reglas: al aplicar el filtro de medianas el método candidatebreathsectionsandmedian además de calcular la mediana se encarga de crear objetos BreathEvent que corresponden a cada una de las sucesiones de eventos respiratorios sucesivos (isbreathframe=1). Estos objetos BreathEvent junto con la lista de deeps contenidos por la muestra se recorren buscando cuantos deeps hay dentro de los límites de cada uno de estos objetos, esta operación es llevada a cabo por el método adddeepinbe. Cuando ya cada una de éstas secciones candidatas tiene definido el número de deeps significativos que contiene, se le aplican las reglas contenidas en la Tabla 4.1 para definir los límites inferior y superior de los eventos respiratorios. El método edgemarking se encarga de aplicar las reglas en función de si contiene 0, 1, 2 o más deeps significativos en su interior. Submódulo F: Segundo proceso de filtrado Eliminación final de falsos positivos una vez se tiene la lista de candidatos y son delimitados con el método edgemarking, en función de los deeps significativos que contiene, se llama al método falsepositiverejection con cada uno de los candidatos que se encuentran en la lista. Este método se encarga de eliminar los candidatos que no cumplan la condición de duración del evento respiratorio mínimo (MIN_LENGTH_BREATH) y que de nuevo cumpla con el criterio de energía sea mayor al mínimo impuesto ya desde el primer filtrado. 57

90 5.3.7 Módulo IV: Valoración del estado respiratorio del usuario Para valorar las respiraciones obtenidas en el primer algoritmo, como buena, normal o con dificultad respiratoria, se ha utilizado una herramienta llamada Weka que incorpora varios algoritmos de inteligencia artificial. En este caso como se ha indicado en el capítulo anterior se emplea el clustering y en concreto la técnica EM que arroja un coeficiente de similitud que cuanto más cercano a cero es más se parece al modelo. La Figura 5.13 muestra los diferentes submodulos de los que se compone. Figura 5.13: Submódulos y resultado del Módulo IV: Valoración del estado respiratorio del usuario Creación archivos ARFF y modelos En primer lugar se deben crear los archivos ARFF, son los únicos además de los csv con los que puede trabajar la librería de weka de ambos modelos. Para ello se han seleccionado manualmente eventos respiratorios de voluntarios sanos y de voluntarios asmáticos de los cuales se han calculado los coeficientes MFCC y se han incluido dentro del proyecto. Para crear los archivos ARFF del resto de eventos respiratorios que serán la salida del primer algoritmo se crea un bucle que va creando un archivo por cada uno de los eventos con sus coeficientes MFCC que caracterizaran cada una de las respiraciones. Cálculo similitud con modelos La similitud de cada uno de los eventos respiratorios con cambos modelos (sanos y asmáticos) se calcula mediante una librería de Weka pero compatible con Android a la que simplemente hay que meter los parámetros que deseas tener, los archivos de entrenamiento y 58

91 prueba (ambos ARFF). Después se elige el algoritmo a ejecutar y tras ejecutarse se mostrarán por pantalla todos los resultados. En el Listado 5.6 se muestra el código correspondiente al cálculo del coeficiente de similitud con el modelo de los asmáticos (malos.arff). options = new String [ 12]; options [0] = " t"; options [1] = Environment. getexternalstoragedirectory ()+"/ Simoa / malos. arff "; options [2] = " T"; options [3] = "/ data / data / com. tfg. cristian. testingdesign / files /"+ strings [0]+ "_"+i+". arff " ;// A q u lo que se vaya a probar options [4] = " N"; options [5] = "16"; options [6] = " I"; options [7] = " 100 "; options [8] = " M"; options [9] = " 1.0E 6"; options [10] = " S"; options [11] = " 100 "; result = ClusterEvaluation. evaluateclusterer ( new EM (), options ); simmalos [i 1]= resulttofloat ( result ); Listado 5.6: Cálculo similitud con el modelo de los asmáticos Los resultados que devuelve son del tipo String por lo que hay que pasar a float el coeficiente que se necesita, para ello se ha implementado el método resulttofloat. Se han creado también dos vectores del tamaño de la lista de BreathEvents en los cuales se van guardando los coeficientes similitud con cada uno de los modelos. Dado que existe la posibilidad de que se detecten falsos positivos como respiraciones buenas, los coeficientes de similitud de los dos arrays que se cogeran será el que corresponda a la mediana para evitar coger valores muy altos o muy bajos que podrían ser provocados por los falsos positivos. Cálculo coeficiente Después del cálculo de la mediana de ambos vectores se tiene ya la similitud con el modelo bueno y el modelo de los asmáticos que van a ser utilizadas para definir el estado del usuario. Para ello se comprueba cual de los dos coeficientes está más cerca del 0; una vez se sabe cual de los dos es el mayor se dividen el que tenga mayor valor absoluto entre el menor. El coeficiente que esté más próximo a 0 será el que se indicará como estado del usuario (verde si se acerca más al modelo bueno y rojo si se acerca más al estado con problemas 59

92 respiratorios) salvo que al realizar el cociente del que se habla en el párrafo anterior éste no supere el 1.05 lo que hará que se decante como estado normal (naranja) entre el bueno y el asmático, se puede observar el código en el Listado 5.7. float sano = result. get (0) ; float malof = result. get (1) ; float coeff ; if(sano > malof ){ coeff = Math. abs ( malof )/ Math. abs ( sano ); if(coeff >1.05) { rojo. setimagedrawable ( getresources (). getdrawable ( R. drawable. verde )); } else { rojo. setimagedrawable ( getresources (). getdrawable ( R. drawable. ambar )); } } else { coeff = Math. abs ( sano )/ Math. abs ( malof ); if(coeff >1.05) { rojo. setimagedrawable ( getresources (). getdrawable ( R. drawable. rojo )); } else { rojo. setimagedrawable ( getresources (). getdrawable ( R. drawable. ambar )); } } Listado 5.7: Determinar el estado de obstrucción del paciente Módulo V: Diseño e implementación de la aplicación móvil En el quinto y último módulo es donde se lleva a cabo la integración de los dos algoritmos, con la captura de audio correspondiente al primer módulo y la representación de los resultados de una forma clara al usuario. Todo ello en una única aplicación Android. Se divide en cuatro partes: 1. Intrucciones: en la que se explica al usuario el procedimiento a seguir y como realizar la grabación. 2. Grabación del wav: en la que se lleva a cabo la grabación por parte del usuario. 3. Resultados detección de eventos respiratorios: tras analizar la muestra se muestran los eventos respiratorios detectados. 4. Resultados estado respiratorio: un termometro muestra su estado respiratorio con 3 estados posibles. 60

93 Instrucciones Es el primer Activity (Figura 5.14) que aparece al iniciar la aplicación, aquí se explica como se tiene que realizar la grabación tanto a nivel de que botones pulsar como la forma en que debe colocarse el teléfono. Al estar enfocado el trabajo a un futuro en el que esta detección se haga en segundo plano mientras tiene lugar una llamada, la posición correcta con la que grabarse es con el teléfono en la oreja al igual que si se estuviera manteniendo una conversación telefónica. Figura 5.14: Activity inicial de la aplicación e instrucciones de uso Grabación del wav Para la grabación del wav se ha diseñado una activity principal que da la bienvenida a la aplicación y solicita el ingreso de un nombre como forma de identificar los archivos que se generen a lo largo del flujo del programa con su nombre en concreto. Abajo del todo se puede observar un botón rojo para comenzar la grabación al igual que el que aparece en muchos objetos cotidianos, fácil de reconocer lo que ocurrirá en caso de pulsar dicho botón (Figura 5.15). Al pulsar el botón de grabar se inicia la grabación y una animación mediante la cual baja un micrófono desde la parte superior de la pantalla y aparece el texto de "Grabando... botón de PARAR en la parte inferior de la pantalla cuando se quiera acabar con la grabación (Figura 5.16). Cuando se pare la grabación del audio pulsando el botón PARAR, aparecerán tres nue- 2 un 61

94 Figura 5.15: Introducir nombre y comenzar grabación Figura 5.16: Aspecto de la aplicación durante la grabación vos botones en la parte inferior de la pantalla. La descripción de los nuevos botones es la siguiente: Repetir (botón izquierdo): este botón se puede pulsar en caso de que la grabación realizada no haya gustado al usuario, sea cual sea el motivo. Devolvería el flujo del programa al activity principal donde se introduce el nombre pero ya aparecería el nombre introducido con anterioridad en caso de que el usuario desee el mismo no deba volver a escribirlo. El archivo de audio que se creará en la segunda vez si mantiene el mismo nombre sobrescribirá el anterior audio generado. Reproducir (botón central): para que el usuario pueda comprobar que se ha grabado correctamente la muestra puede pulsar este botón y podrá escucharlo ademaś de ver con un puntero azul en pantalla como transcurre y el segundo en el que se encuentra escuchando (Figura 5.18). Continuar (botón derecho): si el usuario está conforme con la muestra que ha grabado pulsaría este botón para que se inicie el algoritmo de detección de respiraciones que se explica en la siguiente subsección. Resultados detección respiraciones Si se ha pulsado el botón de CONTINUAR una vez realizada la grabación, comenzará el proceso de ejecución del primer algoritmo el cual devolverá los diferentes eventos respiratorios que haya capturado. Para mostrarlos al usuario se ha optado por una tabla donde se 62

95 Figura 5.17: Aspecto de la aplicación tras finalizar la grabación Figura 5.18: Puntero azul y muestra del segundo que se esta reproduciendo asigna un ID a cada evento así como el segundo en que se inicia el evento y el final del mismo (Figura 5.22). Se conserva el reproductor en esta activity para que el usuario pueda comprobar que los segundos que aparezcan en la tabla corresponden o no a eventos respiratorios. Además de mostrar la tabla muestra un botón el cual debe ser pulsado para comprobar el estado en el que se encuentra el usuario que llamará al segundo algoritmo. Mientras el smartphone esta procesando los datos en busca de esos eventos respiratorios ofrece al usuario un feedback en forma de barra (spinner) que va acercandose al 100 % a medida que se va acabando la ejecución del algoritmo para que el usuario sepa en todo momento que la aplicación esta ejecutandose (Figura 5.21). Resultado estado respiratorio Por último en este Activity será donde se mostrará al usuario su estado respiratorio con tres indicadores: bueno, normal o con dificultad respiratoria. Aquí es donde se ejecuta el segundo algoritmo y se muestra el resultado que este arroje. De igual forma que en la detección de respiraciones mientras el smartphone procesa y analiza los datos que recibe muestra un spinner que va rellenandose a medida que comprueba cada uno de los eventos respiratorios. 63

96 Figura 5.19: Spinner que aparece durante el procesamiento Figura 5.20: Esta activiy muestra los eventos respiratorios detectados Figura 5.21: Spinner que aparece mientras se ejecuta el algoritmo Figura 5.22: Activity final en la que se muestra el estado del paciente 5.4 Diagramas UML En esta última sección del capítulo se muestran algunos de los diagramas UMLs utilizados en el desarrollo del proyecto tanto a la hora de implementar como para saber que requisitos 64

97 Figura 5.23: Diagrama de casos de uso SiMoA se están pidiendo y la secuencia que sigue el intercambio de información entre las diferentes entidades o clases Diagrama de casos de uso El diagrama de casos de uso desde el punto de vista del usuario en este proyecto es muy sencillo, dado que el caso de uso global es que el usuario se graba hablando con la aplicación y automáticamente después la aplicación le muestra en que instantes del tiempo se han producido sus respiraciones y determina su estado respiratorio. Se ha desglosado en algunos casos de uso más para que sea más sencillo de comprender (Figura 5.25) Diagrama de clases En este apartado además de mostrar el diagrama de clases resultante se va a explicar el propósito de cada una de las clases que lo forman por si durante la explicación de los módulos no ha quedado suficientemente claro. En primer lugar de desglosa el diagrama de clases correspondiente a la funcionalidad del primer algoritmo encargado de la demarcación de eventos respiratorios. Frame: centro de todo en este proyecto, cada una de las señales con la que se trabaja antes de nada se divide en objetos de la clase Frame, ya sean superframes o subframes. BreathTrainingSet: es la clase que se encarga de crear el conjunto de entrenamiento en base a los archivos tipo wav que recibe para formar la plantilla con la que luego se compararán los audios. Cepstrogram: cada uno de los superframes cuenta con un cepstrograma que es una matriz en la que cada una de sus columnas es el vector de características de cada uno de los subframes que lo componen. 65

98 Figura 5.24: Diagrama de clases algoritmo detección de eventos respiratorios SimilarityCoefficients: esta clase se encarga de calcular el coeficiente Cp en base a un cepstrograma de la señal de entrada que recibe y los cepstrogramas del conjunto de entrenamiento o plantilla. BreathDemarcation: en esta clase se lleva a cabo todos los procedimientos tanto del filtrado primero como del segundo, y ya por último deliminar las respiraciones de la que será la última clase, BreathEvent. BreathEvent: estos objetos están formados por un atributo y otro de fin de cada sección candidata, una sección candidata o precandidata es una sección de objetos Frames cuyos atributos breathframes es uno y están de forma consecutiva. En la segunda parte del trabajo que implica la determinación del estado respiratorio del usuario, se concentra en una única clase donde se obtiene el coeficiente de similitud (likelyhood) de los coeficientes MFCC de cada uno de los eventos respiratorios con respecto a los modelos GMM generados tanto de sanos como con algún tipo de patología. Esta clase SimilarityModels en donde se hace la llamada a la librería de Weka para Android que permite hacer los cálculos necesarios para obtener el coeficiente de similitud mencionado anteriormente. Son necesarios los archivos ARFF (extensión propia de Weka) para pasarselos a dicha librería, los cuales han sido creado una vez se determinaron los eventos respiratorios de la entrada de voz dentro del primer Activity Diagramas de secuencia Los únicos diagramas de frecuencia que se van a incluir en la memoria van a ser los de los procedimientos más característicos del proyecto como son el de aplicación de filtros (Figura 66

99 Figura 5.25: Diagrama de clases algoritmo determinación del estado respiratorio Figura 5.26: Diagrama de secuencia aplicación filtro ) y el paso de la voz del usuario a un array de floats (Figura 5.27). 67

100 Figura 5.27: Diagrama de secuencia wav-array float 68

101 Capítulo 6 Resultados EN este capítulo se muestran los resultados obtenidos tras el desarrollo de la herramienta tanto en la detección de eventos respiratorios como en la evaluación del estado respiratorio a partir de éstos. Además se muestra el aspecto final de la aplicación Android con una serie de capturas de pantalla. 6.1 Detección de respiraciones En esta sección se muestra una tabla 6.1 con los resultados correspondientes a la detección de eventos respiratorios dentro del habla continua, lo cuál es la función principal de la herramienta implementada. Dentro de la tabla, se incluye el nombre del archivo de audio generado, el número de respiraciones existentes, las respiraciones que ha detectado la herramienta correctamente, las que sólo ha detectado parcialmente y las que han sido detecciones falsas o falsos positivos. Además de la tabla, se incluye un gráfico en el que se aprecian los resultados tras tomar muestras de grabaciones con un total de 10 personas tanto sanas como con problemas respiratorios que se elevan a 23 muestras ya que algunos hicieron varias grabaciones. Se puede comprobar que los resultados de este primer algoritmo son bastante satisfactorios con la mayoría de aciertos entre el 75 y el 100 % (Figura 6.1). Figura 6.1: Porcentaje de aciertos en la detección de respiraciones 69

102 Nombre audio Detecciones totales Correctas Erroneas Masculino_c_ Masculino_c1_ Masculino_c2_ Masculino_c3_ Masculino_c4_ Masculino_c5_ Masculino_c6_ Masculino_c7_ Masculino_eh1_ Masculino_eh2_ Masculino_ep1_ Masculino_ep2_ Masculino_i1_ Masculino_i2_ Masculino_o1_ Masculino_o2_ Masculino_j Masculino_iv Masculino_iv Masculino_iv Masculino_iv Masculino_p Masculino_ceci Cuadro 6.1: Resultados arrojados por el primer algoritmo Por otra parte se muestra el resultado de aplicar este primer algoritmo al audio pepe.wav en el que se detectan con total exactitud las dos respiraciones que se producen (Figura 6.2). Se pueden apreciar dos segmentos del audio sombreados con los segundos exactos de inicio y fin del evento respiratorio. Tras pasar este audio como test por el algoritmo de detección de respiraciones los resultados obtenidos son los que se muestran en la Figura 5.22 del capítulo anterior que coinciden con la representación gráfica de la locución. Los fragmentos que muestran una amplitud mayor corresponden a la voz del usuario y los que tienen una amplitud menor a las respiraciones (segmentos sombreados) corresponden a silencios o a la pulsación de los botones de la aplicación, como lo pueden ser el primer y el último segundo. 6.2 Determinación estado respiratorio Para la realización de pruebas acerca del estado respiratorio se comprobó previamente que el algoritmo empleado por Weka para crear dos modelos de distribucioens de mezclas gaussianas (GMM) que representen, por un lado, un estado respiratorio saludable y, por otro, un 70

103 Figura 6.2: Respiraciones detectadas en pepe.wav estado con presencia de obstrucción respiratoria u otros problemas respiratorios derivados; clasificaba de forma correcta tanto a sanos como asmáticos cada uno en su correspondiente grupo. Las primeras pruebas que se realizaron sobre este algoritmo tuvieron lugar en un pc de sobremesa ejecutando código Java para comprobar que los resultados que se obtenian eran coherentes y ya migrarla a la aplicación móvil. Una vez se obtuvo la relación entre los modelos y las muestras de los diferentes usuarios se implementó en la aplicación móvil y comenzaron las pruebas finales. Estas pruebas finales fueron realizadas sobre cinco voluntarios con una particularidad, la primera toma se hizo en total reposo y la siguiente tras haber elevado el número de pulsaciones por minuto (ppm) del corazón lo cual provoca un estado pulmonar más agitado que el inicial. Antes de realizar la primera prueba se procedió a determinar los valores pulmonares de los usuarios gracias a un espirometro convencional para corroborar su estado respiratorio. Lo que se quiere comprobar es el comportamiento de la aplicación de estimación del estado respiratorio sometiendo al usuario a cierta actividad física que altere su estado cardio respiratorio y contrastarlo con los resultados, en forma de índice obtenidos por la aplicación y su clasificación como: estado respiratorio bueno, normal o con dificultades. A continuación se muestran los resultados obtenidos dividiendo a los voluntarios en asmáticos crónicos, estacionales y sin ningún tipo de desorden respiratorio tanto en un Cuadro 6.2, como detalladamente Usuarios que presentan asma crónica Esta prueba se realizó sobre dos pacientes con un cuadro clínico de asma crónica y se les sometió a la misma prueba: Grabación de voz continua en reposo Grabación de voz continua tras subir y bajar unas escaleras 71

104 Usuario Estado en reposo Estado tras esfuerzo físico Crónico_1 Dificultad respiratoria Dificultad respiratoria Crónico_2 Dificultad respiratoria Dificultad respiratoria Estacional_1 Bueno Dificultad respiratoria Sano_1 Bueno Dificultad respiratoria Sano_2 Bueno Normal Sano_3 Bueno Dificultad respiratoria Cuadro 6.2: Pruebas finales determinación estado respiratorio Los resultados arrojados por ambas pruebas para los dos pacientes fueron los mismos, el algoritmo de determinación del estado respiratorio los clasificó a los dos como personas con dificultad respiratoria Usuarios que presentan asma estacional En este grupo de usuarios sólo se contó con un voluntario, se le realizó una prueba anterior a su entrenamiento habitual de futbol sala y los valores obtenidos en la aplicación lo determinaban como un estado respiratorio normal (naranja). Una vez concluyó su entrenamiento se le volvió a pedir una muestra de audio para determinar su nuevo estado respiratorio y la aplicación lo clasificó como persona con dificultad respiratoria debido al aumento de su actividad pulmonar a lo largo del entrenamiento Usuarios que no presentan asma Por último en usuarios sin ningún tipo de enfermedad pulmonar apararente se contó con tres voluntarios que se sometieron a dos pruebas, en una se repetía la de subir y bajar escaleras después de hacer la primera prueba y en otra se compararon muestras de un día normal con una muestra obtenida tras una sesión de running durante media hora a ritmos altos. Tras realizar la primera toma de los tres voluntarios, en reposo, el algoritmo clasificó su estado respiratorio como bueno (verde) pero tras el esfuerzo físico tanto de las escaleras como después de correr clasificó a dos dentro del estado con cierta dificultad respiratoria (rojo) y a uno como un estado respiratorio normal (un leve empeoramiento de su estado tras la actividad). 72

105 Capítulo 7 Conclusiones y propuestas EN este capítulo se exponen las conclusiones acerca de los objetivos iniciales que se han podido conseguir con el desarrollo de este proyecto y además se aportan unas ligeras ideas de cómo se podría mejorar en ciertos aspectos. 7.1 Limitaciones encontradas A lo largo del desarrollo de este TFG se han encontrado varias limitaciones pero principalmente dos que serán desarrolladas en la siguiente enumeración: 1. Grabación ios/android: respecto al tema de la grabación los problemas se fueron encontrando desde el inicio del módulo IIb cuando se tenía la intención de detectar los eventos respiratorios. Como se ha indicado en el apartado donde se describen todos los elementos hardware a emplear aparece tanto un móvil Android como un móvil ios, se detectó que la diferencia entre los audios eran muy grande entre unos y otros. Los grabados con el iphone tenían una amplitud mucho más grande que los de Android lo que facilitaba al algoritmo detectar entre eventos respiratorios y voz, a diferencia de Android donde se mezclaban los silencios con los eventos respiratorios. Tras mucho investigar se encontró la solución al poder ampliar la señal multiplicando la matriz de floats por una constante que ampliaba 13 db la muestra porque en un principio sólo se podía amplificar la señal llevando al software de edición de audios Audacity y ya ahí ampliarla y después devolverla al algoritmo. Para que se vea más graficamente, se adjuntan dos imágenes una del aspecto de una grabación realizada con el iphone y otra grabación realizada con el Nexus 4. Figura 7.1: Ejemplo grabación iphone 4S 73

106 Figura 7.2: Ejemplo grabación Nexus 4 2. Voz mujeres/hombres: los primeros conjuntos de entrenamiento que se tomaron correspondian solamente a hombres porque no se pensaba que existiera una diferencia tan grande entre la respiración de un hombre y la de una mujer. Después de hacer muchas pruebas con audios de hombres se decidió meterle al primer algoritmo la muestra de una mujer, resultando que no reconoció ninguna de sus respiraciones. Ahí se tomó la determinación de que podría ser una característica a mejorar en futuras versiones de la aplicación cuando se tenga la posibilidad de tomar muestras a mujeres asmáticas para extender a éstas el algoritmo. 7.2 Objetivos alcanzados DET-01 Este objetivo se ha conseguido puesto se han estudiado múltiples casos similares al que se ha desarrollado, principalmente este desarrollo se ha basado en el estudio de los cantantes [RL07]. DET-02 Este objetivo ha sido cubierto tras realizar varias grabaciones y seleccionar los mejores eventos respiratorios de cada una como bien se explica detalladamente en el Anexo Elección conjunto de entrenamiento y cálculo Bm/2. DET-03 La obtención de un vector de características de cualquier muestra de audio, en este caso sólo centrado en el conjunto de entrenamiento y de la muestra de entrada al algoritmo ha sido cubierto con el desarrollo del módulo IIb. DET-04 Tras conseguir el subobjetivo anterior (vector de características de cada subframe) ya se podía implementar el módulo necesario para que este subobjetivo fuera cubierto, el módulo con todas las funcionalidades necesarias para ello es el módulo III. Este módulo ha sido el más laborioso del desarrollo ya que conlleva tanto el cálculo de coeficientes como desarrollo de dos filtros para el procesamiento adecuado de la señal y obtener los mejores resultados posibles. 74

107 CLA-01 En cuanto al estudio de trabajos previos de diferenciación entre muestras sanas y con algún tipo de obstrucción se ha conseguido con dos de los artículos incluídos en el capítulo de Antecedentes [Rac] y [BP04]. CLA-02 Relacionado con el objetivo CLA-01 se ha conseguido éste, puesto que los dos artículos a los que se hacer referencia emplean los coeficientes MFCC como diferenciación entre muestras. Además de contar ya con la implementación de cómo obtener estos coeficientes en el desarrollo del primer algoritmo (Detección de eventos respiratorios). CLA-03 Con el objetivo de diferenciar los coeficientes MFCC de sanos y asmáticos, se ha elegido un algoritmo de inteligencia artificial denominado EM que indica mediante un coeficiente, la similitud que existe entre un conjunto de entrenamiento y la muestra que recibe como entrada. CLA-04 Al necesitar el algoritmo elegido en el punto anterior dos conjuntos de entrenamiento para crear los dos modelos necesarios se ha llevado a cabo una toma de muestras tanto de personas asmáticas como de personas sin ningún tipo de desorden respiratorio, como se muestra en el Anexo Recogida muestras comparativas: smartphone - espirómetro. AND-01 La recogida de muestras de audio se ha recogido en formato wav ya que este no utiliza compresión para guardar los datos, por lo tanto no conlleva ninguna perdida de calidad al almacenarse. De esta forma luego el estudio es mucho más preciso que si se tratara de un formato comprimido. En un principio se empleó una resolución de muestras por segundo peros los datos a analizar eran muy grandes a la hora de ejecutar el algoritmo por lo que se decidió bajarlo a 8000 muestras/segundo. Como se ha explicado en el capítulo 5 para poder recoger las muestras en un smartphone Android y en el formato wav se ha empleado la clase AudioRecord de Android. AND-02 El desarrollo de la aplicación Android ha sido el objetivo más fácil de llevar a cabo, su totalidad se ha conseguido con el desarrollo del último de los módulos, módulo V, en el que se integran todos los módulos anteriores y se les dota de una interfaz gráfica fácil de manejar. 75

108 7.3 Propuestas de trabajo futuro Una vez se ha llegado a este punto siempre se quedan cosas en el tintero que habría gustado de implementar, cambiar ciertos aspectos o como no mejorar la herramienta generada. En los siguientes puntos se mostrarán algunas de las que se piensa son buenas mejoras para la éste trabajo. Vulnerabilidad al ruido externo Por el momento el algoritmo sólo es capaz de detectar los eventos respiratorios en entornos lo más silenciosos posibles, que el ruido sea el mínimo. Esta mejora afectaría directamente al cálculo del vector de características MFCC que sería reforzado de manera que consiguiera detectar estos eventos respiratorios en entornos más ruidosos. Comunicación directa con el especialista La aplicación que se ha desarrollado es una aplicación local sin ningún tipo de conexión con nada, el paciente graba su voz y obtiene un valor que le indica su estado con respecto a un valor pulmonar. A esto se le podía dar muchísimo más potencial con el desarrollo de una herramienta web que se instalaría en el equipo del especialista (neumólogo o alergólogo) y cada vez que se tomara una muestra en la aplicación Android se subiría a un servidor con el que conectaría la herramienta web y el especialista llevara el seguimiento de sus pacientes. Otros tipos de avances podrían ser la generación de gráficas con respecto a las muestras tomadas para que el especialista examinara los datos de una forma más rápida y sencilla que si sólo viera valores numéricos. Integración con llamadas en segundo plano Otra mejora interesante sería el hecho de no ser una aplicación independiente, sino integrarse con la aplicación de llamadas y grabar mientras el usuario atiende sus llamadas telefónicas. De esta manera sería una monitorización más continua, y se reduce al mínimo la interacción del usuario con la aplicación, sin tener que explícitamente coger el teléfono y dirigirse de manera voluntaria a la aplicación para obtener su valor pulmonar en ese instante. Extensión a otras plataformas Esta aplicación donde reside todo su valor es en el algoritmo que emplea para desde una señal de audio en formato wav es capaz de detectar los eventos respiratorios y además con la duración y energía de estos puede aproximar un valor pulmonar. Por tanto la exportación a otras plataformas como puede ser web, ios, Firefox OS o cualquier otro sistema operativo móvil no llevaría consigo grandes problemas. Sólo habría que encontrar la manera de grabar sonido en cada una de estas plataformas y después pasarlo a un arreglo de números en coma 76

109 flotante con signo y el algoritmo haría el resto. Historial de las tomas por paciente La aplicación resultante tan sólo muestra el estado una vez se toma la muestra pero no realiza ningún tipo de registro de sus estados para mantenerlo en el teléfono, el usuario realiza la prueba y se muestra su estado que el puede registrar en papel o en algún sitio para tener constancia de su evolución. Una de las mejoras que se podrían incluir en la aplicación sería que sólo pudiera ser utilizada por un usuario (o contar con perfiles) e ir creando estadísticas y gráficas en función de los diferentes resultados que obtenga al hacerse la prueba. Inclusión de la monitorización de otros sensores Una mejora interesante sería la monitorización de otros sensores del teléfono como pueden ser el acelerómetro o el giróscopo, con los cuales se puede detectar la actividad que realiza el usuario previamente a la toma de la muestra. En otras palabras, se puede detectar si el usuario justo antes de hacer la prueba ha estado corriendo, andando, subiendo escaleras o estático, lo cual puede influir mucho en el resultado. Porque una persona sin aparentemente ningún sintoma de enfermedades respiratorias puede hacerse la pruebas después de subir varios pisos por las escaleras y encontrarse fatigado, clasificandolo la aplicación como con un importante grado de obstrucción respiratoria que nada tiene que ver con su estado habitual. Inclusión de conjunto de entrenamiento mixto Debido a la falta de voluntarias femeninas durante la fase final del proyecto no ha sido posible la recolección de muestras de respiraciones de mujeres para entrenar tanto al primer algoritmo de template matching como para crear un modelo en el segundo algoritmo correspondiente a mujeres asmáticas y otro modelo correspondiente a mujeres sanas. Como mejora futura se podrían buscar dichas voluntarias y ampliar el abanico de personas monitorizables por este sistema. Ampliación de la granularidad estados respiratorios Como última mejora se propone incluir nuevos estados respiratorios a la salida para dotar al sistema de mayor granularidad a la hora de obtener los resultados, sin limitarse sólo a tres como actualmente. 7.4 Publicaciones Como resultado de este proyecto y las líneas de investigación llevadas a cabo por el laboratorio MAmI de la Escuela Superior de Informática de Ciudad Real, se ha elaborado un artículo de investigación titulado Towards a non-intrusive self-management system for Asthma Control using smartphones. Este artículo ha sido aceptado para su publicación y presentación en el congreso UCAmI 2014 celebrado en Belfast. 77

110 7.5 Conclusión personal Con el desarrollo de este TFG he realizado mi primer trabajo de una envergadura mayor a los que vengo realizando a lo largo de la carrera, además de ser mayor lo tiene que acotar uno mismo y fijarse los hitos para ir completando todas y cada una de las partes que éste se compone. Este tipo de trabajos se salen de la normalidad dentro de la titulación, ya que normalmente las prácticas de cada una de las asignaturas se centran sólo en aspectos de dicha asignatura. En cambio este tipo de desarrollos integra muchos de los campos que se han tratado de manera independiente durante la carrera. En este caso he utilizado conocimientos de Álgebra para el manejo de matrices, Estadística para el cálculo de los descriptores que comentaba anteriormente y RStudio, de Ingeniería del Software a la hora de utilizar una metodología de trabajo, de Física el hecho de manejar una señal de audio y trabajar con frecuencias, y por supuesto la programación a todos los niveles para acabar teniendo como resultado esta aplicación. Por otra parte al tratarse de un trabajo que ha requerido bastante investigación me ha gustado bastante, nunca me había planteado dedicarme a la investigación pero el hecho de coger varios artículos y con ellos crear algo totalmente nuevo cogiendo cosas de unos y otros me ha resultado bastante atractivo. Si a eso le sumas que el resultado del trabajo va a ayudar a personas con un problema como es el asma es muy gratificante. Cuando estuve haciendo las pruebas, puerta por puerta, la gente más joven se sorprendía de que se pudiera llegar a tener algo como un espirómetro en el teléfono móvil y querían tenerla cuanto antes instalada. La gente mas mayor por su parte les parecía como si les hablaras en un idioma totalmente distinto pero también querían tener esa facilidad en el teléfono de sus hijos o nietos, y no necesitar desplazarse al hospital para hacerse estas pruebas. 78

111 Referencias [AF14] A. Abushakra y M. Faezipour. A Novel Lung Capacity Model to Virtually Aid in Breath Regulation. International Journal of High Speed Electronics and Systems, 23(01n02): , url: doi/abs/ /s [And] [aud] Android. Android website. url: Audacity website. url: [BP04] M. Bahoura y C. Pelletier. Respiratory sounds classification using cepstral analysis and Gaussian mixture models. En Engineering in Medicine and Biology Society, IEMBS th Annual International Conference of the IEEE, volume 1, páginas 9 12, Sept [BP09] B.Holz y P.Whitten. Managing Asthma with Mobile Phones: A Feasibility Study. Nov [Bra14] [BW] J. Bravo. m-health: Mobile Computing and Health Monitoring. J. of Computation in Biosciences and Engineering, P. Boersma y D. Weenink. Praat: doing phonetics by computer. url: [com] comscore. Spain Digital Future in Focus url: Spain-Digital-Future-in-Focus.pdf. [GBGG05] J. Gosling, B.Joy, G.Steele, y G.Bracha. Java(TM) Language Specification, The (3rd Edition) (Java (Addison-Wesley)). Addison-Wesley Professional, [gim] Gimp website. url: [GMA + 12] D. Gustafson, M.Wise, A.Bhattacharya, A. Pulvermacher, K.Shanovich, B.Phillips, E.Lehman, V.Chinchilli, R.Hawkins, y JS. Kim. The Effects of Combining Web-Based ehealth With Telephone Nurse Case Management for Pediatric Asthma Control: A Randomized Controlled Trial. J Med Internet Res, 14(4):e101, Jul url: 79

112 [GPNS11] [Gun] S. Gupta, P.Chang, N.Anyigbo, y A. Sabharwal. mobilespiro: portable openinterface spirometry for Android. En Irwin Mark Jacobs, Patrick Soon- Shiong, Eric Topol, y Christofer Toumazou, editors, Wireless Health, página 24. ACM, url: GuptaCAS11. D. Gunning. Medicamentos para el asma. url: upload/docs/factsheets/spanish/pulmonary asthma.pdf. [JC08] G. Hernández JR. Calvo, R. Fernández. Métodos de extracción, selección y clasificación de rasgos acústicos para el reconocimiento del locutor. Ciudad de La Habana, Cuba, [JZZ09] [kil] J. Yu J. Zhang, W. Ser y T.T. Zhang. A Novel Wheeze Detection Method for Wearable Monitoring Systems. Intelligent Ubiquitous Computing and Education, International Symposium on, 0: , Kile website. url: [LGB + 12] E. Larson, M. Goel, G. Boriello, S.Heltshe, M.Rosenfeld, y S.N.Patel. SpiroSmart: Using a Microphone to Measure Lung Function on a Mobile Phone. En Proceedings of the 2012 ACM Conference on Ubiquitous Computing, UbiComp 12, páginas , New York, NY, USA, ACM. url: [lib] LibreOffice website. url: impress/. [PL03] J. Hilario E.A. Sánchez P. Letelier, M.C. Penadés. Metodologías Ágiles en el desarrollo de Software. VIII Jornadas de Ingeniería de Software y Bases de Datos, JISBD, url: f /actas.pdf. [Rac] [RBH93] Vikas Rachna, D. Singh. Feature Extraction From Asthma Patient s Voice Using Mel-Frequency Cepstral Coefficients. IJRET: International Journal of Research in Engineering and Technology. L. Rabiner y J. Biing-Hwang. Fundamentals of Speech Recognition. Prentice- Hall, Inc., Upper Saddle River, NJ, USA, [RL07] D. Ruinskiy y Y. Lavner. An Effective Algorithm for Automatic Detection and Exact Demarcation of Breath Sounds in Speech and Song Signals. Audio, Speech, and Language Processing, IEEE Transactions on, 15(3): , March

113 [RQD00] [rst] [sdk] DA. Reynolds, TF. Quatieri, y RB. Dunn. Speaker verification using Adapted Gaussian mixture models. En Digital Signal Processing, página 2000, RStudio website. url: Android SDK. url: [stu] Android Studio. url: studio.html. [tre] [WHOa] Trello website. url: WHO. Asthma. url: [WHOb] WHO. Scope: asthma. url: scope/en/. 81

114

115 ANEXOS 83

116

117 Recogida muestras comparativas: smartphone - espirómetro.1 Recogida correspondiente al trabajo en el módulo IIa En un principio la idea que se tenía era de recoger muestras tanto con la aplicación resultante del Módulo IIa como con el espirómetro convencional y con estas entradas alimentar un algoritmo que empleara lógica difusa para encontrar la similitud entre ambas señales. Como se necesitaba gran cantidad de muestras para que los resultados fueran lo más fiables posibles, en un principio se intentó realizar dicho proceso en el entorno de un hospital y contando con la colaboración de los neumólogos para facilitar la comprensión de los datos obtenidos. No se pudo llevar a cabo ya que ningún especialista mostró interés y la necesidad de pasar por el comité de ética del hospital se alargarían demasiado los plazos del proyecto. Por lo tanto esta recogida de información se hizo por cuenta propia,se buscaron personas con trastornos respiratorios o alergias que alteraran el funcionamiento respiratorio y a éstas se les realizaron las pruebas. Antes de nada a todas las personas de las cuales se tomaron muestras se les hacía entrega de una autorización que nos permitía recabar algunos de sus datos (Figura 3) y nos daban su consentimiento (Figura 4). Sobre los aspectos legales todos los datos relativos a una persona que sean obtenidos o distribuidos están sujetos a la Ley Orgánica de Protección de Datos (LOPD) y el Real Decreto 1720/2007 que se debe cumplir para garantizar el derecho a la protección de datos de carácter personal en territorio español. La LOPD distingue entre información que identifica o hace identificable a una persona e información que no identifica, en este caso la única información con la que se trabaja es un ID que no tiene información personal que sólo permite diferenciar a unas de otras, la edad de la persona, altura, peso, si es asmático, alérgico o fumador y su sexo. Son datos con los que no se es capaz de identificar a dicha persona. Se puede apreciar en la tabla que también se han tomado muestras a algunos menores, pero todo ello tras sus padres dar el consentimiento y firmar la autorización que es citada anteriormente. Por último un apéndice en la LOPD indica que la información recabada sobre los españoles debe residir en territorio español, para en cualquier momento que se solicite esa información 85

118 Figura 3: Datos aportados por los sujetos saber donde se encuentra. En este caso la información reside en el ordenador del autor del presente documento..2 Recogida correspondiente al trabajo en el módulo IV Con el objetivo de probar el algoritmo desarrollado en los módulos IIb y III así como la usabilidad de la aplicación Android inicial en la que sólo se recogían audios se vuelve a hacer otra recogida de muestras. En este caso los asmáticos estacionales con relación a alergías primaverales (como puede ser el polen, gramineas, etc) ya no serían de utilidad al realizarse las pruebas en el mes de Octubre, sólo se ha centrado en enfermos crónicos de asma. En esta ocasión se ofrecieron como voluntarios cuatro hombres y dos mujeres, la mecánica que se siguió en esta recogida fue realizar dos pruebas: una prueba totalmente en 86

119 reposo y otra después de hacer algún tipo de actividad aunque sólo fuera andar unos metros o subir y bajar unas escaleras. Las muestras obtenidas serán empleadas en el módulo IV para caracterizar el modelo que será la referencia para comparar las muestras entrantes y a más similitud con éste más tiende a tener algún tipo de obstrucción respiratoria el paciente. 87

120 INFORMACIÓN AL PACIENTE Y CONSENTIMIENTO INFORMADO DEL ESTUDIO: Título del estudio: Aplicaciones espirométricas en plataforma Android. Yo, (nombre y apellidos del paciente) Presto libremente mi conformidad para participar en el estudio. He podido hacer preguntas sobre el estudio y he recibido suficiente información. Comprendo que mi participación es voluntaria. Comprendo que puedo retirarme del estudio: 1. Cuando quiera. 2. Sin tener que dar explicaciones. 3. Sin que esto repercuta en mis cuidados. Fecha:... Firma del participante Fecha:... Firma del investigador Tal como se establece en el Real Decreto 1720/2007 y la Ley Orgánica de Protección de Datos de Carácter Personal 15/1999, el consentimiento para el tratamiento de sus datos personales y para su cesión es revocable. Vd. puede ejercer el derecho de acceso, rectificación y cancelación dirigiéndose al investigador, el cual lo pondrá en conocimiento del promotor. Figura 4: Autorización empleada para obtener el consentimiento de las personas que han colaborado 88

121 Distribución de la carga de trabajo del proyecto En este anexo se relata y se muestra con esquemas como ha sido el desarrollo de SiMoA y la justificación del tiempo empleado. Inicialmente alrededor de Octubre de 2013 comenzó todo contactando con el director del proyecto y la gente del grupo de investigación MAmI, así como la búsqueda de información tanto acerca de la espirometría individualmente como acerca de la existencia de algunos espirómetros en las diferentes plataformas móviles. No se inició el anteproyecto de manera concurrente al proyecto ya que había que ir avanzando un poco en el campo para ver si las ideas iniciales eran viables con los recursos existentes. La primera idea fue crear un espirómetro sobre la plataforma Android que obtuviera los datos pertinentes mediante la espirometría forzada del mismo. En la totalidad del mes de octubre se centro en el aprendizaje de como funciona Android y unas pinceladas de como se programan las aplicaciones, completando la totalidad del Módulo I: Captura señal de audio para finales del mismo mes. El Módulo IIa: Espirometría forzada se alargó durante los meses de noviembre, diciembre y enero, debido a la falta de idea y experiencia con el manejo de señales acústicas, y también a los exámenes y trabajos relativos al final del primer cuatrimestre con varias asignaturas de 3 o y 4 o curso. Este módulo IIa constituyó la entrega final de una de dichas asignaturas, siendo necesario algún refinamiento de él tras las correcciones del profesor de la asignatura. Las correcciones del módulo se llevaron a cabo durante los meses de febrero y marzo haciendo multitud de pruebas que probaran el buen funcionamiento del módulo. Tras hacer el refinamiento del módulo y la aplicación, tuvo lugar la recogida de muestras por parte de varias personas que se ofrecieron voluntarias como bien se explica en el Anexo 7.5. Esta recogida de muestras inicialmente iba a ser llevada a cabo dentro de un hospital con casos reales de asmáticos y empleando un espirómetro profesional, pero no se pudo llevar a cabo. Esto dio lugar a la adquisición de un espirómetro portatil y se realizó la recogida de muestras entre gente conocida del autor del documento con reconocidos transtornos respiratorios. Después de hacer toda la recogida de muestras tuvo lugar un punto de inflexión donde el proyecto cambia de rumbo dejando la espirometría forzada a un lado y centrándose en la detección de los valores respiratorios en el habla. Durante el mes de abril se vuelve a estudiar la situación y las posibilidades existentes, resultando como conclusión la creación de una aplicación que consiga grabaciones de múltiples personas para después estudiar di- 89

122 chas grabaciones y de ahí deducir los valores espirométricos. Parte del mes de abril y mayo consistieron en la implementación de dicha aplicación y además una aplicación web desarrollada en PHP para alojar los resultados. La aplicación fue publicada en el Google Play pero la inmensa mayoría de los usuarios no hicieron un uso correcto teniendo que dar otro nuevo enfoque. Este sería el enfoque definitivo, se detectarían los eventos respiratorios dentro de una muestra de audio. Se realiza el anteproyecto durante parte del mes de mayo siendo aprobado en el mes de junio. Se inicia así la implementación del Módulo IIb: obtención de los vectores de características de los Frames en este mes de junio que se alargaría durante prácticamente todo el mes lo que respecta a investigación, implementación y pruebas. En el mes de julio se implementó el módulo III: Similitud template-muestra que ha sido uno de los módulos que mas trabajo ha llevado ya que ha incluido cálculos estadísticos para fijar umbrales y la realización de múltiples grabaciones para probar tanto la voz como la respiración hasta que se ha dado con los resultados mas óptimos posibles para aumentar la robustez del algoritmo. Este módulo se finalizó totalmente en el mes de Agosto cuando se fijaron los valores de todos los umbrales y los resultados arrojados por este algoritmo de detección de eventos respiratorios eran los deseados. Durante las primeras semanas de septiembre se estudió como llevar a cabo la distinción entre respiración sana y respiración con algún tipo de obstrucción para durante la segunda quincena de septiembre hasta mediados de octubre en el desarrollo del Módulo IV. Por último la parte final del proyecto se desarrolló durante los meses de octubre y parte de noviembre creando la aplicación Android que integra los dos algoritmos y muestra el estado del usuario. Descripción Mes Días Horas Inicio Octubre 6 18 Módulo I Octubre Módulo IIa De Noviembre a Enero Refinamiento y recogida muestras Febrero y Marzo Asma-Alergia-Voz Abril y Mayo Anteproyecto Mayo Módulo IIb Junio Módulo III De Julio a Septiembre Módulo IV Septiembre y Octubre Módulo V Octubre y Noviembre Memoria De Junio a Noviembre - - Cuadro 1: Desglose (en meses) del desarrollo del proyecto Además de mostrar en la tabla anterior las horas en bruto que ha llevado cada una de las partes del proyecto, a continuación se muestran dos gráficas en las que se divide el tiempo 90

123 Figura 5: División del trabajo por meses Figura 6: Divisón del trabajo por módulos invertido en este proyecto tanto por meses (Figura 5) como por módulos (Figura 6). Resultando como el módulo que mas trabajo ha llevado el III debido a la multitud de cálculos y pruebas necesarias hasta que ha quedado lo suficientemente robusto. 91

124

125 Elección conjunto de entrenamiento y cálculo Bm/2 El algoritmo que se emplea para determinar si parte de una muestra, audio en este caso, se corresponde con un evento respiratorio se ha empleado un algoritmo de template matching como se viene explicando en el presente documento. Se necesita entonces una serie de muestras que sirvan para confeccionar esa plantilla o template. En este caso para obtener los mejores resultados posibles con el algoritmo y que se pueda aplicar en diferentes dispositivos se han tomado muestras tanto en un dispositivo Android (Nexus 4) como en un dispositivo ios(iphone 4s). Se han tomado muestras leyendo varias lecturas con ambos dispositivos a tres voluntarios entre los que se encuentra el autor del proyecto. Después todas esas muestras se han examinado con Audacity para recortar sólo los eventos respiratorios (Figura 7), quedando finalmente un total de 19 eventos respiratorios para garantizar unos buenos resultados. Estos 19 eventos respiratorios (Figura 8) son los que decidirán en gran medida si un subframe dentro de una muestra corresponde o no a un evento respiratorio. Dado que este conjunto de entrenamiento siempre será el mismo después de haber hecho las pruebas necesarias con los archivos.wav se ha creado un objeto serializable que contiene el objeto BreathTraining- Set al que se le han añadido todos los wav. Esto supone un importante ahorro de espacio en el proyecto puesto que los 19 archivos wav ocupan 1.3 MB y el objeto.ser KB y ahorra el construir un objeto nuevo cada vez que se ejecute el programa. A continuación se muestra el código necesario para crear el objeto serializable (Listado 1) y el código necesario para leerlo una vez se ha creado (Listado 2). BreathTrainingSet btrainingset = new BreathTrainingSet (); btrainingset. addexample ("./ breaths_set / inspiration1. wav "); btrainingset. addexample ("./ breaths_set / inspiration2. wav "); Figura 7: Selección de evento respiratorio dentro de un audio 93