A Forth-Based Robot Control Language

©

C()P~ riglll I F:\C Rohlll COII I re d (S, roro ·~'G). B;tl"u'ltma . Sp; lill. 1~I;-.i .-)

A FORTH-BASED ROBOT CONTROL LANGUAGE P. M. Bruijn, H. C. Van Leeuwen and H. B. Verbruggen Vd/I [·/Ii. 'l'nil) "/ 'fl'd/l/ll/"g:r. /)1'/1111'111/1'/11 ,,/ F/nlri((/I F /lgi/lI'l'I'i/lg. C"/Ilml '-"hl/ml"". I '() HII.\ 'ill] I. ]r,tJII (; : \ /), ,//1. Til l' .\'l'fhl'l'l"/Ii/.,

Abstract. After a general introduction to robot programming languages the Forth-based programming language FAR is treated. This language provides the user with high-level programming capabilities to facilitate the (interactive) programming of a robot f or a new task or the modification of an existing one. An example of the use o~ FAR is given to program the movement of a 5axis robot in a flexible way . Keywords Robot . Programming: programming, Computer control.

languages.

I NTRODUCTION Selecting the language with which to very realise a robot control system is important. The programming language FORTH seems highly suitable because of its flexible structure and the oppo r tunity it offers to mould the instruction set (vocabu lar y in FORTH terms) to a special field of application such as robotics. This article describes the implementation of a control language FAR (FOR TH As Robot language). which is sui table for 5-axis robots and has been tested on a rnod1fied RHINO XR-1 robot. In the next section the general requirements of a robot programming language (RPL) are summarised. then an implementation of FAR based on a selection of the requirements stated in the previous section is treated. The paper concludes with a pr ogramming example and some concluding remarks.

REQUIREMENTS FOP. A ROBOT CONTROL LANGUAGE a and desirable features of required The robot programming language have been reviewed extensivelY in literature (Gruver . 198b ) . It should be a general purpose larlguage to allow complex computations on data obta ined from sensors and a high-level language to hide specific hardware and software details. Since robots work in a real-time environment. data nlust be ~rocessed within certain time constraints. Further. the language should have a modular structure and be easy to ex~and. as one can never anticipate all the needs of future applications. The language should support a in for parallel tasi< executicn. mechanism order to describe ccc~erative simultaneous operations of multiple robots and devices. Moreover. interactive debugging and support facilities should be available for quick and user-friendly program development.

Interactive

These demands are perhaps incomplete. but are nevertheless extensive. It is clear that no current general computer language meets these demands . This has been the primary reason for developing languages specifically for manipulation. The major disadvantage of this approach is . howe v er, that hardly any robot independant languages have resulted. This has been one of the reasons FORTH has been investigated with respect to its suitability for robot programming. As indicated by Th ompson (1983), FORTH offers some interesting features which fulfil the stated requirements for a universal robot language.To begin with . i t is interactive Most other languages would have by nature. to be made interactive. FORTH is moreover a high-level language , providing only singleentry Single-exit control structures. It has an extremely modular structure and farces to modular programming. And . most important perhaps. it is extremely easy to extend. We note that a good introduction to FORTH is gi ven by Brodie (1981) . and advanced programmers may be able to find a lot of useful information in Brodie (198b). Let's take a closer look at what the language should offer. and concentrate on ~hose aspects related to robotics. One of these concerns the data- types which are incar~orated in the language or are userdefinable . One of the basic needs in a rabot programming language is a description of the position o f the robot. As most rcbots have 5 or 6 degrees of freedom some kind of a 5- or 6-dimensional array of real flumbers will be needed. The position ( x.Y . z ) takes 3 parameters . while the crientatlon re~uires another 3 parameters to describe fully the state of the r obot. This description will be used so frequently t~at it necessitates 8 special data - type . whose name emerges from the literature as f'P.AME . Another aspect of a programming language is the possibility to instruct the computer on \~hat to do . varying fram data manipulation ~o specifying the action of the robot. The

