!
`
`'i
`
`IROS ’92
`
`VOLUME 1
`
`PROCEEDINGS OFTHE 1992
`lEEE/RSJ INTERNATIONAL CONFERENCE ON
`
`‘VINTELLIGENT ROBOTS
`AND SYSTEMS
`
`lUl.
`(.'S'tk ;
`Sensor-based Robotics And Opportunties For Its Industrial Applications
`
`I
`
`July 7-10,1992
`
`Raleigh, North Carolina, USA
`
`SPONSORED BY
`The IEEE Industrial Electronics Society * The Robotics Society of Japan
`The Society of Instrumentation and Control Engineers
`The IEEE Robotics and Automation Society * The New Technology Foundation
`
`Page 1 of 13
`
`Mercedes Exhibit 1007
`
`

`
`i
`
`I
`
`i
`
`f.
`
`\Q
`
`~
`
`i\T
`a !0
`-<
`. o
`. :r 44-31
`
`N > 1
`C . 1
`
`^O'^S Hq
`V THE \
`* MILTON S.li
`EISENHOWER
`LIBRARY ^
`
`1992 lEEE/RSJ International Conference on Intelligent Robots and Systems
`
`Abstracting is permitted with credit to the source. Libraries are premitted to photocopy beyond the limits of
`U.S. copyright law for private use of patrons those articles in this volume that cany a code at the bottom of the
`first page provided the p>er-copy fee indicated in the code is paid through the Copyright Clearance Center,
`29 Congress Street, Salem, MA 01970. Instructors are premitted to photocopy isolated articles for noncommercial
`classroom use without fee. For other coping, reprint, or republication permission, wnte to the Staff Director of
`PubUshing Services at the IEEE, 345 East 47th Street, New York, NY 10017-2394. All rights reserved. Copyright©
`1992 by The Institute of Electrical and Electronics Engineers, Inc.
`
`X-} c.
`
`/5
`
`IEEE Catalog Number. 92CH3181-5
`ISBNCasebound: 0-7803-0738-0
`Softbound; 0-7803-0737-2
`Microfiche: 0-7803-0739-9
`Library of Congress Number 92-53498
`AddilitHial copies of this publication are available from
`
`lEEE Service Center
`445 Hoes Lane
`Piscataway, NJ 08854-4150
`1-800-678-IEEE
`
`Page 2 of 13
`
`

