Graphical Interface for Robot

This invention relates to a system and method for graphically creating and visualizing robot positions, orientations and trajectories in space and for controlling and moving robots in accordance with graphical information.

Robots today are programmed to perform their tasks by either on-line or off-line techniques, or combinations of both. A typical on-line programming method is known as the "teaching playback" technique. That technique involves the steps of placing the robot in the actual environment where it is to be used (i.e., placing the robot in a work space containing a workpiece to be acted on by the robot), training the robot by moving it through a series of configurations with respect to the workpiece, and causing those configurations to be stored in memory. The stored configurations are then used to generate a robot program. During "playback", the program regenerates the configurations which are continuously repeated on a succession of workpieces placed in the robot's work space.

A typical off-line programming technique involves generating the robot program using a CAD (computer-aided design) or CAD/CAM (computer-aided design/computer-aided manufacturing) system. The robot programs are composed of commanded actions (e.g., REACH, GRASP, PALLETIZE), configurations where the actions are to occur (e.g., position x.sub.1, y.sub.1, z.sub.1, orientation .alpha..sub.1, .beta..sub.1, .gamma..sub.1 ; position x.sub.2, y.sub.2, z.sub.2, orientation .alpha..sub.2, .beta..sub.2, .gamma..sub.2 ; etc . . . , ) and sensory queries that are used for branching and program control. In this method, a CAD data file stores data about the dimensions and positions of workpieces. The movement and configurations of the robot are coordinated with the CAD data. For example, CAM involves creating tool-path programs and is used to create parts and components on computerized numerically controlled (CNC) equipment. The specific data generated by the CAD system can be directly utilized in a CAM setup. There is sufficient information in a solid model drawing to automatically or semi-automatically create tool-path files.

On-line and off-line programming methods can also be employed together. For example, an on-line method could be used to create all or part of the initial robot program and an off-line method can be used to complete and/or edit the program.

Graphical interfaces have been developed to assist an operator or user in performing off-line programming. Typically, such interfaces employ a screen which depicts either the workpiece, images of the robot, or both. Those interfaces are deficient in many ways. For example, although the robot and the workpiece may both appear on the screen, the configuration of the robot's end-effector (typically a gripper) is not changeable by simple user interaction. Furthermore, the trajectories between configurations are either not shown on the screen and/or cannot be generated by simple user commands employing the CAD environment.

Current approaches to programming robots can be classified into two major categories:

1. Robot oriented programming

2. Object oriented (task level programming)

In robot oriented programming languages, an assembly task is explicitly described as a sequence of robot motions. The robot is guided and controlled by the robot program throughout the entire task.

Task level languages describe the assembly task as a sequence of positional goals of the objects rather than the motion of the robot needed to achieve these goals. No explicit robot motion is specified.

In sum, off-line and on-line programming of robots typically requires knowledge of a specialized robot programming language even when working in a CAD environment. Thus, in the prior art, the powerful and easy to use CAD environment has not been fully employed to lessen the complexity and time required for off-line programming of a robot. Furthermore, neither the on-line nor off-line programming technique has, heretofore, provided a way to simultaneously visualize plural robot configurations, to visualize together both robot configurations and trajectories by employing a graphical interface in a CAD environment, to graphically visualize different end effector states, or to associate programming code with one such state. The present invention solves those deficiencies.

The invention comprises apparatus and methods for graphically creating and visualizing robot positions, orientations and trajectories in space and for controlling and moving robots in accordance with graphical information. A three dimensional graphical environment is provided for visualizing objects in space. Graphical image data representing the end-effector of a robot is stored in a file. The operator or user inputs data representing the position and orientation of the end-effector at one or more positions in the three dimensional space wherein a specified position and orientation defines a configuration. A graphical image representation of the end-effector is displayed in the graphical environment at the specified position and orientation.

In another embodiment of the invention, a 10 plurality of configurations can be specified and displayed on the same graphical display along with trajectories between configurations.

In yet another embodiment of the invention, robot movement and control data can be generated from the information input into the graphical display

In yet another embodiment of the invention, the state of the end effector is specified at each configuration and the end effector is graphically displayed in its specified state.

In yet another embodiment of the invention, an end effector state associated with a Criptic node can be specified. A set of data instructions and/or commands are associated with each Criptic node so that when the end effector reaches such a node, the data instructions and/or commands are performed at the configuration associated with that node.

For the purpose of illustrating the invention, there is shown in the drawings a form which is presently preferred; it being understood, however, that this invention is not limited to the precise arrangements and instrumentalities shown.

FIG. 1 is a prior art perspective view of a six-degree-of-freedom robot arm with rotational joints.

FIG. 2 is a prior art perspective view of a six-degree-of-freedom robot arm with one sliding joint.

