JPH06102916A - Device for converting robot operation program - Google Patents

Abstract

PURPOSE:To provide a conversion device which can convert the structure of programs in a unified system even if the operation programs of a robot is a matrix type or a non-matrix type. CONSTITUTION:The conversion device C of the robot operation program is provided with a means A dividing the operation program of the non-unified system into instruction blocks where a command is set to be a unit and a means B dividing the divided instruction blocks into step blocks regulating a shift operation. Here, the step blocks do not include plural instruction blocks regulating the shift operation of the robot. Thus, the converted program structures become the same system even if the operation program of the robot is either the matrix type or the matrix type.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a device for converting a motion program that defines a motion of a robot from a non-unified form to a unified form.

[0002]

2. Description of the Related Art Motion programs that define the motions of robots are often created in different formats for each robot and are not necessarily standardized. In addition, a simulator has been developed in order to check the operation program of the robot and to correct any incompleteness. In this simulator, an operation program is input (uploaded), the locus of movement of the robot and the like are calculated from the input operation program, and the posture and the like of the robot are animation-displayed based on this. As a result, the operator can check in advance how the robot operates based on the input operation program, and can make necessary program corrections. It is uneconomical to prepare this simulator for each robot. Therefore, a technique has been proposed in which one simulator can handle operation programs defined in different formats.
No. 176906.

According to this technique, a conversion device for converting an operation program between a non-unified form and a unified form is built in a simulator of a robot. Then, the simulator inputs (uploads) an operation program defined in a different format and converts it into a unified format. Then, the movement locus of the robot is calculated based on the operation program of which the format is unified, and the robot is animated based on the calculation. Then, if necessary, the operation program is modified in this unified format.
Also, if necessary, a unified form of operation program can be created in the simulator. The operation program whose operation has been confirmed by the simulator is converted into a format unique to the robot before input (download) to the actual robot. In this way, a single simulator can handle operating programs defined in multiple types of formats.

FIG. 3 shows the above-mentioned Japanese Unexamined Patent Publication No. 2-176906.
It shows an example of an operation program that can be handled by the technology described in Japanese Patent Publication No.
Acceleration, tools, interpolation method (for example, information such as linear interpolation or curved interpolation), data that determines input / output of signals, and the like are defined. This data is divided for each teaching point, and each of them is called a step block.

The upper part of FIG. 15 exemplifies various formats of an operation program defined in units of step blocks. The leftmost example is an example in which teaching point data is determined by the encoder value of each joint, and the center is the teaching. An example in which point data is defined by the position vector and direction vector of the arm, the rightmost side has teaching point data in a reference format, and the teaching point data to be referenced is stored separately. JP-A-2-
In the technology described in Japanese Patent No. 176906, file format conversion means CV1, CV2 ... CV for each format.
n is prepared and is used to convert into an operation program in a unified format illustrated in the lower part.

[0006]

The formats illustrated in the upper part of FIG. 3 and FIG. 15 are common in that data is defined for each teaching point. Hereinafter, this is referred to as a matrix type operation program. However, the operation program of the robot is not always the matrix type. For example, FIG. 2 shows an example of a non-matrix type operation program, and the teaching point is not a unit in this format. In the format of FIG. 2, the motion of the robot is defined in the language format.

The technique disclosed in Japanese Patent Laid-Open No. 2-176906 is based on the premise that the operation program for each robot is of matrix type, and the operation programs of different types are unified in the category of matrix type. It only discloses the technology to do. The unified format shown in the lower part of FIG. 15 still has a data structure with teaching points as a unit, and is a format that is completely unsuitable for a non-matrix type or language type operation program.

As described above, even the most modern operation program conversion apparatus described in Japanese Patent Laid-Open No. 2-176906 is limited to the matrix type, and the matrix type and the non-matrix type. There is no conversion device that can handle both. Therefore, in the present invention, it was decided to develop a conversion device capable of converting into an operation program of a unified format regardless of whether it is a matrix type or a non-matrix type. For that purpose, we have devised a new unified format that is compatible with both matrix type and non-matrix type.

[0009]

Therefore, according to the present invention,
As the concept is schematically shown in FIG. 1, it is a device for converting an operation program in a non-unified format, which is defined in a different format for each robot, into an operation program in a unified format. Means A for dividing the unified operation program into instruction blocks in units of commands, and means B for dividing the divided instruction blocks into step blocks that do not include two or more instruction blocks that define the movement operation. The conversion device C for the operation program for the robot provided was created.

[0010]

