Iconos - Ruidera - Universidad de Castilla

UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
GRADO EN INGENIERÍA INFORMÁTICA
TRABAJO FIN DE GRADO
PHASE: Sistema para el
reconocimiento de estrés en voz
Raúl Campos Rubio
Junio, 2016
PHASE: S ISTEMA PARA EL
RECONOCIMIENTO DE ESTRÉS EN VOZ
Escuela
Superior
de Informática
UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
Departamento de Tecnologías y Sistemas de Información
TECNOLOGÍA ESPECÍFICA DE
TECNOLOGÍAS DE LA INFORMACIÓN
TRABAJO FIN DE GRADO
PHASE: Sistema para el
reconocimiento de estrés en voz
Autor: Raúl Campos Rubio
Director: José Bravo Rodríguez
Director: Iván González Díaz
Junio, 2016
Raúl Campos Rubio
Ciudad Real – Spain
E-mail: [email protected]
Teléfono: 663350981
c 2016 Raúl Campos Rubio
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
Actualmente, los teléfonos inteligentes nos permiten estar en contacto con nuestros seres
queridos, manejar nuestros calendarios, correos electrónicos o archivos, entre otras muchas
opciones. Su propósito multitarea y su naturaleza ubicua les permite ser la plataforma objetivo de muchos investigadores y desarrolladores.
Por otra parte, el estrés es un estado fisiológico que desencadena una gran cantidad de
reacciones en el cuerpo humano. Algunas de estas reacciones pueden ser monitorizadas utilizando señales biométricas.
El objetivo principal de este proyecto es crear una aplicación para identificar las condiciones de estrés y evitar las enfermedades relacionadas con este estado por medio de la voz,
a través del uso de teléfonos inteligentes como fuente de datos e información. El detector
PHASE (phone analyzer of stress) ha sido desarrollado como una solución en el contexto de
la m-health, con la finalidad de ser un producto no intrusivo, fácil de usar y elegante.
V
Abstract
Nowadays, smartphones devices allow us to keep in touch with people, manage our calendar, email, files and so on. Their multitask purpose and ubiquitous nature let them be the
target platform for so many researchers and developers.
On the other hand, stress is a physiological state that triggers a huge amount of reactions within the human body. Some of these reactions can be monitored using biometric
signals.
The main goal of this project is to create an application to identify stress conditions and
avoid illnesses related with this state by means of voice, through the use of smartphones as a
source of data and information. PHASE detector (phone analyzer of stress) has been developed as a m-health solution in order to be non-intrusive, easy to use and elegant product.
VII
Agradecimientos
Gracias a mi familia, padres y hermano, por apoyarme y no dudar de mi en ningún momento, por su coraje, su trabajo y su ánimo constante y a Jesús por todos aquellos viajes y
vivencias.
El trayecto siempre fue difícil, por ello agradecer a tantísimas caras que me han ayudado a
abordar los problemas, algunas que nunca volverán y algunas que espero con ilusión volver
a ver.
A Isabel por animarme tanto y darme aquellos viernes llenos de dulzura, a pesar de haberla
conocido en mitad del trayecto, su persona siempre es necesaria para mi.
Agradecer a Pepe por apostar por mi y a Iván por perfilar la idea, por dedicarme tantísimo
tiempo, paciencia y trabajo.
Feliz por haber descubierto mi vocación, por intentar ser mejor profesional, porque me
hace sentir realizado y por un futuro brillante.
Raúl
IX
A mi familia por haber hecho esto posible, a Isabel por animarme y entenderme.
xi
Índice general
Resumen
V
Abstract
VII
Agradecimientos
IX
Índice general
XIII
Índice de cuadros
XVII
Índice de figuras
XIX
Índice de listados
XXI
Listado de acrónimos
XXIII
1. Introducción
1
1.1. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1.1. Dispositivos móviles . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1.2. M-health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1.3. Inteligencia artificial (IA) . . . . . . . . . . . . . . . . . . . . . . .
3
1.2. Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2.1. La voz como eje principal . . . . . . . . . . . . . . . . . . . . . .
4
1.2.2. El estrés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2.3. Usos prácticos . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.3. Solución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.4. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2. Objetivos y Herramientas
9
2.1. Objetivo principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2. Objetivos secundarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
XIII
2.2.1. Referentes al tratamiento de voz . . . . . . . . . . . . . . . . . . .
9
2.2.2. Referentes a la predicción . . . . . . . . . . . . . . . . . . . . . .
10
2.2.3. Referentes a la representación visual de los datos . . . . . . . . . .
10
2.3. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3.1. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3.2. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3. Antecedentes
17
3.1. Predicción del estrés a través de señales biométricas . . . . . . . . . . . . .
17
3.1.1. Apariencia física . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.1.2. Piel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.1.3. Actividad cerebral mediante EEG . . . . . . . . . . . . . . . . . .
18
3.1.4. Actividad cardíaca mediante ECG . . . . . . . . . . . . . . . . . .
18
3.1.5. Voz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.2. Vectores de características . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.2.1. Coefiecientes ceptrales en la escala de mel (MFCC), número de cruces por cero (ZCR) y energía . . . . . . . . . . . . . . . . . . . . .
18
3.2.2. Coeficientes delta . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.2.3. Parámetro cepstral basado en sub-banda (SBC) . . . . . . . . . . .
19
3.3. Mecanismos de clasificación . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.3.1. Modelos de mezclas gaussianas (GMM) . . . . . . . . . . . . . . .
19
3.3.2. Redes neuronales . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.3.3. Árboles de decisión . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.3.4. Deformación dinámica del tiempo (DTW) . . . . . . . . . . . . . .
21
3.3.5. Máquina de vectores de soporte (SVM) . . . . . . . . . . . . . . .
21
3.4. Trabajos por parte de esta universidad . . . . . . . . . . . . . . . . . . . .
21
4. Tratamiento de la Voz
23
4.1. Características del audio . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.1.1. Formato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.2. Filtrado y VAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.2.1. Umbral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.3. Representación de los datos . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.3.1. MFCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.3.2. Coeficientes delta . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.3.3. Energía y número de cruces por cero . . . . . . . . . . . . . . . . .
32
xiv
5. Clasificacion y Concurrencia
35
5.1. Aprendizaje automático . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
5.1.1. Aprendizaje supervisado . . . . . . . . . . . . . . . . . . . . . . .
36
5.2. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.3. SVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
5.3.1. Parámetros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
5.3.2. Tipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.3.3. Kernels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.3.4. LibSVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
5.4. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.5. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5.5.1. Concurrencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
5.5.2. Grabación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
5.5.3. Procesador de voz . . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.5.4. Optimizaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
6. Tecnologías y Componentes
51
6.1. Tecnologías Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
6.1.1. Elementos a nivel interno . . . . . . . . . . . . . . . . . . . . . . .
51
6.1.2. Elementos de la interfaz . . . . . . . . . . . . . . . . . . . . . . .
53
6.1.3. Manifest y permisos . . . . . . . . . . . . . . . . . . . . . . . . .
62
6.2. Tecnologías web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
6.2.1. Lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
6.2.2. Librerias JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . .
64
7. Arquitectura Software, Metodología y Usabilidad
69
7.1. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
7.2. Capas software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
7.2.1. Presentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
7.2.2. Dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
7.2.3. Persistencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
7.3. Patrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
7.4. Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
7.5. Diseño centrado en el usuario (DCU) . . . . . . . . . . . . . . . . . . . . .
77
8. Conclusiones y Trabajo Futuro
81
8.1. Cobertura de los objetivos . . . . . . . . . . . . . . . . . . . . . . . . . .
xv
81
8.1.1. Referentes al tratamiento de voz . . . . . . . . . . . . . . . . . . .
81
8.1.2. Referentes a la predicción . . . . . . . . . . . . . . . . . . . . . .
81
8.1.3. Referentes a la representación visual de los datos . . . . . . . . . .
82
8.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
8.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
A. Aspectos Legales
89
A.1. Ley orgánica de protección de datos (LOPD) . . . . . . . . . . . . . . . . .
89
A.2. Recursos gráficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
Referencias
93
xvi
Índice de cuadros
6.1. Algunos de los mensajes existentes en el sistema. . . . . . . . . . . . . . .
52
6.2. Algunos de los permisos existentes en el sistema. . . . . . . . . . . . . . .
63
XVII
Índice de figuras
1.1. Cuota de mercado en porcentaje de sistemas operativos móviles los últimos
años [2]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2. Esquema del proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1. Equipos hardware utilizados a lo largo del desarrollo. . . . . . . . . . . . .
16
3.1. Composición de una distribución utilizando componentes Gaussianas. . . .
20
3.2. Esquema general de una red neuronal con entradas y salidas. . . . . . . . .
20
4.1. Comparación de un señal con su versión discretizada. . . . . . . . . . . . .
24
4.2. Estructura del formato WAV. . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.3. Actividad real comparada con actividad detectada, y los cuatros criterios de
error. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.4. Ejemplo de un fragmento de audio eliminado entre dos zonas de silencio,
supone un incremento de los ratios de error FEC y MSC. . . . . . . . . . . .
28
4.5. División de cada segmento de audio en subsegmentos. . . . . . . . . . . .
29
4.6. Ventana de Hamming en el intervalo [0, N − 1]. . . . . . . . . . . . . . . .
30
4.7. Ejemplo del resultado de una FFT para el caso de frecuencias infrasonoras.
Amplitud en el eje de ordenadas medido en voltios. . . . . . . . . . . . . .
31
4.8. Comparativa de la frecuencias equivalentes en Mels y en Hertzios. . . . . .
31
4.9. Banco de filtros de Mel. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.10. Representación del vector de características que se genera para cada segmento de audio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
5.1. A la izquierda distribución de puntos en un espacio 2D a la derecha la división del espacio utilizando SVM. . . . . . . . . . . . . . . . . . . . . . . .
38
5.2. Gráfico generado por gnuplot y la herramienta grid.py, define las áreas de
probabilidad en función de γ (ordenadas) y C (abscisas). . . . . . . . . . .
41
5.3. Diagrama de secuencia que especifica el flujo de tratamiento de la voz. . . .
48
6.1. Ciclo de vida de una actividad. . . . . . . . . . . . . . . . . . . . . . . . .
54
6.2. Elemento DatePickerDialog. . . . . . . . . . . . . . . . . . . . . . . . . .
56
XIX
6.3.
BetweenDatesFragment
y DailyFragment. . . . . . . . . . . . . . . . . . . .
57
6.4.
PeopleListFragment
y PersonFragment. . . . . . . . . . . . . . . . . . . . .
58
6.5. Ejemplo de una notificación de la aplicación. . . . . . . . . . . . . . . . .
59
6.6. Menú de cajón. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
6.7. Ítem de llamada renderizado usando CallAdapter. . . . . . . . . . . . . . .
61
6.8. Gráfico splines representando el nivel de estrés y la duración respecto de la
fecha. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
6.9. Gráfico doughnut con la contribución de estrés de cada hora del día. . . . .
66
6.10. Grafo representativo de los contactos y las llamadas. . . . . . . . . . . . .
66
7.1. Diagrama de casos de uso. . . . . . . . . . . . . . . . . . . . . . . . . . .
70
7.2. Paquete de interfaces web y adaptadores. . . . . . . . . . . . . . . . . . . .
71
7.3. Paquete de fragmentos. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
7.4. Paquete de actividades y vistas personalizadas. . . . . . . . . . . . . . . .
71
7.5. Paquete de dominio (modelos). . . . . . . . . . . . . . . . . . . . . . . . .
72
7.6. Paquete de dominio (lógica). . . . . . . . . . . . . . . . . . . . . . . . . .
73
7.7. Paquete de persistencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
7.8. Esquema representativo de la metodología Scrum. . . . . . . . . . . . . . .
77
7.9. Prototipo del menú drawer y del filtro de contactos. . . . . . . . . . . . . .
79
7.10. Prototipo del filtro entre fechas y del fragmento que describe las llamadas. .
80
A.1. Iconos originales utilizados para mejorar la experiencia visual en la aplicación. 91
xx
Índice de listados
5.1. Listado del script BASH para validación de los datos. . . . . . . . . . . . . .
42
5.2. Resultados para el participante 1 (hombre). . . . . . . . . . . . . . . . . .
42
5.3. Resultados para el participante 2 (hombre). . . . . . . . . . . . . . . . . .
43
5.4. Resultados para el participante 3 (hombre). . . . . . . . . . . . . . . . . .
43
5.5. Resultados para el participante 4 (mujer). . . . . . . . . . . . . . . . . . .
43
5.6. Resultados para el participante 5 (mujer). . . . . . . . . . . . . . . . . . .
44
5.7. Resultados para el conjunto total (mixed.data). . . . . . . . . . . . . . . . .
44
5.8. Métodos run() y finish() pertenecientes a la clase Recorder. . . . . . . . .
45
6.1. Método sobrescrito para la clase ScrollingWebView. . . . . . . . . . . . . .
62
XXI
Listado de acrónimos
PHASE
Phone Analyzer of Stress
PDA
Personal Digital Assistant
HTML
Hypertext Markup Language
HTML5
Hypertext Markup Language version 5
XML
Extended Markup Language
SVG
Scalable Vector Graphics
CSS
Cascading Style Sheets
MFCC
Mel Frequency Ceptral Coefficient
PCM
Pulse-Code Modulation
API
Application Programming Interface
LOPD
Ley Orgánica de Protección de Datos
IA
Inteligencia Artificial
GMM
Gaussian Mixture Model
PSO
Particle Swarm Optimization
SiMoA
Sistema de Monitorización del Asma
GSR
Galvanic Skin Response
EEG
Electroencephalography
ECG
Electrocardiography
DTW
Dynamic Time Warping
SBC
Subband Based Cepstral parameter
AMMON
Affective and Mental health Monitor
SVM
Support Vector Machine
VAD
Voice Activity Detector
DCT
Discrete Cosine Transform
FFT
Fast Fourier Transform
DCU
Diseño Centrado en el Usuario
XXIII
wav
Wave form audio file format
mp3
MPEG audio layer III
aiff
Audio Interchange File Format
GNU
GNU is Not Unix
GNOME
GNU Network Object Model Environment
JVM
Java Virtual Machine
W3C
World Wide Web Consortium
ECMA
European Computer Manufacturers Association
SQL
Structured Query Language
RDBMS
Relational DataBase Management System
DOM
Document Object Model
AJAX
Asynchronous JavaScript And XML
IDE
Integrated Development Environment
PHP
PHP pre Hypertext Processor
EPL
Eclipse Public License
CPL
Common Public License
WYSIWYG
What You See Is What You Get
GIMP
GNU Image Manipulation System
UML
Unified Modeling Language
RAM
Random Access Memory
CPU
Central Processing Unit
HDD
Hard Disk Drive
FEC
Front End Clipping
OVER
Over Hang
MSC
Mid-Speech Clipping
NDS
Noise Detected as Speech
ZCR
Zero-Crossing Rate
RBF
Radial Basis Function
SVC
SVM Classification
SVR
SVM Regression
Bash
Bourne Again Shell
LED
Light Emitting Diode
xxiv
JSON
JavaScript Object Notation
SDK
Software Development Kit
SMS
Short Message Service
CRUD
Create, Read, Update and Delete
DAO
Data Access Object
TCP
Transmission Control Protocol
MAmI
Modelling Ambiental Intelligence
SNR
Signal to Noise Ratio
I+D
Investigación y Desarrollo
xxv
Capítulo 1
Introducción
E
presente proyecto destaca por el amplio rango de campos y tecnologías que domina, desde aquellas relacionadas con las tecnologías de la información, la plataforma
Android y las tecnologías web, pasando por aquellas relacionadas con la inteligencia artificial y las técnicas de aprendizaje automático. Posee una sólida base teórica relacionada con
técnicas estadísticas, transformadas y otros fundamentos matemáticos, además de una fuerte
componente de programación concurrente y tareas en segundo plano. La solución pretende
ser un producto fácil de usar, intuitivo, no intrusivo en las labores del usuario y que sirva al
destinatario para corregir aquellas actitudes y patrones que son factores determinantes del estrés y por tanto la causa de una gran cantidad de enfermedades que atañen nuestra salud.
L
1.1 Contexto
1.1.1
Dispositivos móviles
Por todos es conocida la extraordinaria capacidad de los computadores que hoy día conocemos como smartphones, no tanto por su velocidad de cálculo sino por su gran versatilidad.
Los teléfonos inteligentes son algo más que un teléfono, son dispositivos que conocen su
localización, su posición, su proximidad con otros objetos y una gran variedad de características. Tal es su transversalidad, que se han convertido en computadores que gestionan las
tareas del usuario de forma centralizada y ubicua. Desde cualquier punto con conexión a Internet el individuo es capaz de abrir un correo electrónico, gestionar su calendario, visualizar
una página web, escuchar su música preferida o hablar con sus familiares, entre otras muchas
opciones.
Aunque la oferta de mercado para dispositivos hardware es muy amplia y extensa, el mundo de los sistemas operativos móviles está muy limitado a unos cuantos únicamente. Es el
ecosistema Android aquel con más difusión en el mercado actualmente (ver Figura 1.1). Si
sumamos su extensa, versátil y detallada API de desarrollo, se convierte el candidato perfecto
sobre el cual desarrollar aplicaciones.
1.1.2
M-health
La m-health (abreviatura de mobile health) se define como aquellas prácticas relacionadas con la salud que son soportadas mediante la utilización de dispositivos móviles, tales
1
Figura 1.1: Cuota de mercado en porcentaje de sistemas operativos móviles los últimos años
[2].
2
como tabletas, smartphones, dispositivos de monitorización, asistentes digitales personales
(PDA) y en general dispositivos inalámbricos [13]. Relaciona el campo de la salud con el
de la informática y las tecnologías móviles. La computación móvil por su parte, consiste en
una rama de las ciencias de la computación que estudia cómo diferentes dispositivos pueden
comunicarse sin estar conectados de forma física, mediante una red de computadores. Asimismo la m-health pretende ser un complemento de apoyo en las tareas de los profesionales
de la salud para facilitar el seguimiento de sus pacientes de forma autónoma. La mayoría de
trabajos en este campo están centrados en la monitorización de enfermedades y parámetros
sobre la propia salud a través de sensores.
M-health surge como un subsegmento dentro de la e-health (electonic health) [8]. Este
último incluye todas las tecnologías posibles, como la web o el uso de big data, entre otros.
La expansión de la m-health va de la mano de la expansión de los dispositivos móviles.
Debido a sus pequeños tamaños y la cantidad de sensores de los que disponen, los teléfonos inteligentes abren nuevas e increíbles posibilidades a ser explotadas en el campo de la
salud.
1.1.3
Inteligencia artificial (IA)
Otro de los campos que sirve de base para el desarrollo del proyecto es la inteligencia
artificial (IA), en donde destacan aquellos análisis basados en voz. En efecto, se puede considerar la voz como un medidor del estado de salud de las personas.
Dentro de la IA se encuentran las técnicas de reconocimiento automático del habla que
se encuadran dentro del subcampo de la lingüística computacional. De forma más genérica
podríamos decir que usa el conocimiento sobre la lingüística y las ciencias de la computación
para diseñar algoritmos y técnicas que permitan el reconocimiento y traducción de lenguaje
hablado a texto por parte de computadores [20]. Aunque el objetivo principal del presente
proyecto no sea el de reconocer el habla humana, si que tiene una profunda relación en tanto
que trata del procesamiento de voz para determinar otro tipo de características y patrones.
Por otro lado los algoritmos de aprendizaje supervisado de los que hace uso intensivo la
inteligencia artificial tienen una gran cantidad de aplicaciones, son usados por ejemplo en
regresión y clasificación, ya que sirven para deducir funciones a partir de datos de entrada
[29]. Podemos clasificar imágenes, audios, incluso hacer pronósticos meteorológicos o de
cualquier índole. Entre estos algoritmos se encuentran las redes neuronales, los modelos de
mezclas Gaussianas o las máquinas de vectores de soporte. Todo algoritmo de aprendizaje
necesita un modelo o datos de entrenamiento, que sirve como una serie de ejemplos que
pueden estar etiquetados en el caso de la clasificación, y que ayudan al algoritmo a tomar sus
decisiones.
3
1.2 Problema
1.2.1
La voz como eje principal
Entre los diferentes tipos de análisis de voz surge la idea de poder analizar emociones, sin
embargo y a pesar de que se ha hecho un gran avance a nivel global y se han perfeccionado una gran cantidad de técnicas para este fin, poder diferenciar un conjunto de emociones
básicas (pongamos por ejemplo el enfado, la felicidad, la tristeza, la neutralidad, etc.) todavía sigue siendo una ardua labor y los resultados que arrojan algunos de los algoritmos
de clasificación siguen siendo insuficientes como para llevar un estudio serio al respecto y
su posterior aplicación práctica. Por el contrario la identificación de patrones de estrés (que
de hecho ya está siendo analizado mediante otras clases de valores biométricos) parece más
factible y su aplicación práctica es todavía más amplia.
1.2.2
El estrés
El estrés (del griego stringere que significa apretar), es una reacción fisiológica del organismo generalmente activada para afrontar situaciones que se perciben como amenazantes
o bien requieren una exigencia mayor, ya sea física o mental del cuerpo humano. Cualquier
estímulo o condición ambiental son candidatos a ser factores determinantes del estrés. Las
reacciones estresantes se producen a nivel del sistema nervioso simpático, estados que pueden mantenerse durante largos períodos de tiempo, tal es así, que en el campo de la medicina
se conocen casos de distrés, el cual es un tipo de estrés crónico o nocivo que puede durar
años. Muchas veces el estrés puede tener su origen en una vida acelerada.
El estrés sin más no resulta perjudicial, si no fuera porque es la raíz de muchos problemas
de salud a largo plazo [11], aquellos más representativos son:
Problemas coronarios: Se suele elevar la presión sanguínea causando ataques cardíacos. En combinación con otros factores como el tabaco y el alcohol pueden desencadenar enfermedades coronarias.
Problemas mentales: La salud mental es otro de los campos afectados, generando ansiedad, depresión, insomnio, ataques de pánico o neurosis, entre otros.
Problemas digestivos: Causa y empeora problemas como irritación de colón, algunas
formas de gastritis, náuseas, diarreas, etc. Además suelen aparecer de forma no continua.
Transtornos menstruales: Puede alterar los ciclos menstruales, tanto las hormonas sexuales como las del estrés están reguladas mediante el hipotálamo.
Además de todo lo expuesto, el cerebro de las mujeres resulta más sensible a la acción
de las hormonas del estrés frente al de los hombres, según un estudio de la Universidad de
Filadelfia [6].
4
1.2.3
Usos prácticos
Es necesario enfocar la detección de estrés, definir qué valores recoger, qué valores plasmar, de dónde obtenerlos y cómo darles un formato elegante, atractivo y útil que pueda servir
al usuario a identificar potenciales fuentes de estrés como personas, horas del día (i.e. horas
de trabajo), o fechas concretas (días, semanas o meses). Habría que definir el tipo de monitorización al que se va a someter al usuario de la aplicación y no obligarle a hacer innecesarias
mediciones que pueden resultar molestas o aburridas, y que a la postre pueden hacer que el
usuario pierda su interés.
Todo esto en conjunto debería ser capaz de hacer que el paciente o individuo tome consciencia de qué factores de los antes mencionados producen estrés en su vida cotidiana y
poder evitarlos para mejorar su salud y su estilo de vida.
1.3 Solución
La plataforma escogida son los teléfonos inteligentes (como ya se comentó) y como fuente
de audio surgió la idea de recoger el sonido de las llamadas telefónicas, gracias al sistema
operativo Android que permite notificar a ciertas aplicaciones de estas acciones, tanto llamadas de entrada como de salida.
Tras la recogida de audio, un proceso de filtrado elimina el silencio y el ruido de fondo,
dejando un audio puro que contiene exclusivamente la voz del interlocutor. El siguiente paso
consiste en extraer unos vectores de características tras un complejo proceso que implica la
fragmentación del audio y la aplicación de diversos mecanismos matemáticos. Cada pequeño
fragmento de audio se transforma en una serie de valores numéricos que representan de forma
precisa la información que contiene la voz.
Dichos valores sirven de entrada a un algoritmo de clasificación cuyo objetivo es discernir
qué fragmentos contienen mayoritariamente una componente de estrés y cuáles no, con tal
fin se utiliza un modelo de estrés previamente computado que sirve como regla de cara a la
predicción.
Con el objetivo de no bloquear las tareas del usuario ni de la aplicación misma, los procesos previamente definidos deben de ejecutarse de forma paralela e invisible para el usuario, y
notificar cuando los resultados estén listos. Con ello debe obtenerse un porcentaje de tiempo
clasificado como tiempo de estrés y su respectiva duración, entre otros datos. La interpretación de los resultados siempre es subjetiva, en el sentido de «¿qué es mas importante para
una persona?», podría darse el caso de grabar una llamada corta con altos niveles de estrés
o una larga con un menor porcentaje del tiempo estresado. Quizás la corta debería ser mas
representativa para el usuario a pesar de que el estrés neto fuera menor.
Tras extraer las datos requeridos, es imprescindible poseer una interfaz gráfica interactiva
para mostrarlos, de forma que el usuario pueda extraer sus conclusiones. Varios esquemas
5
Figura 1.2: Esquema del proceso
han sido utilizados, usando los recursos que proporciona el API de Android en conjunción
con las tecnologías web embebidas. Se han utilizado diversos gráficos para representar los
niveles de estrés a lo largo del tiempo, desglosados cumpliendo con los criterios antes mencionados, así como grafos y listas. La Figura 1.2 resume de forma intuitiva la dinámica del
proyecto.
1.4 Estructura del documento
Capítulo 1: Introducción
Se trata del presente capítulo, en donde introducimos el contexto, la problemática y la
solución final.
Capítulo 2: Objetivos y Herramientas
Finalidad y justificación, desglose del objetivo principal en sub-objetivos. Asimismo
se introducen las herramientas hardware y software que han sido utilizadas a lo largo
del trabajo.
Capítulo 3: Antecedentes
Se trata el alcance de proyectos anteriores al actual y de diversos trabajos y publicaciones relacionados con el presente trabajo, por parte de otras universidades y autores.
Capítulo 4: Tratamiento de la Voz
Se analizan los mecanismos desde el punto de vista del tratamiento de la señal necesarios, como el filtrado o la representación de los datos.
Capítulo 5: Clasificacion y Concurrencia
Se habla sobre los algoritmos de aprendizaje automático, en concreto aquellos referentes a la clasificación de datos. Se detallan los resultados experimentales de dicha
clasificación y por último se comenta la implementación de esta parte desde un punto
de vista concurrente.
Capítulo 6: Tecnologías y Componentes
Se exponen el conjunto de tecnologías tanto móviles como web que participan del
6
desarrollo. Se indaga en el uso del API desde un punto de vista funcional y las descripciones de los componentes por separado.
Capítulo 7: Arquitectura Software, Metodología y Usabilidad
Viaje por la arquitectura software de la aplicación, sus relaciones, capas, diagramas de
clases y patrones de diseño. Finalmente se exponen la metología utilizada y el diseño
centrado en el usuario.
Capítulo 8: Conclusiones y Trabajo Futuro
Justificación de los objetivos listados en el Capítulo 2, así como trabajos futuros y
conclusión personal del autor.
7
Capítulo 2
Objetivos y Herramientas
E
este capítulo se define el alcance del presente trabajo de fin de grado, además de
los medios hardware y software utilizados y sus propiedades. Es importante delimitar
los objetivos, ya que la mayoría de proyectos de investigación tienen una gran cantidad de
aplicaciones y muchos de ellos prosperan como trabajos de fin de máster y tesis doctorales,
asimismo el tiempo que podría invertirse en su desarrollo es potencialmente infinito. Aunque
breve, este capítulo sirve de guía al lector para el resto del documento.
N
2.1 Objetivo principal
El objetivo principal del proyecto es el de desarrollar una aplicación para la plataforma
Android que permita recoger el audio de llamadas entrantes o salientes para determinar los
niveles de estrés que contiene la voz mediante técnicas de inteligencia artificial, y poder
determinar el estado del individuo, con la finalidad de que éste pueda tomar consciencia
y corregir comportamientos que son factores decisivos de estos estados estresantes o bien
hacerlo por medio de algún especialista.
2.2 Objetivos secundarios
A continuación se exponen la lista de subobjetivos de los se compone el objetivo principal
desglosados por temática y con su correspondiente código:
2.2.1
Referentes al tratamiento de voz
(VOZ1) Grabar audio: La fuente de información son las grabaciones que se deben
realizar con cada llamada nueva, por ende se debe reconocer el inicio y fin de una
llamada. Obviamente debe ser una tarea totalmente transparente y no intrusiva.
(VOZ2) Filtrar audio: El audio recogido debe poderse limpiar y se deben aislar aquellos fragmentos sonoros de aquellos que contienen silencio y/o ruido, con la finalidad
de obtener unos resultados precisos fruto de la acción del hablante y no del ruido ambiente.
(VOZ3) Extraer características: Extraer aquellos valores que puedan determinar qué
componentes de estrés contiene la voz, de forma que una conversación telefónica pue9
da traducirse en un conjunto de características sobre las que poder trabajar.
2.2.2
Referentes a la predicción
(PRE1) Obtener conjunto de voces: Debe extraerse un conjunto suficientemente bueno
y variado de voces de todo tipo, grabaciones donde existan fragmentos de calma y
estrés de forma que puedan identificarse ambos estados de forma inequívoca.
(PRE2) Elegir un algoritmo de aprendizaje: Este mecanismo debe ser capaz de hacer
predicciones de forma dinámica sobre los conjuntos de datos entrantes, una buena
elección del algoritmo es crucial en tanto que existen unas limitaciones en cuanto a
capacidad computacional se refiere.
(PRE3) Determinar los parámetros del algoritmo de aprendizaje: En este caso debe
determinarse cuáles son los valores de los parámetros del algoritmo que hacen que el
resultado sea óptimo.
(PRE4) Crear un modelo de estrés universal: Con el objetivo de entrenar un algoritmo de aprendizaje automático, se debe crear un modelo que sirva de base al mismo,
basándose en el grupo de voces obtenido anteriormente.
(PRE5): Testear la bondad de la predicción: Es primordial conocer si efectivamente la
clasificación está siendo llevada a cabo con éxito o si por el contrario esta fracasando,
en este último caso se debe realizar un estudio de sus causas.
2.2.3
Referentes a la representación visual de los datos
(VIS1) Crear un filtro de contactos: El usuario debe ser capaz de ver los niveles de
estrés agrupados por persona de forma que mediante alguna estructura tipo grafo pueda
ver a simple vista con qué contactos ha sufrido situaciones estresantes. También debe
ser capaz de seleccionar cada uno para obtener información pormenorizada.
(VIS2) Crear un filtro de franjas horarias: El usuario debe ser capaz de ver los niveles
de estrés agrupados por hora del día, de forma que mediante algún gráfico sea capaz
de identificar la contribución individual de cada hora del día al estrés total y ver qué
tiempos son los más conflictivos (como las horas de trabajo por ejemplo), así como
obtener información pormenorizada de cada franja.
(VIS3) Crear un filtro de fechas: El usuario debe ser capaz de ver los niveles de estrés
agrupados por períodos de tiempo de varios días, semanas o meses con la finalidad de
identificar lapsos de tiempo en los que se haya padecido estrés de forma constante.
10
2.3 Herramientas
2.3.1
Software
Sistemas operativos
Ubuntu: Es una distribución del sistema operativo GNU/Linux basada en debian y utilizada principalmente como S.O. de escritorio, aunque en los últimos meses se ha extendido a los smartphones. La ventaja es que se distribuye como software libre y gratuito
por parte de sus desarrolladores de la empresa Canonical. Incluye su propio entorno de
escritorio llamado Unity y basado en GNOME. Además está enfocado al uso por parte
de usuarios y ha tenido bastante éxito llegando a ser la distribución GNU/Linux con
más cuota de mercado en la actualidad.
Android: Es un S.O. para smartphones basado al igual que Ubuntu en el núcleo Linux.
El proyecto de crear un sistema operativo para móviles que fuera transversal fue iniciado por la empresa Android Inc. que posteriormente fue comprada y absorbida por
Google. Su uso se ha extendido a la mayoría de dispositivos con pantalla táctil como
tablets, relojes y teléfonos. Android fue presentado en 2007 y el primer móvil que funcionaba con él se vendió en 2008, hasta el punto de que actualmente tiene la mayor
cuota de mercado.
Lenguajes
Java: Es un lenguaje de propósito general orientado a objetos, basado en clases y
concurrente. Fue diseñado por James Gosling en Sun Microsystems alrededor de 1995,
con el objetivo de crear un lenguaje que funcionara en múltiples plataformas sin la
necesidad de recompilarse como hasta entonces hacían C y C++. Las aplicaciones
Java compilan a un código intermedio conocido como bytecode que es interpretado
por la Máquina Virtual Java (JVM) allí donde esté instalada. La principal razón del
uso de Java como principal lenguaje en el proyecto es su inclusión en la plataforma
Android como lenguaje de facto para desarrollo de aplicaciones móviles.
XML:
Es un lenguaje de marcas (Extensible Makup Language) definido por la W3C,
no es más que un conjunto de reglas que busca definir un formato común que sea entendible tanto por parte de la máquina como del humano. Normalmente es usado para
definir conjuntos de datos arbitrarios en forma de árbol. Cada etiqueta XML debe abrirse y cerrarse, puede contener propiedades y un cuerpo compuesto por otras etiquetas.
HTML es un subconjunto de XML.
HTML: HyperText Markup Language (lenguaje de marcas de hipertexto), es el lenguaje
de marcado para elaboración de páginas web, su última versión es HTML5. Es capaz
de definir el contenido que deberá ser desplegado como texto, imágenes, vídeos y
juegos (entre otros) como cuerpo de la página. Con el tiempo ha ido cambiando, se
han incorporado y eliminado diversas características para hacerlo más eficiente y ser
11
compatible con distintos dispositivos (tablets, smartphones, relojes, etc.), capacidad
conocida como responsive.
CSS:
Cascading style sheets (hojas de estilo en cascada), usado para definir el aspecto
visual, es decir la presentación de un documento HTML mediante la utilización de
reglas. La idea subyacente detrás de CSS es separar los estilos del propio documento
HTML aunque puede ser definido en el mismo fichero físico. Las reglas se definen
para etiquetas HTML, clases, identificadores, elementos con ciertas propiedades y la
combinación de todos estos elementos de forma separada o anidada.
JavaScript: Es un lenguaje interpretado, dialecto del estándar ECMAScript, se define
como imperativo, débilmente tipado, dinámico y orientado a objetos, aunque a diferencia de la mayoría de lenguajes que se definen como tal, no usa clases sino prototipos.
Se utiliza principalmente para el lado cliente en aplicaciones web, aunque gracias a
la plataforma NodeJS ha conseguido extenderse a al lado servidor. También se provee al lenguaje de una implementación del DOM (Document Object Model) que es
básicamente una estructura de árbol para la representación de documentos HTML y su
manipulación.
SQL:
Es un lenguaje declarativo de propósito específico diseñado con el objetivo de
interaccionar con sistemas de gestión de bases de datos relacionales (RDBMS). SQL
consta de tres tipos de sentencias, aquellas que permiten definir la estructura de los
datos, las que permiten la manipulación de los mismos y las que definen su acceso.
A pesar de ser un estándar, es común que algunas de sus sentencias no sean portables
de unos RDBMS a otros, debido a que rara vez es implementado de forma íntegra por
parte de los sistemas de base de datos.
Librerías
LibSVM: Es una librería de código abierto desarrollado por la Universidad Nacional
de Taiwan que incluye una implementación de SVM. El código base esta escrito en
C++ pero existen una gran cantidad de wrappers para otros lenguajes de programación como Python, R, Java, Matlab, Perl, Lisp, etc. Soporta tanto clasificación como
regresión.
Recognito: Se trata una librería para reconocimiento de texto hablado independiente
del usuario y escrita en Java.
WavFile: Es una librería Java específica para el manejo de archivos en formato WAV,
proporciona un API para la escritura y lectura de archivos en este formato, así como
la obtención de sus características (número de canales, número de muestras, etc.) sin
tener que lidiar con aspectos de bajo nivel.
JQuery: Es una librería JavaScript creada para simplificar la manera de interactuar con
12
los documentos HTML, manipular el árbol DOM, manejar eventos, y desarrollar animaciones, también simplifica las técnicas AJAX (Asynchronous JavaScript and XML),
para enviar peticiones remotas en tiempo de ejecución. Una de las críticas más frecuentes es que retarda la aplicación (debido a su motor de consultas) y que puede ser
sustituida por otros frameworks más modernos y potentes.
CanvasJS: Es una librería JavaScript con un API para dibujar gráficos automáticamente
en base a un conjunto de datos. Entre los tipos de tablas disponibles se encuentran los
gráficos de barras, de líneas, de burbujas o circulares, entre otros.
SigmaJS: Es una librería JavaScript dedicada a la generación de grafos, permite la utilización de un espacio cartesiano donde colocar nodos, interconectarlos y modificar
sus propiedades (color, tamaño, etiquetas, etc.). La principal ventaja es que es independiente de cualquier otra librería.
IDE’s
y editores
Eclipse: Es un entorno de desarrollo integrado (IDE) usado para la programación en
Java, hasta el punto de que es el más extendido entre los desarrolladores de este lenguaje. Contiene un sistema de plugins mediante el cual nuevas funcionalidades pueden
ser incluidas en el entorno. Asimismo, puede utilizarse para desarrollar en otros lenguajes de programación como C, Ada, Haskell, JavaScript, PHP, etc., a pesar de que su
implementación esté hecha en Java. Tiene una licencia EPL (Eclipse Public License)
que es usada usada por la Fundación Eclipse como reemplazo de la CPL.
Android Studio: Se trata del IDE oficial basado en IntelliJ IDEA que fue creado por
Google bajo la licencia Apache. Esta pensado específicamente para el desarrollo sobre
Android y es multiplataforma. Las aplicaciones generadas bajo este entorno pueden ser
testeadas usando un emulador o bien un dispositivo físico. Permite la integración con
Gradle que es un sistema para automatización de compilados, además provee una vista
WYSIWYG (What You See Is What You Get) en donde los componentes de la interfaz
pueden ser manipulados directamente y renderizados en tiempo de desarrollo..
Atom: Es un editor de texto multiplataforma creado por GitHub Inc. en 2015 al estilo
del editor TextMate. Fue desarrollado utilizando Electron, un framework para generación de aplicaciones de escritorio utilizando tecnologías web. Permite una integración
fluida con el sistema de control de versiones Git además de un sistema de paquetes
muy amplio desarrollado por la comunidad Atom.
Emacs: Es un editor de texto para el proyecto GNU de la familia de editores
Emacs. Fue creado por el mismo fundador del proyecto GNU, Richard Stallman. Se
dice que además de las típicas tareas de edición de texto, Emacs es capaz de controlar
subprocesos, indentar código automáticamente, mostrar múltiples archivos de un solo
golpe, entre otras funciones.
GNU
13
Herramientas de soporte
Audacity: Se trata de un editor y grabador de audio digital disponible para Windows,
OS X, GNU/Linux y FreeBSD. Fue liberado en el año 2000 por personal de la Universidad Carnegie Mellon. Asimismo permite trabajar con formatos como WAV, MP 3 o
AIFF, entre otros. Permite la recogida de audio desde múltiples fuentes, así como añadir
efectos, recortar, enfatizar, atenuar, etc.
Git: Se trata de un sistema de control de versiones bastante extendido y desarrollado
en parte por Linus Torvalds, para poder gestionar el desarrollo del kernel Linux. Está
enfocado en la rapidez, la integridad de los datos (evitar corrupción de archivos) y
en los flujos de trabajo no lineales. Git permite la generación de ramas de desarrollo
alternativas (branches), así como viajar a lo largo del historial de commits.
Bitbucket: Es un servicio de alojamiento web para repositorios que utilicen los sistemas de control de versiones Git o Mercurial. Pertenece a la empresa Atlassian y está
escrito en Python. Posee diferentes planes de pago, y además permite la creación de
repositorios privados y públicos de forma ilimitada. Provee un número de usuarios
también ilimitado para el caso de las cuentas de carácter académico como la UCLM.
Es muy similar a GitHub sin embargo este último se ha alzando como el servicio de
alojamiento por excelencia para repositorios open source.
Trello: Es una aplicación online para gestión de proyectos fuertemente influenciado por
metodologías ágiles como Scrum. Permite agrupar las tareas a realizar en un proyecto
en tablones y en listas, normalmente en tres categorías, «to do», «doing» y «done»,
siguiendo con la filosofía de Scrum. Además permite colocar fechas de vencimiento y
asignar personal a cada una de las tareas y tablones.
Google Calendar: Es un sistema para gestión del tiempo en donde pueden crearse tareas (periódicas o puntuales) a lo largo del mismo y programarse para que avisen al
usuario en un determinado momento. Es una aplicación web, aunque también existe una versión móvil. Funciona en la nube como el resto de servicios de este tipo y
permite una fácil integración con el resto de componentes de Google como Gmail.
Herramientas de cara a la documentación
LATEX: Es el acrónimo de Lamport TEX, se trata de un sistema de composición de
textos con el cual está fabricado el presente documento. Está compuesto de un conjunto
de macros que permiten la creación de libros mediante elementos como capítulos,
secciones o bibliografías, entre otros, utilizando las bases del motor de TEX. Se utilizan
una serie de etiquetas que funcionan como directivas para definir la estructura general
y los estilos, conjuntamente al contenido (párrafos), todo escrito en texto plano.
GIMP:
Es un programa de edición de imágenes, es el acrónimo de GNU Image Manipulation Program. Funciona mediante rasters o mapas de bits, permitiendo el retoque,
14
la generación de formas libres y textos, la aplicación de filtros, el escalado, así como
generar recortes, todo ello mediante un sistema de capas. Muchas de las imágenes de
este documento han sido retocadas usando GIMP.
Google Drive: Es un servicio dependiente de Google para almacenamiento de ficheros
en la nube de forma similar a Dropbox. Además, incluye un paquete ofimático para
composición de textos, presentaciones y hojas de cálculo de forma colaborativa y concurrente. Existe un cliente que permite sincronizar automáticamente los archivos en
local con aquellos que residen en la nube.
Gliffy: Es un software basado en la nube que permite la generación de diagramas, entre
ellos UML o diagramas de Venn. Posee un plan de pago y uno gratuito aunque bastante
limitado. Nació de la mano de Atlassian e incluye plugins para sus productos más
famosos. En 2013 se mudaron a las tecnologías HTML5. Algunas de las imágenes de
este documento han sido creadas usando Gliffy.
Creately: Es una herramienta de diagramado y diseño de software basada en la nube
que utiliza tecnologías flash. Al igual que Gliffy permite generar UML, pero la diferencia reside en la cantidad de componentes y tipos de UML que es capaz de desplegar.
Los diagramas UML de este documento han sido generados usando Creately.
2.3.2
Hardware
Smartphone
El dispositivo móvil en el cual se ha llevado a cabo el despliegue de la aplicación es un
Huawei G510-0100 que tiene las siguientes características:
Sistema operativo Android en su versión 4.1.1 (Jelly Bean).
500MB de memoria RAM
Dimensiones 134 x 67 x 9.9 mm
CPU
Dual-core 1.2 GHz Cortex-A5
Además como segundo dispotivo de prueba se ha utilizado otro modelo de la clase Huawei,
en concreto un Huawei P8 Lite, cuyas características son:
Sistema operativo Android en su versión 5.0.2 (Lollipop).
2GB de memoria RAM
Dimensiones de 143 x 70.6 x 7.7 mm
CPU
Octa-core 1.2 GHz Cortex-A53
PC
El equipo portátil (laptop), en el que ha tenido lugar el desarrollo ha sido un Acer Aspire
5750G que tiene las siguientes características:
15
Figura 2.1: Equipos hardware utilizados a lo largo del desarrollo.
Sistema operativo GNU/Linux en su distribución Ubuntu.
8GB de memoria RAM
Intel(R) Core(TM) i5-2450M CPU a 2.50GHz
Disco duro HDD 500GB.
Tarjeta NVIDIA Geforce GT 630M,
La Figura 2.1 ilustra los dispositivos implicados en el desarrollo.
16
Capítulo 3
Antecedentes
L
A finalidad de este tercer capítulo es justificar el origen de las bases teóricas y empíricas
que han servido para inspirar el trabajo. Primero se dan unas nociones sobre cuáles
son las principales fuentes de información biométricas que sirven para determinar el estado
de estrés. Dentro de la detección de estrés mediante voz se exponen qué características se
extraen y que algoritmos de aprendizaje son los más usados por los autores más pioneros en
este campo.
3.1 Predicción del estrés a través de señales biométricas
El estrés puede ser detectado mediante gran cantidad de respuestas fisiológicas, dado que
las reacciones que desencadenan estos estados son muy variadas, desde actividad mental,
motora, térmica, sudoración, gestos, comportamiento o ritmo cardíaco, entre otros.
3.1.1
Apariencia física
Wenhui Liao et al. [19] por parte del Instituto Politécnico Rensselaer (Nueva York), presentan en su artículo un sistema de monitorización de estrés en tiempo real que toma valores
de diferentes fuentes, entre ellas la apariencia física (movimientos de cabeza, movimientos de
ojos o expresiones faciales) extraidas mediante grabaciones de vídeo, conjuntamente a fuentes fisiológicas medidas mediante un ratón de mano capaz de detectar emociones (conocido
como emotional mouse), todo ello en relación a las reacciones que el usuario experimenta
frente a una computadora.
3.1.2
Piel
Alberto de Santos Sierra et al. [30] de la Universidad Politécnica de Madrid estudian la
detección mediante dos reacciones fisiológicas. Por un lado, la respuesta galvánica de la piel
(GSR) es decir, la conductividad, ya que la resistencia eléctrica superficial varía dependiendo
de la acción de ciertas glándulas sudoríparas, sobre todo en manos y dedos. Por otro lado,
también se registra la actividad cardíaca, todo ello con el propósito de mejorar la seguridad
de sistemas que requieran mediciones biométricas (como retina o voz) ante los casos en los
que los individuos sean forzados a realizar dichas mediciones.
17
3.1.3
Actividad cerebral mediante EEG
Phuoc Nguyen et al. [24] a través de la Universidad de Canberra (Australia) proponen
un método de estracción de características utilizando las ondas cerebrales aportadas por un
electroencefalograma (EEG). Todo parte de la asunción de que al igual que la señal de voz, la
señal cerebral también contiene periodicidades a corto plazo y por tanto pueden ser aplicados
mecanismos que inicialmente fueron ideados para tratamiento de la señal acústica como los
coeficientes en la escala de Mel (MFCC).
3.1.4
Actividad cardíaca mediante ECG
G. Ranganathan et al. [25] estudian las variaciones que genera el sistema nervioso autónomo en los electrocardiogramas (ECG) para pacientes fumadores antes y después de fumar,
con hasta un total de 20 individuos. Los ECG se graban utilizando electrodos en el pecho y
o en las extremidades. Se puntualiza que dichas ondas pueden ser alteradas por problemas y
enfermedades coronarias junto al ruido electromagnético perteneciente al entorno (dispositivos móviles, circuitería, etc.).
3.1.5
Voz
Keng-hao Chang et al. [9] de la Universidad de California en Berkeley desarrollaron la
librería AMMON (Affective and mental health monitor), para reconocimiento de emociones
y demás estados a nivel mental. Se trata de una librería altamente eficiente escrita en C
que está ideada para funcionar como parte de aplicaciones móviles. La principal conclusión
que extraen los autores del artículo respecto al estrés es que, dicho estado está fuertemente
influenciado por el individuo en cuestión y resulta de mayor interés calcular aquellas variaciones de la voz dentro del propio sujeto.
3.2 Vectores de características
Dentro del análisis de la señal de voz destacan diversos factores y coeficientes, unos más
sofisticados que otros. Trabajos previos demostraron la utilidad de características como el
número de cruces por cero (ZCR), los coeficientes cepstrales en la escala de Mel (MFCC) o
la energía de la señal.
3.2.1
Coefiecientes ceptrales en la escala de mel (MFCC), número de cruces
por cero (ZCR) y energía
A. Milton et al. [21], defienden la utilización de los MFCC como mecanismo ampliamente
reconocido en el campo del reconocimiento del habla y destacan sus numerosas ventajas,
como una complejidad computacional baja requerida en su cálculo y la robustez frente al
ruido blanco. Además incluye como elementos adicionales el número de cruces por cero de
la señal y la energía en cada momento (véase el Capítulo 4 para más detalle). También son
utilizados por [9] junto con otros como el tono (pitch) y los tiempos glotales (la glotis es el
18
espacio definido entre las cuerdas vocales).
3.2.2
Coeficientes delta
Virginia Sandulescu et al. [28] describen la implementación de una aplicación móvil de
reconocimiento de estrés utilizando los ya mencionados MFCC, pero incluyendo como novedad los coeficientes delta que describen la dinámica de los anteriores. Esta es la aproximación
que se sigue en el presente trabajo, sin embargo la aplicación descrita en este artículo tiene
una estructura radicalmente distinta ya que utiliza un servidor centralizado para manejo de
información, entre otros factores.
3.2.3
Parámetro cepstral basado en sub-banda (SBC)
K.V.Krishna et al. [18] hablan sobre la computación afectiva como aquella que intenta reconocer y simular emociones humanas. En cuanto al reconocimiento utilizan los parámetros
MFCC conjuntamente a los SBC para reforzar la clasificación, evitar la influencia del ruido
y mejorar los resultados. Comentan que el éxito de la clasificación aumenta desde un 51 %
hasta un 70 % gracias al uso de los SBC.
3.3 Mecanismos de clasificación
Dentro del análisis de voz, se han utilizado diversas técnicas de aprendizaje automático
para llevar a cabo el reconocimiento de patrones, de forma que se han demostrado aptas
para su uso en este ámbito. Entre los clasificadores más usados se encuentran los árboles de
decisión, las máquinas de vectores de soporte y las redes neuronales.
3.3.1
Modelos de mezclas gaussianas (GMM)
Xianglin Cheng et al. [10] en su artículo focalizan la atención en la detección de emociones
de forma general, más que en un modelo de estrés concreto, aunque utilizando como fuente la voz. Determinan 5 emociones humanas a ser detectadas incluyendo enfado, sorpresa,
felicidad, neutralidad y tristeza. Dentro del clasificador por modelos de mezclas gaussianas
que utilizan, destacan el método de máxima de probabilidad como algoritmo para encontrar
valores paramétricos. La Figura 3.1 muestra de forma intuitiva el principio de los GMM para
obtener la probabilidad total utilizando distribuciones normales.
3.3.2
Redes neuronales
Jagvir Kaur et al. [17], también defienden el reconocimiento de emociones aunque no
especifican cuáles en concreto. A la hora de implementar el esquema de red neuronal dividen
en dos conjuntos, uno para entrenar y otro para testear, y a raíz de ahí marcan cada archivo
de audio relacionado con cada emoción independientemente. La Figura 3.2 ejemplifica el
esquema genérico de una red neuronal.
19
Figura 3.1: Composición de una distribución utilizando componentes Gaussianas.
Figura 3.2: Esquema general de una red neuronal con entradas y salidas.
20
3.3.3
Árboles de decisión
Pablo Hernandez-Leal et al. [15] analizan el estrés en el ambiente de trabajo. Puede obtenerse información sobre el comportamiento de forma no intrusiva mediante los smartphones,
aunque bajo ciertas circunstancias el nivel de datos recogidos pueden ser escasos, por ende,
un buen modelo del usuario puede no ser obtenido. Para lidiar con estas limitaciones se utilizan árboles de decisión con el fin de determinar 3 niveles de estrés (alto, medio y bajo).
3.3.4
Deformación dinámica del tiempo (DTW)
Lindasalwa Muda et al. [22], tratan exclusivamente sobre algoritmos de reconocimiento
de voz, destacan que el principal objetivo de dicho campo consiste en identificar tres componentes, el género, las emociones y la identidad del hablante y para ello combinan técnicas
de MFCC con DTW. Este último es un algoritmo que mide la similitud entre dos secuencias
temporales que pueden variar en velocidad, por ejemplo podría utilizarse para medir la similitud en la conducción de dos individuos que recorriesen diferentes tramos de una ciudad a
diferentes ritmos.
3.3.5
Máquina de vectores de soporte (SVM)
Los trabajos de [21] toman una aproximación bastante compleja en cuanto a la aplicación
de SVM se refiere, dicho algoritmo es el escogido para el presente proyecto. Sostienen la
utilización del clasificador en tres etapas, realizando 3 clasificaciones binarias para un total
de 7 estados, de forma que las salidas del primer clasificador indican el criterio que debe
utilizar el segundo, y el segundo con el tercero. Dependiendo de la ruta seguida la voz se
enmarca dentro de alguno de esos 7 estados.
3.4 Trabajos por parte de esta universidad
Christian Carretón [26], un antiguo alumno de la Universidad de Castilla-La Mancha ideó
un sistema para la monitorización del asma conocido como S I M OA. El objetivo de esta aplicación era crear un mecanismo útil por el cuál enfermos asmáticos pudieran determinar su
estado respiratorio sin recurrir a incómodas espirometrías o caros especialistas, utilizando las
mismas bases que el trabajo actual. Se ha hecho uso de la implementación básica que proporcionaba este proyecto en cuanto a extracción de características sonoras que fue desarrollado
conjuntamente con el laboratorio MA M I de la misma universidad.
Una vez se ha definido el estado del arte y se han expuesto todas las posibilidades y
variantes por parte de los autores más relevantes, toca decidir que camino seguir y definir
con detalle las bases y las etapas necesarias para llevar a cabo con éxito la finalidad del
proyecto.
21
Capítulo 4
Tratamiento de la Voz
E
capítulo es parte del núcleo del presente proyecto, ya que expone las bases teóricas
matemáticas y físicas referentes al tratamiento de la señal de audio y sus diferentes fases. Se detallan qué características y formato deben poseer los audios con los que se trabaja.
Asimismo se explica el proceso de filtrado del audio y los parámetros y criterios de error asociados. Por último se detallan qué valores se extraen del audio de cara a la clasificación.
STE
4.1 Características del audio
A pesar de que el audio sea una señal continua, para poder ser almacenada en un archivo
debe ser discretizada a lo largo del tiempo mediante dos procesos:
Muestreo: Consiste en tomar valores de la señal analógica a intervalos regulares en
base a un período T , de modo que, siendo F (n) la función que devuelve un valor de
amplitud de la señal analógica en base a un tiempo n, la versión discretizada f [n] se
compondrá en base a la Ecuación 4.1.
f [n] = {F (0), F (Ts ), F (2 · Ts ), ..., F (n · Ts )}
(4.1)
Por tanto el audio es tan sólo un vector de valores de amplitud a ojos de la máquina.
Por otra parte el Teorema de Nyquist establece la frecuencia de muestreo necesaria,
especificando que debe ser al menos el doble de la frecuencia más alta presente en la
señal analógica que requiera ser procesada, con el objetivo de que la señal digital sea
fiel a la original. Lo más común es que la frecuencia de audio vaya desde los 8000 Hz
hasta los 44000 Hz. A mayor frecuencia mayor cantidad de muestras y por ende mayor
calidad del audio. La frecuencia de muestreo sobre la que se trabaja a lo largo del
proyecto es de 11025 Hz. Dado que la voz humana es capaz de generar frecuencias de
hasta 4000 Hz, según el teorema de Nyquist la frecuencia mínima debería ser 8000 Hz,
sin embargo se utiliza un muestreo ligeramente superior debido a ciertos factores en la
extracción posterior. Utilizar una frecuencia aún mayor sería un gasto computacional
que no produciría mejores resultados y retrasaría la ejecución de la fase de extracción.
Cuantificación y codificación: Estos pasos son dos procesos que van de la mano, la
23
Figura 4.1: Comparación de un señal con su versión discretizada.
cuantificación es una función que mapea los valores de amplitud a un conjunto de
valores discretos, normalmente al más cercano numéricamente. Dicha aproximación
provoca un error conocido como error de cuantificación. La codificación por su parte
establece cuál es el conjunto de valores discretos (la imagen de la función), que viene
dada principalmente por la combinación de un número determinado de bits. A mayor
número de bits mayor es el peso de cada muestra de forma individual. La codificación
que se utiliza en los audios del proyecto es de 16 bits, se considera suficiente para
obtener una buena calidad.
El resultado de todo el proceso queda reflejado en la Figura 4.1.
4.1.1
Formato
De cara al procesamiento (que es la etapa más pesada y delicada de toda la cadena) se
utilizan audios en formato WAV. Cada fichero de audio contiene unos streams de valores de
amplitud (PCM) conjuntamente a unas cabeceras con metadatos (ver Figura 4.2), este formato tiene la condición añadida de que no realiza compresión con pérdidas sobre el archivo,
de hecho no realiza ninguna compresión, lo que permite salvaguardar aquellos valores de
frecuencia que son débilmente percibidos por el oído humano pero que son decisivos en la
clasificación. Otros formatos más convencionales como MP 3 sí que realizan compresión con
pérdidas y no son aptos para su utilización en el presente trabajo.
4.2 Filtrado y VAD
De todo el audio que se recoge obviamente no todo es voz que pueda ser aprovechada,
siempre existen pausas en cualquier discurso y no sólo eso, sino que puede haber fuentes
externas de ruido que puedan estar afectando significativamente al proceso. Para abordar
estos problemas se utilizan técnicas conocidas como VAD (Voice Activity Detection), que
permiten detectar la presencia o ausencia de voz humana en una grabación. Por tanto, el proceso de filtrado consistirá en la aplicación de algún algoritmo que recorra el audio ignorando
aquellas zonas en las no haya actividad.
24
Figura 4.2: Estructura del formato WAV.
25
Una gran parte de los algoritmos VAD utilizan mecanismos de autocorrelación como criterio. En estadística, la correlación de dos variables indica la relación de proporcionalidad
entre dichas variables, es decir, si al aumentar una aumenta la otra, y viceversa, siempre de
forma sistemática. La autocorrelación consiste en la correlación de una señal consigo misma
desplazada un tiempo delta. Esto es de utilidad para encontrar patrones repetitivos dentro de
la función.
Por otro lado el ruido conocido normalmente como «ruido blanco», es una señal aleatoria
cuya principal característica es que carece de correlación, además posee la misma densidad
espectral a lo largo de toda la banda de frecuencias al contrario que los armónicos. La voz
a diferencia del ruido es una señal periódica y por lo tanto su autocorrelación también es
periódica, comparada con la del ruido que no lo es. Cuando se hace la media de los valores
de autocorrelación estos tienden a cero para el caso del ruido (o señales sin correlación) y
tiende a valores mayores para el caso de señales periódicas, sirviendo como un buen criterio
para detectar voz, obviamente este principio también funciona para el caso del silencio. La
expresión que define la correlación de una señal discreta y[n] consigo misma a partir de un
tiempo delta d es la que se define en la Ecuación 4.2.
−1
1 NX
y[n] · y[n − d]
·
Ryy (d) =
N n=0
4.2.1
(4.2)
Umbral
Como ya se ha explicado anteriormente la media de los valores de autocorrelación tiende
a cero pero nunca es completamente cero, debido a algunas periodicidades fruto de la aleatoriedad. Se hace por tanto necesario la utilización de un umbral debajo del cuál consideremos
que la señal se considera ruido blanco y puede ser eliminada, valores muy altos del umbral
causarían la eliminación de fragmentos de voz valiosos mientras que valores excesivamente
bajos podrían preservar fragmentos no deseados.
Existen algoritmos que permiten ajustar de forma dinámica el valor del umbral analizando
el fichero de audio en cuestión, sin embargo suponen una sobrecarga más al sistema y en
el caso que nos concierne no aportan demasiado, ya que no se requiere una precisión tan
estricta, aunque resultaría prioritario como parte del trabajo futuro (véase Capítulo 8). Al
contrario, la estrategia aquí será utilizar un valor estático, debidamente justificado de forma
empírica mediante cuatro criterios de error. Se ha realizado una validación de forma experimental durante la implementación, utilizando varios fragmentos de audio recogidos con el
smartphone.
Todos los criterios siguen la Ecuación 4.3, donde NS es el número de muestras totales que
componen el audio de prueba y NM es el número de muestras mal clasificadas dependiendo
del criterio. Las muestras que componen los períodos de voz y ruido son etiquetadas como
26
Figura 4.3: Actividad real comparada con actividad detectada, y los cuatros criterios de error.
activas o inactivas de forma previa a la aplicación del algoritmo, con el objetivo de determinar
cuáles han sido omitidas. El resultado de los criterios es siempre un porcentaje de error que
debe intentar ser reducido.
NM
· 100
(4.3)
Error =
NS
Front End Clipping (FEC): Error al detectar como ruido la voz inicial en una transición
de ruido a voz.
Over Hang (OVER): Error al detectar como voz el ruido inicial en una transición de
voz a ruido.
Mid-Speech Clipping (MSC): Error al detectar como ruido la voz en mitad de un período de voz.
Noise Detected as Speech (NDS): Error al detectar como voz el ruido en mitad de un
período de ruido.
De forma minuciosa se han comprobado los niveles de error para 30 segundos de audio neto, correspondiente a 3 grabaciones diferentes. Se han realizado varias iteraciones,
hasta escoger el valor del umbral igual a 0’00006. Una vez que se aplica dicho parámetro
utilizando el algoritmo de detección a las grabaciones de prueba, se obtienen aproximadamente 23 segundos de voz. Aunque la Ecuación 4.3 utiliza muestras, pueden utilizarse
también tiempos en segundos, puesto que son dos unidades proporcionales (M uestras =
F recuencia · T iempo), en todo caso los niveles de error se han mantenido por debajo del
0’3 %, porcentaje que se considera satisfactorio. Se ha detectado que fragmentos de voz muy
breves y con poca energía son los más propensos a ser eliminados (véase Figura 4.4).
Existe una familia de algoritmos conocido como PSO (particle swarm optimization) que
son genéricos para diversos tipos de problemas de optimización, por ello pueden utilizarse
27
Figura 4.4: Ejemplo de un fragmento de audio eliminado entre dos zonas de silencio, supone
un incremento de los ratios de error FEC y MSC.
para generar un umbral dinámicamente dado que el problema de determinar dicho parámetro
es un caso de optimización automática. PSO permite encontrar un candidato de forma iterativa utilizando un espacio de búsqueda e intentando minimizar los criterios de error antes
mencionados para cada audio.
Una vez que el audio está listo, se debe definir qué representación del mismo puede ser
útil para identificar estrés.
4.3 Representación de los datos
Utilizar los valores de amplitud del audio de forma directa para clasificar no es una buena
aproximación, en su lugar se utilizan características extraídas del mismo utilizando procedimientos matemáticos y algorítmicos bajo una base justificada y probada. Cada vector de
características resume el contenido de cada fragmento o ventana compuesto por una pequeña
cantidad de valores de audio. En este caso partimos de los coeficientes cepstrales en la escala
de Mel, entre otros.
4.3.1
MFCC
Los coeficientes cepstrales en la escala de Mel (Mel-frequency cepstral coefficients), son
un tipo de valores cepstrales de representación del audio. Un cepstrum es el resultado de aplicar la transformada inversa de Fourier, mientras que la escala de Mel es una representación
logarítmica (frente a la lineal) del espectro de frecuencias de audio. Esta escala (medida en
mels en vez de hertzios) supone una aproximación mucho más fiel a cómo el oído humano
percibe los cambios de frecuencia, es decir, es mucho más sensible identificando frecuencias
graves y no tan útil para diferenciar las agudas. Estos valores se utilizan en el campo del
reconocimiento automático del habla, un ejemplo bastante común sería el reconocimiento de
28
Figura 4.5: División de cada segmento de audio en subsegmentos.
números hablados al teléfono [14]. También se utilizan en el campo de la música, permitiendo determinar características como el género de una canción [23].
Para obtener dichos coeficientes deben seguirse los siguientes pasos [3]:
1. Pre-énfasis: Es un procedimiento realizado con el fin de incrementar las frecuencias
altas respecto de las bajas, es lo contrario de la atenuación.
2. División: El audio se fragmenta en pequeños segmentos, para este proyecto en concreto dichos segmentos son de entre 10 y 20 milisegundos, con un solapamiento entre
ellos de 5 ms (véase Figura 4.5). El número de muestras de cada segmento será igual
a su duración multiplicado por la frecuencia de muestreo (11025 Hz).
3. Enventanado de Hamming: Una función de ventana es una función que es evaluada a
cero fuera de algún intervalo determinado, en este caso debe aplicarse sobre todos los
segmentos de forma independiente. En el caso de Hamming, su función es suavizar
las frecuencias falsas originadas al efectuar cortes bruscos en la etapa anterior (véase
Figura 4.6). Sigue la Ecuación 4.4, donde N es el número de de muestras del segmento,
α suele tomar el valor 0, 54 mientras que β = 1 − α.
w(n) = α − β cos(
2πn
)
N −1
(4.4)
4. Transformada rápida de Fourier (FFT): El análisis de Fourier es el estudio de las formas en las cuáles funciones pueden ser representadas o aproximadas mediante sumas
de otras funciones trigonométricas simples, convierte una señal desde su dominio original en el tiempo a un dominio de la frecuencia [27]. En concreto la transformada
rápida es un tipo de transformada discreta de cómputo rápido, evadiendo la comple29
Figura 4.6: Ventana de Hamming en el intervalo [0, N − 1].
jidad de de la transforma clásica que es cuadrática (O(n2 )). Los valores de los coeficientes cepstrales por ende representan la contribución de cada una de la funciones
sinusoidales ordenadas por frecuencia a la señal de audio total que en el fondo es una
función más. Las magnitudes de los números complejos resultado de la transformada
son computadas dando lugar a un periodograma (véase Figura 4.7).
5. Banco de filtros de Mel: Son un conjunto de filtros triangulares (en este caso 13).
Aquí es donde la escala de Mel hace su aparición (véase Figura 4.8), puesto que la
separación de estos filtros (que existen en el dominio de la frecuencia) sigue dicha
escala, la Figura 4.9 representa de forma intuitiva la posición de estos filtros. De alguna
forma atenúa las frecuencias altas obtenidas en el periodograma y amplifica las bajas
dándoles más peso.
6. Logaritmo: Es necesario tomar el logaritmo de las energías de cada frecuencia. Es
parte del cómputo del cepstrum, utilizando las propiedades de los logaritmos se pueden
alterar ciertas operaciones (productos en adiciones).
7. Transformada discreta del coseno (DCT): Es un tipo de transformada en el cual las
funciones trigonométricas que componen la señal son únicamente cosenos oscilando
a diferentes frecuencias. La función de esta transformada es llevar a cabo el proceso
inverso a la transformada rápida de Fourier volviendo al dominio de tiempo nuevamente. El resultado sería la señal original si no fuera por las operaciones que se han
realizado en mitad del proceso, se podría decir que es el mismo audio pero escuchado
por el oído de una persona. Para esta operación se podría realizar la inversa de la transformada discreta de Fourier, sin embargo se prefiere la DCT ya que posee propiedades
de compresión y de decorrelación bastante útiles.
30
Figura 4.7: Ejemplo del resultado de una FFT para el caso de frecuencias infrasonoras. Amplitud en el eje de ordenadas medido en voltios.
Figura 4.8: Comparativa de la frecuencias equivalentes en Mels y en Hertzios.
Figura 4.9: Banco de filtros de Mel.
31
El resultado son 13 valores de los cuáles el primero se descarta dado que corresponde
con la componente continua de la señal cuya frecuencia es nula y que no aporta nada al
análisis.
Los componentes cepstrales son la base de la clasificación, sin embargo no es la única
representación de la señal que se requiere, puesto que las características derivadas que se
explicarán a continuación ayudan significativamente al proceso.
4.3.2
Coeficientes delta
Son conocidos como los coeficiente diferenciales, mientras que los MFCC’s describen la
parte estática de la señal los deltas lo hacen con la dinámica. Existe gran cantidad de información en las trayectorias de los coeficientes cepstrales que es reflejada mediante sus correspondientes coeficientes deltas. Cada MFCC tiene asociado su delta a lo largo del tiempo. La
expresión para obtener estas características es la Ecuación 4.5.
N
X
dt =
n (ct+n − ct−n )
n=1
2
N
X
(4.5)
n
2
n=1
Donde dt es el coeficiente delta para un segmento t, ct es el coeficiente cepstral para el mismo segmento y N es una constante que normalmente vale 2 o 3, a mayor valor de N mayor
es el rango alrededor del segmento que se toma en cuenta para generar el coeficiente.
Existen otro tipo de valores llamados delta-delta o doble-delta que son conocidos como los
componentes de aceleración, estos componentes son extraídos mediante la misma expresión
anterior pero utilizando los delta simples en vez de los MFCC, ya que mide la variación
de los primeros respecto del tiempo. En este caso los coeficientes doble-delta no han sido
utilizados.
4.3.3
Energía y número de cruces por cero
El número de cruces por cero (ZCR) es una medida del número de veces que una señal corta
el eje de abscisas o pasa por el valor cero de amplitud. Este valor y la energía contenida en el
segmento son dos parámetros extras que también son representativos en la clasificación y que
pueden ser añadidos al vector de características haciendo así un total de 26 componentes por
segmento. El número de cruces por cero puede computarse utilizando la Ecuación 4.6.
zcr =
N
X
|sgn(xi ) − sgn(xi−1 )|
2
i=1
(4.6)
Donde sgn es la función de signo que devuelve 1 o −1 dependiendo de si el signo es
positivo o negativo. Si el signo cambia de una muestra a otra aumenta en uno el ZCR.
32
Figura 4.10: Representación del vector de características que se genera para cada segmento
de audio.
La Figura 4.10 es una representación intuitiva del vector de características resultante, compuesto por los 12 MFCC, los 12 coeficientes delta, la energía y el ZCR.
Una vez que se ha determinado la representación de los datos y su obtención, se necesita
definir un algoritmo de aprendizaje que se adapte a las necesidades para poder empezar a
trabajar con los vectores de características.
33
Capítulo 5
Clasificacion y Concurrencia
E
parte trata de aquellos mecanismos de aprendizaje y predicción utilizados para
determinar los niveles de estrés, y que utilizan las características presentadas en el
capítulo anterior. Igualmente, se realiza un estudio de la precisión de la clasificación y se
justifica la creación de un modelo de aprendizaje que sirva como modelo universal de estrés. Por último se exponen detalles de la implementación así como las diferentes clases y
niveles de concurrencia, una vez que los resultados del estudio antes mencionado han sido
satisfactorios.
STA
5.1 Aprendizaje automático
Es una subcategoría dentro de las ciencias de la computación que emergió del estudio del
reconocimiento de patrones y las teorías de aprendizaje computacional, dentro del campo de
la inteligencia artificial (IA). El aprendizaje automático incluye el estudio y la construcción
de algoritmos que puedan hacer predicciones sobre conjuntos de datos. Todos cumplen el
mismo patrón, utilizan un modelo precomputado partiendo de un ejemplo conocido como
conjunto de entrenamiento, sirviendo como entrada al algoritmo. Dicho conjunto de entrenamiento es un grupo de observaciones que sirven para poder realizar predicciones dirigidas
por datos («data-driven predictions»), dichas decisiones serán las salidas del algoritmo.
La programación dirigida por datos es un paradigma de programación que en vez de definir una secuencia de pasos a tomar (como en el caso de la programación imperativa), lo que
define son sentencias que describen los datos sobre los cuales trabajar y el procesamiento que
es requerido. Existen lenguajes de programación que trabajan sobre texto los cuales seleccionan un archivo y trabajan sobre la secuencia de líneas que lo componen, además la selección
de datos en estos casos se realiza mediante expresiones regulares principalmente, estas expresiones regulares y los motores que las computan aparecen en la mayoría de lenguajes de
programación. De forma genérica se podría decir que se aplica a streams de datos o bien,
información estructurada, para su agregación, filtrado, transformación y demás operaciones
relacionadas. Todos las entradas a un algoritmo de aprendizaje automático son conjuntos de
datos que deben ser procesados siguiendo esta filosofía. Los tipos de aprendizaje automático
son tres:
35
Aprendizaje supervisado: Se presentan las entradas y las salidas deseadas de forma
que el algoritmo debe extraer una regla o función que mapee del primer conjunto al
segundo.
Aprendizaje no supervisado: No hay pistas que se provean al algoritmo sobre cuáles
deben ser las salidas, de forma que él es el responsable de encontrar la estructura y
determinar sus salidas adecuadamente a partir de sus propias entradas. Este tipo de
aprendizaje puede ser un fin en sí mismo o puede llevar al descubrimiento de patrones
ocultos en los datos.
Aprendizaje reforzado: El algoritmo tiene que alcanzar una meta sin nada que le aporte
una perspectiva de cómo de cerca está de ella. Un ejemplo sería un juego dónde una
máquina debe enfrentarse a un oponente.
El tipo de problema al que nos encontramos es del tipo supervisado ya que, dejamos
que el algoritmo infiera la función de clasificación utilizando un conjunto de entrenamiento
etiquetado. Debemos por tanto tener claro qué muestras de entrenamiento se corresponden
con estrés y cuáles con relajación (véase Sección 5.2) a la hora de alimentar al algoritmo.
5.1.1
Aprendizaje supervisado
En este tipo de algoritmos cada ejemplo es una tupla, que consiste en un valor de entrada
(por regla general se trata de un vector) conjuntamente a un valor de salida esperado. Tras
analizar el conjunto de entrenamiento se infiere una función que permite ser aplicada sobre
nuevos valores de entrada. En el mejor de los casos el algoritmo debería ser capaz de determinar de forma precisa para aquellas instancias que todavía no han sido vistas. Los pasos
que se deben seguir para resolver un problema de este tipo son:
1. Decidir qué tipo de muestras utilizar.
2. Recoger un conjunto de entrenamiento. Este conjunto debe ser representativo para
poder ser útil en un contexto real.
3. Definir la representación de los datos. El vector de características no debe contener
un número de variables excesivo (dimensionalidad), pero debe contener la suficiente
información.
4. Determinar el tipo de algoritmo de aprendizaje (SVM, modelos de mezclas gaussianas,
árboles de decisión, etc.).
5. Determinar los parámetros bajo los cuales trabajará el algoritmo. Estos parámetros
se ajustan para optimizar el rendimiento usando técnicas como la validación cruzada
(véase Subsección 5.3.4).
6. Evaluar la precisión de los resultados. Deben realizarse comprobaciones sobre otro
conjunto conocido como conjunto de prueba.
36
Algunos de estos pasos ya fueron llevados a cabo en el capítulo anterior, como decidir la
representación de los datos, otros serán definidos en la sucesivas secciones.
5.2 Modelo
Definir a nivel subjetivo el concepto de «voz estresada» es algo complicado, podríamos
decir que se corresponde con un nivel de energía mayor, una mayor tensión, un tono y una
cadencia bastante fuertes. A nivel objetivo (físico) podrían determinarse que patrones existen
en cuanto a nivel de onda se refiere. No obstante, no se requiere definir estos patrones, dado
que el algoritmo de aprendizaje una vez entrenado es capaz de identificar ambos. Con tal fin
es necesario hacerse con las muestras de audio que contengan ambos estados.
La estrategia a seguir es utilizar una serie de voluntarios para realizar las grabaciones
oportunas, se pueden utilizar recursos externos pero éstos rara vez reúnen las condiciones de
formato y voz adecuadas. En el proceso de búsqueda se tuvo acceso a diferentes repositorios
de voces por parte de diferentes universidades entre ellas Imperial College of London, sin
embargo no se ajustaban demasiado a los audios requeridos y la variedad de individuos era
muy pobre.
El actual conjunto de entrenamiento que conforma el modelo de aprendizaje se compone
de las voces de 5 voluntarios (3 hombres y 2 mujeres). Es fundamental que el modelo no
sea excesivamente pesado pero que contenga la mayor cantidad de voces posibles (mujeres,
hombres, niños, personas mayores, etc.), con el fin de crear un clasificador de estrés universal
que sea extrapolable a cualquier persona. El modo de proceder es grabar al voluntario en
dos momentos distintos utilizando algún fragmento de texto que es leído en voz alta, en el
primero de los casos se pide al voluntario leer con suma tranquilidad y relajación tras haberle
sometido durante varios minutos a música relajante. En el segundo de los casos la situación
es a la inversa, leyendo el mismo texto tras haberse inducido al voluntario a una situación
de estrés mediante otro tipo de audios. El proceso no siempre es fácil, es necesario guiar
al individuo y repetir la grabación varias veces en algunas situaciones. La razón de utilizar
un mismo texto (por ejemplo un discurso), permite dar cuenta de aquellas diferencias que
dependen del estado de la persona y no de pronunciación o énfasis de un determinado párrafo.
Al final se obtienen 10 audios listos para componer el modelo, que son transformados a un
total de 1249 vectores de soporte. Este fichero de datos es un recurso estático que se carga
con cada clasificación. Hay que tener en cuenta que las muestras no son los audios completos
sino pequeños fragmentos o picos que se han considerado especialmente representativos del
estrés o relajación.
La eficacia del conjunto de entrenamiento deberá ser testeada como último paso utilizando la validación cruzada (véase Subsección 5.3.4), pero para ello se debe antes definir el
algoritmo de aprendizaje, si se diese el caso de que los resultados fueran negativos habría
tres opciones, o bien el conjunto de prueba no es apto, o bien el de entrenamiento no lo es,
37
Figura 5.1: A la izquierda distribución de puntos en un espacio 2D a la derecha la división
del espacio utilizando SVM.
o en última instancia podría ser culpa del vector de características, de ello se hablará en la
siguiente sección.
5.3 SVM
Es el acrónimo de máquina de vectores de soporte (support vector machine) también conocido como redes de vectores de soporte, que en el contexto del aprendizaje automático se
trata en realidad de un conjunto de algoritmos. Fueron postulados y desarrollados por primera vez por los laboratorios AT&T. De forma intuitiva se puede decir que SVM se encarga de
colocar los puntos de muestra en el espacio (que en este caso es multidimensional con 26 variables) e intenta separar las clases por un espacio lo más amplio posible (véase Figura 5.1).
De forma genérica podríamos decir que intenta buscar un hiperplano, es decir un subespacio con una dimensión menos que pueda dividir las muestras iniciales. Un hiperplano en
el caso de 26 dimensiones tendría 25, así como un línea es un hiperplano del espacio 2D o
un plano convencional lo es para un espacio 3D. Un subespacio permite dividir a su espacio ambiente original. Por lo general, la aproximación será mejor cuanta más distancia haya
entre el hiperplano y el punto de entrenamiento más cercano a él, aunque por otro lado el
error de generalización será peor ya que existe un espacio más grande sin documentar muy
cercano al hiperplano.
5.3.1
Parámetros
Existen un gran conjunto de parámetros ajustables dentro del clasificador, pero hay dos
especialmente influyentes en el resultado:
Coste (C): Se le conoce como constante de capacidad, se utiliza en las funciones de
38
error, es una forma de decirle al algoritmo qué nivel de precisión se requiere. Se aplica
en el tipo de SVM (véase Subsección 5.3.2).
Valor gamma (γ): Es un valor que se aplica a nivel de kernel (véase Subsección 5.3.3)
y se define como la inversa del radio de influencia de una muestra. Esto quiere decir
que determina la influencia de unas unas muestras respecto a otras.
5.3.2
Tipos
emplea un algoritmo de entrenamiento iterativo para intentar minimizar una función
de error. Dependiendo de como sea la función de error se pueden clasificar los modelos de
SVM en cuatro categorías [32]:
SVM
C-SVC (clasificación SVM tipo 1).
Nu-SVC (clasificación SVM tipo 2).
Epsilon-SVR (regresión SVM tipo 1).
Nu-SVR (regresión SVM tipo 2). No confundir con el segundo tipo mencionado, ya
que este se utiliza para regresión.
En tanto que el presente ejercicio es un problema de clasificación sólo se pueden utilizar
los dos primeros tipos. En concreto se ha utilizado el segundo (nu-SVM) que es el que mejor
resultados ha generado de forma empírica.
5.3.3
Kernels
Un kernel es una función de similitud que toma dos valores o muestras y determina su parecido. Muchos algoritmos de aprendizaje pueden ser escritos únicamente usando productos
escalares, de forma que estos productos escalares pueden ser reemplazados por kernels con
el objetivo de reducir la complejidad de un cálculo que puede implicar potencialmente infinitas dimensiones [5]. Los kernels disponibles para SVM vienen definidos en las ecuaciones
de la 5.1 a la 5.4.
Lineal:
K(xi , xj ) = xTi xj
(5.1)
K(xi , xj ) = γ(xTi xj + r)d , γ > 0
(5.2)
Polinomial:
RBF
(Radial Basis Function):
K(xi , xj ) = exp(−γ||xi − xj ||2 ), γ > 0
(5.3)
K(xi , xj ) = tanh(γxTi xj + r)
(5.4)
Sigmoid:
39
Como ya se mencionó anteriormente, γ es un parámetro que aparece en la expresión de
la mayoría de estos kernels, entre otros como d (grado) y r (coeficiente cero). El kernel
escogido ha sido RBF.
5.3.4
LibSVM
Se trata de una librería integral de SVM que sirve tanto para clasificación (C-SVC, nu-SVC)
como para regresión (epsilon-SVR, nu-SVR) [16], también soporta clasificación multiclase
aunque el problema en este caso consiste en una clasificación binaria. Antes de implementar
usando el API de la librería, se ha utilizado la utilidad por línea de comandos (que trabaja
con archivos de texto), con el fin de corroborar todo lo dicho hasta el momento. Además de
los tipos y los kernels, SVM también aporta una gran cantidad de herramientas tanto para
validación cruzada, representación de datos o escalado.
Escalado
El escalado de los datos es un proceso por el cual el rango de los datos pasa de estar
en un intervalo desconocido de antemano a estar en uno definido. La principal ventaja es
evitar que atributos en una escala numérica muy grande predominen sobre aquellos en una
escala inferior, también agiliza el proceso de cálculo. La escala por defecto es la [-1, 1] y
es la más recomendable, por supuesto es necesaria aplicar la misma escala tanto para los
conjuntos de entrenamiento, como los de prueba, como aquellos que deban ser procesados
en producción.
Validación cruzada y búsqueda en malla
La estrategia de validación cruzada consiste en dividir el conjunto de muestras en n subconjuntos, de forma que n − 1 conjuntos se utilizan para entrenar el algoritmo, mientras que
uno de ellos se utiliza para pruebas. La precisión es el número de elementos del conjunto
total que han sido correctamente clasificados en las n iteraciones, frente a los que no.
Por otro lado la búsqueda en malla (que hace uso de la validación cruzada) tiene como
fin encontrar valores óptimos a ciertos parámetros del algoritmo. Tal como se explicó en la
Subsección 5.3.1, se requieren dos parámetros decisivos llamados C y γ, sus valores no son
conocidos de antemano y varían dependiendo del tipo de problema, por lo tanto es necesario
determinarlos con el fin de obtener unos buenos resultados. La búsqueda es un problema de
optimización, trata varios pares de (C, γ) de manera que iterando y teniendo como heurística
el porcentaje de éxito, los parámetros se aproximan a su valor óptimo, existen algoritmos
mucho más sofisticados y rápidos para encontrar estos valores pero se opta por la búsqueda
en malla por su simplicidad. Los resultados son los que se muestran en la Figura 5.2, tras lo
cual se deduce que los mejores valores son aproximadamente C = 2 y γ = 0,001953125.
En el proceso se definen las áreas de probabilidad, la mejor de todas ellas tiene un nivel de
precisión del 96 %. Hay que tener en cuenta que el conjunto consistente en los 10 fragmen40
Figura 5.2: Gráfico generado por gnuplot y la herramienta grid.py, define las áreas de probabilidad en función de γ (ordenadas) y C (abscisas).
tos de los 5 voluntarios antes mencionados (véase Sección 5.2) componen un total de 1249
muestras sobre las que se ha aplicado la validación. Esta primera aproximación nos da un visión de que efectivamente la clasificación está siendo exitosa, teniendo en cuenta que siendo
binaria, un modelo aleatorio obtendría un 50 % de precisión.
5.4 Resultados
Para asegurar que el proceso es correcto se ha utilizado un criterio de validación cruzada
todavía más estricto. En este caso se ha utilizado un 85 % de las muestras para entrenar y un
15 % de ellas para testear, pero con una diferencia respecto a las pruebas anteriores: las muestras en vez de dividirse en conjuntos arbitrarios han sido seleccionadas de forma aleatoria.
Para automatizar el proceso se ha escrito un script BASH definido en el Listado 5.1
Al inicio del script se deben declarar varias constantes, como el tipo de SVM, el kernel, los
parámetros, la ubicación de la librería, el porcentaje de prueba (85 %) y el directorio con los
datos del participante. Las líneas del archivo de datos se barajan mediante el comando shuf y
se escalan mediante la correspondiente herramienta svm-scale. Se calcula el número de líneas
procesando la salida del comando wc, para posteriormente dividir el archivo mediante el
comando split, generando dos archivos, uno con el 85 % de las entradas y otro con el 15 %.
A continuación se entrena un modelo mediante la herramienta svm-train y se predicen los
resultados para el conjunto de prueba. Como el conjunto de prueba está también etiquetado,
41
#!/bin/sh
# -*- mode:bash -*LIBSVM=./libSVM-3.21
TRAIN_PERCENTAGE=85
SVM_TYPE=1
KERNEL=2
DIR=./person-x
C=2
G=0.001953125
# Shuffle & split files
shuf $DIR/raw.data > shuffled.data
$LIBSVM/svm-scale shuffled.data > scaled.data
lines=‘wc -l scaled.data | cut -d" " -f1‘
per=‘expr $lines \* $TRAIN_PERCENTAGE / 100‘
split -l $per scaled.data
mv xaa training.data
mv xab testing.data
# Use SVM train & predict
echo Training...
$LIBSVM/svm-train -s $SVM_TYPE -t $KERNEL -g $G -c $C training.data model > /dev/null
echo Predicting...
$LIBSVM/svm-predict testing.data model prediction.out >> results.out
echo "Finished!"
# Clean
rm -f shuffled.data scaled.data xa* training.data testing.data
Listado 5.1: Listado del script BASH para validación de los datos.
la herramienta es capaz de comparar y definir la precisión.
Los listados del 5.2 al 5.7 describen los resultados que se almacenan en el archivo results.out, tras varias iteraciones de este script para los diferentes participantes. Realizando
la validación de forma recurrente se puede dar cuenta de estadísticos como la media, máximos, mínimos y desviaciones típicas. Puede observarse que los resultados son mejores para
aquellas predicciones dentro de una misma voz y cae ligeramente cuando las 5 voces están
mezcladas (la variedad y el número de muestras es mayor), aún así la clasificación sigue
siendo buena (84.2 % de media).
Accuracy = 100 % (17/17) (classification)
Accuracy = 100 % (17/17) (classification)
Accuracy = 100 % (17/17) (classification)
Accuracy = 94.1176 % (16/17) (classification)
Accuracy = 94.1176 % (16/17) (classification)
Accuracy = 100 % (17/17) (classification)
Accuracy = 100 % (17/17) (classification)
Accuracy = 100 % (17/17) (classification)
Accuracy = 100 % (17/17) (classification)
Accuracy = 100 % (17/17) (classification)
42
Mean = 98.82352 %
Min = 94.1176 %
Max = 100 %
Std. dev = 2.48024 %
Listado 5.2: Resultados para el participante 1 (hombre).
Accuracy = 90.625 % (29/32) (classification)
Accuracy = 96.875 % (31/32) (classification)
Accuracy = 90.625 % (29/32) (classification)
Accuracy = 90.625 % (29/32) (classification)
Accuracy = 93.75 % (30/32) (classification)
Accuracy = 96.875 % (31/32) (classification)
Accuracy = 93.75 % (30/32) (classification)
Accuracy = 87.5 % (28/32) (classification)
Accuracy = 96.875 % (31/32) (classification)
Accuracy = 96.875 % (31/32) (classification)
Mean = 93.4375 %
Max = 96.875 %
Min = 87.5 %
Std. dev = 3.43908 %
Listado 5.3: Resultados para el participante 2 (hombre).
Accuracy = 82.0513 % (32/39) (classification)
Accuracy = 97.4359 % (38/39) (classification)
Accuracy = 97.4359 % (38/39) (classification)
Accuracy = 92.3077 % (36/39) (classification)
Accuracy = 94.8718 % (37/39) (classification)
Accuracy = 87.1795 % (34/39) (classification)
Accuracy = 89.7436 % (35/39) (classification)
Accuracy = 84.6154 % (33/39) (classification)
Accuracy = 87.1795 % (34/39) (classification)
Accuracy = 89.7436 % (35/39) (classification)
Mean = 90.25642 %
Max = 97.4359 %
Min = 84.6154 %
Std. dev = 5.24092 %
Listado 5.4: Resultados para el participante 3 (hombre).
Accuracy = 91.6667 % (33/36) (classification)
Accuracy = 94.4444 % (34/36) (classification)
Accuracy = 97.2222 % (35/36) (classification)
Accuracy = 88.8889 % (32/36) (classification)
Accuracy = 88.8889 % (32/36) (classification)
Accuracy = 91.6667 % (33/36) (classification)
Accuracy = 94.4444 % (34/36) (classification)
Accuracy = 91.6667 % (33/36) (classification)
Accuracy = 86.1111 % (31/36) (classification)
Accuracy = 88.8889 % (32/36) (classification)
43
Mean = 91.38889 %
Max = 97.2222 %
Min = 86.1111 %
Std. dev = 3.3256 %
Listado 5.5: Resultados para el participante 4 (mujer).
Accuracy = 97.3684 % (37/38) (classification)
Accuracy = 100 % (38/38) (classification)
Accuracy = 97.3684 % (37/38) (classification)
Accuracy = 97.3684 % (37/38) (classification)
Accuracy = 97.3684 % (37/38) (classification)
Accuracy = 100 % (38/38) (classification)
Accuracy = 100 % (38/38) (classification)
Accuracy = 100 % (38/38) (classification)
Accuracy = 100 % (38/38) (classification)
Accuracy = 100 % (38/38) (classification)
Mean = 98.94736 %
Max = 100 %
Min = 97.3684 %
Std. dev = 1.35895 %
Listado 5.6: Resultados para el participante 5 (mujer).
Accuracy = 84.0426 % (158/188) (classification)
Accuracy = 87.234 % (164/188) (classification)
Accuracy = 87.766 % (165/188) (classification)
Accuracy = 84.5745 % (159/188) (classification)
Accuracy = 82.4468 % (155/188) (classification)
Accuracy = 79.2553 % (149/188) (classification)
Accuracy = 80.8511 % (152/188) (classification)
Accuracy = 86.1702 % (162/188) (classification)
Accuracy = 81.9149 % (154/188) (classification)
Accuracy = 87.766 % (165/188) (classification)
Mean = 84.20214 %
Max = 87.766 %
Min = 79.2553 %
Std. dev = 3.03031 %
Listado 5.7: Resultados para el conjunto total (mixed.data).
5.5 Implementación
Hasta ahora se ha hablado de la base teórica y las decisiones de alto nivel que se han tomado respecto a los procesos de clasificación, sin embargo es necesario hablar del código de
las diferentes etapas, una vez que los resultados han dado luz verde a la implementación.
44
5.5.1
Concurrencia
Los procesos concernientes al audio tienen un alto nivel de concurrencia. Hay que tener
en cuenta que el procesamiento es una fase lenta que puede llevar varios minutos, si no se
aporta un diseño concurrente de ejecución podría darse el caso de recibir una llamada mientras se está procesando la anterior, ya que podría haber varias llamadas consecutivas. Si no
ofrecemos un hilo de ejecución independiente la aplicación sería incapaz siquiera de realizar
otra grabación, ya que el proceso estaría ocupado filtrando, extrayendo características, escalando, clasificando, etc. Para que nuestras clases puedan ejecutarse de forma independiente
necesitamos que hereden de Thread, que incluye métodos relacionados con los hilos como
run() o join().
5.5.2
Grabación
La grabación se ha realizado por medio de una clase llamada Recording, que posee una
instancia de la clase AudioRecord. Ésta última pertenece al API de Android y permite obtener
datos de unos búffers con la información recogida del micrófono, tras otorgarle los permisos necesarios (véase Capítulo 6). Cualquier instancia de esta clase se ejecutará de forma
independiente (gracias a Thread) al momento de crearse, ya que su constructor se encarga de
hacer una llamada a su método start().
La filosofía para recoger el audio es sencilla, existe un bucle controlado gracias a una
variable de parada, el valor de dicha variable no cambia dentro del bucle y se mantiene a
true. A simple vista podría pensarse que se trata de un bucle infinito, sin embargo, al existir
dos hilos de ejecución separados, el hilo encargado de recibir notificaciones de llamadas
(hilo principal) podría cambiar el valor de dicha variable de parada mediante algún método,
con el fin de detener la grabación, esa es la función de finish() (véase Listado 5.8), este
patrón de concurrencia es conocido como patrón señalización. La razón de un diseño así es
que el audio debe ser recogido fragmento a fragmento mediante el API de AudioRecord sin
detenerse hasta la finalización de la llamada.
public void run(){
...
while(!stopped){
short[] buffer = new short[MINBUFFERSIZE];
recorder.read(buffer, 0, buffer.length);
buffers.add(buffer);
}
...
}
public void finish()
{
stopped = true;
}
Listado 5.8: Métodos run() y finish() pertenecientes a la clase Recorder.
45
Para el tratamiento de archivos en formato WAV se utiliza una librería llamada WavFile,
que permite leer y escribir este tipo de archivos, salvaguardando o recuperando la matriz de
muestras sin entrar en detalles de cómo utilizar las cabeceras del formato, que normalmente
requiere implementar aspectos de muy bajo nivel como el orden big endian o little endian,
así como gestionar valores en hexadecimal.
5.5.3
Procesador de voz
Este elemento debe realizar las tareas pesadas de procesamiento de la señal recogida en la
fase anterior. En este caso se ha implementado a través de una clase VoiceProcessor. Dichas
tareas pueden dividirse en cuatro grupos:
1. Filtrado: Utilizando el detector de voz y compactando la señal.
2. Extracción: Cálculo de coeficientes cepstrales, delta, energía y tasa de cruces por cero.
3. Clasificación: Escalado y ejecución de SVM.
4. Notificación y guardado: Se debe notificar al usuario utilizando las opciones del sistema operativo Android, así como guardar los resultados en la base de datos.
Filtrado
Se ha hecho uso de Recognito, que es una librería para reconocimiento de texto hablado
independiente del usuario. Las razones para usarla son entre otras, su implementación hecha en Java (puede integrarse con el resto del proyecto), la facilidad de uso (baja curva de
aprendizaje) o la eficiencia. Lo que interesa de Recognito no es su funcionalidad principal,
sino una de las herramientas que utiliza como detector de voz. En concreto una clase llamada
AutocorrellatedVoiceActivityDetector.
En esta fase se requiere abrir el archivo donde está almacenado el audio (mediante WavFile) y extraer las muestras. Tras ello debe instanciarse un detector de voz mediante la clase
anterior, además de establecerse el umbral estático (véase Subsección 4.2.1). Mediante el
método removeSilence() se obtiene el nuevo conjunto de muestras de audio que contienen
voz pura y que debe reemplazar al conjunto antiguo.
Extracción
Como ya se comentó en el Capítulo 3, se ha hecho uso de la implementación existente
para extracción de coeficientes cepstrales, en concreto existe una clase Frame que contiene
los métodos para subdivisión del audio en fragmentos, preénfasis y cálculo de MFCC’s. A
ésto se ha implementado la extracción de coeficientes delta que no existía y el volcado de
datos en un formato de texto apto para ser procesado por SVM.
46
Clasificación
Se debe realizar una implementación usando el API de libSVM con la finalidad de aplicar
SVM con éxito. Ha sido escogida la versión Java de la librería para una mejor integración en
el proyecto Android. La estrategia aquí consiste en implementar una clase, que en este caso se
llama Classifier y que realiza las operaciones de carga del modelo, lectura de las entradas,
escalado y evaluación. La razón de esta clase es agrupar otras clases y procedimientos que
no siguen la orientación a objetos de forma demasiado rigurosa, sino más bien una filosofía
estructural como C, de forma que obtengamos un acceso limpio y claro a todas las labores de
clasificación. La librería se ha incluido dentro de un paquete llamado libSVM que a su vez se
encuentra ubicado en un paquete más general llamado SVM y únicamente se han seleccionado
los componentes estrictamente necesarios:
SVM_model: Se trata de una clase que sirve únicamente como contenedor de atributos,
entre ellos los parámetros del algoritmo (que se agrupan en una instancia de la clase
SVM_parameter), también el número de clases (labels), y lo más importante, las matrices
de nodos que componen la base del modelo (vectores de soporte).
Es una representación de una variable dentro de un vector de soporte, se
compone de una etiqueta (número de variable, en este caso de 0 a 25) y su valor. Un
vector de soporte no es más que un array simple compuesto por instancias de esta
clase.
SVM_node:
SVM_scale: Se trata de una herramienta por línea de comandos (que está implementada
en Java) cuyo código fuente ha sido convenientemente modificado para poder escalar
y recuperar los datos en forma de cadena en vez de volcarlos a un archivo externo.
SVM_load_model: Se trata de un método que carga los datos de un modelo contenidos
en un fichero estático. Dado que en este caso no es necesario entrenar en tiempo de
ejecución (mediante la función SVM_train) cargar el modelo resulta lo más conveniente.
Toma como parámetros el modelo (SVM_model), un vector a
predecir y una matriz con las probabilidades de cada clase. En este caso la etiqueta
1,0 representa un vector de estrés mientras que 2,0 representa uno de relax. La función
devuelve la etiqueta con mayor probabilidad para ese vector en concreto.
SVM_predict_probability:
Una vez que la implementación de esta clase está acabada, resta utilizar sus funciones en la
etapa de procesamiento, es decir, el escalado de datos, la lectura (que consiste en transformar
los vectores en texto a nodos SVM) y la predicción, en este orden.
Notificación y guardado
Como etapa final es necesario guardar los resultados obtenidos en algún tipo de base de
datos, junto con otros detalles como el número de contacto, la duración y el instante de
47
Figura 5.3: Diagrama de secuencia que especifica el flujo de tratamiento de la voz.
tiempo en el que comenzó la llamada. Posteriormente debe realizarse una notificación que
avise al usuario de que efectivamente el procesamiento de la llamada que realizó finalizó y
puede conocer sus resultados de estrés, para más detalle véanse los Capítulos 6 y 7.
La duración de la etapa de procesamiento es proporcional a la duración de la llamada y
puede darse el caso de que existan varias instancias de VoiceProcessor corriendo en paralelo,
cada una encargada de su propia llamada, a la vez que puede estar grabándose y escuchando
a nuevas notificaciones respecto a otras conversaciones, por ende las etapas de recepción,
grabación y procesamiento pueden estar solapadas (véase Figura 5.3).
48
5.5.4
Optimizaciones
Los procesos que han sido definidos a lo largo del capítulo son bastante costosos en cuanto a tiempo (complejidad computacional) se refiere, problema que se agrava en el caso de
los smartphones cuya potencia puede llegar a ser muy limitada. En concreto existen dos que
son los más preocupantes, por un lado el proceso de escalado que tiene que leer el archivo
de entrada varias veces para poder tomar los máximos y mínimos de cada variable y por
otro el proceso de extracción de características. Aunque el tratamiento se produce de forma
asíncrona y sin interrumpir al usuario, se considera positivo poder reducir los tiempos de
procesamiento para obtener resultados lo más pronto posible. , Con el fin de reducir el número de vectores que deben ser escalados antes de pasar al clasificador, se utiliza un proceso
de muestreo. Como el estrés no se produce de forma aislada sino progresiva tiene sentido
escoger muestras de forma periódica para los casos en los que el conjunto a predecir sea
excesivamente grande, estos conjuntos pueden contener varios millones de muestras para el
caso de llamadas de larga duración. La estrategia ha sido reducir a un conjunto que tenga
como máximo 1000 vectores de clasificación que han sido tomados proporcionalmente a lo
largo de la llamada.
En cuanto al proceso de extracción de características, la propia fase de filtrado del silencio
ya supone una mejora considerable. No se ha aplicado el proceso de muestreo en el caso
del audio, a pesar de que la entrada al algoritmo de extracción se podría haber reducido
considerablemente, ya que al realizar cortes bruscos sobre el audio muchos valores referentes
a la dinámica del sonido dejan de tener sentido, en concreto los valores delta (coeficientes
diferenciales) y doble delta (coeficientes de aceleración).
49
Capítulo 6
Tecnologías y Componentes
E
objetivo de este capítulo es describir como se han usado las tecnologías que dan
vida a la aplicación, qué componentes del API tanto de la plataforma Android como
web están presentes, cómo funcionan, cuál es su filosofía y su finalidad. Se detallan los
elementos que forman parte de la interfaz y aquellos que realizan su labor a nivel interno.
Por otro lado se analiza el manifiesto de la aplicación y qué permisos han de ser otorgados
para su funcionamiento. Se describen algunos de los problemas surgidos y cómo han sido
solucionados.
L
6.1 Tecnologías Android
A continuación se va a detallar qué componentes del API de Android han sido utilizados
y qué dinámicas siguen estos elementos [1], como la detección de eventos de llamada o los
servicios de procesamiento en segundo plano, entre otros.
6.1.1
Elementos a nivel interno
Estos elementos son clases que no forman parte de las definiciones en XML de las interfaces nativas Android y sirven al dominio de la aplicación.
Servicio
Los servicios son componentes que permiten ejecutar operaciones de gran duración y peso
en segundo plano, y como ya se ha mencionado anteriormente no proveen interacción directa
alguna con el usuario. Dichos servicios pueden seguir ejecutándose aunque el usuario haya
cambiado a otra aplicación, y pueden relanzarse en el caso de que el proceso principal sea
eliminado, si así se especifica programáticamente. La razón de que este componente se haya
incluido es el hecho de que la aplicación requiere una gran carga en segundo plano y por ende
un único servicio debe ser instanciado con la finalidad de orquestar el resto de elementos,
tanto aquellos que se responden a los eventos de llamadas como aquellos que se dedican al
procesamiento. Para poder usar las propiedades del servicio se requiere una clase que herede
de Service, en este caso VoiceService. Su método onStartCommand() registra una instancia de
la clase CallReceiver y desencadena todo el proceso de grabación.
51
Receptor de broadcast
Los broadcast del sistema son una forma de comunicación interproceso, la diferencia reside en que éstos son globales para aquellas aplicaciones que hayan registrado sus receptores
y estén esperando un tipo de señal concreta. Estos mensajes pueden ser enviados desde aplicaciones o por el S.O. en sí mismo.
Anuncio
Categoría
Emisor
BATTERY_LOW
BOOT_COMPLETED
ACTION_TIME_TICK
ACTION_CAMERA_BUTTON
DEVICE_STORAGE_LOW
PACKAGE REMOVED
NETWORK_STATE_CHANGED
ACTION_PHONE_STATE
ACTION_SHUTDOWN
Batería
Sistema operativo cargado
Se envía cada minuto
Se activa el botón de la cámara
Queda poca memoria
Se eliminó una aplicación
Cambia la red Wi-fi
Llamada de teléfono
El dispositivo va a ser desconectado
Cambia el método de entrada
Sólo sistema
Sólo sistema
Sólo sistema
Todos
Sólo sistema
Sólo sistema
Sólo sistema
Todos
Sólo sistema
INPUT_METHOD_CHANGED
Todos
Cuadro 6.1: Algunos de los mensajes existentes en el sistema.
Estos receptores al igual que los servicios tampoco poseen una interfaz con el usuario,
aunque pueden realizar cambios en la misma. El ciclo de vida de éstos es bastante sencillo, la instancia sólo existe durante la llamada al método onReceive(). Los broadcast en los
que estamos interesados son los del tipo ACTION_PHONE_STATE_CHANGED (véase Cuadro 6.1),
concretamente se debe recoger el campo EXTRA_STATE, que será aquel que nos proveerá información concreta del estado del teléfono. Los valores que contiene dicho campo aparecen
recogidos como constantes en la clase TelephonyManager, siendo los más relevantes aquellos
que se listan a continuación:
EXTRA_STATE_OFFHOOK: Emitido cuando al menos una llamada existe y está comunicando, y además no hay llamadas que estén sonando (entrantes) o esperando (salientes) en ese momento. Este mensaje es el anuncio de que una llamada está teniendo
lugar y se debe iniciar la grabación.
EXTRA_STATE_IDLE: Emitido cuando no hay actividad en lo referente a llamadas.
Este anuncio indica que la comunicación previamente existente ha finalizado y se debe
por tanto finalizar la grabación.
Se deberá utilizar la clase gestora TelephonyManager antes mencionada para registrar el
receptor, en conjunción con el método registerReceiver(). Los diferentes niveles de concurrencia y procesamiento que se desencadenan ante la recepción de llamadas ya fueron
definidos en el Capítulo 4.
52
Parcelable
Se trata de una interfaz Java que debe ser implementada por todas aquellas clases del
dominio cuyas instancias deban ser transferidas entre actividades o bien entre fragmentos
(véase Subsección 6.1.2). Constituye una técnica de serialización de datos, de forma que
los campos de una instancia puedan ser contenidos en el cuerpo de un mensaje (mecanismo
conocido como «marshalling»), otros lenguajes como Python poseen mecanismos de serialización incorporados pero no es el caso de Java. La interfaz especifica la implementación
de un método writeToParcel(), que debe tomar los atributos de la instancia y grabarlos a un
objeto de tipo Parcel. Asimismo debe utilizarse para el caso de las clases del dominio Call
y Person (véase Capítulo 7),
JavascriptInterface
Se trata de una anotación Java que permite compartir métodos con una componente JavaScript. Una anotación es una forma de especificar metadatos en el código fuente de Java,
mediante la utilización del símbolo «@». Puede incluirse en cualquiera de las clases existentes, aunque es una buena práctica generar clases especifícas para esta tarea. Los métodos que
la incluyan serán compartidos con la parte JavaScript de un WebView, si así se especifica. A
la clase se le asigna un alias y se incorpora en el lado web como un objeto global accesible
mediante dicho alias. De esta forma se comparten procedimientos (i.e. lanzar un mensaje
flotante mediante un WebView) o datos (mediante métodos setter() y getter()), la única restricción es que los valores devueltos sean datos primitivos o bien serializaciones de objetos,
preferentemente en formato JSON. Las interfaces JavaScript que han sido implementadas
son:
ArrayWebInterface: Clase que permite compartir una lista en formato JSON gracias a
la clase JSONArray del paquete org.json.
ObjectWebInterface: Permite compartir un objeto en JSON utilizando la clase JSONObject
incluida en org.json.
DailyWebInterface: Sirve de puente en el caso del filtro por franjas horarias, cuando
un segmento que corresponde a una hora del día es pulsado, un evento de pulsación
es emitido en el lado JavaScript. Con ello se llama al procedimiento changeFilter()
de la interfaz, notificando de esta manera al fragmento que la contiene (véase Subsección 6.1.2).
6.1.2
Elementos de la interfaz
El desarrollo de interfaces en Android es similar al que se lleva a cabo en otros entornos
Java, por ejemplo en entornos de escritorio, en donde es común el uso de la librería Swing.
Por un lado existe una declaración de componentes estática (en este caso en XML), y por otro
existe una parte dinámica que referencia a algunos de estos elementos con el fin de modifi53
Figura 6.1: Ciclo de vida de una actividad.
carlos, dejando de lado aquellos que no necesitan un comportamiento dinámico. Ésta es una
buena práctica y es la forma natural de proceder con la implementación. A continuación se
listan aquellos elementos relacionados con la interfaz más remarcables:
Actividad
Una actividad es una unidad de interacción con el usuario que tiene siempre una vista
asociada. Como se ha mencionado antes, debe estar definida en un archivo tipo XML y su
comportamiento en una clase que herede de Activity. Cualquier aplicación deberá estar
conformada por un un conjunto de actividades que no comparten variables pero que sin
embargo, pueden comunicarse e instanciarse entre sí. Posee un ciclo de vida siguiendo un
patrón de máquina de estados (véase Figura 6.1), cada estado está asociado a un método:
onCreate(): Es invocado cuando la actividad es creada por primera vez, aquí es donde
debe hacerse un «set up» de la vista, le sigue una llamada a onStart().
onRestart(): Ejecutado después de que la actividad haya sido parada, justo antes de ser
restaurada de nuevo, le sigue el método onStart().
onStart(): Es llamado cuando la actividad se vuelve visible al usuario, si se coloca en
primer plano continua con onResume(), si no con onStop().
onResume(): Invocado cuando se comienza la interacción con el usuario, en ese momento la actividad está a la cabeza de la pila de actividades. Siempre es seguido por
onPause().
onPause(): Se recurre a este método cuando la actividad ha pasado a segundo plano
pero sin embargo no ha sido eliminada todavía. Es la acción contraria de onResume().
onStop(): Se realiza cuando la actividad ya no es visible al usuario.
onDestroy(): Es la llamada final antes de que la interfaz sea destruida por completo. No
sólo el usuario puede desencadenarlo, el sistema también puede ejecutar este método
54
para liberar espacio.
Una de las prácticas más habituales años atrás era la de generar aplicaciones compuestas
por una serie de actividades que se comunicaban entre sí. No obstante a partir del API nivel
11 se desarrolló un nuevo componente conocido como fragmento, debido a la necesidad
de que las vistas fueran compatibles con dispositivos como tablets, permitiendo fabricar
diseños sin la necesidad de manejar cambios complejos en la jerarquías de componentes.
El proyecto sigue esta filosofía y define una única actividad, la cual va reemplazando y
colocando fragmentos dependiendo de las acciones que tome el usuario.
Fragment
Como ya se ha mencionado un fragmento representa una porción de la interfaz de usuario
dentro de una actividad, con la condición añadida de que es un componente altamente reutilizable. Esto quiere decir que dicha actividad puede estar compuesta de multiples fragmentos,
y un framento a su vez puede tomar parte en muchas actividades, por ende siendo independiente de todas ellas. Su manipulación se realiza mediante transacciones usando la clase
auxiliar FragmentManager. Debe iniciarse una transacción y debe realizarse un «commit» tras
los cambios. Asimismo un fragmento debe reemplazar un elemento previamente existente
para garantizar la posición exacta en la jerarquía de componentes. La lista de fragmentos que
posee la aplicación es:
DataFragment: Es el más significativo de todos, ya que es instanciado por varios filtros. En su generación es necesario enviar como argumento una lista de llamadas, para
ello se requiere que la clase Call sea parcelable (véase Subsección 6.1.1). Este componente tiene como base dicho conjunto de llamadas. Además despliega un gráfico
interactivo usando tecnologías web y un pequeño texto con el número de ellas, para
finalmente renderizar dicha lista.
NoDataFragment: Contiene una simple etiqueta indicando que no se ha seleccionado
dato alguno a representar.
BetweenDatesFragment: Usado para el filtro de búsqueda por fechas, incorpora un
par de textos, unos iconos y dos campos. El comportamiento de dichos campos ha sido
redefinido para el evento click (que en interfaces móviles se corresponde con un toque
con el dedo), desplegando así un elemento del tipo DatePickerDialog que es un selector
de fechas bastante intuitivo para escoger cada uno de los límites (véase Figura 6.2).
Cuando la fecha es seleccionada se coloca como contenido en su respectivo campo,
cuando existen dos fechas se procede con la consulta referente al filtro. La Figura 6.3
contiene una captura de pantalla de esta parte de la interfaz.
DailyFragment: Usado para el filtro de búsqueda por franja horaria. Contiene un encabezado similar al del fragmento anterior y ademas un componente web de franjas
55
Figura 6.2: Elemento DatePickerDialog.
56
Figura 6.3: BetweenDatesFragment y DailyFragment.
horarias (véase Sección 6.2). Al pulsar sobre cada una de las franjas se crea una instancia de DataFragment, pasando como argumento las llamandas que corresponden a
dicho período. La Figura 6.3 contiene una captura de pantalla de este fragmento.
PeopleListFragment: Usado para el filtro de búsqueda por contacto. Además del encabezado, un grafo es desplegado en un componente web, conjuntamente a una lista
de contactos con una renderización personalizada. El nombre del contacto aparece si
es que existe en la agenda. Al pulsar sobre cualquier elemento de lista se instancia un
fragmento del tipo PersonFragment que lo reemplaza. La captura de la izquierda en l.a
Figura 6.4 representa esta parte.
PersonFragment: Este elemento acepta como argumento un contacto. Su funcionamiento es bastante sencillo, despliega un fragmento de datos utilizando las llamadas
que pertenecen a dicho contacto y coloca un texto con su nombre en la esquina superior derecha. El fragmento es el que se puede apreciar en la Figura 6.4 concretamente
en la captura de la derecha.
FragmentWithLists: Esta clase debe ser extendida por todos aquellos fragmentos que
incorporen listas (en este caso PeopleListFragment y DataFragment). Existe un problema cuando se incrustan listas dinámicas dentro de vistas con scroll que no permite
57
Figura 6.4: PeopleListFragment y PersonFragment.
58
Figura 6.5: Ejemplo de una notificación de la aplicación.
que dichas listas tomen sus tamaños completos, es un artificio que redimensiona el
componente para una correcta visualización.
Notificación
Hay tres tipos de notificaciones al usuario:
Notificaciones de icono, en donde aparece una pequeña imagen en la barra de estado.
Notificaciones mediante LED, encendiendo la pequeña luz del dispositivo de un color
determinado.
Notificaciones de sonido o vibración.
La barra de estado es aquella que se ubica en la parte superior del display. El usuario puede
desplazar hacia abajo para visualizar la lista de notificaciones del primer tipo acumuladas que
no han sido atendidas. Estas notificaciones son el mecanismo más interesante para comunicar
información por parte de servicios, y en este caso se utilizan para comunicar cuándo los
datos de la última llamada han sido procesados y están listos para su visualización. Para
su gestión se utiliza la clase homónima NotificationManager. La notificación toma un id, de
forma que si algo cambia pueda ser actualizada, asimismo utiliza un título y un cuerpo (véase
Figura 6.5).
59
Figura 6.6: Menú de cajón.
DrawerLayout
Un layout es un contenedor a nivel visual que define la posición y relación entre los elementos que contiene. Existen varios layouts que son usandos recurrentemente como los layouts relativos, lineales (horizontal y vertical) o de marco (frame). Un DrawerLayout es un
layout especial que debe usarse como primer componente en la jerarquía y permite definir un
menú lateral conocido como «cajón». Este menú permanece oculto la mayoría del tiempo,
pero aparece progresivamente conforme se arrastra el dedo de izquierda a derecha. Permite
optimizar el espacio colocando las opciones más relevantes de la aplicación en él y ocultándose cuando no es requerido. En este caso se colocan los filtros en este menú y se lanza
la transacción de fragmentos correspondiente cuando alguna de estas opciones es seleccionada. El resultado es el que aparece reflejado en la Figura 6.6. Es definido en la actividad
principal de la aplicación y como restricción permite incluir únicamente dos elementos en su
interior:
1. El contenido principal que es envuelto dentro de un scroll vertical.
2. El menú desplegable.
60
Figura 6.7: Ítem de llamada renderizado usando CallAdapter.
ListAdapter
Un adaptador de objectos actúa como un puente entre una vista y la capa inferior de datos para dicha vista, en concreto de los varios adaptadores existentes, el adaptor de lista es
aquel que provee acceso a los elementos de la lista y renderiza una vista individual para
cada uno de ellos siguiendo sus propios criterios. Cuando se debe desplegar una lista de
componentes arbitrarios, existen varias opciones, la primera es utilizar adaptadores por defecto que despliegan los componentes de forma minimalista, la otra es generar adaptadores
personalizados. Todo adaptador está asociado a una vista de elemento o ítem en XML que
debe de instanciar, de forma que se puede personalizar los elementos que dicho componente
contiene, por ejemplo utilizando varios textos por componente o una imagen arbitraria. Los
adaptadores de lista implementados han sido:
DrawerAdapter: Utilizado para los ítems del menú de cajón de la izquierda. Tiene
en cuenta la posición de cada elemento y renderiza el nombre y la imagen del filtro
correspondiente.
CallAdapter: Adaptador de llamadas que se invoca en el fragmento de datos. Contiene
los siguientes elementos para cada ítem (véase Figura 6.7):
• Porcentaje de estrés: Se despliega de la forma «50 % of time stressed» y el color
de texto corresponde a un gradiente entre naranja y azul, donde un naranja puro
representa el 100 % del tiempo y un azul puro representa el %0 (calma).
• Barra de progreso: Viene definida en un XML en el directorio de recursos estático. Personalizándolo se pueden definir propiedades visuales como los diferentes
gradientes, las formas y demás detalles. La zona completada se define como el
porcentaje de estrés.
• Etiqueta de duración: Medida en segundos, horas y minutos
• Etiqueta de fecha: En formato «dd/mm/aaaa».
61
• Etiqueta de persona: El contacto con el que la llamada tuvo lugar, si está registrado como tal aparecerá su nombre, si no aparecerá su número.
PersonAdapter: Adaptador que se invoca en el fragmento de lista de personas. Contiene los siguientes elementos para cada ítem:
• Icono de persona.
• Nombre o número en su defecto.
• Número de llamadas realizadas con dicho contacto.
• Icono de teléfono.
CustomView
Aunque el API de componentes visuales es amplio y extenso, no sólo los componentes
predefinidos pueden ser utilizados en las vistas, también se pueden crear clases personalizadas en las cuáles se puede definir el comportamiento heredando del componente base (View)
o de cualquier otro. En este caso había un problema cuando se combinaba el scroll vertical principal con el zoom para el caso de las gráficas. El zoom requería un movimiento de
izquierda a derecha mientras que el scroll requería uno de arriba a abajo, sin embargo un
movimiento en diagonal generaba un efecto confuso y el zoom no se realizaba correctamente. Para solventar el problema se requiere un componente web que ignore el scroll vertical,
dicho componente ha sido definido en la clase ScrollingWebView que hereda directamente de
WebView. Se requiere sobrescribir el método onTouchEvent() (véase el Listado 6.1).
@Override
public boolean onTouchEvent(MotionEvent event){
requestDisallowInterceptTouchEvent(true);
return super.onTouchEvent(event);
}
Listado 6.1: Método sobrescrito para la clase ScrollingWebView.
6.1.3
Manifest y permisos
Como mecanismo de seguridad los desarrolladores de Android idearon el sistema de permisos. En general el manifest es un archivo XML que contiene información esencial sobre
la aplicación. Sobra decir que muchos de los elementos antes mencionados deben ser declarados en el manifiesto como actividades, servicios y receptores de broadcast. Especifica
también el nombre de la aplicación y la versión del SDK. Los permisos para aquellas acciones
reservadas como escribir en un fichero, comprobar el estado de la red o leer los contactos del
usuario (véase Cuadro 6.2) deben ser especificados, de otra manera el sistema bloqueará a
la aplicación con una excepción cuando intente realizarlas. De esta forma es fácil saber cúal
es el alcance de una aplicación y mantener al usuario al tanto, para que él decida su propio
nivel de privacidad.
62
Nombre
Descripcion
BLUETOOTH
Permite a la aplicación conectarse a dispositivos Bluetooth emparejados
Permite acceder a información sobre redes
Permite iniciar una llamada telefónica
Permite formatear sistemas de archivos
eliminables
Permite leer la información de contactos
Permite leer mensajes SMS
Permite reiniciar el dispositivo
Permite grabar audio
Permite escribir en el almacenamiento
externo
Permite acceso de solo lectura al estado
del teléfono
ACCESS_NETWORK_STATE
CALL_PHONE
MOUNT_FORMAT_FILESYSTEMS
READ_CONTACTS
READ_SMS
REBOOT
RECORD_AUDIO
WRITE_EXTERNAL_STORAGE
READ_PHONE_STATE
Cuadro 6.2: Algunos de los mensajes permisos en el sistema.
Los permisos requeridos nuestra aplicación son:
READ_PHONE_STATE: Para poder leer el estado del teléfono y los broadcast del
sistema relacionados con las llamadas.
RECORD_AUDIO: Imprescindible para poder utilizar el micrófono.
READ_CONTACTS: Útil para traducir números de contacto en sus nombres de contacto realizando una consulta al sistema, de esta forma resulta más cómodo de cara al
usuario.
WRITE_EXTERNAL_STORAGE: Necesario para guardar de forma permanente los archivos de audio WAV y los archivos de datos.
No obstante, las tecnologías Android no son las únicas que forman parte del proyecto.
6.2 Tecnologías web
La web es un conjunto de tecnologías bastante interesante para suplir las carencias que
las tecnologías Android tienen, sobre todo a nivel visual. La gran ventaja es la cantidad de
librerías y frameworks para automatizar trabajo que existen, con resultados bastante profesionales. Las pequeñas vistas conocidas como WebView pueden ser embebidas en aplicaciones
nativas y permiten ser desplegadas como documentos HTML. Aunque el rendimiento decae
ligeramente, estos componentes son capaces de tener un aspecto natural y un look and feel
nativo. Además, parece que las tecnologías web están desarrollándose a un ritmo vertiginoso
en los últimos años y están invadiendo campos como las tecnologías móviles con las conocidas como aplicaciones híbridas. En el caso de los WebView existen unas interfaces, que
gracias a la anotación @JavascriptInterface permiten comunicar la parte Java con la parte
63
JavaScript compartiendo datos y procedimientos. En el caso de Android cada componente
web es una instancia ligera del navegador Chrome. Tanto las librerías como los lenguajes definidos a continuación ya fueron explicados brevemente en el Capítulo 2, ahora se detallará
su utilización.
6.2.1
Lenguajes
Los lenguajes HTML, CSS y JavaScript son definidos por el W3C (Wide Web Consortium)
y son el estándar y la base del resto de tecnologías web. Existen frameworks y preprocesadores, tecnologías relativamente nuevas que dan soporte a un desarrollo más cómodo, aunque
en este caso particular no se ha utilizado ninguna. La tarea de interpretación de cada uno de
estos lenguajes recae sobre el navegador concreto, por ejemplo Chrome utiliza el motor de
JavaScript V8 y el motor Blink (bifurcación de WebKit) para renderización. Los tres estándares antes mencionados aportan los tres elementos básicos de toda aplicación de usuario:
contenido, estilo y dinamismo.
6.2.2
Librerias JavaScript
Las librerías elegidas han sido utilizadas para la generación y representación de gráficos
con el objetivo de mostrar la información recogida y han sido escogidas por su versatilidad
y su elegancia.
JQuery: Su uso aquí es meramente como dependencia de la librería CanvasJS.
CanvasJS: Utilizada para generar gráficos. Trabaja bien con fechas lo cual es esencial
para dibujar dichos gráficos en el tiempo, además incluye ejes responsive, pudiendo
hacer zoom en el caso de que los datos sean muy densos. En este caso es muy importante, ya que las llamadas pueden estar separadas un intervalo de tiempo muy pequeño
(10 segundos) o un intervalo muy grande (10 meses), lo cual puede ocasionar efectos
no deseados, pero que sin embargo se solucionan con esta funcionalidad. Esta librería
depende de JQuery. Los tipos de gráficos utilizados han sido:
• Spline chart: Son gráficos de líneas que conectan puntos, la diferencia con el
«line chart» clásico es que los puntos no están conectados de forma brusca si no
usando curvas suaves (spline) que se obtienen mediante interpolación de valores
usando polinomios (ver Figura 6.8), con ella representamos estrés (en porcentaje)
y tiempo de llamada (en segundos) en función del tiempo UNIX, tiene por tanto
una doble escala. Las curvas suaves son más realistas en tanto y cuanto el estrés
se padece de forma progresiva.
• Doughnut chart: Dado un conjunto de valores reparte un gráfico circular de forma
proporcional, útil para representar la contribución horaria al conjunto de estrés
64
Figura 6.8: Gráfico splines representando el nivel de estrés y la duración respecto de la fecha.
total. Para calcular cada valor utilizamos la Expresión 6.1.
n
X
tn · sn
(6.1)
i=0
Siendo n el numero de llamada que pertenece a esa hora del día en concreto,
t el tiempo de duración y s el porcentaje de estrés. El algoritmo que calcula el
conjunto también tiene en cuenta los saltos de unas horas a otras, divide el tiempo
y pondera añadiendo cada contribución a su respectiva franja. El resultado es el
que aparece en la Figura 6.9.
SigmaJS: El grafo resultante generado con esta librería es un ejemplo excelente de
interfaz natural, entendida ésta como la interfaz que permite una interacción haciendo
uso de movimientos gestuales (aunque una interfaz móvil tiene mucho de interfaz
natural de por sí), la razón es que el grafo es totalmente escalable, redimensionable,
se translada y gira, teniendo un control total y pudiéndose ajustar para focalizarse
en aquellas partes que el individuo considere. Utilizándola se ha implementado una
estructura árbol (ver Figura 6.10), donde:
• La raíz es el usuario.
• El primer nivel son los contactos con los que se ha entablado conversación.
• El segundo nivel corresponde a las llamadas, cada una con un gradiente de color.
Los nodos pasan de azul (0 %, #009ACD) a naranja (100 %, #FF5333) e indican
intuitivamente al usuario el estado de estrés que conllevan, el tamaño del nodo
aumenta a medida que crece el porcentaje.
Para hacer un uso razonable del espacio al colocar los nodos, se utilizan técnicas de
65
Figura 6.9: Gráfico doughnut con la contribución de estrés de cada hora del día.
Figura 6.10: Grafo representativo de los contactos y las llamadas.
66
rotación y translación utilizando algebra vectorial sencilla. Primero 2π radianes (es
decir la circunferencia), se divide entre el número de contactos. El nodo de primer
nivel se desplaza una cantidad x de unidades siguiendo esa porción de la circunferencia, para después distribuir cada llamada perteneciente al contacto a lo largo de π
radianes (media circunferencia), esta vez con una separación menor respecto a su nodo
padre. De esta forma repartimos el espacio a lo largo de los 360o , aunque habría otras
posibilidades.
67
Capítulo 7
Arquitectura Software, Metodología y Usabilidad
L
finalidad del presente capítulo es la de dar cobertura al proyecto desde el punto de
vista de la ingeniería del software, mientras que en el Capítulo 6 intentábamos dar una
visión desde punto de vista funcional es decir, qué componentes habían sido usados y cuál es
su finalidad, ahora vamos a ver cuál es su estructura y cómo se interrelacionan las diferentes
clases, así como los patrones de diseño y los diferentes diagramas. Se detallarán las tres
capas fundamentales de persistencia, dominio y presentación, se tratará en detalle cómo la
persistencia ha sido llevada a cabo. Se hablará de la metodología seguida y finalmente del
diseño centrado en el usuario.
A
7.1 Casos de uso
Un diagrama de casos de uso contiene todas las secuencias de interacciones que se desarrollan entre un sistema y sus actores, en respuesta a un evento que inicia el actor sobre
el propio sistema. Sólo existe un tipo de actor que es el usuario de la aplicación, y como
posibles casos de uso de alto nivel se tienen los tres filtros cuyo objetivo es desplegar la información de un conjunto de llamadas dependiendo de ciertos criterios, de ahí que se incluya
la acción «Visualizar información de llamadas» (que se corresponde con un fragmento de la
interfaz) al resto de casos de uso (véase Figura 7.1).
7.2 Capas software
Dividir una aplicación en capas es imprescindible si queremos una arquitectura clara y
deseamos dividir responsabilidades creando un software modulable y reutilizable. Uno de
los patrones más comunes es la división en dominio, persistencia y presentación, que en este
caso puede realizarse mediante paquetes separados.
7.2.1
Presentación
Es aquella capa que contiene aquellos elementos que forman parte de la interfaz o interactúan con el usuario. En la aplicación este paquete está fragmentado en otros paquetes más
pequeños en concreto:
Paquete activities: Contiene la actividad principal, corresponde a la Figura 7.4.
69
Figura 7.1: Diagrama de casos de uso.
Paquete fragments: Contiene los 7 fragmentos que se generan a lo largo de las vistas,
se refleja en la Figura 7.3.
Paquete adapters: Contiene los 3 adaptadores de lista que renderizan sus respectivos
conjuntos, la Figura 7.2 describe este paquete.
Paquete customViews: Contiene la vista web personalizada (véase Figura 7.4).
Paquete webInterfaces: Contiene las 3 interfaces JavaScript para compartir datos y
procedimientos, ilustrado en la Figura 7.2.
7.2.2
Dominio
Este paquete contiene dos tipos de componentes, por un lado modelos que se corresponden
con objetos de negocio (representados en la Figura 7.5), en este caso se han identificado dos,
las llamadas y los contactos (que poseen llamadas). Por otro lado contiene la parte de lógica
más importante de toda la aplicación. Puede observarse qué elementos heredan de Thread y
tienen por tanto hilos de ejecución independientes. A lo largo de toda la ejecución se instancia
un único servicio de voz y un único receptor de broadcast que le pertenece, mientras que por
cada llamada se instancia un recorder y su correspondiente procesador de voz que trabajan
en paralelo al servicio para no bloquearlo (véase Figura 7.6).
70
Figura 7.2: Paquete de interfaces web y adaptadores.
Figura 7.3: Paquete de fragmentos.
Figura 7.4: Paquete de actividades y vistas personalizadas.
71
Figura 7.5: Paquete de dominio (modelos).
7.2.3
Persistencia
Es aquella parte encargada de materializar y desmaterializar los modelos del dominio tomando los datos de alguna base de datos o similar. Existen varias opciones a la hora de
guardar información, por ejemplo hay una forma de persistencia mediante preferencias en el
sistema Android e incluso pueden guardarse ficheros de forma interna o externa (los archivos
de audio y datos son almacenados de esta forma), lo más elegante resulta utilizar una base
de datos relacional, en concreto el sistema gestor de base de datos de SQLite que viene embedido dentro del sistema Android parece una buena opción, además la gestión de la base es
automática (aspectos como su ubicación, etc.). Este paquete viene representado en la Figura
7.7.
Modelo relacional
SQLite
sigue un modelo relacional, frente a otras bases que optan por otros modelos como MongoDB o Datastore de Google. Consiste en almacenar tuplas mediante alguna clave
primaria en tablas y relacionar tablas entre sí mediante claves secundarias, minimizando la
redundancia.
Tablas
Pese a que existen dos modelos (llamada y contacto), se ha decidido implementar una
única tabla de datos compuesta por:
Timestamp: Valor INT que representa el tiempo UNIX del momento en que comenzó la llamada. El tiempo UNIX se define como el número de segundos transcurridos
desde la medianoche del 1 de enero de 1970. Se considera una buena referencia y es
72
Figura 7.6: Paquete de dominio (lógica).
73
Figura 7.7: Paquete de persistencia.
fácilmente transformable en todas las API a fechas más legibles. Además es la clave
primaria de la tabla.
Número de teléfono: Valor STRING, viene definido en los extras del broadcast de
inicio de llamada.
Estrés: Valor FLOAT, definido como la proporción de muestras clasificadas como estrés frente a las clasificadas como relax.
Duración: Valor FLOAT, representa el número de segundos que duró la llamada (incluye tiempo de silencio), mediante el timestamp y la duración se puede ajustar con
precisión el transcurso de la llamada.
No se ha implementado una segunda tabla de contactos por el hecho de que no hay suficiente
información referente a los mismos, únicamente su número de teléfono. Podría almacenarse
su nombre si existiese, sin embargo no sería útil ya que es bastante dinámico y es preferible
hacer una consulta al sistema en tiempo de ejecución.
Helpers y connectors
La forma más común para crear, actualizar y conectar una base de datos en Android es
mediante una clase auxiliar llamada SQLiteOpenHelper. Debemos implementar un helper de
base de datos para cada tabla existente, o al menos es una buena práctica hacerlo de esta
manera. La clase contiene una cadena SQL de creación de la tabla y está asociada a un conector específico. El conector implementa operaciones de inserción, selección, actualización
y eliminación (CRUD), generalmente implementa varias operaciones de selección personalizadas bajos ciertos criterios. Sobre el sistema gestor recae la tarea de buscar por fechas y por
teléfono (contacto) con las sentencias SQL adecuadas, sin embargo buscar por franja horaria
utilizando un tiempo UNIX es bastante complejo por ello se ha delegado esa responsabilidad
74
a las capas superiores utilizando el API de Java para fechas y calendario.
7.3 Patrones
Los patrones son esqueletos que resuelven problemas comunes de diseño brindando una
solución ya probada y documentada. Los patrones mas remarcables aplicados son:
DAO
Un Data Access Object es un objeto que provee una interfaz abstracta a algún tipo de
base de datos o mecanismo de persistencia. Un DAO provee operaciones CRUD sin exponer
detalles de bajo nivel, mapeando de esta forma llamadas a la capa de persistencia. Una buena
practica es generar una clase DAO por cada objeto del dominio que deseemos materializar
o desmaterializar. La función de DAO en el caso de Call es implementada por el conector,
que posee las operaciones de selección e inserción. Este patrón se antepone al patrón Active
Record, en el cual el modelo es responsable de sus relaciones con la base de datos.
Factory
Los métodos estáticos de creación (static factory methods), son métodos que permiten la
construcción de un objeto sin tener que llamar al constructor de la clase y a los métodos setter() adicionales, permiten refactorizar el código necesario para la creación de una instancia
y los pasos necesarios para su inicialización. Es utilizado para todo fragmento de la interfaz
mediante el método newInstance(), los esqueletos de código que el IDE genera para la implementación de un fragmento ya lo contienen aunque no es obligatoria su implementación,
pero sí es útil si requerimos enviar al fragmento ciertos argumentos (una lista de contactos o
de llamadas) para que trabaje con ellos.
State
El patrón estado se utiliza cuando el comportamiento de un objeto cambia dependiendo
del estado del mismo. Un buen ejemplo de máquina de estados es un socket TCP de conexión
donde su estado puede ser escuchando, cerrado o conexión establecida, existen eventos que
generan las transiciones de unos estados a otros. Nuestra actividad es el caso más claro de
máquina de estados, donde los estados son «started», «created», «paused», etc., los cambios
son generados por el usuario o el sistema, por ejemplo al enviar la aplicación a segundo
plano. El código que se ejecuta en las transiciones puede ser sobrescrito por el desarrollador
mediante sus correspondientes métodos onStarted(), onCreated(), onPaused(), etc. (véase
Capítulo 6).
75
7.4 Metodología
Simplificando, una metodología software consiste en dividir el trabajo en distintas fases o
etapas que contienen las actividades a realizar, con el fin de tener una mejor planificación y
gestión de un proyecto [31]. La metodología más coherente y que ha sido llevada a cabo a lo
largo del presente proyecto es una metología ágil tipo Scrum, que se caracteriza por:
1. Utilizar una estrategia de desarrollo iterativo, donde en vez de generar un producto de
forma monolítica se utilizan iteraciones que son pequeñas etapas que permiten evolucionar el producto basándose en las etapas o iteraciones anteriores.
2. Un solapamiento entre fases, en vez de utilizar un modelo en cascada donde cada fase
(requisitos, diseño, implementación, etc.) se sucede de manera lineal.
3. La calidad del producto se basa en el conocimiento de equipos autogestionados y no
en la calidad de un conjunto de procesos. (Aunque en este caso el integrante sea sólo
uno, más sus directores de proyecto.)
Es óptima en el caso de proyectos cuyos conjuntos de requisitos son inestables, en este
caso se ha ido definiendo el alcance de la aplicación final a lo largo de las últimas semanas
conforme a la restricciones de tiempo, una vez que la base concerniente a la extracción y
clasificación estaba clara. Se prioriza el software que funciona sobre una documentación
exhaustiva. También se utiliza en situaciones problemáticas dónde:
El cliente no recibe lo que necesita.
Los costes se vuelven inasumibles.
La calidad es más bien pobre.
La moral de los equipos es baja.
Es necesario identificar la fuente de problemas e ineficiencias.
La innovación, competitividad, flexibilidad y productividad son fundamentales.
Se basa en sprints que son períodos entre una y cuatro semanas (esta magnitud debe ser
lo más corta posible) en donde el equipo genera un incremento del software (iteración),
el conjunto de características que deben cumplirse en cada sprint vienen definidas en el
Product Backlog (véase Figura 7.8), donde aparecen priorizados. Por ejemplo, un sprint se
inicia con la última reunión con el cliente y finaliza con otra reunión a la semana siguiente
y podría incluir los objetivos de implementar la grabación de audios cuando una llamada es
recibida.
Durante el Sprint Planning se determinan los elementos del backlog, de forma que todos
los interesados participan de forma activa hasta llegar a un acuerdo. Es una aproximación
pragmática teniendo en cuenta que los problemas a resolver no pueden ser completamente
definidos, planificados y entendidos desde el principio del desarrollo. Utiliza lo que se conoce
76
Figura 7.8: Esquema representativo de la metodología Scrum.
como «Historias de Usuario» que no es ni mas ni menos que la representación de un requisito
escrito en una o dos frases. Aunque la metodología define varios roles como el Scrum Master,
el Product Owner o el Scrum Team, no es jerárquico. En este caso el equipo es el presente
alumno y el master sus directores de trabajo.
7.5 Diseño centrado en el usuario (DCU)
El DCU es un paradigma que tiene por meta desarrollar productos que resuelvan los problemas concretos de los usuarios a los que van destinados [12]. Las metodologías ágiles
facilitan el diseño centrado en el usuario en tanto que propician la interacción con el cliente.
La finalidad es que los usuarios realicen la menor cantidad de esfuerzo, obtengan la mejor
experiencia y la mayor satisfacción con los resultados obtenidos. Asimismo, está fuertemente vinculado a las interfaces de usuario y a la capa de presentación. Incluye una serie de
tareas que deben cumplirse en algún momento:
Al inicio, realizar un estudio para conocer quiénes serán los usuarios finales, dado que
la aplicación es un sistema altamente interactivo, el diálogo con el usuario es de suma
importancia.
Durante el desarrollo, crear un producto teniendo en mente que debe de ajustarse a la
capacidad de los usuarios, sus expectativas, motivaciones y necesidades.
Al final, poner a prueba la usabilidad de lo diseñado utilizando tests con usuarios.
No es aconsejable relegar el diseño de la interfaz de usuario a las etapas finales por ello,
desde un primer momento siempre se ha tenido en mente cuáles debían ser las conclusiones
que un usuario observando la aplicación debía obtener respecto a la detección de estrés, cómo
unos mismos datos debían ser representados visualmente de forma diferente usando filtros
para focalizar la atención del usuario, de forma que la misma no se perdiese en una maraña
de fechas y porcentajes.
77
Por otra parte el modelo de ingeniería de la usabilidad de Jakob Nielsenn define los 10
principios que deben seguirse para realizar un correcto diseño centrado en el usuario, entre
ellos la iteratividad del proceso, el prototipado como eje fundamental o el test empírico antes
mencionado (evaluación). La iteratividad queda justificada con la metodología, el prototipado se ha llevado a cabo con herramientas de maquetado («mockups») (véanse Figuras 7.9
y 7.10) el test empírico se ha llevado a cabo con algunos de los miembros del laboratorio
MA M I como voluntarios con la aplicación instalada, utilizando como técnica de evaluación
el recorrido cognitivo, teniendo como evaluador al alumno. Los voluntarios han tenido que
responder una serie de cuestiones respecto a una serie de tareas (encontrar como visualizar
una información u otra) y los resultados han sido positivos.
78
Figura 7.9: Prototipo del menú drawer y del filtro de contactos.
79
Figura 7.10: Prototipo del filtro entre fechas y del fragmento que describe las llamadas.
80
Capítulo 8
Conclusiones y Trabajo Futuro
E
este capítulo final se intenta condensar la información de los capítulos anteriores, una
vez que el lector ha comprendido el cometido y funcionamiento del presente trabajo.
Se justifica la cobertura de objetivos listados al inicio del documento junto con aquellos
posibles trabajos futuros o mejoras. Finalmente una conclusión subjetiva del autor.
N
8.1 Cobertura de los objetivos
A continuación se detallará cómo se han cubierto los objetivos contemplados en el Capítulo 2, individualmente y agrupados por temática:
8.1.1
Referentes al tratamiento de voz
(VOZ1) Grabar audio: Combinando el API de Android con técnicas de programación
concurrente se pueden recoger los datos obtenidos desde el micrófono a la vez que se
atiende a nuevas notificaciones de llamadas.
(VOZ2) Filtrar audio: Mediante algoritmos de detección de voz (VAD) se puede aislar
el silencio y ruido de la voz principal del hablante, gracias a la periodicidad de la voz
y los mecanismos de autocorrelación de la señal.
(VOZ3) Extraer características: Existen cuatros fuentes de datos, los MFCC, los coeficientes delta, el número de cruces por cero y la energía de la señal, que se obtienen
para cada fragmento de audio.
8.1.2
Referentes a la predicción
(PRE1) Obtener conjunto de voces: Se han obtenido las voces de 3 hombres y 2 mujeres bajo las condiciones de estrés y calma necesarias, obteniendo un total de 10 audios.
(PRE2) Elegir un algoritmo de aprendizaje: SVM fue el escogido, utilizando la librería
libSVM que posee una implementación en Java, integrándose de forma impecable con
el resto del trabajo.
(PRE3) Determinar los parámetros del algoritmo de aprendizaje: La validación cruzada y la búsqueda en malla, conjuntamente a las herramientas que libSVM nos proporciona permiten automatizar el proceso de búsqueda y determinar los valores óptimos.
81
(PRE4) Crear un modelo de estrés universal: El modelo refleja los parámetros del
algoritmo, el tipo de SVM y el kernel elegido. Los vectores de soporte que lo componen
están extraídos del conjunto de voces inicial.
(PRE5) Testear la bondad de la predicción: Además de la validación cruzada, se ha
elegido un criterio todavía más agresivo para comprobar la validez del modelo utilizando un script BASH y las herramientas por línea de comandos que ofrece libSVM. El
resultado ha sido satisfactorio alrededor del 85 % de éxito.
8.1.3
Referentes a la representación visual de los datos
(VIS1) Crear un filtro de contactos: Gracias a el API de interfaces de Android y los
componentes web que proporciona, se ha diseñado un grafo utilizando la libreria SigmaJS. Dicho grafo permite dar cuenta al usuario de cada llamada y además permite
agruparlas por individuo. También proporciona una lista de contactos con información
pormenorizada de cada uno.
(VIS2) Crear un filtro de franjas horarias: Utilizando la librería CanvasJS se ha generado un diagrama circular dividido por horas y con un tamaño proporcional a la cantidad
de estrés sufrido durante esas horas. Cada hora ofrece información en detalle.
(VIS3) Crear un filtro de fechas: Se permite al usuario introducir unas fechas límite de
forma cómoda e intuitiva, así como visualizar el estado del individuo en ese período
de tiempo utilizando un diagrama (vista que es reutilizada por el resto de filtros). Se
trata de un diagrama de líneas suave con doble escala, a un lado la duración y al otro
el nivel de estrés.
8.2 Trabajo futuro
Aunque la mayoría de funcionalidades han quedado resueltas a lo largo del proyecto,
existen funciones extra que serían muy interesantes de implementar pero que debido a las
limitaciones de tiempo no ha sido posible llevarlas a cabo.
Filtros adicionales
Existe multitud de parámetros adicionales que pueden extraerse en relación al momento
de ejecutar la llamada, por ejemplo podría realizarse una búsqueda del tiempo atmosférico,
e incluso podrían recogerse eventos del calendario para poder realizar una comparativa y
determinar de qué forma otros aspectos de la vida cotidiana afectan sensiblemente al estrés
padecido.
Con los datos recogidos actualmente podrían implementarse otros filtros sin necesidad de
incluir nueva información, como por ejemplo un filtrado por secuencialidad, ver la relación
de estrés que desencadena una secuencia de llamadas determinada. Esto podría implementarse mediante un grafo cuyas aristas fuesen llamadas y cuyos nodos fuesen contactos.
82
Umbral dinámico para el detector de voz (VAD)
Como ya se explicó en el Capítulo 4, el filtrado de silencio y ruido se realiza utilizando
un umbral que es fijo. Sin embargo, este umbral podría no adaptarse a todos los escenarios
posibles de ruido. Existen algoritmos para calcular dinámicamente este parámetro de forma estimada, utilizando para ello características como la relación señal/ruido (SNR), que se
define como la proporción existente entre la señal de voz y la potencia del ruido que la corrompe. Por un lado se definiría el ruido estacionario (continuo) y por otro el no estacionario
(ráfagas).
También destacar que hay técnicas más sofisticadas (y que requieren más tiempo de cómputo) para la detección de voz, a parte de aquellas que usan la autocorrelación como mecanismo
fundamental.
Coeficientes doble-delta
Aunque diversos estudios señalan que la inclusión de los coeficientes doble-delta es positivo de cara a la clasificación ya que mejora ligeramente el porcentaje de éxito [3], éstos no han
sido incluidos, a pesar de que la implementación es idéntica a los coeficientes deltas simples.
Incluir estos valores supondría añadir otras 12 variables al vector de características.
Extensión a otras plataformas
La implementación se ha realizado en la plataforma Android por las razones que ya expusieron en el Capítulo 1, sin embargo aumentar el rango de dispositivos a la que la aplicación
puede dar soporte resulta positivo de cara a su expansión. Plataformas como Apple dan soporte mediante lenguajes de programación como Objective-C y Swift y al ser incompatibles
con Java requieren crear un desarrollo independiente con todas las labores de mantenimiento
y testing por separado. Otra opción podrían ser las denominadas aplicaciones híbridas que
funcionan con tecnologías web y resultan ser multiplataforma, aunque el riesgo que incorporan es que pueden no incluir funcionalidades nativas que en un desarrollo ad-hoc podrían
ser triviales.
Realizar una clasificación multiclase
La base de la aplicación es una clasificación binaria, ya que partiendo de un segmento de
audio éste se determina como estresado o como calmado. Sin embargo, el nivel de estrés
es una variable continua como cualquier otra y pueden definirse diferentes estados, podrían
definir por ejemplo cuatro estados, «estrés absoluto», «estrés moderado», «estrés reducido»,
«estrés no significativo». La creación de un modelo se estrés se complica bastante ya que
tendríamos que tener un conjunto de voces lo suficientemente grande como para determinar
empíricamente los cuatro estados, además de que los resultados arrojados por SVM decaerían
significativamente.
83
Aumentar la cantidad de voces incluidas en el modelo
Crear un modelo de estrés universal no es sencillo debido a que cada voz es única. Las características del aparato fonador como cuerdas vocales, cavidad bucal, dientes y lengua, son
exclusivas para cada individuo, además hay que incluir el sesgo producido por dos factores:
la edad y el sexo. Los voluntarios incluidos rondan el intervalo de 18 a 45 años, 3 son hombres 2 son mujeres. Para mejorar la precisión podríamos incluir un número de voluntarios
mayor de forma repartida a lo largo de la franja de edades y equilibrado en cuanto a sexo
para evitar tener un conjunto de datos desbalanceado.
Algoritmos de aprendizaje alternativos
Podría testearse la eficacia de otros algoritmos diferentes y llevar a cabo un estudio de cuál
es el más efectivo a la hora de clasificar. Un paradigma bastante de moda actualmente son
las redes neuronales, inspiradas en el funcionamiento del sistema nervioso biológico, otros
como los árboles de decisión predicen usando diagramas lógicos. Otra posibilidad que cogió
bastante fuerza al inicio del proyecto fue la utilización de modelos de mezclas gaussianas,
en donde la distribución de probabilidad total se traduce en n distribuciones gaussianas o
normales.
8.3 Conclusiones
El gran atractivo del presente trabajo es el componente de I+D que conlleva. La temática
fue escogida inicialmente a pesar de que no se tenía grandes indicios de su viabilidad más allá
de un par de artículos. Suponía un gran riesgo por eso debía de realizarse un estudio inicial
que valorase el alcance de la clasificación. Gracias a los resultados tan positivos obtenidos,
se tomó la decisión de realizar una implementación concreta para Android.
El segundo de los atractivos como ya se comentó es la diversidad, de hecho los Capítulos
5, 6 y 7 corresponden con los ámbitos de las ciencias de la computación, las tecnologías de
la información y la ingeniería del software respectivamente. Además tiene una componente
de ejecución concurrente en segundo plano y una parte de matemáticas, física y tratamiento
de la señal, este último campo mucho más propio de la ingeniería electrónica que de la
informática como tal.
Por otro lado se ha requerido la lectura de gran cantidad de artículos de investigación,
algunos de ellos más útiles que otros. No han faltado los intentos infructuosos, por ejemplo
a la hora de reunir el conjunto de voces, donde se recogieron una gran cantidad de audios
anónimos vía internet, pero que debido al formato de origen (MP 3) tuvieron que ser desechados ya que los procesos de validación cruzada daban resultados bastante negativos. También
se seleccionaron diferentes algoritmos de VAD, todos con gran complejidad en la implementación, hasta dar con la técnica idónea. Por no hablar de la parte visual, en la que se tuvo
que lidiar con varias librerias de generación de gráficos hasta encontrar aquellas que mejores
84
resultados proporcionaban.
Como colofón final podríamos decir que se trata de un interesante trabajo de investigación,
que podría ser muy útil en el campo del m-health para poder mejorar nuestro estilo de vida
y nuestra salud en general, y para hacer del mundo un lugar mejor y más tranquilo.
85
ANEXOS
87
Anexo A
Aspectos Legales
A.1 Ley orgánica de protección de datos (LOPD)
Esta ley orgánica de ámbito español fue aprobada el 13 de diciembre de 1999, con base al
artículo 18 de la constitución española [7]. Dicho artículo trata sobre el derecho a la intimidad
familiar y personal, así como el secreto de la comunicaciones.
Su objetivo fundamental es el de regular los datos de carácter personal independientemente
del soporte en el que sean tratados. Establece una serie de principios de protección de datos
entre ellos:
1. Calidad de los datos, deben ser adecuados, pertinentes y no excesivos para una finalidad explícita y legítima. Queda prohibida la recogida de datos mediante medios
fraudulentos.
2. Derecho de información en la recogida de datos, deben darse a conocer aspectos como
la existencia de un fichero y la identidad y dirección del responsable, así como las
formas de ejercer los derechos de acceso, rectificación, cancelación y oposición.
3. Consentimiento del afectado, salvo algunas excepciones como administraciones públicas.
4. Comunicación de datos, se regula el traspaso de información a terceros, así como su
acceso por parte de éstos.
5. Deber de secreto, todos aquellos implicados en el tratamiento están obligados al secreto profesional y a la no transmisión de los datos.
6. Seguridad en los datos. Existen diferentes niveles de seguridad que deben aplicarse
dependiendo de la naturaleza de los datos.
7. Datos especialmente protegidos, se listan una serie de datos que son considerados especialmente sensibles y que determinan en parte el nivel de seguridad.
Asimismo el software realiza operaciones con datos tales como números de contacto y grabaciones privadas, dichas grabaciones son borradas al finalizar su respectivo procesamiento
y lo único que permanece en el dispositivo son una serie de vectores numéricos almacenados en archivos, que no corresponden con datos de carácter personal, ya que no hay persona
identificada ni identificable en ellos. Por otra parte el artículo 2.2.a) establece que:
89
«El régimen de protección de los datos de carácter personal que se establece en la presente
Ley Orgánica no será de aplicación:
a) A los ficheros mantenidos por personas físicas en el ejercicio de actividades exclusivamente personales o domésticas.»
Por ende no es de aplicación dicha ley, ya que el funcionamiento del software no está
regido por ninguna persona física ni jurídica, ni tampoco se lleva recolección alguna de datos,
ni su respectiva comunicación a terceros. Es estrictamente responsabilidad del destinatario
del software la transmisión o modificación de los datos recogidos mediante dicho medio.
A.2 Recursos gráficos
Los iconos de la aplicación resultante tales como imagénes de relojes, calendarios o usuarios han sido extraídos utilizando el motor de búsqueda Flaticon. Dicho motor es propiedad
R fundada en 2010 y permite la descarga de iconos en diferentes tade la empresa Freepik
maños y formatos (aunque está especializado en el formato vectorial SVG). Posee dos planes
de pago, uno de mensual en el cual pueden descargarse todo tipo de iconos sin limitaciones
y otro gratuito. Este último requiere la mención del autor de dichos iconos allá donde se
utilicen [4]. Se han generado versiones en blanco para un mejor contraste, este caso ya esta
contemplado por la licencia. Dicha licencia específica las condiciones:
Se tiene derecho al uso del material un número ilimitado de veces para uso comercial o
personal tanto para sitios web, aplicaciones, material impreso, publicidad, multimedia,
presentación de productos u ornamentación (pública o privada). Dicho derecho es no
transferible, no exclusivo y no sublicenciable.
Se permite alterar y crear material derivado.
La licencia es internacional.
No puede sublicenciarse, vender o alquilar ningún contenido, ni tampoco una versión
modificada del mismo.
No puede distribuirse el contenido a menos que sea expresamente autorizado.
No puede incluirse en ninguna otra base de datos o fichero por parte de terceros.
No pueden ofrecerse dichos contenidos (ni sus derivados) para descarga por parte de
terceros.
En concreto especifica colocar el texto «Designed by Freepik and distributed by Flaticon»
en algún lugar visible, en este caso se ha colocado en la sección «About it» del menú desplegable que aparece al pulsar los tres puntos arriba a la derecha. La Figura A.1 muestra los
iconos utilizados.
90
Figura A.1: Iconos originales utilizados para mejorar la experiencia visual en la aplicación.
91
Referencias
[1] Android official documentation for developers.
dido el 10-06-2016.
[2] ComScore Reports
ket
Share.
March
2015
https://developer.android.com.
U.S.
Smartphone
Subscriber
Acce-
Mar-
http://www.comscore.com/Insights/Market-Rankings/
comScore-Reports-March-2015-US-Smartphone-Subscriber-Market-Share.
Accedi-
do el 21-06-2016.
[3] Guide
for
mel
frequency
cesptral
coefficient
(mfcc).
http:
//practicalcryptography.com/miscellaneous/machine-learning/
guide-mel-frequency-cepstral-coefficients-mfccs/.
Accedido el 10-06-2016.
[4] Términos de licencia para el uso gratuito de iconos por parte del motor de búsqueda
de iconos Flaticon. http://www.flaticon.com/terms-of-use. Accedido el 20-06-2016.
[5] What are Kernels in Machine Learning and SVM?
https://www.quora.com/
What-are-Kernels-in-Machine-Learning-and-SVM. Accedido el 25-06-2016.
[6] Bangasser, Debra A, Andre Curtis, Beverly AS Reyes, Thelma T Bethea, Ioannis Parastatidis, Harry Ischiropoulos, Elisabeth J Van Bockstaele y Rita J Valentino: Sex differences in corticotropin-releasing factor receptor signaling and trafficking: potential
role in female vulnerability to stress-related psychopathology. Molecular psychiatry,
15(9):896–904, 2010.
[7] BOE, no 298: Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de
Carácter Personal (LOPD).
[8] Bravo, José y Ramón Hervás: Ambient Assisted Living and Home Care. Springer, 2012.
[9] Chang, Keng hao, Drew Fisher y John Canny: Ammon: A speech analysis library for
analyzing affect, stress, and mental health on mobile phones. Proceedings of PhoneSense, 2011.
[10] Cheng, Xianglin y Qiong Duan: Speech Emotion Recognition Using Gaussian Mixture
Model. En Proceedings of the 2012 International Conference on Computer Application
and System Modeling. Atlantis Press, 2012.
93
[11] Dohrenwend, Barbara S y Bruce P Dohrenwend: Stressful life events: Their nature and
effects. John Wiley & Sons, 1974.
[12] Endsley, Mica R: Designing for situation awareness: An approach to user-centered
design. CRC press, 2016.
[13] Fontecha, Jesús, Iván González, Vladimir Villarreal y José Bravo: Ambient Intelligence
for Health. Advances in vital signs and gait monitoring systems within mHealth environments. 2016.
[14] Ganchev, Todor, Nikos Fakotakis y George Kokkinakis: Comparative evaluation of
various MFCC implementations on the speaker verification task. En Proceedings of
the SPECOM, volumen 1, páginas 191–194, 2005.
[15] Hernandez-Leal, Pablo, Alban Maxhuni, L Enrique Sucar, Venet Osmani, Eduardo F
Morales y Oscar Mayora: Stress Modelling Using Transfer Learning in Presence of
Scarce Data. En Ambient Intelligence for Health, páginas 224–236. Springer, 2015.
[16] Hsu, Chih Wei, Chih Chung Chang, Chih Jen Lin y cols.: A practical guide to support
vector classification. 2003.
[17] Kaur, Jagvir y Abhilash Sharma: Emotion Detection Independent of User Using MFCC
Feature Extraction. International Journal of Advanced Research in Computer Science
and Software Engineering, 2014.
[18] Kishore, KV Krishna y P Krishna Satish: Emotion recognition in speech using MFCC
and wavelet features. En Advance Computing Conference (IACC), 2013 IEEE 3rd
International, páginas 842–847. IEEE, 2013.
[19] Liao, Wenhui, Weihong Zhang, Zhiwei Zhu y Qiang Ji: A real-time human stress monitoring system using dynamic Bayesian network. En 2005 IEEE Computer Society
Conference on Computer Vision and Pattern Recognition (CVPR’05)-Workshops, páginas 70–70. IEEE, 2005.
[20] Llamas Bello, César y Valentín Cardeñoso Payo: Reconocimiento automático del habla. técnicas y aplicación. Universidad de Valladolid. Secretariado de Publicaciones
E.I., 1998.
[21] Milton, A, S Sharmy Roy y S Tamil Selvi: Svm scheme for speech emotion recognition
using mfcc feature. International Journal of Computer Applications, 69(9), 2013.
[22] Muda, Lindasalwa, Mumtaj Begam y I Elamvazuthi: Voice recognition algorithms
using mel frequency cepstral coefficient (MFCC) and dynamic time warping (DTW)
techniques. arXiv preprint arXiv:1003.4083, 2010.
94
[23] Müller, Meinard: Information retrieval for music and motion, volumen 2. Springer,
2007.
[24] Nguyen, Phuoc, Dat Tran, Xu Huang y Dharmendra Sharma: A proposed feature extraction method for EEG-based person identification. En International Conference on
Artificial Intelligence, 2012.
[25] Ranganathan, G, R Rangarajan y V Bindhu: Evaluation of ECG signal for mental stress
assessment using fuzzy technique. International Journal of Soft Computing and Engineering (IJSCE), 1(4):195–201, 2011.
[26] Ruiz, Cristian Carretón: SiMoA: Sistema de Monitorización del Asma. Informe técnico,
Universidad de Castilla-La Mancha (UCLM), 2014.
[27] Sancho, Jesús Bobadilla, Pedro Gómez Vilda y Jesús Bernal Bermúdez: La Transformada de Fourier: Una visión pedagógica. Estudios de fonética experimental, (10):41–
74, 1999.
[28] Sandulescu, Virginia, Sally Andrews, David Ellis, Radu Dobrescu y Oscar MartinezMozos: Mobile app for stress monitoring using voice features. En E-Health and Bioengineering Conference (EHB), 2015, páginas 1–4. IEEE, 2015.
[29] Santos-Garcia, Gustavo: Inteligencia artificial y matematica aplicada. Universidad de
Valladolid. Secretariado de Publicaciones E.I., 2002.
[30] Santos Sierra, Alberto de, Carmen Sánchez Ávila, Javier Guerra Casanova y Gonzalo
Bailador del Pozo: Real-time stress detection by means of physiological signals. Recent
Application in Biometrics, 58:4857–65, 2011.
[31] Sims, Chris y Hillary Louise Johnson: Scrum: A breathtakingly brief and agile introduction. Dymax, 2012.
[32] Sofware, Dell: Support Vector Machines (SVM) Introductory Overview. http://www.
statsoft.com/Textbook/Support-Vector-Machines. Accedido el 23-06-2016.
95
Este documento fue editado y tipografiado con LATEX empleando
la clase esi-tfg (versión 0.20160630) que se puede encontrar en:
https://bitbucket.org/arco group/esi-tfg
[respeta esta atribución al autor]
97