This is the accepted version of the following article, which is in proceedings of the First International Cnoference on Autunomous Agent, ACM Press, 1997, pp.435--442
An Open Architecture for Robot Entertainment
3
Masahiro Fujita and Koji Kageyama
D21 Laboratory, Sony Corporation 6-7-35, Kitashinagawa Shinagawa-ku, Tokyo, 141 Japan
[email protected],
[email protected]
Abstract We propose an open architecture for autonomous robot systems, which are aimed at entertainment applications. In order to achieve system extension and recon guration capabilities for mechanical, electrical, and software systems, we propose an architecture with the following features: (i) A common interface for various components such as sensors and actuators, (ii) a mechanism for obtaining information on functions of components and their con gurations, and (iii) layered architecture for hardware adaptation, system services, and application for ecient development of hardware and software components. A software platform provides an environment for agent design so that designers can customize their recognition and control algorithms. This is based on Apertos, a fully objectoriented real-time distributed operating system which allows each physical and software component to be de ned uniformly as an object. As an example of an autonous robot based on the proposed architecture, we describe an autonomous quadruped robot that is currently under development. Our robot is capable of various behavior such as walking, sitting, standing, and speaking, and it is directed by sound and visual interactions with humans and the environment.
Introduction
In this paper, we propose an open architecture for physical robots and their software system designed particularly, but not exclusively, for entertainment. We use the term Robot Entertainment to denote this eld. The goal of the work described in this paper is to establish a draft standard for mobile robots and their software systems. This standard would allow di erent companies and researchers interested in robots for entertainment to build their own products and prototype systems using o -the-shelf components, which meet our speci cations. Our open architecture and standard target entertainment applications for three reasons: 3
In Proceedings of the First International Conference on Autonomous Agents, ACM Press, 1997, pp.435{442
Complete Agent: A robot for entertainment re-
quires a complete autonomous physical agent. Instead of research and development activities focusing on speci c perceptual functional components such as speech and visual cognitive subsystems, a complete agent promotes and accelerates research activities involving combination of subsystems and whole robot systems. Technology Level: Robots for entertainment applications do not require such high performances in speech recognition and visual information processing that are required in mission-critical industrial applications. While there exist special and dicult requirements in entertainment applications themselves, limited capabilities or performances can cause a certain kind of excitement to users in most game playing situations such as RoboCup (Kitano 1995) (soccer games by robot agents). This implies many existing AI technologies can be implemented for these kinds of applications. Emerging Industry: We believe that we will be able to create a completely new market in the near future by introducing this kind of robot product sharply focused on entertainment applications. After the Gold Rush of Internet and cyberspace, people will eagerly seek real objects to play with and touch. Robot Entertainment provides tangible physical agents and an undoubted sense of reality. By establishing a standard for entertainment robot software as well as robot parts, manufacturers can produce and sell their own commodities using the standard. AI researchers often spend large amounts of time customizing hardware. O -the-Shelf components allow researchers to construct customized robots for their research platform minimizing time consuming hardware and software hacking. In order to achieve our goal, the standard must be comprehensive and exible. It should be able to cover possible robot structures and software needs for a wide range of entertainment applications. We call our standard the Open architecture for Robot entertainment, or OpenR.
Overview of the OpenR Architecture
The OpenR system architecture has the following salient features: Open Architecture: The OpenR de nes a set of standard interfaces for physical and software components and a programming framework, so that anyone can design extensions to the basic robot system within this standard. In order to realize this goal, rst, we consider some application examples and their architecture. Then, we de ne a Generic Reference Model and introduce a Layered Architecture. Con gurable Physical Components: The OpenR de nes a common interface for all robot components for exible and extensible robot con guration. This includes a mechanism for obtaining information on component function and con guration for interactive applications. Along with object-oriented software architecture, the OpenR provides Plug-and-Play capabilities for physical robots. Object-Oriented Robot OS: The OpenR employs Apertos (Yokote 1992), a fully object-oriented distributed real-time operating system, This enables us to de ne all physical and software components uniformly as distributed \objects".
Requirments
In Robot Entertainment , there will be various applications, such as a pet-type robot, a game-type robot, or a tele-presence robot, which may be fully autonomous, or remote controlled semi-autonomous. For these applications, the following are considered to be common requirements: stand-alone application, extensibility, friendly application development tools. Taking these requirements into account, we are able to de ne a generic refernce model.
Generic Refence Model
The generic reference model consists of a basic system, an extension system, and a development environment (Fig.1). Interconnections between these systems are to be de ned as reference points. Since small numbers of pins and a wide bandwidth are important , we plan to use a serial bus.
Basic System: The basic system is a stand-alone
robot system. It consists of fundamental components such as a CPU board, actuators and a camera, and is battery operated. In addition, it has removable Program Media which can be changed when other applications are installed. Details of the basic system are discussed in Section \Basic System".
Basic System Bus Adaptor
RP0 MPS
RP0-2
Development Environment
RP0-1
CPC
RP0-0
System Core
PC/Workstation
RP1
Extension System eg. Basic Module for Multi-Processors SYSTEM Wireless Module
RP 2-0
PC
Figure 1: Generic System Functional Model
Extension System: The Extension System is a set
of auxiliary components to expand functions of the basic system. One such component is a wireless LAN module connected to the Basic System Module for remote controlled applications. Another basic system can thus be connected as an extension system in order to expand the CPU computation power to form a multi-processor system. Various low-level control for multi-processor system are handled by Apertos, mentioned above.
Development Environment: The standard development environment will be on a PC or a workstation, providing a friendly environment in which end users are able to develop programs for robots based on the OpenR standard.
Layered Architecture
Next we describe the layering of the reference model. In principle, there is a hardware adaptation layer (HAL), a system service layer (SSL), and an application layer (APL) (Fig.2) Layering technique is often used in open architectures or multi-vendor systems, because designers can develop programs independent from hardware using well de ned interfaces.
Hardware Adaptation Layer: HAL keeps SSL
independent from details of hardware speci cations. This mechanism makes it possible for the system to use a high cost-performance hardware implementation
RP1
APL
Application
RP0-2
Development Environment
Basic Sys.
Ext. Sys.
RP0 Application
HAL
Comm. Manager
Comm. Manager
Serial Bus Host
Serial Bus Serial Bus Function Funciton
MPS
System Core
Designed Robot
Designed Robot
Robot Func Library
Virtual Robot
Function Function TagsFunction CPC Tags Basic Tags Info Basic Info Basic Info
Serial Bus Function
Serial Bus Host
Hardware Hardware Interface Serial Bus Interface Function
Application
APL SSL
RP0-0
Comm. Manager
Serial Bus Host
SSL
HAL
CPC Functions Functions as as CPC Functions Robot Robot
Figure 2: Layered Generic System Reference Model
Figure 3: Basic System Layered Reference Model
according to the progress of the technologies without change of the higher layers. Furthermore, it guarantees re-use of software components in the higher layers, accelerating the accumulation of software components, and as a result, allows the system to become widely spread.
sensors and actuators which have common interfaces, so that designers or users can build their own robots by connecting CPCs. Furthermore, these components have so-called Hot-Plug-In and Plug-and-Play capabilities, so that a user can change con guration of a robot without power-o . MPS supplies application programs so that a user can run di erent applications by inserting various MPSs. The reference points are de ned between the three function systems, and the interfaces are speci ed at those points. As in the previous section, the layering structure is applied as shown in Fig.3. There are three layers, HAL, SSL and APL, and each object in a function system communicates with an object in another function system in the same layer.
System Service Layer: SSL provides services to
APL by interfacing physical components and application programs. In essence, this layer manages distributed hardware resources which are connected to each other via the serial bus, so that the users in APL can easily use the distributed resources.
Application Layer: APL is the layer in which
designers develop applications software components. Utility objects and Application Interface (API) are provided for designers and end users.
Basic System
The basic system consists of three functional subsystems: System Core, Con gurable Physical Components (CPC), and removable Media for Program Storage (MPS), as shown in Fig. 1. Here we describe the architecture for Basic System, focusing on Con gurable Physical Components (CPCs) which have a common interface so that a designer can make a robot with any desired con guration. In addition, The Basic System has a mechanism for automated con guration of CPCs. The System Core is the master of the entire robot control system. It is composed of a CPU and other peripheral components, including DSPs for signal processing, such as sound processing. CPCs are a set of
Con gurable Physical Component
To provide the exible robot structure with a common interface, we de ne the CPC with following features: Hot-Plug-In, Plug-and-Play Stores the con guration of components Stores the physical properties of components Stores the functional properties of components The serial bus will be connected in a tree structure. An example is shown in Fig. 4, where twelve parts are connected. The Serial bus host in HAL of System Core can get the tree-structure of the con guration while assigning a logical address to each CPC. To obtain the physical and functional properties for the CPC host, which manages communications among CPCs in SSL, each CPC has the following information: shape, mass, center of mass and inertial moments.
CPCs in APL
camera, mic P10
P9
P0
P7
P3
P5
P1
P4
P8
P2
P6
0 1
Serial Bus Host P0
4 3
2 P1
P3
0
0
P2
P4
P5
P7
0
0
0
P10
P6
P8
P9
0 P11
mic
1 P12
camera
Figure 4: Tree-Structured CPC the positions of linked points and the direction of
the axis along which the next CPC is attached.
primitive functions of the CPC.
Here primitive functions mean, for example, an actuator, 2D image sensor and a microphone. The CPC host reads this information. If there is not enough memory in CPCs to store CPC property information, only an ID-tag number is recoreded. In this case, the CPC host obtains the corresponding information from MPS, or Extension System con gured as a storage, based on the ID-tags of CPCs. The system copes with these two cases to provide the set of objects via the same protocol to APL, so that a user does not have to worry about whether CPC has enough memory to store CPC property information. The set of CPC objects, which are constructed by the CPC host with the CPC property information, is called a Virtual Robot. The Virtual Robot also knows the logical addresses of CPCs.
When a designer wants to make an application program, he/she can access each CPC by obtaining the logical address of the CPC from the Virtual Robot. This is done by utilizing the tree-structure of the CPC con guration. If the designer knows the tree-structure, he/she can specify the CPC by specifying the position in the treestructure. For example, in Fig.4, if we would like to access the camera named P12, which has the position of f2,0,1g in the tree-structure, we can get the logical address of P12 from the Virtual Robot by specifying the position, f2,0,1g. The Virtual Robot knows the information of primitive functions of CPCs and its physical con guration; however, using only information it is dicult to determine how to use the CPCs for higher functionalities. For example, in Fig.4, only a designer can determine that the set of P10, P11 and P12 is used as a head. Imagine that there is no camera and no microphone in Fig.4, then there is no clue to determine which part is the head, except for using common sense derived from the whole shape of robot. Therefore, a designer is able to design several alternative robots for the same CPCs and the same physical con guration. One of these alternatives is called a Designed Robot. As a result, application designers can use the CPCs via this Designed Robot using a logical meaning message, rather than the position in the treestructure in the Virtual Robot.
Application Layer
In APL, the following services are going to be supported: Fully Object-Oriented and Concurrent Object environment by Apertos. Graphical Programming environment for end users. Some image and audio processing/recognition programs with layering structure and standard interfaces. Autonomous Robot Reference Model. As for the Graphical Programming environment we design some base classes for asynchronous communication among the application objects. The base classes, which have standard interfaces for communication, are designed using the method called Observer Pattern (Gamma et al. 1995). Using objects with standard communication interfaces, in the future we will be able to provide a graphical programming environment, in which a user can create an application program by connecting utility or toolbox objects displayed as icons with communication nodes. For the ToolBox, we are planning to prepare objects for image and audio signal processing/recognition which have layered structures. By de ning reference points between those layers, it becomes possible to
Taget Behavior Generator
Body
Event Event1 from other module
>