FIG. 3 is prior art depiction of the coordinate relations for a six-degree-of-freedom robot.

FIGS. 4(a), 4(b) and 4(c) show three types of icons which represent different types of nodes employed in the invention.

FIGS. 5 (a) and 5 (b) shows screen displays in a CAD environment before and after CAD data is entered, respectively, but before robot-related information is entered.

FIGS. 6(a) through 6(c) show the screen display of a CAD environment during successive entry of robot control data in accordance with the invention.

FIGS. 7(a), 7(b) and 7(c) show screen displays which illustrate the technique for selecting nodes using CAD generated information.

FIG. 8 shows a screen display of a series of nodes connected by trajectories within a work environment.

FIG. 9(a) shows a screen display of a program written to execute a specific trajectory.

FIG. 9(b) is a magnification of a portion of FIG. 9(a).

FIGS. 10(a) and 10(b) show flowcharts of the process for converting data generated in the CAD environment into robot control data.

FIGS. 11(a) and 11(b) show a more detailed flowchart of the process in FIGS. 10(a) and 10(b).

FIG. 12 shows one example of a robot suitable for interfacing with the graphical interface of the invention.

While the invention will be described in connection with a preferred embodiment, it will be understood that it is not intended to limit the invention to that embodiment. On the contrary, it is intended to cover all alternatives, modifications and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims.

Referring now to the drawings, wherein like numerals indicate like elements, there is shown in FIGS. 1 and 2 selected components of prior art robots 10 and 10' which can be programmed according to the present invention. The robot 10 is a typical industrial robot manipulator having an arm 12 capable of six degrees of freedom of movement (exclusive of gripper closure or end effector 14). The six degrees of freedom are required to enable the gripper 14 to approach an object from any orientation. This is usually accomplished with three arm joints, waist 16 (associated with the first degree of freedom), shoulder 18 (associated with the second degree of freedom) and elbow 20 (associated with the third degree of freedom), which can position the wrist at any x,y,z coordinate in a working volume. The three-axis wrist joints 22 (associated with the fourth, fifth and sixth degrees of freedom) can then orient the gripper 14 attached to it by three independent motions (roll .alpha., pitch .beta., yaw .gamma.) around the x,y,z location of the wrist, as also understood with respect to prior art FIG. 3. The roll, pitch and yaw of an end-effector can also be seen in FIG. 11 of U.S. Pat. No. 4,763,276, which is incorporated herein by reference. In effect, the wrist represents the origin of a three-axis coordinate system fixed to the gripper 14. Moving the first three joints of the arm translates this origin to any point in a three-axis coordinate system fixed to the working volume, whereas motion of the final three joints (in the wrist) orients the gripper coordinate system in rotation about an origin at the wrist point. For clarity, the robots in prior art FIGS. 1 and 2 have wrist-joint axes which do not all intersect at a single point.

Prior art FIGS. 1 and 2 illustrate different types of joints. The robot 10 in FIG. 1 illustrates an arm 12 with rotational (i.e., revolute) joints numbered 1 to 6. The robot 10' in FIG. 2 illustrates an arm 12' with one sliding (i.e., prismatic) joint 24. Robots are typically constructed of combinations of such joints.

The entire purpose of the arm is to position the gripper or end-effector 10 at a particular configuration so that it can perform some useful function at the configuration. As discussed above, a configuration is defined by a position x,y,z and an orientation .alpha., .beta., .gamma.. That is, the position is defined by the location in space of the gripper (usually determined by the location in space of the wrist), whereas the orientation is defined by the rotation about an origin of the wrist point defined at the given location in space.

The mathematics of robot motion (kinematics) is well-known and thus will not be repeated herein. Descriptions of such can be found in U.S. Pat. No. 4,763,276, incorporated by reference above, or in textbooks such as Paul, R. P. Robot Manipulators: Mathematics, Programming and Control, MIT Press, Cambridge, Mass., 1981, or Fu, K. S. et al., Robotics: Control, Sensing, Vision, and Intelligence, McGraw-Hill, Inc., New York, 1987. In sum, the kinematics allow one to convert the value of the joint variable for each of the six joints in the robot into the configuration of the end-effector, and vice versa. Thus, it is the kinematic equations which allow the robot program to convert configuration data (i.e., x,y,z and .alpha.,.beta.,.gamma. values) of the end-effector entered by the operator during off-line programming into actual robot arm configurations, and which allows a robot end-effector to be placed in a given configuration during an on-line teaching session and have the robot's joint position transducers converted into configuration data (i.e., x,y,z and .alpha.,.beta.,.gamma. values).

