MemoriaCarlos 14.7.09 - Grupo de Tecnología del Habla

ÍNDICE DE CONTENIDOS
ÍNDICE DE CONTENIDOS ...................................................................................... I
ÍNDICE DE FIGURAS. .......................................................................................... III
1.
INTRODUCCIÓN ......................................................................................... 1
1.1.
2.
INTERFAZ PERSONA-MÁQUINA .................................................................. 3
2.1.
Estado del arte: Interfaces Persona-Máquina ................................................ 3
2.2.
Interfaz Verbal ............................................................................................. 3
2.2.1.
2.2.2.
2.2.3.
2.3.
2.3.1.
2.4.
2.4.1.
2.4.2.
3.
4.
5.
Estructura de la memoria ............................................................................. 2
Reconocimiento de voz (SERVIVOX) ............................................................................. 4
Síntesis de voz con emociones ..................................................................................... 4
Identificador de usuarios .............................................................................................. 4
Interfaz Visual .............................................................................................. 4
Tratamiento de Imágenes (Opencv) ............................................................................. 4
Interfaz Física ............................................................................................... 4
Brazo Robótico ............................................................................................................. 5
Cara Robótica ............................................................................................................... 5
APLICACIÓN ............................................................................................... 5
3.1.
Control Roomba ........................................................................................... 6
3.2.
Control Infrarrojos........................................................................................ 6
3.3.
Control Luz ................................................................................................... 6
3.4.
Control Conversación ................................................................................... 6
3.5.
Tres en raya virtual....................................................................................... 6
3.6.
Tres en raya físico......................................................................................... 6
EMOTIVIDAD ............................................................................................. 6
4.1.
Relaciones.................................................................................................... 6
4.2.
Emociones ................................................................................................... 6
ARQUITECTURA GENERAL DEL SISTEMA ..................................................... 7
5.1.
5.1.1.
5.1.2.
5.1.3.
5.1.4.
5.1.5.
5.1.6.
5.1.7.
Arquitectura de comunicaciones. .................................................................. 7
Estado del arte: Arquitecturas de comunicaciones. ..................................................... 7
Descripción de una arquitectura Cliente/Servidor ....................................................... 9
Componentes de una arquitectura Cliente/Servidor ................................................... 9
Características de una arquitectura Cliente/Servidor ................................................ 10
Ventajas e inconvenientes de una arquitectura Cliente/Servidor ............................. 11
Estructura Cliente/Servidor implementada. ............................................................... 12
Mecanismo de comunicación: SOAP .......................................................................... 14
I
5.1.7.1. Sockets .................................................................................................................. 14
5.1.7.2. RPC ........................................................................................................................ 14
5.1.7.2.1. XML-RPC ........................................................................................................ 15
5.1.7.2.2. SOAP .............................................................................................................. 15
5.1.8. Estructura física implementada .................................................................................. 17
5.2.
Modelo de Comportamiento ...................................................................... 18
5.2.1. Estado del arte: Módulo de comunicaciones. ............................................................ 18
5.2.1.1. GALAXY-II .............................................................................................................. 18
5.2.1.2. CU Communicator ................................................................................................. 19
5.2.2. Módulo de comportamiento implementado .............................................................. 20
6.
BIBLIOGRAFÍA...........................................................................................22
II
ÍNDICE DE FIGURAS.
Figura 1.
Figura 2.
Figura 3.
Figura 4.
Figura 5.
Figura 12.
Figura 11.
Figura 13.
Figura 14.
Figura 6.
Figura 7.
Figura 8.
Figura 9.
Figura 10.
(Instituto Nacional de Estadística, 2003-2008) .......................................................................... 1
Arquitectura General del Sistema .............................................................................................. 7
Topologías de redes peer-to-peer. ............................................................................................. 8
Esquema genérico de arquitectura cliente-servidor. ................................................................. 9
Estructura de cliente-servidor de la implementación .............................................................. 13
Solicitud XML-RPC .................................................................................................................... 15
Respuesta XML-RPC ................................................................................................................. 15
Solicitud SOAP .......................................................................................................................... 16
Respuesta SOAP ....................................................................................................................... 16
Estructura física implementada ............................................................................................... 17
Script hub modelo GALAXY-II ................................................................................................... 19
Arquitectura GALAXY-II ............................................................................................................ 19
Proceso de comunicación con el reconocedor ......................................................................... 20
Proceso de comunicación con el sintetizador de voz ............................................................... 21
III
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 esta evolución queda más que patente.
Figura 1.
(Instituto Nacional de Estadística, 2003-2008)
Estas tendencias generan problemas que hasta ahora no habían aparecido relacionados
con la dificultad de adaptación de determinados colectivos. Por ejemplo, según el INE, uno de
los principales motivos de que el porcentaje de penetración de acceso a internet en los hogares
sea de aproximadamente un 50% en el 2008 es que dichos colectivos“…tienen pocos
conocimientos para utilizarlos (26,1%)”. 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 74 años que ha utilizado el ordenador en los últimos tres meses se
reduce a “…el 61,0% de la población…”. Esto sustenta la idea de que es necesario un cambio
en la forma de interactuar con los aparatos electrónicos.
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 parecen demasiado complicados como 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, velocidad, etc.
1
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 más
cerca de las personas de modo que permiten la interacción con los aparatos minimizando el
proceso de 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, puesto que se consideran
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 que
consideramos de importancia para acercar personas y máquinas: las interfaces, más amigables;
la aplicación, un asistente domótico 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.
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) que tiene como objeto la investigación para la
integración del control verbal en entornos domóticos. En este sentido varias funcionalidades
incluidas han sido realizadas en otros proyectos el grupo.
1.1.
Estructura de la memoria
La presente memoria está estructurada en función de las tres vías de desarrollo
implementadas.
Arquitectura general del sistema
Interfaz Persona-Máquina implementada explicando.
Aplicaciones
Emotividad se hablará de emociones y relaciones.
Resultados
Líneas de trabajo futuras.
2
2.
INTERFAZ PERSONA-MÁQUINA
Como se ha mencionado en la introducción, los aparatos electrónicos presentan
interfaces, que si bien están simplificadas no dejan de ser más cercanas a la máquina. Es el caso
de un mando a distancia. Aunque en un botón ponga power y sea de otro color, el hecho de
presionar botones es una acción que no está relacionada con una forma de comunicación propia
de la persona. En este proyecto se sustituye esa forma de interactuar por otras más cercanas a la
forma en la que una persona se dirigiría a otra, por ejemplo “enciende la luz”, “pon la luz” o frases
similares.
Por otro lado, para crear sistemas cuya utilización no sea considerada desesperante por
parte de los usuarios se está tendiendo a las interfaces multimodales. Este tipo de interfaces
integran diferentes vías de comunicación de modo que los usuarios y las máquinas intercambian
información de diferentes maneras. En consecuencia, la utilización de los sistemas se convierte
en una experiencia menos predeterminada. Es decir, ahora, si el usuario quiere alegrar al
sistema puede acariciarle o dejarse ver entre otras acciones.
Para el modelo implementado se ha incluido una interfaz verbal asociada al
reconocimiento de voz mediante comprensión, síntesis de voz con emociones e identificador de
usuario. También se emplea una interfaz física consistente en una cara y un brazo robóticos. El
brazo es utilizado para interaccionar con el usuario en determinadas aplicaciones como los
juegos, mientras que la cara es un símbolo del sistema cuya función es que las personas que
tienen dificultades, o incluso a las que les desagrada el uso de un ordenador, puedan dirigirse a
algo físico con un cierto parecido a las personas. Por último se han utilizado una interfaz visual
basada en la librería de tratamiento de imágenes OpenCV para la entrada de datos y la pantalla
como salida.
A continuación se profundizará en cada una de ellas.
2.1.
Estado del arte: Interfaces Persona-Máquina
2.2.
Interfaz Verbal
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 las
personas.
Gracias a esto, a la hora de reconocer frases, si se crea una base de datos de tamaño y
libertad de reconocimiento suficiente, el usuario no tendrá que aprender ningún comando ya
que lo que solicitará lo hará de manera intuitiva. Por ejemplo, si el usuario desea 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, desde la máquina al 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
3
información por parte del sistema, el proceso transcurre de forma similar a una conversación
entre personas. 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, lo cual hace que el uso por
parte de las personas sea completamente transparente.
Todas estas ventajas conllevan que la interfaz verbal constituya la principal forma de
comunicación del sistema. Facilitando el proceso de intercambio de información y
contribuyendo a conseguir sistemas que sean aceptados por la mayor parte de las personas.
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 uno de ellos
2.2.1.
Reconocimiento de voz (SERVIVOX)
2.2.2.
Síntesis de voz con emociones
2.2.3.
Identificador de usuarios
2.3.
Interfaz Visual
Los motivos que llevan a incluir una interfaz de este tipo es que se hace necesaria alguna
forma de captar información del entorno sin solicitarla. Es decir, si por ejemplo el sistema realiza
cualquier acción cuando hay alguien cerca de él habrá que detectar esa presencia resultando
inapropiado 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
información del entorno tan heterogénea como si hay o no luz o si el usuario sonríe o está
enfadado.
Como salida de 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 en el curso 2008-2009 que realizaron una práctica innovadora sobre detección de
emociones mediante Opencv.
A continuación se profundizará en el empleo del tratamiento de imágenes mediante la
librería Opencv.
2.3.1.
2.4.
Tratamiento de Imágenes (Opencv)
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
4
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 la creación de un sistema de
sensores que permitiese jugar al tres en raya contra la máquina mediante el movimiento de
piezas.
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.
3.
2.4.1.
Brazo Robótico
2.4.2.
Cara Robótica
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 muestre a los usuarios 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 al 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.
5
4.
3.1.
Control Roomba
3.2.
Control Infrarrojos
3.3.
Control Luz
3.4.
Control Conversación
3.5.
Tres en raya virtual
3.6.
Tres en raya físico
EMOTIVIDAD
Constituye la piedra angular de este sistema. Nace de la idea de elevar las máquinas a la
categoría de compañeros domóticos ya que tendrán más aceptación por parte de los usuarios si
se puede interaccionar con ellos 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, ya que de otra forma,
un sistema con el que se convive y al que se trata como si fuese algo nuevo siempre genera un
rechazo. La segunda funcionalidad es más ambiciosa y trata la idea de generar artificialmente
emociones de modo que el sistema tenga un comportamiento cercano al humano para realizar
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 con un igual.
4.1.
Relaciones
4.2.
Emociones
6
5.
ARQUITECTURA GENERAL DEL SISTEMA
La descripción esquemática de la arquitectura general del sistema se ilustra en la Figura x.
Como se ve existen dos módulos de interfaces. Uno de ellos es la interfaz de entrada que recibe
la
información
del
hardware y que tras un
cierto
proceso
de
adaptación entrega al
módulo
de
comportamiento.
Este
módulo será detallado más
adelante pero su misión es
reconducir
dicha
información al módulo de
emotividad y al módulo de
aplicaciones. El módulo de
aplicaciones genera una
respuesta relacionada con
los objetivos de cada tarea
mientras que el módulo de
Figura 2. Arquitectura General del Sistema
emotividad genera una
respuesta emocional e
información acerca de la relación con el usuario. Finalmente, el módulo de comportamiento
recibe estas respuestas provenientes de cada módulo y genera una respuesta final que será
entregada directamente a la interfaz de salida que actuará sobre el hardware.
5.1.
Arquitectura 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.
5.1.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
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
7
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 usuario 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:


