Consol ida ted Fuel Reprocess ing Program

CONF-840 4 1 3 — 7

DE84 0 1 1 4 5 9

CONTROL SOFTWARE ARCHITECTURE AND OPERATING MODESOF THE MODEL M-2 MAINTENANCE SYSTEM

P. E. Satterlee, Jr. and H. L. MartinInstrumentation and Controls Division

J. N. HerndonFuel Recycle Division

Oak Ridge National Laboratory*Oak Ridge, Tennessee

Paper for presentation at theAmerican Nuclear Society Topical Meeting on

Robotics and Remote Handling in Hostile Environments

April 1984Gatlinburg, Tennessee

By acceptance of this article, thepublisher or recipient acknowledgesthe U.S. Government's right toretain a nonexclusive, royalty-freelicense in and to any copyrightcovering the article.

*0perated by Union Carbide Corporation for the U.S. Department ofEnergy.

DISCLAIMER

This report was prepared as an account of work sponsored by an agency of the United StatesGovernment. Neither the United States Government nor any agency thereof, nor any of theiremployees, makes any warranty, express or implied, or assumes any legal liability or responsi-bility for the accuracy, completeness, or usefulness of any information, apparatus, product, orprocess disclosed, or represents that its use would not infringe privately owned rights. Refer-ence herein to any specific commercial product, process, or service by trade name, trademark,manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recom-mendation, or favoring by the United States Government or any agency thereof. The viewsand opinions of authors expressed herein do not necessarily state or reflect those of theUnited States Government or any agency thereof.

Of »si»i«"is

ABSTRACT — The Model M-2 maintenance system Is thefirst completely digitally controlled servomanipula-tor. The M-2 system allows dexterous operations to beperformed remotely using bilateral force-reflectingmaster/slave techniques, and its integrated operatorinterface takes advantage of touch-screen-driven menusto allow selection cf all possible operating modes.The control system hardware for this system has beendescribed previously.* This paper describes the archi-tecture of the overall control system. The system'svarious modes of operation are identified, the soft-ware implementation of each Is described, systemdiagnostic routines are described, and highlights ofthe computer-augmented operator interface arediscussed.

INTRODUCTION

The Model M-2 maintenance system is the firstimplementation of a master/slave servonanipulatorthat utilizes a totally digital control system. TheM-2 maintenance system Is currently being used as aprototype servomanipulator for the Remote Operationsand Maintenance Demonstration (ROMD) Project at theOak Ridge National Laboratory (ORNL) to demonstratethe feasibility of remotely maintaining chemical andmechanical process equipment in a mocked-up zero-man-access nuclear fuel reprocessing facility. The ORNLFuel Recycle Division is developing this technologyfor use in advanced nuclear fuel reprocessing, andtotally remote operation and maintenance of the facil-ity are fundamental to its operation. The bilateral,force-reflecting, master/slave servomanipulator willbe the principal tool used for maintenance. Photo-graphs of the M-2 master station and slave packageappear in Figs. 1 and 2 respectively.

*Research sponsored by the Office of Spent FuelManagement and Reprocessing Systems, U.S. Departmentof Energy, under contract No. W-7405-eng-26 with UnionCarbide Corporation.

Fig. 1. M-2 maintenance system master station.

Fig. 2. M-2 maintenance system slave package,

The Model M-2 maintenance system consists ofseveral integrated components. The remotely operatedslave package includes two 23-k.g (50-lb) continuouscapacity slave manipulator arms, three color cameras(two are mounted on four-degree-of-freedom camera-positioning arms), and an integral 230-kg (500-lb)capacity hoist for lifting heavy loads. The mastercontrol station consists of two master manipulatorarms, three color TV monitors, camera-positioning andlens controls, hoist controls, slave package azimuthcontrols, and an operator interface that utilizes amenu-driven CRT display with integral touch screen foroperator input. Overall system components aredescribed in detail in ref. 2.

The Model M-2 was developed jointly by SargentIndustries' Central Research Laboratories (CRL)Division, and ORNL. CRL designed the mechanical com-•ponents of the M-2 and fabricated the entire mechani-cal and electrical package. CRL also developed thebrushless dc motor/encoder packages, and ORNL designedthe control system hardware and software.1 This paperwill detail the software architecture and the result-ing operational modes of the M-2 manipulator.

