`
`David J. Miller and R. Charleene Lennox
`
`An objectvoriented Robot Independent
`Programming Environment (RIPE) developed
`at Sandia National Laboratories is being used for
`rapid design and implementation of a variety of
`applications. A system architecture based on
`hierarchies of distributed multiprocessors
`provides the computing platform for a layered
`programming structure that models the applica-
`tion as a set of software objects. These objects
`are designed to support model—based automated
`planning and programming, real—time sensor—
`based activity, error handling, and robust
`communication. The object—oriented paradigm
`provides mechanisms such as inheritantc and
`polymorphism which allow the implementation
`of the system to satisfy the goals of software
`reusability, extensibility, reliability, and por—
`tability. By designing a hierarchy of generic
`parent classes and device-specific subclasses
`which inherit the same interface, a Robot Inde—
`pendent Programming Language (RIPL) is real?
`ized. Work cell tasks demonstrating robotic cask
`handling operations for nuclear waste facilities
`are successfully implemented using this object—
`oriented software environment
`
`Introduction
`
`The Robot Independent Programming En-
`vironment (RIPE), developed at Sandia National
`Laboratories, is an object-oriented approach to
`robot system software architectures. The
`primary accomplishmentofthe RIPE effort is the
`achievement of a software environment which
`facilitates the rapid design and implementation
`of complex robot systems to support diverse
`research efforts and applications. RIPE allows
`robot system developers to concentrate on algo—
`rithm design and optimization, as well as testing
`and evaluation ofnew control, sensing, comput—
`
`
`Conference on Robotics andA ummatiori, Cin—
`cinnati, 0H, Aug. 13-16, 1990. The authors
`are with Sandia NationalLaboratories. Albu-
`querque, NM. This work was supported by the
`U. S. Department of Energy under Contract
`DEPAC04—76DP00789.
`
`74
`
`ing, and communications technologies
`without having to focus on overall system
`software development and integration. This is
`achieved by modeling the robot system as a
`set of software classes. As a result, RIPE hides
`device integration details and provides
`uniform interfaces to all objects in the system.
`A separation of concept from implementation
`characterizes RIPE’s software classes and
`provides software reusability, extensibility.
`reliability, and portability
`In the following sections, the problems as-
`sociated with complex robot software systems
`(which we have experienced first hand) are
`reviewed, together with past approaches dealing
`with these problems. We then discuss the under—
`lying object—oriented concepts and distributed
`computing architecture upon which RIPE is
`based. RIPE currently supports automatic mo—
`tion planning and programming of robotic and
`machining devices based on models of the en?
`vironrnent, sensor—based control, error handling,
`and robust communication. The RIPE architec-
`ture also supports development of advanced
`software concepts such as graphical interfaces
`for robot system control.
`The detailed design of RIPE is then defined,
`followed by a discussion of two implementa—
`tions involving robotic cask handling operations
`for nuclear waste facilities. These systems show
`how the class hierarchy, consisting of generic
`parent classes and device—specific subclasses
`sharing the same interface, results in a Robot
`Independent Programming Language (RIPL).
`Finally, a brief discussion of error handling and
`additional future work is presented.
`
`Current Approaches to Robot
`Software
`
`Sandia is currently developing robot systems
`for applications including hazardous material
`handling, automated assembly, and robotic edge
`finishing. Supporting this work are research
`laboratories investigating controls and optimiza-
`tion,
`telerobotics, grasping and dexterous
`manipulation, vision,
`tactile and proximity
`sensing, path planning and collision
`
`0272~l708l91/0200-0014 $01.00 © 1991 IEEE
`
`avoidance, oscillation damped movement,
`autonomous vehicles, flexible arms, and sirnula—
`tion. The diversity of Sandia's robotics effort
`implies that the software environment must sup
`port a wide variety of requirements and devices.
`It also must serve users with different levels of
`expertise in robot system programming.
`
`The Problems
`
`As our robotics effort has developed we have
`experienced many of the problems common to
`robot programming Some of the problems are
`1) the inability of robot languages to handle
`integration of sensors into the motion control
`system,
`2) the difficulty of extending application
`codes to include new tasks or new devices.
`3) thc high expense of application program-
`ming,
`4) the small amount of code that is reusable
`for new systems,
`5) the focus on manipulator—level rather than
`on taskelevel programming,
`6) the management of system complexity,
`7) the time consuming process of writing and
`debugging low-level (e.g. communication)
`software before beginning to test new algo-
`rithms,
`8) the need for real—time control of mechani-
`cal devices,
`9) the necessity of implementing robust error
`handling and recovery code.
`
`It has been our experience that software
`development costs are a significant part of the
`overall
`intelligent robot system development
`costs. Finding solutions to robot software
`problems reduces these costs and thereby in—
`creases the viability of using intelligent robot
`systems in applications where it was once con—
`sidered too costly.
`
`Other Approar'hes to Solving the Problem
`
`Various approaches have been used to try
`to solve these problems. Vendor supplied
`
`IEEE Control Systems
`
`ABB Inc.
`
`EXHIBIT 1038
`
`Page 1 of 10
`
`RGBOO158033
`
`Page 1 of 10
`
`

`