As described above, it is known in the art for an operator to interact with a CAD system to aid in certain aspects of programming a robot. A CAD system can be used to create and/or display a wire-frame model, solid model or surface model (essentially a wire-frame model with surfaces hanging on the wire frame) of a workpiece. Certain aspects of the robot's operation can be visualized with respect to the workpiece. For example, the system in U.S. Pat. No. 4,998,050 creates a composite picture of an entire robot in its work environment.

A CAD data base is associated with the images displayed on a CAD screen. Standard data formats are employed to ensure that CAD or CAD/CAM information created on one system can be readily usable by another system. Standard data formats include IGES (Initial Graphics Exchange Specification), DXF (Data Transfer Format) and DWG, among others. The DXF data format is widely used in small-scale commercial CAD products such as AUTOCAD, a product of AutoDesk Corp.

One embodiment of the invention will now be described. That embodiment functions within a three-dimensional version of AUTOCAD. However, in view of the interchangeability of data in CAD-type programs, it should be understood that the invention is not limited to operating only within AUTOCAD or similar CAD programs, but will be applicable to any CAD system.

The Appendix includes the programming code for carrying out the AUTOCAD-compatible embodiment of the invention. Such an embodiment allows the user to interact with display screens and commands familiar to a CAD operator. However, when the operator selects a "ROBOT" option from AUTOCAD's enhanced pull-down menu, the operator will then invoke the programming code in the Appendix and will be able to perform all of the robot-related functions described below. AUTOCAD's "Command:" line is employed for initiating data entry.

The program in the Appendix was written to interface with a robot having a unique robot arm formed from tube-shaped structural members. The robot arm of that robot is shown in FIG. 12. The statements in the program to a "tube-rob", "tuberob" or "TR- . . . " refer to the robot arm of that unique robot. However, the program and graphical interface can be applied universally to any robot with six degrees of freedom and an end-effector.

The invention creates data structures called "nodes" within a CAD environment. The nodes contain the six generalized coordinates needed to specify the configuration (position and orientation) of an object in space. The nodes in the invention represent the configuration of the end-effector in space. Trajectories are specified by connecting two nodes. Thus, in operation, the robot moves its end-effector from node to node in accordance with the programmed configurations of the nodes (e.g. node 1 to node 2 along trajectory A, node 2 to node 3 along trajectory B, and so on). The nodes and the trajectories between the nodes can be created, edited and visualized on a display screen.

If the robot's end-effector is required to perform an action or series of commands at a given configuration or if other functions are to be performed in the robotics environment while the end-effector is at a given configuration, the programming code for executing the action, commands or function is embedded in a special type of node called a "Criptic node". Each Criptic node thus has programming code associated therewith. The word "Criptic" is a word coined by the inventor to reflect the hidden or cryptic nature of the associated programming code. That is, the programming code, itself, is not visible when viewing the node on a display screen. A special programming language called "Criptic language" created by the inventor is employed for this function. The Criptic language consists of commands in C-language. Criptic nodes, by employing Criptic language, are used to build intelligence into the robot arm for a specific application.

The nodes are represented by on the display screen as icons. As is well-known in the art, icons are used in user interfaces to pictorially represent a desired command. For example, an icon of a file drawer would be selected to cause a computer to file certain information or a garbage can would be selected to cause the computer to delete certain information. In the invention, however, the icon performs a semiotic function by representing the end-effector (gripper) of the robot arm and its state. The icon has a three-dimensional appearance to represent the physical appearance of an end-effector. The nodes appear directly in the CAD environment wherever the end-effector is desired to be placed. In an off-line programming method, the operator enters a configuration and the node appears at the x,y,z position associated with the configuration. Since the nodes are represented by a three-dimensional icon, the orientation of the end-effector is also visible. In the off-line method, the orientation is also entered by the operator. In an on-line programming method, the robot arm is moved to a desired position and the end-effector is oriented in a desired orientation. By employing the robot's joint position transducers and kinematics equations discussed above, the program creates a node on the screen associated with the taught configuration. The result of either method is that the operator can visually represent the end-effector in space.

Additional features of the invention include, among others:

(a) the ability to connect nodes in order to create and view trajectories between the nodes;

(b) the ability to place workpieces and/or other objects on the screen or relate objects to them so that the relationship between the end-effector, its trajectories, and the workpieces and/or objects can be visualized;

(c) the ability to specify that particular actions or commands are to be performed at a given configuration (i.e., the so-called "Criptic node").

FIGS. 4(a), 4(b) and 4(c) show three types of icons which represent different types of nodes employed in the invention. The insertion point shown in FIG. 4(a) is user defined and represents the origin of motion coordinate system (MCS) icon 24. As is well known in the art, the MCS is a temporary coordinate system. The MCS icon 24 shows the orientation of the MCS's X, Y and Z axes. The icon 24 appears on the screen to help the operator enter correct motion commands. The icon 24 always has a single arrow on the X axis, a double arrow on the Y axis and a triple arrow on the Z axis.

