Diseño e implementación de un asistente personal capaz de...

UNIVERSIDAD POLITÉCNICA DE MADRID

ESCUELA TÉCNICA SUPERIOR DE INGENIEROS

DE TELECOMUNICACIÓN

DEPARTAMENTO DE INGENIERÍA ELECTRÓNICA

PROYECTO FIN DE CARRERA

Diseño e implementación de un asistente personal capaz de expresar emociones

CARLOS SANZ MORENO

Madrid, 2009

TÍTULO: Diseño e implementación de un asistente personal

capaz de expresar emociones.

AUTOR: Carlos Sanz Moreno.

TUTOR: D. Juan Manuel Montero Martínez.

DEPARTAMENTO: Ingeniería Electrónica.

TRIBUNAL:

Presidente: D. Javier Ferreiros López.

Vocal: D. Juan Manuel Montero Martínez.

Secretario: D. Fernando Fernández Martínez.

Vocal Suplente: D. Rubén San Segundo Hernández.

Fecha de Lectura: Madrid, de de 2009

CALIFICACIÓN:

UNIVERSIDAD POLITÉCNICA DE MADRID

DEPARTAMENTO DE INGENIERÍA ELECTRÓNICA

ESCUELA TÉCNICA SUPERIOR DE INGENIEROS

DE TELECOMUNICACIÓN

PROYECTO FIN DE CARRERA


- Proyecto becado por la Cátedra Indra-Adecco-UPM -

CARLOS SANZ MORENO

Ingeniero de Telecomunicación

Tutor del Proyecto

JUAN MANUEL MONTERO MARTÍNEZ

Doctor Ingeniero de Telecomunicación

Septiembre, 2009

RESUMEN

El presente proyecto versa sobre el diseño e implementación de un asistente personal

capaz de expresar emociones que posibilite una relación entre las personas y las máquinas

sencilla e intuitiva. La motivación principal de este proyecto ha sido la, cada vez más frecuente,

complejidad tecnológica de los hogares sumada a los avances en todo tipo de interfaces.

Se ha creado un sistema con diferentes características: una interfaz multimodal capaz de

procesar información heterogénea que permita eliminar las barreras de comunicación con las

máquinas, es decir, se ha incluido reconocimiento y síntesis de voz, tratamiento de imágenes y

sensores físicos; un conjunto de aplicaciones domóticas destinadas al contexto de un hogar que

permita mostrar a los usuarios la utilidad de los sistemas electrónicos en la vida cotidiana

(control de luces, control de aspiradora, control de equipo de música…); por último, se ha creado

un modelo de emotividad que permita que la relación entre las personas y las máquinas diste de

un simple conjunto de órdenes.

Ajustándose a estas características, el presente proyecto ha profundizado en el diseño de

una arquitectura que permitiese dar soporte a las funcionalidades descritas para, una vez

incluidas, centrarse en el diseño del módulo de emotividad. En concreto se ha creado un modelo

de usuarios que sea capaz de analizar la relación entre el usuario y el sistema para poder ajustar

el comportamiento de éste en función de ella. Finalmente, también se ha desarrollado un

sistema emocional escalable que simplifique la generación de emociones separándola de las

características particulares de cada tarea.

Palabras Clave: ambiente inteligente, interfaz multimodal, asistente personal,

appraisal theory, Maslow, domótica, sistema emocional.

A mis padres, por vuestra gran dedicación

A mis hermanos, por vuestro maravilloso ejemplo

A Ainhoa, por tu cariño incondicional

Es de bien nacidos ser agradecidos…

En estas líneas quería realizar un paréntesis y recordar, brevemente, a todos aquellos que han contribuido, de una u otra forma, a conseguir que este proyecto saliese adelante.

Mis agradecimientos al grupo de Control Inteligente, especialmente a Diego por su espléndida labor en el sistema de comunicaciones. A los alumnos Jorge, Daniel, Enrique, Juan Carlos, José Manuel y Jorge sin los cuales no se podría haber realizado este sistema. También a Alexander Zlotnik por su maravillosa infraestructura. Al personal del Departamento de Ingeniería Electrónica, en especial a Luis García, Julián Sánchez Osorio y Oscar García González por su gran trabajo con la cara robótica.

Por supuesto agradecer al todo Grupo de Tecnología del Haba su apoyo con cuantos problemas he tenido. En especial a Javier Ferreiros, Juan Manuel Lucas, Fernando Fernández

Agradecer a la cátedra INDRA-ADECCO su apoyo en este proyecto, en especial a su director, José Manuel Menéndez, y a Carlos A. Martín.

No obstante, querría seguir con la tradición de nuestro querido Almodóvar dando las gracias a José Miguel y Víctor, por su compañía y por estar siempre disponibles para echarme una mano o para tener una conversación en una tarde de esas “donde se ganan las ligas”. A Syaheerah por su paciencia, por la cantidad de horas que hemos pasado intentando comunicarnos y por su ayuda a la hora de enfocar este proyecto. A Rober por ser la “mano anónima” que activaba el sintetizador cada vez que había uno de los muchos apagones.

También quería agradecer especialmente a Juancho todo su trabajo, todos los días dedicados a este proyecto sin escatimar esfuerzos, por pedirme mucho pero por darme más. Por estar siempre disponible para enseñarme cualquier cosa. Por demostrarme lo fácil que es hacer las cosas si tienes claro lo que quieres y, por supuesto, por hacerme una estrella mediática de youtube.

No escapan de mi cabeza todos aquellos que han contribuido a que esta aventura haya concluido. Vienen a mi recuerdo muchos nombres, Fer, Huanluih, Alberto, Ana, Noemí, Isabel… mucha gente para nombrar. Por supuesto no me puedo olvidar de mi gran compañero y amigo MA, con quién siempre es agradable tomar un café y echar un vistazo atrás. 6 años dan para tanto…

Por supuesto soy incapaz de olvidar a aquellos con los que he pasado tan buenos momentos. Laura y Agus que siempre han servido como ejemplo de amistad y de buen rollo. A Carlos porque eres un ejemplo de persona excepcional, porque nunca tienes una mala cara y porque siempre estás dispuesto a echar una mano. A Cris, mi “pescaíto”, por tantos y tantos buenos ratos, por compartir conmigo las esperas del autobús y porque sé que me quieres aunque tu orgullo no te permita reconocerlo (¡Deja de mirarme el culo!) ;). A Ele y Jose por todos los ratos

que hemos pasado juntos, porque siempre estáis dispuestos a dar una vuelta y, sobretodo, a Elena por demostrarme cómo se puede ser fan de un McDonald´s jeje.

Sin embargo sería imposible terminar aquí estos agradecimientos. Necesito dedicar unas líneas a todos aquellos que estaban mucho antes de que toda esta aventura empezase y que seguro estarán mucho tiempo después. Mi familia.

Empezaré con los más recientes: Gracias Laura porque siempre estás dispuesta para un rato de conversación, cosa que ha hecho tus visitas muy importantes para poder seguir cuerdo tras tantas horas en el cuarto trabajando. Tampoco me olvido de Ramón, que siempre has aguantado estoicamente los “coñazos” que te meto: que si mira mi proyecto, que si te digo la presentación, que si vamos a tocar tal o vamos a cual. Gracias por ser tan paciente y tan buena gente, y ya sabes, cuida de mi hermanita ;).

Además me gustaría recordar a mis tíos y primos, Cande, Santi Raúl y Álvaro, por ser más que mis primos mis hermanos, porque cada vez que estoy con vosotros noto el calor de estar con personas que te quieren, y eso no es fácil de encontrar.

Cómo no recordad a mi otro hermano, Pablo. Dice el dicho que quien tiene un amigo tiene un tesoro y eso es precisamente lo que he descubierto contigo, aún recuerdo cuando estábamos bajo el frío de Diciembre iluminados por la tenue luz de una farola enfrente de tu calle totalmente vacía, con las tuberías de plástico que habíamos sacado de no sé dónde, ¿quizás de alguna expedición al bosque?, intentando matar “apachis”. De aquello hace ya algún tiempo, pero creo que nuestra amistad no ha sufrido ningún cambio. Gracias.

También quería tener un breve recuerdo para “la Mari” porque me has acogido y me has tratado con el cariño de una madre y porque aún te debo una visita a las casas colgadas de Cuenca.

A Ainhoa por ser un apoyo constante, por estar siempre disponible para calmarme y orientarme, por no mandarme muy muy lejos cuando me pongo obcecado, por hacerme sentir tan feliz contigo y porque nunca a un ser extraño le llamé mi familia.

No puedo continuar sin hacer un paréntesis y recordar a aquellos que ya no están conmigo… Aunque nunca lo confesé, tenía tantas ganas de que pudierais verme acabar…

Quisiera recordar a mi hermano Alberto que, aunque eres un poco rarito, siempre he notado tu protección como hermano pequeño que soy (faltaría más :P) y porque has sido en muchas ocasiones uno de mis mejores amigos, los veranos en La Beltraneja con Carlos, Alberto y Julio jugando al fútbol o haciendo marchas en bici los guardo con mucho cariño.

A mi hermana Raquel por todo el tiempo que has dedicado a enseñarme, me enseñaste a caminar, me ayudaste cuando estaba atascado en el colegio, aunque ahí Alberto también contribuía. Me enseñaste a patinar, a montar en bici cuando te seguíamos como patitos. Gracias porque a pesar de sacarme 7 años nunca has tenido ningún problema en que fuese contigo, gracias por ser el espejo en el que tanto Alberto como yo nos hemos mirado durante todos estos años, ya que sin tu ejemplo dudo mucho que estuviese aquí hoy y gracias, porque, aunque la vida avanza, nunca nos has echado de la tuya.

Finalmente, a mis padres, es increíble el pensar como una persona puede mostrar tanta entrega, tanto cariño, tanto sacrificio sin esperar nada a cambio. Cómo son capaces de ser un ejemplo durante todo el día. Cómo nunca están cansados y siempre son capaces de dar un poco más. Gracias papá por el sacrificio que has hecho ¿durante, cuántos años ya, 7? Yendo

diariamente a Toledo sin mostrar ni una pizca de cansancio en casa, por ser un ejemplo de superación y de profesionalidad y sobre todo porque gracias a tu valía seguimos aquí hoy. Gracias mamá por demostrarme cómo es en la sinceridad y la honestidad en donde reside realmente la grandeza de las personas, gracias por tu comportamiento siempre ejemplar, porque siempre te has sacrificado por los demás, porque si alguien tiene que estar incómodo para que los demás sean felices eres la primera en hacerlo.

Por tantas y tantas cosas…. GRACIAS A TODOS.

GLOSARIO

- Adaboost: Adaptative Boosting.

- API: Aplication Programming Interface.

- BIC: Bayesian Information Criterion.

- Bluetooth: Estándar para interconexión inalámbrica de dispositivos.

- CPU: Central Processing Unit.

- DIE: Departamento de Ingeniería Electrónica.

- DISAM: División de Ingeniería de Sistemas y Automática.

- DVD: Digital Versatile Disc.

- FHSS: Frequency Hopping Spread Spectrum.

- GTH: Grupo de Tecnología del Habla.

- Hi-Fi: High Fidelity.

- HMM: Hidden Markov Models.

- HTTP: HyperText Transfer Protocol.

- IA: Inteligencia Artificial.

- IP: Internet Protocol.

- iRTrans: Módulo transmisor de infrarrojos.

- ISM: Industrial, Scientific and Medical.

- KNN: K Nearest Neighbors.

- MIT: Massachusetts Institute of Technology.

- NIF: Need Independent Feature.

- NLP: Natural Language Processing.

- n-value: Valor del nivel de necesidad de Maslow.

- OpenCV: Librería de procesado de imágenes.

- PC: Personal Computer.

- RFID: Radio Frequency Identification.

- RNA: Redes Neuronales Artificiales.

- Roomba: Robot aspiradora.

- SERVIVOX: Conjunto de aplicaciones para gestión de diálogo.

- SOAP: Simple Object Acces Protocol.

- SPP: Serial Port Profile.

- TCP: Transmission Control Protocol.

- TDT: Televisión Digital Terrestre.

- TIF: Task Independent Feature.

- TTS: Text To Speech.

- UC: University of Colorado.

- WA: Word Accuracy.

- Wifi: Wireless Fidelity.

- X10: Protocolo de comunicación para aplicaciones domóticas.

I

ÍNDICE DE CONTENIDOS

1 INTRODUCCIÓN - 1 -

1.1. Objetivo de este proyecto - 3 -

1.2. Estructura de la memoria - 3 -

1.3. Fases de Trabajo - 4 -

2 DESCRIPCIÓN GENERAL DEL SISTEMA - 7 -

2.1. Definición de requisitos - 8 -

2.2. Arquitectura general del sistema - 8 -

2.3. Modelo de Comportamiento - 10 - 2.3.1. Estado del arte: Módulo de comportamiento. - 10 -

2.3.1.1. GALAXY-II - 11 - 2.3.1.2. CU Communicator - 12 -

2.3.2. Módulo de comportamiento implementado - 12 - 2.3.2.1. Mensajes procedentes de la interfaz de entrada - 13 - 2.3.2.2. Mensajes destinados a la interfaz de salida - 15 - 2.3.2.3. Mensajes del modelo emocional - 16 - 2.3.2.4. Secuencia del módulo de comportamiento - 17 -

3 SUBSISTEMA DE COMUNICACIONES - 19 -

3.1. Estado del arte: Arquitecturas de comunicaciones. - 19 -

3.2. Arquitectura Cliente/Servidor - 22 - 3.2.1. Descripción - 22 - 3.2.2. Componentes - 22 - 3.2.3. Características - 23 - 3.2.4. Ventajas e inconvenientes - 24 - 3.2.5. Estructura implementada. - 25 -

3.3. Mecanismo de comunicación: SOAP - 27 - 3.3.1. Sockets - 27 - 3.3.2. RPC - 28 -

3.3.2.1. XML-RPC - 29 - 3.3.2.2. SOAP - 30 -

3.4. Estructura física implementada - 32 -

4 INTERFAZ PERSONA-MÁQUINA - 35 -

4.1. Interfaz Verbal - 39 - 4.1.1. Estado del arte - 41 -

4.1.1.1. Reconocimiento de voz - 41 - 4.1.1.1.1. Métodos de reconocimiento - 43 -

4.1.1.1.1.1. Reconocimiento de patrones - 44 - 4.1.1.1.2. Variabilidad de la señal de voz - 46 - 4.1.1.1.3. Prestaciones - 48 -

4.1.1.2. Identificación de usuario - 49 - 4.1.1.3. Síntesis de voz - 53 -

II

4.1.1.3.1. Arquitectura general de un sintetizador de habla - 54 - 4.1.1.3.1.1. Procesamiento de Lenguaje Natural (NLP) - 55 - 4.1.1.3.1.2. Proceso de Síntesis - 55 -

4.1.1.3.2. Creación del Corpus - 58 - 4.1.1.3.3. Elección de unidades que concatenar - 58 - 4.1.1.3.4. Marcado de las unidades - 59 - 4.1.1.3.5. Síntesis por Selección de unidades: - 59 - 4.1.1.3.6. Síntesis por HMM. - 61 - 4.1.1.3.7. Comparación de los métodos de síntesis - 62 -

4.1.2. Reconocimiento de voz e Identificación de Usuario (SERVIVOX) - 63 - 4.1.2.1. Adaptación del SERVIVOX - 64 - 4.1.2.2. Proceso de reconocimiento de una nueva frase - 64 - 4.1.2.3. Pruebas de identificación - 66 -

4.1.2.3.1. Modo 1 - 68 - 4.1.2.3.2. Modo 2 - 71 -

4.1.3. Síntesis de voz con emociones - 73 -

4.2. Interfaz Visual - 75 - 4.2.1. Estado del arte: Reconocimiento de objetos - 76 -

4.2.1.1. Métodos basados en características - 77 - 4.2.1.1.1. Color - 77 - 4.2.1.1.2. Múltiples características - 77 - 4.2.1.1.3. Esqueletización - 77 -

4.2.1.2. Métodos basados en modelos - 78 - 4.2.1.2.1. Redes neuronales - 79 - 4.2.1.2.2. K vecinos más cercanos - 80 - 4.2.1.2.3. Adaboost - 81 -

4.2.2. Tratamiento de Imágenes (Opencv) - 82 - 4.2.2.1. Detección de luz - 83 - 4.2.2.2. Detección de movimientos - 84 - 4.2.2.3. Detección de caras - 84 -

4.3. Interfaz Física - 85 - 4.3.1. Brazo Robótico - 86 - 4.3.2. Cara Robótica - 86 - 4.3.3. Detector de Caricias - 89 -

5 APLICACIÓN - 93 -

5.1. Estructura Genérica de una Tarea - 94 -

5.2. Control de Roomba - 95 - 5.2.1. Características de Roomba - 96 - 5.2.2. Tecnología Bluetooth - 96 - 5.2.3. Tarea Implementada - 99 -

5.3. Control Infrarrojos - 100 - 5.3.1. Tecnología de Infrarrojos - 100 - 5.3.2. Tarea Implementada - 101 -

5.4. Control Luz - 101 - 5.4.1. Tecnología X10 - 102 - 5.4.2. Tarea Implementada - 102 -

5.5. Tres en raya virtual - 104 -

5.6. Tres en raya físico - 105 -

5.7. Control Conversación - 106 -

5.8. Resumen de tareas - 107 -

III

6 EMOTIVIDAD - 109 -

6.1. Relaciones - 114 - 6.1.1. Modelo de Relaciones implementado - 114 -

6.1.1.1. Actualización de usuarios - 116 - 6.1.1.2. Presentación de nuevos usuarios. - 117 -

6.1.2. Influencia de relaciones en el comportamiento del sistema - 119 - 6.1.3. Conclusiones sobre el modelo de relaciones - 120 -

6.2. Emociones - 121 - 6.2.1. Estado del arte: Teorías emocionales. - 122 -

6.2.1.1. La teoría de Ortony, Clore and Collins - 124 - 6.2.1.2. La teoría de Roseman - 127 - 6.2.1.3. La teoría de Scherer - 128 - 6.2.1.4. La teoría de Frijda - 130 - 6.2.1.5. La teoría de Oatley & Johnson-Laird - 133 -

6.2.2. Diseño del modelo emocional: Requisitos del sistema emocional - 135 - 6.2.3. Definición de objetivos de alto nivel: la teoría de Maslow. - 138 - 6.2.4. Diseño del modelo emocional: Arquitectura propuesta - 142 -

6.2.4.1. Relación tareas-necesidades - 144 - 6.2.4.2. Variación de necesidades. - 145 -

6.2.4.2.4. Nivel Fisiológico - 146 - 6.2.4.2.5. Nivel de Seguridad - 147 - 6.2.4.2.6. Nivel de Afiliación - 149 - 6.2.4.2.7. Nivel de Estima - 154 - 6.2.4.2.8. Nivel de Autorrealización - 157 -

6.2.4.3. Generación de NIFs - 158 - 6.2.4.3.9. Deseabilidad - 159 - 6.2.4.3.10. Inesperado - 161 - 6.2.4.3.11. Urgencia - 163 - 6.2.4.3.12. Relevancia - 165 - 6.2.4.3.13. Infrecuente - 166 -

6.2.4.4. Generación de emociones - 168 - 6.2.5. Sistema emocional implementado - 171 - 6.2.6. Conclusiones del sistema emocional - 174 -

7 CONCLUSIONES Y LÍNEAS FUTURAS - 177 -

7.1. Conclusiones - 177 - 7.1.1. Cumplimiento de requisitos - 179 -

7.2. Líneas Futuras - 180 -

8 PLIEGO DE CONDICIONES - 183 -

8.1. Condiciones generales - 183 -

8.2. Condiciones generales a todos los programas - 184 -

8.3. Condiciones generales de prueba - 185 -

8.4. Recursos materiales - 185 -

8.5. Recursos lógicos - 185 -

9 PRESUPUESTO - 187 -

9.1. Presupuesto de ejecución material - 188 - 9.1.1. Relación de salarios - 188 - 9.1.2. Relación de obligaciones sociales - 188 - 9.1.3. Relación de salarios efectivos totales - 189 -

IV

9.1.4. Coste de la mano de obra - 189 - 9.1.5. Coste total de materiales - 189 - 9.1.6. Importe total del presupuesto de ejecución material - 190 -

9.2. Importe de ejecución por contrata - 190 -

9.3. Honorarios Facultativos - 191 -

9.4. Importe Total del Proyecto - 191 -

BIBLIOGRAFÍA - 193 -

APÉNDICE A: Vocabulario del Reconocedor - 197 -

APÉNDICE B: Listado de Frases para Sintetizar - 199 -

APÉNDICE C: Experimento de Identificación - 201 -

APÉNDICE D: Relación entre Clases - 203 -

V

ÍNDICE DE FIGURAS.

FIGURA 1. EVOLUCIÓN TECNOLÓGICA DE LOS HOGARES (37) ............................................................................. - 2 - FIGURA 2. ARQUITECTURA GENERAL DEL SISTEMA ........................................................................................... - 9 - FIGURA 3. ARQUITECTURA GALAXY-II ....................................................................................................... - 11 - FIGURA 4. SCRIPT HUB MODELO GALAXY-II ................................................................................................ - 12 - FIGURA 5. PROCESO DE COMUNICACIÓN CON LA INTERFAZ DE ENTRADA ............................................................. - 14 - FIGURA 6. PROCESO DE COMUNICACIÓN CON LA INTERFAZ DE SALIDA ................................................................ - 16 - FIGURA 7. TOPOLOGÍAS DE REDES PEER-TO-PEER. .......................................................................................... - 21 - FIGURA 8. ESQUEMA GENÉRICO DE ARQUITECTURA CLIENTE-SERVIDOR. ............................................................. - 22 - FIGURA 9. ESTRUCTURA DE CLIENTE-SERVIDOR DE LA IMPLEMENTACIÓN ............................................................ - 26 - FIGURA 10. SOLICITUD XML-RPC................................................................................................................ - 29 - FIGURA 11. RESPUESTA XML-RPC .............................................................................................................. - 29 - FIGURA 12. SOLICITUD SOAP ..................................................................................................................... - 31 - FIGURA 13. RESPUESTA SOAP .................................................................................................................... - 31 - FIGURA 14. ESTRUCTURA FÍSICA IMPLEMENTADA ............................................................................................ - 32 - FIGURA 15. ROBOT URBANO ....................................................................................................................... - 36 - FIGURA 16. OPEL EYE ................................................................................................................................ - 37 - FIGURA 17. NEXI (ROBOT EMOCIONAL DEL MIT) ........................................................................................... - 38 - FIGURA 18. DISPOSITIVOS CON PANTALLA TÁCTIL. ........................................................................................... - 38 - FIGURA 19. DIAGRAMA DE BLOQUES DE UN RECONOCEDOR OBTENIDO DE (7) ....................................................... - 42 - FIGURA 20. ARQUITECTURA BÁSICA DE UN SISTEMA RECONOCEDOR OBTENIDO DE (9) ............................................ - 42 - FIGURA 21. ESQUEMA DE UN RECONOCEDOR DE DOS ETAPAS, OBTENIDO DE (7) ................................................... - 44 - FIGURA 22. ESQUEMA DE UN SINTETIZADOR DE HABLA ..................................................................................... - 54 - FIGURA 23. PROCESO DE SÍNTESIS MEDIANTE SELECCIÓN DE UNIDADES TOMADO DE (50). ....................................... - 59 - FIGURA 24. PROCESO DE SÍNTESIS MEDIANTE HMM TOMADO DE (50). .............................................................. - 61 - FIGURA 25. SECUENCIA DE MENSAJES DEL RECONOCEDOR. ................................................................................ - 66 - FIGURA 26. ALTERNATIVAS DE IDENTIFICACIÓN DE USUARIOS: USUARIO NUEVO VERSUS USUARIO CONOCIDO .............. - 66 - FIGURA 27. MODO 1 CON 30 LOCUTORES Y LAMBDA 4,5 ................................................................................. - 69 - FIGURA 28. MODO1 CON 30 LOCUTORES E HISTORIA DE 5 FRASES ..................................................................... - 70 - FIGURA 29. MODO 1 CON 30 LOCUTORES, HISTORIA DE 5 Y LAMBDA DE 4,5 ........................................................ - 70 - FIGURA 30. MODO 2 CON 1 LOCUTOR, HISTORIA 5 Y POBLACIÓN DE 30. ............................................................. - 71 - FIGURA 31. MODO 2 CON 10 LOCUTORES, HISTORIA DE 30 Y POBLACIÓN DE 30. .................................................. - 72 - FIGURA 32. PROCESO DE SÍNTESIS ................................................................................................................ - 73 - FIGURA 33. MECANISMO PING-PONG .......................................................................................................... - 74 - FIGURA 34. ESQUELETIZACIÓN DE LA MANO (15) ............................................................................................ - 78 - FIGURA 35. EJEMPLO DE UNA NEURONA ARTIFICIAL ......................................................................................... - 79 - FIGURA 36. EJEMPLO DEL ALGORITMO KNN PARA K = 4 Y K = 8 ......................................................................... - 80 - FIGURA 37. PLANTILLAS DE CARACTERÍSTICAS TIPO HAAR PROPUESTAS POR VIOLA Y JONES Y LIENHART ..................... - 81 - FIGURA 38. ESQUEMA DE UN CLASIFICADOR EN CASCADA .................................................................................. - 82 - FIGURA 39. FILTRADO PARA DETECCIÓN DE LUZ ............................................................................................... - 83 - FIGURA 40. BRAZO ROBÓTICO ..................................................................................................................... - 86 - FIGURA 41. A LA IZQUIERDA GROUCHO A LA DERECHA ROBOT URBANO ............................................................... - 87 - FIGURA 42. GESTOS (DE ARRIBA IZQUIERDA ABAJO DERECHA) ENFADO, NEUTRAL, ALEGRÍA, TRISTEZA Y MIEDO ............ - 88 - FIGURA 43. CARA DE LEVE ENFADO ............................................................................................................... - 88 - FIGURA 44. MECANISMO DE DETECCIÓN DE CARICIAS. ...................................................................................... - 90 - FIGURA 45. ESTIMACIÓN DE FRECUENCIA DE LAS CARICIAS ................................................................................. - 91 - FIGURA 46. DIAGRAMA DE HERENCIA DE LAS TAREAS ....................................................................................... - 95 - FIGURA 47. PILA DE PROTOCOLOS BLUETOOTH PARA SPP (13) .......................................................................... - 98 - FIGURA 48. ARQUITECTURA GENERAL DEL SISTEMA IRTRANS (19) .................................................................... - 100 - FIGURA 49. TRAMA X10 .......................................................................................................................... - 102 - FIGURA 50. ARQUITECTURA SISTEMA DRAC EXTRAÍDO DE (20) ....................................................................... - 103 - FIGURA 51. SCRIPT EN PERL PARA EL CONTROL DE DISPOSITIVO X10 ................................................................. - 104 -

VI

FIGURA 52. SECUENCIA DE CÁLCULO DEL MEJOR MOVIMIENTO. ........................................................................ - 105 - FIGURA 53. ESQUEMA DE ARQUITECTURA DE TAREA ....................................................................................... - 107 - FIGURA 54. ICAT CHESS PLAYER ................................................................................................................. - 110 - FIGURA 55. GUARDERÍA ROBÓTICA DEL PROYECTO FEELIX GROWING ................................................................. - 111 - FIGURA 56. URBANO EN UNA EXPOSICIÓN .................................................................................................... - 111 - FIGURA 57. ESQUEMA DEL MODELO DE RELACIONES ...................................................................................... - 115 - FIGURA 58. MÁQUINA DE ESTADOS DEL PROCESO DE IDENTIFICACIÓN ................................................................ - 117 - FIGURA 59. ESTRUCTURA DEL TIPO DE EMOCIONES (30) ................................................................................. - 125 - FIGURA 60. SISTEMA EMOCIONAL DE FRIJDA (41) ......................................................................................... - 133 - FIGURA 61. ARQUITECTURA MEDIANTE TIF .................................................................................................. - 136 - FIGURA 62. PIRÁMIDE DE MASLOW ............................................................................................................ - 138 - FIGURA 63. ADAPTACIÓN DE LA PIRÁMIDE DE MASLOW. ................................................................................ - 141 - FIGURA 64. ARQUITECTURA EMOCIONAL IMPLEMENTADA ............................................................................... - 142 - FIGURA 65. LISTA DE EVENTOS Y RELACIÓN CON NECESIDADES .......................................................................... - 144 - FIGURA 66. SIMULACIÓN DE SURVIVAL ........................................................................................................ - 147 - FIGURA 67. SIMULACIÓN DE SAFETY ............................................................................................................ - 148 - FIGURA 68. SIMULACIÓN DE HISTOGRAMAS PARA LUZ .................................................................................... - 151 - FIGURA 69. VENTANA DE PARZEN SOBRE HISTOGRAMA PARA EL PUNTO 1.72X10

7 .............................................. - 152 -

FIGURA 70. SIMULACIÓN COMPLETA DE CHANGES ......................................................................................... - 154 - FIGURA 71. SIMULACIÓN DE SUCCESS .......................................................................................................... - 156 - FIGURA 72. SIMULACIÓN DE ETHICS ............................................................................................................ - 158 - FIGURA 73. SIMULACIÓN DE DESEABILIDAD. ................................................................................................. - 160 - FIGURA 74. SIMULACIÓN DE INESPERADO CON CAMBIOS SUAVES. ..................................................................... - 161 - FIGURA 75. SIMULACIÓN DE INESPERADO CON CAMBIOS ABRUPTOS .................................................................. - 162 - FIGURA 76. SIMULACIÓN DE URGENCIA CON CAMBIOS SUAVES ......................................................................... - 164 - FIGURA 77. SIMULACIÓN DE URGENCIA CON CAMBIOS ABRUPTOS ..................................................................... - 165 - FIGURA 78. SIMULACIÓN DE RELEVANCIA ..................................................................................................... - 166 - FIGURA 79. SIMULACIÓN DE INFRECUENTE ................................................................................................... - 168 - FIGURA 80. SECUENCIA DE CÁLCULO EMOCIONAL.......................................................................................... - 171 - FIGURA 81. PROCESO DE RESPUESTA EMOCIONAL .......................................................................................... - 172 - FIGURA 82. DEFINICIÓN DE CLASE CEMOTION .............................................................................................. - 203 - FIGURA 83. JERARQUÍA DE CLASES PARA LAS NECESIDADES .............................................................................. - 204 - FIGURA 84. DIAGRAMA DE IMPLEMENTACIÓN DEL MÓDULO EMOCIONAL .......................................................... - 204 - FIGURA 85. FUNCIONALIDAD DE CMODULOBASESOAP ................................................................................... - 204 - FIGURA 86. JERARQUÍA DE CLASES DE TAREAS REMOTAS ................................................................................. - 204 - FIGURA 87. ÁRBOL DE LLAMADAS DEL MÉTODO MAIN .................................................................................... - 204 - FIGURA 88. ÁRBOL DE LLAMADAS PARA EL SERVIDOR DE SÍNTESIS ..................................................................... - 204 - FIGURA 89. ÁRBOL DE LLAMADAS PARA EL SERVIDOR DE CARA ......................................................................... - 204 -

VII

ÍNDICE DE TABLAS

TABLA 1. RESULTADO DE PRUEBA DE IDENTIFICACIÓN DE EMOCIONES............................................................... - 63 - TABLA 2. CORRESPONDENCIA ENTRE ACCIONES Y COMANDOS ........................................................................ - 99 - TABLA 3. LOCAL VARIABLES IN THE THEORY OF ORTONY, CLORE AND COLLINS ................................................. - 126 - TABLA 4. PLAN JUNCTURES .................................................................................................................... - 134 - TABLA 5. RELACIÓN DE PESOS PARA CÁLCULO EMOCIONAL ........................................................................... - 169 - TABLA 6. SUELDOS DE LAS PERSONAS QUE HAN INTERVENIDO EN EL PROYECTO ................................................ - 188 - TABLA 7. SALARIOS EFECTIVOS TOTALES ................................................................................................... - 189 - TABLA 8. OBLIGACIONES SOCIALES .......................................................................................................... - 188 - TABLA 9. COSTE DE LA MANO DE OBRA. ................................................................................................... - 189 - TABLA 10. COSTE DE MATERIALES ............................................................................................................. - 190 - TABLA 11. PRESUPUESTO DE EJECUCIÓN MATERIAL ...................................................................................... - 190 - TABLA 12. RELACIÓN DE CONCEPTOS ADICIONALES ....................................................................................... - 191 - TABLA 13. IMPORTE DE EJECUCIÓN POR CONTRATA ...................................................................................... - 191 - TABLA 14. HONORARIOS FACULTATIVOS .................................................................................................... - 191 - TABLA 15. HONORARIOS TOTALES............................................................................................................. - 191 - TABLA 16. IMPORTE TOTAL DEL PROYECTO ................................................................................................. - 192 - TABLA 17. EXPERIMENTO IDENTIFICACIÓN DE USUARIOS MODO 1 ................................................................... - 201 - TABLA 18. EXPERIMENTO IDENTIFICACIÓN DE USUARIOS MODO 2 BASE DE DATOS GTH ...................................... - 202 - TABLA 19. SECUENCIA DEL BUCLE PRINCIPAL ............................................................................................... - 204 -

Capítulo 1 – Introducción

- 1 -

CCCCAPÍTULO 1APÍTULO 1APÍTULO 1APÍTULO 1

1 INTRODUCCIÓN

En los últimos años se ha asistido a un incremento considerable del equipamiento

tecnológico presente en cada hogar. De hecho, si se comparan cifras del instituto nacional de

estadística (INE) para el año 2003 y para el 2008 la evolución queda más que patente.

Estas tendencias generan

de determinados colectivos. Por ejemplo, según el INE, uno de los principales motivos

el porcentaje de penetración de acceso a internet en los hogares sea de aproximadamente un

50% en el 2008 es que, dichos colectivos

(26,1%)”. Además, mientras el uso de los ordenadores

“…es prácticamente universal (94,1%)…”

utilizado el ordenador en los últimos tres meses

sustenta la idea de que es necesario un cambio

electrónicos.

Es importante señalar que este proyecto se enmarca en una línea de trabajo desarrollada

en el Grupo de Tecnología del Habla (GTH) del Departamento de Ingeniería Electrónica (DIE) de

la Escuela Técnica Superior de Ingenieros de Telecomunicaci

la investigación para la integración

Figura 1.

0

10

20

30

40

50

60

70

80

90

100


- 2 -

Estas tendencias generan nuevos problemas relacionados con la dificultad de adaptación

de determinados colectivos. Por ejemplo, según el INE, uno de los principales motivos


dichos colectivos, “…tienen pocos conocimientos para utilizarlos

Además, mientras el uso de los ordenadores, por parte de menores de 10 a 15 años

es prácticamente universal (94,1%)…”, el porcentaje de personas entre 16 y

utilizado el ordenador en los últimos tres meses, se reduce a “…el 61,0% de la población

sustenta la idea de que es necesario un cambio en la forma de interactuar con



Técnica Superior de Ingenieros de Telecomunicación (ETSIT) que tiene como objetivo

la investigación para la integración de sistemas de gestión de diálogos en entornos domóticos.

Figura 1. Evolución tecnológica de los hogares (37)

Evolución tecnológica en los hogares

Porcentaje de Penetración en 2003

Porcentaje de Penetración en 2008


relacionados con la dificultad de adaptación

de determinados colectivos. Por ejemplo, según el INE, uno de los principales motivos por el que


tienen pocos conocimientos para utilizarlos

de 10 a 15 años,

74 años, que ha

el 61,0% de la población…”. Esto

con los aparatos



ón (ETSIT) que tiene como objetivo

en entornos domóticos.

Porcentaje de Penetración en

Porcentaje de Penetración en


- 3 -

1.1. Objetivo de este proyecto

Actualmente cualquier aparato electrónico que se pueda adquirir viene con un manual de

instrucciones para aprender a utilizarlo. Esto es un claro reflejo de que la interfaz, si bien puede

estar simplificada, es más cercana a la máquina que a la persona y, por tanto, requiere un

proceso de adaptación. En muchos casos, estas dificultades impiden que las personas detecten

la utilidad de estos dispositivos, pues pueden parecen demasiado complicados para aprender a

manejarlos. Además, existe un rechazo frente a máquinas que no presentan un comportamiento

empático. Por ejemplo, el uso de un sistema de navegación GPS, en un automóvil, se reduce si

no es capaz de dar unas directrices adecuadas en función de la distancia al hito, la velocidad, etc.

Frente a esta problemática, las soluciones que se barajan pasan por la creación de

sistemas capaces de servir de adaptación entre las máquinas y los humanos. Estos sistemas se

sitúan cercanos a las personas, de modo que permiten la interacción con los aparatos

minimizando el aprendizaje necesario. Es decir, el usuario se comunicaría con el sistema de

forma natural (bien por gestos, habla u otra forma de comunicación propia de las personas) y

éste se encargaría de interpretar el mensaje y realizar la acción solicitada.

Por otro lado, cada vez son más comunes los sistemas capaces de simular emociones

humanas, ya que éstas son consideradas como una vía de desarrollo para la aceptación de las

máquinas por parte de las personas.

Por tanto, el objetivo de este proyecto es el desarrollo sobre las tres vías mencionadas

para acercar personas y máquinas: las interfaces, más amigables; la aplicación, un asistente

personal que proporcione verdadera utilidad; y la emotividad, que el usuario sea capaz de

interaccionar con un sistema que se adapte en vez de mostrarse como una máquina monótona y

desesperante. Por tanto, este proyecto versará sobre el diseño e implementación de un

asistente personal capaz de expresar emociones.

1.2. Estructura de la memoria

Dada la heterogeneidad de este proyecto, la presente memoria está estructurada en

función de las tres vías de desarrollo: Aplicaciones, Interfaz y Emotividad. Además, se ha

decidido incluir el estado del arte de forma distribuida. En este sentido, no habrá un capítulo


- 4 -

específico de estado del arte, sino que será una serie de apartados en cada capítulo. En ellos se

explicará la situación del tema sobre el que se va a hablar a lo largo del capítulo. A continuación

se presenta la estructura de la memoria:

• Descripción general del sistema.

• Subsistema de comunicaciones.

• Interfaz Persona-Máquina implementada.

• Aplicaciones.

• Emotividad: se hablará de las emociones y las relaciones.

• Conclusiones y Líneas de trabajo futuras.

Como se ve, hay un primer capítulo que servirá de base para entender cuál es el sistema

del que se hablará. Posteriormente, se proporcionará una visión de la arquitectura de

comunicaciones implementada para, finalmente, profundizar sobre cada una de las vías de

desarrollo. Por último se hará una reflexión proporcionando las conclusiones y líneas futuras.

1.3. Fases de Trabajo

Este proyecto ha sido realizado conforme a las siguientes fases de trabajo:

1. Análisis del proyecto y documentación: Durante esta fase se analizó la plataforma

de desarrollo de aplicaciones con voz SERVIVOX, con la intención de poder

adaptar los módulos de reconocimiento y comprensión del lenguaje natural.

2. Incorporación del identificador de hablante: En esta etapa se integró la

tecnología de identificación del hablante de forma que pueda ser usado por este

agente en su modelo de usuarios.

3. Desarrollo del modelo de relaciones: Esta fase consistió en la implementación del

modelo de relaciones que permite dar de alta a nuevos usuarios así como

modificar y consultar sus características, permitiendo que evolucione la tipología

de cada interlocutor (amigo, conocido o desconocido) dependiendo de sus

interacciones con el agente.

4. Adaptación del sintetizador de habla con emociones: En esta fase se trabajó en

habilitar el acceso al módulo sintetizador de voz, que actualmente está disponible

en un entorno LINUX, desde Microsoft Windows.


- 5 -

5. Desarrollo del modelo de emociones: En ella se implementó el modelo de

emociones que permite definir el estado emocional del agente en cada momento

atendiendo a los eventos que detecte y al paso del tiempo.

6. Desarrollo del módulo de tareas: En esta etapa se incorporaron las tareas de

juego. Se crearon las acciones de ayuda doméstica como encender o apagar la luz,

controlar Roomba o gobernar el equipo HI-FI.

7. Desarrollo del modelo de comportamiento e integración: En esta fase se

diseñó el dominio de aplicación y se obtuvo un conjunto de frases representativas

de lo que los usuarios pueden decir al agente en dicho dominio, permitiendo

ajustar el reconocedor de habla (habla � texto) y el módulo de comprensión

(texto � conceptos relevantes en el dominio) para un funcionamiento óptimo.

Capítulo 2 – Descripción General del Sistema

- 7 -


2 DESCRIPCIÓN GENERAL DEL SISTEMA

Antes de abordar con detenimiento cada uno de los módulos de este sistema, resulta

necesaria una breve visión de conjunto. El objetivo de este apartado es proporcionarla.

Primero se definirán una serie de requisitos a alcanzar en la elaboración de este proyecto.

Posteriormente se ofrecerá un esquema general de la arquitectura del sistema y finalmente, por

su carácter de núcleo de unión entre los diferentes componentes del sistema, se profundizará en

el modelo de comportamiento.


- 8 -

2.1. Definición de requisitos

A la vista de la problemática referida en el capítulo de introducción se hacen prioritarios

los siguientes requisitos generales del sistema:

� Interfaz multimodal: El objetivo es crear una forma de comunicación persona-

máquina que no dependa de un tipo de interfaz determinado. Habilitando varias

maneras se conseguirá que el sistema sea menos estricto en cuanto a las reglas de

comunicación.

� Comportamiento emocional: El sistema debe ser capaz de reaccionar

emocionalmente a los diferentes acontecimientos que suceden en su entorno.

� Comportamiento personalizado: El sistema debe estar en disposición de

identificar con qué usuario está tratando y actuar en consonancia a la relación que

mantienen.

� Funcionalidad de asistente doméstico: Debe ser capaz de realizar sencillas tareas

domésticas como encender o apagar una luz, controlar una aspiradora robótica

Roomba o gobernar un equipo HI-FI.

� Compañero de juegos: Debe actuar como un compañero de juego en las 3 en

raya, comportándose de manera emocional.

� Arquitectura escalable: El sistema debe ser suficientemente independiente como

para que la inclusión de nuevas tareas, o la modificación de las ya existentes, se

realice de forma sencilla.

2.2. Arquitectura general del sistema

La arquitectura general del sistema es la representada en la figura.

Como se puede ver, existen cinco grandes módulos. Cada uno de ellos está compuesto por

distintos sub-módulos que serán detallados en los capítulos pertinentes.

• Módulo interfaz de entrada y módulo interfaz de salida: Aunque en esencia

ambos se podrían haber fusionado en un único módulo de interfaz, se ha

preferido esta división. El funcionamiento de cada uno de ellos es gobernar el


hardware de interfaz adaptando la información, ya sea para su correcta

representación,

• Módulo de aplicaciones:

tareas que es capaz de realizar el sistema.

módulo es que todas ellas tien

aparecerá detallado

• Módulo de emotividad:

comportamiento “humanizado”.

como el modelo de emociones. Su misión es generar información para que las

respuestas puedan ser adaptadas a los diferentes

• Módulo de comportamiento:

principalmente, de la intercomunicación entre los diferentes módulos.

Llegados a este punto es posible realizar

funcionamiento del sistema:

1. Un estímulo del exterior es percibido por el hardware de entrada.

Descripción General del Sistema

- 9 -

ware de interfaz adaptando la información, ya sea para su correcta

representación, como para que pueda ser utilizada por el sistema.

Módulo de aplicaciones: En este módulo se agrupan cada una de las diferentes

tareas que es capaz de realizar el sistema. El motivo de su agrupación

que todas ellas tienen unas características comunes tal y

aparecerá detallado en el Capítulo 5.

e emotividad: Este módulo es el encargado de generar

comportamiento “humanizado”. En él se recogen tanto el modelo de relaciones,


respuestas puedan ser adaptadas a los diferentes estados del sistema.

Módulo de comportamiento: Constituye el núcleo del sistema y se encarga,


Llegados a este punto es posible realizar, a grandes rasgos, una breve descripción del

del sistema:

Un estímulo del exterior es percibido por el hardware de entrada.

Figura 2. Arquitectura General del Sistema

ware de interfaz adaptando la información, ya sea para su correcta

omo para que pueda ser utilizada por el sistema.

En este módulo se agrupan cada una de las diferentes

El motivo de su agrupación en un único

en unas características comunes tal y como

Este módulo es el encargado de generar un

l se recogen tanto el modelo de relaciones,


estados del sistema.

Constituye el núcleo del sistema y se encarga,


una breve descripción del

Un estímulo del exterior es percibido por el hardware de entrada.


- 10 -

2. El sub-módulo correspondiente del módulo interfaz de entrada se encarga de

procesar esta información y, si es necesario, adaptarla.

3. A continuación el sub-módulo que recibe el estímulo proporciona la información

adaptada al módulo de comportamiento.

4. El módulo de comportamiento se encarga de difundir esta información a las

tareas del módulo de aplicaciones.

5. La tarea que recibe la información genera una acción de respuesta destinada a la

interfaz de salida e información orientada al módulo de emociones.

6. El resultado de la tarea es enviado al módulo de comportamiento.

7. El módulo de comportamiento almacena la acción de respuesta y envía la

información destinada al módulo de emociones.

8. El módulo de emociones recoge la información y recalcula la respuesta emocional

enviándola al módulo de comportamiento.

9. El módulo de comportamiento genera una respuesta final combinando la

información emocional con la acción respuesta de la tarea. Esta respuesta final es

enviada a la interfaz de salida.

10. El módulo de interfaz de salida procesa la respuesta final y genera una acción

acorde a ella.

2.3. Modelo de Comportamiento

Como se ha dicho, en esta arquitectura el módulo de comportamiento juega un papel

importante como coordinador del sistema ya que cualquier mensaje que quieran intercambiar

los módulos pasa por él. Además, presenta la necesidad de ser escalable, pues el sistema puede

crecer y el módulo de comportamiento que sustenta la coordinación de las comunicaciones

corre el peligro de convertirse en el cuello de botella del sistema.

Antes de abordar la solución propuesta se presentarán los precedentes en los que se ha

basado.

2.3.1. Estado del arte: Módulo de comportamiento.

El auge que los equipos informáticos han experimentado desde los noventa hace que cada

vez sean más ambiciosas las aplicaciones que se ejecutan en ellos, como es el caso de las


- 11 -

aplicaciones basadas en reconocimiento de voz. Estas aplicaciones, unidas a la posibilidad de

conexión a internet que casi cualquier ordenador tiene, proporcionan el marco perfecto para la

automatización de servicios telefónicos como alquiler de coches, reserva de hoteles, información

de vuelos, etc.

No obstante, esta suerte de aplicaciones presenta una gran complejidad y es por ello que

se tiende a dividir estos sistemas en módulos con funcionalidades independientes y concretas.

Por ejemplo, un usuario que esté en una ciudad y desee realizar una reserva de hotel llamará a

un teléfono que estará asociado a un servidor de audio. Este servidor de audio se comunicará

con un reconocedor de voz que puede estar en otra ciudad. Este reconocedor de voz deberá

enviar la información a un servidor que esté conectado a la base de datos de reservas del hotel

que puede estar en una tercera ciudad. Por tanto, se está realizando un proceso descentralizado

con intercambio de información entre diferentes módulos. Para coordinar este intercambio de

información han aparecido módulos de comportamiento. A continuación se van a analizar dos

de las alternativas más relevantes: el GALAXY-II Communicator (1) elaborado como

actualización del GALAXY (2) por el Massachusetts Institute of Technology (MIT), y el CU

Communicator (3) creado por la Universidad de Colorado.

2.3.1.1. GALAXY-II

GALAXY-II es una arquitectura Cliente/Servidor para acceder a información online usando

reconocimiento de voz. En la figura se puede apreciar la representación esquemática del

sistema.

La peculiaridad de éste consiste en

que la interacción del hub central con los

servers se controla por medio de un

lenguaje de script. Cada script contiene la

lista de servidores con su dirección, puerto,

la lista de servicios que es capaz de ofrecer

y uno o varios programas. Cada programa

consiste en un conjunto de reglas

(compuestas por una condición

desencadenante y una operación

consecuencia), una lista de variables de

Figura 3. Arquitectura GALAXY-II


- 12 -

entrada y salida para cada regla y un

conjunto de variables opcionales sobre

información del pasado del sistema.

Cuando una regla se dispara, la

variable de entrada se empaqueta en un

token y se envía al servidor determinado

por esa regla. Adicionalmente, el hub

puede esperar un token del servidor con la

variable de salida. Además, las variables de

entradas y salidas son almacenadas en un

master token interno del hub.

Como se ve, es el hub quien decide, en base a una serie de scripts, qué servidor debe

recibir ese mensaje. Por tanto, se considera que este tipo de módulo de comunicación presenta

cierta inteligencia.

2.3.1.2. CU Communicator

Análogo al modelo GALAXY-II aparece el CU Communicator. Éste también es un modelo

Cliente/Servidor que puede ser utilizado en sistemas similares al presentado en el GALAXY II

para acceder a información online mediante reconocimiento de voz. La particularidad de este

sistema es que el hub central de comunicaciones no presenta ningún tipo de inteligencia. Es

decir, en este caso los módulos que originan los mensajes son los que determinan dónde tiene

que ser entregado. Por ejemplo, el servidor de audio manda al hub un mensaje que informa de

la existencia de un nuevo mensaje de audio disponible y que debe ser entregado al reconocedor

de voz. De esta forma el hub actúa como un mero router enviando la información de unos

módulos a otros.

2.3.2. Módulo de comportamiento implementado

La solución adoptada pasa por un término medio entre las nombradas anteriormente. En

este sistema el funcionamiento del módulo de comportamiento está determinado por la

procedencia y el destino de los mensajes que se estén enviando. Así pues existe información

procedente de la interfaz de entrada, información dirigida a la interfaz de salida e información

relativa al sistema emocional. A continuación se expondrá el funcionamiento en cada caso.

Figura 4. Script hub modelo GALAXY-II


- 13 -

2.3.2.1. Mensajes procedentes de la interfaz de entrada

Los mensajes procedentes de la interfaz de entrada pueden provenir tanto del

reconocedor de habla como del tratamiento de imágenes mediante Opencv. Estos mensajes son

conceptos que los destinatarios, en este caso las tareas, serán capaces de entender. Por

ejemplo, “SinLuz”, “saludo”, etc.

El funcionamiento del módulo de comportamiento para este tipo de mensajes puede ser

considerado como inteligente, pues el módulo que genera el mensaje no determina quién va a

ser el destinatario.

En el proceso de envío de mensajes intervienen varios procesos, en concreto, las tareas, el

módulo generador de mensaje y el módulo de comportamiento. Por tanto, resulta interesante

analizar lo que ocurre en cada uno de ellos.

• Interfaz de Entrada: Los módulos de la interfaz de entrada se encuentran

constantemente analizando la información de los sensores, ya sea el micrófono o

la cámara web, y, en función de ella, determinan si ha ocurrido algo. Cuando

detectan que algo ha ocurrido lo que hacen es actualizar el concepto que

caracteriza el suceso y lo indican incrementando un número de versión asociado.

Es decir, si el reconocedor detecta la palabra “hola”, el nuevo concepto será

“saludo” y el número de versión se incrementará en uno.

• Tarea: Las tareas son programas destinados a realizar algo en función de las

órdenes del usuario. En este sentido, la mayor parte del tiempo están a la espera

de dichas órdenes, concretamente el cliente de la tarea se encuentra en un bucle

esperando un concepto que le resulte válido. También cabe destacar que las

tareas presentan dos estados, activo o no, en función de si se encuentran en

medio de la realización de una acción. Por ejemplo, si se inicia una partida, la

tarea de juego se encontrará activa hasta que la partida finalice.

• Módulo de comportamiento: Se encarga de hacer llegar el concepto a las tareas.

Su funcionamiento es sencillo y mecánico para favorecer la escalabilidad. El

módulo de comportamiento analiza periódicamente el número de versión de los

conceptos de los módulos de interfaz de entrada. Cuando detecta que alguno de


- 14 -

ellos no coincide con el que tiene guardado comienza el proceso de envío del

concepto. Para ello, el módulo recorre la lista de las tareas enviando el concepto

en modo de prueba. En este momento cada tarea que recibe el concepto analiza

si es un concepto de los que es capaz de entender o no y devuelve una respuesta

en función de ello. Tras recibir alguna respuesta el módulo de comportamiento

vuelve a recorrer nuevamente todas las tareas para enviar el concepto a aquella

que lo admita y que esté activa. Si no hay ninguna activa, se enviará a la primera

que lo admita. Si ninguna lo admite no se enviará. Además, si el proceso de

sondeo de prueba falla porque no se recibe ninguna respuesta ya sea afirmativa o

negativa, el sistema esperará unos segundos y abortará automáticamente el

proceso. Finalmente se memorizará el nuevo número de versión para poder

volver a detectar cambios.

La figura ilustra el proceso general:

1. Se recibe el concepto, en este caso del reconocedor de voz.

2. Sondeo de las tareas en modo de prueba.

3. Respuesta de las tareas al concepto de prueba.

4. Transmisión del concepto a la tarea que lo comprendía y que estaba activa.

Como se ve, el orden de prioridad de las tareas está prefijado a la hora de definir la lista

de las tareas. De esta forma, un concepto que entiendan varias tareas, si ninguna de ellas está

activa, será transmitido a la que se encuentre en una posición más adelantada de la lista.

Figura 5. Proceso de comunicación con la interfaz de entrada


- 15 -

2.3.2.2. Mensajes destinados a la interfaz de salida

Los mensajes destinados a la interfaz de salida típicamente estarán dirigidos al

sintetizador de voz, ya que el control de la cara es gobernado directamente por el módulo de

comportamiento en función del estado emocional.

Para la transmisión de este tipo de mensajes el módulo de comportamiento no presenta

inteligencia añadida ya que el generador del mensaje establece el destinatario. De esta forma, el

módulo de comportamiento se comportará como un mero router.

En este caso también intervienen varios actores: las tareas, que ahora son las que generan

el mensaje; el módulo de comportamiento, que será el encargado de hacer llegar los mensajes; y

el sintetizador de voz, que será el destinatario. A continuación se expondrá lo que ocurre en

cada uno de ellos.

• Tarea: Las tareas son las encargadas de generar los mensajes hacia el sintetizador

de voz. No todas las tareas generan mensajes, pero sí todas presentan la

estructura para mandarlos, de esta forma se invierte en escalabilidad. El

funcionamiento de la generación de mensajes por parte de la tarea es bastante

sencillo. Cada tarea consta de un concepto y un número de versión asociado al

concepto. Cuando se desea sintetizar una frase simplemente se rellenará el

campo concepto acorde a la situación y se aumentará el número de versión. En

esta ocasión, a diferencia de la comunicación con el interfaz de entrada, el

concepto estará compuesto de cuatro palabras o campos que ayudan a

determinar qué frase escoger. Por ejemplo se podrían usar las palabras “Juego” y

“Ganar” para sintetizar una frase relacionada con el juego y con la situación de

haber ganado. No obstante, si no se necesitan las cuatro palabras para definir el

concepto pueden indicarse como “Irrelevante” de modo que serán ignorados por

el sintetizador.

• Módulo de Comportamiento: El módulo de comportamiento recorrerá una lista

de las tareas comprobando periódicamente el número de versión del concepto a

sintetizar. Si alguna tarea ha modificado este número se invocará al sintetizador,

para lo que es necesario añadir dos parámetros más. Uno es la emoción,

proveniente del sistema emocional, y otro es la relación con el usuario,


- 16 -

proveniente del modelo de usuarios. Finalmente se cursa la solicitud al

sintetizador y se sigue recorriendo la lista. Si hubiera otra tarea que desease

sintetizar también se cursaría. Por último se guardarían los números de versiones

correspondientes a cada tarea para, en la próxima comprobación, no volver a

enviar el mismo concepto.

• Sintetizador de voz: Este es el destinatario de las comunicaciones. Consiste en un

servidor que proporciona un servicio de síntesis que es invocado por el módulo de

comportamiento. En este sentido su funcionamiento es totalmente pasivo en

cuanto a la transmisión de mensajes.

La figura muestra el esquema de funcionamiento. Cada tarea solicita un concepto. El

módulo de comportamiento recoge estas solicitudes y las complementa con la emoción y la

relación con el usuario y envía la solicitud al sintetizador de voz. Éste es el encargado de realizar

la síntesis final.

2.3.2.3. Mensajes del modelo emocional

Es importante indicar que el módulo de comportamiento no interviene en el proceso de

comunicación entre las tareas y el sistema emocional, esto se describirá en el apartado de

emociones del Capítulo 6. No obstante, no implica que en el proceso de obtención de emociones

el módulo de comportamiento no intervenga. Todo lo contrario, este módulo es el encargado de

solicitar el cálculo emocional cada cierto tiempo. Por tanto, en esta ocasión se puede decir que

el módulo de comportamiento actúa de forma autónoma, ya que se mueve por motivación

propia al precisar dicha información para poder completar su tarea de enviar mensajes a la

interfaz de salida.

Figura 6. Proceso de comunicación con la interfaz de salida


- 17 -

El modo de solicitar dicha información al sistema emocional es sencillo ya que, por un lado

el sistema emocional es parte del mismo programa y no un cliente o servidor externo, lo que

posibilita llamadas locales a funciones. Por otro lado, este tipo de solicitudes no van a crecer,

pues el único que solicitará el cálculo de la nueva respuesta emocional será el módulo de

comportamiento y, en consecuencia, no necesita crearse un proceso que pueda ser fácilmente

escalable.

2.3.2.4. Secuencia del módulo de comportamiento

El proceso periódico que se repite en el módulo de comportamiento cada cierto tiempo

consiste en:

1º. Administración de la interfaz de entrada, reenviando los conceptos que puedan

haberse recibido.

2º. Petición de actualización emocional del sistema.

3º. Realización de las acciones destinadas al control de la interfaz de salida (cara y

síntesis de voz).

Capítulo 3 – Subsistema de Comunicaciones

- 19 -


3 SUBSISTEMA DE COMUNICACIONES

En este sistema se ha utilizado una arquitectura distribuida en la que distintos

componentes se comunican vía TCP/IP. Esta es una tendencia de los últimos años favorecida por

las condiciones actuales de conectividad y cantidad de dispositivos. No obstante, antes de

precisar la implementación realizada parece conveniente hacer un análisis de la situación y las

diferentes alternativas que aparecen a la hora de crear un sistema de estas características.

3.1. Estado del arte: Arquitecturas de comunicaciones.

La evolución de las comunicaciones entre ordenadores ha ido de la mano con los

principales avances técnicos. Así pues, antiguamente existía un gran ordenador principal al cual


- 20 -

se conectaban los usuarios mediante sencillos terminales remotos para solicitar un determinado

servicio de entre todos los que eran ofrecidos. Estos terminales eran de escasas prestaciones y

por tanto el sistema central llevaba el peso de las operaciones. Posteriormente, gracias al

abaratamiento de los componentes, se ha ido evolucionando a la separación de servicios en

diferentes equipos de modo que cada usuario se conectaba a una computadora dedicada. De

esta forma se redujo el cuello de botella asociado a un gran ordenador que procesara las

solicitudes de todos los terminales. Seguidamente aconteció el auge de los equipos de escritorio,

lo cual permitió que los ordenadores servidores no necesitasen tanta potencia, pues gran parte

de los cálculos son realizados en el equipo del usuario. Por último, la actual popularización de las

redes de ordenadores hace que la mayoría de los equipos se encuentran interconectados. Este

concepto da pie a las arquitecturas Cliente/Servidor en las que un proceso denominado cliente,

que se encuentra realizando una tarea, puede demandar información a un servidor. Sin

embargo, en estas arquitecturas los servidores pueden recibir muchas solicitudes con el

consiguiente riesgo de convertirse en cuellos de botellas.

Otra de las soluciones existentes es la arquitectura peer-to-peer (P2P). Este tipo de

arquitecturas se basan en un concepto diferente. En ellas todos los componentes están al mismo

nivel de modo que cada nodo o usuario es un cliente y servidor que recibe las peticiones de

comunicaciones de sus vecinos y las envía a aquellos que estén próximos al destino. Además,

puede realizar él mismo una petición. La ventaja fundamental es que no existe un servidor que

controle las comunicaciones de modo que el sistema es enormemente escalable solucionando el

problema que presentan las anteriores. Existen dos variaciones de esta arquitectura:

• Peer-to-peer centralizada: En la que un único nodo actúa como punto

central del sistema de modo que todas las comunicaciones pasan por él.

Este sistema presenta problemas de escalabilidad pues la capacidad del

servidor central puede convertirse en un cuello de botella si el número de

nodos conectados aumenta suficientemente.


- 21 -

• Peer-to-peer mixta: En esta versión existen nodos centrales que actúan

como servidores para distribuir el tráfico. No obstante, la información de

enrutamiento está en los nodos, de modo que si alguno de los módulos

centrales se cae, el sistema puede comportarse como un peer-to-peer

puro.

A la vista de las alternativas, en este proyecto se ha decidido implementar una

arquitectura Cliente/Servidor. Esto es así porque peer-to-peer está orientada a sistemas muy

grandes en los que cada nodo toma decisiones globales ya que son quienes gobiernan. En la

arquitectura Cliente/Servidor, existe la ventaja de que las peticiones de cada cliente pasan por el

mismo servidor y, por tanto, la implementación de una lógica que coordine al sistema puede ser

realizada en un único módulo. En el caso de las redes peer-to-peer, cada petición puede llevar

un camino distinto y la implementación de una lógica de coordinación debería ser creada en

cada nodo de forma distribuida. Además, el tamaño del sistema es suficientemente reducido

como para que no exista, ni pueda existir en un futuro próximo, una limitación del número de

módulos posibles debido a las capacidades del servidor.

Figura 7. Topologías de redes peer-to-peer.

3.2. Arquitectura Cliente/Servidor

3.2.1. Descripción

Su funcionamiento es sencillo

un ordenador servidor, que realiza la función

configuración no es definitiva. Es decir, los ordenadores pueden ser clientes para

tareas y servidores para otras ya que el objetivo es que cada ordenador realice las

óptimas para sus recursos (4).

La tendencia en este tipo de arquitecturas es

computación mientras que los clientes realizan diversas acciones relacionadas con el usuario. De

esta forma un sistema complejo es dividido en módulos haciendo más fácil su desarrollo y

escalabilidad. Además, no existe una imposición sobre la situación

pueden estar distribuidos físicamente en

geográficas.

3.2.2. Componentes

Los componentes principales de una arquitectura Cliente/Servidor son:

Figura 8.


- 22 -

Arquitectura Cliente/Servidor

Descripción

onamiento es sencillo, se tiene un ordenador cliente que requiere un servicio de

realiza la función para la que está programado. No obstante, esta

configuración no es definitiva. Es decir, los ordenadores pueden ser clientes para

tareas y servidores para otras ya que el objetivo es que cada ordenador realice las

La tendencia en este tipo de arquitecturas es que el servidor se encargue del peso de



escalabilidad. Además, no existe una imposición sobre la situación de los módulos, de modo que

pueden estar distribuidos físicamente en diferentes equipos incluso en diferentes localidades

Componentes

Los componentes principales de una arquitectura Cliente/Servidor son:

Esquema genérico de arquitectura cliente-servidor.


que requiere un servicio de

No obstante, esta

configuración no es definitiva. Es decir, los ordenadores pueden ser clientes para determinadas

tareas y servidores para otras ya que el objetivo es que cada ordenador realice las funciones

que el servidor se encargue del peso de la



de los módulos, de modo que

incluso en diferentes localidades


- 23 -

• Cliente: también denominado front-end es el proceso que permite al

usuario formular las solicitudes de información. Entre las funciones que

realiza un cliente se encuentran: administrar la interfaz de usuario,

interactuar con el usuario, procesar la lógica de la aplicación y hacer

validaciones locales, generar requerimientos de bases de datos, recibir

resultados del servidor y formatear resultados.

• Servidor: también denominado back-end, es el proceso encargado de

procesar las peticiones que le realizan los diferentes clientes sobre los

recursos que es capaz de administrar. Las funciones que puede realizar

son: aceptar los requerimientos de bases de datos que hacen los clientes,

procesar requerimientos de bases de datos, formatear datos para

trasmitirlos a los clientes y procesar la lógica de la aplicación.

3.2.3. Características

Las características básicas de una arquitectura Cliente/Servidor son:

• Combinación de un cliente que interactúa con el usuario, y un servidor

que interactúa con los recursos compartidos. El proceso del cliente

proporciona la interfaz entre el usuario y el resto del sistema. El proceso

del servidor actúa como un motor de software que maneja recursos

compartidos tales como bases de datos, impresoras, módems, etc.

• Las tareas del cliente y del servidor tienen diferentes requerimientos en

cuanto a recursos del sistema, periféricos necesarios, etc.

• Se establece una relación entre procesos distintos, los cuales pueden ser

ejecutados en la misma máquina o en máquinas diferentes distribuidas a

lo largo de la red.

• Existe una clara distinción de funciones basada en el concepto de

"servicio", que se establece entre clientes y servidores.

• La relación establecida puede ser de muchos a uno. Un servidor puede dar

servicio a muchos clientes, regulando su acceso a recursos compartidos.

• Los clientes corresponden a procesos activos en cuanto a que son éstos

los que hacen peticiones de servicios a los servidores. Estos últimos tienen

un carácter típicamente pasivo ya que esperan las peticiones de los


- 24 -

clientes. No obstante, puede darse el caso de que el servidor actúe como

cliente para un tercer servidor.

• No existe otra relación entre clientes y servidores que no sea la que se

establece a través del intercambio de mensajes entre ambos. El mensaje

es el mecanismo para la petición y entrega de solicitudes de servicio.

• El ambiente es heterogéneo. La plataforma de hardware y el sistema

operativo del cliente y del servidor no son siempre iguales. Precisamente

una de las principales ventajas de esta arquitectura es la posibilidad de

conectar clientes y servidores independientemente de sus plataformas.

• El concepto de escalabilidad tanto horizontal como vertical es aplicable a

cualquier sistema Cliente/Servidor. La escalabilidad horizontal permite

agregar más estaciones de trabajo activas sin afectar significativamente el

rendimiento. La escalabilidad vertical permite mejorar las características

del servidor o agregar múltiples servidores.

3.2.4. Ventajas e inconvenientes

Las principales ventajas del esquema Cliente/Servidor son:

• Una de las causas que más ha promovido el uso de sistemas

Cliente/Servidor es la proliferación de plataformas hardware de bajo

coste. Este hecho origina la principal ventaja de estas arquitecturas.

Realizar sistemas complejos a partir de ordenadores más baratos que los

necesarios para una solución centralizada. Además, gracias a la

independencia entre clientes y servidor, se pueden utilizar distintos

sistemas operativos y distintos elementos hardware, lo que permite crear

sistemas flexibles y escalables a bajo coste.

• Al permitir interconectar máquinas heterogéneas se favorece un sistema

eficiente donde cada módulo puede residir en un equipo de prestaciones

ajustadas a dicho módulo.

• Así mismo, este tipo de sistemas permiten que los ordenadores

tradicionales se interconecten con nuevos sistemas creando

funcionalidades que antes no estaban disponibles.


- 25 -

• Al dividir un sistema complejo en pequeños módulos se facilitan las tareas

de desarrollo. El programador puede abordar un módulo de manera

independiente al resto del sistema. Esto permite que las tareas sobre

dicho módulo no requieran de un análisis del sistema completo.

• La división en módulos permite que el crecimiento del sistema sea

sencillo. Para añadir un nuevo módulo sólo se necesita conocer la interfaz

de comunicación con el servidor. La forma en la que esté implementada el

nuevo módulo no influye en el resto del sistema.

Entre las principales desventajas del esquema Cliente/Servidor se encuentran:

• El mantenimiento de estos sistemas resulta costoso pues se trata de

conjuntos heterogéneos de software y hardware distribuido cuya

depuración resulta costosa.

• Para que los clientes y los servidores puedan comunicarse es importante

que utilicen el mismo mecanismo (por ejemplo sockets o solicitud de

procedimientos remotos o Remote Procedure Call (RPC)). Esto conlleva

una limitación en los sistemas a elegir para implementar los módulos,

pues deben ser compatibles con una implementación de este tipo.

• Además, debido a la posibilidad de que varios clientes actúen sobre los

mismos datos deben existir estrategias para el manejo de llamadas

concurrentes y para mantener la consistencia de datos.

• Es importante tener en cuenta que el correcto funcionamiento del

sistema depende de factores relacionados con las comunicaciones. Estos

factores no aparecen en sistemas tradicionales y pueden ser: congestión

en la red, dificultad de tráfico de datos, etc.

3.2.5. Estructura implementada.

A la vista de las características se ha determinado que la arquitectura Cliente/Servidor

resulta idónea para el objetivo de este proyecto. Como se ha dicho es perfecta para incluir

ordenadores tradicionales en sistemas mayores, que es precisamente el objetivo de este

proyecto.


- 26 -

En la figura se puede apreciar el esquema de comunicaciones de la arquitectura

implementada. Como puede apreciarse el módulo que obtiene información del exterior (interfaz

de entrada) está compuesto por dos unidades software, opencv y robint (reconocedor de voz e

identificador de usuario), que actúan como clientes ya que son procesos que generan cambios

en el sistema a partir de cambios en estímulos de entrada.

Por otro lado, el módulo de aplicaciones está compuesto por unidades de software

específicas para cada tarea, esto es: 3 en raya virtual, 3 en raya físico, control de la luz, control

de roomba, control de infrarrojos y control de conversación. Todas estas tareas son procesos

activos pues analizan los estímulos de entrada que reciben indirectamente del módulo interfaz

de entrada y determinan una respuesta que se traducirá como una solicitud al servidor principal.

Los modelos de comportamiento y de emotividad, este último compuesto por el modelo

de emociones y el de relaciones, están implementados en la unidad de software servidor

principal. Esta unidad es servidor y cliente al mismo tiempo. Por un lado es servidor ya que no

presenta un comportamiento independiente. Es decir, depende de la solicitud de los clientes

para realizar una acción. Los clientes que se conectarán a esta unidad de software serán los

Figura 9. Estructura de cliente-servidor de la implementación


- 27 -

integrantes de los módulos interfaz de entrada y aplicaciones. Por otro lado, es cliente puesto

que los componentes del módulo interfaz de salida son totalmente pasivos, ya que no realizan

ningún tipo de acción por iniciativa propia, siendo el servidor principal el que los activa mediante

la solicitud de servicio.

Finalmente, sólo resta hablar del módulo interfaz de salida. Este módulo está compuesto

por las unidades de software control de cara y sintetizador. Además, hace uso del recurso

externo que genera el audio a partir del texto a sintetizar. Todos estos elementos son servidores

pues requieren de una solicitud por parte del cliente, en este caso el servidor principal, para

realizar cualquiera de las acciones para la que están programados.

Una vez presentada la estructura de comunicaciones es necesario describir el mecanismo

que se ha utilizado para hacer posible esta implementación. Esto es lo que se hará en el

siguiente punto.

3.3. Mecanismo de comunicación: SOAP

Como se ha mencionado anteriormente, la implementación de un modelo

Cliente/Servidor requiere de un mecanismo de comunicación basado o bien en sockets o bien en

RPC. A continuación se describirá cada uno de ellos para, finalmente, explicar la decisión

implementada.

3.3.1. Sockets

Un socket es un mecanismo de bajo nivel por el cual dos programas independientes a

priori son capaces de intercambiar información. Se puede asemejar a un recurso compartido en

el que ambos, tanto programa cliente como servidor, pueden escribir y leer información. Para

que el socket esté correctamente definido es necesario un protocolo de transporte, una

dirección IP y un puerto asociado al socket. De esta forma los programas pueden intercambiar

octetos siempre y cuando ambos sean capaces de localizarse. Con este mecanismo es el

programa cliente el que inicia la conexión permaneciendo el programa servidor a la espera.

Inicialmente se hizo uso de la clase CSocket Node, que proporciona los métodos

necesarios para la comunicación mediante sockets. No obstante, conforme el sistema crece se

hace patente su principal problema. El tipo de información que se puede pasar fácilmente es

muy limitado haciendo necesarios métodos que la analizasen para determinar la tarea a realizar.


- 28 -

Además, presentan problemas relacionados con el sincronismo de los métodos de transmisión y

recepción de datos. El programa que recibe el dato se queda esperando durante un cierto

tiempo o bien indefinidamente según se determine. Los inconvenientes es que si el tiempo de

espera está acotado, el programa puede continuar sin recibir los datos, ignorándolos. Por otro

lado, si el tiempo de espera es indefinido, el programa receptor quedaría bloqueado. Este hecho

en el caso de un servidor que espera una solicitud resulta especialmente relevante.

En resumen, los sockets no son una implementación eficiente para este sistema ya que, al

ser mecanismos de bajo nivel, presentan una gran complejidad a la hora de intercomunicar

distintos módulos. Como alternativa aparecen las RPC.

3.3.2. RPC

El mecanismo de solicitud de procedimientos remotos es una forma de comunicación

entre procesos que permite a un programa ejecutar una función o procedimiento en otro

distinto.

La forma en la que se establece una llamada es la siguiente: Un programa cliente está en

ejecución y en un momento dado necesita realizar una acción que es provista por otro programa

llamado servidor. En ese momento el cliente realiza una llamada al procedimiento enviando los

parámetros que sean necesarios. Si la comunicación es exitosa, el servidor recibirá la solicitud y

comenzará a realizar la funcionalidad solicitada. Mientras el servidor realiza la tarea, el cliente

permanece bloqueado esperando una respuesta. Una vez que el servidor finaliza su acción,

devuelve el resultado de la operación al módulo cliente, que sigue con su ejecución normal.

El principal problema de este mecanismo frente a llamadas a procedimientos locales, es

que la comunicación puede fallar en cualquier momento debido a errores de la red. No

obstante, para funciones idempotentes en las que múltiples llamadas no modifican el resultado,

no presenta demasiadas dificultades.

Hay que señalar que el mecanismo RPC es una definición que precisa ser implementada.

En la actualidad existen dos grandes alternativas XML-RPC y Simple Object Access Protocol

(SOAP).


- 29 -

3.3.2.1. XML-RPC

XML-RPC es una implementación para RPCs que persigue la idea de sencillez. Su objetivo

no es proporcionar una solución específica a cada situación, sino que pretende ser una

implementación genérica que sea extensible a multitud de casos. Utiliza una codificación basada

en el popular lenguaje de descripción XML y el protocolo de comunicación HTTP. Una de las

ideas que generaron esta solución era que un programador de HTML fuese capaz de ver el

código de un mensaje XML-RPC y pudiese entenderlo y modificarlo. A continuación se muestra

un ejemplo de una solicitud y su respuesta.

No obstante, debido a la gran sencillez que busca, presenta una serie de limitaciones:

La forma de llamar a los métodos es mediante methodName que puede contener

identificadores como mayúsculas, minúsculas, números, subrayado, punto, dos puntos y barra.

No obstante, esto presenta dificultades a la hora de pasar objetos como parámetros.

Las estructuras y matrices son anónimas. Es decir, no se identifica el tipo de dato que se

está pasando de modo que la única forma de determinarlos es conociendo el orden en que

deben estar.

<?xml version="1.0"?>

<methodCall> <methodName>examples.getStateName

</methodName>

<params>

<param>

<value><i4>40</i4></value>

</param>

</params>

</methodCall>

Figura 10. Solicitud XML-RPC

<?xml version="1.0"?>

<methodResponse>

<params>

<param>

<value><string>South Dakota</string></value>

</param>

</params>

</methodResponse>

Figura 11. Respuesta

XML-RPC


- 30 -

3.3.2.2. SOAP

Simple Object Access Protocol (SOAP) es una evolución del protocolo XML-RPC. Se sitúa

justo donde XML-RPC presenta sus limitaciones, es decir, permite definir tipos de datos. Esto

provoca que sea algo más complejo que el anterior pero, como contrapartida, ofrece mayor

potencial para el desarrollo de aplicaciones.

Como formato de los mensajes se ha utilizado también XML. Las ventajas de usar este

lenguaje derivan de ser comúnmente utilizado por las empresas así como de los esfuerzos de

desarrollo de código libre. No obstante, también existen inconvenientes al utilizar este tipo de

lenguajes. En concreto, al ser un lenguaje descriptivo exhaustivo que permite la comprensión

tanto de máquinas como de humanos, puede ralentizar la ejecución de los procesos.

Por otro lado, SOAP no está vinculado a ningún protocolo de transporte. Esto ofrece la

posibilidad de trabajar desde Single Mail Transfer Protocol (SMTP) a Hypertext Transfer Protocol

(HTTP) o su versión cifrada HTTPs, entre otros. Sin embargo, es HTTP el que constituye la

implementación más extendida, ya que proporciona una de las principales ventajas de SOAP

frente a otros métodos. Es decir, permite la comunicación a través de cortafuegos y proxies.


- 31 -

A continuación se presenta un ejemplo de solicitud y respuesta mediante SOAP.

Como puede verse, la estructura de los mensajes SOAP es bastante más compleja que los

de XML-RPC. En definitiva, XML-RPC es un protocolo muy sencillo pero que, por su simplicidad,

presenta carencias a la hora de realizar determinadas acciones como pasar un objeto como

parámetro. En contraposición, SOAP aparece como un protocolo de mayor complejidad pero

que da cobertura a las carencias de XML-RPC.

<soapenv:Envelope>

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Body>

<req:echo xmlns:req="http://localhost:8080/axis2/services/MyService/">

<req:category>classifieds</req:category>

</req:echo>

</soapenv:Body>

</soapenv:Envelope>

Figura 12. Solicitud SOAP

<soapenv:Envelope>

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">

<soapenv:Header>

<wsa:ReplyTo>

<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>

</wsa:ReplyTo>

<wsa:From>

<wsa:Address>http://localhost:8080/axis2/services/MyService</wsa:Address>

</wsa:From>

<wsa:MessageID>ECE5B3F187F29D28BC11433905662036</wsa:MessageID>

</soapenv:Header>

<soapenv:Body>

<req:echo xmlns:req="http://localhost:8080/axis2/services/MyService/">

<req:category>classifieds</req:category>

</req:echo>

</soapenv:Body>

</soapenv:Envelope>

Figura 13. Respuesta SOAP


- 32 -

Como conclusión del análisis de ambos métodos se ha adoptado SOAP. De esta forma se

asegura que el sistema pueda seguir creciendo sin problemas respecto al protocolo utilizado. Por

otro lado, las herramientas que generan XML para SOAP constituyen un factor importante en la

decisión final. En este caso se ha utilizado JABON (5), una utilidad para la creación automática

del código SOAP a partir de la implementación en C++ de las funciones.

3.4. Estructura física implementada

Finalmente, con la idea de presentar el sistema completo, se adjunta la figura en la que se

ilustra la estructura física del sistema.

Como puede observarse el sistema hace uso de tres ordenadores diferentes. El motivo de

esta elección es que determinados programas, como son el reconocedor e identificador de

locutor (SERVIVOX) o el sintetizador de voz, que por sus características necesitan grandes

recursos, deben ejecutarse en máquinas independientes.

Figura 14. Estructura física implementada


- 33 -

Se puede observar que el grueso de los procesos discurre en un ordenador central, en

concreto todas las unidades de software del módulo aplicaciones y la unidad servidor principal

que implementa el módulo comportamiento y emotividad. No obstante, la implementación de

todas y cada una de estas unidades incluye el protocolo utilizado, permitiendo que la

distribución física del sistema sea variable en función de la posible variación de requisitos.

Analizando el sistema se aprecia que el ordenador central se comunica con el dispositivo

infrarrojo IRTRANS y con la webcam mediante USB. Además, hay una comunicación con un

microprocesador Motorola Coldfire, en el que reside la versión del 3 en raya física, aparte de dos

de los ordenadores mediante TCP/IP. Finalmente, el ordenador en el que reside la unidad

sintetizadorSoap se comunica por TCP/IP a un equipo del GTH donde reside el sintetizador de

voz con emociones.

Capítulo 4 – Interfaz Persona-Máquina

- 35 -

CCCCAPÍTULO APÍTULO APÍTULO APÍTULO 4444

4 INTERFAZ PERSONA-MÁQUINA

Desde los primeros ordenadores, la forma mediante la cual personas y máquinas se

comunican ha sido objeto de constantes innovaciones y mejoras. Inicialmente se basaban en un

teclado con el cual el usuario podía ejecutar comandos en el equipo. No obstante, esta solución

se antojaba como limitada. De hecho, en el MIT aparece el sistema SketchPad, que soportaba la

manipulación de objetos gráficos mediante un lápiz óptico, permitiendo cogerlos, moverlos y

cambiarles el tamaño utilizando algunas restricciones. Seguidamente se produjo un gran avance

debido a la aparición del ratón como alternativa económica al lápiz óptico. Un sencillo

dispositivo, originalmente compuesto por una bola, que al ser arrastrado desplaza un puntero en

la pantalla del equipo. Gracias a este elemento, los sistemas operativos existentes comenzaron a


- 36 -

evolucionar hacia entornos más amigables para el usuario. Así es como aparecieron las

ventanas, que actualmente constituyen el interfaz gráfico de cuasi cualquier aplicación.

Finalmente, en los últimos años, e impulsado por la evolución tecnológica de los dispositivos, se

están desarrollando nuevas formas de comunicación. Entre ellas destacan:

• Reconocimiento y Síntesis de Voz: La idea de una comunicación verbal con

dispositivos electrónicos ha sido perseguida durante los últimos cuarenta años.

Sin embargo aún ahora, existen limitaciones (6) al diseñar una máquina capaz de

entender un discurso de cualquier usuario en cualquier contexto sobre cualquier

temática. Así mismo, en cuanto a la síntesis de voz, cabe decir que pese a que se

está trabajando en la expresión de emociones y la naturalidad de la síntesis, aún

resulta un poco artificial. No obstante, por las características de la comunicación

verbal, este tipo de interfaces presentan una gran importancia a la hora de crear

sistemas de manejo amigable e intuitivo. Entre los ejemplos comerciales que se

pueden citar como interfaces de voz, el sistema para invidentes de los autobuses

de la EMT utiliza un sintetizador de voz mientras que el reconocimiento de voz se

puede encontrar en móviles, en dispositivos manos libres bluetooth de algunos

automóviles e incluso Microsoft Windows Vista proporciona un reconocedor de

voz. Como ejemplo de síntesis y reconocimiento de voz en el mismo sistema se

puede pensar en el robot guía Urbano.

Figura 15. Robot Urbano


- 37 -

• Tratamiento de imágenes: Mediante técnicas de análisis de imágenes, un sistema

es capaz de detectar movimientos, gestos faciales, formas, colores, etc. De esta

manera se abre camino a la comunicación no verbal entre las personas y las

máquinas. Así, un sistema, de forma no intrusiva, puede controlar la situación

relacionada con un usuario y decidir qué acciones conviene realizar. Un ejemplo

comercial de este tipo de interfaces se encuentra en el Opel Insignia, un automóvil

último modelo en el que se incluye el sistema Opel Eye. Esta tecnología consiste

en una cámara que analiza la información de las señales de tráfico mostrando en

el cuadro de mandos el límite de velocidad de la vía así como la posible

prohibición de adelantamientos.

• Robótica: Aunque la robótica no es un tipo de interfaz propiamente dicho, sí

determina la forma en la que un sistema se relaciona con su entorno. De hecho, el

proveer de brazos robóticos a un sistema permite la interacción física de éste con

su entorno. Así mismo, la creación de caras robóticas o de robots que imiten los

rasgos humanos proporciona una gran variedad de alternativas para la

comunicación no verbal entre el sistema y las personas. Un ejemplo de esto es el

último sistema elaborado por el MIT, NEXI. Un robot capaz de imitar las

expresiones emocionales de los humanos.

Figura 16. Opel Eye

• Pantallas táctiles:

conductores transparentes que, en función de en qué parte de la pantalla se está

produciendo presión, generan un valor de resistencia que permite determinar el

punto de contacto. Este ti

los últimos años. De hecho

esta interfaz en teléfonos móviles. Además, también se utiliza en videoconsolas

como Nintendo DS o, de forma incipient

tener una orientación a estación multimedia facilitando el uso de tareas como

escuchar música, ver fotos, etc.

Ante la aparición de este tipo de alternativas se plantea la idea de utilizarlas en un sistema

que permita controlar los dispositivos tradicionales que están en un hogar de una forma sencilla


- 38 -

táctiles: Las pantallas táctiles más comunes consisten en un par de


uciendo presión, generan un valor de resistencia que permite determinar el

punto de contacto. Este tipo de interfaces está teniendo un auge

los últimos años. De hecho, desde la aparición del Iphone, la tendencia es incluir


como Nintendo DS o, de forma incipiente, en equipos de escritorio que pretenden


escuchar música, ver fotos, etc.



Figura 17. NEXI (Robot emocional del MIT)

Figura 18. Dispositivos con pantalla táctil.


consisten en un par de


uciendo presión, generan un valor de resistencia que permite determinar el

stá teniendo un auge considerable en

desde la aparición del Iphone, la tendencia es incluir


e, en equipos de escritorio que pretenden




Dispositivos con pantalla táctil.


- 39 -

e intuitiva. Es decir, en lugar de pulsar un botón para encender una luz, el usuario debería

interactuar de una forma más parecida a como lo haría con otra persona. Esto puede ser

mediante una orden verbal.

Por otro lado, en pro de conseguir una sensación de inteligencia del sistema y que el

usuario no necesite seguir unos patrones para interaccionar con él, se plantea el concepto de

crear una interfaz multimodal. Este tipo de interfaces combinan diferentes estímulos de entrada

del usuario así como varios modos de salida de información. La ventaja de simultanearlos radica

en que las deficiencias de un tipo de interfaz se ven cubiertas por otros de modo que el sistema

general resulta más robusto. Además se incrementa su usabilidad ya que, por ejemplo en

dispositivos móviles en los que teclear una palabra resulta más o menos complicado, si se

añadiese reconocimiento de voz se simplificaría el uso haciéndolo más atractivo. Por último se

potencia la accesibilidad de los sistemas. Al implementar diferentes alternativas para la

comunicación persona-máquina, los usuarios que padezcan algún tipo de discapacidad pueden

relacionarse de maneras alternativas. Por ejemplo, un discapacitado físico podría interaccionar

mediante habla.

Las interfaces que han sido combinadas en este sistema son: Verbal, que combina síntesis,

reconocimiento e identificación; Visual, que incluye el tratamiento de imágenes como entrada

de datos y la presentación por pantalla como salida; y Física, compuesta de una cara robótica

para la representación del estado del sistema, un brazo robótico para una interacción más

natural con el entorno y un sensor infrarrojos para detectar la proximidad del usuario. A

continuación se entrará en detalle sobre cada una de ellas.

4.1. Interfaz Verbal

Constituye la principal interfaz de este sistema. Incluye el reconocimiento de voz, la

síntesis de voz y la identificación de usuario. Cada una de estas aplicaciones presenta grandes

ventajas. A continuación se expresan algunas de las justificaciones que llevan a incluirlas en el

proyecto.

Pensando en que el usuario no tenga que aprender a comunicarse con el sistema aparece

la idea de utilizar la voz. De hecho, la voz es una de las interfaces más intuitivas que existen ya

que, una vez que se aprende a hablar, constituye la principal forma de comunicación de la


- 40 -

mayoría de las personas. En este sentido, a la hora de reconocer frases, si se crea una base de

datos de tamaño y libertad de reconocimiento suficientes, el usuario no tendrá que aprender

ningún comando, ya que lo que solicitará lo hará de manera intuitiva. Por ejemplo, en el caso de

encender una luz, podrá decir: “enciende la luz” o “pon la luz” o frases similares que no son

distintas a lo que le diría a otra persona.

Así mismo, existen ventajas que son aplicables en el otro sentido de la comunicación, es

decir, la comunicación máquina-usuario mediante síntesis de voz. Estas ventajas están

relacionadas con el hecho de que el usuario no tiene que prestar una atención especial a la hora

de recibir información por parte del sistema, el proceso transcurre de forma similar a una

conversación entre personas. Esto es, el sistema sintetiza algún tipo de mensaje que expresa en

un lenguaje verbal cercano a las personas. Por ejemplo, si el sistema no desea que se le insulte

podría decir algo como “no me gusta que me insultes”.

De forma análoga, la identificación de usuarios mediante voz presenta ventajas como no

requerir contraseñas ni proceso de verificación explícito. Es decir, no se basa en una información

que el usuario recuerde (contraseña y nombre de usuario) ni en algo que se posee (tarjeta

magnética, RFID u otra alternativa) sino que se basa en las características de la voz de cada

persona y por tanto resulta más transparente para el usuario además de más cercano al

comportamiento de una persona que es capaz de identificar a otra por su cara, voz, ojos, etc.

En resumen, todas estas ventajas conducen a que la interfaz verbal constituya la principal

forma de comunicación del sistema. Por un lado, facilita el proceso de intercambio de

información. Por el otro, contribuye a conseguir sistemas que sean más amigables, de modo que

la aceptación por parte de los usuarios aumenta considerablemente.

Finalmente, es necesario mencionar que para la creación de esta interfaz ha sido

fundamental el trabajo que se está realizando en el Grupo de Tecnología del Habla relacionado

con reconocimiento de voz, síntesis de voz e identificación de usuarios. A continuación se

profundizará sobre cada campo.


- 41 -

4.1.1. Estado del arte

4.1.1.1. Reconocimiento de voz

Antes de nada es conveniente repasar el concepto de reconocimiento de voz. El módulo

reconocedor de voz tiene como objetivo convertir una secuencia de palabras emitidas por un

usuario en una secuencia textual que sea lo más fiel posible a aquella. Para lograr esto deberá

analizar la secuencia acústica en busca de las unidades de información que se desean obtener. El

conjunto de unidades de información sobre el cual el reconocedor compara las tramas acústicas

se denomina vocabulario del mismo (7).

El sistema de reconocimiento de voz utilizado en este proyecto ha sido heredado del

proyecto de Nuria Pérez Magariños. Este proyecto tenía como objetivo la mejora de una interfaz

basada en reconocimiento de voz y, por tanto, resulta una lectura obligada para el lector

interesado.

Los reconocedores de voz se pueden clasificar según diferentes criterios (8):

- Según el objetivo último del reconocimiento existen:

• Reconocedores de habla: Lo más importante es conseguir la secuencia de

palabras que se ha dicho.

• Reconocedores de locutor: Lo que interesa es averiguar la identidad del

hablante.

• Reconocedores de idioma: El objetivo es identificar el idioma en el que se está

hablando.

• Reconocedores de emoción: El objetivo es determinar el estado emocional del

locutor.

- Según el tamaño del vocabulario, las prestaciones y complejidad del sistema

varían:

• Pequeños: Son capaces de reconocer los dígitos del 0 al 9, si, no…

• Medianos: Vocabularios cuyo máximo es 1000 palabras.

• Grandes: Vocabularios con más de 1000 palabras.

• Muy Grandes: Vocabularios con más de 10000 palabras.


- 42 -

- Según el tipo de reconocimiento:

• Habla aislada: Basados en órdenes simples y sin pausas.

• Habla continua: Permiten reconstruir un mensaje emitido por un locutor en

condiciones normales incluyendo pausas, dudas o símbolos que se encuentren

fuera del vocabulario.

El modelo genérico de un sistema de reconocimiento de voz es el siguiente:

Lo módulos más significativos de este sistema son:

- El Detector: Extrae de la señal digital un conjunto de características (features) que

serán empleados por el subsistema reconocedor.

- El Reconocedor: Mediante los vectores de características obtenidos por el

detector y empleando tanto los modelos acústicos como los modelos de lenguaje,

Figura 19. Diagrama de bloques de un reconocedor obtenido de (7)

Figura 20. Arquitectura básica de un sistema reconocedor obtenido de (9)


- 43 -

genera la secuencia de palabras que más se asemeje a dichos vectores de

características. El reconocedor también puede proporcionar la información

necesaria para llevar a cabo una adaptación de los modelos anteriormente

mencionados para mejorar los resultados obtenidos.

4.1.1.1.1. Métodos de reconocimiento

En líneas generales, se puede decir que han existido dos aproximaciones al

reconocimiento del habla:

• Aproximación fonético-acústica: Estaba basada en la teoría de la fonética acústica,

según la cual, existe un número finito y diferenciable de unidades fonéticas en el

lenguaje hablado que están caracterizadas, en términos generales, por una serie

de propiedades que se manifiestan en la señal de voz o en su espectro. Aunque,

las propiedades acústicas de estas unidades fonéticas son muy variables debido

principalmente a los locutores y a las unidades fonéticas vecinas, se asume que las

reglas que gobiernan esa variabilidad son sencillas y que pueden ser rápidamente

aprendidas y aplicadas en situaciones prácticas.

• Aproximación de reconocimiento de patrones: Este método tiene dos pasos, el

entrenamiento de los patrones y el reconocimiento mediante la comparación de

patrones. El “conocimiento” sobre el habla se introduce en el sistema mediante

un proceso de entrenamiento. La idea es que si se dispone de un número

suficiente de versiones diferentes del patrón que se desea reconocer en el

conjunto de datos de entrenamiento que se proporciona al algoritmo de

reconocimiento, el proceso de entrenamiento debe ser capaz de caracterizar

adecuadamente las propiedades acústicas del patrón, que quedan reflejadas en el

modelo acústico que es un modelo oculto de Markov. La utilidad del método está

en el paso de comparación de patrones, que realiza una comparación directa

entre la voz que debe reconocerse (habla desconocida) con cada uno de los

posibles patrones que ha aprendido en la fase de entrenamiento y clasifica el

habla desconocida en función de lo bien que encaja con los patrones.


- 44 -

4.1.1.1.1.1. Reconocimiento de patrones

En líneas generales se puede decir que un reconocedor basa su funcionamiento en dos

eventos bien diferenciados: la segmentación y el reconocimiento.

La mayoría de los reconocedores actuales optan por utilizar un esquema estocástico

basado en representar la secuencia acústica mediante modelos ocultos de Markov (HMM,

Hidden Markov Models), así como técnicas de reconocimiento de patrones y algoritmos

avanzados basados en la teoría de programación dinámica para resolver ambos problemas de

manera integrada.

A lo largo de los años, el desarrollo de las tecnologías y algoritmos de reconocimiento ha

dado lugar, como consecuencia, a un incremento de la complejidad de las tareas que debe llevar

a cabo el reconocedor de habla. Para tratar de dividir esta complejidad, es habitual dividir el

trabajo del mismo en dos fases, aplicando diferentes modelos en cada una de ellas para obtener

un mejor resultado global.

El reconocedor del GTH que se ha empleado en la realización de este Proyecto presenta

este tipo de funcionamiento. En un primer proceso, denominado one pass, se aplica como

modelo acústico un HMM por cada trifonema y como modelo lingüístico uno basado en

bigramas. Una vez efectuado el reconocimiento y asignada una puntuación o score a cada una

de las palabras reconocidas, se pasa a un segundo bloque conocido como etapa de rescoring, en

la cual se utiliza el modelo acústico de la etapa previa y se varía el modelo lingüístico a uno

basado en trigramas, aprovechando que este modelo contiene mayor información.

Figura 21. Esquema de un reconocedor de dos etapas, obtenido de (7)


- 45 -

La información entre ambas etapas no se limita a los parámetros acústicos sino que puede

reutilizar una mayor información del one pass para simplificar el trabajo del rescoring.

Los elementos que intervienen en este reconocedor son:

• Confianza: Se entiende como medida de confianza la puntuación que le asigna el

reconocedor a cada una de las decisiones que toma, constituyendo de esta forma

un sistema de medida de lo bien o lo mal que el propio reconocedor asume que

está realizando su tarea. La confianza suele medirse en dos niveles diferentes:

palabra (corrección con que el sistema asigna a cada una de las palabras que

reconoce, sólo válido en palabras que hayan sido reconocidas) y frase (corrección

de la frase en conjunto, compara la frase obtenida con la original de modo que sí

se tiene en cuenta el borrado de palabras).

• Modelos acústicos: Los modelos acústicos se construyen a partir de Modelos

ocultos de Markov de los trifonemas. Los alófonos aislados se tratan como HMM,

con el objetivo de tener en cuenta la variabilidad que introducen los alófonos

adyacentes en la pronunciación de cada alófono.

• Modelos lingüísticos: El conocimiento léxico, es decir, la definición del vocabulario

y la pronunciación de las palabras son parte esencial de la sintaxis y semántica de

la lengua y, como tales, definen reglas que determinan qué secuencias de

palabras son gramaticalmente correctas y dan lugar a un discurso comprensible.

En los reconocedores automáticos suelen emplearse modelos estocásticos del

lenguaje, que modelan las características del idioma desde un punto de vista

probabilístico. La clave de estos modelos consiste en proporcionar la información

probabilística adecuada, de manera que las secuencias de palabras más comunes

tengan mayor probabilidad. Esto no sólo mejora el resultado del reconocimiento,

sino que contribuye a restringir el espacio de búsqueda del reconocedor,

aumentando la rapidez del sistema.

• Grafos: El trabajo de reconocimiento se puede asimilar como un problema de

búsqueda y los grafos son una de las herramientas más potentes para resolver

este tipo de problemas. Permiten evaluar diferentes alternativas de actuación en


- 46 -

base a una determinada función de coste, que asocia un valor a cada uno de los

caminos que recorren el grafo. Todo grafo consta de un conjunto de nodos y una

serie de uniones entre ellos. Si el grafo es dirigido, dichas uniones reciben el

nombre de flechas y son unidireccionales. En función del problema considerado,

los nodos y las flechas constituirán sistemas de almacenamiento de información.

(7)

4.1.1.1.2. Variabilidad de la señal de voz

Aunque en la actualidad pueden construirse reconocedores muy precisos para un

determinado locutor, con un lenguaje determinado y un estilo de hablar particular, en un

entorno conocido y para una tarea concreta, todavía no somos capaces de crear un reconocedor

que entienda a cualquier locutor, independientemente del entorno, el lenguaje o la tarea (9).

Es por esto que la precisión y la robustez son las últimas medidas a tener en cuenta para

un resultado exitoso de los algoritmos de reconocimiento. Hay varias razones por las que los

algoritmos o sistemas actuales no dan los resultados esperados por los usuarios. A continuación

se describen algunos de ellos.

• Variaciones en el contexto: La interacción hablada entre las personas requiere un

conocimiento del significado de las palabras y del contexto en el que son dichas.

Palabras con significados muy diferentes pueden tener la misma pronunciación

como, por ejemplo, vaca y baca. También existe el caso de que varias palabras

tengan igual pronunciación pero, sin embargo, presenten un significado diferente,

por ejemplo, “toma té verde” o “tomate verde”. Además de estos contextos de

frase o de palabra existe un nivel de contexto de fonema que es apreciado, sobre

todo en habla rápida, donde muchos fonemas no llegan siquiera a pronunciarse.

• Variaciones en el estilo: En el reconocimiento de habla continua, la tasa de error

para el habla espontánea que puede surgir en cualquier conversación diaria es

mucho mayor que para un discurso cuidadosamente articulado y leído en voz alta.

La tasa de habla también afecta a la tasa de reconocimiento de palabras.

Generalmente, cuanto mayor es la tasa de habla (palabras/minuto) mayor es la

tasa de error. Además, si una persona susurra o grita para reflejar sus estados

emocionales, la variación se incrementa más significativamente. Pueden


- 47 -

proponerse soluciones del orden de imponer habla aislada que reduce

significativamente la complejidad del reconocedor, no obstante, esta forma de

habla no resulta natural para las personas.

• Variaciones en el locutor: Cada individuo habla de una forma diferente. La forma

que la que una persona habla es el reflejo de una serie de características físicas,

edad, sexo, dialecto, salud y educación. De esta manera, los patrones de habla de

una persona pueden ser totalmente diferentes de los de otra. Incluso si se

eliminan las diferencias debidas a locutores diferentes, un mismo locutor a

menudo es incapaz de reproducir exactamente los mismos sonidos. Como

solución aparecen sistemas dependientes de locutor en los que se recogen

muestras suficientes para poder generar un modelo que permite el

reconocimiento exitoso del habla de dicho usuario. Este tipo de sistemas

presentan muchas ventajas frente a los independientes, por ejemplo, al estar

optimizado para un locutor concreto, el proceso de reconocimientos se realiza de

forma más rápida. No obstante, presentan un inconveniente, requieren un

proceso de aprendizaje suficiente que en ocasiones no es factible de ser realizado,

por ejemplo, un sistema de operador de telefonía automático no puede generar

un modelo del locutor.

• Variaciones en el entorno: El mundo está lleno de sonidos de distinta intensidad

procedente de diversas fuentes. Si además se utiliza un reconocedor integrado en

dispositivos móviles, los ruidos debidos al espectro varían más, ya que se puede

estar en movimiento. Además existen ruidos causados por el locutor como

extraléxicos emitidos cuando se está dudando o ruidos causados por la electrónica

del reconocedor (micrófono, conversos A/D). Existen soluciones análogas a las

variaciones en el locutor, es decir, con un número suficiente de entornos ruidosos,

entrenar un reconocedor que sea capaz de optimizar el proceso en cada entorno.

No obstante, las variaciones en el entorno constituyen uno de los principales retos

del reconocimiento.


- 48 -

4.1.1.1.3. Prestaciones

En la actualidad no existen reconocedores perfectos, todos cometerán un cierto error a la

hora de transcribir los mensajes acústicos que reciben. Algunos de los motivos que llevan a este

reconocimiento erróneo pueden ser el entorno en que se obtiene la señal de voz (puede ser más

o menos ruidoso) o la ausencia de referencias en el vocabulario (out of vocabulary) (7).

La calidad de un reconocedor se puede medir evaluando cada una de las palabras que

constituyen la frase. Esto se hace así debido a la forma en la que se desarrolla el alineamiento y

la confrontación de la frase reconocida con la transcripción escrita de la secuencia acústica de

entrada, recogida en una base de datos de entrenamiento. De esta manera, al confrontar dos

frases pueden darse los siguientes casos:

- Acierto: La palabra reconocida coincide con la original. - Sustitución: La palabra reconocida no coincide con la original sino con otra. - Borrado: El reconocedor no ha reconocido una palabra que sí se encontraba en la

frase original. - Inserción: El sistema introduce una palabra que no se encontraba en la frase original.

A partir de estos valores se definen una serie de porcentajes que proporcionan información

sobre la calidad del reconocedor:

- %aciertos = 100⋅hipótesisladelongitud

aciertosdenúmero

- %sustituciones = 100⋅hipótesisladelongitud

nessustituciodenúmero

- %borrados = 100⋅hipótesisladelongitud

borradosdenúmero

- % inserciones = 100⋅hipótesisladelongitud

sinsercionedenúmero

Realmente las tres primeras tasas constituyen el 100%, dado que el índice por el cual se

normalizan es la longitud en palabras de la hipótesis y en esta no tiene sentido definir las

inserciones, puesto que una inserción es un palabra ajena a la hipótesis que ha introducido el

reconocedor.

La suma de las tres últimas tasas es el porcentaje de error del reconocedor:


- 49 -

%error = %sustituciones + % borrados + % inserciones

El parámetro de mayor utilidad para la medida de las prestaciones de un reconocedor no es

la tasa de palabras correctas, sino la tasa de precisión de palabra o word accuracy (WA) ,

definida como:

WA = 100% - %error = %aciertos - %inserciones

4.1.1.2. Identificación de usuario

Dentro de un sistema de diálogo tienen cabida varios módulos que, sin ser

imprescindibles, pueden producir mejoras muy importantes en el comportamiento del sistema.

Estas mejoras pueden tener un carácter técnico, si, por ejemplo, incrementan las tasas de

reconocimiento, o pueden ser de carácter subjetivo, si producen en el usuario una sensación de

naturalidad y sencillez mucho mayor (10).

El módulo de reconocimiento o identificación del hablante cumple estos dos objetivos. Su

función consiste en identificar al locutor entre un grupo de locutores previamente almacenados,

con la posibilidad de incorporar nuevos locutores a la base de datos.

El uso de este módulo de reconocimiento de locutor se plantea en dos tipos de entornos:

- Entorno seguro: Dentro de un entorno donde la seguridad constituya un factor

importante, la labor de este módulo está dirigida a la verificación de locutores

almacenados, esto es, el sistema debe comprobar si el locutor es quién dice ser. En este

caso la propia voz constituye el password del sistema. Este tipo de aplicación se enmarca

en el conjunto de sistemas de seguridad que utilizan el reconocimiento de parámetros

biométricos para el control de acceso.

- Entorno no seguro: En este caso la labor de este módulo es la identificación de un

locutor entre un conjunto de posibles locutores, o, en caso de que no se pueda asegurar

la identificación, que el locutor sea clasificado como un nuevo locutor. Se observa que, al

contrario que en el caso anterior, el locutor no proporciona información sobre quién

dice ser, y el sistema debe elegir quién considera que es. En un entorno en el que no

existan problemas de seguridad y en el cual la población de usuarios esté limitada es

donde este módulo alcanzaría su mayor rendimiento.


- 50 -

Sin duda, el hogar es un entorno idóneo para aprovechar un sistema de este tipo. Un

sistema de diálogo domótico podría mejorar sus funcionalidades de la siguiente manera: si fuera

capaz de reconocer qué usuario le dirige un mensaje, podría modificar su respuesta o

comportamiento en función del usuario reconocido.

En cualquiera de estos casos, será necesario transformar la información contenida en la

forma de onda en información de tipo digital y con el formato adecuado. De esta forma el

sistema proporcionará una representación de la señal de voz que contiene las características

útiles para una aplicación de identificación.

El funcionamiento del módulo de identificación puede ser descrito grosso modo de la

siguiente manera:

El sistema permanece en espera hasta que detecta que el nivel de señal de audio ha

sobrepasado un umbral (lo que se interpreta como una intervención de un locutor). A partir de

entonces comienza a grabar, hasta que detecta que el nivel de sonido ha descendido por debajo

de un umbral durante el tiempo suficiente (el objetivo de esto es evitar que pequeños silencios

entre palabras se interpreten como el fin de la intervención). Cuando la intervención finaliza la

aplicación deja de grabar, calcula los coeficientes cepstrales necesarios y los almacena para el

módulo de reconocimiento de locutor, que posteriormente utilizará estos datos para

caracterizar la intervención.

Por tanto, el primer proceso que se debe realizar es el procesado de la señal de voz así

como el cálculo y la extracción de las características del habla. Este proceso consiste en un

análisis en frecuencia, utilizando las bandas de la escala Mel para, posteriormente, realizar una

transformación que proporcione los parámetros finales, denominados parámetros cepstrales o

cepstrum.

Por último, el objetivo del módulo es poder clasificar una intervención como

perteneciente a un grupo, dentro de un conjunto posible de grupos. Para ello se utilizará un

clasificador que, tras comparar las características de la intervención con los modelos de voz

disponibles, proporcionará una decisión. El clasificador elegido sigue un algoritmo de decisión

BIC (Bayesian Information Criterion).

El objetivo de este algoritmo consiste en emitir un juicio sobre la verosimilitud que una

intervención guarda con un grupo de intervenciones o cluster, en lengua inglesa. Por cluster se


- 51 -

entiende una o varias intervenciones agrupadas conjuntamente debido a su similitud, y que

constituyen el modelo de un locutor.

Tras aplicar el algoritmo a una pareja formada por una intervención y un grupo de

intervenciones agrupadas en un cluster, se espera recibir un resultado numérico que aporte

información sobre la similitud de dichos elementos. La forma de obtener esa medida

matemática de la similitud será comparar qué situación representa más fielmente los datos:

aquella en la que existe un único modelo gaussiano –procedente del conjunto de intervención y

cluster– o aquella en la que existe un modelo para la intervención y otro diferente para el

cluster. A continuación se muestra el desarrollo que permite decidir entre las dos hipótesis: H1,

la intervención constituye un nuevo modelo; H0, si la intervención pertenece a un modelo

existente.

Cada una de estas hipótesis debe ser comprobada por medio del BIC. Si se parte de un

conjunto de N vectores, denominado � = {��: � = 0, … , � − 1}, que se intenta representar bajo

un modelo M, el BIC es:

(M)·lnN#2

),(ln)(λ−= MXLMBIC

Donde:

L(X,M): Verosimilitud del conjunto de vectores X bajo el modelo M.

λ: Factor de penalización empírico que teóricamente es la unidad, pero será el parámetro

que nos permita ajustar el sistema.

#(M): Número de parámetros libres del modelo que sirve de medida de su complejidad.

El número de parámetros libres para un único modelo gaussiano de matriz de covarianzas

completa, cuyos vectores de características tienen dimensión d, � + �� es, y este valor será

usado como factor de penalización.

Para elegir una hipótesis determinada en primer lugar se hará una aproximación

considerando dos grupos de intervenciones diferentes, X e Y, y posteriormente se identificará X

como la intervención a clasificar e Y como el cluster con el que se quiere comparar la

intervención.


- 52 -

Si los vectores pertenecientes a X son � = {��: � = 0, … , �� − 1} y los vectores

pertenecientes a Y son � = {��: � = 0, … , �� − 1}, la fórmula que proporciona una decisión

entre ambas hipótesis es:

<>

ΣΣΣ∪

1

0

:1

:1

)),(/(·)),(/(

)),(/)((

H

H

NYLNXL

NYXL

YYXX µµµ

Donde se ha empleado la siguiente nomenclatura:

µ, µx, µy: Vectores de medias del modelo conjunto, del modelo para el conjunto X y del

modelo para el conjunto Y, respectivamente.

YX ΣΣΣ ,, : Matrices de covarianzas del modelo conjunto, del modelo para el conjunto X y

del modelo para el conjunto Y, respectivamente.

),( ΣµN : Distribución gaussiana de vector de medias µ y de covarianzas Σ .

Si este cociente es mayor que 1 la verosimilitud del modelo completo es mayor, por tanto,

que la de los modelos por separado. A partir de esta ecuación se puede emplear el BIC, teniendo

en cuenta que las medias pueden verse muy afectadas por pequeñas diferencias en las

condiciones de grabación, por lo que solamente se empleará la información de las matrices de

covarianzas. Finalmente, se obtiene un ratio que servirá de indicador de la similitud del conjunto

X con conjunto Y, y cuyo valor viene dado por la siguiente fórmula:

)ln()2

)1((

2

1lnlnln)( YXYYXXYX NN

dddNNNNratio +++−Σ−Σ−Σ+= λ

Donde:

XN : Número de muestras del conjunto X.

YN : Número de muestras del conjunto Y.

λ : Parámetro o factor empírico a ajustar.

Σ : Matriz de covarianzas completa de la unión del conjunto X y del conjunto Y.


- 53 -

XΣ : Matriz de covarianzas completa del conjunto X.

YΣ : Matriz de covarianzas completa del conjunto Y.

d: Dimensión del vector de características.

Considerando el conjunto X como la intervención que se quiere clasificar, y el conjunto Y

como el cluster con el que se está realizando la comparación estadística, es posible extraer las

siguientes conclusiones: en el caso de que este ratio sea negativo valida la hipótesis H0, es decir,

se decide que la intervención conjuntamente con el cluster constituyen un mejor modelo

gaussiano que los modelos por separado. En caso contrario se valida la hipótesis H1, y la

intervención no se incluye en el cluster.

Por su relevancia cabe destacar el parámetro λ o factor de penalización empírico que

teóricamente es la unidad y cuya modificación permitirá ajustar el sistema. En concreto cuanto

mayor sea este parámetro, más probable será la validación de la hipótesis H0 (un único modelo

gaussiano). Por el contrario, cuanto menor es el valor de dicho parámetro, más posibilidades hay

de que la intervención no sea incluida en el cluster y se genere un nuevo cluster a partir de dicha

intervención. Por tanto, este parámetro servirá para decidir el grado de similitud exigido a una

intervención para poder clasificarla dentro de un cluster: para valores altos, el sistema es poco

estricto, y se generan pocos clusters distintos (en el extremo, el sistema agrupa con facilidad

varios locutores reales en un solo locutor reconocido); para valores bajos, el sistema es estricto y

genera con facilidad gran cantidad de clusters (en el extremo, el sistema separa intervenciones

de un mismo locutor real en varios locutores reconocidos).

4.1.1.3. Síntesis de voz

El sistema de síntesis de voz utilizado es resultado de los trabajos de Roberto Barra

Chicote. (11)

Los sistemas de síntesis de habla tienen como objetivo generar voz a partir de un

determinado texto que se pasa como entrada. A esta voz generada se la denomina voz

sintetizada o, de forma más común, voz artificial. La síntesis de habla ha supuesto un avance

muy importante en el mundo de la tecnología, y especialmente en el desarrollo de sistemas que

necesitan comunicarse con el usuario de manera verbal (11).

El progreso que se ha dado en los sistemas de conversión a voz

sido posible gracias a los avances en teoría lingüística, en el modelo de la caracterización

acústica-fonética de los sonidos, en el modelado matemático para la generación de voz, en el

diseño hardware de los ordenadores.

4.1.1.3.1.

En la actualidad se dispone de una amplia variedad de procedimientos a través de los

cuales se puede generar voz sintetizada. No obstante, todos estos procesos de síntesis de habla

comparten una arquitectura com

bloques se compone de un conjunto de módulos que se encargan de leer el texto de entrada y

analizarlo para determinar la estructura de las frases. El segundo bloque

un conjunto de subsistemas que transforman la información que se obtiene del módulo anterior

en una voz artificial de salida. A estos dos bloques se les denomina comúnmente Módulo de

Procesamiento de Lenguaje Natural

(compuesto por la síntesis prosódica y la síntesis segmental

La siguiente figura muestra la estructura descrita:

A continuación se pasa a describir más ampliamente cada uno de estos


- 54 -

El progreso que se ha dado en los sistemas de conversión a voz (TTS ‘text to speech’


fonética de los sonidos, en el modelado matemático para la generación de voz, en el

diseño hardware de los ordenadores.

Arquitectura general de un sintetizador de habla



comparten una arquitectura común que se puede dividir en dos bloques. El primero de esos


analizarlo para determinar la estructura de las frases. El segundo bloque, por su parte

unto de subsistemas que transforman la información que se obtiene del módulo anterior


de Lenguaje Natural (Natural Language Processing o NLP) y Módulo d

osódica y la síntesis segmental), respectivamente.

La siguiente figura muestra la estructura descrita:

A continuación se pasa a describir más ampliamente cada uno de estos dos bloques.

Figura 22. Esquema de un sintetizador de habla


‘text to speech’) ha


fonética de los sonidos, en el modelado matemático para la generación de voz, en el

tectura general de un sintetizador de habla



ún que se puede dividir en dos bloques. El primero de esos


por su parte, consta de

unto de subsistemas que transforman la información que se obtiene del módulo anterior


) y Módulo de Síntesis

dos bloques.


- 55 -

4.1.1.3.1.1. Procesamiento de Lenguaje Natural (NLP)

En esta parte de la síntesis de habla se realiza una descripción fonética del texto de

entrada que se refiere a los fonemas que aparecen cuando las palabras del texto son

pronunciadas.

El bloque de Procesamiento de Lenguaje Natural consta a su vez de dos módulos:

• Analizador de Texto: Tiene la función de tomar como entrada cualquier texto y

darle el formato adecuado para ser entendido por el siguiente módulo (el

Convertidor de Texto a Fonemas). Se encargará del tratamiento de abreviaturas,

números, etc. que pudieran formar parte del texto de entrada, generando a

partir de ellos las cadenas de letras que se deban pronunciar al leer dicho

número o abreviatura. También tiene como tarea procesar los signos de

puntuación para la extracción de la información relacionada con ellos como

puede ser la asignación de pausas entre frases.

• Convertidor de Texto a Fonemas: Una vez que el analizador ha convertido el

texto de entrada en una serie de palabras que este módulo puede manejar, se

procede a realizar la trascripción fonética del texto, que consiste en la extracción

de los fonemas que componen cada una de las palabras.

4.1.1.3.1.2. Proceso de Síntesis

En este segundo módulo la información que se obtuvo a la salida del Procesador de Texto

Natural es transformada en habla. Es aquí donde se produce la voz sintetizada o artificial.

En un primer paso el Generador Prosódico se encarga de asignar a cada uno de los

fonemas procedentes del NLP la duración y entonación adecuadas, ya que el habla presenta

cambios en la frecuencia fundamental, la amplitud o las duraciones de los fonemas. Estos

cambios dependen del sentido, el énfasis o la emoción de la que se le quiera dotar a cada

palabra o a la sentencia completa.

Posteriormente será el módulo de síntesis segmental el encargado de producir la voz a

partir de los fonemas etiquetados por el generador de prosodia. Los métodos utilizados para


- 56 -

sintetizar habla han cambiado mucho desde los primeros sistemas, que utilizaban dispositivos

eléctricos y mecánicos resonantes, hasta los sintetizadores modernos, que emplean

ordenadores. Actualmente existen varios métodos a través de los cuales se puede construir voz

artificial. Estos métodos se clasifican en dos:

•••• Síntesis Segmental basada en conocimiento: De naturaleza más tradicional, dentro de

estos sistemas de síntesis se encuentran:

- Sintetizadores articulatorios: En este tipo de sintetizadores se realiza una analogía

entre los parámetros relativos a los órganos articulatorios y sus movimientos, y los

parámetros circuitales, pero, por el contrario, son muy difíciles de desarrollar.

Además resulta muy complicado controlar automáticamente algunos de los

parámetros que utilizan este tipo de sintetizadores tales como el tamaño de la

cavidad oral, de la tráquea o la posición de la lengua.

- Sintetizadores por formantes: Estos sintetizadores generan la voz mediante la

variación de distintos parámetros que aplican a señales armónicas. Están formados

por una serie de filtros que modelan el tracto vocal, siendo estos filtros excitados

por una fuente que simula las cuerdas vocales. Este tipo de sintetizadores presentan

la ventaja de que son muy flexibles.

- Sintetizadores por concatenación de forma de onda: Concatenan unidades

pregrabadas para generar nuevas frases, con lo que se intenta aumentar la calidad

de la señal generada minimizando el ruido de codificación. La complejidad es alta,

pero la calidad obtenida es muy buena, especialmente cuando se dispone de una

cierta cantidad de unidades que se van seleccionando adecuadamente. Entre los

diferentes tipos de síntesis por concatenación se encuentran: la concatenación de

fonemas, de semifonemas, de difonemas, de sílabas, de palabras y de unidades de

longitud variable.

- Sintetizadores derivados de las técnicas de predicción lineal (LPC): Son

sintetizadores de análisis-síntesis en los que los parámetros que controlan la función

de transferencia del filtro que simula el tracto vocal, son parámetros LPC. Se basan

en la posibilidad de modelar el tracto vocal como un filtro todo polos variante en el


- 57 -

tiempo. Físicamente esto equivale a una serie de cilindros huecos de diámetro

variable. Las propiedades de la onda sonora, después de haber pasado por todos

ellos, puede predecirse teniendo en cuenta que cada uno de los cilindros condiciona

la forma de la onda al entrar en el siguiente.

•••• Síntesis Segmental basada en corpus: Estos sistemas se basan en una gran base de

datos para, a partir de ella generar la voz. Existen dos tipos:

- Sintetizadores basados en selección de unidades: Estos sistemas son la evolución de

los basados en concatenación de onda. Su aparición viene asociada a las, cada vez,

mayores prestaciones que presentan los sistemas informáticos. De hecho, la idea de

estos sintetizadores es disponer de un conjunto de grabaciones suficientemente

grande como para que una misma unidad puede ser seleccionada de entre muchas

alternativas. De esta forma se simplifica el problema de ajustar las grabaciones a la

situación, bastará con un análisis para escoger cuál es la unidad óptima. Eliminando

etapas de proceso de señal necesaria en la síntesis por concatenación básica.

- Sintetizadores basados en modelos ocultos de Markov (HMM): Este es uno de los

nuevos métodos utilizados en síntesis de habla. Es un modelo estadístico que puede

ser usado para caracterizar los parámetros del habla obtenidos a partir de una base

de datos de locuciones y, posteriormente, generar los parámetros correspondientes

al texto de entrada para crear la forma de onda de la voz artificial. Este tipo de

modelos son capaces de producir habla con diferentes características, tanto

diferencias de locutor, como expresión emocional, de una manera flexible. Otra de

las ventajas de este método es que requiere poca memoria en comparación a otras

alternativas. No obstante, uno de los mayores problemas que afectan a este tipo de

sintetizadores es que su naturalidad se ve disminuida en comparación con los

sistemas basados en selección. Sin embargo el trabajo sobre este tipo de

sintetizadores está siendo prioritario a la hora de investigar sobre síntesis lo que los

posiciona como una alternativa muy interesante (12).

A continuación se analizará más en detalle la síntesis basada en corpus, pues es el método

que se ha incluido en este sistema.


- 58 -

4.1.1.3.2. Creación del Corpus

Como se ha dicho, estos sistemas se basan en un conjunto de grabaciones de un locutor

determinado, esto es lo que se denomina corpus. Para generar el corpus se hace empleo de un

sistema de reconocimiento que sea capaz de extraer las unidades lingüísticas determinadas de

las grabaciones realizadas.

Es importante notar que la calidad del sintetizador es dependiente de las características

del corpus. En este sentido sería ideal disponer de una base de datos suficientemente grande

como para proporcionar multitud de ejemplos de la misma unidad lingüística en diferentes

contextos. No obstante, la generación del corpus es un proceso laborioso que requiere del

empleo de una persona que haga las veces de locutor. En este sentido es necesario que dicha

persona no sufra alteraciones en su voz durante el proceso de grabación (por ejemplo

constiparse). Además, por cuestiones de tiempo, no es posible realizar más que un conjunto

determinado de grabaciones por lo que el texto a grabar será un factor determinante en la

generación del corpus. Con esta finalidad sería ideal grabar varios textos de naturaleza diferente,

por ejemplo, el Ingenioso Hidalgo Don Quijote de la Mancha, una revista científica, un

periódico... No obstante, vuelve a presentarse el problema de la necesidad de acortar el proceso

de grabación. En este sentido se emplea el criterio de diseño Greedy.

Este criterio busca elegir un conjunto de frases o párrafos de un texto que en su conjunto

posean características similares a las del texto íntegro. Es decir, si se tuviera un texto de 10.000

frases para ser caracterizado con solamente 10 de ellas, la solución, por búsqueda exhaustiva,

consistiría en analizar todas las combinaciones de frases, tomadas de 10 en 10, para ver cuál se

asemejaría más al texto íntegro. Esta solución, en un caso real de millones de frases, resulta

inviable. Ante esto el criterio Greedy establece un método iterativo subóptimo, va eligiendo las

frases de una en una intentando que, cada vez, se escoja la frase que más acerque el resultado al

texto completo. Por ejemplo, si el texto tiene un alto porcentaje de letras ‘a’, el sistema buscará

frases con alto porcentaje de dicha letra. La elección es subóptima porque elegir la frase óptima

en cada paso no garantiza la elección del conjunto de frases óptimo.

4.1.1.3.3. Elección de unidades que concatenar

El tipo de unidad a extraer es un parámetro crítico para conseguir una buena calidad en la

voz sintetizada: hay que llegar a un compromiso entre la mejor calidad segmental posible (a


- 59 -

mayor longitud de los segmentos, menos puntos de concatenación y por lo tanto mayor calidad)

y la cantidad de memoria necesaria para almacenar las unidades pregrabadas.

Los efectos coarticulatorios tienden a minimizarse en el centro acústico de un fonema, lo

cual llevó a Peterson a proponer el difonema (trozo de voz que va desde la mitad de un fonema

a la mitad del siguiente fonema) como la unidad más satisfactoria para la concatenación.

En castellano, donde se pueden considerar que existen unos 30 alófonos, el número

máximo de difonemas sería de 302=900 (que muestreados a 16 KHz y 16 bits ocuparían unos 5

Mbytes), pero no todos se utilizan. Por otro lado, puede ser necesaria la inclusión de trifonemas,

que son una extensión a agrupaciones de tres fonemas cuando los efectos de coarticulación son

tan grandes que no es posible la segmentación en difonemas (por ejemplo, oclusiva + ’r’ + vocal).

4.1.1.3.4. Marcado de las unidades

Una vez obtenida la grabación, queda por realizar la tarea fundamental de identificación o

marcación de los fonemas que componen la grabación. Esta tarea solía realizarse de forma

manual, aunque en los últimos años se han empezado a aplicar técnicas de reconocimiento de

habla para marcar automáticamente las frases, palabras o logatomos grabados, sobre todo en

síntesis HMM o en síntesis por selección de unidades, dado el tamaño del corpus.

4.1.1.3.5. Síntesis por Selección de unidades:

Este mecanismo se basa en la memoria y consiste en “copiar y pegar”, parte de la idea de

que, a partir del corpus, es posible sintetizar satisfactoriamente cualquier frase mediante la

inclusión de las unidades pregrabadas. Para ello se utiliza el algoritmo de Viterbi, que busca la

minimización del coste total asociado a la selección de una unidad u otra:

Figura 23. Proceso de síntesis mediante selección de unidades tomado de (50).


- 60 -

Target Cost:

Concatenation Cost:

Total Cost:

- Target Cost es el coste asociado a elegir una unidad de entre las disponibles,

teniendo en cuenta que ésta no presenta exactamente las mismas características

que la que se desea. Por ejemplo, se necesita una ‘a’ de 10 ms y se tiene una de 12,5

ms.

- Concatenation Cost es el coste asociado a la disparidad entre la unidad seleccionada

y los vecinos.

- Total Cost es el coste total de elegir una unidad determinada, resulta de la suma de

los dos anteriores.

Es importante mencionar que cada uno de los costes está ponderado por el parámetro wj.

Las ventajas de este sistema son:

- Gran calidad media y máxima.

- Voz muy similar a la original; esto permite generar emociones siempre y cuando se

disponga de un corpus con emociones. Es decir, no se puede generar nada que no

haya sido grabado.

Los problemas asociados a éste método son:

- Irregularidad: es bastante sensible a imprecisiones de segmentación y puede

presentar, ocasionalmente, artefactos de síntesis muy graves, por lo que a veces

no es inteligible, de modo que, pese a tener una gran calidad media, presenta

mínimos muy pobres.

- Difícil de modular: Como se ha dicho, este método parte del concepto “cortar y

pegar”, por lo que modificar los aspectos del habla de un determinado locutor

resulta muy complejo, es preferible disponer de un corpus con los estilos y

emociones que se quieran utilizar.

- Necesidad de horas de grabaciones: Debido a la necesidad de un corpus

especialmente completo, es necesaria una importante cantidad de horas para su

creación.

∑ ⋅= ),(),( iitj

tjii

t utCwutC

∑ −− ⋅= ),(),( 11 iicj

cjii

c uuCwuuC

∑∑ −+= ),(),(),( 1:1:1 iicjii

tjnn uuCutCutC


- 61 -

4.1.1.3.6. Síntesis por HMM.

Este método se basa en el aprendizaje. Para realizar la síntesis de cualquier frase se

necesita tener correctamente caracterizado el corpus. El proceso de síntesis se comienza por un

análisis del texto con el fin de generar un conjunto de características asociadas al tracto vocal, a

la excitación de la garganta, a las aceleraciones y a las derivadas. Posteriormente, se realizará la

síntesis propiamente dicha, que consta de dos etapas:

Se utiliza la unidad pentafonema, que contempla una unidad en el contexto de las dos

unidades precedentes y las dos posteriores a ella. Este modelo proporciona un desarrollo

matemático que permite optimizar el compromiso entre el valor medio de la unidad y la

desviación necesaria para suavizar las transiciones, mediante un sistema de ecuaciones lineales

que dependen de la matriz de covarianza y del vector de medias de los modelos.

Las ventajas de este sistema son:

- Robustez: presenta buena calidad media y mínima por lo que, pese a que no tiene

los grandes picos de calidad de la selección de unidades, es menos sensible a

imprecisiones de segmentación fonética y, además, no hay artefactos ocasionales

graves, por lo que, a diferencia de la selección de unidades, siempre es inteligible.

- Optimización matemáticamente bien definida: El análisis que permite generar la

unidad de forma óptima consiste en un conjunto de ecuaciones lineales.

- Modelado independiente: tracto, excitación y duraciones.

Figura 24. Proceso de síntesis mediante HMM tomado de (50).


- 62 -

- Es fácil de modular para generar emociones y estilos empleando técnicas como:

• adaptación supervisada (MAP, MLLR).

• interpolación.

• extrapolación.

No obstante, también presenta algunos problemas:

- Sobre-suavizado: Si se tiende a suavizar en exceso las unidades, la voz resultará

menos similar a la original. No obstante esto tiene un efecto positivo, minimiza el

número de artefactos.

- Modelado de excitación mejorable, suele ser bastante simple.

- Necesidad de horas de grabaciones: Este sistema también requiere de un corpus con

la inversión en tiempo que ello requiere. No obstante resulta escalable puesto que

tiene una gran capacidad de generalización.

4.1.1.3.7. Comparación de los métodos de síntesis

Al analizar las distintas técnicas disponibles para la síntesis de habla, se observa cómo, en

igualdad de condiciones los sintetizadores por selección de unidades son los que presentan

mejores resultados en lo que a calidad de voz sintetizada y grado de naturalidad se refiere. Sin

embargo, los sintetizadores por HMM presentan una importante ventaja frente a éstos, y es que

permiten la manipulación de las características de la voz, lo cual resulta de gran importancia

para la síntesis de emociones, puesto que las características de la fuente de voz así como del

tracto vocal pueden cambiar de una emoción a otra. En la síntesis por selección de unidades, por

el contrario, la fuente de voz es única ya que corresponde a fonemas pregrabados por un

locutor. Además ese locutor debe ser capaz de controlar y mantener constante la calidad del

habla para evitar cambios repentinos en la voz sintetizada en medio de sílabas.

En cuanto a qué método es mejor para la expresión emocional, Roberto Barra realizó un

experimento de identificación de emociones en voz sintética generada por los métodos HMM y

Selección de unidades. En él se obtuvieron unos resultados excelentes en tanto por ciento de

emociones al escuchar frases breves con texto neutro y habla sintética emocional:


- 63 -

El mejor método para sintetizar alegría, enfado y tristeza es el de selección de unidades,

mientras HMM es mejor para sorpresa, miedo, asco y neutralidad.

4.1.2. Reconocimiento de voz e Identificación de Usuario

(SERVIVOX)

El módulo de reconocimiento de voz utilizado está integrado en la aplicación SERVIVOX.

Ésta es consecuencia de multitud de proyectos desarrollados en el GTH. Entre las

funcionalidades que se han ido incorporando cabe citar el reconocimiento de habla

independiente de locutor basado en un vocabulario predefinido y la identificación de usuario,

existen versiones que son capaces de identificar idiomas. Estos procesos se encuentran muy

interconectados dentro del módulo SERVIVOX. De hecho, cada vez que se reconoce una frase

con suficiente confianza, lo siguiente que se hace es analizar a qué usuario se le puede atribuir,

de modo que los procesos de identificación y reconocimiento se puede decir que actúan como

uno solo.

Por todo ello, a continuación se analizará la adaptación del SERVIVOX a la arquitectura de

este sistema, describiendo los procesos desencadenados tras el reconocimiento de una frase, así

como aquellos asociados a la identificación de un locutor.

Alegría Enfado Sorpresa Tristeza Miedo Asco

Selección de

Unidades 56 71 34 72 25 30

HMM 37 58 49 48 37 60

Habla 70 70 70 60 50 30

Tabla 1. Resultado de prueba de identificación de emociones


- 64 -

4.1.2.1. Adaptación del SERVIVOX

El módulo SERVIVOX incorporado en este sistema ha sufrido cambios respecto a la

implementación proporcionada. De hecho, inicialmente estaba preparado para el

funcionamiento mediante comunicaciones tipo Sockets. No obstante, tal y como aparece

reflejado en el Capítulo 3 Subsistema de Comunicaciones, el mecanismo de comunicación de

este sistema es SOAP y por ello el módulo SERVIVOX ha precisado una adaptación.

En concreto, esta adaptación ha consistido en la creación de una nueva clase llamada

“RecoSOAP” cuyo objetivo es la implementación de la funcionalidad de comunicación. En este

sentido, aparece el método FraseReconocida. Este método es llamado desde el cliente (módulo

SERVIVOX) y ejecutado en el módulo de comportamiento. Recibe como parámetros la frase

recibida, el concepto asociado a la frase, el usuario identificado como autor, el número de frases

asignadas a dicho usuario, y la dirección del archivo de audio donde ha sido guardada esa frase.

Así mismo, se han creado un par de métodos auxiliares, “Confirma Locutor Actual” y

“Modo ID”.

La forma de incluir estos métodos de comunicación en el sistema SERVIVOX ha buscado

minimizar los cambios. De hecho, SERVIVOX es un sistema complejo y autónomo. Cualquier

cambio que se produzca en él requiere un importante análisis detallado de las múltiples

consecuencias. Teniendo en cuenta esto, los cambios han consistido, principalmente, en la

modificación del método de comunicación, que en lugar de escribir en un socket llama a los

métodos de RecoSoap. Además, como ahora se necesita más información para transmitir, se ha

modificado para que todos los parámetros puedan ser enviados.

Como resultado, el número de pasos desencadenados como consecuencia de un

reconocimiento varía. A continuación se verá dicho funcionamiento.

4.1.2.2. Proceso de reconocimiento de una nueva frase

El proceso que tiene lugar cuando un nuevo concepto es reconocido es el siguiente:

1. El cliente del SERVIVOX detecta la nueva frase y determina el concepto asociado.

Así mismo, se identifica el usuario que dijo tal frase y se incrementa el número de

frases adjudicadas.


- 65 -

2. El cliente realiza una llamada al procedimiento remoto Frase Reconocida que será

ejecutada en el servidor de SERVIVOX.

3. El servidor analiza el concepto reconocido y, en caso de que no sea una nueva

presentación, o no se encuentre ya en un proceso de presentación, actualiza el

número de versión asociado al concepto recibido así como el concepto recibido.

4. El cliente realiza otra solicitud de procedimiento remoto, esta vez a Confirma

Locutor Actual. Este método es ejecutado nuevamente en el servidor.

5. Confirma Locutor Actual devuelve el locutor al cual se le debe asignar la frase

reconocida. Si es una comunicación normal, el locutor devuelto será el mismo que

el recibido en Frase Reconocida. En cambio, si el sistema se encuentra en modo

presentación, los usuarios pueden ser diferentes.

6. El cliente recibe el locutor del servidor y, en el caso en el que fuese distinto del

enviado, eliminaría la frase asignación de la frase a ese locutor y se la adjudicaría

al nuevo.

7. Finalmente el cliente realiza una última llamada al procedimiento remoto Modo

ID, que, nuevamente, será ejecutado en el servidor.

8. El servidor responderá con Modo ID on si se encuentra en un proceso de

presentación, en otro caso este modo estará desactivado.

9. El cliente recibe el Modo ID y, si éste está activado, establece el umbral de

confianza del reconocedor en 0, de esta forma el siguiente reconocimiento será

capaz de admitir frases aunque no las entienda, útil en el proceso de

presentación. Por el contrario, si el Modo ID está desactivado, el sistema

establecerá el umbral de confianza a 0.72, ya que como se concluye en las

pruebas realizadas en el proyecto de Jorge Cancela González (13): “…podemos

sintetizar que un valor demasiado bajo del umbral de confianza provoca excesivos

errores de clasificación al dar por válidas frases con confianza demasiado bajas, y

un umbral de confianza demasiado alto provoca que la exigencia de confianza que

requerimos sea cumplida por pocas de las frases, de forma que las tasas de frases

correctamente clasificadas decaen. Por lo tanto la mejor solución pasa por un

compromiso fijando un umbral de confianza entorno a 0,72.”


- 66 -

Analizando las comunicaciones que tienen lugar entre el cliente y el servidor se puede

elaborar la siguiente figura.

4.1.2.3. Pruebas de identificación

Como se ha dicho, dentro del módulo de identificación de usuario hay un parámetro λ que

modela el funcionamiento del sistema y que debe ser ajustado. Antes de explicar su efecto es se

recapitulará el método de funcionamiento del identificador detallado en el estado del arte.

Figura 25. Secuencia de mensajes del reconocedor.

Figura 26. Alternativas de identificación de usuarios: usuario nuevo versus usuario conocido


- 67 -

El identificador es un clasificador que se encarga de, juzgando diferentes aspectos de la

voz, determinar la similitud entre una frase de un locutor desconocido y los modelos

almacenados. Por ejemplo, si se supone que una cierta secuencia de vectores de característica

de la voz es tenida en cuenta, tras una serie de interacciones con un usuario el sistema habrá

generado una distribución en función de cómo varíe esta secuencia en cada interacción.

Seguidamente, si se recibe una nueva frase el sistema calculará la distancia entre la secuencia de

características de la frase recibida con respecto a la distribución dada. En función de esta

distancia el sistema decidirá o bien considerar que corresponde al usuario anterior y, por tanto,

recalculará los nuevos parámetros de la distribución o, por el contrario, puede considerar que es

suficientemente diferente del modelo almacenado y, en consecuencia, generará un nuevo

usuario. Esto se puede ver gráficamente en la siguiente figura.

Esta figura unidemnsional corresponde al modelado de una de las características de la voz.

No obstante, este mismo sistema se aplica a una vector de características creando un sistema

suficientemente robusto.

Como se puede ver, inicialmente hay una distribución determinada y aparece una nueva

frase con una secuencia de característica que está representada por el punto rojo. El sistema, en

este momento, tiene dos alternativas: generar un nuevo usuario (creando una nueva

distribución basada en la nueva muestra) o incluir la muestra en la distribución del usuario

existente (modificando la distribución asociada a éste). Uno de los determinantes de elegir una u

otra opción es la distancia entre el punto y la distribución. No obstante, existe una forma de

controlar a partir de qué distancia es conveniente crear un nuevo usuario o no, esto es el

parámetro lambda.

En concreto valores bajos de lambda favorecen la creación de nuevos usuarios. Como

ventaja presenta la posibilidad de reconocer automáticamente un nuevo usuario. Sin embargo

presenta un problema asociado a la posibilidad de identificar a un usuario conocido como un

nuevo usuario. Por el contrario, valores altos de lambda favorecen la identificación de usuarios

antiguos. En este caso se favorece que las nuevas frases sean asignadas a usuarios ya conocidos.

No obstante, como contrapartida, se reduce la capacidad del sistema para reconocer a nuevos

usuarios de forma autónoma, siendo necesario que un usuario maestro lo indique.


- 68 -

En este sentido existe un compromiso entre detección de nuevos usuarios e identificación

de los ya existentes. Por ello se han realizado unas pruebas para determinar qué valor de lambda

resultaría óptimo para el propósito del sistema.

El experimento ha consistido en dos pruebas:

1. Determinar a partir de un conjunto de usuarios de los que se tiene una historia, la

cantidad de frases que es capaz de identificar correctamente.

2. Determinar a partir de un número de usuarios conocidos, cuántos cambios de

usuarios puede reconocer con éxito.

4.1.2.3.1. Modo 1

El funcionamiento de este experimento es el siguiente. Se tiene un conjunto de usuarios

que serán todos los que se van a utilizar en el estudio y para cada uno se dispone de una serie de

frases grabadas. De cada usuario se proporcionan parte de esas frases como muestra para el

sistema, lo que se denominará historia. Una vez establecidas estas condiciones iniciales, se

procederá a pasar el resto de frases de cada usuario. El objetivo es analizar la tasa de acierto, es

decir, la cantidad de frases que es capaz de reconocer correctamente respecto al número de

frases totales. Matemáticamente:

�� !�" = #º %!�� #��%�� &' − �#º � (�(�!�"� ∗ #º � ℎ��"!�� #º � %!�� "��+ � − �#º � (�(�!�"� ∗ #º � ℎ��"!��

Los resultados de este experimento se adjuntan en el apéndice Experimento de

identificación. Cabe citar que se han utilizado muestras procedentes de dos bases de datos

diferentes, GTH y DISAM, ambas compuestas por frases cortas como: ¿Quién eres tú?, ¿Dime

qué hora es? O ¿Cuándo comenzó esta línea de investigación?


- 69 -

A la vista de los resultados sobre GTH se puede concluir que para un número fijo de

usuarios (30) y del factor lambda (4.5), cuanto mayor sea la longitud de la historia, mejores

resultados se obtienen. No obstante, con vistas a su aplicación sobre un sistema resulta

imposible establecer historias excesivamente grandes ya que necesitaría realizar un proceso de

presentación demasiado largo. Por ello se busca un compromiso longitud de historia versus tasa

de acierto, que se concreta en una historia de 5 frases.

Utilizando este resultado como dato y fijando también el número de usuarios se puede

ver como la variación de lambda altera la tasa de aciertos. En concreto, valores por encima de 4

maximizan los resultados para la base de datos GTH con 30 usuarios y una historia de 5 frases.

Sin embargo de este rango de valores de lambda óptimos se elegirá el de 4,5, ya que, por la

forma de actuar de lambda, éste es un valor que reduce el número de usuarios inventados, lo

cual es útil para esta prueba, que busca identificar ya existentes y no reconocer nuevos usuarios.

Figura 27. Modo 1 con 30 locutores y lambda 4.5

0,000

0,200

0,400

0,600

0,800

1,000

1,200

3 4 5 10

Ta

sa d

e a

cue

rto

Longitud de la historia

Con el factor lambda definido como 4,5

longitud de la historia fijada en 5 frases se han realizado prueb

para determinar si el orden de identificación influye en las tasas de acierto. El resultado es que

los valores de la tasa varían desde 0.839 hasta 0.960 en

obstante, el valor medio de aciertos es de 0.8739 por lo que la tasa de aciertos en dicha

condiciones es bastante buena, teniendo en cuenta el breve entrenamiento de 5 frases.

Figura 28.

0,000

0,100

0,200

0,300

0,400

0,500

0,600

0,700

0,800

0,900

1,000

Ta

sa d

e a

cue

rto

Figura 29.

0,000

0,200

0,400

0,600

0,800

1,000

1,200

0

Ta

sa d

e a

cie

rto

s


- 70 -

Con el factor lambda definido como 4,5, el número de usuarios establecido como 30

longitud de la historia fijada en 5 frases se han realizado pruebas sobre la base de datos GTH


los valores de la tasa varían desde 0.839 hasta 0.960 en función de cuál sea el locutor inicial.

obstante, el valor medio de aciertos es de 0.8739 por lo que la tasa de aciertos en dicha


Figura 28. Modo1 con 30 locutores e historia de 5 frases

2 2,5 3 3,5 4 4,5 5

Lambda

Figura 29. Modo 1 con 30 locutores, historia de 5 y lambda de 4,5

2 4 6 8 10121416182022242628

Locutor inicial

Tasa de aciertos


, el número de usuarios establecido como 30 y la

as sobre la base de datos GTH


función de cuál sea el locutor inicial. No

obstante, el valor medio de aciertos es de 0.8739 por lo que la tasa de aciertos en dichas


10

Modo 1 con 30 locutores, historia de 5 y lambda de 4,5

Tasa de aciertos

Capítulo 4 – Interfaz Persona

4.1.2.3.2.

En esta ocasión el experiment

usuarios, analizar la capacidad para detectar nuevos usuarios

historia. Como antes, son fundamentales los parámetros

lambda. No obstante, en esta ocasión la forma de analizar los resultados será mediante los

valores Recall, que indica qué p

y el valor Precisión, que representa el porcentaje de cuántos cambios de los detectad

realmente cambios correctos

, ��++-! ��

En esta ocasión se ha utilizado únicamente la base de datos GTH y se ha realizado la

prueba bajo dos contextos diferentes. El primero consiste en 1 locutor conocido con una historia

de 5 frases, la lambda se irá modificando y

de 30 locutores.

Figura 30.

0,000

0,200

0,400

0,600

0,800

1,000

1,200

Interfaz Persona-Máquina

- 71 -

Modo 2

En esta ocasión el experimento consiste en, dada una historia de un número reducido de

usuarios, analizar la capacidad para detectar nuevos usuarios de los que no se tiene ninguna

son fundamentales los parámetros: historia, número de locutores y

te, en esta ocasión la forma de analizar los resultados será mediante los

alores Recall, que indica qué porcentaje de los cambios de usuario existente

y el valor Precisión, que representa el porcentaje de cuántos cambios de los detectad

correctos. Matemáticamente.

= #º ��./�"� � � ��"� �"!! ��. #� #º ��./�"� �� #� � -! ��ó# = #º ��./�"� � � ��"� �"!! ��. #� #º ��./�"� � � ��"�



de 5 frases, la lambda se irá modificando y se analizará la Precisión y el Recall para una población

Figura 30. Modo 2 con 1 locutor, historia 5 y población de 30.

2 3 4

Lambda

o consiste en, dada una historia de un número reducido de

de los que no se tiene ninguna

historia, número de locutores y

te, en esta ocasión la forma de analizar los resultados será mediante los

centaje de los cambios de usuario existentes se han detectado,

y el valor Precisión, que representa el porcentaje de cuántos cambios de los detectados son

�"!! ��. #�



ecall para una población

Modo 2 con 1 locutor, historia 5 y población de 30.

Recall

Precisión

Como se ve en los resultados

implica que se detectan correctamente casi el 100% de los cambios existentes. Los valores de

precisión, por el contrario, son excesivamente bajos indicando que el número de cambios que s

han detectado es mucho mayor que

pecando de crear con mucha facilidad usuarios nuevos. No obstante, al aumentar lambda y

dificultar la creación de usuarios no hay mejoras sustanciales

de Recall.

El otro contexto consiste en 10 locutores conocidos

uno de ellos y una población de, nuevamente, 30 locutores.

se analizará Precisión y Recall.

En este caso se ve que los resultados, lejos de mejorar, se empeoran tanto en precisión

como en Recall.

En conclusión, el sistema presenta resulta

de usuarios conocidos, tasas del 90% de éxito. No obstante, los resultados para la detección de

nuevos usuarios son bastante pobres, siendo necesario, en consecuenci

aspecto.

Figura 31. Modo 2 con 10 locutores, historia de 30 y población de 30.

0,000

0,050

0,100

0,150

0,200

0,250

0,300

0,350

0,400

0,450


- 72 -

Como se ve en los resultados, pese a que Recall sí obtiene valores cercanos al 1, esto


excesivamente bajos indicando que el número de cambios que s

han detectado es mucho mayor que los que existen realmente. Por tanto el sistema está


ión de usuarios no hay mejoras sustanciales, sino más bien un empeoramiento

El otro contexto consiste en 10 locutores conocidos, una historia de 30 frases para cada

y una población de, nuevamente, 30 locutores. Análogamente se varia


En conclusión, el sistema presenta resultados muy buenos para la identificación de frases


nuevos usuarios son bastante pobres, siendo necesario, en consecuencia, mejorar este último

Modo 2 con 10 locutores, historia de 30 y población de 30.

3 4

Lambda


, pese a que Recall sí obtiene valores cercanos al 1, esto


excesivamente bajos indicando que el número de cambios que se

los que existen realmente. Por tanto el sistema está


sino más bien un empeoramiento

una historia de 30 frases para cada

Análogamente se variará lambda y


dos muy buenos para la identificación de frases


a, mejorar este último

Modo 2 con 10 locutores, historia de 30 y población de 30.

Recall

Precisión


- 73 -

4.1.3. Síntesis de voz con emociones

La inclusión del sintetizador de voz con emociones permite la comunicación del sistema

con el entorno por medio de la voz. Concretamente, el módulo sintetizador de emociones se

encuentra corriendo en un servidor remoto al cual no se tiene acceso más que para solicitar la

síntesis de determinadas frases. En este sentido el trabajo realizado en este sistema ha estado

encaminado únicamente a crear las herramientas necesarias para el manejo de las frases que se

desean sintetizar así como para la reproducción de los archivos de audio generados. Para

analizar esto en detalle, primeramente se debe tener claro qué necesita el sintetizador para su

correcto funcionamiento.

El servidor de síntesis necesita un archivo de texto en el cual aparezca la frase a sintetizar.

Además necesita que a la hora de invocar la síntesis se precise la emoción con la que se quiere

sintetizar dicha frase, así como el locutor y el método de síntesis. Un ejemplo del comando de

empleado para solicitar la síntesis será: “'tts/client/client.sh joaquin neutral multisyn

tts/client/text2synth.txt ping.wav” En este caso se ha solicitado la síntesis con emoción neutral y

voz joaquin mediante el método multisyn del archivo text2synthtxt. El resultado será el archivo

de audio ping.wav, este archivo podrá ser reproducido y contendrá el habla asociado a la frase

del archivo.

Figura 32. Proceso de síntesis


- 74 -

Con estas premisas el módulo creado para gestionar esto consiste en un servidor que

recibe solicitudes del módulo de comportamiento. Las solicitudes consistirán en una emoción,

una relación con el usuario y cuatro parámetros. El servidor utiliza la relación con el usuario y los

cuatro parámetros para encontrar la frase a sintetizar dentro de una lista de disponibles (si algún

parámetro es innecesario estará rellenado con la palabra “IRRELEVANTE”). Una vez encontrada

la frase se encargará de enviar la petición de síntesis al servidor remoto utilizando la emoción

proveniente del módulo de comportamiento. Una vez generado el archivo .wav se encargará de

reproducirlo y volverá al estado inicial para atender nuevas funcionalidades. Este proceso

aparece representado en la figura anterior.

Hay que decir que el proceso estrictamente de síntesis (generación del archivo .wav a

partir del .txt) no está optimizado, ya que se accede remotamente a una máquina en la que se

encuentra el servidor de síntesis, aparte del hecho de que la reproducción del archivo .wav debe

comenzar cuando se termina de generar. Por todo ello resulta un proceso relativamente lento.

Debido a esto el servidor implementado incluye un mecanismo de concurrencia llamado Ping-

Pong. Este mecanismo consiste en que, si se deseasen sintetizar varias frases, se crearían dos

hebras (Ping y Pong) entre las que se reparte el conjunto de frases a sintetizar. De este modo

mientras que una hebra está esperando la generación de su archivo de audio, la otra está

reproduciendo el suyo. Así se consigue que el tiempo que pasa entre frases se reduzca

proporcionando la sensación de discurso continuo. La figura anterior representa este

mecanismo.

Figura 33. Mecanismo Ping-Pong


- 75 -

Otra de las particularidades implementadas en el servidor consiste en la carga dinámica de

la lista de frases. Las frases disponibles para la síntesis se encuentran en un archivo de texto

“frases.txt”. Este archivo es leído cada vez que una solicitud de síntesis llega de modo que la

lista de frases puede actualizarse en tiempo de ejecución.

Finalmente cabe mencionar otra de las características implementadas, esta es la

aleatoriedad de frases. Existen ocasiones en las que se reciben solicitudes de síntesis de un

concepto determinado con relativa frecuencia. En este caso se puede producir un efecto de

monotonía si a ese concepto le corresponde una única frase. Para solucionarlo se ha habilitado

un número con cada frase. Éste número es un indicador de la cantidad de veces que, al

solicitarse un determinado concepto, se sintetizará dicha frase. Por ejemplo.

[JUEGO GANAR] 3 He ganado. 1 Te he ganado. 2 He ganado soy muy feliz.

En este caso, al solicitar la síntesis del concepto [JUEGO GANAR], el servidor tiene tres

alternativas con un valor para cada una de ellas, de modo que elegirá cuál debe ser sintetizada

mediante una variable aleatoria. En concreto particionará el espacio muestral en 6 intervalos

(suma de los números) asignando 3 a la primera frase, 1 a la segunda y 2 a la última. Efectuará

un sorteo y en función de cuál sea el intervalo al que pertenece el resultado se elegirá una u otra

frase.

4.2. Interfaz Visual

Los motivos que llevan a incluir una interfaz de este tipo parten de la necesidad de alguna

forma de captar información del entorno sin solicitarla (agente no intrusivo). Es decir, si por

ejemplo el sistema realiza cualquier acción cuando hay alguien cerca de él, deberá ser capaz de

detectar esa presencia sin que se esté constantemente preguntando si hay alguien cerca. Con

este objetivo los nuevos medios de tratamiento de imágenes resultan muy útiles pues permiten

recabar multitud de información del entorno, tan heterogénea como si hay o no luz o si el

usuario sonríe o está enfadado.


- 76 -

Como medio de salida visual para información se ha utilizado la pantalla. No obstante, con

la idea de que el sistema sea aceptado por la mayoría de los usuarios, esta forma de

comunicación debe utilizarse en situaciones muy puntuales ya que el objetivo es mitigar la

sensación de estar dirigiéndonos a máquinas.

Para la realización de esta interfaz ha sido fundamental el trabajo de Jorge Miguel Peñalba

Zambrano y Daniel García Moral, ambos estudiantes del Laboratorio de Sistemas Electrónicos

Digitales durante el curso 2008-2009, que realizaron una práctica innovadora sobre detección de

emociones mediante Opencv. (14)

A continuación se profundizará en el empleo del tratamiento de imágenes mediante la

librería Opencv.

4.2.1. Estado del arte: Reconocimiento de objetos

El proyecto de Ainhoa Montero de Espinosa constituye un gran ejemplo de aplicación de

interfaces visuales en entornos inteligentes. Aunque sus objetivos iban más allá del mero

reconocimiento de objetos (contemplaba el seguimiento), resulta un interesante punto de

partida (15).

El objetivo del reconocimiento de objetos consiste en identificar y localizar la posición de

un objeto dentro de una imagen. Existen numerosos métodos para realizar esta tarea pero

fundamentalmente se pueden agrupar en dos categorías:

• Métodos explícitos o basados en características. Estos métodos utilizan datos

concretos del objeto como el color, la textura, la geometría, etc. Su mayor ventaja

es su bajo coste computacional, haciendo que el tiempo de ejecución disminuya,

aumentando la velocidad de seguimiento.

• Métodos implícitos o basados en modelos. Estos tipos de algoritmos no conocen

ningún tipo de información previa acerca del objeto, sino que extraen a través de

unas muestras o patrones de entrenamiento la información necesaria para

distinguir los objetos que se desean detectar. Son más robustos que los métodos

basados en características pero de más alto coste.


- 77 -

A continuación se hablará sobre cada uno de ellos.

4.2.1.1. Métodos basados en características

4.2.1.1.1. Color

Los algoritmos basados en color sobre todo se utilizan en aplicaciones relacionadas con la

detección de caras y el seguimiento de las manos. Consisten en definir unos umbrales de

crominancia (Cr1, Cr2) y (Cb1, Cb2) y aquellos píxeles que caigan en ese rango (Cr1 < Cr < Cr2) y (Cb1 <

Cb < Cb2) se clasificarán como píxeles de interés.

En general, utilizar una técnica basada solamente en color no es suficiente para detectar o

realizar un seguimiento de objetos, sobre todo, si se trata de caras o manos. Últimamente,

numerosas aplicaciones combinan el análisis de formas con la segmentación por color para la

localización y seguimiento de cabezas y caras en una secuencia de imágenes.

4.2.1.1.2. Múltiples características

Estos algoritmos se basan en la detección de un todo a partir de la detección de las

diferentes características.

Una implementación típica de este algoritmo para el reconocimiento de caras comienza

por la identificación de regiones del color de la piel (descrita en el apartado anterior). Si la forma

de la región se asemeja a una elipse, pasa a ser un candidato. Finalmente, para verificar si el

candidato corresponde con una cara, se buscan dentro de la región las características faciales

(ojos, boca, nariz, cejas, etc).

4.2.1.1.3. Esqueletización

La esqueletización consiste en transformar una forma o un objeto compuesto por un

conjunto de píxeles en un objeto formado por líneas conservando sus propiedades topológicas.

El resultado que se obtiene se denomina esqueleto. Utilizando este método se reduce

significativamente la cantidad de información para procesar, agilizándose la fase de

reconocimiento.

En primer lugar, se segmenta la imagen que se está analizando para poder diferenciar los

diferentes objetos que la conforman. Una vez obtenida las distintas regiones se realiza una

operación morfológica denominada adelgazamiento. Esta operación elimina la información


- 78 -

redundante, lo cual facilita la extracción de las características topológicas, además de reducir el

tiempo de acceso y el espacio que ocupa en memoria.

Para reconocer un objeto se analiza las características del esqueleto de la imagen: número

de líneas que lo componen, los ángulos que forman entre ellas, etc. Se comparan las

características del esqueleto actual y el esqueleto del objeto que se desea detectar, y si

coinciden, se verifica que se trata de dicho objeto.

Los esqueletos proporcionan abstracción de las características geométricas y morfológicas

del objeto, de forma que al almacenarse sólo parte de la información también se puede ver

como un proceso de compresión de datos. La esqueletización es muy útil para reconocer dentro

de una imagen objetos alargados: caracteres, polígonos, o manos.

4.2.1.2. Métodos basados en modelos

Estos métodos obtienen la información de forma implícita a través de un aprendizaje de

patrones. Con ello clasifican las señales que reciben según la información que tienen a priori. Por

lo tanto, para realizar esta tarea es necesario construir un clasificador cuyo objetivo es asignar

un nombre a un conjunto de características correspondientes a un patrón.

Este tipo de técnicas se caracterizan por tener una primera fase de entrenamiento, en la

cual aprenden, a partir de un conjunto de muestras, las características que componen el objeto

que se desea detectar. Dependiendo del método que se utilice, el aprendizaje consistirá en un

algoritmo u otro. A continuación se van a describir tres tipos de clasificadores: redes neuronales,

k vecinos más cercanos y adaboost.

Figura 34. Esqueletización de la mano (15)


- 79 -

4.2.1.2.1. Redes neuronales

Los clasificadores basados en redes neuronales artificiales (RNA) se inspiran en el

funcionamiento del sistema nervioso animal. La red se compone de unidades de procesamiento

llamadas neuronas. Cada neurona está formada por una serie de entradas y una única salida, y

pueden recibir como entrada la salida de otras neuronas. Cada señal de entrada pasa a través de

una ganancia o peso sináptico (wij en la Figura 35). Se considera como la entrada neta la suma

ponderada de todas las entradas reales. Cada neurona transforma la entrada neta mediante una

función de activación para determinar su salida.

Las neuronas deben ser previamente entrenadas para reconocer patrones. Durante el

entrenamiento aprenden por la actualización o cambio de los pesos sinápticos que caracterizan

a las conexiones. Los pesos son adaptados de acuerdo a la información extraída de los patrones

de entrenamiento nuevos que se van presentando. Existen dos métodos de aprendizaje:

• Supervisado. Las muestras de entrenamiento se componen de varias parejas de

patrones de entrada y salida. Un agente externo, denominado supervisor o

maestro, comprueba si la salida que genera la RNA coincide con la esperada. En el

caso de que no coincidan modificará los pesos de las conexiones.

• No supervisado. En este caso el conjunto de entrenamiento lo componen

únicamente los patrones de entrada. La red no obtiene información del entorno

acerca de si es correcta o no la salida generada, por lo que debe aprender a

adaptarse basándose en las experiencias recogidas de entrenamientos anteriores.

Figura 35. Ejemplo de una neurona artificial


- 80 -

Las redes neuronales han resultado ser muy eficientes para el reconocimiento de

caracteres, de objetos y para robots móviles. La principal ventaja es la capacidad de clasificar

patrones complejos. Sin embargo, su mayor inconveniente es que la arquitectura de la red debe

estar muy bien diseñada (el número de capas, el número de nodos, etc) para su correcto

funcionamiento.

4.2.1.2.2. K vecinos más cercanos

Las técnicas de clasificación basadas en los vecinos más cercanos (KNN) es uno de los

planteamientos más clásicos de reconocimiento de patrones. Son sencillos y rápidos, y ofrecen

una valiosa información sobre el problema de clasificación que se quiere abordar.

Su funcionamiento es el siguiente. Primero deben almacenarse los vectores característicos

y las etiquetas de los ejemplos de entrenamiento. Durante la clasificación, se evalúa la muestra

desconocida y se representa con un vector en el espacio característico. Se calcula la distancia

entre dicha muestra y los vectores almacenados y se eligen los k más cercanos. La muestra se

clasificará en la clase a la que pertenezcan la mayoría de los ejemplos seleccionados.

En la figura se ilustra el funcionamiento de este algoritmo. La muestra desconocida que se

desea clasificar es el círculo rojo. Si se escoge una k = 4 se clasificaría en la clase triángulo. Sin

embargo, para una k = 8 la muestra pertenecería a la clase cuadrado.

La efectividad de los algoritmos basados en vecindad reside en la métrica que se utilice.

De esta manera, para mejorar la robustez de este algoritmo frente a vectores aislados, se han

propuesto algunas modificaciones. Éstas se aplican en la elección del conjunto de

entrenamiento, eliminando aquellos ejemplos con una desviación muy grande. Además, se han

Figura 36. Ejemplo del algoritmo KNN para k = 4 y k = 8


- 81 -

diseñado técnicas de condensación para hacer más rápido el proceso de clasificación, en las

cuales las muestras de una clase que se encuentren rodeadas completamente de muestras de la

misma clase son eliminadas, ya que no influyen en la clasificación.

4.2.1.2.3. Adaboost

Adaboost (Adaptive Boosting) es una técnica de clasificación que consiste en formar, a

partir de un conjunto de clasificadores “débiles”, un clasificador “fuerte”, el cual entrega la

respuesta final del algoritmo. Los clasificadores débiles tienen unos resultados muy pobres, pero

combinando varios de ellos se puede conseguir una tasa de detección elevada ya que esta crece

de forma exponencial. En contraposición, la tasa de falsos positivos es demasiado alta (30%)

haciendo que disminuya su fiabilidad.

En un ejemplo mediante características tipo Haar la idea consiste en que en cada

clasificador débil se aplican las plantillas de la figura sobre la ventana de búsqueda. La suma de

los píxeles que caen sobre la parte blanca se substrae de la suma de los píxeles que caen sobre la

parte negra. Si el resultado está por encima de un umbral (que se habrá determinado en el

entrenamiento) la ventana se clasificará como el objeto que se quiere detectar. Cada una de

estas características no son capaces de detectar un objeto por sí solas, de ahí el nombre de

“débil”, pero pueden dar indicio de su existencia.

Figura 37. Plantillas de características tipo Haar propuestas por Viola y Jones y Lienhart


- 82 -

Además, disponiendo a los clasificadores en cascada, de menor a mayor complejidad, se

consigue que las primeras etapas eliminen un gran número de negativos (los más fáciles) con

muy poco procesamiento y las últimas etapas tengan tiempo suficiente para clasificar

correctamente los casos más complejos.

4.2.2. Tratamiento de Imágenes (Opencv)

Como se ha comentado, para la inclusión de esta interfaz es fundamental el trabajo

realizado en LSED por Jorge Miguel Peñalba Zambrano y Daniel García Moral. Estos alumnos

partieron de un sistema basado en la librería Opencv capaz de detectar las caras del usuario y, a

partir de él, fueron capaces de distinguir entre ellos, el sistema podía identificar la emoción del

usuario a partir de la expresión facial. Esto fue realizado mediante el entrenamiento del sistema.

De esta forma se crearon varios clasificadores. Uno para distinguir usuarios, otro para detectar

sonrisas, otro para detectar enfado, sorpresa, etc… Sin embargo, la creación de cada clasificador

era dependiente de usuario. Es decir, creaban un clasificador de sonrisas de Jorge y un

clasificador de sonrisas de Daniel, por lo que en este proyecto se ha considerado no incluir esta

funcionalidad ya que lo que se pretende es crear un sistema capaz de adaptarse a cualquier

usuario. En este sentido se han incluido funcionalidades más básicas, esto es: detectar la luz,

detectar caras y detectar movimientos. Atendiendo a dichas funcionalidades sí se obtiene un

clasificador independiente de usuario.

En cuanto a la estructura de este módulo cabe decir que es un cliente que se comunica

con el módulo de comportamiento para, por un lado informar de la situación (luz, movimiento,

cara…) y, por el otro, para modificar el estado emocional acorde, por ejemplo, al hecho de que

se haya ido la luz.

Figura 38. Esquema de un clasificador en cascada


A continuación se detallará los procesos seguidos para determinar luz, movimientos y

caras.

4.2.2.1. Detección de luz

Para la detección de luz el funcionamiento es muy simple. Si la suma de

cada uno de los pixeles que componen la imagen es

no hay luz. Por el contrario, si la suma es mayor significa que sí hay luz. No obstante, al tratarse

de una medición sujeta a importante fuentes de ruido (sombras, ruidos de oscuridad de la

propia cámara), es necesario elaborar un sistema que filtre los resultados promediando con

cierta cantidad de mediciones. De esta forma se crea un filtro paso bajo que elimine las

variaciones rápidas. La siguiente figura muestra este concepto.

Como se puede ver existe una historia de 5 posiciones en las cuales se almacena el valor

de la suma de los pixeles de cada imagen. Cada vez que se toma una nueva imagen, esto ocurre

aproximadamente cada 100 ms, el sistema calcula el valor de la suma y lo

memoria eliminando la posición más antigua. Realiza el promediado de todos los valores y,

comparándolo con el umbral de luminosidad (2x

comunicándoselo al modelo de comportamiento como un concepto que puede s

“sinLuz”.


- 83 -


Detección de luz

Para la detección de luz el funcionamiento es muy simple. Si la suma de

cada uno de los pixeles que componen la imagen es menor que un umbral entonces significa que



esario elaborar un sistema que filtre los resultados promediando con


variaciones rápidas. La siguiente figura muestra este concepto.



aproximadamente cada 100 ms, el sistema calcula el valor de la suma y lo


con el umbral de luminosidad (2x107) determina si hay o no luz,

comunicándoselo al modelo de comportamiento como un concepto que puede s

Figura 39. Filtrado para detección de luz


Para la detección de luz el funcionamiento es muy simple. Si la suma de los valores de

menor que un umbral entonces significa que



esario elaborar un sistema que filtre los resultados promediando con




aproximadamente cada 100 ms, el sistema calcula el valor de la suma y lo almacena en la


) determina si hay o no luz,

comunicándoselo al modelo de comportamiento como un concepto que puede ser “luz” o


- 84 -

4.2.2.2. Detección de movimientos

La detección de movimientos sigue un funcionamiento análogo al anterior, no obstante,

en esta ocasión no se suman los pixeles de una imagen. El método consiste en restar a la imagen

anterior la nueva imagen. De esta forma, si la diferencia entre imágenes supera un valor

determinado (1.5x106), se puede considerar que ha ocurrido un cambio. Por el contrario, si el

valor diferencia es inferior a un cierto umbral, se puede considerar que no ha tenido lugar un

cambio y, por lo tanto, un movimiento. Aunque en este método también está sujeto a posibles

ruidos, un filtrado similar al caso anterior no es tan apropiado pues interesa que se detecten los

movimientos aunque sean más o menos sutiles. En este sentido se puede ajustar el umbral de

modo que el cambio de la imagen anterior a la actual tenga que ser mayor para poder

considerar un cambio. Teniendo en cuenta que la imagen que se está analizando es de una

resolución de 320x240 pixeles, el umbral de 1.5x106 significa el cambio en, más o menos, 20

pixeles.

4.2.2.3. Detección de caras

Esta es la funcionalidad más compleja que implementa la interfaz visual. Se basa en la

detección de caras con independencia del usuario. Para ello se ha utilizado el clasificador de

ejemplo que suministra la librería Opencv. Este clasificador está entrenado para detectar los

rasgos de una cara en cualquier imagen y se basa en la técnica Adaboost que, como se ha

detallado anteriormente, es capaz de conseguir unas tasas de éxito de detección aceptables,

mediante el empleo de diferentes etapas compuestas, cada una de ellas, por clasificadores

sencillos.

No obstante, dado que el clasificador es independiente de usuario, las condiciones de

detección están un poco relajadas de modo que sea posible identificar las caras de diferentes

personas. Sin embargo esto presenta el problema de la posible ocurrencia de falsos positivos,

esto significa que se detecta una cara donde realmente no hay ninguna. Para solventar este

problema se computa por periodos de tiempo. Es decir, el sistema analiza una imagen cada

cierto tiempo y, cuando ha realizado un número determinado de análisis, determina si había

cara o no. En concreto, el muestreo de imágenes sigue realizándose cada 100 ms

aproximadamente, mientras que el análisis de muestras se realiza cada segundo. La condición de

ocurrencia es que si durante un segundo se han detectado cinco o más caras (el máximo de

caras detectable por segundo según la frecuencia de muestreo es 10), lo que significa que había


- 85 -

una cara por lo menos el 50% del tiempo, el sistema interpreta que existe una cara y lo

comunica al módulo de comportamiento mediante el concepto “hayCara”. Por el contrario, si se

detectan menos de cinco caras, esto significa una presencia inferior al 50% de tiempo

aproximadamente, el sistema no enviará ningún mensaje relacionado con la presencia de caras.

4.3. Interfaz Física

Hasta ahora se ha hablado de interfaces útiles para intercambiar información, pero existe

un inconveniente: el sistema es abstracto. Esto significa que los usuarios son capaces de

comunicarse de forma fácil mediante voz y el sistema es capaz de obtener información de forma

no intrusiva, pero, realmente, el interlocutor de la persona no existe como ente físico. Por tanto,

es necesaria la presencia de una parte física a la que la persona pueda asociar como

representación del sistema. En este proyecto se ha creado una cara robótica capaz de gesticular

algunas expresiones emocionales. Esta cara hace las veces de interlocutor para las personas que

ahora sí tienen algo a lo que dirigirse, cuando saluda o cuando juega con el sistema, la cara

expresa su estado interno realimentando al usuario. De esta forma se diluye la sensación de

estar interactuando con una máquina convencional.

Por otro lado, se ha incluido un brazo robótico asociado a un juego, en concreto las tres en

raya. De esta forma, el usuario puede interactuar de forma física con el sistema sin necesidad de

dirigir una mirada a la pantalla. Para esta interfaz ha sido fundamental el trabajo realizado por

Enrique Fueyo Ramírez y Juan Carlos Hernández Munuera, alumnos del Laboratorio de Sistemas

Electrónicos Digitales en el curso 2008-2009, que trabajaron en la creación de un sistema de

sensores que permitiese jugar al tres en raya contra la máquina a partir del movimiento de

piezas mediante un brazo robótico creado por los alumnos José Manuel Cano y Jorge Blanco, del

curso 2007 2008 (16).

En resumen, las interfaces físicas son necesarias para conseguir que una persona acepte

un sistema emocional y además resultan de utilidad a la hora de proporcionar otro enfoque en la

interacción persona máquina.


- 86 -

4.3.1. Brazo Robótico

El brazo robótico ha sido incluido en este capítulo pues, en esencia, es una interfaz

persona máquina ya que permite la interacción de la máquina con el entorno mediante su uso.

No obstante en este sistema esta interfaz no está aprovechada en toda su capacidad pues

únicamente se incluye esta característica como medio para poder jugar a las tres en raya sin

proporcionarle otra utilidad. El requisito para que pudiera ser considerado una interfaz sin

ningún tipo de limitación es que permitiera ser utilizado para diversos objetivos. Es decir, como

por ejemplo para hacer algún gesto, para intentar interaccionar con el usuario dando la mano

cuando se presenta, etc. No obstante, en el caso que se expone, el brazo robótico tendrá la

misión de mover fichas. A continuación se puede ver una imagen.

Como se puede ver el ingenio no es más que un conjunto de servos que controlan un

brazo articulado terminado en unas pinzas capaces de abrirse y cerrarse. En el tablero de juego

hay una serie de orificios donde se sitúan sensores de infrarrojos que detectan la presencia de

una ficha o no en dicho punto. Más información sobre esta implementación puede ser

encontrada en el apartado de tres en raya físico en el Capítulo 5.

4.3.2. Cara Robótica

La inclusión de una cara robótica responde a la necesidad de crear un símbolo al que una

persona pueda dirigirse a la hora de interaccionar. Resulta muy complicado, si no imposible,

crear un sistema emocional verosímil sin ningún elemento físico con el que se pueda mantener

un contacto visual. De hecho, solamente con la expresión emocional de la síntesis de habla

Figura 40. Brazo robótico


- 87 -

resulta ambigua la expresión de algunas emociones. En este sentido la cara robótica juega ese

doble papel. Por un lado actúa como símbolo del sistema permitiendo que el usuario tenga algo

físico con lo que interrelacionarse y, por otro lado, matiza o refuerza la expresión de las

emociones.

La cara robótica que se ha utilizado en este proyecto es heredada del trabajo realizado en

una beca de la UPM sobre innovación educativa. El diseño está extraído de la cara del robot

Urbano. Este robot pertenece a un proyecto que está realizado de forma conjunta por el Grupo

de Automática DISAM de la ETSII y por el GTH de la ETSIT y cuyo objetivo es crear un robot guía

de museo que presente comportamiento emocional (más información acerca de este sistema

puede ser encontrada en el Capítulo 6). No obstante, el diseño presenta una serie de limitaciones

a la hora de cumplir uno de los objetivos propuestos, la expresión emocional. Antes de entrar

en detalle se describirá brevemente la cara utilizada que, por su bigote, ha sido denominada

Groucho.

Como puede verse el diseño de ambas caras es el mismo y presenta cinco servos que

permiten:

• Movimiento independiente de cejas.

• Movimiento independiente de labios (labio derecho o labio izquierdo).

• Movimiento conjunto de párpados.

Figura 41. A la izquierda Groucho a la derecha robot Urbano


- 88 -

Con estas características los gestos disponibles para expresar emociones son los

siguientes:

Si se recuerda el número de emociones distintas que soporta el sintetizador usado, esto

es, alegría, neutral, tristeza, miedo, enfado, asco y sorpresa, se puede ver que las emociones de

asco y sorpresa no tienen un gesto correspondiente. No obstante, para sorpresa existe una

solución basada en la transición de la cara. Si se abren mucho los ojos, unido a la síntesis de una

frase con sorpresa, es posible dar la sensación de esa emoción. Para el caso de asco la cara

puede cerrar los ojos y torcer la boca pero este gesto no es unívoco por lo que para la expresión

de dicha emoción es imprescindible el sintetizador de habla.

Por otro lado, la cara permite generar gestos intermedios que proporcionan más riqueza

expresiva al sistema. En la siguiente imagen aparece un ejemplo de esto.

Figura 42. Gestos (de arriba izquierda abajo derecha) enfado, neutral, alegría, tristeza y miedo

Figura 43. Cara de leve enfado


- 89 -

Este gesto puede ser entendido como desconfianza a lo que ocurre, o disgusto frente a

una situación pero sin llegar a enfadarse mucho, etc.

En cuanto a la integración de la cara en el sistema global, cabe decir que es un servidor

que implementa procedimientos para cada gesto. Estos procedimientos son llamados desde un

cliente implementado en el módulo de comportamiento.

Por último, el control de los servos se realiza con una placa controladora de servos Servo 8

Torque Board de NetMedia. Entre las características de esta placa destaca la capacidad de

gobernar hasta 8 servos controlando su consumo en todo momento, de esta forma se puede

abre un camino de realimentación del movimiento. Otra característica es la interfaz RS-232 de

control. Es decir se comunica mediante puerto serie, concretamente con los siguientes

parámetros:

• Bits por segundo: 19200

• Bits de datos: 8

• Paridad: ninguno

• Bits de parada: 1

4.3.3. Detector de Caricias

La implementación de este sensor de caricias es fruto del trabajo desarrollado en el

Laboratorio de Componentes Electrónicos (LCEL) durante el curso 2008/2009 por los alumnos

Enrique Fueyo Ramírez, Juan Carlos Hernández Munuera y Daniel García Moral. La práctica se

basaba en la realización de una cabeza animatrónica, empleando dispositivos digitales

programables y electrónica analógica discreta. En este sentido se planteaba la inclusión de

diversos tipos de sensores como puede ser temperatura, acelerómetros infrarrojos y

ultrasonidos, con la electrónica necesaria para hacerlos funcionar de manera autónoma.

Como resultado de aquél trabajo se ha heredado un sensor infrarrojo CNY70. Este sensor

suele ser utilizado por robots seguidores de líneas. No obstante, en esta ocasión su objetivo es

diferente. Pretende detectar las posibles caricias que se le apliquen al sistema mediante la

proximidad de la mano del usuario. Esta información es recogida y enviada mediante el puerto

paralelo. De esta forma el sistema puede detectar la presencia o no de un contacto, ya que este

sensor está ajustado para que la distancia de detección sea muy corta.

El control de este sensor por parte del sistema se realiza mediante el módulo de

comportamiento. En concreto, este módulo solicita cada cierto tiempo una lectura del sensor,

típicamente cada centena de milisegundo. De esta forma, teniendo en cuenta el tiempo que

puede tardar una persona en pasar la mano por encima, el sensor puede interpretar una misma

caricia como varias sucesivas. Además se presenta un problema de ruido inhere

de sensores. Este problema consiste en que posibles alteraciones desconocidas del entorno

pueden ser interpretadas como una caricia. Para resolver ambos problemas se ha implementado

una capa de control de dicho sensor

correctamente una única caricia.

Para la realización del filtrado de una caricia se ha creado una historia de cinco muestras

tomadas cada, aproximadamente, 100 ms. De esta forma cada vez que se toma una nueva

medida se elimina la más antigua de la historia y se incluye la nueva. Posterior

determina si la condición predominante

a determinar que hay caricia no hay problema. No obstante, en el caso en el que se determine

por la historia que hay una nueva caricia se analizará s

caricia. De esta manera se detecta una nueva caricia porque, primero, el estímulo ha estado

presente un periodo suficiente de tiempo y, segundo,

estaba siendo acariciado.


- 90 -



picamente cada centena de milisegundo. De esta forma, teniendo en cuenta el tiempo que


caricia como varias sucesivas. Además se presenta un problema de ruido inhere



una capa de control de dicho sensor, cuyo objetivo es filtrar posibles falsas caricias y detectar

correctamente una única caricia.



medida se elimina la más antigua de la historia y se incluye la nueva. Posterior

determina si la condición predominante es que hay caricia o no. En el caso en el que no se llegue


por la historia que hay una nueva caricia se analizará si en la toma anterior había o no una


presente un periodo suficiente de tiempo y, segundo, porque la situación precedente era que no

Figura 44. Mecanismo de detección de caricias.




picamente cada centena de milisegundo. De esta forma, teniendo en cuenta el tiempo que


caricia como varias sucesivas. Además se presenta un problema de ruido inherente a la mayoría



trar posibles falsas caricias y detectar



medida se elimina la más antigua de la historia y se incluye la nueva. Posteriormente se

es que hay caricia o no. En el caso en el que no se llegue


i en la toma anterior había o no una


la situación precedente era que no


En la figura se ve a la izquierda la nueva entrada (

situación de la historia y la salida que puede ser: Ninguna

detectada; Nueva Caricia, si se detecta una caricia y antes no había ninguna car

Se Mantiene, si se detecta una caricia y antes ya había una caricia detectada.

Adicionalmente, esta capa de adaptación incluye otro paso

de la importancia de una caricia para el sistema emocional. En este sen

ocasionales tienen efectos moderados en el sistema emocional. Por el contrario, caricias

continuadas tendrán un efecto mucho más apreciable en la respuesta emocional.

Para computar esto se ha definido una nueva historia

vez que el paso anterior detecta una Nueva Caricia, esta nueva memoria almacena el instante de

tiempo en el que ocurre y,

frecuencia de ocurrencia por minuto. De esta forma, comparándola con una frecuencia de

ocurrencia máxima, es posible ponderar

bastante útil para el sistema emocional

puede ser descrito mediante la siguiente figura.


- 91 -

figura se ve a la izquierda la nueva entrada (negro detecta,

situación de la historia y la salida que puede ser: Ninguna Caricia, si no hay ninguna caricia

detectada; Nueva Caricia, si se detecta una caricia y antes no había ninguna car

Mantiene, si se detecta una caricia y antes ya había una caricia detectada.

esta capa de adaptación incluye otro paso relacionado con la estimación

de la importancia de una caricia para el sistema emocional. En este sentido se define que caricias



sto se ha definido una nueva historia, esta vez de tres posiciones.


a partir de la caricia más antigua y de la más reciente


es posible ponderar el efecto de la sucesión de caricias, cosa que resulta

el sistema emocional, tal y como se explica en el Capítulo 6

puede ser descrito mediante la siguiente figura.

Figura 45. Estimación de frecuencia de las caricias

detecta, gris no detecta) la

, si no hay ninguna caricia

detectada; Nueva Caricia, si se detecta una caricia y antes no había ninguna caricia detectada; o

Mantiene, si se detecta una caricia y antes ya había una caricia detectada.

relacionado con la estimación

tido se define que caricias



esta vez de tres posiciones. Cada


la más reciente, estima una


el efecto de la sucesión de caricias, cosa que resulta

Capítulo 6. El mecanismo


- 92 -

Como se puede ver, el eje vertical es el eje de tiempos mientras que a la derecha aparece

la frecuencia. Cada vez que ocurre un evento se almacena en la memoria desplazando el último

y se calcula la frecuencia. Analizando el caso particularizado para que cada evento ocurra tras un

periodo, T se puede ver que el primer evento tendría una frecuencia de 2/T, el segundo tendría

una frecuencia de 2/2T o lo que es lo mismo de 1/T (esto significa que está ocurriendo cada T

segundos) el tercero tendría una frecuencia de 1/T, por lo cual la estimación hecha en el

segundo evento sería válida.

Como factor adicional se incluye la frecuencia máxima, esta frecuencia surge del análisis

de la situación para el caso peor. En concreto, si se piensa en que para detectar una caricia tiene

que estar durante 300 ms ocurriendo y unos 400 ms apagada para que se vuelva a poder

detectar una nueva caricia surge que el periodo entre caricias es de 1/700ms, o lo que es lo

mismo 0.001 caricias/ms. No obstante, esta es una cota superior, el valor de frecuencia máxima

puede ser ajustado en función de la situación real (es muy poco probable que se le acaricie tan

rápido).

De esta forma el efecto de una caricia puede ser cuantificado como:

% ��" = %! �( #�� .��%! �( #�� .á��.�

De modo que si la frecuencia estimada es cercana a la máxima (las caricias son

frecuentes), la importancia de éstas es grande. Mientras que si la frecuencia estimada es baja

(las caricias se producen de tarde en tarde), la importancia es mucho menor.

Capítulo 5 - Aplicación

- 93 -


5 APLICACIÓN

En la introducción se habló del problema que tienen ciertos colectivos de usuarios a la

hora de detectar una verdadera utilidad en los sistemas electrónicos. La solución pasa por

encontrar una killer aplication que les muestre el efecto que tienen los sistemas electrónicos en

el incremento del rendimiento de cualquier actividad. Para perseguir este objetivo se ha

implementado la funcionalidad de asistente domótico. Este tipo de asistentes se pueden

asemejar a los electrodomésticos y, por tanto, parece viable conseguir situar el grado de

aceptación de un sistema de esta clase en el nivel de una lavadora o un frigorífico, es decir,

aparatos que están presentes en la inmensa mayoría de las casas y que son utilizados por todos.


- 94 -

En el presente capítulo se explicará cada módulo de tarea implementado. Si es pertinente

se incluirán estados del arte que siente las bases de la tecnología que ha sido utilizada en los

correspondientes módulos.

No obstante y dado que, aunque las tareas muestran comportamientos independientes se

enmarcan dentro de un mismo sistema, el primer paso para su explicación es un breve apartado

con la lista de características comunes a las tareas para, a continuación, abordar las

particularidades de cada una de ellas.

5.1. Estructura Genérica de una Tarea

La arquitectura de comunicaciones escogida es del tipo Cliente/Servidor. Este hecho

beneficia la escalabilidad del sistema, ya que cada tarea puede ser un módulo independiente. No

obstante, también exige una serie de requisitos asociados a la estandarización de las interfaces

de las tareas de modo que el aumento del número de tareas no incremente la complejidad del

modelo de comportamiento (que será el encargado de negociar con las tareas).

Como se ha dicho, el sistema es del tipo Cliente/Servidor, esto implica que cada tarea

debe tener dos partes, la parte cliente y la parte servidor. Atendiendo a la definición de un

cliente (ver Capítulo 3 Subsistema de Comunicaciones), el cliente será aquel en el que se incluya

la funcionalidad de la tarea. Por ejemplo, si la tarea se encarga de limpiar el suelo, todas las

acciones específicas de limpiar el suelo están en el cliente. Así mismo, el servido será, por tanto,

el que contenga lo procedimientos que se solicitarán remotamente y que están particularizados

para dicha tarea, siendo también el encargado de la comunicación con el módulo de

comportamiento. Por ejemplo, si cuando el sistema termina de limpiar dice “He acabado”, el

cliente sería el encargado de enviar un mensaje de estado como “suelo limpio” siendo el

servidor el que comunica “descodifica” ese estado y solicita al módulo de comportamiento la

síntesis de la frase “He acabado”.

En cuanto a la interfaz estandarizada que deben incluir las tareas cabe mencionar la

creación de una clase base de la que deben derivar todas las tareas. Esta clase es “Módulo Base

Soap” y define los siguientes métodos virtuales:


• “Enviar Respuesta A Usuario”

cualquier tarea

respuestas de tipo acción, en concreto sintetizar.

llama desde el cliente y se ejecuta en el servidor, por tanto, si el estado en

el que se esté requiere sintetizar algo, será el

orden de síntesis mediante

• “Comunicar Situación Módulo”:

estado emocional en función del parámetro estado. Además también recibe

un valor que, en algunos casos, puede resultar necesario para el cálculo

emocional. Una vez más

por tanto, es allí donde se ejecuta.

Además de estos métodos, la clase “

heredado denominado “Espera Respuesta Usuario”

la funcionalidad para comunicar la información de las interfaces de entrada a los módulos

tareas. El funcionamiento de este método aparece descrito en el

módulo de comportamiento.

5.2. Control de

Como su propio nombre indica, esta tarea implementa el control de la aspiradora robótica

Roomba como parte del sistema. Aunque la funcionalidad incluida en este

que un ejemplo, hay que citar la posibilidad de realizar ac

- 95 -

“Enviar Respuesta A Usuario”: Este método debe ser implementado por

cualquier tarea. Recibe como parámetro el estado y su misión es generar las

uestas de tipo acción, en concreto sintetizar. Una vez implementado se


el que se esté requiere sintetizar algo, será el servidor

orden de síntesis mediante “Prepara Sintetizador”.

“Comunicar Situación Módulo”: Este método tiene por objetivo modificar el



emocional. Una vez más, el cuerpo de este método está en el servid

por tanto, es allí donde se ejecuta.

Además de estos métodos, la clase “Modulo Base Soap” proporciona un método que será

Espera Respuesta Usuario”. El objetivo de este método es proporcionar


tareas. El funcionamiento de este método aparece descrito en el Capítulo 1

módulo de comportamiento.

de Roomba


Roomba como parte del sistema. Aunque la funcionalidad incluida en este proyecto

, hay que citar la posibilidad de realizar acciones más complejas.

Figura 46. Diagrama de herencia de las tareas

: Este método debe ser implementado por

y su misión es generar las

Una vez implementado se


servidor el que prepare la

Este método tiene por objetivo modificar el



el cuerpo de este método está en el servidor y,

oporciona un método que será

. El objetivo de este método es proporcionar


apítulo 1, en el apartado


proyecto es poco más

ciones más complejas. De hecho, el


- 96 -

proyecto de Jorge Cancela González trata sobre la creación de una interfaz multimodal para este

robot domótico móvil (13) y en él, el lector puede encontrar más información acerca de lo que

se habla en este apartado.

5.2.1. Características de Roomba

El robot Roomba es una creación de iRobot. El principal objetivo de Roomba es la limpieza

del suelo y, por tanto, se comercializa como una aspiradora robótica que en sus versiones más

modernas incluye sensores de suciedad para enfatizar la limpieza en sitios con muy sucios.

Además, consta de sensores de suelo (para detectar precipicios) y de paredes (para evitar

obstáculos). Por último, incluye la capacidad de volver automáticamente a la estación de carga y

existen paredes virtuales que permiten acotar el terreno de limpieza del robot.

Sin embargo, dado el potencial de Roomba, iRobot ha proporcionado diferentes opciones

que permiten el desarrollo de aplicaciones basadas en este robot. Entre estas posibilidades

están la comunicación vía cable por interfaz rs-232 o la comunicación Bluetooth mediante el

módulo RooTooth creado específicamente por iRobot para Roomba. También cabe citar la API

(“Aplication Programming Interface”) suministrada que posibilita el desarrollo de

funcionalidades de forma sencilla.

5.2.2. Tecnología Bluetooth

Anteriormente se ha mencionado que el módulo RooTooth permite la comunicación

Bluetooth con Roomba. Esta opción es muy potente puesto que, por un lado, se prescinde del

cable, hecho particularmente importante en el caso del control de un robot destinado a moverse

entre objetos con el consiguiente riesgo de “enganche”. Por otro lado, se heredan todas las

ventajas de la tecnología Bluetooth.

Bluetooth responde al objetivo de crear una forma de comunicación inalámbrica

independiente del terminal, capaz de operar en todo el mundo, que permitiese la transmisión de

audio y datos (transmisión multimedia) y todo ello con limitaciones en el consumo de energía

(destinado a dispositivos portátiles). Opera en la banda ISM (2,4Ghz) de corto alcance que está

destinada a uso industrial científico y médico y, además, se encuentra desregulada

internacionalmente. La transmisión se realiza mediante saltos de frecuencia en dispersión de

espectro (Frequency-Hopping Spread Spectrum FHSS). Esto consiste en la transmisión de señales


- 97 -

radio conmutando rápidamente entre portadoras de diferentes frecuencias. En Bluetooth se

llegan a utilizar 79. Tal vez la característica más relevante de este tipo de transmisión sea la

capacidad de compartir el espectro con otras tecnologías como WIFI.

Existes diferentes categorías de dispositivos Bluetooth:

- Atendiendo a la potencia de transmisión:

� Clase 1: Potencia de transmisión hasta 20 dBm con alcance de unos 100

metros

� Clase 2: Potencia de transmisión hasta 4 dBm con alcance de unos 10

metros

� Clase 3: Potencia de transmisión hasta 0 dBm con alcance de

aproximadamente 1 metro.

- Atendiendo al ancho de banda:

� Versión 1.2: Versión básica hasta 1Mbps.

� Versión 2.0 + EDR: Incorpora tecnología Enhanced Data Rate para lograr

velocidades de hasta 3 Mbps.

� UWB (propuesto): Con el objetivo de interconectar Bluetooth con Wifi las

velocidades irán desde 50 a 480 Mpbs.

La topología de red utilizada por Bluetooth es una piconet. Una piconet es un conjunto de

dispositivos Bluetooth, concretamente un maestro y hasta siete esclavos que se diseminan en

una distancia de entre 10 y 100 metros. Aunque el nodo maestro debe pertenecer únicamente a

una piconet los esclavos pueden pertenecer a varias a la vez, lo que se denomina scatternet o

red distribuida. Finalmente cabe decir que este tipo de diseño maestro/esclavo favorece el bajo

coste de esta tecnología pues los esclavos son dispositivos sumamente sencillos y pasivos que

realizan lo que les es solicitado por el maestro, siendo éste el que presenta mayor complicación.

Uno de los motivos que dotan a esta tecnología de gran versatilidad es el número de

perfiles definidos. Cada perfil es una guía que detalla el procedimiento de la comunicación entre

dispositivos Bluetooth para un determinado propósito. Es decir, cada perfil no es más que una

definición de:

• Dependencia de otros perfiles.

• Propuestas de formato de interfaz de usuario.


- 98 -

• Características concretas de la pila de protocolos Bluetooth utilizada por el perfil.

Para realizar su función, cada perfil se sirve de ciertas opciones y parámetros en

cada capa de la pila. También se puede incluir un breve resumen de los servicios

requeridos si resulta necesario.

En este sentido hay multitud de perfiles desde transmisión de audio estéreo (A2DP) hasta

incluso conexión a red por línea conmutada (DUN). No obstante el que se utilizará en este

proyecto es el de emulación de línea serie y generación del interfaz RS-232 (SPP). Huelga decir

que para que dos dispositivos Bluetooth puedan interconectarse ambos deben soportar el

mismo perfil y, como es lógico, no todos los dispositivos soportan todos los perfiles.

Analizando en detalle el perfil SPP (Serial Port Profile) cabe mencionar que este perfil tiene

el objetivo de emular un puerto en serie utilizando las propiedades de conectividad de los

niveles más bajos de la pila de protocolos de Bluetooth. En este perfil se definen dos roles:

• Dispositivo A: Que inicia la conexión o iniciador.

• Dispositivo B: Que espera a que el otro inicia la conexión o aceptor.

Por tanto, la pila de protocolos de cada uno de los dispositivos será la siguiente.

Se puede apreciar que los tren niveles inferiores corresponden a protocolos definidos por

Bluetooth, mientras que la aplicación puede ser cualquiera que precise comunicación por puerto

serie. Finalmente, existe un “pegamento” que proporciona una emulación de la funcionalidad

del puerto serie para que la aplicación no tenga que saber cómo se maneja la comunicación por

Bluetooth. Esta capa de emulación o API no se tratan de forma explícita en este perfil.

Figura 47. Pila de protocolos Bluetooth para SPP (13)


- 99 -

5.2.3. Tarea Implementada

Esta tarea implementa tres funcionalidades: iniciar un proceso de limpieza, finalizar un

proceso de limpieza y enviar al robot a su estación de carga. Hay que mencionar que en cada

una de estas actividades lo que se realiza desde el cliente es iniciar la secuencia pertinente

definida por los desarrolladores de Roomba. De esta forma no se ha profundizado en la

definición de los movimientos ni de las secuencias que maximicen la limpieza. Así mismo, el

procedimiento de acoplo a la estación de carga también es el proporcionado por los

desarrolladores de iRobot.

Esta tarea consta de dos partes, un servidor que responde al funcionamiento general para

los servidores de tareas y un cliente. Además, esta tarea requiere que previamente se haya

habilitado una conexión Bluetooth con perfil SPP entre el PC y Roomba por medio de Rootouth.

El funcionamiento es sencillo, un concepto es recibido por el servidor y enviado al cliente.

Éste chequea si es un concepto válido para la tarea y, si lo es, espera la transmisión definitiva.

Tras recibir el concepto definitivo analiza cuál es y se limita a enviar los comandos necesarios

mediante una comunicación estándar por el puerto serie virtual. Estos comandos son los

proporcionados en la API de iRobot para el control de Roomba. A continuación se adjunta la lista

de acciones a realizar y la secuencia de comandos a enviar.

El comando de inicio debe ser enviado para que el sistema sea capaz de atender al resto

de los comandos. Cada uno de ellos es enviado de forma análoga a como si se utilizara un puerto

Comando de inicio Binario: 128

Empezar a limpiar Binario: 135

Dejar de limpiar Binario: 131

Ir a casa Binario: 143

Tabla 2. Correspondencia entre Acciones y Comandos


- 100 -

serie físico con una velocidad de 57600 kbps, 8 bits de datos, sin paridad, un bit de parada y sin

control de flujo.

5.3. Control Infrarrojos

Esta tarea implementa el control de un dispositivo emisor de infrarrojos iRTrans. Este

dispositivo es capaz de almacenar códigos para controlar cualquier aparato que presenten una

interfaz infrarrojos. No obstante, para la intención de este proyecto será suficiente con el control

básico de un equipo Hi-Fi. Para esta tarea no se incluye el control mediante lenguaje natural, sin

embargo, existen diversos proyectos que tratan esta tarea, por ejemplo, los proyectos de

Alejandro Guirao Rodríguez (17) o Rafael García Sánchez (18) tratan sobre estos temas.

5.3.1. Tecnología de Infrarrojos

La tecnología de control infrarrojo de dispositivo es bastante madura teniendo en cuenta

que la comercialización de las primeras televisiones con mando a distancia data de los 90. En la

actualidad casi todos los dispositivos electrónicos de un salón admiten este tipo de control (aire

acondicionado, televisión, equipo de música, DVD, receptor tdt…). En este sentido el módulo

iRTrans tiene un gran abanico de posibilidades.

Este dispositivo está creado específicamente para el control por infrarrojos de cualquier

dispositivo. Para ello presenta la siguiente arquitectura.

Figura 48. Arquitectura general del sistema IRTrans (19)


- 101 -

Como se ve existe un cliente en Windows de iRTrans que se encarga de manejar la

comunicación con el módulo servidor mediante un socket. Este módulo principal, con la ayuda

de la base de datos de comandos IR se comunica a través de distintos medios (en este caso un

USB) con el módulo físico que se encarga de la emisión de la señal. Más información puede ser

encontrada en el manual del usuario (19).


Como en la tarea anterior, hay dos partes. Un servidor que se encarga de la comunicación

con el modelo de comportamiento y un cliente. Para el correcto funcionamiento de este sistema

debe estar ejecutándose la aplicación de control de IRTrans. Es decir, el programa suministrado

por el fabricante que implementa la arquitectura definida en el apartado anterior.

El funcionamiento del cliente es muy simple. Inicialmente se carga la base de datos

correspondiente al dispositivo a controlar. A continuación se establece una estructura con

información sobre los comandos a utilizar. Posteriormente el cliente actuará como todos los

demás. Es decir, esperará a que le llegue un concepto válido para realizar la tarea deseada. En

este caso, tanto encender como apagar la luz utilizan el mismo comando infrarrojo, por tanto,

una vez que llega cualquiera de dichos conceptos, el cliente llamará a la función

“mandarInfrarrojos” que se encarga de solicitar el envío del comando pertinente. Es importante

notar que, en función de qué dispositivo se quisiera controlar, habría que cargar una base de

datos u otra.

5.4. Control Luz

Esta aplicación está orientada al control de luces. El objetivo es habilitar el control de

cualquier luz de una vivienda mediante el sistema. Para ello se ha utilizado la tecnología X10

destinada, precisamente, al control de dispositivos eléctricos en el ámbito del hogar. Es decir,

control domótico. Para el desarrollo de esta aplicación se ha utilizado parte del proyecto

realizado por Alexander Zlotnik que habilitaba la conexión remota al entorno de desarrollo

Coldfire. (20)


- 102 -

5.4.1. Tecnología X10

X10 es un protocolo de comunicación destinado al control de aparatos eléctricos. Su uso

se encuentra muy extendido en ambientes domóticos debido, por un lado, al bajo precio de los

dispositivos y por otro al medio de comunicación. Este estándar utiliza la instalación eléctrica del

hogar para la transmisión de las señales digitales entre los dispositivos X10. En concreto, envía

ráfagas de información moduladas con una portadora de 120 Khz en cada paso de la señal

eléctrica alterna por cero. Esto es 50 ó 60 Hz dependiendo del país. De hecho, cada paso por

cero transmite un bit.

La estructura de un mensaje es la siguiente.

Existe un campo de dirección y campo de datos. Un controlador envía un mensaje a una

determinada unidad que se encuentra definida por su dirección. Todas las unidades están a la

escucha y cuando reciben un mensaje con su dirección procesan el campo de datos. En una

versión inicial los comandos pueden ser “off” y “on”. No obstante, controladores más avanzados

permiten responder con información de sensores como temperatura, etc.

Hay que tener en cuenta que un sistema básico X10 no puede estar distribuido en

diferentes fases eléctricas. En este sentido existen controladores X10 activos que permiten

retransmitir la señal por diferentes fases.


Nuevamente la tarea constará de dos partes, un servidor y un cliente. Al igual que

siempre, el servidor se encargará de la comunicación con el módulo de comportamiento. Por

otro lado el cliente se encargará de la comunicación con el servidor DRAC. Este servidor es parte

del proyecto de Alexander Zlotnik (20) y básicamente implementa la siguiente estructura.

Figura 49. Trama X10


En definitiva, el cliente de la tarea se encargará

para encender o apagar bombilla. Estas solicitudes serán procesadas por el servidor DRAC

enviándolas por puerto serie (línea azul) mediante el protocolo de linux Heyu, al módulo

controlador X10. El módulo controlad

controlador de la bombilla mediante las líneas eléctricas de la instalación (línea roja). Este

terminal finalmente activa el paso de la corriente al dispositivo eléctrico, en este caso la

bombilla.

La forma de comunicar el cliente de la aplicación con el servidor DRAC es mediante

conexión TCP/IP con protocolo HTTP

permite la comunicación mediante HTTP entre el ordenador en el que corre e

ordenador que está conectado con el módulo

parámetro más, que puede ser: heyuoffM1.php o heyuonM1.php. El campo heyu(on/off) es el

que determinará si lo que se quiere es activar (on) o des

que el campo M1 permite direccionar a qué dispositivo se manda la orden. En este caso es M1

porque el casquillo X10 tiene asignada esa dirección.

- 103 -

En definitiva, el cliente de la tarea se encargará de realizar solicitudes al servidor DRAC



controlador X10. El módulo controlador X10 recibe la solicitud y envía la orden al dispositivo




con protocolo HTTP. Para ello se utiliza el siguiente script en

permite la comunicación mediante HTTP entre el ordenador en el que corre e

ordenador que está conectado con el módulo controlador de X10. No obstante hace falta un


que determinará si lo que se quiere es activar (on) o desactivar (off) el dispositivo X10, mientras


porque el casquillo X10 tiene asignada esa dirección.

Figura 50. Arquitectura sistema DRAC extraído de (20)

de realizar solicitudes al servidor DRAC



or X10 recibe la solicitud y envía la orden al dispositivo




script en Perl. Este script

permite la comunicación mediante HTTP entre el ordenador en el que corre el cliente de luz y el

controlador de X10. No obstante hace falta un


activar (off) el dispositivo X10, mientras


(20)


- 104 -

5.5. Tres en raya virtual

Se ha mencionado que este sistema debería ofrecer la posibilidad de jugar a juegos. En

concreto se ha implementado como juego las 3 en raya en dos modalidades: la modalidad

virtual, que es la que se va a tratar aquí, y la física, que será tratada en el siguiente apartado.

Analizando esta tarea, el objetivo es proporcionar la funcionalidad necesaria para poder

jugar a las 3 en raya en una versión que imprima por pantalla el tablero de juego. Como base de

esta tarea se ha partido de una implementación de código libre de dicho juego (21). A partir de

ella se ha modificado lo suficiente como para poder incluir dos partes: un servidor que se

encargue de la comunicación con el módulo de comportamiento y un cliente que es el que lleva

el control del juego. El cliente será el resultado de la aplicación inicial adaptada suficientemente

como para que las respuestas del jugador provengan de conceptos reconocidos.

La forma en la que ha sido implementada la inteligencia artificial de este tres en raya es

mediante fuerza bruta. El sistema analiza todas las alternativas posibles tras un movimiento y

asigna una puntuación a cada movimiento en función de las veces que haya conducido a ganar o

a perder la partida. Finalmente, la elección final se hace en base al movimiento que haya tenido

más puntuación.

require HTTP::Request; require LWP::UserAgent; use HTTP::Cookies; $cookie_jar = HTTP::Cookies->new; $ua = LWP::UserAgent->new; $busqueda=$ARGV[0]; #$busqueda="http://multiwordnet.itc.it/online/multiwordnet-main.php?language=spanish&field=word&word=tipo&wntype=Overview&pos="; $request = HTTP::Request->new(GET => $busqueda); $cookie_jar->add_cookie_header($request); $response = $ua->request($request); if ($response->is_success) { print $response->content; } else { print $response->error_as_HTML; }

printf "\n";

Figura 51. Script en Perl para el control de dispositivo X10


En la figura se ve el árbol que se generaría tras un supuesto

este movimiento se abren tres alternativas o movimientos (N+1). Cada uno de ellos se desglosa

en otros tantos movimientos (N+2). Finalmente, tras i iteraciones, se llega al movimiento N+i

desde donde algunos conducen a ganar (a ést

derrota (se les asigna -1). Posteriormente se recorre el árbol hacia atrás asignando a cada rama

el valor de la suma de todas las ramas que se deriven de ella. De esta forma se llega a los valores

finales, +3, -1 y -2 que hacen que se elija el movimiento de la parte izquierda del árbol

éste es el de la puntuación más elevada.

Una de las características que hacen distinta esta versión de juego de la implementada

físicamente es que ésta es una modalidad de

irán poniendo fichas hasta que el tablero quede sin espacios que rellenar. De esta forma se

puede llegar a la situación de un empate.

5.6. Tres en raya físico

Esta tarea se encarga de la versión física del ju

partido del trabajo realizado en el laboratorio de sistemas electrónicos digitales por parte de los

Figura 52.

- 105 -

En la figura se ve el árbol que se generaría tras un supuesto movimiento enésimo. Para



desde donde algunos conducen a ganar (a éstos se les asigna un 1) y algunos conducen a la

1). Posteriormente se recorre el árbol hacia atrás asignando a cada rama


2 que hacen que se elija el movimiento de la parte izquierda del árbol

es el de la puntuación más elevada.

acterísticas que hacen distinta esta versión de juego de la implementada

físicamente es que ésta es una modalidad de relleno de tablero. En este sentido, los jugadores


puede llegar a la situación de un empate.

Tres en raya físico

Esta tarea se encarga de la versión física del juego tres en raya. Para realizarla se ha


Figura 52. Secuencia de cálculo del mejor movimiento.

movimiento enésimo. Para



os se les asigna un 1) y algunos conducen a la

1). Posteriormente se recorre el árbol hacia atrás asignando a cada rama


2 que hacen que se elija el movimiento de la parte izquierda del árbol, pues

acterísticas que hacen distinta esta versión de juego de la implementada

relleno de tablero. En este sentido, los jugadores


ego tres en raya. Para realizarla se ha


Secuencia de cálculo del mejor movimiento.


- 106 -

alumnos Enrique Fueyo Ramírez y Juan Carlos Hernández Munuera que durante el curso 2008

2009 trabajaron en la mejora de una versión del tres en raya con brazo robótico realizada por

José Manuel Cano y Jorge Blanco durante el curso 2007 2008. En concreto, la versión inicial

partía de la definición de una práctica básica y se centraba en conseguir, entre otras cosas,

implementar un juego de 3 en raya al que se pudiese jugar mediante un teclado matricial. Como

mejora surgió la inclusión de un brazo robótico que recrease en un tablero la situación del juego.

Partiendo de esta base, los alumnos del 2008 2009 trabajaron en desarrollar una matriz de

sensores infrarrojos que permitieran detectar la posición de las piezas y, de esta forma, dejar

como opcional el teclado matricial. Bastará con mover una pieza físicamente para que el sistema

detecte el movimiento y genere una respuesta que será llevada al tablero por el brazo robótico.

Además, con vistas a la integración con otros proyectos como este, basados en el

comportamiento emocional, el sistema genera, en un archivo remoto mediante protocolo trivial

ftp, información acerca de la situación del juego. Esta situación básicamente consiste en el

estado del juego (activo o no), el resultado de la partida, (ganar, perder o empate) y la presencia

o no de trampas.

Aunque la información que puede enviar la tarea contempla el empate, este juego

implementa la modalidad en la que cada jugador puede tener sobre el tablero un máximo de

tres fichas cada uno y, por tanto, podrá moverlas. De esta forma se elimina la posibilidad de

empatar.

Este juego presenta un funcionamiento autónomo. La tarea encargada de su control

simplemente lee periódicamente el archivo de resultados y determina la respuesta emocional

pertinente. En este sentido esta tarea podría ser implementada únicamente como un proceso

periódico dentro del módulo principal. No obstante, con el fin de estandarizar lo máximo posible

el sistema se han definido dos partes, un servidor, que se encarga de la comunicación con el

módulo de comportamiento y un cliente que se encarga de revisar periódicamente el archivo

para solicitar una nueva respuesta emocional.

5.7. Control Conversación

Esta tarea es algo diferente al resto. No se centra en el control de un dispositivo para

realizar una acción. Por el contrario, esta tarea trata de constituir un módulo de gestión de la


conversación que, para los conceptos recibidos, sea capaz de generar una respuesta tanto verbal

como emocional. De esta forma, la tarea constará de dos partes: un servidor que, como siempre,

se encargará de la comunicación con el módulo de comportamiento; y un cliente que recogerá l

relación de respuestas a cada concepto reconocido.

En resumen, el comportamiento de esta tarea es el siguiente: El reconocedor entrega un

nuevo concepto al módulo de comportamiento que realiza la transmisión a la tarea mediante el

servidor. Una vez el concepto llega al cliente éste lo analiza y determina la respuesta pertinente

devolviéndola al servidor que, a su vez, la entregará al módulo de comportamiento donde

finalmente irá a los módulos correspondientes. Viéndolo con un ejemplo, si se recibe un insu

esta tarea decidirá que es una acción que afecta negativamente a las emociones y, además,

generará una solicitud de síntesis al sintetizador eligiendo una frase relacionada con insulto.

5.8. Resumen de tareas

Como se ha visto, cada tarea tiene un objetivo específico

estructura común que permite que cualquier nueva tarea pueda ser incluida de forma sencilla.

Es preciso definir un servidor para cada tarea que implemente

todas ellas y que permita la interconexión

- 107 -

conceptos recibidos, sea capaz de generar una respuesta tanto verbal


se encargará de la comunicación con el módulo de comportamiento; y un cliente que recogerá l

relación de respuestas a cada concepto reconocido.



ncepto llega al cliente éste lo analiza y determina la respuesta pertinente


finalmente irá a los módulos correspondientes. Viéndolo con un ejemplo, si se recibe un insu



Resumen de tareas

ha visto, cada tarea tiene un objetivo específico, pero todas ellas comparten una


finir un servidor para cada tarea que implemente las funciones comu

y que permita la interconexión con el módulo de comportamiento

Figura 53. Esquema de arquitectura de tarea

conceptos recibidos, sea capaz de generar una respuesta tanto verbal


se encargará de la comunicación con el módulo de comportamiento; y un cliente que recogerá la



ncepto llega al cliente éste lo analiza y determina la respuesta pertinente


finalmente irá a los módulos correspondientes. Viéndolo con un ejemplo, si se recibe un insulto



pero todas ellas comparten una


las funciones comunes a

con el módulo de comportamiento y, por extensión,


- 108 -

con el resto del sistema (interfaz de entrada, de salida y sistema emocional). La forma de

comunicación entre servidor y módulo de comportamiento será mediante llamadas locales.

Por otro lado, la tarea deberá incluir un cliente que implemente el funcionamiento

específico de la tarea y, en el caso en el que sea necesario, debe ser capaz de manejar elementos

específicos de la tarea como comunicación por bluetooth, comunicación por infrarrojos, control

X10, etc. La forma de comunicación con estos elementos específicos de las tareas no puede ser

generalizada, siendo cada tarea la encargada de implementar la opción necesaria.

El comportamiento emocional de cada tarea, es decir, el tipo de eventos que pueden

ocurrir en el contexto de una tarea y su influencia en el sistema emocional es un tema que será

tratado en el siguiente apartado. Así mismo, la relación de conceptos que pueden ser

reconocidos asociados a cada tarea aparece definida en el correspondiente apéndice.

Capítulo 6 – Emotividad

- 109 -


6 EMOTIVIDAD

Desde sus inicios, las máquinas se han topado con un rechazo por parte de muchas

personas. Este rechazo sienta sus bases en el comportamiento monótono y siempre lógico de las

máquinas, que muchas veces realizan acciones que, desde el punto de vista de las personas,

pueden resultar ilógicas, ya que las motivaciones de los sistemas no siempre se aprecian desde

el prisma de usuario. Esta situación es totalmente contraria a la intención de que las máquinas

estén realmente integradas en el entorno cotidiano de las personas proporcionando servicios

como compañía, cuidados, entretenimiento, monitorización de pacientes, ayudas en terapias,

etc. Los sistemas no pueden ser simplemente sacados de su plataforma de desarrollo y puestos

en la vida real. Es necesario un proceso de adaptación a un entorno cambiante y que es solo


- 110 -

parcialmente conocido. Así mismo, la personalización del comportamiento para los usuarios y

compañeros son características necesarias para lograr una integración exitosa a largo plazo. Por

tanto, será necesario el desarrollo de mecanismos capaces de funcionar bajo cualquier contexto

adaptándose al entorno. Con esta idea nacen multitud de sistemas. A continuación se exponen

algunos ejemplos:

• iCat the affective Chess Player: (22) Este proyecto del Instituto Superior Técnico

de la Universidad Técnica de Lisboa trata de la creación de un jugador emocional

de ajedrez. El sistema es capaz de detectar la posición de las piezas durante la

partida y, además de busca un movimiento para ganar, analiza emocionalmente la

partida y genera respuestas emocionales.

• Proyecto Feelix Growing: (23) Es un proyecto creado en 2006 hasta 2010 y

financiado por la Comisión Europea. Su objetivo es la investigación interdisciplinar

de un desarrollo social apropiado desde una perspectiva global o integrada como

un elemento clave hacia la consecución de robots que interaccionan con humanos

en ambientes cotidianos de una manera rica, flexible, autónoma y centrada en el

usuario. Entre los proyectos de esta línea de trabajo destaca la creación de una

guardería de robots compuesta por Aibos. Estos robots simulan el

comportamiento de bebés aprendiendo sobre emociones. Los participantes de

este proyecto son: La Escuela de Ciencias de la Informática de la Universidad de

Herthfordshire; El Centro Nacional Francés de Investigaciones Científicas; El

equipo de Neurocibernética, del laboratorio de Equipos de Tratamiento de

Imágenes y de Señales, dependiente de la universidad Cergy Pontoise y de ENSEA

(Escuela Superior Nacional de Electrónica y sus Aplicaciones); El Laboratorio de

Algoritmos de Aprendizaje y Sistemas, de la Escuela Politécnica Federal de

Figura 54. iCat Chess Player


- 111 -

Laussane; El Centro para el Estudio de Emociones, de la Universidad de

Portsmouth; El Laboratorio de Imagen, Vídeo y Sistemas Multimedia Inteligentes,

del Instituto de Comunicación y Sistemas Informáticos de la Universidad Técnica

Nacional de Atenas; Entretainment Robotics, compañía del grupo Adaptronics; y

Aldebaran Robotics.

• Robot Urbano: Este proyecto está realizado de forma conjunta por el Grupo de

Automática DISAM de la ETSII y por el GTH de la ETSIT. Persigue fomentar la

integración, en la sociedad, de técnicas relacionadas con la automática (control

inteligente, navegación de robots autónomos, ingeniería de software), mediante

el uso de nuevas tecnologías de la información (protocolos de Internet, interfaces

web y habla) que faciliten una comunicación amigable con el ciudadano. Para ello

se ha creado un cuerpo artificial móvil con un cierto nivel de autonomía. El

objetivo es permitir el acceso personalizado de ciudadanos a lugares públicos, así

Figura 55. Guardería robótica del proyecto Feelix Growing

Figura 56. Urbano en una exposición


- 112 -

como una interacción fluida con la información y con otros ciudadanos allí

presentes.

A la vista de estos ejemplos se extrae que la emotividad está llamada a jugar un papel

principal en el desarrollo de sistemas inteligente. En este sentido ha sido incluida como parte del

sistema de este proyecto. Nace de la idea de elevarlo a la categoría de compañero, ya que

tendrá más aceptación por parte de los usuarios si se puede interaccionar con él de una forma

más cercana. Para conseguirlo es necesaria la implementación de dos funcionalidades.

La primera está recogida en el modelo de relaciones y trata sobre la adaptación del

sistema a su relación con el usuario. Es decir, en un entorno domótico como el que se establece,

es necesario que el sistema sea capaz de recordar su relación con el usuario y modificar su

comportamiento en función de ella. De otra forma, la interacción con el sistema se podría

asemejar a dos personas que viven juntas, pero que, cada día que se cruzan por el pasillo, se

presentan como si no se conocieran. Obviamente esta situación generaría rechazo por parte de

los usuarios.

La segunda funcionalidad es más ambiciosa y trata la idea de generar artificialmente

emociones. De este modo, el sistema tiene un comportamiento cercano al humano, pudiendo

realizar las tareas, como por ejemplo los juegos, de una manera más natural. Mediante este

comportamiento la interacción persona máquina se mejora sustancialmente intentando que el

usuario tenga la sensación de estar comunicándose casi con un igual. De hecho, la inteligencia

artificial (IA) resulta realmente interesante para las personas cuando presenta, al menos, un

mínimo de comportamiento emocional. Esto es debido a que si un sistema se comporta

únicamente basándose en la lógica sería altamente predecible y aburrido para los humanos. Por

el contrario, si el comportamiento es emocional a menudo se escapa de la lógica y genera

sistemas menos predecibles. De hecho, la investigación emocional se encuentra en un punto de

máxima actividad. Hay multitud de grupos de investigación por todo el mundo que se centran en

esta disciplina.

La importancia de la IA queda patente en palabras del MIT, en el cual se ha creado un

grupo de inteligencia emocional (Affective Computing Group), que describe la necesidad de

desarrollar sistemas emocionales de la siguiente manera:

“La importancia de esto se desprende de los trabajos de Damasio y otros que han


- 113 -

estudiado a los pacientes que esencialmente no tienen "suficientes emociones" y, en

consecuencia, sufren de deterioro en la toma de decisiones racionales. La naturaleza de su

discapacidad es extrañamente similar a la que presentan en la actualidad las máquinas

booleanas de toma de decisiones, y a la frágil inteligencia artificial de los sistemas expertos. Los

hallazgos recientes indican que, en los seres humanos, las emociones son esenciales para una

toma de decisiones flexible y racional. Nuestra hipótesis es que serán esenciales para que las

máquinas también presenten una toma de decisiones flexible y racional, así como un

pensamiento verdaderamente creativo y una variedad de capacidades cognitivas a semejanza de

los humanos" (24).

Sin embargo, aunque el trabajo de Damasio es bastante reciente, su postura no es nueva.

De hecho puede ser trazada hasta los años sesenta. No obstante, fue olvidada por la mayoría de

los investigadores hasta que la incapacidad de los sistemas para realizar actividades complejas

de manera autónoma ha revivido el interés por este tipo de alternativas.

A continuación se entrará en detalle sobre cada uno de los dos componentes del módulo

de emotividad. En primer lugar se analizará el modelo de relaciones implementado obteniendo

unas conclusiones específicas de este módulo. Seguidamente se analizará el modelo emocional

haciendo un breve repaso a las diferentes teorías emocionales existentes y entrando en detalle

sobre la arquitectura definida. Finalmente, también se ofrecen una serie de conclusiones

específicas de este modelo.


- 114 -

6.1. Relaciones

La adaptación de las máquinas a los usuarios es un concepto que ha estado presente casi

siempre. Si se piensa en los ordenadores personales, se puede encontrar un claro ejemplo de

esto en la personalización de los escritorios. También los asientos eléctricos de algunos

automóviles poseen memoria y permiten adoptar la postura deseada del usuario de forma

automática una vez identificado de quién se trata. En la actualidad el grado de personalización

de los teléfonos móviles va desde el tono de llamada, pasando por el fondo de pantalla, hasta

incluso poder elegir las aplicaciones que corren en primer plano. En definitiva, es obvio que la

relación entre personas y máquinas requiere que estas últimas sean personalizables para que el

usuario experimente una utilización más satisfactoria.

6.1.1. Modelo de Relaciones implementado

La implementación realizada sigue el concepto de que las máquinas deben poseer

autonomía para adaptarse a cualquier situación. Es decir, resulta interesante que la

personalización según el tipo de usuario se haga de forma automática. Esto significa que el

sistema debe ser capaz de: primero, identificar de quién se trata; segundo, monitorizar la

relación; y tercero, adaptar el comportamiento en función de la relación. En otras palabras, si un

usuario X inicia una interacción con el sistema, éste debe ser capaz de identificarle y determinar

la relación que mantienen. Si ese usuario X realiza otra acción como una alabanza, el sistema

tiene que detectarla y determinar cómo afecta a su relación. Además, las acciones que realiza el

sistema deben estar condicionadas por la relación. Así por ejemplo, las palabras que elija a la

hora de sintetizar voz para un concepto vendrán determinadas por la relación con su

interlocutor.

Para la caracterización de la relación entre el sistema y las personas se ha utilizado una

máquina de estados de Moore. La relación con la persona es un estado determinado y en

función de que se cumplan las condiciones de transición la relación evolucionará.

Como se puede ver, el sistema se compone de tres estados:

• Desconocido: Este es el estado por defecto de cualquier usuario. Cuando se

presenta por primera vez a un usuario, se clasifica según este tipo y se inicia

automáticamente un proceso de presentación. Este proceso consta de una serie


- 115 -

de preguntas que el sistema utilizará como modelo del nuevo usuario para una

mejor identificación en el futuro.

• Conocido: Este es un estado intermedio de transición. En él se intenta recoger el

comportamiento frente a un usuario con el que se ha interaccionado varias veces,

pero no las suficientes como para considerarle amigo. La confianza con la que se

trata al usuario es mayor que en desconocido. La transición al siguiente estado se

realiza en función del número de interacciones entre usuario y sistema. Este

número puede ser modificado para simular una personalidad más o menos

extrovertida. No obstante, un valor excesivamente bajo puede causar un rechazo

por parte del usuario ya que el sistema haría amigos demasiado rápido. Para la

implementación realizada se ha considerado un valor de 17 iteraciones de modo

que el fenómeno se pueda apreciar en relativamente poco tiempo.

• Amigo: Este es el estado de máxima confianza. La relación entre sistema y usuario

trata de acercarse a una relación entre dos amigos cualesquiera. Se ha

considerado que este es el estado final. No obstante, podría establecerse que un

usuario sea capaz de perder el estatus de amigo.

En el sistema implementado el modelo de relaciones reside en el servidor del reconocedor

de voz. Consiste en una capa intermedia que analiza la información (frase, concepto asociado a

la frase, número de locutor y número de frases del locutor) recibida del reconocedor antes de

que sea enviada al resto del sistema.

Figura 57. Esquema del modelo de relaciones


- 116 -

6.1.1.1. Actualización de usuarios

El funcionamiento del modelo de relaciones es sencillo. Cada vez que se reconoce una

nueva frase el contador de frases asociadas al usuario se aumenta manteniendo inalterado el

comportamiento del sistema. Además se analiza si se satisface cada una de las condiciones de

transición entre los estados de relaciones. Todas estas acciones se realizan incluso dentro del

proceso de presentación.

Para contabilizar las frases de los usuarios así como almacenar información acerca de

ellos, el modelo de relaciones se apoya en un archivo de texto generado en tiempo de ejecución.

En este archivo se va almacenando la información relativa a los distintos usuarios del sistema.

De esta forma, al recibir una nueva frase, el sistema buscará en el archivo al locutor pertinente e

incrementará su contador. Además, analizará el valor de este contador y determinará en qué

estado se encuentra su relación con ese locutor (desconocido, conocido, amigo) actualizándola

en caso necesario. Finalmente, a lo largo del proceso de presentación, el sistema irá

almacenando la dirección de los archivos de audio donde se encuentra la información que se ha

ido solicitando al locutor (e-mail, trabajo…), así como el nombre del usuario. El formato del

archivo de texto es el siguiente.

Se puede apreciar el ejemplo de un usuario identificado como “_1” que ha realizado seis

locuciones, cuyo estado es desconocido (UKWN) y que se llama Carlos. Además aparece el

conjunto de archivos donde se encuentra cada una de las grabaciones: profesión, correo

electrónico….

usuario (numFrases) -->Relacion Nombre archivoDeTrabajo archivoDeMail archivoDeNacimiento archivoDeDomicilio

<_1 (00006) -->UKWN &Carlos $..\datavoz\Grabaciones\juancho_0_16.wav

@..\datavoz\Grabaciones\juancho_0_17 º..\datavoz\Grabaciones\juancho_0_18.wav

*..\datavoz\Grabaciones\juancho_0_19.wav >


- 117 -

6.1.1.2. Presentación de nuevos usuarios.

Aparte de monitorizar el estado de las relaciones, este módulo se encarga del proceso de

presentación de un nuevo usuario. Es decir, cuando se le indica que se va a presentar a un nuevo

usuario, el módulo toma el control del sistema y realiza una serie de acciones que conducen a

que, finalmente, el nuevo usuario quede caracterizado, para que el sistema de identificación

tenga información suficiente. Este funcionamiento se basa en una máquina de estados. Las

entradas son conceptos proporcionados por el reconocedor y la salida son frases a sintetizar e

información para el cliente del reconocedor. Concretamente, el locutor al cual debe asignarse la

frase y si el modo de presentación se encuentra activo o no. En la figura se puede ver el

esquema de esta máquina.

Inicialmente se parte del estado “Por defecto”. Este estado constituye el funcionamiento

normal del servidor de reconocimiento. Es decir, cuando se recibe un concepto se actualiza el

número de versión del reconocedor y el módulo de comportamiento se encargará de enviarlo a

todos los demás módulos. Además, se envía al cliente de reconocimiento el locutor al que debe

asignarse la frase (en este estado coincide con el proporcionado por el identificador) así como el

Figura 58. Máquina de estados del proceso de identificación


- 118 -

indicador de modo de presentación (en este caso 0 ó modo normal). No obstante, el servidor

está a la espera del concepto “presentación”. Cuando se recibe este concepto se pasa al

siguiente estado (confirmar nuevo usuario) y se sintetiza una frase que pregunte explícitamente

si hay alguien nuevo. A partir de este estado los conceptos reconocidos dejan de ser

transmitidos al resto del sistema de modo que sólo se utilizan en la máquina de estados. Esto es

así hasta el estado “Fin de presentación” o hasta el estado “por defecto”

En el estado “Confirmar nuevo usuario” se devuelve el usuario que ha identificado el

sistema como el autor de la frase y el modo de presentación sigue desactivado. Además el

sistema permanece a la espera de uno de los dos conceptos posibles: sí (Y) y no (N) ignorando

los demás. En el caso de que el concepto reconocido sea “N” el sistema vuelve al estado “por

defecto”. En cambio, si se reconoce “Y” se pasará al siguiente estado (Nombre) sintetizando una

frase que pregunte el nombre del nuevo locutor.

En “Nombre” se devuelve al cliente un nuevo locutor para que se le asignen las frases. A

partir de este momento, durante el resto del proceso, el locutor al que deben asignarse las

frases será a éste que se acaba de crear (candidato) independientemente de lo que decida el

identificador. Este es el último estado en modo normal, de esta forma lo que se reconozca

puede ser comprendido, permitiendo que el sistema almacene el nombre del usuario. Cuando se

recibe una nueva frase se sintetiza una respuesta que pregunte sobre la profesión del locutor y

se guarda en un archivo la frase de lo que el usuario dijo que era su nombre. Además se pasa al

estado “Profesión”.

“Profesión” es otro estado de recepción de información genérico. En él se espera una

frase del reconocedor sin importar el contenido. De hecho, el umbral de confianza es cero y, por

tanto, es casi seguro que lo que se reconozca no sea asociado a ningún concepto. Cuando se

recibe la frase, el sistema almacena en un archivo la dirección del archivo de audio que contiene

lo que se ha grabado como profesión. Además devuelve al cliente el locutor candidato (al que se

le tiene que asignar esa frase independientemente de que haya sido o no identificado como el

locutor que la realizó) y se habilita el modo de presentación. Como respuesta al usuario, se

sintetiza una frase solicitando el correo electrónico del locutor. El resto de estados presentan

comportamientos similares. Se recibe una frase reconocida que responde al concepto solicitado

en la transición del estado anterior y se almacena en un archivo. Además se genera una frase de

síntesis que solicita la información que actuará como evento de cambio al siguiente estado. En

todos estos estados el locutor que se devuelve al cliente es el candidato y el modo de


- 119 -

presentación permanece activo. La finalidad del modo de presentación es que el umbral de

confianza del reconocedor sea cero. De esta forma se pueden reconocer todo tipo de palabras

aunque no estén definidas en el vocabulario de ejemplo. No obstante, obrando de así se corre el

riesgo de que un ruido durante el proceso de reconocimiento sea admitido y, por tanto, la

información de identificación de usuario se corrompa. En este sentido es especialmente

importante un control de los posibles ruidos durante el proceso de identificación.

Por último se llega al estado “Lugar de residencia”. En este estado se recibe la

información a la pregunta sobre dónde vive y se almacena en un archivo. Como respuesta se

sintetiza una frase de fin de presentación, esto puede ser “encantado de conocerte”, y se pasa al

estado “Fin de presentación”. “Lugar de residencia” sigue devolviendo el locutor candidato y

modo de presentación activado.

Finalmente, se llega al estado “Fin de presentación”. En este estado el locutor que se

devuelve pasa a ser el identificado por el módulo de identificación. Además, la transición al

estado “por defecto” se realiza al recibir la solicitud de modo de presentación por parte del

cliente.

6.1.2. Influencia de relaciones en el comportamiento del

sistema

Este modelo de relaciones es muy potente pues genera una gran variedad de alternativas

a la hora de adaptar un sistema a un usuario. No obstante, por sí solo no es más que una

posibilidad. Es necesario que los módulos que constituyen el sistema tengan en cuenta la

información de la relación con el usuario y sean capaces de adaptar su comportamiento a ella.

En el modelo implementado se ha decidido mostrar un ejemplo concreto y fácilmente

apreciable, mediante la síntesis de voz, de la capacidad que se menciona. En concreto, cada vez

que un módulo del sistema desea sintetizar una frase, ésta es escogida atendiendo a la relación

con el último locutor detectado. Por ejemplo, para generar una despedida existen varias

alternativas:

• Para un usuario desconocido: “Mucho gusto hasta otro momento.”

• Para un usuario conocido: “Hasta luego.”

• Para un amigo: “¡Nos vemos!”


- 120 -

Sin embargo, el abanico de adaptaciones posibles en las tareas es enorme. De hecho,

incluso las emociones podrían verse alteradas en función del usuario, de esta forma un insulto

podría generar enfado si proviniese de un desconocido, o apenas alterar el estado emocional si

proviene de un usuario amigo.

6.1.3. Conclusiones sobre el modelo de relaciones

El modelo de relaciones se trata de modelar un comportamiento social. En este sentido

especificar una serie de estados que satisfagan a todos es complejo ya que cada uno entiende

las relaciones interpersonales a su manera. De hecho, una persona puede considerar a otra

como su amigo no siendo así en el otro sentido. Además, es comprensible que cada persona

entienda el tipo de estados posibles de formas distintas. De todo ello se deduce que en la

implementación de este modelo existe un componente implícito que no se ha tenido en cuenta

directamente: La personalidad del sistema. Es decir, las condiciones pueden hacer un sistema

más o menos extrovertido, mientras que la definición de estados puede llevar a, por ejemplo, un

sistema rencoroso (un número de insultos conduce a un estado de enemistad). Finalmente, en

pro de realizar un modelo simplificado que exponga la idea, se ha considerado que los estados

definidos son suficientemente significativos, aunque cabría añadir muchos más.


- 121 -

6.2. Emociones

Las emociones han estado presentes en la IA desde sus inicios. Si bien su relevancia ha

sufrido una importante evolución. Inicialmente, las emociones no eran más que una

característica suplementaria en sistemas de procesos cognitivos. Este tipo de sistemas se

caracteriza por un conjunto de tareas bien definidas en función de un entorno conocido. En ellos

las emociones cobran un papel opcional, es decir, el sistema puede funcionar perfectamente sin

presencia de emociones (25). Como alternativa a este tipo de sistemas aparece la inteligencia

emocional. Los sistemas de inteligencia emocional se basan en torno a la creación de un modelo

de emociones como parte central.

En los inicios de la inteligencia emocional los modelos usaban una simplificación del

complejo entorno que rodea a un sistema. Estaban basados en un conjunto de reglas

deterministas que definían el estado emocional en función del entorno. Estos sistemas llamados

razonadores (“Reasoners”) demostraron sus limitaciones. Es decir, una descripción exhaustiva

del entorno resulta imposible ya que éste es cambiante e imposible de predecir en su totalidad.

Por ello, para realizar un sistema más o menos completo, se requería una gran cantidad de

casos, lo que requería una cantidad importante de recursos y, en consecuencia, aumentaba los

tiempos de decisión. En definitiva, una solución inviable.

Frente a estos sistemas aparecieron aquellos basados en modelos psicológicos. Estos no

establecen reglas causa-efecto para cada evento del entorno, sino que intentan simular los

procesos humanos que ocurren durante la generación de emociones. Esto significa dotar al

sistema de los mecanismos necesarios para que sea capaz de hacer frente a un cambio del

entorno que nunca había experimentado y poder responder, emocionalmente, en consonancia

con él. (26). Es decir, donde en el pasado la investigación en IA buscaba una representación del

conocimiento, ahora busca el desarrollo de agentes inteligentes autónomos.

El interés en desarrollar agentes inteligentes autónomos radica en los requisitos prácticos,

por ejemplo, la exploración espacial. Enviar un robot a explorar un planeta como Marte significa

hacer funcionar a un sistema en un entorno desconocido y, por tanto, confiar en que el sistema,

de forma autónoma, sea capaz de explorar y reaccionar. Otro ejemplo es desarrollar agentes

que accedan a internet y sean capaces de determinar, de forma autónoma, qué tipo de

información será de utilidad para el usuario. Aplicando esta idea a un agente emocional, debería

ser capaz de adaptarse emocionalmente a una situación que puede no estar contemplada


- 122 -

explícitamente en el momento del diseño, pero que, gracias a su autonomía, puede ser

procesada igualmente.

A continuación se va a hacer un breve repaso de las teorías que persiguen la creación de

sistemas emocionales. De esta forma se espera crear una visión general que permita entender la

solución propuesta.

6.2.1. Estado del arte: Teorías emocionales.

En la actualidad la teoría de la evaluación o “Appraisal Theory” se sitúa a la vanguardia de

las teorías psicológicas que definen el comportamiento emocional de las personas. Esta teoría

postula la idea de que las emociones son consecuencia de los juicios (“appraisals”) que una

persona realiza de los eventos que ocurren en su entorno. En otras palabras, la evaluación de

una situación provoca una respuesta emocional que está basada en esa misma evaluación. Un

ejemplo de esta teoría es una primera cita. Si la velada es evaluada como positiva, uno puede

sentir felicidad, alegría, vértigo, emoción y/o anticipación porque se ha evaluado este evento

como algo que podría tener efectos positivos a largo plazo, es decir, comenzar una nueva

relación, compromiso o incluso matrimonio. Por otro lado, si la cita es evaluada como negativa,

las emociones, en consecuencia, podrían incluir abatimiento, tristeza, vacío o incluso miedo.

(27).

La importancia de esta teoría en el panorama psicológico que trata de caracterizar los

procesos que generan las emociones radica en que es la única capaz de llenar el vacío que dejan

las demás. Esto es: (28)

• Permite determinar tanto el grado como el tipo de respuesta emocional para

una situación: Inicialmente se consideró la respuesta emocional como un

problema unidimensional. Sin embargo, con el paso del tiempo, esa teoría fue

expandida para incorporar una componente de positividad o negatividad de modo

que las respuestas emocionales se modelan como un sistema bidimensional. En

consecuencia existen varias emociones distintas como alegría, tristeza, miedo…

tal y como se manifiesta en la observación de las expresiones faciales de

diferentes culturas. Esto revela que las emociones son más generales de lo que se

pensó en un principio por lo que dos ejes resultan escasos. La Appraisal Theory

ayuda a explicar el problema del grado y el tipo de cambios emocionales.


- 123 -

• Permite explicar las diferentes respuestas emocionales de los individuos ante la

misma situación: Sin tener en cuenta esta teoría, cada estímulo debería provocar

la misma reacción en cada individuo que lo recibiese. En cambio, según la

Appraisal Theory, un estímulo va a provocar diferentes respuestas en cada

individuo dependiendo del contexto precedente a la estimulación. Por ejemplo, si

una amistad está llegando a su fin, una persona podría probablemente sentirse

triste, culpable o furiosa. Sin embargo la otra persona posiblemente sienta alivio o

apatía. Es decir, acorde al punto de vista que cada individuo tiene de la amistad,

su respuesta emocional a una ruptura de la relación será muy diferente.

• Tiene en cuenta la matriz de estímulos que causa respuestas emocionales

similares: No hay manera de cuantificar todos los estímulos que conducen a una

respuesta emocional concreta. Cualquier tipo de contexto que se considere

apropiado para producir una respuesta emocional determinada puede producir

cualquier emoción. Otro tipo de teorías son incapaces de explicar este hecho. Sin

embargo la Appraisal Theory sí es capaz.

• Tiene en cuenta los desencadenantes de la respuesta emocional: Esta teoría

tiene en cuenta el hecho de que las respuestas emocionales no se obtienen de la

nada. Es decir, la respuesta a un estímulo se ve intensificada dentro del contexto

de la situación. Por ejemplo, una persona ha perdido a su madre y al mes

siguiente muere un conocido. La respuesta emocional a la pérdida del conocido se

ve intensificada por el hecho de haber perdido recientemente a la madre.

• Permite determinar la respuesta emocional más pertinente: Es decir, si se

reacciona con enfado a una situación en la que el enfado resultaría en una pérdida

de energía, se está afrontando la situación de un modo ineficiente. Las respuestas

emocionales están desarrolladas de modo que el gasto de energía sea el mínimo

que permita manejar la situación.

• Es capaz de explicar la existencia de respuestas emocionales absurdas: Esta

teoría ayuda a clarificar por qué respuestas emocionales irracionales son

correctas. Otras teorías, que establecen que las emociones tienen la función de

ayudar a conseguir los objetivos de las personas y que además pueden ser


- 124 -

inhibidas en cualquier momento, son incapaces de explicar estas respuestas

irracionales.

Como consecuencia de la robustez que presenta esta teoría psicológica, los sistemas

emocionales actuales la utilizan como base para obtener una respuesta emocional. La idea es

definir una forma de obtener atributos de evaluación y combinarlos para generar las emociones.

A continuación se describirán algunos de los modelos más relevantes. (29)

6.2.1.1. La teoría de Ortony, Clore and Collins

Esta teoría desarrollada en 1988 fue elaborada con vistas a posibilitar una implementación

en los ordenadores. Asume que las emociones se desarrollan como consecuencia de la

interpretación y de procesos cognitivos relacionados con los estímulos. Por tanto, se centra

exclusivamente en los desencadenantes cognitivos de las emociones. (30)

Los autores postulan que hay tres aspectos que determinan esos procesos cognitivos:

eventos, agentes y objetos. Los eventos son relevantes por sus consecuencias. Los agentes lo

son por sus acciones y los objetos por las propiedades que presentan.

Por tanto, esta teoría se desarrolla alrededor de la idea de que las emociones representan

reacciones proporcionales a la percepción del mundo. Es decir, uno puede sentirse complacido

o no con las consecuencias de un evento (agrado /desagrado); puede aprobar o rechazar las

acciones de un agente (aprobación/desaprobación); o puede gustarle o no las características de

un objeto (gusto/disgusto).

Una diferenciación más exhaustiva consiste en el hecho de que los eventos conllevan

consecuencias para uno mismo y para los demás y que un agente puede ser uno mismo u otra

persona. Las consecuencias de un evento para otra persona pueden ser catalogadas como

deseables o indeseables, mientras que las consecuencias para uno mismo pueden clasificarse,

atendiendo a las expectativas que generan, como relevantes o irrelevantes. Por último, las

expectativas relevantes para uno mismo pueden diferenciarse de nuevo si son confirmadas o no

confirmadas.

Atendiendo a esta clasificación se puede realizar un árbol con los diferentes criterios. En él

se puede ver cómo las diferentes emociones quedan determinadas por ciertas características.


- 125 -

En esta teoría la intensidad de un sentimiento emocional está determinada

principalmente por tres variables de intensidad: Desirability que está relacionada con la reacción

a eventos y es evaluada atendiendo a los objetivos. Praiseworthiness, que está relacionado con

la reacción a acciones de agentes y es evaluada en función de unas normas. Appealingness,

relacionado con la reacción a los objetos y evaluada en función a las actitudes.

A parte de estas tres variables de intensidad, esta teoría define un grupo de variables

secundarias, algunas de ellas globales y otras específicas, que sirven para complementar el

modelado de la intensidad emocional. El grupo de variables se encuentra en la siguiente tabla.

Figura 59. Estructura del tipo de emociones (30)


- 126 -

En la práctica, a cada una de estas variables se le asigna un valor y un peso. Además,

existe un umbral para cada emoción por debajo del cual no son percibidas.

Basándose en este modelo, la aparición de una emoción puede ser descrita mediante un

lenguaje formal. Sea 2�3, , �� la desirability (D) de un evento (e) para una persona (p) en un

cierto instante de tiempo (t). Esta función tiene un valor positivo para un evento deseable y un

valor negativo para uno no deseable. Además, sea 45�3, , �� una combinación de las variables

de intensidad globales y -6�3, , �� el potencial para un estado de alegría. De esta manera, la

regla para el estado de alegría puede ser:

78 �2�3, , �� > 0�

:;<= -6�3, , �� = %6�2�3, , ��, 4>�3, , ��

Donde la función %6 proporciona una nueva regla que permite determinar la intensidad

de la emoción 46 y hace posible la experiencia de la alegría. Si se establece un umbral para alegría

(?6�3, ��) entonces:

78 �-6�3, , �� > ?6�3, ��

EVENTS AGENTS OBJECTS

desirability praiseworthiness appealingness

sense of reality sense of reality sense of reality

proximity proximity proximity

unexpectedness unexpectedness unexpectedness

arousal arousal arousal

desirability for other strength of cognitive unit familiarity

deservingness expectation deviation

liking

likelihood

effort

realization

Tabla 3. Local variables in the theory of Ortony, Clore and Collins (30)


- 127 -

:;<= 46�3, , �� = -6�3, , �� − ?6�3, ��

<@A< 46�3, , �� = 0

Esto significa, que si el umbral de dicha emoción es superado se produce esa respuesta

emocional, pero si, por el contrario, el umbral no es superado, la emoción no es experimentada.

En este modelo cada emoción tiene sus propias formulas y, aunque los autores sólo formalizaron

algunas, defienden que todas pueden ser descritas de la misma manera, si bien admiten que,

con más emociones, esto sería mucho más complicado.

6.2.1.2. La teoría de Roseman

La teoría de Roseman fue elaborada en 1979 y revisada numerosas veces por él mismo.

Aunque ha sufrido muchos cambios, el enfoque en la appraisal theory permanece inalterado. La

ventaja de esta teoría es que provee una estructura que puede ser traducida fácilmente en

reglas, lo cual hace que tenga una gran aceptación en el desarrollo de IA. (31)

Roseman desarrolló su teoría basándose en unos doscientos informes sobre experimentos

emocionales. A partir del análisis de esos documentos estableció un modelo en el que seis

dimensiones cognitivas determinan cuándo surge una emoción y qué tipo de emoción es. Si bien

la composición de cada uno de estos niveles ha ido variando en diferentes revisiones. La versión

más actual sería la siguiente.

• La primera dimensión describe si una persona tiene una motivación que le

conduzca a una situación deseada o por el contrario que le aleje de situaciones

indeseadas. De esta forma, la dimensión caracteriza estados positivos y negativos.

• La segunda dimensión describe si la situación es acorde al estado de ánimo de la

persona o no. Para ello, la dimensión diferencia entre situación apetecible y

situación de adversa. Además, se establecen los estados motivación coherente:

que está ligado a los valores positivos de la primera dimensión (hacia situaciones

deseadas), y motivación incoherente, que está ligado a valores negativos de la

primera dimensión (hacia situaciones indeseada).


- 128 -

• La tercera dimensión describe si un evento es detectado como una certeza o

como una posibilidad. Esta dimensión, por tanto, establece lo seguro y lo posible.

Además incluye el estado inesperado determinante de la emoción sorpresa.

• La cuarta dimensión está relacionada con la evaluación de la capacidad para

controlar una situación. Esto establece los estados bajo y alto.

• La quinta dimensión describe quién es el causante del evento. Por tanto, se

definen los estados: circunstancias, otro o uno mismo.

• La última dimensión está relacionada con las emociones negativas. Se denomina

“tipo de problema” y describe si un evento es detectado como negativo, porque,

impida alcanzar un objetivo (con el resultado de frustración) o porque sea

negativo en su naturaleza (con el resultado de aborrecimiento). Esta dimensión

contiene los estados característico y no característico.

De la combinación de estas dimensiones y sus valores se puede elaborar una tabla de la

que, según Roseman, las emociones pueden ser obtenidas. Hasta hoy el modelo de Roseman no

ha podido ser probado empíricamente. Una debilidad es evidente: Existe un problema a la hora

de analizar una situación en la que una persona realiza dos apreciaciones diferentes. Por

ejemplo, si un estudiante cree que el examen de su profesor no es justo pero, al mismo tiempo,

reconoce que no se ha preparado lo suficiente para el examen. La teoría de Roseman no podría

determinar de forma clara qué emoción es la resultante, ya que en este caso dos estados de la

quinta dimensión estarían activos al mismo tiempo. No obstante, como se ha dicho al principio,

este modelo tiene gran aceptación en los círculos de IA debido a la facilidad que presenta

realizar una implementación que tenga en cuenta todos los estados.

6.2.1.3. La teoría de Scherer

En este modelo se establecen cinco subsistemas, los cuales están involucrados en los

procesos emocionales. Estos subsistemas son: (32)

• Un subsistema de procesado de información evalúa el estímulo de entrada

mediante la percepción, la memoria, la previsión y la evaluación de la información

disponible.


- 129 -

• Un subsistema de apoyo, que altera la situación interna gracias al control de los

estados neuroendocrinos, somáticos y autónomos.

• Un subsistema de elaboración de planes a seguir, que prepara las acciones y

selecciona entre posibles motivaciones en conflicto.

• Un subsistema de actuación controla las expresiones motoras y el

comportamiento visible.

• Un subsistema de monitorización, que controla la atención asignada a los estados

actuales y realimenta con esa información al resto de subsistemas.

Esta teoría se centra sobre todo en el primer subsistema, el de procesado de información.

Atendiendo a su teoría, este subsistema está basado en “appraisals” que son denominadas

controles de evaluación de estímulos (stimulus evaluation checks SEC). El resultado de estas

SECs ocasiona de nuevo cambios en los otros subsistemas. Scherer define cinco SECs básicos,

cuatro de los cuales poseen más variedades.

• El novelty check decide si el estímulo interno o externo ha cambiado; su sub-

características son: suddenness, confidence y predictability.

• El intrinsic pleasantness check especifica si un acercamiento al estímulo es

agradable o no y, por tanto, provoca tendencias de aproximación o evitación.

• El goal significance check decide si el evento contribuye o dificulta el objetivo de

la persona. Su sub-características son: goal relevance, probability of result,

expectation, support character y urgency.

• El coping potential check determina en qué medida cree la persona que tiene la

situación bajo control. Su sub-características son: agent, motive, control, power y

adaptability.

• El compatibility check compara el evento con normas internas y externas. Su sub-

características son: externality e internality

Por tanto, según este modelo, cada emoción puede ser claramente determinada por una

combinación de SECs y sub-características. En contraposición a la teoría de Roseman, esta teoría

ha sido apoyada empíricamente hasta el momento. De hecho, esta teoría constituirá el punto de

partida para el sistema emocional diseñado. En concreto, se adaptará la filosofía del primer

subsistema (procesado de información) mediante dos fases: las necesidades y las variables de

características.


- 130 -

6.2.1.4. La teoría de Frijda

Esta teoría postula que la palabra emoción no se refiere a un tipo natural. Establece que

no es posible referirse a un tipo de fenómenos bien definidos que sean claramente

diferenciables de otros eventos mentales o de comportamiento.

Para Frijda los procesos que provocan las emociones tienen mucho interés. De hecho el

centro de esta teoría es el término motivación. La motivación define la disposición de un sistema

a preferir una situación frente a otra, ya sea referida al entorno o al propio organismo. Por lo

tanto, las motivaciones producen objetivos (“goals”) y preferencias para el sistema de modo

que, el grado de dificultad del sistema para perseguir a sus motivaciones, es la causante de las

emociones. Además, la intensidad de cada emoción está determinada, esencialmente, por la

relevancia de la motivación.

En su teoría Frijda define seis características principales con las que se describe el

funcionamiento emocional del sistema.

• Detección de la relevancia de la motivación: El subsistema emocional determina el

significado de cada evento para los objetivos del sistema y lo anuncia a todos los demás

componentes mediante una señal denominada “affect”. Esto implica que el sistema

debe ser capaz de recoger información del entorno así como del propio sistema.

• Evaluación: La siguiente fase es que el significado del estímulo para las motivaciones sea

evaluado. Este proceso consta de dos pasos: evaluación de relevancia y evaluación de

contexto.

• Control de prioridad: Si la señal de relevancia es suficientemente intensa será capaz de

modificar las prioridades de la percepción, la atención y el procesado. Por tanto,

presentará una tendencia a afectar al comportamiento del sistema.

• Cambios en la disposición para actuar: Según esta teoría, esto representa el corazón de

la respuesta emocional. Modificando esta disposición se producen cambios en el

tratamiento de procesos, en los recursos de atención y en la tendencia hacia cierto tipo

de acciones.

• Regulación: Además de la determinación de la disposición para actuar, el sistema

emocional monitoriza todos los procesos del sistema general y los eventos del entorno


- 131 -

que pueden modificar la disposición para actuar. De esta forma es capaz de intervenir

apropiadamente.

• Naturaleza social del entorno: El sistema emocional se ajusta al hecho de que opera en

un entorno social. En este sentido, muchas categorías de evaluación son de naturaleza

social. De hecho, la disposición para actuar es mayoritariamente una predisposición a

acciones sociales.

En esta teoría se reconoce la tremenda necesidad de las emociones en sistemas que

poseen múltiples motivaciones en un entorno incierto. Si una ocurre situación que pueda poner

en peligro alguna de las motivaciones, se desarrollan las llamadas tendencias de actuación. Estas

tendencias están íntimamente ligadas a los estados emocionales y sirven como dispositivos de

seguridad para lo que, Frijda, denomina realización de la motivación (CR). Una lista de las

principales tendencias de actuación es la siguiente:

• Approach (Desire)

• Avoidance (Fear)

• Being-with (Enjoyment, Confidence)

• Attending (Interest)

• Rejecting (Disgust)

• Nonattending (Indifference)

• Agonistic (Attack/Threat) (Anger)

• Interrupting (Shock, Surprise)

• Dominating (Arrogance)

• Submitting (Humility, Resignation)

Además, según Frijda, un sistema emocional debe presentar los siguientes elementos;

• Motivaciones: Son representaciones internas mediante las cuales la situaciones

percibidas son probadas.

• Repertorio de acciones: Está formado por un conjunto de: reacciones instantáneas

de urgencia, señales sociales y mecanismos para desarrollar nuevos planes.


- 132 -

• Mecanismos de evaluación: Son mecanismos que establecen la relación entre

eventos y motivaciones así como conectan el control de acciones al repertorio de

acciones.

• Analizador: Consiste en la observación de la información que se está recibiendo y

la consiguiente codificación en función de sus implicaciones y consecuencias.

• Comparador: Prueba toda la información centrándose en la relevancia para las

motivaciones. El resultado son señales de relevancia. Estas señales activan el

sistema de actuación y el generador de diagnósticos. Además provocan un

incremento de la atención.

• Generador de Diagnósticos: Es el responsable de la evaluación del contexto,

escanea la información en función de las relevancias de cada acción. Realiza un

conjunto de pruebas (p.e. si las consecuencias de un evento son seguras o

inciertas, quién es el responsable…) y genera un perfil de evaluación.

• Evaluador: Las señales de acuerdo o discrepancia del comparador y el perfil del

generador de diagnósticos son combinados en una señal de relevancia final y un

parámetro de intensidad. Este parámetro indica la urgencia de una acción para el

sistema de actuación. La relevancia constituye lo llamado control de procedencia

de la señal.

• Proponedor de acciones: Prepara la acción seleccionando un camino de actuación

apropiado y habilitando los recursos necesarios.

• Actor: Genera la acción.


- 133 -

Esta composición de un sistema emocional puede ser formalizada de modo que sea capaz

de constituir las bases para un modelo informático. De hecho, ha sido utilizada en sistemas

como ACRES (33) y su evolución WILL (34).

6.2.1.5. La teoría de Oatley & Johnson-Laird

Oatley y Johnson-Laird desarrollaron su teoría con vistas a que pudiera ser implementada

como un modelo de ordenador. Percibieron la necesidad de elaborar su teoría en el hecho de

que la mayoría de los sistemas informáticos que modelaban la mente humana no consideraban

las emociones. En contraposición a este hecho, ellos situaron a las emociones como el centro de

la organización de los procesos cognitivos. (35)

Asumen una jerarquía de procesos concurrentes que tratan solicitudes formuladas por

tareas asíncronas. Estas solicitudes se coordinan por un sistema de control central o sistema

operativo. Éste sistema de control contiene un modelo del sistema completo. Los módulos que

componen el sistema se comunican unos con otros mediante dos tipos de comunicación:

Figura 60. Sistema emocional de Frijda (41)


- 134 -

• Comunicación simbólica o proposicional: A través de esta comunicación se envía

información acerca del entorno.

• Comunicación no proposicional o de naturaleza emocional: Su tarea no es

transmitir información sino sumir a todo el sistema en un estado de mayor

atención, lo que se llama modo emocional, que se puede asemejar a una

interrupción en programación. Este tipo de comunicación puede invocar acciones

de unos módulos e inhibir otros.

Si el sistema se sume en un modo de organización emocional, sin que existan datos del

exterior que deban ser evaluados por un sistema operativo consciente de alto nivel, la señal

emocional simplemente se propaga de forma global a través de todo el sistema. De este modo

se establecen un número reducido de modos emocionales.

Según Oatley, cada objetivo y cada plan poseen un mecanismo de monitorización que

evalúa los eventos según su relevancia para ellos. Cuando un cambio de la probabilidad de

conseguir un determinado objetivo o sub-objetivo tiene lugar, el mecanismo de monitorización

difunde esta situación por todo el sistema cognitivo mediante una señal. Esta señal puede

entenderse como la predisposición para responder a ese cambio.

Las emociones coordinan procesos cuasi autónomos del sistema nervioso. De esta forma

se comunica la situación de los planes o “plan junctures”. Esta teoría establece la siguiente

conexión entre “plan junctures” y las emociones.

Plan juncture Emotion

Subgoals being achieved Happiness

Failure of major plan Sadness

Self-preservation goal violated Anxiety

Active plan frustrated Anger

Gustatory goal violated Disgust

Tabla 4. Plan junctures (42)


- 135 -

Como conclusión se puede decir que las emociones son una solución a los cambios en los

planes para un sistema de múltiples objetivos. Además este sistema establece que la tarea

encargada de las emociones es la que brinda información a todos los demás módulos.

6.2.2. Diseño del modelo emocional: Requisitos del sistema

emocional

Como se ha mencionado anteriormente, uno de los objetivos de este proyecto es crear un

sistema emocional. No obstante, antes de definir un modelo resulta necesario analizar qué

requisitos precisa el sistema global:

• Sistema multitarea: Este sistema está orientado a un funcionamiento como

asistente domótico. En este sentido, debe ser capaz de realizar multitud de tareas

muchas de las cuales constituirán una influencia para el estado emocional. Por

tanto, el requisito que se establece es que el modelo que se escoja sea capaz de

evaluar cambios de diferentes tareas.

• Sistema concurrente: Así mismo, el sistema puede realizar acciones de diversa

naturaleza en el mismo instante de tiempo. Esto requiere un sistema emocional

que tenga en cuenta los eventos concurrentes y, además, pueda jerarquizar su

influencia para generar una respuesta emocional coherente.

• Sistema escalable: Por último, y pensando en el gran crecimiento que puede sufrir

un sistema de estas características en cuanto al número de funcionalidades

disponibles, el sistema emocional debe proporcionar los medios necesarios para

que la inclusión de una nueva tarea no suponga un rediseño del modelo

emocional.


- 136 -

Inicialmente se pensó utilizar la “appraisal theory” como base del sistema emocional ya

que, como se ha dicho anteriormente, es la teoría psicológica que presenta mayor robustez a la

hora de explicar el comportamiento emocional de las personas. En este sentido, una primera

aproximación consistía en que cada tarea generase un vector de atributos de evaluación

independientes de la tarea (task independet features TIF). Estos atributos caracterizarían cada

evento en relación al objetivo específico de la tarea. Posteriormente, un módulo se encargaría

de generar la respuesta emocional a partir de los TIF de cada tarea. El esquema de esta

arquitectura puede verse a continuación.

Sin embargo esta aproximación presentaba deficiencias. En concreto si se atiende a la lista

de características requeridas se puede ver:

• Sistema multitarea: Inicialmente esta aproximación satisface este requisito ya

que cada evento ocurrido en las distintas tareas es juzgado y descrito mediante un

vector TIF. De esta forma, el módulo generador de emociones será genérico e

independiente de tarea. Simplemente generará una respuesta emocional en

función de los vectores de evaluación.

• Sistema concurrente: Aquí se presentaba la necesidad de tratar diferentes

eventos que ocurriesen de forma simultánea así como de generar un mecanismo

Figura 61. Arquitectura mediante TIF


- 137 -

que los jerarquizase. Con esta aproximación no hay ningún problema a la hora de

tratar eventos simultáneos. No obstante, a la hora de jerarquizarlos sí que existen

dificultades. En concreto, cada tarea caracteriza un evento en función de su

objetivo de tarea. Esto implica que, aunque la información de los TIF sea

homogénea, no posea la capacidad de, por sí misma, priorizarse. Véase el

siguiente ejemplo: se ejecuta simultáneamente un juego y la monitorización de la

batería. En un momento determinado se realiza un buen movimiento en el juego,

pero el nivel de la batería decrece. La primera tarea generará un vector TIF que

conducirá, probablemente, a una emoción positiva como alegría. Por el contrario,

la segunda tarea generará un TIF que conducirá a un estado emocional negativo

de miedo o tristeza. Ante esta situación la única forma de decidir qué emoción

debe ser la predominante es mediante algún tipo de información que sea

dependiente de la tarea. Por tanto, al introducir esta modificación se está

perjudicando, por un lado, el requisito de multitarea, ya que el módulo generador

de emociones no será tan genérico. Por otro lado, se dificulta la escalabilidad.

• Sistema escalable: Como hemos dicho el modelo emocional debe permitir que el

sistema crezca de forma sencilla. Atendiendo a esta aproximación. La inclusión de

una nueva tarea implica que el programador tenga en cuenta, para cada evento

que se produzca, la situación emocional a la que se conduce. Por tanto, es el

programador quien debe generar el vector de TIF. Además como este vector es

utilizado directamente en el cálculo de emociones, los valores que se asignen a

cada uno de estos atributos deben estar en consonancia con los valores que

otorguen el resto de las tareas. Esto implica que además de tener en cuenta el

comportamiento emocional, el programador debe analizar el comportamiento

emocional de las otras tareas. Finalmente, si se incluye información destinada a

jerarquizar las emociones, la inclusión de una nueva tarea debería reconfigurar de

alguna forma el módulo generador de emociones.

Por tanto, a la vista de las deficiencias encontradas en la satisfacción de cada uno de los

requisitos definidos, la aplicación en estos términos de la “appraisal theory” no es aconsejable

de forma directa. Además, a la vista de los resultados emerge una incongruencia de tipo

psicológico. Las emociones son consecuencia directa de la satisfacción o no de los objetivos de

las tareas. Es decir, el sistema se “pone alegre” porque, por ejemplo, se gana a un juego. Por el

contrario, parece más apropiado que el si

consigue un objetivo de más alto nivel. Esta visión permite justificar el aprendizaje emocional de

nuevas tareas de la siguiente forma. Al aprender una nueva tarea no se responde

emocionalmente porque se ha aprendido que, por ejemplo, no caerse de una bicicleta es

positivo para la tarea, sino que se ha aprendido que no caerse de la bicicleta es positivo porque

no perjudica algún objetivo de alto nivel

6.2.3. Definición de objetivos de alto

Maslow.

Abraham Maslow estableció en 1943 una teoría sobre la motivación humana

teoría fue desarrollada a partir de la observación de personas que no presentaban ningún

de trastorno psicológico como Albert Einstein o Eleanor Roosevelt entre otros

las personas están motivadas por la búsqueda de la satisfacción de una serie de necesidades.

Además, Maslow fue capaz de jerarquizar dichas necesidades

constituyendo la conocida Pirámide de Maslow. En esta pirámide las necesidades se posicionan

de más prioritarias (situadas en la parte de debajo de la pirámide) a menos prioritarias.

estas necesidades se encuentran en una relació


- 138 -

apropiado que el sistema se ponga alegre porque, al ganar en un juego



ha aprendido que, por ejemplo, no caerse de una bicicleta es

sino que se ha aprendido que no caerse de la bicicleta es positivo porque

no perjudica algún objetivo de alto nivel como permanecer ileso.

Definición de objetivos de alto nivel: la teoría de

estableció en 1943 una teoría sobre la motivación humana

teoría fue desarrollada a partir de la observación de personas que no presentaban ningún

de trastorno psicológico como Albert Einstein o Eleanor Roosevelt entre otros


fue capaz de jerarquizar dichas necesidades mediante cinco niveles


de más prioritarias (situadas en la parte de debajo de la pirámide) a menos prioritarias.

estas necesidades se encuentran en una relación de subsunción de modo que, si un nivel básico

Figura 62. Pirámide de Maslow


al ganar en un juego,



ha aprendido que, por ejemplo, no caerse de una bicicleta es

sino que se ha aprendido que no caerse de la bicicleta es positivo porque

nivel: la teoría de

estableció en 1943 una teoría sobre la motivación humana (36). Esta

teoría fue desarrollada a partir de la observación de personas que no presentaban ningún tipo

de trastorno psicológico como Albert Einstein o Eleanor Roosevelt entre otros, y concluye que


nte cinco niveles,


de más prioritarias (situadas en la parte de debajo de la pirámide) a menos prioritarias. Además,

si un nivel básico


- 139 -

está insatisfecho, se impedirá la satisfacción de los niveles superiores. Sin embargo, esta

restricción parece exagerada, por lo que se ha optado por la priorización de emociones de cada

nivel. Así mismo, se puede apreciar que las más prioritarias son aquellas que están más

relacionadas al comportamiento animal o instintivo, mientras que las superiores son de más alto

nivel.

Maslow estableció que el comportamiento de las personas está motivado por la

satisfacción de todas y cada una de estas necesidades y que, una vez satisfechas, se alcanzaría

un estado de felicidad.

Los niveles son:

• Nivel Fisiológico: Este nivel es el más prioritario y también el de más bajo nivel. En él se

recogen las necesidades básicas de las personas como son respiración, alimentación….

En definitiva, aquellas necesidades que permiten estar vivo.

• Nivel de Seguridad: Este nivel recoge aquellas necesidades que, no siendo estrictamente

necesarias para seguir vivo, resultan imprescindibles para poder realizar cualquier

acción. Por ejemplo, seguridad física, de recursos, salud….

• Nivel de Afiliación: En este nivel se recoge la necesidad de pertenencia a un grupo. Esto

significa amistad, afecto…

• Nivel de Reconocimiento: O también denominado nivel de estima. Este nivel fue

clasificado por Maslow mediante dos tipos: alta estima (relacionada con la necesidad de

respeto de uno mismo, de maestría, de confianza, etc.) Baja estima (relacionada con el

respeto de las demás personas, de la necesidad de reconocimiento, de estatus etc.)

• Nivel de Autorrealización: Es el nivel más alto de la pirámide y por ello es el más

abstracto. Mediante la satisfacción de este nivel Maslow establece que se alcanza el

sentido de la vida. Además, a este nivel se llega cuando todos los demás han sido, al

menos, parcialmente satisfechos.

Como puede apreciarse, la teoría de Maslow es una jerarquización de las necesidades de

las personas. Es decir, es una definición de los objetivos que posee el individuo y que persigue y

evalúa durante la realización de las tareas. Este concepto cuadra, precisamente, con lo que

requiere el sistema emocional cuando habla de objetivos de alto nivel. Una serie de necesidades

suficientemente genéricas, para que, cualquier cambio proveniente de cualquier acción, pueda

ser caracterizado en relación a ellos. Por todo ello la teoría de Maslow sirve de eslabón entre los


- 140 -

eventos y la “appraisal theory”. Sin embargo, el comportamiento de un sistema así como sus

necesidades presentan diferencias con el de las personas y, en consecuencia, resulta pertinente

una adaptación de las necesidades. Esta adaptación es la siguiente:

• Nivel Fisiológico: Este nivel conserva la misma interpretación que para el caso de los

humanos. Es la necesidad de estar funcionando. Analizando los eventos que pueden

afectar a este nivel aparecen cambios en el nivel de batería, en la memoria disponible o

en la temperatura de la CPU. Si cualquiera de estos eventos hace que su variable quede

en un valor crítico la necesidad tornará insatisfecha y el sistema no podrá funcionar. Es

decir, si se produce un evento de decaimiento del nivel de batería que hace que este

nivel pase a un valor suficientemente bajo como para que el equipo entre en

hibernación, la necesidad estará insatisfecha. Además, por el tipo de necesidad, se

puede ver que el sistema no funcionará a no ser que se satisfaga.

• Nivel de Seguridad: Este nivel recoge los eventos que puedan imposibilitar que el

sistema realice sus acciones de forma correcta. Eventos de este nivel pueden ser tanto

un fallo de comunicación con los módulos que integran el sistema, como una variación

del nivel de iluminación del entorno. Nótese que mientras que si la necesidad fisiológica

del sistema se encuentra insatisfecha, éste no puede funcionar, si se encuentra

insatisfecha la necesidad de seguridad, el sistema no podrá realizar una acción. Por

ejemplo, en un estado de insatisfacción de esta necesidad causado por la iluminación, el

sistema se verá impedido para un tipo de acciones, en concreto aquellas que precisen

imágenes de la webcam, pero podrá realizar cualquier otro tipo de acciones.

• Nivel de Afiliación: Como se dijo anteriormente, este nivel tiene que ver con sentirse

parte de un grupo social. Esta definición puede llevar a generar varias variables para

computar dicha necesidad. Es decir, la necesidad de afiliación puede depender del

número de amigos del sistema, del número de veces que se juega a un juego, etc. Sin

embargo, en el modelo desarrollado, se ha utilizado una única variable denominada

“changes” que es dependiente del número de cambios que ocurren en el sistema. Esto

es así porque se ha considerado que, para el modelo, sentirse integrado socialmente

significa que el usuario está interactuando con el sistema. De esta forma la detección de

caras o el reconocimiento de conceptos son dos muestras del tipo de eventos que

influirán en esta variable y por ende, en esta necesidad.


- 141 -

• Nivel de Reconocimiento: En este caso la necesidad de sentirse reconocido puede venir

nuevamente modelado por varias variables. No obstante, se ha elegido la variable

“success”. Esta variable recoge los eventos que alcanzan al objetivo específico de cada

una de las tareas. Es decir, eventos como ganar o perder en un juego, conocer a alguien

nuevo, recibir un concepto correctamente, etc. modificarán el valor de success.

• Nivel de Autorrealización: Quizás éste sea el nivel más difícil de adaptar. Atendiendo a

las alternativas proporcionadas por Maslow, tal vez sea la moralidad la que mejor encaje

en un sistema robótico. En este sentido se ha decido utilizar la variable “ethics” que se

ve afectada por eventos que puedan considerarse inmorales. Es decir, trampas en un

juego, un insulto, etc.

Como resumen se puede decir que los niveles más bajos de Maslow (fisiológico y

seguridad) dependerán directamente de variables físicas del sistema, mientras que cada uno de

los tres superiores están modelados por una variable que resulta del cómputo a lo largo del

funcionamiento del sistema.

Figura 63. Adaptación de la Pirámide de Maslow.


- 142 -

6.2.4. Diseño del modelo emocional: Arquitectura

propuesta

Combinando la teoría de Maslow con la “appraisal theory” se ha llegado a un esquema en

el que el cálculo de la respuesta emocional es independiente de la tarea. Esto es posible

mediante la capa de objetivos de alto nivel proporcionada por Maslow. El funcionamiento es el

siguiente: Un evento producido en el contexto de una tarea es detectado por ella, quien

además, se encarga de juzgar a qué necesidades afectará ese evento. Seguidamente se

modificará el nivel de satisfacción de las necesidades implicadas y se caracterizará esta variación

en términos de la “appraisal theory”, es decir, mediante un vector de atributos de evaluación. En

este caso estos atributos son denominados atributos independientes de necesidad (need

independet feature NIF). Además, la información de los NIFs es complementada por el valor del

Peso, que es característico de cada nivel de Maslow. De esta forma se genera suficiente

información como para que el generador emocional determine la nueva respuesta emocional

final.

En esta arquitectura se pueden distinguir dos partes. Una primera parte es totalmente

dependiente de tarea y consiste en la relación de cada tarea con las necesidades de Maslow.

Esta relación debe ser establecida por el creador de las tareas atendiendo a la definición de cada

nivel. Por ejemplo, si se incluye una tarea que sea saludar a personas para encontrar a un

locutor específico, pueden ocurrir dos tipos de eventos: recibir respuesta del locutor buscado o

Figura 64. Arquitectura emocional implementada


- 143 -

recibir respuesta de otro locutor. Cada vez que se saluda a una persona y se recibe respuesta, el

nivel de satisfacción de afiliación debería incrementarse. Además, si la persona que devuelve el

saludo no es la buscada, el nivel de estima puede decaer, mientras que, si es la correcta, el nivel

aumentará. En definitiva, la forma en que se relacionan tareas y necesidades está determinada

por las características de la tarea.

La siguiente parte es independiente de la tarea. La información del evento ya ha sido

codificada como variación de las necesidades y, gracias a esto, el resto del cálculo emocional no

precisa la información de qué tarea ha detectado el evento. Es decir, en el ejemplo anterior, al

detectar al locutor buscado se aumentaría la satisfacción de estima. No obstante, estima

también podrá resultar incrementada por ganar a un juego. Por tanto, al analizar la variación de

estima no se tendrá en cuenta cuáles son las causas del cambio de valor. Simplemente se analiza

el cambio de valor mediante un vector de apreciación (NIF vector).

El vector NIF es un conjunto de atributos que caracterizan el cambio del valor de la

necesidad. Dado que la necesidad está modelada por una variable numérica (n-value), el

conjunto de NIFs puede ser obtenido mediante un análisis matemático. Siguiendo con el

ejemplo dado, el evento de la tarea generó un aumento en el n-value de estima de, por ejemplo,

+10. Este aumento será analizado y clasificado mediante NIFs como deseable, relevante, etc

(Más adelante se hablará en detalle de este tipo de atributos).

Recapitulando lo sucedido se ve que, lo que inicialmente era una detección de locutor,

ahora es un conjunto de variables como deseable, relevante, etc. Es decir, se ha caracterizado un

evento de forma abstracta permitiendo la comparación entre eventos cualesquiera.

Adicionalmente se proporciona una información en forma de un Peso, que es dependiente

del nivel de Maslow que sufre el cambio. Así, el módulo generador emocional, recibe este tipo

de información abstracta y genera la respuesta emocional. Es decir, con el ejemplo dado, al

aumentar +10 el nivel de necesidad y clasificarlo como deseable, relevante, etc. el generador

emocional establecerá que la emoción resultante debe ser positiva y muy probablemente sea

alegría. Además, esta emoción tendrá una importancia, indicada por su Peso, frente a otras

emociones.

En los siguientes puntos se analizará con detenimiento cada una de las partes de esta

arquitectura (relación tareas-necesidades; variación de necesidades y generación de NIFs; y

generación de emociones).


- 144 -

6.2.4.1. Relación tareas-necesidades

La inclusión de una nueva tarea requiere definir a qué necesidades afectará cada uno de

los eventos que es capaz de generar. A continuación se muestra el total de los eventos que han

sido considerados en el sistema.

En la figura se ve tanto el módulo que genera el evento como la necesidad a la que se

asocia dicho evento. No obstante, como se puede apreciar, ningún evento ha sido relacionado

con la necesidad de afiliación o variable changes. Esto es así por motivos de simplificación del

dibujo, ya que, se ha considerado que todos estos eventos, además de modificar los niveles que

se indican en la figura, modifican la variable changes. A continuación se justificarán estas

conexiones.

• Fisiológica (survival): Se han asociado eventos de batería y de memoria. Este tipo

de eventos se refieren a los parámetros claves del sistema. Si cualquiera de ellos

falla gravemente, el sistema dejará de funcionar.

Figura 65. Lista de eventos y relación con necesidades


- 145 -

• Seguridad (safety): Aquí se han asociado únicamente los eventos del módulo de

tratamiento de imágenes relativos a la luz. Se considera que, si no hay luz, el

sistema lo interpreta como un riesgo a su seguridad, ya que esto impide la

realización de tareas como utilizar la cámara para recoger imágenes.

• Afiliación (changes): Como se ha dicho, a este nivel afectan todos los eventos de

la figura. Esto es debido a que todos ellos tienen una procedencia externa. Es

decir, la ocurrencia de cualquiera de estos eventos implica que ha habido una

interacción con alguien.

• Estima (success): En este nivel influyen los eventos concepto reconocido y

presentación por parte del módulo de reconocimiento. Es decir un éxito en el

reconocimiento de voz aumenta el nivel de estima. En cuanto a presentación,

tiene más que ver con que el sistema desee conocer gente; por ello, al conocer a

alguien lo califica como éxito. También afectan alabanza, saludo y despedida, por

parte del control de conversación y, caricias, por parte del sistema central. Estos

últimos eventos tienen el significado de un reconocimiento, por parte de un

usuario, de las acciones que realiza el sistema, mientras que, saludo y despedida,

están relacionados con el objetivo de servir al usuario, es decir, si el usuario se va,

el sistema no cumple su objetivo. Finalmente, de los dos juegos de 3 en raya,

están implementados los eventos ganar, perder y empatar que se relacionan con

el éxito en dicha tarea.

• Autorrealización (ethics): A este nivel afectan el evento insulto del módulo de

conversación y los movimientos ilegales del módulo de juego. Se ha considerado

que estos dos eventos son contrarios a la moralidad del sistema.

Una vez que se han definido qué tareas afectan a qué necesidades, se procederá a detallar

matemáticamente esta relación.

6.2.4.2. Variación de necesidades.

La forma en cómo se relacionan las tareas con las necesidades es un tema complicado. De

hecho, dependiendo de cuál sea la necesidad afectada, este procedimiento se realiza de una

forma u otra. Además, el tipo de tarea que interviene es, a su vez, un condicionante. Así pues, lo

más sencillo resulta analizar esta variación necesidad por necesidad.


- 146 -

Antes de comenzar el análisis pormenorizado se establecen una serie de consideraciones

generales:

• Los valores de los niveles de necesidad (n-values) se encuentran acotados entre 0

y 100.

• 0 es el n-value cuando una necesidad se encuentra insatisfecha mientras que 100

es el de una necesidad completamente satisfecha.

• Existe una zona crítica, por debajo del valor crítico tomado como 15, que indica

que cualquier evento tiene el riesgo de llevar a un estado de insatisfacción

absoluto de la necesidad.

• Los n-values iniciales deben calcularse tras un periodo de evaluación de la

situación. De esta forma, el sistema no se pondrá feliz o triste de forma repentina

al iniciarse.

• Existen necesidades de tipo incremental y necesidades directas. Las de tipo

incremental sufren una modificación respecto a su estado anterior con la

aparición de un nuevo evento. Las de tipo directo adoptan un valor proporcional

al valor de la variable que sufre el evento.

• El cómputo de los niveles de necesidad se realiza asíncronamente, cada vez que se

produce un evento. No obstante, la evaluación del nivel de necesidad, esto es

generar los vectores de atributos NIF, se realiza de forma síncrona.

6.2.4.2.4. Nivel Fisiológico

Este nivel es de tipo forma directa ya que depende directamente de parámetros críticos

en el funcionamiento del sistema. Es decir, si cualquiera de ellos falla el nivel debe quedar

insatisfecho. O lo que es lo mismo, las variables que influyen en este nivel se relacionan

mediante una operación lógica “and” o “y”, equivalente a una multiplicación. De ésta forma el n-

value survival será

�(!B�B�+ = �3"!� #��C #�B + � /�� !í�� ∗ �3"!� #��C � . ."!�� +�/! �100


- 147 -

Así pues, si, tanto nivel de batería como memoria libre, valen 0, el nivel valdrá 0.

La gráfica anterior es una representación de una situación de funcionamiento en la que el

sistema consume memoria de forma constante hasta quedarse con un 10% de memoria libre.

Así mismo el nivel de batería también decrece hasta que en el instante 9 se conecta a la red

eléctrica. El resultado es que el valor de survival decrece y, pese a que se mejora la situación de

batería, el consumo de memoria hace que esta necesidad no se encuentre satisfecha.

6.2.4.2.5. Nivel de Seguridad

Este nivel depende directamente del valor de la luminosidad y, por tanto, no presenta

grandes problemas. Como particularidad cabe citar el proceso de normalización de luminosidad.

Luminosidad es una variable que recoge la luminosidad medida en el entorno, aunque,

sería posible elegir la energía media por pixel, lo que permitiría tener un parámetro

independiente de las características de la cámara. Sus valores típicos son del orden de 107 y, por

tanto, debe ser sometido a un proceso de normalización. En primer lugar se define un

procedimiento de filtrado de muestras de luz. Este procedimiento consiste en que luminosidad

sea el promedio de varias medidas, en concreto se ha optado por una historia de 5. El

funcionamiento es el siguiente: cada vez que se realiza una medida (éstas se realizan de forma

Figura 66. Simulación de survival


- 148 -

periódica) se incluye en la historia desechando la muestra más antigua. Además se calcula la

media aritmética de los cinco valores guardados. El siguiente paso es la comparación de ese

promedio con un umbral de luminosidad. Si el promedio es menor, se considera que no hay luz,

mientras que si es superior a dicho umbral, se considera que sí hay luz. Finalmente, se normaliza

mediante un proceso no lineal. Si el valor era superior al umbral (hay luz) el n-value safety

valdrá 100. Si, en cambio, el valor es inferior al umbral el safety, resultará de la siguiente

expresión:

��% �� = E 3!". ��"(./!�+ � +(FG × B�+"! I!í��"

Donde valor Crítico es 15 (definido en consideraciones generales) y el umbral de luz es

2x107. De esta forma la simulación de este nivel es la siguiente.

En la gráfica superior está el valor de la luz en promedio mientras que, en la inferior, se

encuentra el n-value. Las líneas rojas son los umbrales tanto de luz como de necesidad. Se puede

ver que en las zonas en las que el valor de la luz está por encima del umbral, el n-value se

encuentra saturado en 100. Por el contrario, la zona de luz por debajo del umbral implica un

comportamiento lineal del n-value. Una alternativa, en el caso de que el sistema se mostrase

suficientemente ruidoso, sería incluir una cierta histéresis en el proceso, de esta forma se

Figura 67. Simulación de safety


- 149 -

definirían dos niveles diferentes, uno para pasar a la situación de linealidad y otro para salir de

dicha región. No obstante, como se ha explicado en el capítulo de Interfaces, la luz tiene

implementado un sistema de filtrado que permite eliminar las variaciones causadas por el ruido.

Si a este nivel de necesidad se le incluyeran nuevas entradas deberían hacerse con una

relación lógica “or”. Es decir, este nivel, a diferencia del fisiológico, puede estar parcialmente

satisfecho aunque alguno de los parámetros que influyen en él sea 0. En otras palabras, ahora,

para que el sistema esté por debajo del nivel crítico, deben estarlo también todos los

parámetros que influyen en el nivel. Por el contrario, antes, en el fisiológico, para que el sistema

estuviese por debajo del nivel crítico debía estarlo al menos uno.

6.2.4.2.6. Nivel de Afiliación

Para este nivel se tienen en cuenta todos los eventos posibles del sistema. Por ello, resulta

necesario algún mecanismo que sea capaz de adaptar el efecto de cada evento en este nivel.

Como una primera alternativa surge la idea de utilizar porcentajes determinados por las propias

tareas generadoras de eventos. El problema de esto es que, al coincidir este mecanismo con el

desarrollado para otros niveles, un mismo evento afectaría de forma similar a distintas

necesidades, por lo cual parece redundante la existencia de varios niveles. Como alternativa se

ha propuesto un mecanismo de influencia basado en la cantidad de información que

proporciona un evento. En este sentido un evento que es muy repetitivo resulta de menor

interés en comparación con un evento que se repite cada más tiempo.

Para llevar a cabo el mecanismo mencionado se hace uso de un histograma por cada

evento. Este histograma recoge la cuantificación de un valor del evento y el número de

ocurrencias de cada una de ellas. Posteriormente, en base al número de ocurrencias de un caso

y al número de ocurrencias globales se puede obtener un porcentaje que, tras la adaptación

pertinente, estará relacionado con la cantidad de información. Inicialmente se analizará el

mecanismo del histograma para un caso particular como puede ser la luz.

La detección de luz es un proceso periódico, por lo que medir la velocidad de repetición

no resulta de interés. En su lugar se analizará el valor de luminosidad proporcionado, de esta

forma, las distintas situaciones posibles de luminosidad quedan caracterizadas. Por ejemplo,

otro caso sería analizar movimiento que, al ser eventos asíncronos, resultaría útil analizar con

qué velocidad se producen.


- 150 -

No obstante, volviendo al caso de la luz, se analizará el nivel de luminosidad. Este nivel es

una variable continua que puede tomar muchísimos valores y, por tanto, debe aplicarse un

proceso de cuantificación. En este sentido se ha definido un rango desde 0 hasta 4x107 con

saltos de 0.25x107. De esta forma cualquier valor fuera de rango se aproximará al extremo más

cercano, mientras que los valores que queden dentro serán asignados al nivel más cercano.

Antes de presentar los resultados de la simulación realizada es necesario resaltar otro

concepto. Este histograma pretende, a partir de un conjunto de mediciones, ser capaz de

estimar la probabilidad para cada uno de sus niveles. En este sentido es necesario el empleo de

alguna técnica que, a partir de los datos presentes, sea capaz de estimar la probabilidad de los

otros niveles. Para realizar esto aparecen diversas alternativas:

• Interpolación: La interpolación consiste en generar una probabilidad a partir de

los niveles vecinos. Asumiendo esta técnica se incurre en el error de suponer que

la función de la probabilidad estimada se corresponde con una recta. Además, es

necesario normalizar.

• K-NN vecinos: Esta técnica consiste en determinar la probabilidad estimada de un

punto a partir de los K vecinos. Es importante señalar que no importa la longitud

de la distancia entre el punto y los vecinos. Se debe coger un K adecuado.

• Ventana de Parzen: El condicionante ahora no es el número de vecinos que se

elegirán sino la longitud de la ventana. De esta forma, en función de dónde se

encuentre el punto que va a ser estimado, el número de vecinos que intervendrán

en el cálculo será uno u otro.

El estudio sobre la elección de qué método es el que presenta mayores ventajas rebasa

ampliamente el objetivo de este proyecto. No obstante, se ha determinado emplear una

Ventana de Parzen. La anchura de esta ventana también debe ser escogida teniendo en cuenta

las bondades y defectos de cada caso. Por ejemplo, una ventana muy pequeña llevaría a que las

contribuciones vecinas no se tuviesen en cuenta, mientras que una ventana excesivamente

grande llevaría a que el número de ocurrencias en cualquier nivel se homogeneizase. Para este

caso se ha definido la siguiente anchura.


- 151 -

J#�ℎ(!� = 2 ∗ ��LMNMOP�Q MORNM O�SMTMU� + V

Como se ve en la simulación, inicialmente hay un situación inicial con dos repeticiones de

1.5x107 y tres repeticiones de 3.5 x107. A continuación se produce un primer evento 2.6 x107,

este evento se cuantifica en el nivel de 2.5 x107 y se determina su valor. En este caso no hay

ningún vecino por lo que el valor es uno (la única ocurrencia es la del caso actual). En la tercera

gráfica se aprecia un segundo evento, esta vez de valor 1.72 x107. En esta ocasión dicho evento

se cuantifica en el nivel de 2 x107 y se recalcula su valor. En este caso sí existen vecinos, por lo

que la ocurrencia es resultado del siguiente análisis.

A partir del nuevo punto se dibuja la ventana de anchura 2x0.25 alrededor de él, tal y

como muestra la figura.

Figura 68. Simulación de histogramas para luz


- 152 -

Como se ve, los niveles que quedan dentro son el 1.5x107 y el 1.75x107. Este último nivel

es, por proximidad, al que se va a asignar el nuevo evento. Por tanto, el siguiente paso es

determinar la estimación de ocurrencias del nivel al que se asigna el nuevo punto. Para ello se

promedia el número de ocurrencia de los niveles que caen en la ventana teniendo en cuenta una

nueva ocurrencia en el nivel que corresponda.

"�(!! #�W�X O�SMT = ∑ "�(!! #��O�SMTMU �MORNZ �M SMORQOQ#ú. !" � #�B + � ��#�"� � � !"

En este ejemplo concreto:

"�(!! #�W�X �.]^ = "�(!! #��.^ + "�(!! #��.]^2 = 2 + 12 = 1.5

Que es el resultado presentado en la simulación de histogramas.

Finalmente, el cuarto histograma de la simulación presenta un nuevo caso. Esta vez a

partir del punto la ventana no incluye ningún nivel vecino que tenga un número de ocurrencias

distinto de cero. Es por esto que el número de repeticiones para el nivel 1.75x107 aumenta en 1.

Una vez analizado el cálculo de las contribuciones resta profundizar en el mecanismo de

modificación de changes. Este mecanismo consiste en la modificación mediante contribuciones

Figura 69. Ventana de Parzen sobre histograma para el punto 1.72x107


- 153 -

que son resultado de todo el cálculo anterior. En concreto la contribución de un nivel se define

como:

�"#�!�/(��ó#O�SMT = "�(!! #�W�X O�SMT∑ "�(!! #�W�X∀ O �SMT

De esta forma se obtiene un valor para las contribuciones menor o igual que uno. El

siguiente paso es utilizar ese valor para incrementar el n-value changes de la siguiente forma.

"3( ��" = 100 − �ℎ�#> � "3( ��" = ��"#�!�/(��ó#O�SMT� ∗ "3( ��" �ℎ�#> � = 100 − "3( ��"

Con este modelo el límite superior es 100 y es convergente. No obstante existe un

problema, y es que ningún evento decrementa este nivel. Por ello, atendiendo a la definición de

changes (cambios ocurridos) tiene sentido que la causa por la que se decremente este nivel sea

el paso del tiempo. De esta manera, tras un cierto tiempo sin cambios, este nivel de necesidad

tornará insatisfecho.

El modelo matemático que lo recoge es el siguiente:

�ℎ�#> � �� = �1 − %��"!� ∗ �ℎ�#> �� Tras una serie de repeticiones

�ℎ�#> �O = �1 − %��"!�O ∗ �ℎ�#> �� De modo que, teniendo en cuenta que esta evaluación se hará cada, aproximadamente,

100 ms y estableciendo una caída de changes de un 60% se puede obtener que el factor

realmente coincide con τ-1. A continuación se puede ver una simulación del funcionamiento

completo de changes asociados a eventos procedentes de la luz. Para dicha simulación se ha

supuesto un τ-1=0.0338, o lo que es lo mismo, se ha supuesto que el sistema tarda unos 15

segundos en atenuar aproximadamente un 60% el nivel de changes.

En la simulación se aprecia un conjunto de eventos periódicos de luz en color verde y el

nivel de changes en azul. Inicialmente sólo ocurren eventos del mismo valor (3.5x107) por lo que

la información que aportan es pequeña y, en consecuencia, el efecto sobre el valor de changes

es nulo. De esta forma changes se amortigua por el paso del tiempo.


- 154 -

A continuación sucede un evento de valor 2x107. Este evento es la primera vez que

ocurre, y como en el sistema se habían producido otro tipo de eventos, el valor de changes se ve

alterado. A partir de este momento se suceden eventos del mismo valor, lo que hace que la

tendencia de changes sea a atenuarse.

Finalmente el último evento es de valor 1.72x107 que, como se puede apreciar en el

histograma, es la primera vez que ocurre. En este sentido, su contribución será enorme, de

modo que el valor de changes aumenta casi llegando al 100%. A partir de este momento se

terminan este tipo de eventos y el resultado es la atenuación, mediante la constante de tiempos,

de este nivel.

6.2.4.2.7. Nivel de Estima

Este nivel depende de diferentes eventos procedentes de distintos módulos. En este

sentido es muy difícil predecir las posibles secuencias de eventos positivos o negativos que

pueden darse, por lo que se corre el riesgo de que, si el mecanismo de actualización del n-value

no está bien definido, el sistema pueda saturarse por uno de sus extremos con lo cual eventos

en el mismo sentido no afectarían, pero eventos de distinto tipo sí podrían modificar el estado.

Es decir, si, por ejemplo, se sucedieran multitud de eventos positivos, el n-value podría llegar a

saturarse llegando a su valor máximo (100). A partir de aquí, los eventos positivos que pudieran

Figura 70. Simulación completa de Changes


- 155 -

llegar no se tendrían en cuenta, ya que el sistema está completamente satisfecho, sin embargo,

eventos negativos sí alterarían el valor. El hecho de que se deje de tener en cuenta los eventos

de un determinado tipo resulta incorrecto, porque, si bien en distinta medida, cada evento debe

presentar un efecto. En consecuencia, la forma de actualización escogida para este n-value

consiste en el mecanismo de porcentajes. Cada tarea indica el cambio de este n-value, ya sea

mediante un incremento o un decremento, y proporciona un porcentaje. Si es un incremento el

porcentaje se refiere a la reducción del opuesto del n-value. Si, por el contrario, se refiere a un

decremento, el porcentaje es relativo al decrecimiento del n-value. Matemáticamente el modelo

es el siguiente.

"3( ��" = 100 − �(�� 78 é��" "3( ��" = �1 − 3"!� #��C � ∗ "3( ��" �(�� = 100 − "3( ��"

<@A< 78 %!��" �(�� = �1 − 3"!� #��C � ∗ �(�� Las consecuencias inmediatas de este modelo matemático son:

• El n-value tiene como límite superior 100. Además es convergente

asintóticamente a este límite.

• El límite inferior del n-value es 0 y también converge asintóticamente.

• Los eventos positivos tienen una influencia dependiente del estado de la

necesidad. De esta forma, la aparición de eventos positivos cuando el n-value es

elevado, presenta una modificación de la necesidad menor que si el n-value fuese

bajo. Es decir, en estados de insatisfacción se valora más la aparición de eventos

positivos, mientras que en estados de satisfacción los eventos positivos son

menos importantes. Así mismo, estas conclusiones se pueden extender para el

caso de eventos negativos, haciéndose obvio que los eventos negativos tendrán

mayores consecuencias cuando el sistema se encuentra en un estado de

satisfacción.


- 156 -

En la figura se presenta la simulación de este n-value. Para su realización se han supuesto

8 eventos representados en color verde. Así mismo, el valor inicial de success era de 50. Como se

ve, el primer evento es un saludo que incrementa el valor de success. Seguidamente hay un

error de reconocimiento que lo decrementa. A partir de este momento se suceden una serie de

caricias que elevan el valor de success hasta 85 más o menos. Por último hay un nuevo saludo y

una victoria que dan el valor final de 93. El cálculo sigue las operaciones descritas anteriormente

por lo que la única incógnita son los porcentajes de cada evento:

• Saludo: un evento saludo tiene un tanto por uno fijo de 0,25. Esto implica que

decrementa el opuesto de success un 25% cada vez que ocurre.

• Error de reconocimiento: este evento también responde a un porcentaje fijo, en

este caso es de 0,15. Sin embargo, en esta ocasión se disminuye un 15% success

con cada aparición.

• Ganar: otro evento de tanto por uno fijo. En este caso vale un 0,4 y, al ser un

evento de éxito, contribuye a disminuir el opuesto de success un 40%.

• Caricia: este evento tiene un peso especial asociado a la importancia de cada

caricia, que depende de: la historia, la frecuencia estimada y la frecuencia

Figura 71. Simulación de success


- 157 -

máxima. Esto se encuentra detallado en el apartado del sensor de caricias, en el

capítulo de Interfaces.

6.2.4.2.8. Nivel de Autorrealización

Este nivel se ve afectado por movimientos legales e ilegales por parte de los juegos y, por

insultos, por parte del control de conversación. El funcionamiento es similar al nivel de estima.

Cada tarea evento proporciona una dirección (disminución o aumento) y un porcentaje (en que

se modifica el n-value). En concreto, los movimientos ilegales así como los insultos disminuyen

el n-value en el porcentaje correspondiente, mientras que los movimientos legales lo

incrementan mediante la disminución del opuesto del n-value en el porcentaje determinado. De

esta forma el análisis matemático es el mismo que antes:

"3( ��" = 100 − �ℎ�� 78 ."B�.� #�" + >�+ "3( ��" = �1 − 3"!� #��C � ∗ "3( ��" �ℎ�� = 100 − "3( �� <@A< �ℎ�� = �1 − 3"!� #��C � ∗ �ℎ�� Además se vuelven a extraer las mismas conclusiones:

• Límite superior de 100 con convergencia.

• Límite inferior de 0 con convergencia.

• Influencia de los eventos determinada por la situación de la necesidad. Si está

insatisfecha los eventos positivos tienen mayores efectos. Por el contrario, si está

satisfecha los eventos negativos tendrán más efecto.

La simulación adjunta consiste en un caso en el que se está jugando una partida. Por este

motivo se suceden una serie de movimientos legales. Acto seguido se producen dos

movimientos ilegales que originan la sucesión de tres insultos. Como puede verse, el n-value

ethics se inicia en 50 y, con la ocurrencia de los sucesivos eventos positivos, incrementa

gradualmente su valor hasta aproximadamente 80. A partir de ese momento se suceden

movimientos ilegales que conducen a ethics hasta 20. Finalmente, los insultos acaban

arrastrando el valor hasta la zona crítica. Los porcentajes de cada evento son:


- 158 -

• Movimiento Legal: Presenta un porcentaje fijo de 0.2. Es decir, decrementa el

opuesto de ethics un 20%.

• Movimiento Ilegal: Presenta un porcentaje fijo de 0.25. Es decir, decrementa

ethics un 25%.

• Insulto: Presenta un porcentaje fijo de 0.5. Es decir, decrementa ethics un 50%.

6.2.4.3. Generación de NIFs

Como se ha mencionado, una de las características del modelo basado en las necesidades

de Maslow es que los eventos se convierten en un cambio de los n-values. Por tanto, la

obtención de atributos de evaluación a partir de estos cambios, puede ser realizada

matemáticamente.

Otro aspecto relevante es el número de atributos de evaluación necesarios. Para abordar

este problema se debe pensar en que la misión de estas variables es caracterizar un evento de

forma que se puedan diferenciar unas emociones u otras a partir de ellos. Atendiendo a las

características de expresión emocional de este sistema. Concretamente a los gestos que se

pueden realizar con la cara robótica así como a las diferentes con que emociones se puede

sintetizar texto. Se concluye que el número de emociones que pueden ser expresadas es

Figura 72. Simulación de ethics


- 159 -

reducido. De hecho son 6 emociones: miedo, alegría, tristeza, enfado, sorpresa y neutralidad. Así

pues, el número de atributos de evaluación no precisa ser muy elevado.

En cuanto a la notación, se han denominado NIF, o atributos independientes de

necesidad, puesto que permiten obtener la información de la misma forma para cualquier

necesidad. Es decir, dependen del valor n-value pero no de a qué nivel pertenezca.

A continuación se detallará matemáticamente cada uno de los NIFs y se realizará una

simulación para cada uno de ellos. En la simulación se utilizará un n-value genérico que, como

todos, estará acotado entre 0 y 100 y cuya zona crítica está por debajo de 15.

Finalmente se debe mencionar el otro atributo que caracteriza a la variación de un nivel,

el Peso. Este atributo no es exactamente un NIF, puesto que su valor está determinado por qué

nivel sea el evaluado, lo que lleva a pensar que es un atributo dependiente de la necesidad. Los

valores que puede tomar este atributo son estáticos y predefinidos. Para el nivel fisiológico vale

5 y decrece con cada nivel hasta valer 1 para autorrealización.

6.2.4.3.9. Deseabilidad

La deseabilidad caracteriza cómo, el evento ocurrido, contribuye a satisfacer o no la

necesidad. Se modela mediante una variable continua entre -100 y 100 cuyo signo está

asociado al sentido de la satisfacción de una necesidad. Es decir, si el evento contribuye a que se

satisfaga una necesidad el valor será positivo. Si, por el contrario, el evento conduce a la

insatisfacción de la necesidad, será negativo.

Además, la deseabilidad proporciona información que permite comparar distintos

eventos del mismo signo. Es decir, dos eventos que tiendan a satisfacer una necesidad deben

ser diferenciados en función de cuánto contribuye cada uno. Esta información está contenida en

el valor absoluto.

Así pues, la deseabilidad corresponde matemáticamente a la estimación de la derivada

primera del n-value

2 � �/�+��O = �B�+( O − �B�+( Ob�

Como se puede ver en la simulación pertinente, el módulo de la deseabilidad es mayor

cuanto mayor es el cambio que experimenta el n-value. Inicialmente hay incrementos pequeños


- 160 -

Figura 73. Simulación de deseabilidad.

del n-value que se suceden de forma continuada. Éstos son de deseabilidad positiva y módulo

reducido. Además se puede apreciar que hacia el instante 20 hay una variación de la pendiente

del n-value, lo cual modifica el valor de deseabilidad. Posteriormente, hacia el instante 60, hay

una disminución importante del n-value y por tanto la deseabilidad es negativa llegando a

alcanzar el valor de -20. Esto es debido a que cambia el n-value de forma más o menos brusca.

Finalmente, cabe señalar que, cuando el valor del n-value no se modifica, la deseabilidad

permanece igual a 0. Esto es debido a que este NIF caracteriza cambios y no situaciones.

Las consecuencias emocionales de la definición de la deseabilidad, en los términos

descritos, radican en el hecho de que, con tendencias suaves, el sistema puede alcanzar un

estado de satisfacción de una determinada necesidad sin que se haya experimentado una

emoción significativa. Esto se debe a que, como se verá más adelante, la emoción viene

atenuada por el factor τ, que competirá con el incremento causado por los eventos. No

obstante, para el caso de que la variación del n-value fuese abrupta, la deseabilidad tomaría

valores mayores generando una respuesta emocional suficientemente significativa.


- 161 -

6.2.4.3.10. Inesperado

Este atributo caracteriza la tendencia a corto plazo. Su significado parte de la hipótesis de

que un evento tiende a ser muy parecido al anterior. O lo que es lo mismo, el sistema tiende a

no sufrir cambios en su tendencia. En este sentido si la tendencia es una reducción del n-value

una conservación o un aumento de este valor serán inesperados. Así mismo, una variación en la

velocidad de reducción de dicho valor también es considerada como inesperada.

En definitiva, inesperado caracteriza cuánto se aparta el evento actual de la tendencia

generada por el evento precedente. Esto se puede modelar matemáticamente mediante la

diferencia entre el evento actual y el evento anterior convenientemente normalizado. Es decir, si

se pasara de una situación de plena satisfacción (n-value=100) a una de insatisfacción completa

(n-value=0) para luego volver al caso de máxima satisfacción (n-value=100), el valor de

inesperado, sin normalizar, sería de 200. Para el caso de que se partiera de una situación de

insatisfacción (n-value=0) hacia una de satisfacción (n-value=100) y posteriormente cayera hacia

insatisfacción (n-value=0), el valor de inesperado sería -200. No obstante, ambas situaciones

serían igualmente inesperadas, obteniendo así la siguiente fórmula.

Figura 74. Simulación de inesperado con cambios suaves.


- 162 -

4# �3 !��"O = |��B�+( O − �B�+( Ob�� − ��B�+( Ob� − �B�+( Ob��|2

Además, por su significado, este NIF sólo tendrá valores entre 0 (evento esperado) y 100

(evento muy inesperado).

En la simulación con cambios suaves (figura 74) , se aprecia que el valor de inesperado es

0 a menos que se produzca un cambio de pendiente. Analizando en detalle el máximo de

inesperado se aprecia que una variación desde una pendiente de -17,5 aproximadamente, a una

de -1.67, inesperado vale alrededor de un 8. Lo cual es coherente con el hecho de que el valor

máximo de inesperado se obtiene si se pasa de una pendiente de -100 a otra de +100. Si por el

contrario se supone que el n-value sufre eventos puntuales (figura 75) que modifican su valor

de forma discontinua, se tendrá la siguiente simulación.

Ahora las variaciones ocurren en saltos, lo que genera eventos inesperados en cada

variación. Nótese que ambas simulaciones tratan la misma secuencia de valores del n-value. No

obstante, mientras que en el sistema continuo los eventos se sucedían con cada instante de

Figura 75. Simulación de inesperado con cambios abruptos


- 163 -

tiempo, en el sistema discontinuo apenas hay catorce eventos.

6.2.4.3.11. Urgencia

La urgencia modela el grado en el que la velocidad de variación generada puede conducir

al nivel crítico desde la situación actual. Es decir, tendrá en cuenta tanto la relación entre, el

módulo del cambio producido y el necesario para llegar a la zona crítica, como la distancia a la

zona crítica. Debido a esta definición se intuye que la urgencia será una variable no lineal. De

hecho, una vez se alcanza el nivel crítico, urgencia queda saturada en su valor máximo. También

se considera de urgencia máxima que la repetición del evento conduzca a la zona crítica.

Finalmente, el tramo lineal de urgencia se modela como, la relación entre la variación ocurrida y

la necesaria para llegar a la zona crítica por un peso que es inferior cuanto más lejos se esté de la

zona crítica. El detalle matemático es el que sigue.

78 �B�+( O ≤ e./!�+ I!í��" e!> #�� = 100 <@A< 78 �B�+( O + ��B�+( O − �B�+( Ob�� ≤ e./!�+ I!í��" e!> #�� = 100 <@A< e!> #�� = f�100 − �B�+( O� ∗ g �B�+( O − �B�+( Ob��B�+( O − e./!�+ I!í��"gh

Nuevamente hay que resaltar que la urgencia está acotada entre 0 (valor mínimo) y 100

(valor máximo). Además, con este modelo, el mismo cambio es menos urgente cuando el n-

value es elevado pues, por un lado el cambio producido respecto al necesario para alcanzar la

zona crítica es menor y, por el otro, la situación está más cerca de la satisfacción de la necesidad

y, por tanto, cualquier cambio tiene menos urgencia. Sin embargo, si el mismo cambio ocurriera

en zonas de bajo valor del n-value sería mucho más urgente porque, por un lado, está en una

zona cercana a la zona crítica y, por el otro, porque la distancia entre el cambio ocurrido y el

cambio necesario para caer en la zona crítica es menor.


- 164 -

Analizando la simulación de este NIF lo primero que se ve es que, cuando el n-value se

encuentra por debajo del nivel crítico, urgencia vale 100. Otra característica interesante que se

desprende de la simulación se puede ver en el tramo del sexto al octavo cambio de pendiente.

En él se aprecia que, con una tendencia generada (mismo módulo de cambio en cada instante

de tiempo), la urgencia se incrementa en la medida en que el valor del n-value va siendo más

bajo.

Si se realiza la simulación para un sistema abrupto se aprecia que el cuarto evento, que

conduce al valor de 100, no es urgente, mientras que el sexto evento, que conduce al valor 50,

tiene una urgencia máxima, pues la repetición de este evento conduce a la zona crítica.

Finalmente, cabe destacar que existen un par de eventos (1º y 13º) que incrementan el n-value

hasta un valor inferior a 100 pero superior a la zona crítica. Estos eventos presentan algo de

urgencia, pues no conducen al estado de satisfacción máxima. Sin embargo, si estos eventos

provocasen una disminución del n-value presentarían una mayor urgencia. Hay que recordar que

urgencia depende tanto de la relación entre el cambio producido y el necesario para alcanzar la

zona crítica, como de la situación a la que conduce el cambio.

Figura 76. Simulación de urgencia con cambios suaves


- 165 -

6.2.4.3.12. Relevancia

La relevancia es un atributo que caracteriza la situación a la que conduce un evento. En

este sentido valores más altos del n-value serán caracterizados como menos relevantes que

valores bajos. Matemáticamente la relevancia es una función que responde a una recta entre

100 y el valor crítico y que se satura por debajo de él. Además esta recta presenta un cierto

offset que permite que, cuando el n-value vale 100, la relevancia no sea 0. Esto significa que

eventos que tengan lugar cuando la necesidad está satisfecha son poco relevantes pero no

irrelevantes. La expresión matemática es la siguiente.

, + B�#�� = 100 ∗ e./!�+ I!í��".á��B�+( O, e./!�+ I!í��"�

Figura 77. Simulación de urgencia con cambios abruptos


- 166 -

En la simulación correspondiente se aprecia cómo el valor de relevancia va

disminuyéndose a medida que aumenta el n-value hasta alcanzar su mínimo (15). A partir del

sexto cambio de pendiente se aprecia como la relevancia aumenta hasta que se satura en 100,

pues el n-value se encuentra en la zona crítica. Finalmente, la relevancia vuelva a bajar porque

se satisface la necesidad (n-value sube a 90).

6.2.4.3.13. Infrecuente

Este atributo indica el grado de “desconocido” que es un evento. Es decir, si en la

situación actual se están sucediendo eventos que producen la misma variación, este atributo

tenderá, tras un número de repeticiones suficientes, a 0. No obstante, si, de repente, aparece un

evento que produce un cambio del n-value distinto de la tendencia generada a largo plazo, ese

será evaluado como más infrecuente (situación desconocida). Matemáticamente, esto es

modelado mediante una distribución normal en la que, con cada evento, se calcula el inverso de

la probabilidad de ocurrencia y se actualiza la media y la varianza con el nuevo cambio del n-

value sucedido.

Figura 78. Simulación de relevancia


- 167 -

4#%! �( #� = 100 ∗ i1 − bg�PQjk�Zlbm�n�∗on gp ∗ √2 ∗ r s

t = ∑ ��./�"�O�u��ú. !" � vB #�"� p = w ∑ ��./�"��O�u��ú. !" � vB #�"� − t� ��./�"O = �B�+( O − �B�+( Ob�

En la simulación adjunta se ven tres gráficas: la media, la desviación y la simulación en sí. Como

puede apreciarse al principio de la simulación, hay un cambio importante en el tercer evento,

esto hace que la media y la desviación fluctúen. Sin embargo, justo a continuación, se entra en

una zona de cambios más o menos constantes del n-value. En esta zona, tanto la media como la

desviación se van estabilizando. De hecho, la media acaba alcanzado el valor uno mientras que la

desviación baja hacia 0. Como consecuencia, el valor de infrecuente desciende ya que cada vez

es más probable que ocurra uno de esos eventos. Finalmente se llega a la zona en la que se

alcanza la región crítica. En esta zona, tanto la media como la desviación vuelven a variar. De

hecho, la media desciende, ya que los eventos provocarán cambios negativos, y la desviación,

obviamente, aumentará debido a que se rompe con la situación anterior. En consecuencia el

valor de inesperado volverá a ser elevado ya que la probabilidad de un evento como estos era

reducida.

Una de las particularidades que presenta el empleo de este atributo es la capacidad para

adaptarse a una situación. Si se repiten eventos que generan las mismas variaciones del n-value

el sistema cada vez los valorará como menos infrecuentes. De esta forma, un evento que

inicialmente era extraño, tras un número de repeticiones es evaluado como típico.


- 168 -

6.2.4.4. Generación de emociones

La generación de emociones a partir de los NIFs se realiza en el módulo generador de

emociones. Gracias al diseño del sistema, en el que los atributos son iguales para cualquier nivel,

éste proceso puede ser realizado de una forma genérica. Cada vez que se detecta una variación

en un n-value se generá el vector NIF correspondiente, que es utilizado en el cálculo de la

variación emocional. Además, tras un cierto tiempo, las emociones tenderán a amortiguarse.

En cuanto al número de emociones implementado, el factor determinante, como ya se

mencionó, es la capacidad expresiva del sistema. En concreto, la cara robótica y el sintetizador

de voz (interfaces de salida) son los condicionantes del repertorio que puede ser expresado.

Teniendo en cuenta estas características, el número de emociones presentes es de seis: miedo,

alegría, tristeza, enfado, sorpresa y neutralidad. De forma genérica, la variación de una emoción

puede estar expresada de la siguiente manera.

v."��ó#R = v."��ó#Rb� + ∆v."��ó# ∆v."��ó# = %y�4z�{{{{{{{{{{|} − 1~ ∗ v."��ó#Rb� %y�4z�{{{{{{{{{{|} = 2 � �/�+�� ∗ , + B�#�� ∗ %�2 � �/�+��, 4# �3 !��", e!> #��, 4#%! �( #� � ∗ %�- �"�

Figura 79. Simulación de infrecuente


- 169 -

%�2 � �/�+��, 4# �3 !��", e!> #��, 4#%! �( #� � == ��>#"�2 � �/�+�� ∗ ��1 ∗ 4# �3 !��" + �2 ∗ �#%! �( #� + �3 ∗ e!> #�� Donde los pesos k1, k2 y k3 dependen de distintas circunstancias. En la siguiente tabla

quedan recogidos sus valores.

�7�=��<A<��7@7�� K1 K2 K3 8��<A��

Alegría + 0.5 0.5 0.5 Peso >>0

Sorpresa

+

78 ��# �3 !��" � �#%! �( #� > �ℎ�� 1 = �2 = 0.7 <@A< �1 = �2 = 0.35

0.5 Peso ~0

Tristeza

-

78 �- �" ≥ v��.�� 1 = �2 = �3 = 0.1 <@A< �1 = �2 = �3 = 0.5

Peso >>0

Miedo

- 0.5 0.5

78 �(!> #��> �ℎ�� 3 = 0.7 <@A< �3 = 0.35

78 ��B +≤ � >(!�� - �" <@A< 0

~0

Enfado

-

78 ��# �3 !��" � �#%! �( #� > �ℎ�� 1 = �2 = 0.7 <@A< �1 = �2 = 0.35

0.5

78 ��B +≥ v��.�� 5 <@A< 0

~0


- 170 -

El singo de la deseabilidad es una función que modifica el signo del incremento en función

de la deseabilidad y la emoción. En concreto, para las emociones de alegría y sorpresa

(consideradas positivas), el signo del incremento coincide con el de deseabilidad. Esto implica

que un evento positivo aumente estas emociones. Sin embargo, el resto de emociones, miedo,

tristeza y enfado, presentan una relación contraria. El signo del incremento es opuesto al de la

deseabilidad. Esto provoca que eventos positivos reduzcan el nivel de estas emociones, mientras

que eventos negativos las incrementan.

En cuanto a la función de peso, ésta es una función que para alegría, sorpresa y tristeza

devuelve el peso tal cual. No obstante, para miedo devolverá 0 si el nivel de necesidad es

superior al de seguridad. Esto provoca que la contribución a miedo sea cero y refleja el hecho de

que el miedo está generado por amenazas a los niveles básicos de Maslow, que constituyen

riesgos para el funcionamiento del sistema. Finalmente, para enfado el peso será distinto de 0

para niveles de Maslow superior o igual a estima; Esto significa que el sistema se enfada por no

conseguir éxitos o por una ausencia de ética en las acciones. Además, dado que éstas son las

únicas fuentes de enfado, el peso de estos niveles para dicha emoción es elevado.

A continuación hay que hablar de la constante de tiempos. En concreto se distinguen dos

tipos de emociones, aquellas de largo plazo (alegría y tristeza) y aquellas de corto plazo (miedo,

sorpresa y enfado). Véase el siguiente caso: Tras un evento que genere sorpresa la tendencia es

que quede alegría ya que, la sorpresa, tras un cierto tiempo, desaparece. No tiene sentido que

alguien esté sorprendido media hora, o al menos, que exprese sorpresa durante media hora. En

este sentido, la constante de tiempo de sorpresa hace que dicha emoción se amortigüe de forma

más o menos rápida. No obstante, como el evento que genera sorpresa, por definición, también

generará un nivel de alegría, al tener esta última una constante de tiempos mayor, tardará más

en atenuarse y, en consecuencia, tras una sorpresa inicial quedará alegría hasta, que pasado

suficiente tiempo, la alegría se amortigüe y el sistema llegue a neutral. Esto mismo se produce

con las emociones negativas, miedo y enfado frente a tristeza. No obstante, regulando las

constantes de tiempo se puede modificar la personalidad del sistema, haciendo que tarde más o

menos en superar un enfado, o provocando que sea más o menos miedoso mediante la

constante de miedo.

Por último se hablará de la emoción neutral. Se ha mencionado que existían seis

emociones, no obstante, en la tabla de pesos para cálculo el emocional no aparecía neutral. Esto

es debido a que esta emoción está modelada de forma peculiar. Ningún evento en sí mismo


- 171 -

contribuye al aumento de la neutralidad. Es más bien la ausencia de eventos la que provoca la

neutralidad, siendo los eventos los que atenúan esta emoción. En este sentido neutralidad se ha

modelado como el opuesto del sumatorio de todas las emociones.

� (�!�+�� = 100 − � ."��ó#

De esta forma, el incremento de cualquier emoción provoca una disminución de la

neutralidad, pero la amortiguación de las emociones provoca un aumento de la neutralidad. Por

otro lado esta emoción también debe cumplir con las condiciones establecidas para las demás,

es decir, su valor está acotado entre 0 y 100.

Las consecuencias de este tipo de cálculo emocional pasan por que el sistema es capaz de,

pasado un cierto tiempo, acostumbrarse a la situación de satisfacción de las necesidades. Esto

provoca que la expresión emocional sea dinámica y cambie con el paso del tiempo.

6.2.5. Sistema emocional implementado

El propósito de este apartado es dar una visión general de cómo están distribuidas las

Figura 80. Secuencia de cálculo emocional


- 172 -

diferentes etapas del cálculo emocional en el sistema. Lo primero que se hará es recapitular el

proceso de cálculo emocional representado en la figura:

1. Aparece un evento en el contexto de una determinada tarea.

2. La tarea, conforme a su programación, modifica los n-values de los niveles de

necesidad correspondientes.

3. Los cambios en la satisfacción de las necesidades generan los NIFs de evaluación

de cada cambio.

4. El módulo generador de emociones, a partir de estos NIFs y de los Pesos genera la

respuesta emocional.

Una vez resumido cómo se calcula una nueva emoción se expondrá en qué módulo del

sistema se realiza cada acción ordenándolas según su secuencia de ocurrencia. Para ello se

utilizará el siguiente esquema.

Como se ve, los módulos encargados de controlar las interfaces de entrada son los que

detectan un cambio en el entorno. Este cambio es enviado al módulo de comportamiento que,

Figura 81. Proceso de respuesta emocional


- 173 -

tras un proceso de sondeo, lo retransmite a la tarea pertinente. Esta tarea generará una

respuesta, así como, un cambio en las necesidades del sistema.

Seguidamente, el sistema emocional almacena las variaciones de necesidad solicitadas y

permanece a la espera.

A continuación, el módulo de comportamiento solicita la emoción. En este momento el

módulo emocional realizará el cálculo de NIFs y el subsiguiente cálculo emocional para cada

nivel de necesidad que haya variado. Como resultado de este proceso, devuelve la respuesta

emocional dominante (de mayor valor).

Finalmente, el módulo de comportamiento, envía la respuesta de la tarea así como la

emoción a los controladores de las interfaces de salida, que se encargarán de enviar la respuesta

al exterior.

No obstante, llegados a este punto, se ha de realizar un breve inciso sobre el cálculo de la

emoción predominante. Teniendo en cuenta que cada emoción está modelada por un valor

entre 0 y 100 y que puede haber dos emociones simultáneas con valores parecidos, es necesario

proporcionar un mecanismo que impida fluctuaciones de las emociones en momentos de

transición emocional. Esto es, por ejemplo, que una emoción, como alegría, va decreciendo

mientras que origina el aumento de neutral. En un instante determinado, ambas emociones

tendrán prácticamente el mismo valor y, por tanto, la respuesta emocional final fluctuará entre

ellas. Para resolver este problema, el sistema implementado incluye una cierta histéresis que

favorece la emoción predominante en el pasado hasta que la nueva emoción la supera en un

valor determinado. Con esto se garantiza que, tras el primer cambio emocional, no se sucederán

cambios a no ser que haya un aumento real de otra emoción.

Aunque no aparece reflejado en la figura, el módulo de comportamiento, cada cierto

tiempo, se encarga de solicitar la amortiguación de las emociones al módulo emocional.

En conclusión, este proceso se puede caracterizar de la siguiente manera:

• Una primera fase compuesta de la detección de cambios del exterior de forma

asíncrona.

• El envío de estos cambios a las tareas de forma síncrona.

• Respuesta de las tareas y cálculo de los nuevos valores de las necesidades de

forma asíncrona.


- 174 -

• Solicitud del estado emocional así como de la amortiguación de emociones, si

procede, de forma síncrona.

• Respuesta final de forma síncrona.

Las acciones síncronas están gobernadas por la secuencia de ejecución del módulo de

comportamiento que se repite cada Periodo General de Muestreo (aproximadamente 100ms).

Finalmente, haciendo un nuevo análisis desde un punto más cercano a la programación, el

sistema emocional se compone de las siguientes partes:

• Tarea: Módulo cliente que detecta un evento y comunica su nuevo estado

mediante la llamada al procedimiento remoto “Comunicar Situación

Módulo” que es procesada por el servidor de la tarea en el núcleo del

sistema. Como resultado se generará una actualización de las necesidades.

• Necesidades: Modeladas como clases derivadas de la clase “CGoalProcess”

proporcionan una serie de métodos particulares para cada una de ellas que,

tras ser llamados por los servidores de las tareas, actualizan el valor de la

necesidad. Además de estos métodos específicos de necesidad, heredan los

métodos necesarios para detectar el cambio de una necesidad y generar el

vector NIF pertinente (este método será llamado desde el Módulo de

Comportamiento).

• Emociones: Las emociones son implementadas como objetos de la clase

“CEmotion”. Esta clase proporciona los métodos necesarios para: calcular

las emociones a partir de los NIFs. Este método se llama

“actualizaEmociones” y es llamado desde el método que detecta la

variación de la necesidad y genera un vector NIF; Buscar la emoción

máxima mediante “BuscaEmociónMáxima” llamado desde el módulo de

comportamiento; O amortiguar las emociones cada cierto tiempo mediante

“amortiguacionEmociones” también llamado desde el módulo de

Comportamiento.

6.2.6. Conclusiones del sistema emocional

Una vez expuesto el sistema emocional diseñado e implementado resulta conveniente

analizar los requisitos establecidos inicialmente:


- 175 -

• Sistema multitarea: El sistema implementado es capaz de traducir cualquier

evento procedente de cualquier tarea en una variación de necesidades. A partir

de este momento, el cálculo de emociones se realiza de forma independiente a las

tareas, por lo que es factible para varias tareas distintas.

• Sistema concurrente: El mecanismo de necesidades permite, por un lado,

acumular cambios de distintas tareas en una misma necesidad para que, a la hora

del cálculo emocional, la respuesta tenga en cuenta a todos los cambios. Por otro

lado, en el caso de que varias tareas afecten a distintas necesidades, el modelo

propuesto incluye una prioridad para cada necesidad de modo que, el cálculo

emocional contempla la importancia de unos eventos frente a otros.

• Sistema escalable: La inclusión de una tarea en este sistema resulta instantáneo,

simplemente hay que definir qué eventos pueden ocurrir en la nueva tarea y

relacionar cada evento con las necesidades pertinentes. El resto del cálculo

emocional permanecerá invariable. No obstante, con esta implementación

también se ganan en escalabilidad en el otro extremo. Es decir, la inclusión de

nuevas emociones puede realizarse a partir de un mayor número de NIFs

obtenidos de la necesidad. Esto implica que la inclusión de nuevas emociones no

hacen el diseño de una tarea más complejo. En definitiva, la pirámide de Maslow

definen dos partes claramente diferenciadas.

En este sistema, la forma en la que se relacionan las tareas con las necesidades, así como

la forma en la que se calculan las emociones a partir de los NIFs, son condicionantes que, de

forma implícita, constituyen el temperamento del sistema. Actuando sobre estas variables así

como sobre las constantes de tiempo de las emociones, se puede conseguir un sistema que

tienda a estar enfadado con facilidad, o tienda a sorprenderse.

Finalmente, como se ha visto, la inclusión de la pirámide de Maslow, como objetivos de

alto nivel, resulta un importante avance en el modelo emocional. Sin embargo, sus efectos no

afectan únicamente a este cálculo. De forma implícita se ha dotado de un mecanismo capaz de

servir como motivación del sistema y, en consecuencia, permitiría generar comportamientos

autónomos que tiendan a satisfacer las necesidades. No obstante, esto va más allá de este

proyecto y queda recogido en el capítulo de líneas futuras.

Capítulo 7 – Conclusiones y Líneas Futuras

- 177 -


7 CONCLUSIONES Y LÍNEAS FUTURAS

Este capítulo está dedicado a la reflexión sobre el trabajo realizado, a la autocrítica y como

fruto de ello se desprenderán líneas de actuación que pueden resultar interesantes a la hora de

mejorar el sistema.

7.1. Conclusiones

En este proyecto se ha conseguido implementar un asistente domótico capaz de simular

estados emocionales y expresar emociones. Para ello se han integrado en un único sistema

multitud de módulos realizados en trabajos anteriores, como la aplicación SERVIVOX del GTH, el

sintetizador de voz procedente de los trabajos realizados en el GTH, para interaccionar por voz;


- 178 -

el brazo y la cara robótico para la interacción física; el tratamiento de imágenes basado en

opencv para la interacción visual; etc.

A este asistente se le ha incluido un comportamiento emocional debido a la importancia

que tienen las emociones en el objetivo de crear sistemas que, destinados a convivir con las

personas, sean aceptados por los usuarios. De hecho, durante el desarrollo del trabajo, se realizó

una presentación a personal de Indra y Adecco y en esta presentación se observó que aunque el

comportamiento meramente “profesional” (como asistente personal), es decir, controlar luces,

pasar la aspiradora, etc. generó interés por parte de los asistentes, cuando se mostró el

comportamiento emocional, el público se interesó mucho más por el agente.

Persiguiendo los objetivos descritos se ha creado una arquitectura completamente

escalable que, basada en un esquema modular cliente/servidor, permite una fácil expansión de

este sistema, haciendo que la inclusión de nuevas funcionalidades resulte sencilla para cualquier

programador. De esta forma, un nuevo módulo no necesita conocer nada del resto del sistema,

basta con que se implemente una interfaz común.

Se ha evaluado e integrado un sistema de identificación de usuario basado en el criterio

BIC con buenos resultados de tasa de identificación en un experimento de hasta 30 locutores,

empleando, tan sólo, cinco frases breves para construir el modelo inicial de locutor. Además se

ha diseñado e implementado un protocolo que permita presentar al sistema una nueva persona

y que, en el futuro, el sistema sea capaz de identificar a esta nueva persona.

Se ha integrado un servidor de síntesis basado en técnicas HMM. Mediante una estructura

de conceptos por niveles, la información asociada al grado de relación con el locutor y al estado

emocional, el servidor es capaz de, en cada momento, seleccionar las frases de forma aleatoria

de acuerdo con las probabilidades asociadas a las distintas alternativas vinculadas a los

parámetros proporcionados al servidor.

Se ha integrado el acceso a un servidor para control de electrodomésticos mediante X10;

se ha creado un servidor para comunicación mediante un interfaz infrarrojo con un equipo HI-FI;

se ha creado un servidor que integra un brazo robótico capaz de jugar a las tres en raya; se ha

integrado un detector de caricias basado en fotosensores con un filtrado por medio de software;

se ha integrado y adaptado un juego de tres en raya virtual; se ha creado una cara robótica con

capacidad para expresar emociones y parpadear en función del estado emociona; se ha creado


- 179 -

un servidor para integrar dicha cara en el sistema; y se he creado un servidor capaz de

comunicarse inalámbricamente por medio de Bluetooth con una aspiradora robótica.

La piedra angular de este sistema es el modelo emocional. Este modelo ha sido ideado

partiendo de las teorías emocionales conocidas como appraisal theories y adoptando la

tendencia actual de la robótica: la arquitectura de subsunción de Brooks. De esta forma,

mediante la teoría psicológica de Maslow, conocida como Pirámide de Maslow, se ha

conseguido implementar un sistema emocional jerarquizado que resulta independiente de las

tareas.

7.1.1. Cumplimiento de requisitos

A continuación se analiza en qué medida ha sido satisfecho cada uno de los requisitos

fijados para este proyecto:

� Interfaz multimodal: El sistema consta de una interfaz visual capaz de detectar

movimiento, caras y luz mediante cámara web, además de poder representar

información por pantalla. También se ha incluido una interfaz verbal capaz de, por

un lado, reconocer conceptos e identificar usuarios y, por el otro, de sintetizar

voz. Por último se ha añadido una interfaz física capaz de expresar emociones,

mediante gestos faciales, y detectar acciones como caricias, además de la

implementación física de una versión de las tres en raya.

� Comportamiento emocional: Se ha definido e implementado un sistema

emocional que es capaz de evaluar la situación en cada momento y generar una

emoción acorde a ella. Además, esa emoción es tenida en cuenta a la hora de

elegir, primero, qué frase se va a sintetizar y, segundo, qué emoción se empleará.

Por tanto, se ha conseguido definir un comportamiento acorde a las emociones.

� Comportamiento personalizado: Se ha evaluado e incluido un sistema de

identificación de usuario mediante voz. Este sistema está asociado a un modelo de

usuarios que recopila la historia de las interacciones entre cada usuario y el

sistema, determinando, en base a ella, la relación que les une. Además esa

relación es tenida en cuenta a la hora de elegir las frases a sintetizar. De modo

que se consigue adaptar el comportamiento en función de la relación con el

usuario.


- 180 -

� Funcionalidad de asistente doméstico: Prueba de esto es todo el Capítulo de

Aplicación, en el que se detallan cada una de las tareas incluidas: control de luces,

control de aspiradora Roomba, control de equipo HI-FI, etc. Todas estas tareas

responden al comportamiento como un asistente domótico básico.

� Compañero de juegos: Se han incluido dos implementaciones del juego tres en

raya, una física y otra virtual. Ambas implementaciones son capaces de generar

información relativa a la situación del juego (ganar, perder, empatar, trampas…)

que es utilizada para generar variaciones en el sistema emocional. Como se ha

visto, el estado emocional es expresado de distintas formas de modo que, en

conjunto, se consigue que el sistema actúe emocionalmente mientras juega.

� Arquitectura escalable: Se ha mencionado en repetidas ocasiones el objetivo de

intentar realiza un sistema lo más escalable posible. En cuanto a las tareas, se

mencionó la creación de interfaces estandarizadas, destinadas a crear una forma

de comunicación normalizada con el módulo de comportamiento. De esta

manera, la inclusión de las tareas resulta muy sencilla. Además, al imponer

requisitos únicamente relativos a la interfaz, el grado de libertad a la hora de crear

cada tarea es enorme. Por otro lado, la creación del sistema emocional ha

contemplado como pilar base la escalabilidad. Como se explica en el Capítulo de

Emotividad, la inclusión de una nueva tarea no supone grandes cambios en el

modelo emocional.

7.2. Líneas Futuras

Para terminar se enumeraran una serie de líneas de trabajo que, durante el transcurso de

este proyecto, han aparecido como mejoras interesantes:

- Generación de comportamiento en función de las necesidades de Maslow: Con

vistas a generar un sistema autónomo resulta pertinente la inclusión de algún

mecanismo motivador de acciones. En este sentido se propone la adaptación del

modelo de comportamiento para que, en función del nivel de satisfacción de las

necesidades de Maslow, pudiera realizar acciones destinadas a satisfacerlas.

- Aumento del repertorio de emociones: Parece necesario invertir esfuerzos en

perfeccionar las interfaces de salida para enriquecer el rango de expresión

emocional. De esta forma será preciso añadir más emociones al modelo

emocional y buscar una solución para generarlas, esto puede ser mediante ejes.


- 181 -

De hecho, numerosos trabajos emocionales se basan en el modelado mediante

varios ejes. En estos sistemas las emociones aparecen como regiones dentro del

espacio definido.

- Aprendizaje de comportamiento: Otra de las funcionalidades interesantes a la

hora de seguir trabajando en un sistema autónomo es proporcionar la capacidad

de aprender acciones para contrarrestar una situación. Por ejemplo, si se va la luz,

el sistema probaría un conjunto de acciones y monitorizaría el nivel de la

necesidad alcanzado. Si ésta se satisface, reforzaría las acciones realizadas y

conseguiría aprender que, determinada acción tiene determinadas consecuencias.

Este objetivo se podría unir al de actuar conforme al nivel de necesidad.

- Mejora de la interfaz visual basada en Opencv: Como se ha visto, la funcionalidad

de tratamiento de imágenes incluida en este proyecto es bastante básica. Sin

embargo, es un hecho que, con esta herramienta, se consiguen sistemas mucho

más complejos. Por tanto, una línea de trabajo consistiría en adaptar esta interfaz

para ser capaz de distinguir más elementos. Éstos pueden ser los gestos

relacionados con las emociones de una persona u otro tipo de características.

Además es interesante preservar la independencia del modelo frente a quién esté

interactuando con él. De este modo no será necesaria ninguna intervención con

vistas a adaptar al sistema cada vez que aparezca un nuevo usuario.

- Inclusión de nuevas tareas y mejora de las ya existentes: Dada las facilidades que

presenta la arquitectura implementada para la inclusión de tareas, se puede

seguir ampliando las ya existentes o generar nuevas tareas, como descarga de

noticias de interés desde la red, preparación de café, pinche de cocina accediendo

a las recetas on-line, supervisión de las existencias de comidas en un frigorífico,

etc. Las posibilidades son casi ilimitadas.

- Integración de los módulos de síntesis, reconocimiento emociones y relaciones

en el proyecto Robonauta.

Como resultado final de este trabajo se ha elaborado un vídeo en el cual se demuestran

todos y cada uno de los objetivos alcanzados.

Capítulo 8 – Pliego de Condiciones

- 183 -


8 PLIEGO DE CONDICIONES

8.1. Condiciones generales

I. La obra será realizada bajo la dirección técnica de un Ingeniero de

Telecomunicación y el número de programadores necesarios.

II. La ejecución material de la obra se llevará a cabo por el procedimiento de

contratación directa. El contratista tiene derecho a obtener, a su costa, copias

del pliego de condiciones y del presupuesto. El ingeniero, si el contratista lo

solicita, autorizará estas copias con su firma, después de confrontarlas.


- 184 -

III. Se abonará al contratista la obra que realmente se ejecute, de acuerdo con el

proyecto que sirve de base para la contrata.

IV. Todas las modificaciones ordenadas por el ingeniero-director de las obras, con

arreglo a sus facultades, o autorizadas por la superioridad, serán realizadas

siempre que se ajusten a los conceptos de los pliegos de condiciones y su

importe no exceda la cifra total de los presupuestos aprobados.

V. El contratista, o el organismo correspondiente, quedan obligados a abonar al

ingeniero autor del proyecto y director de obra, así como a sus ayudantes, el

importe de sus respectivos honorarios facultativos por dirección técnica y

administración, con arreglo a las tarifas y honorarios vigentes.

VI. Tanto en las certificaciones de obra como en la liquidación final, se abonarán las

obras realizadas por el contratista a los precios de ejecución material que

figuran en el presupuesto, por cada unidad de obra.

VII. En el caso excepcional en el que se ejecute algún trabajo no consignado en la

contrata, siendo admisible a juicio del ingeniero-director de las obras, se pondrá

en conocimiento del organismo correspondiente, proponiendo a la vez la

variación de precios estimada por el ingeniero. Cuando se juzgue necesario

ejecutar obras que no figuren en el presupuesto de la contrata, se evaluará su

importe a los precios asignados a ésta u otras obras análogas.

VIII. Si el contratista introduce en el proyecto, con autorización del ingeniero-director

de la obra, alguna mejora en su elaboración, no tendrá derecho sino a lo que le

correspondería si hubiese efectuado la obra estrictamente contratada.

IX. El ingeniero redactor del proyecto se reserva el derecho de percibir todo ingreso

que en concepto de derechos de autor pudiera derivarse de una posterior

comercialización, reservándose además el derecho de introducir cuantas

modificaciones crea convenientes.

8.2. Condiciones generales a todos los programas

X. Estarán realizados en lenguajes estándar.

XI. Se entregarán tres copias de los listados para cada programa o subrutina.

XII. Los programas y subrutinas deberán ir documentados, indicando brevemente su

función, entradas y salidas, y cualquier otra información de interés.

XIII. Se entregará, junto con los programas, un manual de uso e instalación.

Capítulo 8 – Pliego de Condiciones

- 185 -

8.3. Condiciones generales de prueba

XIV. Los programas y subrutinas que se entreguen deberán funcionar sobre un

ordenador PC o compatible con microprocesador AMD 2000+ o superior y con,

al menos, 256 MBytes de RAM. Se ejecutarán bajo sistema operativo Windows

XP Professional, en entorno local.

XV. Solamente se aceptarán los programas si funcionan correctamente en todas sus

partes, rechazándose en caso contrario. Si, por causas debidas al contratista, los

programas no funcionaran bajo las condiciones expuestas anteriormente, la

empresa contratante se reservará el derecho de rescindir el contrato.

8.4. Recursos materiales

XVI. Ordenador PC compatible, AMD Athlon XP 2300, 1GB de memoria RAM y 40 GB

de disco duro.

XVII. Altavoces.

XVIII. Tarjeta de red Ethernet.

XIX. Controlador X10 Marmitek LM15 y marmitek CM11.

XX. WebCam.

XXI. Cara robótica compuesta por 5 servomotores y placa controladora Netmedia 8

servo torque board.

XXII. Módulo iRTrans.

8.5. Recursos lógicos

XXIII. Sistema operative Microsoft Windows XP Professional.

XXIV. Compilador Microsoft Visual C++ 6.0

XXV. Microsoft Office 2007.

Capítulo 9 – Presupuesto

- 187 -


9 PRESUPUESTO

El presupuesto consta de cuatro apartados: el cálculo del presupuesto de ejecución

material, el presupuesto de ejecución por contrata que incluirá el cálculo de los gastos generales

y del beneficio industrial, el coste de la dirección de obra y, por último, el presupuesto total,

suma de todos los conceptos anteriores.

Todas las cantidades que aparecen están contempladas en Euros.


- 188 -

9.1. Presupuesto de ejecución material

Se incluye en este presupuesto los gastos en herramientas empleadas, tanto hardware

como software, así como la mano de obra.

En la ejecución de este proyecto han participado las siguientes personas:

• Un Ingeniero Superior de Telecomunicación, encargado del desarrollo y redacción

del proyecto, así como de la obtención e interpretación de los resultados.

• Un mecanógrafo, encargado de la escritura del proyecto en un procesador de

textos, elaboración de gráficos, etc.

9.1.1. Relación de salarios

Se parte del sueldo base mensual de cada una de las personas que han intervenido en el

proyecto para calcular el sueldo base diario respectivo. A éste habrá que añadir las obligaciones

sociales.

9.1.2. Relación de obligaciones sociales

Sueldo base mensual

Sueldo base diario

Gratificación Sueldo total

diario Ingeniero Superior de

Telecomunicación 1.334,59 44,49 6,07 50,56

Mecanógrafo 632,49 21,08 5,67 26,76

Tabla 6. Sueldos de las personas que han intervenido en el proyecto

CONCEPTO Vacaciones anuales retribuidas 8,33%

Indemnización por despido 1,60% Seguro de accidentes 7,00%

Subsidio familiar 2,90% Subsidio de vejez 1,80%

Abono días festivos 12,00% Días de enfermedad 0,75%

Plus de cargas sociales 4,25% Otros conceptos 15,00%

TOTAL 53,63%

Tabla 7.Obligaciones sociales


- 189 -

9.1.3. Relación de salarios efectivos totales

9.1.4. Coste de la mano de obra

Para calcular el coste de la mano de obra basta con aplicar el número de días trabajado

por cada persona por el salario respectivo.

9.1.5. Coste total de materiales

Para la ejecución de este proyecto se han empleado un ordenador personal tipo PC

basado en el microprocesador Pentium III y una impresora Láser HP LaserJet 2100 Series PCL 6-1,

para la elaboración de toda la documentación necesaria. También se incluyen los gastos de

material fungible y de oficina.

Días Salario( €)/día Total ( €) Ingeniero Superior

de Telecomunicación

330 77,67 25.630,7

Mecanógrafo 40 41,1 1.644,13 TOTAL COSTE DE MANO DE OBRA

27.274,83

Tabla 9. Coste de la mano de obra.

Sueldo diario

Obligaciones sociales Total/día

Ingeniero Superior de Telecomunicación

50,56 27,11 77,67

Mecanógrafo 26,76 14,35 41,1

Tabla 8. Salarios efectivos totales


- 190 -

Los costes referentes a los materiales utilizados se reflejan en la siguiente tabla:

9.1.6. Importe total del presupuesto de ejecución material

El presupuesto de ejecución material se calcula basándose en los costes de mano de obra

y los costes materiales.

9.2. Importe de ejecución por contrata

Al importe de ejecución material hay que añadirle los siguientes conceptos:

Precio (€) Uso (meses)

Amortización (años) Total (€)

1 ordenador personal para diseño 1.502,53 12 5 300,51

Controladores X10 LM15 y CM111 50,00 12 5 10,00

WebCam 40,00 12 5 8,00 Cara Robótica 100,00 12 5 20,00

iRTrans 100,00 12 5 20,00 2 ordenadores auxiliares para

reconocimiento y síntesis 3.005,06 12 5 601,02

Compilador Microsoft Visual C++ 420,71 12 5 84.14

Impresora Láser HP LaserJet 2100 780,71 1 5 13,01

Placa de red Ethernet 120,2 - - 120,2 Material fungible y de oficina 120,2 - - 120,2

TOTAL GASTO DE MATERIAL

1.297,08

Tabla 10. Coste de materiales

CONCEPTO IMPORTE (€) COSTE TOTAL DE MATERIALES 1.297,08

COSTE TOTAL DE MANO DE OBRA 27.274,83 TOTAL PRESUPUESTO DE EJECUCIÓN MATERIAL 28.571,91

Tabla 11. Presupuesto de ejecución material


- 191 -

Resultando:

9.3. Honorarios Facultativos

Este proyecto se encuadra dentro del grupo XII: Aplicaciones de la Electrónica y Aparatos

de Telecomunicación. Si se aplican las tarifas correspondientes sobre el importe del presupuesto

de ejecución material se tiene:

Los honorarios que hay que aplicar son los correspondientes tanto por redacción del

proyecto como por dirección, por lo que el total de honorarios es:

9.4. Importe Total del Proyecto

El Importe Total del Proyecto es la suma del Importe de Ejecución por Contrata, los

Honorarios de Redacción y los Honorarios de Dirección, al cual habrá que aplicar el 16% de IVA.

IMPORTE DE EJECUCIÓN POR CONTRATA 36.387,51

Tabla 13. Importe de ejecución por contrata

CONCEPTO IMPORTE (€) GASTOS GENERALES Y FINANCIEROS (22%) 6.140,83

BENEFICIO INDUSTRIAL (6%) 1.674,77 TOTAL G.G. Y B.I. 7.815,6

Tabla 12.Relación de conceptos adicionales

Hasta 30.050,61 (Coef. 1,0 sobre 7%) 2.103,54 Hasta 60.101,21 (Coef. 0,9 sobre 7%) 399,22

TOTAL HONORARIOS FACULTATIVOS ( €) 2.502,76

Tabla 14. Honorarios facultativos

Honorarios de Ingeniero por redacc ión 2.502,76 Honorarios de Ingeniero por dirección 2.502,76

TOTAL HONORARIOS 5.005,53

Tabla 15.Honorarios totales


- 192 -

El importe total del presente proyecto asciende a la cantidad de CUARENTA Y OCHO MIL

QUINCE euros NOVENTA Y TRES céntimos.

EL INGENIERO AUTOR DEL PROYECTO

Fdo.: Carlos Sanz Moreno

MADRID, SEPTIEMBRE DE 2009.

EJECUCIÓN POR CONTRATA 36.387,51

HONORARIOS 5.005,53

IMPORTE 41.393,04

IVA (16%) 6.622,88

IMPORTE TOTAL 48.015,93

Tabla 16. Importe total del proyecto

Bibliografía

- 193 -

BIBLIOGRAFÍA

1. Seneff, Stephanie, y otros. GALAXY-II: A Reference Architecture for Conversational

System Development. ICSLP. 1998.

2. Goddeau, David, y otros. GALAXY: A Human-Language Interface to on-line Travel

Information. ISCLP. 1994.

3. Pellom, Bryan, Ward, Wayne y Sameer, Pradhan. The CU Communicator: An

Architecture for Dialogue Systems. ISCLP. 2000.

4. Carneige Mellon. Software Engineering Institute. Client/Server Software Architectures

An Overview. Carneige Mellon University, 2003.

5. Rodríguez Losada, Diego. JABON a SOAP C++ Code Generator.

http://www.intelligentcontrol.es/jabon/.

6. Rabiner, Lawrence y Juang, Biing Hwang. Fundamentals of speech recognition.

Englewoods Cliffs, New Jersey : Prentice-Hall PTR , 1993.

7. Lucas Cuesta, Juan Manuel. Análisis e implementación de mejoras para un reconocedor

de habla continua. Proyecto Fin de Carrera. Madrid : ETSIT, 2006.

8. Pérez Magariños, Nuria. Mejora de la interfaz vocal de control de un robot autónomo

móvil. Adaptación acústica y generación supervisada de mapas. Proyecto Fin de Carrera.

Madrid : ETSIT, 2008.

9. Huang, Xuedong, Acero, Alex y Hon, Hsiao Wuen. Spoken language processing. A guide

to theory, algorithm and system development. New Jersey : Prentice-Hall PTR, 2001.

10. García Mancebo, Javier. Desarrollo de un sistema en tiempo real para la identificación

de locutores a través de la voz en un entorno domótico. PFC. Madrid : ETSIT, 2007.


- 194 -

11. Alcázar Prior, Rosario. Desarrollo de un conversor texto-voz con emociones y

aplicación a la interacción hablada en entornos inteligentes. Proyecto Fin de Carrera. Madrid :

ETSIT, 2007.

12. Barra-Chicote, R., Yamagishi, J., Montero, J. M., King, S., Lufti, S., Macias-Guarasa, J.

Generación de una voz sintética en castellano basada en HMM para la evaluación Albayzín 2008:

Conversión texto a voz. 2008.

13. Cancela González, Jorge. Desarrollo de una interfaz multimodal para un robot

domótico móvil. Control por voz y mando a distancia. Proyecto fin de carrera. Madrid : ETSIT,

2009.

14. Peñalva Zambrano, Jorge Miguel y García Moral, Daniel. Groucho está contento,

Groucho quiere jugar…. http://emotionalbot.wordpress.com/page/1/.

15. Montero de Espinosa Marrón, Ainhoa. Análisis y desarrollo de una interfaz gestual

para ambientes inteligentes. Proyecto fin de carrera. Madrid : ETSIT, 2008.

16. Fueyo Ramírez, Enrique y Hernández Munuera, Juan Carlos. 3enRaya jugando contra

Groucho. http://3nraya.wordpress.com/.

17. Guirao Rodríguez, Alejandro. Mejora de la interfaz vocal para el control de un equipo

de alta fidelidad. Proyecto fin de carrera. Madrid : Etsit, 2006.

18. García Sánchez, Rafael. Controlling a High Fidelity system from speech. Proyecto fin de

carrera. Madrid : ETSIT, 2005.

19. Müller, Marcus. IRTrans User Manual. http://www.irtrans.de/en/.

20. Zlotnik, Alexander. DRAC (Distributed Remote ACcess system) - A remote access

system to electronics laboratories. Proyecto fin de carrera. MADRID : ETSIT, 2007.

21. Heathfield, Richard. 2002. http://users.powernet.co.uk/eton/c/ttt.c.

22. Leite, Iolanda y Pereira, André. iCat, the Affective Chess Player. Porto Salvo, Portugal.

2007.

23. Feelix Growing. About Feelix Growing. Feelix Growing. http://www.feelix-

growing.org/about.

Bibliografía

- 195 -

24. MIT Affective Computing Group. Affective Computing Group Home Page.

http://affect.media.mit.edu/index.php.

25. Pfeiffer, R. Artificial intelligence models of emotion. . In Cognitive Perspectives on

Emotion and Motivation. V. Hamilton, G. Bower & N. Frijda. Kluwer Academic Publishers, 1988.

26. Artificial Intelligence Laboratory. The "Fungus Eater" approach to the study of

emotion: A View from Artificial Intelligence. Universidad de Zürich, 1994.

27. Scherer, K.R., Shorr, A. y Johnstone, T. Appraisal processes in emotion: theory,

methods, research. Oxford University Press. 2001.

28. Wikipedia.Appraisal Theory. http://en.wikipedia.org/wiki/Appraisal_theory.

29. Ruebenstrunk, Gerd. Emotional Computers. Computer models of emotions. 1998.

30. Ortony, A., Clore, G.L. y Collins, A. The cognitive structure of emotions. Cambridge,

U.K. : Cambridge University Press., 1988.

31. Roseman, I.J., Antoniou, A.A. y Jose, P.A. Appraisal Determinants of Emotions:

Constructing a More Accurate and Comprehensive Theory. Cognition and Emotion. 1996.

32. Scherer, K.R. On the nature and function of emotion: a component process approach.

Hillsdale : Erlbaum, 1984.

33. Frijda, N. H. y Swagerman, J. Can computers feel? theory and design of an emotional

system. Cognition & Emotion. 1987.

34. Moffat, D. y Frijda, N.H. Where there's a Will there's an Agent. M.J. Woolridge y N.R.

Jennings. Intelligent Agents - Proceedings of the 1994 Workshop on Agent Theories,

Architectures, and Languages. Springer, 1995.

35. Oatley, K. y Johnson-Laird, P.N. Towards a cognitive theory of emotions. 1987.

36. Maslow, A.H. A Theory of Human Motivation. Psychological Review. 1943.

37. Instituto Nacional de Estadística. Encuesta sobre Equipamiento y Uso de Tecnologías

de la Información y Comunicación en los hogares. 2003-2008.


- 196 -

38. Hurtado Gil, Sandra Victoria. Representación de la arquitectura de software usando

UML. Universidad Icesi.

39. XML-RPC. http://www.xmlrpc.com/.

40. W3C. SOAP Version 1.2 Part 1: Messaging Framework (Second Edition).

http://www.w3.org/TR/soap12-part1/.

41. Frijda, N.H. y Moffat, D. Modeling emotion. Cognitive Studies. 1994.

42. Oatley, K. Best Laid Schemes. The Psychology of Emotions. Cambridge University

Press. 1992.

43. Salazar Canal, Jorge. Diseño, implementación y pruebas de esquemas de

personalización en sistemas de gestión de diálogo persona-máquina a través de la identificación

de la voz. Proyecto fin de carrera. Madrid : ETSIT, 2009.

44. Saxe, D. y Foulds, R. Automatic Face and Gesture Recognition,. Toward Robust Skin

Identification in Video Images,”. 1996.

45. Rowley, H., Baluja, S. y Kanade, T. Neural Network-Based Face Detection,. IEEE Trans.

Pattern Analysis and Machine Intelligence. 1998.

46. Lucas, S.M. Face recognition with continuos n-tuple classifier. BMVA Press, 1997.

Brithis Machine Vision Conference.

47. Viola, P. y Jones, M. Robust real-time face detection. International Journal of

Computer Vision. 2003.

48. Raitio, Tuomo. Hidden Markov Model Based Finnish Text-to-Speech System Utilizing

Glottal Inverse Filtering. Master’s Thesis. HELSINKI : UNIVERSITY OF TECHNOLOGY, 2008.

49. Ferreiros López, Javier y Ellis, Daniel P. W. Using acoustic condition clustering to

improve acoustic change detection on broadcast news. 2000.

50. Zen, Heiga, Tokuda, Keiichi y Black, Alan W. Statistical parametric speech synthesis,

Speech Communicatio. 11, 2009, Vol. 53.

Apéncide A- Vocabulario del Reconocedor

- 197 -

APÉNDICE A: Vocabulario del Reconocedor

arribaalaizquierda -> orden=[A]

arribaenelcentro -> orden=[B]

arribaaladerecha -> orden=[C]

izquierda -> orden=[D]

centroalaizquierda -> orden=[D]

centro -> orden=[E]

centrocentro -> orden=[E]

derecha -> orden=[F]

centroderecha -> orden=[F]

abajoalaizquierda -> orden=[G]

abajoenelcentro -> orden=[H]

abajoaladerecha -> orden=[I]

porsupuesto -> orden=[Y]

si -> orden=[Y]

claro -> orden=[Y]

nidebroma -> orden=[N]

no -> orden=[N]

atiendeahora -> orden=[atiende]

buenas tardes -> orden=[atiende]

hola -> orden=[atiende]

hola groucho -> orden=[atiende]

saludos -> orden=[atiende]

dejadeatenderme -> orden=[deja_atender]

adios-> orden=[deja_atender]

hastaluego -> orden=[deja_atender]

empiezaalimpiar -> orden=[pasa_aspiradora]

dejadelimpiar -> orden=[para_aspiradora]

terminadelimpiar -> orden=[para_aspiradora]

veacargarte -> orden=[ir_casa]

veacasa -> orden=[ir_casa]

enciendelaluz -> orden=[enciende_luz]

apagalaluz -> orden=[apaga_luz]

enciende la radio -> orden=[enciende_radio]

pon la radio -> orden=[enciende_radio]

quita la radio -> orden=[apaga_radio]

eres muy malo jugando al tres en raya -> orden=[insulto]

me pareces muy malo jugando al tres en raya -> orden=[insulto]

me pareces un poco tonto -> orden=[insulto]

eres un poco tonto -> orden=[insulto]

no eres muy listo -> orden=[insulto]

groucho eres tonto -> orden=[insulto]

eres muy bueno jugando al tres en raya -> orden=[alabanza]

me pareces muy bueno jugando al tres en raya -> orden=[alabanza]

me pareces bastante listo -> orden=[alabanza]


- 198 -

eres bastante listo -> orden=[alabanza]

eres muy listo -> orden=[alabanza]

groucho eres muy listo -> orden=[alabanza]

te voy a presentar a un nuevo usuario -> orden=[presentacion]

éste es un amigo mío -> orden=[presentacion]

quiero jugar -> [Y]

quiero jugar al tres en raya -> [Y]

carlos -> [nombre]

carlos sanz -> [nombre]

carlos sanz moreno -> [nombre]

juan manuel -> [nombre]

juan manuel montero -> [nombre]

juan manuel montero martínez -> [nombre]

Apéncide B – Listado de Frases para Sintetizar

- 199 -

APÉNDICE B: Listado de Frases para Sintetizar

[JUEGO GANAR]

1 He ganado.

2 Te he ganado.

3 He ganado soy muy feliz.

[JUEGO GANAR AMIGO]

1 Colega tienes que seguir practicando.

1 Amigo mío pensabas que ibas a ganarme?.

[JUEGO GANAR CONOCIDO]

10 JEJEJE te he ganado.

10 Madre de dios que malo eres.

[JUEGO PERDER]

10 Me has ganado Cómo ha podido suceder?.

10 Esto no va a quedar así me la próxima vez te venceré.

[JUEGO INICIAR]

5 Vamos cobarde compite conmigo.

10 Juega conmigo.

[JUEGO NEUTRAL]

8 Vamos te toca.

1 Te cuesta decidir tu movimiento?.

[JUEGO TRAMPA]

80 Seguro que lo puedes hacer mejor.

50 Esa no es una posición correcta.

[CONOCER NOMBRE]

50 Cómo te llamas?.

25 Cuál es tu nombre?.

25 Cómo decías que te llamabas?.

40 Cuál es tu nombre completo?.

[CONOCER MAIL]

70 Cuál es tu i meil?.

10 Tienes correo electrónico?.

[CONOCER PROFESION]

1 A qué te dedicas?.

2 En qué trabajas?.

[CONOCER NUEVO]

5 Hay alguien nuevo?.

8 No consigo identificarte eres nuevo?.

[CONOCER FIN]

1 Encantado de conocerte.

1 Hola mucho gusto.

[SALUDAR UKWN]

1 Buenos días.

2 En qué puedo ayudarle?

[SALUDAR KNWN]


- 200 -

1 Hola que tal?.

4 Te puedo ayudar en algo?.

[INSULTO]

1 No me gusta que me insultes.

1 Me estas enfadando.

[SALUDAR FRND]

1 Hola amigo.

1 Hola.

5 Qué quieres que haga?.

[DESPEDIR UKWN]

1 Mucho gusto hasta otro momento.

[DESPEDIR KNWN]

1 Hasta luego.

[DESPEDIR FRND]

1 Nos vemos!.

[FIN]

Apéndice C – Experimento de Identificación

- 201 -

APÉNDICE C: Experimento de Identificación

Base de datos Modo Historia Locutores Lambda Aciertos Frases Tasa Locutor inicial

GTH 1 3 30 4.5 1019 1498 0.660

GTH 1 4 30 4.5 1344 1498 0.880

GTH 1 5 30 4.5 1364 1498 0,901

GTH 1 10 30 4.5 1476 1498 0,982

GTH 1 5 30 2 788 1498 0,473

GTH 1 5 30 2,5 1085 1497 0,694

GTH 1 5 30 3 1082 1497 0,692

GTH 1 5 30 3,5 1167 1497 0,755

GTH 1 5 30 4 1382 1498 0,914

GTH 1 5 30 4,5 1364 1498 0,901

GTH 1 5 30 5 1364 1498 0,901

GTH 1 5 30 10 1370 1498 0,905

GTH 1 5 30 4,5 1364 1498 0,901 0

GTH 1 5 30 4,5 1444 1498 0,960 2

GTH 1 5 30 4,5 1273 1498 0,833 4

GTH 1 5 30 4,5 1173 1498 0,759 6

GTH 1 5 30 4,5 1236 1498 0,806 8

GTH 1 5 30 4,5 1371 1498 0,906 10

GTH 1 5 30 4,5 1330 1498 0,875 12

GTH 1 5 30 4,5 1236 1498 0,806 14

GTH 1 5 30 4,5 1321 1498 0,869 16

GTH 1 5 30 4,5 1446 1498 0,961 18

GTH 1 5 30 4,5 1302 1498 0,855 20

GTH 1 5 30 4,5 1417 1498 0,940 22

GTH 1 5 30 4,5 1369 1498 0,904 24

GTH 1 5 30 4,5 1357 1498 0,895 26

GTH 1 5 30 4,5 1281 1498 0,839 28

Tabla 17.Experimento Identificación de usuarios modo 1


- 202 -

Modo Historia Locutores Locutores

Conocidos Lambda Frases

Cambios

Detectados Cambios Ok

Cambios OK

Detectados Precisión Recall

2 5 30 1 2 1498 885 29 23 0,032 0,966

2 5 30 1 3 1498 266 18 10 0,064 0,586

2 5 30 1 4 1498 219 6 2 0,023 0,172

2 30 30 10 3 1498 216 8 5 0,034 0,350

2 30 30 10 4 1498 210 6 4 0,025 0,250

Tabla 18.Experimento Identificación de usuarios modo 2 base de datos GTH

Apéndice D – Relación entre Clases

- 203 -

APÉNDICE D: Relación entre Clases

En este apéndice se realizará un análisis estructural del sistema. Con vistas a este objetivo

se presentarán, por un lado, la jerarquía entre clases. Posteriormente se analizará el

funcionamiento del método main y las llamadas que realiza.

Para la realización del modelo emocional se tiene la clase CEmotion.

Esta clase define la funcionalidad señalada y consta de un array de elementos

TEmociones. Cada una de las posiciones de ese array es una emoción distinta: alegría, tristeza,

enfado…

Además, se necesita la implementación de los niveles de necesidad de Maslow para los

que se tiene el siguiente esquema

Figura 82. Definición de clase CEmotion


- 204 -

Como se ve cada necesidad está modelada por una clase heredada de CGoalProcess, la

cual proporciona la funcionalidad básica para el cálculo emocional (parte de ella heredada, a su

vez, de la clase CIOProcess). Esto consiste en mecanismos de regiones críticas, mecanismo de

generación de NIF, etc. A partir de esta clase básica cada nivel de necesidad genera unas

funciones que serán llamadas por las tareas que produzcan eventos. A continuación se presenta

el diagrama que describe todo el proceso emocional.

Figura 83. Jerarquía de clases para las necesidades


- 205 -

Para la realización del Módulo de Aplicaciones se tiene la siguiente jerarquía para las

tareas remotas.

Figura 84. Diagrama de implementación del Módulo Emocional


- 206 -

Como se puede ver, cualquier tarea hereda la clase básica CmoduloBaseSoap. Esta clase

proporciona la siguiente funcionalidad.

De esos métodos EnviarRespuestaAUsuario y ComunicarSituaciónMódulo son virtuales

obligano así a que cada tarea implemente una funcionalidad para estos métodos, que serán a la

postre los encargados de comunicar la respuesta y la variación de necesidades al módulo de

Figura 86. Jerarquía de clases de tareas remotas

Figura 85. Funcionalidad de CmoduloBaseSoap


- 207 -

comportamiento. Hay que señalar que cada una de estas clases *Soap son clientes de modo que

la comunicación es remota.

Finalmente cabe proporcionar el árbol de llamadas que se producen desde el main del

sistema.

Figura 87. Árbol de llamadas del método main


- 208 -

Este es el método principal del sistema, desde él se lanzan el resto de módulos que corren

localmente (llamadas a los métodos Lanza*). Por otra parte realiza las llamadas dentro del bucle

principal.

Finalmente, los árboles de llamadas para los servidores de cara y de síntesis serán.

Orden de secuencia Finalidad Método

1 Lectura de entradas actuacionOpencv ()

2 Lectura de entradas enviaPalabraDelReconocedor()

3 Lectura de entradas analizaSensores()

4 Lectura de entradas lectura3enRaya()

5 Análisis de necesidades needsArray[i]->ProcessLoop()

6 Análisis de necesidades imprimeNiveles()

7 Análisis de emociones emotions->amortiguacionEmociones()

8 Análisis de emociones emotions->calcularNeutraYSatura()

9 Análisis de emociones emotions->buscaEmocionMaxima()

10 Análisis de emociones emotions->imprimeEmociones()

11 Generación de respuesta invocaSintetizador()

12 Generación de respuesta definirCara()

Tabla 19.Secuencia del bucle principal


- 209 -

Figura 88. Árbol de llamadas para el servidor de síntesis

Figura 89. Árbol de llamadas para el servidor de cara

Diseño e implementación de un asistente personal capaz de...

Documents

Transcript of Diseño e implementación de un asistente personal capaz de...