`robot programming languages have been en—
`hanced to provide extended sensor
`capabilities, real~time path modification, and
`user-friendly interfaces. VAL-II [18] and
`AML/X [14] are examples of such languages
`which have evolved until
`they resemble
`general—purpose, high-level computer lan-
`guages. However, applications written in
`these languages are specific to the vendor’s
`robot and, therefore, are not portable.
`One approach is to replace the robot con
`trol system with a new control system em—
`bedded within an existing operating system,
`written in a general purpose language, and
`using primitive functions included in alibrary.
`RCCL [6] and KALI [l ], for example, provide
`such intermediate level robot control primi—
`tives. These primitives can be called by off—
`line programming systems and can provide an
`environment for research into control and
`optimization algorithms. Frequently neither
`RCCLno’r KALI is a viable option for industry
`work cells or research labs because they re-
`quire knowledge of complex robot trajectory
`planning and systems programming.
`In attempts to move beyond manipulator—
`level programming of basic robot motions in
`a three-dimensional work space, task-level
`languages such as AUTOPASS [9] andLAMA
`[l 1] were defined. They were somewhat
`premature and were never fully implemented
`due to the unsolved subproblems of grasp
`planning, path planning, and fine motion plan-
`ning [8]. However, it is generally agreed that
`task-level languages are needed to solve the
`problems relating to the expense and'com—
`plexity of robot system programming.
`A number of the more recent approaches
`[7], [19], [20] use conventional programming
`languages to help solve the problems of sys-
`tem complexity, real—time constraints, sensor
`integration, and modeling. These approaches
`have the advantages gained by using a lan-
`guage which is reliable, well—supported, port-
`able, and familiar. In addition,
`these
`approaches focus on the total work cell system
`rather than only on the robot. The drawback is
`that, to date, the software has often been single
`purpose and not easily extended to other ap—
`plications.
`
`Approachfor RIPE
`
`RIPE was developed to support model-
`based automated planning and programming
`of robotic and machining devices, integration
`of sensor technologies. development of next
`generation robot system programming lan-
`guages with graphical interfaces, error han-
`dling, and robust communication. It is built
`upon well—established software operating sys-
`
`February 1991
`
`’T' W ,
`
`, W. F...
`
`tems and programming languages. RIPE is an
`environment for complex system integration
`which stresses use of off-the—shelf hardware
`(e.g. conunercial robots) where appropriate as
`well as providing support for advanced system
`development.
`Computing Architecture. The RIPE
`computing architecture consists of a hierarchi-
`cal multiprocessor approach which employs
`distributed general and special purpose
`processors. This architecture provides the
`computing power required by the RIPE
`software to control complex diverse subsys-
`tems in real—time while coordinating reliable
`communications between them. Advances in
`microprocessor technology allow general pur—
`pose processors to achieve the computing per-
`formance required by complex robot control
`algorithms while remaining compatible with a
`large base of existing software.
`Object-Oriented Design. Central to the
`design of RIPE is object-oriented program-
`ming. Object—oriented design results in
`software architectures based on the objects
`that comprise a system and its environment
`rather than on the functions it performs [12].
`Robot systems perform actions on certain ob-
`jects within a defined work space. The
`software controlling the robot system can be
`viewed as an operational model of the world
`in which the robot exists. Therefore, RIPE is
`organized around representations of the ob-
`jects in the work space so that its structure
`reflects the physical structure of the system.
`Controlled complexity is achieved by creat-
`ing, combining, and manipulating software
`objects instantiated from previously defined
`software classes to perform the specific tasks
`of the system.
`Object-oriented programming is based on
`the concepts of abstract data types. classes.
`objects, generic operations, message passing,
`type hierarchies/inheritance, and polymor-
`phism [12]. Applying these concepts to RIPE
`results in modularity, encapsulation, abstrac—
`tion, and information hiding. Abstract data
`types, classes, and objects allow the designer
`to model the physical robotic work cell entities
`in RIPE by defining only their attributes, be
`havior, and interfaces. Examples of such en-
`tities include work pieces or parts with
`geometric attributes, devices (e.g. NC
`machines, fixtures, machine tools,
`tool
`changers, robots, grippers, other end effec-
`tors), and sensors for contact switches, force
`control, and vision.
`Since the software classes in RIPE are
`defined to represent the physical objects that
`are commonly found in a work cell, the com-
`munication interfaces to these generic
`software classes in RIPE become the general
`
`device independent language used to program
`the cell. This is achieved by applying the
`concept ofpolymorphism. Polymorphism (in-
`herent in the object-oriented programming en-
`vironment of RIPE) enables objects of a
`generic parent class and objects of its device-
`specific subclasses to receive the same mes-
`sages and respond to them appropriately. The
`device independent programming language in
`RIPE resulting from object-oriented design of
`robotic work cells is RIPL.
`Separating robot system concepts from the
`actual RIPE implementation results in robot
`system software which is reusable, extensible,
`reliable, and portable. RIPE’s reusability is the
`basis for the design process. Extensibility is
`provided in RIPE by defining new software
`classes which in tum become part of the
`general work cell programming language. Use
`of inheritance to define subclasses which are
`extensions or restrictions of RIPE parent clas-
`ses greatly lowers the cost and complexity of
`software development. System reliability is
`enhanced by reusing well-defined RIPE ob-
`jects, and portability is realized because RIPE
`classes are tightly encapsulated and relatively
`independent of their environment.
`
`The Development Environment. Our
`development environment for RIPE has four
`primary layers: task—level programming, su—
`pervisory control, real-time control and device
`drivers. The choice of software at each layer
`is influenced by the primary requirements for
`modeling, sensing, and motion specification,
`as well as the widely acknowledged levels of
`robot software (task, manipulator, servo) [2],
`[21]. In addition, there is a strong relationship
`between the architecture employed at each
`particular layer and robot performance re-
`quirements.
`The first layer is synonymous to what is
`generally referred to as task-level program-
`ming. At this level, world modeling, planning,
`and simulation are performed. Currently, this
`layer is in the initial stages of definition in our
`architecture.
`
`The second layer is the supervisory control
`layer implemented on a UNIX-based worksta—
`tion. This layer contains the primary control
`programs which coordinate all devices and
`activities of the system. UNIX is used by this
`layer because it provides a rich set of software
`development tools, is a mature operating sys
`tem with emerging standards, and is available
`on almost all computers. The C++ language
`[16] is used to implement the object-oriented
`work cell class hierarchies and the supervisory
`code which manipulates these classes. C++ is
`a standard high level language which offers all
`the necessary features for object-oriented
`
`15
`
`Page 2 of 10
`
`RGBOO158034
`
`Page 2 of 10
`
`

`