FIG. 4(a) shows an "open gripper node icon" which represents an end-effector that is open at the entered configuration.

FIG. 4(b) shows a "closed gripper node icon" which represents an end-effector that is closed at the entered configuration.

FIG. 4(c) shows a "Criptic node icon" which represents an end-effector that has Criptic language associated with it at the entered configuration. When a Criptic node is created, the end-effector is positioned and oriented in accordance with entered data and then Criptic language code associated with that node is created and stored. When the node is encountered during operation of the robot, the Criptic language code is accessed and executed. In contrast, when an open gripper or closed gripper node icon is encountered, no such Criptic language is executed. The end-effector merely moves to the configuration of the node and either opens or closes. Although the Criptic node icon in FIG. 4(c) appears to be identical to an open gripper node icon in FIG. 4(a), the CAD system associates different colors with each icon. Thus, the user can readily distinguish between a Criptic node icon and an open gripper icon even though the appearance is similar. It is also possible to employ icons having a unique appearance for each type of node.

The physical motion of opening or closing the end-effector, or executing Criptic language occurs after the end-effector has reached the desired configuration.

It should be understood that the use of other types of node icons are within the scope of the invention. For example, if it is desired to have the end-effector slowly squeeze a workpiece (instead of opening or closing on it) or spin about its axis, a different icon could be created. In the limited embodiment having only the three types of nodes shown in FIGS. 4(a)-4(c), other types of end-effector operations would be performed by creating a Criptic node and embedding the operations (e.g., squeezing or spinning) in the Criptic language. Furthermore, other types of end-effectors exist which have states other than "open" or "closed" The invention can be employed with any type of end-effector wherein each end-effector state would be represented by a different type of node.

The Criptic node is ideally suitable for processing sensory queries. For example, if it is desired to have the end-effector move to the next node only if a sensor indicates a preselected condition, the operator can define the node as a Criptic node and associate Criptic programming language with the node. The programming language instructs the robot not to move the end-effector until the sensor detects the preselected condition. Examples of other operations which can be associated with a Criptic node are:

(a) branching

(b) waiting for a signal from another robot

(c) linking to a conveyor belt

(d) generating data or graphs

(e) performing logic

(f) adaptive control

FIG. 5 (a) shows the screen in an AUTOCAD environment before any information is entered and FIG. 5(b) shows the screen after normal CAD data is entered, but before robot-related node information is entered.

In FIG. 5(a), the operator sees axis lines x,y,z and reference circle lines in the x-y axis plane associated with the world coordinate system (WCS). In FIG. 5(a), the axes of the MCS icon is set to the UCS. The "W" in the User Coordinate System (UCS) icon in the lower left hand corner of FIG. 5 (a) indicates that the operator has selected the UCS to be equal to the WCS. The UCS will be further explained below.

If the operator has not selected the "ROBOT" option from AUTOCAD's enhanced pull-down menu, the screen functions as a normal CAD system wherein three-dimensional objects can be created or retrieved from a data file. For example, workpieces or objects associated with the robot's work environment can be placed on the screen. FIG. 5(b) shows one such workpiece in the form of a solid model of a die set. A die set is shown as an example of an object that is often used in a robot-controlled environment. The robot can position metal parts into the die set and remove them from the die set after they are manipulated therein.

Once the operator selects the "ROBOT" option or mode, the screen then allows robot-related information to be created, independent of objects placed on the screen in the normal CAD mode. However, the CAD-related workpieces or objects can be employed to designate reference points or the like. For example, if it is desired to move the robot's end-effector to a particular point on the CAD-related workpiece, the operator moves the cursor to that point and captures the appropriate data to create a node at that point.

FIGS. 6(a) through 6(c) show the screen of an AUTOCAD environment for creating a robot control program using an off-line programming method. The workpiece(s) can optionally appear on the screen if the operator wishes to use them as a guide for selecting nodes. For clarity of illustration, no workpieces appear in these figures. As discussed above, the programming process consists of generating nodes, trajectories between nodes, and Criptic language code when a Criptic node is specified.

After selecting the "ROBOT" option from the pull -down menu, the operator is ready to enter the first node and the following steps are performed:

(1) At the "Command" lines, the operator specifies the User Coordinate System (UCS). As is well-known in the art, the UCS is defined by the user and can be oriented anywhere in relation to the WCS. By selecting "UCS", the CAD system will interpret all configuration data according to the WCS.

