Desarrollo de un sistema de reconocimiento del habla distribuido basado en Android

UNIVERSIDAD POLIT ´ ECNICA DE VALENCIA ESCUELA POLIT ´ ECNICA SUPERIOR DE GAND´ IA Grado en Ingenier´ ıa de Sistemas de Telecomunicaci´ on Sonido e Imagen ”Desarrollo de un sistema de reconocimiento del habla en Android” TRABAJO FINAL DE GRADO Autor: Emilio Granell Romero Directores: Carlos D. Mart´ınez Hinarejos Vicent Tamarit Ballester GANDIA, 2012 “El ser humano es enemigo de aquello que ignora: Ense ˜na una lengua: evitar´as la estupidez de una guerra; divulga una cultura: conseguir´as hacer popular a un pueblo entre las gentes de otro.” Na¨ım Boutanos Resumen En este trabajo se presenta un sistema de interpretaci´ on autom´ atica distribuido. Este sistema est´ a compuesto por una aplicaci´ on cliente desarrollada para dispositivos m´ oviles con sistema operativo Android, que interact´ ua con los usuarios, y un servidor encargado de las tareas autom´ aticas de reconocimiento del habla y traducci´ on. El dominio de interpretaci´ on est´ a limitado a una tarea concreta basada en la interacci´ on que un turista podr´ ıa tener a su llegada a un hotel. Nuestro sistema es capaz de traducir frases habituales en una comunicaci´ on oral en la recepci´ on de un hotel del castellano al ingl´ es. Abstract In this work we present a distributed system for automatic interpretation. This system consists of a client application developed for mobile devices with Android operating system, which interacts with users, and a server dedicated to the automatic speech recognition and machine translation. The domain of interpretation is limited to a particular task based in the interaction that a tourist may have on arrival at a hotel. Our system is able to translate standard sentences in oral communication at the reception of a hotel from Spanish into English. “A todos los que siempre creyeron en m´ı m´as de lo que yo mismo nunca cre´ı” En especial me gustar´ıa expresar mi agradecimiento: A los directores de este proyecto Carlos y Vicent, por ofrecerme su experiencia con total disponibilidad durante la realizaci´ on de este proyecto. A Pati, por echarme una mano durante la comprobaci´ on del sistema y la revisi´ on de este documento, y por poner su voz en el v´ ıdeo de demostraci´ on. A todos los voluntarios (familiares y amigos) que participaron desinteresadamente en la comprobaci´ on de Hermes. ´ Indice general 1. Introducci ´on 1 1.1. Interpretaci´ on autom´ atica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1.1. EuTrans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1.2. Est´ andar ETSI 201 108 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Dispositivos m´ oviles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3. Motivaci´ on y objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.4. Organizaci´ on del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Fundamentos te ´oricos 5 2.1. Reconocimiento autom´ atico del habla . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. iATROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.2. Reconocimiento: Algoritmo de Viterbi . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. An´ alisis de la se ˜ nal de voz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.1. Modelo de generaci´ on de voz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.2. An´ alisis Cepstral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3. Comunicaci´ on en sistemas distribuidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.1. Arquitectura cliente-servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4. Dispositivos m´ oviles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4.1. Clasificaci´ on de los dispositivos m´ oviles . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.2. Sistemas operativos m´ oviles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3. Hermes 19 3.1. Modificaci´ on respecto al est´ andar ETSI 201 108 . . . . . . . . . . . . . . . . . . . . . . 19 3.2. Arquitectura y dise˜ no . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.3. Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.3.1. Actividad 1: Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Emilio Granell Romero I Desarrollo de un sistema de reconocimiento del habla en Android extraen de la onda ac´ ustica, mediante an´ alisis estad´ ısticos. Como ventaja respecto a los sistemas basados en el conocimiento, aqu´ ı las reglas no las define una persona, sino que son obtenidas mediante an´ alisis estad´ ısticos que pueden describirse f´ acilmente mediante algoritmos. Presentan, por otra parte, una desventaja: la necesidad de adquirir un corpus anotado lo suficientemente grande y representativo que pueda servir de referencia. En este proyecto la direcci´ on que se ha seguido ha sido la basada en t´ ecnicas estad´ ısticas. Para ello es necesario definir tres modelos: el sint´ actico o modelo del lenguaje, el l´ exico y el ac ´ ustico. Modelo sint ´actico El modelo sint´ actico, tambi´ en denominado modelo del lenguaje, define todas las posibles frases susceptibles de ser reconocidas por el sistema. En un nivel m´ as general incluir´ ıa todas las posibles frases sint´ acticamente correctas del lenguaje, lo que generar´ ıa un modelo inabarcable para la capacidad de c´ omputo actual. Por ello el modelo de lenguaje se define generalmente para una tarea concreta. Este modelo, adem´ as de representar la sintaxis del lenguaje, puede incorporar la informaci´ on sem´ antica de las palabras. Para implementarlos se utilizan gram´ aticas probabil´ ısticas [20] (o su equivalente como aut´ omata), o N-gramas [15]. En el caso en el que se incluya sem´ antica adem´ as de reconocimiento se suelen utilizar transductores de estados finitos (TEF). Modelo l´exico El modelo l´ exico le indica al sistema la pronunciaci´ on de cada una de las palabras que componen el modelo sint´ actico. El modelo l´ exico describe la pronunciaci´ on de cada palabra como una secuencia de s´ ımbolos que representan sonidos, definidos mediante los modelos ac ´ usticos. Suelen implementarse como aut´ omatas finitos deterministas (AFD). Por ejemplo, la palabra “Juan” generar´ ıa el modelo de estados finitos de la Figura 2.1. /x/ /u/ /a/ /n/ Figura 2.1: Aut´ omata de estados finitos para la palabra “Juan” (N´ otese que se trata de la transcripci´ on fon´ etica). Modelo ac ´ustico El modelo ac´ ustico es el modelo asociado a cada sonido. En el caso del habla suele asignarse uno a cada fonema del lenguaje, de forma que sea posible comparar las caracter´ ısticas de una secuencia ac ´ ustica con los modelos descritos, a fin de obtener una frase del lenguaje como hip´ otesis de la frase pronunciada. La implementaci´ on m´ as com ´ un de estos modelos es mediante Modelos Ocultos de Markov cont´ ınuos (HMM1por sus siglas en ingl´ es). Un HMM es un modelo de estados finitos probabil´ ıstico. La notaci´ on de un HMM suele ser λ= (A, B, π), donde: Aindica las probabilidades de transici´ on entre estados. Bcontiene las probabilidades de emisi´ on de cada s´ ımbolo para cada estado. πes la probabilidad, para cada estado, de ser inicial. 1Hidden Markov Model 6 Emilio Granell Romero Cap´ıtulo 2. Fundamentos te´oricos Esta definici´ on corresponde con la de un HMM gen´ erico. A partir de aqu´ ı se pueden distinguir entre HMM discretos y continuos. La diferencia est´ a en c´ omo se definan las probabilidades de emisi´ on, si es mediante probabilidades discretas o mediante funciones continuas. Los HMM continuos habitualmente utilizan mixturas de distribuciones Gausianas como funciones de probabilidad. A pesar de que en la literatura se encuentran otras funciones de densidad de probabilidad, el uso de las Gausianas multivariadas es el recomendado, debido a que pueden usarse para aproximar cualquier funci´ on de densidad [16]. Generar un modelo ac ´ ustico es una tarea muy laboriosa que un proyecto como este no puede abarcar; por esta raz´ on se ha recurrido a un conjunto de modelos ya existente, entrenados a partir del corpus Albayzin [3]. Este corpus se obtuvo con la colaboraci´ on de varias universidades espa ˜ nolas, y en ´ el han participado 100 locutores representantes de las variedades geogr´ aficas y sociales m´ as importantes del espa ˜ nol; se ha mantenido tambi´ en una distribuci´ on igualitaria de ambos sexos. En total se grabaron 4097 frases, que suponen un total de, aproximadamente, tres horas y media de se˜ nal. La tipolog´ ıa de los modelos es de tres estados, de izquierda a derecha, con bucles y sin saltos. Se utiliza una mixtura de 128 gaussianas (con matriz de covarianza diagonal) de 33 componentes y cada modelo es monofonema. 2.1.1. iATROS iATROS [14] es el acr´ onimo de “Improved Automatically Trainable Recognizer Of Speech”. iATROS es un reconocedor autom´ atico tanto para habla como para texto manuscrito y est´ a compuesto de dos m´ odulos de preprocesado y extracci´ on de caracter´ ısticas (para la se ˜ nal de voz y para las im´ agenes de texto manuscrito) y un m´ odulo principal de reconocimiento. Los m´ odulos de preprocesado y extracci´ on de caracter´ ısticas proporcionan vectores de caracter´ ısticas al m´ odulo de reconocimiento, que utiliza HMM y modelos de lenguaje para realizar la b´ usqueda de las mejores hip´ otesis del reconocimiento. 2.1.2. Reconocimiento: Algoritmo de Viterbi Para realizar el reconocimiento de una frase dicha, iATROS despliega los tres modelos anteriores, obteniendo un HMM sobre el que buscar el camino m´ as probable que generar´ ıa la frase pronunciada. Cada transici´ on del TEF que representa el modelo de lenguaje se despliega en el aut´ omata de la palabra emitida en la transici´ on, definido en el modelo l´ exico, y ´ este, a su vez, despliega cada una de sus transiciones en un HMM, definido en el modelo ac´ ustico. El resultado final se puede asumir (de manera simplificada) como un enorme HMM que representa al modelo de lenguaje. El algoritmo de Viterbi [5] es la piedra angular del reconocimiento del habla y pieza fundamental en iATROS. Es el encargado de, dado un HMM y una observaci´ on, calcular la secuencia de estados del modelo que m´ as probabilidad tiene de haber generado esa observaci´ on. En este caso concreto, a partir de la secuencia sonora adecuadamente preprocesada, se trata de buscar dentro del modelo de lenguaje desplegado el camino que m´ as probabilidad tiene de haber generado esa onda. El m´ etodo computa, dado un HMM, la secuencia m´ as probable de estados Sque ha seguido el HMM para producir una observaci´ on O. Expresado formalmente, el problema a resolver consiste en: dado un HMM λy una secuencia de observaciones O, se busca la secuencia de estados S∗de modo que: S∗= arg max S Pr(O, S|λ)(2.1) La implementaci´ on m´ as eficiente de Viterbi es como algoritmo iterativo, ya que se puede Emilio Granell Romero 7 Desarrollo de un sistema de reconocimiento del habla en Android expresar como un algoritmo de programaci´ on din´ amica; sin embargo, es habitual formularlo de forma recursiva. 1. Inicializaci ´on:∀i∈estado Hacer δ1(i) = πibi(o1) ψ1(i) = 0 2. Recursi ´on:∀t/t = 2, ..., T ∀j/j ∈estado Hacer δt(j) = m´axi[δt−1aij]bj(ot) ψt(j) = arg max i [δt−1(i)aij] 3. Finalizaci ´on: P∗= m´axi[δT(s)] s∗ T= arg max s∈SF [δT(S)] 4. Recuperaci ´on del camino:∀t/t =T−1, ..., 1Hacer s∗ t=ψt+1(s∗ t+1) Tes la longitud de la observaci´ on O,P∗es la probabilidad del camino m´ as probable, s∗ T es el estado final m´ as probable y los s∗ tforman la ruta de estados m´ as probable (la secuencia de estados que resulta ´ util para el reconocimiento). Durante la ejecuci´ on del algoritmo se considera que cada estado del HMM tiene una puntuaci´ on, que representa la probabilidad de transitar desde el estado inicial hasta ella. En realidad, puesto que el orden de magnitud de las probabilidades puede llegar a ser muy peque ˜ no, para no perder informaci´ on esta puntuaci´ on es el logaritmo cambiado de signo de la probabilidad. Esto no s´ olo evita el underflow, sino que adem´ as facilita los c´ alculos, pues las multiplicaciones de probabilidades son ahora sumas. En la formulaci´ on anterior estas probabilidades parciales se encuentran en δi. El problema de encontrar Pr(O|λ)es NP-Duro. El coste del algoritmo de Viterbi en su implementaci´ on iterativa (por programaci´ on din´ amica) es O(NT B), siendo Bel factor de ramificaci´ on efectiva del algoritmo de programaci´ on din´ amica asociado, y Nel n ´ umero total de estados. Para reducir el espacio de b´ usqueda (y con ello el coste del algoritmo) y mejorar el resultado del reconocimiento, se a ˜ naden al reconocedor tres par´ ametros heur´ ısticos: Beam, Grammar Scale Factor y Word Insertion Penalty. A continuaci´ on se detallan estos par´ ametros: Beam: Cada transici´ on del modelo de lenguaje se despliega, como se ha visto, en un HMM sobre el que se aplica el algoritmo de Viterbi. Si la transici´ on recibe una puntuaci´ on mayor que la mejor puntuaci´ on m´ as este factor, se poda y dejan de explorarse los caminos que desde ella se pudieran generar. Con este factor puede controlarse el n´ umero de caminos que hay que explorar. Para valores bajos muchos caminos se podar´ an, lo que previsiblemente repercutir´ a en un mayor error de reconocimiento pero en un menor tiempo de c´ alculo, dado que cada iteraci´ on requiere actualizar la puntuaci´ on de menos caminos. Grammar Scale Factor: Este par´ ametro modifica el peso de las probabilidades del modelo de lenguaje frente al modelo ac ´ ustico. Es ´ util para equilibrar la influencia del modelo ac ´ ustico y la gram´ atica. Valores altos dan m´ as importancia a la gram´ atica, mientras que valores bajos hacen que el modelo ac´ ustico gu´ ıe el reconocimiento. Word Insertion Penalty: Penaliza la inserci´ on de nuevas palabras. Cuanto m´ as alto es este factor, m´ as se premia a las frases cortas en n ´ umero de palabras. Este par´ ametro es necesario porque frases largas, o incluso palabras, pueden decodificarse como palabras m´ as cortas, rompiendo el significado original. Por ejemplo palabras compuestas como “autom´ovil”, pueden ser reconocidas como “auto” y“m´ovil”. Ajustando este par´ ametro se controla este efecto en el reconocimiento. 8 Emilio Granell Romero Cap´ıtulo 2. Fundamentos te´oricos Para adaptar el reconocedor a nuevas tareas basta con modificar el modelo de lenguaje (es decir, el aut´ omata que representa el lenguaje de la tarea), as´ ı como el modelo l´ exico, incluyendo todas las palabras de la tarea. El modelo ac´ ustico, dado que es m´ as general, puede reutilizarse en varias tareas, siempre que la lengua sea la misma. 2.2. An ´ alisis de la se ˜ nal de voz En el reconocimiento del habla, la se ˜ nal de voz, una vez digitalizada, se procesa para producir una nueva representaci´ on param´ etrica de la voz. Esta representaci´ on es en forma de secuencia de vectores de caracter´ ısticas principales, que deben representar la informaci´ on contenida en la envolvente del espectro. 2.2.1. Modelo de generaci ´on de voz El sistema de generaci´ on de voz se puede modelar como un sistema compuesto por un filtro variable en el tiempo, un generador de ruido aleatorio y un generador de impulsos, como se puede ver en la Figura 2.2. Filtro variable en el tiempo Generador de impulsos Generador de ruido aleatorio X X Voz EV EC Figura 2.2: Modelo de producci´ on de voz. Este modelo tiene dos entradas, una para se˜ nales sonoras (vocales) EVy otra para las se˜ nales no sonoras (consonantes) EC. Para las se ˜ nales sonoras la excitaci´ on es un tren de impulsos, mientras que para las se˜ nales no sonoras la excitaci´ on es ruido aleatorio. La combinaci´ on de estas dos se ˜ nales modela el funcionamiento de la glotis. A continuaci´ on, la se˜ nal de entrada pasa por un filtro que modela el funcionamiento del tracto vocal para obtener la se˜ nal de voz. En este modelo es posible considerar que la se˜ nal de voz para fonemas sonoros se genera mediante la convoluci´ on mostrada en la Ecuaci´ on 2.2. s(t) = e(t)∗h(t)(2.2) En ella, la entrada al sistema es el tren de pulsos gl´ oticos e(t)yh(t)es la respuesta al impulso del tracto vocal. Emilio Granell Romero 9 Desarrollo de un sistema de reconocimiento del habla en Android Cuando se pasa al dominio frecuencial mediante la transformada de Fourier, se observa que el espectro en frecuencia de la se˜ nal de voz, se corresponde con el producto de la transformada de Fourier de la se ˜ nal de entrada por la respuesta en frecuencia del filtro. S(ω) = E(ω)H(ω)(2.3) 2.2.2. An ´alisis Cepstral Se define el cepstral de una se ˜ nal s(t)como la transformada inversa de Fourier del m´ odulo del espectro en escala logar´ ıtmica de esa se˜ nal, es decir: c(t) = F−1[log(S(ω))] (2.4) Desarrollando el ceptral para S(ω)se obtiene: c(t) = F−1[log |E(ω)|] + F−1[log |H(ω)|](2.5) c(t) = ce(t) + ch(t)(2.6) De la Ecuaci´ on 2.6 se concluye que el cepstral de una se˜ nal es la suma del cepstral de la se˜ nal de entrada y del cepstral de la respuesta al impulso del filtro. Generalmente, la se ˜ nal del pulso gl´ otico var´ ıa muy lentamente en relaci´ on con la respuesta en frecuencia del filtro que modela el funcionamiento del tracto vocal. Al realizar la primera transformaci´ on de Fourier se puede observar como e(t)es modulada por h(t). Por ello, al realizar la segunda transformaci´ on despu´ es de haber aplicado el logaritmo al m´ odulo del espectro, se queda en las primeras muestras cepstrales la informaci´ on relativa a la respuesta en frecuencia del filtro que modela el tracto vocal. La mayor parte de la informaci´ on del locutor se encuentra en las cuerdas vocales, mientras que la informaci´ on de la palabra pronunciada se encuentra en las caracter´ ısticas del tracto vocal. Por ello, en el reconocimiento autom´ atico del habla, lo que interesa son las caracter´ ısticas del tracto vocal y se utilizan las componentes ceptrales bajas. En cambio, en el reconocimiento autom´ atico de locutores se utilizar´ an las componentes cepstrales altas, que contienen las caracter´ ısticas de la glotis. Para el reconocimiento del habla es usual considerar de 10 a 12 coeficientes cepstrales (los 10 ´ o 12 primeros) obtenidos sobre una ventana temporal de unos 20 ´ o 30 milisegundos de duraci´ on. Para obtener los cepstrales de una se˜ nal de voz, se puede utilizar el algoritmo de extracci´ on definido en el est´ andar ETSI 201 108 [4]. En la Figura 2.3 se muestra el diagrama de bloques de este algoritmo de extracci´ on y a continuaci´ on se explica detalladamente cada uno de estos bloques. ADC OC F PE W FFT MF LOG DCT Voz Cepstrales Abreviaturas ADC OC F PE W FFT MF LOG DCT Conversión analógico - digital Compensación de Offset División en tramos Pre - énfasis Ventanas de análisis Transformada rápida de Fourier Filtrado de la señal Transformación logarítmica Transformada de coseno discreta Figura 2.3: Diagrama de bloques del algoritmo de extracci´ on de cepstrales. 10 Emilio Granell Romero Cap´ıtulo 2. Fundamentos te´oricos Conversi ´on anal ´ogico - digital En primer lugar, se debe definir la frecuencia de muestreo de la digitalizaci´ on de la se˜ nal de voz. Como el rango de inteligibilidad de la voz se encuentra en el espectro de frecuencias entre 300 Hz y 3400 Hz, se requiere una frecuencia de muestreo m´ ınima de 8 KHz. Sin embargo, el est´ andar permite adem´ as frecuencias de muestreo de 11 KHz y 16 KHz. Compensaci ´on de Offset A continuaci´ on, se debe aplicar un filtro de muesca (notch) a las muestras de la se ˜ nal de entrada Sin para retirar su valor de continua, produciendo una se ˜ nal libre de continua Sof . Sof (n) = Sin(n)−Sin(n−1) + 0,999Sof (n−1) (2.7) Divisi ´on en tramos La se˜ nal libre de continua Sof se divide en tramos superpuestos de Nmuestras. La diferencia entre los puntos de inicio entre tramos consecutivos es de Mmuestras y define el n´ umero de tramos por unidad de tiempo. Los valores espec´ ıficos de NyMdependen del valor de la frecuencia de muestreo elegida, como se puede apreciar en la Tabla 2.1. El tama˜ no de los tramos es 25 ms para 8 y 16 KHz y de 23.27 ms para 11 KHz. Frecuencia de muestreo (KHz) 8 11 16 Longitud del tramo N(muestras) 200 256 400 Intervalo de cambio M(muestras) 80 110 160 Tabla 2.1: Valores de la longitud del tramo y del intervalo de cambio dependiendo de la frecuencia de muestreo. Filtro de pre - ´enfasis A continuaci´ on se aplica un filtro de pre-´ enfasis a cada tramo de la se˜ nal de entrada libre de continua: spe(n) = sof (n)−0,97sof (n−1) (2.8) donde, sof yspe son las se˜ nales de entrada y de salida del bloque de pre-´ enfasis respectivamente. Ventanas de an ´alisis A la salida del bloque de pre-´ enfasis se aplica una ventana de Hamming de longitud N: sw(n) = 0,54 −0,46 cos 2π(n−1) N−1spe(n),1≤n≤N(2.9) donde, Nes la longitud del marco y spe yswson las se ˜ nales de entrada y salida del bloque de aplicaci´ on de ventanas respectivamente. Emilio Granell Romero 11 Desarrollo de un sistema de reconocimiento del habla en Android Transformada r ´apida de Fourier (FFT) Cada ventana de Nmuestras se completa con ceros hasta 256 muestras para 8 y 11 KHz y hasta 512 para 16 KHz de frecuencia de muestreo. A continuaci´ on, se aplica la transformada de Fourier de longitud F F T L = 256 ´ oF FT L = 512 para obtener el espectro de la se˜ nal: bink= F F T L−1 X n=0 sw(n)e−jnk 2π F F T L  , k = 0, ..., F F T L −1(2.10) donde, swes la se ˜ nal de entrada en el bloque FFT, F F T L es la longitud de la FFT (256 ´ o 512 muestras), y binkes el valor absoluto del vector complejo resultante. Debido a la simetr´ ıa del espectro, s´ olo los t´ erminos bin0,...,F F T L/2se entregan a la salida de este bloque. Filtrado de la se ˜nal Los componentes de baja frecuencia se ignoran, porque las frecuencias ´ utiles se encuentran entre los 64 Hz y la mitad de la frecuencia de muestreo. Esta banda se encuentra dividida en 23 canales equidistantes en el dominio de la frecuencia de Mel. La elecci´ on de la frecuencia de inicio en 64Hz, corresponde al caso donde toda la banda de frecuencia se encuentra dividida en 24 canales y el primer canal es descartado usando cualquiera de las tres posibles frecuencias de muestreo. Las frecuencias centrales de cada canal en t´ erminos de los ´ ındices bin de la FFT (cbinipara el canal i) se calculan como sigue: Mel{x}= 2595 log10 1 + x 700(2.11) fci=Mel−1Mel {fstart}+Mel {fs/2} − Mel {fstart} 23 + 1 i, i = 1, ..., 23 (2.12) cbini=round fci fs F FT L(2.13) donde, round(.)significa redondear al siguiente entero. La salida de los filtros de Mel es la suma ponderada de los valores de la magnitud del espectro obtenida con la transformada r´ apida de Fourier (bini) de cada banda. La aplicaci´ on de las ventanas triangulares medio superpuestas es como sigue: fbankk= cbink X i=cbink−1 i−cbink−1+ 1 cbink−cbink−1+ 1bini+ cbink+1 X i=cbink+1 1−i−cbink cbink+1 −cbink+ 1bini(2.14) donde, k= 1, ..., 23,cbin0ycbin24 denotan los ´ ındices bin de la FFT que corresponden a la frecuencia de inicio y a la frecuencia mitad de la de muestreo respectivamente. cbin0=round fstart fs F FT L(2.15) cbin24 =round fs/2 fs F FT L=F F T L/2(2.16) 12 Emilio Granell Romero Cap´ıtulo 2. Fundamentos te´oricos Transformaci ´on logar´ıtmica A la salida de los filtros de Mel se aplica una funci´ on logar´ ıtmica a cada canal. fi= ln(fbanki), i = 1, ..., 23 (2.17) Se establece un valor m´ ınimo para la transformaci´ on logar´ ıtmica, de modo que la salida de este bloque no puede ser menor de −50. Transformada de coseno discreta Finalmente, se obtienen los 13 coeficientes cepstrales aplicando una transformaci´ on de coseno discreta a la salida de la funci´ on logar´ ıtmica. Ci= 23 X j=1 fjcos πi 23(j−0,5),0≤i≤12 (2.18) 2.3. Comunicaci´ on en sistemas distribuidos Un sistema distribuido se define como una colecci´ on de computadoras aut´ onomas separadas f´ ısicamente y conectadas entre s´ ı por una red de comunicaci´ on. En ella cada m´ aquina posee sus propios componentes de hardware y el software adecuado para que el sistema sea visto por los usuarios como un ´ unico sistema de computaci´ on. 2.3.1. Arquitectura cliente-servidor La arquitectura cliente-servidor es un modelo de sistema distribuido en el que el trabajo se reparte entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el servidor, que le da respuesta, como podemos ver en la representaci´ on de la Figura 2.4. La mayor´ ıa de las aplicaciones en Internet utilizan la arquitectura cliente-servidor, como por ejemplo los servidores web, los servidores de archivos, los servidores del correo, etc. HTTP Petición Respuesta Servidor Cliente Figura 2.4: Arquitectura cliente-servidor. Cliente: Es quien inicia las peticiones y espera las respuestas del servidor. Por lo general, puede conectarse a varios servidores a la vez y normalmente interact´ ua directamente con los usuarios finales mediante una interfaz gr´ afica de usuario. Servidor: Al iniciarse espera a que le lleguen las peticiones de los clientes. Tras la recepci´ on de una solicitud, la procesa y luego env´ ıa la respuesta al cliente. Por lo general, acepta conexiones Emilio Granell Romero 13 Desarrollo de un sistema de reconocimiento del habla en Android desde un gran n ´ umero de clientes y no es frecuente que interact´ ue directamente con los usuarios finales. Comunicaci ´on entre clientes y servidores (Sockets) Servidor Cliente Abrir el canal de comunicación Abrir el canal de comunicación Esperar a recibir solicitudes Aceptar petición Envío y recepción de datos Conectar con el servidor Envío y recepción de datos Cerrar el canal de comunicación Cerrar el canal de comunicación Figura 2.5: Modelo de comunicaci´ on cliente-servidor. A los puntos finales de una comunicaci´ on entre dos sistemas que intercambian informaci´ on a trav´ es de una red de comunicaciones se les llama sockets [12]. Un socket queda definido por la direcci´ on IP del dispositivo en el que se encuentra y un n ´ umero de puerto de 16 bits. Una conexi´ on est´ a determinada por un par de sockets, el del cliente y el del servidor. En la Figura 2.5 se muestra un modelo t´ ıpico de comunicaci´ on por sockets en una arquitectura cliente-servidor. Hay dos tipos de sockets: socket stream y socket datagram. Socket stream: Utilizan el protocolo TCP (Transmission Control Protocol), por lo que tambi´ en son conocidos como sockets orientados a conexi´ on. El utilizar el protocolo TCP implica que antes de enviar la informaci´ on se debe establecer la conexi´ on entre los dos sockets, y ofrece la ventaja de que incorpora la correcci´ on de errores de forma transparente al programador. Socket datagram: Utilizan el protocolo UDP (User Datagram Protocol), por lo que tambi´ en son conocidos como sockets sin conexi´ on. Al utilizar dicho protocolo se puede enviar la informaci´ on sin necesidad de haber establecido la comunicaci´ on entre los sockets. La ventaja de este tipo de sockets es que produce una menor sobrecarga sobre la informaci´ on transmitida, a cambio de no tener incorporada la correcci´ on de errores. Esto lo hace m´ as r´ apido y por tanto m´ as interesante en una red en la que se pierdan pocos paquetes y para aplicaciones de tiempo real. 2.4. Dispositivos m ´ oviles Los dispositivos m´ oviles son aparatos de peque ˜ no tama˜ no, con algunas capacidades de procesamiento, con conexi´ on permanente o intermitente a una red, con memoria limitada y dise˜ nados espec´ ıficamente para una funci´ on, aunque pueden llevar a cabo otras m´ as generales [21]. 14 Emilio Granell Romero Cap´ıtulo 2. Fundamentos te´oricos 2.4.1. Clasificaci ´on de los dispositivos m ´oviles Dado el variado n´ umero de niveles de funcionalidad asociado con dispositivos m´ oviles, en el 2005, T38 y DuPont Global Mobility Innovation Team propusieron los siguientes est´ andares para la definici´ on de dispositivos m´ oviles: Dispositivo m ´ovil de datos limitado: Dispositivos que tienen una pantalla peque ˜ na, principalmente basada en pantalla de tipo texto con servicios de datos generalmente limitados a SMS y acceso WAP. Dispositivo m ´ovil de datos b ´asico: Dispositivos que tienen una pantalla de mediano tama˜ no, (entre 120 x 120 y 240 x 240 pixels), men´ u o navegaci´ on basada en iconos por medio de una rueda o cursor, y que ofrecen acceso a e-mails, libreta de direcciones, SMS, y un navegador web b´ asico. Dispositivo m ´ovil de datos mejorado: Dispositivos que tienen pantallas de medianas a grandes (por encima de los 240 x 120 pixels), navegaci´ on de tipo stylus, y que ofrecen las mismas caracter´ ısticas que el “dispositivo m´ovil de datos b´asico”, m´ as aplicaciones nativas y corporativas usuales, en versi´ on m´ ovil. Este tipo de dispositivos utilizan un sistema operativo como iOS, Windows Phone, Symbian, Android, etc. 2.4.2. Sistemas operativos m´oviles Un sistema operativo m´ ovil es un programa que gestiona los procesos b´ asicos de un dispositivo m´ ovil al igual que las computadoras utilizan Windows o Linux entre otros. Sin embargo, los sistemas operativos m´ oviles son bastante m´ as simples y est´ an m´ as orientados a la conectividad inal´ ambrica, los formatos multimedia para m´ oviles y las diferentes maneras de introducir informaci´ on en ellos. En el estudio realizado por Gartner Inc. [7] se muestra una comparativa entre los dispositivos m´ oviles vendidos a nivel mundial en el segundo trimestre del 2011 respecto al mismo periodo del 2010. Presenta los resultados por empresas fabricantes (Figura 2.6) y por sistemas operativos (Figura 2.7). De los resultados de este estudio, podemos concluir que los usuarios prefieren dispositivos m´ oviles con los sistemas operativos Android e iOS, mientras que los dispositivos con Symbian y BlackBerry OS (Research In Motion) cada d´ ıa son menos apreciados. Observando la gr´ afica de fabricantes, se confirma la afirmaci´ on anterior: Nokia est´ a perdiendo cuota de mercado a pasos agigantados por haber apostado por un sistema operativo m´ ovil que no acaba de gustar a los usuarios, como es Windows Phone de Microsoft, que al igual que Symbian (su anterior sistema operativo) y el Blackberry OS de Research In Motion, est´ an cediendo terreno a Android e iOS. BlackBerry OS BlackBerry OS es el sistema operativo utilizado en una l´ ınea de tel´ efonos inteligentes denominados BlackBerry, que integran el servicio de correo electr´ onico m´ ovil. BlackBerry fue desarrollado por la compa ˜ n´ ıa canadiense Research In Motion (RIM). Aunque incluye las aplicaciones t´ ıpicas de un tel´ efono inteligente (libreta de direcciones, calendario, listas de tareas, etc.), es fundamentalmente conocido por su capacidad para enviar y recibir correo electr´ onico de Internet accediendo a las redes m´ oviles de las compa ˜ n´ ıas de telecomunicaciones que brindan este servicio. Symbian Symbian es un sistema operativo m´ ovil que fue producto de la alianza de varias empresas de telefon´ ıa m´ ovil, entre las que se encuentran Nokia, Sony Ericsson, Psion, Samsung, Siemens, Emilio Granell Romero 15 Desarrollo de un sistema de reconocimiento del habla en Android Proveedor de Contenido: Proporciona datos a las aplicaciones; a trav´ es de un proveedor de contenido su aplicaci´ on puede compartir datos con otras. Android contiene una base de datos SQLite, que puede servir como proveedor de contenidos. Receptor de Mensajes: Recibe los mensajes del sistema y las solicitudes impl´ ıcitas; se puede utilizar para responder a condiciones cambiantes en el sistema. Una aplicaci´ on puede registrarse como receptor de la difusi´ on de ciertos eventos y se puede iniciar a s´ ı misma si se producen tales acontecimientos. Nuestra aplicaci´ on cliente est´ a compuesta de tres actividades: la actividad principal, la actividad de digitalizaci´ on de la voz y la actividad de comunicaci´ on con el servidor. En la Figura 3.3 se puede ver el grafo de funcionamiento de esta aplicaci´ on. Al iniciarse, el usuario se encuentra con la actividad principal, desde la que se pasa a la actividad de digitalizaci´ on de la voz. Una vez terminada la digitalizaci´ on se activa la actividad de comunicaci´ on con el servidor. Desde la actividad de comunicaci´ on se env´ ıa el fichero de audio al servidor y se recibe la respuesta de iATROS que se muestra al usuario. Terminado el proceso, la aplicaci´ on vuelve a la actividad principal a la espera de una nueva consulta por parte del usuario. Principal Digitalización Comunicación Figura 3.3: Funcionamiento de la aplicaci´ on cliente. A continuaci´ on, veremos en detalle cada una de estas tres actividades. 3.3.1. Actividad 1: Principal Cuando el usuario inicia la aplicaci´ on en su dispositivo m´ ovil con Android, se encuentra con la pantalla de inicio mostrada en la Figura 3.4(a). En esta pantalla el usuario encuentra un bot´ on verde con un micr´ ofono en su interior, un bot´ on gris con un altavoz y los textos “Preparado” y“Pulse para comenzar a reconocer”. El usuario debe pulsar el bot´ on verde con el micr´ ofono justo antes de empezar a decir lo que desea traducir. En la parte baja se encuentran dos cuadros de texto: en el primero se mostrar´ a el texto reconocido por el servidor y en el segundo su traducci´ on. Al ser pulsados, su contenido ser´ a le´ ıdo en castellano e ingl´ es, respectivamente, mediante el sintetizador de voz de Google. El bot´ on gris con el altavoz permite al usuario escuchar el audio capturado por el dispositivo. En esta pantalla inicial el usuario tiene a su disposici´ on la configuraci´ on de la aplicaci´ on en el bot´ on “Configuraci´on” y la informaci´ on b´ asica de este proyecto en el bot´ on “Acerca de ...” a los que se accede al pulsar la tecla “Men ´u”, tal y como se puede ver en la Figura 3.4(b). Al pulsar sobre el bot´ on “Acerca de ...” se muestra una breve descripci´ on del proyecto (Figura 3.4(c)), el nombre del autor, de los directores y el lugar y a ˜ no de realizaci´ on. Al pulsar sobre el bot´ on “Configuraci´on”, se entra en el men ´ u de configuraci´ on que contiene las opciones que los usuarios pueden modificar (Figura 3.4(d)). ´ Estas son los dos par´ ametros que hacen referencia a la comunicaci´ on con el servidor por sockets (la direcci´ on y el puerto del socket del servidor) y la posibilidad de desactivar la sintetizaci´ on de voz. 22 Emilio Granell Romero Cap´ıtulo 3. Hermes La direcci´ on del servidor (Figura 3.4(e)) se puede introducir como una direcci´ on IP (como podr´ ıa ser “192.168.43.207”) o como una direcci´ on HTTP (como podr´ ıa ser “http://iatros.upv.com”). El puerto TCP utilizado para escuchar en el servidor (Figura 3.4(f)) debe ser un n´ umero comprendido entre 1024 y 49151 (como podr´ ıa ser “35557”), que son los n´ umeros de puerto libres para el uso en nuestras aplicaciones. (a) Pantalla inicial. (b) Men´u de la aplicaci´on. (c) Acerca de ... (d) Men ´u de configuraci´on. (e) Direcci´on IP del servidor iATROS. (f) Puerto de escucha del servidor iATROS. Figura 3.4: Actividad principal. En cuanto el usuario pulse el bot´ on verde con el micr´ ofono, la aplicaci´ on pasar´ a a la siguiente actividad: la digitalizaci´ on de la voz. Emilio Granell Romero 23 Desarrollo de un sistema de reconocimiento del habla en Android 3.3.2. Actividad 2: Digitalizaci ´on de la voz Para poder analizar la voz en el servidor, como se describe en el est´ andar ETSI ES 201 108 [4], en esta actividad se digitaliza el sonido que llega al micr´ ofono del dispositivo m´ ovil con una frecuencia de muestreo de 16KHz, y se almacena en un fichero de audio sin compresi´ on. Figura 3.5: Actividad de digitalizaci´ on de la voz. Mientras se est´ a digitalizando la voz, el usuario se encuentra con la pantalla de la Figura 3.5 en la que el bot´ on verde al ser pulsado se ha vuelto rojo y el texto le recuerda que debe “Hablar ahora” y que debe “Pulsar cuando termine de hablar”. En cuanto el usuario termine de hablar y pulse el bot´ on rojo la aplicaci´ on pasar´ a a la siguiente actividad: la comunicaci´ on con el servidor. 3.3.3. Actividad 3: Comunicaci´on con el servidor En esta actividad se establece la comunicaci´ on mediante sockets con el servidor. Al servidor se le env´ ıa el fichero de sonido obtenido en la actividad anterior y, mientras iATROS est´ a realizando el reconocimiento en el servidor, la aplicaci´ on cliente espera a recibir la respuesta, que se muestra al usuario en cuanto se recibe. Mientras el dispositivo m´ ovil trata de establecer la comunicaci´ on mediante sockets con el servidor, aparece una animaci´ on con el texto “Conectando con el servidor iATROS. Por favor espere ...”, como se puede ver en la Figura 3.6. Una vez establecida la comunicaci´ on mediante sockets con el servidor se procede a enviar el fichero de sonido. Durante el env´ ıo se muestra una barra de progreso con el texto “Enviando el fichero de sonido al servidor iATROS. Por favor espere ...”, como se aprecia en la Figura 3.6(b), a fin de mantener informado al usuario sobre el progreso del env´ ıo del fichero. Mientras el servidor iATROS realiza el reconocimiento del fichero de sonido enviado, el dispositivo m´ ovil espera a que el servidor termine con el reconocimiento y le env´ ıe la respuesta. Durante este periodo de tiempo en el dispositivo m´ ovil se muestra una animaci´ on con el texto “Procesando en el servidor iATROS. Por favor espere ...”, como se puede ver en la Figura 3.6(c). Una vez recibida la respuesta del servidor iATROS, ´ esta se muestra al usuario. En el primer 24 Emilio Granell Romero Cap´ıtulo 3. Hermes cuadro de texto se presenta la transcripci´ on de la frase dicha por el usuario y en el cuadro de texto inferior su traducci´ on al ingl´ es, como se puede ver en la Figura 3.6(d). Al mismo tiempo, se reproduce la traducci´ on utilizando el sintetizador de voz de Google en ingl´ es. La Figura 3.6(d) muestra un ejemplo de funcionamiento del sistema. En el caso de que un usuario diga la frase “Quiero una habitaci´on tranquila con vistas al mar.”, el servidor iATROS dar´ ıa como respuesta la transcripci´ on de la frase dicha y su traducci´ on al ingl´ es: “I want a quiet room with a view of the sea.”. (a) Estableciendo la comunicaci´on con el servidor iATROS. (b) Env´ıo del fichero de sonido al servidor iATROS. (c) Procesando en el servidor iATROS. (d) Muestra de la respuesta al usuario. Figura 3.6: Actividad de comunicaci´ on con el servidor. A continuaci´ on, la aplicaci´ on vuelve de la actividad de comunicaci´ on con el servidor a la actividad principal, manteniendo en los cuadros de texto la respuesta del servidor. De este modo, el usuario puede seguir leyendo la respuesta, e incluso si pulsa sobre los textos, puede volver a escucharlos hasta que esta respuesta sea sobreescrita por una nueva consulta del usuario, tal y como recuerdan los textos: “Preparado” y“Pulse para comenzar a reconocer o pulse sobre el texto Emilio Granell Romero 25 Desarrollo de un sistema de reconocimiento del habla en Android para volver a escuchar”. 3.4. Servidor La funci´ on del servidor es mantenerse a la espera de las peticiones de los clientes y dar una respuesta en cuanto recibe una petici´ on. Las peticiones de los clientes llegan en forma de un fichero con la voz del usuario digitalizada y la respuesta que esperan los clientes es el resultado del procesado de este fichero con iATROS. El resultado esperado es la transcripci´ on y la traducci´ on al ingl´ es de la frase dicha por el usuario. Como servidor hemos utilizado una m´ aquina virtual creada con el software de virtualizaci´ on Virtual Box [17]. A este servidor virtual le hemos instalado el sistema operativo Debian [2] (una distribuci´ on basada en GNU/Linux), y el software de reconocimiento del habla iATROS [19]. En el Ap´ endice A se muestra el proceso de creaci´ on y configuraci´ on del servidor virtual, y en el Ap´ endice B se muestra el proceso de instalaci´ on de iATROS en dicho servidor. Una vez creado y configurado el servidor virtual, se desarroll´ o una aplicaci´ on en Java encargada de establecer la comunicaci´ on mediante sockets con la aplicaci´ on cliente de los dispositivos m´ oviles con Android y de ejecutar el RAH. Para ejecutar esta aplicaci´ on en el servidor utilizamos la siguiente orden: $ java -jar Servidor.jar Escuchar puerto RAH Recibir fichero Enviar respuesta Figura 3.7: Funcionamiento de la aplicaci´ on servidor. En la Figura 3.7 se muestra el grafo de funcionamiento de esta aplicaci´ on. Como se puede observar, est´ a compuesta por cuatro fases: la fase de escucha del puerto del socket a la espera de que llegue una petici´ on de un cliente, la fase de recepci´ on del fichero de sonido, la fase de RAH y la fase de env´ ıo de la respuesta del reconocimiento al cliente. A continuaci´ on veremos con detalle cada una de estas cuatro fases. 3.4.1. Fase 1: Escuchar puerto Cuando se ejecuta la aplicaci´ on el servidor se encuentra en la fase de escucha. En esta fase el servidor est´ a a la escucha del puerto del socket TCP (por ejemplo, el puerto TCP n ´ umero: 35557) a la espera de peticiones de los clientes. En el servidor se puede ver el siguiente mensaje que informa de que est´ a listo para atender peticiones: Servidor iATROS preparado. Esperando nuevo cliente. 26 Emilio Granell Romero Cap´ıtulo 3. Hermes Cuando se recibe una petici´ on de un nuevo cliente, la aplicaci´ on establece la comunicaci´ on y muestra por pantalla la confirmaci´ on: Nuevo cliente aceptado. A continuaci´ on, la aplicaci´ on del servidor pasa a la fase de recepci´ on del fichero de sonido. 3.4.2. Fase 2: Recibir fichero En esta fase la aplicaci´ on servidor acepta recibir el fichero de sonido, mostrando por la pantalla el nombre del fichero que est´ a recibiendo, as´ ı como el identificador del dispositivo con Android que se lo est´ a enviando: Recibiendo el fichero sound.raw, desde el dispositivo: 9774d56d682e549c Una vez completada la recepci´ on del fichero, se muestra el siguiente mensaje de confirmaci´ on por la pantalla: Fichero completo! Con el fichero de sonido completo, la aplicaci´ on servidor ya puede pasar a la fase de RAH. 3.4.3. Fase 3: Reconocimiento Autom´atico del Habla En esta fase, la aplicaci´ on servidor realiza el an´ alisis de la voz y posteriormente el reconocimiento mediante iATROS del fichero de audio recibido. Para realizar el an´ alisis de la voz del fichero recibido, la aplicaci´ on ejecuta iatros-speechcepstral, como se puede ver en la siguiente orden: iatros-speech-cepstral -c conf.feat -i sound.raw -o sound.cc Donde: sound.raw es el fichero de entrada (con el audio obtenido con el dispositivo m´ ovil), sound.cc es el fichero de salida (con los cepstrales que representan la voz del fichero de entrada) y conf.feat es el fichero de configuraci´ on (en el que se definen los valores de todas las variables del an´ alisis de la voz definido en el est´ andar ETSI 201 108). El contenido del fichero de configuraci´ on conf.feat1se muestra a continuaci´ on: # Configuration file for iATROS system # Generated by iATROS Configurator # Thu Oct 21 12:32:11 2011 <filter> TriangularFilters 23 </filter> <parameters> FrameSize 410 1El significado de cada uno de los par´ametros de configuraci´on se puede consultar en la ayuda de iATROS. Emilio Granell Romero 27 Desarrollo de un sistema de reconocimiento del habla en Android SampleFreq 16000 SubSampleFreq 100 FFTlength 512 FrameShift 160 WindowLen 0.025625 Factor 0.97 WindowAlfa 0.54 CepCoefNumb 13 Channels 1 Bits 16 Frames 32 SecondsSilence 0.5 SilenceThreshold 50 Derivative 2 </parameters> <buffers> SizeSignal 100000 SizeCC 1000 </buffers> <device> InputDevice default OutputDevice default </device> Una vez se ha obtenido el fichero de cepstrales se realiza el RAH con la versi´ on offline de iATROS : iatros-offline -c eutrans.cnf Este proyecto est´ a basado en EuTrans, concretamente en la tarea del turista, por lo que no ha sido necesario realizar un entrenamiento de los modelos utilizados por el reconocedor. En el fichero de configuraci´ on de EuTrans (eutrans.cnf) se definen los modelos sint´ actico, l´ exico y ac ´ ustico utilizados y todos los par´ ametros del reconocedor. A continuaci´ on se muestra el contenido del fichero eutrans.cnf 2: samples = sound.cc [decoder] hmm = models/HMM-Albayzin-128-CC lexicon = models/expc.lx lexicon-type = ATROS grammar = models/exp.tr grammar-type = FSM start = <s> end = </s> histogram-pruning = 10000 do-acoustic-early-pruning = true language-separator = | beam = 400 grammar-scale-factor = 10 word-insertion-penalty = 0 2El significado de cada uno de los par´ametros de configuraci´on se puede consultar en la ayuda de iATROS. 28 Emilio Granell Romero Cap´ıtulo 3. Hermes Cuando iATROS encuentra la frase que corresponde con mayor probabilidad a la dicha por el usuario, la aplicaci´ on toma la respuesta de iATROS y pasa a la ´ ultima fase: el env´ ıo de esta respuesta a la aplicaci´ on cliente. 3.4.4. Fase 4: Enviar respuesta En esta ´ ultima fase la respuesta obtenida de iATROS se env´ ıa mediante el socket a la aplicaci´ on cliente, que durante todo este tiempo ha permanecido a la espera. Esta respuesta, incluye la transcripci´ on en castellano y su traducci´ on al ingl´ es separadas por el s´ ımbolo |, como se puede ver en el siguiente ejemplo: Quiero una habitaci´ on tranquila con vistas al mar. |I want a quiet room with a view of the sea. Para finalizar, una vez enviada la respuesta al cliente, el servidor vuelve a la fase de escucha del puerto a la espera de nuevas peticiones de los clientes. Servidor iATROS preparado. Esperando nuevo cliente. Emilio Granell Romero 29 Desarrollo de un sistema de reconocimiento del habla en Android 30 Emilio Granell Romero CAP´ ITULO 4 COMPROBACI ´ ON DEL SISTEMA “El testing puede probar la presencia de errores pero no la ausencia de ellos.” Edsger Dijkstra (1930-2002), f´ısico e inform´atico holand´es. Para comprobar el funcionamiento del sistema de interpretaci´ on autom´ atica (Hermes), se realizaron pruebas instalando la aplicaci´ on cliente en distintos dispositivos m´ oviles (ver Tabla 4.1). La aplicaci´ on cliente funcion´ o perfectamente en todos los dispositivos excepto en el “Sony Ericsson Xperia X10 mini pro”, en el que a pesar de no dar ning ´ un tipo de error, la aplicaci´ on no pudo grabar el fichero de audio aunque dispon´ ıa de memoria suficiente. A parte de este caso aislado, se comprob´ o que para los dispositivos con pantallas peque ˜ nas el cuadro de texto inferior donde se muestra la traducci´ on sal´ ıa cortado. Esto demuestra que si se quisiera que este proyecto se pudiera utilizar de forma gen´ erica en cualquier dispositivo m´ ovil con Android habr´ ıa que realizar una nueva interfaz gr´ afica adaptada a estas pantallas. Marca y modelo Android CPU RAM Pantalla Samsung Galaxy Tab 7” 2.2 1 GHz 512 MB 600 x 1024 px en 7” HTC Wildfire 2.1 528 MHz 384 MB 240 x 320 px en 3.2” HTC Hero 2.1 528 MHz 288 MB 320 x 480 px en 3.2” Samsung Galaxy Ace 2.2 800 MHz 278 MB 320 x 480 px en 3.5” LG Optimus ME P350 2.2 600 MHz 256 MB 240 x 320 px en 2.8” Sansumg Galaxy S+ 2.3 1.4 GHz 512 MB 480 x 800 px 4” Sony Ericsson Xperia X10 mini pro 2.1 1 GHz 512 MB 320 x 480 px en 3” HTC Desire HD 2.3 1GHz 768 MB 480 x 800 px en 4,3” Tabla 4.1: Lista de dispositivos m´ oviles con los que se ha comprobado el sistema Adem´ as de comprobar el sistema utilizando distintos dispositivos m´ oviles, se comprob´ o con 20 personas, diez hombres y diez mujeres, con un rango de edades comprendido entre los 11 y los 63 a˜ nos con una gran variedad de ocupaciones (un cartero, una esteticista, un conductor de autob´ us, una psic´ ologa, una periodista y una escolar, entre otros). Los usuarios utilizaron el sistema locutando las frases incluidas en el corpus de prueba mostrado en el Ap´ endice C y realizaron la encuesta del Ap´ endice D. La transcripci´ on de sus respuestas se encuentra en el Ap´ endice E. El primer objetivo de esta encuesta es obtener la valoraci´ on del sistema por parte de los usuarios en cuatro puntos: su inter´ es por este tipo de sistemas, tiempo de espera de la respuesta, precisi´ on en la interpretaci´ on y la satisfacci´ on con el sistema. Para evaluar estos cuatro puntos se Emilio Granell Romero 31 Desarrollo de un sistema de reconocimiento del habla en Android [15] C. Manning and H. Sch¨ utze (1999). Foundations of statistical natural language processing. MIT Press. [16] P. Moreno, B. Raj, E. Gouvˆ ea, and R. Stern. Multivariate-Gaussian-based cepstral normalization for robust speech recognition. In Acoustics, Speech, and Signal Processing, 1995. ICASSP-95., 1995 International Conference on, volume 1, pp 137–140. IEEE, 1995. [17] Oracle. Virtual Box (2011). <https://www.virtualbox.org/> (Consultado: 1 de junio del 2011). [18] M. Pastor, A. Sanchis, F. Casacuberta, and E. Vidal. EuTrans: a Speech-to-Speech Translator Prototype. In Proceedings of EuroSpeech, pp 2385–2389, 2001. [19] PRHLT. iATROS (2011). <http://prhlt.iti.es/page/projects/multimodal/idoc/iatros> (Consultado: 10 de julio del 2011). [20] P. Suppes (1970). Probabilistic grammars for natural languages. Synthese, 22(1):95–116. [21] Wikipedia. Dispositivo m´ ovil — Wikipedia, La enciclopedia libre (2011). <http://es.wikipedia.org/w/index.php?title=Dispositivo_m%C3%B3vil&oldid=52769721> (Consultado: 20 de octubre del 2011). [22] M. Zechner. libGDX (2011). <http://libgdx.badlogicgames.com/> (Consultado: 20 de agosto del 2011). 38 Emilio Granell Romero AP´ ENDICE A CREACI ´ ON DE UN SERVIDOR VIRTUAL “A crash reduces your expensive computer to a simple stone.” Computer Haiku Poem from Internet Un servidor virtual es un software que emula a un servidor que puede ejecutar programas y ofrecer servicios como si fuese real. Esto permite tener en un mismo ordenador varios servidores con distintas configuraciones y diferentes sistemas operativos. En este proyecto, se opt´ o por utilizar la virtualizaci´ on para evitar hacer pruebas directamente en la m´ aquina f´ ısica. Se cre´ o un servidor virtual basado en Debian [2] mediante Virtual Box [17], siguiendo los siguientes pasos: 1. Descarga de Virtual Box y Debian. 2. Creaci´ on de la m´ aquina virtual. 3. Instalaci´ on de Debian en la m´ aquina virtual. 4. Instalaci´ on de ssh. 5. Reenv´ ıo de puertos en Virtual Box. A.1. Descarga de Virtual Box y Debian Desde la p´ agina web http://www.virtualbox.org/wiki/Downloads descargamos el software de virtualizaci´ on Virtual Box para nuestro sistema operativo. Virtual Box se encuentra disponible para Linux, Windows, Mac OS y Solaris. Desde la p´ agina web http://www.debian.org/releases/ descargamos la ´ ultima versi´ on de Debian. Desde esta p´ agina se tiene la opci´ on de descargar las im´ agenes ISO de CD o DVD de la ´ ultima versi´ on disponible en sus tres vertientes: estable, en pruebas e inestable para la arquitectura de nuestro sistema. Para este proyecto descargamos tan s´ olo la imagen ISO del primer CD de la versi´ on estable para la arquitectura x86. Emilio Granell Romero 39 Desarrollo de un sistema de reconocimiento del habla en Android A.2. Creaci ´ on de la m ´ aquina virtual Una vez descargada la ´ ultima versi´ on de Virtual Box, la instalamos en nuestro sistema anfitri´ on y la ejecutamos. En Virtual Box procedemos a crear una nueva m´ aquina virtual mediante el asistente que nos guiar´ a en cada paso: 1. Le asignamos el nombre Servidor iATROS a la m´ aquina virtual e indicamos que el sistema operativo que vamos a instalar es de tipo Linux y versi´ on Debian. 2. Le otorgamos 512 Mb de memoria RAM. 3. Le creamos un nuevo disco duro de arranque virtual de tipo expansi´on din´amica de 10 Gb. A.3. Instalaci´ on de Debian en la m´ aquina virtual Una vez creada la m´ aquina virtual, la seleccionamos y entramos en su configuraci´ on para montar una unidad de CD/DVD ROM a partir de la imagen ISO del CD de instalaci´ on de Debian que hemos descargado anteriormente. Al iniciar la m´ aquina virtual Servidor iATROS,´ esta arrancar´ a desde el CD de Debian que hemos montado, mostrando una pantalla con las distintas opciones de instalaci´ on. Seleccionamos la primera opci´ on install y procedemos a instalar el sistema siguiendo los siguientes pasos: 1. Seleccionamos el idioma, el pa´ ıs y el teclado deseados. 2. Le damos un nombre a la m´ aquina Servidor iATROS y un dominio virtual. 3. Elegimos el tipo de particionamiento del disco duro como guiado utilizando todo el disco y escribimos los cambios ejecutados en ´ el. 4. Introducimos la contrase˜ na de administrador. 5. Creamos un nuevo usuario, definiendo su nombre user y su contrase ˜ na password. 6. En la selecci´ on de programas, marcamos Servidor web ySistema est´andar dejando desmarcado Entorno de escritorio, ya que no instalaremos el entorno gr´ afico para emular fielmente un servidor real. 7. Instalamos GRUB. 8. Al finalizar la instalaci´ on, desmontamos la unidad (en el men ´ u Dispositivos, opci´ on Desmontar CD/DVD ROM) y pulsamos aceptar para reiniciar. 9. Al reiniciar actualizamos el sistema mediante apt-get. $ apt-get update && apt-get upgrade && apt-get dist-upgrade Una vez actualizado el servidor, si tecleamos uname -a obtendremos la informaci´ on del sistema. $ uname -a Linux debian 2.6.32-5-686 #1 SMP Tue Sep 13 22:14:59 UTC 2011 i686 GNU/Linux 40 Emilio Granell Romero Ap´endice A. Creaci´on de un servidor virtual A.4. Instalaci´ on de SSH Trabajaremos con el servidor a distancia mediante el protocolo SSH. Como el protocolo SSH no se instala por defecto, debemos instalarlo mediante la orden: $ apt-get install openssh-server Para comprobar que se ha instalado correctamente y que est´ a funcionando, intentamos conectarnos con la siguiente orden: $ ssh localhost Si nos permite la conexi´ on, es que todo funciona correctamente. A.5. Redireccionamiento de puertos en Virtual Box Por defecto, la configuraci´ on de red de Virtual Box viene definida como NAT, lo que significa que la m´ aquina virtual est´ a inaccesible desde el exterior mientras no se establezca una ruta desde un puerto local de la m´ aquina f´ ısica (anfitri´ on) a un puerto de la m´ aquina virtual (invitado). Sin embargo, nosotros queremos entrar en la m´ aquina virtual desde fuera, por un puerto asignado al socket utilizado para la comunicaci´ on con la aplicaci´ on cliente y por SSH para poder realizar tareas de administraci´ on. Para hacer esto, abriremos dos puertos en la m´ aquina f´ ısica: el 2222 para SSH y el 35557 para el socket. Los enrutaremos a los puertos 22 para ssh de la m´ aquina virtual y al 35557 para iATROS. Para realizar el redireccionamiento de los puertos, accedemos a la configuraci´ on de red de la m´ aquina virtual como se puede ver en la Figura A.1 y apretamos en el bot´ on Reenv´ıo de puertos. En la nueva pantalla, a˜ nadimos un reenv´ ıo del puerto TCP de la m´ aquina f´ ısica 2222 al 22 de la m´ aquina virtual para SSH, y otro del puerto TCP de la m´ aquina f´ ısica 35557 al 35557 de la m´ aquina virtual para iATROS, quedando como se puede ver en la Figura A.2 Una vez creado y configurado el servidor virtual cada vez que necesitemos realizar tareas de administraci´ on nos conectaremos al servidor virtual desde la m´ aquina f´ ısica mediante SSH, utilizando la orden: $ ssh -p 2222 user@localhost Emilio Granell Romero 41 Desarrollo de un sistema de reconocimiento del habla en Android Figura A.1: Configuraci´ on de red. Figura A.2: Reenv´ ıo de puertos. 42 Emilio Granell Romero AP´ ENDICE B INSTALACI ´ ON DE IATROS “La palabra es limitada y no puede nombrar lo innombrable.” La elocuencia del silencio. Cuento cl´asico de la India iATROS est´ a preparado para ser f´ acilmente compilado en un entorno est´ andar de Linux. El c´ odigo fuente de iATROS se proporciona con un archivo para ser f´ acilmente compilado utilizando la herramienta cmake. El c´ odigo de iATROS y sus m´ odulos deben ser descargados en el directorio ’local’, donde los programas y las librer´ ıas se instalar´ an. Las librer´ ıas y los archivos binarios pueden ser instalados en el sistema (se necesitar´ an privilegios de administrador para esto) creando el sistema iATROS en el directorio de sistema /usr. Para instalar iATROS en un sistema Debian se deben seguir los siguientes pasos: 1. Descarga del c´ odigo fuente. 2. Preparaci´ on del sistema para la compilaci´ on. 3. Configuraci´ on. 4. Compilaci´ on e instalaci´ on. 5. Actualizaci´ on de las variables de entorno. A continuaci´ on, veremos cada uno de estos pasos en detalle. B.1. Descarga del c ´ odigo fuente En la p´ agina web del grupo de investigaci´ on PRHLT se encuentra disponible el c´ odigo fuente de iATROS [19]. Procedemos a descargarlo mediante wget desde la carpeta de descargas /home/user/Descargas. $ wget http://prhlt.iti.es/projects/multimodal/idoc/iatros/files/iatros-v1.0.tgz Una vez descargado el fichero iatros-v1.0.tgz que contiene el c´ odigo fuente de iATROS, lo descomprimimos utilizando en descompresor tar. $ tar xzvf iatros-v1.0.tgz Emilio Granell Romero 43 Desarrollo de un sistema de reconocimiento del habla en Android Al ejecutar la orden anterior se crear´ a una nueva carpeta /home/user/Descargas/iatros-v1.0 que contendr´ a en su interior todo el c´ odigo fuente de iATROS. B.2. Preparaci ´ on del sistema para la compilaci´ on Para la compilaci´ on de iATROS son necesarias las herramientas, subversion, gcc, g++, make, cmake, flex y bison, por lo que si nuestro sistema no dispone de ellas, debemos instalarlas mediante apt-get. $ apt-get install subversion gcc g++ make cmake flex bison Los modulos htr yspeech requieren las librer´ ıas fftw3 yasound2 en sus versiones de desarrollo. $ apt-get install libfftw3-dev libasound2-dev B.3. Configuraci´ on Antes de compilar iATROS debemos configurar el entorno de compilaci´ on. Para ello debemos crear el directorio de instalaci´ on y desde ´ este ejecutar el script de configuraci´ on configure que preparar´ a la compilaci´ on de iATROS. $ mkdir /home/user/iatros-v1.0 $ cd /home/user/iatros-v1.0 $ ../Descargas/iatros-v1.0/configure B.4. Compilaci´ on e instalaci ´ on A continuaci´ on, se ejecuta la orden make para compilar iATROS, y make install para instalarlo en el sistema. $ make $ make install B.5. Actualizaci´ on de las variables de entorno Por ´ ultimo, como se ha instalado iATROS en un directorio no est´ andar, se deben actualizar las variables de entorno PATH yLD LIBRARY PATH, a˜ nadiendo las siguientes l´ ıneas al fichero .bashrc: export IATROS_PATH=/home/user/iatros-v1.0 export PATH=$PATH:$IATROS_PATH/bin export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$IATROS_PATH/lib 44 Emilio Granell Romero AP´ ENDICE C CONJUNTO DE PRUEBA “El lenguaje le da forma al mundo. La palabra es el primer ejercicio del poder.” Vicente Romano En este ap´ endice se muestra el conjunto de frases utilizadas para comprobar el funcionamiento y rendimiento del sistema de interpretaci´ on autom´ atica implementado. 1. Mi nombre es Pablo Alted. 2. Hice una reserva a nombre de Asunci´ on Bellver. 3. ¿Podr´ ıan explicarme la factura de la habitaci´ on cero quince? 4. Mi nombre es Fernando Cabo. 5. He reservado una habitaci´ on hasta ma˜ nana a nombre de la se ˜ nora Rosa Royo. 6. Tengo hecha una reserva a nombre de Jaime Su´ arez. 7. Por favor, ¿le importar´ ıa mostrarnos alguna habitaci´ on individual con tel´ efono? 8. Por favor, una habitaci´ on tranquila individual a nombre de Pablo Castillo. 9. Creo que se produjo un error en mi cuenta. 10. He hecho una reserva a nombre de Elvira Garc´ ıa. 11. En la habitaci´ on hace mucho calor. 12. ¿Est´ an incluidos en la cuenta los gastos?. 13. Tengo reservada una habitaci´ on doble a nombre de Manuel Ortega. 14. Tengo reservada una habitaci´ on a nombre del se˜ nor Paches. 15. Me llamo Inmaculada Arroyo. 16. Por favor, tengo la reserva de una habitaci´ on a nombre del se˜ nor Arenas. 17. Tengo hecha una reserva a nombre de Rafael V´ azquez. 18. ¿Me llama a un taxi para la habitaci´ on doscientos doce? 19. Mi nombre es Ricardo Bacete. Emilio Granell Romero 45 Desarrollo de un sistema de reconocimiento del habla en Android 20. Hice la reserva de una habitaci´ on doble a nombre de Susana Velasco. 21. Por favor, tengo hecha una reserva a nombre de Amelia Ferrando. 22. Por favor, quiero que me bajen los bultos a mi habitaci´ on. 23. Por favor, ¿le importar´ ıa mostrarme alguna habitaci´ on doble y tranquila? 24. Hemos reservado una habitaci´ on a nombre de la se ˜ nora Silvia Mingot. 25. He reservado una habitaci´ on a nombre de la se˜ nora Amparo Cabedo. 26. Me llamo Gloria Serrano. 27. Por favor, tengo una reserva a nombre de Silvia Nadal. 28. Tengo una reserva a nombre de Rosal´ ıa Nebot. 29. Tengo hecha una reserva a nombre de Gerardo Quereda. 30. ¿Podr´ ıa cambiarme a otra habitaci´ on m´ as tranquila? 31. Ll´ amenos a un taxi para la habitaci´ on doscientos veintitr´ es. 32. Son demasiado caras. 33. Por favor, deseo una habitaci´ on tranquila individual a nombre de Daniel Salsas. 34. Por favor, ¿nos repasa la cuenta de la habitaci´ on doce? 35. Por favor, he reservado una habitaci´ on a nombre de Carmelo Lobo. 36. Por favor, una habitaci´ on tranquila doble a nombre del se ˜ nor Monsonis. 37. ¿Est´ an anotados en la cuenta todos los gastos? 38. Hice una reserva a nombre de Miguel Ib´ a˜ nez. 39. Una habitaci´ on tranquila que tenga buena vista, televisi´ on y tel´ efono. 40. Tengo reservadas dos habitaciones con tel´ efono y televisi´ on. 41. ¿Qu´ e precio tiene una habitaci´ on individual para diez semanas? 42. Reserv´ e una habitaci´ on individual para un d´ ıa a nombre de Jacinto Ortega. 43. Tengo una reserva a nombre de Marta Orenga. 44. Por favor, hice una reserva a nombre de Silvia Arnau. 45. ¿Puedo pagar con cheques? 46 Emilio Granell Romero AP´ ENDICE D ENCUESTA DE SATISFACCI ´ ON “Those are my principles, and if you don’t like them... well, I have others.” Groucho Marx En este ap´ endice se muestra la encuesta realizada a los usuarios que probaron el sistema, para conocer su grado de satisfacci´ on y obtener una evaluaci´ on. 1. Informaci´ on personal. a) Marca y modelo del dispositivo m´ ovil: b) Versi´ on de Android: c) Sexo (Hombre/Mujer): d) Edad: e) Ocupaci´ on: 2. Inter´ es por los sistemas de interpretaci´ on autom´ atica (En una escala del 1 al 5, donde 5 es “muy interesante” y 1 es “nada interesante”). ¿C´ omo de interesante es un sistema de interpretaci´ on autom´ atica para usted? 3. Tiempo de espera (En una escala del 1 al 5, donde 5 es “muy r´apido” y 1 es “muy lento”). ¿C´ omo le ha parecido el tiempo de espera de la respuesta? 4. Precisi´ on (En una escala del 1 al 5, donde 5 es “muy preciso” y 1 es “nada preciso”). ¿C´ omo de preciso le ha parecido el sistema? 5. Valoraci´ on global (En una escala del 1 al 5, donde 5 es “muy satisfecho” y 1 es “nada satisfecho”). ¿Cu´ al es su grado de satisfacci´ on con el uso de Hermes? 6. Caracter´ ısticas. a) ¿Qu´ e caracter´ ısticas del producto le han gustado? Facilidad de uso, est´ a de moda, otros (por favor, especifique): b) ¿Qu´ e caracter´ ısticas considera que deben mejorarse? 7. Valoraci´ on econ´ omica. a) ¿Pagar´ ıa por este servicio de interpretaci´ on autom´ atica? b) ¿Cu´ al considera que ser´ ıa el precio justo? Emilio Granell Romero 47