U.S. Department

of Commerce

National Bureau

of Standards

Proceedings of NBS/Air Force ICAM

Workshop on Robot Interfaces

January 1980

NBSIR 80-2152

Prepared for: Manufacturing Technology Division

Air Force Materials Laboratory

Air Force Systems Command

Wright- Patterson Air Force Base, Ohio 45433

100

.056

80-2152

1981

v_.

!

NBSIR 80-2152

• ' r

PROCEEDINGS OF NBS/AIR FORCE ICAM

WORKSHOP ON ROBOT INTERFACES

National Bureau of Standards

Library, £-01 Admin. Bldg.

rb 2 7 1981

0.' - —

DlJOO

, USh

no.

January 1981

Prepared for: Manufacturing Technology Division

Air Force Materials Laboratory

Air Force Systems Command

Wright-Patterson Air Force Base, Ohio 45433

U.S. DEPARTMENT OF COMMERCE, Philip M. Klutznick, Secretary

Jordan J. Baruch, Assistant Secretary for Productivity, Technology, and innovation

NATIONAL BUREAU OF STANDARDS, Ernest Ambler, Director

NOTICE

When Government drauiings# specifications* or other data are used

for any purpose other than in connection with a definitely related Government procurement operation* the United States Government

thereby incurs no responsibility nor any obligation uihatsoever*

and the fact that the government may have formulated* furnished*

or in any way supplied the said drawings* specifications* or other data* is not to be regarded by implication or otherwise as in

any manner licensing the holder or any other person or corporation* or conveying any rights or permission to manufacture* use

or sell any patented invention that may in any way be related

thereto.

Copies of this report should not be returned unless return is

quired by

notice on < security

specific

considerations*

document.

contractual obligations^

reor

For Early Domestic Dissemination

Because of its significant early commercial potential* this information* which has been developed under a U. S. Government program* is being disseminated within the United States in advance

of general publication. This information may be duplicated and

used by the recipient with the expressed limitations that it not

be published nor released to foreign parties without appropriate

licenses. Release of this information to other domestic parties

by the recipient shall be made subject to these limitations.

This legend shall be marked on any reproduction of this data in

whole or part. These limitations shall be considered void two

years after the release date on the data.
-flip firo" #*’»«r m— « r.?; nl *4. : »« *»^;ri9;/iit) Td i'ls ;»« Jl "fil>i4 i«

-4'T0<|iia3 ,'«^oy t»#|' T^ITtiW-;. f».f(f|''f<ti ea^ili ,^., i«ftiiBj*

l>'»#«blir*r 4.,\iM»i ni yaw *T0

' t-H jr'

‘

.•oip*v0<ii'4i

“'mj tfff i> i' .•-^" ', , ^ m'- 'f*" -•t i^'i *irt^- i9 9^k%*'} ^ ...

- ' --“ a ' itvi;.

®

fi

; a '«W

-Vyjsffl. :c, ,.

. tf- ^ • V V < ' IJ- •

-»i i.rt# #»»<>,a ir|yii«

ftnjn' b,#i%;>i'| 4ub