According to the conversion device having this structure, the language type operation program is divided into step blocks by the step block dividing means B. Here, the step block is a unit of an instruction block that defines the movement motion of the robot, and does not include a plurality of instruction blocks that define the movement motion. On the other hand, the matrix type operation program is divided into instruction blocks by the instruction block dividing means A. Here, the instruction block has a command as a unit.

Therefore, whichever format is converted, the converted program structure has the same format. That is, one operation program is unified as a form of a set of step blocks that includes one or a plurality of instruction blocks and does not include an instruction block that defines two or more movement operations. In this way, according to the conversion device of this configuration, both matrix type and non-matrix type conversion can be performed.

[0012]

FIG. 4 shows the system configuration of an embodiment embodying the present invention. In this embodiment, the present invention is incorporated into a simulator of a robot. This simulator is composed of a post processor 1 and a main processor 3 connected by a communication line P. The post processor 1 mainly converts a part of the format of the motion program and the attribute data of the robot and inputs / outputs them. The main processor 3 mainly calculates the movement locus based on the operation program and the attribute data of which the formats are unified, displays the animation, makes necessary corrections, and saves it in the database.

The post processor 1 transfers and partially converts and rewrites the operation program and attribute data of each robot, and is provided with a flexible disk drive 2 for reading and writing the flexible disk FD outside. This post processor 1 is a well-known CPU, R
It is configured as an arithmetic logic operation circuit from OM, RAM, etc., and has a built-in storage device such as a hard disk for storing a large amount of data. According to the function of the post processor 1 realized by such an arithmetic logic operation circuit,
Explaining the configuration of the post processor 1, n operation program files od for storing operation programs and attribute data corresponding to the robots R1, R2 ... Rn of each model,
N file format conversion units CVn for converting the operation program files od of different formats into the operation program files OD of the unified format, and the operation program files OD of the unified format for storing the converted operation programs and attribute data, An interface 4 for outputting these data to the main processor 3 via the communication line P is provided.

On the other hand, the main processor 3 includes a display device 5, an input device 7, a large computer 8 and peripheral devices 9.
Are connected via respective dedicated interfaces 10. These devices will be sequentially described. Display device 5
The main processor 3 displays the position / orientation data and graphic data of the robot, work, etc. Interface 1
It is received via 0 and the figure of the robot or the work is displayed based on the data. Since these data are output to the display device 5 and updated at regular time intervals, by repeatedly displaying them, the movement of the robot can be animated.

The input device 7 has various forms such as a keyboard, a digitizer, a mouse, and a dial selection type input switch, and inputs necessary data through the input interface 10. Large computer 8
Is a large machine having a function such as CAD, and is capable of handing over the graphic shape data of a robot or a work created by using CAD to the main processor 3. When the shape data is received from the large-sized computer 8, it is stored in the database 15 in the main processor 3 as the shape data file KD. In addition, via the interface 10 to the main processor 3,
Peripheral devices 9 such as printers, plotters, and magnetic tapes are connected, and data can be transferred to and from these peripheral devices 9.

Next, the internal structure of the main processor 3 and the function of each part will be described. In the main processor 3, a database 15, a graphic creation unit 21, a robot attribute definition unit 22, a robot / work placement unit 24, a robot teaching unit 25, a data management unit 27, a robot reproduction unit 29,
The trajectory calculation processing unit 30 is configured. Each unit is not configured as specific hardware, but a function realizing unit including software in a well-known arithmetic logic operation circuit using a CPU, a ROM, a RAM, and a large-capacity storage device such as a hard disk. It is realized by the information stored in.

The figure creating section 21 is a section for creating each axis shape of each robot, the shape of a work, etc. using the input device 7 and the display device 5, and has a function similar to so-called CAD. The data created here is used when simulating the motion state of the robot and examining its posture and the like. The created shape data, etc. are stored in the large computer 8
Similar to the case of inputting from, the shape data file KD is saved in the database 15.

The robot attribute definition unit 22 has a function of registering the shape data created as the shape of each axis of the robot for each axis of the robot. That is, the positional relationship of each axis, the movable form such as slide and rotation, the movable range, the operation speed, the upper limit value of acceleration, and the like, and the robot attribute data such as which axis of the robot these data are associated with are input from the input device 7. Created and stored in the database 15 as an attribute data file ZD. By loading the attribute data file ZD of each robot defined by this function and the shape data file KD created by the graphic creation unit 21 into the database 15 as necessary, the graphic data is converted into a robot on the main processor 3. It will work and be displayed.

The robot / workpiece arranging unit 24 has a function of arranging the shapes of the robots and the workpieces created by the above-mentioned functions, that is, defining the positional relationship of each object. That is, the graphic data file KD and the attribute data file ZD are loaded into the database 15, the position data of each object is input to the data by the input device 7, and each object is arranged by correcting as necessary, The examination result is saved as the arrangement file HD.

