A rapidly deployable manipulator system

Robotics and Autonomous Systems ELSEVIER

Robotics and Autonomous Systems 21 (1997) 289-304

A rapidly deployable manipulator system C h r i s t i a a n J.J. Paredis *, H. B e n j a m i n B r o w n , P r a d e e p K. K h o s l a Department of Electrical and Computer Engineering and The Robotics Institute, Carnegie Mellon University, Pittsburgh, PA 15213-3890, USA

Abstract

A rapidly deployable manipulator system combines the flexibility of reconfigurable modular hardware with modular programming tools, allowing the user to rapidly create and program a manipulator, which is custom-tailored for a given task. This article describes the main building blocks of such a system: a reconfigurable modular manipulator system (RMMS), modular and reusable control software, and a novel agent-based approach to task-based design of modular manipulators. Keywords: Modular robotics; Softwareassembly; Composabledesign system; Agent-based genetic algorithm

I. Introduction

Robot manipulators can be easily reprogrammed to perform different tasks, yet the range of tasks that can be performed by a manipulator is limited by its mechanical structure. For example, horizontal SCARAconfiguration manipulators, such as the Adept One and the CMU Direct Drive Arm II, are well suited for delicate table-top assembly operations requiring accuracy and selective stiffness, but have very limited vertical reach. On the other hand, vertical elbow-configuration manipulators, such as the Puma family, have a relatively long reach in all directions and are suitable for painting, welding, and parts handling, but do not have the accuracy and stiffness required for precise assembly. Therefore, to perform a given task, one needs to choose a manipulator with an appropriate mechanical structure - kinematical as well as dynamical. Applying a manipulator with an optimal configuration to a particular task is only possible if the task is known in advance. This is often not the case in un* Corresponding author. E-mail: [email protected].

predictable environments such as a nuclear environment or a space station. To be able to address these unknown tasks, one would need a manipulator with a wide range of capabilities - probably beyond the limitations of a single manipulator. To solve this problem, one could deploy a large number of manipulators, each with different kinematic and/or dynamic characteristics. However, this is often prohibitively expensive, for instance, because the robots become contaminated by radiation, or because the total mass of all manipulators combined is too large to be transported into space. We propose the concept of a rapidly deployable manipulator system to address the above-mentioned shortcomings of fixed configuration manipulators. As is illustrated in Fig. 1, a rapidly deployable manipulator system consists of software and hardware that allow the user to rapidly build and program a manipulator which is custom-tailored for a given task. The central building block of a rapidly deployable system is a reconfigurable modular manipulator system (RMMS). The RMMS utilizes a stock of interchangeable link and joint modules of various sizes and performance specifications. Two such modules are

0921-8890/97/$17.00 © 1997 Elsevier Science B.V. All rights reserved P11S0921-8890(97)00081-4

C.J.J. Paredis et al./Robotics and Autonomous Systems 21 (1997) 289-304

290

