Robôs Teleoperados em Ambientes Virtuais

Vista previa del material en texto

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY 
CAMPUS ESTADO DE rvtÉXICO 
ROBOTS TELEOPERADOS EN AMBIENTES VIRTUALES. 
TESIS QUE PARA OPTAR EL GRADO DE 
MAESTRO EN CIENCIAS COMPUTACIONALES 
PRESENTA 
MOISÉS ALENCASTRE MIRANDA 
Asesor: Dr. ISAAC RUDOMÍN GOLDBERG 
Comité de tesis: Dr. ISAAC RUDOMÍN GOLDBERG 
Dr. RICARDO SWAIN OROPEZA 
Dr. CARLOS RODRÍGUEZ LUCATERO 
Jurado: Dr. RICARDO SWAIN OROPEZA 
Dr. CARLOS RODRÍGUEZ LUCATERO 
Dr. ISAAC RUDOMÍN GOLDBERG 
Atizapán de Zaragoza, Edo. Méx., Enero de 2003. 
Presidente 
Secretario 
Vocal 
3 
RESUMEN 
Conforme se han realizado avances en distintas áreas tecnológicas como en las redes 
computacionales, la realidad virtual y el desarrollo de interfaces gráficas, los sistemas de 
teleoperación se han vuelto más elaborados y robustos; pennitiendo que el control de los robots 
se lleve a cabo teniendo de por medio grandes distancias. Los sistemas de realidad virtual junto 
con las redes computacionales han dado origen a los ambientes virtuales en red dentro de los 
cuales se puede interactuar con múltiples usuarios en mundos semejantes a los reales que pueden 
incluir la teleoperación de robots en este tipo de ambientes. 
Por otra parte, el alto costo de los robots los hace inaccesibles para algunas instituciones 
en países como el nuestro, por lo que los usuarios se ven limitados a probar algoritmos 
desarrollados en uno o dos robots distintos cuando mucho, siendo necesaria la existencia de 
herramientas que permitan el acceso a varios robots que pueden localizarse en áreas geográficas 
remotas. 
Actualmente existen muy pocos sistemas que permitan la teleoperación de varios robots 
virtuales y/o reales en ambientes virtuales en red y los pocos que existen no se encuentran al 
alcance de cualquier usuario, por lo tanto se ha desarrollado un sistema con estas características. 
La aplicación desarrollada para esta trabajo incluye la implementación de un ambiente virtual en 
red que sea portable, modular, distribuido, escalable y multiusuario sobre el cuál se pueda tener 
un modelo general de robot capaz de manejar de la misma forma a robots manipuladores y a 
robots móviles. Así mismo, se tiene la capacidad de teleoperar múltiples robots reales y virtuales 
en el mismo ambiente, utilizando la transmisión de video streaming para el monitoreo remoto de 
los robots reales con múltiples cámaras. Los robots teleoperados se pueden controlar mediante la 
interfaz gráfica del sistema o mediante el uso de joysticks. 
Finalmente, se probó la modularidad del ambiente virtual en red, añadiendo un modulo 
que permite el despliegue del ambiente virtual con librerías gráficas distintas a las definidas 
originalmente. 
ÍNDICE. 
1 Introducción. 
1.1 Planteamiento del problema. 
1.2 Objetivos. 
2 Teleoperación de robots. 
2.1 Los robots y la robótica. 
2.1.1 Robots manipuladores. 
2.1.2 Robots móviles. 
2.2 Teleoperación. 
2.3 Teleoperación en robótica. 
2.3.1 Teleoperación de robots. 
2.3.2 Telerobótica. 
2.4 Control remoto de robots. 
2.4.1 Comunicación remota. 
2.4.2 Interfaces gráficas para el control de robots. 
2.4.3 Monitoreo remoto de robots. 
2.4.3.1 Productos de RealNetworks. 
2.4.3.2 Camserv. 
2.4.3.3 JMF. 
3 Ambientes virtuales en red. 
3. 1 Realidad virtual. 
3 .2 Ambientes virtuales. 
9 
10 
11 
13 
13 
14 
16 
18 
21 
22 
23 
25 
25 
26 
28 
30 
30 
31 
33 
33 
34 
4 
3.2.1 Ambientes virtuales para robótica. 
3.3 Ambientes virtuales en red. 
3.4 Arquitecturas de net-VE's. 
3.4.1 SIMNET. 
3.4.2 DIS. 
3.4.3 HLA. 
3.4.4 NPSNET. 
3.4.5 OODVR. 
4 Trabajos relacionados. 
4.1 Teleoperación de robots vía una página web. 
4.1.1 ROBOSIM. 
4.1.2 RCVVL. 
4.1.3 Robot en línea UJI. 
4.2 Robots en ambientes virtuales. 
4.2.1 OGLSIMROB. 
4.2.2 Webots. 
4.2.3 IGRIP. 
4.3 Sistemas telerobóticos standalone. 
4.3.1 Robonauta. 
4.3.2 Operabotics. 
4.4 Net-VE's para telerobótica. 
4.4.1 VEVI. 
4.4.2 WITS. 
5 Desarrollo. 
5.1 Modificaciones de OODVR. 
5.1.1 Primera aplicación de robótica en OODVR. 
5.1.2 Problemas a solucionar en OODVR. 
5 .1.3 Modificaciones y mejoras externas. 
35 
37 
38 
39 
40 
42 
43 
45 
50 
51 
51 
52 
53 
54 
54 
56 
57 
58 
59 
60 
61 
61 
63 
70 
70 
74 
77 
78 
5 
5.1.4 Modificaciones y mejoras realizadas. 
5.1.4.l Protocolo de red. 
5.1.4.2 Automatización de una clase Robot. 
5.1.4.3 Base de datos. 
5.2 OODVR++. 
5.2.1 Teleoperación de robots virtuales. 
5.2.2 Teleoperación de robots reales. 
5.2.3 Dispositivos de control. 
5.2.4 Video streaming. 
5.3 Otro módulo en OODVR++. 
5.3.1 Despliegue gráfico en OpenGL. 
6 Resultados. 
7 Conclusiones. 
7 .1 Conclusiones particulares. 
7.2 Trabajo a futuro. 
Bibliografia 
79 
80 
83 
86 
92 
93 
98 
107 
111 
118 
119 
123 
126 
126 
128 
130 
6 
7 
LISTA DE FIGURAS Y TABLAS. 
Figura 2-1. El robot manipulador PUMA 560 de Unirnation Inc. 15 
Figura 2-2. El robot móvil Nomad 200 de Nomadic Technologies. 17 
Figura 2-3. Primer sistema de teleoperación. Laboratorio Nacional Argonne. 19 
Figura 2-4. Servomanipulador maestro-esclavo. 20 
Figura 2-5. Sistema teleoperado de un robot PUMA 560. JPL. 23 
Figura 2-6. Diagrama de una telecirugía. 24 
Figura 2-7. Telerobot Sojourner de la NASA. 26 
Figura 2-8. GUI utilizada para un telerobot en el JPL. 27 
Figura 2-9. Mini-telerobot y el monitoreo del mismo con múltiples cámaras. 29 
Figura 2-10. Ejemplo de transmisión de streaming video con camserv. 31 
Figura 2-11. JMStudio de JMF 2.1.1 capturando video de una WebCam. 32 
Figura 3-1. Telepresencia. 36 
Figura 3-2. Ejemplo de un helicóptero en un VE en DIS-Java-VRML. 42 
Figura 3-3. Ejemplo de VE de NPSNET-IV. 44 
Figura 3-4. Esquema de comunicación de OODVR. 47 
Tabla 3-1. Tabla comparativa entre OODVR y las otras arquitecturas de net-VE's. 49 
Figura 4-1. GUI y VE de RoboSiM. 52 
Figura 4-2. Sistema de Entrenamiento en Telerobótica UJI. 54 
Figura 4-3. Dos vistas de una celda de manufactura en OGLSIMROB. 55 
Figura 4-4. Dos simulaciones de robots en la interfaz y el VE de Webots. 57 
Figura 4-5. Dos simulaciones en el software IGRIP. 58 
Figura 4-6. Robonauta teleoperado por un especialista de la NASA. 59 
Figura 4-7. Dos ejemplos de teleoperación con Operabotics. 60 
Figura 4-8. Teleoperación, simulación y monitoreo de un robot submarino en VEVL 63 
Figura 4-9. GUI de WITS. 65 
Tabla 4-1. Parte 1 de una tabla comparativa entre WITS y otros trabajos de robots. 68 
8 
Tabla 4-2. Parte 2 de la tabla comparativa entre WITS y otros trabajos de robots. 69 
Figura 5-1. Aplicación de robots virtuales en la primera versión de OODVR. 76 
Figura 5-2. Arquitectura OODVR para robots virtuales. 76 
Figura 5-3. Diagrama Entidad-Relación de la DB de Robots. 89 
Figura 5-4. Diagrama de clases del paquete oodvr.db. 90 
Figura 5-5. Ventana de la GUI de OODVR++ con el controlador. 93 
Figura 5-6. Primera versión de teleoperación de robots virtuales en OODVR+. 95 
Figura 5-7. Cuatro robots manipuladores virtuales en OODVR++. 96 
Figura 5-8. Un robot manipulador y dos robots móviles en OODVR++. 97 
Figura 5-9. Teleoperación de múltiples robots. 97 
Figura 5-10. Robot móvil AmigoBot. 99 
Figura 5-11. Otros robots móviles de la empresa ActivMedia. 100 
Figura 5-12. Primera imagen de un ejemplo de teleoperación de un robot real. 104 
Figura 5-13. Segunda imagen de un ejemplo de teleoperación de un robot real. 104 
Figura 5-14. Tercera imagen de un ejemplo de teleoperación de un robot real. 105 
Figura 5-15. Cuarta imagen de un ejemplo de teleoperación de un robot real. 105 
Figura 5-16. Quinta imagen de un ejemplo de teleoperación de un robot real. 106 
Figura 5-17. Sexta imagen de un ejemplo de teleoperación de un robot real . 107 
Figura 5-18. Dispositivos de control utilizados. 108 
Figura 5-19. GUI para asignar los movimientos del dispositivo de control. 11 O 
Figura 5-20. Operación del AmigoBot virtualcon un joystick. 110 
Figura 5-21. Operación del Amigobot virtual con un volante. 111 
Figura 5-22. Primera imagen de un ejemplo de telemonitoreo por video streaming. 115 
Figura 5-23. Segunda imagen de un ejemplo de telemonitoreo por video streaming . 116 
Figura 5-24. Tercera imagen de un ejemplo de telemonitoreo por video streaming. 116 
Figura 5-25. Cuarta imagen de un ejemplo de telemonitoreo por video streaming . 117 
Figura 5-26. Quinta imagen de un ejemplo de telemonitoreo por video streaming. 117 
Figura 5-27. Arquitectura OODVR++. 118 
Figura 5-28. Ventana de selección del despliegue gráfico en OODVR++. 121 
Figura 5-29. Despliegue gráfico en OpenGL del robot Pwna 560 en OODVR++ 121 
Figura 5-30. Operación del robot Puma en OpenGL desde la GUI en Java. 122 
Tabla 6-1. Tabla de evaluación de las características de OODVR++. 125 
9 
1 INTRODUCCIÓN. 
A mediados del siglo XX, la teleoperación abarcaba el uso de un manipulador remoto 
controlado por un operador para manejo de sustancias peligrosas [l]. El manipulador remoto, 
llamado esclavo, era un dispositivo mecánico que traducía los movimientos del operador, 
realizados en otro dispositivo mecánico llamado maestro, en movimientos correspondientes en 
una posición remota. Comúnmente, el operador observaba la ejecución de la tarea a través de 
una ventana de cristal plomado o mediante televisión en circuito cerrado . 
En las últimas décadas, el interés en el uso de la robótica fue aumentando en varios países 
del mundo. Dicho interés no solo es en las áreas de investigación e industria, sino también en las 
áreas de educación y entretenimiento. En estas áreas mencionadas, los robots se desempeñan en 
la mayoría de sus aplicaciones de dos maneras: un operador controla los movimientos del robot 
( como sucede en la teleoperación), ó el robot puede .guiarse autónomamente por haber sido 
programado previamente. 
Actualmente, los sistemas de teleoperación han sido implementados en una gran cantidad 
de aplicaciones de robótica, y han evolucionado al controlar distintos robots a grandes distancias 
a través de una red alámbrica, inalámbrica, vía Internet, vía satélite en la Tierra o a través del 
espacio. El dispositivo maestro ya no es necesariamente algo mecánico o eléctrico, sino que 
también ha evolucionado hasta llegar a ser interfaces gráficas controladas desde una o más 
computadoras. Con el avance de las gráficas por computadora, dichas interfaces podrían incluir 
un mundo virtual similar al real en donde se controlaría al robot. Entonces se podrían tener 
10 
"Robots Teleoperados en Ambientes Virtuales". 
1.1 PLANTEAMIENTO DEL PROBLEMA. 
Debido al aumento de la cantidad de equipo de cómputo en las empresas, universidades y 
hogares, y al crecimiento en el acceso a redes de alta velocidad y a la Internet, se puede hacer un 
mayor uso de la teleoperación de robots a grandes distancias. La teleoperación de robots puede 
ser útil también cuando se desea programar un robot autónomamente, ya que se necesita primero 
operarlo normahnente para saber la forma en que se mueve y así poder programarlo para que 
trabaje en lugares lejanos. 
Por otra parte, los robots son todavía escasos en algunos países como México, por sus 
altos costos, siendo dificil tener varios robots para distintas pruebas de investigación o para la 
enseñ.anza y capacitación de muchas personas al mismo tiempo. 
En las últimas décadas, los trabajos hechos en teleoperación de robots han sido 
implementados utilizando cada vez más los nuevos desarrollos en las áreas de realidad virtual y 
de redes computacionales. Tal es el caso de los Ambientes Virtuales en Red en donde se 
aprovechan los últimos avances de la realidad virtual y de la infraestructura tecnológica de red 
para interactuar remotamente con otros usuarios o robots. 
Existen algunos sistemas desarrollados para teleoperación de robots mediante el uso de 
ambientes virtuales, en estos un usuario teleopera un robot real remoto por medio del control de 
un robot virtual en un mundo virtual local. Otros sistemas incluyen la teleoperación de un robot 
virtual. Pero en ambos casos sólo un usuario puede interactuar en el ambiente virtual. 
El problema en los desarrollos actuales es que todavía no se implementan aplicaciones de 
teleoperación de robots en ambientes virtuales en red que estén disponibles para cualquier tipo de 
usuario. Los pocos trabajos en el área son sistemas hechos por laboratorios de la Administración 
11 
Nacional de Aeronáutica y del Espacio o NASA (National Aeronautics and Space Administration) 
de los Estados Unidos y que sólo lo pueden utilizar con toda su funcionalidad los investigadores 
que trabajen o tengan alguna relación con la NASA. 
Por lo tanto, en el área de enseñanza e investigación debe existir un sistema de ambientes 
virtuales en red para teleoperación de robots con las siguientes características: 
• Interacción de múltiples usuarios distantes con uno o varios robots virtuales y reales en un 
ambiente virtual en tiempo real. 
• Colaboración de usuarios entre sí en distintas tareas. 
• Monitoreo en tiempo real del robot real teleoperado por medio de un formato de 
compresión y transmisión de video. 
• Teleoperación de robots virtuales móviles o manipuladores. 
• Distribución de la carga de procesamiento del ambiente virtual compartido en distintas 
plataformas de cómputo. 
• Enseñanza de distintos conceptos de robótica o explicación del uso de distintos robots 
para varios alumnos. 
1.2 OBJETIVOS. 
El objetivo general es desarrollar un sistema de ambiente virtual en red para teleoperación 
y monitoreo mediante video de robots móviles y manipuladores virtuales o reales que sea 
modular, portable, escalable, distribuido y multiusuario. Este sistema podrá ser fácilmente 
utilizado y modificado para integración de nuevos módulos por investigadores en el área de la 
robótica, profesores y alumnos. 
El sistema se basará en una arquitectura para el desarrollo de ambientes virtuales en red, 
llamada Arquitectura Orientada a Objetos para Realidad Virtual Distribuida u OODVR (Object 
Oriented Distributed Virtual Reality). A continuación se mencionan los objetivos específicos que 
se desarrollaron y se explican en este trabajo: 
1. Modificar la arquitectura OODVR. La arquitectura OODVR no fue definida ru 
12 
implementada completamente en su versión original. Por lo tanto, se deben añadir 
algunas características importantes y modificar la arquitectura para mejorarla. 
2. Afiadir la geometría de los robots en la arquitectura. Realizar u obtener el modelo 
geométrico de los robots virtuales que se desean incluir en el ambiente virtual. Incluir los 
modelos virtuales de algunos robots móviles o manipuladores existentes en el Instituto 
Tecnológico de Estudios Superiores de Monterrey Campus Estado de México (ITESM-
CEM). 
3. Hacer un sólo programa genérico con el cual se añada cualquier tipo de robot móvil o 
manipulador al ambiente virtual. 
4. Crear un controlador maestro o interfaz para teleoperar cada robot virtual. 
5. Desarrollar los programas que harán la teleoperación de un robot real desde la 
arquitectura. 
6. Realizar un módulo de monitoreo remoto por medio de video para observar las tareas que 
desempeñ.an los robots reales. El video podrá ser tomado de cámaras que observan al 
robot real o están montadas sobre él. 
7. Integrar un módulo extra en la simulación. Por ejemplo, la teleoperación de un robot 
virtual con otro tipo de despliegue gráfico, un módulo de visión o de planeación de rutas. 
13 
2 TELEOPERACIÓN DE ROBOTS. 
La unión de los primeros trabajos de la teleoperación con la creación de los primeros 
robots dieron lugar a la teleoperación de robots y a la telerobótica. En este trabajo se tiene la 
posibilidad de desarrollar el control remoto de distintos tipos de robots en un mismo sistema. 
Para esto, los primeros trabajos y los conceptos específicos necesariosen los campos de la 
robótica y la teleoperación son explicados a continuación. 
2.1 LOS ROBOTS Y LA ROBÓTICA. 
El término robot fue introducido al vocabulario en 1920 con el drama satírico "Rossum 
Universal Robots" del checo Karel Capek [2]. La palabra robot proviene de la palabra checa 
robota, que significa trabajo forzado. Desde entonces el término ha sido aplicado a una gran 
variedad de dispositivos mecánicos, tales como manipuladores, telemanipuladores, vehículos 
submarinos, vehículos en tierra autónomos, etc. Virtualmente algo que opera con algún grado de 
autononúa, usualmente bajo control de una computadora, tiende a ser llamado robot. En suma, 
un robot es un dispositivo mecánico-electrónico reprogramable de uso general con sensores 
externos que puede efectuar diferentes tareas. Siendo la reprogramabilidad el elemento clave, el 
cerebro computarizado que da al robot su utilidad y adaptabilidad. 
14 
El término robótica se atribuye en 1939 a Isaac Asimov, escritor de ciencia ficción. La 
robótica es una ciencia aplicada que ha sido considerada como una combinación de tecnología de 
las máquinas - herramientas y de la informática [ 1]. Comprende y relaciona campos tan 
aparentemente diferentes como diseño de máquinas, dispositivos mecánicos, teoría de control, 
microelectrónica, programación de computadoras, inteligencia artificial, factores humanos, teoría 
de la producción y a los robots. En las primeras décadas de la robótica, las áreas de investigación 
e industria avanzaron en todos los campos mencionados para mejorar la forma en que trabajaban 
los robots y para que fueran más autónomos. De esta manera, la necesidad de aumentar cada vez 
más la productividad y conseguir productos acabados de una calidad uniforme, hizo que la 
industria girará hacia una automatización basada en la robótica. En consecuencia, la robótica era 
una forma de automatización industrial. Pero en los últimos años la robótica también se está 
utilizando mucho en áreas como la educación, entretenimiento y algunas otras áreas de aplicación 
más específicas que se mencionarán en los siguientes subpuntos. 
Los robots se pueden clasificar de muchas formas: por generaciones, por su aplicación, 
por su configuración fisica, por diversos criterios de distintas asociaciones, por su grado de 
autononúa, etc. Pero se considera que la clasificación más general de los robots es por su tipo y 
se divide en dos: robots manipuladores y robots móviles. Estos son los dos tipos de robots que 
actualmente se construyen y se venden comercialmente en distintas empresas [3]. 
2.1.1 ROBOTS MANIPULADORES. 
Los robots manipuladores son robots con una anatonúa o con la construcción fisica de un 
brazo mecánico controlado por computadora. Estos robots están montados en una base que está 
fija, su cuerpo está formado por varios eslabones conectados por articulaciones, y al final de la 
última articulación se encuentra el efector final o herramienta con la cual realizará una tarea 
específica [l]. Al movimiento individual, ya sea de translación o de rotación con respecto a 
algún eje coordenado, de cada articulación individual del robot se le llama grado de libertad. El 
robot industrial, que fue el robot más común en los inicios de la robótica, es un robot 
manipulador. 
Una definición utilizada por el "Instituto del Robot de América" da una descripción más 
15 
precisa de los robots industriales: "Un robot industrial es un manipulador reprogramable 
multifuncional diseñado para mover materiales, piezas, herramientas ó dispositivos 
especializados a través de movimientos programados variables para la ejecución de una 
diversidad de tareas" [2]. En la figura 2-1 se muestra un ejemplo de robot industrial llamado 
PUMA 560 de la empresa Unimation Inc. 
Figura 2-1. El robot manipulador PUMA 560 de Unimation Inc. 
Los robots manipuladores se utilizan en distintas aplicaciones de la industria. 
Actualmente la mayoría de las aplicaciones se encuentran en los procesos de fabricación en 
celdas de manufactura. Las aplicaciones que se empiezan a desarrollar son en áreas de 
construcción, exploración del espacio, cuidados médicos y educación. La mayoría de las 
aplicaciones industriales de los robots manipuladores se pueden clasificar en tres tipos [1]: 
l. Aplicaciones de manipulación de materiales, carga y descarga. La función del robot 
consiste en desplazar materiales o piezas en la celda de manufactura de un lugar a otro. 
También se incluye la carga y descarga de máquinas de producción. 
2. Aplicaciones de procesos. En esta categoría se incluye la soldadura por puntos, la 
soldadura por arco, la pintura al spray y otras operaciones en las que la función del robot 
es manipular una herramienta para realizar algún proceso de fabricación en la celda de 
manufactura. 
16 
3. Ensamble e inspección. El ensamble de partes es muy utilizado en la industria automotriz 
y se está incrementando en la fabricación de circuitos integrados y electrónicos. Los 
robots de inspección hacen uso de sensores para calibrar y medir características de calidad 
del producto fabricado. 
2.1.2 ROBOTS MÓVILES. 
Un robot móvil es una combinación de varios componentes de hardware y de software, y 
puede ser considerado como una colección de los siguientes cuatro subsistemas [4]. 
l. Locomoción. Con la locomoción el robot se mueve a través de su ambiente. 
Dependiendo del tipo de locomoción los robots móviles se dividen en robots terrestres, 
acuáticos, aéreos y del espacio, siendo los más comunes los robots móviles terrestres y a 
los que se referirá en este trabajo. 
• Hardware: incluye motores, engranajes, la estructura del robot, etc., y el dispositivo 
específico dependiendo del tipo de locomoción como lo son ruedas, orugas ( como 
las de un tanque), patas o piernas, hélices, cohetes, etc. 
• Software: provee los mecanismos o librerías para mover el hardware de 
locomoción. 
2. Sensado. Con el sensado el robot mide propiedades de sí mismo y de su ambiente. 
• Hardware: puede incluir una serie de sensores internos como acelerómetros, 
giroscopios, inclinómetros, etc.; sensores externos no visuales como táctiles, 
infrarrojos, de sonar, de radar, de láser, de posición basados en satélite o GPS 
(Global Positioning System), magnéticos, etc; y sensores de visión basados en 
cámaras. 
• Software: provee los mecanismos o librerías para accesar los datos obtenidos por 
los sensores. 
3. Razonamiento. Con el razonamiento el robot mapea las medidas sensadas en acciones. 
• Hardware: incluye la computadora o computadoras que controlan al robot. 
• Software: incluye los algoritmos que en base a toda la infonnación de los demás 
subsistemas, toma las decisiones de acción del robot. 
4. Comunicación. Con la comunicación el robot se comunica con un operador o con 
17 
computadoras externas. 
• Hardware: puede incluir conecc1ones alámbricas o inalámbricas por medio de 
comunicación serial o por red. 
• Software: provee los mecanismos para enviar y recibir datos a través del hardware 
de comunicación. 
Una gran diferencia entre los robots manipuladores y los robots móviles es que los 
primeros operan dentro de un ambiente de trabajo limitado debido a que mantienen una posición 
fija, y los segundos tienen un ambiente de trabajo variable debido a que pueden cambiar su 
posición a través de la locomoción [5]. En la figura 2-2 se muestra un ejemplo de robot móvil 
llamado Nomad 200 de la empresa Nomadic Technologies. 
Figura 2-2. El robot móvil Nomad 200 de Nomadic Technologies. 
Los robots móviles se utilizan mucho para tareas con ciclos de trabajo demandantes, para 
llegar a ambientes inhóspitos donde enviar a una persona sería muy costoso o muy peligroso, 
para llegar a ambientes inaccesibles para una persona, o para llegar a un ambiente remoto donde 
podría tomar mucho tiempo enviar a una persona [4]. Las áreas de aplicación de los robots 
móviles son: la transportaciónde materiales entre distintas locaciones, la inspección y el 
reconocimiento en procesos industriales, el uso de los mismos como vehículos inteligentes o 
vehículos aéreos, la automatización en minería, la robótica espacial, el reconocimiento militar, la 
desactivación de bombas y minas, la inspección submarina, la agricultura y la ingeniería forestal, 
la ayuda a deshabilitados, el entretenimiento, y la limpieza del hogar. 
18 
2.2 TELEOPERACIÓN. 
La creación de herramientas especiales para "manejo remoto" ha sido una parte integral 
de la adaptación natural de los seres humanos a sus ambientes a través de la historia [6]. 
Alrededor de 1940, se intensificó la realización de sistemas de manejo remoto para que los 
científicos experimentaran la fisica atómica y la radioactividad, permitiéndoles así trabajar con 
ambientes peligrosos. Los primeros sistemas de manejo remoto fueron muy simples. Se 
construyeron paredes de materiales blindados que protegían a los usuarios del ambiente peligroso 
que se encontraba detrás de ellas; por lo tanto, se utilizaban periscopios y arreglos de espejos para 
ver las áreas de trabajo a través de los muros. También se fabricaron varias herramientas largas, 
para que los trabajadores manipularan los objetos detrás de la pared, para realizar los 
experimentos y pruebas con radiación. 
Conforme avanzó la ciencia, los experimentos llegaron a ser más complicados, entonces 
las herramientas para manejo remoto también tuvieron que serlo. Se construyeron muros 
protectores transparentes para que se pudiera observar a través de ellos el área de trabajo. 
También se crearon nuevos sistemas de manipuladores mecánicos a través de los cristales que 
permitían a los operadores realizar mejor las tareas. 
La división de Control Remoto del Laboratorio Nacional Argonne, en Chicago - Estados 
Unidos, tomó el reto de desarrollar un mecanismo que tuviera un controlador maestro donde un 
operador pudiera proporcionar los comandos de posición y orientación a un mecanismo esclavo ó 
sistema de encadenamiento que replicaría los movimientos y fuerzas en un área de trabajo remota 
[6]. Este reto fue logrado en 1948 por Raymond C. Goertz, en el mismo laboratorio, quien 
desarrolló el primer sistema de teleoperación para utilizarlo en el manejo de materiales 
radiactivos (ver figura 2-3) [7]. En las primeras implementaciones de teleoperación, el 
manipulador maestro y el brazo esclavo remoto eran dispositivos mecánicos cinemáticamente 
idénticos, es decir que los límites y movimientos de las articulaciones del manipulador esclavo 
eran exactamente las mismas que las del maestro. También los dos mecanismos maestro-esclavo 
eran copias exactas a distinta ó misma escala. 
19 
Figura 2-3. Primer sistema de teleoperación. Laboratorio Nacional Argonne. 
El Laboratorio Nacional Argonne siguió realizando muchos avances en teleoperación 
durante los siguientes 15 años. Para 1952, Goertz crea un sistema de teleoperación bilateral, es 
decir, con retroalimentación de fuerzas tanto del dispositivo maestro hacia el esclavo, como de 
manera opuesta. Aún así, debido a la construcción mecánica de dichos sistemas, permitían una 
separación fisica promedio de diez metros entre el operador y el área de trabajo [6]. 
Debido al problema de tener una reducida separación fisica, para mediados de la década 
de los 50's se desarrollaron manipuladores maestro-esclavo eléctricos, a los cuales también se les 
llamó servomanipuladores eléctricos. También evolucionó el sistema de observación de la tarea 
remota por medio de televisores en circuito cerrado. En estos últimos sistemas se intentaba 
acomodar al dispositivo maestro, de tal manera que sus articulaciones coincidieran con las del 
operador [8]. 
En la siguiente figura 2-4 se muestra un sistema de teleoperación con servomanipuladores 
desarrollado en el Laboratorio Nacional Argonne. 
20 
Figura 2-4. De arriba hacia abajo: Operador moviendo el dispositivo maestro eléctrico o 
servomanipulador, y monitoreando el dispositivo esclavo por medio de 
televisores de circuito cerrado; dispositivo esclavo eléctrico. Laboratorio 
Nacional Argonne. 
En suma, la teleoperación pennite a un operador en una localidad ejecutar una tarea en 
otra localidad, quizás a gran distancia [7]. Los sistemas de teleoperación tienen los siguientes 
componentes: 
• Una interfaz de operador, incorporando un dispositivo de entrada llamado maestro que el 
operador utiliza para controlar al sistema. 
• Un dispositivo de salida llamado esclavo que ejecuta las acciones solicitadas por el 
operador en un sitio remoto. 
• Un esquema de comunicación entre los dos sitios. 
21 
2.3 TELEOPERACIÓN EN ROBÓTICA. 
A inicios de la década de los 50's el desempeño de los sistemas de teleoperación era muy 
pobre en comparación a la eficiencia de trabajo de una persona, es decir, era entre diez y cien 
veces más lento que operar con herramientas directamente [6]. Por lo tanto, muchos objetivos en 
investigación y desarrollo de teleoperación se enfocaron en distintos caminos para mejorar la 
eficiencia de trabajo de las operaciones remotas. Estos objetivos incluyeron el desarrollo de 
mejores manipuladores, estaciones de control, algoritmos de control, etc. 
En 1954, George Devol, científico de Estados Unidos, diseñó el primer robot bajo la 
patente "transferencia de artículos programada". Dicho robot era un manipulador cuya operación 
podía ser programada, por lo tanto cambiada; es decir, el robot podía seguir una secuencia de 
pasos de movimientos determinados por las instrucciones de un programa [2]. Para 1961, George 
Devol y Joseph Engelberger, con la fundación de su empresa Unimation Inc en Estados Unidos, 
instalan el primer robot industrial comercial, llamado Unimate, en una fábrica automotriz [ 1]. 
Posteriormente, en 1969 Nils Nilsson, de la Universidad de Stanford, desarrolló el primer 
robot móvil, llamado SHAKEY, que incluía una cámara, sensores táctiles y comunicación vía 
radio a una computadora marca DEC [5]. Con la creación de nuevos robots móviles surge el 
concepto de robótica móvil, la cual era una nueva área de investigación que se encarga del 
control y el estudio de algoritmos para los cuatro subsistemas de un robot móvil autónomo o 
semiautónomo [ 4]. 
La forma de operar cualquier robot puede ser de dos maneras: autónoma o semiautónoma 
[4]. Un sistema autónomo es aquel diseñado para que el robot se opere por sí mismo sin control 
humano externo; es decir, el robot puede ser totalmente autónomo por haber sido programado 
previamente así. Un sistema semiautónomo es aquel en el cual es requerido un operador para 
mover al robot, pero también el robot puede tomar decisiones por su cuenta; es decir, el robot 
puede tener cierto grado de autonomía. 
22 
Durante la década de los 70's y hasta finales de la década los 80's, conforme se fueron 
desarrollando robots más sofisticados, fueron utilizados para teleoperación en aplicaciones 
submarinas, militares, del espacio, nucleares y de ambientes peligrosos [6]. Sin embargo, en los 
últimos años la teleoperación se generalizó al control remoto de robots y así ha incrementado su 
uso en aplicaciones como la medicina, la minería, la arqueología, el entretenimiento y la 
educación. 
De manera general, se puede decir que el control remoto de robots se divide en la 
teleoperación de robots y en la telerobótica; es decir, el control remoto de robots es un sistema 
semiautónomo que puede ser operado de dos formas: como un sistema teleoperado o como un 
sistema telerobótico [7]. El ténnino control no se refiere a la teoría de control analógico o digital 
de un robot, sino que se refiere a tener el control de la operación del robot. 
2.3.1 TELEOPERACIÓN DE ROBOTS. 
La teleoperación de robots es una tecnología que implica el uso de un sistema 
teleoperado, el cual se conforma de un operador que remotamente guía de forma directa al robot, 
causandocada incremento de movimiento de sus grados de libertad; es decir, el robot sigue los 
movimientos exactos solicitados por el operador siempre que sus capacidades fisicas se lo 
permitan [8]. 
Los robots teleoperados, también llamados teleoperadores, son parte de un sistema 
teleoperado en el cual el dispositivo remoto o robot es controlado momento a momento por un 
operador con funciones a muy bajo nivel [4]. 
La teleoperación de robots puede recibir datos del hardware de sensado del robot, por 
ejemplo la retroalimentación de fuerzas o la imagen de su cámara, pero realiza las acciones de 
movimiento del robot dictadas por el operador sin considerar algoritmos que procesen esos datos. 
Este tipo de sistema tiene el más bajo grado de autonomía de un sistema semiautónomo, es decir 
que el operador toma todas las decisiones. 
En la figura 2-5 se muestra un ejemplo de los primeros sistemas de teleoperación de 
23 
robots que aprovechaba el uso de la electrónica y las computadoras. Este sistema fue diseñado 
por A. K. Bejczy y J. K. Salisbury, del Laboratorio de Propulsión de Jets o JPL (Jet Propulsion 
Laboratory) de la NASA, a finales de la década de los 70's [8]. Ellos pennitieron que los 
dispositivos maestro y esclavo ya no necesitaran ser cinemáticamente idénticos, ni que fueran 
semejantes pero a distinta escala. El operador movía con una mano el dispositivo maestro, el 
cual era un mecanismo de 6 grados de libertad, entonces la computadora realizaba las 
transformaciones de coordenadas necesarias para mover el dispositivo esclavo, el cual era un 
robot industrial PUMA 560 con 6 grados de libertad y sensores de fuerza. Finalmente, en base a 
la retroalimentación de fuerzas y al monitoreo del robot mediante varias cámaras, entonces, el 
operador tomaba las decisiones sobre los movimientos que seguirían. 
Figura 2-5. Sistema teleoperado de un robot PUMA 560. JPL. 
2.3.2 TELEROBÓTICA. 
La telerobótica es una tecnología que implica el uso de un sistema telerobótico, el cual 
realiza una comunicación a un alto nivel de abstracción en el cual el operador comunica las metas 
y el robot sintetiza una trayectoria o plan para alcanzar la meta [8]. 
En un sistema telerobótico, los comandos de bajo nivel ejecutados por el operador son 
interpretados o filtrados por algoritmos de software, que consideran los datos obtenidos de los 
24 
sensores localizados en el robot, para limitar o interpretar las acciones del operador [ 4]. 
La telerobótica soporta la interacción de información proveniente del sensado, de la 
planeación de rutas, o de la teoría de control aplicada para que el robot pueda tornar decisiones en 
algún momento durante el cual el operador está realizando el control remoto del mismo. 
Dependiendo de cuánta de esa información se considere para la torna de decisiones será el grado 
de autonomía variable que se tendrá en este sistema semiautónomo. 
En la figura 2-6 se muestra un diagrama ejemplificando una aplicación de la telerobótica 
en la medicina; en dicha aplicación al realizar una cirugía telerobótica surge el nuevo término de 
telecirugía que se refiere a la realización de una cirugía remota que puede utilizar varios 
conceptos y dispositivos de realidad virtual [9]. En la telecirugía un cirujano opera locahnente un 
modelo del paciente virtual, entonces sus acciones son transmitidas a un asistente robot que opera 
al paciente en una localidad remota. El primer experimento en telecirugía fue realizado entre el 
JPL, localizado en la ciudad de Pasadena California en Estados Unidos, y el Laboratorio de 
Telerobótica del Politécnico de Milán, localizado en la ciudad de Milán en Italia [1 O]. En este 
experimento se realizó una laparoscopía de un cerdo y la transmisión fue hecha a través de dos 
satélites. 
VIRTUAL INTERFACE 
ENVIRONMENT 
TACTILE 
INPUT/FEEDBACK 
WINDOWS 
REIIOTE 
IIANIPULATION 
Figura 2-6. Diagrama de una telecirugía. 
HEAO-COUPLED 
25 
2.4 CONTROL REMOTO DE ROBOTS. 
Para tener un meJor desempeño y un mayor control en un sistema teleoperado o 
telerobótico se debe tener un medio de comunicación remoto eficiente entre el operador y el 
robot, también se debe mantener un monitoreo remoto de las tareas que ejecuta el robot por 
medio de diversas cámaras de video, además de incluir interfaces gráficas simples que faciliten el 
control de los robots. 
2.4.1 COMUNICACIÓN REMOTA. 
En los primeros sistemas de teleoperación, la distancia entre el operador y el sitio remoto 
estaba restringida a unos pocos metros por la necesidad del operador de ver y monitorear 
directamente las acciones que se llevaban acabo en el ambiente remoto. El medio fisico para la 
comunicación eran sistemas mecánicos. A estos sistemas se les llamó teleoperación de corto 
rango. Debido a que había una separación muy pequeña entre los 2 dispositivos maestro-esclavo, 
entonces no existía un retraso en las comunicaciones. 
Cuando los sistemas de teleoperación se volvieron eléctricos, se podía incrementar en 
muchos metros la separación entre el operador y el ambiente remoto. El monitoreo se realizaba 
por medio de televisores de circuito cerrado. A estos sistemas se les llamó teleoperación de 
mediano rango y el retraso en la comunicación no era perceptible [7]. 
Actuahnente, el control remoto de robots ha sido implementado en muchas aplicaciones 
donde el robot requiere ser operado a grandes distancias. Por lo tanto, ahora la comunicación se 
realiza a través de una red alámbrica local, de una red inalámbrica, vía Internet, vía satélite en la 
Tierra o a través del espacio [7]. A estos sistemas se les llama teleoperación de largo rango y en 
ellos ya existen retrasos de tiempo perceptibles entre los movimientos que solicita el operador y 
los movimientos ejecutados en el robot, por lo tanto son necesarios algoritmos de sincronización 
entre los dispositivos maestro- esclavo. 
26 
Uno de los ejemplos más recientes de teleoperación vía satélite a través del espacio es el 
telerobot móvil Sojoumer, que se muestra en la figura 2-7, el cual fue utilizado por la NASA en 
el proyecto Pathfinder para exploración del planeta Marte en 1997 [4]. Este robot fue operado 
como un sistema telerobótico seleccionando puntos para sus rutas desde el centro de control en la 
Tierra, por lo tanto este robot tuvo un alto grado de autonomía debido a que los retrasos de la 
comurúcación no eran factibles para un continuo control o teleoperación del robot por parte de 
los operadores desde la Tierra. 
Figura 2-7. Telerobot Sojoumer de la NASA. 
2.4.2 INTERFACES GRÁFICAS PARA EL CONTROL DE ROBOTS. 
El dispositivo maestro en teleoperación también ha evolucionado; en sus principios era un 
brazo mecánico o eléctrico, después fue una caja con botones y switches (llamado en inglés 
teach pendant) que mapeaba directamente cada botón a cada movirrúento del robot, 
posteriormente se utilizaron joysticks, dispositivos hápticos, etc. 
Recientemente, con los avances en el área de gráficas por computadora, para realizar el 
control remoto de uno o varios robots se han utilizado dos tipos de sistemas avanzados: las 
Interfaces de Usuario Gráficas o GU/'s (Graphical User Interfaces) controladas por 
computadora, y el reconocirrúento de posiciones de la mano del operador por medio de visión por 
computadora [7]. Al utilizar GUI's que sustituyan al dispositivo maestro que teleopera al robot se 
tiene una implementación más simple y más barata. 
27 
Un ejemplo del uso de este tipo de interfaces de usuario gráficas es el que realizó B. 
Hannaford, en el JPL en 1991, para permitir a un operador seleccionar y controlar en distintos 
modos cada uno de los seis grados de libertad de un telerobot [8]. Esta GUI se muestra en la 
figura 2-8. 
·~ 
.''I 
"-" 
•• 
"~ 
.••. 
m::: 
---,;f,u;. •'\•l•;J 
, H)u,:. 
,1•:;Q(• 
,•f•III• 
,'.~~ ,,.)(,.,1 ,lrl'(.t, 
i~l U'.il -·· 
§1 IB! .. 
• li] [fil .. ' ,.,.. !. 
H,.,11 
Úpil( ·1: 
• • • rE:iC;.:J: 
~ :~.' . 
·.·.·,.' ... ] ~ ... . 
'--~ ·• 
~--- fltl .•• ""'•; -
• , ... ,, . .; - n1 
.. 1tN..r, 
•':•:•• ,¡._..¡_:,,(: 1------------
(ro:::) (-, .. 
Figura 2-8. GUI utilizada para un telerobot en el JPL. 
De la misma manera que para el dispositivo maestro, el dispositivo esclavo también puede 
ser reemplazado por una simulación gráfica tridimensional del robot o modelo virtual del mismo 
que sea muy parecido al robot real. Este avance en las gráficas por computadora ayuda en 
aplicaciones de educación y enseñanza, en los cuales no se tienen siempre disponibles todos los 
robots reales para aprender a utilizarlos. Así, se puede enseñar el funcionamiento de muchos 
tipos de robots por medio de sistemas de simulación que los incluyan virtualmente. 
Paul S. Schenker del JPL menciona que en los últimos aftos las GUI's se han establecido 
como un rol importante en el diseño de los sistemas robóticos donde el usuario tiene que 
interactuar con un robot a través de la computadora, logrando reducir la curva de aprendizaje del 
operador [11]. El manejo de íconos y menús en las GUI's ayuda a representar estructuras 
complejas y relaciones entre objetos y eventos. Además, es importante que una interfaz de 
gráficas 3D sirva como herramienta de simulación de tareas de los robots y como un medio de 
28 
interacción del operador en línea con los robots y su ambiente. En general, es de gran interés el 
diseño interactivo 3D y la animación en tiempo real de robots en VE's como parte de una GUI en 
sistemas robóticos. 
2.4.3 MONITOREO REMOTO DE ROBOTS. 
El monitoreo en el último tipo de sistemas de teleoperación de largo rango se realiza por 
medio de cámaras de video que observan el ambiente de trabajo del robot, o con cámaras 
montadas sobre los robots para ver su ambiente desde su punto de vista. 
En la década de los 90's fue muy común el control de sistemas de cámaras remotas vía 
Internet, desplegándose las imágenes de video en una página de web. Las primeras 
implementaciones de esto mostraban una cafetería de la Universidad de Cambridge y un tanque 
con peces de la empresa Netscape [7]. Posteriormente, estos sistemas se implementaron en 
aplicaciones de control remoto de robots. Pero lo común en la mayoría de estos trabajos era 
capturar una nueva imagen de la cámara cada detenninado tiempo y enviarla a un servidor de 
web; para esto utilizan un formato de imagen pequeña, por ejemplo JPEG. Esto reduce el monto 
de información transmitida al enviar imágenes a través de Internet. Sin embargo, se pierde 
continuidad en el video, y quizás esto podría afectar la teleoperación de los robots. 
En algunos otros sistemas de teleoperación se despliega el video de una manera continua 
y sin retrasos por medio de formatos específicos para compresión y transmisión de video, debido 
a que si se transmitiera el video sin compresión sería muy lento el despliegue. A la transferencia 
remota de flujo de datos con contenido multimedios (audio y/o video) comprimido se le llama 
streaming media, y están basados en el envío de streams o flujos de detenninado tamaño de los 
datos teniendo un indicativo de tiempo [ 12]. La velocidad de transmisión de este tipo de video 
puede tener un desempeño aceptable en el limitado ancho de banda de Internet, pero podría dar 
un desempeño mucho mejor ( despliegue de video en tiempo real) a través de un ancho de banda 
más amplio o dedicado a esa tarea solamente, por ejemplo en redes de área local o en Internet 2. 
En la figura 2-9 se muestra un sistema telerobótico con un mini-telerobot para manejo de 
cristales de protemas, desarrollado en 1997 por la Universidad de Washington, la Universidad de 
29 
Alabama y la compañía del espacio y de la defensa Boeing [8]. Este sistema fue desarrollado 
para realizar experimentos remotos en la Estación Espacial Internacional (EEI); su monitoreo se 
controla a través de íconos de una interfaz de control virtual que permite observar lo que capturan 
las distintas cámaras que observan el área de trabajo del experimento, así como las cámaras que 
están montadas en el robot. En ese proyecto se utiliza compresión de video para la transmisión y 
despliegue. 
\. L -
Figura 2-9. De izquierda a derecha: rnini-telerobot para manejo de cristales de proteínas para la 
EEI, y el monitoreo del mismo con múltiples cámaras. 
Debido a que el streaming media maneja contenido multimedios de audio y/o video, por 
lo tanto se le llama streaming video a la transferencia remota de flujo de datos de video 
comprimido. Las tres formas más comunes para realizar transmisión de ese video comprimido 
por red mediante el manejo de streaming media son: 
• El uso de software comercial como lo son el RealOnePlayer, el Helix Producer Plus y el 
Helix Universal Server de la compañía Real Networks que se describe más adelante en el 
2.4.2.1. 
• El uso de servidores de web dedicados que transmiten streaming video y se pueden 
accesar desde una página web. Un ejemplo de estos es el programa camserv, para el 
sistema operativo Linux, descrito en el siguiente subpunto 2.4.2.2. 
• El uso de librerías de programación de compresión y transmisión de streaming video que 
permitan programar una aplicación interactiva en algún lenguaje de programación. Por 
ejemplo las librerías JMF que se explican a continuación en el 2.4.2.3, utilizadas desde el 
lenguaje de programación orientado a objetos llamado Java de la empresa Sun 
30 
Microsystems [13] que fue escogido como el lenguaje para desarrollar la aplicación de 
este trabajo. 
2.4.3.1 Productos de RealNetworks. 
RealNetworks es una empresa con varios productos enfocados en el streaming media entre 
los cuales se encuentran RealOne Player, Helix Producer Plus y Helix Universal Server [14]. 
Los productos de RealNetworks están más enfocados para web; algunos productos para 
transmisión de video y/o audio en Internet son utilizados por varias empresas radiodifusoras, de 
televisión y otras, y otros productos, más utilizados por usuarios comunes, son para recepción de 
esos datos en el formato de archivo llamado RealMedia que incluye a los formatos llamados 
RealAudio y RealVideo. 
El RealOne Player, llamado RealPlayer en versiones anteriores, es el producto para 
recepción de streaming, despliegue y reproducción de audio y video. Para la captura, edición y 
codificación de formatos RealMedia se utiliza el producto Helix Producer Plus, antes llamado 
Real Producer. El producto Helix Universal Server es el servidor de streaming que envía los 
streams del archivo RealMedia codificado a las computadoras clientes que lo solicitan. 
Algunos trabajos para teleoperación de robots han optado por utilizar esta opción. Pero, 
un problema de utilizar productos comerciales es que son programas sin código abierto, con los 
cuales no se pueden programar módulos extras a lo que el producto ofrece, además de que el 
monitoreo por video estaría por separado de una aplicación que fue desarrollada con algún 
lenguaje de programación. Otro problema es que son productos shareware que tienen un periodo 
de evaluación de unos pocos días y después deben ser comprados por varios miles de dólares. 
2.4.3.2 Camsenr. 
Camserv es un programa libre, de código abierto para Linux, que permite hacer streaming 
video a través del web [15]. La conversión del video a streams se realiza al ejecutarse el servidor 
de streaming camserv, el cual toma un puerto de red para la transferencia. Camserv, en su última 
31 
versión 0.5.1-1, toma como entrada el video capturado desde los dispositivos de video que 
soporta, los cuales son compatibles con el driver Video4Linux que funciona con las cámaras de 
video comunes compatibles a la WebCam (cámara para web de la marca Creative Labs) y con las 
tarjetas de entrada de video o frame grabbers de la empresa Hauppage. Los usuarios pueden 
observar el video al conectarse a una página de web del servidor donde se está corriendo 
camserv.En la figura 2-1 O se observa desde el navegador Netscape el video transmitido por 
camserv de un kit de un robot manipulador desde una WebCam. 
:;;;; Netscape: 
Fiie Edlt Vlew Go Communlcator 
rn if. .;¡. '3 · .. · , ili · ,t~ ~ 
j Back Fo rward Reload . ;, Ho~e ·, Search Netscape 
ill ~ ... Bookmarks ~ Location: ~t~: //192.1.1. 7/p~eba. hbnl 
Figura 2-1 O. Ejemplo de transmisión de streaming video con camserv. 
Un problema de utilizar un servidor de streaming video como camserv es que el 
monitoreo de las acciones de los robots estaría separado de la aplicación a desarrollar, entonces 
no se tendría la posibilidad de realizar procesamiento de imágenes o integrar un módulo de visión 
a la aplicación; además, debido a que camserv transmite video a través del esquema cliente-
servidor rompería con el esquema distribuido que se utilizará en la aplicación a desarrollar en este 
trabajo. 
2.4.3.3 JMF. 
Las librerías de programación llamadas Ambiente de Trabajo de Multimedios en Java o 
32 
JMF (Java Media Framework) son una Interfaz de Programación de Aplicaciones o API 
(Application Programming Interface). Las librerías de programación de JMF sirven para definir 
ambientes que incluyen: el despliegue, la captura, la conferencia y la transferencia de streaming 
media, para ser incorporados en applets y aplicaciones standalone desarrolladas en Java. La 
última versión de JMF (2.1.1) es multiplataforma y portable al igual que Java [ 12] [ 16]. 
JMF soporta múltiples formatos de archivos de multimedios como lo son el video digital, 
MIDI, algoritmos tradicionales de compresión de audio y video (streaming audio y streaming 
video), etc. Los formatos de archivos que soporta son: AIFF, A VI, Flash, GSM, HotMedia, 
MIDI, MPEG-1 Video, MP2, MP3, QuickTime, Sun Audio, Wave; además de soportar varios 
dispositivos comunes de captura de audio y video mediante clases de Java en JMF, en una 
aplicación llamada jmfinit, para buscar dichos dispositivos y registrarlos en un archivo 
Umf properties) junto con las características de captura del mismo. 
En la aplicación de este trabajo, para el desarrollo del monitoreo por medio de video de 
los robots reales teleoperados, se utilizará JMF debido a que sus librerías están hechas en Java y 
no tienen costo. En la figura 2-11 se muestra un demo que incluye el JMF 2.1.1, llamado 
JMStudio, el cual es una aplicación para abrir archivos de video, capturar, desplegar y transmitir 
video en tiempo real. 
Fig~ra 2-11. JMStudio de JMF 2.1.1 capturando video de una WebCam. 
33 
3 AMBIENTES VIRTUALES EN RED. 
Con la evolución de las gráficas por computadora y la invención de la realidad virtual se 
definieron los conceptos de ambientes virtuales como simulaciones gráficas avanzadas que 
involucraban varias tecnologías. Posteriormente, con los avances en telecomunicaciones, el 
concepto se extendió al de ambientes virtuales en red. Actualmente, estos ambientes virtuales en 
red se han vuelto arquitecturas que definen estándares que se implementan para realizar sistemas 
colaborativos de teleoperación de robots en red. 
Este trabajo se basó en una arquitectura de ambientes virtuales en red para implementar el 
sistema de teleoperación de robots. Se explican a continuación los antecedentes y las 
definiciones de la realidad virtual y los ambientes virtuales en red que son útiles para el 
entendimiento de los próximos capítulos. 
3.1 REALIDAD VIRTUAL. 
Grigore Burdea, de la Universidad Estatal de New Jersey en Estados Unidos, define a la 
Realidad Virtual o VR (Virtual Reality) de la siguiente manera: "La Realidad Virtual es una 
interfaz de usuario de alto nivel que involucra simulación e interacciones en tiempo real a través 
de múltiples canales sensoriales. Estas modalidades sensoriales son visual, auditiva, táctil, 
34 
olfativa y gustativa" [9]. 
La VR es una simulación en la cual las gráficas por computadora son utilizadas para crear 
un mundo sintético que se vea realista, y que sea interactivo, es decir que no sea estático y 
responda a entradas o comandos del usuario en tiempo real o de manera inmediata [9]. La 
interactividad contribuye al sentimiento de inmersión del usuario de ser parte de la acción en la 
pantalla. La interacción, la inmersión y la imaginación son las características fundamentales de 
la VR. El usuario puede ver y manipular los objetos gráficos en la pantalla, pero también puede 
tocarlos o sentirlos por medio de dispositivos que se consideran herramientas en la VR. 
Las posibles herramientas a utilizar en VR son: sensores de posición tridimensional o 30, 
que pueden ser magnéticos, ultrasónicos, etc.; guantes de sensado, que pueden ser ópticos, 
mecánicos, eléctricos, etc.; dispositivos de visión estéreo, que pueden ser dispositivos de 
despliegue montados en la cabeza o HMD (Head Mounted Displays), lentes estéreo, pantallas de 
proyección estéreo, etc.; generadores de sonido, etc [9]. Sin embargo, actualmente la VR puede 
ser realizada sin necesidad de tener un HMD, es decir, se puede utilizar la pantalla de una 
estación de trabajo gráfica, o incluso la pantalla de cualquier Computadora Personal o PC 
(Personal Computer) que tenga un procesador suficientemente rápido y una buena tarjeta de 
video; de la misma manera, los guantes de sensado pueden ser reemplazados por dispositivos más 
simples como un joystick, o incluso el uso del dispositivo apuntador o mouse en una GUI. 
3.2 AMBIENTES VIRTUALES. 
Los Ambientes Reales o RE's (Real Environments) son las representaciones de un mundo 
o región de la vida cotidiana, de los cuales no se tiene un modelo geométrico computacional pero 
se puede capturar dentro de la computadora. Los RE's abarcan los datos reales, en 20 o 30, de 
cualquier captura de imagen fotográfica, imagen infrarroja, video, radar, rayos-X, ultrasonido, 
escaneo láser, etc. En cambio, los Ambientes Virtuales o VE's (Virtual Environments) son 
necesariamente la representación del modelado geométrico computacional del ambiente real, al 
cual se le aplica el rendering (proceso de las gráficas por computadora en el cual se aplican un 
35 
conjunto de operaciones para proyectar una vista de un objeto o una escena 3D sobre una 
superficie bidimensional o 2D). Los RE's y los VE's existen como entidades separadas [17]. El 
dominio de la Realidad Virtual se encuentra cerca de los VE's. Algunos autores también le 
llaman mundos reales a los ambientes reales, y mundos virtuales a los ambientes virtuales. 
En 1993 otra definición más específica de un VE fue hecha por Roy S. Kalawsky, de la 
Universidad de Loughborough en Inglaterra, en la cual lo define como "experiencias sensoriales 
sintéticas que comunican componentes fisicos y abstractos a un operador o participante. La 
experiencia sensorial sintética es generada por un sistema computacional que presenta 
interfaces más avanzadas y que en un futuro será indistinguible del mundo fisico real" [18]. 
Kalawsky incorpora el participante como parte importante del VE. 
Hasta mediados de la década de los 80's la mayoría de los VE's eran sistemas para un 
simple usuario, que al no ser aplicaciones en red entonces no soportaban colaboración entre un 
grupo de usuarios; por lo tanto, para tener VE's en sistemas gráficos avanzados y colaborativos se 
desarrollaron VE's basados en red [18]. 
3.2.1 AMBIENTES VIRTUALES PARA ROBÓTICA. 
En la robótica, el desarrollo de sistemas de simulación gráficos o ambientes virtuales se 
aplicó primero en celdas de manufactura para reducir el tiempo que se tarda la programación de 
robots fuera de línea [9]. También las herramientas de realidad virtual y el desarrollo de 
ambientes virtuales fueron utilizados para la teleoperación de robots cuando maduró la 
tecnología. 
A finales de la década de los 80's e inicio de los 90's, Sumumu Tachi, de la Universidad 
de Tokio en Japón, realizó la primera aplicación de los ambientes virtuales en teleoperación de 
robots. Paraesto, definió el nuevo concepto de telepresencia o teleexistencia que es la 
proyección de un usuario a un lugar distante por utilizar un robot remoto, computadoras e 
interfaces hombre-máquina [ 17]. La teleexistencia fue un concepto que ejemplificaba la 
aplicación actual de la realidad virtual en la teleoperación de robots. 
36 
El proyecto de teleexistencia de Tachi, (ver figura 3-1 ), incluía a un dispositivo mecánico 
esclavo que ajustaba con las articulaciones del operador, con el cual el operador teleoperaba a un 
brazo de robot llamado Telesar (Teleexistence Surrogate Anthropomorphic Robot). Mediante el 
movimiento del HMD en su cabeza controlaba la orientación del sistema de cámaras estéreo que 
tenía el robot y veía en el mismo HMD lo que observaban las cámaras [8]. Después incluyó en el 
concepto de teleexistencia la proyección en un ambiente virtual generado por computadora [17]. 
Al sistema de Tachi se le incluyó una simulación gráfica del robot Telesar para hacer más fácil la 
teleoperación. 
Figura 3-1. Telepresencia. De izquierda a derecha y de arriba hacia abajo: operador 
utilizando el dispositivo esclavo y el HMD, el robot Telesar con sistema de 
cámaras estéreo, y el VE con el robot virtual. 
En los últimos años se han desarrollado otros proyectos de teleoperación de robots por 
internet en los cuales se controla el robot real al mover el robot virtual dentro del ambiente virtual 
mostrado en una página web. 
37 
3.3 AMBIENTES VIRTUALES EN RED. 
Un Ambiente Virtual en Red o net-VE (Networked Virtual Environment) es un sistema 
que permite a múltiples usuarios interactuar en tiempo real, no importando que varios usuarios 
estén localizados en distintas partes del mundo [ 19]. Comúnmente, cada usuario accesa su propia 
computadora, utilizando una interfaz de usuario con el contenido del ambiente virtual. Estos 
ambientes proveen a los usuarios de un sentido de realismo por incorporar gráficas realistas 3D y 
sonido estereo, para crear una experiencia inmersiva. 
Para 1995, N. I. Durlach y A. S. Mavor, del MIT (Massachussets Institute ofTechnology) 
en Estados Unidos, definieron a los net-VE's como sistemas que penniten a múltiples usuarios 
geográficamente distantes interactuar en un ambiente virtual común [ 18]. 
Los net-VE's son cada vez más utilizados para entrenamiento de equipos militares e 
industriales, diseño colaborativo, ingeniería, y en juegos multiusuarios [19]. La investigación y 
desarrollo de net-VE's está aumentando en las universidades. En un futuro, los net-VE's podrían 
estar en aplicaciones comerciales incluyendo compra virtual en tiendas, conferencias en linea, 
soporte personalizado remoto, y aprendizaje a distancia. 
Los net-VE's incluyen la integración de varias áreas como lo son: el diseño e 
implementación de protocolos de red, los sistemas paralelos y distribuidos, las gráficas por 
computadora, los sistemas multihilos o multithreading ( ejecución de varios procesos, llamados 
hilos o threads, al mismo tiempo), el desarrollo de bases de datos, y el diseño de GUI's [19]. Sin 
embargo, los net-VE's tienen aún problemas para mantener consistente la información 
distribuida, para garantizar la interactividad en tiempo real, y para competir los recursos de ancho 
de banda de red, de procesamiento y de rendering. Un net-VE se distingue por las siguientes 5 
características: 
l. Un Sentido Compartido de Espacio. Todos los participantes tienen la sensación de estar 
localizados en el mismo lugar, por ejemplo en el mismo cuarto, construcción, ó terreno. 
Aquel lugar compartido representa una localidad común dentro de la cual pueden llevarse 
acabo otras interacciones. El lugar puede ser un modelo de algo real ó ficticio. El 
38 
espacio compartido debe presentar las mismas características a todos los participantes. 
2. Un Sentido Compartido de Presencia. Cuando se entra al espacio compartido, cada 
participante puede ser identificado por una representación gráfica de él mismo en el 
ambiente virtual (llamado avatar), que puede tener forma humana o no. 
3. Un Sentido Compartido de Tiempo. Los participantes deben poder ver el comportamiento 
de otros participantes en el momento en que está ocurriendo. 
4. Una Forma de Comunicarse. Debe existir un medio de comunicación entre los 
participantes, sea hablado, escrito o por gestos de su avatar. 
5. Una Forma de Compartir. La verdadera importancia de los net-VE's radica en la 
habilidad de los usuarios de interactuar con el ambiente virtual y con otros participantes. 
3.4 ARQUITECTURAS DE NET-VE'S. 
En su origen el desarrollo de la VR distribuida en net-VE's fue fuertemente impulsado por 
la industria militar, principalmente para la elaboración de simuladores utilizados en 
entrenamientos de combate. La industria militar ha destinado muchos recursos para desarrollar 
software de calidad que permita entre otras cosas la reutilización, compatibilidad y portabilidad 
de componentes. 
Para este trabajo se utilizó una arquitectura orientada a objetos reciente para realizar VR 
distribuida en net-VE's, llamada OODVR, la cual fue diseñada en base a dos arquitecturas, 
llamadas DIS y HLA, que a pesar de que fueron creadas hace varios años siguen utilizándose y 
estando vigentes en cuanto a actualizaciones, además de que son las dos arquitecturas bases para 
otras de las últimas arquitecturas. A continuación se describirán estas tres arquitecturas junto con 
otras dos arquitecturas: la prime_r arquitectura de net-VE's, llamada SIMNET, y otra arquitectura 
más reciente, llamada NPSNET que en su última versión tiene capacidades similares a muchas 
otras arquitecturas existentes actualmente, las cuales ya no se mencionan debido a que no 
muestran mejores características que ésta. 
39 
3.4.1 SIMNET. 
En I 983, el Departamento de Defensa o DoD (Department of Defense) de los Estados 
Unidos inició el desarrollo del primer net-VE llamado SIMNET que se terminó en I 990, este 
sistema fue un ambiente virtual distribuido de propósitos militares para el entrenamiento de 
pequeñas unidades del ejercito como lo son tanques, helicópteros y puestos de comando [ 19]. 
La arquitectura SIMNET fue implementada sólo en estaciones de trabajo y definía los 
siguientes tres componentes básicos: 
I. Una arquitectura objeto-evento. Modelan el mundo como una colección de objetos cuyas 
interacciones con otros objetos son una serie de eventos. Los objetos son los vehículos y 
armas que interactúan en la red; es decir, no son objetos de programación orientada a 
objetos, sino simples elementos en el VE. Los eventos son los mensajes enviados en la 
red indicando el cambio en el estado del objeto o del mundo. Por ejemplo un solo objeto 
es un tanque manejado por una sola computadora y un evento es el mensaje transmitido 
de que el tanque giró a la derecha. 
2. Una noción de nodos de simulación autónomos. Significa que cada nodo (participante en 
una computadora) es responsable de: uno o más objetos en el VE, de colocar paquetes en 
la red representando el estado actual (mensaje cada cinco segundos para avisar a los otros 
participantes si un objeto en particular sigue en el sistema) y los cambios de estado 
(movimientos) de su o sus objetos, y de recibir los paquetes de otros participantes con los 
estados de sus objetos para actualizar su copia de los objetos (llamados fantasmas) en su 
VE. Esto quiere decir que existía un procesamiento distribuido de las tareas en la 
simulación compartida, teniendo una arquitectura distribuida y no un esquema cliente-
servidor ya que no hacía falta la necesidad de un servidor central debido a que se repartía 
el trabajo en todos los nodos. 
3. Un conjunto de algoritmos de predicción y convergencia llamados dead reckoning. Estos 
algoritmos son para reducir el tráfico de paquetes en la red, es decir que no se van a 
enviar paquetes de red en todo momento por cada objeto sino que solo se enviarán si ha 
cambiadosu estado. Un algoritmo de predicción pennite predecir el movimiento de las 
copias fantasmas de los objetos de un nodo dependiendo de los últimos datos reportados 
del estado del objeto original en cuanto a dirección, velocidad y posición, enviando a la 
red un paquete con el cambio de estado del objeto cada cierto grado de umbral o tiempo 
40 
definido. Si llega tarde el paquete o sucede un movimiento de un objeto entre un paquete 
y otro, entonces se tendrá que utilizar un algoritmo de convergencia para que a partir de la 
última dirección y velocidad del objeto original, se modifique la dirección y velocidad del 
objeto fantasma y así vaya en la misma posición al mismo tiempo que el original. 
Los mensajes o eventos enviados por la red por cada objeto o elemento en SIMNET eran 
muy grandes. Esos mensajes incluían tanto datos estáticos ( datos que nunca cambiaban) como 
dinámicos ( datos que cambiaban a cada segundo), los datos del mensaje eran: identificación del 
vehículo por nombre y de la computadora que lo controla, tipo del vehículo, apariencia del 
objeto, localización en el VE, matriz de transfonnación para sus movimientos, capacidades del 
objeto, velocidad normal, vector de velocidad del vehículo y orientación de sus annas, además de 
otros valores que servían como control de tiempo y de características específicas del objeto. Para 
enviar esos mensajes la implementación de SIMNET primero utilizó el protocolo de red llamado 
UDP y al final cambió por el protocolo Multicast, protocolos que serán explicados 
posteriormente en otro capítulo. 
3.4.2 DIS. 
La arquitectura de Simulación Interactiva Distribuida o DIS (Distributed Interactive 
Simulation) es una generalización y extensión de SIMNET, también desarrollada por el DoD en 
1993, con un nuevo protocolo que se convirtió en el estándar 1278 de la IEEE [19]. 
La arquitectura de DIS incluye los nusmos tres componentes básicos de SIMNET 
mencionados en el punto anterior 3.4.1, es decir: una arquitectura objeto-evento (no es lo mismo 
que orientada a objetos), una noción de nodos de simulación autónomos, y un conjunto de 
algoritmos de predicción y convergencia. Pero, la arquitectura de DIS tiene diferencias con 
respecto a SIMNET y afl.ade nuevas características, todas ellas se describen a continuación: 
1. DIS trata como entidades el concepto de objetos que utiliza SIMNET. 
2. DIS tiene soporte para varios tipos de vehículos terrestres y acuáticos, y no sólo para los 
pocos vehículos definidos que soportaba SIMNET. 
3. DIS puede ser ejecutado en más plataformas de cómputo que SIMNET, es decir, DIS 
soporta distintas estaciones de trabajo y PC's. 
41 
4. DIS pennite dentro del VE a tres distintos tipos de participantes: 
• Un participante puede ser controlado por un usuario. 
• El participante puede ser controlado por una computadora. 
• Un sistema de armamento puede controlar al participante. 
5. En DIS se transmiten otro tipo de mensajes por red llamados Unidades de Protocolo de 
Datos o PDU's (Protocol Data Unit), los cuales son 27 diferentes y constituyen el estándar 
de la IEEE. Los 4 principales PDU's para interactuar con el ambiente virtual son: el del 
estado de la entidad, el de disparo, el de detonación y el de colisión. El PDU más 
utilizado es el del estado de la entidad y contiene: la versión del protocolo, el número de 
identificación del ejercicio de simulación, el tipo de PDU, la familia del protocolo, el 
tiempo, la identificación de la entidad por aplicación y computadora, el tipo de entidad, la 
velocidad lineal, la localización, la orientación, los parámetros de dead reckoning, las 
capacidades de esa entidad y otros parámetros de control. Existe un recipiente en cada 
nodo de DIS que recibe el PDU, lo procesa y actualiza lo necesario para que se despliegue 
el cambio. 
6. A diferencia de SIMNET, DIS utiliza otro tipo de algoritmos de predicción y 
convergencia que manejan nuevos parámetros definidos en el PDU, por ejemplo la 
aceleración lineal, la velocidad angular, etc. 
Con la tercera y cuarta diferencia se pueden tener en DIS simulaciones a mayor escala con 
más participantes en una mayor variedad de computadoras. La arquitectura de DIS sigue 
enfocada para aplicaciones militares al igual que en SIMNET, esto se observa en los PDU's 
mencionados en la quinta diferencia los cuales son muy orientados a acciones de vehículos de 
guerra. 
El formato del paquete de un PDU no solo es un estándar de la IEEE sino que es un 
estándar para muchas otras arquitecturas que se basaron en los paquetes de DIS. Existe un 
problema con DIS, al igual que sucedía en SIMNET: aunque existen mecanismos en DIS para 
enviar PDU's solo cuando es necesario, sus mensajes enviados por red son más grandes que en 
SIMNET y siguen teniendo información estática que no se utiliza y debería ser enviada sólo una 
vez. Las primeras implementaciones de DIS enviaban sus PDU's utilizando el protocolo de red 
llamado IP Broadcasting y posteriormente se implementó utilizando el protocolo Multicast 
42 
(protocolos que se explicarán en un capítulo posterior). 
El DoD ocultó muchos detalles de la implementación de DIS, por lo tanto los 
investigadores subsecuentes en el área tuvieron que reinventar varias cosas en sus arquitecturas 
basadas en DIS. En 1997, la Escuela de Posgrado Naval o NPS (Naval Postgraduate School) 
desarrolló DIS-Java-VRML que es un net-VE para web basado en el estándar de DIS. 
En DIS-Java-VRML se realiza el despliegue gráfico utilizando el Lenguaje de Modelado 
de Realidad Virtual o VRML (Virtual Reality Modeling Language) versión 2.0 del consorcio 
llamado Web3D, y se hace el envío y recepción de PDU's por la red a través de threads en Java. 
Actualmente, el consorcio Web3D se hace cargo de distribuir gratuitamente y actualizar DIS-
Java-VRML. En la figura 3-2 se observa un ejemplo de esta implementación de DIS con un 
helicóptero del ejército volando sobre un terreno. 
Figura 3-2. Ejemplo de un helicóptero en un VE en DIS-Java-VRML. 
3.4.3 HLA. 
La Arquitectura de Alto Nivel o HLA (High Level Architecture) fue definida en 1996 por 
la Oficina de Simulación y Modelado de la Defensa del DoD y tenninada en 1999 para sustituir 
el uso de DIS y realizar simulaciones con mayor interoperabilidad y reutilización de sus partes 
[19]. Al igual que en DIS, con HLA también se definió un estándar de la IEEE en el año 2000, el 
estándar número 1516. 
HLA comparte muchas características de DIS y a su vez de SIMNET. En HLA al igual 
43 
que en SIMNET se menciona el concepto de objetos y no entidades como en DIS; sin embargo, 
la arquitectura HLA sigue siendo una arquitectura no orientada a objetos. Las diferencias entre 
HLA y DIS son las siguientes: 
1. HLA separa las funciones de simulación y las de comunicación, debido a que la mayor 
carga del desarrollo de una simulación distribuida se centra en aspectos de comunicación, 
en vez de en comportamientos específicos de la simulación. 
2. HLA permite incorporar nuevos objetos de .interacción dinámicamente sin la necesidad de 
una reconstrucción completa del sistema como sucedía en DIS. 
3. HLA llama federaciones a los participantes de DIS. Cada federación representa a un 
conjunto de objetos, cada objeto teniendo un conjunto de atributos y la capacidad de 
iniciar y recibir eventos. 
4. En HLA se realizó una implementación del protocolo de Infraestructura en Tiempo Real 
o RTI (Real-Time Infraestructure); en ella las federaciones registran sus objetos, y envían 
y reciben infonnación de los estados de los objetos remotos en otras computadoras. 
En general, HLA utiliza a RTI para administrar lo siguiente: las federaciones, los objetos, 
las declaraciones o filtros que cambian atributos de objetos o eventos particulares, el tiempo de 
sincronización común a todas las federaciones, la toma de control sobre un objeto local o remoto, 
y la distribución de los datos. Para el caso de la implementaciónde RTI en HLA, las 
federaciones pueden programarse en los lenguajes de programación C++, Java o Ada. 
3.4.4 NPSNET. 
La arquitectura de Red de NPS o NPSNET (NPS Network) es desarrollada por un grupo 
de investigación dedicado a la creación de ambientes virtuales a gran escala desde finales de la 
década de los 80's [19]. Ellos desarrollaron varias generaciones de software y la posibilidad de 
integrar cada vez un mayor número de usuarios en una simulación. Las primeras dos 
aplicaciones desarrolladas eran para que un usuario tuviera el control de un misil e intentara 
destruir un tanque o un vehículo móvil. Para la conexión de estas dos aplicaciones se utilizó un 
simple intercambio de infonnación por paquetes de red a bajo nivel. Conforme fueron 
integrando estas distintas aplicaciones que habían desarrollado, realiz.aron las primeras tres 
versiones de la arquitectura llamadas NPSNET-1, NPSNET-2 y NPSNET-3. 
44 
Para 1993 se terminó la siguiente versión llamada NPSNET-IV (ver una escena de batalla 
en la figura 3-3), cuyas características nuevas con respecto a sus anteriores versiones fueron las 
siguientes [ 18] [ 19]: 
l. La implementación de NPSNET-IV fue en C++ y las librerías gráficas utilizadas para 
desarrollar el VÉ fueron la API llamada Performer de la compañía SGI, por lo tanto sólo 
podía ejecutarse en estaciones de trabajo de esa empresa. 
2. Añadieron sonido. 
3. Le llaman componentes a los objetos en la simulación. 
4. Incluyeron mejores algoritmos de dead reckoning. 
5. Se podían tener simulaciones en el aire, tierra y mar, teniendo la opción de añadir 
humanos articulados además de incrementar la lista de vehículos utilizados en cada tipo 
de simulación. 
Figura 3-3. Ejemplo de VE de NPSNET-IV. 
En la versión actual NPSNET-V, terminada en el 2001, incluyeron las siguientes 
características [20]: 
1. Tienen cargado dinámico de componentes en cualquier momento de la simulación. 
2. Incluyen modificación dinámica de los comportamientos de los componentes y de los 
protocolos. 
45 
3. Cambiaron la implementación a Java y las librerías gráficas a Java3D, teniendo así la 
posibilidad de ejecutar la aplicación en múltiples plataformas. 
En futuras versiones quieren hacer pruebas para poder tener distintos despliegues gráficos 
además del que ya tienen en Java3D, por ejemplo quieren ver la integración de un despliegue con 
las librerías gráficas X3D del nuevo estándar del consorcio Web3D para VRML. 
3.4.5 OODVR. 
La arquitectura Orientada a Objetos para Realidad Virtual Distribuida u OODVR (Object 
Oriented Distributed Virtual Reality) es una arquitectura de net-VE's que fue definida en el año 
1998 e implementada en su primera versión de prueba para el 2000 por Diego Malpica Chauvet 
del ITESM-CEM dentro del proyecto llamado "Laboratorios Virtuales" apoyado por REDII-
CONACYT (Red de Desarrollo e Investigación en Informática - Consejo Nacional de Ciencia y 
Tecnología). Debido a que este trabajo pertenece al mismo proyecto de "Laboratorios Virtuales" 
apoyado por REDII-CONACYT, se decidió tomar la arquitectura OODVR para realizar la 
aplicación de teleoperación de robots en VE's [21]. También el trabajo de Lourdes Muñoz 
Gómez, llamado "Laboratorios Virtuales Asistidos", pertenecía al mismo proyecto de REDII-
CONACYT y fue desarrollado en paralelo y en colaboración a este trabajo utilizando OODVR. 
La arquitectura OODVR se basó originalmente en algunas características de DIS y HLA, 
pero también incluyó nuevas características, todas ellas están descritas a continuación: 
l. Se les llama entidades a todos los objetos que se encuentran dentro del VE, de la misma 
manera que en DIS. Existen dos tipos de entidades que se explican más adelante. 
2. Se utiliza el término de participante al igual que en DIS, pero no sólo es considerado 
como un usuario que se une a la simulación en red en determinado momento y que va a 
aportar ciertos objetos virtuales, sino que en OODVR un participante es una instancia de 
ejecución del VE donde cabe la posibilidad de que un usuario la ejecute más de una vez 
en una computadora, es decir que pueden existir varios participantes en el net-VE por 
cada usuario. 
3. Un participante de OODVR puede contribuir con distintas entidades locales y entidades 
símiles o proxies al VE [21]. Las entidades locales son aquellas que fueron registradas y 
46 
ejecutadas por un participante en el net-VE y sirven para controlar el despliegue y los 
cambios de estado de los proxies, sin embargo dichas entidades locales no se despliegan. 
Los proxies son la representación de una entidad local en el mismo participante, otro 
participante u otra computadora, teniendo las mismas características de ejecución que la 
entidad local, pero estas entidades símiles son las que se despliegan. 
4. En OODVR la simulación puede tener muchas entidades con las que interactúen distintos 
participantes. Incluso, puede haber un participante en el net-VE que no haya registrado 
ninguna entidad en la simulación, y aún así podrá observar e interactuar con todo lo que 
haya en el VE. 
5. Si el número de participantes crece, la comunicación entre las entidades locales y sus 
proxies puede ser más eficiente en OODVR definiendo regiones de la simulación 
colocando algunos participantes como repetidores de red de dichas regiones. 
6. Al igual que DIS, OODVR maneja la noción de nodos de simulación autónomos. 
7. OODVR es multiplataforma y portable debido a que su implementación fue realizada en 
Java. 
8. La nueva característica y la más importante de OODVR es la de ser una arquitectura 
orientada a objetos. No como HLA que fue implementada en un lenguaje de 
programación orientado a objetos, pero no es una arquitectura orientada a objetos. Una 
arquitectura de net-VE's es orientada a objetos si la transmisión en red utiliza objetos para 
todo lo referente a la actualización de la simulación; es decir, el protocolo de envío de 
paquetes en red de OODVR es más sencillo que en DIS y HLA, ya que no se envían 
paquetes de red a un bajo nivel con una lista de datos, sino que desde objetos locales 
(objetos de orientación a objetos) se envían a ejecutar remotamente a través de la red 
funciones de objetos remotos mediante la arquitectura distribuida de Java llamada 
Invocación de Método Remoto o RMI (Remote Method lnvocation). 
Los RMI's son una API de Java para el desarrollo de aplicaciones distribuidas mediante la 
comunicación entre objetos que se localizan en distintos lugares remotos [22]. RMI realiza la 
invocación de un método en un objeto remoto. Un objeto remoto, el cual puede encontrarse en la 
misma computadora o en otra distinta, permite ejecutar sus métodos remotos desde un objeto 
local a través de una interfaz remota; así, un participante puede instanciar un objeto local y 
ejecutar sus métodos remotos, que se ejecutarán a su vez en el objeto remoto tal y como si 
estuviera interactuando con el objeto remoto. Lo anterior se consigue de manera transparente, sin 
47 
que sea necesario la implementación detallada de los mecanismos de transmisión de paquetes de 
bajo nivel a través de una red 
En la figura 3-4 se muestra el esquema de comunicación en red de OODVR en un 
ejemplo que tiene dos regiones con tres participantes. En ese esquema el participante A tiene una 
entidad local Al que controla a sus proxies Al en el mismo participante y en el participante B; y 
la entidad Al en el participante C es el símil de la entidad Al del participante B (se maneja el 
concepto de proxy del proxy). Análogamente el participante C tiene una entidad local Cl que 
controla a los proxies en el mismo participante y en el participante B; y la entidad Cl en A es el 
proxy del proxy de C 1 en C. En estos dos casos el B funciona como repetidor entre la región que 
incluye a B y A, y la región que incluye a B y C. El caso de las entidades de B es distinto debido 
a que su entidad local B 1 si controla a sus tres