The control system of a master/slave manipulatormust provide two primary functions. First, stabilitymust be provided while maintaining a one-to-one geo-metric relationship between master and slave. Second,force-reflection sensitivity should approach whalik theoperator would feel if performing the task directly.If these two objectives are met, the operator'sability to perform tasks remotely is greatly enhanced.A simplified block diagram of a single-degree-of-freedom control loop is presented in Fig. 3. Thisfigure depicts the general signal flow in a typicalM-2 control loop. Notice that the control loop isrelatively straightforward. There are, however, a fewenhancements to improve manipulator response which aremade possible by the fact that the basic controlalgorithms are implemented in software. For example,a low velocity friction compensation technique is usedto increase manipulator sensitivity to light loads.

CONTROL SYSTE1 ARCHITECTURE

The overall control system hardware remainsessentially as described in ref, 1. Only one majorchange has been implemented to improve manipulator

FORCEREFLECTrRATIO

AMPLIFIER(CURRENT LOOP)IDUTCCVIN

AMPLIFIER(CURRENT LOOPIOUTOCVIN

Fig. 3. Simplified block diagram of a M-2manipulator control loop.

response and stability: data from the analog tachom-eters has been removed from the control loops andreplaced with a software derivation of velocity fromposition data. The result is a totally digital con-trol system. (The only analog sensor still in thesystem is motor current, and this parameter is pro-vided for future statistical analysis only and doesnot enter into control algorithms.) Having totaldigital control greatly enhances short- and long-termstability. The analog tachometer sensor introducednoise into the control loops, which necessitated lessthan optimum tuning of motor response. It alsorequired special initialization techniques to compen-sate for long-term drift. The software finite dif-ference approximation of velocity has eliminated thisproblem, and control system tuning has been pushed tothe limits of the system's mechanical response. Theresult is increased sensitivity, no joint jitter, andfaster joint response.

The M-2 manipulator control system is comprisedof three basic components: the joint controllers (oneper joint, 28 total), the communications traffic con-troller (one per arm, 4 total), and the system monitor(one per system). In addition, the integral hoist iscontrolled by a processor identical to the joint con-troller, but with firmware appropriate to achievehoist velocity control instead of typical manipulatormotor position control. The two camera systems arecontrolled by individual camera processors that usethe same microprocessor as the joint controllers.This allows the use of the same communication firmwareused in the joint controllers. A simplified blockdiagram of the system hardware is shown in Fig. 4.All processors (except the system monitor processor)are Intel 8031 single-chip microcontrollers imple-mented as special-purpose, single-board microcom-puters. Real-time, high-speed communication betweenprocessors utilizes the high-speed universal asynchro-nous receiver transmitter (UART) built into the Intel8031 microprocessor. Low-speed communication betweenthe Zilog Z80-based system monitor (SM) and the masterarm traffic controllers is provided by simple RS-232Cserial links.

SYSTEM MONITOR• Z8O- 4MH<

« BASIC COMPLIER

• OISK STORAGE• SIOO COMPATIBLE

FOR I /O EXPANSION

• VOT

-MONITOR WITHTOUCH SCREEN

CRANEOPERATORCONSOLE

MANIPULATOROPERATOR CONSOLS

HIGH SPEEO INTERPROCESSOR SERIALLINKS

HIGH SPEED INTERPfDCESSOR SERIALLINKS

T C - TRAFFIC CONTROLLER

JC - JOINT CONTROLLER

CC-CAMERA ARM CONTROLLER

HC-HOIST CONTROLLER

Fig. 4. Block diagram of M-2 system controlhardware.

The key processor In the system is the mastertraffic controller (TC). The TC in each arm providesorderly command and data exchange between all proces-sors associated with its arm. In addition, the TC ineach master arm routes commands and data to/from thesystem monitor and the joint controllers (JC). The TCis also the system timekeeper. All data and commandinput/output (I/O) occurs on specified time ticks.This is especially important now that velocity data isderived in software. To perform these tasks, the TCprovides sequenced address information (which initi-ates loop data exchange) on the high-speed serial linkbetween joint controllers. The TC also receives andtransmits data and commands between the system monitorand the joint controllers. The JC status datareceived by the TC is checked for fault conditions androuted to the system monitor. If a problem occurs,the TC can be commanded by the system monitor to routeall data from the ailing JC back to the system monitorfor complete analysis. The operator can easily viewall parameters of the ailing joint and take appropri-ate corrective action.

Address and command data from the master TC aretable driven. The system monitor fills a table in themaster TC's memory with joint address and taskdescription data, and all or part of the table can bechanged by the system monitor. Each frame consists of12 channel times, and for each channel time there is acorresponding location in the TC command/ data table.Channel time zero is reserved to activate the remoteslave TC; channel times 1 through 7 normally controlthe master and slave JCs for the arm associated withthat master TC; channel time 8 is used on the rightmaster TC only and controls the remote hoist proces-sor; channel time 9 controls that arm's camera proces-sor; and channel times 10 and 11 normally are notused. Each channel time entry can be set up to con-trol any particular processor in the system. Althoughthe above channel assignments are the norm, specialcases arise. For example, a set of constants must bedownloaded to each JC in the system to change forcereflection ratios, father than take a joint out of anormal mode (such as master/slave) and replace thetable entry with constants data, the spare entries(10 and 11) are used. This allows the change of con-stants without having to interrupt master/slave con-trol. Each joint's address and unique set of con-stants is loaded into entries 10 and 11, one master/slave pair at a time. Thus all joints continue tooperate in the same mode as before the constants loadmode was initiated. This scheme is possible because

each joint has a unique address and the command datafrom the TC is obtained by encoding the address in anyof the 12 entries in the TC command/ data table. EachJC is 'awakened' by receiving its unique address andis not dependent upon what time data is receivedwithin the frame.

Any particular JC could, in fact, be awakened andcommanded to execute a function as many a& 12 timesper frame. In reality, each JC is awakened by everyTC address transmission. However, if the transmittedaddress does not match the particular JC's address,the remaining data for the channel time is ignored.In such instances the JC normally executes the localdata sampling module. If properly awakened, the JCcontinues to receive the remaining data of that chan-nel time and then executes the software module(s)commanded by the TC. Each JC gets its unique addressby the motherboard slot it occupies. During power-on-start of each JC, the address encoded by hardwarestrapping of the motherboard is read and subsequentlyused by the JC firmware to identify the JC's address.The firmware in every JC is identical; it is madeunique by the JC's slot address and the unique set ofconstants downloaded to it during system initializa-tion. Having all JC firmware identical simplifies JCsoftware development and maintenance. Custominationof the system JCs is achieved by the programmabletable array in the master TC.

There are seven JCs for each of the four arms inthe M-2 system, giving each joint motor its own dedi-cated JC. Within the firmware of these processorslies the joint control algorithms. Each JC samplesall data associated with its joint (position, veloc-ity, current, and status) and communicates these datain real time to the corresponding remote JC. Thisdata sample/exchange has been fixed at 53 Hz. Theoriginal paper indicated the mimiraum desired framerate of the M-2 to be 60 Hz,1 but it has been deter-mined experimentally that frame rates as low as 45 Hzare acceptable (causing no instabilities due to inade-quate motor control rate). The 53-Hz rate was chosento simplify velocity derivation from position data.The analog tachometer was adjusted to provide a veloc-ity reading equal to the motor drive command when themotor is unloaded. This setting permits simplifieddrive command computation, given the desired torqueand motor velocity. The velocity derivation u.;es asimple position change versus time algorithm. Theposition change per frame (at 53 Hz) exactly equals

the motor driving command when the motor runsunloaded, and thus the velocity derivation equals theoriginal analog tachometer reading without the noiseand drift problems. No changes were needed in thecontrol algorithms when the system was converted tosoftware vslocity derivation. The derived velocity isactually an average velocity over one frame, and thussome phase error is introduced. At low to mediummotor velocities this phase error is negligible, andat high velocities phase error has little effect onthe computation of motor drive command. The smallvelocity phase error introduced, therefore, causes nospecial problems. The software-derived velocity elim-inates tachometer analog drift and ripple problems.As a result,-^the M-2 system can be tuned to obtainnear maximum \motor response with no stabilityproblems.

Real-time joint control is incorporated in thefirmware of the joint controllers; the lowest level ofsystem control resides here. Each JC can be commandedto do one or more specific control tasks per frame.There are 13 JC main software modules. It is thecombinations of these modules, as commanded by thesystem monitor and traffic controllers, that effectthe various operating modes of the M-2 manipulator.For example, the most important operating mode is thebilateral, force-reflecting, master/slave mode. Toput a joint pair into this mode, the system monitor/traffic controller commands three JC modules to exe-cute at the frame rate: local joint data sampling,data exchange between local and remote JCs, andmaster/slave closed-loop control. Each individual JCprocessor is provided with sufficient software modulesthat can be called in a prescribed order to effectwhatever operating mode the manipulator operatordesires. This technique increases flexibility andprovides the control environment needed to achieve allpresent and future operating modes of the Model M-2manipulator. Actual manipulator operating modes areimplemented in a high-level language (currently com-piled BASIC), while control level algorithms areprogrammed in assembly language. Future changes inthe system software will probably occur only in thehigh-level language of the system monitor. A currenteffort is centered on translating the system monitorsoftware package to FORTH, the language, chosen for theAdvanced Servomanipulator Project at ORNL.3 Improvedoperator interfaces now being developed for theadvanced servomanipulator will be readily transport-able to the M-2 once the system monitor software hasbeen translated to FORTH.

10

Of the 13 JC software modules, 10 are concernedwith joint motor control. The motor control modulesinclude position, velocity, current drive, closed-loop

. control, synchronize, status, index, calibration,brake, and deadman. The remaining three JC softwaremodules, which are considered noncontrol modules, arecommunications, data sampling, and mathematics sup-port. The ultimate goal of the motor control modulesis to compute a motor drive signal based on local andremote joint parameters (position, velocitys forcegain, etc.) The motor drive calculated by controlalgorithms is intended to command motor current(torque) in order to assure torque reflection throughthe system. The amplifiers used to develop drivecurrent are pulse-width-modulated (PWM) voltage ampli-fiers. This requires software determination of thevoltage required to produce the desired motor current,which is calculated using motor characteristics andmotor velocity. This motor drive module allows thesystem to function in a current-controlled mode eventhough the amplifiers are of the voltage output type.The JC can command PWM voltage to only 8-bit preci-sion, and it was apparent during early testing thatmore precision was needed for smoother, more resolvedcontrol. A voltage dither scheme has been implementedto effectively increase voltage drive precision. ThePWM voltage drive command that is time-multiplexed atnearly 10 kHz adds approximately 3 more bits of preci-sion. This dither rate is much higher than the systemmechanical response. The smaller discrete stepsbetween command changes result in smoother operationand highly resolved torque control.

The sensor (position, velocity, status, etc.) andmotor drive modules support general manipulator opera-tions. Status is especially important in diagnosingsystem performance. Motor temperature, amplifiertemperature, and amplifier current trip status aremonitored at the frame rate. Corrective action (suchas setting brakes) enables deadman operation when anonstandard condition is detected.

Standard control loops are implemented by input-ting sensory data to appropriate data processing mod-ules. The output is then processed by PWM drive algo-rithms. An integer mathematics subroutine package wasdeveloped to simplify algorithmic module development.The mathematics package includes addition, subtrac-tion, multiplication, division, comparison, andscaling for 8/16-bit signed integer arithmetic. Themathematics package is used throughout by the varioussoftware control modules.

11

Position encoders on each joint motor produce apair of phased pulse trains from which the magnitudeand direction of rotation are determined. Relativeposition is determined by pulse counting, while direc-tion of motor rotation is determined by the sign ofthe phase angle. A special hardwired circuit on theJC processor board decodes the position pulse trainsinto two mutually exclusive outputs. One output pro-duces one pulse for each clockwise step of the motorwhile the other produces one pulse for each counter-clockwise step. The two 'up/down' outputs are inputdirectly to counter inputs of the 8031 JC microproces-sor, and each one clocks its own up or down 16-bitregister. The position of the motor at any given timeis simply the difference between the up/down counterregisters. Scale factors are used to account for thedifferent gear ratios of the master and slave joints.These scale factors ensure one-to-one correspondencebetween master and slave joints. The scale factorscould also be used to magnify or reduce master jointmotions as seen by the slave.

Originally, motor velocity was determined using adc tachometer and an analog-to-digital converter, butthis arrangement introduced noise and drift into thecontrol loops. An approximation of velocity can beobtained by counting motor position change versustime. Since precise knowledge of position and time isavailable in the M-2 system, derived velocity seemedpractical. A simple algorithm is used to approximatevelocity equal to the position change over one frametime. As noted earlier, a frame time fixed at 53 Hzproduces a derived velocity equal to the originalanalog tachometer reading. The implementation ofsoftware-derived velocity has significantly improvedsystem stability and response. The added stabilityallows higher loop gains, which produce better systemresponse. The derived velocity signal is scaled bythe same scale factors used for position to ensurejoint synchronization.

A synchronize module se«:s the master joint'sposition equal to the current slave's position. Thismodule is used to lock the master to the slave anytime the joints become misaligned. On power-up, forexample, all master and slave joints are put in thismode, so that the joints will be synchronized and nottry to seek random locations when motor power isenabled. Calibration between master and slave canthen be obtained in one of two ways. An indexingmodule can be invoked to place the slave in a hold orbrake mode while the master power is shut off. This

12

allows the operator to move the master to a positionthat appears visually to be the same as the slave'sposition. On exit from the indexing module, the syn-chronization module is called to lock the jointstogether again. A second technique for joint calibra-tion utilizes the calibration module of the slaveprocessor. When commanded to both master and slavejoints, this module causes different actions dependingupon the type of joint (master or slave). For themaster, the joint's motor is disabled and the joint'sposition is synchronized to whatever position isreported by the slave. Invoking the calibrationmodule in a slave processor causes a small constantmotor command to be applied until the joint reaches amechanical end of travel. At this instant, the slavejoint's position is set equal to zero. A special formof the master/slave module is then used to drive eachslave joint back to a predetermined physical positionthat leaves the slave arm in what is called a normalstarting stance. The operator then physically posi-tions the unpowered master arms in the same normalstarting position, and the synchronization module isinvoked to lock the arms together.

The brake module, when invoked on a slave joint,causes the slave position setpoint to be set equal tothe slave position at the time the brake module wasfirst invoked. The closed-loop control module thenmaintains a constant slave position using an appropri-ate motor PWM command. If the brake module is left ineffect for a predetermined time (approximately 2 min),the slave electromechanical brake is activated and themotor power is removed. The technique allows smoothbraking as needed, yet continuous long-term brakingautomatically removes motor power to minimize motorand amplifier heating. Invoking the brake module on amaster joint simply turns off master power and setsthe deadman condition.

A special deadman module is provided for operatorsafety. The master grips contain an infrared opticalsensor to detect the operator's hand. When the opera-tor is not grasping the grip, the proximity sensorshuts down master motor power. This prevencs anirregularity in the system that might cause the masterarms, if powered, to move abruptly toward the operatorand cause possible injury. The nongripped state isreported to the joint controllers and invokes thedeadman condition. This condition causes specialaction of the master and slave JCs before normaloperating power is reapplied to the master joints.Deadman is a two-sequence condition. Master motorpower off occurs at the start. When the power iscommanded back on, it is limited to a safe level until

13

master/slave resynchronization is obtained. Thismodule is best demonstrated by the typical systemresponse to the operator's release of the master gripand subsequent regrip. When the operator lets go ofthe master grip while the system is i.n normal master/slave mode, the slave locks up; and, if the slave armis supporting a load, the slave would continue to holdthat load even though the master arm becomes unpow-ered (limp). (While released, the master arm willtend to coast to a neutral position.) When released,the master arms are placed in deadman conditionimmediately as each master JC directly samples thegrip proximity sensor. When the operator engages themaster grip to resume master/slave operation, a gentletug is felt as the master JCs attempt to movethe master arm joints into the position they were inwhen the grip was released. When synchronization isachieved, full operating power to the masters is per-mitted, and the system resumes master/slave operation.

Other conditions can occur which automaticallyinvoke the deadman state. For example, a temporaryamplifier shutdown can occur in either a master orslave joint due to an unexpected large load change.The joint controller detects the amplifier currenttrip and invokes the deadman condition before attempt-ing to repower the amplifier. This is necessarybecause position correspondence is uncertain duringany loss of motor power, and recovery requires saferesynchronization.

A special diagnostic status module is responsiblefor overall joint motor and amplifier integrity.Alarm conditions, when detected, are reported immedi-ately to the TC/SM, and certain conditions are actedon immediately at the JC level. Three types of statusdata are sampled by the JC at the frame rate: ampli-fier/motor temperature warnings, amplifier/motor tem-perature faults, and joint sensor data (position,velocity, motor current, etc.). The warnings arerouted to the TC/SM and displayed on the operator'ssystem control CRT. If ignored, a warning couldbecome a fault and the affected joints could be shutdown automatically by the associated JCs. Normaloperator procedure is to request the SM to display allparameters of the afflicted joint(s) and then correctthe problem. A fault condition automatically shutsdown the faulty joint and invokes the deadman condi-tion. Some types of faults are automaticallycorrected by the local JC.

Many of the software modules developed for thearm joint controllers are useful in other parts of theM-2 maintenance system. The hoist controller, forexample, uses software almost identical to the JC,and a slight modification of the standard master/slaveclosed-loop control module achieves hoist velocitycontrol rather than joint position control. A self-centering potentiometer on the operator's system con-trol panel provides operator input of hoist velocitycommands. This potentiometer produces an analog valuewhich is sampled by the system monitor and then routedto the right master TC along with the hoist processoraddress and velocity mode command. The TC commandsthe hoist controller at the frame rate to produce avelocity proportional to the operator's hoist controlpotentiometer output. The hoist controller receivesthe requested hoist velocity and adds it to a specialsetpoint position register. The hoist amplifier isthen commanded using the standard closed-loop controlmodule with the special setpoint position registervalue as input. If the hoist velocity command isconstant, the setpoint position register will changeat the frame rate by the amount commanded. The effectis a constant position change or constant velocity.The sign of the velocity command can be positive ornegative, thus providing bidirectional velocity con-trol. The resulting velocity of the hoist motor istherefore proportional to the commanded velocity. Thehoist motor velocity is constant if the commandedvelocity is constant, regardless of the load, as longas the commanded velocity does not exceed the velocityof the hoist when loaded to full capacity.

OPERATING MODES OF THE M-2

The overall goal of the M-2 control softwarearchitecture is to provide a set of real-time controland communications modules sufficient to permit opera-tion of the M-2 manipulators in any one of severaloperating modes. Once the low-level set of moduleswas completed and tested, the command and execution ofthese modules could be accomplished by a single high-level program running on the system monitor. The SMprovides a simple interface between the operator andthe sometimes complicated module commands needed tocontrol the system. A set of M-2 operating modes wasdeveloped to assist the operator in performing remotemaintenance tasks. All operating modes are commandedby push buttons on the master grips or by touch-screeninput to the operator's CRT control panel. (A photo-graph of the operator control panel appears inFig. 5.) The various operating modes will be dis-cussed, with some examples of how they are achieved.

15

M nil 11 ii —

Fig. 5. Operator console for the M-2manipulator.

16

The most important operating mode is the standardbilateral, force-reflecting, master/slave mode.Several low-level modules must be invoked before thesystem can be placed into the master/slave mode.However, all low-level commands needed to effectmaster/slave operation are essentially transparent tothe operator. On power-up and subsequent systeminitialization, system integrity is analyzed andreported to the operator. If all is well, the opera-tor simply touches the CRT at a specific location andthe high-level system software takes over the task ofcommanding joint synchronization and then master/slavecontrol mode. Once the system is operating, theoperator has options to

1. Change force reflection ratio;2. Index master relative to slave;3. Perform slave absolute calibration;4. Set slave brakes;5. Operate hoist;6. Position cameras and control camera power,

lighting, and lens; and7. Request system status report.

Future planned options include

1. Robotics mode for the slave,2. Automatic camera tracking of an arm's end

effector, and3. Complete system data logging for statistical

analysis.

The operator can choose from one of five force reflec-tion ratios. Four of them collectively provide a goodrange of bilateral force reflection ratios (1:1, 2:1,4:1, and 8:1). The fifth is infinity, or unilateralmaster/ slave control, which is provided for futurestudies that will address operator efficiency when th<manipulator system provides force reflection or noforce reflection. To change the force reflectionratio, the operator merely touches the desired ratioon the face of the CRT and the high-level system pro-gram uses an index into a force constants array todownload the new constants to the TC and ultimately tothe JCs. As stated earlier, this is done using thespare table entries of the TC, and thus this functionis transparent to the operator. The operator noticesonly the change of force in the master as theconstants loading ripples through the joints.

17

The index mode is normally applied to only theupper six degrees of freedom. (Rarely would theoperator want to index the tong joint.) Although theoperator can selectively index one or more joints(through the CRT/touch screen), the upper six degreesof freedom also can be commanded by pressing a smallpush button on the master grip of whichever arm theoperator wishes to index. As long as the switch isdepressed, the SM instructs the TC to command theupper six joints to execute the index control module.When the index push button is released, the SM com-mands the synchronize mode and then places the sixjoints back in the master/slave mode. All of this isdone by manipulating a command data array in the SMand then loading the array into the TC control table.

All position sensors in the manipulator arms arerelative sensors that lose calibration whenever poweris shut off. Situations arise in which it is desir-able to have an indication of the absolute position ofthe slave joint motors. The technique used to cali-brate the slave position sensors is first to drive theslave motors at reduced power toward a mechanical endlimit. Tliis position is then temporarily set equal tozero, and a special master/slave mode is commanded todrive the slave motors to a predetermined positionrelative to the mechanical end limit. This 'normalstance' position is then set equal to zero and can bedetermined at any time. This absolute calibrationmode is entered by simple touches on the CRT touchscreen. The high-level program in the SM first com-mands the TC/JCs into calibration mode, then checks tosee that all joints requested for calibration havereached the end limits, and, finally, uses the limitedvelocity master/slave mode to move the slave arm intonormal stance. The limited velocity master/slavemodule in the slave JC is identical to the standardmaster/slave module but has a 20% limit imposed on themaximum motor command sent to the motors. The resultis limited velocity. Movement of just the slave isobtained by not addressing the master JCs. Theequivalent of a master data packet is sent to theslaves from the SM/TC and allows robotic control ofthe slave. After the slave joints are positioned innormal stance, "synchronize master and slave joints"is commanded followed by master/slave mode with thedeadman condition in effect. This sequence of eventsseems complicated, but the high-level subroutinesdeveloped permit such complicated sequences with justa few subroutine calls.

18

The operator can set the slave brakes in one ofseveral ways, the simplest of which is to release themaster grip. In this case, the optical deadman tensordirectly shuts off master power and informs the JCsthat the deadman condition exists. The JCs1 internalsoftware handles the condition transparent to thehigh-level software in the SM. As stated earlier,system brake setting for the master implies masterpower off; for the slave, it implies closed-loop con-stant joint positioning for about 2 min and thenmechanical brake setting with slave motor power off.If the operator is holding a critical load that may bedropped by slight motions while releasing the grip, asecond method of brake setting can be used: pushingone of two push buttons on the master grip. One push-button locks only the slave tong, while the otherlocks all seven degrees of freedom. Thus the brakeset/deadman modes can be initiated safely while theoperator has a solid grip on the master. The operatorcan then release the master grip and after regrip-ping it can operate the same push buttons to releasethe system. The third and final method of systembrake setting is available from the operator's CRTtouch screen. This method provides individual or all-joint brake setting. When it is invoked, a menuappears that allows the operator to select all or onlya single joint.

The integral hoist is controlled by a hoist con-troller (HC) in the right arm slave electronics pack-age. The HC is a single-board computer identical tothe JCs but with special hoist control firmware. Thehoist motor/amplifier package is the same as the slavemotor/amplifier packages. A single self-centeringpotentiometer located on the operator system controlpanel allows velocity control of the hoist. The SMhigh-level software package reads the hoist controlpotentiometer approximately three times per second.If the reading is outside a small deadband centered onzero, the value is passed directly to the right TC andultimately to the HC. If the reading is within thedeadband, a zero command is sent.

The three camera systems are controlled by a setof self-centering potentiometers. Digital controls(camera power and lighting) are obtained by selectingthe camera menu on the operator's CRT touch screen andtouching the desired function. Individual camera lenspotentiometers are provided to control zoom, iris, andfocus. Camera positioning arm controls are four-degree-of-freedom joysticks. Like the hoist potenti-ometers, the camera controls are sampled at approxi-mately 3 Hz by the SM. A deadband of potentiometer

19

output prevents motion when the controls are not beingpushed. The SM high-level software scans the cameracontrols continuously and routes the commands to theTCs. The camera controllers (CC) receive the commandsand produce proportional analog signals for the cameracontrol motor amplifiers. The on/off digital controlof camera power and lighting is also sent with theanalog commands and results in digital outputs on theCCs. The digital outputs control solid state acrelays and directly operate the camera ac power andlight circuits. The CCs have only two operatingmodes. The one used for normal camera control hasjust been described and is called the velocity control-mode. A closed-loop position control mode also hasbeen developed for the four-degree-of-freedom camera-positioning motors. These camera joints are fittedwith potentiometers that encode the camera joints into12-bit absolute positions. Future efforts will usethis mode and the slave's end-effector position toautomatically point the camera at the slave's endeffector. This automatic camera tracking ability willbe very useful for 'finding' the arms when the opera-tor activates the system or needs to reposition thecamera and does not have time to do it manually.

System diagnostics are performed continuously bythe individual processors in the M-2 maintenance sys-tem. A reserved location on the operator's CRT dis-play shows overall system status. If all is well, asimple 'OK' message is displayed. Whenever one ormore joints report a warning or fault condition, theTC routes the condition to the SM. The reserved loca-tion for overall system status on the operator's CRTdisplay then identifies the faulty arm with a high-lighted, flashing 'WARNING' or 'FAULT' message. Theoperator can then touch the status bar on the CRTtouch screen and interrogate the system for the com-plete status of the faulty joint(s). Warnings areusually the result of heating because the operator hasused the arm above its rated continuous capacity longenough to cause amplifier or motor overheating. Oper-ation can continue for some time, but if it is ignoredtoo long, the fault temperature sensors could activateand shut down the overheated joint(s). System faultsare sometimas intermittent in nature and are correctedautomatically by the JCs. For example, if a warningis ignored and the overheated joint shuts down(faults), the jofnt cools rapidly. When the tempera-ture cools below the fault level, the joint is broughtback on-line with the deadman condition set. However,a warning will continue to be displayed until thejoint has a chance to cool to its normal operatingtemperature. A special feature of the M-2 status

20

routines is recording joint usage. If a joint ispowered and has a minimum preset velocity and/or posi-tion error, a special bit set in the status wordindicates that the joint is being used to do work(i.e., it is being moved and/or is supplying torque).This status bit is recorded by the TC and sent to theSM, which uses a real-time clock to time joint usage.The output of the timing routines drives a set ofelectromechanical timers (one per joint in thesystem), which indicate minutes of actual joint usage.The time data collected can also be displayeddynamically in units of seconds on the operator's CRTdisplay. This type of data will be used in time-motion studies of various maintenance system tasks.The data provide some insight into which joints willrequire the most maintenance and how often.

Future enhancements to the M-2 maintenance systemare being planned in three stages. A multiprocessor,68000-based microcomputer system is being developed toreplace the single-processor system monitor microcom-puter currently in use. The new SM will first be usedto collect all data for all JCs in both arms at halfthe present frame rate. The data will be collected onmagnetic tape while typical remote maintenance tasksare being performed, and statistical analysis of thisdata base will be used to answer questions aboutoperator efficiency. A second enhancement will be thetranslation of the high-level system software fromcompiled BASIC to FORTH. The converted FORTH packagewill run on the same Z80-based SM microcomputer usingthe same assembly language support package used withthe current compiled BASIC program. When the newFORTH high-level system package is running, the assem-bly language support package will be translated to acombination of high-level FORTH and 68000 assemblylanguage. At that same time, the multiprocessor68000-based system monitor microcomputer will be hard-ware interfaced to the M-2 manipulators and operatorcontrol panels. With an improved SM computer system,automatic camera tracking .and robotics operations willbe the first enhancements to the M-2 system. Thethird stage of improvements to the system will involvethe addition of some of the operator interfacescurrently being developed for the AdvancedServomanipulator Project at ORNL. Color graphics dis-plays and voice input/output will be major features ofthe improved operator interface.

21

SUMMARY

The M-2 maintenance system has been in use at theROMD facility at ORNL for more than six months, andoperating experience has verified that M-2 performanceexceeds original expectations. Sensitivity is betterthan expected, and response is adequate to performvarious tasks requiring dexterity. Comparison of theM-2 manipulators to other remote manipulator systemsusing analog control verifies the improved performanceobtainable by a microcomputer-based digital controlsystem. Since the M-2 maintenance system has beeninstalled, several software enhancements have beenadded at little engineering cost. Modularization ofthe control algorithms and sequenced execution ofthese modules by a single high-level program providesa simple vehicle for software changes. Ideas can becoded with a minimum of effort and made a permanentpart of the system if appropriate.

In retrospect, much has been learned concerningthe architecture and digital control aspects of aservomanipulator system. The use of graphic, menu-driven operator commands has improved operator learn-ing efficiency and system flexibility. Demonstrationof stable loop closure at 45 Hz proved to be wellbelow the range of original estimates (60 to 100 Hz).The ever-expanding capabilities of digital electronicswill allow more joints to be controlled from a singlemicrocomputer in future applications. Also, single-board computer systems are now available 'off-the-shelf to function as joint controllers, whereasduring the controls development of the M-2, special-purpose systems had to be designed from the chiplevel.

The value of intelligent diagnostics has beenwitnessed in debugging and maintenance troubleshoot-ing. Data logging and special robotic communicationneeds have made the use of parallel communications ina tightly coupled system appear to be the path topursue for future systems as opposed to the high-speedserial method implemented in the M-2. The advantagesof noise-free encoders appear to be significant,especially in velocity measurement.

The Model M-2 maintenance system will continueto be used to demonstrate remote repair and replacementof equipment in the ROMD facility. Significant studiesof reliability and operating experience will be carriedout as experience increases. With a sensitivity to apeak load ratio of 1:100, this entirely digitally con-trolled servomanipulator is an example of servomanipu-lation which will set the standard for future systems.

22

REFERENCES

1. H. L. Martin, P. E. Satterlee, Jr., andB. J. Bolfing, "Distributed Digital Processing forServomanipulator Control," Proceedings of the 30thConference on Remote System Technology, AmericanNuclear Society (1982).

2. J. N. Herndon, H. L. Martin, P. E. Satterlee,Jr., D. G. Jelatis, and C. E. Jennrich, "The State ofthe Art Model M-2 Maintenance System," Proceedings ofthe ANS Topical Meeting on Robotics and RemoteHandling in Hostile Environments, American NuclearSociety (April 1984).

3. H. L. Martin, W. R. Harael, S. M. Killough,and R. F. Spille, "Control and Electronic Subsystemsfor the Advanced Servomanipulator," Proceedings of theANS Topical Meeting on Robotics and Remote Handling inHostile Environments, American Nuclear Society(April 1984).

23