David J. Miller and R. Charleene Lennox
`
`
`
`An objecboriented 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 platfonn 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—tirne sensor-
`based activity, error handling, and robust
`communication. The object-oriented paradigm
`provides mechanisms such as inheritantx: 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, cornput—
`
`Presented at the 1990 IEEE International
`Conference on Robotics andA ummation, Cin-
`cinnati, OH, Aug. 13-16, 1990. The authors
`are with Sandia National Lalwratories. Albu-
`querque, NM. This work was supported by the
`U. S. Department of Energy under Contract
`DE-/tC()4—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 irnplerrtentation
`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—oriertted 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-
`vironment, 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—spccific 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-1708/91/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 prngrarnrning. 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) the 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 task-level 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 Approaches to Solving the Problem
`
`Various approaches have been used to try
`to solve these problems. Vendor supplied
`
`/EEE Control Systems
`
`ABB Inc.
`
`EXHIBIT 1039
`
`Page 1 of 10
`
`
`
`RGBOO158033
`
`Page 1 of 10
`
`

`
` generic parent class and objects of its device-
`they resemble
`which have evolved until
` development.
`specific subclasses to receive the same mes-
`general-purpose, high-level computer lan-
`Computing Architecture. The RIPE
`sages and respond to them appropriately. The
`guages. However, applications written in
`computing architecture consists of a hierarchi-
`device independent programming language in
`these languages are specific to the vendor's
`cal multiprocessor approach which employs
`robot and, therefore, are not portable.
`RIPE resulting from object-oriented design of
`distributed general and special purpose
`robotic work cells is RIPL.
`One approach is to replace the robot con-
`processors. This architecture provides the
`Separating robot system concepts from the
`trol system with a new control system em-
`computing power required by the RIPE
`actual RIPE implementation results in robot
`bedded within an existing operating system,
`software to control complex diverse subsys-
`tems in real—time while coordinating reliable
`system software which is reusable, extensible,
`written in a general purpose language, and
`communications between them. Advances in
`reliable, and portable. RIPE’s reusability is the
`using primitive functions included in alibrary.
`RCCL [6] and KALI [1], for example, provide
`basis for the design process. Extensibility is
`microprocessor technology allow general pur-
`such intermediate level robot control primi-
`provided in RIPE by defining new software
`pose processors to achieve the computing per-
`classes which in tum become part of the
`tives. These primitives can be called by off-
`formance required by complex robot control
`general work cell programming language. Use
`line programming systems and can provide an
`algorithms while remaining compatible with a
`environment for research into control and
`of inheritance to define subclasses which are
`large base of existing software.
`extensions or restrictions of RIPE parent clas-
`optimization algorithms. Frequently neither
`Object-Oriented Design. Central to the
`RCCLnor KALI is a viable option for industry
`ses greatly lowers the cost and complexity of
`design of RIPE is object-oriented program-
`work cells or research labs because they re-
`software development. System reliability is
`ming. 0bject—oriented design results in
`quire knowledge of complex robot trajectory
`software architectures based on the objects
`enhanced by reusing well-defined RIPE ob-
`planning and systems programming.
`jects, and portability is realized because RIPE
`that comprise a system and its environment
`In attempts to move beyond manipulator-
`classes are tightly encapsulated and relatively
`rather than on the functions it performs [12].
`level programming of basic robot motions in
`independent of their environment.
`Robot systems perform actions on certain ob-
`a three-dimensional work space, task-level
`jects within a defined work space. The
`languages such as AUTOPASS [9] andLAMA
`software controlling the robot system can be
`[l 1] were defined. They were somewhat
`viewed as an operational model of the world
`in which the robot exists. Therefore, RIPE is
`premature and were never fully implemented
`due to the unsolved subproblems of grasp
`organized around representations of the ob-
`planning, path planning, and fine motion plan-
`jects in the work space so that its structure
`ning [8]. However, it is generally agreed that
`reflects the physical structure of the system.
`task-level languages are needed to solve the
`Controlled complexity is achieved by creat-
`problems relating to the expense and’com-
`ing, combining, and manipulating software
`plexity of robot system programming.
`objects instantiated from previously defined
`A number of the more recent approaches
`software classes to perform the specific tasks
`[7], [19], [20] use conventional programming
`of the system.
`languages to help solve the problems of sys-
`Object-oriented programming is based on
`tem complexity, real—tirne constraints, sensor
`the concepts of abstract data types. classes.
`integration, and modeling. These approaches
`objects, generic operations, message passing,
`have the advantages gained by using a lan-
`type hierarchies/inheritance, and polymor-
`guage which is reliable, well-supported, port-
`phism [12]. Applying these concepts to RIPE
`able, and familiar. In addition,
`these
`results in modularity, encapsulation, abstrac-
`approaches focus on the total work cell system
`tion, and information hiding. Abstract data
`rather than only on the robot. The drawback is
`types, classes, and objects allow the designer
`that, to date, the software has often been single
`to model the physical robotic work cell entities
`purpose and not easily extended to other ap-
`in RIPE by defining only their attributes, be
`plications.
`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
`
`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 perfonnance 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. UNTX 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
`
`Approachfor RIPE
`
`RIPE was developed [0 support model-
`basod 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 welbestablished software operating sys-
`
`February 1991
`
`,T.
`
`,,,
`
`,
`
`, W,
`
`,,.,
`
`15
`
`Page 2 of 10
`
`
`
`RGBOO158034
`
`Page 2 of 10
`
`