P
eer-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.
P
eer-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
Figura 3.
Topologías de redes peer-to-peer.
puro.
8
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.
5.1.2.
Descripción de una arquitectura Cliente/Servidor
Su funcionamiento es sencillo (figura x): se tiene un ordenador cliente, que requiere un
servicio de un ordenador servidor que 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
determinadas tareas y servidores para otras ya que el objetivo es que cada ordenador realice las
funciones óptimas para sus recursos.
Figura 4.
Esquema genérico de arquitectura cliente-servidor.
La tendencia en este tipo de arquitecturas es que el servidor se encargue del peso de la
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 de los módulos, de modo que
pueden estar distribuidos físicamente en diferentes equipos incluso en diferentes localidades
geográficas.
5.1.3.
Componentes de una arquitectura Cliente/Servidor
Los componentes principales de una arquitectura Cliente/Servidor son:

C
liente: también denominado front-end es el proceso que permite al
usuario formular las solicitudes de información. Entre las funciones que
9

5.1.4.
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.
S
ervidor: 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.
Características de una arquitectura Cliente/Servidor
Las características básicas de una arquitectura Cliente/Servidor son:








C
ombinació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.
L
as tareas del cliente y del servidor tienen diferentes requerimientos en
cuanto a recursos del sistema, periféricos necesarios, etc.
S
e 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.
E
xiste una clara distinción de funciones basada en el concepto de
"servicio", que se establece entre clientes y servidores.
L
a relación establecida puede ser de muchos a uno. Un servidor puede dar
servicio a muchos clientes, regulando su acceso a recursos compartidos.
L
os 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 pasivo ya que esperan las peticiones de los clientes.
N
o 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
10