`Cask-Head
`
`Face Plate
`
`Air Wrench
`
`Aws Lifting Shoe
`
`Micro Switch
`
`Gas Sampler
`
`Torque Sensor
`
`
`Fig. I . Cask head work cell class hierarchy.
`
`programming. Because C++ is a superset of C,
`a large existing base of C code is used, and all
`of the advantages of C programming are
`retained (portability, versatility, and systems
`programming facilities).
`The third layer in the programming
`environment handles reaHime control of
`devices for tasks such as force control. This
`layer consists of multiple VME—based 68000
`family processors on a backplane network
`running the VxWorks operating system [22].
`VxWorks was selected because of its real—time
`kemel,
`full—featured development and run-
`time environments, and its compatibility with
`UNIX. In addition, VME—based global
`memory and VxWorks semaphores allow irn—
`mediate access to sensor data, and coordina-
`tion of robot and sensor object methods which
`may be executing on multiple CPU’s. C++
`runs effectively in this environment, and
`therefore, the same software can be used both
`at the workstation level and the real-time C0117
`trol layer. An Ethemet—based local area net—
`work ties together the workstations and VME
`systems.
`The bottom layer contains the device
`drivers for each subsystem in a work cell.
`Some device drivers are relatively simple and
`consist of interfacing commands for tasks
`such as controlling a bar code reader. Others
`are sophisticated programming environments,
`such as the CIMCORP XRlOO gantry robot
`
`l6
`
`software system. It is often more practical and
`efficient to utilize the vendor-supplied pack—
`aged software rather than attempt to create a
`new language and external interface. How-
`ever, RIPE objects can use KALI or RCCL
`based commands to communicate with spe»
`cialized controllers as well.
`
`In the case of intelligent devices such as
`robot controllers, a monitor program located
`at the controller for the dev1ce is written in the
`robot programming language. This monitor
`establishes communication with an external
`host CPU, waits foracommandfrom that host,
`carries out the command when one is received,
`and then waits for the next command. The host
`may send the command in a format which is
`directly executable by the robot controller
`(such as a VAL-II statement), or it may send a
`command code which triggers a subroutine
`call in the monitor. The monitor is treated as
`the part of a distributed robot object which
`resides on the robot controller. The messages
`that it understands and interprets are defined
`in the robot class and frequently have a one-
`to—one correspondence with the user interface
`routines defined for the robot class.
`
`Definition of Robot Systems in RIPE
`
`The design of RIPE is based not only on
`our goals of ease of use, expressiveness,
`extensibility, and reusability but also on
`
`compatibility with FACvSIM [5], a simulation
`system developed at Sandia for the analysis of
`robot systems. The panitioning of a system into
`classes is fairly straightforward since most clas-
`ses reflect the physical objects ofthe application.
`The software classes which do not represent
`physical objects are termed "virtual objects" and
`include CommunicationHandler, World-
`Modeler, Errorllandlen TrajectoryGenerator
`and PathPlanner.
`
`The Generic Objects
`
`The class inheritance hierarchies in RIPE are
`designed to allow the programming of tasks
`using generic classes. Figs. 1 and 2 illustrate two
`example system hierarchies. In the Cask Head
`Work Cell, aCincinnati Milacron robot performs
`leak detection and gas sampling operations on
`the head of a cask containing nuclear waste. In
`the Radiation Survey Work Cell, contamination
`surveys of the cask are performed by a GM-
`CORP gantry robot. The division of a robot
`system into the three basic classes of WarkPiece,
`Station and Device is derived from the concept
`that devices carry out actions on workpieces, and
`stations are locations in the work space for stor—
`ing these devices or work pieces. The definition
`of the class hierarchy for WorkPiece and Station
`is specific to an application, but each work cell
`has several kinds ofdevices, e.g. robots, sensors,
`grippers, and other tools. All devices which carry
`out actions are derived from the parent class
`Device. Instead of. or in addition to a
`manipulator, a system might employ other
`devices such as an NC machine, a conveyor, a
`remotely controlled fork lifi, or a mobile robot.
`These have the property of being able to move
`or transport a work piece or a tool and thus,
`derive from the Transportclass. Tool is the parent
`class of any object used by the robot to perform
`a task. Grabber has the attribute of being used to
`pick up work pieces or other tools. Grippers,
`hands, face plates, and hooks are instances of the
`Grabberclass. AScnsor is a Tool which provides
`data for the performance of the task. Besides
`force sensors, vision systems, and proximity
`sensors, examples of the Senior class would be
`a barcode reader used for identification of a work
`piece, a contact switch which verifies the
`presence of a tool in its station, or a gas sampling
`device. A tool, such as an air wrench, which is
`not an instance of the Grabber or Sensor class,
`derives directly from the Tool class.
`Each subclass of Device which is also a
`generic parent class is highlighted in Figs. 1 and
`2. Although not shown in Figs. 1 and 2, virtual
`objects
`such
`as ErrorHandler
`and
`Communicationfiandler are also generic
`parent classes. The routines that define the
`user interface to a generic class, along with
`
`IEEE Control Systems
`
`Page 3 of 10
`
`RGBOOi 58035
`
`Page 3 of 10
`
`

`