`
` The software classes which do not represent
`
`physical objects are termed "virtual objects" and
`include Communicationflandler, World-
`Modeler, Errorflandler. Traject0ryGenerat0r
`and PathPlarmer.
`
`
`
`
`
`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 CM-
`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 Tram-portclass. 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 Sensor class would be
`a barcode reader used for identification of a work
`piece, a Contact switch which verifies the
`presence of a tool in in 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 ErmrHana'ter
`and
`Communicationfiandler are also generic
`parent classes. The routines that define the
`user interface to a generic class, along with
`
`IEEE Confrol Systems
`
`Page 3 of 10
`
`
`
`
`
`
`
`Face Plate
`
`
`Lifting Shoe Air Wrench
`
`
`
` Micro Switch
`Torque Sensor
`
`Gas Sampler
`
`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 real-time 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 im-
`metfiate 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 con-
`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 XRl00 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 device 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
`
`
`
`RGBOO158035
`
`Page 3 of 10
`
`

`
`
`
`
`
`
`
`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.
`
`
`
`Face Plate
`
`Std Gripper
`
`
`
`Bar Code Reader
`
`
`
`
`
`
`
`
`Geiger Counter
`
`Swipe Analyzer
`
`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—specifrc 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, movejel, 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 generic 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 11 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
`Commum‘cationHandler’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
`CMRobot class has been extended for research
`
`into oscillation-damped movement of a flexible
`beam. Routine flex_beam_dampirzg uses the
`rnove’c0mply command and torque feedback to
`actively damp vibrations ofacantilevered beam.
`When only the routines specified in the generic
`parent class areused 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 I 99 l
`
`_ Tc.
`
`The AHTP consists of several subprojects,
`one of which is the Cask Head Operations
`(CHO) project. The CHO project investigates
`robotic perforrnanoe 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 Iorrg as possible describing
`and implementing the specific tasks of a sys-
`tem[l2]. 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-
`
`I7
`
`
`
`RGBOO158036
`
`Page 4 of 10
`
`Page 4 of 10
`
`