P. \1. Brllijll. H. :'I.. \'all Leell\\l'1l most important of these are description of the robot's movement one

frame

the from the opening or the

to another and

closing of the gripper. Another aspect, which is specific for programming robots, is the so-called teachmode. Although the state of the robot can be described by frames. and the robot can be instructed to move to a frame. this does

not imply that the frame coordinates of a £pecific object can be given easily. Thus, there must be an interactive way to move the robot to the desired object and store the frame coordinates. Normally, this function is realised with a so-called teach box. a box with special buttons for special functions. There is no reason. however. why a computer terminal could not serve that purpose. an additional advantage of which is that more conveniently arranged information screen.

can

be

displayed

on

the

A last aspect to be mentioned is safety. Of course . software checking on certain conditions (such as preventing the robot fram reaching beyond its reach) will be pe formed before each movement. Despite this software checking a condition can occur which could potentially be fatal to the robot.

an object or a

human being.

One must

be able to stop all motion immediately by hitting an emergency stop button. After such an interrupt to recover easily.

the system must

be

able

~lIId

H. B. \'nhrllggcll

without internal knowing the exact representation . For this purpose, frame instructions (in FORTH called 'words') have been made to manipulate frame-values on the stack, very much resembling the existing Forth words FR@

,

FR!

:

FAR

Now that a general idea of what an RPL should look like has been given, i t is time to look at the proposed robot language FAR (Forth As Robot language) more closely. The first choice to be made concerns the FRAME data type. As stated, a frame consists of a position and an orientation, a total of 6 parameters. Robots with only 5 degrees of freedom. therefore, cannot be orientated freely

in

every position.

For these robots

it is not desirable to describe the orientation in a position-independent manner. for it is nearly impossible for a user to determine. given an arbitrary position. whether an orientation belongs to the (positiondependent) group of realisable orientat1ons. This is a very essential difference between robots of 5 and of 6 degrees of freedom. Because the robot on which the language was tested had 5 degrees of freedom. but more importantly. because most industrial robots have only 5 degrees

of freedom. the orientation (of a frame) will be described by Pitch (p) and Roll (r) . So the FRAME data-type as defined in FORTH consists of (x,y,z,p ,r ). On the stack, the x-value will be at the 'bottom' and the roll-value on the 'to p ', denoted as: ( x y z pr). The user can define frames. just like variables and constants (with the addition that the frame values will be initialised to zero) by the following statement

FRAME

OBJECT

The execution of OBJECT will values on top of the stack OBJECT -------> The

next step is

put

the

frame

x y

z p r)

the manipulation of

this

two frame. Just as o ne can ROT or SWAP wish to integers on the stack. one may frames. similar operations on execute

,

FRNEGATE

These words appear to be very handy tools for constructing several move statements. for all movement the MOVE The basis is instruction. This word needs a frame on the stack as argument and will cause the robot to move to the specified frame. Using Forth. we must specify our data (the frame) before the operation (the movement). So the syntax will be OBJECT

MOVE

MOVE (OBJECT) , or MOVE TO rather then we would expect in most other OBJECT as languages This may look a bit confusing at first, but any problems disappear once you are using this structure of Forth for some time. The availability of the instruction MOVE, it easy to define a new instruction makes +MOVE for relative movements by using the colon-definition in the following FORTH way : +MOVE

FORTH AS ROBOT LANGUAGE

FR+

FR.

POS@

FR+

MOVE

The colon (:) opens the definition of +MOVE. containing the given list of instructions separated by spaces or carriage returns. The semicolon (:) serves as the terminator of the definition. The new instruction +MOVE expects a framevalue on the staCK. adds the frame-value of the actual position (POS@) and moves to this newly constructed absolute frame . An often-used procedure. especially useful for robots with 5 degrees of freedom, is to quickly move to a position above the object, and then slowly proceed to grasp the object. With the tools now at hand, it is not difficult to realise these motions. First we define a frame FR-OF (offsetframe) and fill it with a certain displacement along the z-axis (in this case 5 cm) FRAME FR-OF O.

