Virtual Laboratory

Isaac Rudomin, Lourdes Muñoz, and Moises Alencastre

Department of Computer Science

ITESM-CEM, Carretera Lago de Guadalupe Km. 3.5,
Atizapán de Zaragoza, Estado de México, C.P. 52926
México
rudomin@campus.cem.itesm.mx
http://cic087.cem.itesm.mx/ rudomin/

Abstract. A networked virtual laboratory consisting of a virtual man-

ufacturing cell is developed using a general object oriented architecture
for distributed virtual reality (OODVR) developed for this purpose.

1 Introduction
A distributed simulation, within the context of virtual laboratories is an impor-
tant part of networked virtual environment that allows the user to interact with
a graphical representation of the laboratory, in such a manner that all process-
ing occurrs in a distributed fashion within all the computers participating in the
networked graphics simulation, rather than using a client-server model for the
simulation.
A networked virtual environment is a software system where multiple users
interact in realtime, wherever these users may be, including geographically dif-
ferent places [1]. Typically, each user has access to a computer that provides a
graphical interface for the virtual world. These environments give the user the
appearance of realism by using 3D graphics and sounds among other things. A
virtual environment has the following characteristics:
1. A sense of shared space: all users have the illusion of being in the same
space, whether a closed environment such as a room or an open environment
such as a field, and all participants have the same approximate conditions
for interaction.
2. A shared sense of presence: every user inside the environment must be repre-
sented within the simulation by some entity, which may or not be an avatar.
3. A sense of shared time: every user must be capable of observing the actions
of other users in the environment when they are happening.
4. A comunication mechanism: beyond visualization of the environment, it is
helpful that users can comunicate using voice or text.
5. A sharing mechanism: users can share information or manipulate every ob-
ject in the simulation
To implement all the necessary characteristics that make such a system a
virtual environment, several sub-systems must be integrated into a single apli-
cation:
1. Distributed systems that must contain all the necesary resources for com-
munications of the networked application, so that data loss is avoided and
concurrency and synchronization happens.
2. Graphical systems that are realistic enough to sustain the illusion of inmer-
sion yet simple enough to preserve realtime interaction
3. Interactive systems that must process input data in realtime so that each user
percieves his environment as existing locally, that is, every user must have a
direct and immediate impact so that the illusion of inmersion is preserved.
Also, he must percieve the actions of other users as if they were local.

One important issue is visual consistency for all users accessing the same virtual
environment. This must be mantained by sending enough information through
the network to insure consistency yet limited enough that the interaction speed
is mantained. Convergence and prediction algorithms are used for this effect.
Prediction allows us to calculate locally from the present state of elements
within the simulation, by sending only periodic updates (usually position and
speed at a given time). One must remember, however, that predictions are esti-
mates, and may destroy consistency. When this happens, convergence algorithms
are used to restore in a smooth fashion this consistency.

2 Distributed virtual environment architectures

We briefly describe architectures that have been previously developed for dis-
tributed virtual environments.

1. Simulator Networking (SIMNET): This was a distributed environment sim-

ulator developed for military purposes by DARPA in 1983 [8]. It had a
propietary protocol and was used for training of small units like tanks and
helicopters.
2. Distributed Interactive Simulation (DIS): As a generalization of the SIM-
NET protocol, DIS was developed by DARPA in 1993 and became standard
(IEEE 1278) [7],[9]. The purpose of DIS was to allow participants in the
virtual world to be of any kind and use any equipment, thereby allowing
large-scale simulations. DIS has 3 basic components: An object architec-
ture (not object oriented in the modern sense), the notion of distributed
autonomous simulation nodes, and very importantly, prediction and conver-
gence algorithms such as dead-reckonning[2].
3. High Level Architecture (HLA): Was developed by DoD in 1996 to allow the
development of simulations with increased interoperability and reuse[10].
The central aspect of this architecture is the separation of simulation and
communication functions. This because for the most part, the development
of distributed simulation is slowed down by programming the communica-
tion functions, yet they are very similar from simulation to simulation, rather
than the simulation-specific behaviours. This allows the incorporation of new
interaction objects without rebuilding the entire system. HLA uses a model
 of ’federations’, where a federation is an element that can select an interac-