`l
`
`l
`
`I
`
` Swipe Analyzer
`
`Bar Code Reader
`
`Face Plate
`
`Sid Gripper
`
`generic classes can provide very different
`software object systems. The tasks performed
`in the application determine which class
`routines will be invoked in the supervisory
`code. Thus, changing the way the supervisor
`uses these class routines can result in the im-
`plementation of an entirely different task even
`though the class definitions remain un—
`changed.
`
`Application of RIPE
`
`The Cask Head Work Cell and Radiation
`Survey Work Cell were constructed as part of
`the Advanced Handling Technologies Project
`(AHTP) at Sandia National Laboratories [4].
`The AHTP includes efforts to automate cask
`handling operations at nuclear waste facilities.
`These work cell prototypes serve as proof—of-
`concept systems to demonstrate cask handling
`operations that might be performed robotical-
`ly.
`
`Fig.2 Radiation survey work cell class hierarchy.
`
`Cask Head Work Cell Example
`
`other attributes and routines common to all
`instances of that class, are defined at the
`generic parent level of the hierarchy.
`The Appendix shows a subset of the user
`interface to the Robot class. Attributes are
`defined in data structures such as current and
`home. Actions that are common to all robots
`are found in the definitions of the routines or
`object methods. The keyword virtual at the
`beginning of each function declaration indi-
`cates that the routine is to be defined by a
`device—specific subclass. All robots can be
`commanded to move, but the definition for
`executing a move is specific to a particular
`robot. Note the presence of default values for
`some parameters in the virtual routines, for
`example speed in the move, moveArel, and
`path_move declarations. Including optional
`parameters and default values provides
`flexibility in the subclass definition and in the
`application. For example, if the user wants to
`specify a speed during a move, he invokes the
`desired move routine with the speed parameter
`set. If he does not set the speed parameter, the
`default speed, which is established earlier by
`a call to set_speed, is used.
`
`Derived Objectsfor Specific Applications
`
`Figs. 1 and 2 show how objects in specific
`work cells are derived from their genetic parent
`classes. The bottom level of the hierarchy
`enumerates the software representation of the
`
`physical objects in the work cell. The Cask
`Head Work Cell, as represented in Fig.
`1 for
`example, required programming of the
`CMRobot class as well as other types of subclas—
`ses representing the different devices and work
`pieces. The interface to CMRabot is already
`defined in parent class Robot. The interface ser—
`ves as a kind oftemplate so thatthe programming
`is a matter of"filling in the blanks." For example,
`the code for the move routine consists of trans-
`lating the command into the format the Cincin-
`nati Milacron controller expects and invoking
`the
`CommunicationHandler’s
`routine
`
`send_msg.
`If a subclass has more capabilities than the
`parent, the user interface to the subclass is the set
`of routines defined for the parent class plus
`additional ones defined in the subclass. The
`CMRobor class has been extended for research
`
`into oscillation-damped movement of a flexible
`beam. Routine flex_beam_damping uses the
`move’comply command and torque feedback to
`actively damp vibrations ofacantilevered beam.
`When only the routines specified in the generic
`parent class aroused in programmingan applica»
`tion, a different derived object representing a
`different physical device can be substituted,
`and the commands in the application code
`remain the same. These routines define the
`primitives for RIPL.
`Fig. 2 shows the derived objects for the
`Radiation Survey Work Cell. Acompaxison of
`the two work cells shows that the same set of
`
`February 1 99 i
`
`, "TV
`
`The AHTP consists of several subprojects.
`one of which is the Cask Head Operations
`(CHO) project. The CHO project investigates
`robotic performance of cask head operations
`required before and after nuclear fuel bundle
`unloading. The Cask Head Work Cell was
`designed as a prototype system for cask head
`operations which include leak detection. gas
`sampling (port cover removal/replacement
`and coupling/decoupling of the sampling ap—
`paratus at the port), and bolting and unbolting
`operations. Robust algorithms were required
`for mating the torque wrench to various bolt
`heads on a cask head mock-up using force
`feedback. The requirements for the work cell
`operations illustrate the application of the
`RIPE environment.
`
`One of the premises on which object-
`oriented design is based states that designers
`should avoid as long as possible describing
`and implementing the specific tasks of a sys—
`tem[12]. Rather, they should produce a high
`level design that defines only a set of classes
`which characterizes the behavior of the ob-
`jects in the system. We followed this principle
`by designing and implementing the necessary
`Cask Head Work Cell classes, as discussed
`above,
`independent of any application to
`which they would be applied. As anticipated,
`implementation of the actual cask head opera-
`tions was fast and straightforward. All that was
`required was to create and manipulate the
`work cell objects to perform the specific tasks
`of the system. Also, other applications of the
`work cell such as flexible beam oscillation
`damping research [15] were easily imple—
`
`17
`
`Page 4 of 10
`
`RGBOOl 58036
`
`Page 4 of 10
`
`