`
`Table of Contents
`
`Organization
`
`Welcoming Messages
`
`Volume 1 (pages 1-702)
`
`Space Robotics: I (Special Session)
`Maneuvering and Manipulation of Flying Space Tclerobotics System ..
`K. Machida, Y. Toda, and T. Iwata
`-
`Mobility and Manipulation of a Light-Weight Space Robot ^...................
`Y. Xu, B. Brown, S. Aoki, and T. Kanade
`Integrating Robotic Functions and Operator Supervision using Petri Nets
`D.R. Lefehvre and G.N. Saridis
`Task Level Programming and Robot Autonomy .......................................
`G. Giralt, R. Alami, and R. Chatila
`-
`
`Force/Torque Sensing (Special Session)
`Load Carrying Capacities of ISO 9409-1 Bolt Patterns for Compact Six Degree of Freedom
`Force-Torque Transducers ........................................................................................................
`J. Ramming
`A Simplistic Approach to the Redesign of a Forcc/Torque Sensor ...........................................
`D.M. Perry
`Has Forcc/Torque Sensing Gained Factory Acceptance? ..........................................................
`K. Morris
`Implementation Results of a Hybrid Learning Force Control Scheme ....................................
`K. Gulielmo and N. Sadegh
`
`Coordinated Manipulation
`Cartesian-Space Kalman-Bascd Predictive Compensation For Computation Delays in Leader-
`Follower Coordination of Two Manipulators: Formulation and Experimental Validation ......
`Z. Turn eh
`Multi Point Compliance Control of Dual Ann Robots .................................................................
`A. Jazidie, T. Tsuji, and K. Ito
`
`IX
`
`111
`
`V
`
`3
`
`11
`
`20
`
`27
`
`37
`
`41
`
`44
`
`47
`
`59
`
`65
`
`s I I t
`
`I
`
`s
`
`‘I
`§
`
`3I
`
`I
`
`Page 3 of 13
`
`

`
`/
`<
`
`>f
`
`m
`
`'iSt'
`rS
`
`A Generic Geometrical Path Planning For the Coordinated Motion of Two Manipulators
`JZ.C. Lai
`Coordination Specification for a Robotic Platform System..............................................
`F.Y. Wang, M. Mittmann, and G.N. Saridis
`Control of Mechanical System with Man-Machine Interaction .........................................
`K. Kosuge, Y. Fujisawa, and T. Fiikuda
`
`Adaptive Control
`Stability and Performance of Sampled-Data Robot Adaptive Controllers ............................
`G. Warshaw, H.M. Schwartz, and H. Asmer
`A Direct Adaptive Control Melliod With Desired Compensation for Robotic Manipulators
`H. Asmer, H.M. Schwartz, and G.D. Warshaw
`Implementation of a PC-Based Adaptive Control Scheme for an Industrial Robot..............
`K.C. Kushal and J. Sneckenberger
`Experimental Analysis of a Centralized/Decentralized Controller for Robotic Manipulators
`G. Yanovski, EJ. Davison, DM, Lokhorst, and J.K. Mills
`The Learning of Reactive Control Parameters Through Genetic Algorithms......................
`M. Pearce, R. Arkin, and A. Ram
`
`2-D Vision
`Some Problems in Perspective System Theory and Its Application to Machine Vision.....
`B. Ghosh, M. Jankovic, and Y.T. Wu
`A Combined Extended Circular Image and Spatial Occupancy approach to 2-D Contour
`Matching ....................................................................................................................................
`E. Milios and TJ. Horton
`Determination of Object Location via Decomposition of Movement ...................................
`X. Cao, G. Hu, and N. Shrikhande
`The Acquisition of Distance and Orientation of a Mobile Robot with a Concept of Virtual
`Corner Point..............................................................................................................................
`M. Park, H. Kim, D. Woo, and M. Park
`A Unification Theory for Early Vision ..................................................................................
`H. Jeong and J.G. Kim
`
`Dexterous Manipulation
`A Self-learning Controller for Monocular Grasping....................
`P.P. van der Smagt, B.J.A. Krose, and F.C.A. Groen
`Multi-Agent Architecture for Controlling a Multi-Fingered Robot
`T. Matsui, T. Omata, and Y. Kuniyoshi
`Mechanical and Control Features of the UB Hand Version 2.....
`C. Melchiorri and G. Vassura
`Grasp Recognition Using the Contact Web.....................................
`S.B. Kang and K. Ikeuchi
`
`X
`
`71
`
`79
`
`87
`
`95
`
`105
`
`114
`
`122
`
`130
`
`139
`
`147
`
`155
`
`163
`
`169
`
`177
`
`182
`
`187
`
`194
`
`Page 4 of 13
`
`

