Extending the RCCL Programming Environment to Multiple
`Robots and Processors
`
`
`
`John Lloyd. Mike Parkerl and Rick nnccraini
`
`l MtGi|i University. Research Center for Intelligent Machines. 3480 University Street, Montreal.
`Quebec. Canada
`l-l3A EAT
`
`3 RCA Advanced Technology Laboratories. Route 33. Moorestown. New Jersey
`
`D3057
`
`Abstract
`
`The Robot Control C Library (RCCL) is a system for developing robot
`control programs in a UNlX environment. and has proven to be particu-
`larly useful in research applications. This paper contains a description of
`the work presently being undertaken by the RCA Advanced Technology
`Laboratories and McGill University in expanding RCCL to handle mul-
`tiple robots, and upgrading its implementation to a multiple-processor
`n1icroVA>(/UNIX system. This includes 1)
`reworking the primitive set
`to allow for the specification of multiple robot actions. 2] modifying the
`trajectory generation mechanism so that several robots may be controlled
`and coordinated at once. and 3) redesigning the system interface on top
`of which RCCL is built to allow the creation of multiple real-time robot
`control tasks interfaced to UNIX.
`
`1.
`
`Introduction
`
`This paper presents the system work currently being done at the RCA
`Advanced Technology Laboratories (ATL].
`lvloorestown, New Jersey.
`in
`cooperation with the McGil| University Research Center for Intelligent Ma-
`chines [McRC|M} Montreal. Canada. in exploring cooperative multi—robnt
`control and programming environments. The work utilizes a microVAX
`ll/system running the Robot Control C Library {RCCLHGL which is im-
`plemented under UNIX using a set of system primitives called the Robot
`Controi Interface lRC|). which make it possible to create a real-time robot
`control task and connect it to a UNIX program.
`The mulli-robot control work at ATL is motivated by its potentiai ad-
`vantages in manipulating large objects, or performing complex tasks that
`require more than one hand
`Many of the specific applications being
`studied are directed at NASA programs for space station construction and
`maintenance. which includes the development of a multi-armed service-r
`robot
`The ATL[McGill research effort on which this paper is based is aimed
`at:
`
`O Extending the RCCL "language" to create a programming environ-
`ment for coordinated control of multiple manipulators [section 3).
`0 Providing for multi-robot RCCL by extending RCl to support multiple
`control tasks in a nrnlti-processor environment [section 4),
`0 Developing algorithms for force control and cooperative manipulator
`action based on an outer force control loop wrapped around an inner
`position control loop [11] [this work is described in
`
`2. Background: The RCCL/RCI Environment
`
`The orginal RCCL is a library of routines for describing and control-
`ling robot positions and actions. combined with a trafectorygeneratorfor
`realizing these actions [5, 10].
`It is Eargelyvan implementation of the ideas
`presented in Richard Paulis book [12]. An RCCL application program is
`written in the ”C" language and uses special primitives to specify robot
`action requests and queue them for servicing by the trajectory generator.
`The trajectory generator is a real-time background task. which does path
`interpolation and smoothing. maps from Cartesian to joint space. and
`
`CH2535-1/88/U000/0465501.00 (C) 1988 IEEE
`
`465
`
`outputs a set of joint setpoints at a ltypicai] rate around 50 Hz. Usually.
`these setpoints are fed to the mannlacturer-supplied joint
`level control
`modules of a particular robot (which execute PID control at typical rates
`of 1 I-(Hz). The task structure is hence a 3-level affair. consisting of an
`asyrrcllrorlous pfanm'.vg task (the main RCCL program). a synchronous
`lrafectorl-controltasir (provided by RCCL}. and joint-controltasks.
`(Fig-
`ure 1).
`The main program starts up RCCL with a call to rcc.I_open (1. Two
`types of routines are then available:
`
`0 Primitives used in rrrarripulntirlg coordinate frame refationslifps.
`{'5 Prirrrititres which invoke and control robot moriorrs.
`
`The first maintain coordinate frame transformations {represented in
`RCCL by the data structure type Thar‘). and position equations [type
`PBS) defined rising these transformations. Position equations are used to
`relate the value of the manipulator T6 transform to the product of other
`transforms. For example. given a WORLD coordinate frame w.r.t. robot
`linlc D. a position P w.r.t. WORLD. and a robot TOOL. transfornr.
`then
`locating the tool
`tip at the part involves satisfying the equation
`T6 TOOL
`WORLD P
`The RCCL primitive for creating positions is rnalroPosit:1'or1(). whose
`argument list is a set of transforms describing a transform equation. Tire
`position equation above would be created with a piece of code that looks
`like:
`
`TRSF Icoorci,
`transform pointers
`.'
`PBS tpos;
`! position pointer
`.
`. .in.t‘ tialize transforms. .
`.
`
`‘tool,
`
`*’p
`
`pos = :nalrePos.it1‘ortt' 1:5,
`
`tool, E0. coord, p, TL.
`
`tool}:
`
`The keyword El] denotes the two halves of the equation. while the
`keyword TL and the transform following it provide additional information
`as to where the manipulator tool frame exists. Tire ability to create general
`coordinate transform relationships is a powerful
`tool. Within the same
`equation. one transform might represent the position of a sensor. another
`might represent path corrections for compliant motion. and another might
`generate a motion path. This can be exploited within RCCL by changing
`the actual values of the transforms prior to or during motions.
`The primitive that initiates robot motion is rnovef). which takes a
`position data structure as an argument and queues a request for the trajec-
`tory generator to move the robot so that the position equation is satisfied.
`Successive 1noVo(J requests will
`travel
`through the target point; to stop
`there. the command stop (J is used. These commands do not wait until
`the motion has finished:
`that must be done using various rra.it.for()
`primitives. The motion can be controlled by setting various parameters
`such as the path generation mode [joint or Cartesian), speed.
`forces to
`exert. force limit conditions. etc.
`in addition. individual transforms in the
`target position equation can be varied by binding them to programmer de-
`fined real-time functions. which are executed in reahtlme by the trajectory
`generator. Since the target will automatically track these transforms. we
`can use this feature to create very general. dynamically changing. paths.
`While an RCCL programmer typically does not work with the trajec-
`tory generation code.
`it may be desired to work at
`that
`level
`to install
`
`ABB Inc.
`
`EXHIBIT 1038
`
`Page 1 of 5
`
`
`
`RGBOO158516
`
`Page 1 of 5
`
`

`
`
`
`-1 ll" ,
`
`'u
`
`u'_
`
`-_
`
`.ni
`
`n
`
`I
`
`-
`
`
`
`nificant part of the Mcfiill/RCA effort. and is discussed in section 4 of
`this paper.
`RCCL was originally written at Purdue University by Vincent Hay-
`ward.
`in collaboration with Richard Paul. during 1982-83.
`It was trans-
`ported to McGill University during 1934-85 [1D[, and later retargeted to
`ntlcrow-\X lls at RCA.
`the Jet Propulsion Laboratory (California). and
`McGi||
`A nilcroVAX llfVMS implementation was achieved at
`the
`NASA Robotics Laboratory. Goddard Space Flight Center. Maryland, dur-
`ing the spring of l9Bi'. All of these sites primarily use PUMA robots.
`
`3. Enhancing RCCL for Multiple Robots
`
`3.1 Nluitiple Robot Control Issues
`
`_ 1.
`
`Miilti-robot control can be considered in three ways:
`fridependent Operation. Several robots doing independent tasks at
`the same time. accomplished by running several single-robot RCCL
`programs concurrently.
`2. Synchronized Operatiori. Two or more arms are required to execute
`a single task. such as in assembly operations. A system supporting
`this must have the ability to synchronize individual arm motions. as
`in specifying that arm A must wait for arm B to move into position
`before continuing with its trash.
`3. Coordfiioted Operatioii. Several arms are interacting with a com-
`mon object. A system supporting this must provide 1) a convenient
`method of specifying relative positions amongst the arms that cor-
`respond to grasping positions of each arm on the common object.
`and 2] a method of specifying a coordinated motion that niaintalns
`the relative positions while moving the object along a desired path.
`The new RCCL priinitives described below are largely directed at this
`issue.
`
`For coordinated motion. kinematic constraints exist between the dif-
`ferent arms which the trajectory computed for each arm must satisfy.
`Forces oi interaction caused by residual position errors can then be re-
`clilced lising a method such as described in
`We ensure that the kine-
`matic constraints are satisfied by computing-a single path of niotlon for
`the object being manipulated. which the trajectories for each robot simply
`follow at some constant offset. This need is met by introducing into RCCL
`the concept of an abstract object frame. Generally. the object frame is
`rigidly attached to some physical object which is to be manipulated. An
`object frame can be ‘‘moved'' , hi Cartesian space. using the RCCL motion
`primitives: a trajectory generator will then move the object frame through
`space. By creating robot positions which incorporate this object frame.
`and maintaining the robot at these positions. we can move a real object
`attached to the object frame. Moreover. by including functionally defined
`transforms in the object frame equation. we can incorporate sensor-based
`tracking into its motion.
`3.2 Nlulti-robot Function Primitives
`
`The original! RCEL primitives for controlling a single arm generalize
`to multiple arms quite naturally.
`A muiti-robot RCCL must allow us to be able to move different
`robots. We hence give move (J an additional argument:
`a pointer to a
`new data structure [type l-t!lllIP} which denotes a particular robot and
`collects together in one place all the data associated with that robot. The
`1-Uli‘i‘IPstructure for a robot is returned by rce1_open(). which now takes
`the name of the robot and sets up a trajectory generator it:
`
`.i-iAifIF'
`
`".1'Dl‘.'l o t ;
`
`robot = .rci:.I_open( "PH!JA5EO" J:
`
`
`
`RGBOO158517
`
`Page 2 of 5
`
`
`
`that the transform "tobe solved for" no longer has to be the t5 ofa robot.
`but is arbitrary and is denoted by the keyword l'it.slllS. This permits the
`example in section 2 to be rewritten as
`
`
`
`p0 = raalcePos:ii::ia:nf TiL*lffS,
`
`tool. El}. coord, p, TL, tool);
`
`We also need to be able to create object frames. This is done using
`a special instance of the I-IAIJIP data structure:
`
`i.nurIi= may ,-
`
`obj = rcc1_open ("£lB'JECI'_,Fi?.Ai‘~!E");
`
`The object from: is essentially a virtual robot. With its own trajectory
`generator. and we can use it with most of the canonical motion control
`primitives. The only differences are that the virtual manipulator has less
`capability than the piiysical manipulator:
`it does not make any sense to
`move a generic object in "joint" mode. nor does it make any sense to look
`at its joint angles.
`The field obj-Dtrans in the object's LIANIP structure contains the
`instantaneous value of the object transform. and varies as motions are
`executed on the object. Using functionally defined transforms. we can
`force the value of obj—>trans to be determined by sensor inputs or other
`means.
`
`An object frame does not have to be connected to a robot. but it can
`be. by incorporating its transform obj-btzrar-is into a position equation
`used for moving a robot [see the example below). Since an object frame
`is not always physically attached to anything. we may wish to sometimes
`simply "put" an object frame at a (possibly time varying) position. instead
`of "nii:ivi'ng" it there. For this. we define a primitive maintain C}. which
`is a little bit like ii-love-(). except that 1] it immediately puts the object at
`the goal position. and 2)
`lieeps following the goal position until another
`action is requested on that object. The primitive can be used with robots
`as well as object frames. as long as we are careful to previously aiotref)
`to the position that we plan to maintain U. Usage of ma.1'nha.in() is
`illustrated in the example below.
`
`3.3 Task Implementation
`
`Figure 2 gives a control task diagram of the new RCCL implemented
`for a system with two arms and one object frame. Each manipulator.
`and the object frame. has a trajectory generator (iniplemeiited using an
`RC! control task). As usual.
`the planning level task is a normal C pro-
`gram which generates and queues motion requests for the trajectory tasks.
`Communication among the tasks is through shared memory. Tile trajec-
`tory tasks remove motion requests from their respective motion queues
`and then generate the intermediate setpoints that constitute a path to the
`specified goal position. which is being continuously reevaluated to take ac-
`count of functionally delined transforms. Syiiclaronlzatlon is required to
`insure that the value of the object frame transform is evaluated first. as it
`~ may be used in the position equations of the physical manipulators. The
`robot
`trajectory tasks must also do inverse kinematics to generate the
`setpoint joint angles which are transmitted to the robot controller.
`This lmplernentation uses the extended RCI primitives described in
`section -1.
`
`3.4 Dual Arm Example
`
`A brief exampie that arises in the context of satellite servicing will
`illustrate the features described. We wish to grasp a moving object with
`two manipulators and then follow it without exerting a force on it. an
`action which would be the first step in a two arm catch of a rotating
`satellite. Refer to the transform diagram in Figure 3. The 3-D location
`of the object is tracked witli a camera sensor. The sensor data drives the
`position of an object frame using a functionally defined transform. Loc.
`
`466
`
`Page 2 of 5
`
`

`
`
`
`
` TRSF rcam, rlioc;
`
`P05 *Ul:j_Pos:
`i‘dAllIP *Dbj;
`
`transforms related to object
`I
`I position equation for object
`l object frame data structure
`
`. allocate and initialize transforms and position
`
`.| Set up obj frame, and turn on its trajectory generator
`
`
`The capability of the original RCCL[UNlX interface in allowing a
`programmer to attach a simple control task to programs executing in the
`rich environment of a large operating system (UNIX) has proven very
`usefui in research and development. Driven by this success. we proceeded
`to expand this interface into an independent realvtime system package.
`capable of creating multiple control tasks. and able to take advantage of
`multiple CPUs on a common backplane.
`
`-= rcc1_open ("UBJECT_FRAf-IE");
`Uhj
`rr:c.1_cont.ro.I
`flllaj);
`
`.’ build the equation for the object frame
`
`Elbj_Pos = malcePosition (Cam, TRMIS,
`
`1’-IQ‘, Loc, TL, Tl?.M.'S).'
`
`maintain (lilbj. Cl.l:j,pos,l,‘
`
`.1 have obj frame tract:
`
`‘Lac’
`
`Next. to move the physical manipulators to grasp points defined with
`respect to the object frame. we would issue move requests to positions
`defined with respect to flbj’>trans:
`
`P03 *flbj_Pos;
`TRSF *Tool1,
`TRSF *Tool2,
`P03 #121, *p2,'
`IMNIP -rrobotl, *robot2.'
`extort: int camp1y,on.'
`‘
`
`1' position equation for obj
`rllispl, wompljrl;
`! Xforms for
`tcoorcll.
`‘Goord2. *'Disp2.
`rCo:zrply2,'
`! robots I it 2
`!pos:it.iorI eqns.
`! data streets for robots
`.' flag to turn on compliance
`
`. allocate and initialize transforms and positions
`
`! Setup robot trajectory tasks and turn them on
`
`robot! = rccl_open ("PUfvfA1"),'
`.r::c.I,_control
`(rol:otJ);
`
`robot2 = rcc1_open ("Pl.lM.?l2").'
`rcc1,,contro.t
`frobotz’);
`
`.' Now build the robot position equations
`
`ilrtibj->t1-ans,
`pi = ma1<:ePos.it:ion (TRANS. Taall. Eli. Coordl.
`Dispi. Complyi, TL. 1"oo11);
`p2 = ma£«:ePosition (TRANS. Tool2, Eli.
`l.'oord2,
`itzflbj->l:rans,
`Di.sp2. Comply2. Ti... Tool2):
`cause robot
`to follow
`Move to grasp point,
`
`tracking}-lode frobotl);
`move
`(robol:1, pl);
`
`.1
`l
`
`tracicingilode frobot2}.'
`move (robot2, p2);
`
`:ra1't_:l"or frobotl-Dcompletetflr
`sra:it_for frobotz-Dcomploted);
`
`‘fait for motions to stop
`I at grasp position
`
`comply_on = 1:
`GRASP frobotl);
`GRASP frobotz);
`
`.'
`.'
`.'
`
`start: comply functions,
`than grasp object at the
`same time.
`
`The primitive trackingi-lodef) preceding the move requests is an-
`other new feature that tells the trajectory generator to continue to track
`a position, after a motion is completed. until another motion request ap—
`pears on the move queue [instead of stopping firmly at the goal position's
`last value]. The program uses the completed liag to determine when both
`robots reach their grasp positions (remember that the move requests do
`not block]. That this will probably not happen at the same time is OK
`since the each arm will continue to track the grasp point. When the grip-
`pors are closed. a compliance algorithm is started. using a compliance
`function bound to the transforms Comply! and Gom_o1y2. which ensures
`the arms continue to foliow the object while exerting zero force.
`This program is naturally oversimplified.
`ignoring things like via
`points to control approach. transform allocation and definition. and details
`of the grasp process. The force control method for sen-oing the comply
`transforms is an issue dealt with in a separate paper (see [9]].
`
`4.1 Design Concept
`
`RCI (Robot Controllnterfacel permits .1 pmgramnier to create real
`time control
`tasks and attach them to a Uhllxfprogram. Each "task"
`comprises a function for set of functions). which are a loaded part of
`the main program. but execute asynchronously in real—time. Control of
`the tasks [r'.c-.. starting. stopping. setting up scheduling cliaracteristicsl is
`_ achieved through primitives called by the main program [also known as the
`planning task). Tasks can communicate using either shared memory or
`message passing.
`if a task is being used for robot control. it will typically
`be attached to an interrupt from either the RCl system clock or a robot
`controller. RC1 provides support for robot control by proviriing [for certain
`types of robots) a set of robot interface functions that read slate and
`feedback information back from the robot and post it in a "blackboard"
`called the lllcllrstructure, and take commands which have been issued by
`the control or planning tasks and send them oil’ to the robot.
`The design oi’
`the RCI primitives was motivated by the following
`goals:
`
`to serve as a developnlent and
`
`tasks often need to run at
`
`0 Ease of use- the system is meant
`prototyping environment.
`«:5 Extreiriefy fast operation - robot control
`rates of IUD H2 or higher.
`0 Syirclrronizedsclieduling— control tasks may need to run in sync with
`each other. so a common clock is required.
`«Ci Shared memory between tasks. — required to ensure the fastest pos-
`sible inter—tasl: communication.
`0 Message passing between tasks. — for instances where data isolation
`is important and communication speed is not.
`RC! Primitives
`
`4.2
`
`Control tasks are created and controlled by primitives called from the
`planning task.
`
`tel = rciflreate (name,
`
`cpuf-laslr)
`
`task with the given name on one of the CPUs specified
`creates a control
`by cpol-laslr. A pointer to a task descriptor is returned to be used in
`subsequent references to the task. The task is associated with a robot if
`it is given the same name as one of the robots supported by the system
`(section 4.3).
`together using the call
`All
`tasks and memory areas are deietecl
`rciclose () (deletion of individual control
`tasks is not currently imple-
`mented).
`The control functions that comprise a task are specified with
`rciGontrolF:ms (to‘, startup. fxnl.
`fxn2. release)
`
`where the arguments are pointers to functions: any of these can be de-
`clared l.lUlI.l.'.. startup and release are called once when the task is ac-
`tivated and deactivated, respectively. Two control functions [f:cn1 and
`:f:co2) are are allowed so that
`they can be interleaved with robot
`|f0
`{Figure ti].
`Creating a task does not actually turn it on (activate it): that is done
`using rcistartfhitmaslrj which starts the tasks indicated by the bit
`mask (the bit code for a task can be obtained from the task descriptor).
`Tasks are deactivated using rciRe1ease(biI:mas}r).
`
`Various planning level primitives determine how an RCI control
`is scheduled.
`
`task
`
`467
`
`Page 3 of 5
`
`
`
`RGBOO158518
`
`Page 3 of 5
`
`

`
` to execute tie control
`
`runnable.
`
`task functions at high priority when they become
`‘
`
`
`
`arbitrary event. instead of the clock, a wakeup function can be specified:
`rc:il.'lr1.Ftmct:ion (sci, n'alreup_:Funcf;i on)
`
`
`
`The task will be woken up when the li‘a1t'eLrpFunctiOn returns true.
`Once a control task is invoked. it will not be interrupted by other con-
`trol tasks until it completes. This permits simple round-robin scheduling
`for tasks on the same processor: tasks which must run concurrently have
`to be assigned different processors. A timeout mechanisnl detects rogue
`tasks which exceed their allocated time.
`
`Shared memory between tasks is set up by planning level primitives
`before the tasks are activated:
`at]
`:32
`
`rcisharedi-femory (labs-.i.1. s:i2e1.
`rcifiloballdemory flabelz. s;ize2.
`
`to‘);
`td. bitzaraulc)
`
`rcisharecii-lemory() creates a shared memory area. identified by la-
`bel. between the planning lash and the control task td. rc1‘G1oba1l'-lem-
`oryf) is similar. except
`that all
`the tasks indicated by hi tmasir have
`access to the memory. Controt
`tasks can get pointers to the memory
`with the calls gEt5‘ha.recii-!e.'nor}'(label) or gem}obaltlemoryflabel).
`The message passing primitives are quite simple and are callable from
`all tasks. They do not block.
`II
`rcjsond (sendcode. buffer. size)
`Ii
`rcilteceive (getcode. buffer. size, sender)
`
`r'Ci5'Endf) takes a message of size bytes contained in buffer and
`queues it for delivery to the task indicated by the bit mask sendcode.
`rcifleceivc-(J checks for messages anrl gets the first from any of the
`senders specified by the bit mask getccide. returning the size. The task
`descriptor of the sending task is returned in sender.
`
`A few support functions are available for control tasks. which do not
`have access to the usual UNIX system calls. These include functions
`for local memory allocation {rcfl-iallocfi and n:.i.F‘reefJl. signaling
`the planning task lrcisignal (J), and a function which prints diagnostic
`messages to the task processor console lrc1‘Prinl;f(.l].
`
`4.3 Robot Interfacing Aspects
`
`RCI rriaintains a database of robots. When a task is created which
`has the name of one of these robots, that task is connected to the robot.
`This means that RCI will 1)
`instantiate parameter blocks in the task
`descriptor with the joint ievel data for that robot and 2) automatically
`perform l/O with the robot. maintain the HDl’.’structure. and service com-
`mands for the (two) control functions that execute each control cycle
`(Figure 4), The fields in the robot parameter and new structures are de-
`lined to represent a general robot at the joint level. This includes features
`such as joint angles, velocities, torques. limits on these values, lower level
`representations such as joint encoder counts and DAC values. conversion
`routines between such representations. and calibration information. Fields
`are also available for generic sensor l/O. RCI does not. at the moment.
`maintain kinematic or dynamic robot parameters since this information
`tends to depend on the RCI application.
`
`4.4
`
`implementation Using a Set of lVlicroVAX ll CPUs
`
`it is possible to create a mlIlti«proce.ssor system consisting of [up to
`4) micro\lAX CPU boards residing on the same Q-bus. One of these. the
`arbiter. contains the bus arbitration logic. while the others are configured
`as auxiliaries. Each CPU contains floating point support and 1 Mbyte of
`local memory (this can be expanded if necessary). Communication be-
`tween CPUS is achieved by mapping segments of processor local memory
`onto the Q-bus. where it can be accessed by all processors
`This hardware capability was used to build a muiti—processor RCI
`system. where the arbiter CPU runs UNlX [and possibly some control
`
`RC! tasks can also be executed on auxiliary CPUs. The required
`CPUs are allocated by the RC1 program (The same CPU cannot currently
`be shared between different RCI programs) and are booted and loaded with
`a specialized nrfnifrernenl. This nifnfkerneflwritten at McGill University by
`Mike Parker) provides the services necessary to load and run RCI control
`tasks,
`It connnunicates with UNIX using a special UNIX device driver
`and a set of defined inter-CPU messages implemented using shared 0-
`bus memory.
`Control tasks are set up and run on an auxiliary CPU in the following
`way. Those segments of program code which are required by the control
`functions are downloaded into the processor. along with monitor code
`that provides communication with the RC! primitives and calls the control
`tasks when they are activated and become runnable. Different control
`tasks on the same CPU are pulled for readiness and executed round robin
`style. Each task runs until its functionls} return: tasks cannot presently
`interrupt each other (this capability may be added in the future if it proves
`necessary: it would require assigning priorities to tasks}.
`RCI programs maintain a separate sclieduler task which is responsi-
`ble lor waking up those tasks whicli have been set for scheduled wakeup
`with the rciflncloclrf) function. A wakeup signal is sent to the monitor
`responsible for the task. which in turn executes the task at the first oppor-
`tunity. The scheduler is maintained as a single task so as to ensure that
`scheduling profiles of different tasks are kept in sync. The scheduler uses
`the RC] system clock. which is kept on the same CPU as the scheduler
`and is available for reading (through shared memory) by all RCI tasks.
`The RCI clock can be implemented using either the 100 Hz VAX hardware
`clock. or a clock device attached to the Q-bus.
`lf a clock device is used,
`and the scheduler CPU is an auxiliary. then special arraagenients must be
`made for the clock device to interrupt the CPU through its conrmunr'ca»
`lion register‘ ([3]). since auxiliary CPUs cannot receive D-bus interrupts
`directly.
`
`5. Conclusion
`
`We have described work which is being done to create a useful muiti-
`robot programming and development environment by extending the toolkit
`already provided by the RCCL/RCI system. Our principal motivation has
`been the proven usefulness of having a full C/Ulillx environment for cre-
`ating and testing robot control algorithms at many different levels. The
`present status of our work is as follows:
`the RCI extensions have been
`completed and are running on the microVAX system. Preliminary results
`on the multi~arm work shouhi be available by the time of this conference.
`References
`
`[1]
`
`iii
`
`l3]
`
`l5]
`
`Patrick Aboussouan. "Frequency Response Estimation of Manipu-
`lator Dynamic Parameters" llvl. Eng. Thesis). Dept. of Electrical
`Engineering. McGill University, Montreal. Canada. December 1935.
`Moshe Cohen and Laeeque K. Daneshmend, "Evaluation of an Ac-
`celeration Feedback Position Control Algorithm on it Commercial Ma—
`nipulator". Submitted to the 1988 IEEE Conference on Robotics and
`Automation.
`
`Digital Equipment Corporation. KAGBD-AA CPU Modrile User's
`Guide. DEC Educational Services Development and Publishing. Marl-
`boro. lvlass. DEC Order Number El(-KAfi3Cl-UG-U01.
`
`Vincent Hayward and Samad Hayati, "Design Principles of a Coop-
`erative Robot Controller", Space Station Automation lil. Proceedings
`of S.Pl'E_ November 1987. Cambridge.
`lvlass.
`Vincent Hayward and John Lloyd, "RCCL User's Guide". Technical
`Report, Dept. of Electrical Engineering. McGill University. Montreal.
`Canada. December 1955.
`
`468
`
`
`
`RGBOO158519
`
`Page 4 of 5
`
`Page 4 of 5
`
`

`
`
`
`
`
`
`
`
`
`CDDIID I
`
`“"30"
`
`cumin 2
`
`rroaora
`
`
`
`Trajectory Control Task {SD Hz.)
`. Palh computations and smoothing
`- Solve [or T5
`. Inverse kinematics
`
`Figure 3 Translorm diagram for a nmiti-robot object
`manipulation task.
`
`
`
`
`
`RobotJointControlTasks(1KHL] |
`
`robot controller
`
`
`high Wm! fink
`
`
`
`VAX computer
`
`
`
`
`
`wait for stall
`of control rzycie
`
`
`
`
`
`
`read daaa from Ioixol
`into her variable
`
`call first user
`control function
`
`
`cali second user
`control function
`
`
`
`DC
`
`sent! commands described
`in the chg variable
`
`.
`to the robot
`
`Figure 1
`
`A typical RCCL system.
`
`Figure 4 Execution cycle for an RCI robot control task.
`
`469
`
`Page 5 of5
`
`
`RGBOO15852O
`
`
`
`Planning Lurl LI 511
`
`$1;
`
`
`
`
`
`
`-l_—_Z:l-*—l:Ze—lil%
`i'LlMM more rzurur
`drivel rum! am»!
`i".JlrlJ\i‘ mun: quvw
`
`PUMA! Cunlrul lash ' Ulnecl Control T.ulr I PUMA? Cnnirnl Task
`
`
`. run: mmgguluxons
`- so"; puem re
`. mum s.....»or...
`
`
`. Pan :nm;mnu:uI
`. so" is. omen Turrslarm
`_
`
`. rum tmnpuldllllnl
`. sou 4.. vmna: l'h
`. rn.....L....:-urn
`
`
`
`T" WM“ c°"""ll"
`
`T" Pullm C'""'"""
`
`Figure 2
`
`Task diagmn, nf 3 ,m,|t;_,0;mt RCCL 5y5[E.,,.,_
`
`COMP” I
`4+
`TOOL1
`
`5'5?‘ W5? cgMp._y 3
`I
`
`
`
`
`
`
`
`
`
`
`[7]
`
`[B]
`
`[9]
`
`[lflf
`
`Elli
`-
`
`[12]
`
`
`
`
`
`
`
`
`L. B. Holcomb and M. D. Montemerlo. "NASA Automation and
`Robotics Technology Program".
`IEEE AES lulagazine. April. 1937.
`pg. 19 - 26.
`Jin S. Lee, Samad Hayati. Vincent Hayward, and John Lloyd. "im-
`plementation of RCCL, a robot control C library on a microVAX ll".
`Advances in Intelligent Robotics Systems. SF'lE's Cambridge Sym-
`posium on Optical and Optoelectronic Engineering. Cambridge. Mas-
`sachusetts. October 26-31. 19% pp. 472 —- 430.
`Jin Lee. "Multi-Arm Coordination and Force Control Using Position
`Accommodation". submitted to the 19th Annual Pittsburgh Confer-
`ence on Modeling and Simulation. May 1988.
`Join: Lloyd. lnlpienrentatiorr of a Robot Control Devefoprnerrt En-
`viromnerrt (M. Eng. Thesis]. Dept. of Electricat Engineering. McGi|l
`University. Montreal. Canada. December 1985.
`J, A. Maples and J. J. Becker. "Experirnents in Force Control of
`Robotic Manipulators". Proceedings oHEEE Conference on Robotics
`EMU Aufonration. San Francisco. CA., April 1-10. 1985. pp. 695 - 702.
`Vol. 2
`Richard F’. Paul. Robot ll4arn'puIators.' Mathematics. Progr.rnrrrrirrg.
`and Control. MIT Press. Cambridge. Mass. 1981
`
`Planning Level Task
`(C User Prugrfim)
`- Define transforms and positions
`o Generate move commands
`
`shared mfimflfi‘
`
`mow: queue
`
`Page 5 of 5