Mapeo facial de emociones sint´eticas

Raquel P. Conde L´opez
Marzo 2005
2
i
A fuerza de perseverancia
alcanz´o el caracol el arca de Noe.
ii
Agradecimientos
A mi familia, por el apoyo. En especial a mis padres, Roberto y Mari Carmen por la
paciencia. Tambi´en a mis hermanos Eduardo y Sergio por estar ah´ı. Porque todos ellos han
dado mucha ca˜ na, pero s´e que est´an orgullosos de que “la ni˜ na” sea ingeniero. Porque no
los cambiar´ıa por nada, aunque a veces me los hubiera cargado.
A Ricardo por mil motivos. Por provocarme con tantas cosas nuevas, por hacer m´as
grande mi mundo. Por creer en m´ı y darme la oportunidad de trabajar en su equipo.
Por apoyarme en los malos momentos y cuidarme. Por ser grande como ingeniero y como
persona. Por su amistad. Por tener siempre la puerta abierta y una silla en su despacho, a
pesar de estar m´as que liado casi siempre.
A Pablo por su amistad todos estos a˜ nos. Por tirar de mi en los malos momentos y
celebrar conmigo los buenos. Por las clases magistrales. Por las cervezas y las risas. Por
tantos buenos ratos. Por ser el m´as canalla. Por estar siempre de mi lado y apoyarme.
Porque si he llegado a la meta es en gran parte por su culpa.
A Carlosm por todo el trabajo que ha hecho conmigo, por convertirme en una friki, por
su paciencia y confianza en m´ı. Por re´ır conmigo y apoyarme en los malos momentos. Por
sus consejos, por ser un tipo muy sabio. Por ayudarme en todo momento, pero sobre todo
en la recta final y hacer que esto finalmente fuera realidad. Por los paseos por Madrid al
salir del depar, por los mails y por portarse como un amigo.
A Julia por echarme m´as que un cable con la memoria y no asesinarme por comerme
todos los acentos. Por ese dominio y control de los “papeles” que ninguno llegaremos a
tener. Por la parte de culpa que tiene de que seamos un gran equipo.
A Anita, porque a pesar de los a˜ nos y las nominaciones sigue estando ah´ı, porque lo
bueno perdura en el tiempo. A Manuel por las eternas charlas arreglando el mundo delante
de un caf´e de comercio justo. A Rafa por los buenos ratos. Por la complicidad en tantos
momentos. Porque somos demasiado distintos como para no chocar a veces, pero ambos
seguimos enteros. A Silvia por cuando eramos una pi˜ na y pod´ıamos con todo, porque a
pesar de lo complicadas que se pusieron a veces las cosas, salimos de todas. Por las risas y
por las l´agrimas, porque nos hicieron fuertes. Por las cosas buenas. A Cris por tener siempre
una sonrisa disponible. A Ceci por formar parte de la familia ASLab a pesar de ser del
DIE. Gracias por estar ah´ı todo este tiempo. Por meternos en tantos l´ıos y por apuntarse
iii
iv
a un bombardeo. A Paco por pertenecer a la secta. Por las vueltas y vueltas despu´es de
las clases de bailes de sal´on. . . A Ignacio por el psicoan´alisis por el messenger, por las
conversaciones absurdas y por las risas. A Carlos G. por pasarse siempre que puede por
aqui y no olvidarse de nosotros. A la pandi porque nos hacemos mayores pero seguimos
juntos despu´es de tantos a˜ nos y de tantas cosas. . . A los que dejaron que les “robara el
alma” para este proyecto. A Bel´en por cuidar de su “hermana mayor” y por creer en m´ı.
A mis amigos de la escuela por compartir apuntes, clases y horas en la cafeter´ıa. Por las
charlas en clase y en los pasillos, porque tambi´en ellos me ense˜ naron lo que es un ingeniero.
A todos aquellos, compa˜ neros de pupitre y profesores, que se cruzaron en mi vida estos
a˜ nos. Porque de todos aprend´ı algo, porque algunos me ense˜ naron la valiosa lecci´on de en
lo que no quiero convertime.
Y a quien corresponda por ayudarme a que al fin, despu´es de mucho esfuerzo, hoy pueda
dar esto por terminado. ¡GRACIAS A TODOS!
´
Indice general
1. Introducci´on 1
1.1. Motivaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Objetivos del proyecto fin de carrera . . . . . . . . . . . . . . . . . . . . . 5
1.4. Estrategia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Comunicaci´on y emoci´on 7
2.1. Interacci´on y dise˜ no visual . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Inteligencia emocional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Expresiones faciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1. Descripci´on de las expresiones universales . . . . . . . . . . . . . . 12
2.3.2. M´ usculos de la cara . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4. Animaci´on facial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5. Modelo de Waters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.1. Mec´anica muscular . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.2. Vectores de m´ usculos . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.3. El modelado de los m´ usculos lineales . . . . . . . . . . . . . . . . . 19
2.5.4. Propiedades el´asticas . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6. Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7. Conclusi´on: Ideas b´asicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3. Una Cara para Higgs 25
3.1. Introducci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
v
vi
´
INDICE GENERAL
3.2. La aplicaci´on HiggsFace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3. Interacci´on con Higgs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4. Descripci´on de la aplicaci´on HiggsFace . . . . . . . . . . . . . . . . . . . . 27
3.5. Dise˜ no de la aplicacion HiggsFace . . . . . . . . . . . . . . . . . . . . . . . 28
4. Plataformas software 31
4.1. CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.1. El grupo OMG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.2. La norma CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.3. La Tecnolog´ıa CORBA . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2. El Broker ICa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.1. Arquitectura de Control Integrado . . . . . . . . . . . . . . . . . . 40
4.2.2. Instalaci´on de ICa Broker . . . . . . . . . . . . . . . . . . . . . . . 41
4.3. Omni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.1. Instalaci´on de Omni . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4. Aria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4.1. Comunicaci´on con el robot . . . . . . . . . . . . . . . . . . . . . . . 43
4.4.2. Instalaci´on de Aria . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5. Cliente prototipo CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5.1. Interfaz IDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.5.2. Estructura general del cliente C++ . . . . . . . . . . . . . . . . . . 46
4.5.3. Makefile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.5.4. Ejecuci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6. Servidor banco de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.6.1. Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.7. Aplicaci´on final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5. Sistemas gr´aficos 55
5.1. Introducci´on a los sistemas gr´aficos . . . . . . . . . . . . . . . . . . . . . . 56
5.2. Gr´aficos por ordenador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2.1. Creaci´on de gr´aficos 3D . . . . . . . . . . . . . . . . . . . . . . . . 56
´
INDICE GENERAL vii
5.2.2. Animaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.3. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3. Blender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.4. Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.5. Trabajo con Blender y Python . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.5.1. Criterios de selecci´on . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.5.2. Prototipo Blender . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.5.3. Animaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.5.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.6. OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.7. Trabajo con OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.7.1. Creaci´on gr´afica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.7.2. Animaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6. Mapeo de emociones en Higgs 85
6.1. EmotionMapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.2. Informaci´on sensorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.3. Transformaciones emocionales . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.3.1. Vector informaci´on sensorial . . . . . . . . . . . . . . . . . . . . . . 88
6.3.2. Matriz de emociones . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.3.3. Vector de informaci´on emocional . . . . . . . . . . . . . . . . . . . 90
6.4. Visualizaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7. Conclusiones y l´ıneas futuras 93
7.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.2. L´ıneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.2.1. Nuevo servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.2.2. Teor´ıa sobre las Emociones . . . . . . . . . . . . . . . . . . . . . . . 95
7.2.3. Aumentar el realismo de la imagen . . . . . . . . . . . . . . . . . . 95
A. Ejemplos 97
viii
´
INDICE GENERAL
B. Otras herramientas 99
´
Indice de figuras
1.1. Parte de la interfaz del sistema HINT . . . . . . . . . . . . . . . . . . . . . 2
1.2. Diagrama de caso de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Estudios de Duchenne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2. Expresiones universales de Eckman. . . . . . . . . . . . . . . . . . . . . . . 13
2.3. M´ usculos de la cara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4. Clasificaci´on de los m´etodos de modelado . . . . . . . . . . . . . . . . . . . 17
2.5. Modelo lineal de Waters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6. Secuencia de contracci´on muscular . . . . . . . . . . . . . . . . . . . . . . . 20
2.7. Actividad muscular coseno . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1. Robot m´ovil Pioneer 2-AT8 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2. Esquema sencillo de la aplicaci´on HiggsFace . . . . . . . . . . . . . . . . . 27
3.3. Modelo UML elemental de la aplicaci´on HiggsFace. . . . . . . . . . . . . . 28
4.1. Servicio de objetos CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2. Componentes de la arquitectura CORBA . . . . . . . . . . . . . . . . . . . 35
4.3. Generaci´on, integraci´on y compilaci´on . . . . . . . . . . . . . . . . . . . . . 47
4.4. Simulador de Aria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.5. Herramienta para Qt: Designer . . . . . . . . . . . . . . . . . . . . . . . . 52
4.6. Banco de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1. Captura de pantalla de Blender 2.36 . . . . . . . . . . . . . . . . . . . . . 59
5.2. Ejemplo de modelado con Blender . . . . . . . . . . . . . . . . . . . . . . . 62
5.3. Im´agenes auxiliares para el modelado . . . . . . . . . . . . . . . . . . . . . 63
ix
x
´
INDICE DE FIGURAS
5.4. Modelo de una cara con Blender . . . . . . . . . . . . . . . . . . . . . . . . 64
5.5. Men´ u para la iluminaci´on de Blender . . . . . . . . . . . . . . . . . . . . . 64
5.6. Men´ u para el renderizado de Blender . . . . . . . . . . . . . . . . . . . . . 65
5.7. Escena por defecto de Blender . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.8. Algunas opciones de Blender . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.9. Men´ u game engine de Blender . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.10. OpenGL Rendering Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.11. Aplicaci´on Facial Simulator para Windows . . . . . . . . . . . . . . . . . . 73
5.12. Ejemplo con OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.13. Modelado de la cara con l´ıneas . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.14. Modelado de la cara con pol´ıgonos . . . . . . . . . . . . . . . . . . . . . . 76
5.15. Distribuci´on de los m´ usculos en la cara . . . . . . . . . . . . . . . . . . . . 76
5.16. Esquema sencillo de la aplicaci´on HiggsFace . . . . . . . . . . . . . . . . . 84
6.1. Elementos de la aplicaci´on HiggsFace . . . . . . . . . . . . . . . . . . . . . 86
6.2. El EmotionMapper como aplicaci´on lineal . . . . . . . . . . . . . . . . . . 91
Cap´ıtulo 1
Introducci´on
1.1. Motivaci´on
La visualizaci´on de los estados funcionales de los sistemas t´ecnicos tiene una gran
importancia cuando de esta visualizaci´on se deriva la correcta o incorrecta interpretaci´on
de dicho estado por parte de un ser humano (consideremos, por ejemplo, la necesidad de
comprender el estado de nuestro autom´ovil cuando lo vamos conduciendo).
´
Esta ha sido una de las misiones tradicionales de las interfases de usuario donde no s´olo
la usabilidad del sistema t´ecnico sino el desempe˜ no global del sistema hombre-m´aquina
dependen cr´ıticamente del modelo mental que el ser humano tiene de la m´aquina (ver
Figura 1.1).
Al mismo tiempo, en la construcci´on de sistemas complejos de control intervienen mu-
chos factores que determinan la necesidad de emplear arquitecturas software adecuadas.
Esta adecuaci´on se mide por el grado en que dichas arquitecturas permitan obtener tanto
caracter´ısticas funcionales determinadas (como son la satisfaccion de requisitos estricta-
mente necesarios en el ´ambito del control) como caracter´ısticas no funcionales (que son
cr´ıticas a la hora de contruir un sistema software complejo).
Este proyecto fin de carrera se sit´ ua en la confluencia de ambas necesidades —visualizaci´on
y arquitectura software— tratando de ofrecer una soluci´on general al problema concreto
de la percepci´on por parte de seres humanos no entrenados de estados t´ecnicos globales de
sistemas f´ısicos.
Hay m´ ultiples ejemplos que podemos ofrecer de esta necesidad de comprensi´on y que
se han estudiado ampliamente en el ´ambito de la psicolog´ıa industrial, en el de la filosof´ıa
de la t´ecnica y, m´as recientemente, en el ´ambito de la rob´otica interactiva. Ejemplos
paradigm´aticos son el dise˜ no de salpicaderos de autom´oviles, las interfases para operadores
de procesos en caso de emergencias o los sistemas dom´oticos.
Obviamente en este proyecto no se trata de ofrecer una soluci´on definitiva a todos los
1
2 CAP
´
ITULO 1. INTRODUCCI
´
ON
Figura 1.1: Una interfase de usuario dise˜ nada para la operaci´on de un sistema t´ecnico
debe permitir que el humano desarrolle un modelo mental adecuado para el desempe˜ no del
sistema hombre-m´aquina. En la figura se presenta parte de la interfase del sistema HINT
[Alarc´on et al., 1994].
problemas de visualizaci´on de estados t´ecnicos —tarea posiblemente demasiado ambiciosa
para un proyecto fin de carrera— sino de proponer una arquitectura de visualizacion conc-
reta que se ofrece como una soluci´on viable a uno de los problemas planteados por la
necesidad de comprensi´on del sistema t´ecnico que los interfases hombre-maquina plantean:
la comunicaci´on efectiva y sin entrenamiento previo a un humano de un estado t´ecnico de
un sistema f´ısico. El objetivo es simple: entender, de un vistazo, c´omo est´a la m´aquina.
1.2. Contexto
Este trabajo se enmarca dentro del proyecto de investigaci´on a largo plazo CS
2

Complex Software-intensive Control Systems. Este es un proyecto de investigaci´on en tec-
nolog´ıas software para sistemas complejos de control realizado por el Autonomous Systems
Laboratory (ASLab) de la UPM, dentro del Departamento de Autom´atica de la ETS de
Ingenieros Industriales de la Universidad Polit´ecnica de Madrid.
El objetivo de este proyecto investigador es la definici´on de arquitecturas de control in-
tegrado para la construcci´on de sistemas complejos de control y el desarrollo de tecnolog´ıas
software para su construcci´on. Las l´ıneas maestras son simples y gu´ıan todo el desarrollo
del proyecto:
1.2. CONTEXTO 3
Modularidad
Seguimiento de est´andares
Reutilizabilidad
Dise˜ no basado en patrones
Independencia del dominio
En este contexto, se ha definido una plataforma software gen´erica de base denominada
Integrated Control Architecture (ICa) [Sanz et al., 1999c] que proporciona los criterios
de dise˜ no software centrales. La arquitectura ICa es una metaarquitectura software que
ofrece una serie importante de ventajas frente a otros enfoques :
Coherente y unificada: La arquitectura ICa proporciona integraci´on, vertical y horizon-
tal, total y uniforme; por ejemplo permite emplear un ´ unica tecnolog´ıa en todos los
niveles en la verticalidad del sistema de control (desde la decisi´on estrat´egica hasta
los dispositivos empotrados de campo) as´ı como la integraci´on horizontal de unidades
de negocio o empresas extendidas.
Clara: El modelo empleado en ella es un modelo preciso: el modelo de objetos ditribuidos
de tiempo real que constituye la base de las plataformas estado del arte en este
campo.
Flexible y extensible: Permite su adaptaci´on a distintos contextos de ejecucion y dis-
tintos dominios al realizar un m´ınimo de compromisos de dise˜ no; lo que permite la
reutilizaci´on modular de componentes y la incorporaci´on de nuevos componentes en
dominios concretos.
Abierta: Permite la interoperabilidad con sistemas ajenos (tanto heredados como futur-
os).
Portable: Gracias a basarse en est´andares internacionales.
Esta arquitectura —o metaarquitectura como debe ser considerada ICa en realidad
[Sanz et al., 1999a]— se ha venido desarrollando en nuestro departamento durante los ´ ulti-
mos a˜ nos y, gracias a diferentes proyectos de I+D, se ha aplicado con ´exito en multiples
´ambitos de control:
Control estrat´egico de procesos de fabricacion de cemento [Sanz et al., 2001].
Gesti´on de emergencias en plantas qu´ımicas [Sanz et al., 2000].
Sistemas de monitorizaci´on distribuida de tiempo real de produccion y distribuci´on
de energ´ıa el´ectrica [Clavijo et al., 2000].
4 CAP
´
ITULO 1. INTRODUCCI
´
ON
Figura 1.2: Diagrama de caso de uso para un despliegue de una aplicaci´on de control y
protecci´on de redes.
Robots m´oviles cooperantes [Sanz et al., 1999b].
Bucles de control en red [Sanz, 2003].
Protecci´on de subestaciones el´ectricas [Sanz, 2002].
etc.
La caracter´ıstica primaria de ICa es su enfoque modular. Los sistemas se contruyen
por medio de m´odulos reutilizables sobre frameworks de sistemas distribuidos de objetos
de tiempo real. La organizaci´on concreta de los m´odulos viene dada por su arquitectura de
aplicaci´on, que se deriva de la metaarquitectura por medio del uso de patrones de dise˜ no
[Sanz and Zalewski, 2003]. Su despliegue se hace seg´ un las necesidades y restricciones de
la aplicacion, explotando la reubicabilidad de los componentes (ver Figura 1.2).
En este proyecto fin de carrera se aborda la construcci´on de un m´odulo reutilizable
espec´ıfico para una cierta clase de arquitecturas que estamos investigando en la actualidad.
La clase de arquitecturas se denomina SOUL y el nombre de este m´odulo es SOUL::Face.
1.3. OBJETIVOS DEL PROYECTO FIN DE CARRERA 5
1.3. Objetivos del proyecto fin de carrera
Los objetivos de este proyecto son muy simples —que no f´aciles de alcanzar— y se
describen sumariamente diciendo que persigue la implementaci´on de un m´odulo reutilizable
en el contexto de ICa para la visualizaci´on de estados de sistemas t´ecnicos basado en
comunicaci´on emocional mediante caras.
1.4. Estrategia
La estrategia a seguir para conseguir la correcta interpretaci´on de los estado t´ecnicos
desde un punto de vista estrat´egico se basa en comunicacion emocional. Esta se detalla en
el Cap´ıtulo 2 de esta memoria.
En pocas palabras podemos decir que la idea b´asica que gu´ıa este proyecto consiste en
implementar un sistema metaf´orico-anal´ogico de visualizaci´on de estados de sistemas t´ecni-
cos mediante la representaci´on tridimensional de caras antropom´orficas correspondientes a
estados emocionales humanos.
Decimos metaf´orico-anal´ogico porque el sistema t´ecnico no se dise˜ na necesariamente
para emular estado mentales humanos (como es el caso de la rob´otica humanoide). As´ı que
cualquier interpretaci´on del estado t´ecnico en t´erminos de emociones humanas es necesaria-
mente metaf´orico. Sin embargo, las caracter´ısticas del tipo de interacci´on hombre-m´aquina
ulterior hace que veamos analog´ıas de comportamiento derivables de la emoci´on que ex-
presan estados intencionales de la m´aquina.
As´ı, una refiner´ıa podr´ıa “poner cara de susto” para indicar al operador humano la per-
cepci´on, por parte del sistema t´ecnico, de un riego inminente. Evidentemente, no podemos
decir que la refiner´ıa est´a asustada —en el sentido humano— pero es obvio que el canal de
comunicaci´on facial-emocional proporciona, en este caso, un ancho de banda mucho mayor
que los sistemas de alarma tradicionales.
1.5. Estructura de la memoria
Esta memoria de Proyecto Fin de Carrera se estructura en siete cap´ıtulos y tres
ap´endices:
Cap´ıtulo 1 / Introducci´on: Este cap´ıtulo es en el que se presenta el proyecto y se in-
troducen sus ideas b´asicas.
Cap´ıtulo 2 / Comunicacion emocional: Donde se describen las ideas b´asicas del proyec-
to centradas en emplear visualizacion de estados t´ecnicos mediante caras antropom´orfi-
cas correspondientes a estados emocionales humanos.
6 CAP
´
ITULO 1. INTRODUCCI
´
ON
Cap´ıtulo 3 / Una Cara para Higgs: En este cap´ıtulo se describe la aplicaci´on espec´ıfi-
ca para la que se implementa el sistema dise˜ nado. Higgs es un robot m´ovil de Pioneer
cuyo estado se pretende expresar mediante emociones.
Cap´ıtulo 4 / Plataformas software: En esta parte se describen las herramientas soft-
ware que se utlizan para el desarrollo de la aplicaci´on.
Cap´ıtulo 5 / Sistemas Gr´aficos: En este cap´ıtulo se describen las herramientas gr´afi-
cas utilizadas para el desarrollo del proyecto as´ı como el trabajo realizado con ellas.
Cap´ıtulo 6 / Mapeo de emociones en Higgs: Donde se describe el m´etodo con el que
se obtiene la informaci´on sensorial de Higgs y c´omo se traduce a estados emocionales
que se visualizan en una cara antropom´orfica.
Cap´ıtulo 7 / Conclusiones y l´ıneas futuras: En este cap´ıtulo se recogen por un lado
las conclusiones del trabajo realizado en este proyecto fin de carrera as´ı como las
l´ıneas de trabajo que quedan abiertas tras la finalizaci´on del mismo.
Ap´endice A / Ejemplos: Donde se recogen im´agenes de las expresiones universales de
Eckman para la cara dise˜ nada para Higgs.
Ap´endice B / Experimentos: Donde se recogen im´agenes tomadas durante el desar-
rollo del proyecto a modo de experimento.
Ap´endice C / Otras herramientas: Donde se recogen otras herramientas software uti-
lizadas para el desarrollo de este proyecto.
Cap´ıtulo 2
Comunicaci´on y emoci´on
En este cap´ıtulo se recogen unas ideas b´asicas acerca de la comunicaci´on y las emo-
ciones. El objetivo de este proyecto es crear una interfaz de usuario de forma que, de un
vistazo, se sepa c´omo est´a el sistema f´ısico en un determinado momento. Con las ideas
que aqui se recogen se justifica la elecci´on de la comunicaci´on emocional mediante caras
antropom´orficas.
En la Secci´on 2.1 se describe la utilizaci´on de las im´agenes como medio de comunicaci´on
de informaci´on.
La Secci´on 2.2 describe la importancia de las emociones en la toma de decisiones. De
como raz´on y emoci´on son dos t´erminos ´ıntimamente relacionados cuando se habla de
temas de inteligencia.
En la Secci´on 2.3 se trata el tema de la comunicaci´on facial mediante expresiones. Se
describe la existencia de una serie de expresiones universales (reconocidas por cualquier
persona en cualquier parte del mundo) as´ı como la descripci´on muscular de las mismas.
En la Secci´on 2.4 describe los modelos que existen para la generaci´on y animaci´on de
caras de forma realista.
La Secci´on 2.5 describe el modelo muscular para la animaci´on facial dise˜ nado por Keith
Waters.
La ´ ultima parte, (Secci´on 2.7), recoge una serie de ideas acerca del tema tratado en este
cap´ıtulo que se utilizan como base para el desarrollo del proyecto objeto de esta memoria.
7
8 CAP
´
ITULO 2. COMUNICACI
´
ON Y EMOCI
´
ON
2.1. Interacci´on y dise˜ no visual
El dise˜ no visual es una disciplina profesional que estudia los sistemas de informaci´on,
con el objeto de convertir los datos en formas visuales, teniendo en cuenta los procesos
perceptivos. Consiste en la creaci´on de im´agenes est´eticas y funcionales con fines netamente
comunicacionales.
El dise˜ no visual estudia la generaci´on y producci´on de la imagen fija, m´ovil, ambiental
y digital, a partir de las estructuras de los lenguajes que operan, circulan y funcionan en
la sociedad, con el objeto de entender la interactividad de los dispositivos y los datos con
el observador. En nuestro caso este lenguaje es el lenguaje de la comunicaci´on emocional
entre humanos mediante la expresi´on facial. La importancia de este mecanismo de comuni-
cacion queda manifiesta cuando, por problemas m´edicos, se pierde la capacidad de generar
expresiones faciales (por ejemplo en el s´ındrome de M¨oebius [Cole, 1998]).
El dise˜ no visual crea estructuras de comunicaci´on e informaci´on visual, soportado por
elementos estructurales del dise˜ no y formales de los modelos de informaci´on y comunicaci´on
(emocional en nuestro caso). As´ı mismo, el dise˜ no visual define los m´etodos para verificar,
de forma experimental, la eficacia comunicativa de estos datos, con el prop´osito de reducir
la entrop´ıa cognitiva.
Los sistemas de comunicaci´on con sistemas t´ecnicos emplean m´ ultiples tecnolog´ıas, de
las cuales la visualizaci´on no es sino una m´as; aunque dada la importancia de la percep-
ci´on visual para los seres humanos —somos animales visuales— no es de extra˜ nar que la
visualizaci´on sea la forma de comunicaci´on preferida
1
. Sin embargo, en la actualidad se
entiende que muchos sistemas t´ecnicos requieren de una nueva vizualizaci´on, que permitan
entender, interiorizar e interpretar la informaci´on sobre el estado del sistema —el estado
mental de la m´aquina, podr´ıamos decir— de una manera mas din´amica y activa. El dise˜ no
visual, permite la creaci´on de amplios sistemas comunicativos, basados en la ergonom´ıa que
permitan al usuario una relaci´on m´as natural con dicha informaci´on. Es en relaci´on con la
ergonom´ıa y con la eficacia donde la comunicaci´on usando expresiones faciales encuentra
su lugar.
Hay mucho trabajo realizado en el desarrollo de sistemas de visualizacion en ambientes
t´ecnicos (ver por ejemplo, todo el trabajo realizado en construccion de interfases de usuario
para operadores de proceso) pero, en cierta medida, la visualizacion que aqu´ı se investiga
se aleja de estas l´ıneas y entra m´as de lleno en la explotaci´on de la conexi´on visual entre
humanos.
1
Hay otras, sin embargo, basadas en otras modalidades sensoriales o incluso basadas en comunicaci´on
directa —intrusiva y no intrusiva— con el cerebro
2.2. INTELIGENCIA EMOCIONAL 9
2.2. Inteligencia emocional
A pesar de las connotaciones negativas que en la actualidad tiene la palabra “senti-
mental” cuando forma parte del comportamiento, cualquier concepci´on de la naturaleza
humana que deje de lado el poder de las emociones comete un error. Todos sabemos por
experiencia propia que nuestras decisiones y nuestras acciones dependen tanto, y a veces
m´as, de nuestros sentimientos como de nuestros pensamientos.
Todas las emociones son, en esencia, impulsos que nos llevan a actuar, programas de
reacci´on autom´atica con los que nos ha dotado la evoluci´on. En cierto modo, las emociones
son se˜ nales empleadas en los controladores complejos que nos mantienen en funcionamiento.
Desde nuestro punto de vista, las emociones son se˜ nales sint´eticas de control estrat´egico.
Sint´eticas porque no responden a una magnitud concreta medida mediante cierto sensor
sino que son producidas —calculadas— por el sistema de evaluaci´on de nuestro control m´as
global. Estrat´egicas porque estos bucles de control se sit´ uan en los niveles m´as altos de la
jerarqu´ıa de controladores que nos mantiene vivos. Cada emoci´on, como se˜ nal de control,
predispone al cuerpo a un tipo diferente de respuesta [Goleman, 1996]:
el enfado: aumenta el flujo sangu´ıneo de las manos, haciendo m´as f´acil empu˜ nar
un arma o golpear a un enemigo, tambi´en aumenta el ritmo card´ıaco y la tasa de
hormonas que, como la adrenalina, permitern generar la cantidad de energ´ıa necesaria
para acometer acciones vigorosas
el miedo: la sangre se retira del rostro (lo que explica la palidez y la sensaci´on de
“quedarse fr´ıo”) y fluye a la musculatura esquel´etica larga (como las piernas, por
ejemplo) favoreciendo as´ı la huida. Al mismo tiempo, el cuerpo parece paralizarse,
aunque s´olo sea un instante, para calibrar, tal vez, si el hecho de ocultarse pudiera
ser una respuesta m´as adecuada. Las conexiones nerviosas de los centros emocionales
del cerebro desencadenan tambi´en una respuesta hormonal que pone al cuerpo en
un estado de alerta general, sumi´endolo en la inquietud y predisponi´endolo para la
acci´on, mientras la atenci´on se fija en la amenaza inmediata con el fin de evaluar la
respuesta m´as apropiada
la alegr´ıa: aumento en la actividad de un centro cerebral que se encarga de inhibir
los sentimientos negativos y de disminuir los estados que generan preocupaci´on, al
mismo tiempo que aumenta el caudal de energ´ıa disponible. En este caso no hay
cambio fisiol´ogico especial salvo, quiz´as, una sensaci´on de tranquilidad que hace que
el cuerpo se recupere m´as r´apidamente de la excitaci´on biol´ogica provocada por las
emociones perturbadoras
la sorpresa: el arqueo de las cejas hace que aumente el campo visual y permite
que penetre m´as luz en la retina, lo cual nos proporciona m´as informaci´on sobre
el acontecimiento inesperado, facilitando as´ı el descubrimiento de lo que realmente
ocurre y permitiendo elaborar, en consecuencia, el plan de acci´on m´as adecuado
10 CAP
´
ITULO 2. COMUNICACI
´
ON Y EMOCI
´
ON
el desagrado: tiene un gesto que transmite el mensaje de que algo resulta literal
o metaf´oricamente repulsivo para el gusto o para el olfato. La expresi´on facial de
disgusto (ladeando el labio superior y frunciendo ligeramente la nariz) sugiere un
intento primordial de cerrar las fosas nasales para evitar un olor nauseabundo o para
expulsar un alimento t´oxico
la tristeza: consiste en ayudarnos a superar una p´erdida irreparable (como la muerte
de un ser querido o un desenga˜ no). La tristeza provoca una disminuci´on de energ´ıa y
del entusiasmo por las actividades vitales (especialmente las diversiones y placeres) y,
cuanto m´as se profundiza y se acerca a la depresi´on, m´as se ralentiza el metabolismo
corporal. Este encierro introspectivo nos brinda as´ı la oportunidad de llorar una
p´erdida o una esperanza frustrada, sopesar sus consecuencias y planificar, cuando la
energ´ıa retorna, un nuevo comienzo
Estas predisposiciones biol´ogicas a la acci´on son moldeadas posteriormente por nuestras
experiencias vitales y por el medio cultural en el que nos ha tocado vivir.
La mente racional y la mente emocional son consideradas como dos facultades relati-
vamente independientes que reflejan el funcionamiento de dos circuitos cerebrales distintos
aunque interrelacionados.
Las emociones se usan para enfatizar o ayudar a alcanzar una meta como actos inten-
cionales de comunicaci´on. En el mundo real las emociones de los dem´as influyen en nuestras
decisiones y nuestro estado emocional. Pueden motivarnos y animarnos a conseguir ciertas
cosas.
La idea de que las m´aquinas puedan tener un d´ıa emociones es un tema recurrente
en ciencia-ficci´on. “2001: Una odisea del espacio”, “Blade Runner” o “El hombre bicen-
terario” son algunos de los ejemplos que podr´ıamos se˜ nalar. En la actualidad existe una
gran diferencia entre ciencia-ficci´on y ciencia, pero muchos investigadores de inteligencia
artificial consideran que es cuesti´on de tiempo superarla y hablan de la importancia de
crear ordenadores emocionales.
Rosalind Picard [Picard, 1998] sugiere que los ordenadores influyen en las emociones
humanas de forma tanto positiva como negativa, si comprendemos mejor estas influencias y
podemos aplicar las positivas al dise˜ no de los mecanismos de visualizaci´on e interacci´on, la
gente se sentir´a mejor al trabajar con ordenadores. Estar de buen humor tiene un impacto
positivo en muchos aspectos de la creatividad y aumenta las posibilidades de ´exito. Y
como los estados de ´animo persisten y se contagian, los buenos sentimientos siguen cuando
dejemos de trabajar con el ordenador.
Marvin Minsky en “The Society of Mind” [Minsky, 1978] reflexiona lo siguiente: “la
cuesti´on no es si las m´aquinas inteligentes pueden tener emociones sino si las m´aquinas
pueden ser inteligentes sin emociones”. Desde nuestra perspeciva, los subsistemas de con-
trol emocional, constituyen una parte importante de la generacion de comportamiento al
m´as alto nivel y se imbrica, por tanto, en las estrategias m´as globales del agente inteligente.
2.3. EXPRESIONES FACIALES 11
2.3. Expresiones faciales
La cara es la parte m´as expresiva del cuerpo humano
2
, el canal m´as importante de
comunicaci´on no verbal, es una buena interfaz para comunicar porque las personas tienen
capacidad de reconocer expresiones e inferir de ellas estados emocionales.
El primero en demostrar la universalidad de las expresiones y su continuidad en hom-
bres y animales fue Charles Darwin en 1872 en “The expression of emotions in man and
animals”[Darwin, 1872] que fue publicado 10 a˜ nos antes del m´as famoso “The origin of the
species”.
La investigaci´on m´as importante sobre expresiones faciales fue desarrollada en 1862
por Duchenne[Duchenne, 1862], centrada en el estudio de los movimientos de los distintos
m´ usculos de la cara utilizando electrodos en puntos de la superficie del rostro (ver Figura
2.1). De este modo pudo clasificar los m´ usculos en expresivos, inexpresivos o discordante-
mente expresivos. A pesar de que existen discrepancias entre su clasificaci´on y la originada
por los descubrimientos recientes, ´el fue el que defini´o esencialmente el campo.
Figura 2.1: Estudios de Duchenne
El pionero del estudio anal´ıtico de la expresi´on de la cara humana fue Duchenne, pero
no fue hasta los 70 que no se llev´o a cabo un estudio m´as riguroso y preciso. Corri´o a cargo
de Paul Eckman y Wallace Friesen. Desarrollaron el Facial Action Coding System (FACS)
[Ekman and Friesen, 1978] que permit´ıa medir con rigor cient´ıfico todos los movimien-
tos musculares de la cara. Dividieron las expresiones en acciones de peque˜ nos grupos de
m´ usculos que denominaron Action Units (AU).
Durante cinco a˜ nos Eckman viaj´o alrededor del mundo para comprobar cient´ıficamente
si los gestos y las expresiones difieren con la cultura, siguiendo las teor´ıas de antrop´ologos
2
La comunicaci´on entre personas se produce mediante voz, las expresiones faciales y los gestos o posi-
ciones del cuerpo, mas del 65 % de la informaci´on transmitida cara a cara forma parte de la banda no
verbal.
12 CAP
´
ITULO 2. COMUNICACI
´
ON Y EMOCI
´
ON
destacados en aquella ´epoca. Seg´ un esta l´ınea de pensamiento, los seres humanos apren-
demos los gestos y las expresiones a trav´es del contacto social, y ´estos var´ıan en funci´on
de la cultura. Pero el investigador record´o que Charles Darwin [Darwin, 1872] hab´ıa dicho
exactamente lo contrario: las expresiones humanas eran innatas y por tanto universales a
todas las especies.
Utiliz´o la fotograf´ıa como soporte para sus investigaciones. Ense˜ n´o retratos a personas
de cinco pa´ıses diferentes para que identificasen la emoci´on de cada imagen y las inter-
pretaciones coincidieron. Tambi´en comprob´o que cada cultura tiene sus propias normas
que definen la forma socialmente aceptable de mostrar las emociones. Lo hizo mediante
un experimento que consist´ıa en mostrar pel´ıculas con escenas quir´ urgicas y accidentes a
japoneses y estadounidenses. Si estaban solos tanto unos como otros mov´ıan los mismos
m´ usculos de la cara mientras que en presencia de un investigador los japoneses tend´ıan a
enmascarar m´as las emociones de desagrado con una sonrisa. Para confirmar los resultados
obtenidos fu´e a cotejarlos a una cultura alejada de la civilizaci´on y convivi´o dos a˜ nos con
el pueblo fore en Pap´ ua, Nueva Guinea.
Sus investigaciones concluyen que hay seis categor´ıas que pueden considerarse como
universales, esto es, reconocibles por cualquier persona de cualquier tipo y condici´on en
cualquier parte del mundo. Estas categor´ıas son: alegr´ıa, tristeza, sorpresa, enfado,
miedo y desagrado. Cada una de estas ellas tienen un amplio rango de expresiones con
distinta intensidad y variaciones en los detalles de las mismas.
Debemos a Gary Faigin [Faigin, 1990] la consideraci´on de que hay expresiones no rela-
cionadas con emociones que tambi´en est´an universalmente reconocidas: dolor, esfuerzo,
somnolencia. . .
Las regiones m´as expresivas de la cara son los ojos, las cejas y la boca. Por eso son las
zonas en las que se centra la descripci´on de las expresiones universales que se recoge en la
siguiente secci´on.
2.3.1. Descripci´on de las expresiones universales
Dada la universalidad descubierta por Ekman [Ekman and Friesen, 1975], es posible
hacer an´alisis y representaciones gen´ericas de estas emociones (ver Figura 2.2).
Alegr´ıa: en la expresi´on pura de alegr´ıa las cejas est´an relajadas. El p´arpado superior
est´a ligeramente bajado y el p´arpado inferior est´a recto, siendo elevado por la mejilla. Los
labios son finos y est´an fuertemente presionados contra el hueso. En la expresi´on de alegr´ıa
se forman patas de gallo en los extremos de los ojos, un pliegue en forma de sonrisa bajo
el p´arpado inferior, hoyuelos y un profundo pliegue nasolabial desde la nariz a la barbilla.
Algunas variaciones de la alegr´ıa pueden ser risa desternillante, risa, sonrisa con la boca
abierta, sonrisa melanc´olica, sonrisa ansiosa, sonrisa de agradecimiento, sonrisa t´ımida,
sonrisa perversa, sonrisa con los ojos cerrados, falsa sonrisa y falsa risa. Las risas y sonrisas
falsas se caracterizan por una disminuci´on en las patas de gallo de los ojos, as´ı como por
2.3. EXPRESIONES FACIALES 13
ausencia o s´olo ligeros pliegues debajo del p´arpado inferior.
Tristeza: en la expresi´on pura de tristeza, la zona interior de las cejas se curva hacia
arriba. La piel y los tejidos blandos debajo de la ceja se agolpan sobre el p´arpado superior.
Los ojos se cierran ligeramente a consecuencia de la presi´on hacia abajo de los tejidos
sobre el p´arpado y tambi´en por el movimiento hacia arriba del p´arpado inferior. La boca
est´a relajada. Las arrugas asociadas a la tristeza incluyen pliegues horizontales en la frente;
l´ıneas verticales entre las cejas; pliegues oblicuos sobre el p´arpado superior y un pliegue
en forma de sonrisa bajo el labio inferior. La tristeza puede tener muchas variaciones
y diferentes intensidades: lloro con la boca abierta, lloro con la boca cerrada, tristeza
reprimida, casi lloro e infelicidad. Estas variaciones pueden conllevar cejas completamente
bajadas, ojos fuertemente cerrados, una protuberancia en la barbilla y un pliegue nasolabial
muy pronunciado.
Alegr´ıa Tristeza Enfado
Miedo Sorpresa Desagrado
Figura 2.2: Expresiones universales de Eckman.
Enfado: en la expresi´on pura de enfado, los extremos de las cejas se empujan hacia
abajo y se juntan. El extremo inferior de la ceja se pone al mismo nivel que el p´arpado
elevado. El ojo est´a medio abierto, pero la presi´on de la frente impide que se vea el blanco del
ojo por encima del iris. La boca est´a cerrada con el labio superior ligeramente comprimido.
Las arrugas en el enfado incluyen pliegues horizontales sobre los p´arpados superiores y
l´ıneas verticales entre las cejas. Las variaciones posibles del enfado son: rabia y tensi´on.
Dichas variaciones pueden implicar labios ligeramente presionados con protuberancia en la
barbilla o un boca totalmente abierta con una mueca del labio superior con el labio inferior
recto, ense˜ nando los dientes superiores e inferiores.
14 CAP
´
ITULO 2. COMUNICACI
´
ON Y EMOCI
´
ON
Miedo: el miedo puede variar desde la preocupaci´on al terror. Las cejas se elevan
y se juntan. La parte inferior de las cejas se curva hacia arriba. Los ojos est´an alerta.
La boca puede estar ligeramente abierta y ca´ıda, estando estirada en ambos lados. Las
arrugas asociadas pueden incluir pliegues horizontales en la frente, l´ıneas verticales entre
los ojos, hoyuelos sobre las cejas y pliegues oblicuos sobre los p´arpados superiores. En la
preocupaci´on los labios se fruncen fuertemente y los bordes de los labios desaparecen. Se
abulta la parte por debajo del labio inferior y sobre la barbilla. En el terror, tanto la boca
como los ojos est´an totalmente abiertos. El labio superior se relaja mientras que el inferior
se estira hasta mostrar los dientes inferiores. El pliegue nasolabial se vuelve recto y poco
profundo. Pliegues en forma de par´entesis aparecen a los lados del labio inferior.
Sorpresa: en la sorpresa, las cejas se elevan rectas tanto como es posible. Los p´arpa-
dos superiores se abren lo m´aximo posible con los inferiores relajados. La boca se abre
totalmente formando un ´ovalo. Se forman pliegues horizontales en la frente.
Desagrado: el desagrado puede variar desde el desde˜ no al rechazo f´ısico. Las cejas se
relajan y los p´arpados est´an relajados o tan s´olo ligeramente cerrados. El labio superior se
eleva en una mueca, a menudo asim´etrica. El labio inferior se relaja. El pliegue nasolabial
es m´as profundo a lo largo de la nariz. En el desde˜ no, los p´arpados pueden estar parcial-
mente cerrado con los ojos mirando hacia abajo. En el rechazo f´ısico, las cejas se bajan,
especialmente en los extremos interiores. Los ojos pueden estar casi cerrados, en un gui˜ no.
El labio superior se eleva en una mueca intensa que permite ver los dientes superiores. El
labio inferior se eleva ligeramente. Hay l´ıneas verticales entre los arcos superciliares, patas
de gallo y por debajo del p´arpado inferior. Tambi´en aparecen arrugas desde el lagrimal
hacia el puente de la nariz as´ı como una protuberancia en la barbilla.
2.3.2. M´ usculos de la cara
Los m´ usculos en la cara se conocen habitualmente como los m´ usculos de expresi´on facial.
Algunos de estos m´ usculos pueden tambi´en desempe˜ nar otras funciones importantes, tales
como el movimiento de mejillas y los labios durante el habla. Los m´ usculos de expresi´on
facial son superficiales (situados en el exterior del cr´aneo) y est´an unidos a una capa de
grasa subcut´anea y piel en los puntos de inserci´on. Cuando los m´ usculos est´an relajados,
el tejido graso rellena los hoyos existentes para dar al cr´aneo una forma suave.
Los m´ usculos para la expresi´on facial trabajan sin´ergicamente y no de forma independi-
ente. El conjunto trabaja como un equipo coordinado y organizado, teniendo cada miembro
un funci´on espec´ıfica. Los m´ usculos interaccionan unos con otros. Por tanto, es dif´ıcil dis-
tinguir fronteras claras entre ellos. En el caso de la animaci´on facial s´olo los m´ usculos
principales de cada grupos se modelan.
Los m´ usculos principales de expresi´on facial y sus efectos en la cara cuando se contraen
son los siguientes
3
:
3
Entre par´entesis los nombres correspondientes a la literatura inglesa.
2.4. ANIMACI
´
ON FACIAL 15
Cigom´atico mayor (Zygomatic Major): desplaza la comisura de los labios super-
olateralmente. La parte inferior del surco nasolabial se profundiza cuando se estira
hacia arriba y hacia fuera
Depresor del ´angulo de la boca (Angular Depressor): tira de la comisura de la
boca inferolateralmente. Profundiza la parte inferior del surco nasolabial y lo empuja
hacia abajo
Elevador del ´angulo de la boca (Labii Nasi): eleva la comisura y el labio supe-
rior, empujando la parte interior de la mejilla hacia el ojo
Elevador del labio superior y del ala de la nariz (Inner Labii Nasi): atrae
en direcci´on superior el ala de la nariz y el labio superior. Se eleva y profundiza el
surco nasolabial
Frontal interior (Frontalis inner): la parte media del m´ usculo frontal eleva la
parte interior de las cejas
Frontal exterior (Frontalis outer): la parte lateral del m´ usculo frontal eleva la
parte exterior de las cejas
Frontal (Frontalis major): eleva las cejas de forma que el arco formado es m´as
prominente
Corrugador lateral (Lateral Corrugator): tira de la parte interna de las cejas
Corrugador de la ceja o superciliar (Corrugator Supercilli): junta las cejas
Su disposici´on puede verse en la Figura 2.3.
2.4. Animaci´on facial
Desde el trabajo de Parke [Parke, 1972], pionero en los temas de animaci´on facial,
muchos investigadores han intentado generar un modelado y animaci´on de rostros de forma
realista. Los m´as ambiciosos han intentado que el modelado y renderizado se haga en tiempo
real. Pero debido a la complejidad de la anatom´ıa facial as´ı como a la sensibilidad natural
a la apariencia de los rostros, en la actualidad no existen sistemas ampliamente aceptados
que generen las expresiones y emociones de forma realista y en tiempo real para un avatar
(entendemos por avatar a toda representaci´on digital de un personaje).
El objetivo de las caras tridimensionales es doble: que parezcan reales y que se mue-
van de forma real. Para lo cual es necesario fijarse en la anatom´ıa y geometr´ıa del rostro.
´
Este est´a formado por m´ usculos y huesos cubiertos de piel. Los huesos proporcionan el
marco est´atico en el cual se anclan los m´ usculos. Los m´ usculos constituyen los organos
16 CAP
´
ITULO 2. COMUNICACI
´
ON Y EMOCI
´
ON
del movimiento y generan la expresion moviendo la piel. Los m´ usculos tambi´en inter-
accionan unos con otros. Existen tres tipos de musculos en la cara: lineales/ paralelos,
el´ıpticos/circulares y planos. Un esquema de los m´ usculos de la cara puede verse en la
Figura 2.3.
Figura 2.3: M´ usculos que intervienen en la generaci´on de la expresi´on superficial de la cara
[Waters and Parke, 1996].
Las caras en realidad son superficies muy complejas, no hay modelos que la representen
y simulen en todos sus aspectos. Dependiendo de la aplicaci´on que se est´e desarrollando se
necesitar´a un grado de detalle u otro. Para el caso de la animaci´on de caracteres sint´eticos
podemos utilizar modelos que aproximen s´olo algunos aspectos de la anatom´ıa de la cara.
Al realizar el modelo facial podemos considerar que tenemos dos partes: la descripci´on
geom´etrica y las posibilidades de animaci´on. Ambas estan ´ıntimamente relacionadas: la
estructura del modelo determina su potencial animaci´on. Puede que sea conveniente crear
caracteres emp´aticos dependiendo del contexto (se odia al villano, se ama al h´eroe, se r´ıe
con el c´omico . . . )
Los detalles de la cara son muy importantes para obtener resultados reales (los ojos, el
pelo de la cara (cejas, pesta˜ nas, barba . . . ), los dientes, las enc´ıas y la lengua). Puede que
tambi´en las orejas, aunque eso depende de la complejidad del modelo (son muy dif´ıciles
de modelar). La utilizaci´on de ojos detallados y din´amicos es muy importantes a la hora
2.4. ANIMACI
´
ON FACIAL 17
de tener ´exito en la expresividad de la animaci´on (el movimiento de los ojos y los cambios
de dilataci´on de la pupila a˜ naden realismo a la animaci´on, mientras que los detalles en la
coloraci´on del iris y las reflecciones en el globo ocular a˜ naden vida a la cara). La cara ha
de verse como parte de la cabeza, es necesario a˜ nadir cara, orejas, pelo, la parte de atr´as
de la cabeza y el cuello. Las orejas y el pelo le dan distinto aire a los personajes que se
generen.
Para el modelado y la animaci´on facial existen distintas t´ecnicas que se dividen en dos
categor´ıas:
manipulaci´on de la geometr´ıa (keyframes, interpolaci´on, parametrizaciones, m´etodos
de elementos finitos, modelado basado en los movimientos de los m´ usculos, etc.)
manipulaci´on de las im´agenes (morphing, manipulaci´on de texturas, etc.)
La figura 2.4 recoge una clasificaci´on de los m´etodos de modelado y animaci´on facial.
Animación/
modelado facial
Manipulación
de la Geometría
Interpolación
Modelo físico
de músculos
Pseudomodelo
de músculos
Modelo de
elementos
finitos
Modelo de
mallas
Modelo
basado en
vectores
Animación
del pelo
Parametrización
Manipulación de
la imagen
Morphing
de imagen
Expresiones
vasculares
Manipulación de
texturas y
blending
Generación de
arrugas
Construcción de
modelo individual
Antropometría
Interpolación
bilineal
Adquisición y
ajuste del
modelo
Interpolación de
datos dispersos
Proyección en
coordenadas
cilíndricas y
esféricas
Modelo de
splines
Deformación
libre de
formas
Figura 2.4: Clasificaci´on de los m´etodos de modelado
18 CAP
´
ITULO 2. COMUNICACI
´
ON Y EMOCI
´
ON
2.5. Modelo de Waters
Esta secci´on contiene la descripci´on del modelo desarrollado por Waters [Waters, 1987]
para la animaci´on facial.
2.5.1. Mec´anica muscular
Los m´ usculos representan el motor principal de las expresiones faciales. Cuando un
m´ usculo se contrae, intenta mover los elementos anexos conjuntamente. Cuando se trata
de m´ usculos faciales, esta acci´on consiste en mover la piel hacia el punto de uni´on con el
hueso.
Los m´ usculos est´an formados por multitud de fibras larga llamadas miofibras en un
dise˜ no repetido. Cuando estas miofibras individuales se contraen, ejercen en conjunto una
fuerza a lo largo de dos extremos forzando al m´ usculo a encojerse. Los m´ usculos se com-
portan como muelles ajustables de forma que las fuerzas que generan son funci´on de la
longitud y la estimulaci´on neuronal.
Para modelar los m´ usculos, una soluci´on es la de ignorar la microestructura de las fibras
musculares, modelando los m´ usculos enteros como entidades b´asicas. Para mimetizar el
efecto de la contracci´on muscular, se utiliza una funci´on de deformaci´on geom´etrica. Este
procedimiento es con diferencia, el menos costoso computacionalmente y el que proporciona
resultados aceptables.
Lo que se pierde con este modelo de deformaci´on simplificado es la alteraci´on de la
geometr´ıa del m´ usculo que se traducir´ıa necesariamente en alteraciones de la posici´on de
la piel que no ser´an adecuadamente modeladas.
2.5.2. Vectores de m´ usculos
El considerar los m´ usculos faciales como entidades individuales con puntos defnidos
de uni´on y direcciones ´ unicas, permite modelar un m´ usculo como un vector en el espacio
3D. En este caso, el m´ usculo tiene propiedades vectoriales de direcci´on y magnitud. La
direcci´on es hacia el punto de uni´on con el hueso. La magnitud del desplazamiento depende
de la constante el´astica del m´ usculo y la tensi´on creada por la contracci´on muscular. La
magnitud es cero en el punto de uni´on y se incrementa hasta el m´aximo en el otro extremo
de inserci´on en la piel.
Hay tres tipos b´asicos de m´ usculos faciales que pueden modelarse: el m´ usculo lineal, el
m´ usculo circular y el m´ usculo plano.
Los m´ usculos lineales son fibras largas y paralelas, como por ejemplo el m´ usculo
cigom´atico mayor (o m´ usculo de la risa). En estos m´ usculos, la piel circundante se
2.5. MODELO DE WATERS 19
contrae hacia el nodo est´atico de uni´on con el hueso hasta que, a cierta distancia, la
fuerza disminuye a cero.
Los m´ usculos circulares est´an formados por fibras en forma de anillo, cuyo objetivo
es cerrar orificios faciales tales como la boca o los ojos. En estos m´ usculos, la piel se
contrae hacia un centro imaginario de forma uniforme.
Los m´ usculos planos son ´areas grandes y planas de fibras que no surgen de un punto
origen concreto. Por tanto, se contraen hacia un nodo localizado en vez de a un grupo
de nodos separados.
De hecho, el m´ usculo plano es un conjunto de entidades musculares paralelas dis-
tribuidas sobre un ´area, siendo por tanto posible modelarlo como varios m´ usculos lineales.
El comportamiento y efecto de los m´ usculos circulares tambi´en puede modelarse como var-
ios musc´ ulos lineales orientados radialmente. Por tanto, el modelo del m´ usculo lineal es el
m´as importante de los tres.
2.5.3. El modelado de los m´ usculos lineales
Waters describe el modelo de m´ usculo lineal como sigue: para el m´ usculo lineal es
importante computar como el tejido adyacente, tal como el nodo p en la Figura 2.5 se ve
afectado por la contracci´on del vector del m´ usculo. Se supone que no existe desplazamiento
en el punto de inserci´on en el hueso y que la m´axima deformaci´on tiene lugar en el punto
de inserci´on en la piel. Como consecuencia, una disipaci´on de la fuerza se pasa al tejido
adyacente, a lo largo de ambos sectores en el diagrama.
Figura 2.5: Modelo lineal de Waters y su zona de influencia
20 CAP
´
ITULO 2. COMUNICACI
´
ON Y EMOCI
´
ON
Para calcular el desplazamiento de un nodo arbitrario p situado en la malla un nuevo
desplazamiento p’ dentro del segmento v
1
p
r
p
s
hacia v
1
a lo largo del vector p,v
1
, se utiliza
la siguiente expresi´on:
p

= p + akr
pv
1
||pv
1
||
Aqu´ı, la nueva localizaci´on p’ es una funci´on de un par´ametro de desplazamiento an-
gular:
a = cos(a2)
donde a2 es el ´angulo entre los vectores (v
1
,v
2
) y (v
1
,p), D es ||v
1
-p||, r un par´ametro
de desplazamiento radial y k un constante fija que representa la elasticidad de la piel.
r =
_
¸
¸
¸
¸
_
¸
¸
¸
¸
_
cos
_
1 − D
R
s
_
; p dentro de v
1
p
n
p
m
p
1
cos
_
D − R
s
R
1
− R
s
_
; p dentro de p
n
p
r
p
s
p
m
Variando el factor de contracci´on del m´ usculo, el desplazamiento de la piel parecer´a mo-
verse a lo largo del eje principal del m´ usculo hacia el origen del vector como se muestra en
la Figura 2.6.
Figura 2.6: Secuencia progresiva de contracci´on muscular en una malla de 20x20. De izquier-
da a derecha con factores de 3, 5 y 10.
2.5.4. Propiedades el´asticas
El modelo de los m´ usculos lineales utiliza una funci´on coseno como primera aprox-
imaci´on a las propiedades el´asticas de la piel. A´ un cuando esta aproximaci´on produce
resultados aceptables, es obvio que la elasticidad de la piel var´ıa con la edad y de persona
2.6. APLICACIONES 21
a persona. Cambiando la funci´on coseno por una interpolaci´on no lineal o una funci´on po-
tencial, es posible variar la elasticidad de la malla y por tanto, simular la menor elasticidad
de la piel seg´ un envejece.
Una funci´on potencial incrementa las disminuci´on a cero en los bordes de los vectores
musculares Figura 2.7 muestra la funci´on coseno elevada a la potencia x. Esta t´ecnica per-
mite una aproximaci´on m´as flexible al modelado de los vectores de los m´ usculos primarios.
Figura 2.7: Actividad muscular coseno elevado a las potencias 0, 20 y 50 (de izquierda a
derecha) con una contracci´on muscular de 2.0.
2.6. Aplicaciones
El crecimiento exponencial en la capacidad de computaci´on en los ´ ultimos a˜ nos ha
llegado a tal nivel que la complejidad de las matem´aticas empleadas en el tratamiento de
gr´aficos tridimensionales puede resolverse en periodos suficientemente cortos como para
producir animaciones 3D realistas. Asimismo, la disponibilidad de tarjetas gr´aficas que
poseen procesadores 3D especializados ha convertido este tipo de animaci´on en una realidad
incluso para el p´ ublico general. Esto trae consigo la aparici´on de nuevas industrias para
satisfacer esta necesidad, as´ı como la apertura de nuevas ´areas para investigaci´on.
Aunque el hardware existente para mostrar gr´aficos de calidad est´a disponible, no sucede
los mismo con los m´etodos y t´ecnicas para el modelado y la animaci´on realista de personajes
3D, que est´an a´ un en desarrollo (aunque existen algunos productos internos explotados
por empresas de animaci´on y algunos productos comerciales en el ´ambito de produccion
de imagen sint´etica).
Algunas de las aplicaciones de esta tecnolog´ıa, tanto desde el punto de vista industrial
como de la investigaci´on, son:
Animaci´on: la revoluci´on de los gr´aficos 3D para la industria de animaci´on ha pro-
ducido un nuevo g´enero de pel´ıculas con t´ıtulos como “Toy Story” o “Final Fantasy”.
No obstante, m´as all´a de la representaci´on fiable de personajes 3D, lo importante en
22 CAP
´
ITULO 2. COMUNICACI
´
ON Y EMOCI
´
ON
la creaci´on de un personaje cre´ıble es el realismo de sus expresiones y movimien-
tos. Tradicionalmente, la animaci´on se hace por parametrizaci´on, es decir, diferentes
formas (morph) predefinidas se interpolan con diferentes pesos para representar una
mezcla de expresiones faciales. Este m´etodo funciona con personajes de dibujos ani-
mados (p.ej. Toy Story) que poseen un n´ umero limitado de expresiones faciales. Sin
embargo, la animaci´on de caras humanas con anatom´ıa perfecta (p.ej. Final Fantasy)
utilizando el m´etodo anteriormente descrito requerir´ıa un gran n´ umero de formas que
pueden consumir demasiado tiempo.
Juegos: la disponibilidad de aceleradores de tarjetas 3D ha cambiado el ´ambito de
los juegos en casa. La calidad de los gr´aficos procesados en tiempo real ha llegado a
un nivel adecuado para que los rasgos faciales sean suficientemente detallados para
ser animados. Por una parte, aparecen problemas similares a los existentes en ani-
maci´on. Por otra parte, en los juegos la expresi´on facial s´olo es distinguible cuando
ocupa la mayor parte de la imagen, lo que no es siempre habitual. Por tanto, la
animaci´on basada en m´ usculo implica el consumo de recursos de computaci´on que
puede beneficiarse de la utilizaci´on de t´ecnicas de reducci´on de complejidad basadas
en la distancia.
Teleconferencia: la habilidad para transmitir y recibir im´agenes faciales es la base
de la video o teleconferencia. A pesar del r´apido crecimiento en la disponibilidad de
ancho de banda para comunicaciones, se necesitan algoritmos de compresi´on. En lu-
gar de transmitir datos de la imagen f´ısica, los algoritmos de visi´on artificial pueden
utilizarse para extraer y transmitir estados de los m´ usculos faciales de forma indepen-
diente. Unos pocos par´ametros se transmiten al decodificador donde la cara humana
se reconstruye, y all´ı, marco a marco se reflejan los cambios en los estados de los
m´ usculos en la representaci´on 3D.
Avatares: un ´area emergente es el uso de interfaces para el usuario, que utilizan
personajes o agentes. La idea es que dichos agentes interaccionen con el usuario, de
forma convincente para que el usuario crea que interact´ ua con un ser inteligente y/o
emocional. Aqu´ı, las expresiones faciales juegan un gran papel. La animaci´on basada
en m´ usculo permitir´ıa utilizar los mismos datos de expresiones para un gran n´ umero
de agentes. La animaci´on por parametrizaci´on requerir´ıa un conjunto ´ unico de for-
mas (morph) objetivos para cada personaje. Por el contrario, los estados musculares
pueden utilizarse para distintos personajes.
2.7. Conclusi´on: Ideas b´asicas
La idea b´asica de este proyecto es que la comunicaci´on m´aquina-hombre —en el sentido
mencionado en el Cap´ıtulo 1 de comunicar estados t´ecnicos globales— puede mejorar mucho
con el uso de caracteres sint´eticos. Seg´ un esta idea, dotaremos al sistema t´ecnico (al robot,
2.7. CONCLUSI
´
ON: IDEAS B
´
ASICAS 23
al autom´ovil, a la refiner´ıa) de una cara antropom´orfica para facilitar la relaci´on. Esto se
ha estudiado ampliamente en rob´otica humanoide, pero la propuesta de este trabajo es su
aplicaci´on a cualquier sistema t´ecnico incluso no antropom´orfico, ya que cualquier sistema
tiene un estado global en t´erminos de control —un estado emocional podr´ıamos decir—
susceptible de ser comunicado por este canal.
Para que la interpretacion de la cara sea efectiva no basta con la generaci´on de cualquier
representacion gr´afica. En este proyecto se intenta investigar en t´ecnicas para crear agentes
cre´ıbles para los humanos con los que interact´ uan. La habilidad de expresar emociones
—importante para lograr el objetivo de la interpretaci´on anal´ogica— depender´a, necesari-
amente, de la calidad de la s´ıntesis.
Las personas entienden a otras personas u objetos a trav´es de la interacci´on y son
expertos observadores del movimiento; detectando, de forma r´apida, los movimientos no
naturales o imposibles. Lo importante en este contexto es crear una expresi´on inteligible
m´as que producir una cara humana exacta. Los gr´aficos de elevada calidad que son capaces
de generar los ordenadores hacen que se puedan generar expresiones m´as reales, mejorando
la comunicaci´on hombre-m´aquina.
Las expresiones faciales est´an siendo cada ves m´as importantes en sistemas con inter-
faces humanoides (de hecho se investiga ampliamente en el ´ambito de la rob´otica antropom´orfi-
ca
4
). Los caracteres sint´eticos son tambi´en cada vez mas populares
5
y, sin embargo, su
comunicaci´on facial es limitada. Las razones principales de que esto sea as´ı son la falta de
conocimiento sobre las expresiones faciales, especialmente su comportamiento din´amico,
y la falta de m´etodos para crear y representar caras con el apropiado comportamiento
emocional y cognitivo.
Existen diversas t´ecnicas para la animaci´on facial (ver Figura 2.4). El m´etodo selecciona-
do para este proyecto ha sido el realizar la animaci´on facial bas´andonos en manipulaciones
geom´etricas ayud´andonos de las caracter´ısticas f´ısicas del modelo de m´ usculos, utilizando
vectores
6
. Es el denominado “Muscle Based Animation of Facial Expressions” desarrollado
por Waters [Waters, 1987]. Consideramos que ´esta es la mejor elecci´on porque:
Utiliza una simulaci´on anat´omica lo que le confiere realismo.
Es r´ apida lo que permite su uso en tiempo real.
Es un m´etodo relativamente simple lo que permite una implementacion en el alcance
de este proyecto.
Por este m´etodo han demostrado inter´es tanto la industria del entretenimiento (juegos,
pel´ıculas de animaci´on) como la comunidad de investigadores en general.
4
Kismet: http://www.ai.mit.edu/projects/humanoid-robotics-group/kismet/kismet.html
5
Un ejemplo de esto es que si hacemos una b´ usqueda del t´ermino “avatar” en el buscador Google
encontramos m´as de veinticinco millones de enlaces.
6
Camino se˜ nalado en la Figura 2.4
24 CAP
´
ITULO 2. COMUNICACI
´
ON Y EMOCI
´
ON
Dise˜ nando de este modo nos aseguramos que podemos crear diferentes interfaces seg´ un
la aplicaci´ on de la que formen parte con el mismo c´odigo, ya que entre unas caras y otras
s´olo var´ıa la topolog´ıa del rostro y la distribuci´on de los m´ usculos, s´olo ser´ıa necesario que
el programa cargara la adecuada en cada caso.
En el presente proyecto se ha dise˜ nado una ´ unica interfaz sencilla, del estilo de una
m´ascara que adopta las distintas expresiones faciales.
Cap´ıtulo 3
Una Cara para Higgs
3.1. Introducci´on
El proyecto SOUL del grupo ASLab pretende desarrollar una arquitectura de control
reflexivo en el contexto de ICa. Esta arquitectura de control pretende conseguir un aumento
de robustez en los sistemas de control basados en ICa por medio de la implementaci´on de
mecanismos de auto-consciencia.
Dentro de este contexto, este proyecto fin de carrera implementa un modulo reutilizable
para la implementaci´on de interfases basadas en caras. Este m´odulo se denomina Faces.
Este proyecto tambi´en desarrolla una aplicaci´on concreta de este m´odulo para proporcionar
una cara a un sistema t´ecnico: un veh´ıculo de reducidas dimensiones.
3.2. La aplicaci´on HiggsFace
En t´erminos m´as precisos, la aplicaci´on de demostraci´on en la que se va a utilizar el
m´odulo desarrollado en el presente proyecto es la comunicaci´on de los estados globales
del robot m´ovil Pioneer 2AT-8, denominado a partir de este momento en el resto de la
memoria, como Higgs.
Higgs pertenece a la familia de robots m´oviles de ActivMedia Robotics
1
. Esta empresa
dise˜ na y construye robots m´oviles as´ı como sistemas de navegaci´on, control y de soporte
a la percepci´on sensorial de los mismos. El Pioneer 2AT-8 es una plataforma robusta que
incorpora los elementos necesarios para la implementaci´on de un sistema de navegaci´ on y
control del robot en entornos del mundo real.
El objetivo de la aplicaci´on HiggsFace es visualizar, mediante una cara antropom´orfica
y por medio de expresiones emocionales, los estados internos del robot Higgs.
1
Se puede conseguir m´as informaci´on en www.activmedia.com.
25
26 CAP
´
ITULO 3. UNA CARA PARA HIGGS
Figura 3.1: El robot Higgs. Un robot m´ovil Pioneer 2-AT8 de ActivMedia Robotics.
3.3. Interacci´on con Higgs
Para poder expresar los estados globales de Higgs mediante emociones hemos de comu-
nicarnos con ´el. Este problema fue abordado en un proyecto desarrollado en ASLab el a˜ no
pasado que ten´ıa por t´ıtulo “Sistema de Comunicaciones para Pioneer 2AT-8”[Pareja, 2004].
El objetivo del mismo era la comunicaci´on inal´ambrica (para que la plataforma fuera
aut´onoma) del robot m´ovil con la red local de computadores del departamento. Se de-
sarroll´o un software que permite la transmisi´on de toda la informaci´on sensorial propor-
cionada por el interfaz electr´onico del robot a la red local, de modo que esta informaci´on
est´a disponible en cualquier punto de la red y puede ser requerida en cualquier momento.
Esta implementaci´on se hizo siguiendo las directrices de dise˜ no de ICa, por lo que su
reutilizaci´on en el contexto de este proyecto es pr´acticamente inmediata.
La aplicaci´on se desarroll´o mediante la implementaci´on de un servant CORBA que en-
capsula la interfase proporcionada por el fabricante (denominada Aria). El objeto CORBA
Higgs
2
es usado externamente por clientes CORBA siguiendo un esquema cliente/servidor.
El servidor Higgs se ejecuta en la CPU local del robot y se encarga de escuchar y atender
las peticiones que le llegan por parte de los clientes que se ejecutan en cualquier m´aquina
de la red local. En el dise˜ no de ICa se prev´e la posibilidad de que en alg´ un momento los
sistemas operativos y las plataformas de ejecuci´on pueden ser diversos de modo que Higgs
est´a preparado para la heterogeneidad del sistema. La tecnolog´ıa CORBA nos proporciona
esta capacidad de integraci´on distribuida heterog´enea.
Utilizando los resultados de dicho proyecto [Pareja, 2004], podemos obtener los estados
mec´anicos de Higgs mediante un cliente CORBA que le solicite al servidor que se ejecuta en
2
Aunque el nombre del objeto CORBA es el mismo que el del robot, identificaremos de quien se trata
en cada caso por el contexto (ver nota aclaratoria al final del cap´ıtulo).
3.4. DESCRIPCI
´
ON DE LA APLICACI
´
ON HIGGSFACE 27
Higgs los datos sensoriales para su posterior tratamiento y transformaci´on de los mismos
en visualizaci´on de estados emocionales.
La informaci´on que nos proporciona el servidor Higgs es la siguiente: velocidades, posi-
ci´on del robot, informaci´on de los sonares, y estado de la bater´ıa.
En el cap´ıtulo 6 veremos c´omo se transforma esta informaci´on sensorial y c´omo se
mapean ´esta a estados emocionales que ser´an expresados mediante expresiones faciales en
un dispositivo de visualizaci´on.
3.4. Descripci´on de la aplicaci´on HiggsFace
En la aplicaci´on HighsFace intervienen tres elementos distribuidos:
Higgs: un servidor CORBA que soporta la interfase Pioneer::Pioneer2AT.
HiggsFace: un servidor CORBA que soporta la interfase SOUL::Face
EmotionMapper: un programa intermedio (un agente activo ICa) que mapea es-
tados de Higgs a estructura facial.
Un esquema sencillo de la aplicaci´on puede verse en la Figura 3.2.
Figura 3.2: Esquema sencillo de la aplicaci´on HiggsFace
28 CAP
´
ITULO 3. UNA CARA PARA HIGGS
El funcionamiento de la aplicaci´on es simple: en Higgs se ejecuta el servidor CORBA
Higgs, que nos proporciona la informaci´on sensorial del robot m´ovil. Esta informaci´on se
mapea a estados faciales que se le comunican al servidor CORBA HiggsFace que se encarga
de dibujar en la pantalla la cara correspondiente al estado mec´anico del robot.
3.5. Dise˜ no de la aplicacion HiggsFace
Uno de los criterios de dise˜ no de ICa es la independencia de dominio de los componentes
modulares.
En el caso que nos ocupa, el modulo Higgs implementa la interfase general Pio-
neer::Pioneer2AT que encapsula la funcionalidad del paquete Aria de ActiveMedia. Del
mismo modo el m´odulo HiggsFace implementa la interfase SOUL::Face.
Ambas interfases han sido dise˜ nadas para ser independientes de la aplicacion concreta
(para proporcionar dicha independencia de dominio) y permiten la reutilizacion de los
modulos en otras aplicaciones. Esto es posible ya que, por ejemplo Higgs, no implementa
ninguna funcionalidad espec´ıfica de la aplicacion construida en este proyecto.
Del mismo modo, el m´odulo empleado en la construccion de HiggsFace no implementa
ninguna funcinalidad concreta de esta aplicaci´on y podr´ıa ser empleado en cualquier otra
(por ejemplo para generar caras de avatares o caras sint´eticas en entornos de telepresencia
humana).
Figura 3.3: Modelo UML elemental de la aplicaci´on HiggsFace.
3.5. DISE
˜
NO DE LA APLICACION HIGGSFACE 29
Lo ´ unico que es espec´ıfico de esta aplicaci´on es el EmotionMapper ya que este m´odulo
es el que vincula espec´ıficamente una interfase Pioneer::Pioneer2AT con una interfase
SOUL::Face.
La aplicacion global recibe el nombre HiggsFace que es tambi´en el nombre empleado
en el objeto CORBA que soporta la interfase SOUL::Face (ya que este es el centro del
trabajo de este proyecto).
Nota aclaratoria: Higgs tiene un cuerpo, una cara y un canal de conexi´on con el cuer-
po. Todos ellos son Higgs. Podemos ser mas precisos y hablar del cuerpo de Higgs (el
robot, un Pioneer 2AT8), la cara de Higgs (la cara, un SOUL::Face) y el interfase del
cuerpo de Higgs (el objeto software, un Pioneer::Pioneer2AT). Desde el punto de vista
del NameService CORBA, Higgs es el objeto que envuelve el cuerpo y HiggsFace es el
objeto que gestiona la cara.
30 CAP
´
ITULO 3. UNA CARA PARA HIGGS
Cap´ıtulo 4
Plataformas software
En este cap´ıtulo se describen las herramientas software que se utilizan para el desarrollo
de la aplicaci´on objeto del presente proyecto.
Como ya se dijo en la introducci´on, este trabajo se enmarca dentro de la filosof´ıa ICa
y eso, desde el punto de vista software, quiere decir estandarizaci´on: C, C++, POSIX y
CORBA. Esta ´ ultima es la tecnolog´ıa de base para el desarrollo modular propugnado por
ICa y por ello se le dedica una atenci´on especial en este cap´ıtulo.
En la Secci´on 4.1 se describen aspectos generales de la especificaci´on CORBA de la
OMG (e.g. en qu´e consiste la tecnolog´ıa y estructura general de la Object Management
Architecture).
La Secci´on 4.2 se encarga de describir el Broker ICa como una implementaci´on particular
de CORBA que se va a utilizar en la aplicaci´on (junto con otros brokers de terceros).
La Secci´on 4.3 describe otro broker utilizado para la implementaci´on de los servidores
CORBA de la aplicaci´on desarrollada en este proyecto, el broker OmniORB.
En la Secci´on 4.4 se incluyen algunas notas sobre Aria, que es un paquete de clases
suministrada por el fabricante del robot m´ovil para posibilitar el control del mismo. Este
es el paquete encapsulado tras la interfase Pioneer::Pioneer2AT.
En la Secci´on 4.5 se describe el proceso de creaci´on de un prototipo de la aplicaci´on
final HiggsFace.
En la Secci´on 4.6 se describen componentes auxiliares, y en particular, el servidor de
pruebas. Este servidor se ha creado para poder generar los estados de Higgs cuando el robot
no est´a operativo dado que, en concurrencia con este proyecto, los sistemas embarcados en
´el estaban siendo actualizados.
31
32 CAP
´
ITULO 4. PLATAFORMAS SOFTWARE
4.1. CORBA
La tecnolog´ıa CORBA est´a orientada a los sistemas distribuidos heterog´eneos. Un sis-
tema distribuido heterog´eneo es aquel compuesto por diferentes m´odulos software que in-
teractuan entre s´ı sobre distintas plataformas hardware/software
1
unidas por una red de
´area local.
La suite de especificaciones CORBA (Common Object Request Broker Architecture)
proporciona un conjunto de abstracciones flexibles y servicios concretos necesarios para
posibilitar soluciones pr´acticas a los problemas que surgen en entornos distribuidos het-
erog´eneos.
CORBA no es m´as que una especificaci´on normativa para la tecnolog´ıa de la gesti´on
de objetos distribuidos (DOM). Esta tecnolog´ıa DOM proporciona una interfaz de alto
nivel situada en la cima de los servicios b´asicos de la programaci´on distribuida. En los
sistemas distribuidos la definici´on de la interfaz y ciertos servicios (como la b´ usqueda de
m´odulos) son muy importantes. Proporciona un est´andar para poder definir estas interfaces
entre m´odulos, as´ı como algunas herramientas para facilitar la implementaci´on de dichas
interfaces en el lenguaje de programaci´on escogido.
CORBA es independiente tanto de la plataforma como del lenguaje de la aplicaci´on.
Esto significa que los objetos se pueden utilizar en cualquier plataforma que tenga una
implementaci´on del CORBA ORB (Object Request Broker) y que los objetos y los clientes
se pueden implementar en cualquier lenguaje de programaci´on por lo que al programador
no le har´a falta saber el lenguaje en que ha sido escrito otro objeto con el que se est´e co-
municando.
4.1.1. El grupo OMG
El OMG (Object Management Group) es una organizaci´on sin ´animo de lucro creada en
1989 formada con la misi´on de crear un mercado de programaci´on basada en componentes,
impulsando la introducci´on de objetos de programaci´on estandarizada.
Su prop´osito principal es desarrollar una arquitectura ´ unica utilizando la tecnolog´ıa
de objetos para la integraci´on de aplicaciones distribuidas garantizando la reusabilidad de
componentes, la interoperabilidad y la portabilidad, basada en componentes de progra-
maci´on disponibles comercialmente.
El OMG es una organizaci´on de estandarizaci´on de car´acter neutral e internacional, am-
pliamente reconocida. Hoy en d´ıa son miembros del OMG alrededor de mil distribuidores
de software, desarrolladores y usuarios que trabajan en diferentes campos, incluyendo uni-
versidades e instituciones gubernamentales. Adem´as, mantiene estrechas relaciones con
otras organizaciones como ISO, W3C, etc. Sus est´andares facilitan la interoperabilidad y
1
Pueden tener arquitecturas diversas y soportar diferentes sistemas operativos
4.1. CORBA 33
portabilidad de aplicaciones construidas mediante objetos distribuidos. El OMG no pro-
duce implementaciones, s´olo especificaciones de software que son fruto de la recopilaci´on y
elaboraci´on de las ideas propuestas por los miembros del grupo OMG.
4.1.2. La norma CORBA
CORBA es una especificaci´on normativa que resulta de un consenso entre los miembros
del OMG. Esta norma cubre cinco grandes ´ambitos que constituyen los sistemas de objetos
distribuidos:
Un lenguaje de descripci´on de interfaces, llamado IDL (Interface Definition Lan-
guage), traducciones de este lenguaje de especificaci´on IDL a lenguajes de imple-
mentaci´on (como pueden ser C++, Java, ADA, Python, etc.) y una infraestructura
de distribuci´on de objetos llamada ORB (Object Request Broker).
Una descripci´on de servicios, conocidos con el nombre de CorbaServices, que com-
plementan el funcionamiento b´asico de los objetos de que dan lugar a una aplicaci´on.
Cubren los servicios de nombres, de persistencia, de eventos, de transacciones, etc.
El n´ umero de servicios se ampl´ıa continuamente para a˜ nadir nuevas capacidades a
los sistemas desarrollados con CORBA.
Una descripci´on de servicios orientados al desarrollo de aplicaciones finales, estruc-
turados sobre los objetos y servicios CORBA. Con el nombre de CorbaFacilities,
estas especificaciones cubren servicios de alto nivel (como los interfaces de usuario,
los documentos compuestos, la administraci´on de sistemas y redes, etc.) Pretende
definir colecciones de objetos prefabricados para aplicaciones habituales.
Una descripci´on de servicios verticales denominados CorbaDomains, que proveen
funcionalidad de inter´es para usuarios finales en campos de aplicaci´on particulares.
Por ejemplo, existen proyectos en curso en sectores como: telecomunicaciones, finan-
zas, medicina, etc.
Un protocolo gen´erico de intercomunicaci´on, llamado GIOP (General Inter-ORB
Protocol), que define los mensajes y el empaquetado de los datos que se transmiten
entre los objetos. Adem´as define implementaciones de ese protocolo gen´erico, sobre
diferentes protocolos de transporte, lo que permite la comunicaci´on entre los difer-
entes ORBs consiguiendo la interoperabilidad entre elementos de diferentes vende-
dores. Como por ejemplo el IIOP para redes con la capa de transporte TCP.
4.1.3. La Tecnolog´ıa CORBA
En esta secci´on se hace una descripci´on general de la arquitectura CORBA y su fun-
cionamiento. Para un conocimiento mas detallado es necesario recurrir a los documentos
34 CAP
´
ITULO 4. PLATAFORMAS SOFTWARE
Figura 4.1: Servicio de objetos CORBA
de especificaci´on del OMG
2
.
Common Object Request Broker Architecture (CORBA)
CORBA especifica un sistema que proporciona interoperabilidad entre sistemas que fun-
cionan en entornos heterog´eneos y distribuidos de forma transparente para el programador.
Su dise˜ no se basa en el modelo de objetos del OMG, donde se definen las caracter´ısticas
externas que deben poseer los objetos para que puedan operar de forma independiente de
la implementaci´on.
Las caracter´ısticas m´as destacables de CORBA son las siguientes:
es una tecnolog´ıa no propietaria
una base fundamental de la especificaci´on son los requisitos reales de la industria
es una arquitectura extensible
es independiente de la plataforma
es independiente del lenguaje de programaci´on
proporciona m´ ultiples servicios de aplicaci´on
2
M´as informaci´on en www.omg.org
4.1. CORBA 35
servidores y clientes (proveedores y usuarios de servicios) pueden desarrollarse de
manera totalmente independiente
En una aplicaci´on desarrollada en CORBA los objetos distribuidos se utilizan de la
misma forma en que ser´ıan utilizados si fueran objetos locales, esto es, la distribuci´on y
heterogeneidad del sistema queda oculta y el proceso de comunicaci´on entre objetos es
totalmente transparente para el programador.
Arquitectura general
Un objeto CORBA es una entidad que proporciona uno o m´as servicios a trav´es de
una interfaz conocida por los clientes que requieren dichos servicios. Un objeto CORBA se
define como aquel que proporciona alg´ un tipo de servicio, de modo que las entidades que
solo los utilizan no se consideran como tales.
Figura 4.2: Componentes de la arquitectura CORBA
El componente central de CORBA es el ORB (Object Request Broker), el cual propor-
ciona la infraestructura necesaria para identificar y localizar objetos, gestionar las conex-
iones y transportar los datos a trav´es de la red de comunicaci´on. En general el ORB
36 CAP
´
ITULO 4. PLATAFORMAS SOFTWARE
est´a formado por la uni´on de varios componentes, aunque es posible interaccionar con ´el
como si fuera una ´ unica entidad gracias a sus interfaces. El n´ ucleo del ORB (ORB Core)
es la parte fundamental de este componente, siendo el responsable de la gesti´on de las peti-
ciones de servicio. La funcionalidad b´asica del ORB consiste en transmitir las peticiones
desde los clientes hasta las implementaciones de los objetos servidores.
Los clientes realizan peticiones de servicio a los objetos, tambi´en llamados servidores, a
trav´es de interfaces de comunicaci´on bien definidas. Las peticiones de servicio son eventos
que transportan informaci´on relativa a los objetos o entidades implicadas en dicho servicio,
informaci´on sobre la operaci´on a realizar, par´ametros, etc. En la informaci´on enviada se
incluye una referencia de objeto del objeto proveedor del servicio; esta referencia es un
nombre complejo que identifica de forma un´ıvoca al objeto en cuesti´on dentro del sistema.
Para realizar una petici´on un cliente se comunica primero con el ORB a trav´es de uno
de los dos mecanismos existentes a su disposici´on: para el caso de invocaci´on est´atica el
stub o para el caso de la invocaci´on din´amica el DII, Dynamic Invocation Interface.
Invocaci´on est´atica: el stub es un fragmento de c´odigo encargado de mapear o traducir
las peticiones del cliente, que est´a implementado en un lenguaje determinado, y
transmit´ırselas al ORB. Es gracias a los stubs que los clientes pueden ser programados
en diferentes lenguajes de programaci´on.
Invocaci´on din´amica: se basa en el uso de la DII. Permite realizar invocaciones sin
necesidad de que el cliente sepa cierta informaci´on acerca del servidor, que ser´ıa
necesaria en caso de utilizar el stub.
Una vez la petici´on llega al n´ ucleo del ORB es transmitida hasta el lado del servidor,
donde se sigue un proceso inverso de nuevo a trav´es de dos mecanismos alternativos: el
skeleton del servidor, an´alogo al stub del cliente, o la DSI (Dynamic Skeleton Interface),
contrapartida de la DII. Los servicios que proporciona un servidor CORBA residen en
la implementaci´on del objeto, escrita en un lenguaje de programaci´on determinado. La
comunicaci´on entre el ORB y dicha implementaci´on la realiza el adaptador de objetos
(Object Adapter, OA), el cual proporciona servicios como:
generaci´on e interpretaci´on de referencias a objetos
invocaci´on de m´etodos de las implementaciones
mantenimiento de la seguridad en las interacciones
activaci´on o desactivaci´on de objetos
mapeo de referencias a objetos
registro de implementaciones
4.1. CORBA 37
Existen adaptadores de objetos m´as complejos, que proporcionan servicios adicionales,
y que son utilizados para aplicaciones espec´ıficas (por ejemplo, bases de datos). Dos adap-
tadores de objetos b´asicos son el BOA (Basic Object Adapter) y el POA (Portable Object
Adapter). El primero ha quedado ya obsoleto, y suele utilizarse el segundo adaptador. El
ORB proporciona adem´as un POA preconfigurado que puede usarse si no se desea crear
un POA espec´ıfico para una aplicaci´on, llamado RootPOA.
El adaptador de objetos necesita conocer cierta informaci´on acerca de la implementaci´on
del objeto y del sistema operativo en el que se ejecuta. Existe una base de datos que almace-
na esta informaci´on, llamada Interface Repository (IR), que es otro componente est´andar
de la arquitectura CORBA. El IR puede contener otra informaci´on relativa a la imple-
mentaci´on como por ejemplo datos de depurado, versiones, informaci´on administrativa,
etc.
Las interfaces de los objetos servidores pueden especificarse de dos maneras: o bien
utilizando el lenguaje IDL, o bien almacenando la informaci´on necesaria en el IR. Para el
caso de la invocaci´on din´amica la interfaz DII accede al IR en busca de ´esta informaci´on
en concreto cuando un cliente la utiliza para realizar una petici´on. De este modo se hace
posible que un cliente pueda invocar un servicio sin necesidad de conocer la descripci´on
IDL de la interfaz del objeto servidor.
Por ´ ultimo, en el lado del servidor CORBA, los objetos que se encargan en ´ ultima
instancia de atender a las peticiones de servicio son los servants. Estos objetos contienen
la implementaci´on de las operaciones asociadas a cada servicio o m´etodo de la interfaz del
objeto. No son visibles desde el lado del cliente; este s´olo ve una entidad ´ unica a la que
conoce como servidor. Dentro del servidor se crean y gestionan servants que atienden las
peticiones que llegan al mismo. El adaptador de objetos es el encargado de hacer llegar
dichas peticiones a los servants, crearlos o destruirlos, etc. Cada servant lleva asociado un
identificador llamado object ID, valor que es utilizado por el adaptador de objetos para la
gesti´on de los mismos.
Interoperabilidad entre ORBs
En la actualidad existen muchas implementaciones diferentes de ORBs, lo cual es una
ventaja ya que cada desarrollador puede emplear aquella que mejor satisface sus necesi-
dades. Pero esto crea tambi´en la necesidad de un mecanismo que permita a dos implementa-
ciones diferentes comunicarse entre s´ı. Tambi´en es necesario en determinadas situaciones
proporcionar una infraestructura que permita a aplicaciones no basadas en CORBA comu-
nicarse con aplicaciones basadas en esta arquitectura. Para satisfacer todos estos requisitos
existe una especificaci´on para lograr la interoperabilidad entre ORBs.
Las diferencias en la implementaci´on del broker no son la ´ unica barrera que sepa-
ra a objetos que funcionan en distintos ORBs, tambi´en existen otras dificultades como
infraestructuras de seguridad o requisitos espec´ıficos de sistemas en v´ıas de desarrollo. De-
bido a esto, los objetos que funcionan en diferentes dominios (ORBs y entornos de los
38 CAP
´
ITULO 4. PLATAFORMAS SOFTWARE
mismos) necesitan un mecanismo que haga de puente entre ellos. Este mecanismo debe
ser suficientemente flexible para que no sea necesaria una cantidad de operaciones de “tra-
ducci´on” inmanejable, ya que la eficiencia es uno de los objetivos de la especificaci´on de
CORBA. Esta caracter´ıstica es cr´ıtica en sistemas de control, donde suele ser necesario
alcanzar unos niveles determinados de seguridad, predecibilidad y seguridad.
La interoperabilidad puede alcanzarse a trav´es muchos procedimientos, los cuales pueden
clasificarse en dos tipos principales: inmediatos e intermediados (immediate/mediated bridg-
ing). En los procedimientos intermediados los elementos de un dominio que interaccionan
con los de otro dominio distinto, son transformados a un formato interno acordado por
ambos dominios de antemano, y bajo este formato la informaci´on pasa de un dominio al
otro. Este formato interno de la informaci´on puede basarse en una especificaci´on est´andar,
como en el caso del IIOP del OMG, o bien puede ser un formato acordado de forma privada.
Los procedimientos inmediatos se basan en traducir directamente la informaci´on desde el
formato utilizado por un dominio, al formato utilizado por el otro, sin pasar por estructuras
intermedias de datos. Esta soluci´on es mucho m´as r´apida, pero es menos general.
CORBA IDL
Como ya hemos mencionado, el lenguaje IDL (Interface Definition Language) es un
lenguaje utilizado para especificar interfaces CORBA. A trav´es de un compilador espec´ıfico
que procesa las definiciones escritas en IDL, se genera c´odigo fuente en el lenguaje de
programaci´on deseado en cada caso, c´odigo que es utilizado en las aplicaciones para crear
servidores CORBA ya que proporciona la infraestructura de skeletons y stubs necesaria
para que estos objetos puedan comunicarse con el ORB. IDL es un est´andar ISO, y tiene
las siguientes caracter´ısticas principales:
su sintaxis es muy similar a la de C++
soporta herencia m´ ultiple de interfaces
independiente de cualquier lenguaje de programaci´on y/o compilador, puede ma-
pearse a muchos lenguajes de programaci´on.
permite independizar el dise˜ no de la interfaz de la implementaci´on del objeto CORBA
en cuesti´on. La implementaci´on puede cambiarse por otra distinta, manteniendo la
misma interfaz, de forma que desde el “exterior” el objeto sigue siendo el mismo y
contin´ ua ofreciendo id´enticos servicios.
IDL no es un lenguaje de programaci´on propiamente dicho, es ´ unicamente un lenguaje
declarativo. Tiene tres elementos principales: operaciones (m´etodos), interfaces(conjuntos
de operaciones) y m´odulos (conjuntos de interfaces).
El IDL se mapea (“traduce”) al compilar al lenguaje de programaci´on deseado. Para el
lenguaje C++, IDL sigue la siguiente tabla de conversi´on:
4.1. CORBA 39
Tipo de datos IDL Tipo de datos C++ typedef
short CORBA::Short short int
long CORBA::Long long int
unsigned short CORBA::UShort unsigned short
unsigned long CORBA::ULong unsigned long
float CORBA::Float float
double CORBA::Double double
char CORBA::Char char
boolean CORBA::Boolean unsigned char
octet CORBA::Octet unsigned char
enum enum enum
Bases de la construcci´on de aplicaciones CORBA
Para desarrollar un objeto CORBA se siguen, en general, los siguientes pasos:
1. Dise˜ no: determinaci´on de los servicios que debe proporcionar el objeto, e imple-
mentaci´on de la/las interfaces IDL correspondientes.
2. Compilaci´on de IDL: mediante el compilador de IDL se procesan las definiciones
de interfaces y se generan los skeletons y stubs correspondientes, en un lenguaje de
programaci´on determinado.
3. Implementaci´on de servants: utilizando las clases generadas por el compilador de
IDL, se crean los servants de la aplicaci´on, que contienen la implementaci´on de las
operaciones del objeto CORBA.
4. Implementaci´on del servidor: el objeto CORBA debe proporcionar la infraestruc-
tura base para que la comunicaci´on con el ORB sea posible; debe crear un adaptador
de objetos para sus servants, etc.
5. Compilaci´on: se procede a la compilaci´on de los archivos de c´odigo fuente. Debe
incluirse el c´odigo generado autom´aticamente por el compilador de IDL (la parte
correspondiente a los skeletons).
El proceso se reduce b´asicamente a tres fases: generaci´on e integraci´on de c´odigo corre-
spondiente a las interfaces, implementaci´on de la funcionalidad del objeto CORBA y por
´ ultimo, compilaci´on. Estos pasos son los correspondientes para el desarrollo de un objeto
CORBA, es decir, un servidor. Para el desarrollo de un cliente, el proceso se reduce a la
integraci´on del c´odigo fuente generado correspondiente a los stubs.
40 CAP
´
ITULO 4. PLATAFORMAS SOFTWARE
4.2. El Broker ICa
En esta secci´on se describe ICa Broker que es una implementaci´on CORBA. Los proyec-
tos que se realizan en el grupo ASLAb estan estrechamente relacionados, constituyendo,
en cierta medida, piezas del mismo puzle ICa.
ICa Broker ha sido desarrollado en proyectos anteriores del grupo y posteriomente por
un spin-off de alumnos de nuestro grupo (www.scilabs.es). Se sigue usando ICa Broker
porque permite explorar aspectos particulares de la implementacion gracias al acuerdo
UPM-SCILabs de acceso al codigo fuente sin tener que entrar en la complejidad de otros
brokers Open Source como TAO.
Como ya se ha mencionado, este proyecto emplea recursos desarrollados en un proyec-
to anterior cuyo objetivo era el desarrollo del sistema de comunicaci´on del robot m´ovil
[Pareja, 2004]. En este proyecto se emple´o ICa Broker como plataforma CORBA pero,
como se ha indicado previamente en la Secci´on 4.1 esto no condiciona a tener que utilizarlo
en este proyecto (recordemos la interoperabilidad entre ORBs descrita en la secci´on an-
terior), pero tener aplicaciones ya desarrolladas que lo utilizan es una buena raz´on para
decantarnos por esa opci´on.
ICa Broker es un broker CORBA —con un entorno de desarrollo asociado— dise˜ nado
para asistir la creaci´on de sistemas software de medio y alto nivel en entornos industriales.
Proporciona herramientas para el desarrollo de software distribuido, con prestaciones de
tiempo real y tolerancia a fallos. ICa Broker 1.0 fue el resultado del trabajo desarrollado
por el Departamento de Autom´atica, Ingenier´ıa Electr´onica e Inform´atica Industrial dentro
del marco de un proyecto ESPRIT DIXIT en colaboraci´on con varias empresas de toda
Europa. ICa Broker RT 2.0 es la version actual, propiedad de la empresa SCILabs con la que
la UPM mantiene un acuerdo de colaboraci´on. Esta versi´on cumple con la especificaci´on
Real-time CORBA 1.1 de la OMG.
4.2.1. Arquitectura de Control Integrado
ICa significa Arquitectura de Control Integrado. Este es el marco en el que se desar-
roll´o este broker: para posibilitar el desarrollo de sistemas integrados de control.
Entendemos por arquitectura un dise˜ no software a un determinado nivel de abstrac-
ci´on, centrado en los patrones de organizaci´on del sistema que describen c´omo se particiona
la funcionalidad y c´omo esos elementos se interconectan e interrelacionan entre s´ı. Por un
lado una arquitectura es un modelo de separaci´on del sistema en componentes y por otro
un modelo de coordinaci´on de los mismos.
ICa implementa una metodolog´ıa de orientaci´on a componentes: m´odulos software que
interaccionan unos con otros a trav´es de una interfaz p´ ublica bien conocida. En el caso
m´as general estos componentes se situan en un entorno distribuido y heterog´eneo (tanto
desde el punto de vista del hardware como de los sistemas operativos soportados) formado
4.2. EL BROKER ICA 41
por una o varias plataformas hardware conectadas por una red que les permite interactuar
a trav´es de ella.
En ICa 1.0 se desarrollaron extensiones para adaptarse a las necesidades de los sistemas
de control de procesos industriales, en los cuales aparecen restricciones de tiempo real, los
sistemas deben tener tolerancia a fallos y existen limitaciones de velocidad importantes.
Ejemplos de estas extentiones son los mecanismos de gesti´on de timeouts y de checkpointing.
No renuncia a su aplicaci´on en entornos sin estas necesidades, por lo que es aplicable en
los sistemas que no requieran alguna de estas prestaciones simplemente renunciando a
ellas. Existen otros frameworks que han sido dise˜ nados para aplicaciones de car´acter m´as
ofim´atico y se aplican de forma forzada en entornos que se encuentran m´as all´a de sus
especificaciones de dise˜ no.
Por ´ ultimo con el t´ermino integrado se hace referencia a una de las caracter´ısticas
principales de ICa: su orientaci´on hacia la integraci´on de tecnolog´ıas de control, plataformas
y lenguajes diversos. A la hora de integrar componentes para formar un sistema de control
existen t´ecnicas diversas y los desarrolladores deben conocer y controlar todas ellas para
utilizar la m´as adecuada en cada caso. Los sistemas de control se dise˜ nan generalmente
por capas, formando lo que se conoce con el nombre de pir´amide de control. En las capas
inferiores se intercambia informaci´on a altas velocidades y con un nivel de abstracci´on bajo,
mientras que, a medida que se va ascendiendo por la misma, los flujos de datos disminuyen
pero aumenta el nivel de abstracci´on de los mismos. En las capas superiores tenemos control
inteligente, en el que la informaci´on que se intercambia es abstracta y desarrollada con
metodolog´ıas diversas, proporcionando principalmente soporte a la decisi´on. La integraci´on
de estas metodolog´ıas de control, junto con la integraci´on de diversas plataformas y sistemas
operativos son los objetivos de ICa.
4.2.2. Instalaci´on de ICa Broker
Para poder utilizar el broker de ICa es necesario instalar sus librerias en las m´aquinas
en las que se vaya a desarrollar el proceso de creaci´on del software[Chinchilla, 2003]. El
sistema operativo elegido para el desarrollo de la aplicaci´on que es objetivo de este proyecto
es GNU/Linux, por lo que para la instalaci´on de las mismas se utiliza el paquete corre-
spondiente a este sistema operativo que fue proporcionado por SCILabs (creadores de ICa
Broker RT 2.0).
El directorio /usr/local/ICa contiene las librer´ıas, scripts y ficheros necesarios para
la compilaci´on de las aplicaciones basadas en el ICa Broker. Para completar la instalaci´on
se deben a˜ nadir algunas l´ıneas a diversos ficheros del sistema:
/etc/hosts, en la que se deben a˜ nadir las entradas para identificar la m´aquina en
la que correr´a el servicio de nombres (aplicaci´on icans)
/etc/services, en la que se deber´a configurar a qu´e puertos y protocolos usa el
broker para establecer la comunicaci´on entre las distintas m´aquinas de la red local.
42 CAP
´
ITULO 4. PLATAFORMAS SOFTWARE
/etc/init.d/ICa, hay que crearlo si se quiere que ICa arranque autom´aticamente
como un servicio del sistema.
.bashrc, a˜ nadir una serie de variables de entorno para facilitar la compilaci´on de los
programas
Con estos pasos se concluye la instalaci´on de ICa Broker.
4.3. Omni
OmniORB fue desarrollado por Olivetti Research Ltd (que en 1999 pas´o a ser parte
de AT&T Laboratories) para ser utilizado en peque˜ nos equipos de entorno embebido que
necesitaban de comunicaci´on con ORBs comerciales en ordenadores sobremesa y servidores.
Ha evolucionado con el tiempo a trav´es de 11 versiones p´ ublicas para la comunidad COR-
BA, varias versiones beta y peque˜ nos desarrollos. En la actualidad lo utilizan numerosos
desarrolladores de programas en m´ ultiples aplicaciones.
OmniORB es un broker que implementa la especificaci´on 2.6 de CORBA. Es robusto y
tiene grandes prestaciones, permitiendo la programaci´on en C++ y Python. Es libre bajo
los terminos GNU General Public License. Es uno de los tres ORB al que se le ha concedio
el Open Group’s Brand de CORBA, lo que significa que ha sido probado y certificado
para CORBA 2.1 (le faltan todavia caracter´ısticas para ajustarse a la norma 2.6 como por
ejemplo no se soportan las interfaces locales ni los objetos por valor).
Este es otro de los brokers usados en este proyecto para la implementaci´on de los
servidores de HiggsFace.
4.3.1. Instalaci´on de Omni
Al ser Open Source se puede encontrar en la red
3
todo lo necesario para instalarlo,
as´ı como las instrucciones de como hacerlo dependiendo de la plataforma (Windows, Linux,
Sun, etc.) sobre la que se est´e trabajando.
4.4. Aria
Aria es un paquete software orientado a objetos programado en C++ que propor-
ciona una API (Application Programming Interface) para el control de diversos robots
m´oviles de ActivMedia
4
. Aria permite la construcci´on de aplicaciones para el control de los
robots: desde la ejecuci´on de simples comandos hasta la elaboraci´on de comportamientos
3
http://omniorb.sourceforge.net/
4
Empresa fabricante del robot Higgs.
4.5. CLIENTE PROTOTIPO CORBA 43
inteligentes como detectar y evitar obstaculos, reconocimiento de caracter´ısticas de objetos,
exploraci´on. . .
Aria es un potente y robusto paquete compuesto por m´as de cien clases programadas
en C++. Existen clases para el control de dispositivos como c´amaras, l´aser o pinzas, clases
con utilidades matem´aticas o para el manejo de tiempos, etc.
Aria est´a registrado bajo la GNU Public Licence, lo que significa que es un software de
c´odigo abierto. Del mismo modo todo el software desarrollado a partir de ARIA debe ser
distribuido y proporcionando el c´odigo fuente.
4.4.1. Comunicaci´on con el robot
Una de las principales funciones de Aria, y el primer cometido de toda aplicaci´on de
control para el robot, es establecer y gestionar la comunicaci´on cliente-servidor AROS
5
entre los dispositivos del robot y la aplicaci´on cliente. Suministra diversas clases para
establecer esta conexi´on, una vez establecida, las funciones principales que se realizan son
de lectura y escritura de datos en los dispositivos.
4.4.2. Instalaci´on de Aria
Los fabricantes del robot facilitan el paquete ARIA-1.3-2.i386.rpm para la insta-
laci´on del software en las m´aquinas en las que se va a desarrollar la aplicaci´on. Es nece-
sario copiar el paquete en ra´ız y descomprimirlo. De este modo se crea el directorio
/usr/local/Aria. Hay que compilar los archivos lo cual puede hacerse en un solo pa-
so utilizando el comando “make everything”. Una vez compilado con ´exito queda instalado
el paquete Aria y listo para su utilizaci´on.
4.5. Cliente prototipo CORBA
Si bien las anteriores secciones se han dedicado a una descripci´on general de las her-
ramientas, esta describe el uso de las mismas para la construcci´on de un prototipo de la
aplicaci´on objeto del presente proyecto.
Debido a las caracter´ısticas CORBA descritas antes, existe total libertad a la hora
de dise˜ nar el cliente que se conecte a la aplicaci´on servidor creada. Se utiliza invocaci´on
est´atica por lo que es necesario conocer la interfaz IDL con que se cre´o el servidor al que se
conecta y ultilizar la misma para desarrollar el cliente, pero el lenguaje en el que se haga
y el broker que se utilice puede elegirse libremente.
5
AROS (ActivMedia Robotics Operating System), es el sistema operativo que se ejecuta en el micro-
procesador del robot m´ovil Pioneer-2AT8.
44 CAP
´
ITULO 4. PLATAFORMAS SOFTWARE
En “Sistema de Comunicaciones para Pioneer 2AT-8”?? se utilizaba ICa y C++ para
desarrollar la aplicaci´on cliente/servidor y este es el punto de partida en este caso, aunque
nada obliga a ello ya que, como se explic´o en la secci´on de CORBA, existe interoperabilidad
entre ORBs y las aplicaciones cliente/servidor son independientes entre s´ı desde el punto
de vista del lenguaje de implementaci´on.
En las siguientes secciones se describen distintos aspectos referentes a la creaci´on de un
prototipo CORBA con el objetivo de familiarizarse con la programaci´on para el desarrollo
de la aplicaci´on final. En la Secci´on 4.5.1 se describe la interfaz idl utilizada para la creaci´on
del mismo. La estructura general de un cliente CORBA con C++ se describe en la Secci´on
4.5.2. Las ´ ultimas secciones estan dedicadas a la compilaci´on del programa (Secci´on 4.5.3)
y la Secci´on 4.5.4 al modo en que se ejecuta el binario generado.
4.5.1. Interfaz IDL
Para la realizaci´on del programa cliente debe ser conocida la interfaz que proporciona
el servidor para poder hacer peticiones, debido a que utilizamos invocaci´on est´atica. El
proyecto “Sistema de Comunicaciones para Pioneer 2AT-8”[Pareja, 2004] dise˜ n´o una apli-
caci´on cliente/servidor basada en una interfaz que ha sido modificada posteriormente para
adecuarse a las necesidades de las aplicaciones que se desarrollan en el grupo. La siguiente
interfaz idl se utiliza para la aplicaci´on:
module Pioneer{
const long NUMSONARS = 16;
typedef float SonarArray[16];
struct Pioneer2AT_State {
float Velocity;
float LeftVelocity;
float RightVelocity;
float RotVelocity;
float XCoordinate;
float YCoordinate;
float ThCoordinate;
SonarArray Sonar_Range;
float ClosestSonar;
float ClosestRange;
float Battery;
};
interface Pioneer2AT{
4.5. CLIENTE PROTOTIPO CORBA 45
// Get all-in-one robot state
Pioneer2AT_State getFullState();
// Connection management
long connect();
void disconnect();
// Velocities information
float getVelocity();
float getLeftVelocity();
float getRightVelocity();
float getRotVelocity();
// Velocities manipulation and movement
void setVelocity(in float vel);
void setLeftRightVelocity(in float leftvel,in float rightvel);
void setRotVelocity(in float vel);
void moveDistance(in float vel);
// Robot coordinates information
float getXCoordinate();
float getYCoordinate();
float getThCoordinate();
// Sonar information
long getSonar_Range(in long num_sonar);
short getClosestSonar();
long getClosestRange();
// Battery information
float getBattery();
// CORBA object remote control
void init();
void finish();
};
};
El nombre del m´odulo creado es Pioneer. En la primera parte del IDL se declaran los
tipos de datos y se define la estructura Pioneer2AT State que guarda toda la informaci´on
sensorial del robot m´ovil. Tambi´en se define un tipo de dato (SonarArray) para guardar
46 CAP
´
ITULO 4. PLATAFORMAS SOFTWARE
en un vector de n´ umeros con coma flotante toda la informaci´on de los 16 sensores de los
que dispone. En la segunda parte del IDL se declara la interfaz Pioneer2AT en la que se
definen los m´etodos disponibles para el m´odulo Pioneer. En este caso el m´odulo s´olo posee
una interfaz pero podr´ıan definirse tantas como fueran necesarias y los m´etodos disponibles
son:
obtener el estado del robot, esto es, toda su informaci´on sensorial (en una estructura)
conexi´on/ desconexi´on al robot
velocidad lineal y de rotaci´on con la que se mueve
manipulaci´on de la velocidad y posici´on del robot
posici´on del robot
estado de la bater´ıa
control del servidor CORBA
El siguiente paso es generar los stubs y los skeleton con el compilador idl correspondiente
a ICa (que se llama ADL). Se utiliza el stub generado para implementar el cliente; los
skeleton se usan para implementar la parte del servidor
6
. Un esquema general del proceso
puede verse en la figura 4.3
4.5.2. Estructura general del cliente C++
Al principio de la funci´on “main” del programa principal de la aplicaci´on cliente hay
que realizar una serie de pasos relacionados con CORBA, la forma en la que se hacen estos
pasos es siempre la misma. En los siguientes fragmentos de c´odigo se recogen estos pasos
as´ı como los comandos CORBA correspondientes:
1. Instanciar las clases.
RTCORBA::RTORB_var rtorb;
CORBA::Object_ptr nameService;
CosNaming::NamingContext_var namingContext;
CosNaming::Name name;
RTPortableServer::POA_var rtpoa;
PortableServer::POAManager_var mgr;
2. Obtener la referencia del ORB, si es nula el programa aborta su ejecuci´on.
6
Existe un servidor dise˜ nado con la misma interfaz IDL para ejecutarse en la CPU de Higgs y atender
peticiones
4.5. CLIENTE PROTOTIPO CORBA 47
Figura 4.3: Generaci´on, integraci´on y compilaci´on
cout << "Obtaining a RTORB reference...";
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
CORBA::Object_var obj = orb->resolve_initial_references("RTORB");
rtorb = RTCORBA::RTORB::_narrow(obj);
cout << "done." << endl;
if (CALL_IS_NIL(rtorb.in()))
cerr << "ERROR: Couldn’t get a reference to RTORB" << endl;
3. Obtener la referencia del POA.
cout << "Obtaining a Root POA reference...";
CORBA::Object_var obj2 = rtorb->resolve_initial_references("RootPOA");
rtpoa = RTPortableServer::POA::_narrow(obj2);
cout << "done." << endl;
if (CALL_IS_NIL(rtpoa.in()))
cerr << "ERROR: Couldn’t get a reference to RTPOA" << endl;
48 CAP
´
ITULO 4. PLATAFORMAS SOFTWARE
4. Activar el POA Manager.
cout << "Activating POA Manager...";
mgr = rtpoa->the_POAManager();
mgr->activate();
cout << "done." << endl;
5. Obtener el NameService.
cout << "Resolving name service...";
nameService = rtorb->resolve_initial_references("NameService");
namingContext = CosNaming::NamingContext::_narrow(nameService);
cout << "done." << endl;
CosNaming::Name robot_name;
robot_name.length(1);
robot_name[0].id = CORBA::string_dup("SERVIDOR_ROBOT_SERVANT");
robot_name[0].kind = CORBA::string_dup("");
6. Resolver el nombre a una refrencia al servant.
cout << "Resolving servant name...";
CORBA::Object_var object_robot = namingContext->resolve(robot_name);
cout << "done." << endl;
7. Obtener el manejador del servant.
cout << "Obtaining handle for servant...";
miRobot = Pioneer::Pioneer2AT::_narrow(object_robot);
cout << "done." << endl;
4.5.3. Makefile
Una vez escrito el c´odigo de la aplicaci´on es necesario compilarlo. Con este objetivo se
escribe el archivo Makefile.
Make es una herramienta de generaci´on de c´odigo, muy usada en los sistemas operativos
tipo GNU/Linux. Lee las instrucciones escritas en el archivo Makefile que reciben el nombre
de dependencias. La herramienta Make se usa para las labores de creaci´on de fichero
ejecutable, la limpieza de los archivos temporales en la creaci´on del fichero...
El Makefile correspondiente al prototipo CORBA es el siguiente:
4.5. CLIENTE PROTOTIPO CORBA 49
4.5.4. Ejecuci´on
Una vez generado el binario, para ejecutarlo se debe seguir el proceso siguiente:
1. Lanzar el servidor de nombres (icans) para obtener el NamingService.IOR
2. Lanzar la aplicaci´on servidor pas´andole como par´ametro el IOR del NameService
3. Lanzar la aplicaci´on cliente pas´andole como par´ametro el IOR del NameService
El servidor de nombres genera la referencia al objeto (IOR) que es un par´ametro que le
tenemos que pasar al ejecutable. Depende de varios factores tales como la m´aquina en la que
corra el servidor de nombres y de cuando se haya lanzado el mismo, de modo que es distinto
en cada ocasi´on. Para facilitar la tarea en c3p0 (uno de los ordenadores del departamento)
se est´a ejecutando constantemente la aplicaci´on icans (ICa Naming Service) por lo que el
IOR del NameService es siempre el mismo y podemos crear scripts en los que se indica que
se ejecute el binario con el IOR permanente del NameService como par´ametro.
El NamingService.IOR correspondiente a c3p0 es el siguiente:
IOR:010000002800000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e674
36f6e746578743a312e300001000000000000008a000000010101000f0000003133382e313030
2e37362e3234300000d107000043000000004000000d4e616d6553657276696365526f6f74504
f41000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e74657874
3a312e300000310001000000020000001a0000000100000001000000280000000a00000001000
000010000000040000000
De modo que el lanzador del cliente queda de la siguiente forma:
./ClienteRobotB2 -ORBInitRef IOR=‘cat NamingService.IOR‘
Por cuestiones de mantenimiento del robot m´ovil necesita un nuevo computador abordo
para satisfacer las necesidades de otro proyecto que se est´a desarrollando ahora en el
grupo, Higgs no se encuentra operativo en todo momento. Afortunadamente el paquete
Aria incluye un simulador llamado “SRIsim” cuya interfaz puede verse en la Figura 4.4
que permite simular la conexi´on al robot.
El problema que se plantea al no poder conectar directamente el cliente al robot es que
los movimientos del mismo en el simulador no se pueden controlar ya que el cliente dise˜ nado
solo le pide la informaci´on, no lo teleopera en modo alguno, por lo que el simulador no sirve
para probar si la cara se anima seg´ un las distintas situaciones en las que se pueda encontrar
Higgs. Se har´ıa necesaria la creaci´on de otro cliente que nos permitiera provocar en el robot
los distintos estados para comprobar que la interfaz dise˜ nada recorre todo el espectro de
50 CAP
´
ITULO 4. PLATAFORMAS SOFTWARE
Figura 4.4: Simulador de Aria
situaciones mec´anicas posibles y las mapea a los estados emocionales correspondientes.
Otra alternativa es crear una aplicaci´on en la que se pudiera simular los estados de Higgs
que interesaran en cada caso. Esta segunda es la opci´on elegida: se crea una aplicaci´on que
act´ ua como banco de pruebas para el m´odulo SOUL::Face.
4.6. Servidor banco de pruebas
Como alternativa se crea un banco de pruebas que act´ ua como “simulador del simu-
lador”, esto es, una interfaz gr´afica formada por barras y displays con la que se interact´ ua
por medio del rat´on para generar los distintos estados mec´anicos con objeto de comprobar
que se generan las expresiones adecuadas para cada caso. Esta interfaz se dise˜ na con Qt y
se conecta mediante CORBA utilizando las librerias de OmniORB al programa de dibujo
gr´afico propiamente dicho. Sustituye al robot o al simulador, actuando como servidor y
permitiendo la generaci´on de la informaci´on sensorial que se utiliza posteriormente en el
proceso de mapeo a emociones.
4.6. SERVIDOR BANCO DE PRUEBAS 51
4.6.1. Qt
La biblioteca Qt (o simplemente Qt) es una herramienta de programaci´on para desarrol-
lar interfaces gr´aficas de usuario. Una interfaz gr´afica de usuario (GUI) es un m´etodo para
facilitar la interacci´on del usuario con el ordenador a trav´es de la utilizaci´on de un conjunto
de im´agenes y objetos (como iconos o ventanas) adem´as de texto. Surge como evoluci´on
de la l´ınea de comandos de los primeros sistemas operativos y es pieza fundamental en un
entorno gr´afico.
Un poco de historia. Inicialmente Qt apareci´o como biblioteca desarrollada por Troll-
tech
7
en 1992 siguiendo un desarrollo basado en el c´odigo abierto, pero no libre. Se us´ o ac-
tivamente en el desarrollo del escritorio KDE (entre 1996 y 1998), con un notable ´exito y
r´apida expansi´on. Esto foment´o el uso de Qt en programas comerciales para el escritorio,
situaci´on vista por el proyecto GNU como amenaza para el software libre.
Para contrarrestar ´esta se plantearon dos ambiciosas iniciativas: por un lado el equipo
de GNU en 1997 inici´o el desarrollo del entorno de escritorio GNOME con [GTK+] para
GNU/Linux. Por otro lado se intenta construir una biblioteca compatible con Qt pero
totalmente libre, llamada Harmony.
Qt cuenta actualmente con un sistema de doble licencia: por un lado dispone de una
licencia GPL para el desarrollo de software de c´odigo abierto (open source) y software libre
gratuito y por otro una licencia de pago para el desarrollo de aplicaciones comerciales.
Designer
Como ayuda para el dise˜ no de la interfaz gr´afica con Qt se utiliza la herramienta
“Designer”
8
(Figura 4.5).
“Designer” nos permite la creaci´on de di´alogos interactivos con distintos objetos (bar-
ras, displays . . . ). Para estos elementos se definen sus propiedades tales como el nombre,
tama˜ no, tipo de letra, etc. Estos son clases dentro de la aplicaci´on que estamos dise˜ nando.
Posteriormente ser´a necesario implementar la funcionalidad mediante el c´odigo que se debe
ejecutar cuando se recibe el evento correspondiente.
Resultado del trabajo con “Designer” se obtiene un archivo de extensi´on “.ui”. Uti-
lizando el compilador de ui (ui compiler) para generar la descripci´on de la clase “.h” y su
implementaci´on “.cpp”(*) (implementaci´on de la clase). Como la parte de Qt emplea las
palabras clave “SLOT” y “SIGNAL” que no significan nada para C++, es necesario pasar
el “.h” por el compilador de objetos de Qt MOC (Meta Object Compiler) que se encarga de
crear “glue code”(*) de modo que se genera c´odigo C++ correspondiente a los mecanismos
de comunicaci´on “SIGNAL-SLOT” (una especie de mapeo o traducci´on a C++).
7
www.trolltech.com
8
http://www.trolltech.com/products/qt/designer.html
52 CAP
´
ITULO 4. PLATAFORMAS SOFTWARE
Figura 4.5: Herramienta para Qt: Designer
Es necesario implementar el comportamiento de los distintos elementos del di´alogo, es
decir, indicar qu´e tipo de acci´on realizar´an cuando se produzca un evento. Los archivos
“.cpp” descritos anteriormente son creados directamente a partir del “.ui” generado por el
“Designer” por lo que no conviene tocarlos, ya que cualquier cambio que se haga en ellos
se perder´a al modificar la interfaz.
El proceso seguido para la implementaci´on de la funcionalidad caracter´ıstica de cada
elemento de la interfaz dise˜ nada es crear una clase que herede de la clase generada en la
implementaci´on del ui, de modo que en esta nueva clase se definan los m´etodos virtuales
de la clase base.
Una vez est´e implementada la funcionalidad es necesario pasar el “.h”(*) por el MOC
porque aparecen de nuevo mecanismos de “SIGNAL-SLOT” y es necesario generar el “glue
code”(*) para que el compilador de C++ pueda entenderlo.
Para generar el binario es necesario escribir la aplicaci´on principal(*), en la que se
instancia la clase derivada en un entorno de aplicaci´on de Qt.
Es momento de reunir los archivos marcados con (*), compilarlos para generar los
ficheros de c´odigo objeto, enlazar estos con las librerias de Qt y obtener de este modo el
binario de la aplicaci´on.
4.7. APLICACI
´
ON FINAL 53
Interfaz
La interfaz dise˜ nada para la aplicaci´on es la que se muestra en la Figura 4.6.
Figura 4.6: Banco de pruebas: simulador del simulador
Makefile
El Makefile utilizado para la compilaci´on de la aplicaci´on dise˜ nada con Qt es el siguiente:
Ejecuci´on
Una vez generado el binario se ejecuta y proporciona su IOR (el del servidor, para que
los clientes puedan referirse a ´el directamente sin en NameService) que es necesario pasar
como par´ametro a cualquier aplicaci´on cliente que quiera conectarse al servidor dise˜ nado.
4.7. Aplicaci´on final
La aplicaci´on final se dise˜ na seg´ un lo descrito en el cap´ıtulo 3 utilizando las librer´ıas de
Omni ORB. En los casos en los que no se conecta al robot se utiliza el banco de pruebas
dise˜ nado con Qt que implementa la funcionalidad del servidor que se ejecuta en la CPU de
Higgs y nos permite generar estados globales del sistema. La equivalencia de estos estados
mec´anicos a estados emocionales se puede visualizar en un display mediante una cara.
54 CAP
´
ITULO 4. PLATAFORMAS SOFTWARE
Cap´ıtulo 5
Sistemas gr´aficos
El dise˜ no gr´afico es una forma de comunicaci´on visual. Puede aplicarse a muchos medios,
ya sean impresos, digitales, audiovisuales. . .
El mundo del dise˜ no gr´afico es un mundo fascinante. Encontramos m´ ultiples ejemplos
en el cine, la publicidad, los v´ıdeojuegos. . . los resultados son sorprendentes.
El presente cap´ıtulo se organiza del siguiente modo:
En la Secci´on 5.1 se da una visi´on general de los sistemas gr´aficos y las distintas
aplicaciones que ´estos tienen.
En la Secci´on 5.2 se describen conceptos generales acerca de los gr´aficos por orde-
nador, desde qu´e son hasta las herramientas disponibles en el mercado para trabajar
con ellos, pasando por la descripci´on de las fases b´asicas presentes en el proceso de
creaci´on de gr´aficos 3D.
Las Secciones 5.3, 5.4 describen dos herramientas que se utilizan en el desarrollo del
proyecto: Blender y Python. Se recogen en ellas conceptos generales como qu´e son,
algo de su historia y las caracter´ısticas principales de cada una de ellas.
La Secci´on 5.5 describe el trabajo realizado con las herramientas antes presentadas
en el desarrollo del proyecto. Se describe el trabajo realizado con Blender y Python
y c´omo se ha de abandonar esa v´ıa al no satisfacer las especificaciones del proyecto
los resultados que con ellas se pueden obtener.
La Secci´on 5.6 describe la forma en la que se ha dise˜ nado finalmente la parte gr´afica
del proyecto. Empieza con cuestiones generales sobre OpenGL para terminar descri-
biendo la aplicaci´on realizada.
55
56 CAP
´
ITULO 5. SISTEMAS GR
´
AFICOS
5.1. Introducci´on a los sistemas gr´aficos
Los gr´ aficos por ordenador son el campo de computaci´on visual donde se utilizan or-
denadores tanto para generar im´agenes de forma artificial como para integrar o modificar
informaci´on espacial y visual recogida del mundo real. Este campo se puede dividir en
varias ´areas:
Renderizado 3D en tiempo real (utilizado en juegos)
Renderizado para creaci´on de v´ıdeos y pel´ıculas
Edici´on de efectos especiales (para pel´ıculas y televisi´on)
Edici´ on de im´agenes y modelado (utilizado en ingenier´ıa)
Inicialmente el desarrollo de los sistemas gr´aficos por ordenador tuvo lugar en entornos
acad´emicos. Con el tiempo, su uso en pel´ıculas y televisi´on demostr´o su utilidad para la
creaci´on de efectos especiales y de animaci´on con sorprendentes resultados. Desde “2001:
Una odisea del espacio” donde los efectos de gr´aficos por ordenador se creaban mediante
animaci´on manual, pasando por “Final Fantasy” que fue un hito en cuanto a animaci´on
se refiere por los resultados de elevada calidad obtenidos con sus personajes, hasta llegar
a las ´ ultimas pel´ıculas de Pixar, “Buscando a Nemo” o “Los Incre´ıbles”.
5.2. Gr´aficos por ordenador
Los gr´aficos por ordenador se crean mediante la utilizaci´on de software especializado
para el dise˜ no. En general, el t´ermino “gr´aficos por ordenador” se utiliza para referirse por
una parte al proceso de creaci´on y por otra al estudio de t´ecnicas gr´aficas para el dise˜ no.
5.2.1. Creaci´on de gr´aficos 3D
El proceso de creaci´on de gr´aficos 3D por ordenador se divide en tres fases b´asicas:
1. Modelado
2. Composici´on de la escena
3. Renderizado (creaci´on de la imagen final)
5.2. GR
´
AFICOS POR ORDENADOR 57
Modelado. La etapa de modelado consiste en dar forma a objetos individuales que luego
ser´an usados en la escena. Existen diversas t´ecnicas: modelado poligonal, modelado con
NURBS . . . Los procesos de esta etapa pueden incluir la edici´on de la superficie del objeto o
las propiedades del material (color, luminosidad, caracter´ısticas de reflexi´on, transparencia
u opacidad), agregar texturas, mapas de relieve (bump-maps) y otras caracter´ısticas a los
objetos. Tambi´en pueden incluir algunas actividades relacionadas con la preparaci´on del
modelo 3D para su posterior animaci´on
1
.
El modelado puede ser realizado por programas dedicados (como Lightwave 3D, Rhinoceros
3D o Moray), un componente de una aplicaci´on (Shaper, Lofter en 3D Studio) o por un
lenguaje de descripci´on de escenas (como en POV-Ray).
Composici´on de la escena. Esta etapa involucra la distribuci´on de objetos, luces,
c´amaras y otras entidades en una escena que ser´a utilizada para producir una imagen
est´atica o una animaci´on.
La iluminaci´on es un aspecto especialmente importante de la composici´on de la escena:
contribuye al resultado est´etico y a la calidad visual del trabajo.
Renderizado. Se llama render al proceso final de generar la imagen o animaci´ on a
partir de la escena creada. El proceso de render necesita una gran capacidad de c´alculo,
pues requiere simular muchos procesos f´ısicos complejos. La capacidad de c´alculo que se
puede realizar en un PC se ha incrementado r´apidamente a trav´es de los a˜ nos, permitiendo
un grado superior de realismo en los gr´aficos 3D.
5.2.2. Animaci´on
Por animaci´on se entiende la creaci´on de im´agenes en movimiento. Para crear la “ilusi´on
de movimiento” se muestra una imagen en la pantalla del ordenador que es r´apidamente
sustituida por una nueva imagen, similar a la anterior pero ligeramente modificada. Para
enga˜ nar a la vista y al cerebro, haci´endoles creer que se est´a viendo un objeto en movimien-
to, las im´agenes deben dibujarse a 24 frames por segundo o m´as r´apido (un “frame” es un
imagen completa). Por encima de 70 frames/segundo no mejora el realismo por el modo
en el que la vista y el cerebro procesan las im´agenes. Por debajo de 24 frames/segundo la
mayor´ıa de la gente percibe extra˜ nos fen´omenos disminuyendo el efecto de realismo. Por
ejemplo, en los dibujos animados convencionales utilizan 12 frames/segundo para reducir
el n´ umero de dibujos. Sin embargo, los gr´aficos por ordenador necesitan de tasas mayores
para mejorar el realismo de la imagen.
En animaci´on es muy frecuente utilizar la t´ecnica de doble buffering para evitar el flick-
1
A los objetos se les puede asignar un esqueleto de modo que el movimiento del mismo afecte au-
tom´aticamente al modelo.
58 CAP
´
ITULO 5. SISTEMAS GR
´
AFICOS
ering (parpadeo) originado porque la pantalla se borra y se redibuja de forma constante.
El proceso que se sigue es el siguiente: cuando la imagen se renderiza se hace en el llamado
buffer secundario, en el que el ordenador dibuja la imagen haciendo los cambios necesarios
antes de mostrarla. Mientras tienen lugar los cambios, lo que se muestra en pantalla es
el contenido del buffer primario. Cuando la imagen se completa, se dibuja en pantalla el
contenido del buffer secundario. Este proceso puede hacerse de dos formas:
el contenido del buffer secundario se copia en el primario
se intercambian los buffers primario y secundario (de forma que el primario pasa a
secundario y viceversa)
Este cambio debe hacerse de forma imperceptible para el usuario o de otro modo se pro-
duce la llamada ruptura de la imagen, que disminuye el efecto perseguido por la animaci´on,
es decir, la “ilusi´on de movimiento”.
5.2.3. Herramientas
Para el dise˜ no gr´afico en sus distintas fases(modelado, animaci´on. . . ) existen en el
mercado multitud de herramientas:
Herramientas especializadas en ciertos procesos como por ejemplo:
• modelado: Rhino3D, Wings3d . . .
• texturizado: UVMapper, DeepPaint . . .
• render: YaFray, 3DLight . . .
• animaci´on: Pose, AnimationMesher . . .
Entornos integrados para todos los procesos, muy caros en general. Este es el caso de
los conocidos 3DStudio Max, SoftImage, Maya o LightWave. Existe tambi´en alguna
alternativa libre a los mismos como es el caso de Blender.
5.3. Blender
Blender es un programa de modelado y animaci´on libre (gratuito), con caracter´ısticas
como soporte para programaci´on bajo Python. Es mucho menos conocido que otros pro-
gramas para animaci´on 3D, como 3DStudio, Lightwave o Maya, pero es una herramienta
de gran potencia para el dise˜ no gr´afico.
5.3. BLENDER 59
Un poco de historia
Originalmente el programa fue desarrollado como una aplicaci´on propia por el estudio
de animaci´on holand´es NeoGeo; el principal autor, Tom Roosendaal, fund´o la empresa “Not
a Number Technologies” (NaN) en junio de 1998 para desarrollar y distribuir el programa.
La compa˜ n´ıa lleg´o a la bancarrota en 2002 y los acreedores acordaron ofrecer Blender
como un producto de c´odigo abierto y gratuito bajo los t´erminos de la GNU GPL a cambio
de 100.000e. El 18 de julio de 2003, Roosendaal cre´o la “Fundaci´on Blender” (sin ´animo
de lucro) para recoger donaciones; el 7 de septiembre se anunci´o que se habia reunido el
dinero necesario para liberar Blender y el c´odigo fuente se hizo p´ ublico el 13 de octubre.
Por tanto, Blender es Open Source, es decir, que el c´odigo fuente del programa est´a disponible
para examinarlo y generar mejoras a este para su inclusi´on en las nuevas versiones
2
. La
´ ultima versi´on, Blender 2.36 (Figura 5.1), est´a disponible en la web
3
para instalar en
los distintos sistemas operativos (tiene versiones para Windows, Linux, Irix, Sun Solaris,
FreeBSD y Mac OS X bajo la GNU Public License).
Figura 5.1: Captura de pantalla de Blender 2.36
Como ejemplo de su buen estado se puede se˜ nalar que se ha utilizado como una de las
herramientas de animaci´on para la pel´ıcula “Spiderman 2”.
2
M´as informaci´on sobre la evoluci´on de blender en www.blender.org
3
www.blender3d.org
60 CAP
´
ITULO 5. SISTEMAS GR
´
AFICOS
Caracter´ısticas
Las caracter´ısticas principales de esta herramienta de dise˜ no gr´afico son:
Es multiplataforma, libre, gratuita y con un tama˜ no de origen realmente peque˜ no
(alrededor de 5 MB dependiendo del sistema operativo)
Permite utilizar una gran variedad de primitivas geom´etricas, incluyendo curvas, mal-
las poligonales, NURBS, metaballs (objetos de tres dimensiones con caracter´ısticas
f´ısicas del mercurio)
Junto a las herramientas de animaci´on se incluyen cinem´atica inversa, deformaciones
por armadura o cuadr´ıcula, v´ertices de carga y part´ıculas est´aticas y din´amicas.
Permite la edici´on de audio y sincronizaci´on de v´ıdeo.
Posee caracter´ısticas interactivas para juegos (detecci´on de colisiones, recreaciones
din´amicas y l´ogica)
Posibilita un renderizado interno vers´atil y la integraci´on externa con el potente
trazador de rayos libre de YafRay.
Mediante el lenguaje Python se pueden automatizar o controlar distintas tareas
Acepta formatos gr´aficos como TGA, JPG, Iris, SGI, o IFF. Tambi´en puede leer
ficheros Inventor.
5.4. Python
Python es un lenguaje de programaci´on de scripts (script es el nombre que se da
a un archivo, o conjunto de archivos, que contiene instrucciones, y que necesita de un
programa int´erprete para ejecutarse). Permite dividir el programa en m´odulos reutilizables
desde otros programas. Dispone de una gran colecci´on de m´odulos est´andar que se pueden
utilizar como base de los programas (o como ejemplos para empezar a aprender Python).
Tambi´en posee otros que proporcionan E/S de ficheros, llamadas al sistema, sockets y hasta
interfaces GUI (Interfaz Gr´afica con el Usuario).
Un poco de historia
Python fue creado como sucesor del lenguaje ABC por Guido van Rossum en 1990
cuando trabajaba en el Stichting Mathematisch Centrum (CWI)
4
. En 1995 continu´o su
4
www.cwi.nl
5.5. TRABAJO CON BLENDER Y PYTHON 61
trabajo en Python en el CNRI
5
donde cre´o muchas versiones del lenguaje. En mayo del
2000 Guido y el equipo de desarrollo de Python se trasladan a BeOpen.com y se forma
el BeOpen PythonLabs. En octubre de este mismo a˜ no, PythonLabs pasa a Digital Cre-
ations (actualmente Zope Corporation). En 2001, se crea la “Python Software Foundation”
(PSF)
6
, una organizaci´on sin ´animo de lucro que surge espec´ıficamente para proteger la
libertad de Python como lenguaje de c´odigo abierto.
El nombre del lenguaje proviene de la afici´on de su creador original por los humoristas
brit´anicos Monty Python. El principal objetivo que persigue este lenguaje es la facilidad,
tanto de lectura como de dise˜ no.
Caracter´ısticas
Las caracter´ısticas principales de Python son:
Es un lenguaje de alto nivel sencillo, potente y r´apido que est´a en constante crec-
imiento
7
.
Es un lenguaje interpretado, lo que ahorra un tiempo considerable en el desarrollo
del programa pues no es necesario compilar ni enlazar. Se dice que un lenguaje es
interpretado si sus instrucciones se ejecutan secuencialmente a partir del c´odigo fuente
(el int´erprete va recibiendo l´ıneas de c´odigo que traduce a c´odigo m´aquina para que
se ejecuten).
El int´erprete se puede utilizar de modo interactivo. Esto facilita experimentar con
caracter´ısticas del lenguaje, escribir programas desechables o probar funciones du-
rante el desarrollo del programa. Tambi´en es una calculadora muy ´ util.
5.5. Trabajo con Blender y Python
5.5.1. Criterios de selecci´on
Se eligi´o Blender como herramienta para el dise˜ no y la animaci´on del modelo facial que
es objeto de este proyecto por tres motivos fundamentales:
Es libre (se dsitribuye bajo la GNU Public License)
Es multiplataforma (existen versiones para Windows, Linux, Mac OS X. . . )
5
www.cnri.reston.va.us
6
M´as informaci´on en la p´agina web www.python.org/psf/
7
M´as informaci´on en www.python.org
62 CAP
´
ITULO 5. SISTEMAS GR
´
AFICOS
Figura 5.2: Ejemplo de modelado con Blender: “Ginger”
Es un entorno integrado para la animaci´on gr´afica (con la misma herramienta pode-
mos trabajar en las distintas etapas del dise˜ no grafico: modelado, texturizado y ani-
maci´on)
5.5.2. Prototipo Blender
* Aprendizaje de la herramienta. Durante el desarrollo de este proyecto la versi´on
de Blender ha cambiado varias veces, a˜ nadiendo prestaciones a la herramienta. La m´as
interesante de ellas desde el punto de vista de la animaci´on es que el motor de juegos
(game engine), congelado desde la versi´on 2.28, volvi´o a formar parte de Blender
a partir de la 2.34 (agosto de 2004). El game engine permite la interacci´on con el
programa en tiempo real y esto es una caracter´ıstica necesaria para la implementaci´on
del software que es objeto de esta memoria.
El objeto a crear es una cara antropom´orfica que posteriormente habr´a de animarse,
pero el primer paso en este proceso es familiarizarse con la herramienta. Blender es
una herramienta muy potente con un entorno de ventana muy distinto del usual, muy
distinto incluso de los entornos de ventana de otras aplicaciones similares dedicadas
al dise˜ no gr´afico. Por este motivo antes de empezar con la construcci´on del modelo de
la cara se construyeron otros elementos m´as simples. Como apoyo en este proceso de
aprendizaje se utilizaron los recursos disponibles en la red as´ı como la “Gu´ıa oficial
de Blender” [Roosendaal and Selleri, 2004]. Una de las creaciones de esta etapa de
aprendizaje puede verse en la Figura 5.2.
Una vez alcanzado el dominio suficiente de la herramienta se comenz´o con el dise˜ no
de la cara antropom´orfica para el proyecto.
* Modelado. Se construy´o una cara mediante puntos utilizando como soporte dos
imagenes de una cara, una de frente y otra de perfil (Figura 5.3). El motivo por el
5.5. TRABAJO CON BLENDER Y PYTHON 63
cual se utilizaron como referencia fue por cuesti´on de proporciones ya que el objetivo
es crear una cara antropom´orfica de apariencia normal. Aprovechando la simetr´ıa de
la cara se modela la mitad y mediante proyecci´on especular generamos la otra mitad.
Los puntos que definen la cara se unen formando triangulos o cuadrados (la forma
´optima para facilitar el posterior proceso de renderizado es la triangular). Cuantos
m´as puntos, m´as pol´ıgonos y mayor definici´on. El resultado final del proceso de
modelado esta formado por unos 500 puntos y puede verse en la Figura 5.4.
Figura 5.3: Im´agenes auxiliares para el dise˜ no de la cara
* Composici´on. Es momento de determinar la distribuci´on de los objetos, las luces
y las c´amaras en la escena. El ´ unico objeto de la escena es la cara creada en el
proceso de modelado. El tema de iluminaci´on es muy importante para el realismo
de la imagen generada. Blender dispone de distintos tipos de luces y de un men´ u en
el que definir los par´ametros de las mismas (ver Figura 5.5). Es necesario poner en
la escena al menos una luz y una c´amara ya que de otro modo no se ver´ıa nada al
renderizar en el paso siguiente. La escena por defecto de Blender trae una luz y una
c´amara (ver Figura 5.7), que nos sirven para la escena sencilla que se est´a creando.
* Renderizado. Despu´es del proceso de modelado y composici´on se puede generar
la imagen final, es decir, se puede renderizar la escena. El men´ u de Blender corre-
spondiente al renderizado permite definir algunas opciones tales como el tama˜ no de
la ventana en la que veremos el resultado (Figura 5.6). Una vez seleccionado como
se quiere que se realice el render, se ejecuta y se abre una ventana con la escena
renderizada.
* Dificultades en la creaci´on gr´afica con Blender.
Blender tiene una peculiar interfaz gr´afica de usuario como puede verse en la Figura
5.7. Es poco intuitiva pero al mismo tiempo muy eficiente y productiva una vez se
llega a conocer. El usuario se comunica con el programa v´ıa teclado y rat´on (como
Blender hace un uso intensivo de de los mismos, existe una “regla de oro” com´ un
entre los usuarios de Blender: ¡mant´en una mano sobre el teclado y la otra sobre el
64 CAP
´
ITULO 5. SISTEMAS GR
´
AFICOS
Figura 5.4: Dise˜ no con Blender de una cara antropom´orfica
Figura 5.5: Men´ u para la iluminaci´on de Blender
5.5. TRABAJO CON BLENDER Y PYTHON 65
Figura 5.6: Men´ u para el renderizado de Blender
Figura 5.7: Escena por defecto de Blender
rat´on! ). La interfaz de Blender hace uso de los tres botones del rat´on y de un amplio
rango de teclas r´apidas.
Los resultados de elevada calidad
8
hacen que el esfuerzo en dominar la herramienta
est´e recompensado ampliamente por los resultados que se pueden obtener.
Si se quiere “deshacer” una acci´on, Blender ofrece esa posibilidad (Mesh Undo), pero
8
En www.blender3d.org se encuentra una galer´ıa de im´agenes creadas con Blender
66 CAP
´
ITULO 5. SISTEMAS GR
´
AFICOS
Figura 5.8: Algunas opciones de Blender
s´olo funciona para mallas en modo edici´on y para una ´ unica malla, siempre y cuando
se est´e trabajando con ella. Esto dificulta el proceso de modelado ya que hay errores
que una vez cometidos no pueden subsanarse y la ´ unica opci´on en estos casos es
volver a una versi´on guardada del trabajo o volver a empezar.
Otra caracter´ıstica de esta herramienta es que no solicita confirmaci´on para cerrar la
ventana de dibujo, de modo que si no se ha guardado previamente el trabajo realizado
se perder´ıan todas las modificaciones posteriores realizadas tras “salvar” por ´ ultima
vez. Esto tiene sus ventajas en las ocasiones en las que se comete un error que no se
puede deshacer, pero en la mayoria de los casos, esta peculiaridad del programa es
un inconveniente.
5.5.3. Animaci´on
Dejando a un lado los procesos de texturizado (le dan realismo a la im´agen pero es
secundario para los objetivos que persigue este proyecto), se pasa al proceso de animaci´on.
Debido a que el objetivo del proyecto es que la cara se mueva seg´ un lo requiera un programa
externo a Blender es necesario que utilicemos Python como interfaz entre ellos. Ha de usarse
de forma conjunta al game engine ya que, como se explic´o antes, es el ´ unico modo que
existe para que podamos interactuar con Blender en tiempo real. Python no s´olo se utiliza
en el game engine, tambi´en sirve para modelar y animar.
5.5. TRABAJO CON BLENDER Y PYTHON 67
* Game engine . Es el motor de juegos de Blender. Permite la interacci´on con el
programa en tiempo real. En el game engine existen tres partes: los sensores, los
controladores y los actuadores. Haciendo un s´ımil se puede decir que los sensores
act´ uan como los sentidos, los controladores como el cerebro y los actuadores como
los m´ usculos. De modo que los sensores reaccionan ante un evento, los controladores
recogen los eventos de los sensores y calculan el resultado, y los actuadores realizan
la acci´on sobre los objetos. Existen distintos tipos de sensores (“always”, teclado,
rat´on. . . ), de controladores (AND, OR, expresiones, scripts de Python
9
) y actuadores
(movimiento, propiedades, c´amara, sonido . . . ).
El modo en que actua el game engine es el siguiente: se le asocia un sensor a un
objeto. Dependiendo del tipo de sensor elegido se disparar´a en un momento o en otro
(el “always” cada cierto tiempo, el “keyboard” cuando se produzca un evento por
teclado . . . ). Relacionado con ese sensor existe un controlador que se une al actuador
(Figura 5.9).
Figura 5.9: Men´ u game engine de Blender
* Python. El script de Python se encarga de dos cosas: por un lado de interactuar con
Blender y por el otro de recoger los datos que indican c´omo debe cambiar la imagen.
Es necesario comunicar Python con otro programa (el cliente CORBA descrito en el
Cap´ıtulo 3) que se ejecuta dentro de la misma m´aquina. Se eligen los sockets para
la comunicaci´on de ambos. Se crea una estructura cliente/servidor. El cliente es el
programa en Python y el servidor es el programa CORBA (que est´a escrito en C++).
* Proceso de animaci´on. Para el proceso de animaci´on es necesario unir tres ele-
mentos: el servidor CORBA que indica qu´e expresi´on poner, el cliente Python que
lo recoge y se lo comunica al tercer elemento, Blender, mediante un script actuan-
do como controlador en el game engine. Para conectar cliente y servidor se utilizan
sockets.
Existen muchos tipos de sockets, los de uso mas extendido son los sockets unix y los
inet. Como los dos programas se ejecutan en la misma m´aquina en principio pueden
usarse los sockets unix que son m´as r´apidos que los inet, pero debido a que Python
no posee implementaci´on para esta clase de sockets se trabaja con los inet. Se crean
prototipos de cliente/servidor en C++ y en Python, para en el ´ ultimo momento
desarrollar la aplicaci´on mixta en la que el cliente es Python y el sevidor es C++.
9
Permiten generar un comportamiento m´as completo
68 CAP
´
ITULO 5. SISTEMAS GR
´
AFICOS
* Dificultades para la animaci´on con Blender y Python. De modo similar al
proceso de modelado, lo primero es explorar las caracter´ısticas del game engine para
poder utilizarlo para los objetivos del proyecto. Se realizaron pruebas con figuras
sencillas. Comenzaron a surgir problemas ya que las operaciones que se pueden re-
alizar a los objetos con el game engine son limitadas: no todas las operaciones que
se pueden hacer con los objetos tienen su equivalente para el game engine (como por
ejemplo, girar un objeto seg´ un los ´angulos de Euler). Esta funcionalidad de Blender
est´a pensada para el dise˜ no de juegos, por lo que viene provista de funciones f´ısicas
tales como gravedad o colisiones entre objetos. Las pruebas con objetos sencillos no
daban los resultados esperados, las operaciones se complicaban, por lo que en este
punto se abandon´o el camino basado en Blender para el desarrollo de la aplicaci´on.
Blender es una herramienta muy potente pero no es lo suficientemente flexible, para
el desarrollo completo de la aplicaci´on.
5.5.4. Conclusiones
Como quiera que Blender es una herramienta de dise˜ no gr´afico integrada cuya misi´on
es facilitar la creaci´on de gr´aficos que no se adapta a las necesidades de este proyecto y
que no es m´as que un programa dise˜ nado sobre la librer´ıa de dise˜ no grafico por excelencia
(OpenGL), el camino que toma el proyecto a partir de este punto es utilizar para el dise˜ no
y la animaci´on OpenGL directamente.
5.6. OpenGL
Debido a los problemas encontrados al realizar el modelado y animaci´on de la apli-
caci´on objetivo del presente proyecto descritas en la secci´on anterior, se decide recurrir
directamente a OpenGL para resolver el problema planteado. Se descarta recurrir a otra
herramienta gr´afica ya que, tras la experiencia con Blender, es claro que esta aplicaci´on
tiene unas caracter´ısticas muy especificas que son poco comunes en el mundo del dise˜ no
grafico (interactuar en tiempo real utilizando otra aplicaci´on como fuente de eventos ante
los que reaccionar).
OpenGL es una librer´ıa de funciones que permite visualizar gr´aficos 3D en nuestra apli-
caci´on. La gran ventaja de esta librer´ıa es que aisla la aplicaci´on del hardware disponible;
por tanto, si se dispone de una tarjeta aceleradora, no har´a falta cambiar el programa para
aprovechar la potencia de la tarjeta.
Librer´ıas adicionales de OpenGL
La librer´ıa principal de OpenGL suministra todas las funciones necesarias para mostrar
un entorno 3D aunque hay algunas operaciones que son algo tediosas de realizar utilizando
5.6. OPENGL 69
solo esta librer´ıa. Para esto existen tambi´en unas librer´ıa auxiliares:
La librer´ıa GLU (OpenGL Utility Library) es una librer´ıa de utilidades que propor-
ciona acceso r´apido a algunas de las funciones m´as comunes de OpenGL, a trav´es
de la ejecuci´on de comandos de m´as bajo nivel pertenecientes a la librer´ıa OpenGL
propiamente dicha.
La librer´ıa GLUT (OpenGL Utility Toolkit) es un paquete auxiliar que proporciona
una interfaz independiente de la plataforma para crear aplicaciones de ventanas to-
talmente portables. GLUT nos permite crear ventanas y controlar la entrada inde-
pendientemente de la plataforma utilizada
La librer´ıa GLAUX, muy parecida a GLUT, es la que Microsoft ha desarrollado para
Windows. Mantiene practicamente la misma estructura que la librer´ıa GLUT con
el defecto de que solo es aplicable para Windows, mientras que GLUT sirve para
cualquier plataforma.
La librer´ıa GLX es la utilizada para trabajar en un sistema de X-Windows (GNU/Linux),
permite no s´olo renderizar en la m´aquina local, sino tambien a traves de red.
Tambi´en hay otras librer´ıas m´as espec´ıficas para el control de entrada, sonido, red....
(OpenGL es una librer´ıa gr´afica, no fue dise˜ nada para eso).
OpenGL est´a formado por aproximadamente 250 comandos de los cuales unos 200
corresponden al n´ ucleo de OpenGL y los restantes a GLU. GLUT proporciona una API
que facilita enormemente el aprendizaje de la programaci´on con OpenGL. Se recomienda
su uso para aquellas aplicaciones que no requieran interfaces muy sofisticadas ya que para
esos casos es mejor utilizar las herramientas del sistema de ventanas que estemos utilizando
(para Windows se usa la libreria GLAUX y para X-Windows la libreria GLX). GLUT no
es OpenSource, su creador Mark Kilgard sigue manteniendo el copyright. Es necesario
descargar e instalar el paquete para poder utilizarlo. Al descomprimirlo aparece un archivo
“readme” en el que se detallan los pasos a seguir para su instalaci´on dependiendo de la
plataforma en la que se est´e trabajando. La versi´on de GLUT utilizada en el presente
proyecto es la 3.6.
Un poco de historia
OpenGL es un est´andar sobre gr´aficos por ordenador, hoy d´ıa es uno de los m´as conocido
del mundo. En 1982 naci´o en la Universidad de Standford el concepto de graphics machine
y este fue utilizado por Silicon Graphics Corporation en su propia estaci´on Silicon IRIS
para crear un renderizador. As´ı nacio la librer´ıa IRIS GL. A ra´ız de esto, en 1992, muchas
empresas del hardware y software se pusieron deacuerdo para desarrollar conjuntamente
una librer´ıa gr´afica libre: OpenGL. Entre estas empresas destacaban Silicon Graphics Inc.,
70 CAP
´
ITULO 5. SISTEMAS GR
´
AFICOS
Microsoft, IBM Corporation, Sun Microsystems, Digital Equipment Corporation (DEC),
Hewlett-Packard Corporation, Intel e Intergraph Corporation. As´ı naci´o OpenGL (Open
Graphics Library).
Caracter´ısticas
Entre las caracter´ısticas de OpenGL podemos destacar que:
Es multiplataforma.
La gesti´on de la generaci´on de gr´aficos 2D y 3D se realiza por hardware ofreciendo
al programador una API sencilla, estable y compacta.
Su escalabilidad ha permitido que no se haya estancado su desarrollo, permitiendo
la creaci´on de extensiones, una serie de a˜ nadidos sobre las funcionalidades b´asicas,
para aprovechar las crecientes evoluciones tecnol´ogicas
10
.
Las operaciones se puden agrupar en jerarquias, lo que proporciona gran potencia y
flexibilidad a la hora de programar.
OpenGL funciona como una m´aquina de estados, por lo que el orden en el que se
realizan las operaciones es importante. El orden de las acciones resulta cr´ıtico en la
mayoria de las ocasiones. Sus variables de estado tienen unos valores por defecto que
podemos modificar para adaptarlos a la aplicaci´on que estemos desarrollando. Inicial-
mente la mayoria de estas variables de estado est´an desactivadas. Activarlas supone
que el renderizado sea m´as lento pero m´as realista. Es necesario un compromiso entre
ambos para obtener los resultados deseados.
Un programa en OpenGL puede ser complicado, la estructura b´asica puede sintetizarse
en dos ideas:
Inicializaci´on de ciertos estados que controlan como renderiza
11
OpenGL
especificar los objetos que han de renderizarse
OpenGL Rendering Pipeline
La mayor parte de las implementaciones de OpenGL siguen un mismo orden en las
operaciones, que en su conjunto crean lo que se suele llamar “OpenGL Rendering Pipeline”
(Figura 5.10).
10
M´as informaci´on acerca de OpenGL en www.opengl.org
11
Renderizado es el proceso en el cual el ordenador crea im´agenes de modelos u objetos. Las primitivas
geom´etricas con las que se construye cualquier objeto en OpenGL son puntos, l´ıneas y pol´ıgonos y vienen
definidos por sus v´ertices
5.6. OPENGL 71
Figura 5.10: OpenGL Rendering Pipeline
Sobre el vertex data se pueden aplicar evaluators para describir curvas o superficies
parametrizadas mediante puntos de control. Luego se aplican las pre-vertex operations
que convierten a los vertices en primitivas. Aqu´ı es donde se aplican las transformaciones
geom´etricas como rotaciones, traslaciones, etc. por cada v´ertice. En la secci´on primitive
assembly se elimina lo que queda fuera del plano de proyecci´on.
Por la parte de pixel data est´an las pixel operations. Aqu´ı los pixels son desempaquetados
desde alg´ un array del sistema (como el framebuffer) y tratados (escalados, etc.). Luego, si
estamos tratando con texturas, se preparan eln la seci´on texture assembly.
Ambos caminos convergen en la rasterization donde son convertidos en fragmentos.
Cada fragmento ser´a un pixel del framebuffer. Aqu´ı es donde se tiene en cuenta el modelo
de sombreado, la anchura de las l´ıneas o el antialiasing.
En la ´ ultima etapa, las perfragment operations, es donde se preparan los texeles (el-
ementos de textura) para ser aplicados a cada pixel, la “fog” (niebla), el z-buffering, el
blending, etc. Todas estas operaciones desembocan en el framebuffer, donde obtenemos el
render final.
Iluminaci´on
La iluminaci´on en OpenGL permite crear escenas m´as realistas, se basa en luces y
materiales. Una luz es una fuente de iluminaci´on sobre la escena, emite un haz de un color
determinado, dividido en las tres componentes de color RGB. Un material determina la
cantidad de cada color que refleja un objeto determinado.
Una fuente de luz es la entidad que aporta luz a la escena. Una fuente puede emitir
distintos tipos de luz, que son complementarios y pueden emitirse a la vez por la misma
fuente. Los tipos de luz son:
72 CAP
´
ITULO 5. SISTEMAS GR
´
AFICOS
emitida: luz emitida por un objeto. No se ve afectada por ning´ un otro tipo de luz.
difusa: es la luz que incide sobre un objeto y proviene de un determinado punto. La
intensidad con la que se refleja en la superficie del objeto puede depender del ´angulo
de incidencia, direcci´on, etc. Una vez incida sobre un objeto se refleja en todas las
direcciones.
especular: es la luz que al incidir sobre un objeto, se ve reflejada con un ´angulo similar
al de incidencia. Es la luz que produce los brillos.
ambiental: a esta categor´ıa corresponde el resto de luz que aparece debido a la re-
flexi´on residual de la luz que ya se ha reflejado sobre muchos objetos, y es imposible
determinar su procedencia. Es algo as´ı como la iluminaci´on global de la escena.
La iluminaci´on con OpenGL se calcula a nivel de v´ertice, es decir, por cada v´ertice se
calcula su color a partir del material activo, las luces activas y c´omo estas luces inciden
sobre el v´ertice. Se emplean las normales de los vertices
12
(vector perpendicular a la cara
que se esta dibujando). Las normales son salientes por la parte delantera de la cara. Por
defecto la parte delantera de la cara es aquella en que sus vertices se dibujan en sentido
antihorario (aunque esto puede cambiarse modificando el valor de la variable de estado
correspondiente).
Z-Buffer
El z-buffer o buffer de profundidad es un algoritmo que sirve para determinar los puntos
que se dibujan en la pantalla. Cada vez que se va a renderizar un pixel, comprueba que
no haya dibujado antes en ese pixel una posici´on que este m´as cerca repecto a la c´amara.
Este algoritmo funciona bien para cualquier tipo de objetos: c´oncavos, convexos, abiertos
y cerrados.
5.7. Trabajo con OpenGL
Para el modelado de la cara, teniendo en cuenta que debe posiblitarse la animaci´on
posterior, se utiliza como base el denominado “c´odigo de Waters”. El modelo de Waters se
basa en la animaci´on utilizando m´ usculos como describe la Secci´on 2.5.
La aplicaci´on se construye basandose en el trabajo desarrollado por Varian Qua [Qua, 2002].
Utiliza el c´odigo de Waters para desarrollar una aplicaci´on llamada “Facial Simulator” so-
bre Windows utilizando las librer´ıas MFC de Microsoft. Esta aplicaci´on consiste en una
interfaz gr´afica formada por dos partes: una cara y los controles para cambiarla por medio
12
Excepto para renderizar NURBS y otras funciones gr´aficas de alto nivel, OpenGL no genera au-
tom´aticamente las normales, de modo que hay que especificarselas
5.7. TRABAJO CON OPENGL 73
Figura 5.11: Aplicaci´on “Facial Simulator” para Windows
del rat´on para generar distintas expresiones en la misma. Esta interfaz puede verse en la
Figura 5.11.
La reutilizaci´on que este proyecto hace del c´odigo consiste en uso de la estructura
en que se organiza el programa y las funciones generales para dibujar vertices, calcular
normales. . . redise˜ nando la parte de OpenGL para que no dependa del sistema de ventanas
en el que se ejecute la aplicaci´on utilizando exlusivamente las librerias GL, GLU y GLUT.
Tambi´en es necesario dise˜ nar de nuevo toda la parte de animaci´on para adecuarla a los
objetivos de este proyecto.
La aplicaci´on est´a construida de tal modo que la cara y los m´ usculos son datos que est´an
en un archivo. El programa abre los archivos, lee los puntos y los dibuja en la pantalla
utilizando los com´andos de OpenGL. De este modo se podr´a utilizar este programa para
generar caras distintas que vienen determinadas por dos archivos: uno en el que se especifica
la posici´on de los puntos de la cara y otro en el que se especifica la posici´on y zona de
influencia de los m´ usculos sobre la misma. De modo que podemos disponer de m´ ultiples
caracteres definidos cada uno de ellos por dos archivos.
74 CAP
´
ITULO 5. SISTEMAS GR
´
AFICOS
Figura 5.12: Ejemplo con OpenGL
5.7.1. Creaci´on gr´afica
* Aprendizaje de la herramienta. El primer paso para poder desarrollar la apli-
caci´on es familiarizarse con la filosof´ıa y sintaxis que utiliza OpenGL. Los recursos
utilizados en esta etapa fueron el “Redbook”[Woo et al., 1999] y los tutoriales de
NeHe
13
.
Se comenz´o dibujando cosas sencillas para luego ir complicando la escena. Lo primero
que se hizo fue aprender a dibujar una ventana. Despu´es se dibujaron formas y se les
aplic´o color (un ejemplo puede verse en la Figura 5.12). Tambi´en se dibujaron figuras
y se rotaron. Por ´ ultimo se hicieron pruebas para aplicar texturas.
OpenGL es una m´aquina de estados y, como se ha indicado antes, el orden en el que
se realizan las operaciones es cr´ıtico en muchos casos. Un esquema sencillo que deben
seguir los programas en OpenGL es:
1. Activar las opciones que van a ser persistentes en la escena (poner la c´amara,
activar la iluminaci´on global . . . )
2. Activar las opciones que establecen el estado de un objeto espec´ıfico como la
posici´on en el espacio o la textura.
3. Dibujar el objeto.
4. Desactivar las acciones propias de ese objeto (volver a la posici´on inical, desacti-
var su textura . . . ) para que no afecten a objetos que se dibujen posteriormente.
5. volver al punto 2 hasta haber dibujado todos los objetos.
Concluido este proceso de aprendizaje se pasa al modelado de la cara, composici´on
de la escena y su posterior animaci´on.
13
http://nehe.gamedev.net, p´agina de referencia obligada para OpenGL
5.7. TRABAJO CON OPENGL 75
Figura 5.13: Modelado de la cara con l´ıneas
* Modelado.
El objeto que se est´a modelando para esta aplicaci´on es una cara antropom´orfica.
Deben posibilitarse tambi´en las posteriores tareas de animaci´on de la misma (como
ya se indic´o en la Secci´on 2.4 del presente documento). Por eso en esta parte se habla
de dos funciones, la que dibuja los pol´ıgonos de la cara y la que se encarga de dibujar
la estructura muscular (que es la que se utiliza para animar la cara).
Los prototipos de estas funciones son: void paint polygons (HEAD *face, int
type, int normals); y void paint muscles (HEAD *);. Se encargan de leer los
archivos correspondientes y dibujar mediante las primitivas de OpenGL la informa-
ci´on que proporcionan en la pantalla.
La cara se puede generar mediante l´ıneas (Figura 5.13) o mediante pol´ıgonos (Figu-
ra 5.14).La representaci´on que se va a utilizar es la generada mediante pol´ıgonos.
La realizada mediante l´ıneas es interesante para ver la disposici´on de los m´ usculos
(Figura 5.15). Para aumentar el realismo de la im´agen dise˜ nana se les aplica color
a los pol´ıgonos de la cara. El esquema de color seleccionado para la aplicaci´on es el
RGBA. La visualizaci´on del color depende del tipo de luces que iluminen la escena
como se ha indicado anteriormente en el presente cap´ıtulo.
76 CAP
´
ITULO 5. SISTEMAS GR
´
AFICOS
Figura 5.14: Modelado de la cara con pol´ıgonos
Figura 5.15: Distribuci´on de los m´ usculos en la cara
5.7. TRABAJO CON OPENGL 77
* Composici´on.
En esta etapa se construye la escena: se colocan los objetos, se situan las luces. . . Este
proceso se realiza en el programa principal. Su estructura es la siguiente
14
:
• Declaraci´on de las cabeceras de las librerias necesarias para la parte gr´ afica
(Son necesarias gl.h y glu.h pero si el programa utiliza glut solo es necesario
incluir glut.h ya que esta asegura que las otras dos son incluidas, y poner las
tres ser´ıa dar informaci´on redundante) y dem´as librer´ıas de car´acter general que
se necesiten as´ı como las espec´ıficas del programa que se esta dise˜ nando.
#include <GL/glut.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include"Head.h"
• Declaraci´on de las variables globales que se van a utilizar en el programa, como
por ejemplo las relativas a las luces (tipo de luz o posici´on). Para configuraciones
de luces y materiales m´as complejas que las que se usan en esta aplicaci´on es
conveniente crear un fichero llamado “iluminacion.h” en el que se definan las
luces que se van a utilizar en la escena as´ı como los distintos tipos de materiales
e incluir en el programa principal la cabecera correspondiente.
float ambient_light[] = { 0.3, 0.3, 0.45, 1.0 };
float source_light[] = { 0.9, 0.8, 0.8, 1.0 };
float light_pos[] = { 30.0, 70.0, 100.0, 1.0 };
• Declaraci´on de las funciones que se van a utilizar en el programa (y que est´an
definidas en otro archivo del c´odigo fuente), como por ejemplo dibujar los
pol´ıgonos de la cara o pintar los m´ usculos:
void paint_muscles(HEAD *);
void paint_polygons(HEAD *, int, int);
• Funci´on principal, de estructura claramente definida:
◦ Inicializaci´on de los modos con los que se crear´a la ventana como por ejemplo
los buffers que utiliza, el m´as importante por temas de animaci´on es el
GLUT DOUBLE que indica que se usa doble buffer para evitar el flickering.
glutInit(&argc, argv);
glutInitDisplayMode(GLUT_RGBA|GLUT_DOUBLE|GLUT_ALPHA|GLUT_DEPTH);
◦ Establecer el tama˜ no y posici´on de la pantalla
14
Se ponen trozos de c´odigo a modo de ejemplo
78 CAP
´
ITULO 5. SISTEMAS GR
´
AFICOS
glutInitWindowSize(640, 480);
glutInitWindowPosition(0, 0);
◦ Creaci´on de la ventana gr´afica con el nombre que quiera que aparezca en el
t´ıtulo de la ventana.
glutCreateWindow("myFacE");
Este nombre saldr´a siempre y cuando no hagamos una llamada a la fun-
ci´on glutFullScreen() que maximiza la ventana a todo el ´area disponible
ocultando el nombre de la ventana.
◦ Llamada a la funci´on que dibuja cada frame (utiliza el mecanismo de CALL-
BACK).
glutDisplayFunc(&DrawGLScene);
La funci´on a la que llama utilizando CALLBACK debe intercambiar los
buffers para evitar el parpadeo. Esto se hace mediante la instrucci´on de
GLUT glutSwapBuffers(). Justo antes de hacer la llamada a esta funci´on
es necesario llamar a la funci´on glFlush() de GL que se encarga de la
actualizaci´on de los buffers.
◦ Llamada a la funci´on que captura eventos del teclado y/o del rat´on. En
nuestro caso se utiliza la captura de eventos por teclado para hacer pruebas
previas a la aplicaci´on final (utiliza el mecanismo de CALLBACK).
glutKeyboardFunc(&keyPressed);
◦ Llamada a la funci´on que hace modificaciones entre frames necesaria para
las animaciones. Recoge las operaciones que se realizan entre una frame y
la siguiente que hacen que la escena vaya cambiando (utiliza el mecanismo
CALLBACK).
glutIdleFunc(&idle_function);
La funci´on a la que llama utilizando CALLBACK debe hacer que los cam-
bios que se realicen en las variables de dibujo se guarden para que la pr´oxima
vez que se dibuje estos cambios se reflejen. Esto se hace mediante la funci´on
de GLUT glutPostRedisplay().
◦ Lanzar el capturador de eventos que lleva al programa a que entre en un
bucle infinito y se empiece a dibujar (mientras no se llame a esta funci´on
no se dibuja nada en la pantalla)
glutMainLoop();
• Definici´on de las funciones que dibujan cada frame, entre frames, captura de
teclado. . . por ejemplo la funci´on que se ejecuta cuando se produce un determi-
nado evento por teclado (mediante CALLBACK) es la siguiente:
void keyPressed(unsigned char key, int x, int y)
{
usleep(10000);
if(key==ESCAPE){
5.7. TRABAJO CON OPENGL 79
face_reset(face);
make_expression(face, face->current_exp);
}
}
Las funciones de GLUT a las que se pasa como par´ametro la direcci´on de otra funci´on
con la sintaxis glut*(&funcion) utilizan el mecanismo de CALLBACK, de modo que
la funci´on ser´a llamada para hacer una operaci´on espec´ıfica cada vez que se produzca
un evento. La funci´on CALLBACK m´as importante es glutDisplayFunc() que se
ejecuta cada vez que se refresca la pantalla.
Se suele definir una funci´on que realiza la inicializaci´on de OpenGL y recoge las
operaciones que solo han de hacerse una vez en el programa como son:
• Seleccionar el color de fondo de pantalla.
• Activar la iluminaci´on.
• Indicar la profundidad de la escena y habilitar la comparaci´on de profundidad.
• Suavizar las aristas.
• Seleccionar las caracter´ısticas de los materiales.
• Seleccionar la matriz de proyecci´on.
• Seleccionar el tipo de proyecci´on con que se van a ver las im´agenes.
• Seleccionar la matriz de visualizaci´on/modelado.
El c´odigo de la funci´on de inicializaci´on de OpenGL descrita es el siguiente:
void InitGL(int Width, int Height)
{
//fondo de pantalla: blanco
glClearColor(1.0f, 1.0f, 1.0f, 0.0f);
//iluminaci´on
glEnable(GL_LIGHTING);
glEnable(GL_LIGHT0);
//profundidad
glClearDepth(1.0);
//dibujo lo q queda mas cerca
glDepthFunc(GL_LESS);
//habilito la comparacion de profundidad
glEnable(GL_DEPTH_TEST);
//pinto poligonos suavizando las aristas
80 CAP
´
ITULO 5. SISTEMAS GR
´
AFICOS
glShadeModel(GL_SMOOTH);
//caracter´ısticas de los materiales
glEnable(GL_COLOR_MATERIAL);
glColorMaterial(GL_FRONT, GL_AMBIENT_AND_DIFFUSE);
//matriz de proyecci´on (le cargo la matriz identidad)
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
//perspectiva de visualizaci´on de la imagen
gluPerspective(45.0f, (GLfloat) Width / (GLfloat) Height, 0.1f, 100.0f);
//matriz de visualizaci´on/modelado
glMatrixMode(GL_MODELVIEW);
}
* Renderizado. Una vez montada la escena es momento de crear la imagen final,
es decir, de renderizarla
15
. Para ello es necesario generar el binario de la aplicaci´on
dise˜ nada. Se hace mediante el siguiente Makefile:
La parte m´as importante del Makefile es la siguiente:
LIBS = -lX11 -lXi -lXmu -lglut -lGL -lGLU -lm
Se refiere a las librerias de OpenGL con las que se debe enlazar el binario. Son las
librerias GL, GLU y GLUT.
Al ejecutar el binario, se abre una ventana y se ve la cara dise˜ nada (Figura 5.14).
5.7.2. Animaci´on
Una vez concluye el proceso de modelado, composici´on y renderizado el siguiente paso
es la animaci´on de la cara. Durante el proceso de modelado se ha tenido en cuenta que
posteriormente viene un proceso de animaci´on. Este es el motivo por el cual se dibujan los
m´ usculos sobre la cara. Son las herramientas en las que se basa el proceso de animaci´on.
Los pasos generales para animar una escena son los siguientes:
1. Actualizar los datos de la figura (se realizan en la funci´on idle function).
2. Borrar la pantalla.
15
c´omo renderiza internamente OpenGL se explica en la Secci´on 5.6
5.7. TRABAJO CON OPENGL 81
3. Dibujar la figura.
4. Volver al punto 1.
Antes de construir la aplicaci´on final que anima la cara dise˜ nada seg´ un los estados
globales de Higgs se construyen una serie de prototipos. Se parte del dibujo est´atico de la
cara en estado neutro (Figura 5.14).
Prototipo: expresiones b´asicas. Este prototipo pretende que se dibujen las seis ex-
presiones b´asicas de Ekman [Ekman and Friesen, 1978](alegr´ıa, tristeza, miedo, sorpresa,
desagrado y enfado). Como se ha indicado antes, los m´ usculos son los elementos que han
sido implementados en el modelado de la aplicaci´on para facilitar la tarea posterior de
animaci´on.
Los m´ usculos se caracterizan por tener una determinada tensi´on. Cada una de las
expresiones universales se caracteriza por la tensi´on de los m´ usculos que componen la
estructura de la cara. Es de nuevo en un archivo donde se encuentran las tensiones de cada
m´ usculo para cada uno de los estados emocionales. A modo de ejemplo, la parte del archivo
correspondiente a la alegr´ıa es el siguiente:
Alegria
Left_Zygomatic_Major 1.10 Right_Zygomatic_Major 1.00
Left_Angular_Depressor 0.00 Right_Angular_Depressor 0.00
Left_Frontalis_Inner 0.80 Right_Frontalis_Inner 0.90
Left_Frontalis_Major 0.20 Right_Frontalis_Major 0.20
Left_Frontalis_Outer 0.10 Right_Frontalis_Outer 0.30
Left_Labi_Nasi 0.00 Right_Labi_Nasi 0.00
Left_Inner_Labi_Nasi 0.00 Right_Inner_Labi_Nasi 0.00
Left_Lateral_Corigator 0.00 Right_Lateral_Corigator 0.00
Left_Secondary_Frontalis 0.00 Right_Secondary_Frontalis 0.00
Se utiliza como ayuda el teclado para implementar la funci´on prototipo. Esta funci´on
es a la que llama glutKeyboard cuando se presiona la tecla escape del teclado (se ha
definido que reaccione ante esa tecla). Lo que hace es que, cada vez q se pulsa esa tecla, va
recorriendo el archivo en el que se encuentran las distintas expresiones. De modo que se van
mostrando una tras otra en la pantalla. El orden con el que se visualizan es el siguiente:
neutra, alegr´ıa, tristeza, miedo, sorpresa, desagrado y enfado. Los resultados obtenidos
pueden verse en el Ap´endice A de la presente memoria.
El c´odigo de dicha funci´on es el siguiente:
void keyPressed(unsigned char key, int x, int y)
{
82 CAP
´
ITULO 5. SISTEMAS GR
´
AFICOS
usleep(10000);
if(key==ESCAPE){
face_reset(face);
face->current_exp++;
if (face->current_exp>= face->nexpressions)
face->current_exp=0;
make_expression(face, face->current_exp);
}
}
Prototipo: expresi´on viva. Este prototipo pretende que la imagen est´atica que se
dibuja cuando no se produce ning´ un evento tenga mayor sensaci´on de realismo. Lo que se
hace es a˜ nadirle a la tensi´on de los m´ usculos una oscilaci´on de un seno de poca amplitud
entre un frame y el siguiente. De este modo que se produce la sensaci´on de que esta
respirando.
Esta funci´on se implementa en idle function que es la funci´on que se ejecuta entre
frames. Su c´odigo es el siguiente:
void idle_function()
{
usleep(20000);
// codigo para generar la expresion "viva"
static float t;
float ts=0.07;
t=t+ts;
float amplitud=0.0006;
float inc=amplitud/tts*sin(tt); // a lo senoidal
int e=0;
int n;
for (n = 0; n < face->nmuscles; n++)
{
float muscle_contraction = face->expression[e]->m[n];
activate_muscle(face,
face->muscle[n]->head,
face->muscle[n]->tail,
face->muscle[n]->fs,
face->muscle[n]->fe,
face->muscle[n]->zone, +inc);
5.7. TRABAJO CON OPENGL 83
glutPostRedisplay();
}
Prototipo: cambio de expresi´on. El objetivo es pasar de una expresi´on a otra. La
funci´on lee los datos de dos expresiones del archivo de expresiones e interpola entre sus
valores mediante una senoidal.
La funci´on se implementa en el idle function y se ejecuta entre frames, el c´odigo de
la misma es el siguiente:
void idle_function()
{
usleep(20000);
// codigo para cambiar de expresion
static float t;
float ts=0.050;
t=t+ts;
int m;
// generacion de la interpolacion entre los niveles musculares de
// las expresiones i y j
face_reset(face);
int i=0;
int j=1;
for (m = 0; m < face->nmuscles; m++)
{
float muscle_contraction0 = face->expression[i]->m[m];
float muscle_contraction1 = face->expression[j]->m[m];
// genero una senoidal entre los valores
float ampl=abs(muscle_contraction0-muscle_contraction1)/2.0;
float punto_medio=(muscle_contraction0+muscle_contraction1)/2.0;
float inc=ampl*sin(t);
float valor=inc+punto_medio;
activate_muscle(face,
face->muscle[m]->head,
face->muscle[m]->tail,
face->muscle[m]->fs,
face->muscle[m]->fe,
face->muscle[m]->zone, valor);
84 CAP
´
ITULO 5. SISTEMAS GR
´
AFICOS
Figura 5.16: Esquema sencillo de la aplicaci´on HiggsFace
}
glutPostRedisplay();
}
Aplicaci´on final: animaci´on de la cara de Higgs. Un esquema sencillo de la apli-
caci´on final puede verse en la figura 5.16. Seg´ un este esquema el m´etodo seguido para el
proceso de animaci´on en la aplicaci´on final es el que se describe a continuaci´on: el servidor
CORBA Higgs le proporciona al EmotionMapper un vector con informaci´on sensorial del
robot.
´
Este se encarga de traducirla a informaci´on emocional que viene dada por un vector
que tiene por componentes las tensiones correspondientes a cada m´ usculo de la cara. Por
´ ultimo el EmotionMapper le pasa esta informaci´on al servidor CORBA HiggsFace que la
utiliza para dibujar la cara.
La funci´on idle function que se utiliza para realizar las operaciones correspondientes
entre frames, se encarga de utilizar los valores almacenados en el vector de estado emocional
que recibi´o el servidorHiggsFace en la ´ ultima llamada sobre su interfaz. De este modo,
cuando se redibuje la pantalla se har´a con las nuevas tensiones de los m´ usculos de la cara
correspondientes al estado emocional de Higgs.
Cap´ıtulo 6
Mapeo de emociones en Higgs
Este cap´ıtulo describe c´omo se realiza el mapeo a emociones del estado de Higgs. Por
mapeo se entiende la traducci´on del estado sensorial
1
a un estado emocional
2
sino propor-
cionar un mecanismo para implantar una teor´ıa concreta en forma de plug-in (en particular
como un agente activo ICa. El objetivo no es desarrollar una teor´ıa sobre las emociones. Se
pretende habilitar un mecanismo para transformar los estados del robot en estados emo-
cionales y posibilitar la visualizaci´on de ´estos mediante una cara antropom´orfica. Cualquier
teor´ıa sobre las emociones que quiera implementarse despu´es podr´a hacerse cambiando el
modo de mapear la informaci´on.
La aplicaci´on no se dise˜ na para emular estados humanos, sino que convierte los estados
globales del sistema en estados emocionales que expresa mediante caras de modo que estas
sean f´acilmente entendibles por el usuario. De esta forma, de un vistazo, se puede ver c´omo
se encuentra el sistema en un determinado instante.
Este cap´ıtulo describe la parte de la aplicaci´on que ha sido denominada EmotionMap-
per que se encarga de solicitar al robot su estado, mapearlo a un estado emocional y
enviar la informaci´on al programa gr´afico que se encarga de dibujar la cara. Se organiza
del siguiente modo:
En la Secci´on 6.1 se describe, a modo de introduccion, la misi´on del EmotionMapper
y la estructura del mismo.
En la Secci´on 6.2 se describe la informaci´on sensorial que nos proporciona el servidor
CORBA Higgs. Describe el tipo de informaci´on que proporciona al EmotionMapper
cuando este le solicita en un determinado momento el estado del robot m´ovil.
En la Secci´on 6.3 se describe c´omo el EmotionMapper realiza la traducci´on de los
estados globales del sistema en estados emocionales, esto es, el modo en el que la
1
Estado de los sensores del robot (tanto exteroceptivo como propioceptivo)
2
Estado sint´etico de alto nivel empleando en el control estrat´egico de una m´aquina
85
86 CAP
´
ITULO 6. MAPEO DE EMOCIONES EN HIGGS
informaci´on sensorial se transforma en informaci´on emocional que es visualizada pos-
teriormente en una cara antropom´orfica.
En la Secci´on 6.4 se indica c´omo el EmotionMapper transmite la informaci´on emo-
cional al servidor CORBA HiggsFace para que actualice la posici´on de la cara al
estado emocional determinado por el estado del sistema en ese momento.
6.1. EmotionMapper
El EmotionMapper es la parte de la aplicaci´on que se utiliza para transformar la
informaci´on sensorial en informaci´on emocional que pueda ser utilizada por la parte gr´afica
para representar mediante expresiones faciales en una cara antropom´orfica el estado del
sistema (Figura 6.1).
Figura 6.1: Elementos de la aplicaci´on HiggsFace
Higgs no tiene emociones humanas sino estados mec´anicos que abstraemos a estados
emocionales que se expresan mediante expresiones faciales para que, de un vistazo, el
operador sepa c´omo se encuentra el sistema. Hay que “jugar” con la informaci´on sensorial
que proporciona el robot (se describe en la Secci´on 6.2) para convertirla en informaci´on
emocional que guarde relaci´on con el estado del robot.
6.2. INFORMACI
´
ON SENSORIAL 87
6.2. Informaci´on sensorial
El robot m´ovil tiene un programa servidor ejecutandose en su CPU que atiende peti-
ciones a trav´es de la red inal´ambrica. Este servidor fue desarrollado en un proyecto anterior
[Pareja, 2004] y proporciona cierta informaci´on del robot que se va a utilizar para transfor-
mar a informaci´on emocional. El EmotionMapper es un agente ICa que act´ ua como cliente
de ese servidor solicit´andole la informaci´on sensorial de Higgs en un determinado instante.
El servidor le proporciona esa informaci´on mediante un vector con los datos pedidos en ese
momento. La informaci´on que le proporciona el servidor Higgs es la siguiente
3
:
velocidad de traslaci´on del robot (Velocity)
velocidad de rotaci´on del robot (RotVelocity)
velocidad de las ruedas derecha e izquierda (RightVelocity, LeftVelocity)
coordenadas X, Y y θ del robot respecto al sistema de referencia del robot (XCoordinate,
YCoordinate, ThCoordinate)
lecturas de los sonares
4
(Sonar Range)
bater´ıa (Battery)
Este vector le proporciona al EmotionMapper el estado global del sistema. Una vez
tiene esta informaci´on ha de transformarla en estados emocionales. Este proceso (el “mapeo”
propiamente dicho) se describe en la siguiente secci´on.
6.3. Transformaciones emocionales
Entre los objetivos del proyecto no est´a el desarrollo de una teor´ıa sobre las emo-
ciones. El objetivo perseguido es dotar al m´odulo de la funcionalidad necesaria para comu-
nicar su informaci´on sensorial mediante estados emocionales que se visualizan en una cara
antropom´orfica por lo que se limita a transformar la informaci´on sensorial que recibe de
alg´ un modo en informaci´on emocional que pueda utilizarse para dibujar la cara.
En el mapeo de emociones intervienen tres elementos: el vector de informaci´on sen-
sorial (V
R
), la matriz de emociones (M
e
) y el vector de informaci´on emocional (V
C
). A
continuaci´ on se describe cada uno de estos elementos.
3
Entre par´entesis el nombre correspondiente en la estructura proporcionada por el servidor.
4
Dispone de 16 sonares, aunque no todos tienen porqu´e estar activos.
88 CAP
´
ITULO 6. MAPEO DE EMOCIONES EN HIGGS
6.3.1. Vector informaci´on sensorial
Est´a formado por la informaci´on sensorial proporcionada por el robot que se utiliza
para el mapeo de emociones. No todos los datos que son proporcionados por el servidor al
hacerle la consulta sobre el estado de Higgs se utilizan para realizar la transformaci´ on a
estados emocionales. De entre los datos que proporciona el servidor se eligen aquellos que
son susceptibles de poder significar algo para el estado global del robot teniendo en cuenta
que vamos a hacer una analog´ıa para transformarlos en emociones.
Para la aplicaci´on que se est´a desarrollando, la informaci´on proporcionada por el servi-
dor CORBA Higgs que se selecciona para su conversi´on a emociones es la siguiente:
estado de la bater´ıa
coordenada X
coordenada Y
velocidad rueda derecha
velocidad rueda izquierda
velocidad de rotaci´on
Es necesario escalar al rango
[0, 1]
los valores de este vector ya que los valores que en ´el se encuentran corresponden a variables
muy distintas que no tienen relaci´on entre s´ı. De este modo cada variable influye en la
emoci´on final de manera parecida, independientemente de la magnitud de la misma (que
nos conducir´ıa a valores err´oneos porque los rangos de variaci´on de las mismas son muy
distintos).
En la siguiente tabla se reflejan las distintas variables consideradas as´ı como los rangos
de variaci´on de cada una de ellas:
Variable Rango
bater´ıa 0–13 (V)
coordenada X (∗) (m)
coordenada Y (∗) (m)
velocidad rueda derecha 0–250 (mm/s)
velocidad rueda izquierda 0–250 (mm/s)
velocidad de rotaci´on 0–50 (mm/s)
Los rangos de variaci´on de las variables coordenada X y coordenada Y se representa
por (∗) porque realmente no est´an limitados, incluso pueden ser negativos. El sistema
6.3. TRANSFORMACIONES EMOCIONALES 89
de coordenadas de referencia se establece en el momento en el que el robot se conecta
y empieza a moverse pero para poder utilizar estos valores en el mapeo de informaci´on
sensorial a informaci´on emocional que se est´a realizando deben limitarse. Consideramos
que el rango de variaci´on es de -5 a 5 metros.
Una vez la informaci´on sensorial de Higgs en un determinado instante le llega al Emo-
tionMapper, se cogen de esa vector las componentes que interesan para mapear el estado
global a estado emocional y se pasan a valores por unidad. El vector obtenido tras este
proceso es V
R
(vector de informaci´on sensorial).
El orden de estas variables en el vector V
R
es el siguiente
5
:
V
R
=
_
¸
¸
¸
¸
¸
¸
_
Bater´ıa
V rueda dcha
V rotaci´on
V rueda izqda
Coordenada X
Coordenada Y
_
¸
¸
¸
¸
¸
¸
_
6.3.2. Matriz de emociones
La matriz de emociones es una matriz de dimensiones m × n siendo m el n´ umero de
m´ usculos que se utilizan para la animaci´on y n el n´ umero de expresiones existentes. De
modo que el elemento a
ij
de la matriz de emociones representa la tensi´on del m´ usculo i
correspondiente a la expresi´on j.
En el caso de la aplicaci´on que se desarrolla en este proyecto, la matriz de emociones
es de 18 × 6. Esta matriz es,
5
La raz´on por la que se ordenan de este modo se indica en la parte del vector de informaci´on emocional.
90 CAP
´
ITULO 6. MAPEO DE EMOCIONES EN HIGGS
M
e
=
_
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
_
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
_
filas: m´ usculos (2 de cada) m = 1 . . . 18
_
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
_
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
¸
_
Cigom´atico mayor
Depresor del ´angulo de la boca
Frontal interior
Frontal
Frontal exterior
Elevador del ´angulo de la boca
Elevador del labio superior
Corrugador lateral
Corrugador superciliar
columnas: expresiones n = 1 . . . 6
_
¸
¸
¸
¸
¸
¸
¸
¸
_
¸
¸
¸
¸
¸
¸
¸
¸
_
Alegr´ıa
Enfado
Sorpresa
Tristeza
Miedo
Desagrado
La forma en la que se construye la matriz es la siguiente: se dispone de un archivo en el
que se indica la tensi´on de cada m´ usculo para cada una de las seis expresiones universales
de Ekman
6
. La aplicaci´on desarrollada abre dicho archivo y lee sus valores rellenando la
matriz M
e
(matriz de emociones) que se utiliza para el mapeo.
6.3.3. Vector de informaci´on emocional
Este vector representa las tensiones de cada uno de los m´ usculos de la cara para el
estado global del sistema. Se obtiene como producto de la matriz de emociones por el
vector de informaci´on sensorial:
V
C
= M
e
· V
R
siendo:
M
e
= [a
ij
]
m×n
V
R
= [r
j
]
n×1
V
C
= [c
j
]
m×1
6
Los valores de la tensi´on de cada m´ usculo en cada una de las expresiones se obtienen probando valores
hasta generar expresiones naturales.
6.3. TRANSFORMACIONES EMOCIONALES 91
de modo que:
c
i
=
m

j=1
(a
ij
· r
j
)
lo que significa que cada variable pondera una columna de la matriz de emociones. De
modo que el orden de las variables de informaci´on sensorial del vector V
R
es importante ya
que cada una de ellas pondera una emoci´on, es decir, le confiere un peso a esa emoci´on en
el estado final.
Figura 6.2: El EmotionMapper como aplicaci´on lineal
El vector obtenido no siempre puede utilizarse directamente. Es necesario modificarlo
antes si la tensi´on de alguno de los m´ usculos de la estructura supera los valores tension-
ales m´aximos para evitar obtener expresiones imposibles (que los puntos se salgan de la
cara). En la siguiente tabla se recogen las tensiones m´aximas de los distintos m´ usculos que
constituyen la estructura de la cara (su disposici´on se puede ver en la Figura 2.3).
Si alguno de los valores sobrepasa el umbral se satura ese valor, es decir, toma el valor
m´aximo de tensi´on posible para ese m´ usculo. Si todos los valores est´an dentro de los rangos
de variaci´on correspondientes a cada m´ usculo, no ser´a necesario hacer nada y su utilizaci´on
es inmediata.
Una vez obtenido el vector de informaci´on sensorial (V
C
) y modificado en caso de ser
necesario, el EmotionMapper lo transmite al servidor CORBA HiggsFace que utiliza su
informaci´on para dibujar la expresi´on correspondiente.
92 CAP
´
ITULO 6. MAPEO DE EMOCIONES EN HIGGS
M´ usculos (lado izquierdo) Tm´ax. M´ usculos (lado derecho) Tm´ax.
Cigom´atico mayor 1.10 Cigom´atico mayor 1.00
Depresor del ´angulo de la boca 0.70 Depresor del ´angulo de la boca 0.70
Frontal interior 3.10 Frontal interior 3.90
Frontal 0.60 Frontal 0.40
Frontal exterior 2.00 Frontal exterior 2.00
Elevador del ´angulo de la boca 1.80 Elevador del ´angulo de la boca 2.00
Elevador del labio superior 1.20 Elevador del labio superior 1.10
Corrugador lateral 2.30 Corrugador lateral 2.40
Corrugador superciliar 0.50 Corrugador superciliar 0.60
6.4. Visualizaci´on
Una vez que el EmotionMapper ha transformado la informaci´on sensorial en informa-
ci´on emocional ha de pas´arsela al sevidor HiggsFace para que este la trate de la forma
conveniente y en la cara se visualicen las nuevas tensiones de los m´ usculos que dan lugar
a la expresi´on emocional del estado global del sistema.
Cap´ıtulo 7
Conclusiones y l´ıneas futuras
Para finalizar con la memoria de este proyecto fin de carrera titulado “Mapeo facial
de emociones sint´eticas” en este cap´ıtulo se describen las conclusiones que se sacan del
trabajo realizado as´ı como posibles l´ıneas de investigaci´on que podr´ıan seguirse en el futuro
y revertir´ıan en mejoras para el mismo.
En la Secci´on 7.1 se recuerdan los objetivos, el trabajo realizado as´ı como las conclu-
siones que se sacan del proyecto que se describe en esta memoria.
En la Secci´on 7.2 se describen las l´ıneas de trabajo que quedan abiertas tras la conclusi´on
de este proyecto que supondr´ıan mejoras de la aplicaci´on desarrollada.
7.1. Conclusiones
El objetivo de este proyecto es la implementaci´on de un sistema para la visualizaci´on
del estado global de un sistema t´ecnico mediante una cara antropom´orfica utilizando la
expresi´on facial como m´edio de comunicaci´on. As´ı mismo se desarrolla un patr´on de dise˜ no
para poder implantar cualquier teor´ıa emocional en forma de agente activo. Tambi´en se
implementa una aplicaci´on concreta: HiggsFace (plataforma m´ovil Pioneer 2AT-8).
La aplicaci´on consta de tres partes que se han ido describiendo por separado en la
memoria.
Pioneer 2AT: Es el servidor CORBA que se ejecuta en la CPU de Higgs y se encarga
de proporcionar la informaci´on sensorial. Esta parte fue desarrollada anteriormente
para otro proyecto [Pareja, 2004], en un principio s´olo era necesario hacer uso de ´el,
pero la necesidad de hacer pruebas y la falta de disponibilidad del robot en algunos
momentos hicieron necesaria la creaci´on de un simulador que actuara como banco
de pruebas de la aplicaci´on. Fue necesaria la creaci´on de un servidor CORBA con la
misma interfaz que el servidor que se ejecuta en el robot para que cuando la aplicaci´on
93
94 CAP
´
ITULO 7. CONCLUSIONES Y L
´
INEAS FUTURAS
se conecte a Higgs se obtengan los mismos resultados que en las pruebas.
EmotionMapper: Este es un agente intermedio que se encargaba por un lado de recoger
la informaci´on sensorial y por otro de generar informaci´on emocional a partir de ella
mediante un proceso de mapeo. En este proyecto facilita un mecanismo para pasar
de las unas a las otras mediante transformaciones lineales de la informaci´on.
Face: Este bloque que se encarga del dibujo y gesti´on de la representaci´on gr´afica del
estado emocional de Higgs. Une dos cosas: por un lado es un servidor CORBA que
atiende peticiones que le llegan de clientes y por otro es un programa de dibujo gr´ afico
basado en OpenGL. Ambos interactuan de modo que lo que la parte gr´afica dibuja
los valores que le pasa el EmotionMapper dependiendo del estado que se infiere de
la informaci´on sensorial proporcionada por Higgs (o en su defecto por el banco de
pruebas construido para suplirle).
El resultado concreto obtenido en el proyecto es un sistema que dibuja distintas expre-
siones faciales seg´ un el valor de las variables del sistema rob´otico Pioneer 2AT-8. El valor
principal del desarrollo es, sin embargo, su reutilizabilidad en otras aplicaciones.
7.2. L´ıneas futuras
Este proyecto deja abiertas varias l´ıneas de trabajo. Algunas se relacionan directamente
con la aplicaci´on espec´ıfica realizada para este proyecto: HiggsFace, aunque tambi´en las
hay de car´acter m´as general como por ejemplo la relacionada con el mapeo de emociones.
7.2.1. Nuevo servidor
La aplicaci´on espec´ıfica para la que se ha implementado el software dise˜ nado es Higgs-
Face. El objetivo perseguido era hacer que Higgs se comunicara mediante emociones que
se visualizan en una cara antropom´orfica. Para ello el proceso que se se sigue es transfor-
mar la informaci´on sensorial que proporciona el servidor CORBA de Higgs en informaci´on
emocional utilizando el EmotionMapper.
El servidor que se ha utilizado en esta aplicaci´on fue dise˜ nado en otro proyecto [Pareja, 2004]
para satisfacer las necesidades espec´ıficas de aquel y no de ´este, por lo que una l´ınea de
trabajo futura para mejorar esta aplicaci´on es el dise˜ no de un nuevo servidor. Aria (API
para el control del robot) proporciona m´as funciones de las que se implementaron en su
momento para el servidor. Algunas de estas funciones proporcionan informaci´on m´as ade-
cuada a la hora de inferir un estado global del sistema, por ejemplo es el caso de ver si
el robot se est´a moviendo o no, si est´a atascado o si tiene los motores conectados. Toda
esta informaci´on es susceptible de significar algo para el estado global del sistema, mucho
7.2. L
´
INEAS FUTURAS 95
m´as que variables como la posici´on que se ha utilizado para el mapeo en la aplicaci´on
desarrollada (se utiliz´o la informaci´on disponible).
Por lo que una de las l´ıneas futuras que queda abierta tras la finalizaci´on de este
proyecto es desarrollar un servidor que proporcione m´as informaci´on acerca del robot para
aumentar la funcionalidad del mismo y poder as´ı expresar mejor su estado global utilizando
la expresi´on emocional.
7.2.2. Teor´ıa sobre las Emociones
La otra l´ınea de trabajo posible tiene que ver con el EmotionMapper. Como se in-
dic´o en el Cap´ıtulo 6 el objetivo de este proyecto no era el dise˜ no de una “Teor´ıa sobre
las Emociones” sino dotar al sistema de un mecanismo que transformara la informaci´on
sensorial disponible en informaci´on emocional.
En este proyecto no se ha utilizado ninguna teor´ıa concreta. Se dispon´ıa de una serie de
datos a partir de los cuales se implement´o un mecanismo de demostraci´on para transformar
la informaci´on proporcionada por esos datos en emociones que se visualizan en una cara
antropom´orfica.
Una interesante puerta que queda abierta tras este proyecto es la investigaci´on de una
Teor´ıa sobre las Emociones para el mapeo a informaci´on emocional del estado de los dis-
tintos sistemas f´ısicos con los que nos pudieramos encontrar, esto es, habilitar m´etodos que
expliquen c´omo realizar la traducci´on de un estado global del sistema a un estado emo-
cional que sea entendible por el usuario y que guarde analog´ıa con la expresi´on emocional
humana.
7.2.3. Aumentar el realismo de la imagen
La interfaz dise˜ nada en este proyecto para la comunicaci´on del estado global de un deter-
minado sistema (en este caso el robot m´ovil Higgs) es una cara de apariencia antropom´orfi-
ca. De modo que evitamos que sea necesario un “entrenamiento” especial para comprender
lo que se quiere significar ya que de la expresi´on facial se infiere el estado del sistema (de
igual modo que en la comunicaci´on entre personas se infiere el estado del interlocutor). La
cara de Higgs es una m´ascara dotada de gran expresividad de modo que es capaz de gener-
ar expresiones f´acilmente reconocibles por las personas (ver las im´agenes del Ap´endice A).
Con esto se cumple el objetivo del presente proyecto. Pero el dise˜ no gr´afico de la misma es
susceptible de mejora.
Aumentar el realismo de la imagen utilizando el dise˜ no gr´afico es una l´ınea futura de
trabajo. Se puede dise˜ nar que tenga ojos (y que se muevan), pelo en la cabeza y en la
cara (cejas, barba. . . ) as´ı como textura de piel en la cara en lugar de color. Todas estas
caracter´ısticas, como se explic´o en el Cap´ıtulo 2, contribuyen al realismo de la imagen y
consiguen que la interfaz dise˜ nada sea m´as cre´ıble. Lo ´ unico que aporta expresividad a
96 CAP
´
ITULO 7. CONCLUSIONES Y L
´
INEAS FUTURAS
la imagen son los ojos y su movimiento (no es una tarea sencilla conseguir una mirada
natural), el resto de las caracter´ısticas son s´olo est´eticas, pero en cualquier caso este es el
modo de proporcionar interfaces m´as naturales para el usuario.
Ap´endice A
Ejemplos
En este ap´endice se recogen im´agenes de la interfaz dise˜ nada en distintas posiciones. Se
recogen las expresiones universales de Ekman [Ekman and Friesen, 1975].
Alegr´ıa Enfado
97
98 AP
´
ENDICE A. EJEMPLOS
Sorpresa Tristeza
Miedo Desagrado
Ap´endice B
Otras herramientas
Adem´as de las herramientas descritas el los Cap´ıtulos 4 y 5, en la realizaci´on de este
proyecto y su correspondiente memoria se han utilizado otras. A continuaci´on se muestra
una lista de las mismas as´ı como en qu´e se emple´o cada una de ellas.
Eclipse: la plataforma Eclipse est´a dise˜ nada para la construcci´on de entornos de desarrollo
que puedan ser utilizados para la construcci´on de aplicaciones web, aplicaciones Java
de todo tipo, programas C++, y Enterprise JavaBeans (EJBs). En este proyecto se
ha utilizado Eclipse para realizar el programa que se encarga de dibujar y gestionar
la cara que expresa el estado del robot (programa C++).
L
A
T
E
X: es un conjunto de macros de T
E
X. La idea principal de L
A
T
E
X es ayudar a quien
escribe un documento a centrarse en el contenido m´as que en la forma. La calidad
tipogr´afica de los documentos realizados con L
A
T
E
X es comparable a la de una edi-
torial cient´ıfica de primera l´ınea. L
A
T
E
X es Software Libre bajo licencia LPPL. Se ha
utilizado para escribir esta memoria que recoge el trabajo realizado en el proyecto.
Kile: es un editor sencillo para T
E
X y L
A
T
E
X. Se ha utilizado para generar esta memoria.
Se utilizan las funciones integradas de las que dispone, que hacen que la creaci´on del
documento sea m´as sencilla (autocompleta comandos T
E
X/ L
A
T
E
X posibilita generar
y ver el documento con un solo click, tiene un asistente para introducir la bibliograf´ıa
. . . ).
GIMP(GNU Image Manipulation Program): es un programa de manipulaci´on de
im´agenes del proyecto GNU. Es la alternativa m´as firme del software libre al popular
programa de retoque fotogr´afico Photoshop. En este proyecto se ha utilizado para
hacer capturas de las im´agenes de la cara dise˜ nada, as´ı como para el retoque de otras
im´agenes que aparecen a lo largo de la memoria.
Open Office.org: es un proyecto basado en el c´odigo abierto para crear una suite ofim´atica.
Es bastante compatible con los formatos de fichero de Microsoft Office, ya que puede
99
100 AP
´
ENDICE B. OTRAS HERRAMIENTAS
leer directamente los archivos creados con dicha suite ofim´atica, aunque tiene su
propio formato de archivos basado en el est´andar XML. Se ha utilizado los m´odu-
los “Draw”(m´odulo de dibujo vectorial) e “Impress” (presentaciones) para crear las
figuras que se ven a lo largo de la memoria.
Bibliograf´ıa
[Alarc´on et al., 1994] Alarc´on, M., Rodr´ıguez, P., Almeida, L., Sanz, R., Fontaine, L.,
G´omez, P., Alam´an, X., Nordin, P., Bejder, H., and de Pablo, E. (1994). Heteroge-
neous integration architecture for intelligent control. Intelligent Systems Engineering.
[Bartneck, 2002] Bartneck, C. (2002). eMuu-An Embodied Emotional Character For The
Ambient Intelligent Home.
[Bartneck, 2003] Bartneck, C. (2003). Interacting with an embodied emotional character.
In DPPI ’03: Proceedings of the 2003 international conference on Designing pleasurable
products and interfaces, pages 55–60. ACM Press.
[Blanz and Vetter, 1999] Blanz, V. and Vetter, T. (1999). A morphable model for the
synthesis of 3d faces. In SIGGRAPH ’99: Proceedings of the 26th annual conference
on Computer graphics and interactive techniques, pages 187–194. ACM Press/Addison-
Wesley Publishing Co.
[Boden, 1977] Boden, M. A. (1977). Inteligencia artificial y hombre natural. Editorial
Tecnos.
[Braccini et al., 2002] Braccini, C., Lavagetto, F., Costa, M., and Pockaj, R. (2002). A
solution for model-independent animation of mpeg-4 faces.
[Brilliant, 2003] Brilliant, K. (2003). Building a digital human. Charles River Media, INC.
[Bui et al., 2003] Bui, T. D., Heylen, D., and Nijholt, A. (2003). Improvements on a simple
muscle-based 3d face for realistic facial expressions. In CASA ’03: Proceedings of the
16th International Conference on Computer Animation and Social Agents (CASA 2003),
page 33. IEEE Computer Society.
[Chinchilla, 2003] Chinchilla, R. (2003). Installing ICa. Hard Real Time CORBA IST
Project.
[Clavijo et al., 2000] Clavijo, J. A., Segarra, M. J., Sanz, R., Jim´enez, A., Baeza, C.,
Moreno, C., V´azquez, R., D´ıaz, F. J., and D´ıez, A. (2000). Real-time video for distribut-
ed control systems. In Proceedings of IFAC Workshop on Algorithms and Architectures
for Real-time Control, AARTC’2000, Palma de Mallorca, Spain.
101
102 BIBLIOGRAF
´
IA
[Cole, 1998] Cole, J. (1998). About Face. A Bradford Book.
[Darwin, 1872] Darwin, C. R. (1872). The expression of emotions in man and animals.
John Murray.
[Duchenne, 1862] Duchenne, C. B. (1862). The Mechanism of Human Facial Expression.
R. Andrew Cuthbertson.
[Ekman and Friesen, 1975] Ekman, P. and Friesen, W. (1975). Unmasking the face. A
guide to recognizing emotions from facial clues. Englewood Cliffs, New Jersey: Prentice-
Hall.
[Ekman and Friesen, 1978] Ekman, P. and Friesen, W. (1978). Facial action coding system
(FACS): a technique for the measurement of facial action. Technical report, Cosulting
Psychologist Press, Palo Alto, CA.
[El-Nasr et al., 1999] El-Nasr, M. S., Ioerger, T. R., Yen, J., House, D. H., and Parke,
F. I. (1999). Emotionally expressive agents. In CA ’99: Proceedings of the Computer
Animation, page 48. IEEE Computer Society.
[Evans, 2001] Evans, D. (2001). Emotion, a very short introducction. Oxford University
Press.
[Fabri et al., 1999] Fabri, M., Moore, D. J., and Hobbs, D. J. (1999). The emotional avatar:
Non-verbal communication between inhabitants of collaborative virtual environments.
Lecture Notes in Computer Science, 1739:245–248.
[Faigin, 1990] Faigin, G. (1990). The Artist’s Complete Guide to Facial Expressions.
Watson-Guptill Publicatiobs.
[F`abregas, 1993] F`abregas, J. (1993). El arte de leer el rostro. Martinez Roca.
[Garc´ıa, 2003] Garc´ıa, J. (2003). Curso de introducci´on a opengl (v1.0).
[Goleman, 1996] Goleman, D. (1996). Inteligencia emocional. Ed. Kair´os.
[Kopk and Daly, 2003] Kopk, H. and Daly, P. W. (2003). Guide to LaTeX. Addison Wesley,
4th edition.
[Marschner et al., ] Marschner, S. R., Guenter, B., and Raghupathy, S. Modeling and
rendering for realistic facial animation. pages 231–242.
[Michi Henning, 1999] Michi Henning, S. V. (1999). Avance CORBA programming with
C++. Addison Westley.
[Minsky, 1978] Minsky, M. (1978). Society of Mind. Simon.
BIBLIOGRAF
´
IA 103
[Mittelbach and Goossens, 2004] Mittelbach, F. and Goossens, M. (2004). The LaTeX
Companion. Addison Wesley, 2nd edition.
[Ostermann, 1998] Ostermann, J. (1998). Animation of synthetic faces in mpeg-4. In CA
’98: Proceedings of the Computer Animation, page 49. IEEE Computer Society.
[Pareja, 2004] Pareja, I. (2004). Sistema de comunicaciones para pioneer 2at-8. Master’s
thesis, ETSII-UPM.
[Parke, 1972] Parke, F. I. (1972). Computer generated animation of faces. In ACM’72:
Proceedings of the ACM annual conference, pages 451–457. ACM Press.
[Paull, 2002] Paull, D. B. (2002). Programming dynamic character animation. Charles
River Media, INC.
[Picard, 1998] Picard, R. W. (1998). Los ordenadores emocionales. Editorial Ariel.
[Qua, 2002] Qua, V. (2002). Muscle Based Facial Animation. PhD thesis, Imperial College.
[Roosendaal and Selleri, 2004] Roosendaal, T. and Selleri, S. (2004). The official Blender
2.3 guide. Blender Foundation.
[Sanz, 2002] Sanz, R. (2002). Embedding interoperable objects in automation systems.
In Proceedings of 28th IECON, Annual Conference of the IEEE Industrial Electronics
Society, pages 2261–2265, Sevilla, Spain. IEEE Catalog number: 02CH37363.
[Sanz, 2003] Sanz, R. (2003). The IST HRTC project. In OMG Real-Time and Embedded
Distributed Object Computing Workshop, Washington, USA. OMG.
[Sanz et al., 1999a] Sanz, R., Alarc´on, I., Segarra, M. J., de Antonio, A., and Clavijo,
J. A. (1999a). Progressive domain focalization in intelligent control systems. Control
Engineering Practice, 7(5):665–671.
[Sanz et al., 1999b] Sanz, R., Mat´ıa, F., and Puente, E. A. (1999b). The ICa approach to
intelligent autonomous systems. In Tzafestas, S., editor, Advances in Autonomous In-
telligent Systems, Microprocessor-Based and Intelligent Systems Engineering, chapter 4,
pages 71–92. Kluwer Academic Publishers, Dordretch, NL.
[Sanz et al., 2001] Sanz, R., Segarra, M., de Antonio, A., and Alarc´on, I. (2001). A
CORBA-based architecture for strategic process control. In Proceedings of IFAC Con-
ference on New Technologies for Computer Control, Hong Kong, P.R. of China.
[Sanz et al., 2000] Sanz, R., Segarra, M., de Antonio, A., Alarc´on, I., Mat´ıa, F., and
Jim´enez, A. (2000). Plant-wide risk management using distributed objects. In IFAC
SAFEPROCESS’2000, Budapest, Hungary.
104 BIBLIOGRAF
´
IA
[Sanz et al., 1999c] Sanz, R., Segarra, M. J., de Antonio, A., and Clavijo, J. A. (1999c).
ICa: Middleware for intelligent process control. In IEEE International Symposium on
Intelligent Control, ISIC’1999, Cambridge, USA.
[Sanz and Zalewski, 2003] Sanz, R. and Zalewski, J. (2003). Pattern-based control systems
engineering. IEEE Control Systems Magazine, 23(3):43–60.
[Terzopoulos and Waters, 1993] Terzopoulos, D. and Waters, K. (1993). Analysis and syn-
thesis of facial image sequences using physical and anatomical models. IEEE Trans.
Pattern Anal. Mach. Intell., 15(6):569–579.
[Trappl et al., 2002] Trappl, R., Petta, P., and Payr, S. (2002). Emotions in humans and
artifacts. Massachusetts Institute of Technology.
[Waters, 1987] Waters, K. (1987). A muscle model for animation three-dimensional facial
expression. In SIGGRAPH ’87: Proceedings of the 14th annual conference on Computer
graphics and interactive techniques, pages 17–24. ACM Press.
[Waters and Parke, 1996] Waters, K. and Parke, F. I. (1996). Computer Facial Animation.
AK Peters, Ltd.
[Woo et al., 1999] Woo, M., Neider, J., Davis, T., and Shreiner, D. (1999). OpenGL
Programming Guide: the official guide to learning OpenGL, version 1.2, 3rd edition.
Addison-Wesley.

2

i

A fuerza de perseverancia alcanz´ el caracol el arca de Noe. o

ii .

A Silvia por cuando eramos una pi˜a y pod´ n ıamos con todo. Porque somos demasiado distintos como para no chocar a veces. porque nos hicieron fuertes. Por meternos en tantos l´ y por apuntarse ı ıos iii . por ser un tipo muy sabio. porque a pesar de lo complicadas que se pusieron a veces las cosas. Por tantos buenos ratos. Por los paseos por Madrid al salir del depar.Agradecimientos A mi familia. pero s´ que est´n orgullosos de que “la ni˜a” sea ingeniero. Por su amistad. por convertirme en una friki. por el apoyo. bueno perdura en el tiempo. dado mucha ca˜a. Por ser grande como ingeniero y como persona. A Ceci por formar parte de la familia ASLab a pesar de ser del DIE. por su paciencia y confianza en m´ Por re´ conmigo y apoyarme en los malos momentos. ıa A Ricardo por mil motivos. Por creer en m´ y darme la oportunidad de trabajar en su equipo. A Cris por tener siempre a una sonrisa disponible. salimos de todas. Por ser el m´s canalla. Roberto y Mari Carmen por la paciencia. Por las cosas buenas. ı Por apoyarme en los malos momentos y cuidarme. Por ayudarme en todo momento. A Manuel por las eternas charlas arreglando el mundo delante de un caf´ de comercio justo. Por las cervezas y las risas. porque a pesar de los a˜os y las nominaciones sigue estando ah´ porque lo n ı. Por las clases magistrales. A Carlosm por todo el trabajo que ha hecho conmigo. ır sus consejos. Por las risas y por las l´grimas. a pesar de estar m´s que liado casi siempre. Por tener siempre la puerta abierta y una silla en su despacho. Por estar siempre de mi lado y apoyarme. a A Pablo por su amistad todos estos a˜os. pero sobre todo en la recta final y hacer que esto finalmente fuera realidad. En especial a mis padres. Tambi´n a mis hermanos Eduardo y Sergio por estar ah´ Porque todos ellos han e ı. Por tirar de mi en los malos momentos y n celebrar conmigo los buenos. Gracias por estar ah´ todo este tiempo. Por provocarme con tantas cosas nuevas. pero ambos seguimos enteros. Por ı. Por ese dominio y control de los “papeles” que ninguno llegaremos a tener. Por la complicidad en tantos e momentos. por hacer m´s a grande mi mundo. A Anita. A Julia por echarme m´s que un cable con la memoria y no asesinarme por comerme a todos los acentos. a Porque si he llegado a la meta es en gran parte por su culpa. Por la parte de culpa que tiene de que seamos un gran equipo. A Rafa por los buenos ratos. por los mails y por portarse como un amigo. Porque no n e a n los cambiar´ por nada. aunque a veces me los hubiera cargado.

. que se cruzaron en mi vida estos n a˜os. . porque algunos me ense˜aron la valiosa lecci´n de en n ı n o lo que no quiero convertime. . por pasarse siempre que puede por aqui y no olvidarse de nosotros. e n A todos aquellos. clases y horas en la cafeter´ Por las ıa. A Carlos G. A mis amigos de la escuela por compartir apuntes. Porque de todos aprend´ algo. por las o a conversaciones absurdas y por las risas. Por las vueltas y vueltas despu´s de e las clases de bailes de sal´n. A Bel´n por cuidar de su “hermana mayor” y por creer en m´ e ı. compa˜eros de pupitre y profesores. A Paco por pertenecer a la secta.iv a un bombardeo. A la pandi porque nos hacemos mayores pero seguimos juntos despu´s de tantos a˜os y de tantas cosas. porque tambi´n ellos me ense˜aron lo que es un ingeniero. despu´s de mucho esfuerzo. hoy pueda e dar esto por terminado. A Ignacio por el psicoan´lisis por el messenger. A los que dejaron que les “robara el e n alma” para este proyecto. charlas en clase y en los pasillos. ¡GRACIAS A TODOS! . Y a quien corresponda por ayudarme a que al fin. .

.1. . . . . . . . . . . . . o a 3. . . . . . . . . . . . . . . . .5. . . . . Estrategia . . . . . . . . . . . . . . . . .´ Indice general 1. . Una Cara para Higgs 3. . . . . . . . . . .6. . . . . . . . Descripci´n de las expresiones universales o . . . . . . . . . . . . .2. . . . . Inteligencia emocional . . . . . . . . . . 2. . . . . . . . . . . . . . . . . . Modelo de Waters . . . . . . . . . . . . . . . . . . .5. . . . . . . . . . . . . . . . . . . . . . . . . . . .4. . . . . . . . . .3. . . . . . . . . . Introducci´n . . Comunicaci´n y emoci´n o o 2. . . . . . . . . Expresiones faciales . . . . . . . . 2. . . . . . . . .5. .3. . . . . . . . . . . . .1. . Contexto . . . . . Aplicaciones . . . . 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . .5. . . . . . . . . . . . . 1. . . . u 2. . . . . . . . . . . . . . . .1. . .7. . . . . . . .3. . . . . . .1. . . . . . . . . . . . . . . . . 1. . Animaci´n facial . .5. . . . . . . . . .1. . . . . 1. . . . . . . . . . Introducci´n o 1. . . . . . . . . . . . . . . . Motivaci´n . . . 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objetivos del proyecto fin de carrera . . . . Estructura de la memoria . .2. . . . . . . . . . . . . . . . . . . . . . . . . . a 2. . . . . . . . . . . Vectores de m´sculos . . . . . . . . . . . . . . . . u 2. . . . . . . . . . . . . . u 2. . . . . o v 1 1 2 5 5 5 7 8 9 11 12 14 15 18 18 18 19 20 21 22 25 25 . . . o 2. . . . . . . . . . . . . . . . . . . . .5. . . 2. . . .2. . 2. . o n 2. Mec´nica muscular . . . . . . . El modelado de los m´sculos lineales . . . . . . . Interacci´n y dise˜o visual . Propiedades el´sticas . . . a 2. . . . Conclusi´n: Ideas b´sicas . . . . M´sculos de la cara .2. .3. . . . . . .4. . . .4. . . . . . . . . . . . . o 1.

. . . . . . . . . . . . . . . . . . . . . 4. .1. . . . . . . . . Comunicaci´n con el robot . . . . . La norma CORBA . La aplicaci´n HiggsFace . . . . . . . . . .6. . . Aria . . Instalaci´n de ICa Broker . . . . . . . . . . .4. .2. . . . 4. . . . o 4. . .4. . .1. . . Plataformas software 4. . . . . . . .1. .2. . . . . . . . . .2.vi ´ INDICE GENERAL 3. . . . . . . . Dise˜o de la aplicacion HiggsFace . . . . . . . . . . Instalaci´n de Omni . . . .2. . . . . . . .1. . . . . . . . . . Interacci´n con Higgs . . . . . . .3. . . . . Arquitectura de Control Integrado 4. .3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 3. . . . . . . . . . . . . . . . . . . . . 4. . . . Qt . . . . . . . . . . . . Cliente prototipo CORBA . . . . .3. .2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gr´ficos por ordenador . . . . . . . . . . . . . . .1. . . . . . . . o 5. . . . . .5. . . . . .1. . . . . CORBA . . . . 4. . . . . 4. Aplicaci´n final . . La Tecnolog´ CORBA . . . . . . .1. . . . . . . . . . . . 4. . . . . . .1. . . . . . . . . . Makefile . . ıa 4. .5. . . . . . Introducci´n a los sistemas gr´ficos . . . . . . 4. .3. . . . . . . . . . . o a 5. . . . . . . . . . . . . . . . . . . . . . . . . o o 3. . 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5. . . . Descripci´n de la aplicaci´n HiggsFace . . . . . . . . El grupo OMG . . . . . . . . . . . . . . . . . . . . . . .4. . .1. .3. . . . . . . . . . . . . . . . . . . . . Instalaci´n de Aria . . . . o 4. . . . . . . . . . . . . . Omni . 4. . . .5. .2. . . . . . . . . . . . . . . . o 3. Creaci´n de gr´ficos 3D . . . . . . . . o a . . . . . . . . . . . Interfaz IDL . . . . . . . . . . . . o 4. . . . . . Sistemas gr´ficos a 5. . . . . . . . . . . . . . . 4. . . . . . . . . .4.4. . . . . . . . . . . . . . . . . . . . . . . El Broker ICa . . . . . . . . . . . . . . . . . 4. . . . .1. . . .5. . . . . .6. . . . . . . . . . . . . . . . . . . . . . . . 4. . . . . . . . . . .2. . Ejecuci´n . . . . . . . n 25 26 27 28 31 32 32 33 33 40 40 41 42 42 42 43 43 43 44 46 48 49 50 51 53 55 56 56 56 4. . . . . . o 4. . . . .1. . . . . . . . . . . Servidor banco de pruebas . . . . .5. . .2. . . . . . .1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2. . . o 4. . . . . . .7. . .2. . . . . . a 5. . . . . . Estructura general del cliente C++ . . . .

.6. . . . . . .2. . . . . . . . . . . . Conclusiones y l´ ıneas futuras 7. . . . . .1. . . . . . . . . . . . . Prototipo Blender . . . . . . . . . . Creaci´n gr´fica . . .4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5. . . . 6. . . . . . . . .5. . . .´ INDICE GENERAL 5. . . . o a 5.1. . . . . . . . . . . . Animaci´n . . . . . . . . . . . .3. . . . . . 6. . . . . o 7. . . . . . . . . . . . Vector de informaci´n emocional . . . . . .2. .5. . . Aumentar el realismo de la imagen . . . . . . . . . . . . . 7. . .3. . . . . . . . . . . . . . . . . . . . . . . 5. . . . . . . . . . . o 5. . . . . . . . . . . . . .1. . . . . . . . . . . . ıa 7. . . . .3. . . . . . . . . . . . . . . . . .2. . . . . .2. . . Herramientas . . Conclusiones . . . . . . 5. . . . . . . . . . . . . . . . . .7.1. . . . . . . o 6.5. . . . . . o 5. . . . . . . . . . . . . . . . . . Informaci´n sensorial . . . . . o 5. . . . . . . . Blender . Trabajo con OpenGL . . . . . . . . . . . . . . . . . . . . .3. . . . . Conclusiones .7. . . . . Animaci´n . . . . OpenGL . .2. . . . . . . .4. . . . 7. Trabajo con Blender y Python . . . . . . . . . . . o 6. . . . .3. . . . . . . . Nuevo servidor . . . . EmotionMapper . 5. . . . . . . . . . . . . . . . . . . . . . .2. . Vector informaci´n sensorial . 7.2. . . . . . . . . . . . . . . . .3. .1. . . . . . . . . . . . . . . . . . L´ ıneas futuras . . . . . . . . . . . . . . . . .5. . . . . . . . . . . . . A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii 57 58 58 60 61 61 62 66 68 68 72 74 80 85 86 87 87 88 89 90 92 93 93 94 94 95 95 97 5. . . . . . . . . . . . . . . . . 5. . . . . .2. . . . . . . . . . . .2. . .4. . . . . . .2. . . . . Transformaciones emocionales . . . . .2. . . . . . . . . . . . . . . . . o 6. . Mapeo de emociones en Higgs 6. . . . . . . . . . . . . . Animaci´n . . . . . . . . . . . . Visualizaci´n . . . . . . . . . . . o 6. . . . . . . . . . . . . 5. Matriz de emociones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . .1. . . . . . .7. . . . . . . . 6. 5. . . . . . . . 5. . . . . Teor´ sobre las Emociones . . .3. . . . . . . . . . . . . . .3. . . . . . Python . . . . . . .2. . . . . . . . . Ejemplos . . . . . . . . . . . . . . . . Criterios de selecci´n . . . . . . . .

Otras herramientas ´ INDICE GENERAL 99 .viii B.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Servicio de objetos CORBA . . . . . . . . . . . . . . . . . Banco de pruebas . . .1. . . 1. . . . 2. .36 . . .4. . . . 3. . .1. . . . . . Generaci´n. Modelo lineal de Waters . . . . . . . . .2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Expresiones universales de Eckman. Ejemplo de modelado con Blender . . . . . . . M´sculos de la cara . . . . . . . . . . . . . . . 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2. . . o 3. . . . . . . .5. . .3. . Secuencia de contracci´n muscular . . . . . . . . . . . . . . . . . . . . integraci´n y compilaci´n . . . . . . . . . .7. . . o 4. . . . . . Parte de la interfaz del sistema HINT . . . . . . . Herramienta para Qt: Designer . . .2. . o 3. .3. . . . . . . . . . . . . o e 2. . . . Simulador de Aria . .3. . . . . . . . . .2. . . . . . .1. . . . Diagrama de caso de uso . . . . . . . . . . . . . . . . . . . . . . .5. Captura de pantalla de Blender 2. 4. . . . . . . . . . . . . . . o 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clasificaci´n de los m´todos de modelado . 4. . . . 5. . . . . . . . . . . . . . . .1. . . Robot m´vil Pioneer 2-AT8 . . a ix 2 4 11 13 16 17 19 20 21 26 27 28 34 35 47 50 52 53 59 62 63 . . . . . . . . . . . . . . . . o o o 4. 4. . . . Esquema sencillo de la aplicaci´n HiggsFace . . Im´genes auxiliares para el modelado . . 2.3. . . . . . . . . u 2. 4. . . . . Componentes de la arquitectura CORBA . . . . . . . . .4. . . . . . 2. . . . . Actividad muscular coseno . . . . . . . . . . 5. . . . . . . . .6. . . . . . . . . . Estudios de Duchenne . . . . . . . . . . . . . .2. . .´ Indice de figuras 1. . 2. . . . . . . . . . . .6. . . . . . .1. Modelo UML elemental de la aplicaci´n HiggsFace. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . El EmotionMapper como aplicaci´n lineal . . . . . . . . o 64 64 65 65 66 67 71 73 74 75 76 76 84 86 91 . . Ejemplo con OpenGL . . . . . . o u 5. . . . .2.x ´ INDICE DE FIGURAS 5. . . . . Modelado de la cara con pol´ ıgonos . . . u 5.13. 5. . .6. . . o 6. . .5. . .10. . . . . . . . . . Men´ para la iluminaci´n de Blender . . . . . . . . . . u o 5. . . . . . . . . . . . Elementos de la aplicaci´n HiggsFace . . . . . . . . . . . . . . . .1. . OpenGL Rendering Pipeline . . . . . . . . . . . . . . . . . . . Men´ para el renderizado de Blender . . . . . . . . . . .4. .7. . . . . . . . . . 5. . . . . . . . . . .15. . . . . . . . Men´ game engine de Blender . . . . . . . . . . . . . . . . . . . . . Modelado de la cara con l´ ıneas . . . . . . . .16. . o 6. . . . . . 5. . . Escena por defecto de Blender . . . . . . 5. . . . . . . . . . . . . . . . . Modelo de una cara con Blender . . . Aplicaci´n Facial Simulator para Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 5. . . . . . . . . . . . .8. . . . .9. . . . Algunas opciones de Blender . . . . . . . . . . . .14. . . . . 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. . . 5. Esquema sencillo de la aplicaci´n HiggsFace . . . . .12. . . . . . . . . . . . .11. . . . . . . . Distribuci´n de los m´sculos en la cara . . . . . . . . . o 5. . .

1). en la construcci´n de sistemas complejos de control intervienen muo chos factores que determinan la necesidad de emplear arquitecturas software adecuadas. Al mismo tiempo. Motivaci´n o La visualizaci´n de los estados funcionales de los sistemas t´cnicos tiene una gran o e importancia cuando de esta visualizaci´n se deriva la correcta o incorrecta interpretaci´n o o de dicho estado por parte de un ser humano (consideremos. Esta adecuaci´n se mide por el grado en que dichas arquitecturas permitan obtener tanto o caracter´ ısticas funcionales determinadas (como son la satisfaccion de requisitos estrictamente necesarios en el ´mbito del control) como caracter´ a ısticas no funcionales (que son cr´ ıticas a la hora de contruir un sistema software complejo). Este proyecto fin de carrera se sit´a en la confluencia de ambas necesidades —visualizaci´n u o y arquitectura software— tratando de ofrecer una soluci´n general al problema concreto o de la percepci´n por parte de seres humanos no entrenados de estados t´cnicos globales de o e sistemas f´ ısicos. en el ´mbito de la rob´tica interactiva. la necesidad de comprender el estado de nuestro autom´vil cuando lo vamos conduciendo). en el de la filosof´ a ıa ıa de la t´cnica y. Ejemplos e a a o paradigm´ticos son el dise˜o de salpicaderos de autom´viles. o Obviamente en este proyecto no se trata de ofrecer una soluci´n definitiva a todos los o 1 . Hay m´ltiples ejemplos que podemos ofrecer de esta necesidad de comprensi´n y que u o se han estudiado ampliamente en el ´mbito de la psicolog´ industrial.Cap´ ıtulo 1 Introducci´n o 1. o ´ Esta ha sido una de las misiones tradicionales de las interfases de usuario donde no s´lo o la usabilidad del sistema t´cnico sino el desempe˜o global del sistema hombre-m´quina e n a dependen cr´ ıticamente del modelo mental que el ser humano tiene de la m´quina (ver a Figura 1.1. las interfases para operadores a n o de procesos en caso de emergencias o los sistemas dom´ticos. m´s recientemente. por ejemplo.

o a a 1. Las l´ o ıneas maestras son simples y gu´ todo el desarrollo ıan del proyecto: .2. de un vistazo. o problemas de visualizaci´n de estados t´cnicos —tarea posiblemente demasiado ambiciosa o e para un proyecto fin de carrera— sino de proponer una arquitectura de visualizacion concreta que se ofrece como una soluci´n viable a uno de los problemas planteados por la o necesidad de comprensi´n del sistema t´cnico que los interfases hombre-maquina plantean: o e la comunicaci´n efectiva y sin entrenamiento previo a un humano de un estado t´cnico de o e un sistema f´ ısico.. dentro del Departamento de Autom´tica de la ETS de a Ingenieros Industriales de la Universidad Polit´cnica de Madrid. INTRODUCCION Figura 1. En la figura se presenta parte de la interfase del sistema HINT a [Alarc´n et al. Este es un proyecto de investigaci´n en teco nolog´ software para sistemas complejos de control realizado por el Autonomous Systems ıas Laboratory (ASLab) de la UPM.1: Una interfase de usuario dise˜ada para la operaci´n de un sistema t´cnico n o e debe permitir que el humano desarrolle un modelo mental adecuado para el desempe˜o del n sistema hombre-m´quina. Contexto Este trabajo se enmarca dentro del proyecto de investigaci´n a largo plazo CS 2 — o Complex Software-intensive Control Systems. e El objetivo de este proyecto investigador es la definici´n de arquitecturas de control ino tegrado para la construcci´n de sistemas complejos de control y el desarrollo de tecnolog´ o ıas software para su construcci´n. c´mo est´ la m´quina. El objetivo es simple: entender. 1994].2 ´ CAP´ ITULO 1.

Portable: Gracias a basarse en est´ndares internacionales. se ha definido una plataforma software gen´rica de base denominada e Integrated Control Architecture (ICa) [Sanz et al. CONTEXTO Modularidad Seguimiento de est´ndares a Reutilizabilidad Dise˜o basado en patrones n Independencia del dominio 3 En este contexto.. 2001]. 1999a]— se ha venido desarrollando en nuestro departamento durante los ulti´ mos a˜os y. Abierta: Permite la interoperabilidad con sistemas ajenos (tanto heredados como futuros). total y uniforme.1.. por ejemplo permite emplear un unica tecnolog´ en todos los ´ ıa niveles en la verticalidad del sistema de control (desde la decisi´n estrat´gica hasta o e los dispositivos empotrados de campo) as´ como la integraci´n horizontal de unidades ı o de negocio o empresas extendidas. ıa e . La arquitectura ICa es una metaarquitectura software que n ofrece una serie importante de ventajas frente a otros enfoques : Coherente y unificada: La arquitectura ICa proporciona integraci´n. se ha aplicado con ´xito en multiples n e a ´mbitos de control: Control estrat´gico de procesos de fabricacion de cemento [Sanz et al. vertical y horizono tal. lo que permite la n reutilizaci´n modular de componentes y la incorporaci´n de nuevos componentes en o o dominios concretos. 2000].2. Clara: El modelo empleado en ella es un modelo preciso: el modelo de objetos ditribuidos de tiempo real que constituye la base de las plataformas estado del arte en este campo. a Esta arquitectura —o metaarquitectura como debe ser considerada ICa en realidad [Sanz et al. 1999c] que proporciona los criterios de dise˜o software centrales.. e Gesti´n de emergencias en plantas qu´ o ımicas [Sanz et al. 2000].. Flexible y extensible: Permite su adaptaci´n a distintos contextos de ejecucion y diso tintos dominios al realizar un m´ ınimo de compromisos de dise˜o. gracias a diferentes proyectos de I+D. Sistemas de monitorizaci´n distribuida de tiempo real de produccion y distribuci´n o o de energ´ el´ctrica [Clavijo et al..

1999b]. INTRODUCCION Figura 1. 2003]. 2003]. Su despliegue se hace seg´n las necesidades y restricciones de u la aplicacion. La caracter´ ıstica primaria de ICa es su enfoque modular. La clase de arquitecturas se denomina SOUL y el nombre de este m´dulo es SOUL::Face. explotando la reubicabilidad de los componentes (ver Figura 1. En este proyecto fin de carrera se aborda la construcci´n de un m´dulo reutilizable o o espec´ ıfico para una cierta clase de arquitecturas que estamos investigando en la actualidad. o .4 ´ CAP´ ITULO 1. La organizaci´n concreta de los m´dulos viene dada por su arquitectura de o o aplicaci´n. que se deriva de la metaarquitectura por medio del uso de patrones de dise˜o o n [Sanz and Zalewski. Los sistemas se contruyen por medio de m´dulos reutilizables sobre frameworks de sistemas distribuidos de objetos o de tiempo real. o Robots m´viles cooperantes [Sanz et al. o e etc..2: Diagrama de caso de uso para un despliegue de una aplicaci´n de control y o protecci´n de redes. Protecci´n de subestaciones el´ctricas [Sanz. 2002]. o Bucles de control en red [Sanz.2).

4. a Cap´ ıtulo 2 / Comunicacion emocional: Donde se describen las ideas b´sicas del proyeca to centradas en emplear visualizacion de estados t´cnicos mediante caras antropom´rfie o cas correspondientes a estados emocionales humanos.3. un ancho de banda mucho mayor o que los sistemas de alarma tradicionales. .3.5. OBJETIVOS DEL PROYECTO FIN DE CARRERA 5 1. 1. a As´ una refiner´ podr´ “poner cara de susto” para indicar al operador humano la perı. Objetivos del proyecto fin de carrera Los objetivos de este proyecto son muy simples —que no f´ciles de alcanzar— y se a describen sumariamente diciendo que persigue la implementaci´n de un m´dulo reutilizable o o en el contexto de ICa para la visualizaci´n de estados de sistemas t´cnicos basado en o e comunicaci´n emocional mediante caras. Decimos metaf´rico-anal´gico porque el sistema t´cnico no se dise˜a necesariamente o o e n para emular estado mentales humanos (como es el caso de la rob´tica humanoide). As´ que o ı cualquier interpretaci´n del estado t´cnico en t´rminos de emociones humanas es necesariao e e mente metaf´rico. o 1. las caracter´ o ısticas del tipo de interacci´n hombre-m´quina o a ulterior hace que veamos analog´ de comportamiento derivables de la emoci´n que exıas o presan estados intencionales de la m´quina. no podemos o e decir que la refiner´ est´ asustada —en el sentido humano— pero es obvio que el canal de ıa a comunicaci´n facial-emocional proporciona. Sin embargo.1. por parte del sistema t´cnico. de un riego inminente. en este caso. En pocas palabras podemos decir que la idea b´sica que gu´ este proyecto consiste en a ıa implementar un sistema metaf´rico-anal´gico de visualizaci´n de estados de sistemas t´cnio o o e cos mediante la representaci´n tridimensional de caras antropom´rficas correspondientes a o o estados emocionales humanos. Estructura de la memoria Esta memoria de Proyecto Fin de Carrera se estructura en siete cap´ ıtulos y tres ap´ndices: e Cap´ ıtulo 1 / Introducci´n: Este cap´ o ıtulo es en el que se presenta el proyecto y se introducen sus ideas b´sicas. Estrategia La estrategia a seguir para conseguir la correcta interpretaci´n de los estado t´cnicos o e desde un punto de vista estrat´gico se basa en comunicacion emocional. Evidentemente. Esta se detalla en e el Cap´ ıtulo 2 de esta memoria. ıa ıa cepci´n.

o Cap´ ıtulo 5 / Sistemas Gr´ficos: En este cap´ a ıtulo se describen las herramientas gr´fia cas utilizadas para el desarrollo del proyecto as´ como el trabajo realizado con ellas. INTRODUCCION Cap´ ıtulo 3 / Una Cara para Higgs: En este cap´ ıtulo se describe la aplicaci´n espec´ o ıfica para la que se implementa el sistema dise˜ado. .6 ´ CAP´ ITULO 1. o Ap´ndice A / Ejemplos: Donde se recogen im´genes de las expresiones universales de e a Eckman para la cara dise˜ada para Higgs. Cap´ ıtulo 4 / Plataformas software: En esta parte se describen las herramientas software que se utlizan para el desarrollo de la aplicaci´n. o Cap´ ıtulo 7 / Conclusiones y l´ ıneas futuras: En este cap´ ıtulo se recogen por un lado las conclusiones del trabajo realizado en este proyecto fin de carrera as´ como las ı l´ ıneas de trabajo que quedan abiertas tras la finalizaci´n del mismo. ı Cap´ ıtulo 6 / Mapeo de emociones en Higgs: Donde se describe el m´todo con el que e se obtiene la informaci´n sensorial de Higgs y c´mo se traduce a estados emocionales o o que se visualizan en una cara antropom´rfica. Higgs es un robot m´vil de Pioneer n o cuyo estado se pretende expresar mediante emociones. Ap´ndice C / Otras herramientas: Donde se recogen otras herramientas software utie lizadas para el desarrollo de este proyecto. n Ap´ndice B / Experimentos: Donde se recogen im´genes tomadas durante el desare a rollo del proyecto a modo de experimento.

La ultima parte.Cap´ ıtulo 2 Comunicaci´n y emoci´n o o En este cap´ ıtulo se recogen unas ideas b´sicas acerca de la comunicaci´n y las emoa o ciones. ı o En la Secci´n 2. de un vistazo. o La Secci´n 2. El objetivo de este proyecto es crear una interfaz de usuario de forma que. o En la Secci´n 2.3 se trata el tema de la comunicaci´n facial mediante expresiones.7).2 describe la importancia de las emociones en la toma de decisiones. De o como raz´n y emoci´n son dos t´rminos ´ o o e ıntimamente relacionados cuando se habla de temas de inteligencia. Se o o describe la existencia de una serie de expresiones universales (reconocidas por cualquier persona en cualquier parte del mundo) as´ como la descripci´n muscular de las mismas. En la Secci´n 2. Con las ideas que aqui se recogen se justifica la elecci´n de la comunicaci´n emocional mediante caras o o antropom´rficas.1 se describe la utilizaci´n de las im´genes como medio de comunicaci´n o o a o de informaci´n.5 describe el modelo muscular para la animaci´n facial dise˜ado por Keith o o n Waters. (Secci´n 2. recoge una serie de ideas acerca del tema tratado en este ´ o cap´ ıtulo que se utilizan como base para el desarrollo del proyecto objeto de esta memoria. La Secci´n 2. 7 .4 describe los modelos que existen para la generaci´n y animaci´n de o o o caras de forma realista. se sepa c´mo est´ el sistema f´ o a ısico en un determinado momento.

con el prop´sito de reducir o la entrop´ cognitiva. basadas en otras modalidades sensoriales o incluso basadas en comunicaci´n o directa —intrusiva y no intrusiva— con el cerebro 1 . por problemas m´dicos. permite la creaci´n de amplios sistemas comunicativos. COMUNICACION Y EMOCION 2. ambiental n o o o y digital.1. interiorizar e interpretar la informaci´n sobre el estado del sistema —el estado o mental de la m´quina. Hay mucho trabajo realizado en el desarrollo de sistemas de visualizacion en ambientes t´cnicos (ver por ejemplo. Consiste en la creaci´n de im´genes est´ticas y funcionales con fines netamente o a e comunicacionales. Hay otras. circulan y funcionan en la sociedad. o El dise˜o visual crea estructuras de comunicaci´n e informaci´n visual. teniendo en cuenta los procesos perceptivos. en cierta medida. aunque dada la importancia de la percepo a ci´n visual para los seres humanos —somos animales visuales— no es de extra˜ar que la o n 1 visualizaci´n sea la forma de comunicaci´n preferida . 1998]). la eficacia comunicativa de estos datos. podr´ a ıamos decir— de una manera mas din´mica y activa. sin embargo. el dise˜o visual define los m´todos para verificar. El dise˜o a n visual. basados en la ergonom´ que o ıa permitan al usuario una relaci´n m´s natural con dicha informaci´n. n o con el objeto de convertir los datos en formas visuales. que permitan e o entender. soportado por n o o elementos estructurales del dise˜o y formales de los modelos de informaci´n y comunicaci´n n o o (emocional en nuestro caso). Sin embargo.8 ´ ´ CAP´ ITULO 2. Interacci´n y dise˜ o visual o n El dise˜o visual es una disciplina profesional que estudia los sistemas de informaci´n. a partir de las estructuras de los lenguajes que operan. se pierde la capacidad de generar e expresiones faciales (por ejemplo en el s´ ındrome de M¨ebius [Cole. ıa Los sistemas de comunicaci´n con sistemas t´cnicos emplean m´ltiples tecnolog´ de o e u ıas. As´ mismo. La importancia de este mecanismo de comunio cacion queda manifiesta cuando. todo el trabajo realizado en construccion de interfases de usuario e para operadores de proceso) pero. En nuestro caso este lenguaje es el lenguaje de la comunicaci´n emocional o entre humanos mediante la expresi´n facial. con el objeto de entender la interactividad de los dispositivos y los datos con el observador. en la actualidad se o o entiende que muchos sistemas t´cnicos requieren de una nueva vizualizaci´n. las cuales la visualizaci´n no es sino una m´s. m´vil. la visualizacion que aqu´ se investiga ı se aleja de estas l´ ıneas y entra m´s de lleno en la explotaci´n de la conexi´n visual entre a o o humanos. Es en relaci´n con la o a o o ergonom´ y con la eficacia donde la comunicaci´n usando expresiones faciales encuentra ıa o su lugar. ı n e de forma experimental. El dise˜o visual estudia la generaci´n y producci´n de la imagen fija.

facilitando as´ el descubrimiento de lo que realmente ı ocurre y permitiendo elaborar. el plan de acci´n m´s adecuado o a . lo cual nos proporciona m´s informaci´n sobre a a o el acontecimiento inesperado. ıa o n predispone al cuerpo a un tipo diferente de respuesta [Goleman. cualquier concepci´n de la naturaleza o humana que deje de lado el poder de las emociones comete un error. en esencia. Estrat´gicas porque estos bucles de control se sit´an en los niveles m´s altos de la e u a jerarqu´ de controladores que nos mantiene vivos. como se˜al de control. en consecuencia.2. para calibrar. una sensaci´n de tranquilidad que hace que o a o el cuerpo se recupere m´s r´pidamente de la excitaci´n biol´gica provocada por las a a o o emociones perturbadoras la sorpresa: el arqueo de las cejas hace que aumente el campo visual y permite que penetre m´s luz en la retina.2. En cierto modo. Al mismo tiempo. Todos sabemos por experiencia propia que nuestras decisiones y nuestras acciones dependen tanto. n Desde nuestro punto de vista. 1996]: el enfado: aumenta el flujo sangu´ ıneo de las manos. las emociones o a o son se˜ales empleadas en los controladores complejos que nos mantienen en funcionamiento. tal vez. si el hecho de ocultarse pudiera o ser una respuesta m´s adecuada. mientras la atenci´n se fija en la amenaza inmediata con el fin de evaluar la o o respuesta m´s apropiada a la alegr´ aumento en la actividad de un centro cerebral que se encarga de inhibir ıa: los sentimientos negativos y de disminuir los estados que generan preocupaci´n. tambi´n aumenta el ritmo card´ e ıaco y la tasa de hormonas que. programas de reacci´n autom´tica con los que nos ha dotado la evoluci´n. haciendo m´s f´cil empu˜ar a a n un arma o golpear a un enemigo. sumi´ndolo en la inquietud y predisponi´ndolo para la e e acci´n. como la adrenalina. a Todas las emociones son. Inteligencia emocional A pesar de las connotaciones negativas que en la actualidad tiene la palabra “sentimental” cuando forma parte del comportamiento. de nuestros sentimientos como de nuestros pensamientos. por e ejemplo) favoreciendo as´ la huida. el cuerpo parece paralizarse. al o mismo tiempo que aumenta el caudal de energ´ disponible. En este caso no hay ıa cambio fisiol´gico especial salvo. quiz´s. INTELIGENCIA EMOCIONAL 9 2. impulsos que nos llevan a actuar. y a veces m´s. n e e Sint´ticas porque no responden a una magnitud concreta medida mediante cierto sensor e sino que son producidas —calculadas— por el sistema de evaluaci´n de nuestro control m´s o a global. Cada emoci´n. las emociones son se˜ales sint´ticas de control estrat´gico. permitern generar la cantidad de energ´ necesaria ıa para acometer acciones vigorosas el miedo: la sangre se retira del rostro (lo que explica la palidez y la sensaci´n de o “quedarse fr´ ıo”) y fluye a la musculatura esquel´tica larga (como las piernas.2. ı aunque s´lo sea un instante. Las conexiones nerviosas de los centros emocionales a del cerebro desencadenan tambi´n una respuesta hormonal que pone al cuerpo en e un estado de alerta general.

constituyen una parte importante de la generacion de comportamiento al m´s alto nivel y se imbrica. si comprendemos mejor estas influencias y podemos aplicar las positivas al dise˜o de los mecanismos de visualizaci´n e interacci´n. COMUNICACION Y EMOCION el desagrado: tiene un gesto que transmite el mensaje de que algo resulta literal o metaf´ricamente repulsivo para el gusto o para el olfato. sopesar sus consecuencias y planificar. La idea de que las m´quinas puedan tener un d´ emociones es un tema recurrente a ıa en ciencia-ficci´n. “Blade Runner” o “El hombre biceno terario” son algunos de los ejemplos que podr´ ıamos se˜alar. un nuevo comienzo ıa Estas predisposiciones biol´gicas a la acci´n son moldeadas posteriormente por nuestras o o experiencias vitales y por el medio cultural en el que nos ha tocado vivir. 1978] reflexiona lo siguiente: “la cuesti´n no es si las m´quinas inteligentes pueden tener emociones sino si las m´quinas o a a pueden ser inteligentes sin emociones”. la n o o gente se sentir´ mejor al trabajar con ordenadores. a a . m´s se ralentiza el metabolismo a o a corporal. 1998] sugiere que los ordenadores influyen en las emociones humanas de forma tanto positiva como negativa. cuanto m´s se profundiza y se acerca a la depresi´n. La mente racional y la mente emocional son consideradas como dos facultades relativamente independientes que reflejan el funcionamiento de dos circuitos cerebrales distintos aunque interrelacionados. “2001: Una odisea del espacio”. Y e como los estados de ´nimo persisten y se contagian. Rosalind Picard [Picard. La tristeza provoca una disminuci´n de energ´ y n o ıa del entusiasmo por las actividades vitales (especialmente las diversiones y placeres) y. Estar de buen humor tiene un impacto a positivo en muchos aspectos de la creatividad y aumenta las posibilidades de ´xito. Este encierro introspectivo nos brinda as´ la oportunidad de llorar una ı p´rdida o una esperanza frustrada. Pueden motivarnos y animarnos a conseguir ciertas cosas. En la actualidad existe una n gran diferencia entre ciencia-ficci´n y ciencia. los subsistemas de control emocional. En el mundo real las emociones de los dem´s influyen en nuestras o a decisiones y nuestro estado emocional. en las estrategias m´s globales del agente inteligente. Marvin Minsky en “The Society of Mind” [Minsky.10 ´ ´ CAP´ ITULO 2. Desde nuestra perspeciva. cuando la e energ´ retorna. por tanto. La expresi´n facial de o o disgusto (ladeando el labio superior y frunciendo ligeramente la nariz) sugiere un intento primordial de cerrar las fosas nasales para evitar un olor nauseabundo o para expulsar un alimento t´xico o la tristeza: consiste en ayudarnos a superar una p´rdida irreparable (como la muerte e de un ser querido o un desenga˜o). pero muchos investigadores de inteligencia o artificial consideran que es cuesti´n de tiempo superarla y hablan de la importancia de o crear ordenadores emocionales. Las emociones se usan para enfatizar o ayudar a alcanzar una meta como actos intencionales de comunicaci´n. los buenos sentimientos siguen cuando a dejemos de trabajar con el ordenador.

1872] que fue publicado 10 a˜os antes del m´s famoso “The origin of the n a species”. El primero en demostrar la universalidad de las expresiones y su continuidad en hombres y animales fue Charles Darwin en 1872 en “The expression of emotions in man and animals”[Darwin.1). Desarrollaron el Facial Action Coding System (FACS) [Ekman and Friesen. las expresiones faciales y los gestos o posio ciones del cuerpo. el canal m´s importante de a a comunicaci´n no verbal. 1862]. De este modo pudo clasificar los m´sculos en expresivos. Dividieron las expresiones en acciones de peque˜os grupos de n m´sculos que denominaron Action Units (AU). A pesar de que existen discrepancias entre su clasificaci´n y la originada o por los descubrimientos recientes.3.1: Estudios de Duchenne El pionero del estudio anal´ ıtico de la expresi´n de la cara humana fue Duchenne.2. mas del 65 % de la informaci´n transmitida cara a cara forma parte de la banda no o verbal. es una buena interfaz para comunicar porque las personas tienen o capacidad de reconocer expresiones e inferir de ellas estados emocionales. centrada en el estudio de los movimientos de los distintos m´sculos de la cara utilizando electrodos en puntos de la superficie del rostro (ver Figura u 2. 2 . inexpresivos o discordanteu mente expresivos. Corri´ a cargo o a o de Paul Eckman y Wallace Friesen. pero o no fue hasta los 70 que no se llev´ a cabo un estudio m´s riguroso y preciso. Expresiones faciales La cara es la parte m´s expresiva del cuerpo humano2 . u Durante cinco a˜os Eckman viaj´ alrededor del mundo para comprobar cient´ n o ıficamente si los gestos y las expresiones difieren con la cultura. ´l fue el que defini´ esencialmente el campo. La investigaci´n m´s importante sobre expresiones faciales fue desarrollada en 1862 o a por Duchenne[Duchenne. 1978] que permit´ medir con rigor cient´ ıa ıfico todos los movimientos musculares de la cara. EXPRESIONES FACIALES 11 2.3. siguiendo las teor´ de antrop´logos ıas o La comunicaci´n entre personas se produce mediante voz. e o Figura 2.

Tambi´n comprob´ que cada cultura tiene sus propias normas e o que definen la forma socialmente aceptable de mostrar las emociones. esto es. Ense˜´ retratos a personas o ıa no de cinco pa´ ıses diferentes para que identificasen la emoci´n de cada imagen y las intero pretaciones coincidieron. . sonrisa t´ o ımida. 1975]. o 2. u Sus investigaciones concluyen que hay seis categor´ que pueden considerarse como ıas universales. risa. falsa sonrisa y falsa risa. hoyuelos y un profundo pliegue nasolabial desde la nariz a la barbilla. a e Alegr´ en la expresi´n pura de alegr´ las cejas est´n relajadas. sonrisa con la boca ıa abierta. En la expresi´n de alegr´ a o ıa se forman patas de gallo en los extremos de los ojos. e a somnolencia. Utiliz´ la fotograf´ como soporte para sus investigaciones. Debemos a Gary Faigin [Faigin. enfado. sorpresa. sonrisa melanc´lica.2). Nueva Guinea.12 ´ ´ CAP´ ITULO 2. Los a a a labios son finos y est´n fuertemente presionados contra el hueso. Si estaban solos tanto unos como otros mov´ los mismos ıan m´sculos de la cara mientras que en presencia de un investigador los japoneses tend´ a u ıan enmascarar m´s las emociones de desagrado con una sonrisa.3. un pliegue en forma de sonrisa bajo el p´rpado inferior. ıas ıa. miedo y desagrado. . reconocibles por cualquier persona de cualquier tipo y condici´n en o cualquier parte del mundo. 1990] la consideraci´n de que hay expresiones no relao cionadas con emociones que tambi´n est´n universalmente reconocidas: dolor. Las regiones m´s expresivas de la cara son los ojos. Seg´n esta l´ e u ınea de pensamiento. sonrisa con los ojos cerrados. COMUNICACION Y EMOCION destacados en aquella ´poca. las cejas y la boca. Para confirmar los resultados a obtenidos fu´ a cotejarlos a una cultura alejada de la civilizaci´n y convivi´ dos a˜os con e o o n el pueblo fore en Pap´a. as´ como por o ı .1. sonrisa de agradecimiento. El p´rpado superior ıa: o ıa a a est´ ligeramente bajado y el p´rpado inferior est´ recto. sonrisa perversa. es posible hacer an´lisis y representaciones gen´ricas de estas emociones (ver Figura 2. y ´stos var´ en funci´n e e ıan o de la cultura. 1872] hab´ dicho o ıa exactamente lo contrario: las expresiones humanas eran innatas y por tanto universales a todas las especies. esfuerzo. Estas categor´ son: alegr´ tristeza. Lo hizo mediante un experimento que consist´ en mostrar pel´ ıa ıculas con escenas quir´rgicas y accidentes a u japoneses y estadounidenses. Cada una de estas ellas tienen un amplio rango de expresiones con distinta intensidad y variaciones en los detalles de las mismas. a Algunas variaciones de la alegr´ pueden ser risa desternillante. siendo elevado por la mejilla. Pero el investigador record´ que Charles Darwin [Darwin. Por eso son las a zonas en las que se centra la descripci´n de las expresiones universales que se recoge en la o siguiente secci´n. Descripci´n de las expresiones universales o Dada la universalidad descubierta por Ekman [Ekman and Friesen. los seres humanos aprendemos los gestos y las expresiones a trav´s del contacto social. sonrisa ansiosa. Las risas y sonrisas falsas se caracterizan por una disminuci´n en las patas de gallo de los ojos.

2. Enfado: en la expresi´n pura de enfado. La boca est´ cerrada con el labio superior ligeramente comprimido. Alegr´ ıa Tristeza Enfado Miedo Sorpresa Desagrado Figura 2. lloro con la boca cerrada. pliegues oblicuos sobre el p´rpado superior y un pliegue a en forma de sonrisa bajo el labio inferior.2: Expresiones universales de Eckman. pero la presi´n de la frente impide que se vea el blanco del a o ojo por encima del iris. La boca a e a est´ relajada. a l´ ıneas verticales entre las cejas. o a 13 Tristeza: en la expresi´n pura de tristeza. n . ense˜ando los dientes superiores e inferiores. casi lloro e infelicidad. los extremos de las cejas se empujan hacia o abajo y se juntan. Las variaciones posibles del enfado son: rabia y tensi´n. o Dichas variaciones pueden implicar labios ligeramente presionados con protuberancia en la barbilla o un boca totalmente abierta con una mueca del labio superior con el labio inferior recto. una protuberancia en la barbilla y un pliegue nasolabial muy pronunciado. tristeza reprimida. El ojo est´ medio abierto. La piel y los tejidos blandos debajo de la ceja se agolpan sobre el p´rpado superior. El extremo inferior de la ceja se pone al mismo nivel que el p´rpado a elevado.3. La tristeza puede tener muchas variaciones y diferentes intensidades: lloro con la boca abierta. Estas variaciones pueden conllevar cejas completamente bajadas. a Los ojos se cierran ligeramente a consecuencia de la presi´n hacia abajo de los tejidos o sobre el p´rpado y tambi´n por el movimiento hacia arriba del p´rpado inferior. ojos fuertemente cerrados. a Las arrugas en el enfado incluyen pliegues horizontales sobre los p´rpados superiores y a l´ ıneas verticales entre las cejas. EXPRESIONES FACIALES ausencia o s´lo ligeros pliegues debajo del p´rpado inferior. Las arrugas asociadas a la tristeza incluyen pliegues horizontales en la frente. la zona interior de las cejas se curva hacia o arriba.

En la a preocupaci´n los labios se fruncen fuertemente y los bordes de los labios desaparecen. El labio inferior se relaja.2. Cuando los m´sculos est´n relajados. El labio inferior se eleva ligeramente. tanto la boca como los ojos est´n totalmente abiertos. El pliegue nasolabial e es m´s profundo a lo largo de la nariz. hoyuelos sobre las cejas y pliegues oblicuos sobre los p´rpados superiores. Las cejas se relajan y los p´rpados est´n relajados o tan s´lo ligeramente cerrados. Hay l´ ıneas verticales entre los arcos superciliares. especialmente en los extremos interiores. a Los m´sculos para la expresi´n facial trabajan sin´rgicamente y no de forma independiu o e ente.3. Las arrugas asociadas pueden incluir pliegues horizontales en la frente. a menudo asim´trica. Se o abulta la parte por debajo del labio inferior y sobre la barbilla. En el terror. ı 2. Los p´rpaa dos superiores se abren lo m´ximo posible con los inferiores relajados. patas de gallo y por debajo del p´rpado inferior. a La boca puede estar ligeramente abierta y ca´ ıda. e Sorpresa: en la sorpresa. u u o Algunos de estos m´sculos pueden tambi´n desempe˜ar otras funciones importantes. El pliegue nasolabial se vuelve recto y poco profundo. Los ojos pueden estar casi cerrados. En el desde˜o. Las cejas se elevan o y se juntan.14 ´ ´ CAP´ ITULO 2. El labio superior se a a o eleva en una mueca. o Desagrado: el desagrado puede variar desde el desde˜o al rechazo f´ n ısico. La boca se abre a totalmente formando un ´valo. n El labio superior se eleva en una mueca intensa que permite ver los dientes superiores. a o u a el tejido graso rellena los hoyos existentes para dar al cr´neo una forma suave. tales u e n como el movimiento de mejillas y los labios durante el habla. COMUNICACION Y EMOCION Miedo: el miedo puede variar desde la preocupaci´n al terror. Los m´sculos de expresi´n u o facial son superficiales (situados en el exterior del cr´neo) y est´n unidos a una capa de a a grasa subcut´nea y piel en los puntos de inserci´n. Los m´sculos interaccionan unos con otros. es dif´ disu ıcil tinguir fronteras claras entre ellos. las cejas se elevan rectas tanto como es posible. La parte inferior de las cejas se curva hacia arriba. las cejas se bajan. El labio superior se relaja mientras que el inferior a se estira hasta mostrar los dientes inferiores. l´ ıneas verticales entre los ojos. teniendo cada miembro un funci´n espec´ o ıfica. En el rechazo f´ ısico. estando estirada en ambos lados. en un gui˜o. Por tanto. Tambi´n aparecen arrugas desde el lagrimal a e hacia el puente de la nariz as´ como una protuberancia en la barbilla. los p´rpados pueden estar parciala n a mente cerrado con los ojos mirando hacia abajo. e . M´ sculos de la cara u Los m´sculos en la cara se conocen habitualmente como los m´sculos de expresi´n facial. Los ojos est´n alerta. Pliegues en forma de par´ntesis aparecen a los lados del labio inferior. Se forman pliegues horizontales en la frente. Los m´sculos principales de expresi´n facial y sus efectos en la cara cuando se contraen u o son los siguientes3 : 3 Entre par´ntesis los nombres correspondientes a la literatura inglesa. El conjunto trabaja como un equipo coordinado y organizado. En el caso de la animaci´n facial s´lo los m´sculos o o u principales de cada grupos se modelan.

3. La parte inferior del surco nasolabial se profundiza cuando se estira hacia arriba y hacia fuera Depresor del ´ngulo de la boca (Angular Depressor): tira de la comisura de la a boca inferolateralmente. Profundiza la parte inferior del surco nasolabial y lo empuja hacia abajo Elevador del ´ngulo de la boca (Labii Nasi): eleva la comisura y el labio supea rior. o El objetivo de las caras tridimensionales es doble: que parezcan reales y que se muevan de forma real. Animaci´n facial o Desde el trabajo de Parke [Parke.4.´ 2. ANIMACION FACIAL 15 Cigom´tico mayor (Zygomatic Major): desplaza la comisura de los labios supera olateralmente. Los m´sculos constituyen los organos a u u . empujando la parte interior de la mejilla hacia el ojo Elevador del labio superior y del ala de la nariz (Inner Labii Nasi): atrae en direcci´n superior el ala de la nariz y el labio superior. Para lo cual es necesario fijarse en la anatom´ y geometr´ del rostro. o 2. pionero en los temas de animaci´n facial. ıa ıa ´ Este est´ formado por m´sculos y huesos cubiertos de piel.4. o muchos investigadores han intentado generar un modelado y animaci´n de rostros de forma o realista. Pero debido a la complejidad de la anatom´ facial as´ como a la sensibilidad natural ıa ı a la apariencia de los rostros. Los m´s ambiciosos han intentado que el modelado y renderizado se haga en tiempo a real. 1972]. en la actualidad no existen sistemas ampliamente aceptados que generen las expresiones y emociones de forma realista y en tiempo real para un avatar (entendemos por avatar a toda representaci´n digital de un personaje). Los huesos proporcionan el a u marco est´tico en el cual se anclan los m´sculos. Se eleva y profundiza el o surco nasolabial Frontal interior (Frontalis inner): la parte media del m´sculo frontal eleva la u parte interior de las cejas Frontal exterior (Frontalis outer): la parte lateral del m´sculo frontal eleva la u parte exterior de las cejas Frontal (Frontalis major): eleva las cejas de forma que el arco formado es m´s a prominente Corrugador lateral (Lateral Corrugator): tira de la parte interna de las cejas Corrugador de la ceja o superciliar (Corrugator Supercilli): junta las cejas Su disposici´n puede verse en la Figura 2.

. barba . Los m´sculos tambi´n interu e accionan unos con otros. Un esquema de los m´sculos de la cara puede verse en la u Figura 2. Existen tres tipos de musculos en la cara: lineales/ paralelos. Ambas estan ´ e o ıntimamente relacionadas: la estructura del modelo determina su potencial animaci´n. COMUNICACION Y EMOCION del movimiento y generan la expresion moviendo la piel. se ama al h´roe. . 1996]. pesta˜as. . Para el caso de la animaci´n de caracteres sint´ticos a o e podemos utilizar modelos que aproximen s´lo algunos aspectos de la anatom´ de la cara. o ıa Al realizar el modelo facial podemos considerar que tenemos dos partes: la descripci´n o geom´trica y las posibilidades de animaci´n. el´ ıpticos/circulares y planos. Figura 2. los dientes. . Dependiendo de la aplicaci´n que se est´ desarrollando se o e necesitar´ un grado de detalle u otro.16 ´ ´ CAP´ ITULO 2. aunque eso depende de la complejidad del modelo (son muy dif´ e ıciles de modelar). se r´ a e ıe con el c´mico . Puede que sea conveniente crear o caracteres emp´ticos dependiendo del contexto (se odia al villano. La utilizaci´n de ojos detallados y din´micos es muy importantes a la hora o a . no hay modelos que la representen y simulen en todos sus aspectos. Las caras en realidad son superficies muy complejas. las enc´ y la lengua). el pelo de la cara (cejas. ). ) o Los detalles de la cara son muy importantes para obtener resultados reales (los ojos. Puede que n ıas tambi´n las orejas.3: M´sculos que intervienen en la generaci´n de la expresi´n superficial de la cara u o o [Waters and Parke.3.

4. o e o Animación del pelo Animación/ modelado facial Construcción de modelo individual Manipulación de la imagen Antropometría Manipulación de la Geometría Interpolación Parametrización Morphing de imagen Expresiones vasculares Interpolación bilineal Modelo físico de músculos Modelo de elementos finitos Pseudomodelo de músculos Manipulación de texturas y blending Adquisición y ajuste del modelo Modelo de mallas Modelo basado en vectores Modelo de splines Deformación libre de formas Generación de arrugas Interpolación de datos dispersos Proyección en coordenadas cilíndricas y esféricas Figura 2. etc. la parte de atr´s n a de la cabeza y el cuello.´ 2. pelo.4: Clasificaci´n de los m´todos de modelado o e . manipulaci´n de texturas. modelado basado en los movimientos de los m´sculos. es necesario a˜adir cara. Para el modelado y la animaci´n facial existen distintas t´cnicas que se dividen en dos o e categor´ ıas: manipulaci´n de la geometr´ (keyframes.4 recoge una clasificaci´n de los m´todos de modelado y animaci´n facial. orejas. m´todos o ıa o e de elementos finitos.) u manipulaci´n de las im´genes (morphing. mientras que los detalles en la o n o coloraci´n del iris y las reflecciones en el globo ocular a˜aden vida a la cara). etc. interpolaci´n. Las orejas y el pelo le dan distinto aire a los personajes que se generen. La cara ha o n de verse como parte de la cabeza. ANIMACION FACIAL 17 de tener ´xito en la expresividad de la animaci´n (el movimiento de los ojos y los cambios e o de dilataci´n de la pupila a˜aden realismo a la animaci´n.) o a o La figura 2. parametrizaciones.

el menos costoso computacionalmente y el que proporciona resultados aceptables. el a u u m´sculo circular y el m´sculo plano. intenta mover los elementos anexos conjuntamente. Los m´sculos se comu u portan como muelles ajustables de forma que las fuerzas que generan son funci´n de la o longitud y la estimulaci´n neuronal. modelando los m´sculos enteros como entidades b´sicas. Cuando un u m´sculo se contrae. Los m´sculos est´n formados por multitud de fibras larga llamadas miofibras en un u a dise˜o repetido.1. En estos m´sculos.18 ´ ´ CAP´ ITULO 2. COMUNICACION Y EMOCION 2. la piel circundante se a u u . Cuando se trata u de m´sculos faciales. Mec´nica muscular a Los m´sculos representan el motor principal de las expresiones faciales. se utiliza una funci´n de deformaci´n geom´trica. una soluci´n es la de ignorar la microestructura de las fibras u o musculares.2. La a u o o magnitud es cero en el punto de uni´n y se incrementa hasta el m´ximo en el otro extremo o a de inserci´n en la piel. La u o direcci´n es hacia el punto de uni´n con el hueso.5.5. Lo que se pierde con este modelo de deformaci´n simplificado es la alteraci´n de la o o geometr´ del m´sculo que se traducir´ necesariamente en alteraciones de la posici´n de ıa u ıa o la piel que no ser´n adecuadamente modeladas. Modelo de Waters Esta secci´n contiene la descripci´n del modelo desarrollado por Waters [Waters. Cuando estas miofibras individuales se contraen. Este o o o e procedimiento es con diferencia.5. u u Los m´sculos lineales son fibras largas y paralelas. 1987] o o para la animaci´n facial. ejercen en conjunto una n fuerza a lo largo de dos extremos forzando al m´sculo a encojerse. o Hay tres tipos b´sicos de m´sculos faciales que pueden modelarse: el m´sculo lineal. permite modelar un m´sculo como un vector en el espacio o ´ u 3D. esta acci´n consiste en mover la piel hacia el punto de uni´n con el u o o hueso. o Para modelar los m´sculos. a 2. Para mimetizar el u a efecto de la contracci´n muscular. Vectores de m´ sculos u El considerar los m´sculos faciales como entidades individuales con puntos defnidos u de uni´n y direcciones unicas. o 2. La magnitud del desplazamiento depende o o de la constante el´stica del m´sculo y la tensi´n creada por la contracci´n muscular. como por ejemplo el m´sculo u u cigom´tico mayor (o m´sculo de la risa). el m´sculo tiene propiedades vectoriales de direcci´n y magnitud. En este caso.

Figura 2. Los m´sculos circulares est´n formados por fibras en forma de anillo. Se supone que no existe desplazamiento o u en el punto de inserci´n en el hueso y que la m´xima deformaci´n tiene lugar en el punto o a o de inserci´n en la piel. el modelo del m´sculo lineal es el u u m´s importante de los tres.5. cuyo objetivo u a es cerrar orificios faciales tales como la boca o los ojos. a u El comportamiento y efecto de los m´sculos circulares tambi´n puede modelarse como varu e ios musc´los lineales orientados radialmente. a 2. a cierta distancia. De hecho. MODELO DE WATERS 19 contrae hacia el nodo est´tico de uni´n con el hueso hasta que. tal como el nodo p en la Figura 2. El modelado de los m´ sculos lineales u Waters describe el modelo de m´sculo lineal como sigue: para el m´sculo lineal es u u importante computar como el tejido adyacente. Los m´sculos planos son ´reas grandes y planas de fibras que no surgen de un punto u a origen concreto.2. Como consecuencia. siendo por tanto posible modelarlo como varios m´sculos lineales.3. Por tanto. el m´sculo plano es un conjunto de entidades musculares paralelas disu tribuidas sobre un ´rea. En estos m´sculos. Por tanto.5 se ve afectado por la contracci´n del vector del m´sculo. la a o fuerza disminuye a cero. una disipaci´n de la fuerza se pasa al tejido o o adyacente.5. se contraen hacia un nodo localizado en vez de a un grupo de nodos separados. a lo largo de ambos sectores en el diagrama.5: Modelo lineal de Waters y su zona de influencia . la piel se u contrae hacia un centro imaginario de forma uniforme.

5. r un par´metro a a de desplazamiento radial y k un constante fija que representa la elasticidad de la piel. Figura 2. el desplazamiento de la piel parecer´ moo u a verse a lo largo del eje principal del m´sculo hacia el origen del vector como se muestra en u la Figura 2. es obvio que la elasticidad de la piel var´ con la edad y de persona ıa . D es ||v1 -p||.v2 ) y (v1 . 5 y 10. De izquiero da a derecha con factores de 3. A´n cuando esta aproximaci´n produce o a u o resultados aceptables.4. o o a gular: a = cos(a2) donde a2 es el ´ngulo entre los vectores (v1 . p dentro de v1 pn pm p1 r= .p).6. se utiliza la siguiente expresi´n: o p = p + akr pv1 ||pv1 || Aqu´ la nueva localizaci´n p’ es una funci´n de un par´metro de desplazamiento anı.6: Secuencia progresiva de contracci´n muscular en una malla de 20x20.20 ´ ´ CAP´ ITULO 2. 2. Propiedades el´sticas a El modelo de los m´sculos lineales utiliza una funci´n coseno como primera aproxu o imaci´n a las propiedades el´sticas de la piel. p dentro de pn pr ps pm Variando el factor de contracci´n del m´sculo. COMUNICACION Y EMOCION Para calcular el desplazamiento de un nodo arbitrario p situado en la malla un nuevo desplazamiento p’ dentro del segmento v1 pr ps hacia v1 a lo largo del vector p.v1 .  cos        cos  1−D Rs D − Rs R1 − Rs .

simular la menor elasticidad de la piel seg´n envejece. e Algunas de las aplicaciones de esta tecnolog´ tanto desde el punto de vista industrial ıa. son: o Animaci´n: la revoluci´n de los gr´ficos 3D para la industria de animaci´n ha proo o a o ducido un nuevo g´nero de pel´ e ıculas con t´ ıtulos como “Toy Story” o “Final Fantasy”. as´ como la apertura de nuevas ´reas para investigaci´n. la disponibilidad de tarjetas gr´ficas que a poseen procesadores 3D especializados ha convertido este tipo de animaci´n en una realidad o incluso para el p´blico general.6. como de la investigaci´n.7: Actividad muscular coseno elevado a las potencias 0. m´s all´ de la representaci´n fiable de personajes 3D. Aplicaciones El crecimiento exponencial en la capacidad de computaci´n en los ultimos a˜os ha o ´ n llegado a tal nivel que la complejidad de las matem´ticas empleadas en el tratamiento de a gr´ficos tridimensionales puede resolverse en periodos suficientemente cortos como para a producir animaciones 3D realistas.2. Esta t´cnica pero e mite una aproximaci´n m´s flexible al modelado de los vectores de los m´sculos primarios. Esto trae consigo la aparici´n de nuevas industrias para u o satisfacer esta necesidad. o 2. es posible variar la elasticidad de la malla y por tanto. Cambiando la funci´n coseno por una interpolaci´n no lineal o una funci´n poo o o tencial. o a u Figura 2. que est´n a´n en desarrollo (aunque existen algunos productos internos explotados a u por empresas de animaci´n y algunos productos comerciales en el ´mbito de produccion o a de imagen sint´tica). No obstante. no sucede a a los mismo con los m´todos y t´cnicas para el modelado y la animaci´n realista de personajes e e o 3D. APLICACIONES 21 a persona. u Una funci´n potencial incrementa las disminuci´n a cero en los bordes de los vectores o o musculares Figura 2. 20 y 50 (de izquierda a derecha) con una contracci´n muscular de 2.6. Asimismo.0. ı a o Aunque el hardware existente para mostrar gr´ficos de calidad est´ disponible. lo importante en a a o .7 muestra la funci´n coseno elevada a la potencia x.

Por el contrario. La animaci´n por parametrizaci´n requerir´ un conjunto unico de foro o ıa ´ mas (morph) objetivos para cada personaje. lo que no es siempre habitual. o en m´sculo permitir´ utilizar los mismos datos de expresiones para un gran n´mero u ıa u de agentes. que utilizan a personajes o agentes. La idea es que dichos agentes interaccionen con el usuario. se necesitan algoritmos de compresi´n. Unos pocos par´metros se transmiten al decodificador donde la cara humana a se reconstruye. es decir. la animaci´n de caras humanas con anatom´ perfecta (p. Toy Story) que poseen un n´mero limitado de expresiones faciales. en los juegos la expresi´n facial s´lo es distinguible cuando o o o ocupa la mayor parte de la imagen. Aqu´ las expresiones faciales juegan un gran papel. La animaci´n basada ı.ej. Juegos: la disponibilidad de aceleradores de tarjetas 3D ha cambiado el ´mbito de a los juegos en casa.22 ´ ´ CAP´ ITULO 2. dotaremos al sistema t´cnico (al robot. de forma convincente para que el usuario crea que interact´a con un ser inteligente y/o u emocional. los algoritmos de visi´n artificial pueden o utilizarse para extraer y transmitir estados de los m´sculos faciales de forma indepenu diente. Por una parte. diferentes o o formas (morph) predefinidas se interpolan con diferentes pesos para representar una mezcla de expresiones faciales. En luo gar de transmitir datos de la imagen f´ ısica. e u e . Sin u embargo. A pesar del r´pido crecimiento en la disponibilidad de a ancho de banda para comunicaciones. la animaci´n basada en m´sculo implica el consumo de recursos de computaci´n que o u o puede beneficiarse de la utilizaci´n de t´cnicas de reducci´n de complejidad basadas o e o en la distancia. m´sculos en la representaci´n 3D. Teleconferencia: la habilidad para transmitir y recibir im´genes faciales es la base a de la video o teleconferencia. aparecen problemas similares a los existentes en animaci´n. u o Avatares: un ´rea emergente es el uso de interfaces para el usuario. Final Fantasy) o ıa utilizando el m´todo anteriormente descrito requerir´ un gran n´mero de formas que e ıa u pueden consumir demasiado tiempo. la animaci´n se hace por parametrizaci´n. COMUNICACION Y EMOCION la creaci´n de un personaje cre´ o ıble es el realismo de sus expresiones y movimientos. Este m´todo funciona con personajes de dibujos anie mados (p. Por tanto. Por otra parte. Seg´n esta idea. Conclusi´n: Ideas b´sicas o a La idea b´sica de este proyecto es que la comunicaci´n m´quina-hombre —en el sentido a o a mencionado en el Cap´ ıtulo 1 de comunicar estados t´cnicos globales— puede mejorar mucho e con el uso de caracteres sint´ticos. 2. los estados musculares pueden utilizarse para distintos personajes.ej.7. La calidad de los gr´ficos procesados en tiempo real ha llegado a a un nivel adecuado para que los rasgos faciales sean suficientemente detallados para ser animados. y all´ marco a marco se reflejan los cambios en los estados de los ı. Tradicionalmente.

utilizando u 6 vectores . La habilidad de expresar emociones u —importante para lograr el objetivo de la interpretaci´n anal´gica— depender´. Los gr´ficos de elevada calidad que son capaces a a de generar los ordenadores hacen que se puedan generar expresiones m´s reales.ai.mit. necesario o a amente.edu/projects/humanoid-robotics-group/kismet/kismet. Para que la interpretacion de la cara sea efectiva no basta con la generaci´n de cualquier o representacion gr´fica. sin embargo. a y la falta de m´todos para crear y representar caras con el apropiado comportamiento e emocional y cognitivo. a la refiner´ de una cara antropom´rfica para facilitar la relaci´n. Los caracteres sint´ticos son tambi´n cada vez mas populares y. En este proyecto se intenta investigar en t´cnicas para crear agentes a e cre´ ıbles para los humanos con los que interact´an. Esto se o ıa) o o ha estudiado ampliamente en rob´tica humanoide. Existen diversas t´cnicas para la animaci´n facial (ver Figura 2. o Kismet: http://www. El m´todo seleccionae o e do para este proyecto ha sido el realizar la animaci´n facial bas´ndonos en manipulaciones o a geom´tricas ayud´ndonos de las caracter´ e a ısticas f´ ısicas del modelo de m´sculos. especialmente su comportamiento din´mico. CONCLUSION: IDEAS BASICAS 23 al autom´vil. e e pel´ ıculas de animaci´n) como la comunidad de investigadores en general. de forma r´pida.4). su e e comunicaci´n facial es limitada. o a Las expresiones faciales est´n siendo cada ves m´s importantes en sistemas con intera a faces humanoides (de hecho se investiga ampliamente en el ´mbito de la rob´tica antropom´rfia o o 4 5 ca ). 1987]. Es el denominado “Muscle Based Animation of Facial Expressions” desarrollado por Waters [Waters. Lo importante en este contexto es crear una expresi´n inteligible o m´s que producir una cara humana exacta. mejorando a la comunicaci´n hombre-m´quina. Las razones principales de que esto sea as´ son la falta de o ı conocimiento sobre las expresiones faciales. Por este m´todo han demostrado inter´s tanto la industria del entretenimiento (juegos. de la calidad de la s´ ıntesis. a 6 Camino se˜alado en la Figura 2.´ ´ 2. Las personas entienden a otras personas u objetos a trav´s de la interacci´n y son e o expertos observadores del movimiento. a Es un m´todo relativamente simple lo que permite una implementacion en el alcance e de este proyecto. o o Es r´pida lo que permite su uso en tiempo real. detectando.html Un ejemplo de esto es que si hacemos una b´squeda del t´rmino “avatar” en el buscador Google u e encontramos m´s de veinticinco millones de enlaces.4 n 5 4 . los movimientos no a naturales o imposibles.7. pero la propuesta de este trabajo es su o aplicaci´n a cualquier sistema t´cnico incluso no antropom´rfico. Consideramos que ´sta es la mejor elecci´n porque: e o Utiliza una simulaci´n anat´mica lo que le confiere realismo. ya que cualquier sistema o e o tiene un estado global en t´rminos de control —un estado emocional podr´ e ıamos decir— susceptible de ser comunicado por este canal.

del estilo de una n ´ m´scara que adopta las distintas expresiones faciales. COMUNICACION Y EMOCION Dise˜ando de este modo nos aseguramos que podemos crear diferentes interfaces seg´n n u la aplicaci´n de la que formen parte con el mismo c´digo. ya que entre unas caras y otras o o s´lo var´ la topolog´ del rostro y la distribuci´n de los m´sculos. a . s´lo ser´ necesario que o ıa ıa o u o ıa el programa cargara la adecuada en cada caso.24 ´ ´ CAP´ ITULO 2. En el presente proyecto se ha dise˜ado una unica interfaz sencilla.

Esta arquitectura de control pretende conseguir un aumento de robustez en los sistemas de control basados en ICa por medio de la implementaci´n de o mecanismos de auto-consciencia.Cap´ ıtulo 3 Una Cara para Higgs 3. a o 25 . El Pioneer 2AT-8 es una plataforma robusta que o incorpora los elementos necesarios para la implementaci´n de un sistema de navegaci´n y o o control del robot en entornos del mundo real. mediante una cara antropom´rfica o o y por medio de expresiones emocionales. como Higgs. o o Este proyecto tambi´n desarrolla una aplicaci´n concreta de este m´dulo para proporcionar e o o una cara a un sistema t´cnico: un veh´ e ıculo de reducidas dimensiones.1. El objetivo de la aplicaci´n HiggsFace es visualizar.2. los estados internos del robot Higgs. Esta empresa o dise˜a y construye robots m´viles as´ como sistemas de navegaci´n. control y de soporte n o ı o a la percepci´n sensorial de los mismos. Dentro de este contexto. La aplicaci´n HiggsFace o En t´rminos m´s precisos. este proyecto fin de carrera implementa un modulo reutilizable para la implementaci´n de interfases basadas en caras. la aplicaci´n de demostraci´n en la que se va a utilizar el e a o o m´dulo desarrollado en el presente proyecto es la comunicaci´n de los estados globales o o del robot m´vil Pioneer 2AT-8. 3.activmedia.com. Este m´dulo se denomina Faces. denominado a partir de este momento en el resto de la o memoria. Introducci´n o El proyecto SOUL del grupo ASLab pretende desarrollar una arquitectura de control reflexivo en el contexto de ICa. 1 Se puede conseguir m´s informaci´n en www. Higgs pertenece a la familia de robots m´viles de ActivMedia Robotics1 .

por lo que su o n reutilizaci´n en el contexto de este proyecto es pr´cticamente inmediata. La tecnolog´ CORBA nos proporciona a ıa esta capacidad de integraci´n distribuida heterog´nea. Un robot m´vil Pioneer 2-AT8 de ActivMedia Robotics. El objeto CORBA Higgs2 es usado externamente por clientes CORBA siguiendo un esquema cliente/servidor. o a La aplicaci´n se desarroll´ mediante la implementaci´n de un servant CORBA que eno o o capsula la interfase proporcionada por el fabricante (denominada Aria). podemos obtener los estados mec´nicos de Higgs mediante un cliente CORBA que le solicite al servidor que se ejecuta en a Aunque el nombre del objeto CORBA es el mismo que el del robot. identificaremos de quien se trata en cada caso por el contexto (ver nota aclaratoria al final del cap´ ıtulo).26 CAP´ ITULO 3. En el dise˜o de ICa se prev´ la posibilidad de que en alg´n momento los n e u sistemas operativos y las plataformas de ejecuci´n pueden ser diversos de modo que Higgs o est´ preparado para la heterogeneidad del sistema. Interacci´n con Higgs o Para poder expresar los estados globales de Higgs mediante emociones hemos de comunicarnos con ´l. 2 . de modo que esta informaci´n o o est´ disponible en cualquier punto de la red y puede ser requerida en cualquier momento. Se deo o sarroll´ un software que permite la transmisi´n de toda la informaci´n sensorial proporo o o cionada por el interfaz electr´nico del robot a la red local. Este problema fue abordado en un proyecto desarrollado en ASLab el a˜o e n pasado que ten´ por t´ ıa ıtulo “Sistema de Comunicaciones para Pioneer 2AT-8”[Pareja. o 3. 2004]. El objetivo del mismo era la comunicaci´n inal´mbrica (para que la plataforma fuera o a aut´noma) del robot m´vil con la red local de computadores del departamento. 2004]. El servidor Higgs se ejecuta en la CPU local del robot y se encarga de escuchar y atender las peticiones que le llegan por parte de los clientes que se ejecutan en cualquier m´quina a de la red local. o e Utilizando los resultados de dicho proyecto [Pareja.3.1: El robot Higgs. a Esta implementaci´n se hizo siguiendo las directrices de dise˜o de ICa. UNA CARA PARA HIGGS Figura 3.

o Figura 3. o La informaci´n que nos proporciona el servidor Higgs es la siguiente: velocidades. DESCRIPCION DE LA APLICACION HIGGSFACE 27 Higgs los datos sensoriales para su posterior tratamiento y transformaci´n de los mismos o en visualizaci´n de estados emocionales.´ ´ 3. o 3. posio ci´n del robot.2: Esquema sencillo de la aplicaci´n HiggsFace o .4.2. Descripci´n de la aplicaci´n HiggsFace o o En la aplicaci´n HighsFace intervienen tres elementos distribuidos: o Higgs: un servidor CORBA que soporta la interfase Pioneer::Pioneer2AT. En el cap´ ıtulo 6 veremos c´mo se transforma esta informaci´n sensorial y c´mo se o o o mapean ´sta a estados emocionales que ser´n expresados mediante expresiones faciales en e a un dispositivo de visualizaci´n. Un esquema sencillo de la aplicaci´n puede verse en la Figura 3. y estado de la bater´ o o ıa. informaci´n de los sonares.4. HiggsFace: un servidor CORBA que soporta la interfase SOUL::Face EmotionMapper: un programa intermedio (un agente activo ICa) que mapea estados de Higgs a estructura facial.

Del mismo modo el m´dulo HiggsFace implementa la interfase SOUL::Face. Esta informaci´n se o o o mapea a estados faciales que se le comunican al servidor CORBA HiggsFace que se encarga de dibujar en la pantalla la cara correspondiente al estado mec´nico del robot. a 3. Del mismo modo. por ejemplo Higgs. o . o Ambas interfases han sido dise˜adas para ser independientes de la aplicacion concreta n (para proporcionar dicha independencia de dominio) y permiten la reutilizacion de los modulos en otras aplicaciones. Figura 3.5. Dise˜ o de la aplicacion HiggsFace n Uno de los criterios de dise˜o de ICa es la independencia de dominio de los componentes n modulares. no implementa ninguna funcionalidad espec´ ıfica de la aplicacion construida en este proyecto. Esto es posible ya que. UNA CARA PARA HIGGS El funcionamiento de la aplicaci´n es simple: en Higgs se ejecuta el servidor CORBA o Higgs. el modulo Higgs implementa la interfase general Pioneer::Pioneer2AT que encapsula la funcionalidad del paquete Aria de ActiveMedia. el m´dulo empleado en la construccion de HiggsFace no implementa o ninguna funcinalidad concreta de esta aplicaci´n y podr´ ser empleado en cualquier otra o ıa (por ejemplo para generar caras de avatares o caras sint´ticas en entornos de telepresencia e humana). En el caso que nos ocupa.3: Modelo UML elemental de la aplicaci´n HiggsFace.28 CAP´ ITULO 3. que nos proporciona la informaci´n sensorial del robot m´vil.

la cara de Higgs (la cara. Desde el punto de vista del NameService CORBA. un Pioneer::Pioneer2AT). Todos ellos son Higgs. Higgs es el objeto que envuelve el cuerpo y HiggsFace es el objeto que gestiona la cara. Nota aclaratoria: Higgs tiene un cuerpo.˜ 3. DISENO DE LA APLICACION HIGGSFACE 29 Lo unico que es espec´ ´ ıfico de esta aplicaci´n es el EmotionMapper ya que este m´dulo o o es el que vincula espec´ ıficamente una interfase Pioneer::Pioneer2AT con una interfase SOUL::Face. un Pioneer 2AT8). La aplicacion global recibe el nombre HiggsFace que es tambi´n el nombre empleado e en el objeto CORBA que soporta la interfase SOUL::Face (ya que este es el centro del trabajo de este proyecto). un SOUL::Face) y el interfase del cuerpo de Higgs (el objeto software. . Podemos ser mas precisos y hablar del cuerpo de Higgs (el robot. una cara y un canal de conexi´n con el cuero po.5.

30 CAP´ ITULO 3. UNA CARA PARA HIGGS .

desde el punto de vista software.1 se describen aspectos generales de la especificaci´n CORBA de la o o OMG (e. en qu´ consiste la tecnolog´ y estructura general de la Object Management e ıa Architecture).g. los sistemas embarcados en a ´l estaban siendo actualizados. quiere decir estandarizaci´n: C. y en particular. o La Secci´n 4. el servidor de o pruebas.6 se describen componentes auxiliares.2 se encarga de describir el Broker ICa como una implementaci´n particular o o de CORBA que se va a utilizar en la aplicaci´n (junto con otros brokers de terceros). C++. Este servidor se ha creado para poder generar los estados de Higgs cuando el robot no est´ operativo dado que. Esta ultima es la tecnolog´ de base para el desarrollo modular propugnado por ´ ıa ICa y por ello se le dedica una atenci´n especial en este cap´ o ıtulo.5 se describe el proceso de creaci´n de un prototipo de la aplicaci´n o o o final HiggsFace. En la Secci´n 4. en concurrencia con este proyecto. Este o es el paquete encapsulado tras la interfase Pioneer::Pioneer2AT.4 se incluyen algunas notas sobre Aria. e 31 . el broker OmniORB. POSIX y o CORBA. este trabajo se enmarca dentro de la filosof´ ICa o ıa y eso. que es un paquete de clases o suministrada por el fabricante del robot m´vil para posibilitar el control del mismo. En la Secci´n 4.Cap´ ıtulo 4 Plataformas software En este cap´ ıtulo se describen las herramientas software que se utilizan para el desarrollo de la aplicaci´n objeto del presente proyecto. La Secci´n 4. o Como ya se dijo en la introducci´n.3 describe otro broker utilizado para la implementaci´n de los servidores o o CORBA de la aplicaci´n desarrollada en este proyecto. En la Secci´n 4. o En la Secci´n 4.

1. En los a o sistemas distribuidos la definici´n de la interfaz y ciertos servicios (como la b´squeda de o u m´dulos) son muy importantes. incluyendo universidades e instituciones gubernamentales. W3C. amo o a pliamente reconocida. la interoperabilidad y la portabilidad. o CORBA es independiente tanto de la plataforma como del lenguaje de la aplicaci´n. PLATAFORMAS SOFTWARE 4. Esta tecnolog´ DOM proporciona una interfaz de alto ıa nivel situada en la cima de los servicios b´sicos de la programaci´n distribuida. mantiene estrechas relaciones con a otras organizaciones como ISO. etc. Un sisıa a e tema distribuido heterog´neo es aquel compuesto por diferentes m´dulos software que ine o teractuan entre s´ sobre distintas plataformas hardware/software1 unidas por una red de ı a ´rea local. Hoy en d´ son miembros del OMG alrededor de mil distribuidores ıa de software. Proporciona un est´ndar para poder definir estas interfaces o a entre m´dulos. Sus est´ndares facilitan la interoperabilidad y a 1 Pueden tener arquitecturas diversas y soportar diferentes sistemas operativos . o Esto significa que los objetos se pueden utilizar en cualquier plataforma que tenga una implementaci´n del CORBA ORB (Object Request Broker ) y que los objetos y los clientes o se pueden implementar en cualquier lenguaje de programaci´n por lo que al programador o no le har´ falta saber el lenguaje en que ha sido escrito otro objeto con el que se est´ coa e municando. o o Su prop´sito principal es desarrollar una arquitectura unica utilizando la tecnolog´ o ´ ıa de objetos para la integraci´n de aplicaciones distribuidas garantizando la reusabilidad de o componentes. o o impulsando la introducci´n de objetos de programaci´n estandarizada. Adem´s. o El OMG es una organizaci´n de estandarizaci´n de car´cter neutral e internacional.1. desarrolladores y usuarios que trabajan en diferentes campos. basada en componentes de programaci´n disponibles comercialmente. El grupo OMG El OMG (Object Management Group) es una organizaci´n sin ´nimo de lucro creada en o a 1989 formada con la misi´n de crear un mercado de programaci´n basada en componentes.32 CAP´ ITULO 4.1. CORBA La tecnolog´ CORBA est´ orientada a los sistemas distribuidos heterog´neos. as´ como algunas herramientas para facilitar la implementaci´n de dichas o ı o interfaces en el lenguaje de programaci´n escogido. e CORBA no es m´s que una especificaci´n normativa para la tecnolog´ de la gesti´n a o ıa o de objetos distribuidos (DOM). La suite de especificaciones CORBA (Common Object Request Broker Architecture) proporciona un conjunto de abstracciones flexibles y servicios concretos necesarios para posibilitar soluciones pr´cticas a los problemas que surgen en entornos distribuidos heta erog´neos. 4.

Para un conocimiento mas detallado es necesario recurrir a los documentos . Esta norma cubre cinco grandes ´mbitos que constituyen los sistemas de objetos a distribuidos: Un lenguaje de descripci´n de interfaces. que define los mensajes y el empaquetado de los datos que se transmiten entre los objetos. Un protocolo gen´rico de intercomunicaci´n. La norma CORBA CORBA es una especificaci´n normativa que resulta de un consenso entre los miembros o del OMG. El OMG no produce implementaciones. etc. la administraci´n de sistemas y redes. Una descripci´n de servicios orientados al desarrollo de aplicaciones finales. Adem´s define implementaciones de ese protocolo gen´rico. o Una descripci´n de servicios. o 4. Como por ejemplo el IIOP para redes con la capa de transporte TCP. Python. medicina. s´lo especificaciones de software que son fruto de la recopilaci´n y o o elaboraci´n de las ideas propuestas por los miembros del grupo OMG. etc.) y una infraestructura o de distribuci´n de objetos llamada ORB (Object Request Broker). los documentos compuestos. etc. de transacciones.1. llamado GIOP (General Inter-ORB e o Protocol). conocidos con el nombre de CorbaServices. Una descripci´n de servicios verticales denominados CorbaDomains. etc. estruco turados sobre los objetos y servicios CORBA.1.2. llamado IDL (Interface Definition Lano guage).) Pretende o definir colecciones de objetos prefabricados para aplicaciones habituales. de persistencia. que proveen o funcionalidad de inter´s para usuarios finales en campos de aplicaci´n particulares. 4. a o Cubren los servicios de nombres.4. lo que permite la comunicaci´n entre los difero entes ORBs consiguiendo la interoperabilidad entre elementos de diferentes vendedores. estas especificaciones cubren servicios de alto nivel (como los interfaces de usuario. Java. La Tecnolog´ CORBA ıa En esta secci´n se hace una descripci´n general de la arquitectura CORBA y su funo o cionamiento. de eventos. El n´mero de servicios se ampl´ continuamente para a˜adir nuevas capacidades a u ıa n los sistemas desarrollados con CORBA. CORBA 33 portabilidad de aplicaciones construidas mediante objetos distribuidos.3. que como plementan el funcionamiento b´sico de los objetos de que dan lugar a una aplicaci´n. existen proyectos en curso en sectores como: telecomunicaciones. ADA. Con el nombre de CorbaFacilities.1. finanzas. sobre a e diferentes protocolos de transporte. e o Por ejemplo. traducciones de este lenguaje de especificaci´n IDL a lenguajes de impleo mentaci´n (como pueden ser C++.

org a o .34 CAP´ ITULO 4.1: Servicio de objetos CORBA de especificaci´n del OMG2 . e Su dise˜o se basa en el modelo de objetos del OMG. donde se definen las caracter´ n ısticas externas que deben poseer los objetos para que puedan operar de forma independiente de la implementaci´n. o Common Object Request Broker Architecture (CORBA) CORBA especifica un sistema que proporciona interoperabilidad entre sistemas que funcionan en entornos heterog´neos y distribuidos de forma transparente para el programador. PLATAFORMAS SOFTWARE Figura 4. o Las caracter´ ısticas m´s destacables de CORBA son las siguientes: a es una tecnolog´ no propietaria ıa una base fundamental de la especificaci´n son los requisitos reales de la industria o es una arquitectura extensible es independiente de la plataforma es independiente del lenguaje de programaci´n o proporciona m´ltiples servicios de aplicaci´n u o 2 M´s informaci´n en www.omg.

Arquitectura general Un objeto CORBA es una entidad que proporciona uno o m´s servicios a trav´s de a e una interfaz conocida por los clientes que requieren dichos servicios. CORBA 35 servidores y clientes (proveedores y usuarios de servicios) pueden desarrollarse de manera totalmente independiente En una aplicaci´n desarrollada en CORBA los objetos distribuidos se utilizan de la o misma forma en que ser´ utilizados si fueran objetos locales. En general el ORB e o . la distribuci´n y ıan o heterogeneidad del sistema queda oculta y el proceso de comunicaci´n entre objetos es o totalmente transparente para el programador.4. el cual proporciona la infraestructura necesaria para identificar y localizar objetos. gestionar las conexiones y transportar los datos a trav´s de la red de comunicaci´n. esto es. Un objeto CORBA se define como aquel que proporciona alg´n tipo de servicio. de modo que las entidades que u solo los utilizan no se consideran como tales. Figura 4.1.2: Componentes de la arquitectura CORBA El componente central de CORBA es el ORB (Object Request Broker).

a e trav´s de interfaces de comunicaci´n bien definidas. par´metros. aunque es posible interaccionar con ´l a o e como si fuera una unica entidad gracias a sus interfaces. o Invocaci´n din´mica: se basa en el uso de la DII. Las peticiones de servicio son eventos e o que transportan informaci´n relativa a los objetos o entidades implicadas en dicho servicio.36 CAP´ ITULO 4. y a transmit´ ırselas al ORB. Los servicios que proporciona un servidor CORBA residen en la implementaci´n del objeto. La o o comunicaci´n entre el ORB y dicha implementaci´n la realiza el adaptador de objetos o o (Object Adapter. el cual proporciona servicios como: generaci´n e interpretaci´n de referencias a objetos o o invocaci´n de m´todos de las implementaciones o e mantenimiento de la seguridad en las interacciones activaci´n o desactivaci´n de objetos o o mapeo de referencias a objetos registro de implementaciones . OA). PLATAFORMAS SOFTWARE est´ formado por la uni´n de varios componentes. Es gracias a los stubs que los clientes pueden ser programados en diferentes lenguajes de programaci´n. esta referencia es un nombre complejo que identifica de forma un´ ıvoca al objeto en cuesti´n dentro del sistema. an´logo al stub del cliente. escrita en un lenguaje de programaci´n determinado. tambi´n llamados servidores. o informaci´n sobre la operaci´n a realizar. que est´ implementado en un lenguaje determinado. El n´cleo del ORB (ORB Core) ´ u es la parte fundamental de este componente. siendo el responsable de la gesti´n de las petio ciones de servicio. o a Invocaci´n est´tica: el stub es un fragmento de c´digo encargado de mapear o traducir o a o las peticiones del cliente. etc. En la informaci´n enviada se o o a o incluye una referencia de objeto del objeto proveedor del servicio. Los clientes realizan peticiones de servicio a los objetos. Una vez la petici´n llega al n´cleo del ORB es transmitida hasta el lado del servidor. La funcionalidad b´sica del ORB consiste en transmitir las peticiones a desde los clientes hasta las implementaciones de los objetos servidores. a contrapartida de la DII. o Para realizar una petici´n un cliente se comunica primero con el ORB a trav´s de uno o e de los dos mecanismos existentes a su disposici´n: para el caso de invocaci´n est´tica el o o a stub o para el caso de la invocaci´n din´mica el DII. Permite realizar invocaciones sin o a necesidad de que el cliente sepa cierta informaci´n acerca del servidor. o u donde se sigue un proceso inverso de nuevo a trav´s de dos mecanismos alternativos: el e skeleton del servidor. que ser´ o ıa necesaria en caso de utilizar el stub. Dynamic Invocation Interface. o la DSI (Dynamic Skeleton Interface).

4. o Interoperabilidad entre ORBs En la actualidad existen muchas implementaciones diferentes de ORBs. Por ultimo. o Las diferencias en la implementaci´n del broker no son la unica barrera que sepao ´ ra a objetos que funcionan en distintos ORBs. El IR puede contener otra informaci´n relativa a la impleo mentaci´n como por ejemplo datos de depurado. que es otro componente est´ndar o a de la arquitectura CORBA. o o etc.1. Cada servant lleva asociado un identificador llamado object ID. Dentro del servidor se crean y gestionan servants que atienden las peticiones que llegan al mismo. CORBA 37 Existen adaptadores de objetos m´s complejos. en el lado del servidor CORBA. Para el o caso de la invocaci´n din´mica la interfaz DII accede al IR en busca de ´sta informaci´n o a e o en concreto cuando un cliente la utiliza para realizar una petici´n. los objetos que se encargan en ultima ´ ´ instancia de atender a las peticiones de servicio son los servants. Para satisfacer todos estos requisitos existe una especificaci´n para lograr la interoperabilidad entre ORBs. Dos adaptadores de objetos b´sicos son el BOA (Basic Object Adapter ) y el POA (Portable Object a Adapter ). llamada Interface Repository (IR). El primero ha quedado ya obsoleto. Deıas bido a esto. o bien almacenando la informaci´n necesaria en el IR. lo cual es una ventaja ya que cada desarrollador puede emplear aquella que mejor satisface sus necesidades. e proporcionar una infraestructura que permita a aplicaciones no basadas en CORBA comunicarse con aplicaciones basadas en esta arquitectura. valor que es utilizado por el adaptador de objetos para la gesti´n de los mismos. este s´lo ve una entidad unica a la que o ´ conoce como servidor. llamado RootPOA. los objetos que funcionan en diferentes dominios (ORBs y entornos de los . informaci´n administrativa. bases de datos). De este modo se hace o posible que un cliente pueda invocar un servicio sin necesidad de conocer la descripci´n o IDL de la interfaz del objeto servidor. etc. versiones. El adaptador de objetos es el encargado de hacer llegar dichas peticiones a los servants. crearlos o destruirlos. Pero esto crea tambi´n la necesidad de un mecanismo que permita a dos implementae ciones diferentes comunicarse entre s´ Tambi´n es necesario en determinadas situaciones ı. que proporcionan servicios adicionales. y suele utilizarse el segundo adaptador. Estos objetos contienen la implementaci´n de las operaciones asociadas a cada servicio o m´todo de la interfaz del o e objeto. o El adaptador de objetos necesita conocer cierta informaci´n acerca de la implementaci´n o o del objeto y del sistema operativo en el que se ejecuta. tambi´n existen otras dificultades como e infraestructuras de seguridad o requisitos espec´ ıficos de sistemas en v´ de desarrollo. No son visibles desde el lado del cliente. Las interfaces de los objetos servidores pueden especificarse de dos maneras: o bien utilizando el lenguaje IDL. a y que son utilizados para aplicaciones espec´ ıficas (por ejemplo. El ORB proporciona adem´s un POA preconfigurado que puede usarse si no se desea crear a un POA espec´ ıfico para una aplicaci´n. Existe una base de datos que almacena esta informaci´n.

son transformados a un formato interno acordado por ambos dominios de antemano. se genera c´digo fuente en el lenguaje de o programaci´n deseado en cada caso. PLATAFORMAS SOFTWARE mismos) necesitan un mecanismo que haga de puente entre ellos. pero es menos general. y bajo este formato la informaci´n pasa de un dominio al o otro. los cuales pueden e clasificarse en dos tipos principales: inmediatos e intermediados (immediate/mediated bridging). o El IDL se mapea (“traduce”) al compilar al lenguaje de programaci´n deseado. IDL es un est´ndar ISO. interfaces(conjuntos e de operaciones) y m´dulos (conjuntos de interfaces). donde suele ser necesario alcanzar unos niveles determinados de seguridad. La interoperabilidad puede alcanzarse a trav´s muchos procedimientos. Este mecanismo debe ser suficientemente flexible para que no sea necesaria una cantidad de operaciones de “traducci´n” inmanejable. ya que la eficiencia es uno de los objetivos de la especificaci´n de o o CORBA. de forma que desde el “exterior” el objeto sigue siendo el mismo y contin´a ofreciendo id´nticos servicios. o a a CORBA IDL Como ya hemos mencionado. es unicamente un lenguaje o ´ declarativo. u e IDL no es un lenguaje de programaci´n propiamente dicho. Para el o lenguaje C++. Este formato interno de la informaci´n puede basarse en una especificaci´n est´ndar. y tiene a las siguientes caracter´ ısticas principales: su sintaxis es muy similar a la de C++ soporta herencia m´ltiple de interfaces u independiente de cualquier lenguaje de programaci´n y/o compilador. A trav´s de un compilador espec´ e ıfico que procesa las definiciones escritas en IDL. o permite independizar el dise˜o de la interfaz de la implementaci´n del objeto CORBA n o en cuesti´n. Los procedimientos inmediatos se basan en traducir directamente la informaci´n desde el o formato utilizado por un dominio. Esta caracter´ ıstica es cr´ ıtica en sistemas de control. Tiene tres elementos principales: operaciones (m´todos). o bien puede ser un formato acordado de forma privada.38 CAP´ ITULO 4. IDL sigue la siguiente tabla de conversi´n: o . al formato utilizado por el otro. En los procedimientos intermediados los elementos de un dominio que interaccionan con los de otro dominio distinto. o o a como en el caso del IIOP del OMG. el lenguaje IDL (Interface Definition Language) es un lenguaje utilizado para especificar interfaces CORBA. predecibilidad y seguridad. sin pasar por estructuras intermedias de datos. manteniendo la o o misma interfaz. c´digo que es utilizado en las aplicaciones para crear o o servidores CORBA ya que proporciona la infraestructura de skeletons y stubs necesaria para que estos objetos puedan comunicarse con el ORB. La implementaci´n puede cambiarse por otra distinta. puede mao pearse a muchos lenguajes de programaci´n. Esta soluci´n es mucho m´s r´pida.

CORBA Tipo de datos IDL short long unsigned short unsigned long float double char boolean octet enum Tipo de datos C++ CORBA::Short CORBA::Long CORBA::UShort CORBA::ULong CORBA::Float CORBA::Double CORBA::Char CORBA::Boolean CORBA::Octet enum typedef short int long int unsigned unsigned float double char unsigned unsigned enum 39 short long char char Bases de la construcci´n de aplicaciones CORBA o Para desarrollar un objeto CORBA se siguen.4. 5. etc. un servidor. e implen o mentaci´n de la/las interfaces IDL correspondientes. que contienen la implementaci´n de las o o operaciones del objeto CORBA. debe crear un adaptador o de objetos para sus servants. Compilaci´n: se procede a la compilaci´n de los archivos de c´digo fuente. Debe o o o incluirse el c´digo generado autom´ticamente por el compilador de IDL (la parte o a correspondiente a los skeletons). El proceso se reduce b´sicamente a tres fases: generaci´n e integraci´n de c´digo correa o o o spondiente a las interfaces. el proceso se reduce a la integraci´n del c´digo fuente generado correspondiente a los stubs. Para el desarrollo de un cliente.1. Implementaci´n de servants: utilizando las clases generadas por el compilador de o IDL. implementaci´n de la funcionalidad del objeto CORBA y por o ultimo. Implementaci´n del servidor: el objeto CORBA debe proporcionar la infraestruco tura base para que la comunicaci´n con el ORB sea posible. los siguientes pasos: 1. es decir. se crean los servants de la aplicaci´n. o o . compilaci´n. Estos pasos son los correspondientes para el desarrollo de un objeto ´ o CORBA. 4. o 3. Dise˜ o: determinaci´n de los servicios que debe proporcionar el objeto. en general. en un lenguaje de programaci´n determinado. o 2. Compilaci´n de IDL: mediante el compilador de IDL se procesan las definiciones o de interfaces y se generan los skeletons y stubs correspondientes.

En este proyecto se emple´ ICa Broker como plataforma CORBA pero. PLATAFORMAS SOFTWARE 4. En el caso e u m´s general estos componentes se situan en un entorno distribuido y heterog´neo (tanto a e desde el punto de vista del hardware como de los sistemas operativos soportados) formado . o Entendemos por arquitectura un dise˜o software a un determinado nivel de abstracn ci´n. o ICa Broker es un broker CORBA —con un entorno de desarrollo asociado— dise˜ado n para asistir la creaci´n de sistemas software de medio y alto nivel en entornos industriales.2. centrado en los patrones de organizaci´n del sistema que describen c´mo se particiona o o o la funcionalidad y c´mo esos elementos se interconectan e interrelacionan entre s´ Por un o ı. Arquitectura de Control Integrado ICa significa Arquitectura de Control Integrado. con prestaciones de tiempo real y tolerancia a fallos. este proyecto emplea recursos desarrollados en un proyecto anterior cuyo objetivo era el desarrollo del sistema de comunicaci´n del robot m´vil o o [Pareja.scilabs. ICa Broker 1. lado una arquitectura es un modelo de separaci´n del sistema en componentes y por otro o un modelo de coordinaci´n de los mismos. o ICa implementa una metodolog´ de orientaci´n a componentes: m´dulos software que ıa o o interaccionan unos con otros a trav´s de una interfaz p´blica bien conocida.1 de la OMG. en cierta medida. pero tener aplicaciones ya desarrolladas que lo utilizan es una buena raz´n para o decantarnos por esa opci´n. Los proyeco o tos que se realizan en el grupo ASLAb estan estrechamente relacionados. piezas del mismo puzle ICa. o como se ha indicado previamente en la Secci´n 4. o Proporciona herramientas para el desarrollo de software distribuido. propiedad de la empresa SCILabs con la que la UPM mantiene un acuerdo de colaboraci´n.2.0 es la version actual. El Broker ICa En esta secci´n se describe ICa Broker que es una implementaci´n CORBA. Como ya se ha mencionado. ICa Broker RT 2.es). Este es el marco en el que se desarroll´ este broker: para posibilitar el desarrollo de sistemas integrados de control.1 esto no condiciona a tener que utilizarlo o en este proyecto (recordemos la interoperabilidad entre ORBs descrita en la secci´n ano terior). constituyendo. Se sigue usando ICa Broker porque permite explorar aspectos particulares de la implementacion gracias al acuerdo UPM-SCILabs de acceso al codigo fuente sin tener que entrar en la complejidad de otros brokers Open Source como TAO.1. 2004]. 4. ICa Broker ha sido desarrollado en proyectos anteriores del grupo y posteriomente por un spin-off de alumnos de nuestro grupo (www. Esta versi´n cumple con la especificaci´n o o o Real-time CORBA 1.0 fue el resultado del trabajo desarrollado por el Departamento de Autom´tica. Ingenier´ Electr´nica e Inform´tica Industrial dentro a ıa o a del marco de un proyecto ESPRIT DIXIT en colaboraci´n con varias empresas de toda o Europa.40 CAP´ ITULO 4.

e En ICa 1. 2003]. 4. Ejemplos de estas extentiones son los mecanismos de gesti´n de timeouts y de checkpointing. El o sistema operativo elegido para el desarrollo de la aplicaci´n que es objetivo de este proyecto o es GNU/Linux. El directorio /usr/local/ICa contiene las librer´ scripts y ficheros necesarios para ıas.2. por lo que es aplicable en o los sistemas que no requieran alguna de estas prestaciones simplemente renunciando a ellas.0 se desarrollaron extensiones para adaptarse a las necesidades de los sistemas de control de procesos industriales. a medida que se va ascendiendo por la misma.0). En las capas superiores tenemos control o inteligente. Existen otros frameworks que han sido dise˜ados para aplicaciones de car´cter m´s n a a ofim´tico y se aplican de forma forzada en entornos que se encuentran m´s all´ de sus a a a especificaciones de dise˜o. o o mientras que. EL BROKER ICA 41 por una o varias plataformas hardware conectadas por una red que les permite interactuar a trav´s de ella. A la hora de integrar componentes para formar un sistema de control existen t´cnicas diversas y los desarrolladores deben conocer y controlar todas ellas para e utilizar la m´s adecuada en cada caso. o a . en la que se deben a˜adir las entradas para identificar la m´quina en n a la que correr´ el servicio de nombres (aplicaci´n icans) a o /etc/services. junto con la integraci´n de diversas plataformas y sistemas ıas o operativos son los objetivos de ICa.2. plataformas o o ıas y lenguajes diversos. proporcionando principalmente soporte a la decisi´n.4. Instalaci´n de ICa Broker o Para poder utilizar el broker de ICa es necesario instalar sus librerias en las m´quinas a en las que se vaya a desarrollar el proceso de creaci´n del software[Chinchilla. formando lo que se conoce con el nombre de pir´mide de control. la compilaci´n de las aplicaciones basadas en el ICa Broker. n Por ultimo con el t´rmino integrado se hace referencia a una de las caracter´ ´ e ısticas principales de ICa: su orientaci´n hacia la integraci´n de tecnolog´ de control. en los cuales aparecen restricciones de tiempo real. La integraci´n ıas o o de estas metodolog´ de control. Para completar la instalaci´n o o se deben a˜adir algunas l´ n ıneas a diversos ficheros del sistema: /etc/hosts. por lo que para la instalaci´n de las mismas se utiliza el paquete correo spondiente a este sistema operativo que fue proporcionado por SCILabs (creadores de ICa Broker RT 2.2. Los sistemas de control se dise˜an generalmente a n por capas. en la que se deber´ configurar a qu´ puertos y protocolos usa el a e broker para establecer la comunicaci´n entre las distintas m´quinas de la red local. o No renuncia a su aplicaci´n en entornos sin estas necesidades. En las capas a inferiores se intercambia informaci´n a altas velocidades y con un nivel de abstracci´n bajo. en el que la informaci´n que se intercambia es abstracta y desarrollada con o metodolog´ diversas. los sistemas deben tener tolerancia a fallos y existen limitaciones de velocidad importantes. los flujos de datos disminuyen pero aumenta el nivel de abstracci´n de los mismos.

Omni OmniORB fue desarrollado por Olivetti Research Ltd (que en 1999 pas´ a ser parte o de AT&T Laboratories) para ser utilizado en peque˜os equipos de entorno embebido que n necesitaban de comunicaci´n con ORBs comerciales en ordenadores sobremesa y servidores. u OmniORB es un broker que implementa la especificaci´n 2. hay que crearlo si se quiere que ICa arranque autom´ticamente a como un servicio del sistema.6 como por ejemplo no se soportan las interfaces locales ni los objetos por valor). ı Sun. o 4.1 (le faltan todavia caracter´ ısticas para ajustarse a la norma 2. Instalaci´n de Omni o Al ser Open Source se puede encontrar en la red3 todo lo necesario para instalarlo.4. as´ como las instrucciones de como hacerlo dependiendo de la plataforma (Windows. Es robusto y o tiene grandes prestaciones. permitiendo la programaci´n en C++ y Python.d/ICa. e 4.1.3. Es uno de los tres ORB al que se le ha concedio el Open Group’s Brand de CORBA.6 de CORBA. etc.sourceforge.bashrc. Este es otro de los brokers usados en este proyecto para la implementaci´n de los o servidores de HiggsFace. o Ha evolucionado con el tiempo a trav´s de 11 versiones p´blicas para la comunidad CORe u BA. Aria Aria es un paquete software orientado a objetos programado en C++ que proporciona una API (Application Programming Interface) para el control de diversos robots m´viles de ActivMedia4 . Linux. lo que significa que ha sido probado y certificado para CORBA 2. . 4. varias versiones beta y peque˜os desarrollos. En la actualidad lo utilizan numerosos n desarrolladores de programas en m´ltiples aplicaciones. Aria permite la construcci´n de aplicaciones para el control de los o o robots: desde la ejecuci´n de simples comandos hasta la elaboraci´n de comportamientos o o 3 4 http://omniorb. Es libre bajo o los terminos GNU General Public License. .) sobre la que se est´ trabajando. PLATAFORMAS SOFTWARE /etc/init.42 CAP´ ITULO 4. a˜adir una serie de variables de entorno para facilitar la compilaci´n de los n o programas Con estos pasos se concluye la instalaci´n de ICa Broker.3.net/ Empresa fabricante del robot Higgs.

Cliente prototipo CORBA Si bien las anteriores secciones se han dedicado a una descripci´n general de las hero ramientas. o 4. Suministra diversas clases para o establecer esta conexi´n.4. Comunicaci´n con el robot o Una de las principales funciones de Aria.1.3-2. CLIENTE PROTOTIPO CORBA 43 inteligentes como detectar y evitar obstaculos.rpm para la instalaci´n del software en las m´quinas en las que se va a desarrollar la aplicaci´n.4. o Debido a las caracter´ ısticas CORBA descritas antes. Es neceo a o sario copiar el paquete en ra´ y descomprimirlo. existe total libertad a la hora de dise˜ar el cliente que se conecte a la aplicaci´n servidor creada. l´ser o pinzas.4. exploraci´n. Instalaci´n de Aria o Los fabricantes del robot facilitan el paquete ARIA-1. etc. esta describe el uso de las mismas para la construcci´n de un prototipo de la o aplicaci´n objeto del presente proyecto. Hay que compilar los archivos lo cual puede hacerse en un solo paso utilizando el comando “make everything”. las funciones principales que se realizan son o de lectura y escritura de datos en los dispositivos. es el sistema operativo que se ejecuta en el microprocesador del robot m´vil Pioneer-2AT8. Una vez compilado con ´xito queda instalado e el paquete Aria y listo para su utilizaci´n. clases a a con utilidades matem´ticas o para el manejo de tiempos. o Aria es un potente y robusto paquete compuesto por m´s de cien clases programadas a en C++. es establecer y gestionar la comunicaci´n cliente-servidor AROS5 o entre los dispositivos del robot y la aplicaci´n cliente. o 5 .2. . . Se utiliza invocaci´n n o o est´tica por lo que es necesario conocer la interfaz IDL con que se cre´ el servidor al que se a o conecta y ultilizar la misma para desarrollar el cliente.5. 4. reconocimiento de caracter´ ısticas de objetos. pero el lenguaje en el que se haga y el broker que se utilice puede elegirse libremente. lo que significa que es un software de a c´digo abierto. o 4. a Aria est´ registrado bajo la GNU Public Licence. una vez establecida. Del mismo modo todo el software desarrollado a partir de ARIA debe ser o distribuido y proporcionando el c´digo fuente. De este modo se crea el directorio ız /usr/local/Aria.5.i386. AROS (ActivMedia Robotics Operating System). Existen clases para el control de dispositivos como c´maras. y el primer cometido de toda aplicaci´n de o control para el robot.

struct Pioneer2AT_State { float Velocity.5. debido a que utilizamos invocaci´n est´tica. PLATAFORMAS SOFTWARE En “Sistema de Comunicaciones para Pioneer 2AT-8”?? se utilizaba ICa y C++ para desarrollar la aplicaci´n cliente/servidor y este es el punto de partida en este caso. El o a proyecto “Sistema de Comunicaciones para Pioneer 2AT-8”[Pareja. float RightVelocity. aunque o nada obliga a ello ya que. La siguiente interfaz idl se utiliza para la aplicaci´n: o module Pioneer{ const long NUMSONARS = 16. float ClosestSonar.5. float LeftVelocity. En la Secci´n 4.4 al modo en que se ejecuta el binario generado.2. La estructura general de un cliente CORBA con C++ se describe en la Secci´n o 4. float Battery.3) ´ o o y la Secci´n 4.44 CAP´ ITULO 4. float ClosestRange. float XCoordinate. existe interoperabilidad o o entre ORBs y las aplicaciones cliente/servidor son independientes entre s´ desde el punto ı de vista del lenguaje de implementaci´n.5. SonarArray Sonar_Range. interface Pioneer2AT{ . 2004] dise˜´ una aplino caci´n cliente/servidor basada en una interfaz que ha sido modificada posteriormente para o adecuarse a las necesidades de las aplicaciones que se desarrollan en el grupo. float RotVelocity.1.1 se describe la interfaz idl utilizada para la creaci´n o o o del mismo. float ThCoordinate. }. Las ultimas secciones estan dedicadas a la compilaci´n del programa (Secci´n 4. o En las siguientes secciones se describen distintos aspectos referentes a la creaci´n de un o prototipo CORBA con el objetivo de familiarizarse con la programaci´n para el desarrollo o de la aplicaci´n final. typedef float SonarArray[16]. Interfaz IDL Para la realizaci´n del programa cliente debe ser conocida la interfaz que proporciona o el servidor para poder hacer peticiones. o 4. como se explic´ en la secci´n de CORBA. float YCoordinate.5.5.

4.5. CLIENTE PROTOTIPO CORBA // Get all-in-one robot state Pioneer2AT_State getFullState(); // Connection management long connect(); void disconnect(); // Velocities information float getVelocity(); float getLeftVelocity(); float getRightVelocity(); float getRotVelocity(); // Velocities manipulation and movement void setVelocity(in float vel); void setLeftRightVelocity(in float leftvel,in float rightvel); void setRotVelocity(in float vel); void moveDistance(in float vel); // Robot coordinates information float getXCoordinate(); float getYCoordinate(); float getThCoordinate(); // Sonar information long getSonar_Range(in long num_sonar); short getClosestSonar(); long getClosestRange(); // Battery information float getBattery(); // CORBA object remote control void init(); void finish(); }; };

45

El nombre del m´dulo creado es Pioneer. En la primera parte del IDL se declaran los o o tipos de datos y se define la estructura Pioneer2AT State que guarda toda la informaci´n sensorial del robot m´vil. Tambi´n se define un tipo de dato (SonarArray) para guardar o e

46

CAP´ ITULO 4. PLATAFORMAS SOFTWARE

en un vector de n´meros con coma flotante toda la informaci´n de los 16 sensores de los u o que dispone. En la segunda parte del IDL se declara la interfaz Pioneer2AT en la que se definen los m´todos disponibles para el m´dulo Pioneer. En este caso el m´dulo s´lo posee e o o o una interfaz pero podr´ definirse tantas como fueran necesarias y los m´todos disponibles ıan e son: obtener el estado del robot, esto es, toda su informaci´n sensorial (en una estructura) o conexi´n/ desconexi´n al robot o o velocidad lineal y de rotaci´n con la que se mueve o manipulaci´n de la velocidad y posici´n del robot o o posici´n del robot o estado de la bater´ ıa control del servidor CORBA El siguiente paso es generar los stubs y los skeleton con el compilador idl correspondiente a ICa (que se llama ADL). Se utiliza el stub generado para implementar el cliente; los skeleton se usan para implementar la parte del servidor6 . Un esquema general del proceso puede verse en la figura 4.3

4.5.2.

Estructura general del cliente C++

Al principio de la funci´n “main” del programa principal de la aplicaci´n cliente hay o o que realizar una serie de pasos relacionados con CORBA, la forma en la que se hacen estos pasos es siempre la misma. En los siguientes fragmentos de c´digo se recogen estos pasos o as´ como los comandos CORBA correspondientes: ı 1. Instanciar las clases. RTCORBA::RTORB_var rtorb; CORBA::Object_ptr nameService; CosNaming::NamingContext_var namingContext; CosNaming::Name name; RTPortableServer::POA_var rtpoa; PortableServer::POAManager_var mgr; 2. Obtener la referencia del ORB, si es nula el programa aborta su ejecuci´n. o
Existe un servidor dise˜ado con la misma interfaz IDL para ejecutarse en la CPU de Higgs y atender n peticiones
6

4.5. CLIENTE PROTOTIPO CORBA

47

Figura 4.3: Generaci´n, integraci´n y compilaci´n o o o

cout << "Obtaining a RTORB reference..."; CORBA::ORB_var orb = CORBA::ORB_init(argc, argv); CORBA::Object_var obj = orb->resolve_initial_references("RTORB"); rtorb = RTCORBA::RTORB::_narrow(obj); cout << "done." << endl; if (CALL_IS_NIL(rtorb.in())) cerr << "ERROR: Couldn’t get a reference to RTORB" << endl;

3. Obtener la referencia del POA. cout << "Obtaining a Root POA reference..."; CORBA::Object_var obj2 = rtorb->resolve_initial_references("RootPOA"); rtpoa = RTPortableServer::POA::_narrow(obj2); cout << "done." << endl; if (CALL_IS_NIL(rtpoa.in())) cerr << "ERROR: Couldn’t get a reference to RTPOA" << endl;

o El Makefile correspondiente al prototipo CORBA es el siguiente: . Con este objetivo se o o escribe el archivo Makefile. la limpieza de los archivos temporales en la creaci´n del fichero. 4." << endl. Make es una herramienta de generaci´n de c´digo. Obtener el NameService.3. robot_name[0]. Makefile Una vez escrito el c´digo de la aplicaci´n es necesario compilarlo. robot_name. cout << "done. Obtener el manejador del servant.. 6.".. robot_name[0]. La herramienta Make se usa para las labores de creaci´n de fichero o ejecutable. cout << "Resolving servant name. CORBA::Object_var object_robot = namingContext->resolve(robot_name). Lee las instrucciones escritas en el archivo Makefile que reciben el nombre de dependencias. CosNaming::Name robot_name. mgr = rtpoa->the_POAManager().. Activar el POA Manager.." << endl. cout << "Obtaining handle for servant.id = CORBA::string_dup("SERVIDOR_ROBOT_SERVANT"). Resolver el nombre a una refrencia al servant.length(1).48 4.. namingContext = CosNaming::NamingContext::_narrow(nameService). cout << "done.."." << endl.. cout << "done.".. cout << "done.". miRobot = Pioneer::Pioneer2AT::_narrow(object_robot). cout << "Resolving name service. PLATAFORMAS SOFTWARE cout << "Activating POA Manager. muy usada en los sistemas operativos o o tipo GNU/Linux.. nameService = rtorb->resolve_initial_references("NameService"). 7." << endl. CAP´ ITULO 4.kind = CORBA::string_dup(""). 5. mgr->activate().5..

Para facilitar la tarea en c3p0 (uno de los ordenadores del departamento) o se est´ ejecutando constantemente la aplicaci´n icans (ICa Naming Service) por lo que el a o IOR del NameService es siempre el mismo y podemos crear scripts en los que se indica que se ejecute el binario con el IOR permanente del NameService como par´metro. Ejecuci´n o Una vez generado el binario.5. de modo que es distinto en cada ocasi´n. Lanzar el servidor de nombres (icans) para obtener el NamingService.5.IOR correspondiente a c3p0 es el siguiente: IOR:010000002800000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e674 36f6e746578743a312e300001000000000000008a000000010101000f0000003133382e313030 2e37362e3234300000d107000043000000004000000d4e616d6553657276696365526f6f74504 f41000049444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e74657874 3a312e300000310001000000020000001a0000000100000001000000280000000a00000001000 000010000000040000000 De modo que el lanzador del cliente queda de la siguiente forma: . Se har´ necesaria la creaci´n de otro cliente que nos permitiera provocar en el robot ıa o los distintos estados para comprobar que la interfaz dise˜ada recorre todo el espectro de n . Depende de varios factores tales como la m´quina en la que a corra el servidor de nombres y de cuando se haya lanzado el mismo. Lanzar la aplicaci´n cliente pas´ndole como par´metro el IOR del NameService o a a El servidor de nombres genera la referencia al objeto (IOR) que es un par´metro que le a tenemos que pasar al ejecutable. CLIENTE PROTOTIPO CORBA 49 4. Lanzar la aplicaci´n servidor pas´ndole como par´metro el IOR del NameService o a a 3.IOR‘ Por cuestiones de mantenimiento del robot m´vil necesita un nuevo computador abordo o para satisfacer las necesidades de otro proyecto que se est´ desarrollando ahora en el a grupo. a El NamingService. o El problema que se plantea al no poder conectar directamente el cliente al robot es que los movimientos del mismo en el simulador no se pueden controlar ya que el cliente dise˜ado n solo le pide la informaci´n./ClienteRobotB2 -ORBInitRef IOR=‘cat NamingService. Afortunadamente el paquete Aria incluye un simulador llamado “SRIsim” cuya interfaz puede verse en la Figura 4. para ejecutarlo se debe seguir el proceso siguiente: 1. no lo teleopera en modo alguno. Higgs no se encuentra operativo en todo momento. por lo que el simulador no sirve o para probar si la cara se anima seg´n las distintas situaciones en las que se pueda encontrar u Higgs.4 que permite simular la conexi´n al robot.4.IOR 2.4.

Esta segunda es la opci´n elegida: se crea una aplicaci´n que o o act´a como banco de pruebas para el m´dulo SOUL::Face. a Otra alternativa es crear una aplicaci´n en la que se pudiera simular los estados de Higgs o que interesaran en cada caso. Sustituye al robot o al simulador. .6. esto es.4: Simulador de Aria situaciones mec´nicas posibles y las mapea a los estados emocionales correspondientes. PLATAFORMAS SOFTWARE Figura 4. actuando como servidor y a permitiendo la generaci´n de la informaci´n sensorial que se utiliza posteriormente en el o o proceso de mapeo a emociones. Servidor banco de pruebas Como alternativa se crea un banco de pruebas que act´a como “simulador del simuu lador”. Esta interfaz se dise˜a con Qt y n se conecta mediante CORBA utilizando las librerias de OmniORB al programa de dibujo gr´fico propiamente dicho.50 CAP´ ITULO 4. una interfaz gr´fica formada por barras y displays con la que se interact´a a u por medio del rat´n para generar los distintos estados mec´nicos con objeto de comprobar o a que se generan las expresiones adecuadas para cada caso. u o 4.

4.6. SERVIDOR BANCO DE PRUEBAS

51

4.6.1.

Qt

La biblioteca Qt (o simplemente Qt) es una herramienta de programaci´n para desarrolo lar interfaces gr´ficas de usuario. Una interfaz gr´fica de usuario (GUI) es un m´todo para a a e facilitar la interacci´n del usuario con el ordenador a trav´s de la utilizaci´n de un conjunto o e o de im´genes y objetos (como iconos o ventanas) adem´s de texto. Surge como evoluci´n a a o de la l´ ınea de comandos de los primeros sistemas operativos y es pieza fundamental en un entorno gr´fico. a Un poco de historia. Inicialmente Qt apareci´ como biblioteca desarrollada por Trollo tech7 en 1992 siguiendo un desarrollo basado en el c´digo abierto, pero no libre. Se us´ aco o tivamente en el desarrollo del escritorio KDE (entre 1996 y 1998), con un notable ´xito y e r´pida expansi´n. Esto foment´ el uso de Qt en programas comerciales para el escritorio, a o o situaci´n vista por el proyecto GNU como amenaza para el software libre. o Para contrarrestar ´sta se plantearon dos ambiciosas iniciativas: por un lado el equipo e de GNU en 1997 inici´ el desarrollo del entorno de escritorio GNOME con [GTK+] para o GNU/Linux. Por otro lado se intenta construir una biblioteca compatible con Qt pero totalmente libre, llamada Harmony. Qt cuenta actualmente con un sistema de doble licencia: por un lado dispone de una licencia GPL para el desarrollo de software de c´digo abierto (open source) y software libre o gratuito y por otro una licencia de pago para el desarrollo de aplicaciones comerciales. Designer Como ayuda para el dise˜o de la interfaz gr´fica con Qt se utiliza la herramienta n a “Designer”8 (Figura 4.5). “Designer” nos permite la creaci´n de di´logos interactivos con distintos objetos (baro a ras, displays . . . ). Para estos elementos se definen sus propiedades tales como el nombre, tama˜o, tipo de letra, etc. Estos son clases dentro de la aplicaci´n que estamos dise˜ando. n o n Posteriormente ser´ necesario implementar la funcionalidad mediante el c´digo que se debe a o ejecutar cuando se recibe el evento correspondiente. Resultado del trabajo con “Designer” se obtiene un archivo de extensi´n “.ui”. Utio lizando el compilador de ui (ui compiler) para generar la descripci´n de la clase “.h” y su o implementaci´n “.cpp”(*) (implementaci´n de la clase). Como la parte de Qt emplea las o o palabras clave “SLOT” y “SIGNAL” que no significan nada para C++, es necesario pasar el “.h” por el compilador de objetos de Qt MOC (Meta Object Compiler) que se encarga de crear “glue code”(*) de modo que se genera c´digo C++ correspondiente a los mecanismos o de comunicaci´n “SIGNAL-SLOT” (una especie de mapeo o traducci´n a C++). o o
7 8

www.trolltech.com http://www.trolltech.com/products/qt/designer.html

52

CAP´ ITULO 4. PLATAFORMAS SOFTWARE

Figura 4.5: Herramienta para Qt: Designer

Es necesario implementar el comportamiento de los distintos elementos del di´logo, es a decir, indicar qu´ tipo de acci´n realizar´n cuando se produzca un evento. Los archivos e o a “.cpp” descritos anteriormente son creados directamente a partir del “.ui” generado por el “Designer” por lo que no conviene tocarlos, ya que cualquier cambio que se haga en ellos se perder´ al modificar la interfaz. a El proceso seguido para la implementaci´n de la funcionalidad caracter´ o ıstica de cada elemento de la interfaz dise˜ada es crear una clase que herede de la clase generada en la n implementaci´n del ui, de modo que en esta nueva clase se definan los m´todos virtuales o e de la clase base. Una vez est´ implementada la funcionalidad es necesario pasar el “.h”(*) por el MOC e porque aparecen de nuevo mecanismos de “SIGNAL-SLOT” y es necesario generar el “glue code”(*) para que el compilador de C++ pueda entenderlo. Para generar el binario es necesario escribir la aplicaci´n principal(*), en la que se o instancia la clase derivada en un entorno de aplicaci´n de Qt. o Es momento de reunir los archivos marcados con (*), compilarlos para generar los ficheros de c´digo objeto, enlazar estos con las librerias de Qt y obtener de este modo el o binario de la aplicaci´n. o

´ 4.7. APLICACION FINAL Interfaz La interfaz dise˜ada para la aplicaci´n es la que se muestra en la Figura 4.6. n o

53

Figura 4.6: Banco de pruebas: simulador del simulador

Makefile El Makefile utilizado para la compilaci´n de la aplicaci´n dise˜ada con Qt es el siguiente: o o n Ejecuci´n o Una vez generado el binario se ejecuta y proporciona su IOR (el del servidor, para que los clientes puedan referirse a ´l directamente sin en NameService) que es necesario pasar e como par´metro a cualquier aplicaci´n cliente que quiera conectarse al servidor dise˜ado. a o n

4.7.

Aplicaci´n final o

La aplicaci´n final se dise˜a seg´n lo descrito en el cap´ o n u ıtulo 3 utilizando las librer´ de ıas Omni ORB. En los casos en los que no se conecta al robot se utiliza el banco de pruebas dise˜ado con Qt que implementa la funcionalidad del servidor que se ejecuta en la CPU de n Higgs y nos permite generar estados globales del sistema. La equivalencia de estos estados mec´nicos a estados emocionales se puede visualizar en un display mediante una cara. a

54 CAP´ ITULO 4. PLATAFORMAS SOFTWARE .

los resultados son sorprendentes.5 describe el trabajo realizado con las herramientas antes presentadas o en el desarrollo del proyecto. 5. la publicidad. El mundo del dise˜o gr´fico es un mundo fascinante.Cap´ ıtulo 5 Sistemas gr´ficos a El dise˜o gr´fico es una forma de comunicaci´n visual. audiovisuales. .6 describe la forma en la que se ha dise˜ado finalmente la parte gr´fica o n a del proyecto. Encontramos m´ltiples ejemplos n a u en el cine. Empieza con cuestiones generales sobre OpenGL para terminar describiendo la aplicaci´n realizada.2 se describen conceptos generales acerca de los gr´ficos por ordeo a nador. Se describe el trabajo realizado con Blender y Python y c´mo se ha de abandonar esa v´ al no satisfacer las especificaciones del proyecto o ıa los resultados que con ellas se pueden obtener. o a Las Secciones 5. e En la Secci´n 5. pasando por la descripci´n de las fases b´sicas presentes en el proceso de o a creaci´n de gr´ficos 3D. los v´ ıdeojuegos.4 describen dos herramientas que se utilizan en el desarrollo del proyecto: Blender y Python. Puede aplicarse a muchos medios.3. . . La Secci´n 5. digitales. Se recogen en ellas conceptos generales como qu´ son. n a o ya sean impresos. o 55 .1 se da una visi´n general de los sistemas gr´ficos y las distintas o o a aplicaciones que ´stos tienen. El presente cap´ ıtulo se organiza del siguiente modo: En la Secci´n 5. La Secci´n 5. . e algo de su historia y las caracter´ ısticas principales de cada una de ellas. desde qu´ son hasta las herramientas disponibles en el mercado para trabajar e con ellos.

5. “Buscando a Nemo” o “Los Incre´ ıbles”.2. En general. pasando por “Final Fantasy” que fue un hito en cuanto a animaci´n o o se refiere por los resultados de elevada calidad obtenidos con sus personajes. Creaci´n de gr´ficos 3D o a El proceso de creaci´n de gr´ficos 3D por ordenador se divide en tres fases b´sicas: o a a 1. hasta llegar a las ultimas pel´ ´ ıculas de Pixar.56 ´ CAP´ ITULO 5. Renderizado (creaci´n de la imagen final) o .1. Composici´n de la escena o 3. el t´rmino “gr´ficos por ordenador” se utiliza para referirse por n e a una parte al proceso de creaci´n y por otra al estudio de t´cnicas gr´ficas para el dise˜o. Modelado 2. Con el tiempo. Este campo se puede dividir en o varias ´reas: a Renderizado 3D en tiempo real (utilizado en juegos) Renderizado para creaci´n de v´ o ıdeos y pel´ ıculas Edici´n de efectos especiales (para pel´ o ıculas y televisi´n) o Edici´n de im´genes y modelado (utilizado en ingenier´ o a ıa) Inicialmente el desarrollo de los sistemas gr´ficos por ordenador tuvo lugar en entornos a acad´micos. SISTEMAS GRAFICOS 5.1. su uso en pel´ e ıculas y televisi´n demostr´ su utilidad para la o o creaci´n de efectos especiales y de animaci´n con sorprendentes resultados. Introducci´n a los sistemas gr´ficos o a Los gr´ficos por ordenador son el campo de computaci´n visual donde se utilizan ora o denadores tanto para generar im´genes de forma artificial como para integrar o modificar a informaci´n espacial y visual recogida del mundo real. Gr´ficos por ordenador a Los gr´ficos por ordenador se crean mediante la utilizaci´n de software especializado a o para el dise˜o. o e a n 5. Desde “2001: o o Una odisea del espacio” donde los efectos de gr´ficos por ordenador se creaban mediante a animaci´n manual.2.

El proceso de render necesita una gran capacidad de c´lculo. Lofter en 3D Studio) o por un o lenguaje de descripci´n de escenas (como en POV-Ray). La capacidad de c´lculo que se a puede realizar en un PC se ha incrementado r´pidamente a trav´s de los a˜os. o Composici´n de la escena. caracter´ ısticas de reflexi´n. en los dibujos animados convencionales utilizan 12 frames/segundo para reducir el n´mero de dibujos.2. Para crear la “ilusi´n o o a o de movimiento” se muestra una imagen en la pantalla del ordenador que es r´pidamente a sustituida por una nueva imagen. En animaci´n es muy frecuente utilizar la t´cnica de doble buffering para evitar el flicko e A los objetos se les puede asignar un esqueleto de modo que el movimiento del mismo afecte autom´ticamente al modelo. luminosidad. modelado con a e NURBS . Por debajo de 24 frames/segundo la a mayor´ de la gente percibe extra˜os fen´menos disminuyendo el efecto de realismo. Animaci´n o Por animaci´n se entiende la creaci´n de im´genes en movimiento. La etapa de modelado consiste en dar forma a objetos individuales que luego ser´n usados en la escena.2. . Los procesos de esta etapa pueden incluir la edici´n de la superficie del objeto o o las propiedades del material (color. agregar texturas. Sin embargo. Existen diversas t´cnicas: modelado poligonal. transparencia o u opacidad). a pues requiere simular muchos procesos f´ ısicos complejos. mapas de relieve (bump-maps) y otras caracter´ ısticas a los objetos. Por ıa n o ejemplo. Por encima de 70 frames/segundo no mejora el realismo por el modo en el que la vista y el cerebro procesan las im´genes. Esta etapa involucra la distribuci´n de objetos.´ 5. similar a la anterior pero ligeramente modificada. o El modelado puede ser realizado por programas dedicados (como Lightwave 3D. las im´genes deben dibujarse a 24 frames por segundo o m´s r´pido (un “frame” es un a a a imagen completa). luces. . a 1 . e Renderizado. a 5. Para enga˜ar a la vista y al cerebro. GRAFICOS POR ORDENADOR 57 Modelado. o o c´maras y otras entidades en una escena que ser´ utilizada para producir una imagen a a est´tica o una animaci´n. haci´ndoles creer que se est´ viendo un objeto en movimienn e a to. permitiendo a e n un grado superior de realismo en los gr´ficos 3D. Rhinoceros 3D o Moray). un componente de una aplicaci´n (Shaper.2. a o La iluminaci´n es un aspecto especialmente importante de la composici´n de la escena: o o contribuye al resultado est´tico y a la calidad visual del trabajo. los gr´ficos por ordenador necesitan de tasas mayores u a para mejorar el realismo de la imagen. Se llama render al proceso final de generar la imagen o animaci´n a o partir de la escena creada. Tambi´n pueden incluir algunas actividades relacionadas con la preparaci´n del e o 1 modelo 3D para su posterior animaci´n .

muy caros en general. . con caracter´ o ısticas como soporte para programaci´n bajo Python. DeepPaint . SISTEMAS GRAFICOS ering (parpadeo) originado porque la pantalla se borra y se redibuja de forma constante.3. Existe tambi´n alguna e alternativa libre a los mismos como es el caso de Blender. en el que el ordenador dibuja la imagen haciendo los cambios necesarios antes de mostrarla. n a . . que disminuye el efecto perseguido por la animaci´n.58 ´ CAP´ ITULO 5. . Cuando la imagen se completa. Este proceso puede hacerse de dos formas: el contenido del buffer secundario se copia en el primario se intercambian los buffers primario y secundario (de forma que el primario pasa a secundario y viceversa) Este cambio debe hacerse de forma imperceptible para el usuario o de otro modo se produce la llamada ruptura de la imagen. lo que se muestra en pantalla es el contenido del buffer primario. Herramientas Para el dise˜o gr´fico en sus distintas fases(modelado. Blender Blender es un programa de modelado y animaci´n libre (gratuito). Maya o LightWave. . o Entornos integrados para todos los procesos. • render: YaFray. .3. ) existen en el n a o mercado multitud de herramientas: Herramientas especializadas en ciertos procesos como por ejemplo: • modelado: Rhino3D. • animaci´n: Pose. . pero es una herramienta o de gran potencia para el dise˜o gr´fico. . 3DLight .2. 5. . o 5. • texturizado: UVMapper. Mientras tienen lugar los cambios. . AnimationMesher . . Este es el caso de los conocidos 3DStudio Max. la “ilusi´n de movimiento”. Lightwave o Maya. se dibuja en pantalla el contenido del buffer secundario. animaci´n. El proceso que se sigue es el siguiente: cuando la imagen se renderiza se hace en el llamado buffer secundario. Es mucho menos conocido que otros proo gramas para animaci´n 3D. Wings3d . como 3DStudio. SoftImage. o es decir.

1).3. FreeBSD y Mac OS X bajo la GNU Public License).blender.5. o u Por tanto. Irix. 2 3 M´s informaci´n sobre la evoluci´n de blender en www. Tom Roosendaal. Roosendaal cre´ la “Fundaci´n Blender” (sin ´nimo o o a de lucro) para recoger donaciones.1: Captura de pantalla de Blender 2. Linux.000e. La o ultima versi´n. el principal autor. fund´ la empresa “Not o e o a Number Technologies” (NaN) en junio de 1998 para desarrollar y distribuir el programa. BLENDER Un poco de historia 59 Originalmente el programa fue desarrollado como una aplicaci´n propia por el estudio o de animaci´n holand´s NeoGeo. el 7 de septiembre se anunci´ que se habia reunido el o dinero necesario para liberar Blender y el c´digo fuente se hizo p´blico el 13 de octubre. Sun Solaris.org a o o www.36 (Figura 5. La compa˜´ lleg´ a la bancarrota en 2002 y los acreedores acordaron ofrecer Blender nıa o como un producto de c´digo abierto y gratuito bajo los t´rminos de la GNU GPL a cambio o e de 100. est´ disponible en la web3 para instalar en ´ o a los distintos sistemas operativos (tiene versiones para Windows.org . que el c´digo fuente del programa est´ disponible o a para examinarlo y generar mejoras a este para su inclusi´n en las nuevas versiones2 . es decir. El 18 de julio de 2003. Blender 2.36 Como ejemplo de su buen estado se puede se˜alar que se ha utilizado como una de las n herramientas de animaci´n para la pel´ o ıcula “Spiderman 2”. Blender es Open Source.blender3d. Figura 5.

v´rtices de carga y part´ e ıculas est´ticas y din´micas. SISTEMAS GRAFICOS Las caracter´ ısticas principales de esta herramienta de dise˜o gr´fico son: n a Es multiplataforma. recreaciones o din´micas y l´gica) a o Posibilita un renderizado interno vers´til y la integraci´n externa con el potente a o trazador de rayos libre de YafRay. o IFF. Tambi´n posee otros que proporcionan E/S de ficheros. Tambi´n puede leer a e ficheros Inventor. gratuita y con un tama˜o de origen realmente peque˜o n n (alrededor de 5 MB dependiendo del sistema operativo) Permite utilizar una gran variedad de primitivas geom´tricas. JPG. Posee caracter´ ısticas interactivas para juegos (detecci´n de colisiones.60 Caracter´ ısticas ´ CAP´ ITULO 5. incluyendo curvas. SGI. NURBS. 5. En 1995 continu´ su o 4 www. Mediante el lenguaje Python se pueden automatizar o controlar distintas tareas Acepta formatos gr´ficos como TGA. Python Python es un lenguaje de programaci´n de scripts (script es el nombre que se da o a un archivo. a a Permite la edici´n de audio y sincronizaci´n de v´ o o ıdeo. Dispone de una gran colecci´n de m´dulos est´ndar que se pueden o o a utilizar como base de los programas (o como ejemplos para empezar a aprender Python). male las poligonales. que contiene instrucciones.4.nl . metaballs (objetos de tres dimensiones con caracter´ ısticas f´ ısicas del mercurio) Junto a las herramientas de animaci´n se incluyen cinem´tica inversa. Permite dividir el programa en m´dulos reutilizables e o desde otros programas. o conjunto de archivos. deformaciones o a por armadura o cuadr´ ıcula. sockets y hasta e interfaces GUI (Interfaz Gr´fica con el Usuario).cwi. llamadas al sistema. Iris. y que necesita de un programa int´rprete para ejecutarse). a Un poco de historia Python fue creado como sucesor del lenguaje ABC por Guido van Rossum en 1990 cuando trabajaba en el Stichting Mathematisch Centrum (CWI)4 . libre.

n Caracter´ ısticas Las caracter´ ısticas principales de Python son: Es un lenguaje de alto nivel sencillo.5. . Esto facilita experimentar con e caracter´ ısticas del lenguaje. . escribir programas desechables o probar funciones durante el desarrollo del programa.5.python.5. Linux. PythonLabs pasa a Digital Cren ations (actualmente Zope Corporation).1. En mayo del o 2000 Guido y el equipo de desarrollo de Python se trasladan a BeOpen.org a o 6 5 .cnri. potente y r´pido que est´ en constante creca a 7 imiento .va. El int´rprete se puede utilizar de modo interactivo. Trabajo con Blender y Python Criterios de selecci´n o Se eligi´ Blender como herramienta para el dise˜o y la animaci´n del modelo facial que o n o es objeto de este proyecto por tres motivos fundamentales: Es libre (se dsitribuye bajo la GNU Public License) Es multiplataforma (existen versiones para Windows. TRABAJO CON BLENDER Y PYTHON 61 trabajo en Python en el CNRI5 donde cre´ muchas versiones del lenguaje.5. El principal objetivo que persigue este lenguaje es la facilidad. Es un lenguaje interpretado. e ´ 5.us M´s informaci´n en la p´gina web www.python. se crea la “Python Software Foundation” (PSF)6 . En octubre de este mismo a˜o.org/psf/ a o a 7 M´s informaci´n en www. o El nombre del lenguaje proviene de la afici´n de su creador original por los humoristas o brit´nicos Monty Python. lo que ahorra un tiempo considerable en el desarrollo del programa pues no es necesario compilar ni enlazar.com y se forma el BeOpen PythonLabs. una organizaci´n sin ´nimo de lucro que surge espec´ o a ıficamente para proteger la libertad de Python como lenguaje de c´digo abierto. ) www. 5. Tambi´n es una calculadora muy util. Se dice que un lenguaje es interpretado si sus instrucciones se ejecutan secuencialmente a partir del c´digo fuente o (el int´rprete va recibiendo l´ e ıneas de c´digo que traduce a c´digo m´quina para que o o a se ejecuten). a tanto de lectura como de dise˜o.reston. En 2001. Mac OS X.

Una vez alcanzado el dominio suficiente de la herramienta se comenz´ con el dise˜o o n de la cara antropom´rfica para el proyecto. congelado desde la versi´n 2. Una de las creaciones de esta etapa de aprendizaje puede verse en la Figura 5. Como apoyo en este proceso de a aprendizaje se utilizaron los recursos disponibles en la red as´ como la “Gu´ oficial ı ıa de Blender” [Roosendaal and Selleri. El game engine permite la interacci´n con el o programa en tiempo real y esto es una caracter´ ıstica necesaria para la implementaci´n o del software que es objeto de esta memoria. El objeto a crear es una cara antropom´rfica que posteriormente habr´ de animarse. La m´s n a interesante de ellas desde el punto de vista de la animaci´n es que el motor de juegos o (game engine).2: Ejemplo de modelado con Blender: “Ginger” Es un entorno integrado para la animaci´n gr´fica (con la misma herramienta podeo a mos trabajar en las distintas etapas del dise˜o grafico: modelado.5. una de frente y otra de perfil (Figura 5. Prototipo Blender * Aprendizaje de la herramienta. Se construy´ una cara mediante puntos utilizando como soporte dos o imagenes de una cara. o * Modelado. Por este motivo antes de empezar con la construcci´n del modelo de n a o la cara se construyeron otros elementos m´s simples.2.3).62 ´ CAP´ ITULO 5. SISTEMAS GRAFICOS Figura 5.34 (agosto de 2004). El motivo por el . a˜adiendo prestaciones a la herramienta. volvi´ a formar parte de Blender o o a partir de la 2. texturizado y anin maci´n) o 5. Blender es una herramienta muy potente con un entorno de ventana muy distinto del usual. Durante el desarrollo de este proyecto la versi´n o de Blender ha cambiado varias veces. o a pero el primer paso en este proceso es familiarizarse con la herramienta. 2004].2.28. muy distinto incluso de los entornos de ventana de otras aplicaciones similares dedicadas al dise˜o gr´fico.

Figura 5. TRABAJO CON BLENDER Y PYTHON 63 cual se utilizaron como referencia fue por cuesti´n de proporciones ya que el objetivo o es crear una cara antropom´rfica de apariencia normal. El resultado final del proceso de o modelado esta formado por unos 500 puntos y puede verse en la Figura 5.5. se ejecuta y se abre una ventana con la escena renderizada. m´s pol´ a a ıgonos y mayor definici´n. El usuario se comunica con el programa v´ teclado y rat´n (como ıa o Blender hace un uso intensivo de de los mismos. Cuantos m´s puntos. El men´ de Blender correu spondiente al renderizado permite definir algunas opciones tales como el tama˜o de n la ventana en la que veremos el resultado (Figura 5. Despu´s del proceso de modelado y composici´n se puede generar e o la imagen final. La escena por defecto de Blender trae una luz y una c´mara (ver Figura 5. o Los puntos que definen la cara se unen formando triangulos o cuadrados (la forma o ´ptima para facilitar el posterior proceso de renderizado es la triangular).6). El unico objeto de la escena es la cara creada en el a ´ proceso de modelado.7. es decir. Blender dispone de distintos tipos de luces y de un men´ en u el que definir los par´metros de las mismas (ver Figura 5.5).7). Es poco intuitiva pero al mismo tiempo muy eficiente y productiva una vez se llega a conocer. Una vez seleccionado como se quiere que se realice el render. que nos sirven para la escena sencilla que se est´ creando. Aprovechando la simetr´ de o ıa la cara se modela la mitad y mediante proyecci´n especular generamos la otra mitad. se puede renderizar la escena. las luces o o y las c´maras en la escena. existe una “regla de oro” com´n u entre los usuarios de Blender: ¡mant´n una mano sobre el teclado y la otra sobre el e . Es necesario poner en a la escena al menos una luz y una c´mara ya que de otro modo no se ver´ nada al a ıa renderizar en el paso siguiente. o a Blender tiene una peculiar interfaz gr´fica de usuario como puede verse en la Figura a 5. * Dificultades en la creaci´n gr´fica con Blender. a a * Renderizado.5.4. El tema de iluminaci´n es muy importante para el realismo o de la imagen generada.3: Im´genes auxiliares para el dise˜o de la cara a n * Composici´n. Es momento de determinar la distribuci´n de los objetos.

5: Men´ para la iluminaci´n de Blender u o .4: Dise˜o con Blender de una cara antropom´rfica n o Figura 5.64 ´ CAP´ ITULO 5. SISTEMAS GRAFICOS Figura 5.

Blender ofrece esa posibilidad (Mesh Undo). La interfaz de Blender hace uso de los tres botones del rat´n y de un amplio o o rango de teclas r´pidas. TRABAJO CON BLENDER Y PYTHON 65 Figura 5. e Si se quiere “deshacer” una acci´n.5. a Los resultados de elevada calidad8 hacen que el esfuerzo en dominar la herramienta est´ recompensado ampliamente por los resultados que se pueden obtener.7: Escena por defecto de Blender rat´n! ). pero o 8 En www.org se encuentra una galer´ de im´genes creadas con Blender ıa a .6: Men´ para el renderizado de Blender u Figura 5.blender3d.5.

siempre y cuando o o ´ se est´ trabajando con ella. SISTEMAS GRAFICOS Figura 5. tambi´n sirve para modelar y animar. Animaci´n o Dejando a un lado los procesos de texturizado (le dan realismo a la im´gen pero es a secundario para los objetivos que persigue este proyecto).3. pero en la mayoria de los casos. Esto tiene sus ventajas en las ocasiones en las que se comete un error que no se puede deshacer. o Debido a que el objetivo del proyecto es que la cara se mueva seg´n lo requiera un programa u externo a Blender es necesario que utilicemos Python como interfaz entre ellos. como se explic´ antes.66 ´ CAP´ ITULO 5. 5. de modo que si no se ha guardado previamente el trabajo realizado se perder´ todas las modificaciones posteriores realizadas tras “salvar” por ultima ıan ´ vez. Ha de usarse de forma conjunta al game engine ya que. esta peculiaridad del programa es un inconveniente. Python no s´lo se utiliza o en el game engine. se pasa al proceso de animaci´n. o Otra caracter´ ıstica de esta herramienta es que no solicita confirmaci´n para cerrar la o ventana de dibujo. Esto dificulta el proceso de modelado ya que hay errores e que una vez cometidos no pueden subsanarse y la unica opci´n en estos casos es ´ o volver a una versi´n guardada del trabajo o volver a empezar.8: Algunas opciones de Blender s´lo funciona para mallas en modo edici´n y para una unica malla. es el unico modo que o ´ existe para que podamos interactuar con Blender en tiempo real.5. e .

. expresiones. OR. mediante un script actuando como controlador en el game engine. a * Proceso de animaci´n. . Haciendo un s´ ımil se puede decir que los sensores act´an como los sentidos. a El modo en que actua el game engine es el siguiente: se le asocia un sensor a un objeto. Se crea una estructura cliente/servidor. o Es necesario comunicar Python con otro programa (el cliente CORBA descrito en el Cap´ ıtulo 3) que se ejecuta dentro de la misma m´quina. TRABAJO CON BLENDER Y PYTHON 67 * Game engine . Como los dos programas se ejecutan en la misma m´quina en principio pueden a usarse los sockets unix que son m´s r´pidos que los inet. Para conectar cliente y servidor se utilizan sockets. En el game engine existen tres partes: los sensores. Existen muchos tipos de sockets. sonido . De modo que los sensores reaccionan ante un evento. propiedades. Se eligen los sockets para a la comunicaci´n de ambos. teclado. los controladores y los actuadores. ). el cliente Python que e o lo recoge y se lo comunica al tercer elemento. El cliente es el o programa en Python y el servidor es el programa CORBA (que est´ escrito en C++). ). Figura 5. Relacionado con ese sensor existe un controlador que se une al actuador (Figura 5. scripts de Python9 ) y actuadores o (movimiento.9). Es el motor de juegos de Blender. Existen distintos tipos de sensores (“always”. y los actuadores realizan la acci´n sobre los objetos. para en el ultimo momento ´ desarrollar la aplicaci´n mixta en la que el cliente es Python y el sevidor es C++. .5. pero debido a que Python a a no posee implementaci´n para esta clase de sockets se trabaja con los inet. los controladores como el cerebro y los actuadores como u los m´sculos. los de uso mas extendido son los sockets unix y los inet. .9: Men´ game engine de Blender u * Python. o 9 Permiten generar un comportamiento m´s completo a . Permite la interacci´n con el o programa en tiempo real. Blender. de controladores (AND. los controladores u recogen los eventos de los sensores y calculan el resultado. Dependiendo del tipo de sensor elegido se disparar´ en un momento o en otro a (el “always” cada cierto tiempo. el “keyboard” cuando se produzca un evento por teclado . El script de Python se encarga de dos cosas: por un lado de interactuar con Blender y por el otro de recoger los datos que indican c´mo debe cambiar la imagen. . Se crean o prototipos de cliente/servidor en C++ y en Python. Para el proceso de animaci´n es necesario unir tres eleo o mentos: el servidor CORBA que indica qu´ expresi´n poner. o rat´n. c´mara. . ).5.

el camino que toma el proyecto a partir de este punto es utilizar para el dise˜o n y la animaci´n OpenGL directamente. las operaciones se complicaban. se decide recurrir o o directamente a OpenGL para resolver el problema planteado. si se dispone de una tarjeta aceleradora. o 5. tras la experiencia con Blender. OpenGL es una librer´ de funciones que permite visualizar gr´ficos 3D en nuestra apliıa a caci´n. La gran ventaja de esta librer´ es que aisla la aplicaci´n del hardware disponible. lo primero es explorar las caracter´ ısticas del game engine para poder utilizarlo para los objetivos del proyecto. no har´ falta cambiar el programa para a aprovechar la potencia de la tarjeta. Se realizaron pruebas con figuras sencillas.6. o 5. para el desarrollo completo de la aplicaci´n. SISTEMAS GRAFICOS * Dificultades para la animaci´n con Blender y Python. o ıa o por tanto. girar un objeto seg´n los ´ngulos de Euler).5. o o Blender es una herramienta muy potente pero no es lo suficientemente flexible.68 ´ CAP´ ITULO 5. por lo que viene provista de funciones f´ a n ısicas tales como gravedad o colisiones entre objetos.4. por lo que en este punto se abandon´ el camino basado en Blender para el desarrollo de la aplicaci´n. De modo similar al o proceso de modelado. Comenzaron a surgir problemas ya que las operaciones que se pueden realizar a los objetos con el game engine son limitadas: no todas las operaciones que se pueden hacer con los objetos tienen su equivalente para el game engine (como por ejemplo. Librer´ adicionales de OpenGL ıas La librer´ principal de OpenGL suministra todas las funciones necesarias para mostrar ıa un entorno 3D aunque hay algunas operaciones que son algo tediosas de realizar utilizando . Esta funcionalidad de Blender u a est´ pensada para el dise˜o de juegos. OpenGL Debido a los problemas encontrados al realizar el modelado y animaci´n de la aplio caci´n objetivo del presente proyecto descritas en la secci´n anterior. Se descarta recurrir a otra herramienta gr´fica ya que. Conclusiones Como quiera que Blender es una herramienta de dise˜o gr´fico integrada cuya misi´n n a o es facilitar la creaci´n de gr´ficos que no se adapta a las necesidades de este proyecto y o a que no es m´s que un programa dise˜ado sobre la librer´ de dise˜o grafico por excelencia a n ıa n (OpenGL). Las pruebas con objetos sencillos no daban los resultados esperados. es claro que esta aplicaci´n a o tiene unas caracter´ ısticas muy especificas que son poco comunes en el mundo del dise˜o n grafico (interactuar en tiempo real utilizando otra aplicaci´n como fuente de eventos ante o los que reaccionar).

ıa a . su creador Mark Kilgard sigue manteniendo el copyright. La librer´ GLX es la utilizada para trabajar en un sistema de X-Windows (GNU/Linux). ıa a n OpenGL est´ formado por aproximadamente 250 comandos de los cuales unos 200 a corresponden al n´cleo de OpenGL y los restantes a GLU.. En 1982 naci´ en la Universidad de Standford el concepto de graphics machine o y este fue utilizado por Silicon Graphics Corporation en su propia estaci´n Silicon IRIS o para crear un renderizador. A ra´ de esto. (OpenGL es una librer´ gr´fica. hoy d´ es uno de los m´s conocido a a ıa a del mundo. ıa permite no s´lo renderizar en la m´quina local. GLUT proporciona una API u que facilita enormemente el aprendizaje de la programaci´n con OpenGL. Es necesario descargar e instalar el paquete para poder utilizarlo. OPENGL solo esta librer´ Para esto existen tambi´n unas librer´ auxiliares: ıa. a trav´s a a e de la ejecuci´n de comandos de m´s bajo nivel pertenecientes a la librer´ OpenGL o a ıa propiamente dicha. sino tambien a traves de red.6. no fue dise˜ada para eso). GLUT nos permite crear ventanas y controlar la entrada independientemente de la plataforma utilizada La librer´ GLAUX. en 1992. Entre estas empresas destacaban Silicon Graphics Inc. e ıa 69 La librer´ GLU (OpenGL Utility Library) es una librer´ de utilidades que proporıa ıa ciona acceso r´pido a algunas de las funciones m´s comunes de OpenGL. Se recomienda o su uso para aquellas aplicaciones que no requieran interfaces muy sofisticadas ya que para esos casos es mejor utilizar las herramientas del sistema de ventanas que estemos utilizando (para Windows se usa la libreria GLAUX y para X-Windows la libreria GLX ).. Al descomprimirlo aparece un archivo “readme” en el que se detallan los pasos a seguir para su instalaci´n dependiendo de la o plataforma en la que se est´ trabajando.5.. As´ nacio la librer´ IRIS GL. Mantiene practicamente la misma estructura que la librer´ GLUT con ıa el defecto de que solo es aplicable para Windows.. Un poco de historia OpenGL es un est´ndar sobre gr´ficos por ordenador. La librer´ GLUT (OpenGL Utility Toolkit) es un paquete auxiliar que proporciona ıa una interfaz independiente de la plataforma para crear aplicaciones de ventanas totalmente portables. La versi´n de GLUT utilizada en el presente e o proyecto es la 3. GLUT no es OpenSource. red. es la que Microsoft ha desarrollado para ıa Windows. o a Tambi´n hay otras librer´ m´s espec´ e ıas a ıficas para el control de entrada. muy parecida a GLUT. sonido. muchas ı ıa ız empresas del hardware y software se pusieron deacuerdo para desarrollar conjuntamente una librer´ gr´fica libre: OpenGL. mientras que GLUT sirve para cualquier plataforma.6.

Activarlas supone a que el renderizado sea m´s lento pero m´s realista. una serie de a˜adidos sobre las funcionalidades b´sicas. Las primitivas a geom´tricas con las que se construye cualquier objeto en OpenGL son puntos. Caracter´ ısticas Entre las caracter´ ısticas de OpenGL podemos destacar que: Es multiplataforma. OpenGL funciona como una m´quina de estados. que en su conjunto crean lo que se suele llamar “OpenGL Rendering Pipeline” (Figura 5. lo que proporciona gran potencia y flexibilidad a la hora de programar. por lo que el orden en el que se a realizan las operaciones es importante. Sus variables de estado tienen unos valores por defecto que podemos modificar para adaptarlos a la aplicaci´n que estemos desarrollando. la estructura b´sica puede sintetizarse a en dos ideas: Inicializaci´n de ciertos estados que controlan como renderiza11 OpenGL o especificar los objetos que han de renderizarse OpenGL Rendering Pipeline La mayor parte de las implementaciones de OpenGL siguen un mismo orden en las operaciones. IBM Corporation. Un programa en OpenGL puede ser complicado.10). Intel e Intergraph Corporation. M´s informaci´n acerca de OpenGL en www. Su escalabilidad ha permitido que no se haya estancado su desarrollo. Inicialo mente la mayoria de estas variables de estado est´n desactivadas. La gesti´n de la generaci´n de gr´ficos 2D y 3D se realiza por hardware ofreciendo o o a al programador una API sencilla.opengl.org a o Renderizado es el proceso en el cual el ordenador crea im´genes de modelos u objetos. El orden de las acciones resulta cr´ ıtico en la mayoria de las ocasiones. o Las operaciones se puden agrupar en jerarquias. Es necesario un compromiso entre a a ambos para obtener los resultados deseados. Sun Microsystems. As´ naci´ OpenGL (Open ı o Graphics Library). Hewlett-Packard Corporation. l´ e ıneas y pol´ ıgonos y vienen definidos por sus v´rtices e 11 10 . Digital Equipment Corporation (DEC). estable y compacta. permitiendo la creaci´n de extensiones. o n a 10 para aprovechar las crecientes evoluciones tecnol´gicas . SISTEMAS GRAFICOS Microsoft.70 ´ CAP´ ITULO 5.

las perfragment operations. Aqu´ es donde se aplican las transformaciones ı geom´tricas como rotaciones.). que son complementarios y pueden emitirse a la vez por la misma fuente. el blending. por cada v´rtice. Luego. Una fuente puede emitir distintos tipos de luz. Aqu´ los pixels son desempaquetados a ı desde alg´n array del sistema (como el framebuffer ) y tratados (escalados. Todas estas operaciones desembocan en el framebuffer. Aqu´ es donde se tiene en cuenta el modelo a ı de sombreado. OPENGL 71 Figura 5. la anchura de las l´ ıneas o el antialiasing. el z-buffering. En la ultima etapa. si u estamos tratando con texturas. se preparan eln la seci´n texture assembly. dividido en las tres componentes de color RGB.6. Los tipos de luz son: .10: OpenGL Rendering Pipeline Sobre el vertex data se pueden aplicar evaluators para describir curvas o superficies parametrizadas mediante puntos de control. etc. Luego se aplican las pre-vertex operations que convierten a los vertices en primitivas. En la secci´n primitive e e o assembly se elimina lo que queda fuera del plano de proyecci´n. o Ambos caminos convergen en la rasterization donde son convertidos en fragmentos. la “fog” (niebla). etc. emite un haz de un color o determinado. Iluminaci´n o La iluminaci´n en OpenGL permite crear escenas m´s realistas. Una fuente de luz es la entidad que aporta luz a la escena. es donde se preparan los texeles (el´ ementos de textura) para ser aplicados a cada pixel. etc. se basa en luces y o a materiales. Una luz es una fuente de iluminaci´n sobre la escena.5. Un material determina la cantidad de cada color que refleja un objeto determinado. o Por la parte de pixel data est´n las pixel operations. Cada fragmento ser´ un pixel del framebuffer. donde obtenemos el render final. traslaciones.

Las normales son salientes por la parte delantera de la cara. Cada vez que se va a renderizar un pixel. o Utiliza el c´digo de Waters para desarrollar una aplicaci´n llamada “Facial Simulator” soo o bre Windows utilizando las librer´ MFC de Microsoft. No se ve afectada por ning´n otro tipo de luz. o a a Este algoritmo funciona bien para cualquier tipo de objetos: c´ncavos. por cada v´rtice se o e e calcula su color a partir del material activo. OpenGL no genera aua tom´ticamente las normales.72 ´ CAP´ ITULO 5. Una vez incida sobre un objeto se refleja en todas las o direcciones. 5. de modo que hay que especificarselas a 12 . ı o La iluminaci´n con OpenGL se calcula a nivel de v´rtice. Es algo as´ como la iluminaci´n global de la escena. especular: es la luz que al incidir sobre un objeto. etc. ambiental: a esta categor´ corresponde el resto de luz que aparece debido a la reıa flexi´n residual de la luz que ya se ha reflejado sobre muchos objetos.5. Esta aplicaci´n consiste en una ıas o interfaz gr´fica formada por dos partes: una cara y los controles para cambiarla por medio a Excepto para renderizar NURBS y otras funciones gr´ficas de alto nivel. abiertos o y cerrados. Se emplean las normales de los vertices (vector perpendicular a la cara e que se esta dibujando). u difusa: es la luz que incide sobre un objeto y proviene de un determinado punto. Es la luz que produce los brillos. Trabajo con OpenGL Para el modelado de la cara. convexos. teniendo en cuenta que debe posiblitarse la animaci´n o posterior. es decir. El modelo de Waters se o basa en la animaci´n utilizando m´sculos como describe la Secci´n 2. o u o La aplicaci´n se construye basandose en el trabajo desarrollado por Varian Qua [Qua. Por defecto la parte delantera de la cara es aquella en que sus vertices se dibujan en sentido antihorario (aunque esto puede cambiarse modificando el valor de la variable de estado correspondiente). direcci´n. La intensidad con la que se refleja en la superficie del objeto puede depender del ´ngulo a de incidencia.7. comprueba que no haya dibujado antes en ese pixel una posici´n que este m´s cerca repecto a la c´mara. se utiliza como base el denominado “c´digo de Waters”. las luces activas y c´mo estas luces inciden o 12 sobre el v´rtice. SISTEMAS GRAFICOS emitida: luz emitida por un objeto. se ve reflejada con un ´ngulo similar a al de incidencia. 2002]. Z-Buffer El z-buffer o buffer de profundidad es un algoritmo que sirve para determinar los puntos que se dibujan en la pantalla. y es imposible o determinar su procedencia.

De modo que podemos disponer de m´ltiples u u caracteres definidos cada uno de ellos por dos archivos. lee los puntos y los dibuja en la pantalla utilizando los com´ndos de OpenGL. .11: Aplicaci´n “Facial Simulator” para Windows o del rat´n para generar distintas expresiones en la misma. . GLU y GLUT. El programa abre los archivos.5. La reutilizaci´n que este proyecto hace del c´digo consiste en uso de la estructura o o en que se organiza el programa y las funciones generales para dibujar vertices. .11. La aplicaci´n est´ construida de tal modo que la cara y los m´sculos son datos que est´n o a u a en un archivo. Esta interfaz puede verse en la o Figura 5. calcular normales. TRABAJO CON OPENGL 73 Figura 5. o Tambi´n es necesario dise˜ar de nuevo toda la parte de animaci´n para adecuarla a los e n o objetivos de este proyecto. De este modo se podr´ utilizar este programa para a a generar caras distintas que vienen determinadas por dos archivos: uno en el que se especifica la posici´n de los puntos de la cara y otro en el que se especifica la posici´n y zona de o o influencia de los m´sculos sobre la misma.7. redise˜ando la parte de OpenGL para que no dependa del sistema de ventanas n en el que se ejecute la aplicaci´n utilizando exlusivamente las librerias GL.

) o 2. Un esquema sencillo que deben seguir los programas en OpenGL es: 1. composici´n o de la escena y su posterior animaci´n. .12). Desactivar las acciones propias de ese objeto (volver a la posici´n inical. p´gina de referencia obligada para OpenGL a . 5. El primer paso para poder desarrollar la aplicaci´n es familiarizarse con la filosof´ y sintaxis que utiliza OpenGL. ) para que no afecten a objetos que se dibujen posteriormente. Lo primero o que se hizo fue aprender a dibujar una ventana. ´ OpenGL es una m´quina de estados y. o 13 http://nehe. Creaci´n gr´fica o a * Aprendizaje de la herramienta. el orden en el que a se realizan las operaciones es cr´ ıtico en muchos casos.74 ´ CAP´ ITULO 5.net. Concluido este proceso de aprendizaje se pasa al modelado de la cara. Dibujar el objeto. SISTEMAS GRAFICOS Figura 5.7.gamedev. . o 3. Se comenz´ dibujando cosas sencillas para luego ir complicando la escena.12: Ejemplo con OpenGL 5. a activar la iluminaci´n global . . como se ha indicado antes. volver al punto 2 hasta haber dibujado todos los objetos. Activar las opciones que van a ser persistentes en la escena (poner la c´mara. Activar las opciones que establecen el estado de un objeto espec´ ıfico como la posici´n en el espacio o la textura. Despu´s se dibujaron formas y se les e aplic´ color (un ejemplo puede verse en la Figura 5. 4. Por ultimo se hicieron pruebas para aplicar texturas. desactio var su textura . Los recursos o ıa utilizados en esta etapa fueron el “Redbook”[Woo et al. .. Tambi´n se dibujaron figuras o e y se rotaron.1. 1999] y los tutoriales de NeHe13 .

4 del presente documento).15). Se encargan de leer los archivos correspondientes y dibujar mediante las primitivas de OpenGL la informaci´n que proporcionan en la pantalla.La representaci´n que se va a utilizar es la generada mediante pol´ o ıgonos.. int normals). a o o Deben posibilitarse tambi´n las posteriores tareas de animaci´n de la misma (como e o ya se indic´ en la Secci´n 2.14). TRABAJO CON OPENGL 75 Figura 5. La visualizaci´n del color depende del tipo de luces que iluminen la escena o como se ha indicado anteriormente en el presente cap´ ıtulo. o La cara se puede generar mediante l´ ıneas (Figura 5.13: Modelado de la cara con l´ ıneas * Modelado.13) o mediante pol´ ıgonos (Figura 5. y void paint muscles (HEAD *). El objeto que se est´ modelando para esta aplicaci´n es una cara antropom´rfica. Los prototipos de estas funciones son: void paint polygons (HEAD *face. la que dibuja los pol´ ıgonos de la cara y la que se encarga de dibujar la estructura muscular (que es la que se utiliza para animar la cara). El esquema de color seleccionado para la aplicaci´n es el o RGBA. Para aumentar el realismo de la im´gen dise˜ana se les aplica color a n a los pol´ ıgonos de la cara.5. int type. Por eso en esta parte se habla o o de dos funciones. . La realizada mediante l´ ıneas es interesante para ver la disposici´n de los m´sculos o u (Figura 5.7.

15: Distribuci´n de los m´sculos en la cara o u .14: Modelado de la cara con pol´ ıgonos Figura 5.76 ´ CAP´ ITULO 5. SISTEMAS GRAFICOS Figura 5.

7. 1. de estructura claramente definida: o ◦ Inicializaci´n de los modos con los que se crear´ la ventana como por ejemplo o a los buffers que utiliza. .0 }.8.h ya que esta asegura que las otras dos son incluidas. • Funci´n principal.h pero si el programa utiliza glut solo es necesario incluir glut. Este proceso se realiza en el programa principal. 0. Para configuraciones o de luces y materiales m´s complejas que las que se usan en esta aplicaci´n es a o conveniente crear un fichero llamado “iluminacion. int. Su estructura es la siguiente14 : • Declaraci´n de las cabeceras de las librerias necesarias para la parte gr´fica o a (Son necesarias gl.8. float ambient_light[] = { 0.9.3.5. glutInitDisplayMode(GLUT_RGBA|GLUT_DOUBLE|GLUT_ALPHA|GLUT_DEPTH). se situan las luces. TRABAJO CON OPENGL * Composici´n.h> #include"Head.h" • Declaraci´n de las variables globales que se van a utilizar en el programa. int). void paint_polygons(HEAD *.0 }. y poner las tres ser´ dar informaci´n redundante) y dem´s librer´ de car´cter general que ıa o a ıas a se necesiten as´ como las espec´ ı ıficas del programa que se esta dise˜ando.3. o 77 En esta etapa se construye la escena: se colocan los objetos.h y glu. 0. 70. n #include <GL/glut. 0. argv). como por ejemplo dibujar los o pol´ ıgonos de la cara o pintar los m´sculos: u void paint_muscles(HEAD *).h> #include <stdlib. glutInit(&argc. float light_pos[] = { 30. 0. ◦ Establecer el tama˜o y posici´n de la pantalla n o 14 Se ponen trozos de c´digo a modo de ejemplo o .h> #include <unistd.0. • Declaraci´n de las funciones que se van a utilizar en el programa (y que est´n o a definidas en otro archivo del c´digo fuente). 100.0. 1. float source_light[] = { 0.h> #include <stdio. como o por ejemplo las relativas a las luces (tipo de luz o posici´n). 1.45.h” en el que se definan las luces que se van a utilizar en la escena as´ como los distintos tipos de materiales ı e incluir en el programa principal la cabecera correspondiente.0.0 }. . el m´s importante por temas de animaci´n es el a o GLUT DOUBLE que indica que se usa doble buffer para evitar el flickering.

glutCreateWindow("myFacE"). ◦ ◦ ◦ ◦ ◦ • Definici´n de las funciones que dibujan cada frame. En o o nuestro caso se utiliza la captura de eventos por teclado para hacer pruebas previas a la aplicaci´n final (utiliza el mecanismo de CALLBACK). . glutDisplayFunc(&DrawGLScene). Llamada a la funci´n que dibuja cada frame (utiliza el mecanismo de CALLo BACK). 480). glutInitWindowPosition(0. entre frames. Este nombre saldr´ siempre y cuando no hagamos una llamada a la funa ci´n glutFullScreen() que maximiza la ventana a todo el ´rea disponible o a ocultando el nombre de la ventana. if(key==ESCAPE){ . Llamada a la funci´n que hace modificaciones entre frames necesaria para o las animaciones. La funci´n a la que llama utilizando CALLBACK debe intercambiar los o buffers para evitar el parpadeo. glutIdleFunc(&idle_function).78 ´ CAP´ ITULO 5. o glutKeyboardFunc(&keyPressed). int x. Recoge las operaciones que se realizan entre una frame y la siguiente que hacen que la escena vaya cambiando (utiliza el mecanismo CALLBACK). Esto se hace mediante la funci´n o de GLUT glutPostRedisplay(). int y) { usleep(10000). Lanzar el capturador de eventos que lleva al programa a que entre en un bucle infinito y se empiece a dibujar (mientras no se llame a esta funci´n o no se dibuja nada en la pantalla) glutMainLoop(). Justo antes de hacer la llamada a esta funci´n o es necesario llamar a la funci´n glFlush() de GL que se encarga de la o actualizaci´n de los buffers. La funci´n a la que llama utilizando CALLBACK debe hacer que los camo bios que se realicen en las variables de dibujo se guarden para que la pr´xima o vez que se dibuje estos cambios se reflejen. por ejemplo la funci´n que se ejecuta cuando se produce un determio nado evento por teclado (mediante CALLBACK) es la siguiente: void keyPressed(unsigned char key. Creaci´n de la ventana gr´fica con el nombre que quiera que aparezca en el o a t´ ıtulo de la ventana. 0). captura de o teclado. Esto se hace mediante la instrucci´n de o GLUT glutSwapBuffers(). . SISTEMAS GRAFICOS glutInitWindowSize(640. o Llamada a la funci´n que captura eventos del teclado y/o del rat´n.

0). La funci´n CALLBACK m´s importante es glutDisplayFunc() que se o a ejecuta cada vez que se refresca la pantalla. Se suele definir una funci´n que realiza la inicializaci´n de OpenGL y recoge las o o operaciones que solo han de hacerse una vez en el programa como son: • Seleccionar el color de fondo de pantalla. de modo que la funci´n ser´ llamada para hacer una operaci´n espec´ o a o ıfica cada vez que se produzca un evento. make_expression(face. } } 79 Las funciones de GLUT a las que se pasa como par´metro la direcci´n de otra funci´n a o o con la sintaxis glut*(&funcion) utilizan el mecanismo de CALLBACK. TRABAJO CON OPENGL face_reset(face). o • Suavizar las aristas. glEnable(GL_LIGHT0). //iluminaci´n o glEnable(GL_LIGHTING). //profundidad glClearDepth(1.0f. //dibujo lo q queda mas cerca glDepthFunc(GL_LESS).0f. o El c´digo de la funci´n de inicializaci´n de OpenGL descrita es el siguiente: o o o void InitGL(int Width. o • Indicar la profundidad de la escena y habilitar la comparaci´n de profundidad.0f. o • Seleccionar el tipo de proyecci´n con que se van a ver las im´genes.0f). int Height) { //fondo de pantalla: blanco glClearColor(1. 1.5. • Activar la iluminaci´n. //habilito la comparacion de profundidad glEnable(GL_DEPTH_TEST). 1.7. o a • Seleccionar la matriz de visualizaci´n/modelado. //pinto poligonos suavizando las aristas . face->current_exp). • Seleccionar las caracter´ ısticas de los materiales. • Seleccionar la matriz de proyecci´n. 0.

Durante el proceso de modelado se ha tenido en cuenta que o posteriormente viene un proceso de animaci´n. Se hace mediante el siguiente Makefile: n La parte m´s importante del Makefile es la siguiente: a LIBS = -lX11 -lXi -lXmu -lglut -lGL -lGLU -lm Se refiere a las librerias de OpenGL con las que se debe enlazar el binario. 100. 0.6 o o . glColorMaterial(GL_FRONT.7. Son las librerias GL. GLU y GLUT. Este es el motivo por el cual se dibujan los o m´sculos sobre la cara. (GLfloat) Width / (GLfloat) Height. de renderizarla15 . //matriz de visualizaci´n/modelado o glMatrixMode(GL_MODELVIEW). Animaci´n o Una vez concluye el proceso de modelado. n 5. Al ejecutar el binario. Son las herramientas en las que se basa el proceso de animaci´n. glLoadIdentity(). es decir. Para ello es necesario generar el binario de la aplicaci´n o dise˜ada. Actualizar los datos de la figura (se realizan en la funci´n idle function).2. 15 c´mo renderiza internamente OpenGL se explica en la Secci´n 5.80 glShadeModel(GL_SMOOTH). //perspectiva de visualizaci´n de la imagen o gluPerspective(45. composici´n y renderizado el siguiente paso o es la animaci´n de la cara. Borrar la pantalla. se abre una ventana y se ve la cara dise˜ada (Figura 5. u o Los pasos generales para animar una escena son los siguientes: 1. ´ CAP´ ITULO 5.0f. } * Renderizado. o 2. //matriz de proyecci´n (le cargo la matriz identidad) o glMatrixMode(GL_PROJECTION).0f). SISTEMAS GRAFICOS //caracter´sticas de los materiales ı glEnable(GL_COLOR_MATERIAL). Una vez montada la escena es momento de crear la imagen final.1f. GL_AMBIENT_AND_DIFFUSE).14).

Como se ha indicado antes.00 Left_Secondary_Frontalis 0. desagrado y enfado. la parte del archivo u correspondiente a la alegr´ es el siguiente: ıa Alegria Left_Zygomatic_Major 1. int y) { .00 Right_Inner_Labi_Nasi 0. Este prototipo pretende que se dibujen las seis exa presiones b´sicas de Ekman [Ekman and Friesen.14).00 Left_Inner_Labi_Nasi 0. o Los m´sculos se caracterizan por tener una determinada tensi´n.00 Right_Angular_Depressor 0. e El c´digo de dicha funci´n es el siguiente: o o void keyPressed(unsigned char key. alegr´ tristeza.00 Right_Secondary_Frontalis 0. los m´sculos son los elementos que han u sido implementados en el modelado de la aplicaci´n para facilitar la tarea posterior de o animaci´n. cada vez q se pulsa esa tecla.80 Left_Frontalis_Major 0. pueden verse en el Ap´ndice A de la presente memoria.7.00 Left_Lateral_Corigator 0.20 Right_Frontalis_Outer 0.90 Right_Frontalis_Major 0. miedo. Cada una de las u o expresiones universales se caracteriza por la tensi´n de los m´sculos que componen la o u estructura de la cara. sorpresa. De modo que se van mostrando una tras otra en la pantalla. desagrado y enfado). Es de nuevo en un archivo donde se encuentran las tensiones de cada m´sculo para cada uno de los estados emocionales. a ıa. TRABAJO CON OPENGL 3. El orden con el que se visualizan es el siguiente: neutra. 81 Antes de construir la aplicaci´n final que anima la cara dise˜ada seg´n los estados o n u globales de Higgs se construyen una serie de prototipos.10 Left_Labi_Nasi 0.30 Right_Labi_Nasi 0.10 Left_Angular_Depressor 0. Los resultados obtenidos ıa.00 Right_Lateral_Corigator 0. A modo de ejemplo. Se parte del dibujo est´tico de la a cara en estado neutro (Figura 5. 4.00 Right_Frontalis_Inner 0. Volver al punto 1. va recorriendo el archivo en el que se encuentran las distintas expresiones.00 Se utiliza como ayuda el teclado para implementar la funci´n prototipo.00 Left_Frontalis_Inner 0. int x. miedo. Esta funci´n o o es a la que llama glutKeyboard cuando se presiona la tecla escape del teclado (se ha definido que reaccione ante esa tecla). 1978](alegr´ tristeza.5. sorpresa. Prototipo: expresiones b´sicas.20 Left_Frontalis_Outer 0. Lo que hace es que. Dibujar la figura.00 Right_Zygomatic_Major 1.

if(key==ESCAPE){ face_reset(face). if (face->current_exp>= face->nexpressions) face->current_exp=0.0006. face->muscle[n]->fe. float amplitud=0. face->muscle[n]->fs. make_expression(face. t=t+ts. activate_muscle(face. face->muscle[n]->head.82 ´ CAP´ ITULO 5. n < face->nmuscles. face->current_exp). } } Prototipo: expresi´n viva. float inc=amplitud/tts*sin(tt). face->current_exp++. face->muscle[n]->zone. Su c´digo es el siguiente: o void idle_function() { usleep(20000). // a lo senoidal int e=0. o Esta funci´n se implementa en idle function que es la funci´n que se ejecuta entre o frames. Este prototipo pretende que la imagen est´tica que se o a dibuja cuando no se produce ning´n evento tenga mayor sensaci´n de realismo. // codigo para generar la expresion "viva" static float t. Lo que se u o hace es a˜adirle a la tensi´n de los m´sculos una oscilaci´n de un seno de poca amplitud n o u o entre un frame y el siguiente. face->muscle[n]->tail. +inc). SISTEMAS GRAFICOS usleep(10000). .07. n++) { float muscle_contraction = face->expression[e]->m[n]. for (n = 0. int n. float ts=0. De este modo que se produce la sensaci´n de que esta o respirando.

} 83 Prototipo: cambio de expresi´n. float inc=ampl*sin(t). El objetivo es pasar de una expresi´n a otra. el c´digo de o o la misma es el siguiente: void idle_function() { usleep(20000). // codigo para cambiar de expresion static float t. // generacion de la interpolacion entre los niveles musculares de // las expresiones i y j face_reset(face).0. t=t+ts. valor). float muscle_contraction1 = face->expression[j]->m[m]. . activate_muscle(face. int m.050. La o o funci´n lee los datos de dos expresiones del archivo de expresiones e interpola entre sus o valores mediante una senoidal.5. float ts=0. TRABAJO CON OPENGL glutPostRedisplay(). La funci´n se implementa en el idle function y se ejecuta entre frames. face->muscle[m]->head. int i=0. m++) { float muscle_contraction0 = face->expression[i]->m[m]. float valor=inc+punto_medio. int j=1. // genero una senoidal entre los valores float ampl=abs(muscle_contraction0-muscle_contraction1)/2. m < face->nmuscles. face->muscle[m]->tail. face->muscle[m]->fe. float punto_medio=(muscle_contraction0+muscle_contraction1)/2. face->muscle[m]->zone. face->muscle[m]->fs.7. for (m = 0.0.

16. La funci´n idle function que se utiliza para realizar las operaciones correspondientes o entre frames. Este se encarga de traducirla a informaci´n emocional que viene dada por un vector o que tiene por componentes las tensiones correspondientes a cada m´sculo de la cara. o ´ cuando se redibuje la pantalla se har´ con las nuevas tensiones de los m´sculos de la cara a u correspondientes al estado emocional de Higgs. Un esquema sencillo de la aplio o caci´n final puede verse en la figura 5. SISTEMAS GRAFICOS Figura 5. se encarga de utilizar los valores almacenados en el vector de estado emocional que recibi´ el servidorHiggsFace en la ultima llamada sobre su interfaz. De este modo. Por u ultimo el EmotionMapper le pasa esta informaci´n al servidor CORBA HiggsFace que la ´ o utiliza para dibujar la cara.16: Esquema sencillo de la aplicaci´n HiggsFace o } glutPostRedisplay(). . } Aplicaci´n final: animaci´n de la cara de Higgs.84 ´ CAP´ ITULO 5. Seg´n este esquema el m´todo seguido para el o u e proceso de animaci´n en la aplicaci´n final es el que se describe a continuaci´n: el servidor o o o CORBA Higgs le proporciona al EmotionMapper un vector con informaci´n sensorial del o ´ robot.

de un vistazo. o En la Secci´n 6. Por o mapeo se entiende la traducci´n del estado sensorial1 a un estado emocional2 sino proporo cionar un mecanismo para implantar una teor´ concreta en forma de plug-in (en particular ıa como un agente activo ICa. Describe el tipo de informaci´n que proporciona al EmotionMapper o cuando este le solicita en un determinado momento el estado del robot m´vil. sino que convierte los estados o n globales del sistema en estados emocionales que expresa mediante caras de modo que estas sean f´cilmente entendibles por el usuario.2 se describe la informaci´n sensorial que nos proporciona el servidor o o CORBA Higgs. el modo en el que la 1 2 Estado de los sensores del robot (tanto exteroceptivo como propioceptivo) Estado sint´tico de alto nivel empleando en el control estrat´gico de una m´quina e e a 85 . El objetivo no es desarrollar una teor´ sobre las emociones. Se organiza o a del siguiente modo: En la Secci´n 6. a modo de introduccion.Cap´ ıtulo 6 Mapeo de emociones en Higgs Este cap´ ıtulo describe c´mo se realiza el mapeo a emociones del estado de Higgs. En la Secci´n 6. o La aplicaci´n no se dise˜a para emular estados humanos. mapearlo a un estado emocional y enviar la informaci´n al programa gr´fico que se encarga de dibujar la cara. la misi´n del EmotionMapper o o y la estructura del mismo.3 se describe c´mo el EmotionMapper realiza la traducci´n de los o o o estados globales del sistema en estados emocionales.1 se describe. De esta forma. esto es. Cualquier o e o teor´ sobre las emociones que quiera implementarse despu´s podr´ hacerse cambiando el ıa e a modo de mapear la informaci´n. se puede ver c´mo a o se encuentra el sistema en un determinado instante. Se ıa pretende habilitar un mecanismo para transformar los estados del robot en estados emocionales y posibilitar la visualizaci´n de ´stos mediante una cara antropom´rfica. Este cap´ ıtulo describe la parte de la aplicaci´n que ha sido denominada EmotionMapo per que se encarga de solicitar al robot su estado.

1. Hay que “jugar” con la informaci´n sensorial o o que proporciona el robot (se describe en la Secci´n 6. de un vistazo. 6.1).2) para convertirla en informaci´n o o emocional que guarde relaci´n con el estado del robot. Figura 6. MAPEO DE EMOCIONES EN HIGGS informaci´n sensorial se transforma en informaci´n emocional que es visualizada poso o teriormente en una cara antropom´rfica. el operador sepa c´mo se encuentra el sistema. o En la Secci´n 6.4 se indica c´mo el EmotionMapper transmite la informaci´n emoo o o cional al servidor CORBA HiggsFace para que actualice la posici´n de la cara al o estado emocional determinado por el estado del sistema en ese momento. EmotionMapper El EmotionMapper es la parte de la aplicaci´n que se utiliza para transformar la o informaci´n sensorial en informaci´n emocional que pueda ser utilizada por la parte gr´fica o o a para representar mediante expresiones faciales en una cara antropom´rfica el estado del o sistema (Figura 6. o .1: Elementos de la aplicaci´n HiggsFace o Higgs no tiene emociones humanas sino estados mec´nicos que abstraemos a estados a emocionales que se expresan mediante expresiones faciales para que.86 CAP´ ITULO 6.

INFORMACION SENSORIAL 87 6. Transformaciones emocionales Entre los objetivos del proyecto no est´ el desarrollo de una teor´ sobre las emoa ıa ciones. Este servidor fue desarrollado en un proyecto anterior e a [Pareja.2. La informaci´n que le proporciona el servidor Higgs es la siguiente3 : o velocidad de traslaci´n del robot (Velocity) o velocidad de rotaci´n del robot (RotVelocity) o velocidad de las ruedas derecha e izquierda (RightVelocity. aunque no todos tienen porqu´ estar activos. A o continuaci´n se describe cada uno de estos elementos. la matriz de emociones (Me ) y el vector de informaci´n emocional (VC ).´ 6. e . Informaci´n sensorial o El robot m´vil tiene un programa servidor ejecutandose en su CPU que atiende petio ciones a trav´s de la red inal´mbrica. YCoordinate. u o En el mapeo de emociones intervienen tres elementos: el vector de informaci´n seno sorial (VR ). e Dispone de 16 sonares.3.2. 2004] y proporciona cierta informaci´n del robot que se va a utilizar para transforo mar a informaci´n emocional. Y y θ del robot respecto al sistema de referencia del robot (XCoordinate. El EmotionMapper es un agente ICa que act´a como cliente o u de ese servidor solicit´ndole la informaci´n sensorial de Higgs en un determinado instante. ThCoordinate) lecturas de los sonares4 (Sonar Range) bater´ (Battery) ıa Este vector le proporciona al EmotionMapper el estado global del sistema. Una vez tiene esta informaci´n ha de transformarla en estados emocionales. LeftVelocity) coordenadas X. El objetivo perseguido es dotar al m´dulo de la funcionalidad necesaria para comuo nicar su informaci´n sensorial mediante estados emocionales que se visualizan en una cara o antropom´rfica por lo que se limita a transformar la informaci´n sensorial que recibe de o o alg´n modo en informaci´n emocional que pueda utilizarse para dibujar la cara. o 3 4 Entre par´ntesis el nombre correspondiente en la estructura proporcionada por el servidor. Este proceso (el “mapeo” o propiamente dicho) se describe en la siguiente secci´n. o 6. a o El servidor le proporciona esa informaci´n mediante un vector con los datos pedidos en ese o momento.

la informaci´n proporcionada por el servio a o dor CORBA Higgs que se selecciona para su conversi´n a emociones es la siguiente: o estado de la bater´ ıa coordenada X coordenada Y velocidad rueda derecha velocidad rueda izquierda velocidad de rotaci´n o Es necesario escalar al rango [0.3. 1] los valores de este vector ya que los valores que en ´l se encuentran corresponden a variables e muy distintas que no tienen relaci´n entre s´ De este modo cada variable influye en la o ı. El sistema a . ıa Para la aplicaci´n que se est´ desarrollando. emoci´n final de manera parecida. Vector informaci´n sensorial o Est´ formado por la informaci´n sensorial proporcionada por el robot que se utiliza a o para el mapeo de emociones.88 CAP´ ITULO 6. En la siguiente tabla se reflejan las distintas variables consideradas as´ como los rangos ı de variaci´n de cada una de ellas: o Variable bater´ ıa coordenada X coordenada Y velocidad rueda derecha velocidad rueda izquierda velocidad de rotaci´n o Rango 0–13 (V) (∗) (m) (∗) (m) 0–250 (mm/s) 0–250 (mm/s) 0–50 (mm/s) Los rangos de variaci´n de las variables coordenada X y coordenada Y se representa o por (∗) porque realmente no est´n limitados. MAPEO DE EMOCIONES EN HIGGS 6. incluso pueden ser negativos. De entre los datos que proporciona el servidor se eligen aquellos que son susceptibles de poder significar algo para el estado global del robot teniendo en cuenta que vamos a hacer una analog´ para transformarlos en emociones. independientemente de la magnitud de la misma (que o nos conducir´ a valores err´neos porque los rangos de variaci´n de las mismas son muy ıa o o distintos).1. No todos los datos que son proporcionados por el servidor al hacerle la consulta sobre el estado de Higgs se utilizan para realizar la transformaci´n a o estados emocionales.

5 La raz´n por la que se ordenan de este modo se indica en la parte del vector de informaci´n emocional. o En el caso de la aplicaci´n que se desarrolla en este proyecto. o El orden de estas variables en el vector VR es el siguiente5 :  Bater´ ıa  V rueda dcha     V rotaci´n  o   VR =    V rueda izqda  Coordenada X  Coordenada Y  6. TRANSFORMACIONES EMOCIONALES 89 de coordenadas de referencia se establece en el momento en el que el robot se conecta y empieza a moverse pero para poder utilizar estos valores en el mapeo de informaci´n o sensorial a informaci´n emocional que se est´ realizando deben limitarse. o o . El vector obtenido tras este proceso es VR (vector de informaci´n sensorial). o Una vez la informaci´n sensorial de Higgs en un determinado instante le llega al Emoo tionMapper.6. Esta matriz es. Matriz de emociones La matriz de emociones es una matriz de dimensiones m × n siendo m el n´mero de u m´sculos que se utilizan para la animaci´n y n el n´mero de expresiones existentes. la matriz de emociones o es de 18 × 6. De u o u modo que el elemento aij de la matriz de emociones representa la tensi´n del m´sculo i o u correspondiente a la expresi´n j.3. se cogen de esa vector las componentes que interesan para mapear el estado global a estado emocional y se pasan a valores por unidad.2. Consideramos o a que el rango de variaci´n es de -5 a 5 metros.3.

Vector de informaci´n emocional o Este vector representa las tensiones de cada uno de los m´sculos de la cara para el u estado global del sistema. Se obtiene como producto de la matriz de emociones por el vector de informaci´n sensorial: o VC = Me · VR siendo: Me = [aij ]m×n VR = [rj ]n×1 VC = [cj ]m×1 Los valores de la tensi´n de cada m´sculo en cada una de las expresiones se obtienen probando valores o u hasta generar expresiones naturales. 6.6   Tristeza        Miedo          Desagrado La forma en la que se construye la matriz es la siguiente: se dispone de un archivo en el que se indica la tensi´n de cada m´sculo para cada una de las seis expresiones universales o u 6 de Ekman ...3. 6 . . La aplicaci´n desarrollada abre dicho archivo y lee sus valores rellenando la o matriz Me (matriz de emociones) que se utiliza para el mapeo. MAPEO DE EMOCIONES EN HIGGS    Cigom´tico mayor a        Depresor del ´ngulo de la boca   a        Frontal interior          Frontal       filas: m´sculos (2 de cada) m = 1 .90 CAP´ ITULO 6.3. . 18 Frontal exterior u        Elevador del ´ngulo de la boca a        Elevador del labio superior          Corrugador lateral    Me =  Corrugador superciliar             ıa Alegr´        Enfado        Sorpresa   columnas: expresiones  n = 1.

le confiere un peso a esa emoci´n en o o el estado final. Figura 6.6. o Si alguno de los valores sobrepasa el umbral se satura ese valor. es decir. Es necesario modificarlo antes si la tensi´n de alguno de los m´sculos de la estructura supera los valores tensiono u ales m´ximos para evitar obtener expresiones imposibles (que los puntos se salgan de la a cara).3. En la siguiente tabla se recogen las tensiones m´ximas de los distintos m´sculos que a u constituyen la estructura de la cara (su disposici´n se puede ver en la Figura 2.3). no ser´ necesario hacer nada y su utilizaci´n o u a o es inmediata. toma el valor m´ximo de tensi´n posible para ese m´sculo. Si todos los valores est´n dentro de los rangos a o u a de variaci´n correspondientes a cada m´sculo. el EmotionMapper lo transmite al servidor CORBA HiggsFace que utiliza su informaci´n para dibujar la expresi´n correspondiente.2: El EmotionMapper como aplicaci´n lineal o El vector obtenido no siempre puede utilizarse directamente. o o . TRANSFORMACIONES EMOCIONALES de modo que: m 91 ci = j=1 (aij · rj ) lo que significa que cada variable pondera una columna de la matriz de emociones. Una vez obtenido el vector de informaci´n sensorial (VC ) y modificado en caso de ser o necesario. De modo que el orden de las variables de informaci´n sensorial del vector VR es importante ya o que cada una de ellas pondera una emoci´n. es decir.

4. o .90 0.10 2.50 M´ sculos (lado derecho) u Cigom´tico mayor a Depresor del ´ngulo de la boca a Frontal interior Frontal Frontal exterior Elevador del ´ngulo de la boca a Elevador del labio superior Corrugador lateral Corrugador superciliar Tm´x.40 2.80 1.20 2.40 0.92 M´ sculos (lado izquierdo) u Cigom´tico mayor a Depresor del ´ngulo de la boca a Frontal interior Frontal Frontal exterior Elevador del ´ngulo de la boca a Elevador del labio superior Corrugador lateral Corrugador superciliar CAP´ ITULO 6.10 0.10 0. Visualizaci´n o Una vez que el EmotionMapper ha transformado la informaci´n sensorial en informao ci´n emocional ha de pas´rsela al sevidor HiggsFace para que este la trate de la forma o a conveniente y en la cara se visualicen las nuevas tensiones de los m´sculos que dan lugar u a la expresi´n emocional del estado global del sistema.30 0.60 2.00 1.00 2. a 1. MAPEO DE EMOCIONES EN HIGGS Tm´x.00 0. a 1.00 1.70 3.70 3.60 6.

1. Fue necesaria la creaci´n de un servidor CORBA con la o o misma interfaz que el servidor que se ejecuta en el robot para que cuando la aplicaci´n o 93 .1 se recuerdan los objetivos. En la Secci´n 7.Cap´ ıtulo 7 Conclusiones y l´ ıneas futuras Para finalizar con la memoria de este proyecto fin de carrera titulado “Mapeo facial de emociones sint´ticas” en este cap´ e ıtulo se describen las conclusiones que se sacan del trabajo realizado as´ como posibles l´ ı ıneas de investigaci´n que podr´ seguirse en el futuro o ıan y revertir´ en mejoras para el mismo. o o La aplicaci´n consta de tres partes que se han ido describiendo por separado en la o memoria. el trabajo realizado as´ como las concluo ı siones que se sacan del proyecto que se describe en esta memoria. 2004]. o e pero la necesidad de hacer pruebas y la falta de disponibilidad del robot en algunos momentos hicieron necesaria la creaci´n de un simulador que actuara como banco o de pruebas de la aplicaci´n. ıan En la Secci´n 7. Conclusiones El objetivo de este proyecto es la implementaci´n de un sistema para la visualizaci´n o o del estado global de un sistema t´cnico mediante una cara antropom´rfica utilizando la e o expresi´n facial como m´dio de comunicaci´n. en un principio s´lo era necesario hacer uso de ´l. Esta parte fue desarrollada anteriormente o para otro proyecto [Pareja. ıan o 7. Tambi´n se ıa e implementa una aplicaci´n concreta: HiggsFace (plataforma m´vil Pioneer 2AT-8). Pioneer 2AT: Es el servidor CORBA que se ejecuta en la CPU de Higgs y se encarga de proporcionar la informaci´n sensorial.2 se describen las l´ o ıneas de trabajo que quedan abiertas tras la conclusi´n o de este proyecto que supondr´ mejoras de la aplicaci´n desarrollada. As´ mismo se desarrolla un patr´n de dise˜o o e o ı o n para poder implantar cualquier teor´ emocional en forma de agente activo.

aunque tambi´n las e hay de car´cter m´s general como por ejemplo la relacionada con el mapeo de emociones. En este proyecto facilita un mecanismo para pasar de las unas a las otras mediante transformaciones lineales de la informaci´n. por ejemplo es el caso de ver si el robot se est´ moviendo o no.94 CAP´ ITULO 7. 2004] o n para satisfacer las necesidades espec´ ıficas de aquel y no de ´ste. o Face: Este bloque que se encarga del dibujo y gesti´n de la representaci´n gr´fica del o o a estado emocional de Higgs. EmotionMapper: Este es un agente intermedio que se encargaba por un lado de recoger la informaci´n sensorial y por otro de generar informaci´n emocional a partir de ella o o mediante un proceso de mapeo. Para ello el proceso que se se sigue es transforo mar la informaci´n sensorial que proporciona el servidor CORBA de Higgs en informaci´n o o emocional utilizando el EmotionMapper. El objetivo perseguido era hacer que Higgs se comunicara mediante emociones que se visualizan en una cara antropom´rfica.2. Nuevo servidor La aplicaci´n espec´ o ıfica para la que se ha implementado el software dise˜ado es Higgsn Face. por lo que una l´ e ınea de trabajo futura para mejorar esta aplicaci´n es el dise˜o de un nuevo servidor. El resultado concreto obtenido en el proyecto es un sistema que dibuja distintas expresiones faciales seg´n el valor de las variables del sistema rob´tico Pioneer 2AT-8.2. Toda a a esta informaci´n es susceptible de significar algo para el estado global del sistema. El servidor que se ha utilizado en esta aplicaci´n fue dise˜ado en otro proyecto [Pareja.1. Aria (API o n para el control del robot) proporciona m´s funciones de las que se implementaron en su a momento para el servidor. si est´ atascado o si tiene los motores conectados. Algunas se relacionan directamente con la aplicaci´n espec´ o ıfica realizada para este proyecto: HiggsFace. su reutilizabilidad en otras aplicaciones. mucho o . CONCLUSIONES Y L´ INEAS FUTURAS se conecte a Higgs se obtengan los mismos resultados que en las pruebas. El valor u o principal del desarrollo es. sin embargo. Algunas de estas funciones proporcionan informaci´n m´s adeo a cuada a la hora de inferir un estado global del sistema. 7. L´ ıneas futuras Este proyecto deja abiertas varias l´ ıneas de trabajo. Ambos interactuan de modo que lo que la parte gr´fica dibuja a los valores que le pasa el EmotionMapper dependiendo del estado que se infiere de la informaci´n sensorial proporcionada por Higgs (o en su defecto por el banco de o pruebas construido para suplirle). a a 7. Une dos cosas: por un lado es un servidor CORBA que atiende peticiones que le llegan de clientes y por otro es un programa de dibujo gr´fico a basado en OpenGL.

De modo que evitamos que sea necesario un “entrenamiento” especial para comprender lo que se quiere significar ya que de la expresi´n facial se infiere el estado del sistema (de o igual modo que en la comunicaci´n entre personas se infiere el estado del interlocutor). ) as´ como textura de piel en la cara en lugar de color.2. como se explic´ en el Cap´ o ıtulo 2. Se dispon´ de una serie de ıa ıa datos a partir de los cuales se implement´ un mecanismo de demostraci´n para transformar o o la informaci´n proporcionada por esos datos en emociones que se visualizan en una cara o antropom´rfica. o o Por lo que una de las l´ ıneas futuras que queda abierta tras la finalizaci´n de este o proyecto es desarrollar un servidor que proporcione m´s informaci´n acerca del robot para a o aumentar la funcionalidad del mismo y poder as´ expresar mejor su estado global utilizando ı la expresi´n emocional.3.2. contribuyen al realismo de la imagen y consiguen que la interfaz dise˜ada sea m´s cre´ n a ıble. Teor´ sobre las Emociones ıa La otra l´ ınea de trabajo posible tiene que ver con el EmotionMapper. . o Una interesante puerta que queda abierta tras este proyecto es la investigaci´n de una o Teor´ sobre las Emociones para el mapeo a informaci´n emocional del estado de los disıa o tintos sistemas f´ ısicos con los que nos pudieramos encontrar. Pero el dise˜o gr´fico de la misma es n a susceptible de mejora. esto es. . Como se indic´ en el Cap´ o ıtulo 6 el objetivo de este proyecto no era el dise˜o de una “Teor´ sobre n ıa las Emociones” sino dotar al sistema de un mecanismo que transformara la informaci´n o sensorial disponible en informaci´n emocional. pelo en la cabeza y en la n cara (cejas. o 7.2. 7. a a e Con esto se cumple el objetivo del presente proyecto. Lo unico que aporta expresividad a ´ . La o cara de Higgs es una m´scara dotada de gran expresividad de modo que es capaz de genera ar expresiones f´cilmente reconocibles por las personas (ver las im´genes del Ap´ndice A).7. Todas estas ı caracter´ ısticas. o En este proyecto no se ha utilizado ninguna teor´ concreta. Se puede dise˜ar que tenga ojos (y que se muevan). Aumentar el realismo de la imagen utilizando el dise˜o gr´fico es una l´ n a ınea futura de trabajo. Aumentar el realismo de la imagen La interfaz dise˜ada en este proyecto para la comunicaci´n del estado global de un detern o minado sistema (en este caso el robot m´vil Higgs) es una cara de apariencia antropom´rfio o ca. L´ INEAS FUTURAS 95 m´s que variables como la posici´n que se ha utilizado para el mapeo en la aplicaci´n a o o desarrollada (se utiliz´ la informaci´n disponible). habilitar m´todos que e expliquen c´mo realizar la traducci´n de un estado global del sistema a un estado emoo o cional que sea entendible por el usuario y que guarde analog´ con la expresi´n emocional ıa o humana. barba.2.

el resto de las caracter´ ısticas son s´lo est´ticas. a . CONCLUSIONES Y L´ INEAS FUTURAS la imagen son los ojos y su movimiento (no es una tarea sencilla conseguir una mirada natural). pero en cualquier caso este es el o e modo de proporcionar interfaces m´s naturales para el usuario.96 CAP´ ITULO 7.

Alegr´ ıa 97 Enfado . Se e a n recogen las expresiones universales de Ekman [Ekman and Friesen. 1975].Ap´ndice A e Ejemplos En este ap´ndice se recogen im´genes de la interfaz dise˜ada en distintas posiciones.

EJEMPLOS Sorpresa Tristeza Miedo Desagrado .98 ´ APENDICE A.

as´ como para el retoque de otras a n ı im´genes que aparecen a lo largo de la memoria. en la realizaci´n de este o proyecto y su correspondiente memoria se han utilizado otras. y Enterprise JavaBeans (EJBs). que hacen que la creaci´n del o A X posibilita generar documento sea m´s sencilla (autocompleta comandos TEX/ L TE a y ver el documento con un solo click. tiene un asistente para introducir la bibliograf´ ıa . En este proyecto se ha utilizado para a hacer capturas de las im´genes de la cara dise˜ada. Se ha utilizado para generar esta memoria. GIMP(GNU Image Manipulation Program): es un programa de manipulaci´n de o im´genes del proyecto GNU. En este proyecto se ha utilizado Eclipse para realizar el programa que se encarga de dibujar y gestionar la cara que expresa el estado del robot (programa C++). a Open Office.Ap´ndice B e Otras herramientas Adem´s de las herramientas descritas el los Cap´ a ıtulos 4 y 5. Se utilizan las funciones integradas de las que dispone. aplicaciones Java o de todo tipo. A A L TEX: es un conjunto de macros de TEX. Se ha utilizado para escribir esta memoria que recoge el trabajo realizado en el proyecto. A continuaci´n se muestra o una lista de las mismas as´ como en qu´ se emple´ cada una de ellas. Es la alternativa m´s firme del software libre al popular a a programa de retoque fotogr´fico Photoshop. programas C++. La calidad a A X es comparable a la de una editipogr´fica de los documentos realizados con L TE a A torial cient´ ıfica de primera l´ ınea. ya que puede 99 . A Kile: es un editor sencillo para TEX y L TEX. o a Es bastante compatible con los formatos de fichero de Microsoft Office. La idea principal de L TEX es ayudar a quien escribe un documento a centrarse en el contenido m´s que en la forma. . ı e o Eclipse: la plataforma Eclipse est´ dise˜ada para la construcci´n de entornos de desarrollo a n o que puedan ser utilizados para la construcci´n de aplicaciones web. ). L TEX es Software Libre bajo licencia LPPL. .org: es un proyecto basado en el c´digo abierto para crear una suite ofim´tica.

. Se ha utilizado los m´dua o los “Draw”(m´dulo de dibujo vectorial) e “Impress” (presentaciones) para crear las o figuras que se ven a lo largo de la memoria.100 ´ APENDICE B. OTRAS HERRAMIENTAS leer directamente los archivos creados con dicha suite ofim´tica. aunque tiene su a propio formato de archivos basado en el est´ndar XML.

J. C. pages 187–194. eMuu-An Embodied Emotional Character For The Ambient Intelligent Home. Nordin. Building a digital human. D. T. Editorial Tecnos.. Baeza. 2002] Braccini. G´mez. J. [Boden... M. 2002] Bartneck. P. M. Interacting with an embodied emotional character. Improvements on a simple muscle-based 3d face for realistic facial expressions. and de Pablo.. Bejder.. T. A. P. pages 55–60. (1977).. D. [Brilliant... 2003] Chinchilla. page 33. (2000). [Bartneck. V´zquez.. A solution for model-independent animation of mpeg-4 faces. 1977] Boden. (2003). J. L. Charles River Media. 1999] Blanz. 2000] Clavijo.. K. 101 . C. Segarra. (2002).. [Braccini et al. R. 2003] Brilliant. In DPPI ’03: Proceedings of the 2003 international conference on Designing pleasurable products and interfaces. C. and Nijholt. 2003] Bui. Sanz. R. Lavagetto. [Chinchilla.. ACM Press/AddisonWesley Publishing Co. and Pockaj. Alam´n. F. and D´ A. e Moreno. Jim´nez. (1999). ıez. (1994). In Proceedings of IFAC Workshop on Algorithms and Architectures for Real-time Control. E. (2003).. R. A morphable model for the synthesis of 3d faces.. X. [Bartneck. Hard Real Time CORBA IST Project. M.. ACM Press. 1994] Alarc´n. C. Real-time video for distributa ıaz. IEEE Computer Society. A. AARTC’2000. and Vetter.. H. In SIGGRAPH ’99: Proceedings of the 26th annual conference on Computer graphics and interactive techniques. D´ F. Costa. [Clavijo et al. Heterogeo a neous integration architecture for intelligent control.. M. (2003). Spain. In CASA ’03: Proceedings of the 16th International Conference on Computer Animation and Social Agents (CASA 2003).. INC. Installing ICa. A... ed control systems.. 2003] Bartneck. (2003).Bibliograf´ ıa [Alarc´n et al. Rodr´ o o ıguez. Fontaine.. Inteligencia artificial y hombre natural. Almeida. L.. Heylen. Sanz. R. V. C... A. (2002). Palma de Mallorca.. R. [Bui et al. Intelligent Systems Engineering. [Blanz and Vetter. P.

[Evans. M. [El-Nasr et al. (1978).. S. and Parke. 1999] El-Nasr. page 48. A guide to recognizing emotions from facial clues. Cosulting Psychologist Press. R. (2003). Ioerger. Facial action coding system (FACS): a technique for the measurement of facial action. 1975] Ekman.. G. a a [Garc´ 2003] Garc´ J.. (2001). Technical report.0). F. D.. T. House. V. 1996] Goleman. Guide to LaTeX. (1990). D. The Mechanism of Human Facial Expression. Oxford University Press. J. (1999). a very short introducction. 1872] Darwin. M. P. W.102 [Cole. (1872). (1993). The Artist’s Complete Guide to Facial Expressions. Yen... El arte de leer el rostro. Modeling and rendering for realistic facial animation. J.. Andrew Cuthbertson. [Michi Henning. Kair´s. [Ekman and Friesen. R. [Faigin. and Raghupathy. IEEE Computer Society. 1999] Fabri. Watson-Guptill Publicatiobs. (1999). Martinez Roca. A Bradford Book. Palo Alto. pages 231–242. R. Addison Wesley. and Hobbs. W. S. 4th edition. [Fabri et al. 1990] Faigin. CA. [F`bregas. (1999). J. Moore. and Daly.. About Face. [Duchenne. I. Society of Mind. P. Avance CORBA programming with C++. ıa. (1978). In CA ’99: Proceedings of the Computer Animation. [Minsky. New Jersey: PrenticeHall. C. D. (1862). D. o [Goleman. W. ıa. Emotion. M. P. S. C. and Friesen. The expression of emotions in man and animals. and Friesen. 1862] Duchenne. D.. Simon. BIBLIOGRAF´ IA [Darwin. 2001] Evans. ] Marschner. Curso de introducci´n a opengl (v1. Inteligencia emocional. [Marschner et al. J. H. The emotional avatar: Non-verbal communication between inhabitants of collaborative virtual environments. 1978] Ekman. Addison Westley. 1999] Michi Henning. 1739:245–248. R. Lecture Notes in Computer Science. B. [Ekman and Friesen. S. o [Kopk and Daly. B. (1996).. (1975). John Murray. . 1993] F`bregas. 1998] Cole.. Englewood Cliffs. Emotionally expressive agents. 1978] Minsky. Guenter. J. (1998). (2003). Unmasking the face. Ed. 2003] Kopk. H.

The IST HRTC project. Editorial Ariel.. Embedding interoperable objects in automation systems. R. Animation of synthetic faces in mpeg-4. J.. Progressive domain focalization in intelligent control systems. Jim´nez. E. In ACM’72: Proceedings of the ACM annual conference. pages 71–92. (2001). NL. (2004).. M. Programming dynamic character animation. In OMG Real-Time and Embedded Distributed Object Computing Workshop. I. The ICa approach to ıa. A o CORBA-based architecture for strategic process control. (2003). Master’s thesis. Spain. 2004] Pareja. Addison Wesley. Control Engineering Practice.. intelligent autonomous systems.. [Roosendaal and Selleri. Sistema de comunicaciones para pioneer 2at-8. (2000). 1999b] Sanz.. T. P.. Imperial College. Alarc´n.. [Sanz. 1972] Parke. 2003] Sanz. 2000] Sanz. 2nd edition. (1998). Alarc´n. In Proceedings of 28th IECON. OMG. Plant-wide risk management using distributed objects. I. M. [Paull. A. Hungary.R. [Ostermann. Charles River Media. [Picard. and Selleri. de Antonio. of China.. [Parke.. ETSII-UPM. [Sanz et al. 7(5):665–671. In Proceedings of IFAC Conference on New Technologies for Computer Control. IEEE Catalog number: 02CH37363.. In IFAC e SAFEPROCESS’2000. Dordretch. (1998). S. The official Blender 2. de Antonio. and o ıa.3 guide. D. Microprocessor-Based and Intelligent Systems Engineering. 2001] Sanz. (2002). PhD thesis. Hong Kong. F. (2002). M. ACM Press. 2002] Paull. A. A. and Alarc´n. (1999a). R. Blender Foundation. J.. (2004). chapter 4. editor. R. 1998] Picard. Segarra. and Clavijo. page 49. [Sanz. 2002] Qua. [Sanz et al. Mat´ F. R. Computer generated animation of faces. I. pages 451–457. A. de Antonio. (2002). Annual Conference of the IEEE Industrial Electronics Society. pages 2261–2265. In Tzafestas. (2004). Sevilla. 1998] Ostermann. Segarra. A. 2004] Roosendaal. Los ordenadores emocionales. Segarra. R. A. Mat´ F.. Washington. 2002] Sanz. R. USA. Kluwer Academic Publishers. [Qua. 1999a] Sanz. ... and Puente. (1999b).. [Sanz et al. 2004] Mittelbach.. F. [Sanz et al. W. IEEE Computer Society. o J. S. I. M.. [Pareja.. R.BIBLIOGRAF´ IA 103 [Mittelbach and Goossens. Advances in Autonomous Intelligent Systems. I. In CA ’98: Proceedings of the Computer Animation. (1972). and Goossens. B. Budapest. The LaTeX Companion. Muscle Based Facial Animation. V. INC.

Cambridge. and Waters.... ICa: Middleware for intelligent process control. 1987] Waters. OpenGL Programming Guide: the official guide to learning OpenGL. ISIC’1999. (2003). de Antonio. Intell. [Waters. (1999c). ACM Press. M. and Parke.. and Clavijo. (1996). [Waters and Parke. D. Ltd. Addison-Wesley. Pattern Anal.104 BIBLIOGRAF´ IA [Sanz et al. Massachusetts Institute of Technology. (1999). [Woo et al.. Segarra.. Emotions in humans and artifacts.. 1999c] Sanz. 2002] Trappl. J. M. D. Analysis and synthesis of facial image sequences using physical and anatomical models. In SIGGRAPH ’87: Proceedings of the 14th annual conference on Computer graphics and interactive techniques. and Zalewski. [Trappl et al. pages 17–24. K. [Terzopoulos and Waters. K.. In IEEE International Symposium on Intelligent Control. I.. IEEE Control Systems Magazine. 23(3):43–60. 2003] Sanz. Davis.2. A. 1993] Terzopoulos. Pattern-based control systems engineering. 1996] Waters. S. and Payr. P. J. R. [Sanz and Zalewski. . (1987). Computer Facial Animation. 1999] Woo. J. R.. (2002). Petta. A muscle model for animation three-dimensional facial expression. version 1.. (1993). R. J. 3rd edition. Neider. IEEE Trans. A. and Shreiner. K.. AK Peters. USA. 15(6):569–579. F. T. Mach.