`
`A Computer Implementation of Fractal Based Inference Network Classifier for
`Sensorimotor Robot Hand Preshaping ..........................................................
`A. Erkman and C.V. Bay sal
`A System for Planning and Executing Two-Finger Force-Closure Grasps of Curved 2D Objects
`D. Siam, J. Ponce, and B. Faverjon
`
`202
`
`210
`
`Space Robotics: II (Special Session)
`Muliisensory Shared Autonomy—A Key Issue in the Space Robot Technology Experiment
`
`G. Hirzinger, /. Heindl, K. Landzettel, and B. Brunner
`Teleoperated Satellite Repair Experiments ..........................................................................
`H. Das, PS. Schenker, H. Zak, andA.K. Bejezy
`A Predictive Display with Force Feedback and its Application to Remote Manipulation
`System with Transmission Time Delay................................................................
`r. Kotoku
`Time Delay Insensitive Teleoperation ................................................................
`R. Paul, T. Lindsay, and C. Sayers
`Motion Estimation of Unknown Object for Space Robotic Missions........................................
`Y. Masiitani, Y. Okada, F. Miyazaki
`
`Manipulator Modeling and Control
`Experimental Study of the Identification Methods for an Industrial Robot Manipulator........
`K. Yoshida, N. ikeda, H. Mayeda
`Using Adaline Neural Networks for Compensation of Structured Uncertainty in Manipulators
`A. Kuan and B. Bavarian
`A Multi-Population Genetic Algorithm and Its Application to Design of Manipulators ...........
`J.O. Kim and P. Khosla
`'
`■
`On the Development of a Fuzzy Model-Based Controller for Robotic Manipulators ...............
`J.Y. Lai andJ.J. Shieh
`Adaptive Control of Robot Manipulators .................................................................................
`H. Yu, L.D. Seneviratne, and S.W.E. Earles
`
`■i
`
`'d.
`st
`
`I I
`
`IiI
`
`I
`
`221
`
`231
`
`239
`
`247 .
`
`255
`
`263
`
`271
`
`279
`
`287
`
`293
`
`301
`
`309
`
`317
`
`High-Level Control
`Robotic Control in
`an Uncertain Environment; Hypothesis Testing, Identification and
`Accommodation ..
`C. Maciag and G. Cook
`The Segmented Bus: A Dynamically Segmcntable Interprocessor Communication Network
`lor Intelligent Robot Systems .................................................
`C. M. Aras, R.C. Luo, and D.S. Reeves
`Propositional Logic Applied to Execution Control ......................................
`B. Degallaix, J.P. Thihault, and M. Ghallah
`Integration of Real-Time Software Modules for Reconfigurable Sensor-based Control
`D. B. Stewart, R.A. Volpe, and P. Khosla
`A Blackboard, Activity-Based Control Architecture for a Mobile Platform ..................
`R. Liscano, R.E. Fayek, and G.M. Kararn
`........
`
`.............
`
`XI
`
`Systems ... 325
`
`333
`
`Page 5 of 13
`
`

`
`Raleigh, NC July 7-10, 1992
`Proceedings of the 1992 EEE/RSJ International Conference on Intelligent Robots and Systems
`Integration of Real-Time Software Modules for
`Reconfigurable Sensor-Based Control Systems
`David B. Stewart^, Richard A. Volpe^, Pradeep K. Khosla^
`
`'^Department of Electrical and Computer Engineering and Tlie Robotics Institute
`Carnegie Mellon University. Pittsburgh, PA 15213
`*The Jet Propulsion Laboratory, California Institute of Teclinology
`4800 Oak Grove Drive, Pasadena, California 91109.
`
`Abstract—In this paper we develop a framework for Integrat­
`ing real-time software modules that comprise a reconfigurable
`multi-sensor based system. Our framework is based on the pro­
`posed concept of a global database of state Information through
`which real-time software modules exchange information. This
`methodology allows the development and integration of reusable
`software in a complex multiprocessing environment. A reconfig­
`urable sensor-based control system consists of many software
`modules, each of which can be modelled using a slmplihed version
`of a port automaton. Our new state variable table mechanism can
`be used in both statically and dynamically reconfigurable systems,
`and It is completely processor independent. Individual modules
`may also be combined into larger modules to aid in building large
`systems, and to reduce bus and CPU utilization. An efficient im­
`plementation of the state variable table mechanism, which has
`been integrated into the Chimera II Real-Time Operating Sys­
`tem, is also described.
`Keywords—reconfigurable sensor-based control systems, reus­
`able so^.ware, real-time operating systems, interprocessor com­
`munication, spin-locks, real-time software modelling.
`I. Introduction
`Real-time sensor based control systems arc complex. In order to
`develop such systems, control strategies are needed to interp-et and
`process sensing information for generating control signals. There has
`been considerable effort devoted to addressing this aspect of real-time
`control systems. However, ev«i with robust control algorithms, a so­
`phisticated software environment is necessary for efficient implemen­
`tation into a robust system. The level of sophistication is even greater
`if this system is to be generalized so that it is reconfigurable and can
`perform more than a single task or application. Obviously, a real-time
`operating system (RTOS) is part of this software environment. How­
`ever, it is also necessary to have a layer of abstraction between the
`RTOS and control algorithms that makes the implementation efficient,
`allows for easily expanding and/or changing tlie control strategies,
`and reduces development costs by incorporating the concept of reus­
`able software. The development of this layer of abstraction is further
`motivated by the realization that real-time control systems are typical­
`ly implemented in opcn-architecture multiprocessor environments.
`Several issues, such as configuring reusable modules to perform a job,
`
`■Jlic rcsurch r^xRXed in thi» paper ii rupported, in pan by. U.S. Army AMCOM and
`DARPA under contract DAAA-2189-C-0001, the National AerooauUca and Space Ad­
`ministration (NASA), the Department of Electrical and Computer Engineering, and by
`The Robotic* Institute at Carnegie Mellon Univereiiy. Paitial luppon for David B. Stewart
`U provided by the Natural Sciences and Engineering Research Council of C’anada
`(NSERC) through a Graduate Scholarship.
`I'he research reported in this paper was also performed, in part, for the Jet Propulsion
`I-aboratory (JPL), California Institute of Technology, for the Remote Surface Inspection
`system development ar>d accompanying projecu 126] under a contract with NASA. Rcf-
`ertmee herein to any specific commercial product, {nocess, or service by trade name, irade-
`maik, manufacturer, or otherwise, does not constitute or imply its endorsement by the
`United States Government or JK-.
`0-7803-0737-2/92$03.00 199201EEE
`
`325
`
`allocating modules to processors, communicating between various
`modules, synchronizing modules running on separate processors, and
`determining correctness of a configuration, arise in this context.
`In this paper we develop a framework for integrating real-time soft­
`ware modules that comprise a reconfigurable mulU-sensor based sys­
`tem. Our framework is based on the proposed concept of a global da­
`tabase of state information through which real-time software modules
`exchange information. This methodology allows the development and
`integration of reusable software in a complex multiprocessing envi­
`ronment.
`We define a control module as a reusable software module williin a
`real-Ume sensor-based control subsystem. A reconfigurable system
`consists of many control modules, each of which can be modelled us -
`ing a simplified version of a port automaton [22], as shown in Fig. 1.
`£ach module has zero or more input ports, and zero or more output
`ports. Each port corresponds to a data item required or generated by
`the control module. A module which obtains data from sensors may
`not have any input ports, while a module which sends new data to ac­
`tuators may not have any output ports. We assume that each control
`module is a separate task^. A control module can also interface with
`other subsystems, such as vision systems, path-planners, or expert
`systems.
`A link between two modules is created by connecting an output
`port of one module to an appropriate input of another module. A legal
`configuration is obtained if for every input port in the system, there is
`one, and only one, output port connected to it. An extension of the port
`automata theory is presented in 112], where asplit connector allows a
`single output to be fanned into multiple output ports, and a join con­
`nector allows multiple input ports to be merg^ into a single input
`port. The split connector replicates the output multiple times. For Uic
`join connector, a combining algorithm, such as a weighted average, is
`required to merge the data.
`
`input ports ^
`
`control
`nnodulG
`
`>yi
`:—►ym
`
`output ports
`
`communication with
`sensors, actuators,
`and other subsystems
`
`Fig. 1: Port automaton model of a control module
`
`1. We define a task as a sq>arate thread of control within a multitasking operating sys-
`t«n. The definition is consistent with that d* the Chimera U Real-Time C^ierating System
`[23], and is also known as a rfireodin Mach andPOSIX.anda figXtweigfirprocersinsome
`other operating systems.
`
`Page 6 of 13
`
`