RapidlyDeployableSystemsI Rapid Creationof [ Electro-Mechanical System

RapidManipulator Programming [ Engineerin~[

Synthesisof [ Scn.,or-Based [ ControlSoftware [

Fig. 1. The concept of rapidly deployable systems.

Fig. 2. An RMMS pivot joint and link module.

shown in Fig. 2. By combining these general purpose modules, a wide range of special purpose manipulators can be assembled. Recently, there has been considerable interest in the idea of modular manipulators

[2,4,6,10,12,13,23], for research applications as well as for industrial applications. However, most of these systems lack the property of reconfigurability, which is key to the concept of rapidly deployable systems. The RMMS is particularly easy to reconfigure thanks to its integrated quick-coupling connectors. We describe the hardware of the RMMS in detail in Section 2. Experimental results can be found in Section 6. Effective use of the RMMS requires Task Based Design software. This software takes as input description s of the task and of the available manipulator modules; it generates as output a modular assembly configuration optimally suited to perform the given task. Several different approaches have been used successfully to solve simplified instances of this complicated problem [3,11,18,21]. In Section 3, we describe our novel approach, which is a distributed multi-agent design methodology derived from genetic algorithms. A third important building block of a rapidly deployable manipulator system is a framework for the generation of control software. To reduce the complexity of software generation for real-time sensor-based control systems, a software paradigm called software assembly has been proposed in the Advanced Manipulators Laboratory at CMU. This paradigm combines the concept of reusable and reconfigurable software components, as is supported by the Chimera real-time operating system [26], with a graphical user interface and a visual programming language, implemented in Onika [7]. This software framework and its application to the control of the RMMS are described in Section 4. Although the software assembly paradigm provides the software infrastructure for rapidly programming manipulator systems, it does not solve the programming problem itself. Explicit programming of sensorbased manipulator systems is cumbersome due to the extensive amount of detail which must be specified for the robot to perform the task. The software synthesis problem for sensor-based robots can be simplified dramatically, by providing robust robotic skills, that is, encapsulated, strategies for accomplishing common tasks in the robots task domain [ 15]. Such robotic skills can then be used at the task level planning stage without having to consider any of the low-level details. A methodology for developing robotic skills based on sensorimotor primitives [15] is briefly discussed in Section 5.

C.J.J. Paredis et al./Robotics and Autonomous Systems 21 (1997) 289-304

As an example of the use of a rapidly deployable system, consider a manipulator in a nuclear environment where it must inspect material and space for radioactive contamination, or assemble and repair equipment. In such an environment, widely varied kinematic (e.g., workspace) and dynamic (e.g., speed, payload) performance is required, and these requirements may not be known a priori. Instead of preparing a large set of different manipulators to accomplish these tasks - an expensive solution - one can use a rapidly deployable nmnipulator system. Consider the following scenario: as soon as a specific task is identified, the task-based design software determines the optimal modular assembly configuration to perform the task. This optimal configuration is then assembled from the RMMS modules by a human or, in the future, possibly by another manipulator. The resulting manipulator is rapidly programmed by using the software assembly paradigm and our library of robotic skills. Finally, the manipulator is deployed to perform its task. Although such a scenario is still futuristic, the development of the reconfigurable modular manipulator system and its support software, described in this paper, is a major step forward towards our goal of a rapidly deployable manipulator system. Our approach could form the basis for the next generation of autonomous manipulators, in which the traditional notion of sensor-based autonomy is extended to configuration-based autonomy. Indeed, although a deployed system can have all the sensory and planning information it needs, it may still not be able to accomplish its task because the task is beyond the system's physical capabilities. A rapidly deployable system, on the other hand, could adapt its physical capabilities based on task specifications and, with advanced sensing, control, and planning strategies, accomplish the task autonomously.

2. RMMS self-contained hardware modules In most industrial manipulators, the controller is a separate unit housing the sensor interfaces, power amplifiers, and control processors for all the joints of the manipulator. A large number of wires is necessary to connect this control unit with the sensors, actuators and brakes located in each of the joints of the

291

~

n

~,~ "~

7+;3

NN

~

i

~

m

m

m

,m~mimma

mmm

ARCNET

ROM

RS-485

RS-232 mmmmmmmm

~o Dia 8 ~osfics a

72V 48V twisted pair

<

Fig. 3. Diagram of a self-contained RMMS module.

manipulator. The large number of electrical connections and the non-extensible nature of such a system layout make it infeasible for modular manipulators. The solution we propose is to distribute the control hardware to each individual module of the manipulator. These modules then become self-contained units which include sensors, an actuator, a brake, a transmission, a sensor interface, a motor amplifier, and a communication interface, as is illustrated in Fig. 3. As a result, only six wires are required for power distribution and data communication.

2.1. Mechanical design The goal of the RMMS project is to have a wide variety of hardware modules available. So far, we have built four kinds of modules, two of which are shown in Fig. 2: the manipulator base, a link module, three pivot joint modules, and one rotate joint module. The base module and the link module have no degrees-of-freedom; the joint modules have one degree-of-freedom each. The mechanical design of the joint modules compactly fits a DC-motor, a fail-safe brake, a tachometer, a harmonic drive and a resolver. The pivot and rotate joint modules use different outside housings to provide the right-angle or in-line configuration, respectively, but are identical internally. Fig. 4 shows in cross-section the internal structure of

292

C.J.J. Paredis et al./Robotics and Autonomous Systems 21 (1997) 289-304 2.2. Electronic design

X-bearing

Motor bearings

Tachometer

Soll motor shaft ~ - /

Fig. 4. Assembly drawing of a pivotjoint module.

a pivot joint. Each joint module includes a DC torque motor and 100:1 harmonic-drive speed reducer, and is rated at a maximum speed of 0.9 rad/s and maximum torque of 290Nm. Each module has a mass of approximately 10.7 kg. A single, compact, X-type bearing connects the two joint halves and provides the needed overturning rigidity. A hollow motor shaft passes through all the rotary components, and provides a channel for passage of cabling with minimal flexing. For serial manipulators, the base joint usually has a larger payload and therefore requires a more powerful motor than the joints closer to the end-effector. To address this issue, we plan to build joint modules with different sizes and power ratings. In a first step, the size of the quick-coupling connectors can be kept constant while varying the motor and transmission size. In this way, one can provide heavier, more powerful modules for the base joints of the manipulator without compromising the reconfigurability of the system. In a second step, to achieve an even wider range of sizes and power ratings, one could build modules with smaller and/or larger connector sizes. In order to maintain system reconfigurability, one will have to include adaptor links that convert from one connector size to another.

The custom-designed on-board electronics are also designed according to the principle of modularity. Each RMMS module contains a motherboard which provides the basic functionality. Onto the motherboard, one can stack daughtercards to add module specific functionality. The motherboard consists of a Siemens 80C 166 microcontroller, 64K of ROM, 64K of RAM, an SMC COM20020 universal local area network controller with an RS-485 driver, and an RS-232 driver. The function of the motherboard is to establish communication with the host interface and to perform the lowlevel control of the module, as is explained in more detail in Section 2.4. The RS-232 serial bus driver allows for simple diagnostics and software prototyping. A stacking connector permits the addition of an indefinite number of daughtercards with various functions, such as sensor interfaces, motor controllers, RAM expansion, etc. In our current implementation, only modules with actuators include a daughtercard. This card contains a 16bit resolver to digital converter, a 12 bit A / D converter to interface with the tachometer, and a 12 bit D/A converter to control the motor amplifier; we have used an off-the-shelf motor amplifier (Galil Motion Control model SSA-8/80) to drive the DC-motor. For modules with more than one degree-of-freedom, for instance a wrist module, more than one such daughtercard can be stacked onto the same motherboard. 2.3. Integrated quick-coupling connectors

To make a modular manipulator reconfigurable, it is necessary that the modules can be easily connected with each other. We have developed a quick-coupling mechanism with which a secure mechanical connection between modules can be achieved by simply turning a ring hand-tight; no tools are required. As shown in Fig. 5, keyed flanges provide precise registration of the two modules. Turning of the locking collar on the male end produces two distinct motions: first the fingers of the locking ring rotate (with the collar) about 22.5 ° and capture the fingers on the flanges; second, the collar rotates relative to the locking ring, while a cam mechanism forces the fingers inward to securely grip the mating flanges. A ball-transfer mechanism

C.J.J. Paredis et al. /Robotics and Autonomous Systems 21 (1997) 289-304

293

for motors and brakes, and 48V-6A power for the electronics. Additional pins carry signals for two RS485 serial communication buses and four video buses. A plastic guide collar plus six alignment pins prevent damage to the connector pins and assure proper alignment. The plastic block holding the female pins can rotate in the housing to accommodate the eight different possible connection orientations (8 @45°). The relative orientation is automatically registered by means of an infrared LED in the female connector and eight photodetectors in the male connector. 2.4. A R M b u s c o m m u n i c a t i o n system

Each of the modules of the RMMS communicates with a host interface over a local area network called the ARMbus; each module is a node of the network. The communication is done in a serial fashion over an RS-485 bus which runs through the length of the manipulator. We use the ARCNET protocol [ 1] implemented on a dedicated IC (SMC COM20020). ARCNET is a deterministic token-passing network scheme which avoids network collisions and guarantees each node its time to access the network. Blocks of information called packets may be sent from any node on the network to any one of the other nodes, or to all nodes simultaneously (broadcast). Each node may send one packet each time it gets the token. The maximum network throughput is 5 Mbit/s. The first node of the network resides on the host interface card, as is depicted in Fig. 6. In addition to a VME address decoder, this card contains essentially the same hardware one can find on a module motherboard. The communication between the VME side of the card and the ARCNET side occurs through dualport RAM. Fig. 5. A male and female RMMS connector. between the collar and locking ring automatically produces this sequence of motions. At the same time when the mechanical connection is made, pneumatic and electronic connections are also established. Inside the locking ring is a modular connector that has 30 male electrical pins plus a pneumatic coupler in the middle. These correspond to matching female components on the mating connector. Sets of pins are wired in parallel to carry the 72V-25A power

Fig. 6. RMMS computing hardware.

294

C.J.J. Paredis et al./Robotics and Autonomous Systems 21 (1997) 289-304

There are two kinds of data passed over the local area network. During the manipulator initialization phase, the modules connect to the network one by one, starting at the base and ending at the end-effector. On joining the network, each module sends a data-packet to the host interface containing its serial number and its relative orientation with respect to the previous module. This information allows us to automatically determine the current manipulator configuration. During the operation phase, the host interface communicates with each of the nodes at 400 Hz. The data that is exchanged depends on the control mode - centralized or distributed. In centralized control mode, the torques for all the joints are computed on the VMEbased real-time processing unit (RTPU), assembled into a data-packet by the microcontroller on the host interface card and broadcast over the ARMbus to all the nodes of the network. Each node extracts its torque value from the packet and replies by sending a datapacket containing the resolver and tachometer readings. In distributed control mode, on the other hand, the host computer broadcasts the desired joint values and feed-forward torques. Locally, in each module, the control loop can then be closed at a frequency much higher than 400 Hz. The modules still send sensor readings back to the host interface to be used in the computation of the subsequent feed-forward torque.

3. Task-based design An important component of a rapidly deployable manipulator system is the Task-based-design (TBD) software. As is illustrated in Fig. 7, it answers the question: given a low-level task description and an inventory of manipulator modules, find a manipulator configuration, its base position, and the corresponding

Task Based Design

desired joint space trajectory which is optimally suited to perform the given task. Note that TBD involves the complete specification of not only the physical structure of the manipulator (kinematics as well as dynamics), but also its behavior (trajectory planning and control). This is especially important when the successful completion of a task depends on the choice of redundancy resolution - for example in the case of fault tolerance or obstacle avoidance [22]. The desired trajectory is used at execution time for null-space optimization in a damped least-squares kinematic controller [22]: 0 = J ~ ( p + ot(p - x)) + ~ ( I - J'~J)(Odes -- 0),

(1) where p is the Cartesian path, Odes the desired trajectory, and j t the singularity robust Jacobian [19]. We assume that a task is defined as a Cartesian path to be followed by the end-effector of the manipulator without violating any of the following constraints: • joint position, velocity, and torque limits; • singularity avoidance; • collision avoidance with obstacles and with the manipulator itself; • fault tolerance (as defined in [22]). The optimality criterion that we consider is energy consumption. This TBD problem is very complicated because of the following three reasons. First, the design space is large and mixed continuous/discrete. The number of different modular assembly configurations grows factorially with the number of available modules (approximately as n!8 n, where the number 8 corresponds to the number of possible relative orientations between two successive modules). In addition, for every assembly configuration, one has to consider all possible manipulator base positions/orientations (continuously varying). Second, the task evaluation depends on the design parameters in a highly nonlinear and multimodal fashion. Third, the evaluation of one candidate solution is very computationally expensive, since it requires a simulation of the task execution. 3.1. An integrated solution approach

Desired Trajectory

Fig. 7. Task-based design problem definition.

In the literature, the TBD problem is usually decoupled into four subproblems: kinematic design,

C.J.J. Paredis et al./Robotics and Autonomous Systems 21 (1997) 289-304

dynamic design, trajectory planning, and control [3,5,11,18,21]. These subproblems are then solved individually and sequentially. However, this approach assumes a weak interaction between the subproblems, which is often not the case in reality, especially when considering such global design criteria as fault tolerance and energy con,;umption. In a sequential design approach, strong interactions would result in an unacceptably large number of re-iterations. Therefore, we propose a fully integrated design approach that considers kinematics, dynamics, trajectory planning, and control simultaneously in One large global search problem. Our approach is based on a genetic algorithm to which the following important modifications have been made: (1) the computational requirements have been reduced by including problem specific design knowledge in the modification and evaluation functions; (2) the computational resources are increased through an agent-based implementation that can be executed on a group of networked workstations. 3.2. Including proble.m specific design knowledge

Michalewicz [ 14] has shown that the performance of genetic algorithms can be drastically improved by including problem specific knowledge. We implemented two different mechanisms through which problem specific knowledge improves the efficiency of the search algorithm: • reduction of the search space size, • reduction of the evaluation cost of a candidate solution (i.e. fitness determination). In the context of TBD of fault tolerant manipulators, a very important reduction in the size of the search space is obtained by applying the global fault tolerant trajectory planning algorithm [22] to the trajectory planning and control subproblem. Instead of having to search for a desired trajectory, one can determine the manipulator's behavior algorithmically, resulting in a very important reduction in the size of the search space. A second important reduction in search space size is achieved by including problem specific design knowledge in the generation of candidate designs. We require that a candidate design satisfies the following three constraints: • The first and last module of a manipulator must be a base and end-effector module, respectively.

295

• Spatial fault tolerant manipulator requires seven degrees-of-freedom. • The orientation in which an axially symmetric module is mounted with respect to the previous module can be arbitrarily chosen to be zero degrees. The combination of these three constraints results again in a very significant reduction of the search space size. The second important mechanism to improve the efficiency of the search algorithm is to reduce the cost of evaluating a candidate solution. We call the approach we have implemented "progressive evaluation", because it progressively uses more and more complicated - and time consuming - tests to evaluate designs. Very often it is possible to devise a simple test for a necessary condition - if a design fails the test one can guarantee that the design does not meet the task requirements. When a design does not pass the test for a necessary condition, an estimate for the fitness of the design is generated and the evaluation is terminated. Progressive evaluation is based on the observation that it is very often possible to recognize a bad design quickly using a simple test. Here is a successive list of tests that are implemented in the TBD evaluation function: • If fault tolerance is required, test whether the manipulator is redundant. • Test whether the manipulator can reach the initial point of the Cartesian path. • If fault tolerance is required, test whether a fault tolerant joint space trajectory exists (the fault tolerant trajectory planning algorithm itself is also implemented in a progressive manner [20]). • When all these tests are satisfied, a simulation of the task execution is started to verify all the other constraints. 3.3. An agent-based design framework

To complement the reduction of the computational requirements, it is possible to increase the computational resources through an agent-based implementation of the genetic algorithm. For every new generation in a genetic algorithm, one needs to modify and evaluate each of the individuals. These modification and evaluation operations can be parallelized. However, a straightforward parallel implementation of the standard genetic algorithm would

296

C.J.J. Paredis e/al./Robotics and Autonomous Systems 21 (1997) 289-304

Destroyer

Memory with

Candidate Solutions

~..

Creation/ Evaluation | Agent j /

t

MEodificationT"~ valuation / Agent . ~

Fig. 8. Layout of the agent-based design framework.

cause load balancing problems and inefficient processor usage due to the synchronization requirements of the centrally controlled algorithm - selection of the parents for the next generation of individuals depends on the normalized fitness and therefore cannot be executed until all the individuals have been evaluated. In the current literature on parallel genetic algorithms, one can find three main adaptations of the standard genetic algorithm that avoid this centralized control: tournament selection [8], parallel sub-populations [27], and a physically distributed population with one processor per individual [ 17]. Synchronization problems can also be avoided through an agent-based implementation, where each agent corresponds to an operator rather than an individual. This approach, illustrated in Fig. 8, combines three types of agents: creation/evaluation agents, modification/evaluation agents, and destroyer agents. The agents do not communicate with each other directly, but only indirectly through a shared memory which contains the population of candidate solutions. A population manager manages the storage and retrieval of individuals of the population, but does not control the execution of the agents. The agents are fully autonomous and execute asynchronously. Their functions correspond roughly to the functional entities of the genetic algorithm. At start-up, a creation~evaluation agent generates initial candidate solutions, determines their fitness value, and places them in the population (creation of the initial population). Based on the evaluations, modification~evaluation agents select and modify candidate solutions and return them to the population (selection, mutation, and cross-over in genetic

algorithms). One major difference between this agentbased approach and the standard genetic algorithm is the way the population is managed. Rather than creating a new population in each generation based on the population in the previous generation, the algorithm does not consider distinct generations at all. Instead, the off-spring is simply added to the current population. To avoid an ever growing population, individuals with a low fitness value are destroyed by destroyer agents; this is similar to the mechanism used in (/z -tk)-Evolution Strategies [24]. Population convergence is achieved in our approach by preferably destroying the worst individuals. As a result, the framework, shown in Fig. 8, maintains the desired convergence characteristics of genetic algorithms, while, at the same time, avoiding the need for centralized control - a critical criterion for a distributed implementation. The main advantage of an agent-based framework is performance. Current day computing facilities consist of a highly networked group of powerful workstations. Many of these workstations are idle for large amounts of time. These idle cycles can be used at no extra cost to run the agents in our distributed framework. Since we are dealing with a small data structure to represent candidate solutions, the time needed to exchange data between the agents and the population manager is negligible compared to the computing time required for modification and evaluation of candidate solutions, resulting in a speed-up that is almost linear in the number of processors. An additional advantage of this agent-based design framework is its modularity. We have divided the monolithic standard genetic algorithm into functional entities that, by removing the centralized control, have become independent modules or autonomous agents. These agents are separate processes that interact only with the population manager, so that the addition of new agents does not affect the other agents. For a more in-depth discussion of the agent-based design framework together with an extensive performance analysis and examples, refer to [20].

4. Modular and reconfigurable control software As we have shown in Section 2, the two key concepts for achieving rapidly deployable hardware are modularity and reconfigurability. The same concepts

C.J.J. Paredis et al./ Robotics and Autonomous Systems 21 (1997) 289-304

297

user

from sensor X

trom sensor Y

~

iconic programs 0obs)

O

graphical interfaces

to actuator Z real-time tasks Q

subroutine calls

Fig. 9. Framework for software assembly, as implemented in Chimera and Onika (from [26]).

apply also to the software aspect of rapidly deployable systems. The development of real-time control software for sensor-based robotic systems is complicated and time-consuming To reduce this complexity, a software paradigm, called software assembly, has been proposed in the Advanced Manipulators Laboratory at Carnegie Mellon University. This paradigm combines the concept of reusable and reconfigurable software components with a graphical user interface and visual programming language, as is shown in Fig. 9. 4.1. The Chimera real-time operating system

Chimera is a real-time operating system that supports the use of reconfigurable and reusable software

components. It is founded upon the notion of portbased objects, in which the port automaton computation model of concurrent processes is combined with object-based design of software. The internal methods of a port-based object are hidden (as in object oriented programming), while communication is achieved through input, output, and resource ports (as in automata). Each object executes as a separate task on one of the processors in a distributed environment. Communication between objects is performed through a global state variable table which is stored in shared memory. The variables in this table are a union of the input port and output port variables of all the objects. The port names are used to perform the binding between the objects. Instead of

298

C.J.J. Paredis et al./Robotics and Autonomous Systems 21 (1997) 289-304

accessing the global state variable table directly, each objects uses a local copy of the table, in which only the variables used by the object are kept up-to-date. Because the global table is locked during updates, the data are always transferred between global and local state variable tables as a complete set. The result of the global state variable table mechanism is that each of the objects can execute autonomously, without blocking when another task is using a shared resource. More details about Chimera can be found in [25,26].

4.2. The Onika visual programming language

Onika is a high-level graphical interface that facilitates the use of the port-based objects created within Chimera. Onika provides manipulation, encapsulation, and sequencing capabilities for the objects at two distinct levels: high level and middle level (the low level is defined to be the coding of specific objects within Chimera). The middle-level interface allows a system designer to combine low-level software objects into object configurations, such as the one shown in Fig. 10. This level provides a "canvas" on which the user can dragand-drop object icons to interactively assemble the real-time software while it is running on the real-time

T T_

rH r

Fig. 10. An object configuration for joint space control, created at the middle level of Onika.

processing units. No knowledge of textual coding is required, but merely a good working knowledge of control theory and familiarity with control block diagrams. The configurations specified at the middle level represent particular tasks that the system designer requires to complete some higher level application. For instance, "move the robot to a point in space" could be a task accomplished by a single configuration, while making a series of moves to complete an assembly could be an application. Entire object configurations can be iconified and exported to the dictionary in the high-level interface. At the high level, which is intended for nonprogrammers and unskilled users, a storyboard is presented with a dictionary of puzzle-piece-like task icons. The task icons are shape and color coded for proper connection. They are the building blocks for the visual programming language of the high level of Onika. A user can drag-and-drop the icons onto the storyboard to create various applications. Fig. 11 illustrates the program used to execute the task in the experiments of Section 6. 4.3. R M M S control software

The port-based Chimera objects used to control the RMMS are listed in Table 1. The trjjgen, dis, and grav_comp components require the knowledge of certain configuration dependent parameters of the RMMS, such as the number of degrees-of-freedom, and the Denavit-Hartenberg parameters. During the initialization phase, the RMMS interface establishes contact with each of the hardware modules to determine automatically which modules are being used and in which order and orientation they have been assembled. For each module, a data file with a parametric model is read. By combining this information for all the modules, kinematic and dynamic models of the entire manipulator are built. After the initialization, the RMMS object operates in a distributed control mode in which the microcontrollers of each of the RMMS modules perform PID

Fig. 1l. An Onika application.

C.J.J. Paredis et al./ Robotics and Autonomous Systems 21 (1997) 289-304

299

Table 1

Chimera software module description Name

Function

Description

rmms

RMMS interface

grav_comp

Gravity compensation

Jkjac

Forward kinematics and Jacobian

dis trjjgen

Damped least-squares kinematic controller Joint trajectory generator

trjcgen

Cartesian trajectory generator

Initializes RMMS; computes and sends raw joint positions to the joint modules; receives and converts raw sensor readings Computes the gravity compensation torques based on the kinematic and dynamic manipulator models Computes the forward kinematics and Jacobian, based on the kinematic manipulator model Computes the desired joint space position according to the damped least-squares kinematic control algorithm Generates a 5th order polynomial interpolated joint space trajectory Generates a 5th order polynomial interpolated Cartesian space trajectory

control locally at 1900Hz. The communication between the modules and the host interface is at 400 Hz, which can differ from the cycle frequency of the RMMS Chimera object. Since we use a triple buffer mechanism [25] for the communication through the dual-port RAM on the ARMbus host interface, no synchronization or handshaking is necessary. Because closed form inverse kinematics do not exist for all possible RMMS configurations, we use a damped least-squares kinematic controller.

4.4. Seamless integration of simulation To assist the user in evaluating whether an RMMS configuration can successfully complete a given task, we have built a simulator. The simulator is based on the TeleGrip robot simulation software from Deneb Inc., and runs on an SGI Crimson which is connected with the real-time processing unit through a Bit3 VME-to-VME adaptor, as is shown in Fig. 6. A graphical user interface allows the user to assemble simulated RMMS configurations very much like assembling the real hardware. Completed configurations can be tested and programmed using the TeleGrip functions for robot devices. The configurations can also be interfaced with the Chimera real-time software running on the same RTPUs used to control the actual hardware. As a result, it is possible to evaluate not only the movements of the manipulator but also the real-time CPU usage. Fig. 12 shows an RMMS simulation compared with the actual task execution.

5. Synthesis of sensor-based control software using robotic skills In order to deploy a robotic system successfully in an unstructured environment, it is critical that the system can overcome the inherent uncertainty in the environment through sensor integration. However, the programming of sensor-based manipulator systems is cumbersome and time-consuming due to the extensive amount of detail which must be specified for the robot to perform a task. The programming problem can be simplified dramatically, by providing robust robotic skills, that is, encapsulated strategies for accomplishing common tasks in a specific task domain. Such robotic skills can then be used at the task level planning stage without having to consider any of the low-level details. Unfortunately, robotic skill synthesis remains an open and difficult problem. One of the open issues is skill representation. In order to be able to rapidly create new skills, it is important that the skill representation supports skill transfer so that similarities between tasks can be directly exploited. It is also important that sensing be integrated easily with action, for instance, in the form of lowlevel sensor integrated commands. Finally, at the heart of the skill synthesis problem is skill robustness, that is, the skill's ability to successfully execute despite inevitable uncertainty in task parameter knowledge during skill construction. Morrow [15] addresses these issues by introducing an intermediate command layer of sensorimotor

C.J.J. Paredis et aL/Robotics and Autonomous Systems 21 (1997) 289-304

300

Fig. 12. An RMMS configuration: simulation and hardware.

~

Task Space Low Dimensional

I

I

[

-- j L

f

--_-

~'x

\

+ __.

Sensorimotor Primitive Space

gies [15]. While a skill is a parametrized, stand-alone, robust solution to a specific task, a sensorimotor primitive is a domain-general command that can be applied to many skills within a task domain. A library of these sensor-driven commands can then be used to develop new skills quickly and robustly. For examples and a more detailed discussion of robotic skills and sensorimotor primitives refer to [ 15,16].

h Dimensional

6. Experiments

sensor space

action space

Fig. 13. Sensorimotor primitive space (from [15]).

primitives, as is shown in Fig. 13. A sensorimotor primitive is an encapsulation of sensing (processing of sensor feedback) and action (trajectories) which can form domain-general building blocks for task strate-

In this section, we compare two different RMMS configurations executing the same task to demonstrate the configuration independence of the RMMS controller and the Onika high-level programming language. The task consists of writing "RMMS" on a whiteboard, as is shown in Fig. 12. The whiteboard is positioned 0.65 m from the manipulator base and the word "RMMS" measures 0 . 2 m x 0.553 m (see Fig. 15). The whole path is 3.166m long and is traversed in 35.62 s.

C.J.J. Paredis et al./Robotics and Autonomous Systems 21 (1997) 289-304

301

q

Fig. 14. The second configuration used in the experiments.

The first of the two manipulator configurations used in this experiment is shown in Fig. 12. It has three rotational degrees-of-freedom. The first two rotation axes are horizontal and parallel to the writing surface. The third rotation axis is perpendicular to the first two. The second configuration depicted in Fig. 14 has also three rotational degrees-of-freedom. The first rotation axis is again horizontal but this time perpendicular to the writing surface. The second and third rotation axes are parallel to each other and perpendicular to the first axis. These configurations are only two of the many configurations that one can build with the five RMMS modules currently available. Taking into account the axial symmetry of the link and rotate joint module, and the functional equivalence of the three pivot modules, one can build 3520 different three degreeof-freedom manipulators and 12288 different four degree-of-freedom manipulators. In [20], the agentbased design framework, developed in Section 3, is

used to determine which of the 3520 three degree-offreedom manipulators is optimally suited to perform this task. In this section, the focus is on the actual task execution. Even though the two manipulator configurations are totally different in their kinematic and dynamic structure, they can both execute the task with the exact same Chimera and Onika programs. The Onika program shown in Fig. 11 consists of three sub-tasks: move under joint space control to the starting point; then, switch to Cartesian control and follow the Cartesian path defined in the file "RMMS.traj"; finally, switch back to joint space control and move to the home position. At the beginning of the task execution, Onika spawns all the Chimera modules listed in Table 1, but commands only the rmms, grav_comp, and trjjgen modules to start cycling. These three modules constitute the joint space control configuration. At the end of the joint space controlled sub-task, the trjjgen module turns itself off, and Onika switches to Cartesian control by commanding the fkjac, dls, and trjcgen modules to start cycling. Since the rmms and grav_comp modules appear in both the joint space control configuration and Cartesian control configuration, they continue uninterruptedly. Similarly, at the end of the "RMMS" Cartesian trajectory, the trjcgen module turns itself off, after which Onika turns theflcjac and dls modules also off, and the trjjgen module back on for the next sub-task. Fig. 15 illustrates the performance of the damped least-squares kinematic controller in combination with the distributed PID controller. The end-point error is similar for both configurations - less than 2.5 mm at any time. There are three sources of error: the damped least-squares kinematic controller, the distributed PID controller, and the incorrectly calibrated kinematic parameters. The error shown in Fig. 15(b) is based on the measured joint angles, so that it includes the controller errors but not the calibration errors. As a result, the actual end-point error will be slightly larger.

7. Summary We have developed a reconfigurable modular manipulator system which currently consists of six hardware modules, with a total of four degrees-of-freedom. These modules can be assembled in a large number

C.J.J. Paredis et al./Robotics and Autonomous Systems 21 (1997) 289-304

302

Configuration 1

Configuration 2

0.6

/

I

o.?$J-

I

\ _J

\

o.e~b

0.~

t,..-

0.1

OJ

0.1

o.2

0.3

"\

o.s[-

k...-

o•~.~

.,',

-0.1

0

y [m]

0.1

0.2

0.3

(a) 2.sx 10a

2.S

2

2

t

i

1,6

i ,

S

lO

16

i

20

time 1 ~ 1

I~ (~1

(b) 144 12(

joira2

t'~

10(

t]~%

o

-20

"

It ~ 2

~

/ ~ j\

i -x

/\j'x

t'X

I'X

. t_.

,j

./. .... ..... /

~...

...~2 ............ "....""

....................... ............. ' 'i .i'"'' ~....

l~]

(c) Fig. 15. Comparison of the same task executed by two different manipulator configurations. (a) Measured path (solid) and desired path (dotted). (b) End-point position error. (c) Joint angles.

of different configurations to tailor the kinematic and dynamic properties of the manipulator to the task at hand. A novel multi-agent design framework allows the user to determine which modules should be used to perform the current task. Once a manipulator has been assembled from the RMMS modules, the control

software automatically adapts itself to the manipulator configuration by building kinematic and dynamic models; this is totally transparent to the user. In the Advanced Manipulators Laboratory, we are also investigating the use of robotic skills to rapidly synthesize sensor-based control software for the RMMS.

C.J.J. Paredis et al. /Robotics and Autonomous Systems 21 (1997) 289-304

Acknowledgements This research was funded in part by DOE under grant DE-F902-89ER 14042, by Sandia National Laboratories under contract AL-3020, by the Department of Electrical and Computer Engineering, and by The Robotics Institute, Carnegie Mellon University. The authors would also like to thank Randy Casciola, Mark DeLouis, Eric Hoffman and Jim Moody for their valuable contributions to the design of the RMMS system.

References [1] ARCNET Trade Association, ANSI/ATA 878.1-Local Area Network: Token Bus (version 1.10). [2] B. Benhabib and M,Q. Dal, Mechanical design of a modular robot for industrial applications, Journal of Manufacturing System 10 (4) (1991) 297-306. [3] I.-M. Chen and J.W. Burdick, Determining task optimal modular robot assembly configurations, in: Proc. 1995 IEEE Int. Conf. Robot. Automat., Vol. 1 (IEEE Press, New York, 1995) 132-137. [4] R. Cohen, M.G. Lipton, M.Q. Dai and B. Benhabib, Conceptual design of a modular robot, Trans. ASME, J. Mech. Des. 114 (1992) 117-125. [5] S. Farritor, S. Dubowsky,N: Cole and J. Rutman, A systemlevel modular design approach to field robotics, in: Proc. 1996 IEEE Int. Conf. Robot. Automat., Vol. 4 (IEEE Press, Los Alamitos, 1996) 2890-2895. [6] T. Fukuda, G. Xue, E Arai, H. Asama, H. Omori, I. Endo and H. Kaetsu, A study on dynamically reconfigurable robotic systems assembling, disassembling and reconfiguration of cellular manipulator by cooperation of two robot manipulators, in: Proc. IROS'91 (IEEE Press, New York, 1991) 1184-1189. [7] M.W. Gertz and P.K. Khosla, A software architecture-based human-machine interface for reconfigurable sensor-based control systems, in: Proc. 8th IEEE Int. Symp. lntel. Contr. (IEEE Press, New York, 1993) 75-80. [8] D.E. Goldberg, K. Deb and B. Korb, Do not worry, be messy, in: Proc. 4th Int. Conf. Genetic Alg. (MorganKaufmann, Los Altos, CA, 1991) 24-30. [9] J.H. Holland, Adaptation in Natural and Artificial Systems (University of Michigan Press, Ann Arbor, 1975). [10] R. Hui, N. Kircanski, A. Goldenberg, C. Zhou, P. Kuzan, J. Wiercienski, D. Gershon and P. Sinha, Design of the IRIS facility - a modular, reconfigurable and expandable robot test bed, in: Proc. 1993 IEEE Int. Conf. Robot Automat., Vol. 3 (IEEE Press, Los Alamitos, CA, 1993) 155-160. [11] J.-O. Kim and P.K. Khosla, A multi-population genetic algorithm and its application to design of manipulators, in: Proc. IROS'92, Vol. 1 (IEEE Press, New York, 1992) 279-286.

303

[12] S. Kotosaka, H. Asama, H. Kaetsu, H. Ohmori, I. Endo, K. Sato, S. Okada and R. Nakayama, Development of a functionally adaptive and robust manipulator, in: Proc. Int. Symp. Distrib. Auton. Robot. Syst. (Springer, New York, 1992) 85-90. [13] T. Matsumaru, Design and control of the modular robot system: TOMMS, in: Proc. 1995 IEEE Int. Conf. Robot. Automat., Vol. 2 (IEEE Press, New York, 1995) 21252131. [14] Z. Michalewicz, Genetic Algorithms + Data Structures = Evolution Programs, 2nd edn. (Springer, New York, 1994). [15] J.D. Morrow and P.K. Khosla, Sensorimotor primitives for robotic assembly skills, in: Proc. 1995 IEEE Int. Conf. Robot. Automat. (IEEE Press, New York, 1995) 18941899. [16] J.D. Morrow, B.J. Nelson and P.K. Khosla, Vision and force driven sensorimotor primitives for robotic assembly skills, in: Proc. IROS'95, Vol. 2 (IEEE, Los Alamitos, CA, 1995) 90-95. [17] H. Mtihlenbein,Parallel genetic algorithm in combinatorial optimization, in: Computer Science and Operations Research (Pergamon Press, New York, 1992) 441-456. [18] S.S. Murthy, Synergy in cooperating agents: Designing manipulators from task specifications, Ph.D. Thesis, Department of Electrical and Computer Engineering, Carnegie Mellon University, 1992. [19] Y. Nakamura and H. Hanafusa, Inverse kinematic Solutions with singularity robustness for robot manipulator control, Trans. ASME, J. Dyn. Sys., Meas., Contr. 108 (1986) 163-171. [20] C.J.J. Paredis, An agent-based approach to the design rapidly deployable fault tolerant manipulators, Ph.D. Thesis, Department of Electrical and Computer Engineering, Carnegie Mellon University, 1996. [21] C.J.J. Paredis and P.K. Khosla, Kinematic design of serial link manipulators from task specifications, Int. J. Robot. Res. 12 (3) (1993) 274-286. [22] C.J.J. Paredis and P.K. Khosla, Fault tolerant task execution through global trajectory planning, Reliab. Eng. Syst. Saf (1996), to appear. [23] D. Schmitz, P. Khosla and T. Kanade, The CMU reconfigurable modular manipulator system, in: Proc. Int. Symp. Expo. Robots (IFS Publications, Kempston, 1988) 473-488. [24] H.-P. Schwefel, Numerical Optimization for Computer Models (Wiley, Chichester, 1981). [25] D.B. Stewart, Real-time software design and analysis of reconfigurable multi-sensor based systems, Ph.D. Thesis, Department of Electrical and Computer Engineering, Carnegie Mellon University, 1994. [26] D.B. Stewart and P.K. Khosla, Rapid development of robotic applications using component-based real-time software, in: Proc. 1ROS'95, Vol. 1 (IEEE, Los Alamitos, CA, 1995) 465-470. [27] R. Tanese, Distributed genetic algorithm, in: Proc. 3rd Int, Conf. Genetic Alg. (Morgan-Kaufmann, Los Altos, CA, 1989) 434--440.

304

C.J.J. Paredis et al./Robotics and Autonomous Systems 21 (1997) 289-304

C.J.J. Paredis received the M.S, degree in mechanical engineering from the Catholic University of Leuven (Belgium) in 1988, and the M.S. and Ph.D. degrees in electrical and computer engineering from Carnegie Mellon University (CMU) in 1990 and 1996, respectively. He is currently a visiting research engineer at the Engineering Design Research Center at CMU, working in the area of distributed environments for collaborative design. His research interests include modular and distributed robotics, fault tolerance, design of complex electro-mechanical systems, and evolutionary systems. H.B. Brown received his B.S. and M.S. degrees in mechanical engineering from Carnegie Mellon University in 1967 and 1976. He has worked in design and research positions with Allegheny Ludlum Research Center, McGraw-Edison Corporation and Jones and Laughlin Steel Research Lab. He spent five years as a consultant doing investigative engineering. Mr. Brown is currently a Project Scientist at the Robotics Institute where, since 1981, he has participated in a variety of research projects. Five years were with the Leg Lab, developing a sequence of one-, two- and four-legged running robots of unmatched performance. Mr. Brown is interested in the analysis, design and control of robots and electro-mechanical systems, and specializes in the development of high-performance structures and equipment. Recent research projects relate to the development of novel robots for space and lunar applications, such as the Self Mobile Space Manipulator which walks and performs inspection tasks on a Space Station mockup; and Gyrover, a single-wheel, gyroscopically stabilized rover. Current projects include the development of a high-precision (micron resolution) manipulator for the Minifactory project, and development of a long-range capacitive sensor for automated highway applications.

P.K. Khosla received both M.S. and Ph.D. degrees from Carnegie Mellon University (CMU). He is Professor of Electrical and Computer Engineering at CMU, a member of The Robotics Institute, and Director of the Advanced Mechatronics Laboratory. He recently served as a Program Manager in the Software and Intelligent Systems Technology office at DARPA where he was responsible for programs in Manufacturing and real-time software and planning. His current research interests are in the area of real-time sensor-based manipulation, reusable software for real-time control and real-time operating systems, modular manipulators, integrated design-assembly systems, and robotic applications in space, field, and manufacturing environments. Professor Khosla is a Fellow of IEEE and has served on numerous technical and conference committees. He is a recipient of the Inlaks Fellowship (United Kingdom), two NASA Class I Tech Brief Awards, and the Carnegie Institute of Technology Ladd award for excellence in research. His research has resulted in more than 100 journal articles, conference papers and book contributions.