tion protocol for the appropiate object. Federations subscribe to whatever
interests them in the simulation [3].
4. Web Inteface for Telescience (WITS): It is a collaboration architecture de-
veloped to allow different scientists to collaborate in planetary missions from
institutions localized in different countries.WITS was used by Sojourner in
the Mars Pathfinder mission in 1997. There is a WITS server at the Jet
Propulsion Laboratory (JPL) with the basic system including the mission
scenario, which is sent to WITS clients using TCP/IP sockets and Java RMIs.
Its environment, implemented in Java3D was generated from multiple ter-
rain images taken arround the robot at a specific radius. Each scientist can
observe and execute simulated work sequences for the robot, either created
by him or any other scientist. Later, these tasks are sent to the real robot[4].

3 Proposed model

We propose the use of an object oriented architecture for distributed virtual

reality (OODVR) as a model for the implementation of virtual laboratories un-
derstood as distributed simulation (including teleoperation) with multiple simul-
taneous participants.
OODVR was designed and implemented having as an objective a distributed
environment for simulations, where the complete simulation is integrated by
diferent elements. Since a robust simulation that can easily integrate various
elements is desired, consisting of reusable, compatible and portable, platform
independent components. Java, Java 3D, RNI and Java beans were used.
This architecture assumes the participation of several computers in a com-
plete simulation, each called “participant”, that can contribute one or more
“entities” or modules to the simulation. The entities belonging to a given par-
ticipant are called “local” if executing locally, and “proxies” in other cases. See
figure 1.
Proxies are the representation of a local entity on other machines, and they
have their own characteristics and access methods running in the client machine.
A local entity synchronizes and coordinates its proxies using prediction and
convergence algorithms.
A simulation can have as many entities or modules as desired, all interacting
regardless of which participant contributed these modules. This allows certain
participants to join a simulation even if they don’t contribute any modules. If the
number of participants grows to much, the comunication between local entities
and their proxies can be made more agile by defining regions in the simulation,
and defining some participants as repeaters, comunicating the regions.
Another alternative for defining regions is the use or multicast when available.
Multicast is similar to UDP, except that instead of sending a packet to single
destination, the packet is sent to a multicast group. The multicast network pro-
tocols attempt to transport the packet to all interested recipients and the sender
Fig. 1. Participants, entities, regions
does not even need to know who the recipients are. A multicast group[5], is sim-
ply an IP address that falls between 224.0.0.0 and 239.255.255.255. Recipients
express an interest in receiving packets addressed to a particular multicast group.
It is usually preferable to use multicast instead of broadcast, because multicast
gives the choice of multiple groups, whereas any given network only has a single
broadcast address[6].
The idea of using multicast and implementing the concepts of local entities
and proxies, is to provide a really modular and distributed architecture in order
to create custom simulations without changing the code and to add any number
of participants to the simulation without knowing the IP numbers of every single
machine. The use of multicast also provides the possibility that the same user can
run several different simulations in the same machine using different multicast
groups.
To summarize:

1. Participants
– Interact with their local entities to update their proxies.
– Iteract with the proxies to update de simulation views.
– Publish the simulation
– Define and listen to port (multicast mode)
– Listen to the port to update simulation registry
– Create proxies of local entities in the different registered simulations
2. Proxy entities
– Contain the geometry
– Contain the behaviours activated by the local entity.
– Contain a copy of the state information contained in the local entity
– Contain a reference to the local entity of which they are proxies
3. Local enitities
– Contain state information
– Contain a list of references to their proxies
– Activate behaviours in their proxies
– Update state information in their proxies,
– Contain the interfaces that allow interaction with other entities or pro-
cesses.

The next table compares the different architectures:

4 Applications

Using OODVR as implemented at the end of 2000 (using RMI’s and simulation
using Java3D) a Virtual Robotics Lab consisting of a manufacturing cell with 4
robot arms and several static elements was implemented. In order to integrate
all the elements of the simulated cell, as well as future expandability, a general
methodology was followed.
The development of the simulation required:
Architecture SIMNET DIS HLA WITS OODVR
Distributed Y Y Y N(client/server) Y
Portable N Y Y Y Y
General purpose N N Y N Y
Multicast N Y (from 1997) Y N Y
Prediction & Convergence Y Y Y N Y
Autonomous nodes Y Y Y N Y
Open source N Y since 1997 N N Y
Modular N N N N Y
Regions N N Y N Y
Implementation C++ several C++, Java Java Java