5.1.5.
operativo del cliente y del servidor no son siempre la misma.
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.
Ventajas e inconvenientes de una arquitectura Cliente/Servidor
Las principales ventajas del esquema Cliente/Servidor son:





U
na de las causas que más ha promovido el uso de sistemas
Cliente/Servidor es la proliferación de plataformas hardware a 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.
A
l 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.
A
sí mismo, este tipo de sistemas permiten que los ordenadores
tradicionales se interconecten con nuevos sistemas creando
funcionalidades que antes no estaban disponibles.
A
l 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.
L
a 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:
11




5.1.6.
El
mantenimiento de estos sistemas resulta costoso pues se trata de
conjuntos heterogéneos de software y hardware distribuido cuya
depuración resulta costosa.
P
ara 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.
A
demá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.
E
s 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.
Estructura Cliente/Servidor 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.
12
En la figura x se puede apreciar el esquema de comunicaciones de la arquitectura
implementada. Como puede apreciarse el módulo que obtiene información del exterior (interfaz
Figura 5.
Estructura de cliente-servidor de la implementación
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 activos 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
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
13
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.
5.1.7.
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.
5.1.7.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 es muy limitado
haciendo necesarios métodos que la analizasen para determinar la tarea a realizar. 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.
5.1.7.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
14
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).
5.1.7.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 pretenda 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.
<?xml version="1.0"?>
<methodResponse>
<params>
<param>
<?xml version="1.0"?>
<methodCall>
<methodName>examples.getStateName
</methodName>
<params>
<param>
<value><i4>40</i4></value>
</param>
</params>
</methodCall>
Figura 6.
<value><string>South
Dakota</string></value>
</param>
</params>
</methodResponse>
Figura 7.
Solicitud XML-RPC
Respuesta XML-RPC
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.
5.1.7.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
15
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.
A continuación se presenta un ejemplo de solicitud y respuesta mediante SOAP.
<soapenv:Envelope>
<soapenv:Envelope>
xmlns:soapenv="http://schemas.xmlsoap.org/soap/
envelope/"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelo
pe/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addr
essing">
<soapenv:Header>
<wsa:ReplyTo>
xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance">
<soapenv:Body>
<req:echo
xmlns:req="http://localhost:8080/axis2/services
/MyService/">
<req:category>classifieds</req:category>
</req:echo>
</soapenv:Body>
</soapenv:Envelope>
Figura 8.
Solicitud SOAP
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/ad
dressing/role/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:From>
<wsa:Address>http://localhost:8080/axis2/services/MyS
ervice</wsa:Address>
</wsa:From>
<wsa:MessageID>ECE5B3F187F29D28BC11433905662036</wsa:
MessageID>
</soapenv:Header>
<soapenv:Body>
<req:echo
xmlns:req="http://localhost:8080/axis2/services/MySer
vice/">
<req:category>classifieds</req:category>
</req:echo>
</soapenv:Body>
</soapenv:Envelope>
Figura 9.
Respuesta 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.
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
16
decisión final. En este caso se ha utilizado JABON (Rodríguez Losada), una utilidad para la
creación automática del código SOAP a partir de la implementación en C++ de las funciones.
5.1.8.
Estructura física implementada
Finalmente, con la idea de presentar el sistema completo, se adjunta la figura x en la que
se ilustra la estructura física del sistema.
Figura 10.
Estructura física implementada
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 (robint) o el sintetizador de voz, que por sus características necesitan grandes recursos,
deben ejecutarse en máquinas independientes.
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
17
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.
5.2.
Modelo de Comportamiento
En esta arquitectura el módulo de comportamiento juega un papel importante como
coordinador del sistema. Como se ha visto, cualquier mensaje que quieran intercambiar los
módulos pasa por él. Además presenta la necesidad de que debe 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 ser el cuello de botella del sistema.
Antes de abordar la solución propuesta se analizarán las posibles alternativas.
5.2.1.
Estado del arte: Módulo de comunicaciones.
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, este es el caso de las
aplicaciones basadas en reconocimiento de voz. Estas aplicaciones unidas a la posibilidad de
conexión a internet que casi cualquier ordenador tiene, proporciona el marco perfecto para la
automatización de servicios telefónicos como alquiler de coches, reserva de hoteles, información
de vuelos, etc.
Este marco de aplicación presenta una gran complejidad y es por ello que se tiende a
dividir este tipo de sistemas en módulos con funcionalidades independientes. 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 comunicadores. A continuación, debido a sus
características, se van a analizar dos: el GALAXY-II Communicator (Seneff, y otros, 1998)
elaborado como actualización del GALAXY (Goddeau, y otros, 1994) por el Massachusetts
Institute of Technology, y el CU Communicator (Pellom, y otros, 2000) creado por la Universidad
de Colorado.
5.2.1.1.
GALAXY-II
GALAXY-II es una arquitectura Cliente/Servidor para acceder a información online usando
reconocimiento de voz. En la figura X se puede apreciar la representación esquemática del
sistema.
18
La peculiaridad de este sistema consiste en que la interacción del hub 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 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 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 que definía esa regla. Adicionalmente, el hub puede esperar un token del servidor
con la variable de salida. Además la variables de entradas y salidas son almacenadas en un
Figura 11.
Script hub modelo GALAXY-II
master token interno del hub.
Como se ve, es el hub quien decide, en
base a una serie de scripts qué servidor debe
responder a la acción. Por tanto, se considera
que este tipo de módulo de comunicación
presenta inteligencia.
5.2.1.2.
CU Communicator
Análogo al modelo GALAXY-II aparece
el CU Communicator. Éste también es un
modelo Cliente/Servidor para acceder a
información online mediante reconocimiento
de voz. La particularidad de este sistema es
Figura 12. Arquitectura GALAXY-II
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 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 nuevo audio disponible y que debe ser
19
entregado al reconocedor de voz. De esta forma el hub actúa como un mero router enviando la
información entre módulos.
5.2.2.
Módulo de comportamiento implementado
La solución adoptada pasa por un término medio entre las nombradas anteriormente. En
este sistema se distingue el tipo de información a transmitir en función del origen o destino. Así
pues se transmitirá información proveniente del reconocedor de voz, información dirigida al
sintetizador de voz e información dirigida al modelo emocional. En función del tipo de mensaje
el módulo de comportamiento presentará o no inteligencia. A continuación se expone el
funcionamiento en cada caso.
El proceso implementado para transmitir mensajes generados en por el reconocedor de
voz consta de varias etapas y se puede ver en la figura x. Es importante señalar que en este caso
las decisiones sobre a quién debe ser entregado el mensaje recae en el propio módulo de
comportamiento y por ello se puede decir que presenta inteligencia.
1.
2.
3.
4.
El
reconocedor de voz detecta una nueva frase e identifica un concepto asociado. Este
hecho es indicado al módulo de comportamiento actualizando el número de versión
asociado al concepto.
A
partir de este momento se inicia un proceso de solicitud de información a cada tarea. El
modelo de comportamiento realiza una transmisión en modo prueba del concepto
reconocido a todos los módulos capaces de recibir información del reconocedor.
C
ada tarea analiza el concepto recibido en modo de prueba e indica al modelo de
comportamiento si ese concepto le resulta de utilidad. El modelo de comportamiento
mientras tanto, espera un tiempo determinado para recibir la respuesta de las tareas. Si
ninguna tarea responde positivamente descartará el mensaje y finalizará el proceso.
D
e entre todas las tareas que indiquen la validez del concepto para sus objetivos, el
módulo de comportamiento enviará el concepto de forma prioritaria a aquella que esté
activa. Una tarea está activa si se encuentra en mitad del proceso para conseguir su
objetivo. Por ejemplo, si está jugando a un juego, los conceptos válidos para el juego
tenderán
a
ir
prioritariamente a esa tarea,
ya que se encuentra activa,
no siendo así en el caso en el
que aún no se haya
empezado a jugar. Si no hay
ninguna tarea activa se
enviará a cualquiera de las
Figura 13. Proceso de comunicación con el reconocedor
que acepten el concepto
como válido siguiendo un
20
orden preestablecido. En el caso de que hubiese varias tareas activas simultáneamente,
el sistema también elegiría una de ellas en función de un orden preestablecido.
Para la transmisión de los mensajes con destino al sintetizador el módulo de
comportamiento no presenta inteligencia añadida ya que simplemente envía la solicitud.
El algoritmo de funcionamiento es el mostrador en la figura x. Cada componente del
sistema que desee sintetizar una frase determina un conjunto de parámetros que permiten
seleccionarla entre todas las posibles. Además, indica al módulo de comportamiento que tiene
una nueva solicitud mediante una actualización de la versión del concepto a sintetizar.
Seguidamente, el módulo de comportamiento recorre cada uno de los componentes capaces de
generar un mensaje para el sintetizador analizando su situación. Si el módulo desea sintetizar
algún concepto el modelo
de
comportamiento
completa la información
suministrada por dicho
módulo añadiendo la
información relativa a la
relación con el usuario y al
estado emocional del
sistema. Finalmente, se
Figura 14. Proceso de comunicación con el sintetizador de voz
envía la orden de síntesis
al módulo sintetizador.
Como se puede apreciar, el sistema envía todas las solicitudes de síntesis al módulo
sintetizador siendo éste el que se encarga de retrasar una solicitud si ya hay otra en marcha.
Por último, para la transmisión de los mensajes destinados a modificar el estado
emocional, el módulo de comportamiento actúa como un receptor de mensajes. Cada
componente del sistema que sea capaz de modificar el estado emocional puede realizar
llamadas relativas al nivel de necesidad de Maslow que debe variar. El módulo de
comportamiento atiende esas llamadas y modifica el valor del nivel de necesidad indicado.
Como consecuencia de esta variación, el modelo emocional realiza una evaluación
determinando la emoción final que es enviada al modelo de comportamiento para que influya
sobre las acciones a realizar.
21
6.
BIBLIOGRAFÍA
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 : [s.n.], 2007.
Goddeau David [y otros] GALAXY: A Human-Language Interface to on-line Travel
Information [Artículo] // ISCLP. - 1994.
Hurtado Gil Sandra Victoria Representación de la arquitectura de software usando
UML // Universidad Icesi.
Instituto Nacional de Estadística Encuesta sobre Equipamiento y Uso de Tecnologías de la
Información y Comunicación en los hogares [Informe]. - 2003-2008.
Márquez Avendaño Bertha Marie y Zulaica Rugarcía José Manuel Implementación de un
reconocedor de voz gratuito a el sistema de ayuda a invidentes Dos-Vox // Universidad de las
Américas Puebla. - Cholula : [s.n.], 2004.
Pellom Bryan, Ward Wayne y Sameer Pradhan The CU Communicator: An Architecture
for Dialogue Systems [Artículo] // ISCLP. - 2000.
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 : [s.n.], 2008.
Rodríguez Losada Diego [En línea] // JABON a SOAP C++ Code Generator. - 2009. http://www.intelligentcontrol.es/jabon/.
Seneff Stephanie [y otros] GALAXY-II: A Reference Architecture for Conversational System
Development [Artículo] // ICSLP. - 1998.
W3C SOAP Version 1.2 Part 1: Messaging Framework (Second Edition) [En línea]. - 2009. http://www.w3.org/TR/soap12-part1/.
XML-RPC [En línea]. - 2009. - http://www.xmlrpc.com/.
22