In the robot teaching section 25, the robot operation program such as the robot tip position and posture input by the input device 7 can be created and corrected while checking the display device 5 for confirmation. This operation program is saved as an operation program file OD2. Post processor 1
It is also possible to obtain the operation program file OD via the communication line P, and the input operation program file is temporarily stored in the file OD2. It is also possible to load this program on the database 15, modify it with the input device 7, and save it again in the operating program file OD2.

The data management unit 27 controls the shape data file KD, the attribute data file ZD, the arrangement file HD, the operation program file OD2 and the control of the peripheral equipment 9, and the communication with the large computer 8 and the post processor 1. Is. The robot reproducing unit 29 uses the database 1 to store each data created by the functions described above.
After being loaded on the robot 5, the locus calculation processing unit 30 receives the locus calculation, and the movement of each robot is displayed on the display device 5 as an animation. The data that the robot reproducing unit 29 retrieves from the database 15 and passes to the trajectory calculation processing unit 30 is data necessary for robot operation, that is, data such as a target position / posture, velocity, acceleration, and an interpolation method. The locus calculation processing unit 30 receives these data,
The position and orientation values of the interpolation points up to the target value are calculated to obtain the position and orientation data of the robot. By causing the locus calculation processing unit 30 to execute this processing at regular time intervals and passing the data to the display device 5 each time, animation display of the robot is performed.

Next, the processing in the simulator of this embodiment will be described with reference to FIGS. Figure 5
6 is a flowchart showing the processing in the main processor 3, FIG. 6 is a flowchart showing the upload processing of the operation program in the post processor 1, and FIG. 7 is a flowchart showing the download processing.

When simulating the operating states of various types of robots, the main processor 3 first creates the shapes of robots and works by the function of the graphic creating section 21 (step 100). Next, the robot attribute definition unit 22 defines the attributes of the robot and tools (step 110). Then, the robot work placement unit 24 examines the placement of the robot and the work (step 120). The above processing (steps 100 to 12)
According to 0), a figure to be considered is created regarding a series of manufacturing processes using each robot.

Next, processing for obtaining the operation program of the arranged robot in a unified form is performed (step 130).
For this processing, two methods can be adopted. One is a method of obtaining an operation program from each robot actual machine, and the other is a method of creating it using the robot teaching unit 25 of the main processor 3. In the former case, as shown in FIG. 6, in the post processor 1, the operation program is received from the actual robot in the form of the flexible disk FD and uploaded to the operation program file od (step 132), and in a format unique to the robot. The created operation program is converted into an operation program file OD in a unified format by the corresponding file format conversion unit CVn (step 134). The operation program in the unified format thus obtained is transferred from the interface 4 to the main processor 3 via the communication line P (step 136). Since some of the attribute data are necessary for the trajectory calculation, in such a case, the attribute data is transferred together with the operation program. The medium for exchanging data with the actual robot need not be limited to the flexible disk FD, but may be magnetic or paper tape, and may be a medium for exchanging data directly via a communication cable.

After the operation program is obtained by any method, a process of displaying an animation is performed by the functions of the robot reproducing unit 29 and the trajectory calculation processing unit 30 (step 140). Here, the locus calculation processing unit 30 performs a forward conversion process of obtaining the position and orientation of the tip from the angle data of each axis of the robot Rn, and conversely, an inverse transformation process of obtaining the angle of each axis from the robot tip position and orientation. Conventionally, since it is difficult to analytically solve this inverse transformation processing, a unique trajectory calculation processing unit is provided for each type of robot,
Each is executed with its own constant and processing algorithm. On the other hand, in this embodiment, the operation program is in a unified format regardless of the robot model,
Numerical calculations such as the Newton-Raphson method can be performed to calculate the angle of each axis regardless of the number and type of axes of the robot. After that, it is examined whether or not there is a motion to be corrected due to robot interference or the like (step 150),
If there is, the operation program and the arrangement of the robot work are corrected (step 160), and if there are no more points to be corrected, the completed operation program is transferred to the post processor 1 (step 170), and this routine ends. To do. Since some of the attribute data need to be passed to each robot Rn, they are transferred to the post processor 1 together with the operation program.

The post processor 1 receives the transferred file as shown in FIG. 7 (step 18).
0), the received operation program in the unified format is rewritten by the file format conversion unit CVn corresponding to each robot (step 190), and this is downloaded to each robot Rn in the form of a flexible disk FD or the like. (Step 200).

