ICAT '99
Development of R-Cubed Manipulation Language-Implementation and Evaluation to a RCML System1

121

Wei-Chung Teng , Dairoku Sekiguchi , Akira Nukuzuma , Naoki Kawakami ,11Yasuyuki Yanagida , and Susumu Tachi
1

Tachi Laboratory,
School of Engineering, The University of Tokyo
7-3-1 Hongo, Bunkyo-ku, Tokyo, 113-8656 JAPAN{waldo, dairoku, kawakami, yanagida, tachi}@star.t.u-tokyo.ac.jp
2
Takatsuki Laboratory, Minolta Co. Ltd.
1-2,Sakura-Machi,takatsuki-Shi, Osaka, 569-8503 JAPAN
nuu@eie.minolta.co.jp

AbstractR-Cubed (R3: Real-time Remote Robotics) is the concept
and technology which attempts to provide a solution forpeople to telexist anywhere in the world by controlling
remote robots as his avatars in real time base through thenetwork. An R-Cubed system is supposed to allow
people to control remote robots from terminals installed
on homes, offices, or any public booths connected toInternet or other dedicated networks. As part of R-Cubed
research, we proposed RCML/RCTP structure as asolution on implementing R-Cubed systems. To examineand verify practicability of RCML/RCTP structure, wealso implemented an RCML system based on RCML andRCTP specification on a low-end platform. In this paper
we will show how we implement the experimental systemfollowing the specification of RCML and RCTP.
Observation and evaluation to the system results in somehints on designing next version of specification and are
discussed in detail.

On the other side, each client has a teleoperation system
ranging from a control cockpit with master manipulators
and a HMD (high end) to an ordinary PC equipped withmouse and maybe a joystick (low end). In the meantime
real-time data transfer channel is employed to provide abasis for users and robots to communicate with eachother. That is because only with real-time response canhuman retains the sensation of presence.
Towards the realization of R3 concept, we proposed RCubed Manipulation Language (RCML) and R-Cubed
Client

Dedicated teleoperation systems

ServerNetwork

Key words: Telexistence, R-Cubed, RCML, RCTP,
VRMLend) to a movable camera (low end). A virtual robot canalso be a controlling subject, so we can telexist in virtualworlds as in remote environments.

