`
`Extending the RCCL Programming Environment to Multiple
`Robots and Processors
`
`John Lloyd. Mike Parkerl and Rick McClaini
`
`l McGili University. Research Center for Intelligent Machines. 3480 University Street, Montreal.
`Quebec. Canada
`H3A 2A7
`
`1 RCA Advanced Technology Laboratories. Route 33. Moorestown. New Jersey
`
`0805?
`
`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 UlliVersily in expanding RCCL to handle mul-
`tiple robots. and upgrading its implementation to a niultipldproces‘sor
`microVAX/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 interlaced to UNIX.
`
`1.
`
`Introduction
`
`This paper presents the system work currently being done at the RCA
`Advanced Technology Laboratories (ATL). Moorestown, New Jersey.
`in
`cooperation with the McGill University Research Center for Intelligent Ma-
`chines chRClM) Montreal. Canada. in exploring cooperative multi-robot
`control and programming environments. The work utilizes a microVAX
`ll/system running the Robot Control C Library {RCCLHGL which is im—
`plemented under UNlX using a set of system primitives called the Robot
`Controi Interface (RCI). which make it possible to create a real-time robot
`control task and connect it to a UNlX program.
`The mulli-robot control work at ATL is motivated by its potential ad-
`vantages in manipulating large objects, or performing complex tasks that
`require more than one hand [4). 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 [7).
`The ATL/McGili 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-robol RCCL by extending RCl to support multiple
`control tasks in a multi-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 19)).
`
`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 Paul's 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
`
`CH2555-1/88/UOUD/0465501.00 (C) 1988 IEEE
`
`465
`
`outputs a set of joint setpoinls at a ltypicai) rate around 50 Hz. Usually.
`these setpoinls are fed to the maunlactnrer-snpplied joint
`level control
`modules of a particular robot (which execute PlD control at typical rates
`of 1 KHz). The task structure is hence a 3—level affair. consisting of an
`asynchronous planning task (the main RCCL program). a synchronous
`trajectorI-controltasit (provided by RCCL). and foinr-rontroltasks.
`(Fig-
`ure 1).
`The main program starts up RCCL with a call to rchopen 0. Two
`types of routines are then available:
`
`0 Primitives used in manipulating coordinate frame relationships.
`{5 Primitives which invoke and control robot motions.
`
`The first maintain coordinate frame transformations {represented in
`RCCL by the data structure type TRSF). 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
`link i). a position F vv.r.t. WORLD. and a robot TOOL. transform.
`then
`locating the tool
`tip at the part involves satisfying the equation
`T6 TOOL
`WORLD P
`The RCCL primitive for creating positions is maltePositiofl 0. whose
`argument list is a set of transforms describing a lranslorm equation. The
`position equation above would be created with a piece of code that looks
`like:
`
`1125‘!" Icoarci,
`transform pointers
`.'
`PBS *pos;
`l position pointer
`.
`. .ini tialize transforms. .
`.
`
`‘tool,
`
`*P
`
`pos = maltePositiortf (: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 rohnt motion is novef). which takes a
`position data structure as an argument and queues a request for the trajec‘
`tory generator to move the robot so thal the position equation is satisfied.
`Successive move (J requests will
`travel
`through the target point; to stop
`them. the command stapfl is used. These commands do not wait until
`the motion has finished;
`that must he done using various li‘ait‘forf)
`primitives. The motion can be controlled by setting various parameters
`such as the path generation mode [joint or Cartesian), speed.
`forces to
`eitert. 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 rea|»time 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.
`
`Page 1 of 5
`
`EXHIBIT 1037
`
`RGBOOl58516
`
`Page 1 of 5
`
`

`

`new features or even replace the trajectory generator completely. Workers
`experimenting with new joint-level control laws often find it convenient to
`prototype them directly inside the trajectory module and bypass level 3
`[2. 1]. At this point.
`the programmer is no longer working with RCCL.
`but with RC1. Expanding the original capabilities of RC! represents a sig-
`nificant part of the McGill/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-33.
`It was trans-
`ported to McGlll University during 1934-35 [10[, and later retargeted to
`microVAX ils at RCA.
`the Jet Propulsion Laboratory (Califomial. and
`McGill
`[B] A microVAX lIIVMS implementation was achieved at
`the
`NASA Robotics Laboratory. Goddard Space Flight Center. Maryland. dur-
`ing the spring of 193?. All of these sites primarily use PUMA robots.
`
`3. Enhancing RCCL for Multiple Robots
`
`3.1 Muitiple Robot Control ISsues
`
`_ 1.
`
`Mrrlti-robot control can be considered in three ways:
`independent Operation. Several robots doing independent tasks at
`the same time. accomplished by running several single—robot RCCL
`programs concurrently.
`2. Synchronized Operation. Twu or more arms are required to execute
`a single task. such as in assembly operations. A system supporting
`this must have the abiiity to synchronize individual arm motions, as
`in specifying that arm A must wait for arm B to move into position
`before continuing with its tasir.
`3. Coordinated Operation. Several arms are interacting with a con1~
`mon object. A system supporting this must provide 1) a convenient
`method of specifying relative positions arrrongst 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 maintains
`the relative positions while moving the object along a desired path.
`The new HCCL primitives deseribed below are largely directed at this
`lESUC.
`
`For coordinated nrotiorr. 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-
`duced lrsing a method such as described in [El] We ensure that the kine—
`matic constraints are satisfied by computing-a single path of motion 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. Generaliy. the object frame is
`rigidly attached to some physical object which is to be manipulated. An
`object frame can be “moved" , in 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 functionaliy defined
`transforms in the object frame equation. we can incorporate sensor-based
`tracking into its motion.
`3.2 Multi—robot Function Primitives
`
`The original RCCL primitives for controlling a single arm generalize
`to multiple arms quite naturally.
`A multi-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 i-MHIP} which denotes a particular robot and
`collects together in one place all the data associated with that robot. Tire
`IrAr‘JIPstructure for a robot is returned by rchupenO. which now takes
`the name of the robot and sets up a trajectory generator it:
`
`HANIF "rob o t ;
`
`robot = rccl_open( "PHIJAESO" J:
`
`These simple additions, plus the recently added routines for motion
`synchronization (the event fiag mechanism described in Chapter 5 of [10!)
`give us everything we need to do synchronized motions of multiple robots.
`Coordinated robot motion and object frames require a bit more en«
`hancement. First. we generalize maitePositjon 0 [section 2] slightly. so
`that the transform "to be solved for" no longer has to be the t5 ofa robot.
`but is arbitrary and is denoted by the keyword TRANS. This permits the
`example in section 2 to be rewritten as
`
`p0 = maltoPositianf TRANS,
`
`tool. El}. coord, p. TL, tool);
`
`We aiso need to be able to create object frames. This is done using
`a special instance of the MINI? data structure:
`
`name we; .-
`
`obj = rccl_open ("UBJECLFRAHE");
`
`The object frame 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 physical manipulator:
`it does not make any sense to
`move a generic object in "joint" nrode. nor does it make any sense to look
`at its joint angles.
`The field obj-Dtrans in the object's MANIP 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—>transr 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—Duran: 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 "moving" it there. For this. we define a primitive maintain O. which
`is a little bit like nave-f). except that 1] it immediately puts the object at
`the goal position. and 2) heaps 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 .aovef)
`to the position that we plan to maintain”. Usage 0f maintainO i5
`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 (implemented 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. The 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 defined transforms. Synchronization 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 implementation uses the extended RCI primitives described in
`section 4.
`
`3.4 Dual Arm Example
`
`A brief example that arises in the context of satellite servicing will
`illustrate the features described. We wish to grasp a movlng 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 with a camera sensor. The sensor data drives the
`position of an object frame using a functionally defined transform. Loc.
`
`466
`
`Page 2 0f5
`
`RGBOOi 58517
`
`Page 2 of 5
`
`

`

`which is constantly updated with new locations of the object relative to
`the camera coordinate frame. A frame Lo: is set up describing this object.
`TRSF *L‘am. *Loc;
`P05 *Ubjj’os:
`J‘MNIP *Dbj;
`
`transforms related to object
`I
`I position equation for object
`.' object: frame data structure
`
`. allocate and initialize transforms and position
`
`.I Set up obj frame, and turn on its trajectory generator
`
`Dbj = rcc1_open ("DBJECT_FRAr‘-!E");
`rccl_cantrol
`(Ubj);
`
`.’ build the equation for the object frame
`
`Elbj_Pos = make-Position (Cam, TRANS, so, Loc, TL, TIMI-'5):
`
`maintain (libj. Ubj_pos);
`
`.1 have obj frame tract:
`
`'Loc'
`
`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 flbjc>transz
`
`." position equation for obj
`P03 *Ubjj’os;
`TRSF *Tooll, *Coordl. *‘Diapl.
`i*‘lfr'omplyl:
`! Xforms for
`TRSF *ToolZ.
`‘Goord2, *Dispz.
`‘ComplyQ;
`! robots I a 2
`P03 #121, *p2,’
`!position eqns.
`MANIP *robotl. *rabotB:
`! data structs for robots
`exhorn int comply,on:
`‘
`.' flag to turn on compliance
`
`. allocate and initialize transforms and positions
`
`.‘ Setup robot: trajectory tasks and burn them on
`
`robot! = rccl_open ("Furor");
`.rchcontrol
`(robotl);
`
`robot2 = rchopeo ("PUfiLdQ");
`rccl,control
`frobotZ);
`
`I Now build the robot position equations
`
`rttibj-I'trans.
`p1 = makoPosition (TRANS. T0011. Eli. Coardl.
`Dispi, Complyi, TL. Tool”;
`p2 = makePosition (TRANS. ToolB. Ell. L'oord2,
`fizflbj-J'trans,
`DispZ. ComplyE. TL, ToolZ}:
`
`trackingl-lode (robotl);
`move (robotl, pi);
`
`trackingl-lod'e (subsoil):
`move (robot2, p2);
`
`to follow
`.1 cause robot
`i Move to grasp point.
`
`v'ait-for {robotl-Dconpleted):
`h'ait_for (robotZ-Dcompletod);
`
`‘fait for motions to stop
`! at grasp position
`
`comply_on = 1:
`GRASP (robotl);
`GRASP (robotiz);
`
`.‘ start: comply functions,
`.'
`than grasp object at the
`.' some time.
`
`The primitive trackingf-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 flag 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 some time is OK
`since the each arm will continue to track the grasp point. When the grip—
`pers are closed. a compliance algorithm is started. using a compliance
`function bound to the transforms Comply! and GomplyZ. which ensures
`the arms continue to follow the object while exerting Zorn 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 servoing the comply
`transforms is an issue dealt with in a separate paper (see [9]].
`
`4. RCl: Primitives for Creating and Handling
`Real-Time Control Tasks
`
`The capability of the original RCCLI‘UNIX 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.
`
`4.1 Design Concept
`
`RC! (Robot Controllnterfacel permits a programmer to create real
`time control
`tasks and attach them to a UNIXprogrem. Each “task"
`comprises a function [or set of functions). which are a loaded part of
`the main program. but execute asynchronously in real—time. Control of
`the tasks [i.e.. starting. stopping. scttlng up scheduling characteristics) 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. RCl provides support for robot control by providing [for certain
`types ol robots) in set of robot interface functions that read slate and
`feedback information back from the robot and post it in a "blackboard"
`called the Hoh'structure, and Lake commands which have been issued by
`the control or planning tasks and send them off to the robot.
`The design oi the RCI primitives was motivated by the following
`goals:
`
`to serve as a development and
`
`tasks olten need to run at
`
`0 Ease of use— the system is meant
`prototyping environment.
`«1" Extremely fast operation ~ robot control
`rates of 100 Hz or higher.
`0 Synchronizedscheduling— control tasks may need to run in sync with
`each other. so a common clock is required.
`‘5‘ Shared memory between tasks. - required to ensure the fastest pos-
`sible inter-task communication.
`4) Message passing between tasks. — for instances where data isolation
`is important and communication speed is not.
`RC! Primitives
`
`4.2
`
`Contra! tasks are created and controlled by primitives called from the
`planning task,
`
`to = IciGreate (name.
`
`cpur-laslr)
`
`task with the given name on one of the CPUs specified
`creates a control
`by cpol-Iaslr. A pointer to a task descriptor is returned to he used in
`subsequent references to the task. The task is associated with a robot it”
`it is given the same name as one of the robots supported by the system
`(section 4.3).
`All
`tasks and memory areas are deleted together using the call
`:ciGlose () (deletion of individual control
`tasks is not currently imple-
`mooted).
`The control functions that comprise a task are specified with
`rciGontrolFms (to‘, startup. rm. fxn2. release)
`
`where the arguments are pointers to functions; any of these can be de-
`clared HULL. startup and release are called once when the task is ac—
`tivated and deactivated, respectively. Two control functions [fxnI and
`:fm2) are are allowed so that
`they can be interleaved with robot
`IfO
`{Figure 4].
`Creating a task does not actually turn it on (activate it): that is done
`using rcifi'tartfhitmaslr) 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 rcifleleaset'bitmasir).
`
`Various planning level primitives determine how an RCI control
`is scheduled.
`
`task
`
`467
`
`Page 3 of 5
`
`RGBOO158518
`
`Page 3 of 5
`
`

`