`
`Other environments developed for robot control ([1][2](3](5][14])
`lack the flexibility required for the design and implementation of
`reconfigurable systems. The design of these programming environ­
`ments is generally based on heuristics rather than on software archi­
`tecture models, and lends itself only to single-configuration systems.
`Tlie environments also do not make clear distinctions between module
`interfaces and module content, thus lacking a concrete framework
`which would allow development of modules independent of die target
`application and target hardware.
`In this paper, we propose a metliod of using state variables for sys­
`tematically integrating reusable control modules in a real-time multi­
`processor environment. Our design can be used with both statically
`and dynamically reconfigurable systems. Section II describes the de­
`sign issues to be considered, and some of the assumptions we have
`made about the target environment. Section III gives the architectural
`details of our control module integration. Section IV describes an ef­
`ficient implementation of the state variable table mechanism, which
`has been integrated into the Chimera II Real-Time Operating System
`[23]. Finally, Section V summarizes the use of state variables for
`module integration in a reconfigurable system.
`II. Design Issues and Assumptions
`In order to design a general mechanism which can be used to inte­
`grate control modules in a multiprocessor environment, some archi­
`tectural knowledge of tlie target hardware is required. We assume an
`open-architecture multiprocessor system, which contains multiple
`general purpose processors (such as MC68030, Intel 80386, SPARC,
`etc.), which we call Real-Time Processing Units (RTPUs), on a com­
`mon bus (such as VMEbus, Multibus, Futurebus, etc.). Each proces­
`sor has its own local memory, and some memory in the system is
`shared by all processors.
`Given an open-architecture target environment, the following is­
`sues must be considered:
`Processor transparency: In order for a software module to be re­
`usable, it must be designed and written independent of the
`RTPU on which it will finally execute, since neither the hard­
`ware nor software configuration is known apriori.
`Task synchronizalioni Sensors and actuators may be operating at
`different rates, thereby requiring different tasks to have differ­
`ent frequencies. In addition, system clocks on multiple proces­
`sors may not be operating at the exact same rate, causing two
`tasks with the same frequency to have skewing problems. The
`module integration must not depend on task frequencies or
`system clocks for synchronization.
`Data integrity: When two modules communicate with each oth­
`er, a complete set of data must be transferred. It is not accept­
`able for part of a data set to be from the current cycle, while
`the rest of the data set is from a previous cycle.
`Predictability: In real-time systems, it is essential that the com­
`munication between modules is predictable, so that worst-case
`execution and blocking times can be bounded. These limes are
`required for analysis by most real-time .scheduling algorithms.
`Bus bandwidth: In an open-architecture system, a common bus is
`shared by all RTPUs. The communication between modules
`must be designed to minimize the bus traffic.
`implementation ejficiency: The design must lead to an efficient
`implementation. Communication mechanisms which incur
`large amounts of overhead are not suitable for the high fre­
`quency tasks, and therefore cannot be used.
`To address these issues, we propose a state variable tabic mecha­
`nism which allows the integration and reconfiguration of reusable
`modules in a multiprocessor, open-architecture system.
`
`326
`
`Global State Variable Table
`
`local siaio
`variable table
`
`1 r
`local state
`variable table
`
`local state
`variable table
`
`local state
`variable t^lo
`
`• • •
`
`task "N
`module
`module
`5-J
`Processor 4
`Fig. 2; Structure of state variable table mechanism
`for control module integration
`
`module
`Kl
`
`'' tik ''
`rrxxJulo
`K'i-J
`Processor K
`
`111. UHSIGN OhbTAT'li VARlABUi 1 ABLh MliUlANiyM
`The structure of our state variable table mechanism is shown in
`Fig. 2. It is based on using global shared memory for lire exchange of
`data between modules, tlius providing communication wiili minimal
`overhead. A global state variable table is stored in the shared memo­
`ry. The variables in the global state variable table are a imion of all the
`input port and output port variables of the modules Ural may be con­
`figured into the system. Tasks corresponding to each control module
`cannot access this table directly. Rather, every task has its own local
`copy of tl\e table, called ilie local stale variable table.
`Only the variables used by the task are kept up-to-date in the local
`table. No synchronization is needed to access tJiis table, since only a
`single task has access to it. At the beginning of every cycle of a task,
`Uie variables which are input ports are transferred into the local table
`from the global table. At llic end of the task’s cycle, variables which
`are output ports are copied from the local table into the global table.
`Tltis design ensures that data is always transferred as a complete set.
`When using the global stale variable table for inter-module com­
`munication, the number of transfers per second^ (Zy) for module My
`can be calculated as follows:
`n.
`
`m-
`
`i~ 1
`
`0)
`
`where «y is the number of input ports for Mj, my is tlie number of
`output ports for Mj, x,y is input variable x-, for My, y^- is output variable
`y,- for Mj, S(x) is tne transfer size of variable x, Tj is the period of My.
`state van-
`and A is the overhead required for locking and releasing the
`able table during each cycle.
`We assume that the entire global stale variable has a single lock. It
`is possible for each variable to have its own lock, in which case the
`locking overhead increases to (m+n)A. The advantage of using a sin­
`gle lock is described in Section .A..
`The bus utilization B for k modules in a particular configuration, in
`transfers per .second, is then
`
`k
`
`B =
`
`(2)
`
`We use “transfers per second” instead of CPU execution time or bus utilization time
`as a base measure for tlie resource requirements of the communication mechanism, since
`it is a hardware independent measurement.
`
`Page 7 of 13
`
`