The processing of the main processor 3 and the post processor 1 has been briefly described above. The details of the conversion / accumulation processing of the operation program in the processing of the post processor 1 will be described below.

An example of the specific contents of the operation program obtained from the robot controller built in the actual robot Rn is shown in the upper part of FIG. In the operation program,
Data representing a target position and posture at which the robot Rn operates,
Data related to movement conditions such as movement speed, acceleration, interpolation method (linear interpolation, circular interpolation, uniform interpolation for each axis, etc.), I / O switch ON / OFF, timer (waiting time), hand open / close switch (air gun ON / OFF, etc.) There is data on auxiliary functions such as. A set of these data is called a step block. The operation program of each robot is configured as a set of step blocks as shown in the upper column of FIG. As is clear from the example shown in the figure, the format of the data differs from robot to robot, and for example, the robot that displays the data indicating the target position and posture in the number of bits of the encoder that indicates the rotation angle of the drive motor for each axis of the robot If so, a robot that represents the rotation angle in units of angle [deg], or There are robots represented by.

In addition, if it is data relating to movement conditions, for example, when an operation speed is designated, a robot represented by an absolute value [mm / sec] and a unique speed table are provided. There is a type in which the speed is defined in advance and the speed number is specified in the operation program by specifying the code number.

Further, some data of the same format have different meanings. For example, for a robot whose code 1 means linear interpolation and code 2 means circular interpolation,
There is also a robot in which "" means linear interpolation and "Code 1" means circular interpolation. In addition to this, there are differences in data notation (binary notation, ASCII notation). In this way, since the format and meaning of the individual data of the step blocks forming the operation program in the robot controller are different for each robot, the file format conversion unit CVn
Each item is converted into a unified format (standard format), and the unified format is obtained as shown in the bottom column of FIG.

In the conventional simulator, an operation program of the format illustrated in the upper part of FIG. 15, that is, as shown in FIG. 17, one operation program (this is called a program block) is constructed as an assembly of step blocks. On the premise that this is the case, we will unify those that have different formats in this category. For this reason, the file format conversion units CV1, CV2, ... CVn in FIG. 15 are each configured to execute the processing in FIG. Ie step 3
The target robot is designated by 00, and which operation program of the robot is to be handled is set (step 310), and then data is input for each step block (step 320). At this time, the data format is converted, and after step 320 is executed, the operation program has a unified format. This process is step 33.
Continue until 0 is no. As a result, the operation program is converted into a unified operation program in the format shown in FIG.

However, the robot operation program is not always defined as a set of step blocks.
For example, FIG. 2 shows an example thereof, and this operation program is defined as a set of instruction blocks as illustrated in FIG. If all the operation programs are defined as a set of instruction blocks, the program structure can be unified by executing the process of unifying the data format for each instruction block as shown in FIG. . However, it is impossible to handle the robot programmed by the step block and the robot programmed by the instruction block by one simulator by the conventional technique shown in FIGS. 16 to 19 or its extension technique.

Therefore, the file format converters CV1, CV2, ... CVn according to this embodiment are programmed so as to execute the processing of FIG. In step 502 and step 504, the target robot and the target program are designated. Then, in step 506, the first command is loaded. Next, the parameters are loaded (step 508).
Then, an instruction block is generated in units of the command and the parameter (step 510). This concrete example is shown in FIG. 11, and the operation program of the format of FIG. 2 is divided into the instruction blocks shown in the lower half of FIG. FIG. 12 shows how the operation program of the format shown in FIG. 3 is processed, and is divided into an instruction block 999 consisting of a command of SPEED and a parameter of 100 corresponding to the speed 100 of step 1, for example.

After being divided into instruction blocks in step 510 of FIG. 8, it is then determined in step 512 whether or not the instruction block defines an "end" command. If it is not "end", then it is checked in step 514 and thereafter whether it is the final signal input / output processing, branch processing or arithmetic processing.

The instruction block is one of "label", "operation", "operation condition", "signal input / output", "branch processing", "arithmetic processing", and "end". Then, in step 514, the next data is the "label".
It is determined whether or not. In step 516, it is determined whether the next data is "motion". Further, in step 518, it is determined whether the next data is "operating condition". If either of these is YES, the step block is updated in step 522. As a result, one step block includes 0 to 1 instruction blocks that define the moving operation, and no two or more instruction blocks are included. For example, the instruction block 10 of FIG.
In the case of handling 00, the next instruction block 1001 indicates the operating condition. That is, the instruction block 1000 is the final signal input / output processing, and next is the operating condition. Therefore, step 52
In FIG. 2 (FIG. 8), the instruction blocks up to the instruction block 1000 are regarded as one step block. Other Step 5
If the next block at 16 is "motion", it is also regarded as one step block. This case is shown in step block 3 of FIG. That is, since the instruction block 1002 is a branch process and the next block is “operation”, the step block is divided here. Also, if the next instruction block is a label name in step 514 of FIG.
It is divided into two step blocks. This case is recognized between step blocks 7 and 8 in FIG.

