SiMoA: Sistema de Monitorización del Asma - Ruidera

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
S I M OA: S ISTEMA DE
M ONITORIZACIÓN DEL A SMA
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
Cristian Carretón Ruiz
Ciudad Real – Spain
E-mail: Cristian.Carreton@alu.uclm.es
Teléfono: 684 078 215
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
TRIBUNAL:
Presidente:
Vocal:
Secretario:
FECHA DE DEFENSA:
CALIFICACIÓN:
PRESIDENTE
Fdo.:
VOCAL
SECRETARIO
Fdo.:
Fdo.:
iii
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
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
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
“En cada lucha aquel que va a muerte es el que gana ese terreno”
xi
Í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
1
1.1. Contexto del Trabajo Fin de Grado . . . . . . . . . . . . . . . . . . . . . .
1
1.1.1. Asma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1.2. Extensión del Smartphone y mHealth . . . . . . . . . . . . . . . .
4
1.2. Problema y solución propuesta . . . . . . . . . . . . . . . . . . . . . . . .
6
1.2.1. Descripción del problema . . . . . . . . . . . . . . . . . . . . . .
6
1.2.2. Descripción de la solución . . . . . . . . . . . . . . . . . . . . . .
6
1.3. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2. Objetivos
9
2.1. Hipótesis de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3. Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3.1. Relativos a la detección de eventos respiratorios . . . . . . . . . . .
9
2.3.2. Relativos a la valoración del estado respiratorio . . . . . . . . . . .
10
XIII
2.3.3. Relativos a la aplicación Android . . . . . . . . . . . . . . . . . .
10
2.4. Herramientas y medios de trabajo . . . . . . . . . . . . . . . . . . . . . .
10
2.4.1. Lenguajes de programación y sistema operativo . . . . . . . . . . .
10
2.4.2. Medios Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.4.3. Medios Software . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3. Antecedentes
19
3.1. Aproximación de los valores espirométricos . . . . . . . . . . . . . . . . .
19
3.1.1. Por medio del smartphone sin dispositivos adicionales . . . . . . .
19
3.1.2. Por medio de un hardware específico . . . . . . . . . . . . . . . .
20
3.1.3. Por medio de una aplicación de escritorio y un micrófono . . . . .
20
3.2. Reconocimiento de acciones respiratorias . . . . . . . . . . . . . . . . . .
21
3.3. Monitorización de los valores espirométricos . . . . . . . . . . . . . . . .
21
3.3.1. Concienciación a niños con asma . . . . . . . . . . . . . . . . . .
22
3.3.2. Seguimiento vía Short Message Service (SMS) . . . . . . . . . . .
23
3.4. Diferenciación entre respiraciones sanas y respiraciones con alguna patología 23
3.4.1. Extracción de características en la voz de asmáticos utilizando MFCCs 23
3.4.2. Clasificación de sonidos respiratorios utilizando análisis cepstral y
GMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4. Conceptos específicos del dominio
23
25
4.1. Algoritmo 1: detección de eventos respiratorios en habla continua . . . . .
25
4.1.1. MFCC: Mel Filter Cepstral Coefficents . . . . . . . . . . . . . . .
25
4.1.2. Construcción del template . . . . . . . . . . . . . . . . . . . . . .
28
4.1.3. Primer filtrado de la señal . . . . . . . . . . . . . . . . . . . . . .
30
4.1.4. Delimitación de eventos respiratorios . . . . . . . . . . . . . . . .
33
4.1.5. Segundo filtrado de la señal . . . . . . . . . . . . . . . . . . . . .
36
4.2. Algoritmo 2: Valoración del estado respiratorio del usuario . . . . . . . . .
37
5. Método de trabajo
41
5.1. Metodologías ágiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.2. Prototipado evolutivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.3. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.3.1. Inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.3.2. Módulo I: Captura señal de audio . . . . . . . . . . . . . . . . . .
43
5.3.3. Módulo II: Espirometría forzada y reconocimiento de eventos respiratorios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
xiv
5.3.4. Módulo IIa: Espirometría forzada . . . . . . . . . . . . . . . . . .
45
5.3.5. Módulo IIb: Obtención de los vectores de características de los Frames 48
5.3.6. Módulo III: Similitud template - muestra . . . . . . . . . . . . . .
52
5.3.7. Módulo IV: Valoración del estado respiratorio del usuario . . . . .
58
5.3.8. Módulo V: Diseño e implementación de la aplicación móvil . . . .
60
5.4. Diagramas UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
5.4.1. Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . .
65
5.4.2. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . .
65
5.4.3. Diagramas de secuencia . . . . . . . . . . . . . . . . . . . . . . .
66
6. Resultados
69
6.1. Detección de respiraciones . . . . . . . . . . . . . . . . . . . . . . . . . .
69
6.2. Determinación estado respiratorio . . . . . . . . . . . . . . . . . . . . . .
70
6.2.1. Usuarios que presentan asma crónica . . . . . . . . . . . . . . . .
71
6.2.2. Usuarios que presentan asma estacional . . . . . . . . . . . . . . .
72
6.2.3. Usuarios que no presentan asma . . . . . . . . . . . . . . . . . . .
72
7. Conclusiones y propuestas
73
7.1. Limitaciones encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
7.2. Objetivos alcanzados . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
7.3. Propuestas de trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . .
76
7.4. Publicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
7.5. Conclusión personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
Referencias
79
Recogida muestras comparativas: smartphone - espirómetro
85
.1.
Recogida correspondiente al trabajo en el módulo IIa . . . . . . . . . . . .
85
.2.
Recogida correspondiente al trabajo en el módulo IV . . . . . . . . . . . .
86
Distribución de la carga de trabajo del proyecto
89
Elección conjunto de entrenamiento y cálculo Bm/2
93
xv
Índice de cuadros
4.1. Criterios para escoger los límites del evento respiratorio . . . . . . . . . . .
36
5.1. Diferencias entre metodologías ágiles y tradicionales . . . . . . . . . . . .
42
5.2. Relación colores-frecuencias . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.3. Descriptores estadísticos Voz . . . . . . . . . . . . . . . . . . . . . . . . .
56
5.4. Descriptores estadísticos Respiración . . . . . . . . . . . . . . . . . . . . .
56
6.1. Resultados arrojados por el primer algoritmo . . . . . . . . . . . . . . . .
70
6.2. Pruebas finales determinación estado respiratorio . . . . . . . . . . . . . .
72
1.
90
Desglose (en meses) del desarrollo del proyecto . . . . . . . . . . . . . . .
XVII
Índice de figuras
1.1. Efecto que causa un ataque de asma . . . . . . . . . . . . . . . . . . . . .
2
1.2. Puntos en los que colocar el estetoscopio para realizar la auscultación . . .
3
1.3. Ejemplo de una espirometría en un hospital . . . . . . . . . . . . . . . . .
4
1.4. Medidor glucosa AgaMatrix . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.5. Tensiometro Withings . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.6. Esquema de la solución propuesta . . . . . . . . . . . . . . . . . . . . . .
7
2.1. Miembros de la Open Handset Alliance . . . . . . . . . . . . . . . . . . .
11
2.2. Arquitectura de Android . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.3. Dispositivo Android empleado en el desarrollo . . . . . . . . . . . . . . .
13
2.4. Espirómetro digital portátil SP10 . . . . . . . . . . . . . . . . . . . . . . .
14
2.5. SDK Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.6. Captura de la herramienta Trello con sus tres tableros . . . . . . . . . . . .
16
3.1. Procedimiento de extracción de características . . . . . . . . . . . . . . . .
20
3.2. Componentes que forman mobileSpiro . . . . . . . . . . . . . . . . . . . .
21
3.3. Diferenciación de silencio inicial - evento respiratorio - silencio final . . . .
22
3.4. Vista del entorno web de CHESS . . . . . . . . . . . . . . . . . . . . . . .
22
3.5. Los 20 primeros coeficientes correspondientes a las personas sanas . . . . .
24
3.6. Los 20 primeros coeficientes correspondientes a las personas asmáticas . .
24
3.7. Ejemplo de gaussianas . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.1. Obtención del vector de características en base a un sonido . . . . . . . . .
25
4.2. Aplicación método pre-énfasis, donde se enfatizan las frecuencias altas . . .
26
4.3. Gráfico división de la señal en subframes con solapamiento . . . . . . . . .
26
4.4. Ejemplo banco de filtros Mel . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.5. Proceso de multiplicación de filtros y periodograma . . . . . . . . . . . . .
28
4.6. Gráfico formación del cepstrograma a partir coeficientes MFC . . . . . . .
29
4.7. Procedimientos que se aplicarán sobre la señal en este filtro . . . . . . . . .
31
XIX
4.8. Diagrama sobre la delimitación de eventos respiratorios . . . . . . . . . . .
34
4.9. Ejemplo gráfico de peak y deep . . . . . . . . . . . . . . . . . . . . . . . .
35
4.10. Procedimientos a aplicar en el segundo filtrado sobre los candidatos . . . .
37
4.11. Mezcla de tres funciones gaussianas . . . . . . . . . . . . . . . . . . . . .
38
4.12. Esquema funcionamiento EM . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.13. Distribución datos entrenamiento modelo enfermos . . . . . . . . . . . . .
39
5.1. Esquema del funcionamiento del prototipado evolutivo . . . . . . . . . . .
42
5.2. Arquitectura de los módulos que forman la aplicación . . . . . . . . . . . .
43
5.3. Submódulos y resultado del Módulo I: Captura señal de audio . . . . . . .
44
5.4. Espectrograma inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
5.5. Filtro 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.6. Filtro 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.7. Representación gráfica del espectrograma resultante . . . . . . . . . . . . .
47
5.8. Submódulos y resultado del Módulo IIb: Obtención de los vectores de características de los Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.9. Ejemplo de muestra recogida por la aplicación: altura, edad, sexo, fecha toma, [asmático/alérgico/sano], estado . . . . . . . . . . . . . . . . . . . . .
49
5.10. Submódulos y resultado del Módulo III: similitud template - muestra . . . .
52
5.11. División en fragmentos respiratorios/voces . . . . . . . . . . . . . . . . . .
54
5.12. Aplicación de filtro de medias de 3 puntos sobre el componente b . . . . . .
57
5.13. Submódulos y resultado del Módulo IV: Valoración del estado respiratorio
del usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
5.14. Activity inicial de la aplicación e instrucciones de uso . . . . . . . . . . . .
61
5.15. Introducir nombre y comenzar grabación . . . . . . . . . . . . . . . . . . .
62
5.16. Aspecto de la aplicación durante la grabación . . . . . . . . . . . . . . . .
62
5.17. Aspecto de la aplicación tras finalizar la grabación . . . . . . . . . . . . . .
63
5.18. Puntero azul y muestra del segundo que se esta reproduciendo . . . . . . .
63
5.19. Spinner que aparece durante el procesamiento . . . . . . . . . . . . . . . .
64
5.20. Esta activiy muestra los eventos respiratorios detectados . . . . . . . . . .
64
5.21. Spinner que aparece mientras se ejecuta el algoritmo . . . . . . . . . . . .
64
5.22. Activity final en la que se muestra el estado del paciente . . . . . . . . . .
64
5.23. Diagrama de casos de uso SiMoA . . . . . . . . . . . . . . . . . . . . . .
65
5.24. Diagrama de clases algoritmo detección de eventos respiratorios . . . . . .
66
5.25. Diagrama de clases algoritmo determinación del estado respiratorio . . . .
67
5.26. Diagrama de secuencia aplicación filtro 1 . . . . . . . . . . . . . . . . . .
67
5.27. Diagrama de secuencia wav-array float . . . . . . . . . . . . . . . . . . . .
68
xx
6.1. Porcentaje de aciertos en la detección de respiraciones . . . . . . . . . . .
69
6.2. Respiraciones detectadas en pepe.wav . . . . . . . . . . . . . . . . . . . .
71
7.1. Ejemplo grabación iPhone 4S . . . . . . . . . . . . . . . . . . . . . . . . .
73
7.2. Ejemplo grabación Nexus 4 . . . . . . . . . . . . . . . . . . . . . . . . . .
74
3.
Datos aportados por los sujetos . . . . . . . . . . . . . . . . . . . . . . . .
86
4.
Autorización empleada para obtener el consentimiento de las personas que
han colaborado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
5.
División del trabajo por meses . . . . . . . . . . . . . . . . . . . . . . . .
91
6.
Divisón del trabajo por módulos . . . . . . . . . . . . . . . . . . . . . . .
91
7.
Selección de evento respiratorio dentro de un audio . . . . . . . . . . . . .
93
8.
Conjunto de entrenamiento seleccionado . . . . . . . . . . . . . . . . . . .
95
xxi
Índice de listados
5.1. Representación array con GraphView . . . . . . . . . . . . . . . . . . . .
47
5.2. Métodos calcEnergy y calcZCR . . . . . . . . . . . . . . . . . . . . . . .
53
5.3. Ejemplo de la detección de un posible evento respiratorio entre los segundos
2y3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
5.4. Script cálculo de descriptores estadísticos . . . . . . . . . . . . . . . . . .
55
5.5. Filtro medias 3 puntos en Java . . . . . . . . . . . . . . . . . . . . . . . .
56
5.6. Cálculo similitud con el modelo de los asmáticos . . . . . . . . . . . . . .
59
5.7. Determinar el estado de obstrucción del paciente . . . . . . . . . . . . . .
60
1.
Serialización de un objeto BreathTrainingSet . . . . . . . . . . . . . . . .
93
2.
Recuperación del objeto serializado . . . . . . . . . . . . . . . . . . . . .
94
XXIII
Listado de acrónimos
OMS
Organización Mundial de la Salud
TFG
Trabajo Fin de Grado
FVC
Capacidad vital forzada
VC
Capacidad vital
FEV1
Volumen máximo de aire espirado en el primer segundo
PEF
Peak flow
VAD
Voice-Activity-Detection
SMS
Short Message Service
CHESS
Comprehensive Health Enhancement Support System
MFCC
Mel Filter Cepstral Coefficents
DCT
Discrete Cosine Transform
CM
Case Management
OMS
Organización Mundial de la Salud
FFT
Fast Fourier Transform
XXV
Capítulo 1
Introducción
E
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.
N
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.
1.1.1
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 provo1
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 255.000 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
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
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.
1.1.2
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 com4
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
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.
1.2.1
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.
1.2.2
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
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
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
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:
2.3.1
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
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.
2.3.2
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.
2.3.3
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
2.4.1
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 1.1.2. 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
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 VisualBasic.
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
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.
2.4.2
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
R Pentium(R) Dual CPU T3400 @ 2.16GHz x 2
Procesador: Intel
12
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 12.04 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 4.4.4
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
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 SP10
2.4.3
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
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
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
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 LATEXmultiplataforma con licencia GPL, algunas de sus características
son: autocompletado de comandos LATEX, 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
Capítulo 3
Antecedentes
E
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.
STE
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.
3.1.1
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
Figura 3.1: Procedimiento de extracción de características
3.1.2
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.
3.1.3
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 pul20
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:
15e
(0,1524h − 0,0214a − 4,65)t
(3.1)
F V Cm =
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
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.
3.3.1
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
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.
3.4.1
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.
3.4.2
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
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
Capítulo 4
Conceptos específicos del dominio
E
N 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
4.1.1
MFCC: Mel Filter Cepstral Coefficents
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.
MFCC
Figura 4.1: Obtención del vector de características en base a un sonido
25
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
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.
M agnitud =
1
∗ (f f t.real)2 + (f f t.imag)2
nf f t
(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 12-13 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
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.
4.1.2
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
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.



2 4 5   7 3 1


 
M edia =  3 5 7  +  9 8 5

 
8 1 3
4 6 2




 + ···




=
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





donde n es el número de cepstrogramas procedentes del conjunto de ejemplo.



2 4 5   7 3 1



Varianza =  3 5 7 
+ 9 8 5

 
8 1 3
4 6 2
 P




(2−avg)2 +(7−avg)2 +···
n
P
(3−avg)2 +(9−avg)2 +···
n
P
(8−avg)2 +(4−avg)2 +···
n



 + ···

P
=
(4−avg)2 +(3−avg)2 +···
n
P
(5−avg)2 +(8−avg)2 +···
n
P
(1−avg)2 +(6−avg)2 +···
n
29
P
(5−avg)2 +(1−avg)2 +···
n
P
(7−avg)2 +(5−avg)2 +···
n
P
(3−avg)2 +(2−avg)2 +···
n





(4.3)
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.
4.1.3
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 4.1.1.
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
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.
1
C p = Pn PNc
i=1
j=1
|Dij |2
(4.5)
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
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=
X+1)
1 N0 +(N
∗
x2 [n]
N
n=N0
(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 ∗ log10 (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.
+N −1
1 N0X
0,5|sgn(x[n]) − sgn(x[n − 1])|
∗
ZCR =
N n=N0 +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
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.
4.1.4
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
Figura 4.8: Diagrama sobre la delimitación de eventos respiratorios
34
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 Xk se considera deep significativo si
max{E(XL ) − E(XK ), E(XR ) − E(XK )} > (Emax − Emin )/4
(4.10)
donde XL y XK son los picos más cercanos tanto a derecha como a izquierda, Emax y
Emin 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
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
4.1.5
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
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
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
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 4.12.
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
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
Capítulo 5
Método de trabajo
E
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.
N
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
5.1
5.2 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
Metodologías ágiles
Metodologías Tradicionales
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
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
Proceso menos controlado, pocos principios
y políticas
Ausencia de contrato y en caso de existir muy flexible Existe un contrato prefijado
El cliente sólo se comunica con el equipo mediante
El cliente es parte del equipo de desarrollo
reuniones
Grupos pequeños que trabajan en el mismo sitio
Grupos grandes y distribuidos
Pocos artefactos
Más artefactos
Pocos roles
Más roles
La arquitectura del software es esencial y se expresa
Menos énfasis en la arquitectura del software
mediante modelos
Cuadro 5.1: Diferencias entre metodologías ágiles y tradicionales
Figura 5.1: Esquema del funcionamiento del prototipado evolutivo
42
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
5.3.1
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.
5.3.2
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 5.3 .
43
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 WaveTools.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
Figura 5.4: Espectrograma inicial
5.3.3
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.
5.3.4
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 5.2.
45
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 5.5.
2. 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
5.6.
46
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.
X
columna[i] ∗ f ila[j]
X
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 . s e t M a n u a l Y A x i s B o u n d s (350 , 0) ;
47
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.
5.3.5
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
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
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
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
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.
5.3.6
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 5.10 .
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
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
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 0.0025.
Non−Breath
Non−Breath
Non−Breath
XX
Seg :2
XX
Seg :2
XX
Seg :3
XX
Seg :3
XX
Seg :3
XX
Seg :3
XX
Seg :3
Energia
Energia
Energia
Energia
Energia
Energia
Energia
−33.95371 ZCR 0.08231293
−56.282913 ZCR 0.1845805
−64.43788 ZCR 0.35510203
−62.27859 ZCR 0.32517007
−57.73909 ZCR 0.21337868
−56.67229 ZCR 0.21473923
−58.025646 ZCR 0.23650794
Listado 5.3: Ejemplo de la detección de un posible evento respiratorio entre los segundos 2
y3
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
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
Voz
Media
Mediana
Varianza
Cuartil(0.25)
Cuartil(0.5)
Cuartil(0.75)
Energia
-39.37032
-37.25832
73.15023
-41.59542
-37.25832
-33.95717
ZCR
0.1569319
0.1318594
0.009295386
0.08157596
0.1318594
0.2087302
Cuadro 5.3: Descriptores estadísticos Voz
Respiración
Media
Mediana
Varianza
Cuartil(0.25)
Cuartil(0.5)
Cuartil(0.75)
Energia
-60.52494
-60.82553
9.898509
-62.69718
-60.82553
-58.66686
ZCR
0.3107869
0.3105442
0.007061466
0.2504819
0.3105442
0.3899093
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 < d e m a r c a t i o n F r a m e s A u x . size () − POINTS + 1) {
Frame [] aux = d e m a r c a t i o n F r a m e s A u x . subList (i , i +
POINTS ) . toArray ( new Frame [ POINTS ]) ;
Frame copy = new Frame ( d e m a r c a t i o n F r a m e s A u x . get ( i
+ POINTS / 2) ) ;
float sum =0 f ;
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
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
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
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 .
g e t E x t e r n a l S t o r a g e D i r e c t o r y () + " / 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.0 E−6" ;
options [10] = "−S " ;
options [11] = " 100 " ;
result = Cl usterE valuat ion . e valuat eClust erer ( 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
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
5.3.8
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
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... un
botón de PARAR en la parte inferior de la pantalla cuando se quiera acabar con la grabación
(Figura 5.16).
2
Cuando se pare la grabación del audio pulsando el botón PARAR, aparecerán tres nue61
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
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
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
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.
5.4.1
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).
5.4.2
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
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.
5.4.3
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
Figura 5.25: Diagrama de clases algoritmo determinación del estado respiratorio
Figura 5.26: Diagrama de secuencia aplicación filtro 1
5.26) y el paso de la voz del usuario a un array de floats (Figura 5.27).
67
Figura 5.27: Diagrama de secuencia wav-array float
68
Capítulo 6
Resultados
E
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.
N
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
Nombre audio
Masculino_c_23
Masculino_c1_23
Masculino_c2_23
Masculino_c3_23
Masculino_c4_23
Masculino_c5_23
Masculino_c6_23
Masculino_c7_23
Masculino_eh1_19
Masculino_eh2_19
Masculino_ep1_61
Masculino_ep2_61
Masculino_i1_48
Masculino_i2_48
Masculino_o1_44
Masculino_o2_44
Masculino_j1
Masculino_iv1
Masculino_iv2
Masculino_iv3
Masculino_iv4
Masculino_p1
Masculino_ceci1
Detecciones totales
5
1
2
4
3
9
4
6
4
5
8
7
6
10
9
11
2
4
5
4
4
2
3
Correctas
2
1
1
3
1
6
1
4
4
5
6
6
5
8
4
9
1
4
5
3
4
2
2
Erroneas
3
1
1
2
3
3
2
2
1
1
2
5
2
1
1
1
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
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.
6.2.1
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
Usuario
Crónico_1
Crónico_2
Estacional_1
Sano_1
Sano_2
Sano_3
Estado en reposo
Dificultad respiratoria
Dificultad respiratoria
Bueno
Bueno
Bueno
Bueno
Estado tras esfuerzo físico
Dificultad respiratoria
Dificultad respiratoria
Dificultad respiratoria
Dificultad respiratoria
Normal
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.
6.2.2
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.
6.2.3
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
Capítulo 7
Conclusiones y propuestas
E
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.
N
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
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
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 44100 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
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
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
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
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):1450011, 2014. url: http://www.worldscientific.com/
doi/abs/10.1142/S0129156414500116.
[And]
Android. Android website. url: http://www.android.com.
[aud]
Audacity website. url: http://audacity.sourceforge.net/.
[BP04]
M. Bahoura y C. Pelletier. Respiratory sounds classification using cepstral
analysis and Gaussian mixture models. En Engineering in Medicine and Biology Society, 2004. IEMBS ’04. 26th Annual International Conference of the
IEEE, volume 1, páginas 9–12, Sept 2004.
[BP09]
B.Holz y P.Whitten. Managing Asthma with Mobile Phones: A Feasibility
Study. Nov 2009.
[Bra14]
J. Bravo. m-Health: Mobile Computing and Health Monitoring. J. of Computation in Biosciences and Engineering, 2014.
[BW]
P. Boersma y D. Weenink. Praat: doing phonetics by computer. url: http://
www.fon.hum.uva.nl/praat/.
[com]
comSCORE.
Spain Digital Future in Focus 2013.
http://www.digital-nature.com/uploads/documentos/
2013-Spain-Digital-Future-in-Focus.pdf.
url:
[GBGG05] J. Gosling, B.Joy, G.Steele, y G.Bracha. Java(TM) Language Specification, The
(3rd Edition) (Java (Addison-Wesley)). Addison-Wesley Professional, 2005.
[gim]
Gimp website. url: http://www.gimp.com.
[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 2012. url: http://www.jmir.org/2012/4/e101/.
79
[GPNS11] S. Gupta, P.Chang, N.Anyigbo, y A. Sabharwal. mobileSpiro: portable openinterface spirometry for Android. En Irwin Mark Jacobs, Patrick SoonShiong, Eric Topol, y Christofer Toumazou, editors, Wireless Health, página 24.
ACM, 2011. url: http://dblp.uni-trier.de/db/conf/wh/wh2011.html#
GuptaCAS11.
[Gun]
D. Gunning. Medicamentos para el asma. url: https://www.greenhosp.org/
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, 2008.
[JZZ09]
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:331–334, 2009.
[kil]
Kile website. url: http://kile.sourceforge.net/.
[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 280–289, New York, NY, USA, 2012. ACM. url:
http://doi.acm.org/10.1145/2370216.2370261.
[lib]
LibreOffice website.
impress/.
url: https://es.libreoffice.org/descubre/
[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, 2003. url: http://issi.dsic.upv.es/archives/
f-1069167248521/actas.pdf.
[Rac]
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.
[RBH93]
L. Rabiner y J. Biing-Hwang. Fundamentals of Speech Recognition. PrenticeHall, Inc., Upper Saddle River, NJ, USA, 1993.
[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):838–850,
March 2007.
80
[RQD00]
DA. Reynolds, TF. Quatieri, y RB. Dunn. Speaker verification using Adapted
Gaussian mixture models. En Digital Signal Processing, página 2000, 2000.
[rst]
RStudio website. url: http://www.rstudio.com/.
[sdk]
Android SDK. url: http://developer.android.com/sdk/index.html.
[stu]
Android Studio. url: https://developer.android.com/sdk/installing/
studio.html.
[tre]
Trello website. url: http://trello.com/.
[WHOa]
WHO. Asthma. url: http://www.who.int/respiratory/asthma/en/.
[WHOb]
WHO. Scope: asthma.
scope/en/.
url: http://www.who.int/respiratory/asthma/
81
ANEXOS
83
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
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
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
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
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 3o
y 4o 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 di89
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
Módulo I
Módulo IIa
Refinamiento y recogida muestras
Asma-Alergia-Voz
Anteproyecto
Módulo IIb
Módulo III
Módulo IV
Módulo V
Memoria
Octubre
Octubre
De Noviembre a Enero
Febrero y Marzo
Abril y Mayo
Mayo
Junio
De Julio a Septiembre
Septiembre y Octubre
Octubre y Noviembre
De Junio a Noviembre
6
10
20
15
20
10
20
40
20
10
-
18
30
60
30
60
20
80
210
80
40
-
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
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
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 BreathTrainingSet 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 102.2 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).
Brea thTra iningS et bTrainingSet = new Br eathTr ainin gSet () ;
bTrainingSet . addExample ( " ./ breaths_set / inspiration1 . wav " ) ;
bTrainingSet . addExample ( " ./ breaths_set / inspiration2 . wav " ) ;
Figura 7: Selección de evento respiratorio dentro de un audio
93
bTrainingSet . addExample ( " ./ breaths_set / inspiration3 . wav " ) ;
bTrainingSet . addExample ( " ./ breaths_set / inspiration4 . wav " ) ;
bTrainingSet . addExample ( " ./ breaths_set / inspiration5 . wav " ) ;
bTrainingSet . addExample ( " ./ breaths_set / inspiration6 . wav " ) ;
bTrainingSet . addExample ( " ./ breaths_set / inspiration7 . wav " ) ;
bTrainingSet . addExample ( " ./ breaths_set / expiration1 . wav " ) ;
bTrainingSet . addExample ( " ./ breaths_set / expiration2 . wav " ) ;
bTrainingSet . addExample ( " ./ breaths_set / expiration3 . wav " ) ;
bTrainingSet . addExample ( " ./ breaths_set / expiration4 . wav " ) ;
bTrainingSet . addExample ( " ./ breaths_set / expiration5 . wav " ) ;
bTrainingSet . addExample ( " ./ breaths_set / expiration6 . wav " ) ;
bTrainingSet . addExample ( " ./ breaths_set / re sp ir ac io n1 Ip ho ne . wav " ) ;
bTrainingSet . addExample ( " ./ breaths_set / re sp ir ac io n2 Ip ho ne . wav " ) ;
bTrainingSet . addExample ( " ./ breaths_set / re sp ir ac io n3 Ip ho ne . wav " ) ;
bTrainingSet . addExample ( " ./ breaths_set / re sp ir ac io n4 Ip ho ne . wav " ) ;
bTrainingSet . addExample ( " ./ breaths_set / re sp ir ac io n5 Ip ho ne . wav " ) ;
bTrainingSet . addExample ( " ./ breaths_set / re sp ir ac io n6 Ip ho ne . wav " ) ;
try {
FileOutputStream fs = new FileOutputStream ( " trainingSetObj . ser
");
O bje ct Ou tp ut St re am os = new O bj ec tO ut pu tS tre am ( fs ) ;
os . writeObject ( bTrainingSet ) ;
os . close () ;
} catch ( Exception e ) {
System . out . println ( " Se ha producido un error " ) ;
}
Listado 1: Serialización de un objeto BreathTrainingSet
Bre athTra iningS et bTrainingSet = null ;
try {
FileInputStream fs = new FileInputStream ( " trainingSetObj . ser " )
;
Obj ectInp utStre am os = new Ob jectIn putSt ream ( fs ) ;
bTrainingSet =( B reathT rainin gSet ) os . readObject () ;
os . close () ;
} catch ( Exception e ) {
System . out . println ( " Se ha producido un error " ) ;
}
Listado 2: Recuperación del objeto serializado
Una vez ya se ha determinado el conjunto de entrenamiento a emplear se debe fijar un
umbral que indique si el coeficiente Cp de un superFrame se corresponde a un evento respiratorio. El umbral se denominará Bm/2 y se obtiene mediante el siguiente procedimiento.
94
Figura 8: Conjunto de entrenamiento seleccionado
Se entrena el algoritmo con las muestras ya elegidas creando un objeto BreathTrainingSet después se comparan una a una cada una de las muestras que forman el conjunto de
entrenamiento con él mismo. Se descompone cada muestra en subframes y superframes y
tras calcular el cepstrograma de cada superframe se calcula su coeficiente Cp con el método computeCpCoefficient de la clase SimilarityCoefficents que recibe como parámetro el
cepstrograma del superFrame. Se guardan todos y cada uno de los coeficientes Cp de los
superframes de las muestras y se aplica la siguiente fórmula:
Bm/2 =
min{Cp superF rames de cada una de las muestras}
2
95
(1)
Este documento fue editado y tipografiado con LATEX
empleando la clase esi-tfg que se puede encontrar en:
https://bitbucket.org/arco group/esi-tfg
97