`
`(3)
`
`Thus using our state variable table design, we can accurately deter­
`mine the CPU and bus utilization required for the inter-module
`com-
`munication witliin a configuration.
`A configuration is legal if the following holds true:
`k, ntj
`ff ^>
`k,m.
`n :V;; = 0 A
`U X.J Q
`ytj
`V
`V=i,» 1
`''V=1.» = 1 ^
`v=i.«=i yy
`The first term represents the intersection of all output variables
`from all modules. If two modules have the same outputs, tlien a join
`connector is required. Modules with conflicting outputs can modify
`their ouq^ut port variables, such that they are two separate, intermedi­
`ate variables. A join connector is a separate module which performs
`some kind of combining operation, such as a weighted average. Its in­
`put ports are tlie intermediate variables, while its single output port is
`die output variable that was originally in conflict. Tlie bandwidtli
`re-
`quired can then be calculated by treating Uie join connector as a regu­
`lar module. Split connectors are not required in our design, since mul­
`tiple tasks can specify the same input port, in which case data is
`obtained from the same location widiin the global state variable table.
`ITie second term in (3) states that for every input port, there must be a
`module with a corresponding output port.
`Using state variables for module integration is processor indepen­
`dent. Whedier multiple modules run on the same RTPU, or each mod­
`ule runs on a separate RTPU, the maximum bus bandwidth required
`for a particular configuration remains constant, as computed in (2). In
`the next section we give more details on typical modules within a
`reconfigurable sensor-based control system.
`A. Control Module Library
`Tlie state variable table mechanism is a means of integrating con­
`trol modules, which have been developed with a reusable and
`recon-
`figurable interface. Once a module is developed, it can be placed into
`a library, and incorporated into a user’s application as needed. A sam­
`ple control module library is shown in Fig. 3. The classification of dif­
`ferent module types is for convenience only. There is no difference in
`tlie interfaces of say, a robot interface module and a digital controller
`module. We expect that existing robot control libraries (e.g. I2][10]),
`can be repackaged into reusable modules in order to use tliem iii
`reconfigurable systems.
`The following variable notation is used:
`6: joint position
`x: Cartesian position
`0: joint velocity
`x: Cartesian velocity
`0: joint acceleration
`'x: Cartesian acceleration
`X; joint torque •
`f: Cartesian force/torque
`u: control signal
`J: Jacobian
`z: wild-card: match any variable
`The following subscript notation is used:
`d: desired (as input by user or paiii planner)
`r; reference (computed value, commanded on each cycle)
`m: measured (obtained from sensors on each cycle)
`y: wild-card: match any subscript
`Robot interface modules communicate directly with rolxnic hard­
`ware. In general a rolxii is controlled by sending joint torques to an ap­
`propriate input/output port, as represented by flie torque-mode robot
`interface module. The current joint position and joint velocity of the
`robot can also be retrieved from the hardware interface. With some ro­
`bots, direct communication with the robot actuator is not possible.
`The robot provides its own controller, to which reference joint posi­
`tions must be sent. The position-mode robot interface is a module for
`this type of robot interface. Other
`actuators or computer controlled
`machinery may also have similar interface modules. The frequency of
`flicse modules is generally dependent on the robot hardware; some-
`
`limes it is fixed, other times it may be set depending on die application
`requirements.
`The sensor modules are similar to the robot interface modules, in
`that they communicate with device hardware, such as force sensors,
`tactile sensors, and vision subsystems. In the case of a force/torque
`sensor, a 6-DOF foredtorque sensor module inputs raw strain gauge
`values and converts tliem into an array of force and torque values, in
`Newtons and Newton-meters respectively.^ For a visual servoing ap­
`plication [18], much of die reading and preprocessing of images is
`performed by specialized vision subsystems. These systems may gen­
`erate some data, from which a new desired Cartesian position is de­
`rived. as illustrated by the visual servoing interface module.
`The teleoperation input modules are also sensor modules. They
`have been classified separately in order to distinguish user input from
`other sensory input. In our control module library the teleoperation
`modules read from a 6 DOF trackball, thus both modules are similar.
`Tlie difference is the type of preprocessing performed by each mod­
`ule, allowing the trackball to be used either for generating velocities
`(which can be integrated to obtain positions), or force, for when the
`robot is in contact with the environment.
`Trajectory generators are another way of getting desired forces
`or
`positions into the control loop. The input may come from outside thc
`control loop, such as from the user (e.g. keyboard), from a predefined
`trajectory file, or from a paili-planning subsystem.
`Differentiator and integrator modules perform lime differential and
`integrals respectively. For example, joint velocities may be obtained
`by differentiating joint positions. Only the value of the current cycle
`is supplied as input. Previous values are not required, as the modules
`^e designed with memory, and keep track of the positions and veloc­
`ities of previous cycles. The current lime is assumed to be known by
`all modules.
`Digital controller modules are generally the heart of any configura­
`tion. In our sample library, we have trajectory interpolators, a PID
`joint position controller, a resolved acceleration controller [11 ]. an im­
`pedance controller [6], and other supporting modules such as forward
`and inverse kinematics, Jacobian operations [19], inverse dynamics
`[8], and a damped least squares algorithm [29j. Given the proper input
`and output port matching, various controller modules can be integrat­
`ed to perform different types of control. Sometimes a particular
`con-
`trol configuration will not need all of its inputs. Those inputs are often
`set to zero. The zero module provides a constant value 0 to an input
`stream. Theoretically this would be a single task wliich always copies
`the constant variable to the global state variable table. However, in
`practice, tlie global state variable table only has to be updated once,
`after wlfich lime the module no longer has to execute, thus saving on
`lx)th RTPU and bus bandwidtli. This practice is erjuivalcnt to setting
`flic frequency of task zero to infinity.
`Many of the modules require initialization information. For
`exam-
`pie, flic PID controller module requires gains, and forward kine­
`matics and Jacobian module requires the robot configuration. Uiese
`values can also be passed via the global state variable table, and
`are
`read only once from flie table. However, for simplicity in our dia­
`grams, we have not shown these initialization inputs.
`Given a library of modules, several legal configurations may be
`possible. Fig. 4 shows one possible configuration for a telcopcratcd
`robot with a torque-mode interface. Each module is a separate task
`and can execute on its own RTPU, or multiple modules may share the
`same RTPU, without any code modification. Tlie state variable table
`mechanism allows the freciuency of each task to be different. Tlie
`sc-
`lection of frequencies will often be constrained by the available hard-
`I'or consisiciicy among modules, all input and output variables have
`by the systeme internaiionale (SI).
`
`units defined
`
`327
`
`Page 8 of 13
`
`