`tasks], while the auxiliary CPUs are used exclusively for running control
`tasks.
`
`RCl tasks can be run on the arbiterCPU in the same way that the
`original RCCL/UNIX interface worked:
`a special device driver is used
`to execute the control
`task functions at high priority when they become
`runnahle.
`‘
`
`RCl 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 difierent RCI programs] and are booted and loaded with
`a specialized nrfnikernef. This mlnflremeflwritten at McGill University by
`Mike Parker] provides the services necessary to load and run RCl control
`tasks,
`It communicates 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 polled for readiness and eXecuted round robin
`style. Each task runs until its function(s} 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 scheduler task which is responsi-
`ble for waking up those tasks which have been set for scheduled wakeup
`with the rciflnCIockf) 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. Tire 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 RCl tasks.
`The RCI clock can be implemented using either the 100 Hz VAX hardware
`clock. or a clock device attached to the Q-bus.
`if a clock device is used,
`and the scheduler CPU is an auxiliary. then special arrangements must be
`made for the clock device to interrupt the CPU through its communion
`[ion 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/UNlX 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 runlti~arm work should be availabie by the time of this conference.
`References
`
`ll]
`
`Patrick Aboussouan. "Frequency ResponSe Estimation of Manipu-
`lator Dynamic Parameters" (M. Eng. Thesis). Dept. of Electrical
`Engineering. McGill University, Montreal. Canada. December 1935.
`(2] Moshe Cohen and Laeeque K. Daneshmend. "Evaluation of an Ac-
`celeration Feedback Position Control Algorithm on a Commercial Ma—
`nipulator". Submitted to the 1988 IEEE Conference on Robotics and
`Automation.
`
`l3]
`
`Digital Equipment Corporation. KAGBD—AA CPU Module User's
`Guide. DEC Educational Services Development and Publishing. Marl-
`boro. Mass. DEC Order Number EK-KAG3D—UG-UDI.
`
`Vincent Hayward and Samad Hayati. "Design Principles of a Coop-
`erative Robot Controller", Space Station Automation lil. Proceedings
`of SPl'E. November 1987. Cambridge. Mass.
`Vincent Hayward and John Lloyd, “RCCL User's Guide". Technical
`Report, Dept. of Electrical Engineering. McGill University. Montreal.
`Canada. December 1955.
`
`[5]
`
`Page 4 0f5
`
`RGBOO158519
`
`To run a task off the common clock.
`
`rcianClock (tel, interval. offset)
`
`notifies the RC] scheduler to wakeup the task referenced by to once every
`interval railiisecouds. offset by a certain amount. To run a task off some
`arbitrary event. instead of the clock. a wakeup function can be specified:
`rciflnFmrction ('td, rralreup_:functi on)
`
`The task will be woken up when the iraifeupFunccion 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 mechanism detects rogue
`tasks which exceed their allocated time.
`
`Shared memory between tasks is setup by planning lewd primitives
`before the tasks are activated:
`at]
`:32
`
`rciSharedZ-fenrory (labell. sizel.
`rciGlobalMemory (labelQ. size2.
`
`td);
`td. bitmaslr)
`
`raiSharedi-lemoryO creates a shared memory area. identified by 1e-
`bel. between the planning lash and the control task td. rciGloballliem-
`oryf) is similar. except
`that all
`the tasks indicated by hi cmasir have
`access to the memory. Control
`tasks can get pointers to the memory
`with the calls getfi‘haredr-remory(label) or getGlobalhlenroryflabel).
`Tlle message passing primitives are quite simple and are callable from
`all tasks. They do not block.
`rchend (sendcode. buffer. size)
`rcifleceive fgetcode. buffer. size, sender)
`
`nI
`
`!
`
`rcifi'endf) takes a message of size bytes contained in buffer and
`queues it for delivery to the task indicated by the bit mask sendcode.
`rcifleceivef} checks for messages and gets the first from any of the
`senders specified by the bit mask getcode. 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 (rcjttallocfi and rchreefJ]. signaling
`the planning task (rcisignal U], and a function which prints diagnostic
`messages to the task processor console (rciPz-intffjj.
`
`4.3 Robot interfacing Aspects
`
`RCI maintains 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 ievol data for that robot and 2] automatically
`perform [/0 with the robot. maintain the flflli‘structure, and service corri—
`mands for the (two) control functions that execute each control cycle
`(Figure 4], The fields in the robot parameter and new structures are de-
`fined to represent a general robot at the joint level. This includes features
`such as joint angles, velocities, torques. limits on these values, lower levei
`representations such as joint encoder carrots 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 lnformation
`tends to depend on the RCl application.
`
`4.4
`
`implementation Using a Set of lVlicrOVAX If CPUs
`
`it is possible to create a multinprocessor system consisting of (up to
`4) microVAX 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 l 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 [3].
`This hardware capability was used to build a mold—processor RCI
`system, where the arbiter CPU runs UNlX (and possibly some control
`
`468
`
`Page 4 of 5
`
`

`

`Planning Lent is all
`
`
`
`
`fluted mm,
`
`PUP-Ml Cunlrul task I Object Control Tull I PUMA? Cnnlrnl Task
` - Invent hmzmAI-u
`
`o Std-z lo- I‘UMAI Ht
`
`T" PUMA] cmwu"
`T" PUMA? c"'"'"""
`
`“1:39am
`l'uMM mm nun-r
`mm mm! amp.
`but“: mu“ guy“
`
`. tun: thmpullhans
`. Sat" |_ [quflrl IT;
`
`. Par :nmpunuml
`. 5d" 1m DMKI Tumlprm
`
`. rum (mputatwm
`- III-cur Immllll
`
`Figure 2
`
`Task diagram of a rnulti-robot RCCL system.
`
`Q
`
`orsr COMPLY 2
`i
`
`‘
`
`eoMPLv 1 DISH
`4+
`TOOLI
`
`
`
`PUMA 1
`
`HOBOYI
`
`PUMA 2
`
`coonoz
`
`noaorz
`
`Figure 3 Translorm diagram for a multivrobot object
`manipulation task.
`
`. Inverse kinematics
`
`[7]
`
`[B]
`
`[9]
`
`I6] Vincent Hayward and Richard Paul, "Robot Manipulator Control Un~
`tier UNEX: RCCL. a Robot Control C Library~
`International Journal
`offi’obotics Research, Winter. pp. Del — 111
`(Vol. 5. No.
`ll]
`L. B. Holcomb and M. D. Montemerlo, “NASA Automation and
`Robotics Technology Program".
`IEEE AES Magazine. April. 1937.
`pg. 19 - 26.
`Jin S. Lee. Samad Hayati. Vincent Hayward. and John Lloyd. "lm-
`plementation of RCCL, a robot control C library on a microVAX ll".
`Advances in Intelligent Robotics Systems. SPlE’s Cambridge Sym-
`posium on Optical and Optoelectronic Engineering. Cambridge. Mas-
`sachusetts. October 26-31. 1936 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. Implementation of a Robot Control Derrefopment En-
`vironment (M. Eng. Thesis]. Dept. of Electrical Engineering. McGill
`University. Montreal. Canada. December 1985.
`J, A. Maples and J. J. Becker. "Experiments in Force Control of
`Robotic Manipulators". Proceedings OHEEE Conference on Robotics
`and Automation. San Francisco. CA.. April 1-10. 1985. pp. 695 - 702.
`(Vol. 2}
`[12] anglccllgr"; Pl P'Gfl; 3:302? Egjtffilfii‘éatarflfl:[hfégitici Programrm'ng.
`r ro.
`.
`ge.
`..
`
`[16;
`
`[11!
`.
`
`Planning Level Task
`(C User Program)
`- Define transforms and positions
`0 Generate move commands
`
`shared mflmflf)‘
`
`Trajectory Control T35“ {SD “1-)
`. Path computations and smoothing
`- Solve [or T5
`
`VAX computer
`
`
`high Speed link
`
`RobotJointControlTasks(1Kile] I.
`
`robot controller
`
`
`
`wait for start
`
`react data from total
`into hour variable
`
`call first user
`control function
`
`calt second user
`control function
`
`
`
`of control cycle
`
`
`
`
`
`
`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 0f5
`
`RGBOO158520
`
`Page 5 of 5
`
`