(2) The operator is then prompted to select whether the node will be of a "node" type (i.e., open or closed) or of a "Criptic" type. Although a Criptic node is also a "node", the system must distinguish between types of nodes which will have Criptic language associated therewith and types of nodes which do not have such language associated therewith. If a "node" type is specified, the operator will be prompted to indicate whether it is to be "open" or "closed" (i.e., whether the end-effector is to be open or closed at the node). If "Criptic" type is specified, the screen will switch to a text editor, as described in step (5) below.

(3) Regardless of which type of node is to be generated, the operator will be prompted to enter the orientation of the node. The operator enters the appropriate axis or axes and the degree of rotation about the axis or axes. This step is similar to the procedure for orienting three-dimensional CAD-generated objects (e.g., "rotating" in AUTOCAD) However, this orientation represents the orientation of the robot's end-effector in space and will be used to orient the icon on the screen, as opposed to a CAD-generated object.

(4) The operator is then prompted to enter the position (coordinates) of the node in the WCS.

(5) If a Criptic node is selected, the operator will perform one additional step of entering Criptic language code into a text editor which appears on the screen. Although any text editor can be linked to the Criptic node, the program disclosed herein employs its own editor (the so-called "TR-editor") for simplicity.

(6) When it is desired to create trajectories between two nodes, the operator selects a first node, selects a trajectory, and then selects the second node. It should thus be understood that the normal CAD capabilities of connecting points in space with lines, arcs, or the like, can be employed for generating trajectories between nodes.

FIG. 6(a) shows the screen after the following set of information for an closed gripper node P1 at position (5,13,8) and a first orientation has been input into the CAD system using the steps above. The screen displays a closed gripper node icon at the entered configuration. (The labelled points, their coordinates and the dotted lines associated with them have been added for clarity. They do not appear in the actual environment.)

FIG. 6(b) shows the screen after a second node P2, an open gripper node, has been input into the CAD system. The second node has node position (11,7,8) and a second orientation. The screen now displays icons representing both nodes in the graphical environment. If node P2 was a Criptic node, the operator would have been prompted to enter Criptic language code (comprising one or more commands) into a text editor, as further described below. After the code is entered, the Criptic node would appear on the screen in the same manner as other types of nodes. As noted above, it will be distinguished from the open gripper node icon by having a different color.

FIG. 6(c) shows the screen after an arc-shaped trajectory P1-P2 has been generated between nodes P1 and P2.

As described above, an on-line programming method can also be employed to generate one or more of the configurations. Thus, it should be understood that steps (3) and (4) above can be performed by moving the robot's end-effector to a desired configuration in space and determining the configuration from the robot's joint position transducers. Alternatively, other off-line programming methods can be employed for obtaining the data in step (4). For example, CAD data can generate lines, wire-frame models, or solid models and the operator, in the ROBOT mode, can then designate points on the line or points on the models to become node positions. One suitable method of generating solid models is to employ AUTOCAD's Advanced Modeling Extension (AME) solid modeler.

Once the nodes, trajectories and Criptic language has been generated, the operator selects a command to compile a robot control program. After the program is successfully compiled, a GO command invokes the robot to execute the desired movements. Of course, it should be recognized it is the program in the Appendix, in conjunction with some code in AUTOCAD, which allows for the compiling and execution of the robot control program from the data graphically shown on the screen.

The status or state of the end-effector (i.e., open, closed, Criptic) at each node is monitored by keeping a record of the name of the block (i.e., each icon is saved as a block) inserted by AUTOCAD into the graphics file. The status is defined as:

1=OPEN

2=CLOSED

3=CRIPTIC

The status of the end-effector at every node is saved in a "GRIP matrix". The GRIP matrix consists of the position of the node in units of "COUNTS" and the status at each position. COUNTS is a unit of measure for keeping track of the data written to a file read by the robot software in the attached Appendix. The number of filled rows of the matrix indicates how many changes of status (e.g., OPEN to CLOSED, CLOSED to CRIPTIC) will occur in a certain path. Before the GRIP matrix is stored, it is rearranged so as to delete rows containing a status that is the same as the status in an immediately consecutive row. That is, if the status doesn't change, the row is eliminated. An example of this rearrangement feature is the following:

In this example, the third row before rearrangement is redundant because the status of the end-effector has not changed. (It is still closed.) Thus, since it is not necessary to store the status information for that location, that row is deleted before the matrix is stored.