1. Geometric modeling of the robots. Any software can be used. The OBJ or
VRML 2.0 formats are supported by Java3D.
2. Programming the manufacturing cell elements. A general class “robot” that
can move all degrees of freedom of each robot was developed.
3. Integrating all the robots to the simulation. The manufacturing cell with
all its elements is assembled from these. Using OODVR any participant can
provide a simulation element at runtime.
The cell modeled is one that exists at ITESM-CEM, and it consists of 4
robots: Mitsubishi MoveMaster, Unimation Puma 560, Amatrol Jupiter XL and
Amatrol AS/RS. The virtual environment simulates these robots as well as other
static and dynamic elements.
The virtual lab was implemented under OODVR using the following pack-
ages:
1. oodvr.test.universe: Contains the classes Universe and UniverseApplet, which
define the 3D world where the cell elements will exist.
2. oodvr.test.universe.robot: The robot class is generic and allows us to build
any robots in Java3D by using the following parameters:
– Name of robot
– Number of DOFs
– Number of Links
– Name of geometry file (obj or vrml)
– An array of the order of the links
– Scale, Rotation and Translation of the robot in world coordinates
– An array of pivot points that will move the DOFs
– An array relating links and DOFs
The classes RobotI, Robot Stub and ThreadMethod are included for com-
munication and remote methods. Each robot also has its own control panel.
3. Package oodvr.test.universe.ambiente: This includes the class Celda that in
turn calls a number of classes defining the other dynamic and static elements
of the cell.
In mid 2001 the simulation was improved by implementing a simple interface
permitting the user take control of more than one robot at a time. This required
implementing a simple exclusion mechanism so that only one user controls a
given robot at a time. See figure 2.

Fig. 2. Cell (Linux and Windows mid-2001 version)

We have been focusing of late in making several improvements:

1. We can now use multicast to connect the different users to the simulation
without requiring each of them to know the IPs of all the participants. Only
the multicast address and port are now required.
2. OODVR was re-structured so that adding new robots or other objects to
the simulation is simplified. Objects can have remote behaviours. The new
structure of the packages is as follows:
– oodvr.active: All classes for objects with remote behaviours, their con-
trols
– oodvr.passive: All classes for static objects.
– oodvr.device: All classes for input devices.
– oodvr.universe: Classes for the user’s universe management
– oodvr.window: Classes for the GUI.
3. With the restructuring of the package, an interface allowing each user to
specify which entities it will contribute to the simulation. Before this change,
each user had to write a small java program indicating the entities it would
contribute.
4. A module permitting the incorporation of devices such as joysticks was also
added. We are trying to make this a standard interface for more devices.

5 Conclusions

The OODVR architecture has been succesfully applied to the simulation of a

virtual manufacturing cell. It has proved easy to use and modular even in this
incarnation, which is far from complete.
6 Future Work
We are still working on several improvements to the architecture. We must im-
prove the prediction and convergence algorithms to insure that all users are
synchronized. Also, we would like to use something other than Java 3D for the
display (OpenGL, Performer, etc). This is needed because Java3D is sometimes
not as fast or flexible as we would like. We are considering making the display a
separate module.

References
1. SINGHAL, S. et. al., Networked Virtual Enviroments, Design and Implementation,
ACM Press, 1999.
2. CANTERBURY, M., An Automated Approach to Distributed Interactive Simula-
tion (DIS) Protocol Entity Development, NPS Thesis, 1995.
3. U.S. Department of Defense, High-Level Architecture Rules, Version 1.3, February,
1998.
4. BACKES, P. G. et. al., The Web Interface for Telescience (WITS), Proceedings of
the IEEE International Conference on Robotics and Automation, 1997
5. SHOFFNER, M. Hamier D. Java Network Programming: a complete guide to
networking, streams and distributed computing. Manning, 1999.
6. COUCH, J. Java 2 Networking. Mc Graw Hill, Java masters series, 1999.
7. Hardt, J. and White, K., Distributed Interactive Simulation (DIS), EEL 4781 Com-
puter Networks, University of Central Florida, Fall 1998.
8. Locke, J., An Introduction to the Internet Networking Environment and SIM-
NET/DIS, Computer Science Department, Naval Postgraduate School, 1995.
9. Distributed Interactive Simulation DIS-Java-VRML Working Group, Naval Post-
graduate School, http://www.web3D.org/WorkingGroups/vrtp/dis-java-vrml/dis-
java-vrml.html
10. High Level Architecture (HLA), Defense Modeling and Simulation Office,
http://hla.dmso.mil