O.

5.

o. o .

( For Forth experts we (immediate) word which of the following frame values on the stack.) new movement words HOVER DESCEND ASCEND

FP. -O F FR- O F FR-OF

>FR

FR-OF

note that >FR is an extracts the address and stores (FR !) the Now we define three

FR+ FP.NEGATE

MOVE +MOVE +MOVE

Anyone with a basic knowledge of Forth wi ll not have much trouble understanding these operations. Furthermore. it is a good example of how easy it is to extend the available instruction set. these different forms of movement. Beside one can specify several attributes about the movement. First of all, one can specify the speed or the acceleration rate at which tip must be the movement of the tool performed. Normally. when nothing is specified, certain (user adjustable)

Forth-Based Robot Control Language defaults will be assumed. But when there is a delicate action to be performed, one wants to be able to adjust the speed and acceleration. This must be stated before the actual operation, e. g. 5.

3.

ACC SPEED

OBJ ECT HOVER DESCEND

This specification applies MOVE instruction: after defaults will be valid. defaults, the ~ollowing are a vai lable :

only to the next this the normal To change these two instructions

DEF-SPEED DEF-ACC Both take a real as argument, just as SPEED and ACC do, with the current user units for speed or acceleration. We Can choose the desired units on the basis of certain standards or even define our own. We just simply declare once which units are valid (for instance for position) CM

or

INCH

and all instructions which refer to positions or distance will convert the given user- val ues to internal values. Conversely. when we want to know certain values (for instance, when inspecting a frame with FR.) the inverse conversion is made .

It is possible that an obstacle blocks the direct path to the target frame. Then an intermediate point (frame: OBSTACLE) can be chosen through which the tool-tip must move : OBS TA CLE

TARGET

VIA

MOVE

Unlike most available robot systems the movement will actually occur through the specified v ia-frame (OBSTACLE), instead of ta~ing a short-cut near this point. This is wh ich realised through a trajectory and a consists of two straight lines The connecting parabola (see Fig. 1). departure and arrivel directions are computed such that the connecting parabola intersects with the via-frame. These directions depend upon the permitted SPEED If the directions rather and ACCeleration. then the via-frame are important. a similar instruction can be used : OBSTACLE

HEADING

TARGET

MOVE

Now the departure direction will be straight from the actual pOSition to OBSTACLE . and the movemen t will take a 'sh ort - cut ' to the connection line OBSTACLE-TARGET (see Fig. 2). The last specification which can be made concerns external sensors. One may want to control the height of the tool tip above a plane by using an ultrasonic sensor. as lm~lemented on our robot. The movement of the tool tip at a constant distanc e above a plane can be given by

The second important group of instructions concerns the control of the gripper. At present no force or pressure sensors have been implemented on the gripper. So only the followin~ gripper statements which respectively open and close the gripper have been implemented GRASP OPEN The GRASP instruction closes the gripper until no further mo v ement is measured. The OP EN instruction simply opens the gripper to its maximum. With these instructions, however. one can easily define two new powerful instructions GET HOVER PUT HOVER

DESCEND

GRASP

ASCEND

DESCEND

OPEN

ASCEND

The last but not least instruction to be mentioned is TEACH. When executing this word. the teach mode is in voked. This offers several functions. which are given in the following command menu : I

-

o C T F U M

-

Initialise manipulator Original settings Change step size Toggle direction define a Frame Update position Move to frame / position