`

`merited because the classes had been designed
`completely independent of any particular
`work cell activity.
`
`Computing Environment. Fig. 3 illustrates
`the computing architecture that is used to con—
`trol the Cincinnati Milacron work cell doing
`cask head operations. The primary compo-
`nents include a Sun 3/60 workstation, a VME
`bus with two Force 68020 CPU’s, global
`memory, an 8—port serial I/O card, a Cincinnati
`Milacron series T3-786 robot, and a Lord
`force sensor. The computing elements, robot,
`
`approach to hardware which corresponds with
`the different levels of robot software (task.
`manipulator, servo). However, the design of
`RIPE allows the software to be mapped onto
`multiple layers of the hardware, depending
`upon the application. For example, the servo
`level normally resides at the robot controller,
`but whenever compliant motion is performed,
`some of the servo software functions are ex-
`ecuted on the VME bus CPUs. Similarly, the
`manipulator level software may reside on
`either the robot controller, VME bus. or the
`Sun workstation. The task—level software will
`
`USER INTERFACE
`TASK
`
`Display Monitor
`
`Keyboard/Mouse
`
`SYSGSK
`ASCU—Z
`S stemonuol
`Unit
`
`Cincinnati Milacron
`Robot Controller
`
`MULTIBUS
`
`
`
`The Rest of
`The World
`
`(File Server)
`(Vision)
`
`Ethernet
`Controller
`
`SYSGBK
`DRAM
`
`SYStSSK
`ISIO-2
`
`8 . trill Ports
`
`Lord
`Force Sensor
`
`.Serial
`Port
`
`Fig. 3. Cincinnati milacron hardware platform.
`
`and force sensor are all commercial subsys-
`tems. Special end effectors and grippers were
`designed and built at Sandia.
`The distributed VME multiprocessors
`coordinated by the Sun workstation allow in—
`dividual CPUs to control each subsystem in
`the work cell and provide support for con-
`tinuous tasks, concurrency, synchronization,
`data sharing, communications, real-time con-
`trol, and sensor-based activity. In addition. this
`architecture reflects the hierarchical layered
`
`normally be at the workstation level. Finally,
`model-based control requires that knowledge
`about the work cell and its contents be dis—
`tributed among the software objects that logi-
`cally represent their physical counterparts,
`and these objects may reside at any level of the
`hardware.
`
`Software. To perform cask head opera—
`tions, four software tasks were required, All of
`the tasks are implemented in C++ and utilize
`
`78
`
`the communication and device class libraries
`discussed above to perform their functions. A
`UNIX environmentexists on the Sun worksta-
`tion, and a VxWorks environment controls the
`VME hardware, Fig. 3 shows how the tasks
`are distributed among the work cell CPUs for
`the Cask Head Operation task.
`The first task allows the operator to interact
`with work cell devices. The current imple
`mentation uses SunView [17]. but future inter?
`faces will be built with a recently developed
`object—oriented package called InterViews
`[10]. The second task, which also resides on
`the Sun, serves as the work cell supervisor. It
`accepts commands from the operator through
`the first task and carries out these commands
`by initiating appropriate work cell actions
`(which may be performed by other hardware
`components).
`The remaining two tasks reside on the
`VME bus CPUs. One task monitors the Lord
`force sensor (mounted on the wrist of the
`Cincinnati Milacron robot) and computes
`position updates to control robot movement
`whenever the torque wrench has to mate with
`a bolt. The other task provides the commu-
`nications to the robot controller, utilizing the
`DDCMP protocol [3]. Both tasks use a serial
`[/0 card for message transmission to the force
`sensor and robot controller.
`
`Fig. 4 illustrates the objects that are created
`by these tasks whenever they are executed.
`The work cell supervisor creates a LORD<
`ForceSensor object and a CMRobot object.
`These two objects are, in a sense. distributed
`over multiple environments. The way they are
`created (argument
`list specification) deter—
`mines how they are distributed and how they
`communicate with the actual devices. In Fig.
`4 the shaded boxes indicate the commu—
`nication objects created by the device objects.
`For example, if the force sensor were to be
`controlled directly from the Sun workstation,
`a LORDForceSensor object could be created
`with a parameter list that would cause me
`creation of a UnixSen‘al object for direct com-
`munication to the force sensor device through
`a Sun serial port. In our implementation for
`cask head operations, the LORDForceSensor
`object and CMRobot object are distributed
`across both the Sun workstation and a VME
`CPU due to the real—time requirements of
`force servo control. They communicate
`through UnixCIient/VxServer objects over the
`Ethernet between the UNIX environment on
`the workstation and the VxWorks environ-
`ment on the VME bus. The LORDf‘orce-
`Sensor and CMRUbot objects on the VME
`CPU, in turn, create VxSerial and Vdecmp
`communications objects. respectively, which
`allow them to talk to the actual hardware in the
`
`IEEE Control Systems
`
`Page 5 of 10
`
`RGBOOl 58037
`
`Page 5 of 10
`
`