1. Introduction
R3 stands for Real-time Remote Robotics [1], is a longrange project originated by Japanese Ministry ofInternational Trade and Industry (MITI) in 1995. The
concept of R3 is to construct an infrastructure thateveryone in the society can freely telexist through anetwork. In R3 society there would have R-Cubed booths
installed in home, offices, or public places quipped withteleoperation systems which people can use to control
remote robots as if the robots be his/her avatars. Someother words such as networked telexistence or networked
robotics are also used to express the concept of R3 [2].
Figure 1 shows the concept of R3 system. In the clientserver systems each robot site includes its local server
system. The robot type varies from a humanoid (highGUI

Common teleoperation systems

Robots and roboticdevices

Fig. 1 An R3 system should supports large scale ofteleoperation systems and robotic devices

Transfer Protocol (RCTP) as a solution on constructing
R3 systems [3]. The RCML/RCTP approach is designed
from the end-user’s standpoint, keeping “how the users
access the remote real environments” in mind. And on
the early stage our study focuses on implementations on
the low-end systems.

2. Related Works
Although networked telexistence, or networked robotics,
is still a new research field, more and more successful
cases are reported [4-9]. However, some researches aim
on particular purposes such as space work [6] or medical
treatment with dedicated systems that considered not
intuitive to apply on general application. On the other
hand, WWW browser seems to be a possible candidatefor general-purpose networked robotics operation
platform, since many approaches apply WWW browser
to operate remote robots executing simple operations
such as browsing inside building [8][9] or painting [10].
However, the innate characteristics of WWW Browser’s
structure implies problems on constructing a controlling
platform and results the whole system in constrained andnot intuitive structure [3].
On the case of virtual environment, since the VRML 1.0
standard was specified in 1994, the use of VRML has
become the most popular way to construct and accessvirtual worlds. VRML 2.0 provides the mechanism on
designing and handling the actions of objects, and has
become an ISO standard known as VRML97 [11]. By
the way, although some implementations show thepossibility on controlling virtual robot modeled with
VRML [12], a standard way to model controllable
mechanism and sensory information is still necessary forvarious types of robots.

2. Notes on RCML and RCTP
Before we discuss the experimental implementation, abrief introduction on the concept and characteristic of theRCML/RCTP system is showed below.

control the robot at a time.
Input/output objects can still be classified into five types
according to the type of data they handle: video
input/output object, audio input/output object, control
input/output object, text input/output object, and binary
input/output object. Each type of output object is thecounterpart of corresponding type of input objects.

2.3 Translators
RCML/RCTP system is designed to be applicable forvarious types of robots and devices, and the way datatransferred over the network should be standardized andbe independent of the robots and devices connected ateach site. To satisfy this requirement, software modules
called translators are provided to translate the specificformat data into standard format and vice versa. For
example, the data returned from some 6 DOF position
sensor may contain 6 degrees for 6 joint respectively.
The position data is converted by input translator into
standard format, say coordinate in Cartesian coordinate
system, before it’s transferred to the other site. The
transferred position data would be converted by output
translator of the opposite site again to suite the specificoutput device.
An I/O device, when coupled with its translator, istreated as an input/output object in RCML/RCTP system.
Figure 2 shows the relationship between object,translator, and device.

2.4 Structure of RCMLThe R-Cubed Manipulation Language is designed as afile format for describing real world or virtual spaces andfor robot characteristics such as degrees of freedom,control parameters, and sensor information.
Since VRML provides a standard and popular way toconstruct interactive three-dimensional objects andvirtual worlds, we adopt VRML97 as the base format to

2.1 Client-Server Architecture
The RCML/RCTP system is of client-server architectureas R3 system. Server stands for the controlling system
software running at the robot site, and client stands forthe software running at the user's computer.

2.2 Objects
The concept of object is introduced o define thefunctional input/output units on the system. According totheir functionality, the objects are grouped into three
categories: system object, input object, and output object.
System objects include server object and client object,which refer to, in respective, the server and client’s
computer hardware and the RCML/RCTP software
running above it, in the base that only one client canServer (Robot) Site

Input
DeviceRemoteEnvironment

Client (User) Site

Input
Translator

OutputTranslator

Input Object

OutputDeviceOutput Object
OperatorNetworkOutput
DeviceOutputTranslator

Input
Translator

Output Object

Input
DeviceInput Object

one-to-one mapping

Fig.2 Functional units and information flow in the
RCML/RCTP systemdescribe remote environments, controlled robots
themselves, and robot characteristics. A typical RCML
file should include two parts: a virtual world, which is
the “copy” of real remote world, written as normal
VRML files, and a RCML-defined PROTO nodecontaining control parameters and sensory information
description.
The structure of RCML extension nodes is constructed inthe same way with objects. It contains 3 levels with theRCML_Robot grouping node as the “root” node. Systemobject nodes and Input / Output object nodes arecontained in RCML_Robot and stand for system objects
and Input / Output objects respectively. Control objects
areclassified
furthermore
intosmallunit
RCML_ControlInputData or RCML_ControlOutput Datanodes. Table 1 lists all kinds of nodes and shows theirrelationship.

2.5 Phases on RCTP
RCTP is designed to cooperate with RCML. The twomain jobs for RCTP are to negotiate for assigningeffective pairs of input/output devices in robot and usersites, and to transfer the control commands from user andstatus information from robot in real-time.
The process of a RCTP connection is divided into 3phases. In the beginning the users access some Web
pages describing the information of controlling robots,
and then download the RCML file. RCML browser isinvoked at this time to parse the RCML file. This part iscalled the greeting phase.
After the user picks out the controlling objects anddecides the corresponding input device, RCML browser
would try to build a network connection with RCML
server. After connection is established, RCML browser
would request to get the control permission of robot’sobjects. If the requested device is free and functions well,server will assign a unique ID number to the device andacknowledge it back with all initial characteristic valuesappended. All this process should follow thespecification of HTTP/1.1 [13], and the part is called thenegotiation phase. If negotiation phase completessmoothly, RCML browser would send the GO method inorder to start the controlling phase. Control messages andsystem information transferred in this phase are binary
based and contrived to meet the real-time needs, however
the Video/Audio and other Sensory information are left
to dedicated protocols. This phase is call as Live Session
Phase.

Table 1. List of Nodes in RCML
Level 1 Node
RCML_Robot
SystemRCML_Server
Object
RCML_Client
Node
RCML_VideoInput
RCML_AudioInput
Input
RCML_ControlInput
ObjectLevel 2
RCML_TextInput
NodeNode
RCML_BinaryInput
RCML_VideoOutput
RCML_AudioOutput
Output
RCML_ControlOutput
Object
RCML_TextOutput
NodeRCML_BinaryOutput
RCML_Control
RCML_ControlInputData
Level 3 Input Node
Node RCML_Control
RCML_ControlOutputDataOutput Node
PCMCIA wireless LAN card is used to connect thenotebook to the network. For most efficiency we use C
language to code server program. The server program
controls rotation and movement of the robot, anddirection of video camera.
On the client site, the whole client application is
executed on a low-end PC (Pentium MMX 200MHz with64MB memory) with Joystick and ADL-1 equipped.
ADL-1 is a 6DOF position sensor designed originally formeasuring position and direction of human head,
however we use it as a three-dimensional position inputdevice. For higher portability, the main body of client
program is written in Java language, with drivers ofphysical devices written in C language. The VRML
browser (Sony Community Place Browser) is used tohandle VRML part of the RCML file, and videoconferencing program (CU-SeeMe) is used for video
stream transfer. These helper programs greatly shorten
the development period. How the helper programs
cooperate with RCML client program is showed on
Figure 5. Because RCML is defined as an extension ofVRML, all Java program is linked from VRML file by
Script nodes, by this way we could update VRML world
Joystick ADL-1
CommandVideo Signal
Command to Robot andVideo Camera

Command3. Experimental RCML System
To examine and verify practicability of RCML/RCTP
structure, we implemented an RCML system based on
RCML and RCTP specification on a low-end platform.
The structure of the system is shown in Figure 3. On theserver site a direction controllable video camera and anotebook PC are fixed on the movable robot, where aStatus

RobotStatus of Robot &Video Stream

Notebook PC

Client PC

Wireless LAN

Server Side

Client SideFig.3 Hardware structure of the RCML system

Fig. 4 Photo of the controlling robot
synchronized with remote environment.
In this experimental system, RCTP is implemented based

Table 2. Objects in the RCML system
Server Site
Client Site
System Object
Server Program
Client ProgramVideo Input
Video Camera
ObjectVideo Output
Video conferencObject
ing program
Control Input
Common GUIObject(slider bar, text
field, button, etc.),
Joystick,
ADL-1
Control
Direction andOutput Object Zooming ofCamera,
Movement andDirection ofRobotmechanism to negotiate how controlling command andsensory information share the limited bandwidth. During
development period, we also found that VRML grammar
and its Java platform class’s definition did restrict future
extension of RCML. Approach such as XML based
RCML is under consideration.

4. Conclusion
In this paper, some implementation related topics on
RCML and RCTP are picked up and compared to theexperimental system. Practicability of RCML/RCTP
structure is verified as this system treat all kind of input
and output objects the same way by standardize the data
type and format of object. However, further study on
characteristic of user interface is necessary forconstructing general-purpose teleoperation system.
Fig. 5 Screen of client program with scroll bar and 2D
map input objects
on TCP/IP protocol. On the beginning RCML file andtranslators are already in client site’s computer, so thegreeting phase is omitted. However, negotiation phaseand live-session phase is faithfully realized. Users areasked to pick up his/her favorite input device if therequest for controlling robot is permitted. Some common
GUI, joystick, and ADL-1 are supported in this system,and they are treated in the same way by RCTP clone.
Table 2 lists all objects in this RCML system. I/O objectsof the same type can be paired up as defined in theRCML specification.

4. Results
Comparing to approaches using CGI and HTTP, oursystem provides flexible and compact structure to handle
continuous command stream that is necessary for R3system. However, due to narrow bandwidth (2Mbps) ofwireless LAN in the experimental system, time delay
becomes obvious when high quality video stream ischose. Next version of RCTP should has suitable

References
1.

MITI of Japan, R-Cubed WG ed.: “R-Cubed”,Nikkan Kogyo Shimbun (1996).

2.

S. Tachi: “Real-time Remote Robotics – Toward
Networked Telexistence,” IEEE Computer Graphicsand Applications, pp. 6-9 (1998).

3.

W. C. Teng, A. Nukuzuma, N. Kawakami, Y.
Yanagida, and S. Tachi: “Development of R-Cubed
Manipulation Language - The Specification of RCML
and RCTP –,” Proc. of the 8th International
Conference on Artificial Reality and Tele-existence,
pp.156-162 (1998).

4.

R. Simmons: “Xavier: An Autonomous Mobile
Robot on The Web,” Preprints of IROS’98 Workshop‘Robots on the Web’, pp.43-47 (1998).

5.

P. Saucy and F. Mondada: “KhepOnTheWeb: One
Year of Access to a Mobile Robot on the Internet,”
Preprints of IROS’98 Workshop ‘Robots on the Web’,pp.23-29 (1998).

6.

Y.Wakita, S. Hirai, K. Machida, K. Ogimoto,T.Itoko, P. Backes, and S. Peters: “Application ofIntelligent Monitoring for Super Long Distance
Teleoperation,” Proc. Of IROS’96, pp.1031-1037(1996).

7.

A. Kheddar, C. Tzafestas, P. Coiffet, T. Kotoku, S.
Kawabata, K. Iwamoto, K. Tanie, I. Mazon,C.Laugier, and R. Chellai: “Parallel Multi-Robots
Long Distance Teleoperation,” Proc. of ICAR’97,pp.1007-1012 (1997).

8.

S. B. Goldberg, et al.: “DIGIMUSE: A interactivetelerobotic system for remote viewing of threedimensional art objects,” Preprints of IROS’98Workshop ‘Robots on the Web’, pp.55-59 (1998).

9.

S. Maeyama, S. Yuta, A. Harada: “Mobile Robot inthe Remote Museum for Modeling the Evaluation
Structure of KANSEI,” Proc. of 7th IEEE
International Workshop on Robot and Human
Communication, Vol. 1, pp.315-320 (1998).

10. M. R. Stein: “Painting on the World Wide Web: ThePumaPaint Project,” Preprints of IROS’98 Workshop‘Robots on the Web’, pp.37-42 (1998).
11. http://www.vrml.org/technicalinfo/specifications/vr
ml97/index.htm: “VRML97 Specification, ISO-IEC
14772-11997,” Web3D Consortium (1997).
12. http://www.robotic.dlr.de/STUDENTS/Martin.Rohrmeier/robot/robot.html
13. Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Berners-Lee, T.: “Hypertext Transfer Protocol -HTTP/1.1,” RFC 2068, UC Irvine, Digital Equipment
Corporation, M.I.T. (1997).