`
` are distributed among the work cell CPUs for
`
`e computing arc itecture 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,
`
`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
`
`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
`[l0]. 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 perfonned 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
`I/O 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-
`ForceSens0r 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 creatcd 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 UnixSe.rial 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 CMR0bot object are distributed
`across both the Sun workstation and a VME
`CPU clue to the real-time requirements of
`force servo control. They communicate
`through Ui1i.\'CIient/VxServer objects over the
`Ethernet between the UNIX environment on
`the workstation and the VxWorks environ-
`ment on the VME bus. The LORDForce—
`Sensor and CMROb0t objects on the VME
`CPU, in turn, create Vxserial and VxDdcmp
`communications objects. respectively, which
`allow them to talk to the actual hardware in the
`
`/EEE Con rrol Systems
`
`USER INTERFACE
`
`Display Monitor
`
`Keyboard/Mouse
`
`Controller
`
`SYS68l(
`ISIO-2
`
`SYS68K
`ASCU—2
`S stemonuol
`Unit
`
`Cincinnati Milacron
`Robot Controller
`
`Lord
`Force Sensor
`
`.Serial
`Port
`
`MULTIBUS
`
`Fig. 3. Cincinnati rnilacron 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
`
`I8
`
`
`
`RGBOO158037
`
`Page 5 of 10
`
`Page 5 of 10
`
`

`
` in the Radiation Survey Work Cell performs
`
`ecuted using RIPE
`force controlled movement of the robot arm
`Although RRSAS was originally imple-
`mented in C from a function-oriented top-down
`for the random contact swipe survey. The
`design. its highly modular structure and generic
`original force servo control system in
`RRSAS consisted of a PDP/ll with an RT-
`functions for robot control make it possible to
`ll environment [13]. This is replaced by a
`use some of the existing code for the methods of
`much more powerful VME based 68020
`the C-H- gantry robot class (GRobot). Also, be-
`CPU and a VxWorl-ts environment. The new
`cause the generic Robot class had already been
`defined and much had been learned during
`swipe survey software (Swipe Server) is a
`C++ application which creates and manipu-
`development of the CMRobot class, implemen-
`lates a GRobot and JR3ForceSensor object
`tation of the GRobo: class was fairly automatic.
`
`laaloaoooaor..................................................our.... ..
`
`._...-.-.s-s-as‘
`
`Force Sensor
`fippaa-ap’y.-,-----.-..--..---..
`
`r\\\\\\\\\\\\\\‘\\\\\\\I\\\
`VME CPU1
`
`Lord Force Sensor
`
`Cmd State Table
`
`VME CPU2
`
`\.\\\\\\\\\\\\\\\\
`Ikm\\‘nu\\\\nu\\\n\\“\\\“\\\‘\
`
`
`I\III\IIIIIIVIIIIIIIIIIIIIIII\s
`
`
`
`distributed VxDdcrnp objects communicate
`with each other over the VME bus through a
`Vxsocker object.
`Finally, the LORDFOrr:eSensor object also
`creates a CmdStateTable 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
`ASCH readings of the current forces being
`sensed. By isolating device—specific attributes
`and commands into files that are managed by
`the CmdStateTab!e object, methods that con-
`trol the device’s behavior are written generi-
`cally and can reside in the parent Tool, Sensor,
`or ForceSens0r classes rather than in the L-
`0RDForceSensor class. These methods there-
`fore can be used by other types of force sensor
`classes derived from the parents (such as the
`JR3F0rceSens0r 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 C'MRobot 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-up
`in the work cell using stereo vision, identify
`cask contents by reading bar codes, and per-
`form both non—contact and contact radiation
`surveys. Key technologies such as automatic
`motion planning and programming of the
`CIMCORPXR100 gantry robot and force sen-
`sor integration to maintain constant force con-
`tact with the cask surface during
`contamination surveys are demonstrated by
`RRSAS. RRSAS was completed prior to the
`development of RIPE.
`Some subsequent studies currently under
`development include the Impact Limiter Han-
`dling project and the Cask Tiedown project [4].
`These projects will investigate robotic removal,
`
`February 7991
`
`LORD Force Sensor
`
`Cincinnati Milacron Robot
`
`Fig.4. Cask head work cell example.
`
`the Radiation Survey Work Cell
`Similarly,
`employs a JR3 force sensor rather than a Lord
`force sensor, so a JR3F0rceSensor class also
`had to be implemented. This again was
`facilitated by the existence of generic parent
`classes (Tool, Sensor. ForceSensor).
`
`Computing Environment. Aside from the
`specialized subsystems required by RRSAS, the
`primary hardware components of the Radiation
`Survey Work Cell are the same as those found
`in the Cask Head Work Cell (Sun workstation,
`VME bus, robot, sensors). There is of course
`a different robot and a different force sensor,
`and the VME bus uses Heurikon 68020 CPUs
`
`rather than Force CPUs (transparent to the
`software). As stated earlier, this hierarchical
`distributed approach is our standard architec-
`
`to monitor a JR3 force sensor mounted on the
`wrist of the gantry robot and make real-time
`trajectory corrections to the robot arm. The
`corrections are based on the contact force
`detected between the robot's end effector
`(swipe planchet) and the cask. The control
`structuremaintainsa4.0il.0 lb normal con-
`tact force during the swiping motion.
`Fig. 5 illustrates the objects that are created
`by the Swipe Server. If this figure is compared
`with Fig. 4, it can be seen that the object
`hierarchies are nearly identical. The primary
`differences reside at the communication and
`servo level, where additional state machine
`firmware is utilized