n«l riP|||MtT*»>p(<

lojf tk 0fiQkM9 ifnH

9^9km<$'i9 s{* ^t^ aW.tk ^ a i' I# if y #f"* A if «l|®v 0 ^ 34^«#«4^b *T<krtff of

hi 'b*^^ X’Wf flvtV'

oyf to<Pv» b«*t<bi f'(fp-3 itf T#'

v'ti

''
ROBOTICS SUPPORT PROvJECT

FOR THE AIR FORCE I CAM PROGRAM

Proceedings of the NBS/Air Force ICAM

Worfcshop on Robot Interfaces

June 4-6i 1980

Editors

Thomas E. Wheatley

James S. Albus

Roger N. Nagel

National Bureau of Standards

National Engineering Laboratory* CDPT

Industrial Systems Division

Programmable Automation

Washington* DC 20234

Prepared under

MIPR SY1455-78-00003

This is to certify that this report was prepared by U. S.

Government employees as part of their official duties and is

therefore a work of the U. S. Government and not subject to

copyright.
Ck'

W:

V ^1

'vf6 i —"' ’1^. 3

,y

'j; f c4p:^ ' >i«P' ' l>o As I^W ' ''-

A . *’

>

m

/ v.K|i 7.»«i<t»i , '.3 '.»ifcm>HT

./ fcadi^ 0 'iimiit,

L ''..W'f 1

%r

*' •*<'!(..

? 0 VJ»» t^i, » »i»o

^aM,

t ‘VJO"' < J" B'fT'i''^''Sf f»'> |fj(jj,,l n tl I'iiV'i d' »(i» -# .X',1*;VB Ifi

-,. ^0 4 iikmd'^vA * 1 4> • f« ’tH

-4

W.,

I ^

I eoooo-BT^tsma ^fgiw

M<^r' 'V,.

iJ'’ yj^ V

' ^

1!;: iff'

, vl

-

;

, ^:jt'

h'

*. •*' *

t n
TABLE OF CONTENTS

Page

ABSTRACT 1 WORKSHOP ATTENDEES 2

INTRODUCTION 7

WORKSHOP REPORTS 9

SIMPLE SENSOR INTERFACE 9

WRIST INTERFACE 14

COMMON ROBOT CONTROL INTERFACE 18

COMPLEX SENSOR INTERFACE 34

FUTURE GUIDELINES TOWARDS INTERFACES 40

GENERAL RECOMMENDATIONS AND CONCLUSIONS 46

APPENDIX I 47

-i i i-
¥TI 7

jt* • • I ».. * |- ' ( iF'r .'t.'

H.

, ‘.«ri«os3ii

'

. .,. T8IIIW

. ; .... . ^

TOUOB i<lKH03

V.:#-;';: . 3DA XjU<»«3

.. ,1

83^A^H3Ti4r4ffiRAwat a^i i aw>r'/=i

m . ..

• 'A ’ . ^ :^tr

'W^.'.YA ]ilR<
ABSTRACT

This paper

interfaces

4-6, 1980.

faces were

describes the proceedings of

held at the National Bureau

Five possible

d iscussad

a workshop on robot

of Standards on June

areas for standard i zat ion of interthe Simple Sensor interface between

simple peripheral devices and a robot control system; the

Wrist Interface, between the robot wrist and the end effector; the Complex Sensor Interface that covers vision, complex touch, and other such sensors; the Common Robot Control

interface, providing robot independent trajectory descriptions; and Future Guidelines towards Interfaces, covering

data base, offline programming, and system integration interfaces. The goal was to define the areas ready for current

standards, and those for which standards would be considered

an impediment to developing technologies.

This workshop was jointly sponsored by NBS and the Air Force

ICAM project under MIPR SY1457-00003 "Robotics Support Project for the Air Force ICAM Program".

- 1 -
UORKSHOP ATTENDEES

James S. Albus

Programmable Automation

National Bureau of Standards

Bldg. 220, Rm. A123

Uashington/ DC 20^4

(301) 921-2381

Carl V. Ames

General Dynamics

P. 0. Box 748

Ft. Worth, Texas V6101

(817) 732-4811 X5475

Henry 8. Baird

RCA Laboratories

Room N201, US Route 1 Princeton, NJ 08540

(609) 734-3150

Anthony J. Barbera

Programmable Automation

National Bureau of Standards

Bldg. 220, Rm. A123

Washington, DC 20234

(301) 921-2381

Richard Becker

Cheeseborough-Pond 's, Inc.

John Street, Potts Bldg.

Clinton, CT 06413

( 203 ) 669-860 1 , x 557

Sidney Berkouiitz

David W. Taylor Naval Ship

R&D Center, Code 1824

Bethesda, MD 20084

(202) 227-1889

Edufin R. Bowerman

GTE Laboratories

40 Sylvan Rd.

Waltham, MA 02154

(617) 890-8460

-2

-
William S. Browev

Control Data Corporation

124 Hebron Avenue

Glastonbury# CT 06033

(203) 633-6781

Donald 0. Caugheian

Lockheed-Georgia Co.

D47-11 Z80

86 S. Cobb Dr.

Marietta# GA 30063

(404) 424-3859

Hans G. Colleen

ASEA Inc.

4 Neui King StreetWhite Plains# NY 10604

(914) 428-6000 X345

Bryan L. Dauson

Cincinnati Milacvon

4701 Marburg Avenue

Cincinatti# Ohio 45209

(513) 841-8767

John D. Dexheimev

General Electric

1 River Road# Bldg. lOA-115

Schenectady# NY 12345

(518) 385-0689

Maurice J. Dunne

Unimation Inc.

Shelter Rock Lane

Danbury# CT 06810

(203) 744-1800 X305

G. E. Ennis

McDonnell Douglas Corportion

P. . Box 516

St. Louis# MO 63166

(314) 232-4021

Bruce D. Ernst

Prab Conveyors# Inc.

5944 E. Kilgore Rd.

Kalamazoo# MI 49003

(616) 349-8761

-3-
Patrick E. Hacker

Boeing Commercial Airplane Co.

M/S 9R-38, P. O. Bo* 3707

Seattle/ UA 98124

<206) 237-5520

Richard J. Handuierb

General Dynamic«>

Box 748/ MZ 6459

Ft. Worth/ TX 76101

(817) 732-4811 X5475

T. Kasvand

National Research Council

Bldg. M50

Ottawa/ Ontario/ Canada

(613) 993-2003

Arkady G. Makhlin

Westinghouse R&D Center

1310 Beulah Rd.

Pittsburgh/ PA 15235

(412) 256-3982

Gordon Mayer

U. S. A. F. (ICAM)

AFWAL/MLTC

Wright Patterson Air Force Base

Ohio 45433

(513) 255-2562

V/. W. McClure

Texas Instruments Inc.

P. 0. Box 225621, M/S 452

Dallas, TX 75265

(214) 238-3479

Lori Mei

Society of Manufactur ing Engineers

P. 0. Box 930

1 SME Drive

Dearborn, MI 48128

(313) 271-1500 x407

Roger N. Nagel

Programmable Automation

National Bureau of Standards

Bldg. 220/ Rm. A123

Washington, DC 20234

(301) 921-2381

4“
Wallace J. Plumley

Loc kheed-Oeor g ia Co.

D47-11 Z80

86 South Cobb Dr.

Marietta* GA 30063

(404) 424-3796

Louis E. Potter

RCA Corporation

New Holland Ave.

Lancaster* PA 17604

(717) 397-7661 X2200

Donald Seltzer

C. S. Draper Laboratory* Inc.

555 Tech. Square

Cambridge* liA 02139

(617) 258-1368

Joseph Sheehan

David W. Taylor Naval Ship

R&D Center

Bethesda* MD 200Q4

(2C2) 227-1302

Bradford M. Smith

Control Software

National Bureau oF Standards

Bldg. 220* Rm. A123

Washington* DC 20234

(301) 921-2381

Albert C. Snowdon

EATON

Operations 8c Technical Center

4201 N. 27th Street

Milwaukee* W1

(414) 442-7800 X2'?85

Charles Spalding

Unimation Inc.

188 S. Whisman Rd.

Mountain View* CA 94041

(415) 965-0557

Gordon J. VanderBrug

Automatix Inc.

217 Middlesex Turnpike

Burlington* MA 01B03

(617) 273-4340

-5-
John V/ranish

Naval Surface Weapons Center

Code E-IA, Rm. 4-176

White Oak

Silver Spring/ HD 20910

(202) 394-3256

Jerome F. Walker

Nordson Corporation

555 Jackson Street

Amherst/ Ohio 44001

(216) 988-9411

Thomas E. Wheatleg

Programmable Automation

National Bureau of Standards

Bldg. 220/ Rm. A123

Washington/ DC 20234

(301) 921-2381

Jack Wiley

Planning Office

National Bureau of Standards

Bldg. 101/ Rm. A929

Washington. DC 20234

6-
INTRODUCTION

On June 4 - 6» 1980» a workshop on the need for standard i zation of robot interfaces was held at the National Bureau of

Standards (NBS). Co-sponsored by the Air Force ICAM office

and the NBS Programmab le Automation group# the workshop was

co*-chaired by Dr. James Albus and Dr. Roger Nagel of the

NB^. Mr. Gordon Mayer of the Air Force ICAM presented an

over-view of the Air Force program in robotics both present

and future. There were 35 attendees representing industry#

academia# and the government. During the workshop# the attendees were assigned to one or more of five separate working groups# each of which met on two occasions. These five

areas were: the Simple Sensor interface between simple peripheral devices and a robot control system; the Wrist Interface# between the robot wrist and the end effector# the Complex Sensor Interface that covers vision# complex touch# and

other such sensors# the Common Robot Control interface# providing robot independent trajectory descriptions# and Future

Guidelines towards Interfaces# covering data base# offline

programming# and system integration interfaces. There were

general sessions held each day both to charge the separate

working groups with tasks and to hear reports on their

results so that the workshop could truly function in an interactive working fashion.

On the last day of the workshop# a general session was held.

At that session it was determined that with respect to the

Simple Sensor interface# connecting robots with other devices in their environment# the time has come when standards

ought to be created. Similarly# with respect to the Wrist

interface# the connection between the robot wrist and its

end effector# we are also ready for a standard. In both of

these areas ’•eports were written recommending the beginning

of a standards effort.

With respect to the Complex Sensor and Common Robot Control

interfaces# it was determined that it is still too early to

begin a standards effort. However# position papers arguing

for particular directions and general awareness of the community on these topic areas have been written and are included in this report. These position papers are designed to

focus attention on the issues and suggest paths as to how

they may be addressed.

In the fifth topic area# Future Guidelines towards Interfaces# the two main trhemes covered were robot programming

languages and the integration of robots into robotic systems

for automated manufacturing. While the discussions were

-7-
interesting and instructive# it was clear that it is much

too early in the development of these areas to offer standards. The general feeling was that the field is beginning

to accelerate and that it would be worth re-investigating

these topics as well as some of the other topics covered in

the workshop in approx imately one year. Accordingly# the

Bureau of Standards and the Air Force ICAM office are looking into possibility of

place next

the

June.

a second conference to take
WORKSHOP REPORTS

During the introductory workshop session* guidelines were

drawn up for a format for each workshop session to follow.

Various topics and questions were to be presented to the

group members* and answered as best befits that interface.

The topics decided upon for discussion were!

A. Scope and Definition of Interface

B. Is There a Need for a Standard?

C. Standard! nation

D. Timing of Effort

E. Recommendations

Following these initial discussions* the overall group broke

out into the individual working groups. The session

chairpersons were charged with reporting the activities of

their particular group with respect to these questions* and

to draw up a position paper on their conclusions and recommendations at the close of the workshop. Their reports are

below in the following order: the Simple Sensor interface*

the Wrist interface* the Common Robot Control interface* the

Complex Sensor interface* and the Future Guidelines towards

Interfaces report.

SIMPLE SENSOR INTERFACE

I. GROUP MEMBERS

Bryan Dawson * Richard Becker

Edwin Bowerman

Donald Caughman

John Dexheimer

Bruce Ernst

Patrick Hacker

Ward McLure

* Chairperson

Cincinnati- Milacron

Cheeseborough - Ponds* Inc.

GTE Laboratories

Lockheed - Georgia Company

General Electric

Prab Conveyors* Inc.

Boeing

Texas Instruments

II. INTRODUCTION

In the general introduction to the workshop* it was stated

that this type of interface was probably one of those most

-9-
ready for standard i zat ion. This group session was/ therefore! charged with addressing certain specific issues with

regard to the possible standarrfi zation of robot-toperipheral device interfaces and to offer guidelines towards

topics to be addressed in such a standard.

III. DEFINITION OF A PERIPHERAL DEVICE

A peripheral device in this context was defined as a piece

of equipment or device used in conjuction with an industrial

robot in the implementation of an application# and which

communicates with the robot by means of binary signals only.

To set the record straight# it does not include what are referred to as computer peripheral devices such as floppy

discs# printers# and other such devices.

The definition should also not be construed to include

higher frequency binary signals which constitute a data format# nor analog signals. However# many of the areas discussed by this group could also apply to such interfaces.

Examples of peripheral devices would be machine tools# spot

weld equipment# conveyors# etc.

IV. IS THERE A NEED FOR A STANDARD?

The consensus of the group was "yes" and the time for implementation is just right or may be even too late. The following reasons for this conclusion were offered;

A. Many robot users require the interfacing of robots to

older# existing in-plant equipment. It is not until the actual interfacing takes place that snags# such as the following# are found;

1. Lack of interface points on old equipment.

2. Lack of control devices such as limit switches on

existing machines.

3. Lack of complete cycle control on existing equipment# e. g. # no way of initiating an automatic cycle nor

of generating a cycle complete signal.

In other words# up until just recently# machines and equipment have not been built with robots in mind.

B. To offset these problems# there is a need to aid the

user# robot manufac turer # and peripheral equipment manufacturer by providing guidelines to indicate the requirements

for adequate marriage of the equipment.

- 10-
C. It was felt that

ing manufactured

need to standardize

D. Although new eq.u

with robots* it i

years* robots will

“old" equipment.

although new per ipheral equipment is beo be used with robots* there is st i ll a

log ic levels of signals • pment is being made s uitable f or use

envi saged that for at least the ne X t 20

till be required. to interface wi th the

V. RECOMMENDATIONS

The group decided to limit the scope of guidelines to include the following subjects: signal level and type* noise

and means of elimination* connector configurations* minimum

interlock signal requirements* and incorporation of existing

standards.

A. Signal Level and Type

Existing equipment and plants often use 110 V/AC relay logic

type control. Naturally* it is usually not possible to

change these. Therefore* a 110 VAC interface appears to be

necessary. New equipment (and programmable controllers)

tend towards the use of lower voltage solid state logic*

therefore a 24 VDC interface also appears to be necessary.

It was felt that for this type of interface* levels such as

the 5 VDC were too low and included possible noise and line

attenuation problems. Thus (in conjunction with common practice) the two logic levels* 24 VDC and 110 VAC* were put

forth as guidelines.

B. Noise and means of elimination

Precautions must be taken to eliminate the effects of noise*

voltage transients* contact bounce* etc. The following

points were indicated as guidelines to eliminating these

problems.

1. Adequate grounding to eliminate ground loops.

2. Suitable shielding* e. g. * basketweave* twisted

shielded pair signal lines* etc.

3. Eliminating contact bounce and similar effects in

devices such as relays and limit switches by suitable

damping or by time delay concepts in robot controls.

4. Devices need to be isolated* e. g. * by optical coup 1 ing.

5. Noise from switching devices can be eliminated by

- 11 -
suitable arc suppression.

on» i. e. . floating zero po-

(not tied to ground).

6. Dif-ferent ial communicati

tential on one signal line

7. Control power should be

8. Solid state devices may

resistors to ensure proper

from isolated utilities.

require such things as load

signal recognition.

C. Connector Configurations

Field wiring to terminal strip interface boxes was recommended. The interface terminal boxes must be mounted to the

robot control and peripheral equipment such that the terminal strip access is convenient. The field wiring should be

done in hard conduit for noise rejection. Use of individual

pairs of wires from the robot to different parts of peripheral equipment was not recommended.

Also recommended was the use of pre-assemb led flexible conduit and connectors for connections to and from junction

boxes. Such connectors in common use are Pyle National/ Amphenol# Cannon/ etc./ and are usually user specified.

A combination of the above may be used. If a combination of

110 VAC and PA VDC is used# the signal lines must be adequately separated.

D. Minimum Interface Requirements

A minimum interlock requirement is probably necessary. The

attached diagram (Figure 1) shows such interface signals.

However/ the signals and their functions are very

application-oriented and each application must be examined

carefully.

E. Existing Standai'ds

Ulherever possible# existing standards should be used# if not

in their entirety# at least as guidelines. For instance#

some robot manufacturers and users have already formulated

their own standards. Programmable controller users and

manufacturer s similarly may have their own common practices.

A standards search for such information is recommended.

VI. GENERAL COMMENTS AND CONCLUSIONS

It was recognized that in many cases effective use of programmable controllers would bridge the gap between "old"

equipment and robots# and would also allow "add on" cycle

12-
OUTPUTS

FROM

ROBOT

OUTPUTS

FROM

PERIPHERAL

DEVICE

FIGURE

I

Minimum

Robot/Peripheral

Device
.1
control to such equipment. Houieveri the guidelines discussed

above still apply. Many of these guidelines could also apply to the other interfaces discussed in the workshop as

well as to analog signals between equipment.

- 13-
UR 1ST INTERFACE

I. GROUP MEMBERS

Dunne* Maurice-*

Smith* Bradford M. * Uni mat ion

National Bureau of Standards

McDonnell Douglas

Prab Conveyors* Inc.

General Dynamics

RCA

Naval Surface Ueapons

Ennis* Jerry

Ernst* Bruce

Handuierg* R. J

Potter* Louis

Vranish* John

*Co-Chairperson

II. INTRODUCTION

Robots have typically been applied in dedicated* high-volume

tasks where only a single gripper or end effector has been

required. The end effector is generally a unique design and

is specifically built for the chosen task by either the

manufacturer or the end user. If subsequent end effectors

are needed* the user is often hard put to find sources with

reasonable leadtimes and costs. Manufac turer s are necessarily more interested in expanding their sales of similar

robots than they are in taking on more design and fabrication of different end effectors. Other design engineering

firms are unable to develop cost-effective* generic end effectors since mounting techniques vary across different

robot models and the volume of any one configuration is

fairly small.

Present mounting schemes allow for manual replacement of an

end effector and actuation of its operating mechanism. These

schemes generally involve a bolt-on technique with facilities for hydraulic* pneumatic* and/or electrical signals to

and from the end efPector. One problem sometimes encountered

with these designs is that an end effector cannot be replaced in exactly the same, position and orientation that it

had originally. This forces a user to slightly reprogram his

robot every time an end effector such as a gripper or spot

weld gun is taken off for maintenance. Another problem seen

by users of a variety of different robots is that end effectors are not exchangeable across like capability manipulators. Often a spare unit must be stocked for each different

production robot.

Recent trends have seen robots used for a greater variety of

small-volume workloads. Here* end effectors are often

changed to meet new job requirements or to make use of a variety of tools -Por the same job. Increased emphasis is

- 14-
placed on the interface between th

effector. Designs are required

its own tools on command. Several

to exist with at least one in the

e robot wrist and the end

whereby a robot can change

implementations are known

public domain.

III. NEED

The Group concluded early in their discussion that it was

timely to initiate a standard i zation activity to address the

interface between an industrial robot and the variety of end

effectors. Areas to be covered include mechanical registration; fastening; and facilities for air# fluid* and electrical signals to and from the end effector. Furthermore* a

standard for the mounting surface would provide the following benefits:

-A user can put the same gripper on any of his robots

without redesign and rework.

-A user can replace a worn or damaged gripper without

editing or reprogramming.

-A user can purchase a gripper from a specialty supplier with assurance.

IV. INTERFACE REQUIREMENTS

The wrist/end effector interface design addresses a variety

of engineering concerns:

A. Mechanical Fastening

The wrist mounting surface* to which the end effector

is attached* must withstand rated static and dynamic

loads.

B. Registration and Orientation

Facilities must be provided for locating the end effector in the same attitude each time it is mounted.

C. Electrical and Pneumatic

Capability for actuators* powered tools and sensors on

the end effector will require connections for electrical* electronic* hydraulic and pneumatic lines.

D. Replaceable or Quick Change

All applications require means for users to remove an

end effector; some require the robot to change tools

itself.

- 15-
V. STANDARDIZATION

A logical stepwise progression was developed by the working

group through which standard i zat ion of the wrist interface

could be obtained. The strategy was suggested to start with

the development of a common mounting surface for functionally equivalent robots. The surface will provide for fastening* registration and indexing of end effectors. Envisioned

here is perhaps the disk shaped mounting surface shown in

Figure 1 which incorporates a bolt circle for fastening* a land for shear strength and registration* and a pin for indexing. The bolt circle might be on the order of six inches

in diameter for a large class of robots and include a fourinch and a two— inch size to cover smaller classes of robots.

It is important to note that the interior of the circle is

undefined allowing manufac turers leeway in incorporating

this design into their product.

A second step in the strategy is to attack the problem of

passing signals and power through the interface. Various alternatives were suggested leading to the only conclusion

that the mechanical concept imposed no unrealistic constraints on the electrical/pneumatic problem and the latter

was best left to a working group of design engineers under

the standard i zat ion effort.

The last step in the strategy is to address the quick change

problem. At least three designs are known to exist with one

developed under Air Force ICAM funding and being available

to any user. However* it was thought premature at this time

to initiate standard i zation activity in the quick change

area since the variety of signals to and from the end effector are so diverse in present applications that a consensus

for standard i zat ion does not yet exist. A conclusion was

made that a future standard for a quick change device is

highly desirable and it is hoped that the experience gained

in the above two areas by the standards group will pave the

way for needed work on the quick change mechanism.

V I . RECOMMENDAl I ONS

To initiate standard i zation activity in this area the

ing group developed a letter request to the Robotics

tute of America for sponsorship of a group to develop

mon interface between the robot and the end effec

functionally equivalent classes of industrial robots

letter outlined the scope* overview and need for te

work. It was recommended initially that activity be

ed at establishing a bolt-on mounting surface whi

provide registration and indexing. Consideration cou

be given to Future requirements for utility servi

quick change requi rements.

workIn st ia comtor f or

. The

chn ical

d ir ec tch wi 1

Id then

ces and

16-
UNDEFINED AREA

Land

FIGURE 1

Typical Mounting Surface Geometry
»V‘ i.ii

: %•

1

*u

£3 ^

V-“

..*u,

|»wr# 4 a«

IW*.

4 > 'T.

V 1!

•:p

h'afdij

r»

fm /-f

ilAov

> ,v' >'/H^/I<‘'

i «'4

*;« 4

*

r

#'

'(i 4*i4

.n.

I • c '/•!^'' ';

t VV 'IttMlI.

I!

'^riotf'Ji t, »S5^4M. *r . .U't0':r

. * ;

i

. ,d> •4

‘U'fVlU

< ft*J

' ’ifc

. -" __

»• 1 w

' rl -,.

Bl

.•"VI iT'' ' ’'•<1'

I

vf tjIi.#,.

„#*f3 T^,- f 4l r_4.4t t CTtf’ 1 n\ i>fJ

r« I " *: ** f Mil*'

I ! '^ H fhJl.

•-W •

-

' nirdlV

i%u

t k ^ Jit

*A ' fl' imM 4

''

y . IS

Vu<wh^^"»' *'’nkiiij'^^ %tti,*ttuxssi

:* •

ka > .

; '/,} '•

,
One of the first tasks of any such effort would be to gather

data on all U. S. Robotic mounting surfaces presently used.

In an effort symbolic of the perceived need for standard i za~

tion in this av'ea# representatives from each robot vendor

offered to make available the engineering drawings of their

mounting surface. These are included as Appendix I.

VII. CONCLUSIONS

The present variety of grippers and end effectors is extreme

and will probably continue to proliferate. While the robot

manufacturer will provide design and manufacture of a special gripper as an initial service* his interests lie in the

serial production of robots and not in the fabrication of

single quantities of widely varying end effectors. The burden is falling increasingly on the user to design his own.

While the rapid expansion of robots in the work force provides a total volume which could support an independent

business concerned with the design and manufacture of robot

end effectors* it is not yet viable since the method of attachment varies so widely among manufacturers. An adequate

interface standard would be a most timely solution benefiting both vendors and users.

17-
COMMON ROBOT CONTROL INTERFACE

I. GROUP MEMBERS

Barbera# Anthony J. National Bureau of Standards

Spaulding# Charles* - Uni mat ion

Ames# Carl V. - General Dynamics

Baird# Henry S. - RCA

Colleen# Hans - ASEA

Dawson# Brian - Cincinnati-Milacron

Dexheimer# John - General Electric

Dunne# Maurice - Unimat ion

Makhlin# A. G. - West inghouse

Mayer# Gordon - Wr igh t-Patterson

Plumley# Ually - Loc kheed-Georg ia

Seltzer# Donald - Charles S. Draper

VanderBrug# Gordon - Automat i

Uheatley# Thomas - * Co-Chairperson

National Bureau of Standards

II. INTRODUCTION

This uorking group considered the specifications of a robot-independent control interface that would allow for

real-time trajectory control of a robot. Such an interface

would provide the option of controlling the robot with a

user program generated external to the manufac turer 's controller! where the robot^s motions would be specified in

some robot-independent form (e. g. Cartesian descriptions of

the end effector's position and orientation). In considering this interface# the following topics were discussed:

1 .

2 .

3 .

4 .

5 .

The

The

the

The

The

The

need for such an interface.

level within the control structure at which

interface should occur.

scope of the interface specification.

possible standard i zat ion of the interface.

timing of the interface, specification effort.

i

-18
III. THE NEED f-OR I HE INTERFACE

To better

of robot

here.

understand the question of

interface* some background

the need for this type

information is included

A. Background

Industrial robots are

some combination of

rotary-jointed linkag

quired to be able

any point in space uii

cussed here is meant

joints. To establish

cussion different 1 described.

mechanical manipula

prismatic (telescopi

es. A minimum of si

to position the robot

th any orientation,

to provide a means of

common dialog for th

evels of control ca

tors compose d of

ng or sliding ) and

X joi n t s is r e-

's end effect or a t

Th e in terface d isc ontr ol ling th ese

e int er face d i spa b i 1 i ties wi 11 b e

1. Servo System

The more general-purpose industrial robots have their

joint motions under servo control. The inputs to the

servo control are the desired joint positions of the

robot. Ihese are compared to the feedback from the

joint position indicators. If these values are different* a drive signal is generated to move each joint

until the position error is nulled in a smooth* stable

manner. 1his bottom level of control exists in all

general purpose* programmable robots.

2. Joint-Space Coordinates

The joint position values that are input to the servo

system are the coordinates in the joint space of the

robot uihich describe some desired position and orientation of the manipulator.

Different robots within and between manufacturers are

made with different size links and different combinations of prismatic and rotary joints. Thus two different robots capable of performing the same task of

manipulating an end effector through the same trajectories* positions* and orientations could have very

different mechanical configurations. <See Fig 1.

)

Therefore* the sequence of joint position coordinates

for two such robots would be very different even though

they were moving an end effector through the same trajectory in space. Even two robots of the same type

from the same manufacturer would require different

joint position coordinates due to lack of exactly the

same zero location of position indicators* different

tolerances in linkage alignment* slightly different

- 19-
ni

ra

W k'

«i>

.«irf»f(

Hi ,,

V.^-tfh'vjA w40'’ rxi ont*l» t

ff, ii‘Ttjr>\ », fi, "*,i ;< ' M' /iL

V >

-t' ,‘*4l;

« ^J4 «>^'T - ’.Wl

, *'i7t'l»r#"».itJ!'yA

s? %«44f, •?L#

l.^„^iflrii-'^q- '\;0

V.- i *»#*«4*5

I Uw-' ^P^.tt.ff i't .0^M»4i::|'

"'., ;> . «

' '‘4

• ;-!. •<T' '" Ft X *f e V .3, ,i.t» I w»’ jjf i|f',

.t#n% , P-; V ::^:t»»fi^-

'

-i t St . T

X.4^ D I

^ i.lit

', . tf ‘i<plt <Hi ' i’rtlOt *

;:. 4i i.j.Tfe ll||.‘t.it«»<C»vaf t>Y'J«» .;• ' * ' .^ 1

- 49%

n4

'^‘4(jn 4 'i»p4'l»£^-' K44 » .»!-.• . i it«roii-f _ri#cj

t 'fi./ fli: %; ' . f'jii^i .' ^ f^T ' '

, Tt»»V(#li w i“i’ h^

'•«

... l0-i4|(l%'

6^ : |,v|

^.D ,/»^i.*jt *(i#- f?a f4t,'

hmp'*».V» :'^3 * fO t(t

il

' o -I b i

:’ «

^ .'t 4

i •*h^, l#|o "t

,'S" » t* • ( vn f *'‘1«4** %<! „.

,V '>%#'* V '3 I0 '’rnfrl-f

lii chi

“"t f u o**t .'

, '4® . tt#.X , 9 ir-v k 9 *4 .*

'4f*m9 ^,,

yt^iy A • . (4,i < 9dir *i*'0'i ^iP'jy'jj^c \|'fi:3ifi«M4'^w '9

„fl, »»ynrfi/te,y^err .Prj^Mf ItAgr.^ /^n ‘<iV '^^. «:9#i

n^''*,' .yrt^'V At )tiu^ ,.§i 94^!$:'f '''Ptk4i^ *to^ it mtvo-i.fl.t , M.Av.f*'*-

«m%r Y'Ht Yirt' sii.j'otAn', • >ui}j #»4 ATratiti, ,.; A'fiaf'A'T h i’ «-''>«<*

' t tt »o-rf':

W'' #»lw»

V.' .#AA'lr>ff-'' itX' 'tt ,

,'

y

I
777777777T

FIG 1 Example of how two different robot configurations

can position an end effector in the same location and

orientation. The joint values are very different

between the two robots while the end effector's location

in both instances can be described by the same set of

robot-independent work space coordinates.
linkage length# etc

The lack of compatibility between the joint-space coordinates of one robot with those of another robot does

not pose a problem with robots used in stand-alone#

teach-record-p layback app 1 icat ions. This is because

the joint-space coordinates played back to the robot

are the values recorded off the same robot while it was

being physically led through the task motions. However# these recorded joint values could not be played

back through another robot and result in the same trajectories for the reasons mentioned.

3. Cartesian-Gpace Coordinates

The joint-space coordinates of a robot describe motions

of the rotary and sliding joints of the particular

robot involved. There are times# however# when it is

advantageous to be able to command motion of the

robot's end effector in some other coordinate system.

Programming# traject^ory control# and path modification

using sensory feedback are all more easily commanded in

coordinate systems other than joint coordinates of the

robot. For example# it is simpler for an operator to

move the end effector to desired locations if she is

commanding end effector motions in an X# Y# Z frame of

reference (e. g. with a joystick)# rather than trying to

move each joint. (See Fig 2. ) Motion commands can be given in any arbitrary

nate frame of reference as Long as there ex necessary coordinate transf ormat ion algorithms

culate the corresponding joint position val

will result in the proper joint motions. Eac

must have a coordinate transf ormation routine

larized to its linkage and joint conf igurat ion#

as the zero points and resolution of the joint

indicators.

coord iists the

to calues that

h robot

part icuas well

position

A set of values in an arbitrary coordinate

as a Cartesian coordinate system based

place# is a robot-independent description

tion and orientation of the robot's end e Fig 3. ) The coordinate transf ormation r into a robot control system will take th

values and transform them into the corresp

joint position values for that robot.

sy stem1 sue

in the work

of the posi

ffe ctor . (Se

out ine bull

ese Cartesia

ond ing set 0

B. Controllers and Control Systems

When a user purchases an industrial robot# he also receives

a controller which contains some form of control system that

-20-
t

FIG 2 This figure illustrates the required coordination

of a number of joints in order to obtain a straight line

motion of' the hand. For each incremental move along the

straight line path, joints J2 (elevation), J3 (boom extension), and Jb (wrist flex) must be adjusted and coordinated.
J3

n

»

I

>y> w^isT

y)2)cMO POlUT

// ^) FI»>»CeR

coordinate

TRANSFORMATION

ALCOR ITH MS

JI,JZ.J3,J4,J5,Jfe.J7

FIG 3 This figure depicts the specification of the po- « sition and orientation of the end effector by 3 sets of ff workspace robot-independent Cartesian coordinates. T

There is an x,y,z location to specify the wrist point,

an x,y,z location to specify the end point and an x,y,z

location to specify the finger tip. These would be the

same values regardless of tne type of robot used. The

coordinate transformation algorithms will calculate the

set of joint values ( J 1 , J2 , J 3 , J 4 , J5 , J6 , J 7 ) required to

position this particular robot in the correct way to put

the end effector in the specified configuration.
includes a programming and execution capability. The user

does not have direct input capability to the actuators* the

servos* or to a coordinate transf ormat ion routine. Rather#

the robot manufacturer has provided in the controller a user

interface for programming a task to be performed. Once a task is programmed# the controller can be put into an execution mode in which the rohot moves through the recorded trajectories. The following describes the type of programming

required and the level of control capability available with

typical systems.

Joint-Space Controllers

The simplest form of controllers available on servoed

robots use a control system that is totally based in

joint-space coordinates. These controllers are typically the teach-record-playback type. A robot with

such a controller is programmed by moving the joints

using individual joint control buttons until the robot

is in a conf iguration that places the end effector in

the required location and orientation for a desired

trajectory point in the program. This position is

recorded by reading in and storing the values from the

joint position indicators on the robot A sequence of

these points is programmed and recorded in this manner.

To have the robot repeat this sequence# the controller

is put into execution mode which simply causes the

recorded joint values to be played back in the correct

order and timing to the servo system. As the set of

joint values that define each location are input to the

servos# the joints move to these specified positions.

When the joints have moved to within a predefined delta

value of their commanded positions# the next set of

joint values is sent to the servos. Different sequences of such joint coordinates can be recalled from

memory and played through the execution mode of the

controller causing the robot to perform different

prerecorded tasks. However# as mentioned above# a

stored program taught on one robot cannot be

transferred to another robot and have the same task

trajectories executed. Nor is there an interface to

the robot's servo system that allows the user to input

a separately generated set of joint position values.

(This would he desirable# for example# if the user provided a separate coordinate transf ormat ion processor to

calculate joint position values from sets of Cartesian

coordinates. > Joint-space controllers pr

and algorithms to allow

played back# but limit the

programmed tasks through

ovide the necessary 1 ogic

tasks to b e programmed and

user 's capab ilities to only

which the robot must be

-21
physically moved in order to record the joint position

values.

2. Coord inate -Transformat ion Controllers

Several robot controllers are equipped with sufficient

computational capability to calculate the transformation from some defined coordinate system to the joint

coordinates of the particular robot. These controllers

allow the user to program straight-line motions# motions about a tool point axis# and other trajectories

which reference some relatively robot-independent coot

dinate system. Programming becomes a simpler and

easier task since the operator can move the robot into

position using a joystick# or other means# which command motions of the end effector directly. Motions up#

down# sideways# and rotations about a tool tip are all

commanded in a straigh tf orward and simple fashion. The

necessary joint coordination is provided through the

coordinate transf ormat ion algorithms. Again# the controller provides programming and execution capabilities# but still does not provide a user interface into

either the coordinate transf ormat ion calculations or

the joint-position inputs to the servos. Rather# these

are stand-alone controller-robot systems that are used

to teach their own programs and execute them.

There are two major differences between these controllers and the joint-space controllers mentioned previously. First# coord inate-transf ormation controllers ease

programming since coordinated joint motions are commanded in workplace or tool coordinates rather than the

operator having to coordinate various joints through

individual joint motions. Second# these controllers

also provide a higher degree of trajectory control during execution. That is# even though the programming

still consists of recording only the end points of the

trajectories# the executed trajectories can be

straight lines rather than the arc type motions about

the rotary joints that are seen with the joint space

controllers. This straight line motion is due to the

real-time computation of the coordinate transformations. The end points are stored in the form of some

workspace coordinates such as Cartesian# cylindrical or

spherical. Intermediate trajectory points are calculated during execution and transformed to the

corresponding robot joint coordinate values. This

results in c ontrol led-tra jectory motion in the

workspace coordinate system.

Uhile this type of controller provides enhanced capabilities over the joint-space controllers# it still

22-
limits the user to only that set of manufacturer supplied features.

3. Higher-l.evcl Programmable Controllers

In general* the* differences between the joint-space

controllers and the coord inate-transf ormat ion controllers has been the inclusion of extensive computing capabilities. As the manufacturers increase the amount of

real-time processing in their controllers* additional

features can be incorporated. These could include trajectory optimization; trajectory smoothing through intermediate points* user-specified acceleration and deceleration profiles* trajectory modification based on

sensory feedback data; off-line programming of trajectories without requiring the robot to move through the

points in a teach mode* real-time branching to alternate routines to cope with varying situations and error

conditions* self diagnosis* etc.

It is t-he addition of the computer to the industrial

robot manipulator that is resulting in a truly general

purpose programmable automation device with extensive

features and capabi 1 i ties. Indeed* the computer has

created so many possible additional capab i 1 it ies* that

no one controller would be able to provide all of them.

This is why it is important for interfaces to be provided to these controllers so that the full advantages

of computer control can be realized. If the controller

does not provide a certain function* such as trajectory

modification using a particular sensor's feedback* and

there is no interface into the system to accept this

type of functional input from a user-supplied computer

system* then the robot will not be able to incorporate

this capability. With the proper interfaces into the

manufacturer 's controller* however* the robot's potential capabilities can be fully realized.

C. Advantages of Robot-Independent Interface

The following is a description of some of the advantages

that would be provided by a robot-independent control interface.

1. Interchangeab i 1 ity

A robot-independent control interface would provide the

capability of interchangab ity . For example* one robot

could be physically removed from a work area (for

repairs for instance)* another (not necessarily from

the same manufacturer ) moved into its place* and the

same program executed without reteaching it with the

-23-
new robot. If several robots were to perform the same

task in identical work areas« all of them could execute

copies of the same program. This would be possible

since the task program would specify the end points of

the various motions in a robot-independent workspace

coordinate system which would describe the desired positions and orientations of the end effector. These

positions and orientations are a function of the task

and the workspace geographical layout/ not the joint

configuration of the robot. The tailoring of these

programs to a particular robot would occur within the

manufacturei—supplied controller. The robotindependent trajectory coordinates could be fed in

through the proposed interface/ transformed into joint

values for that robot# and executed.

If the output of the reverse transf ormation (namely

from the joint space coordinates of the robot back to

the same robot-independent coordinate system such as

Cartesian coordinates) were made available through this

interface/ then a task program could be taught on one

robot# the robot— independent form of the trajectory

points stored external to the controller# and executed

on any other suitable robot.

2. Optimized vontrol

This type of interface would also provide the user the

option of generating specialized trajectories tailored

to the particular needs of the task# thus allowing trajectory control capabilities not available from the

manufacturer. The following are examples of capabilities that would become possible; special accelerat iondeceleration profiles# passing through intermediate

path points according to some desired smoothing algorithm# displaying controlled motion through some particular coordinate reference frame# moving about an end

effector that is offset from the end plate of the robot

in some unusual manner# programming tasks through a

type of joystick input specialized to some optimal user

coordinate reference system# varying tolerance specification on how close the robot must come to a programmed

point before executing the next point# using specialized approach and departure paths# etc.

This interface being discussed supplies the controller

with the executable trajectory points in a real-time

manner. It essentially allows complete external control

over the motions of the robot on an instant-by-instant

basis where the type of control is only limited by the

user's algorithms processed in the user-supplied external computing syst^em.

-24-
3. Sensory Feedback Interaction

Goal—directed behavior refers to the capability of a robot to carry out a programmed task in spite of small

perturbations in its environment that would normally

lead to incorrect behavior in a simple teach-recordplayback type of robot. An example of this is the acquisition of a part on a conveyor that has some arbitrary rotation and placement on the belt. In order for

the robot to acquire this part# certain information

must be made available to the control system to produce

the corrective trajectory modifications necessary to

cope with the situation and to pick up the part. This

requires sensors to measure the conditions# computing

systems to process the data into a proper form# and a

control system to make trajectory modifications in

real-time in order to accomodate these conditions. If

the manufac turer 's controller does not perform these

functions or does not have the necessary type of interfaces to allow sensor input or external control of the

robot# then the robot will not be able to exhibit this

real-time sensory interactive behavior.

11 er e x i sts sue h

t fr om a n ext erna I er in r eal-time 1 uia y of a n ex t erna 1 si ng an y se nsor y

mo t i ons . The use r pr oce s s ing# an d

If an interface into the robot cont

that trajec toi*y points can be ir

source and executed by the controller

then the user has the option# by

processor and this interface# of

feedback data to control the robot's

must provide the sensor# the sensory

the control system algorithms for trajectory generation

based on the sensory data. The output of this usersupplied system is a set of trajectory points in some

defined robot-independent coordinate reference frame.

These values pass into the controller# are transformed

into the joint space of the robot# and sent to th(? servo system to execute the proper motions on the robot.

Thus# this type of interface

of having the robot interact

sor the user might desire to

cation.

would provide the option

in real-time with any senuse in a particular appli4. Off-line Programming

In general#

robot task,

by leading it

recording each

ecut ion.

there are two methods of programming a

With one# the robot is “taught" the task

the necessary locations#

back in sequence during exthrough all

to be played

The other method# called off-line programming# creates

-25-
a task description without the necessity of using the

robot^s actual motion through those locations. This

programming is a-ccomp 1 ished in much the same manner as

a computer program is written. A procedural description is generated indicating the flow of control with

various branching conditions. The actual location

values can be entered in a number of possible ways.

These trajectory location values are stored in some

robot-independent form (for example^ coordinate values

in a Cartesian reference frame). They may have been

entered by typing the values into a terminal; having

some program generate them* such as might be done with

the locations in a palletized array; accessing an already existent data base (such as might be done with

the locations of holes to be drilled in a wing skin«

the positions of which are already stored in some

CAD/CAM (Computer Aided Design/Computer Aided Manufacturing) system); leading a robot physically through the

task and having the robot-independent form of the coordinates calculated from the reverse coordinate

transf ormat ion of the joint position values. The important -concept here is that since the trajectory locations are stored in terms of a robot-independent set of

coordinate values* they can come from a number of

sources and can be used to control execution of the

programmed task on any robot with sufficient physical

and performance capabilities.

Since these values are not dependent on a specific

robot* they can be generated and manipulated "offline*" without the robot* and used in an integrated

computer-aided-manufactur ing environment where the execution of these programmed trajectories can be accomplished by any number of robots. The user is thus

given the capability to do real-time scheduling* where

jobs can be routed to alternate workstations and the

robot-independent trajectories down-loaded to whichever

robot is available in that workstation.

Clearly* the robot-independent control interface greatly aids in the imp lemelitat ion of a flexible* integrated

system. It also forms a very necessary part of an effective "off-line" programming capability.

To fully realize the benefits of programming tasks by a procedural description of what is desired to be accomplished* it is necessary to he able to describe the

tasks independent of which particular robot may he

used. This is only possible if the programs can reference task positions and orientations in a form that is

dependent on the required action* but not dependent on

a particular robot's joint configuration. If this type

-26-
of robot independence is not available* every robot in

every workstation would have to be led through every

possible set of actions that tuight be performed at that

workstation by that robot* and the joint values of

every robot of every workstation for every one of these

positions will have to be recorded. This programming

effort is enormous* cumbersome* time consuming* ineffective* unstructured in its approach* tedious to maintain* and leads to unreliable and less than optimum use

of the robots.

To reach a truly flexible integrated computer-aidedmanufac tur ing system* robots will have to become general purpose* interchangeable modules with a common*

well-defined interface into the rest of the system.

Robot-independent task descriptions (trajectory points)

will be passed through this interface to be transformed

by the robot's controller computer into the appropriate

joint values needed to execute the tasks.

D. Users of Real-Time Control Interfaces

The general consensus of the working group was that at the

present time there would be a small number of potential

users of tnis optional robot control interface if it were

available. Most users would want to employ the robot in

stand-alone applications where only the capabilities supplied by the manufacturer would be needed* and programming

each and every task by the teach-record-p laybac k technique

would not be considered a problem.

Even though it was felt that the number of potential users

was small* it was noted that they would be mostly the large

manufacturers and therefore represent a sizeable number of

installations. Several of these major manufactur ing companies have already set up their own internal research efforts in this area as part of an overall program of upgrading and automating their manufactur ing process. The computer is the underlying component of this effort in robotics*

which is just one aspect of the overall goal of the integrated computer -aided-manufac tur ing system. The research

effort to produce an easily programmab le* flexible* automated manufactur ing cell is directed towards this end. The

robot is* of course* an important element in this system*

but system integration requires well defined interfaces.

For these research efforts to take full advantage of the sophisticated control and sensory interactive behavior possible with advanced computing systems* the robot cannot be a

stand-alone device without any method for the user to interface to it to enhance and tailor its capabilities to the

user's particular tasks. This type of robot-independent interface specif ication is one of the necessary first steps

-27-
req.uired in the del^inition of a set of appropriate interfaces between robots and external computing systems providing sensory data# control# access to other data bases# and

overall integration of the system.

In general# users of this type of interface would be those

involved in research and development of integrated systems

using robots. Ihis also includes third party vendors who

would develop and install robot systems in companies that

did not have their own company based research effort in this

area# as well as vendors that would supply different components such as a vision sensor module. This type of interface would considerably ease the task of integrating userdefined capabilities and sensory interactive behavior into a turn-key system. Vendors could develop their own retrofit

packages providing users the ability to purchase the components required for the particular application# and essentially plug them together to produce the desired system. A

user could# for instance# buy a robot from one manufacturer

and a vision system from another and connect them to allow

the robot fro perform part acquisition of misoriented parts.

Thus# while the number of users who might make use of this

interface directly is currently small# the number of applications could be considerable.

E. Control Level of the Interface

Possible interfaces into each of three different levels of

control were discussed. (See Fig 4. ) These were the servo

level# the coordinate transf ormat ion level# and the trajectory generation level. The coordinate transf ormat ion level

was thought to be optimal for this interface at the present

time since it provided a fairly simple and straight forward

control specification while being the lowest level that this

specification could still be robot-independent. The following is a brief description of the advantages and disadvantages of interfacing to the three previously mentioned levels of control.

An interface into the joint servo system

control of the robot but would

the coordinate transf ormat ion

would also be robot—dependent

given position and orientation of the robot

each robot.

system wo uld a 11 ow us

equire the user to provi

routines This i nter f

ince the JO int va lu es for

the rob ot are un ique

ato

It was felt that a more likely level for the interface was

at the control level above this# namely the level at which

transformed from some

the joint values for the

Most manufacturers will

the robot trajectory points are

workspace oriented coordinates into

individual actuators of the robot.

28-
eventually supply this capability on their controllers for

the ease in programming and trajectory control it affords.

The interface into these transf ormations is rather simple

and well-defined and provides the user the option of complete real-time trajectory control of the robot. At the

same time# it offers the advantage of robot-independent

specification of robot motions# with all the benefits previously described.

A number of the participants expressed an interest in an interface at a high level in the control system. Only trajectory end-points would be entered through this interface#

while the robot's controller would provide the trajectory

generation# acceleration and deceleration# path control#

etc. The consensus of the group was that this would probably be a desirable interface# but at the present time it

would be more difficult to define due to different ways trajectories can be generated# the various possible formats

used by different manufacturers# and the rather unclear view

of how to specify sensor interaction at this level. However# it was felt that as experience is gained with the more

sophisticated control systems becoming available# an interface at this level should definitely be reconsidered in the

future.

Again# the result of this area of discussion was that the

input at the coordinate transf ormation level seems the most

likely place for a common interface since it provides the

lowest level of input to the robot that is robot-independent

while affording the capacity for real-time control. It

does# however# require the user to provide all the programming# sensory interaction# and trajectory-execution calculations on user supplied computing system that is totally

separate from the robot controller.

IV. SCOPE OF THE INTERFACE

The spec if ication of this interface has been partitioned

into two parts. One deals with the communication aspect of

the interface# the other with the control information.

A. Communication Interface

1. Hardware

There was general agreement that a hardware communications interface should be some standard computer-type

interface. There is certainly no need to duplicate the

efforts that are presently being carried out in the

development of reliable communications hardware. Of

the various hardware configurations available

-29-
.» '•

'. ilvf*lVO*^^ dl

" T

?*(>i a>t'^’'' w}'

J \ -^ :•

' i ,f 0;.V f ’'b irf''-; >-r

' »»

. V rV Ylf

v*^- •<«.' . ! i • j:

• •' k . '» J >i>' •»®fl|iv - ^ <Mlt ^^ ci

^ '»o

Wk

•hAvTH .,

I A > /

*' ' :,V *»# .. [JicQM

'''

A J U%

' ' w > 'f , 0 ‘ j fc fiA ^

't-.'.-^v -cri #• ^qnJt

'a' Vf’' .’?"'l!»l

“» IV-'v ‘ .’J

. -i>y otr^ ft' M

- , .- ; W ) >' 71

'

' ’’

V.' -V ^ !’

,,^;^ ; ^'•^ '

'' '

’ >

(«*?' iv;f. ; *>\ ‘' ^ '^;

: ti t f ,-5 y # (1
WI3T I

in . W'

O 0) 0) Cm I 1 03O to c L. s O O (13 -P -P 4-3 <u CO CO 0) •o CO pH

L.

C > -p -a

CO Cm

O >»O 03 4-3 0> 0) •H r-l 3 CO 3

s: r-H P> CO r-l 3 O a CU CO CO 03 X3 E O O CD -p j3 03 CO

CO c O

C o -P 3 X 0) r-l -pH -p CO 3 o 3) 1. Cm 3 O

(U (U CD

O ^ 4a c o Cm "O o Cm N O o 3 CU P -p 03

•r-t

H L. P-r. o 4-3 >. Cm

4-> CO CN) 0)

a

a

CO c 0) » > 03

X 03 • CO •H >, C3

C •H Cm - to

X o

CL) <D CO •H

X •pH 03 3 3

*H

C <U

O 3! 03 03

L.

C 4-> 0)H 3 aO

O CO L. Q. -P

O 3 03 E CO CO CO 4-3 -H

T3

D pH • O Cm

a s 4-> i. 03

CO

C vO

N 3 O Cm 03a

0) - P Cm j3 o c T3 c >> 0) o 03 4-3 O C rH - ^ 03 3

•H (1)

X -P Cm •O -O

O

-p 3, to

w Cm 3 3 •rH

•rH 0) 0)

a 03 03 CO

a

CO •o -P -P c CO O c CO C CO a 03 a

o. c pH c SZ

M o 1 pH O -P 03 4-3 - 3

0)

a 3.

C >> o SL. pH 0) a “ to o O o O X •pH o o C 3. P v-r x: 3 L. o CD 3 a o 73 Cm O 4-3

j=: CO Cm (1)

H

OH 3 to

O 3 -C 4-3

H 03 CO £3 H P CO •O O •pH (U 'fH CO •pH p a a p -P •* X 3 pH

CO

a CD • t. to 03 -O o

L. (U CO CD

O

H 3 03 -P iH O P 03 3 03 a

-H •0 o O to 3 r-t 1—1 33 03 —

o CO 3. M T3 -3 a —

<D CD Cm aO 3 H CO

•rH 3,

W

X lU 3 (0 x:

CO 3 Oa

(1)

O -O rH 3

<U 4-> 3 C CO

O XI 3 3 GO 0) H CO aO TO P H 3

*H pH (13 (13C

H

X

O

Cm

C Cm -C (H to .TJ

a

CO

p -p

p

O o

CO o CD 3 a 03 rH -M Cm pH CO >

c-<C

O o 03 P H pH a x: H (0 o 3, p p • pH =< 03 lD o M X3 P CO 4-3 3

0) 3 03 03 3 •rH

J CmO CO 03 3 3 O

a

M Cma CO 3 O pH -Q 03 U. 0> CO P M CO TD

a I I

axis.

Ihe

second

example

shows

the

same

end

effector

in

the

same

position

an

orientation

but

specified

ina

spherical

coordinate

system.

An

x,y,z

loca

tion

defines

the

position

of

the

end

point

in

the

workspace.

The

orienta

tion

of

the

end

effector

is

specified

by

the

three

rotational

angles

shown.
I w I T 4k, ab ') <* 'e*. fe, .i' K. « i?-<. , ' 

< ‘P a ' t> '*«> O' if" S 4 ** a

>- # A

tar ,tC t i (> a sj 0 a\.m

,5 '«•

-, ., . a'>V *x iif ' h' »9 It^ > 'C c* * ••

.,

,.. %«¥<-

y '>Ml »*r * j5 If M * W IK V*

"A- - »J

0l f.- at : ^ . Jr' 'j'-rj.

*•*!.. l W, •!» -J3 J' jf, .'K 4 'ti'OiJik' » «, a

.*# . , ,

'jk i.v^ u.

a

tf * '1 tr -:m, a a' '^

,SP , .

(fc ' .. 43 (.“ tk' r- «k'

iCi£ r-,*r

.>* tf r-i*'^ % U

*A q|i t_ «•'

a tr {a ‘^ 13' q; « 3 o

'q^2p’ <•.

C ' /- fe «

'O- t-4 K*

n

a '^V ’>' ' A

ItW tr»"' uc .:4> :0 **

W

tf (H \ a <4 ?

tt

t'- ’It >4 > <? ,»>

u

a -c

,B'

p

Oa f» » ••V

A

L;

#•

U • ;q, 04 )kf '4, , 1 V A C' t4 <tt fcT '<• , to iH- u

*r Wt' ' »~ir; /*» 'ti 3 Cl iZ, a « a,'. - '' w © 1 Ci <9 ' • «u

ST*

-.1^: o. ,

i<l

Q H’ m. =»

,r i 3 'n'''A-

'iJr ,T-i S'

’’ A' '<4 4-‘' ^ 

,3k- >« : ‘tM

*- 

(fi * T» U :"r

Tir rr a>- . B. tf:n *L a.- o «P «• V' 3 'j*. tJ- . Q *- S

t,

W *!

W

la ^ ^ a (T ,^- *• ,(r *-.

a

ti) ,f tS tj '»

S* 0 ;^ ^ 't.* 4—* t' ’ «i

a

Ifn . 'JK * <s « . W^. VC a 1-

or -tJi ,c; <» .• w. **

•5 1- to

Km

<• .“t * i ’ »

,\

q

U Cf a, 0 •&

a i. '* '1 « o u 0 . s a • a-‘ •3 .S * *- 4

*. *- :4 Ck P Hr- *4* »•*- ' 1 ' r" . Jt f< *r ,,; I,* w <!i © II If

'a rli. t K

C

ij .• «w

K

Ot, , mW Uft *“ b '<» 3*.. 4| ,». ^^ & r »

frCO Ot 9T p « <« e >1

u*

r c fc uw */

44 ‘4 u> 

»c ^ " • c 'li'': r* tt' Tt- .

'' & >.»- >< ' j 'i , H'. •
I

ROBOT TASK

COMMAMO INPUTS

(e6. GOTO PART ’A'- grasp')

TRAJECTORY POINTS iN

workspace. COORDINATES

^EG. X. Y.Z. d). Tk.-©")

TRAJECTORY POINTS IN JOINT SPACE COORDINATES

CeG. Jl,ja . J3, JG)

drive signals

TO ACTUATORS

FIG 4 Schematic modularization of Robot Control System depicting possible interface locations for external control signa Is
(paralleli seriali and netuiork)^ the serial type seems

most applicable since it requires few lines# can communicate over long distances# and has sufficient data

rate capability. The amount of data to be transferred

through this interface is relatively small. A suggested data rate was 19.2 kilobaud. This seems applicable

since specif ication of a robot location in an arbitrary

coordinate system is assumed to require nine values#

each having 16 bits of precision. An update rate of

100 Hz was hypothesized yielding 1600 bits per second

of data. This was multiplied by 10 to allow for other

control information and communication protocol overhead

giving 16000 bits per second (baud). The next highest

“standard** data rate is 19.2 kilobaud# so it was chosen

as a desirable value.

2. Protocol

It was suggested that the communications links should

take advantage of the new LSI (large scale integration)

communication circuitry that offers a large amount of

user transparent protocol and error detection. Small

chip sets have sophisticated protocol routines that

essentially guarantee error-free communications by doing extensive error checking on the incoming data

stream and allowing rebroadcast from the sender if an

error is detected. Much of this protocol is handled in

the communications system with relatively small overhead requirements on the processors at either end of

the link.

B. Control Information Interface

This interface is specified by the information to be passed

through it. The following describes the type of information

that was thought to be necessary and whether it was to be in

the form of a standard interface or specified by the robot

manufac tur er

.

1 . Inf ormat i on Content and Structure

It was decided that the information should be a se

coordinate values sufficient to fully describe th

degrees of freedom of an end effector on the r (For example# this could be done by specifying th

sition and orientation of a mounting face plate on

end of the robot arm. ) These coordinate values wou

in some robot-independent coordinate system# sue

Cartesian or spherical. (See Fig 5. ) It was also a that the particular coordinate reference frame t

used should be specified by the robot manufacturer

long as the robot locations are specified in

t

eob

e

Id

h

gr

o

s

of

six

ot.

poth e

b e as

eed

b e As

ome

-30-
robot-independent coordinate system* it is not important which coordinate system is used. Any user with

enough expertise to take advantage of this interface

would have sufficient understanding of the control system t-o be able to easily generate a post-processor

type of software module (see Fig 6) to transform the

location values in some user-defined coordinate system

into the coordinate system specified by the manufacturer. The user would only need to write one of these

post—processors for each robot manufacturer* not one

for each robot. All the robots of one manufacturer

type would use the same post-processor.

The location values would represent absolute coordinates* as opposed to delta offset values from the last

set sent to the robot. This interface essentially provides a switch (see Fig 7) that chooses either the

manufac turei‘ 's control system or the user-supplied control system to input the robot-independent form of the

trajectory coordinates into the coordinate transformation level in the robot controller. This interface

would be a two-way link in that the coordinates specifying the next desired position and orientation would

pass through to the robot contoller and the coordinates

describing the actual position and orientation would

come back from the controller's reverse transf ormat ion.

having been calculated from the present joint position

values of the robot.

Even though these coordinates specify position* velocity and acceleration can be generated by varying the

spacial distance between specified locations. (See Fig

8. ) Given a constant time interval* velocity is detei

mined by the length of the commanded motion at each

new update. For example* if the update rate is 30 Hz

and the coordinate values input to the interface specify a 1.0 cm motion during each update cycle* then the

resulting velocity is 30 cm/sec (1.0 cm/cycle * 30

cycles/sec - 30 cm/sec). If the coordinate values call

for a 2. 0 cm move each time* then the velocity would be

60 cm/sec.

If the length of the motion sp

values is different for each

or deceleration will result,

started f)‘om a stationary po

inputs called For motions* eac

previous motions (that is* th

for a 0. 1 cm motion* the secon

the third for a 0.3 cm moti

would undergo an acceleration

value is avvived at in the

ec i f ied by th e coord inate

cy c le* then ac cel eration

For examp le. if th e robo

sit ion and th e coo r d inat

h 0. 1 cm larg er th an the

e f irst outpu t wou Id call

d f or a 0. 2 c m mo t ion.

on* etc )* th en th e robot

of 90 cm/se c/ sec This

fol low! ng manne T' D ur ing

-31
hanumcturer

’s

COMTRO

ll

ER 1 03 r~H 03 L.

p 1 03

O aO x: O 03 o 03 c P P rH

W x> L.

X CO

O o 3 c P o P x: w •rH o rH Q, C p 03 P CO c o o O 03 03 03 •rH 4J C3 >> o P P 3 CO o; c p p a P —C c c

jC •M

a CO 3 p 3

-p P 3 1 o > p

O c 03 p 03 p •rH P

CO 03

C CO P c 03 P CO Cm 03 3 rH o P •rH CO o O -P C V-l a 03 aO CO

03 03 03 o P P P 3 C Q. 3 3 p 3 P .3 c •rH 03 03 c a P o T3 3 CO •rH •rH c « C O

*rH L.

C P 1—1

rH P o P O •rH E a 2 03 •rH o

fH

O 1 •rH

a 0)

p P p

p

w

O

p o 3 p o 1—1 •3 o o a CO CO p o 3 p a p >> p p .3 3 o >> P CO p p O P

03 lX 03 03 c P 3 C o CO 03 P o CO

ra 03

p 3 P 3 C3 E •rH o '4H p o 3 P 3 P

•H 03

p 03 13

O CO P P

ao 3 3 P rH 3 - P 3 O i. 3 p 3 P P a 1—1 o i- P C 03 3 U p P O 3 P P 3

03 • O 3 3 3 E

(U CO CO

a P C P

s: 3 03 - P O •rH P X aO CO O 3 p P

CO 03 •rH •rH P P pO

03 >1 CO a.pO 3 o P

CO x: CO 3 p P 3 o

0) c s o CO p 03 03 •rH 03 3

03 P P 's P 03 o 3

ta 03 P CO o P P rH P P O C 03 p P 3

CO L. •rH COp ->> •rH > 3 Cm 3 3 CO P o 1—1

L.

O 03

C 3 3

1—1 o P P c 3 •rH

a P

•M S o CO 03 o 13 P CO 3 X o C •rH •rH P 1 E O 03 •rH P P •rH p iH C Cm 3 1—1 3 ro •rH o p

03 CO 03

a P 3 C3

p

p

L.

C •rH s O P 03 o o

aO CO 03

O o a

p o

03 L. •rH

X

Op CO • o

•rH -P o 03 CO 3 3 o 03 c c s O P 3

O. CO 03 .3 03 3 P O

CO •rH rH P P P 3 O p CO P CO P >> a o -P W P 0) >> 3 a CO o - p CO P 1—c X p 3 C a

XI 03 • .03 3 •rH 3 p

s. L. 0)

O P s E

<c o 3 o CO 3 p rH

CO P 03 P 3 C P O o w O P o P •rH 3 P p

•o 03 03 L.

O 3 p CO o P 03 CO P P p c

'J o C P p P O

O 3 3

f-Hu 03

C 03 03O P P P • lu a s rH CO a C3 P P P O
manufacturer s / CONTROLLER

FIG 7 This figure schematically depicts the switching

within the robot controller to accept trajectory point

input either from the manf acturer ' s supplied

t each-execute programs or from the user's supplied control system through the manufacturer’s specified robotindependent interface. The user has post-processed the

trajectory points into the manufacturer's defined coordinate system (in this example, a spherical coordinate

system) which then feeds into the internal coordinate

transformation algorithms to calculate the corresponding

joint values for the particular robot.
FIG 8a Plot illustrating calculation of two example

velocities (30 cra/sec and 60 cm/sec) obtained by specifying position values at constant time intervals ( 1/30

sec).
DISTAHCE

(CM)

IMSTANTANEOOS

VELOCITY

( CM^'SCC)

FIG 8b and 8c Example showing computation of instantaneous velocities (b) obtained from steadily increasing

distance moves in constant time intervals (1/30 sec) and

the resulting acceleration (c).
the last update period of the first second* the robot

would be commanded to move 3. 0 cm (30 updates* each

lengthening the motion by 0. 1 cm* for a total of 30 «

0. 1 cm ~ 3.0 cm) during that particular update time

period for an i nstantaneous velocity of 90 cm/sec. (3.0

cm in 1/30 of a second is an instantaneous velocity of

3.0 cm/cycle * 30 cycles/sec - 90 cm/sec. ) During the

last update period of the next second* it would move

6. 0 cm for a velocity at that instant of 180 cm/sec.

The difference in instantaneous velocities from one

second to the next would be 90 cm/sec. (The instantaneous velocity would be 90 cm/sec at the end of the first

second* 180 cm/sec at the end of the second second* 270

cm/sec at the end of the third second* etc.* that is*

the velocity is increasing by 90 cm/sec each second

giving an acceleration of 90 cm/sec/sec. > Thus* by controlling the length of the motions called for by each

successive set of coordinate values* both velocity and

acceleration can be specified through positional data.

This positional data will be sent to the interface at a fairly high update rate in order to ensure smooth and

stable motion from the robot. The actual update freq,uency of the data will be left up to the robot

manufacturer since this will be a function of the speed

of the coordinate transf ormat ion algorithms in the

robot controller. In general* these updates will be in

the range of 25 to 100 Hz. Uhatever rate is specified

by the robot manufacturer will be a constant for operation of that type of robot.

2. Data Format and Precision

Coordinate values can be represented in a different data formats (integer* floating-po

It was decided that the format of the data

specified by the robot manufac turer* as shou

cision of the data. The values of these

must be at least as precise as the joint pos

cators on the robot* or else some of the pve

pability of the robot would be lost. In gen

are in the range of 16-bit integer values.

number of

int* etc. )

should be

Id the precoordinates

itiori indicision caeral* these

V. STANDARDIZA1 ION

The general feeling of the group was that this interface was

not ready to be standardized. Standard i zat ion requires a total specification of all the data* in structure* format*

precision* communication protocol* etc. It was felt that

this would be too restrictive on both manufac turer s and

users at this time since the total requirements on this

-32-
interface are not that uiell understood yet. It was also

agreed that there was a. much better chance to get an interface of this type impletnented by the manufac turers if they

were allowed to specify the interface to be as compatible as

possible with their present systems. As long as an interface is fully specified* and the coordinates are in a

robot-independent form* the purpose of this interface would

be met. As mentioned previously* the post-processing required to transform any user-supplied coordinates into a

manfacturer 's-def ined coordinate system is a fairly

straightforward task. The availablity of inexpensive processing capability has somewhat relieved the requirement of

a single standard interface format* since* as long as the

information is completely defined* it can be processed by

either a user's or manufacturer 's controller into the required form for the robot system.

It is not improbable* however* that a standard should be

formulated- at some later time* after enough experience has

been gained concerning this interface to fully specify all

of the necessary requirements.

VI. TIhINO OF EFFORT

It was felt this was an appropriate time to consider setting

up this particular interface* but too early for a standardization effort. Several robot manufacturers presently offer

sufficient capabilities in their controllers that this interface could be introduced as an optional input to their

robots. As other robots are introduced with at least the

real-time coordinate transformation capabilities in their

controllers* it is hoped that these workshop efforts will

help to encourage the manufac turers ' inclusion of this type

of interface.

There is presently a considerable interest and the beginnings of in-depth programs within industry and government

aimed at integrated computer-aided-manufac tur ing systems.

The objective is necessarily dependent on a structured systems of modular elements connected by well-defined interfaces. These efforts will undoubtedly help to emphasize the

need and the requirements for these interfaces. Now is the

time to consider them and to begin their implementation.

-33
COMPLEX SENSOR INTERFACE

I. GROUP MEMBERS

Albuft« James S. « - Dexheimeri John* -

Baird# Henry S. - Becker# Dick -

Berkobiitz# Sid ~

Bouierman# Ed ~

Brower# William S. ~ Caughman# Don - Dawson# Brian - Hacker# Patrick - Handwerg# R. J. -

Kasvand# Tony -

Mei# Lori ~

Makhlin# A. 0. -

McClure# Ward -

Nagel# Roger N. *- Potter# Louis -

Seltzer# Donald - Spaulding# Charles -

Uranish# John - Walker# Jerry - Co- Chairperson

National Bureau of Standards

General Electric

RCA

Cheeseborough-Ponds# Inc.

Naval Ship R&D Center

GTE Laboratories

Control Data

Lockheed -Georgia Company

Cine innati-Mi lac r on

Boeing

General Dynamics

Nat^l Research Council

Ontario# Canada

SME

Westinghouse

Texas Instruments

National Bureau of Standards

RCA

Charles S. Draper

Unimat ion

Naval Surface Weapons

Nordson

II. DEFINITION

A complex sensor is one which has some sort of preprocessor

associated with it that performs at least an analog-todigital conversion on the sensory data# and usually performs

scaling# filtering# formatting# analysis# and coordinate

transformations as well. The preprocessor is typically

realized in the form of a microprocessor. A complex sensor

communicates with the robot control system by means of digital signals.

III. NEEDS AND SCOPE

The need for complex sensors is obvious. Present day industrial robots are d.eaf# dumb# blind# and have little or no

sense of force or touch. In order for a robot to interact

with an even slightly unstructured environment# it must have

the ability to sense errors and correct trajectories based

on sensory measurements. This typically requires computation by the sensory data channel to detect features# recognize patterns# and compare observed input with internal expectations. Usually a coordinate transf ormation is

34
necessary before the sensory data can be used b

system for modifying the behavioral actions

Certainly* if the data is visual* a great deal

tion is required before the control system

make decisions.

y the control

of the robot.

of computacan use it to

The use of sensory data for controlling the robot^s actions

implies not only computation* but speed of response. The

robot cannot exhibit high-speed* closed-loop performance (as

it must if it is to be cost competitive) unless the response

time of the feedback loop is short. Decisions cannot be

made and errors cannot be corrected until the feedback information arrives at the control center. High-performance*

closed-loop stability is incompatible with loop delays of

more than a feui milliseconds.

Sophisticated use of sensors and efficient processing of

sensory data also requires input to the complex sensor from

the control system. Sensory computations need to have information as to uihat action is being performed and what

response is expected from the environment. In the manufacturing environment* this is particularly important because

so much is* or can be* known about the environment. The vision system can be told almost exactly what to expect. It

can be furnished with a model of the parts with which it

must deal. It can even be told where they are (within some

tolerance). The vision system of one robot can be given a

picture of what a particular part looked like to the vision

system of another robot that just

same part. Thus* it is important

two-way between the control system

In fact* in many cases* the volume

finished handling that

that the communication be

and the complex sensors,

of data may be highest in

the downward direction*

sory processing module.

from the control system to the senThere are* of course* many kinds o-f complex sensors. Vision

is the most complex* the one for which the data rates are

highest and the processing most complicated* but force*

touch* and various proximity sensors can be extremely sophisticated as well. There are many types of data features*

3-dimensional models* and other types of information that

must flow freely and rapidly back and forth across the sensory interface. finally* there can be many sensors* or many

different kinds of sensors* on the same robot or associated

with the same group of robots.

These being the needs* the task is then to devise the most

efficient* simple* reliable* and inexpensive interface standard that meets these needs. It is* of course* important

that any standard for complex sensory interfaces not impede

the development of any sensor technology because of unnecessary limitations of the interface itself.

-35-
IV. THE WORKSHOP DISCUSSIONS

Th 0 complex sensory interface subgroup focused its discussions on the configuration shown in Figure 1. There are«

however* other possible physical configurations than the bus

structure of Figure 1. There is the star configuration of

Figure 2 where each complex sensor communicates with the

robot controller through a separate port. This simplifies

the protocol* since there is only one sensor on each port*

but it requires a large number of ports. In practice this

is often difficult because of the large number of pin connections required. One way around this difficulty, is shown

in Figure 3* where the robot controller communicates through

a single port to a multiplexer which provides the required

number of ports. A variation on the bus configuration is

the ring structure of Figure 4* which has the advantage of

redundancy. The ring can be broken at any point* and the

ring becomes a bus.

While some complex sensors may consist of nothing more than

an A/D converter and data communications port* it was assumed that a great majority of complex sensors would contain

a microprocessor with a program and a data storage area.

Thus* it was agreed that the interface should provide means

by which process-to-process communication could take place.

Figure 1 indicates the various types of information that

need to flow in both directions through the complex sensory

interface. Information flowing from the complex sensors to

the robot controller consists of highly processed information such as part position and orientation* part classification or ident if icat ion; inspection data such as part dimensions* surface finish* verification of the presence of

holes* etc .

t

force or touch vectors* or even matrices indicating the robot motions called for by sensory measurements.

Information flowing from the robot controller to the complex

sensors is of the form of commands to make certain measurements or to execute certain sensory processing algorithms;

state variables indicating what action is being executed by

the control system or by other systems such as conveyors*

robot carts* machine tools* etc; or even expected data or

parameters such as images* maps* or features which may have

been derived from teaching or from data bases containing

part character ist ics and process plans. The downward link

from robot controller to complex sensor processor may also

be used to download programs.

This implies that the downlink will often be required to

convey large quantities of data. In most cases the downloading of large programs or data bases such as images will

not be done during program execution* but will take place

-36-
FIGURE 1

Basic Configuration of a Complex Sensor System
Additional Sensors

FIGURE 2

Star Configuration

Additional Sensors

FIGURE 3

Star Configuration using a Multiplexor

Additional Sensors

FIGURE 4

Ring Configuration
before the robot's operational task is begun. Thus» the

data rate need not be sufficient to carry out large block

transfers in a fesi milliseconds. Nevertfieless* it is possible that the downloading of programs or data mag need to he

done frequently* (for example* between each part that is

presented to the robot)* so the data transfer may need to be

done in a few seconds* as opposed to a few minutes. If this

is the case* this requirement will dictate the speed of the

communications link.

It was assumed that the robot control system would act as a

master and the complex sensors and their processors would be

slave devices. It was generally agreed that it is best if

the robot controller polls the complex sensors* but it was

understood that using interrupts may be required by some applications. Therefore* the communications should not rule

out the possibility of an interrupt driven system.

It is crucial that sensory information be accessable by the

program in the robot controller in an efficient and timely

manner. It was noted that the time delays that could be

tolerated could vary depending on the type of data and the

use that is made of it in the control system. Information

required for tight servo loops must be available within ten

to fifty milliseconds. This is the turnaround-time* which

includes the time required to send the command requesting

the data plus the time required to collect and process the

data* plus the time required to transmit the results of the

processing to the robot controller. The data transmission

rates need to be high enough to support this entire sequence

for as many sensors as are required to respond within the

loop delay period.

Control programs must not only be able to test and branch on

complex sensory data but must be able to use sensory data as

arguments in functions and routines. This is an extremely

important requirement which does not presently exist on any

commercially available robot. It requires that the interface at the robot controller have some means by which complex sensory data can be inserted into memory locations accessible as arguments by the robot control software.

Without this feature it is cumbersome* if not impossible* to

cause the robot to move in the direction of a sensed force

or to track and acquire a visual feature on a part. Some

existing robot controllers allow the robot to be commanded

to move an incremental amount in x* y* z position* but not in

pitch* yaw* and roll rotation. At present* however* even

this is not easily accomplished through a convenient interface between the complex sensor and the data locations used

by the robot control program.

It is equally important that commands and expected data from

-37-
ij

I

4#,

, .

* ''" ^' " ^ "* - -- - '>-!*fil^(

' $ 4«;:'!.- #>;«6#t

' :'?

,

»r-»l ''4ir«44#»

:#i»4 T' . fX If « likwy 4 44 •«!<»' |44 «4f

>1 %jrtv||^ 44t 'j

'^'*'

' ^

AA^iW'it4^ i n«»j4ka

tfii iHt* '44^^ »*# '] t«ii” il®*'' ;4v*X»

,40.404" ' #44

00o#*-tofcmj.

^fO.f i ;, oil#

*4

41 f?ii4'

»V4 fi .#AI# * •04o|f 5¥4

|i4U#04 ;••

*<» -A

0| «IO'f«*ft vif

0#^, Wt>4^»' ; bo#oo.

4(li • .r

9 Hi \*i 0lcv«’»l0^4»

i^^X-wnt ?

. |m„ i>f»l’?s

rwifrtfir#'y|li4 oW^'¥im>,#.:'. O4’il#4i4¥<o ,.o¥l#.. oif -»,#ioX{i^?i

' 0.44 4o .Sra»#4

r.olT-t>»i«04;r jm**& *4T

oof»ou|»«» lio|iif^iio#«4

#rf7 fll4|Ji»- b«PO«04V4.^,|ttf^^

#10 doOoT# io# »roi'' of 140 04 ,

- - bU^4t¥i¥ 00 9 i OKI'T .oool#044 ¥"#^oiyir#Hi^

ytH r*0 i 4 iJ 9 fiiff999 ^% lOO Oiab. 4t|44*

“«*®» #9t(iiiM •f»0'*^s» oiw>*^;0vo4 4# fo=n'40<i^

%0l40 «" #*11i^l|0 0

nm^'mj.4 ip.y

.O'#.-'

~9'« • ^ « t ’V*' # O #4 4 0 #4 , 4 ¥ ' ^ "#'^,

1

*,'

o,V jfjlltrifo.-jii'j e*-nv^'% .#rioefitt,4»«0'',|i

iiaVo’^ fcffV# A 40: t»i4?'*tH >4l ¥l tvoi ‘-j^ .

., '"

'"'0, no toooly.iiA

i»oOr««il.n«Si *4 ,•#•. »«if -Jt« l|4-: '% O#

... .? .i434Jt«

«40¥^V^0.ft!«4

' «lOl

#vo #m 4

•itH 0 - Vf '4 Wo44 A

liO > • 4i¥o**'V\T oo‘44,'0. 0#»4pOo: f.Uoo# #o»« 1 1 .

. .J£^ Ortia OaOaOflVHiv #o#0,?ii>4# iil

vr> ...V. imiKiK^: <‘‘^t*l‘i !y »' *
I

CURRENT STANDARDS FOR

COMPUTER-COMPUTER COMMUNICATIONS

1. RS -232C

2. RS -449 (A high- speed version of RS -232C)

3. IEEE 583 This runs 132 parallel lines at 20 - 800 kHz,

with a length of up to 100 meters

4. IEEE 583 (CAMAC) This runs 2 or 4 serial lines at 20 - 800

kHz, with a length of up to 2 kilometers

5. IEEE 488 This runs 24 byte-parallel lines at 1000 kHz,

with a length of yp to 20 meters

6. MILSTD 155 3A This runs 2 serial lines at 100 kHz, with

a length of up to 100 meters

7. MILSTD 1553B (A 1000 kHz version of MILSTD 155 3A)

FIGURE 5
the robot control systen be available to the programs in the

complex sensor processor. This implies that the complex

sensor have a comparable interface by which information and

commands from the robot controller can be easily inserted

into the data locations used by the sensory processing

software.

The types of data# types of communication links

standard information protocols that have been u lar kinds of networking in the past were discus

felt that no new communications systems designs

at least not initially. Presently used

computer-to-*computer communication were felt to

The table in Figure 9 list's a number of presen

tions standards that were felt to be potenti

for a complex sensor interface.

« and various

sed for simised. It was

were neededi

methods for

be adequate,

t communicaal candidates

As a result of the fact that complex sensors will often be

required to work in a shop environment where electrical

noise interference is a serious and ever-present threat# it

was felt that an adequate communication protocol must include some form of error detection and correction procedures. It was also felt that fiber optics would ultimately be the communicat ions medium of choice. In the meantime#

the use of a single coaxial cable was felt to be a desirable

option. However# none of the standard systems in Figure 5

work with a single signal.

V. RECOMMENDATIONS

It was concluded that it is too early to recommend any

specific standards for complex sensory interfaces. At

present there are only a few commercially available robots

with complex sensor interfaces of any kind# and these interfaces are limited in utility and cumbersome to use. Thus#

there is very little as yet to standard i z e. Furthermore#

there are too few persons with sufficient experience in complex sensors to make reasonable recommendations as to what

such standards should be. However# this will undoubtedly

change in the near future. Many research labs and robot

users are pursuing the use of complex sensory data in robot

control systems. *lhus# an experience base is rapidly being

developed.

Clearly it is not too early to begin discussing the requirements and suggesting promising approaches. This was the

purpose of the workshop. It was recommended that these

preliminary discussions be followed up with additional

workshops and that contacts be established with the appropriate standards organ! zat ions so that complex sensory

interface standards can be developed as soon as that would

be practical. This is an area where interface standards

38-
might be a pouierful force in creating a market for complex

•eneors. An interface standard would allow manufac turers to

develop a single product that could be used on a wide

variety of robot types.

-39-
FUTURE GUIDELINES TOWARDS INTERFACES

I. GROUP MEMBERS

Nagel« Roger N. * - VanderBrug* Gordon* -

Albus« James S. -

Ames* Carl V. -

Baird* Henry S. -- Barbera* Anthony J. - Brower* William S. - Colleen* Hans -

Dunne* Maurice ~

Ennis* Jerry -

Mei* Lori —

Makhlin* A. G.

Mayer* Gordon -

Neuilin* Burt -

Plumley* Wally *- Sheehan* Joe - Smith* Bradford M. - Snowdon* A1 *- VanderBrug* Gordon - Walker* Jerry -* Wiley* Jack -*

* Co-Chairperson

National Bureau of Standards

Automat ix

National Bureau of Standards

General Dynamics

RCA

National Bureau of Standards

Control Data

ASEA

Unimation

McDonnell Douglas

SME

Westinghouse

Wr igh t-Patterson

Department of Defense

Loc k heed—Georgia

Naval Ship R&D Center

National Bureau of Standards

Eaton Corp.

Automat ix

Nor d son

John Deere & Co.

<NBS Planning Office)

II. INTRODUCTION

The workshop sessions on Future Guidelines towards Interfaces were specifically charged with discussing language*

system integration* and database considerations in the future of robotics. It was a ground rule of the discussion

group that the time was too early for standards efforts by

the very nature of the topic areas. However* the directions

and trends of the future of robotics were discussed with an

eye towards the need for future standards and comments on

standards were reflected throughout the discussions. It became clear early in the discussion that it was difficult to

separate the robot of the future from the factory of the future and discussion often shifted to the role of automation

in manufacturing cells and factories wherein robots played a significant role. It was conjectured that the role of the

robot in the factory of the future was not as an individual

component but as a part of the system. The session leaders

made a strong attempt to focus the discussion around robots

in the factory of the future and stand-alone robot systems

of the future.

-40-
The discussions that took place at the two sessions covered

not only the three areas of language# systems integration#

and databases but also languages for the factory# systems

debugging# and robot requirements in the future. In the

write-up which follows# discussions are summarized for each

of the six topics.

III. SYNOPSIS OF GROUP DISCUSSIONS

A. Robotic Languages

The group felt that the current method of teaching robots

via a teach box would be replaced in the future by off-line

programmming languages* “off-line" in this context meaning

without the robot carrying out the commands in real-time#

but not without a terminal and an interactive language processor. Language can broadly be categorized as the user interface to the control system of the robot. The general perception of the group was that robotic Languages as found today can be put into two broad categories: explicit languages

and implicit languages. An explicit language is one in which

one talks about the robot joints and positions. Examples of

explicit languages include VAL# EMILY# SIGLA# and UAYE. Implicit languages are those in which one describes the tasks

to be performed rather the motions through which the robot

will pass. Examples of implicit languages are AL# ROBOT APT*

AUTO PASS# RAPT# and MAL. There was a general discussion

about the fact that the two categories defined above were

rather broad. In actuality# several levels exist within each

of the categories# and there could be some disagreement

about the categor i z.ation of a particular robot programming

language. Because oP the fact that most of the languages

described above are not broadly available and that the group

did not have significant experience with several of them# it

was decided that it would be more important to talk about

the desirable attributes of languages rather than go through

an exhaustive analysis of the languages themselves. The

group postulated the following as desirable attributes for

robot languages.

A language for programming a robot in an off-line mode

would ideally be robot-independent. It should be a standard# and there might need to be several languages

with efforts similiar to that being done for ROBOT APT

at the current time. The language must allow for a

hierarchy of control and exist at several different

levels of complexity. The language should have provision for modifying the behavior of the robot due to the

input of real-time sensory data. The Language should

have good interfaces to the various manufactur ing and

design databases found in a modern manufac tur ing environment. Programming of the robot in this language

-41 -
should be engineered so that the user need not be a computer scientist but rather someone involved in the

manufactur ing process. The language must have provi--

sions for system verification or debugging of the robot

program a-s created at a terminal. Examples of this

would be a graphic simulation of the robot program.

Robot programs should not be made robot specific until

the program is ready to be executed. That is« it should

be symbolic until the time of execution. Postprocessors for particularized robots should be created

in order to allow the language to be independent but

available for a variety of robots.

The group concluded that the several efforts on robot

languages should continue and that others would most probably surface. At the current time it is far too early to begin a standard i zat ion process on any one particular

language. However* as experience is gained in the use of

these languages* some of them will naturally come forward as

standards of the industry.

B. Systems Integration

The group felt that robots will naturally be imbedded into

the factory of the future. The key concepts with respect to

the integration of robots into the factory of the future are

the accessing by robot programs of the databases found in

computer-aided design systems and the passing of control information that needs to be used by robot programs in workstations and higher-order factory constructs. In both of

these interface areas it was felt that there is not yet

enough industrial experience to define standard interfaces.

However* key issues wera identified with respect to robots

accessing databases in the manufacturing and design arena.

It was pointed out that it will be necessary for designers

to indicate the view* pick-up points* and other parameters

about a part being designed that are relevant to the robot

manipulating that part. This requires the robot to have access to the descriptive geometry and part description information created by the part designer. With respect to control information* the simplest method of passing it to a robot from a higher-order construct would be in robotindependent position coordinates* using standardized terms

and commands that could have meaning to multiple vendors'

robots. In addition to control information* the robot will

have to interact with other sensors in the automated factory. Because parts of these topics were covered in the complex sensor sessions* the group did not linger on this topic.

-42-
C. Databases

As uias reported above* databases and the interface of robot

programs to databases are important concepts if me are to

integrate robots into higher-order factory systems. In particular* it was felt that the database interface was critical to creating a systems hierarchy for a manufacturing

cell. Potential database interfaces were identified in

several areas.

1. A manufac turing database.

2. Inventory of parts and equipment.

3. Shop floor database.

4. Scheduling.

5. NC databases.

6. Process planning databases.

7. Design databases.

The group^s conclusion with respect to databases was that

the concepts required in databases had impact on the ability

to integrate robots into higher-order systems and on the

design of robot programming languages. The group concluded

that* as the use of robots becomes more complex and robots

take on higher-order tasks in the factory manufacturing environment* they will by necessity need access to several of

the databases outlined above in order to carry out their

tasks.

D. Languages for the Factory

The group discussed the language for control of an automated

manufacturing operation and spent a good deal of time trying

to define tha levels in a factory. There was excellent

agreement on the fact that a factory was organized into a

set of hierarchical components. There was significant

disagreement on the identification of each of these levels.

Figure 1 shows the levels as perceived by the group in the

ICAM terminology. The process is the lowest level in the

ICAM terminology and represents the carrying out of a particular task. Above the process is a workstation which

coordinates the efforts of several processes. Above the

uior kstation is a cell* above the center* and above that* a

factory. Typical commands for the bottom three levels of

this hierarchy have been depicted in the figure.

As the group attempted to state commands for the center and

the factory* it became clear that there was some disagreement as to the exact definitions of these levels. The group

was* however* able to label several processes which go on

across some of the higher-order levels* and they have been

included in Figure 1. The general conclusion was that a

-43-
FACTORY

w

eti 13oM

P4

ICAM

Automated

Factory

Levels
factory would be organized into a hierarchy similar to that

used in the ICAH terminology.

As part of the discussion on hierarchical organizations! the

group examined the hierarchy for the NBS robot. The NBS

hierarchy has a complex task at the highest level# breaking

down into simple tasks# trajectory calculations# coordinate

transf ormations# and finally servo commands. It was felt

that the NBS experlance with this hierarchy substantiated

the concepts expected to be used in a modern manufactur ing

cell. The group felt that# as factory plans are organized

in the hierarchical nature and as they begin to be implemented# there would be better agreement on the terminology

and commands which exist at the different levels of the factory. General principles that the group agreed upon were

that the organization would be hierarchical# that it will

use the task decomposition approach# irhat all the levels exist at each moment in time with different cycle times for

up-dating# that each level in the hierarchy has its own commands or input language which could be carried out in timesequencing 'commands and inputs into lower levels#* and that

each level would get input from above in the nature of commands and from below in the nature of feedback.

E. Systems Debugging

The topic of debugging constantly arose in the sessions. In

particular# the availability of debugging tools in the future use of robotics was considered to he extremely important. The need for debugging# it was felt# underscores the

essential nature of establishing well-defined interfaces.

The use of graphics at the manufactur ing cell level was considered to be an important ingredient for debugging off-line

programming# in order not to tie up resources and for safety

considerations (for both people and equipment). The use of

graphics will require an interface standard to allow' graphic

products to work for more than one robot and more than one

robot programming language. The group felt that# beyond emphasizing the concept of building in debugging tools for

off-line robot programming languages# there was not yet

enough experience to specify distinct or direct algorithms

for the debugging.

F. Robots of the Future

The general consensus of the group was that robot systems

would become more and more complex. They would use offline# higher—order control languages as well as employ vision and other complex sensors. They would have robotindependent programming languages. Robot hardware would use

standard interfaces to the language modules and include

post-processors as well as defining robot-independent

-44-
r 1

«l*01

’ ‘

^ Mj

*a T,

j

a,s»l >4t f ,,«

I ri»(r*«>f »,Xyain# *»#«<> , rmon

' ^‘•wt n$-i^^nmi4 Hi iif 4tiw •Jjltf*<•' ,fA0 #*<*!

* ^1/ ijiwiw ir-rf p-if ‘ #4»f ,<it>

' " ' "'

i:lf«‘i>*r®«k'|i*^% #4»i. .^lUOYa

nil^t pi 4^ «« PHk t^W#ip

yasaX*?flp|»5?jt Bdi t®

>

J f

I -‘tt «i«v#i >»<fi ij\ji»%#(g^ »4^#ojY<ia* ®4# Aty

%.>m im *»i

<* j;f5^

' <»•« * ^'4»HQW

1

»NiB'?> ftl^ 'V'0'i -3i|d 1 w'fw* »» ^'Mw /'- — -— -^T" jj^- • - . - - -mf> i;j^9 hnltfi*^ #4

^rm ultv®i ^ -•#^3 . »t| BVO^^ l»ad?®^ tv^jn:|| #

"<->,#4iwy|, Vft ' .y# 4.

j >«••, Eii^

"f“ ! t'rf*Av»rt’*li ril «tOY®

>4f «i »®

t«v»i

,v#’ |*®®IU3:I^24<

» m4tx

1®

-*^te,> f«^»I; i(*i| 4«1 Y«l43#4PH^®<t , «4® '*if^ . -r . . ^^-•. t®ii*^Yii fT«>iS«4®VY®% itwidwhfiti m «4

» *r« '»«1^ v 4*4®Y#® lan«f

3|4®4Ya SW|I »a#4»r#4aA‘'fui t4|.«

®««*' «*>I4 »'»<>» ®f*i 4o#i^r»®} ,fi®iii Y«4 i '*'»#» |04

'-<P* 4rto<^os! tin I ayaTtt\«S*T

im>iio4#i» ftl 9HibHm4

Ti4*il4 Y» 44-rtiHa43*

«ni|ily^ yrf* M

I

' ^ ;'l?^ ay®Y| #44 1 ® ’tw»n»#ny3 f*T»n«»a 4HT ^

- »Y(?% f*fo0

•W tl®« «• 4y|®u®1rii«l 1&W44 ilaiA^firtU

-4oit‘» y¥®4 i^i^uw ®4#f 4»fOlf

• i»%i(i-4ySH# 4c4*^*^ 5tl»4<s®‘^-4®w tf jwyjff®

•®yf4Yii ayljka®'! «d#’ bYm4«®4«

Yv'^ aXo<»t

90n tii*^

ti

/•

Jil -=JH ®iU I'I'vw-.f'. V®4f |ii*

i.

'jLi if
position commands. Robot software would allow for the integration of the robot into complex factory systems or for a robot with a complex array of sensors to be used as standalone equipment.

IV. CONCLUSIONS

In summary# the Future Guidelines working group concluded

that robots would be more extensively used in the factory of

the future. Off-line programming languages for robots and

manufactur ing cells would develop in a hierarchical fashion.

Advanced prrogramming Languages will need to be robotindependent and should provide extensive debugging techniques in an off-line mode. Interfaces will need to be defined for robots# databases# control systems# and complex

sensory devices. In addition# hardware interfaces need to

be defined to allow for smart end effectors and a variety of

hardware connections of the robot to its environment. The

general conclusion of the group# as expected# was that it is

currently too early to start a standard i zat ion effort in

these areas. However# the topics should be reviewed at a

future conference# in order to measure progress and stimulate interest.

-45-
GENERAL RECOMMENDATIONS AND CONCLUSIONS

A group session s»as held on the last day of the workshop

general discussions and conclusions by the full group on

various interfaces. Each session chairperson presente

summary of their group's recommendations and conclusi

The starting up of a standards effort was recommended

both the Simple Sensor and Wrist Interfaces. It was

that both had progressed to a point where standards coul

implemented without impeding any developing technology.

for

the

d a

ons. for

felt

d be

The Common Robot Control and Complex Sensor Interfaces

chairpersons reported on guidelines towards their respective

standards. It was felt that the Common Robot Control Interface was ready to be implemented* but not ready to be standardized. Standardi zation would require a full set of specifications as to data type and rate* protocol* etc. to be

agreed upon* and was felt to be too restrictive on users and

manufacturers at this time. The Complex Sensor Interface

chairperson reported that at present* complex sensors were

not in wide use* and as such* also not ready to be standardized. It was felt that further discussions should be held at

a later date. Both chairpersons recommended a waiting

period for technology and experience to develop in these

areas before actual implementation of a standard.

The Future Guidelines towards Interfaces chairperson* having

a rather broad area of topics ranging from databases to

off-line programming* outlined a list of desirable attributes for each of the topic areas. As most areas are still

developing (or are virtually non-existent at present)* it

was recommended that each topic area be examined again in

another standards workshop to be held in mid-1981.

-46-
APPENDIX I

The

typi

foil

cal

ouiing drauiivitis

commerical robo

shoui the uirist

ts on the mark

mountin

et today

9 surface for

-47-
A i ,• iMei '/

•!f} pH V A ^

I- A |f«.

)>

4

•

t «.

,sm'

“P'S ''f|

MJ** «*«yv:v(lr»yA^ .'

• •» - f *1!'

. a ,,., r>«. •.. H _ , ^ |r. # '4-r : *-»§ '

-"!v<* T' » '"»>»' tt'f ^rir»^ rt 'i

';< I :'A 'J4^.l '.

V;<5i t-f| ,f#f: ' Jl'e' VA+ ffj^t 1% b‘* ::'it'f0-'''i'#«

•„ 0 i ; *. i» i^, :, :l ij^% la

«tl'. i«v ' 4*?»i'' -i#A. *#|, ,•«

I «444 'IfV^ ^ ^ a

<J'§#,.'

. !g m f\^T ;v A4 i t . liA» 1 i l«‘A W »

lo'y •

-..

-

.: rw ' yf*^ ‘WwrW«*'t'

mff-vKiiif -«r 4 -«w«tn^ « r^SAtJ in #4 ‘*#'5 1^4

' %^‘i>r tit'll !»f »l®'^|A#:^:/,#T^fy ''*

; 4i 'ttr

x'-^1^ 0i4nsi0T*4 ,0«kr : tMM0i: M?

lit.

i.'c i.V''f>» <*r.f.
ti
!
D Ii I«i

i*
736-12363-B


0«H««MAL

OATS

09

MAWINO

736-

12361-

6l
o
738-

12360

-B
MAL

OATS

or

73&-I236&M
//

jl

< I n •**

738-12365-a
756-12359-b
736-12356- E>


NBS«II4A (REV. 2«8C) U.S. DEPT. OF COMM.

BIBLIOGRAPHIC DATA

SHEET (See instructions)

PUBLICATION OR

REPORT NO.

NBSIR 80-2152

2. Performing Organ. Report No 3. Publication Date

4. TITLE AND SUBTITLE

NBS/ICAM WORKSHOP ON ROBOT INTERFACES

June 4-6, 1980

EDITORS:

Thomas Wheatley. James S. Albus and Roger N. Nagel

6. PERFORMING ORGANIZATION (If joint or other than NBS, see instructions)

NATIONAL BUREAU OF STANDARDS

DEPARTMENT OF COMMERCE

WASHINGTON, D.C. 20234

7. Contract/Grant No. ^PR SY1455-78-00003

8. Type of Report 8< Period Covered

Final Report

9.

SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (Street. City. State, ZIP)

The National Bureau of Standards and

the Air Force ICAM Project, Air Force Systems Command

Wright-Patterson Air Force Base, Ohio 45433

10.

SUPPLEMENTARY NOTES

I I Document describes a computer program; SF-185, FIPS Software Summary, is attached.

11.

ABSTRACT (A 200-word or less factual summary of most significant information. If document includes a significant

bibliography or literature survey, mention it here)

This paper will describe the proceedings of a workshop on robot interfaces held at

NBS from June 4-6, 1980. Five possible areas for standardization of interfaces were

discussed: (1) Simple Sensors, the interface between simple peripheral devices and

a robot control system; (2) the Wrist Interface, between the robot wrist and the end

effector; (3) the Common Robot Control Interface, between the robot controller and

the coordinate transformation module; (4) the Complex Sensory Interface, between the

robot controller and vision, complex touch, and other sensors; and (5) Future

Guidelines, covering data base, offline programming, and system integration interfaces. The goal was to define the areas ready for current standards, and those for

which guidelines for future standards would be useful.

This workshop was jointly sponsored by NBS and the Air Force ICAM project.

12.

KEY WORDS (S/x to twelve entries; alphabetical order; capitalize only proper names; and separate key words by semicolon s) Complex Sensors; off-line programming; robot control; robot interfaces; robot standards;;

robot wrist; simple sensors

13.

AVAILABILITY

Unlimited

I ] For Official Distribution. Do Not Release to NTIS

I I Order From Superintendent of Documents, U.S. Government Printing Office, Washington, D.C. 20402.

Order From National Technical Information Service (NTIS), Springfield, VA. 22161

14. NO. OF

PRINTED PAGES

15. Price

USCOMM-DC e043-P60
V*