As a result of the above processing, all the operation programs of any type have the structure shown in FIG. 9, that is, one step block includes one or a plurality of instruction blocks (provided that two or more movement operations are specified. Instruction blocks are not included), and the step blocks are aggregated to form a single operation program (program block). Note that according to the processing of FIG. 8, one instruction block is composed of commands and parameters, and one step block is divided in units of the instruction block that defines the movement operation of the robot. That is, one step block is shown in FIG.
As shown in 0, it is composed of an instruction block indicating an operating condition or a label, an instruction block indicating a movement instruction following the instruction block, and an instruction block indicating a signal input / output or a branching operation or an arithmetic operation processing which follows the instruction block. The reason why one step block is divided so as to include zero or one move instruction is to divide the program in steps 514, 516 and 518 of FIG.

As is clear from FIGS. 11 and 12, the operation program of this type is familiar to both matrix type operation programs and non-matrix type operation programs, and it is possible to handle both in a unified manner. There is.

13 and 14 show a processing procedure when the robot teaching unit 25 creates an operation program in the simulator. FIG. 13 shows a processing procedure when an operator inputs in the instruction block format, and FIG. 14 shows a processing procedure when inputting in a matrix format. Also in the case of the processing of FIG. 13, the input instruction block is divided into step blocks by the processing of steps 614, 616, 618. In the case of the processing shown in FIG. 14, the data is input in the matrix format. In this case, the commonly used instruction initial data is input in advance (step 706). For example, when the operation program of FIG. 3 is created, a commonly used command such as speed 100 or acceleration 100 is input in advance. Next, when teaching point data is input (step 708), an instruction block is generated from the teaching point data and the instruction initial data (step 710). Then, the step block is updated for each step block (step 712). If the additional instruction block shown in the function column of FIG. 3 is required, in step 718, the instruction block showing the function is generated.

As a result, as shown schematically in FIG. 9 and specifically in FIGS. 11 and 12, all operation programs have a hierarchical structure of instruction blocks and step blocks, and their formats are unified. To be done. The operation program whose format is unified in this way is shown in FIG.
It can also be modified according to a procedure similar to that shown in FIG. 14, and the confirmed operation program is stored in the database 15. The operation program in the unified format is converted into a format for each robot (step 190) and input to the robot (step 200) at the time of downloading shown in FIG.

[0040]

According to the conversion apparatus of the present invention, the operation program is divided into instruction blocks, and the divided instruction blocks are divided into step blocks. Therefore, this conversion device can be applied to both matrix-type operation programs and non-matrix-type operation programs, and has a unified format after conversion. Therefore, for example, the number of robot target models that can be handled by one robot simulator is increased, and the program modification for increasing the number can be minimized.

[Brief description of drawings]

FIG. 1 is a diagram schematically showing the concept of the present invention.

FIG. 2 An example of an operation program (non-matrix type)

FIG. 3 is an example of an operation program (matrix type)

FIG. 4 is a system configuration diagram of an embodiment.

FIG. 5: Processing procedure by main processor 3

FIG. 6 is an upload procedure by the post processor 1.

FIG. 7: Download procedure by post processor 1

FIG. 8 is a conversion procedure by the post processor 1.

[Figure 9] Unified format data structure

FIG. 10: Structure of step block

FIG. 11 shows an example of a unified format operation program.

FIG. 12 is another example of a unified format operation program.

[Fig. 13] Procedure for creating an operation program (non-matrix type input) with a simulator

FIG. 14: Procedure for creating an operation program (matrix type input) with a simulator

FIG. 15 is a diagram showing a manner of unifying operation programs of different formats in a matrix type category.

FIG. 16: Procedure for unifying matrix type operation programs

FIG. 17: Data structure of matrix type operation program

FIG. 18: Procedure for unifying non-matrix type operation programs

FIG. 19 is a data structure of a non-matrix type operation program.

[Explanation of symbols]

Converter C: Post processor 1 File format converter CV Instruction block division: A; Step 51
0,520 step block division: B; step 522

Claims (1)

[Claims] 1. A device for converting an operation program in a non-unified format, which is defined in a different format for each robot, into an operation program in a unified format, wherein the operation program in a non-unified format is in units of commands. And a means for dividing the divided instruction blocks into step blocks that do not include two or more instruction blocks that define a movement operation.