robot programming

June 13, 1988

ROBOT PROGRAMMING

By Christopher Ce Jobes

Contract No. S0368000

BOEING SERVICES INTERNATIONAL P. O. Box 10838 Pleasant Hills, PA 15236

,.!

ROBOT PROGRAMMING

.

-..,

i

JUNE 13, 1988

Prepared by:

c. c. Job~s , Projec(Engineer

(l

Approved by:

?;{-? 71f~u.? L. F. Miller, Deputy Program Manager

Ii

'l

1

P O. BOX 10838

CCJobes

1-~-f?1C

PLEASANT HILLS , PA 15236

June 2 0, 1988 W6190-88 - 24

- ,

tLFMiller

----_._- - _'il ..

--

- -r To: f--

I

I Aft t e ntion :

I

Sl bject:

ren ce :

R~£E

I ..:.r H

..

....

,..

U.S. Department o£ the Interior Bureau o£ Mines Pittsburgh Research Center Cochrans Mill Road Post O££ice Box 10870 Pittsburgh , PA 15236 Contract S0368000 D.H .

Ambrose

Report Transmittal--Robot Programming RD 21; Support Services £01' Fundamental Investigations o£ Robotics in Mining

.. ',;...

;..

'. E nc ]osed

is a copy o£ the subject report. jUPPli ed as requ ested .

br

Additional copies can

~ __ J

I

r~ ,

INFO. ROUT I NG

-I

I

-- f - -

Sincerely ,

JRBadini

BOEING SERVICES INTERNATIONAL I

KMChulig JAHummer

L. F.

.MCLeigh JF1f\i11er

Miller

FOMC/METF Deputy Program Manager r

As

AEModzik SBNesbitt RETURN TO

--;-

sure: stated

C.A .

Goode

-WRR[ 3Por,JDENCE

REL EAse

FORWARD TO : CORR ESPONDENCE FIL E ~

COHI~ISPONOUIU

f 11_[ (:U f'Y

A DIVIS!ON ,OF BOEING ,TECH~'lI~AL OPERATIONS, INC. I

Date: Label Number: Project Name: Subject:

To:

D. H. Ambrose

cc:

J. R.

K. M. J . A. M. C.

Badin i Chulig Hummer Leigh

G. A. J. F. A. E. s. B.

June 13, 1988 194015

Fundamentals of Robotics in Mining Robot Programming

Marsh Mi 11 er Modzik Nesbitt

Object:

To develop a monograph on the subject of robot programming for the Fundamentals of Robotics in Mining IIRobotics Handbookll.

SUlllllary:

The hierarchy of robot control languages was determined to consist of six levels: zero-level programming; standard teaching robots; graphical teach programming; first generation manipulator languages; second generation manipulator languages; and task or object-oriented languages. Each . of these levels was investigated with emphasis placed on the current state-of-the-art software available, advantages, and disadvantages.

Written by:

Approved by: Larry F. Miller METF Deputy Program Manager

50272· UII

REPORT DOCUMENTATION PAGE 4.

)1. REPORT NO.

Title and Subtitle Robot Programming

7. Author(s) Christopher C. Jobes 9 . Performina Oraanizatlon N.m~nO-Address Boeing Services International P. O. Box 10838 Pleasant Hills, PA 15236

Recipient'. Acce••'on No.

3.

Report Oate

5.

13 June 1988 8.

Perform ina Oraanization Rept. No.

10. Project/Task/Work Unit No. 11. (C)

Contract(C) or Grant(G) No. S0368000

(G)

Sponsorina Ors.nization Name and Address Pittsburgh Research Center U. S. Department of the Interior, Bureau of Mines P. O. Box 18070 Pittsburgh, PA 15236 15. Supplementary Notes This report, in its entirety, was prepared by BSI Documentation .

12.

16. Abstract (Limit:

200

13.

Type of Report & Period Covered Topical Report

14.

words)

This monograph presents the Boeing Services International study on robot programmi ng techni ques and 1anguages for the U. S. Bureau of Mines. This study, a part of the Fundamentals of Robotics in Mining effort, classifies robot programming by type, and the characteristics of each type are listed. Commercially available robot programming languages are then categorized by type.

17. Oocument Analysis a. Oescriptors Automation Robots Programming languages Simulation languages b. Identlfiers/Open·Ended Terms

c. COSATI Field/Group08-I, r~ining Engineering and 13-1; Machinery and Tools 18. Availability Statement 19. Security Class (This Report) 21. NO,,' sages This report ;s submttted in compliance with the - ------contract and is not for release until approved by ~----------------------~-------22. Price 20. Security Class (This Pase) the Bureau of Mines. (See ANSI-Z39.1S) OPTIONAL FORM 272 (4-77) Se. Instructions on Reverse '(Formerly NTIS-35) Oepartment of Commerce 3

CONTENTS

Abstract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction............ . ............... . .......................

Robot programming languages..................................... Zero- 1eve 1 programmi ng. . . . . . . . . . . . . . . . . . . . . . • . • . . . . . • . • • • . • • • • Teaching robots. . ........... . ................... . .......... . .. Walk-through programming............ . ...... . . . ....... . . . .... Lead- through programming........................ . ........ . .. The graphics teach method................................. . ... First generation programming languages........................ Second generation programming languages....................... Task/object level languages................................... Application of robot programming languages to automated mlnlng....................................................... References . .....................................................

5 5

5 6 6 6 7 7 8 9 10 11

11

ILLUSTRATIONS 1.

Palletizing with AUTOPASS •.•.... . ...... . •.••.•.••••••••••••

4

15

ROBOT PROGRAMMING By Christopher C. Jobes!

ABSTRACT This monograph presents the Boeing Services International study on robot programmi ng techni ques and 1anguages for the U. S. Bureau of Mines. This study, a part of the Fundamentals of Robotics in Mining effort, classifies robot programming by type, and the characteristics of each type are listed. Commercially availab l e robot programming languages are then categorized by type.

INTRODUCTION Robot technology is one of the most promising tools in manufacturing and will have a significant impact on the efficient use of 2 production equipment (1). One major obstacle in using robot manipulators as general purpose assembly machines is the lack of suitable and efficient communication between the user and the robotic system so that the user can direct the manipulator to accomplish a given tas k (f). Thus, the defi nit i on II A robot programmi ng 1anguage is a means by which programmers can express the intended operations of a robot and associated activities" (1). It is important to note that robot progranvning languages must not only provide a means of expressing the mot i on of the robot, but a 11 ow the programmer to i nterf ace a 1arge number of things together: users, robot control systems, sensors, geometric modeling systems, planners, knowledge systems, etc.

ROBOT PROGRAMMING LANGUAGES Recent intense interest in robot i cs has created a 1anguage and soft ware explosion in the field. New commercial offerings are being introduced rapidly and research institutions promise even more sophisticated developments. The definition of a complexity hierarchy of robot control languages can place these languages and software developments in perspective (~. The hierarchy consists of six levels : o

o o o o o

zero-level programming; standard teaching robots; graphical teach programming; first generation manipulator languages; second generation manipulator languages; and task or object-oriented languages.

Iproject Engineer, Pittsburgh Research Center, Boeing Services International, Inc., Pleasant Hills, PA. 2Underlined numbers in parentheses refer to items in the list of references at the end of this report. 5

ZERO-LEVEL PROGRAMMING Zero-level programming. also known as hardware-level programming is commonly used in robots where not much flex i bility in operation is required . This type of programming is typical of a drum controller which. as it rotates. opens valves causing the r obot manipulator t o move. This sometimes takes the form of air logic in pneumatic pick-andplace robots or cams in mech an icall y pr ogrammed pick - and-place r obots . These types of r obots are known as bang-bang robots s i nce t he manipulator moves at fu ll speed until it runs into a stop before executi ng the next move (43). The advantages of thi s type of programmi ng are that it i ss imp 1e The disadvantages are that it has limited versatility. and reliable. and can only be used for pick-and-place operations.

TEACH ING ROBOTS Teach and playback. a lso known as gui ding. is the mos t commo nly used programming method in present - day industrial robots {£.-~. This type of sequencing consists of two methods. walk th rough programm ing and lead throug h programm ing.

Walk-Through Programming A robot program is a path in space composed of multiple po i nts . At each point in the program. an operator indicates whether the robot is to stop or pass through the pOint. In addition. the operator has the ability to instruct the robot to wait for a s i gnal at any po int or t o generate a signal at such a point. In walk through programming , the operator physically moves the robot through the path in space . While the robot is movi ng. the computer controller samp 1es feedback s ignals from the ac t uator sensors at each of the robot I S joi nts to record the robot program. Some control lers allow either conti nuous path (CP). point to point (PTP) sampling. or a mixture of both, depending on the nature of the task to be performed. to maximize efficiency and precision (§). CP samp 1 i ng is more des i rab 1e for tasks such as spray painting or arc welding. in which the path is critical to performance (§). One advantage of CP programmi ng is that it can be easily programmed f or these tasks by a skilled painter or welder who has little knowledge of computers. Disadvantages in this method lie in that it requ i res many points to follow a CP thus. it is difficult to edit and requires a large amount of memory. Therefore, the program has limits on its sampli ng rate and thus its resolution depending on the time required by t he pr ogram. FUNKY. a CP programmi ng 1anguage. uses a joyst i ck to move the robot. Control of the system is very s im ilar t o a tape recorde r with PLAY. ERASE . RECORD, FAST FORWARD, and REVERSE modes (14) .

6

lead-Through Programming In lead-through programming (which is more common than the walkthrough programming (~), the operator positions the robot using buttons or toggle switches on a teach pendant, and indicates when the robot has reached a point that is to be entered into the program. The operating system converts the entered information into robot coordinates, or cartesian coordinates which describe that position in space. The PTP program coordinates are then stored in memory requiring far less memory than a CP program for the same task. The teach pendant includes keys that allow a program to be single-step executed for editing and allows po i nts to be inserted, deleted, or changed. T3 is an example of a PTP teach box programming language (15). Operators using the teach box methodology frequently have access to a t erminal or keyboard arrangement which facilitates the use of vendorsupplied software (sometimes called bl ackbox software) which allow one to store and retrieve programs, and to perform rudimentary editing operations. The blackbox software includes a collection of routines commonly used in robot programming. Typical routines may be used for pa ll etizing operations, facilitate the use of binary sensors, provide for simp 1e error recovery, and def i ne re 1ocatab 1e program segments to ease robot programming. The advantages of this method of programming are that programming is easy, it is mastered quickly, and it is especially suitable for palletizing and other material handling tasks. Its disadvantages are that each vendor has unique human interfaces (i . e. programming convent ions) and b1ackbox software routines and there are currently no standards for representation of programs developed by this method. Thus it is difficult to create a generalized robot programming capability, even though generic robot programming elements can be clearly identified. The lack of standards goes beyond program representation. Most robots have an RS-232 communications port on their controller; but their are no standards for the information that might flow across that interface. The quest for standards is a recurrent research theme at each level of the robot language hierarchy (l).

THE GRAPHICS TEACH METUOD Many firms that originally began as vendors of Computer Aided Design (CAD) equipment have begun to realize that their graphical method of programming numerically controlled (NC) machine tools has some application to the programming of robots 0). In fact, specialized graphic robot programming systems have already been developed and introduced to the current market. Such a graphic system begins with a library of three-dimensional robot models which includes the geometry of each robot, along with a model of the constraints on the robot's motion. The models also contain approximations of the control algorithm for each robot. At a typical session, the user selects a robot from the library; he then models a work cell by using an additional library of other devices, such as conveyors and machine tools typically found on the manufacturing floor. 7

Some c~mmercia l lY ava il able software packages are: Autobots, Autosimulati ons; CimStat ion 2000, SILMA Inc.; IGRIP, Deneb Robot ic s, Inc.; PLACE, McDonnell Douglas; Robcad, Technomatix; and Robographix , Computerv i sion . The advantages of this type of programming are that: th e user can see a graph; c animation of the work i ng robot; the systems are qu ite powerful and effici ent at evaluating alternative robot s that might be used f or a part icular tas k; the layout of the work cell can be checked and alternative layouts evaluated; it can be used for visual coll i sion detection ; and actual language commands may be interspersed with the gr aph i ca l instructions for certain robots. The di sadvantages of this type of programming are that: because of the lack of standard robot interfaces, these systems do not ye t produce r obot programs unless special arrangements have been made with the vendor of the particular robot (however, when programs are generated, this technique is cal l ed off-line programming (10,16)); current graphic simulati on systems do not have the ability to model the physics of the real world (gravity, etc.) or more complex things such as the us e of sensors to adapt and change the r obot s program; and vi su a 1 colli s i on avoidance is not recommended because col lisi ons cou l d occur and not be observed by the user. I

FIRST GENERATION PROGRAMMING LANGUAGES The first generation of formal languages for robot programming can be thought of as early robot programming systems created by extending an existing high-level language l ike BASIC (g) to provide for robot motion, lock step coordination, elementary sensor usage, and a minimal operating system. They have commands that allow them to trace straight lines and in some cases circles or arbitrary curves. Using lock step coordination, they have the capability of ge nerat ing, or waiting for, a binary signal at predetermi ned po i nts in the robot's program. This is used to coor d i nate the mot ions of t he robot with other dev ices in t he environment. Elementary sensor usage implies the use of binary sensors that are typi cally connected to the robot cont r oller through digital i nput and ou tput bit-oriented logic. The operating systems supplied with the first generation programm i ng languages were deSigned to be selfcontained and to be usable by operators without computer science training. Typically, only simple operating system capabilities are provided, such as prog r am ed it i ng, program storage and retri eva 1 on di sk , and uploading/down l oading a program to another computer . Some currently available first generation robot programming languages are (3-5,7,9,11-13): ANORAD; AR- BASIC , American Robot (24) ; 0TRAN. Se iko (26);-Ef.1iTIE;" McDonnell Douglas/USAF (25) ; EM ILY; LM. Grenob l e. France (27) ; RCL ; RPL. SRI International (17-19) ; SIG LA. Ol ivetti (22); and VAL, Unimation Inc. (20.21,23). -3Reference to specific products do not imply endorsement by the Bureau of Mines. 8

These first generation systems have serious limitations that restrict their robotic applications. They are unable to perform complex computation, and they are difficult to interface with vision and other complex sensors. The languages provide only limited communication with other computers and controllers, and they are not extens i b1e ina way that allows one to add commands and build capabilities into the language. The human interface was designed to allow for flexibility in programming while not requiring expertise of the programmer. It thus serves two opposite masters and is compromised in both domains. This class of language can be thought of as allowing the sophisticated user to define his own blackbox software. The languages remove the rigidity of augmented teach box software but provide very little new capability.

SECOND GENERATION PROGRAMMING LANGUAGES Second generation programming languages were developed by computer scientists to overcome the first generation languages' limited extensibility, communication, and computational power. Thus they have the computational complexity of a modern structured computer language. Some clearly show their origins, while others embody new concepts. Some of the most recent languages like VAL II are built upon earlier robot control languages. While these languages have the expected robotic extensions for motion, sensor communication, and control, they are enhanced by improved operating systems with more powerful editors and file handling capabilities. Unfortunately, many second generation languages supplied by robot vendors are closed systems; this needlessly restricts their capabilities for computer communication and coordination. Some of them handle geometry, but in a fashion similar to those developed for NC machine tools. Some currently available second generation robot programming languages are (5,7,11,13): Al, Stanford University (28,42); AMl, IBM Corporation (29);- HELP; General Electric Company (30); JARS, Jet Propulsion laboratory (31); MCl, McDonnell Douglas Automation Company (McAUTO) and the U.S. Air Force ICAM Project (32); RAIL, Automatix Inc. -(33); and VAL-II, Unimation Inc. (35,36). The main advantage of second generation software lies in its extens i bil i ty. The 1anguages are extens i b1e in the same way as current computer science languages; they can be used to create an applications package so tai lor-made to the user that he thinks the software was designed especially for him. Through the use of subroutines and functions, new commands can be added to the language that give capabilities, transparent to the user, that did not exist before. After a systems programmer is finished tailoring a second generation software package, the user wi 11 never know all the awkward comp 1ex it i es and syntax demanded by the raw language. This helps compensate for the fact that second generation robot programmers must be well trained in computer sc i ence in order to master the fu 11 power of the 1anguage. Advanced applications involving the use of complex communication and coordination, such as the integration of complex sensors and the communication with other computers, further demand the power of structured computer science languages and the services of highly skilled programmers. 9

The most serious of a number of disadvantages of second generation languages is the difficulty of programming with them, but these weaknesses offer a challenge to researchers to design software features that meet the needs of the computer- integrated workp 1ace. Wi th the exception of APT-like robot languages, second generation languages cannot yet deal with part or cell geometry (i. e. random part shapes and locations of equipment within the workcell) as is necessary i n a work environment . There is sti ll no way to safely debug a robot program . In cont rast to the computer programmer who may di scover a bug from hi s pri nted output, a robot programmer may discover the bug only when the robot breaks something in the cell, damages itself, or injures its human operator. At this present date, it can't be determined whether something can go wrong until it does. Robotic applications should be able to access the wealth of data that resided in a CAD data base, but current versions of second generation languages can handle neither the communications, the different data structures, nor the interpretation of the geometric data. Similarly. the languages currently do not · facilitate the integration of robots into flexible manufacturing systems (FMS) which use computer control to coordinate combinations of NC tools, robots, inspection stations, and material handling systems. Finally, the vast experience compiled by the fields of human factors engineering and ergonomics regarding how people act with automated and computerized equipment has yet to be applied to the user interface of second generation manipulator languages; when this happens, significant improvement can be expected in the ease of use of robotic software.

TASK/OBJECT LEVEL LANGUAGES Robot software is now headed for the next level of hierarchical complexity, that of task-level or object-level languages. Teach box, blackbox, graphical, first generation, and second generation software have all dealt with people translating the needs of their application to the capabilities of the robot. Statements in those languages correspond to specific low-level movements of the manipulator. This is in striking contrast to the way in which a person is directed to accomplish a task. The operator should be able to direct the robot as he would direct a person to perform a series of tasks, which the software would then determine how to carry out in detail. Manufacturers would like statements of that kind in robot software which would correspond to tasks the robot is to accomp 1i sh (see fi gure 1). With such a 1anguage the robot would be able to understand and carry out the instructions on a manufacturing process sheet. This is a set of instructions, or something similar to it, that a robot of the future would be given. This task-level approach is sometimes referred to as object-level because what happens to the part may be specified rather than what task is to be accomplished. Although such software is not now available, research facilities around the world are working hard on its development, and some of those research languages, such as AL (28,42), include object-level features. -- -Some languages that are currently available and perform some task level and object-level functions are (12): AUTOPASS, IBM Corp. (37); KARMA (40); RAPT (34,38); TROLL (39); and-SRL (41).

10

There are two fundamentally different theoretical approaches to the development of task-level programming. One relies on the artificial intelligence (AI) community to develop expert systems that will perform tasks according to formal rules distilled from human experts. This approach uses established AI techniques, but faces the anticipated difficulty of finding human experts in the fast moving field of robotic assembly. The other approach may be termed task-decomposition; the task is analyzed from the top down and is hierarchically decomposed into subtasks that the system knows how to perform. One advantage of the task-decomposition method is that algorithms may be applied recursively to a task until the resulting subtasks are at the level of manipulator motion that can be accomplished with present software. Regardless of the chosen method, task-level languages will become a reality as serious research issues are resolved.

APPLICATION OF ROBOT PROGRAMMING LANGUAGES TO AUTOMATED MINING For the application of robot programming languages to robots that can be used in present day mining operations, the programming instructions must be kept as simple as possible. To do this, a form of a t ask- or object-level programming language should be implemented. Thus, the robot can be told in a few words what to do and where to do it . It would then interpret and carry out the instructions using its internal knowledge base. This scenario provides the least complex interaction between mining personnel and the robot and also allows the most flexibility in the system. However, it appears that this technology will not be available for at least the next five to ten years. Until then, a heavy reliance upon tailored second-generation languages and expert or knowledge based systems will be required. In future systems, a task- or object-level programming language may also be used since it will simplify the communication between modules in the mining hierarchy. This arrangement would also allow each module to operate autonomously resulting in a more flexible and efficient overall system.

REFERENCES 1. Rembold, U., and K. Hormann. Languages for Sensor-Based Control in Robotics. Springer-Verlag, 1987. Fu, K. S., R. C. Gonzalez, and C. S. G. Lee. ROBOTICS: 2. Control, Sensing, Vision, and Intelligence. McGraw-Hill, 1987. 3. Nagel, R. N., and S. R. Garrigan. Robot Software: Current state-of-the-art, and future challenges. AGARD Artificial Intelligence and Robotics, Sept. 1985, pp.4-1 to 4-9. 4. Control.

Snyder, W. E. Industrial Robots: Computer Interfacing and Prentice-Hall, 1985.

11

5. Masterson, J. W., E. C. Poe, and S. W. Fardo. Reston Publishing Co., 1986. 6.

Engleberger, J. F.

Robotics in Practice.

Robotics.

AMACOM, New York,

1980 . 7. Gruver , W. A., B. I . Soroka. J. J. Crai g, and T. L. Turner. Industria l Robot Programming Languages: A Comparative Evaluation. Paper in IEEE Transactions on Systems, Man & Cybernetics, July/August 1984, pp .565-570 . Sor oka, B. I. Designing Languages for Robot Systems . 8. Technical Paper MS84-1051, 1984.

SME

Bonner, S., and K. G. Shin. A Comparative Study of Robot 9. Languages. IEEE Computer, Dec. 1982, pp. 82-96. Off-line Robot Programming: A Practical 10. Jacobs, M. P. Approach. SME Robots 8 Conference , Detroit. MI. June 1984 . 11. Gruver, W. A., B. I. Soroka , J. J. Crai g, and T. L. Turner. Commer ciall y Available Robot Prog ramming Languages. Paper in IEEE Proceed ings of the International Conference on Cybernetics and Society , 1982, pp. 294-296. 12. Dwivedi, S. N., and K. N. Karna. High Level Programming Languages for Controlling Robots . Paper in Proceedings of Robotic Intelli gence and Productivity Conference, Detroit, MI, Nov. 1983, pp. 58-65. Paper in 13th 13. Soroka, B. I. What Can 't Robo t Languages Do? International Symposium on Industrial Robots & Robots 7 Conference, Chicago IL, April 1983. 14. Grossman, Do Pr og r amming of a Computer-Controlled Indust ri al Manipul ator by Guiding Through the Motions. IBM Research Report, RC 6393, Yorktown Heights, NY, 19770 15. Operating Manual Cincinnati Millicron, 1980.

for

T3

Industrial

Robot ,

Vers i on

3.0.

16. Charny, J. Off-line Robot Programming. Paper in Proceedings of the ASME Computers in Engineering , 1983, pp. 51-55. 17.

SRI Robot Programming System.

SRI International, 1981.

18. Park, W. T. The SRI Robot Pr ogramming System (RPS) - An Executive Summary. SRI International, March 19, 1981. 19. Park, W. T. How to Generate a New Version of the SRI Robot Programming System (RPS) . SRI International, August 6, 1979 . 20. User s Guide to VAL, Version 12. June 1980. l

12

Unimation Inc. , 398-H2A,

21. VAL Univision Supplement. Unimation Inc., July 1981.

Version

13

(VSN).

2nd

Ed. ,

SIGLA - The Olivetti SIGMA Robot Programming 22. Salmon, M. Language. Paper in Proceedings of 8th International Symposium on Industrial Robots, Stuttgart, 1978 . 23. Shimano, B. E. VAL - A Versatile Robot Programming and Control System. Paper in Proceedings IEEE Computing Society 3rd International Computer Software Appl ications Conference, Chicago, IL, 1979, pp. 878-883. 24. Gilbert, A., G. Pelton, R. Wang. and S. Motiwalla,. BASIC: An Advanced and User-friendly Programming System for Robots. Robots -8 Conference, Detroit , MI, June 1984 .

ARSME

25 . Advanced Robot ic System Technelogies and Applications, Task A, Enhance Robotics Off-Line Programming. Fifth Interim Technical Report. McDonnell Aircraft Company. Report number ITR940151005U and MDC A8671, March 1984. 26 . Seiko D-TRAN Robotics Manual. November 1983.

1982.

27 .

LM Reference Manual.

Grenoble, France, Oct. 1982.

28.

AL User's Manual.

29.

IBM Robot System/l: AML Reference Manual .

Stanford University, Third Ed., 1981 .

30 . Allegro Operator ' s Manual Electric Co., 1982. 1980 .

Seiko Instruments USA Inc .•

31.

IBM Corporation.

(A12 Assembly Robot).

JARS User's Guide and Manual.

General

Jet Propulsion Laboratory,

32. Robotic System for Aerospace Batch Manufacturing, Task BHigh Level Language User ' s Manual. Wright Patterson Air Force Base, 1981. 33.

RAIL User's Manual.

Automatix Inc .• 1982 .

34. Popplestone, R. J., A. P. Ambler. and I. M. Bellos. RAPT - A Language for Describing Assemblies. The Industrial Robot, Vo l. 5. No. 3, Sept. 1978. 35. User's Guide to VAL-II. Part I: Control from the System Terminal, Version X2. Unimation Inc .• April 1983. 36. User's Guide to VAL-II. Part II: Communications with Supervisory System, Version X2. Unimation Inc., April 1983.

13

a

37. Lieberman, L. I., and M. A. Welsey. AUTO PASS - An Automat ic Progranvni ng System for Computer Contro 11 ed Mechani ca 1 Assembly. IBM Journal of Research and Development, Vol. 21, No.4, 1977, pp. 321333. 38. Ambler , A. P. , S. A. Cameron, and D. F. Corner . Augmenting the RAPT Robot Language. Paper in Proceedings of the NATO International Advanced Research Workshop on Languages for Sensor-based Contr ol in Robotics, Edinburgh Univ., Scotland, 1986. 39. Tevet, A. Development of a High-level Language for Robot i cs. Paper in Proceedings of 14th Convention of Electrical and Electronic Engineers in Israel, March 1985. pp. 4.4.4/1-4. 40. Kirschbrown. R. H., and R. C. Dorf. KARMA A KnowledgeBased Robot Manipulation System. Robotics (Netherlands). Vol. 1. No.1, May 1985, pp. 3-12. I

I

-

41. Rembold, U., and C. Blume. Programming Languages and Systems for Assembly Robots . Paper in Proceedings of the 1984 Conference on Computers in Manufacturing. pp. 415-24. 42. Finke l , R•• R. Taylor, R. Bolles, R. Paul, and F. Jerome. An Overview of AL, A Programming System for Automation. Stanford Artificial Intelligence Laboratory, 1975. 43. Hoekstra, R. L. Robotics and Automated Systems. Western Publ ishi ng Co., 1986.

14

South-

AUTOPASS: WHILE emptypalletthere DO BEGIN WHILE holeinpalletfree DO BEGIN INSERT block IN holeinpallet; END;

replacepallet END;

FIGURE 1. - Palletizing with AUTOPASS (~.

15