Another function is direct interactive movement of the robot. Striking of one of the 'movement keys' invokes the movement of the robot. A subsequent stroke will increase the speed. The 'movement keys' are chosen in line with logic and activate the appropriate motor: 'w' for Waist. 's' for Shoulde r, 'E' for Elbow, 'H' for Hand, 'R' for Roll and 'P' for Pitch. Further, movement along a straight line can be invoked by depressing ' X '. 'y'. or 'Z' . In addition. the orientation o f the tool tip can be changed w ithout changing the (x .Y.z) position by using the key' [' The direction of the movement can be altered by 'T' (for Toggle direction). Next the program asks for which motor or which axis the step or direction must be changed. Another important ~ey is the , with which one instantly stops all movement. This key has been chosen for this function because it is the largest key and thus the quickest to reach. Once one has manoeuvred the robot into the desired position. one can store that pOSition in a frame . This fun ction has also been brought under one key. 'F'. When it 1s struck. the user will be asked for the name of the frame in which he/ she wants to store the position. Either a new frame can be created or an old frame can be updated. As all these functions are invoked by single key strokes. one can quickly define frames without knowing or having to measure the exact position.

EXAMPLE 20.

DISTANCE

TARGET

MOVE

The targ et destination and the condition ( 20 cm. above the plane ) can be contrad ictor y . in which case the condition will control the movement ( see Fig. 3).

We are now ready to take a look at a simple example of how to wr i te a program. ( Keep in mind that programming in FORTH means defining new instructions. called 'w ords ' ). Let's consider Fig . £I. The goal is to exchange the two objects. As there is an

1'. \1.

230 obstacle

between

the

two

Bnlljll.

H ..\. \·"n

objects,

LCCU\\TI1

"nd H. B. \·crbruggen

one

TARGET

cannot move directly from one object to the other. We first define U frames with TEACH: OBJECT1 OBJECT2 TEMP OBSTACLE Then

with

we write our program.

comments

between brackets

OBSTACLE

PLAY-SAFE Name of new instruction. ASCEND Start above the OBSTACLE. OBSTACLE MOVE ( End of first definition.

FiK.

1.

Movement with VIA

Name of next instruction. ) Get first object. put it) ( in temporar¥ position. ) ) ( Move via the obstacle ) OBSTACLE VIA ( to the second object ) ( and put it at the OBJECT2 GET ) OBSTACLE VIA ( place of the first ) ( object. OBJECT1 PUT

CHANGE OBJECT1 GET TEMP PUT

(

TARGET

Now replace the first object from its temp position to the old place of the second.

TEMP GET OBSTACLE VIA OBJECT2 PUT Exchange

frame values.

OBSTACLE

OBJECT1 OBJ ECT2 >FR OBJECT1 >FR OBJECT2 FiK.

2.

Movement with HEADING

CONCLUDING REMARKS fairly robot-independent package (5 A degrees of freedom) has actually been realised. for the most part written in FORTH on a PDP 11/23 computer. The underlying

robot-dependent

routines

written in FORTRAN and MACRO. computations.

however,

are

Time-critical

are also

implemented

in FORTRAN. The robot on which the routines are tested was a modified RHINO XR-1 robot with an ultrasonic distance sensor. To use the package for other robots. only robot-dependen t routines have to

rewritten. The features FOP.TH stated earlier in the article.

the be

offers. as have proved

to be very powerful and elegant tools in the development and use of a robot control

language. Particularly the interactive aspect and the great ease with which the language can be expanded will be hard to beat.

FiK.

3.

Trajectory after Commands: 20. DISTANCE TARGET MOVE

REFERENCES Brodie. L. (1981). Prentice Hall.

Starting

Brodie. L. (198U). Prent1ce Hall.

Thinking E.QE.I..li

Gruver.

J.J.

W.A ..

Soroka.

and Turner.

..E.QE.I.l:l

B . I . . Craig . T.L. ( 19811 ) .

Industrial Robot Programming Languages: A Comparative Evaluation. ~ Transactions ~ SYstems, MAn and

Cybernet1c-.SMr-1U,No.

l...::...l.. U3-51.

~

OBJECT 1

TEMP

~.565-570.

Thom>,son. D. (1983). Improvement of a Human / Robot Interface Through the Use of FORTH . ~ Journal ~ ~ Acplication

OBSTACLE

Research.

FiK.

4.

Example of Exchange of Objects.