`
`J
`
`t
`
`Telfdperation In^ut Modules.:; ^
`6-DOF
`6-DOF
`trackball
`trackball
`x-velodty
`force
`
`• :
`
`w
`
`:'fr6m;VackbSl|;;/:: ' '
`. raw referehde.'dafalV
`
`V T
`
`• :frbrti trackball;
`raw:referencedata
`
`: Robert InlSrfaca Modules
`
`V'.^r:':^
`
`i torque-mode
`robot
`interface
`
`^ :
`•'.
`
`■
`
`pigilaCCOTfrolIers
`
`“N
`
`Cartesian
`, trajectory
`interpolator
`
`:
`.. .»-
`
`' “m—b
`
`forward
`kinematics
`and Jacobian .
`\
`
`frptri robot:
`■.rtp 'rdbdt: ■' S "
`raW'^qtie::;.--
`^ '^'i^Wloirit:?
`ppsitfon idatta;. 'CdfTifTtarid T;- ■'
`
`®rrk->[ joint pos/vel
`trajectory
`i
`interpolator
`
`inverse
`kinematics
`
`wm
`
`> ,posiiion-mode 0
`m
`. e,r.::7!
`‘
`" robot
`• ' ■
`.®rh' ■
`interface
`
`■.;i:lr6rh';rbbqiA.
`raw joint ;
`'■■•pp^yeldati;
`Vi
`
`■•Mrbbot;';
`joi,ritm6v'e:y/'
`^ajmmand ■;,;
`E/
`DlfferenllatbpB ahdIMpgralbrs ■ i
`
`PID joint
`position
`controller
`
`► u .
`'
`
`' ®iri
`- : •
`0
`
`■M
`»*
`resolved
`: Xd acceleration f->;u
`•xm
`controller
`
`inverse
`dynamics
`
`•Tr:'i
`
`• .
`. . ®m
`
`j-> Jacobian
`multiply
`
`xd"--+
`
`Jacobian
`transpose
`
`'^m
`
`^r
`
`time a;
`%Z.
`:v.: differentiator
`:a\\__________
`
`.H- .■
`• ' '
`
`■2y.-
`
`v_
`
`^rn-H>
`time . . ..
`Xm-W
`integrator
`, *m
`■ y V^
`
`X,m '
`
`impedance
`controller “
`
`■ u
`
`zero
`
`■s
`
`-►..xj:
`
`{, Trajectory Geherators : i; ■
`trajectory
`trajectory
`generator
`generator
`x-position
`0-position
`Fa
`from user, file,
`froiTi;user,:'file'.':'. :
`iror path-plan.ning. , or pathiipiannjrjg
`, . subsystem;:; :
`i '.subsysterri' .
`
`r
`damped
`least squares f^ ®r'.
`"N .
`from t't sensor
`^ 0
`y :
`; raw. strain
`gauge data.
`y V.
`
`Z'
`
`: Sensor Mpdutes:;
`6-DOF : ^
`force/lorque
`sensor
`
`'
`
`visual
`servoing
`interface
`
`W
`, A:;frpjn.yisipri: A.AA ■;
`''■rsubsyslemiA';; ;a.''
`
`I’lg. 3: Sample Control Module Library
`
`ware. For example, the robot interface may require that a new torque
`be supplied every 2 msec cycle time (500 Hz frequency), while the
`trackball may only supply data every 33.3 msec (30 Hz frequency).
`Digital control module.? do not directly communicate witJi hardware,
`and can execute at any frequency. Generally the frequency for the con­
`trol modules will be a multiple of the robot interface frequency. When
`using tlie state variable table for corrununication between the mod­
`ules, any combination of frequencies among tasks will work. This al­
`lows frequencies to be set as required by the application, as opposed
`to being constrained by the communications protocol.
`
`X r
`
`^ 0
`m
`Jacobian
`<—
`4— ^
`multiply
`
`'’ forward
`kinematics ^
`0m
`and Jacobian)
`
`C zero
`
`>
`
`fBsolvod
`.... accelsration
`controller /
`
`u
`
`6-DOF ^ ^
`tractoall _ ^
`l^x-velocity
`
`time
`Integrator
`
`0
`m
`
`0
`
`u
`
`rpr
`inverse
`J dynamics
`
`from trackball:
`raw reference
`data
`
`-V 0_.
`pOfqua-mortftX "
`robot
`^ Inteiiace J—~
`
`n °m
`
`to rc^t:
`from robot:
`raw torque
`raw Joint
`position data commar>d
`
`Fig. 4: Example of module integration: Cartesian tcicopcratlon
`
`328
`
`B. Reusable Modules and Reconfigurable Systems
`The primary goal of the global state variable table mechanism is to
`integrate reusable control modules in a reconfigurable, multiprocessor
`system. The previous section gave examples of control modules, and
`a sample configuration. In this section, we will give an example of
`reconfiguring a system to use a different controller, without changing
`the sensor and robot interface modules.
`Fig. 5 shows two different visual servoing configurations demon­
`strating the concept of reusable modules. Both configurations obtain
`a new desired Cartesian position from a visual servoing subs