`

`handling, and replacement of cask impact
`limiters and tiedowns. They also require tech—
`nologies similar to those developed in
`RRSAS, including machine vision and force
`control. These new projects are being ex—
`ecuted using RIPE.
`Although RRSAS was originally imple—
`mented in C from a function-oriented top-down
`design, its highly modular structure and generic
`functions for robot control make it possible to
`use some of the existing code for the methods of
`the C-H- gantry robot class (GRobot). Also, be-
`cause the generic Robot class had already been
`defined and much had been learned during
`development of the CMRobor class, implemen—
`tation of the GRobor class was fairly automatic.
`
`ture which provides the power, compatibility,
`flexibility, and extensibility needed to imple—
`ment complex work cell environments.
`
`Software. The first application using RIPE
`in the Radiation Survey Work Cell performs
`force controlled movement of the robot arm
`for the random contact swipe survey. The
`original force servo control system in
`RRSAS consisted of a PDP/ll with an RT—
`11 environment [13]. This is replaced by a
`much more powerful VME based 68020
`CPU and a VxWorks environment. The new
`swipe survey software (Swipe Server) is a
`C++ application which creates and manipu-
`lates a GRobot and JR3ForceSensor object
`
`la—poaoooao:..................................................r......
`
`f..“.-.‘.§‘..“‘
`
`r‘\\\\‘\‘\\‘\\\‘\\\“\\I“‘
`VME CPU1
`
`Lord Force Sensor
`
`Cmd State Table
`
`VME CPU2
`
`.\‘\\\\\\\\\\\\‘\
`K‘“““‘\‘lh\\‘l\“‘\\“‘\““
`
`work cell. To achieve the update rate neces-
`sary for force control, an additional Vdecmp
`object is created on a second VME CPU to
`handle the low—level protocol and message
`transmission to the robot controller. The two
`distributed Vdecmp objects communicate
`with each other over the VME bus through a
`VxSocke! object.
`Finally, the LORDForceSensor object also
`creates a CmdStoteTable object which reads a
`configuration file that defines the specific be-
`havior of the Lord force sensor device. For
`example, using the CmdStazeTable informa-
`tion, the LORDForceSensor objectknows that
`it must send an "OA" <CR> (Output ASCII)
`command to the force sensor in order to obtain
`ASCII readings of the current forces being
`sensed. By isolating device—specific attributes
`and commands into files that are managed by
`the CmdStateTable object, methods that con-
`trol the device’s behavior are written generi-
`cally and can reside in the parent Tool, Sensor,
`or ForceSensor classes rather than in the L-
`ORDForceSensor class. These methods there—
`fore can be used by other types of force sensor
`classes derived from the parents (such as the
`JR3ForceSensor class) which have their own
`configuration files.
`The Appendix has one portion of code
`from the Force Control Task residing on the
`first VME CPU. This code shows how the
`objects in the work cell are created and used
`to perform a simple bolting operation.
`Messages are sent to the LORDForceSensor
`and CMRobot objects to obtain force readings
`and initiate robot motion until the torque
`wrench is properly seated on abolt.
`
`Radiation Survey Work Cell Example
`
`The Radiation Survey Work Cell was the
`first experimental system to be built for AHTP.
`Its initial application, the Robotic Radiation
`Survey and Analysis System (RRSAS), was
`completed in August 1987 [13], and included
`operations to locate a half scale cask mock-