When the CAD system is placed in the robot environment (by selecting "ROBOT" from AUTOCAD's pull-down menu in the disclosed embodiment), the following commands are available to the operator:

OUT: Allows the user to pick nodes and trajectories for a specified motion.

COMPILE: Transforms the graphical language to robotics movement commands. Checks joint limits (position, velocity and acceleration), generates data and C-language files.

GO: Compiles the c-routines and executes the motion of the robot arm.

HOME: Sets the manipulator to its home configuration.

RESET: Sets the encoder counts to zero at that particular configuration.

ECHO: Echoes the motion in a step by step reverse mode.

KMATICS: Sets the velocities and accelerations of each segment.

LEARN: Allows the computer to capture any manual given position.

GEN: Graphically generates the node location and orientation in the graphical environment (on the screen).

EDIT: Allows the editing of a Criptic node.

CRIPTIC: Establishes a Criptic node at the given position with the given UCS orientation.

SENSORO...5 Activates any of the six sensors for zeroing, homing and calibration.

POSITION: Reads the encoder positions at that configuration.

COMMAND: Lists the graphical environment commands.

This overview of commands can be better understood with the following additional explanations of certain commands:

EDIT: This command activates the autolisp function Edit() and is used for editing a Criptic node. In response to the EDIT command, the operator selects a node to edit by entering INS, followed by the desired node. Once a Criptic node is chosen, the name of the file associated with that Criptic node is stored into "d.backslash..backslash.I-name.txt". A command from within the autolisp file (e-scrpt.exe) is issued to activate the text editor. The Criptic commands can now be edited.

OUT and COMPILE: To move the robot arm from one node to another, the command OUT is selected by the operator. The operator is prompted to select nodes in an orderly fashion. If the robot arm is to move between node 1 and node 2, node 1 is selected first. After both nodes are selected, the command COMPILE is selected by the operator.

OUT and COMPILE are also used in conjunction to create trajectories between nodes as follows:

(1) The operator selects the command OUT;

(2) The operator selects node 1;

(3) The operator specifies a trajectory ARC;

(4) The operator selects node 2;

(5) The operator selects the command COMPILE.

The trajectories not only cause the robot arm to move from node to node along the trajectory but they also cause the orientation of the robot's end-effector to smoothly re-orient itself as it moves through the trajectory. Thus, for example, if the end-effector is to be oriented around the Y axis by 100 degrees at node 1 and by 200 degrees around the Y axis at node 2, the orientation will be approximately 150 degrees half-way through the trajectory. By the time that the end-effector reaches node 2, it will be properly oriented by 200 degrees around the Y axis. The extrapolation process for setting the orientation throughout the trajectory is performed within the program.

GO: This command is used to invoke an execution mode. After the GO command is selected, a series of compilations, bindings and linkings are performed. The operator has no control over the execution of these processes.

LEARN and GEN: In the learning mode, the user may teach the six generalized coordinates in the environment. To get into the learning mode, turn on the power to each individual robot axis motor and type "LEARN" at the command line. Once the learning mode is turned on, the manipulator is able to learn positions by simply leading the arm and memorizing configurations. To memorize (record) a configuration, the <F1> button is depressed. The <ESC> button terminates a learning session. When returning to the programming mode, a "GEN" (short for GENERATE) command can be issued. That will perform the automatic graphic generation of nodes on the screen. The following steps further explain the mechanics of LEARN and GEN.

1. When depressing function key <F1> , the six generalized coordinates are stored in units of encoder counts into the text file "D:.backslash.learn.txt" in the format of (a b c d e f). A space separates each joint coordinate.

2. The TRUE-BASIC file "Drct.sub.-- lrn.tru" then accesses the file "leran.txt", converts the text to numbers, then converts the encoder counts into joint angles and displacements.

3. The direct kinematics is then calculated for each node. It should be noted that the direct kinematics will be specific to the individual robot.

4. To display the correct position and orientation of each node, the UCS has to be changed accordingly without the involvement of the programmer. This was achieved automatically by means of programming using autolisp.

The Criptic node is an important feature of the invention. The Criptic language associated with each Criptic node includes one or more Criptic commands. It should be noted that Criptic language commands cannot be used directly at the command line of AUTOCAD. However, the robot commands described above can be used inside the Criptic nodes to create Criptic language.

The Criptic language which was created for this invention uses a high level language (C-language). Some Criptic language commands that can be entered into the text editor when a Criptic node is specified are as follows:

init.sub.-- io: set I/O configuration

set.sub.-- io: set an output port value

get.sub.-- io: get an input or output port value

get.sub.-- analog get an analogue input value

get.sub.-- position: get the current actual position

get.sub.-- command: get the current command position

get.sub.-- error: get the current position error

set.sub.-- filter: set the digital filter coefficients

controller.sub.-- run: set the controller into run mode

controller.sub.-- idle: set the controller into idle mode

get.sub.-- filter: get the digital filter coefficients

start.sub.-- move.sub.-- all: start trapezoidal velocity motion sequences on multiple axes

wait.sub.-- for.sub.-- all: wait for all of the motion sequences to complete

move.sub.-- all: start the motion sequences and wait for completion

set.sub.13 e.sub.13 stop: stop motion at the emergency deceleration rate

dsp.sub.-- status: get controller status

clear.sub.-- status: reset controller status: careful when used might change the status of a software limit of the arm

in.sub.-- motion: tests for in motion

in.sub.-- position: tests for in position

in.sub.-- sequence: tests for in sequence

axis.sub.-- done: tests for motion completion

The Criptic language code in accordance with the disclosed embodiment was written using Microsoft.RTM. QUICK-C version 2.50a. The flow control, operators, data types, preprocessor directives, and pointers can be used in the same manner as when writing a C-program.

The following rules apply to writing the main function:

a. The main body is not given any names (i.e. main() does not appear in the language associated with any of the Criptic nodes. This will allow the TR-driver to issue different names for each main body of different Criptic nodes. "TR-driver" is the main program of the TR-environment and is set forth in the Appendix.

b. The braces ({ }) associated with the main body function should not appear. This will allow the TR-driver to add functions, as well as edit them.

c. All variables (main body or functions) should be considered as local.

d. Pre-defined functions can be used anywhere in the program.

e. When specifying consecutive change-of-status to the end-effector, care should be given to the mechanical time delay. The end-effector might not respond if the commands are close to each other.

f. Referring one node to another (recognizing the position and orientation of a node from within a Criptic node) is possible by first finding the location of the node, then getting the encoder count from the "d:read.sub.-- c.txt" ASCII text file containing the kinematics information of each segment in the trajectory. This referring allows jumping out of the normal sequence of nodes planned in the program.

g. Once the main body and functions are written, the compiling and linking is performed by the TR-driver. The mechanism for compiling and linking Criptic nodes, C language, TRUE-BASIC and executable files is described below.

Automatic Compiling and Linking

The following steps are performed by the driver program to include Criptic nodes, executables, C-language object-files, and TRUE-BASIC files.

1. Each Criptic node containing the main body is read by the "TR-driver" program and assigned a filename. The filename is generated by obtaining the location of a node (insertion point), extracting the integer, then changing it to a string (e.g. for a node at 1.232,2.34,2.511!, the filename associated with it will be "122.txt".)

2. The C-language program is then generated by assigning a function name to the main body code. The assignment is performed according to the order the Criptic node is picked when planning the trajectory.

3. Several necessary files are then added by the driver program. For clarity, some of the file names and their functions are as follows:

inserts.txt--indicates the location of a node in space

cripts.txt--provides an ordered list of Criptic node positions

function.c--determines when to call Criptic nodes

fl.c...fn.c--file reach Criptic node(n=# of such nodes)

capacity.txt--indicates the number of move commands

read.sub.-- c.txt--contains all move commands (i.e., kinematics data indicating the coordinates in terms of encoder counts)

initial.txt--stores initial position before the next sequence of move commands are planned

try1.dxf--stores all of the coordinates of the graphical environment (i.e., everything that appears on the screen)

c.sub.-- link.bat, r.sub.-- link.bat--linking and compiling files

4. Once the kinematics data is written, the Criptic language is transformed into proper C-language, the end-effector data is produced, the necessary additional files are generated, and a compile statement is generated and saved into a batch file. The batch file can be executed when the command GO is issued. The batch file will have the following format:

COMPILE: (large memory model) (Drive:.backslash..backslash.path.backslash..backslash.filename ) Criptic language functions! C-generated functions! (LINK: Drive.backslash..backslash.path.backslash..backslash.Motion libraries executables)

Where

(): necessary text

!: optional--depends on Criptic nodes.

One example of Criptic language code is the following. (In this example, an optical sensor has been connected to the designated port 1, bit 0. If the optical light in the sensor is crossed, the sensor will go high.)

When the robot program reaches the Criptic node associated with that code, the code will be executed and the sensor will be interrogated. As long as the sensor does not go high (1), the controller will keep waiting for a signal.

The sensor could be a conveyor belt, another manipulator, a computer, or the like. Note, however, that the program is not included in a function definition such as VOID Check.sub.-- Sensor (int a, float b). The robot compiler generates names of functions and adds the necessary C-code so that this function can be called at the right time.

FIGS. 7(a), 7(b) and 7(c) illustrate the techniques described above for selecting nodes using CAD generated information instead of either directly inputting nodes via a keyboard or by an on-line technique of positioning a robot end-effector.

FIG. 7(a) shows three nodes, A, B and C, selected or picked along a CAD drawn line X-Y. Nodes A and C are located at the line's endpoints. Node B is located at the line's midpoint. Of course, the operator must still enter the orientation of each of the nodes.

FIG. 7(b) shows three nodes A, B and C picked on a CAD drawn wire-frame model.

FIG. 7(c) shows three nodes A, B, C picked on a CAD drawn solid model.

Once the nodes in FIGS. 7(a), 7(b) and 7(c) are fully defined (i.e., position, orientation and Criptic language code if necessary), the selected nodes will no longer appear as selected points on the screen but will be shown as node icons. This latter step, however, is not shown in those figures.

FIG. 8 shows a series of nodes connected by trajectories within a work environment which includes a workpiece in the form of a die set. A typical robot program will require the robot to move to (a) specified locations on a workpiece, and (b) points in space where it might wait for the next command or interact with a different workpiece. Thus, as shown in FIG. 8, many nodes will not be associated with a location on a workpiece.

FIG. 9(a) graphically depicts the results of a program written to execute a specific trajectory. In this trajectory, a pen attached to the end-effector follows a series of lines and arcs to spell out the word "PENN" on a 30 degree inclined plane. The pen attached to the end-effector must remain perpendicular to the plane at all times. Thus, the orientation of end-effector remains constant as the positions change. At various nodes, the pen must lift up from the plane in order to move to the next letter, thereby mimicking the motion of lifting a pen from a piece of paper if the human hand were to manually perform the same task. Of course, the benefit of the invention is that the operator can visually see all of the anticipated movements of the end-effector in three-dimensional space.

FIG. 9(b) shows a magnification of the program. It should be appreciated that many of the tools of the CAD environment, such as the ability to magnify portions of the screen, further facilitates programming and visualization of robot control functions.

FIGS. 10(a) and 10(b) show overview flowcharts of the process for converting data generated in the CAD environment into robot control data.

Each motor mounted on the robot arm in FIG. 10(a) is individually controlled through a proportional-integral-derivative digital filter. The filter is used to determine the output control signal from the input position error. There are six coefficients with which the output value in encoder counts is calculated.

FIG. 10(b) represents a simplified loop where the motors can be controlled directly from the CPU of a host computer. I/O ports are also made available for the operator to connect external sensors or devices. The end-effector mounted at the end of link number six (see FIG. 10(a)) is controlled by a user output port. Six sensors on the arm locate the "home" position and are controlled by dedicated output ports. The block labelled "2105 DSP" is a motion control board manufactured by Motion Engineering. That board allows for computer interaction between power amplifiers and encoders (position transducers).

FIGS. 11(a) and 11(b) show a more detailed flowchart of the process in FIGS. 10(a) and 10(b). AutoLISP.RTM. is used to interact with the operator to acquire all the necessary information.

FIG. 12 shows a robot suitable for interfacing with the graphical interface of the invention. That robot includes a unique robot arm formed from tube-shaped structural members and employs of brushless DC motors for movement. As noted above, however, it should be understood that the invention will operate with any six axis robot. Furthermore, the invention will operate with any robot having less than six axes since it is a simple matter to hold the variables associated with one or more unutilized axes as constants.

The Appendix includes a code listing of the program. The programs included in this listing are the more significant ones. The order is irrelevant since the program is modular and written in the form of "Libraries". Three types of programming languages were used; TRUE-BASIC by True-Basic Corp., QUICK-C by Microsoft Corp., and AutoLISP.RTM. by AutoDesk Corp.

The calls and activation to these routines is different. The TRUE-BASIC files, for example, are separately compiled and consequently linked together (bound) to form executable files. Some C-code is generated by the TRUE-BASIC files, compiled using the Microsoft QUICK-C compiler and then linked to other libraries such as (QCPCDSP.LIB) which includes the motion control routines carried out by the motion control board described above. AutoLISP.RTM. files are activated from within AUTOCAD.

The TR-Environment runs under any 3D-graphical package that supports the Drawing Exchange Files. The environment is designed to integrate all of the above mentioned languages and convert graphical six dimensional input into robotics language.

When running the program under AUTOCAD, once the AUTOCAD editor is invoked, all the files needed to run the TR-environment are loaded automatically (unless otherwise specified). This is done by supplying a file called "acad.lsp" in the search path. The "acad.lsp" file is loaded but not executed. Other functions that are written in languages other than AutoLISP.RTM. are loaded through the "acad.pgp" file and are automatically loaded as well. (See descriptions of files for more detail.) Once loaded, the environment will display the following message:

The novel graphical interface described above provides significant advantages not contemplated by the prior art. The novel interface allows an operator to employ a well-known CAD environment for easily entering and simultaneously visualizing plural robot configurations and trajectories in an interactive manner. The novel interface is readily switchable between on-line and off-line programming. The novel interface allows the end-effector state to be specified during the creation of configurations and employs a novel state that has programming code embedded therein.

The present invention may be embodied in other specific forms without departing from the spirit or essential attributes thereof and, accordingly, reference should be made to the appended claims, rather than to the foregoing specification, as indicating the scope of the invention. ##SPC1##